Last Build Date: Sun, 22 Jan 2017 10:04:30 GMT
Fri, 20 Jan 2017 11:00:00 GMT
"I can't read German, but that doesn't look like glowing praise," writes Bruno G.
TC wrote, "This is a thank-you email from Oracle after signing up to their forum. Personally I usually go by just 36db for short. 36bd5a41-416f-438c-93e0-d4dd04bf860e is my father's name!"
"I've heard FSX addons are expensive, but I'll pass on this one anyway," writes Stephan.
"This Windows Embedded installation is provided with the best license I have ever found on a software package. Forget about Linux, this is freedom!" Arrigo M. wrote.
Finlay writes, "You know, I appreciate how Xcode likes provide extra technical information in the small print."
"Yeah...whole lotta crashing going on here. Time to go read a book and let my computer think about what it's done," wrote Frankie.
Will H. writes, "You know, if they know there is going to be an error, why not FIX IT instead of warning me?!"
Thu, 19 Jan 2017 11:30:00 GMTAlex T had hit the ceiling with his current team, in terms of career advancement. He was ready to be promoted to a senior position, but there simply wasn’t room where he was- they were top-heavy as it was, and there were whispers among management of needing to make some cuts from that team. So Alex started looking for other openings. There was another team at his company which had just lost all of its senior developers to other teams. Alex knew that was a bad sign, but in general, climbing the career ladder was a one-way street. Once he had a senior position, even if it was terrible, he could transfer to another team in a few months, keeping his senior title and salary. Perry was the team’s technical director. “I’ve been laying out the TPM architecture for years,” Perry explained, “and you are going to be part of implementing my vision.” That vision was an Internal Framework called “Total Process Management”, which, as the name implied, was a flexible business rules engine that would manage all of their business processes, from HR, to supply chain, to marketing, it would do everything. “We’re bringing the latest technologies to bear, it’ll be based on RESTful microservices with a distributed backend. But we need to staff up to achieve this, so we’re going to be doing a lot of interviews over the next few months, you and me.” Alex knew he could apply for another internal transfer after six months. He already saw this was a disaster, the only question was how disastrous would it be? While the code Perry had him writing was an overcomplicated mess of trendy ideas badly implemented, the worst part was doing the interviews. Perry sat in on every phase of the interview, and had Opinions™ about everything the candidate had on their resume. “You used Angular for that?” he demanded from one candidate, sneering, and drawing a bright red “X” on their resume. He criticized another for using a relational database when they could have used MongoDB. One interview ended early when the candidate admitted that they didn’t spend their nights and weekends hacking at personal projects. The worst part, for Alex, was his role in the technical screens. He’d read about the failures of white-board programming, the uselessness of asking trivia questions: “How do you reverse a linked-list?” wasn’t exactly a great interview question. He’d planned out a set of questions he thought would be better, and even some hands-on coding, but Perry nixed that. “I want you to build a test with an answer key,” Perry said. “Because at some point, we may want to have non-technical people doing a first-pass screening as our team grows and more people want to join it. Use that in the technical portion of the interview.” Interviews turned into days, days turned into weeks, weeks into months, and eventually Perry brought in Jack. Jack had worked at Google (as an intern [Advertisement] Release! is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped! [...]
Tue, 03 Jan 2017 11:30:00 GMTGit is a divisive piece of technology. There's a number of people who insist that it's the best of all possible version controls, often citing the fact that a complete repo copy is on everyone's computers in case of emergency. There are also a lot of horror stories of people screwing up commands and ending up neck-deep in tutorials, desperately trying to undo what they did. Recently, I was involved in a discussion about the merits of Mercurial. The usual git fans stopped by to ridicule the lack of history-rewriting in Mercurial, insisting that it's a necessary part of any version control. Which reminded me of this reader submission ... Toni worked at a certain company that worked on inventory systems, and was also a defense contractor. Her manager quit out of protest; the new boss—whose name was Alexander, but he insisted on being called "Lex"—was assigned to the team from upon high. Lex was a dopey corporate puppet who liked to talk about Bob Dole a lot. The best the team could hope for was that he'd stay out of their way, making vague promises about the future but not actually accomplishing anything. After all, they had done just fine without a boss for eight months. What they didn't know? Lex had been given the keys to the kingdom: their server git repository, and everything in it. One fateful morning, Toni woke up at 4:00 AM to an SMS saying that the code repository at work had been accessed by "a new member of the compliance team." ... What? she wondered, groggily. There was no new member on the "compliance team." That wasn't even a real department name! Damn it, we've been hacked. She rushed to the office, wide awake at this point, praying for no cops with speed guns on the way there. Did someone break in? she wondered. Or worse, hack into the local code repository from one of the ports the IT guys kept forgetting to close? Surely a randomly generated password longer than a bible couldn't have been cracked, right? By 8:00 AM, she hadn't found any sign of intrusion. She was asleep at her desk from exhaustion when her co-worker, Clarissa, came in. Clarissa had just wiped her MacBook Pro clean the night before due to a botched OS X update. She had also gotten a text message, but had assumed it was Toni, as she'd been working late the night before. Clarissa was able to discover what Toni had overlooked: to their horror, two new people, with names 20 characters long, had been "invited" into the team, and the team had been "renamed" to Compliance. That was when they both got an email from Lex. I thought you could use some help! :) That "help" came in the form of two dimwits from the Chennai, India branch, recently acquired by merger a year before. Through Slack, they admitted to the existing team members that they had never used a version control system before. Toni was already seeing red at this point, but the day was just beginning to reveal the depths of insanity that were in store for them. The two new team members had decided that the color of the web-based inventory front-end wasn't "good enough." Now, this had just gone through a redesign; the colors matched the official design guideline, and had been agreed on by numerous stakeholders. Not only did the newbies change the colors, they decided to deploy those changes to the main Internet-facing servers without going through QA. Toni was still processing that little gem when she heard the fires of hell erupt from Clarissa's cubicle. Clarissa told Toni that their "friends" had pushed code to master, bypassing QA, while also tinkering with her custom branches. As if that wasn't bad enough, they'd used an editor that had converted all the source code files on her branch to Windows format, which screwed up all the line endings. Immediately, this caused conflicts with the existing frameworks, and one of their parsers no longer worked. In a fit of brillance, the two new helpers had decided a force push would do the trick. Surely it couldn't be their color tweak breaking things, right? App[...]