Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

Post reply on HN
Print view View original

281–290 of 588 posts

Re: "We ran out of columns"

#281

Post by hinkley »

nyokodo wrote: post #133
dmd wrote: post #97

Earlier quoted context omitted.

Ha - we did that too at BMS. We were paying Oracle by the column or something like that, so people would shove entire CSV rows into a single value (because corporate said everything HAD to be in Oracle) and then parse them application-side.

> people would shove entire CSV rows into a single value So you invented a “no-sql” document database in Oracle.

We got rid of most of the DBAs because they got overfond of saying 'no' and they became a major source of friction for doing reasonable architecture. People started figuring out ways to work around the DBAs like stuffing more shit into existing columns or adding secondary tables that established new relationships between the sacrosanct tables.

A lot of the worst sins happened on Oracle databases, mostly because they were the most popular at the time, and they were the only real DB cult, so the cottage industry of specializations that told other developers not to worry their pretty little heads was especially bad.

Re: "We ran out of columns"

#282

Post by grishka »

bartekpacia wrote: post #253
grishka wrote: post #237

The worst codebase I've ever worked on was the Telegram client for Android. I mean just look at this file, it's so huge GitHub gives up rendering it: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... Or this one, it implements EVERYTHING for rendering and interacting with a message in a single class, all non-service message types, all drawn manually on a canvas "for performance", and all input processed…

It’s even more crazy because Telegram is by far the smoothest messenger app on Android. BTW, would you mind sharing how you got that job?

> BTW, would you mind sharing how you got that job?

I started working with Pavel Durov in 2011 on the VKontakte Android app, after winning several of his developer contests, and it all just went from there. I was the last one of the "old" team to transfer to Telegram. My main job was actually the libtgvoip[1] library and its integration into the Android app (the other platforms were done by their corresponding devs).

I got fired in 2019 because the calls weren't working satisfactorily for Pavel. He got furious when he was unable to call some journalist, cursed at me in front of the entire team and sent me a termination notice. In hindsight, I should've definitely not taken building a VoIP library from scratch alone upon myself. It's a massive undertaking. But at least I learned a lot, and many people say that my implementation performed noticeably better than the current WebRTC-based one ¯\_(ツ)_/¯

I'm now working on two fediverse projects at the same time — Smithereen[2], a VK-like ActivityPub server, and the Mastodon Android app[3].

[1] https://github.com/grishka/libtgvoip

[2] https://github.com/grishka/Smithereen

[3] https://github.com/mastodon/mastodon-android

Re: "We ran out of columns"

#283

Post by bsder »

mike_hearn wrote: post #270
nine_k wrote: post #227

Earlier quoted context omitted.

Did it run under DOS? I'm not even asking about a win16 native GUI client. (You can still enjoy CVS if you want to contribute to OpenBSD, for instance.)

Yes, and for Win95 users there was actually a very nice GUI plugin to explorer called TortoiseCVS. The funny thing about CVS and Subversion is that they were last version control systems that non-programmers could actually use. TortoiseCVS/TortoiseSVN were easy enough that with a lot of training you could get technical writers or artists to use it too. Valuable for game projects. With git, forget about it. It can't e…

Mercurial and TortoiseHg were fine, too.

Only Git had the brain damage to take the source control idea of "there are two areas: working or committed" and add the dumbass index/staging/stash areas that confuse the hell out of everything.

Re: "We ran out of columns"

#284

Post by sanktanglia »

Im currently deep in rewriting a c# monolith thats 10+ years old that has thousands of lines of extra code that i was able to throw away because most of it was written before there were optional arguments so they made overloads for every permutation of arguments for every framework function

Re: "We ran out of columns"

#285

Post by xp84 »

zo1 wrote: post #54
layer8 wrote: post #30

Earlier quoted context omitted.

> remodeling data types and schemas (which you often do as you build an application, whether or not you thought of a great schema beforehand) This is not my experience, it only happens rarely. I’d like to see an analysis of what causes schema changes that require nontrivial migrations.

Same here. If your entities are modelled mostly correctly you really don't have to worry about migrations that much. It's a bit of a red herring and convenient "problem" pushed by the NoSQL camp. On a relatively neat and well modelled DB, large migrations are usually when relationships change. E.g. One to many becomes a many to many. Really the biggest hurdle is managing the change control to ensure it aligns with yo…

I agree. Migrations have never been a problem at my company and this codebase is 9 years old. Just regular old postgres with a few JSONB columns of things that don't need to be relational.

Same for the database that was about 8-9 years old at my last company. Migrations are fine. It's the relationship-changing that is painful.

Re: "We ran out of columns"

#286

Post by acchow »

mewpmewp2 wrote: post #271
gumby wrote: post #211

Earlier quoted context omitted.

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forkin…

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out…

> Git is not a natural development at all. Obviously, it is a standard right now.

Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for.

But senior developers can understand the problems that they claim to address, and why they are important and common problems.

Re: "We ran out of columns"

#287

Post by xp84 »

RaftPeople wrote: post #89
teaearlgraycold wrote: post #20

Earlier quoted context omitted.

Byte vs. Int is premature optimization. But indexing, primary keys, join tables, normalization vs. denormalization, etc. are all important.

> Byte vs. Int is premature optimization I think you can only judge that by knowing the context, like the domain and the experience of the designer/dev within that domain. I looked at a DB once and thought "why are you spending effort to create these datatypes that use less storage, I'm used to just using an int and moving on." Then I looked at the volumes of transactions they were dealing with and I understood why.

Deep down, the optimizer in me wants this to be true, but I'm having trouble seeing how this difference manifests in these days of super powerful devices and high bandwidth.

I guess I just answered my own question though. Supposing there's a system which is slow and connected with very slow connectivity and still sending lots of data around, I guess there's your answer. An embedded system on the Mars Rover or something.

Re: "We ran out of columns"

#288

Post by TacticalCoder »

hleszek wrote: post #126

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

> At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was obvious: installing Visual Studio for each customer on site and teaching the users to run the app in debug mode from Visual Studio.

Holy smoke! That's actually the most creative solution (horrible, but creative) I've ever heard to fix a Heisenbug:

https://en.wikipedia.org/wiki/Heisenbug

Re: "We ran out of columns"

#289

Post by MBCook »

fouronnes3 wrote: post #130
hleszek wrote: post #126

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

I never had to deal with “we don’t use source control”, luckily.

One company I joined was cleaning up the last vestiges of “customize it for every customer by letting people edit their copy on server,” which predictably turned into a mess. They were all very small customizations to styles or images but enough to make upgrades a total mess.

I did work at a company where despite having full source control they didn’t actually know of they could ever deploy the server component again. Edits got made to the live server but then made again in source control, or vice versa. There was one more senior person who couldn’t be talked out of their old workflow.

In theory everything matched.Eventually they even checked and got it all under control where they were positive it was the same and kept it that way.

But it had only ever been deployed from scratch… once. And for like 15 years it lived there and kept getting upgraded. It would all be moved when new hardware was brought in.

But it wasn’t installed from scratch. We truly did not know if we were capable of doing that. It is possible if that server was destroyed and we couldn’t restore from a back up it would take us an unknown amount of time. Even though in theory deploying should be as simple copying the files and starting the web server.

Were there odd configurations that had been made eight years ago that kept it running? Some strange permission changed somewhere?

I wasn’t on that team. But it always made me nervous. That was absolutely a core application of the business.

I really like small shops sometimes. You get a lot of freedom and get to have your hands in a lot of disciplines. You learn a lot of things, including things that’s should never be duplicated.

Re: "We ran out of columns"

#290

Post by xp84 »

doublepg23 wrote: post #228
tryauuum wrote: post #47

Would be great to work in such a company as a Linux guru. There are so many entangled services and machines that you feel like an Indiana Jones. You ssh into a machine and feel century-old dust beneath your footsteps. And you never know what will you find. Maybe a service which holds the company together. Maybe a CPU eating hog which didn't do anything useful last 3 years. I don't enjoy writing new code much. But in…

When I started my recent job the team kept referring to a box running "weird linux". After getting on-boarded and accessing the box it turned out to be running a very old version of OpenBSD. To this day I'm curious who had the wherewithall to install OpenBSD in prod but was seemingly ignorant of the 1yr support cycle.

I started reading and was hoping someone had installed one of the Linux distros that were popular at the turn of the millennium, like Mandrake, Slackware, etc. and it was still trucking along 25 years later.
Post reply on HN