Forums
Let’s say you’ve got a project object in your code. A project might be opened, or it might be closed. In either case, you want to register an event handler to change the status- closed projects can be opened, opened projects can be closed. Now imagine you’re Antonio’s co-worker, Grenk.
No, this time, it’s not a matter of streams. Today, it’s ternary abuse, of the “why is this even here” sort.
Debugging code on embedded devices introduces additional challenges to tracking down what's going wrong, especially as in many cases, you can't even rely on any sort of println debugging. I've worked with a few devices which my only debugging output is 3 RGB LEDs.
Serial devices, then, can be a godsend. For short runs, you can often just wire pin-to-pin, but for longer connections, you need some sort of serial transceiver chip. In most practical situations, the flow between two devices is CPU->UART->transceiver->cable->transceiver->UART->CPU. Apologies to the OSI model, yes, it's more complicated than this, but for our purposes, it's a useful illustration.
The beauty of structured exception handling is that it removes explicit conditional logic from your code. The conditions are still there, of course: a catch statement is essentially saying "if the exception type is X, then do this". But the strict syntax gives the compiler some freedom, and if you're using a language like Java, which favors checked exceptions (where methods declare what kinds of exceptions they might throw), there are all sorts of shortcuts the compiler might take to keep that efficient.
But hey, that's all implicit, and if there's one thing we've learned, "explicit is better than implicit". How can we make exception handling explicit? Well, our Anonymous submitter inherited some Java code which does just that.
“We’re a dynamic, multi-paradigm organization, and we do most of our new development in a blend of Ruby and Go. We’re not the kind of company that is dogmatic about tools though, we just want to deliver the best product for our customers.”
That’s what Delphia was told in the interview. She didn’t quite grasp why they were mixing those two techs in the first place, but the interview went well, and she took the job. It was then that she discovered that everything she’d been told was technically true.
“Um… can you come take a look at something for me?”
Pat looked up from happily hacking away at some new features to see Milton hovering at the edge of the cubicle.
Rita caught a weird bug. It was weird, in part, because there hadn’t been any code changes in their label printing application for ages. Yet, there was a sudden new bug. Labels were printing with what was obviously unicode garbage. Interestingly, the application definitely supported unicode- there had been a huge effort a few years back to move the C++ code from chars to wchars.
Rita started debugging, and confirmed that when the label text was populated, memory stored correct values. By the time the data was printed, it no longer did. Obviously, there was something wrong with memory management- something was touching the end of the string and throwing off the output. That was an easy enough bug to make in C++, but tracing through 7,000 lines of label printing code to figure out where things got thrown off was more of a chore, especially with the… “friendly” variable naming convention the original developer had used.
Printer jams are an unavoidable circumstance. Paper might not seem sticky, but static electricity and humidity can to horrible things, and all the protections in the world can't stop them. Printers are also objectively terrible, and always have been.
Years ago, when Coyne T was a fresh-faced youth, he supported an aging COBOL-based warehouse system. Their reports went to a noisy continuous feed line printer. The printer was a finicky beast, and no matter what sacrifices were made before printing, it had a tendency to devour pages, or have the gears slip and misprint lines. Because the report data came straight from a COBOL job, there was no cached output to reprint- the entire reporting process would need to be re-run every time the printer got angry.
“So, we have a problem. A… a big one.”
Andrea C worked for an insurance company. In terms of software development, a “problem” meant she’d misfiled one of her TPS coversheets or something like that. A big problem meant she’d accidentally checked in code that contained a comment with some profanity in it.
Carl works in research, and like most research organizations, half their code is carelessly glued together GUI tools, command line interfaces, and shell scripts. The other half, the half which does the real work, is Fortran. Sure, the code was written forty years ago, but the laws of physics haven’t changed, so it’s still good and it’s still fast.
Carl usually doesn’t have to touch the Fortran half. Instead, he usually looks at the other bit. Most things are run from shell scripts, and most of the work of the shell scripts is getting environment variables configured so that they Fotran code can actually run its model without having a heart attack.
I mentally think of the early 2000s as "the XML Age". XML was everywhere. Everyone wanted to put XML into their applications. Java was the XML king, using XML for everything. People were starting to ask themselves, "do we need the big expensive RDBMS, when we can just use XML instead?"
In other words, just like JSON today, but worse. Tomislav A inherited one such database- a clunky pile of XML documents with only the vaguest hint of a schema to them, and a mix of valuable, useful data, and a mountain of crap. With the assumption that all data validation was happening in the application layer, the database was mostly "garbage in, garbage sits there forever and can never be deleted because it might be important".
Alex L works for a company with a bunch of data warehousing tools. One of the primary drivers for new features is adding bits which make the sales demos shinier, or in marketing speak, "delivers a value add for a prospective customer".
One of those "shinies" was a lightweight server which would gather stats from the data warehousing engine and provide a dashboard with those stats, and notifications about them. Prospective customers really love it when the machine goes "bing" and shows them an interesting notification.
Jan 19