If the pattern is consistent, it gets easier to ignore the noise when you don't need it. Like, a three/four digit number or a 3 letters and 3 numbers separated by a hyphen.
Sometimes, an issue might depend on another issue and contain commits from the other branch. Tagging each commit makes it easier to pinpoint the exact reason for that change.
* File issues in a project tracker (Github, jira, asana, etc)
* Use the issue id at the start of every commit message for that issue
* Use a single branch per issue, whose name also starts with the issue id
* Use a single PR to merge that branch and close the issue
* Don't squash merge PRs
You can use `git blame` to get the why.
git blame, gives you the change set and the commit message. Use the issue id in commit message to get to the issue. Issue description and comments provide a part of the story.
Use the issue id, to track the branch and PR. The PR comments give you the rest of the story.
I built Git-chain to help with branch management in trunk-based development workflows.
When you want to keep changesets small and reviewable, but still build new work on top of unmerged changes, Git can get messy fast. Git-chain makes it easier to track and manage these dependent branches cleanly.
Would love feedback — especially from teams doing trunk-based development!
I am in the exact same situation as you. I live in Sharjah. my github: https://github.com/hammadfauz
Most of the times, I want to make something, but I have no idea what. If you or anyone has something neat to do, I'll be glad to participate.
To me, it is not at all alarming. But it might be due to my inexperience in dealing with truly huge code bases.
No matter what framework, in the end it's all JavaScript. So even if I develop a flashy app using a nice fat framework, it is still going to run unless JavaScript itself is changed.
That said, I can build an app in Angular today, and when something flashier comes out, I can code new features/modules to my app using that.
Interesting read. As with all things, absolute extremes must be avoided. If we stop and work out solutions to problems already worked out every time, when would we find time to build upon the solutions? Transfer of knowledge is one way, we as a species succeed even with the limited lives we have.
In programming, for example, while it is important to learn how basics work, if I try to write everything from scratch instead of using a library, I am doing it at the expense of furthering human capability. I mean, I just need to know, that I _could_ whip something up, if it didn't exist. Since it does, my time would be better spent on using it to create something even more functional.
Created a simple interface for communicating between generic objects. Mainly as an exercise to teach myself OO JavaScript, and design patterns. Looking for criticism and feature requests.
I didn't realize there there was a name for it. Nobackend. catchy. I use SharePoint server as a nobackend solution. All the apps I write are client-side JavaScript. User profiles, permissions, and authentication are left to SharePoint to deal with. I create lists, query and update them via web services provided out of the box. Even search is provided by a web service, so I don't have to worry about indexing content. All I have to do is build user-centric clients for dealing with the data. It's brilliant.
Hoodie sounds like a great generalization for that, in a public/non-corporate domain. Plus it has events for displaying data changes immediately. What's not to like?
I just got an insight upon reading this. Patents stand to incentivize the research and development, the failures that precede innovations. On the other hand, they hinder research and development that builds on existing technology.
A good middle-ground would be patents being applicable only on rights to create _products_ based on a technology. Rights for any products based on a derivative patent belong solely to that patent, with nothing going towards the 'parent' patent.
This encourages the incremental innovation, as well as pushing the original inventor to continue to improve on their own patent.
For example, let's imagine someone patented a glass bottle as a container for ketchup. Any glass ketchup bottle makers pay that person. A person examines that glass bottle, observes that breakage of glass is a problem, and patents a plastic ketchup bottle. All plastic bottle makers buy their rights from this person. Glass bottle makers (if any) continue to pay the original patent owner for their rights. The glass bottle person, improves upon the plastic bottle, and gets a patent for a squeezable plastic ketchup bottle...You get the idea.
I pity the poor little kid. At this stage in life, people (none other than her parents) are already concerned how she is going to contribute to the world. Let her live for a while. Let her explore, find a path that's interesting to her.
I know programming is the future, its the basic skill that will be necessary for all professionals. But let her learn to walk, see, smell, touch, taste the world around her. Sheesh.
Limited liability is just not fair. If an entity's (Person or corporation) actions cause harm, they must be held liable for the full extent of the harm that they have caused, matching their level of participation in said activity.
What is really at fault here is the tort law, that allows plaintiffs to sue for unreasonably huge amounts, and for ridiculous reasons. In the example given in the article, a person could be sued for owning shares in asbestos production, in the past for as short a time as 10 min. I think that person should be liable, how else would the peoples' grievances be fulfilled. Partially fulfilled grievances is not a fair solution.
I also think it is unfair to hold that person liable for a huge amount. His liability should be calculated based on how many people he affected during his 10 min of holding the shares, and how many shares he had in the establishment during that time.
TLDR; Liability should be limited by the extent of participation in harmful activity (whether intentional or not) and to the measurable amount of damage done rather than arbitrarily.
Sometimes, an issue might depend on another issue and contain commits from the other branch. Tagging each commit makes it easier to pinpoint the exact reason for that change.