Comments are lies that will happen sometime in the future
Comments are always overlooked if gode gets refactored. Language servers can’t/won’t parse them and they’re easy to overlook.
If you name your functions/variables clearly, put complex logic into clearly named functions and keep the same level of abstraction in every function (which never exceeds roughly 50 lines), you hardly need any comments, if any.
Comments are for behavior that’s not possible to convey clearly through code.
If a block of code needs a comment, then you can easily move that block into a function and summarise the comment into a name for that function. If you can not easily move a block of code into a function, then you may need to rethink your design.
This isn’t always true of course, but it’s a good mindset to have.
If I had the willpower or time to go through a multi-thousand line (not including the html templates) legacy Angular 6 codebase where almost every property is typed ‘any’ then I assure you I would have, it’s driving me insane 🙃, also why I prefer backend
I kinda feel your pain. A project that I helped launch is written in Typescript technically, but the actual on-the-ground developers were averse to using type safety, so any is used everywhere. So, it becomes worst of both worlds, and the code is a mess (I don’t have authority in the project anymore, and wouldn’t touch it even if I could).
I’m also annoyed at some level because some of the devs are pretty junior, and I fear they are going to go forward thinking Typescript or type safety in general is bad, which hurts my type-safety-loving-soul
In theory I’m a fan of the inferred but static typing systems that most modern languages use (kotlin, rust, TS, etc.) where most local variable types can be inferred and only return types/object fields/parameters need explicit types.
I just despise typescript because it feels more like someone put a bandaid over JavaScript and all of its oddities instead of making a properly fleshed out language, and allowing the option for an ‘any’ type to be used freely by default emphasizes that.
Based on your description it sounds like you haven’t given it a fair shake. I’ll take TS over JS any day, at least there is room for improvement. I will say however I personally haven’t been unlucky enough to run into projects that abuse the any type. The worst I’ve run into is a JS library with no typings I have to manually type.
I imagine what they mean is e.g. that TypeScript can tell you something is a Date, but it doesn’t attempt to fix some of the confusing, quirky behaviour with that: developer.mozilla.org/en-US/docs/Web/…/Date#inter…
So, yes, it’s generally better than JS, but it doesn’t actually make it good/attractive, if you’re used to the sanity of backend languages. It very much feels like lipstick on a pig.
Exactly this. I’d rather use TypeScript than regular JS, but I enjoy using almost any other statically-typed language more (except maybe C++) because TS has the potential to be just as bad as JS for codebases where it isn’t being used correctly (this is true for other languages as well but it’s usually a lot more obvious).
Not that it isn’t possible to have good typescript code, but rather that code becomes a lot harder to maintain because of problems that could’ve been prevented at a language level (truthy/falsey logic, ‘any’ type being allowed by default rather than ‘unknown,’ etc)
The boy scout technique: fix your types when you're working on a bug or a feature, one file at a time. Also try to use unknown instead of any for more sensitive parts, it will force you to typecheck.
The fuck the lemons technique: resign and seek an employer that didn’t fail at the most basic level of engineering management and development culture for years and years — because life is short and we’re all running out of time… always.
When life hands you lemons, just say fuck the lemons and bail
I had a friend at university who got a job fixing cobol stuff before Y2K. The bank paid him extremely well, housed him in a luxury apartment during the job, and, as he had no driving licence, dropped in a car with free driver for him.
<span style="font-style:italic;color:#969896;">// Greetings, intrepid explorer, to the magnum opus of verbosity – the exhaustive elucidation
</span><span style="font-style:italic;color:#969896;">// of the venerable "Hello, World!" program in the illustrious realm of C++.
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">// Our inaugural act involves the summoning of external powers through the sacred rite of inclusion.
</span><span style="font-style:italic;color:#969896;">// The venerable library is invoked, opening the gateway to input and output sorcery.
</span><span style="font-weight:bold;color:#a71d5d;">#include </span><span style="color:#183691;"><iostream>
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">// Brace yourself, noble adventurer, for the initiation of our journey transpires within the sanctum
</span><span style="font-style:italic;color:#969896;">// of the 'main' function – the veritable heart and soul of our C++ odyssey.
</span><span style="font-weight:bold;color:#a71d5d;">int </span><span style="font-weight:bold;color:#795da3;">main</span><span style="color:#323232;">() {
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// Let us forge a pact with the realm of 'std', alleviating the syntactic tribulations
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// through the divine power of the 'using' declaration. Behold the namespace, a sanctuary
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// where the gods of C++ convene, rendering our code free from the shackles of verbosity.
</span><span style="color:#323232;"> </span><span style="font-weight:bold;color:#a71d5d;">using</span><span style="color:#323232;"> namespace std;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// As we stand on the precipice of expression, the 'cout' oracle emerges.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// This venerable entity, an emissary of the standard output stream, awaits our command.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// With the '<<' conjuration, we channel the essence of our proclamation, "Hello, World!",
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// and cast it into the void of the console, where it shall resonate for eternity.
</span><span style="color:#323232;"> cout </span><span style="font-weight:bold;color:#a71d5d;"><< </span><span style="color:#183691;">"Hello, World!" </span><span style="font-weight:bold;color:#a71d5d;"><<</span><span style="color:#323232;"> endl;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// The denouement approaches, where our protagonist, the 'main' function,
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// bestows upon the cosmic arbiter – the operating system – a token of acknowledgment.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// The triumphant 'return 0' is a symphony of numerical reverence, echoing
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// the harmony of a flawless performance in the grand opera of computational artistry.
</span><span style="color:#323232;"> </span><span style="font-weight:bold;color:#a71d5d;">return </span><span style="color:#0086b3;">0</span><span style="color:#323232;">;
</span><span style="color:#323232;">}
</span>
I have a love/hate relationship with docker. On one side it’s convenient to have a single line start for your services. On the other side as a self-hoster it made some developers rely only on docker meaning that deploying the stack from source is just an undocumented mess.
Also following the log4j vulnerability I tend to prioritize building from source as some docker package were updated far later than the source code was.
I love Docker because it is the only sane method to selfhost shit with my Synology NAS, and I love my Synology NAS because it is the only Linux interaction that I have (from my old MacBook Pro).
The Dockerfile is essentially the instructions for deploying from scratch. Sure, they most likely only exist for one distro but adapting isn’t a huge chore.
You can also clone the repo and build the container yourself. If you want to update say, log4j, and then attempt to build it, that’s still entirely possible and easier than from scratch considering the build environment is consistent.
If I’m updating the source code already I might as well build my service from it, I really don’t see how building a docker container afterward makes it easier considering the update can also break compatibility with the docker environment.
Also adapting can be a pita when the package is built around a really specific environment. Like if I see that the dockerfile installs a MySQL database can I instead connect it to my PostgreSQL database or is it completely not compatible? That’s not really something the dockerfile would tell me.
I really don’t see how building a docker container afterward makes it easier
What it’s supposed to make easier is both sandboxing and reuse / deployment. For example, Docker + Traefik makes some tasks so incredibly easy and secure compared to running them on bare metal. Or if you need to spin up multiple instances, they can be created and destroyed in seconds. Without the container, this just isn’t feasible.
The dockerfile uses MySQL because it works. If you want to know if the core service works with PostgreSQL, that’s not really on the guy who wrote the dockerfile, that’s on the application maintainer. Read the docs, do some testing, create your own container using its own PostgreSQL or connecting to an external database if that suits your needs better.
Once again the flexibility of bind mounts means you could often drop that external database right on top of the one in the container. That’s the real beauty of Docker IMO, being able to slot the containers into your system seamlessly due to the mount system.
adapting can be a pita when the package is built around a really specific environment
That’s the great thing about Docker, it lets you bring that really specific environment anywhere and in an incredibly lightweight manner compared to the old days of heavyweight VMs. I’ve even got Docker containers running on a Raspberry Pi B+ that otherwise is so old that it would be nearly impossible to install the libraries required to run modern software.
Also I created this repo to create a reproducible sec environment for myself. I added other languages, but personally work mostly with python. It is basically resonating for handling all the boiler plate:
For packaging in docker I started to use nix2container project as it gives me a greater control over layers. So for example when I package my phyton app I typically use 3 layers:
python and it’s dependencies
my application dependencies
my application, which is very tiny compared to other two, so there is great reuse of the layers
The algorithm mentioned in the video also helps a lot with reuse, but the above is more optimized by frequency of how things typically change.
BTW: today I discovered this github.com/astro/microvm.nix I haven’t play with it yet, but in theory it would let me generate a microvm image (in similar fashion to generate a docker container) which would let me to run my app natively as a tiny VM on EC2 for example, and use only minimum necessary of a typical OS to run it.
Every time I hear this from one of my devs under me I get a little more angry. Such a meaningless statement, what are you gonna do, hand your pc to the fucking customer?
It's not actually meaningless. It means "I did test this and it did work under certain conditions." So maybe if you can determine what conditions are different on the customer's machine that'll give you a clue as to what happened.
The most obscure bug that I ever created ended up being something that would work just fine on any machine that had at any point had Visual Studio 2013 installed on it, even if it had since had it uninstalled (it left behind the library that my code change had introduced a hidden dependency on). It would only fail on a machine that had never had Visual Studio 2013 installed. This was quite a few years back so the computers we had throughout the company mostly had had 2013 installed at some point, only brand new ones that hadn't been used for much would crash when it happened to touch my code. That was a fun one to figure out and the list of "works on this machine" vs. "doesn't work on that machine" was useful.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.