Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Ah, the little subtle things we have to iron out as we progress from Junior Developer to Medior Developer.. things like:
- knowing the difference between a carriage return and a line feed (although having worked with analog typewriters helps) and later knowing that Unix-based systems and Windows NT-based systems implement it differently..
- knowing that serialization is important because not all computers interpret data the same way and some computers allocate 4 Bytes for a construct, others 16 Bytes.. and then we get the funkiness of transferring character sets between machines..
- knowing that a whitespace character is not only an actual space (as is known in ASCII as code 32). This one can cause even medior developers a headache, as in: why the fuck does this string function say that "hello I am a duck" and "hello I am a duck" are not the same?! Turns out then in the debugger that when you expand every character in the string you see that string1 contains 32 32 32 32 as usual.. but then string2 contains -96 -96 -96 -96 and you're like.. what the fuck..? Then you know you have to throw \\h regex at it. Haha.
- finalizing our objects and streams (although modern languages do that for us).. otherwise we have to do funky shit like trying to find what's locking a file, which is not so easy to figure out.
- figuring out why something won't work often requires you to not only break down the problem in smaller steps, to use a debugger, but sometimes it's even better to just create a proof of concept, slap some minimal code in there and debug that.. much easier.
- etc.
:)7 -
A friend of mine asked me yesterday for help for his bachelor thesis.
He wants to write about MySQL internals in regards to BLOB storage / usage.
We had a veeeerrrry long discussion....
And found a loooot of scary internet pages.
It's so .... Insane....
What some people with doctor titles or higher education generate...
Isn't content. More poo...
Most "blogs" / "articles" or whatever the author named it were missing all kinds of relevant data (version, configuration, anything relevant) but full of opinionated / biased bullshit.
Highlights were:
- we store lot of BLOB data, Backups take long and require more space
(you store additional data in an database, whaddya expect???!!!!)
- interesting guesswork about locking without any reference (interesting since it was sometimes so far away from reality that it looked more like quantum physics)
- storing blobs means that _each_ blob entry will be stored in a separate file (without any reference, but if an RDBMs did that... It would end in an amazing fireball I guess)
- BLOB's bad since it can represent only the file content, the database cannot distinguish wether it's an MP3 / MPG or anything like that...
(Ehm. Yeah. And an database cannot distinguish if you store under "Name" an Name or gibberish?!)
I somehow think that some people made an doctor and post this gibberish nonsense so people stay dumb to give them a job...
Like the TV repair men who steals the batteries from the remote.
Even conspiracy theories were more convincing -
I'm pretty sure I'm not the only one that will say gaming.
Because of gaming I've been in contact with computers a lot and learned a bunch of things that would become useful as the base for learning coding.
Things as simple as using and abusing the file system, file locking and files principles, Googling stuff, etc.4 -
Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.3 -
Why did Microsoft lock down TTF files?
https://support.microsoft.com/en-us...
None of their links work anymore.4 -
It seems like very version of Ubuntu I use at work has jank. Ubuntu 18.04 would have file managers that just die. After locking/unlocking the screen it would move windows between monitors. One window would seemingly cause other windows to have discoloration and I would see phantom objects text overlaid with what looks like transparency. This was all Gnome. Lots of little quirks that I just got used to.
Now I am running 22.04 and while a lot of jank went away I am getting new jank. Every once in a while if I move a window or bring a window up after hiding the window. The window will oversize across the screen like I zoomed in. Noticing this with Firefox. It goes back to normal size real quick. But it is kind of wild. Jank that stayed is my external monitor I have attached through hdmi takes its sweet time to reactivate after being asleep. This might actually be a weird hardware issue. This is also Gnome.
I just find it wild that this jank is there and we are like: "Oh well. At least it ain't MS Windows jank..."5 -
Aka... How NOT to design a build system.
I must say that the winning award in that category goes without any question to SBT.
SBT is like trying to use a claymore mine to put some nails in a wall. It most likely will work somehow, but the collateral damage is extensive.
If you ask what build tool would possibly do this... It was probably SBT. Rant applies in general, but my arch nemesis is definitely SBT.
Let's start with the simplest thing: The data format you use to store.
Well. Data format. So use sth that can represent data or settings. Do *not* use a programming language, as this can neither be parsed / modified without an foreign interface or using the programming language itself...
Which is painful as fuck for automatisation, scripting and thus CI/CD.
Most important regarding the data format - keep it simple and stupid, yet precise and clean. Do not try to e.g. implement complex types - pain without gain. Plain old objects / structs, arrays, primitive types, simple as that.
No (severely) nested types, no lazy evaluation, just keep it as simple as possible. Build tools are complex enough, no need to feed the nightmare.
Data formats *must* have btw a proper encoding, looking at you Mr. XML. It should be standardized, so no crazy mfucking shit eating dev gets the idea to use whatever encoding they like.
Workflows. You know, things like
- update dependency
- compile stuff
- test run
- ...
Keep. Them. Simple.
Especially regarding settings and multiprojects.
http://lihaoyi.com/post/...
If you want to know how to absolutely never ever do it.
Again - keep. it. simple.
Make stuff configurable, allow the CLI tool used for building to pass this configuration in / allow setting of env variables. As simple as that.
Allow project settings - e.g. like repositories - to be set globally vs project wide.
Not simple are those tools who have...
- more knobs than documentation
- more layers than a wedding cake
- inheritance / merging of settings :(
- CLI and ENV have different names.
- CLI and ENV use different quoting
...
Which brings me to the CLI.
If your build tool has no CLI, it sucks. It just sucks. No discussion. It sucks, hmkay?
If your build tool has a CLI, but...
- it uses undocumented exit codes
- requires absurd or non-quoting (e.g. cannot parse quoted string)
- has unconfigurable logging
- output doesn't allow parsing
- CLI cannot be used for automatisation
It sucks, too... Again, no discussion.
Last point: Plugins and versioning.
I love plugins. And versioning.
Plugins can be a good choice to extend stuff, to scratch some specific itches.
Plugins are NOT an excuse to say: hey, we don't integrate any features or offer plugins by ourselves, go implement your own plugins for that.
That's just absurd.
(precondition: feature makes sense, like e.g. listing dependencies, checking for updates, etc - stuff that most likely anyone wants)
Versioning. Well. Here goes number one award to Node with it's broken concept of just installing multiple versions for the fuck of it.
Another award goes to tools without a locking file.
Another award goes to tools who do not support version ranges.
Yet another award goes to tools who do not support private repositories / mirrors via global configuration - makes fun bombing public mirrors to check for new versions available and getting rate limited to death.
In case someone has read so far and wonders why this rant came to be...
I've implemented a sort of on premise bot for updating dependencies for multiple build tools.
Won't be open sourced, as it is company property - but let me tell ya... Pain and pain are two different things. That was beyond pain.
That was getting your skin peeled off while being set on fire pain.
-.-5 -
How does FS-based locking,
Eg. What sqlite does, work on the inside?
I'm working on a file-format for storing binary data and I want it to be safe for concurrent use.2
Top Tags
Weekly Rant
View