HenriTEL

Your DB runs more heterogeneous workloads and migrations so it's more likely to blow up.

Thank you Andrew for sharing your side of the story. We can see that the relationship with Bun and Jarred was far from easy. You say it with your own words and even if it sounds bitter I like it much more than some bland AI assisted content.

looks bad on desktop too, most content being uncentered (spread at the edges of the screen).

Without a way to estimate "AI power" used for the task I don't see how you can fairly rate home assignments.

Not an expert but I'm pretty sure that constitution > statutes and ordinances > rules and regulations. Meaning that USCIS must follow the intent of the law when publishing regulations. In the case of H1B the law is clear that it gives a specific status of temporary worker distinct to the immigrant status. USCIS itself acknowledges it:

https://www.uscis.gov/newsroom/news-releases/us-citizenship-...

Our system is designed for them to leave when their visit is over. Their visit should not function as the first step in the Green Card process.

So they had a security-critical header whose fields are set by their internal authentication service. And that same field can also contain arbitrary strings passed by the end user with git push -o

I know it's easy to say after the fact but still, wtf

  Location: Paris, France
  Remote: Yes
  Willing to relocate: No
  Technologies: Python, AWS, Rust, kubernetes, terraform, linux
  Résumé/CV: https://www.linkedin.com/in/henrihannetel/
  Email: henri.hannetel+hn@pm.me

Ah yes, MinIO, that open source S3 alternative that got archived last week. To me that's the biggest problem when self-hosting services. On day to day operations, some times it just breaks and the time to get it back varies from a couple of hours to a couple of days. And for the longer term you regularly have to upgrade things yourself which takes time and energy and is stressing for stateful deployment. And then you have it, at some point maintainers are just exhausted and the project is gone.

I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy. Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.

Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.

Yeah that's an ad for Azure Cosmos DB

https://blog.henritel.com/

The goal of the article is not to know the exact numbers by heart, duh!

Care about orders of magnitude instead, in combination with the speed of hardware https://gist.github.com/jboner/2841832 you'll have a good understanding of how much overhead is due to the language and the constructs to favor for speed improvements.

Just reading the code should give you a sense of its speed and where it will spend most time. Combined with general timing metrics you can also have a sense of the overhead of 3rd party libraries (pydantic I'm looking at you).

So yeah, I find that list quite useful during the code design, likely reduce time profiling slow code in prod.

Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

Increasing swap is more like adding more HDD. It won't help memory pressure issues.

Ah yes, a new css concept! I love this kind of article that invariably contains this kind of statement:

This is mind-bending stuff, but it becomes intuitive with a bit of practice.

The problem is not the language, it's just that you did not spend enough time to learn it the proper way.

Well you nailed it, the language you're looking for is SQL. There's a reason why duckdb got such traction over the last years. I think data scientists overlook SQL and Excel like tooling.

Login fall under the strictly necessary category and does not require consent for cookie storage under GDPR.

About the cookie banners, I'm honestly not sure it's a regulation issue. For >90% of the websites the "reject all" option have no impact on user experience, so either everybody is breaching or the banner is useless in the first place.

With that it becomes clear that some service is self hosted (the DNS record points to a private IP). It can be a security issue when the Whois record or the domain name allows the identification of the hosting entity. Finding its physical address can be an easy task depending on its social presence.

Then probably the hosting place is an easier target than a data center.

To be fair nowadays .com refer much more to the default, main or official domain of an entity. Say you know the name of a non corporate website, are going to try .com first of something else?

Diffusely | Backend Software Engineer - Python | Full-Time | Hybrid (Paris, FRANCE)

Diffusely is an AI media enhancement company that leverages its cutting-edge media processing platform to develop tailored products for specific verticals: Carcutter for the automotive industry, Autoretouch for the fashion one and Propershot in real estate.

As a Backend Engineer at CarCutter, you will be joining the global #1 visual AI editing and optimization solution for the automotive industry, used by customers from all around the world. Due to our steady growth, we are now expanding our passionate & motivated CarCutter team.

https://diffuselycompte-1738823875.teamtailor.com/jobs/55872...

Contacts: henri[dot]hannetel[at]diffuse[dot]ly

You're comparing apples and oranges. Good taste in fashion is much more subjective than in software engineering, obviously because one stays a subjective discipline while the other always ends up in formal science.

What's interesting is that software engineering starts in social science where most choices are made subconsciously or at least not discussed with other people.

The design might be great on your app, but I just had a look at the features page https://lighthouseapp.io/features and it looksquite messy. Too many of colors and information in the feature tiles, colors of icons in the section headers are off, alignment is odd. As a newcomer, understanding the features on this page takes a lot of efforts.

Among all macOS apps and their weird choices, finder is the most enigmatic one. The Recents tab sorts by Last Opened by default where I would expect to see the rencently added files first. Sorting by another column will not add said column to the view. Files from the Downloads folders seems to be excluded from Recents, or they take hours to be taken into account.

It does not show the current path, no button to go up the file tree, the only text input is behind this search button and it does not understand relative or full paths.

Well, thank god I have a terminal and an IDE at hand.

During Jobs era obviously design was a first order concern.

Then Cook took over but still Jonathan Ive stayed as head of design until 2019.

Ive was replaced by Evans Hankey and Alan Dye who were under Jeff Williams, the Chief Operating Officer.

Talk about a downgrade!

Apple already had serious contrast issues that have been adding up over the last few years, notably yellow text on white background or grey text on dark grey background. This liquid glass design will make the issue ubiquitous.

I'm working with python and it does not work very well, LLMs usually generates at least an order of magnitude more code than what I would write. That code often uses outdated practices, does poor design choices and does not understand hints like writing code in a way that reduce cognitive load, even when we explain that it means, i.e. keep the number of classes and functions small.

It's the complete opposite of OP's main language GO, as he says:

Go has just enough type safety, an extensive standard library, and a culture that prizes (often repetitive) idiom. LLMs kick ass generating it.

Python is an interpreted dynamically typed language and the static type checkers are not there yet (most popular 3rd parties libraries have no type hints for example). Also it allows for many different programming styles that the LLMs struggle to choose from.

1. Every extra line of code is much more risky. 2. It's much harder to verify the LLM's code.

On the other hand I think rust will be in a good place in regards to LLMs in the next few years thanks to the robustness of the language and the quality of its diagnostic messages. Those 2 attributes should compound very well.

Yes, in the end, no matter how polished your apps are, a NAS is a tech product sold to tech people. Tech people want to choose their hard drive.

Web archive: https://web.archive.org/web/20250411060742/https://www.nytim...