This looks promising. I'm looking forward to exploring this further and seeing its practical applications in streamlining document-related workflows. It's always refreshing to see new solutions emerge that potentially shift how we approach common challenges.
Why would China try these postures when the opposite country is neck deep in handling a pandemic and one which originated from its land. Is this any time for a bloody battle or power trips?. May be there is more to it than the reasoning you mentioned. Internal frictions are starting to get visible against premier due to the way he handled the covid and how much repair it has caused China globally. May be he is trying to do all this antics to shore up nationalism and create a new problem/diversion which makes covid related ones to take a back seat.
> India doesn't stand a chance in an actual conflict
If its a full blown war then may be yes. But two nuclear powers going all out and all alone will not happen so others will step in. It would complicate things for China. Ideally it should be conventional and a very short one. The rules for engagement can't be escalated, that means China has to work with severe geographic disadvantages.
Chinese investment money is everywhere so they try to control the narrative. I have seen for sometime that on HN, we are open to criticize but don't take a standpoint unless its something to do with western government.
I think this is due to the flame war or rating system of HN, where active discussions are relegated to oblivion. Instead of trusting biased and funded media - we here need to introspect, without us being silenced.
May be we are mostly left so we don't have a much stronger opinion unless its right - is that the case?. Just curious - why the slack?.
If yours is a small team and if many things are keeping your team busy - never address a technical debt head on until you can afford the luxury or until the business demands warrant for it. Most engineering team focus too much on technical elegance and go overboard. Rewrite culture can become nasty if unchecked.
> But there is a trick you could use if you're not a programmer: visit a top computer science department and see what they use in research projects
Please don't shoot yourself with this suggestion. From my personal experience Academia is so distant from what is relevant or practical to the industry.
Somewhat related, most academia is not focused on source code quality or its suitability for posterity. If you absolutely need to mime or plunder academia to succeed in your startup, pair that with a software industry veteran who can scale and secure your technology operation.
I have the opposite opinion. US funding sources for science and engineering tend to be very government-heavy rather than industry-based; but in my experience those government grants, particularly DoD, emphasize research with specific practical ends. The obvious exception is NSF, but Europe also has similar obvious exceptions at about the same rate.
The big difference between the US and Europe, however, is that universities in the US depend on grants to fund PhD students. Many (most?) European countries have national funding programs for their PhDs, which frees up both the students and their advisors to work on whatever fancies them regardless of practicality. France is particularly notorious for this. US academics do not have this luxury.
In my field, by far the lion's share of impractical (Fun! I love it! But impractical) work comes from Europe.
Yeah this is specific to Europe, in particular Germany, where companies such as BMW would send engineers to work on a defined research project at a university, and then adopt the research if it pans out. In the US there’s far more leeway, and part of being a good PI is stealthily inserting yourself own agenda into the DOT grant proposal, and those in the DOT will give you the leeway knowing that’s “how it works”
I guess this varies a lot. To my shame I don't have hard numbers (! I really should have.)
Personally I've worked on a half dozen global research network projects bringing together both public and private funding and 10-15 organisations, mixed universities, research institutes, and small to behemoth companies.
The target is always some wide ranging new radical technology platform and they spawn a bunch of startups and spin off projects.
Some targets can turn out to be too difficult, or simply wrong, but I've never seen a project that hasn't lead to at least one startup / product / new technology.
Eg: Start out looking at nanoparticle functionalisation, then stumble on a very useful sensor application or targeted molecular delivery.
Eg: Work on autonomous air sensor, then find simple off shoot application for tuberculosis using a completely different technology.
Eg: Build a medical laser for transdermal drug delivery then find applications in dental work and scar tissue removal.
Eg: Design a flexible heterogeneous compute cluster for hpc application, then get customers who want it for the low administration cost.
You start by bringing some very competent and diverse people together to tackle some tricky and new problem. Then after a while you'll have found a bunch of peripheral questions and applications for one thing or other you create in the project.
People talking and sharing experience and knowledge will almost always find new stuff out in the dark. If you're working on the edge of knowledge there is almost always interesting stuff hiding just outside the light of your personal flashlight. Bringing people together in multidisciplinary projects is amazing.
I don't see any tech solutions mentioned out here. At least i would like to take a shot.
Not relying on government is the way to go.
I think we should build a social network for community welfare which can prepare us for something like this in future. Where people build communities among themselves. Key point being internal resource availability to be exposed to the close knit network and an external pool exposed to an radius. Keeping everything to the close knit shouldn't be encouraged and there should be a proportion. Ideally the network should be split when its crossing a proportion.
How do we keep up with something like covid-19 in future?. I don’t think relying on government is the way to go.
Why not build a social network which helps to build close knit communities and it can have a cascade effect on the whole populace as a side effect("good"). Some of the key points for it to work being:
# Pool resources before hand so that the whole system is not suffocated.
# Internal resources exposed to close knit.
# External resources exposed to a radius.
# Cap on internal vs external resources.
# Split the community into smaller ones when it reaches a proportion.
# Point system to motivate communities.
# Ability to mobilize resource across communities.
This need not be the case with just a pandemic but can help us tide over other eventualities as well.
you need more connections than what a single AWS CLI process open to saturate network on a big box. You can achieve the same by doing some "xargs | aws cli" trickery but then error handling becomes harder.
Our S3 client just handles multiple worker processes correctly with error handling.
Its hard to estimate without breaking it down to smaller tasks and this process is laborious. This process assumes we are tackling stuff in which we already have expertise.
The rule of thumb i use - anything which takes more than 3 days needs to be broken down further into tasks. If any task takes more than 3 days during execution then it needs to be broken down to more tasks.
I use the following convention to start the subject of commit(posted by someone in a similar HN thread):
Add = Create a capability e.g. feature, test, dependency.
Cut = Remove a capability e.g. feature, test, dependency.
Fix = Fix an issue e.g. bug, typo, accident, misstatement.
Bump = Increase the version of something e.g. dependency.
Make = Change the build process, or tooling, or infra.
Start = Begin doing something; e.g. create a feature flag.
Stop = End doing something; e.g. remove a feature flag.
Refactor = A code change that MUST be just a refactoring.
Reformat = Refactor of formatting, e.g. omit whitespace.
Optimize = Refactor of performance, e.g. speed up code.
Document = Refactor of documentation, e.g. help files.
Yes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary).
The whole thing should be width limited to 80 or 100 characters.
And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.
At my work we almost encourage the blog post in there idea.
It's not a hard and fast rule and it's ok to ignore it when it makes sense. But we also don't mind if your commit message takes longer to write than the code took to change and debug.
A lot of context is assumed in commits, and almost all of it is temporal. Capturing as much of that as possible pays off down the line.
Commit in the article is a good example where the context explains much more than the change.
(On the flip side, the pay off has an expiry date so I'm not extremely fussed when people lax, but it's still good to check in basic assumptions whith your code)
well, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p
After a few days practicing this, it becomes second nature, and doesn't hold you up at all. Commit histories also become much quicker to parse through, especially with "log --oneline".
I notice no hindrance on my speed because I write good commit messages, and always value them when I one back to them.
> And the subject line should complete the sentence "If this commit is applied, it will...".
I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!
I think that’s opposing incorrect things, in this case. I think the spirit of The Law should be clear and kept alive. Whether to “[If applied, this commit will] <commit msg here>” or “[This commit]<verb> <work description>” is a tiny matter of difference when the point is clear, straightforward, complete commit msgs of logically discreet-and-coherent commits. Both the above formats would fit the bill, and I think I’d be thrilled if my biggest issue w code commits amongst my team were only these two slightly different formats.
The other thing I do is add a "MODULE:" prefix to my commit message. It makes them way more readable. Lots of other people do this too; you can see this in Redis, Linux, and Go codebases, for example.
So your message might look like "router: add support for path vars". Much easier to read than "Add support for path vars to router"
I don't stick to it as a rule but if it's clearly grouped in some way it gives people in the wider org a high level fyi about the area of code you're messing with.
Makes it easy to jump over the commit when bisecting for regressions or hastily looking for the buggy commit to revert.
I also use something like this. A variation of Angular's commit convention[1]. There are tools like commitizen[2] that can help new adopters to build commit messages.
I work at a place that used to prescribe this. I dislike it because it adds too much repetitive noise to the abridged git log. (It occurs to me that you may be making this point in a tongue-in-cheek way.)
Originally I suggested we put the JIRA number/link in the commit body, but then I learned about git-notes to add metadata to commits and now I kinda want to do this with the semantic labels suggested by the thread OP, too (I currently use the schema suggested at https://seesparkbox.com/foundry/semantic_commit_messages).
Notes kinda bloat the repository with additional objects, and they can be removed independent from the commits, so I'm a bit iffy on using them for this.
The branch is called feature/<Ticket ID>-<short-description>
The commits contain usual commit messages. When merging, changes are quashed. The final commit message is similar to the branch name and includes the ticket and a short description, which is similar to the mentioned pattern (bump/add/change/whatever).
I find that awful, because now half your subject line is burned by completely useless information: the JIRA ticket number doesn't provide any useful information when reading a git log / summary.
Yeah and if you no long use JIRA it's not useful. Whatever bug tracking software you use should allow for commits to be attached to bugs. But that should stay in the bug tracking software, not the VCS.
I see pretty consistent vocab used across orgs anyway, so given there is shardd domain knowledge / language at play, im not sure what the goal for standardization is?
Don't take this the wrong way, I use a lot of these when appropriate, but I don't think I could agree that refactoring must be just a refactor, and I don't think I want to limit anyone's commits to this list of change types either.
Forcing changes into these words means a lot of stuff is pointlessly bucketed when more appropriate wording could be used.
Say I want to push a commit "prioritise shipping route a over route b".
So I have to put it under start? Optimise? Fix? Why? Prioritise is the right word, why not just use that? Why play mind games when we have a whole dictionary to draw from?
