Also worth pointing out that by default flamegraphs only show on-cpu time (i.e. your application/kernel running code at the time the sample is taken). That is not the whole story, if the application/thread is asleep waiting for something and doesn’t run on any of the CPUs at the time the sample is taken it won’t show up at all. To see them you need to use “off-cpu” flamegraphs.
I once found a literal “sleep” in the code deep in a 3rdparty library that way (it was PAM, and it kept loading/unloading the crypto library every time, triggering it’s initialization code many times, which had a ‘sleep’ inside it as it was too early for pthread_cond to work. More modern Linux distros don’t have this problem anymore since they switched to libxcrypt).
Flamegraphs can actually help visualise anything where you can produce a weighted frequency for a given stack! You can also do things like trace disk I/O or memory allocations, using the size in bytes as a weight, to get interesting visualisations as well.
I never thought about measuring things other than runtime! I’ll have to keep this in mind; stuff like profiling memory allocations seems like it could be really handy.
Is there a good guide for how to build up the flamegraph data with custom metrics like that? I must admit I have relied on “tool spits out stuff for flamegraph.pl consumption” and haven’t thought of it further
My hero! I thought about doing this myself, and quickly dismissed it as ridiculous. I only considered it because I wanted to learn Nix better, not because I am comfortable with the language.
DHTML, which absolutely stands for “distributed HTML” because that’s the name and this isn’t obvious bait for the no fun crowd at Hacker News
the only way the author could have made it more obvious that it was a joke was if the author had written “WARNING the next sentence is a joke and is not to be taken literally!” before it and then “WARNING END we will now be sincere again” after it
Has anyone here tried this in practice? It sounds appealing, but the practical lack of tooling around version control, deployment, logging, and debugging worry me.
The article is a bit basic using a very limited ser of relational databases features. There are entire banks and other large systems built entirely with stored procedures. Has anyone tried? Well, everyone, back in the day.
A few years ago, I showed a couple of young engineers how we could ditch some 100k LOC worth of backend code with 12 stored procedures, 20 to 100 loc each. We exposed them via HTTP using postgrest. They were very negative and complaining that it was old useless tech. Only by the end of the week when they got it done, had they realized what an enormous gain it was.
Edit: I have no idea where the myths that version control, logging and even debugging come from. You naturally have all these things. Perhaps not a step by step debugger, although I never looked for one.
I’ve seen it used, it’s super old school, and all of the concerns you mention are real and relevant. It results in very tight coupling between business logic/rules and the underlying state/data, and hoo boy that data had better be properly relational or else you’re in for a world of pain. It can be a good idea, in certain contexts, but IME those contexts are few and far between.
I think version control and deployment would be pretty easy to manage with bog-standard migrations.
Testing is fairly easy too and there are libraries for directly testing database queries.
Logging, and debugging idk.
The author said they wanted to use postgres functions cos they kept changing their application language, so I think they probs ended up cooling on postgres functions too.
Lots of successful applications are written in databases, tho. Look up MUMPS / GT.M.
I’ve worked with and built a few relatively heavily programmed Postgres databases. At my current job we stand a GraphQL API up over it with Postgraphile and do everything from access control with row-level security to EEG labeling task management in the database. We build Postgraphile plugins for things not amenable to SQL like JSON tree aggregation. It’s great for us, with a low baseline write load and bursts from scientific dataset transfers; it won’t apply as well to every situation out there although I think it’s generally useful at least to consider.
The 1990s style “procs are your CRUD interface” approach is mostly an artifact of the pre-RLS era. It can still be useful if you want to provide a not-quite-CRUD interface to clients: for example, we replace insert with upsert and offer dedicated operations around dataset membership. The critical component to making it work well imo is to keep the “standard” update_x type wrappers simple – they should do just one thing, and data integrity + correctness checks go in constraints not procedural magic. The biggest problems come up when different rules apply to a wrapped invocation than to a DBA-written SQL statement.
Tooling-wise testing with pgTAP is great, there’re monitoring solutions like pgbadger out there, & there’s even a pldebugger albeit built into pgadmin. Commercial databases do better in some areas but version control integration is the same for everyone – some interesting ideas out there but managing schema changes is never quite seamless.
We do this in our shop. The tools haven’t been a problem. However we have had problems with our “viral” this has been. Once important code was in the database, then we started writing more database code to use it. Ultimately, we have built systems into the database that shouldn’t be there.
My latest company which hired me however mandated a company MacBook
Is this common? I have been fortunate to use Linux at every tech company I have worked with over the last 16 years or so. It was a pretty big deal when the first started allowing Linux and Macs as options to Windows, but every one since has allowed Linux.
Granted, I may be self-selecting somehow. After all, an opportunity with the comment ‘Every developer gets a top-of-the-line MacBook!’ would probably not entice me to apply.
It’s pretty common for compliance reasons; my last employer required this and my current employer just sent me a macbook a few months ago. They make us keep all our private code on it so the day it arrived I installed virtualbox on it and set up port forwarding for SSH and stuck it in a closet. I basically never touch it except to do OS upgrades which for some reason can’t be accomplished over SSH.
I wish Linux worked for our developers. We’ve adopted a mandated MacBook too. People who’ve chosen Linux have generally had a much more difficult time getting their systems to work. The drivers are too finicky and the companies aren’t chosen to support the tools needed to do video conferencing.
Most companies I worked for gave you the choice of either ThinkPad with Linux or Macbook, but I’ve heard from friends about the “here’s your macbook” with varying degree of possibility to change it.
Interestingly a lot of stuff I’ve been working with simply doesn’t work on Windows, so I’ve been pretty safe from “here’s your Windows laptop”, but friends who do consulting/work at customers for a few weeks/months have told enough stories of getting handed one of those, I’d take a mac book over this any day.
Is this common? I have been fortunate to use Linux at every tech company I have worked with over the last 16 years or so. It was a pretty big deal when the first started allowing Linux and Macs as options to Windows, but every one since has allowed Linux.
very, very common esp. with Bay Area and/or start-upy companies. My last 3 jobs always had work mandated MacBooks. The other option was Windows and I def. never want to go back to that.
Appreciate this list thanks! It’s great to see local options.
Also worth pointing out that by default flamegraphs only show on-cpu time (i.e. your application/kernel running code at the time the sample is taken). That is not the whole story, if the application/thread is asleep waiting for something and doesn’t run on any of the CPUs at the time the sample is taken it won’t show up at all. To see them you need to use “off-cpu” flamegraphs.
I once found a literal “sleep” in the code deep in a 3rdparty library that way (it was PAM, and it kept loading/unloading the crypto library every time, triggering it’s initialization code many times, which had a ‘sleep’ inside it as it was too early for pthread_cond to work. More modern Linux distros don’t have this problem anymore since they switched to libxcrypt).
Flamegraphs can actually help visualise anything where you can produce a weighted frequency for a given stack! You can also do things like trace disk I/O or memory allocations, using the size in bytes as a weight, to get interesting visualisations as well.
I never thought about measuring things other than runtime! I’ll have to keep this in mind; stuff like profiling memory allocations seems like it could be really handy.
Is there a good guide for how to build up the flamegraph data with custom metrics like that? I must admit I have relied on “tool spits out stuff for
flamegraph.plconsumption” and haven’t thought of it furtheryou are everywhere.
I assure you I am not!
Sampling profilers (such as
rbspy) do the opposite - visualizing wall time only.My hero! I thought about doing this myself, and quickly dismissed it as ridiculous. I only considered it because I wanted to learn Nix better, not because I am comfortable with the language.
This tutorial is great! I’ve tried WezTerm a few times, but I didn’t realize the potential. Thanks for sharing.
That’s beautiful. Thanks for sharing this. Hopefully we’ll see him keep going.
I think you mean Dynamic HTML. Aside from that, I remember being responsible for doing many of these abominations.
I’m pretty sure it’s a joke. The article is from 2014 and I think “distributed” was a buzzword at the time.
I totally got trolled by it.
this is the whole sentence:
the only way the author could have made it more obvious that it was a joke was if the author had written “WARNING the next sentence is a joke and is not to be taken literally!” before it and then “WARNING END we will now be sincere again” after it
Except that was added today: https://web.archive.org/web/20240125090024/https://zachholman.com/posts/only-90s-developers/
Yes, to make it more obvious.
The writer of this article should have accounted for Poe’s Law, though.
Common mistake, it’s actually Disruptitative HTML.
Disreputable HTML more like.
Something tells me they meant to say distributed.
Yeah, I was wondering if that was a joke or not.
This is awesome! I do miss the OSX top bar.
Has anyone here tried this in practice? It sounds appealing, but the practical lack of tooling around version control, deployment, logging, and debugging worry me.
The article is a bit basic using a very limited ser of relational databases features. There are entire banks and other large systems built entirely with stored procedures. Has anyone tried? Well, everyone, back in the day.
A few years ago, I showed a couple of young engineers how we could ditch some 100k LOC worth of backend code with 12 stored procedures, 20 to 100 loc each. We exposed them via HTTP using postgrest. They were very negative and complaining that it was old useless tech. Only by the end of the week when they got it done, had they realized what an enormous gain it was.
Edit: I have no idea where the myths that version control, logging and even debugging come from. You naturally have all these things. Perhaps not a step by step debugger, although I never looked for one.
I’ve seen it used, it’s super old school, and all of the concerns you mention are real and relevant. It results in very tight coupling between business logic/rules and the underlying state/data, and hoo boy that data had better be properly relational or else you’re in for a world of pain. It can be a good idea, in certain contexts, but IME those contexts are few and far between.
I think version control and deployment would be pretty easy to manage with bog-standard migrations.
Testing is fairly easy too and there are libraries for directly testing database queries.
Logging, and debugging idk.
The author said they wanted to use postgres functions cos they kept changing their application language, so I think they probs ended up cooling on postgres functions too.
Lots of successful applications are written in databases, tho. Look up MUMPS / GT.M.
I’ve worked with and built a few relatively heavily programmed Postgres databases. At my current job we stand a GraphQL API up over it with Postgraphile and do everything from access control with row-level security to EEG labeling task management in the database. We build Postgraphile plugins for things not amenable to SQL like JSON tree aggregation. It’s great for us, with a low baseline write load and bursts from scientific dataset transfers; it won’t apply as well to every situation out there although I think it’s generally useful at least to consider.
The 1990s style “procs are your CRUD interface” approach is mostly an artifact of the pre-RLS era. It can still be useful if you want to provide a not-quite-CRUD interface to clients: for example, we replace insert with upsert and offer dedicated operations around dataset membership. The critical component to making it work well imo is to keep the “standard” update_x type wrappers simple – they should do just one thing, and data integrity + correctness checks go in constraints not procedural magic. The biggest problems come up when different rules apply to a wrapped invocation than to a DBA-written SQL statement.
Tooling-wise testing with pgTAP is great, there’re monitoring solutions like pgbadger out there, & there’s even a pldebugger albeit built into pgadmin. Commercial databases do better in some areas but version control integration is the same for everyone – some interesting ideas out there but managing schema changes is never quite seamless.
We do this in our shop. The tools haven’t been a problem. However we have had problems with our “viral” this has been. Once important code was in the database, then we started writing more database code to use it. Ultimately, we have built systems into the database that shouldn’t be there.
Is this common? I have been fortunate to use Linux at every tech company I have worked with over the last 16 years or so. It was a pretty big deal when the first started allowing Linux and Macs as options to Windows, but every one since has allowed Linux.
Granted, I may be self-selecting somehow. After all, an opportunity with the comment ‘Every developer gets a top-of-the-line MacBook!’ would probably not entice me to apply.
It’s pretty common for compliance reasons; my last employer required this and my current employer just sent me a macbook a few months ago. They make us keep all our private code on it so the day it arrived I installed virtualbox on it and set up port forwarding for SSH and stuck it in a closet. I basically never touch it except to do OS upgrades which for some reason can’t be accomplished over SSH.
I wish Linux worked for our developers. We’ve adopted a mandated MacBook too. People who’ve chosen Linux have generally had a much more difficult time getting their systems to work. The drivers are too finicky and the companies aren’t chosen to support the tools needed to do video conferencing.
Most companies I worked for gave you the choice of either ThinkPad with Linux or Macbook, but I’ve heard from friends about the “here’s your macbook” with varying degree of possibility to change it.
Interestingly a lot of stuff I’ve been working with simply doesn’t work on Windows, so I’ve been pretty safe from “here’s your Windows laptop”, but friends who do consulting/work at customers for a few weeks/months have told enough stories of getting handed one of those, I’d take a mac book over this any day.
very, very common esp. with Bay Area and/or start-upy companies. My last 3 jobs always had work mandated MacBooks. The other option was Windows and I def. never want to go back to that.