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

111–120 of 588 posts

Re: "We ran out of columns"

#111

Post by poikroequ »

dakiol wrote: post #24

Honestly, I like to work on such systems because: - there is so much stuff to improve. There’s nothing better than the feeling of improving things with code (or by removing it) - it’s back to school again and everything goes. You can implement features in any way you want because the constraints the system imposes. Granted, sometimes it’s painful to add functionality - there’s usually no room to subjective topics lik…

> there is so much stuff to improve. There’s nothing better than the feeling of improving things with code (or by removing it)

And there is nothing worse than a crappy codebase the company won't let you improve.

Re: "We ran out of columns"

#112

Post by mort96 »

nolist_policy wrote: post #51
marcosdumay wrote: post #34

Earlier quoted context omitted.

> Another WTF moment was realisation that MS SQL Server does not support BOOLEAN type. The standard does not have a boolean type. It's a postgres extension that the other open source databases adopted (because, yeah, it's obvious). But the proprietary ones insist on not having. The official recommendation is using byte on MS SQL and char(1) on Oracle. Both are ridiculous.

C programmer joins the chat.

Hey we've had _Bool and since 1999!

Re: "We ran out of columns"

#113

Post by mort96 »

trte9343r4 wrote: post #21

Slicing columns into multiple tables is fairly common type of sharding. Sort of SQL way to do columnary store.

But splitting into multiple tables because you hit the 1024 column limit is probably not a common type of sharding...

Re: "We ran out of columns"

#114

Post by brightball »

Nexialist wrote: post #31

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

Had a similar thing on a small team at a bigger company. We didn't have any type of version control so the team did all development on a shared dev server that we SSH'd into. We'd use vim to edit files one at a time and rely on vim's file locking to make sure that we weren't editing anything at the same time as anybody else.

Oddly, the project was one of the best I've ever worked on.

Re: "We ran out of columns"

#115

Post by SoftTalker »

werdnapk wrote: post #60
Nexialist wrote: post #31

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

Visual SourceSafe would show that a file was checked out hinting to maybe stay away. Good times.

IIRC SourceSafe could be configured with strict locking or advisory locking? I might be wrong about that.

The admin user could override or unlock locked files. We had to do this if a developer left a file checked out after they left, or were on vacation. Nobody knew the admin password for the SourceSafe repository. That was OK though, all you had to do was make a local account on your PC named the same as a the source safe admin acccount, and you'd have admin access in SourceSafe.

Re: "We ran out of columns"

#116

Post by jancsika »

Oh man, this article reminds me of an article that was a parody of some horrid business logic.

Something like this: a "genius" programmer was somehow, for some reason using svn commits as a method dispatcher. Commit ids were sprinkled throughout the codebase. A new hire broke the entire system by adding comments, and comments weren't compatible the bespoke svn method dispatcher.

Does anybody remember this article? I really want to read it again.

Re: "We ran out of columns"

#117

Post by evan_ »

mikeocool wrote: post #56
Nexialist wrote: post #31

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

I recall something similar from my first job, except the shared file locking was a full on feature in Macromedia dreamweaver. CSS was just starting to get adopted and every project we worked on just had one “gobal.css” file. When someone else had global.css locked, you’d call dibs if you needed it next. Inevitably, everyday someone would leave the office and forget to unlock global.css and no one else could get anyth…

It just did this by creating a sentinel file- so if you needed to, you could just delete the file manually.

Re: "We ran out of columns"

#118

Post by SoftTalker »

pbronez wrote: post #70
MarceColl wrote: post #10

Earlier quoted context omitted.

Yes, but both these have very different properties. He said (I don't know if its the case) that the db didnt have an autoincremental type. Postgres uses these sequence objects to implement autoincremental ids as he was referring to, they are implemented in-engine and are very fast and have already solved data races. In the article, what he complains about is not about what a sequence is, but about implementing it man…

The scary thing to me about that setup is how the global value is updated. Every individual script must successfully increment the value to avoid duplicate keys. Really hope they had a “get key” stored procedure to handle that.

It's possible they had some requirement for gapless ID numbers. You can't do that with a sequence.

Re: "We ran out of columns"

#119

Post by SoftTalker »

dakiol wrote: post #24

Honestly, I like to work on such systems because: - there is so much stuff to improve. There’s nothing better than the feeling of improving things with code (or by removing it) - it’s back to school again and everything goes. You can implement features in any way you want because the constraints the system imposes. Granted, sometimes it’s painful to add functionality - there’s usually no room to subjective topics lik…

You also get to see some genuinely creative stuff that works well, written by people who aren't indoctrinated in a particular approach.

Re: "We ran out of columns"

#120

Post by dfee »

gnat wrote: post #92
Nexialist wrote: post #67

Earlier quoted context omitted.

It was a little tongue in cheek, but yes. I had large grievances with the software culture there, but after I got sign off on the project to modernise our build process, I couldn't bring myself to abandon ship in the middle of trying to fix it. After everything was finished up, I was feeling burnt out and realised that I'd held on for too long at a company with a fundamentally bad culture that wasn't going to change…

Thank you for the clarification. Because you said “it took a small team … and then I resigned”, it was unclear that you were part of that small team and instead made it sound like you left because the problem was fixed.

For what it’s worth, it wasn’t unclear when I read it.
Post reply on HN