Smartphones are just a helpful tool, yet in conjunction with social media they can be attributed to decline of social relations and attention in children, raising levels of depression, etc.
Email are inundated with spams, but it's still a helpful tool. We don't stop using email because of spam. Good things happen because of email communication everyday.
Do these extroverts have a job that requires any level of focus?
I'm also pretty much an extrovert but if I need to get any work done, being in the office is actually counterproductive for me and for people who I interact with.
> Do these extroverts have a job that requires any level of focus? I'm also pretty much an extrovert but if I need to get any work done, being in the office is actually counterproductive for me and for people who I interact with.
Yeah, me too. It's much harder for me to focus at the office, which is annoying as mentally it's great for me to get out of the house and see people who aren't my family (who are great, I just do better when i see and interact with more people).
The not so secret secret is that office jobs are 50% work and 50% politics. And that's in a good company. In a dysfunctional company, it's more like 80% politics.
They have work to do, but then buckling down and focuses is probably worse than what they're doing. Unfortunately.
It has to do because those assholes will no longer tell me that I should have written an abstract factory or some shit. AI generated code is so fucking clean and SOLID.
And it’s not a joke, PHP is actually the most secure runtime environment out there for web hosting, PRECISELY because of the shared-nothing architecture.
Faster runtimes exist, like Swoole and recently FrankenPHP, to do evented programming like Node JS. But let me tell ya — you risk all kinds of leaks, both of unfreed memory and of secrets, across requests. It ain’t worth it most of the time!
I will keep writing my CLI programs in the languages I want, thanks. Have it crossed your mind that these programs might be for yourself or for internal consumption? When you know runtime will be installed anyway?
You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use.
My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling.
Internal to work? Yeah, Java's going to be an easy sell.
I don't think OP necessarily meant it as a political statement.
There should be some way to define the CLI argument format and its constraints in some sort of DSL that can be compiled into the target language before the final compilation of the application. This way, it can be language agnostic (though I don't know why you would need this) without the need for another runtime. The same interface specification should be able to represent a customizable help/usage message with sane defaults, generate dynamic tab completions code for multiple shells, generate code for good quality customizable error messages in case of CLI argument errors and generate a neatly formatted man page with provisions for additional content, etc.
In fact, I think something like this already exists. I just can't recollect the project.
most java CLIs (well, non shitty ones), and most distributed java programs in general, package their own jvms in a hermetic environment. it’s just saner.
In decreasing order of importance: culture, a good standard library, and tooling that pushes you to be deliberate about your dependencies rather than dumping 300 stupid packages inside every project.
Maven is incredibly well designed (and ironically gets nothing but hate for it), it's probably the hidden reason Java is so successful.
Why does Maven exist, without the commercial compromises of NPM? Probably because Java has the well-funded, well-supported, but non-profit and community-oriented Apache foundation, which is something extremely rare and precious (and probably at least partly a lucky result of Java's complicated legal history).
(JS has plenty of great utility libraries. The problem is that its package management is excessively centralised and not managed terribly well)
The operators of Maven Central deserve a lot of credit for their good stewardship. Unlike the NPM registry, Maven Central does not permit anyone to unpublish packages. Unlike the NPM registry, Maven Central requires verification of domain or forge account ownership to claim a namespace. These are good practices, and anyone seeking to create a central package registry would do well to at least consider this. Maven Central is currently operated by SonaType, but it has changed hands a few times. This article covers its history: https://www.sonatype.com/blog/the-history-of-maven-central-a...
Additionally, it is standard practice in the Java world, which is more "corporate" or "enterprise-y", for better and for worse, to have organisations operate their own internal package registries / mirrors. Even if you unpublished a major package from Maven Central, many organisations would be completely unaffected because they retain archived copies of all of their dependencies.
All that is true, but I think the fact that Maven has supported multiple repos and proxy repos for decades is a significant factor. SonaType deserve credit for being good stewards, but it's also relevant that they have had real competition (e.g. jFrog ran a similar public repository until recently) and if they did ever behave badly then for many organisations it would be a 1-line change in their Maven config to switch, which creates rather different dynamics compared to NP, PyPi etc..
Arguably the root problem was lack of user namespacing; the incident would have been less likely to happen in the first place if the packages in question were named "~akoculu/left-pad" and "~akoculu/kik".
I don't get the part about the small commits. To me a commit could be massive and that's alright, provided it introduces some major feature, while a fix could a one-liner. It really depends on the situation.
This means that you should look to break up a "major feature" into smaller, iterative steps to delivery.
In general, the biggest hurdle engineers need to overcome is to believe it is possible and then simply start thinking in terms of delivering value with every single branch (hopefully user value, but a refactoring counts too), and what are the small steps that get us there?
The benefits are amazing:
* Changes are likely to be limited to only one "thing", thus making them both lower-risk and easier to review and QA
* With every step shipped to production, you learn if it is providing the benefit you are looking for or if you need to pivot
* You are not developing a feature branch while "main" moves at the same time, and wasting time on keeping up with it
* If the project gets stopped 3 months in, you have still delivered some value, including those in-between refactorings
* Your customers love you since they are seeing improvements regularly
* There is never any high-risk, big "release" where you need to sit around as 24/7 support and wait for bugs to rear their heads
I am happy to give some guidance myself: what is the "major feature" you think can only be done with a single, large change all at once? (I've done huge DB model changes affecting 100Ms of rows with no downtime, merged two "subapps" into one, migrated monoliths to microservices etc, but also built new full-stack complex features with branches with diff size being less than 400 lines for each)
Large commits are (IMO) a symptom - lack of a plan, a plan that doesn’t work out, etc. Which is fine! You have to figure it all out somewhere.
One thing you can do to address them is to stash the large commit to the side, then piece by piece pull it into a new branch as a series of smaller commits. This also give a good opportunity to refactor before delivery, now that you know what the code is going to do and how.
It makes debugging so much easier to have small, atomic commits. Of course what's viable depends on what you are doing. I've had great success making changes and rolling them out that aren't actually the full feature yet and some or all parts remain hidden. This also can alleviate the race between two large changes coming in and having to deal with merge conflicts.
Having a massive major feature done as a single commit is evil. Merging two branches may conclude combining a unit of work, a major feature, a minor feature with the main branch (of course once the topic branch is merged to the upstream, and never vice versa [rebase in git terminology]). This is logically "a big commit" constructed from a concrete amount of small commits. Additionally, having small atomic commits also makes reverting a commit a trivial operation regardless the branch the commit was introduced in. Bisecting a range of small commits also makes finding a bad commit easier.
Author here. I don't factor in lunch (so take away 30-60 min). Also, the 19:30 stop is there as a hard stop. Sometimes I feel drained at 17:30 or 18:00 after a very productive day. In that case, I'm happy to wrap up the day.
That was also my first thought, I feel 10 hours (or even 9 hours) is extremely long. Being laser focused for 9 hours is extremely hard to do on the long run. As others said, you need to find your own schedule but don't aim for 10 hours first thing, go slow
