luord

I've thought for a while that sysadmin, operator, "devops engineer" and sre were all more or less the same job, but always felt like saying it would be silly of me.

In the future, I'll just link to this piece.

Well, how sad. I have liked what Jakob wrote quite a bit but not only does this article betray a lack of self awareness as it describes quite a few of his own posts—not that there's anything wrong with that as he has published truly insightful things too and the fluff I still liked for the positivity—but then he used an essay by PG as an example of this.

And now I'm not one of those people who think that everything PG writes is gold, but it's hardly "insight porn". In fact, if that particular essay is "advice", it's the advice to not even try as it's likely just not for you, so it almost seems like Greenfeld misrepresented it just because of a single sentence.

Well, that's good news to me because I have no interest in doing any of that, with two caveats:

- On type checking, I like type hints and gradual typing, but am not big on strict static typing.

- I'd like to do A/B testing, but only for fun and for learning/applying data analysis.

https://luord.com

I post articles on what (I think) I know. Just a static blog generated by Pelican.

Merry Christmas everyone!

Feliz Navidad a todos!

I have been a developer for eight years and yet I still get shocked about the places where Python will be used. I mean, it is my favorite language, but in the communities I gravitate towards (basically communities like HN) it has so many detractors for being dynamically typed, not being functional enough, being slow, etc, that sometimes I'm tempted to think maybe it's actually a guilty pleasure of mine, and that I should look for better pastures.

Then I read articles like this and I remember why I like it: it gets the job done, and quickly (for the developers at least). It's why it's so widely used and keeps climbing. Of course, nothing wrong with learning other languages and I do try to keep up, but Python will remain my go-to for the time being.

Duly noted: get used to `command -v`

Better to follow standards anyway.

While I believe there's value in the mentality that "you don't know what you're building until you're building it", I also agree with a lot of this, as long as it means more asynchronous communication anyhow. The write-up itself was a bit focused on if it all happened in meetings, but a lot of this could also be accomplished over email or collaborative editing, RFCs, etc.

But back to the idea of many applications being emergent and/or not at all (or not entirely) what their creators intended. Maybe there's room for both approaches depending on the situation.

I wish I were this creative; I've mostly bought domains that are variations of my name/last name, and the only one I haven't let die is my usual username luord.com

I've seen the problems of treating containers as houses, primarily during development: Multiple different processes inside a single container, with a wrapper around them (inside the container) that makes it even more difficult to debug.

So, assuming I understood correctly, treating them like tents is infinitely the better choice.

I removed all recruiters and similar, leaving only people I know and (mostly) other engineers... And even then I basically only check the notifications anyhow.

So I consider myself fortunate; by not taking LinkedIn that seriously, I've avoided a lot of... awkwardness, to put it nicely.

In that case then the service will just hang as it won't handle the requests caused by even a simple malfunction (not even an actual attack) like the one mentioned by GP.

Mind you, I see your point and I generally don't like the captchas either, but it is definitely a trade-off and I won't blame webmasters that use the DDoS protection.

I agree but with one caveat: If the difficult to integrate tool/library is open source, then one probably shouldn't ask likely already overworked maintainers for even more work. In those cases, one should probably be the change one wants to see by contributing the features, refactoring or documentation needed to ease integration.

If possible anyhow.

The way I see it is that Linus already left his mark in history twice over (so far). I don't know how he feels about it[1], but if I were given the choice between being a billionaire and being remembered for a great thing I did, I'd certainly pick the second.

And sure, many people have achieved both, but they didn't take their money with them once they were gone. As long as you have enough to live comfortably, everything else is at most an incidental bonus IMO.

[1]: Though I haven't heard anything suggesting he's anything but pretty okay with his lot in life.

This presents a strong case, IMO. And taking in account that studies have been made suggesting that language choice has little to no correlation with number of bugs[1], it would make sense that recency bias plays a part in, well, preference in technologies.

I'm interested in the outliers though: Both the ones among the loved brownfield languages, and the ones present in both loved and dreaded lists. I feel like programming language designers, people in charge of choosing the stack for new projects, and people considering renovating legacy codebases can learn a lot about what to do and what not to do from those.

[1]: Though that one ended up in a flame-war, like discussion on programming languages tend to do. Apparently not even academia is safe.

htmx by itself is so good—when paired with discipline in the backend in creating proper fragments anyway—that so far I haven't needed hyperscript. But then again, htmx is so good that any project by the author has my vote of confidence by default.

Still, I oughta try this to make a proper judgement.

Not that the article itself didn't already have some odd takes, to say the least, but I find it a bit ironic that they talk about design with seeming authority when that site has a very strange anti-feature where every few minutes eyeballs pop up on screen—sometimes over the text, making it more difficult to read—and you have to hover the pointer over them to make them go away. It was absolutely terrifying the first time, and quickly got annoying after that.

In hindsight, the eyeballs act like an unintentional warning not to bother reading. And that's despite my agreeing with the initial premise that these flat rebrandings are getting way too common.

Well, as an avid movie watcher who absolutely loves the theater experience, I truly do hope they never go away, and that my hypothetical children get to experience them too.

It turns out Kubernetes is actually perfect for small teams

As long as at least one of them is an expert on kubernetes. In this case, the one person in the team is that person, and as he points out in the article, he's using it because it's what he knows.

That should be the takeaway, I think. The "trope" remains pretty sensible IMO; I've seen it first-hand, jumping on kubernetes without the know-how is a foot-gun factory, and that team ultimately gave up on trying to implement it.

Probably, the best answer to the "programming is easy" mindset I've read is this article[1] about whether software engineering is actually engineering. Turns out we are engineers, and we're not even that special as far as engineering goes.

And it's funny, because the article has nothing to do with whether programming is hard or not. Not idea what Wayne thinks of the matter.

[1] https://www.hillelwayne.com/post/crossover-project/we-are-no...

I don't believe this until proven otherwise with actual data.

I don't remember the last time that a piece by Uncle Bob or Martin Fowler—and they're just two examples, I've seen quite a few more who are generally met with agreement every time they're posted—was heavily criticized or disagreed with here.

And when I do see disagreements, they tend to come from people who don't seem to have nearly as much experience as those guys do or who might have misinterpreted their point (much like how the idea of agile has turned into something that only reflects the manifesto tangentially, and accidentally at that) and who are, perhaps not coincidentally, likely to fall in the "programming is easy" camp.

And even then, "controversial in hacker news" is hardly representative of what's controversial in the field at large (which I also understand goes against my own first point).

I can't believe it (I'm kidding; I totally can). I like that some of them mention the excavator (<3).

Last weekend I decided to remove all third party services/javascript from my website, replacing them with external links (for the share button or the contact form), nothing (for google analytics[1]) or with web mentions (for disqus).

Not sure how viable it is since it was actually more work than I thought it'd be, but at least I feel better now about my site not loading external stuff and setting unnecessary cookies. Now I guess I should actually write more stuff to see if I get mentions (and to test how vulnerable to spam it is, I suppose). I haven't ruled out looking into other ways to implement federated comment systems—or similar, like web mentions—though[2].

[1]: That said, I'm using cloudflare so I guess I do get its analytics.

[2]: And there's always the self-hosted option.

Damn, I must say that it's rare that I do find something so compelling yet so radically different to how I usually work[1]. Which is not to say that I think I'm an expert; if anything, it's because I don't know how much I don't know.

I must try this.

[1]: Pretty much the usual gitflow with sequential commits of partial work on a branch—often with commits fixing previous errors in the branch—until I deem it finished.

I tried chemical engineering first because in my country's system we more or less have to pick what major we want to apply for since even before finishing high school, and I had to do this at thirteen. And then I got my very first computer as a high school graduation present.

Quickly found out that enjoying the high school chemistry classes the most didn't translate to chemistry processes being what I wanted to do for the rest of my life. On the other hand, I fell in love with tinkering with the computer's software (first in windows, and then even more after I installed Linux) right away.

I stuck it out with chemical engineering for a year and half, before finally dropping out and starting fresh with systems engineering (more or less my country's equivalent to computer science) during what would have been my fifth semester. Haven't looked back since and, much like the author says, I love solving those puzzles.

And here I was living under the assumption that psycopg2 was the only option, and probably the biggest reason I was not using pypy. Gotta take a look at pg8000.

In general, I've always liked the idea of pypy, so I'll try to use it more, and not just for performance. Will also donate when I can.

I'm particularly interested in the support for dataclasses. It's going to make modeling the application while decoupling from the data layer itself easier, I think.

The value of the ‘free work’ to the company is the same as the value it has to you

Absolutely none? I somehow doubt that, otherwise only the most incompetently run companies would still ask for that kind of commitment during the process and... Actually, you might have a point. I certainly have rarely liked work in companies that demanded free work from me during the hiring process. That might be one of the reasons why I haven't done an unpaid take home test in a long time.

But the idea that the company is getting you to do work for its value outside of the interview process just seems

So the company isn't getting the candidate to work for free because it isn't getting value... If we ignore the value it gets from the interview process itself.

Providing some company a service so that it can make a decision on how it operates sounds like work to me.

On another note, this doesn't take into account that pointless busywork is still work.

I have the good fortune of working remotely in a country much cheaper than the USA, so I can afford to be selective about what I'm willing to do during a hiring process. For starters, I haven't had to do an unpaid take home assessment in a while, so I would reject outright a request like the one in TFA, but I'm aware that many are not in my position.

This type of expectation of free work during the process needs to change. Maybe if enough people reject stuff like this, it will, but again, many can't afford not to jump through all the hoops the company decides to put in place. It's a tricky problem, to say the least.

> The respectful thing to do, IMO, is not to ask people to perform this type of free work

Could you share the link to where someone else presented that same point? In fact, I only commented because I found it odd that nobody had said it yet in this subthread.