Today people are much more reliant on real-time collaboration, polished cloud and mobile experiences. Fractionalized open source software has a harder time competing with this than file based boxed software workflows of the past.
970 karma · joined April 24, 2012
Today people are much more reliant on real-time collaboration, polished cloud and mobile experiences. Fractionalized open source software has a harder time competing with this than file based boxed software workflows of the past.
I do not use it collaboratively. I use it to continuously ship smaller things while working on bigger pieces and I constantly move independent changes around to different “lanes” to ship frequently as parts of my work mature.
With Magit I used staging area and amended commits continuously. With GitButler I “assign” files or chunks by dragging them into lanes as I am happy with the changes, and when I have a logical unit I commit it. Having this multiple staging areas has been a great workflow improvement as well.
GitButler does this cool thing where you can work on multiple branches at the same time, applied to the same working directory. For example you can work on the css while an agent works on the admin panel on a separate branch. It would be cool to have this with a tool like FleetCode.
This is much cheaper to run on a server. For example: https://github.com/ozanmakes/scrapedown
- Remove curly braces from props and children
<MyComponent name="Joe" onClick=(() => canBeInParanthesis()) />
<div>userName</div>
<div>"Text contents"</div>
- Add punning (like how { age: age } becomes { age } in JS) const age = 40;
<MyComponent age />/
<MyComponent active=true /> // explicit boolean attributesSome other fun examples: https://gist.github.com/ozanmakes/0624e805a13d2cebedfc81ea84...
Once, a team at my old job wanted to try A/B testing for the first time. After some research, they picked a SaaS tool to make it quick. Simple, right? Just sign up and go.
Of course not. First they had to go through THE PROCUREMENT! (dun dun dun dun)
Those legends weren’t about to let us limp along on a humble pro plan. They wheeled, dealed, and months later emerged triumphant: a glorious three-year enterprise contract. SLAs! Volume discounts! The whole nine yards. The art of the deal baby!
Small snag: by the time the ink dried, the original team had moved on. New PM, new priorities. No one even generated an API key during the whole time we paid for this top-tier enterprise service.
Free versions are generous enough for daily use as well. For example for TablePlus "The free trial is limited to 2 opened tabs, 2 opened windows, 2 advanced filters (filters are not available on the free TablePlus Windows) at a time."
Recently I've been trying jujutsu[0]. As awesome as Magit is, it can't fix some warts of Git like how it does conflict management. But I hate having to do version control from CLI. Most of all, I miss doing a bunch of work, going to magit-status (or edamagit), staging lines or entire files and committing parts of my work separately (like, dependency updates in a separate commit before committing api changes).
I've tried VisualJJ[1] and GG[2] but I just can't find a nice workflow with jj coming from Magit. Splitting changes feel cumbersome. What is your commit workflow with jj coming from Magit?
These folks really seem to get it. I’ll be keeping a close eye on this one.
And don't get discouraged by the attacks on your web design, I think the website is excellent the way it is. Leave it to some reviewers to go into nitty gritty real world stuff; your website does a great job of showcasing the design language and what's great about the product.
Dutch supermarkets offer an impressive variety of products, and there’s no shortage of specialty or “ethnic” shops where you can find virtually any ingredient for any type of cooking. Major cities are brimming with restaurants serving world cuisines, and people with diverse dietary restrictions are well catered to, with a plethora of options available. Plus, Indonesian and Surinamese food can be considered "local" by this point (if you ignore the historical complexity of the topic) and are simply delicious.
While it’s true that the availability of cheap street food might not be as prominent, to say the food here is “bland” couldn’t be further from the truth.
In software we see a lot of these “re-imaginings” come and go, see Arc browser, new cloud databases and myriad other things rolling the dice and hoping that they can disrupt and monetize later.
I think this is rarer in hardware because
a. It is harder, requires more planning, inventory management, higher standards and budget
b. Higher barrier to entry means not a lot of small players taking risks. I suppose it takes a technological shift like AI or spatial computing to re-imagine hardware interaction as well.
The saddest part is, when software companies come and go all that is wasted is some VC money and Twitter rants. With hardware, we’re making more junk to fill up oceans and waste precious resources…
For too long, npm has diverged from its original purpose as a collaborative package manager for a programming language, transforming instead into a battleground for popularity contests. The result is a landscape littered with neglected packages. Developers frequently bypass the opportunity to contribute to existing projects in favor of launching their clones, driven by the allure of glory and name recognition. While I fully support developers receiving the recognition they deserve, this approach undermines the integrity of the package ecosystem. The ideal state, where packages thrive rather than peak and fade within a mere six months, seems increasingly unattainable. All the name squatting and harmful packages are worth a whole another discussion.
I find myself nostalgic for the days of package managers that championed collective effort, building an ecosystem of functional components. Packages were often named for their functionality, leading to a landscape where one canonical package existed for each task. This approach, favoring practicality over catchy branding and endless turnover, is vastly preferable to the current state of affairs