Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "homegrown"
So today (or a day ago or whatever), Pavel Durov attacked Signal by saying that he wouldn't be surprised if a backdoor would be discovered in Signal because it's partially funded by the US government (or, some part of the us govt).
Let's break down why this is utter bullshit.
First, he wouldn't be surprised if a backdoor would be discovered 'within 5 years from now'.
- Teeny tiny little detail: THE FUCKING APP IS OPEN SOURCE. So yeah sure, go look through the code! Good idea! You might actually learn something from it as your own crypto seems to be broken! (for the record, I never said anything about telegram not being open source as it is)
- The server side code is closed (of signal and telegram both). Well, if your app is open source, enrolled with one of the strongest cryptographic protocols in the world and has been audited, then even if the server gets compromised, the hackers are still nowhere.
- Metadata. Signal saves the following and ONLY the following: timestamp of registration, timestamp of the last connection with the server (both rounded to the day so not on the second), your phone number and your contact details (if you authorize it) (only phone numbers) in HASHED (BCrypt I thought?) format.
There have been multiple telegram metadata leaks and it's pretty known that it saves way more than neccesary.
So, before you start judging an app which is open, uses one of the best crypto protocols in the world while you use your own homegrown horribly insecure protocol AND actually tries its best to save the least possible, maybe try to fix your own shit!
*gets ready for heavy criticism*22
Experience that made me feel like a dev badass?
Users requested the ability to 'send' information from one application to another. Couple of our senior devs started out saying it would be impossible (there is no way to pass objects across a machine's memory boundary), then entertained the idea of utilizing the various messaging frameworks such as Microsoft's ServiceBus and RabbitMQ, but came up with a plan to use 2 WebAPI services (one messenger, one receiver) along with a homegrown messaging API (the clients would 'poll' the services looking for message) because ServiceBus, RabbitMQ, etc might not be able to scale to our needs. Their initial estimates were about 6 months development for the two services, hardware requirement for two servers, MSSQL server licenses, and padded an additional 6 months for client modifications. Very...very proud of their detailed planning.
I thought ...hmmm...I've done memory maps and created simple TCP/IP hosts that could send messages back and forth between other apps (non-UI), WPF couldn't be that much different.
In an afternoon, I came up with this (see attached), and showed the boss. Guess which solution we're going with.
The two devs are still kinda pissed at me. One still likes say as I walk in the room "our hero returns"....frack him.11
Let me tell you a story.
Our company has a homegrown monitoring solution. Keeps track of our deployments and alerts us when something is broken. Really nice for the most part, except a little issue where we get up to 25 alerts PER DAY that our PRODUCTION ENVIRONMENT IS DOWN. Including weekends.
With this many false positives, we quickly learn to ignore the alerts and miss real incidents.
So we approached this team, remember its our own tool, and told them about the problem. Turns out it is a known issue. And here's the kicker: they aren't planning on fixing it!
It gets better. Rather than fix this glaring issue, their solution is to make ANOTHER ALERT that lets us know the monitoring is misbehaving.
To recap, we can now expect to get up to 25 false positive alerts per day that our production is down, followed immediately by more alerts that the monitor is broken, which means we can ignore the previous alert.
As our PM said when he heard this: fuck that noise. We are escalating the shit out of this!7
My tech stack progression:
Started with PHP without any frameworks, using a homegrown MVC architecture. Used to use `mysql_` functions everywhere. And only jquery + vanilla CSS in the front end.
Then moved to use PDO functions in PHP and Backbone.js + Less CSS in the front-end.
Then moved to Django in the back-end. Did not like Django very much as it is too opinionated and not flexible (although it's damn good for rapid development if you buy into their type of things).
Then moved to Flask + SQLAlchemy and using a home grown architecture. This is a sweet spot for me in terms of back end and stayed in this spot for the longest time.
Moved to Postgres from MySQL as I fell in love with Postgres.
Then learnt React+Redux. Liked it. Made most sense to front-end development this way. Moved front-end stack to React+Redux.
Learning Haskell and been working with Scotty and eyeing Servant for a while now.
Let's see where it goes from here.
PS: this is my personal journey through various tech stacks in various products at various companies I have worked. I'm not talking about moving a product through these many tech stacks. That doesn't make any sense.9
Like most people I needed some extra cash during uni, so I proceeded to learn CSS + Photoshop (yeah, I know). Followed by PHP and WordPress.
It can be a very shitty platform until you realize that you can stop combining plug-ins from all over the place with dubious code quality and roll your own.
Anyhow I kept at it until I was able to join a niche company doing a quite popular caching plug-in for WP (yeah, W3 Total) when I suddenly became *very* interested in anything and everything performance.
This landed me a very cozy consulting gig in the Nordics - they were using WP for an elephant-traffic website and had run into a myriad of perf issues.
Fixing them and breaking the monolith awarded me with skills in nodejs, linux, asynchronous caching among others.
I was soon in charge with managing the dev boxes for the entire team, and when the main operations dude left, I was promoted to owning the entire platform. (!) Tinkering with Linux for most of my life really came in handy here. (remember Debian potato?)
Used saltstack + aws cloudformation to achieve full parity between all environments. Learned myself some python and all various tips and tricks which in the end amounted to 90% reduction in time-to-first-byte and considerable cost savings.
By the end of the 2yr contract I had turned myself into a fullstack systems engineer and never looked back.
Lawyers not getting along resulted in us having to abandon NewRelic, so I got to learn and deploy the ELK stack as a homegrown replacement, which was super-fun.
Now I work in the engineering effectiveness department of a Swedish fintech unicorn where all languages under the Sun are an option (tho we prefer Python), so the tech stack is unlimited. Infinite tools and technologies, but with strong governing principles and with performance always in mind so as to pick the right tool for the job.
It's like that childhood feeling when you've just dumped a ton of Lego on the floor and are about to build something massive.
I guess the morale here is however disappointed you feel by your current stack - don't. Always strive to make things better, faster, more decoupled, easier to test, etc. and always challenge yourself to go outside the comfort zone.6
My most satisfying bug fix?
I found a core concurrency issue in this gnarly homegrown ORM and reported it to the lead devs, who (very defensively, having written the damn thing) argued that it would never pop up in a prod environment and I was stupid for even bringing it up. Theoretically, this bug could cause pretty much every foreign key to be assigned to the wrong parent, but only if multiple instances of the application were open/running at once. They were so certain it would never happen on live that they explicitly instructed me not to fix it. After all, this bug had been active for many years on a previous project and nobody complained.
Problem was, that previous project was something that only a single user had open most of the time (think: a manager). The new project was something that would be used by multiple people at the same time (think: all the employees). Once we released this new-project-with-old-orm, it didn't take long at all for our customers to start complaining.
After that, they let me fix the bug. :)
So my homegrown raytracing engine somehow managed to render this.
(It's supposed to be a material approximating oldish gold: a texture, a diffuse material model and a specular material model)
(Note the reddish bright interior areas. I think energy isn't being conserved in the specular BSDF. Bug. Gah.)2
I worked on a project that used an archaic homegrown library written by a consultant that had zero documentation, tons of reflection and here is the kicker... the consultant refused to give us the source code as it was "his intellectual property" so we couldn't make any sense of how to actually use it. Moreover, he worked remotely so the timezone difference between us meant that any questions we had took ages to get answered. Glad to be away from that project now.4
So the curriculum director is sad that she can't query lecture objectives that nobody ever entered out of our homegrown database, so she's insisting on buying an expensive off the shelf system, I guess expecting these data to magically be available once it's in place.
This also means I'll have to rewrite the API I've been developing for the past year that powers most of the curriculum resources.
Why can't everyone just know how databases work?2