Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
skydhash
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
211.
▲
by
skydhash
2mo ago
I used alpine linux and it looks pretty easy to setup your own repository, including build scripts for packages. I now use OpenBSD and the port systems of the BSD (each are different BTW) make it also easy to add extra software.
212.
▲
by
skydhash
2mo ago
> Just like cheap plastics and improved processes has enabled us to rapidly manufacture anything we want for a very low price Have they? Most of the world production is tied down to expensive factories and machines. Yes, we have more pro
213.
▲
by
skydhash
2mo ago
I’m using OpenBSD as a daily desktop. The main motivation is that it’s a complete system instead of several projects. So you got simpler userland tools as the kernel interfaces can be easily adjusted. Also the subsystems are way simpler (pa
214.
▲
by
skydhash
2mo ago
> Even on teams of experts, this type of issue would take someone really capable weeks to track down, especially because the repro environment is hard to obtain. > As a system becomes mature, the bugs become harder and harder individ
215.
▲
by
skydhash
2mo ago
> The other part is that almost no one would have the energy to spend hours instrumenting and rebuilding musl, reading the kernel mm code, and thinking hard about how they might interact. Maybe because it isn’t needed. That’s the reason
216.
▲
by
skydhash
2mo ago
That reminds me of one ticket I had to handle. It was generated by an agent from a customer report and the different hypotheses were wrong. Also a huge wall of text. The issue was alongside the API boundary (timezone shenanigans) but the ag
217.
▲
by
skydhash
2mo ago
Because any writing needs a core intent they need to convey, which you can summarize down to according to the audience and why it should be important to them. Kinda like the same idea of elevator pitches, “explain like I’m five” and tactica
218.
▲
by
skydhash
2mo ago
Not really. Spaghetti code is usually related to the big ball of mud. Meaning anything you need to understand, you need to go up and down the files while being distracted by irrelevant concerns. There’s no abstraction, no separation of conc
219.
▲
by
skydhash
2mo ago
> Because that's more about UX and product design than code quality. I think it's because in the business domain, people only attempt safe things. Not really. It’s mainly about the lack of frustration. People will learn the mos
220.
▲
by
skydhash
2mo ago
It’s not a mess as in spaghetti code, which you will find with novice programmers. It’s a mess as in complex and disjointed codebase. Happy path works somewhat, but it crumbles if you run it long enough or encounters an edge case. You need
221.
▲
by
skydhash
2mo ago
Then you would have guessed wrong. Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness. Like any data saved offline. Any update to that offline format mea
222.
▲
by
skydhash
2mo ago
Here is a nice report about tooling https://cacm.acm.org/research/lessons-from-building-static-a... This is the kind of report that you can reflect upon and learn from instead of feeling like you’ve just read a marketi
223.
▲
by
skydhash
2mo ago
> That is true, I was mostly speaking about a supposed need to review the code. Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and l
224.
▲
by
skydhash
2mo ago
Have you ever seen the end credits of a movie. It’s not made by one person either. Just like cathedrals aren’t built by one person. But someone has the vision and make it real. That which is real is a medium from one soul (or many) to you.
225.
▲
by
skydhash
2mo ago
It is documentation. This week, I looked at the Laravel API docs[0], just as much as I looked at the framework guide[1]. It all depends on the question you have and the answer you need. It's like the car manual (Do they still ship with
226.
▲
by
skydhash
2mo ago
Unless the app is released and running on user’s device, your “it works” is on the level of hackathon’s demo. Being on prod has always been the true testing ground of code. It seems like when people are talking about production level qualit
227.
▲
by
skydhash
2mo ago
> The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many Lol! What about fuzzers, linters, typecheckers and formal tooling? There’s plenty of machine code
228.
▲
by
skydhash
2mo ago
> Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others. After reading this article[0], it's become clear to me that what y
229.
▲
by
skydhash
2mo ago
The goal of software development is to eventually be done. Yes there are new incentives or new use cases that come up, but the aim should be towards a stable state where you're barely have to work on the software anymore. It's lik
230.
▲
by
skydhash
2mo ago
I'm strongly on the camp that one PR review shouldn't take more than 10 minutes (vibe number) to review, including reading a linked design spec or speaking with the author for more clarification. Even if I wanted to pull down the
231.
▲
by
skydhash
2mo ago
> it's not "this ought to work", it's "here are the figures showing how well this works, on this dataset" The thing with constraints is that you focus of the thing with high value first. So you focus on the
232.
▲
by
skydhash
2mo ago
Let's say that Z has an error (some assumption that does not hold), and needed to be reverted. How does that impact X's viability? I wouldn't trust any reviews of X after that. I strongly believe that PR should be compared to
233.
▲
by
skydhash
2mo ago
> You can't have mac/windows/linux/whatever all locally simultanously. Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So e
234.
▲
by
skydhash
2mo ago
After reading a fair amount of OSS code, it's rather glaring that the data structures and algorithms are more like atoms than molecules in software design. We do have some molecules in the Design patterns, but they are more suitable to
235.
▲
by
skydhash
2mo ago
> I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need. Can't you run your CI locally? I know it's not feasible for som
236.
▲
by
skydhash
2mo ago
IMO, in a team settings, improving the review policies and speed has a much better benefit. A PR is supposed to be a proposal for some change, adding more proposals on top of something that is not reviewed is a bit icky. > . By focusing
237.
▲
by
skydhash
2mo ago
It’s not really about speed (at least for me). It’s about mental friction. Because you’re fluent in your tooling, you don’t spend time thinking about them.
238.
▲
by
skydhash
2mo ago
I would and I’m someone who like C and Common Lisp. The Java ecosystem is full of good solutions, especially for building a web platform. I rather use something reliable than something lean or cool.
239.
▲
by
skydhash
2mo ago
> Unfortunately, it was fragile, and while it was theoretically infinitely flexible, practically, it was too big of a PITA to change to be flexible on the run. I don’t know. I switch back from neovim to vim for some reason, but that vim
240.
▲
by
skydhash
2mo ago
I truly believe a lot of people don’t really realize how good it is when you have a good environment for development work. It’s straight thinking to doing. And it’s not even about vim/tmux or emacs. You can do so with sublime or IDEA.
More ›