vemv

28 ms·

271.
by vemv 7y ago
I would indicate that engineers' feelings ("hating" something) are quite orthogonal to business needs or technical challenges. Probably every technical decision maker pushing for microservices knows the perils of distributed
272.
by vemv 7y ago
Fair point, but also incomplete. Can you debug a forest by inspecting a single tree?
273.
by vemv 7y ago
Generally, we are rewarded with income and prestige when we did something valuable for society - so pursuing success isn't inherently shallow either.
274.
by vemv 7y ago
Not applying intelligence on real-world aspects that will make you successful is very much non-intelligent. Likewise, not being able to effectively communicate with a variety of people shows a lack of analysis, learning, etc. IOW, people fe
275.
by vemv 7y ago
Can't see the problem in principle - all kinds of storage (DBs, S3, Redis) seem mockable.
276.
by vemv 7y ago
One specific thing I think FP distributed-system frameworks could bring is instantaneous, deterministic testing. e.g. I have N microservices, they communicate via IO (which means slow/brittle tests) but the framework abstracts over tha
277.
by vemv 7y ago
Point taken. At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective. So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100%
278.
by vemv 7y ago
Great insight. I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind. Definitionally, no methodology makes the unavoidable avoidable? Now, let's say you get to tha
279.
by vemv 7y ago
That seems entirely subjective. People may go fast for meeting a deadline, or for iterating as you suggest. Trying to determine what people do is likely a futile discussion. Finally, by writing decoupled, modular software, you are always fr
280.
by vemv 7y ago
Would you rather have a bug-free fighter delivered in 2021 or a buggy fighter in 2020? Especially considering that many codebases are expected to have a shelf life of 5-10 years. IME working deadline-lessly doesn't mean you're sud
281.
by vemv 7y ago
Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. (I'm open to be convinced) Generally I have witnessed tech debt as something pretty blatant
282.
by vemv 7y ago
Scrum has been a catastrophe to the software industry (argued elsewhere countless times) - I don't want to imagine the consequences it can have for jet figthers. For such environments you definitely want to have no deadlines at all, to
283.
by vemv 7y ago
> Well, if you don’t believe that it’s better for a user, at least believe it’s more efficient for us, because we only have to release one application instead of two. Efficiency is in our values. Wow, this is some terrible reasoning. Eff
284.
by vemv 7y ago
Generally I'm of the opinion that git hooks are not the right place to place linters or formatters. For a JVM language, it means that you'll spin up a JVM for each step (and you can well have 15 formatters + linters in your stack)
285.
by vemv 7y ago
> So, you want to build a CubeSat? Not particularly, and even less so with this clichéd, condescending headline. It's a meme that needs to die, why do we have to see these titles popping up in HN every month?
286.
by vemv 7y ago
> the tendency by elisp programmers to inline huge gobs of code in function calls Observation on point, and ironically it limits the ability for developers to tweak third-party software (what if you want to change some aspect _in the mid
287.
by vemv 7y ago
Rarely the actual case (which can be demonstrated from the fact that "the web" is mostly web pages, not webapps). Bloat tends to originate from using way too many widgets/analytics coming from third-party domains.
288.
by vemv 7y ago
Why hand-holding developers into making specific library choices? "You might not need jQuery" was reasonably useful, but that should have been it. No need to turn everything into a meme.
289.
by vemv 7y ago
<subjective thing> is better than <subjective thing>. Oh thanks, that was so useful.
290.
by vemv 7y ago
'Its' content? Don't the lyrics belong to their actual authors?
291.
by vemv 7y ago
'Fortunately' the only reason that lead to this change was that it was a rival political party who created the zone in the first place. Similarly to how Trump would intend to demolish Obamacare. So there are no big lessons for the
292.
by vemv 7y ago
An useful intermediate step, but ultimately, a wrong move. Packages will keep having the essential problem that there's no guarantee whatsoever that the package was derived from the advertised source. Plenty of chance for delivering ma
293.
Bitcoin ransomware attack on GitHub organisations(bitcoinabuse.com)
7 points by vemv 7y ago|0 comments
294.
by vemv 7y ago
Interesting point about Erlang! Where can I find more info on that specific aspect?
295.
by vemv 7y ago
Github star count looks fake for a project so recent.
296.
by vemv 8y ago
Learning from the clojure.spec success story, what might make/break Sorbet is its runtime capabilities, aka reification. * Can I emit typed REST API docs out of sorbet types? * Can I coerce HTTP params out of sorbet types? * Can I emit
297.
by vemv 8y ago
Partnering with Ruby Core is a bit dubious for a project which is still closed source. Why the privacy? Are programmers too dumb to understand something is a beta? What if in the end adoption is marginal and Ruby Core's time was wasted
298.
by vemv 8y ago
Yes, clojure.spec enjoys a great momentum and acceptance in the community. It's being used for a great deal of use cases from safety to generative testing to HTTP params coercion.
299.
by vemv 8y ago
When you "git all the things", upgrading a dependency can equal a `git diff`. Upgrades become reviewable. I envision a future where organisations routinely review upgrades.
300.
by vemv 8y ago
A few more of these and we'll all ditch package managers in favor of plain git repos. Commit SHAs inherently guarantee content integrity.

More ›