Forums
Every time you change existing code, you break some other part of the system. You may not realize it, but you do. It may show up in the form of a broken unit test, but that presumes that a) said unit test exists, and b) it properly tests the aspect of the code you are changing. Sadly, more often than not, there is either no test to cover your change, or any test that does exist doesn't handle the case you are changing.
The dependency graph of your application can provide a lot of insight into how objects call each other. In a well designed application, this is probably mostly acyclic and no one node on the graph has more than a handful of edges coming off of it. The kinds of applications we talk about here, on the other hand, we have a name for their graphs: the Enterprise Dependency and the Big Ball of Yarn.
Thomas K introduces us to an entirely new iteration: The Big Ball of Mandelbrot
Have you ever secured something with a lock? The intent is that at some point in the future, you'll use the requisite key to regain access to it. Of course, the underlying assumption is that you actually have the key. How do you open a lock once you've lost the key? That's when you need to get creative. Lock picks. Bolt cutters. Blow torch. GAU-8...
In 2004, Ben S. went on a solo bicycle tour, and for reasons of weight, his only computer was a Handspring Visor Deluxe PDA running Palm OS. He had an external, folding keyboard that he would use to type his notes from each day of the trip. To keep these notes organized by day, he stored them in the Datebook (calendar) app as all-day events. The PDA would sync with a desktop computer using a Handspring-branded fork of the Palm Desktop software. The whole Datebook could then be exported as a text file from there. As such, Ben figured his notes were safe. After the trip ended, he bought a Windows PC that he had until 2010, but he never quite got around to exporting the text file. After he switched to using a Mac, he copied the files to the Mac and gave away the PC.
Being a software architect is a difficult task. Part of the skill is rote software design based upon the technology of choice. Part of it is the very soft "science" of knowing how much to design to make the software somewhat extensible without going so far as to design/build something that is overkill. An extreme version of this would be the inner platform effect.
Way back when I was a somewhat new developer, I was tasked with adding a fairly large feature that required the addition of a database to our otherwise database-less application. I went to our in-team architect, described the problem, and asked him to request a modest database for us. At the time, Sybase was the in-house tool. He decreed that "Sybase sucks", and that he could build a better database solution himself. He would even make it more functional than Sybase.
Simon T tugged at his collar when the video played. It wasn’t much, just a video of their software being tested. It wasn’t the first time they’d tested Simon’s most recent patch, but it was going to be the last time. There were a lot of eyes in the conference room, and they were all turned on him.
Simon worked for the kind of company which made missiles. The test in the video was one of the highly expensive tests of a real missile under real-world conditions. Several of these had already been done with this software package, so Simon hadn’t expected any problems to crop up. In this case, though, the missile left its launcher and sailed in a perfect parabolic arc into the ground 5 meters away from the launch site.
As we've seen previously, not all government jobs are splashy. Someone has to maintain, for example, the database that keeps track of every legal additive to food so that paranoid hippies can call them liars and insist they all cause cancer and autism. Today's submitter, Cass, had just released an update when users started getting the dreaded blue Internal Error screen—never a good start to the week.
Containers make deployment easy, or at least that’s what it says on the label. It makes intuitive sense, though- instead of wrangling all your dependencies on a host OS, and then trying to understand why your app can’t see them, you bundle all the dependencies into a container and push that around when you want to deploy. It Just Works™.
Sandra had just left a company which didn’t use containers, but containers wouldn’t have helped: the didn’t have a working deployment process, period. They didn’t even try deploying before the production push 9 months into the project, and the first twelve attempts consistently failed because someone hadn’t tested something, or someone didn’t update the script, or the requirements changed and were signed off but nobody told the development team. It meant a lot of nights, a lot of weekends, and a lot of meetings which devolved into circular firing squads.
If you've looked at job postings, you know that there's one thing really big and trendy right now, and that's blockchains. But the other trendy thing is Machine Learning! We'll talk about the Daily WTF's Initial Coin Offering at a later date, but for right now, we're excited to announce our new ML efforts.
Specifically, we recognize that there's a certain structure and pattern to our articles, and instead of paying human writers, we can instead employ the latest machine learning systems to generate new articles that will be indistinguishable from the articles you know and love. The ideal tool, of course, would be an Recurrent Neural Network, which we could train based off previous articles. Unfortunately, that involves a lot of GPU power, and we're already using our GPUs to get ready for that ICO I mentioned. Shhhh. It's a secret.
Mar 18