While looking at our most popular CodeSODs this year, I noticed we had two popular ones that both involved the ternary operator. So, what the heck, this one's a twofer. Originally, "As the World Ternaries" and, "Returnary". -- Remy
As the World Ternaries
Ah, the ternary operator. At their worst they’re a way to obfuscate your code. At their best, they’re a lovely short-hand.
For example, you might use the ternary operator to validate the inputs of a function or handle a flag.
Best of 2016: Overpowered
by Remy Porter
in Best of…
on 2016-12-26
Merry Holidays, and as we coast into the new year, it's time for us to reflect on some of the best/worst moments of the past one. Today, we start things off with a BANG, and a reminder that electricity is a complicated beast. --Remy
Mike had a different perspective on wiring and cable management- because he worked at a factory which made wires and cables. It was the early–90s, and he was in charge of babysitting a couple of VAXes and their massive, 85lb hard drives. It was an easy job: the users knew the system and needed very little support, the VAXes were practically unstoppable, and the backup battery system could keep the entire thing running for over an hour.
The computers supported HR and accounting, which meant as the year ticked towards its end, Mike had to prep the system for its heaviest period of use- the year end closing processes. Through the last weeks of December, his users would be rushing to get their reports done and filed so they could take off early and enjoy the holidays.
'Twas the Night Before Go-Live
by Remy Porter
in Feature Articles
on 2016-12-22
Once again, we're hitting the holiday season. I had fun doing The PM Who Stole Christmas last year, so I decided to try my hand at another holiday classic. Expect your regularly scheduled Error'd tomorrow, but next week, we'll be revisiting our classic and best articles of the year. Happy Holidays! -- Remy
’Twas the night before go-live, and all throughout git,
Not a coder was coding, no single commit;
The release was planned by DevOps with care,
In hopes that userbase would soon be there.
The PMs were nestled all snug with their charts,
While dreams of big bonuses danced in their hearts;
My team in the team room, and I with donuts,
Cracked wise about our PM being a putz;
The Call of the 90s
by Remy Porter
in Feature Articles
on 2016-12-20
The 90s were a weird decade, and not just because of a strange obsession with flannel. Computers were just becoming a mass-market phenomenon, and nobody really quite grasped what that was going to mean. When I entered college in the late 90s, the campus was still littered with dumb terminals wired up to the VAX. Just a few years before, they’d installed the latest thing in networking- 100Base-TX Ethernet- to all of the dorm rooms and most of the classrooms. They loved their brand new network, and didn’t want punk kids messing it up, so you couldn’t just connect your computer to the network (you probably didn’t have a network card anyway). Instead, they had an outside vendor set up an office in a storage room on campus. You had to lug your tower over there, they’d take your computer for a week or two, and then give it back to you with a new NIC, a bunch of crapware, and a note which said your computer was cleared to use the network. You could then take that note over to the IT offices, and they’d put in a work order to activate the network port in your dorm room, and give you an Ethernet cable. Oh, and this entire process cost $200.
The 90s were a dark, dark time.
Eventually, they wised up, kicked the outside vendor off campus, and CS majors like myself got to make a couple of bucks installing NICs into freshmen’s computers. I think many of us might have had that sort of experience. Sabrina did a similar turn in her teens, helping a small ISP get people connected via modem or ADSL, but encountered a few… special edge cases.
Recycled Code
by Remy Porter
in CodeSOD
on 2016-12-19
Hannes has inherited a legacy project. Like most legacy projects, it has no real documentation, the code is a disorganized mess, and making any change runs a non-zero risk of completely knocking over the house of cards.
What few comments the code has tells us things like this:
Not Getting the Getters
by Remy Porter
in CodeSOD
on 2016-12-14
The number of customers that might purchase your software has a detectable impact on how you develop that software. If you’re making a smartphone time-killing game, for example, there are potentially hundreds of millions of customers for that game. This drives software in two directions- you have your mounds of shovelware crap that just hope to make a few bucks fleecing suckers, and then you have the tight competition that optimizes the design of the software.
Contrast that to “enterprise” software. If you’re making an ERP, how many potential customers do you have? Thousands? Tens of thousands? And each one of them is going to want something different from your product, so you’ll need to either pile on features or build an Internal Platform that lets them customize it. It doesn’t matter how much money is in this market, or even how many users there are going to be- it’s all about the number of customers that might pay for your product. This, I suspect, is a large part of why enterprise software is terrible, and I think it lays out a corrolary to Remy’s Law of Enterprise Software: the narrower the audience, the worse the software is going to be.
This is the Endian
by Remy Porter
in CodeSOD
on 2016-12-12
Anyone who’s ever needed to write cross-platform code in C or C++ knows that TRWTF is endianness. Your options are either to use a lot of platform specific preprocessor macros, or to coerce all of your data into your own specific format, for portability.
Adam H’s company took the latter approach, implementing a ByteWriter class. It was relatively easy to use, with code that looked something like this:
Un-Encoding
by Remy Porter
in CodeSOD
on 2016-12-08
Felix caught a ticket about their OpenId authentication. For some mysterious reason, it had started failing around 30% of the time, specifically because the access token returned by the service was invalid.
Felix had originally written the code, but there was one problem: he wasn’t the last one to touch it. Another development team needed their own versions of the code, organized a bit differently, for infrastructure reasons. Eventually, the whole thing was turned into a drop-in library component that was used by all applications which depended on OpenId. The failures started after they made their changes, so obviously their changes caused the failures.
Off in the Distance
by Remy Porter
in Representative Line
on 2016-12-06
Drew W got called in to track down a bug. Specifically, their application needed to take a customer’s location, and measure the distance to the nearest National Weather Service radar station. It knew the latitude and longitude of each, and needed to find the distance between those points, and it was wrong. It could be off by hundreds or even thousands of miles, especially in more remote locations.
Forums
Nov 16