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!
In the US, the purpose of a resume is to get an interview and the standard is short and to the point. That's where I am coming from.
Think of how much work the website generates for the person treating it as a resume. There's processing the navigation, clicking links, trying to figure out what is relevant.
The site is more of a work sample than a resume and those serve different purposes.
Of course other cultures may have different standards.
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.
I think the main problem is about fixes. Invariably, something is going to go wrong in the future with whatever framework you use. Either security related or else. Then your version of {{framework}} won't be supported anymore and you'll have to:
- fix it yourself
- give up: turn off your app
- ignore: let people deal with the issue/be vulnerable
If your version of {{framework}} is supported, likely all you'll have to do is wait for a patch.
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.
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 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!