Forums
Bleu supports a Pimcore-based PHP site. Pimcore is a rather sprawling enterprise system for PHP. Like many Model-View-Controller type frameworks, maps HTTP requests to actions on controllers. Bleu's team has several "default" actions configured on their controllers. Let's take a look at a few of them.
Aug 23public function searchAction()
{
// TODO: replace with actual search
// instead of static page showing all important subpages.
}
Matt's team had a party after their last release. It was a huge push, with tons of new features, that came at the end of many months of work. On the Monday after the party, they came back into work for unsurprising bad news: nothing is perfect, so there were several issues and defects that needed to be patched, quickly.
Since QA is the team responsible for signing off and approving any work, QA is the team that also owns the defect tickets. Matt and his team can't do any work without a ticket, which meant they spent almost an entire day knowing there were bugs to fix, but without any idea of what bugs to fix.
Inilock started making locks back in the 1880s, and has always had a conservative approach to changing things about how locks work. But the world has moved on, and the pin-and-tumbler has given way to RFID card readers and electromagnets.
Since Inilock didn't have the internal expertise to build industrial locking systems for commercial customers, they did what any company would do: they hired highly paid consultants. The project started in 2018. These consultants went out and build a lock firmware platform, a server, and a homegrown TCP protocol to handle configuration and setup, handed it in late and over budget, cashed their checks, and vanished, by 2022.
Mike was refactoring an old web application written in Perl. We joke about Perl being a "write only language," but the original developer wanted to take that unreadable attitude to the JavaScript front-end portion of the application.
function setup() {
position('m1',46,220);
position('m1g',33,200);
position('m1c',33,200);
position('m2',46,330);
position('m2g',33,310);
position('m2c',33,310);
// ... snip 50 lines
}
Typos are the bane of delevopers' existence. For most of our typos, the result is a syntax error. It's quick and easy to find and fix. But any time we're working with strings (or in languages where variables are declared at use) there can be many more subtle bugs.
So when Abigail's company sent an intern off to fix a few typos, they thought this was a lovely little low-hanging fruit bug to fix.
There are common errors that are (or were) once so common that we've built tools to help us avoid them. So I was a little surprised to see this JavaScript from Annie's co-worker.
toggleField() {
this.updateToggle(this.obj.id, this.toggle).subscribe(data=> {
if (data.status = "success") {
this.showToast('Toggle updated successfully');
...
}
...
}
}
David's organization didn't fully understand why you bring interns into a company. The purpose of an internship is to provide an educational opportunity and resume line-item to someone looking to enter the industry, and possibly recruit said intern after they graduate, getting a new-hire that is more ready for your team than average. It's good for the intern, it's good for the overall health of the industry, it's good for the company building its network of professional relationships and recruiting opportunities.
The purpose of an internship is not to just throw tickets at an intern, and let them commit code to your main branch, unsupervised. Unfortunately for David, and for the poor interns that preceded him, that is what the company had done.
Sometimes, you see a code sample and you almost scroll by. "This isn't bad, I see it all the time." So it took a second glance to see the awful charm of what Henrik H found.
Henrik was asked to join a project to fix a high load website having "some issues". Here's a JavaScript tag that was included on nearly every page.
"John Doe" was asked to take a look at a slow-running application. It didn't take too long to discover that the application was slow because the database was slow, but figuring out why the database was slow involved digging deeply through some logs.
The database was a central system, which many applications connected to. Every ten minutes, performance dropped significantly, and it just so happened that every ten minutes a batch update process ran.
Moz works for a company that needs to handle financial transactions. They use Delphi, which has a handy-dandy fixed precision Currency type, which should make this easy.
Of course, someone opted to do most of the math in double precision floating points anyway. Which lead to this function:
As frequently stated, concurrency is hard. Ensuring that all of your data is accessed in a threadsafe manner is a real challenge. So when Ryan saw a method called ThreadSafeArray, it seemed like an obvious utility method: wrap an array up in a thread safe accessor, right?
Well, the signature of the function made Ryan suspicious. And the code…
Time zones are hard. And, to my surprise, if you want to enumerate all the time zones in the world in C#, there isn't an easy way to do that. You can enumerate all the time zones configured on the host computer (in Windows), but that may be incomplete and also may use idiosyncratic names, since it doesn't use the IANA database of timezones.
This leaves developers with a three real options. The first would be to either load the IANA database yourself, and the second would be to use a library that provides it.
The easiest way to write programs that support concurrency is to not. JavaScript in the browser is famously single-threaded, unless you add web-workers, which have a very specific way of interacting with your main script that avoids most of the pitfalls of concurrency. Or at least makes them easy to avoid.
But what if you had a developer who didn't know any of this, and just assumed JavaScript was multithreaded and needed locks, but didn't understand how locks worked? Then you'd get something like this code, from an anonymous submitter.
A decade ago, Adam was doing support on a classic ASP application. This was an internal application which tracked sales accounts, employee reviews, and general HR information. Now, the company had a real HR system, but some of their internal processes predated the HR system, thus they had a custom application that did things the HR system already did, but they already owned the application and didn't want to retrain people.
One day, a manager logged in, started doing some work, took a break, and came back, only to discover that when she pulled up a list of employees, she no longer saw her direct reports, but instead saw all of the employees at the company. She reported the bug and Adam picked up the ticket.
Tracking the performance of an application matters. Too often, developers will try and tune and optimize an application based on their instincts about where the performance is bad- instincts which are frequently wrong.
Remy L's company included performance tracking blocks in their code, enabled by a debug flag. According to the performance stats, their program performed incredibly well. There were rarely ever any long-running methods.
It's Labor Day in the US, which means we're taking a break from the usual grind. Enjoy this classic story about the challenges of providing users with the authentication system they desire- one with no passwords or usernames. Original -- Remy
“It’s impossible,” Gerald said in a matter-of-fact tone, “simply impossible.”
“Now just so we’re clear,” Craig responded, “by ‘impossible’, you actually mean ‘a big pain in the ass’, but you’re a smart guy who can make it happen, right?” That drew a few chuckles from the handful of other coworkers who joined them in the conference room, but Gerald just sighed. “No, Craig, by impossible, I mean impossible. Not doable. Can’t be done. Im-poss-i-ble. Well I mean, unless you can somehow change the underlying structure of the way everyone communicates on the Internet.”