This is from StackOverflow.
Insanely unhelpful error page. “Something failed, then something else failed.” Really?
The worst part of this is that it changed the URL too. So I can’t even just refresh to try again.
The MyBuilder error page is one I don’t really like. We chose it because it’s just static content, and we don’t have to care about what’s broken. If it’s a 500 error, show the same static content (even if we’re still able to display dynamic data). It’s a much easier solution, but when a user gets in touch to tell us, all they can say is “hey, I tried to do something and it just said there was a 500 error!” No helpful leads at all.
I just stumbled across this though, and really like it!
I’m not saying expose the entire error stack trace, but if they’re seeing an error, they may as well see one they can tell us about.
MyBuilder is a company that loves to look at an analyze our processes, and play with them to try to optimise. Our daily standup time is currently one that’s changing a fair bit, so I thought I’d get my thoughts down on paper.
First there was the idea that we should start at nine am, right at the start of business hours. The motivation for this is that it gets everyone in on time, and kicks off the day with everyone knowing what they’re doing.
The problem ended up being that some people were late (I’m notoriously late far too often) which ended up annoying the those who did turn up on time – why should they get here for nine to start a meeting that they can’t actually start until half nine, when I eventually stroll in? It’s upsetting, and disrespectful of their time. But the fact is, no matter how organised you are in the morning, delays whilst commuting in London are inevitable. (And I’m in the worst part for it, apparently.)
So we moved our standup time to half nine, to accommodate people being a little late. There were a number of problems with this:
So we’ve most recently decided to go the other extreme: last thing of the day, at 1730.
We’ve done this now for a little over a week, and for me it seems to not be awful. What you’ve done that day is fresh in your mind, and blockers are easy to think of (because you’ve probably already been blocked). And it makes being late not an awful act of disrespect. The people that get in early know what they should be working on as soon as they get in, and don’t have to wait for the checkin to find out.
It’s not perfect though. Half past five is definitely a winding down time in my office. Nerf wars are easier to start (because we’re just
sittingstanding ducks). People seem to be more easily distracted, often ending up talking between themselves until they’re nudged back into the meeting. Both of these can be fixed by team members staying focused, and asking customer service to hold off the gunfire after 1730.
I much prefer this time, mostly because it feels like a better time to be discussing what you’ve done today, and to plan for tomorrow.
During Symfony Live (London, 2013), the first person to mention this was Jakub Zalas.
That’s not surprising; most people who mention this concept usually give a hat tip to BDD style testing. The argument is that instead of giving a command to the machine like
job.addTradesman, you’re telling a story with your test. And the way we tell stories is with spaces. And since our test names usually tell a story (
job should be able to have a tradesman associated) why not use the next best thing? Underscores. (Analogy stolen from Eric Lefevre-Ardant.)
One problem my team have is that this breaks our convention of
There’s a few reasons that have just dawned on me why I don’t like that. First, it’s not working as tests-as- documentation. That type of name is explaining the scenario, but what we really want to know is what the outcome should be. Second, I’m not often jumping into a test file to look at all the tests concerning
addTradesman. I’m usually opening a test file because a test has failed. And what I need to know then, really quickly, is what was expected to happen, and what actually happened. This current method of naming doesn’t give me that information. However,
Our compromise is to have our test method names look something like this:
testAddTradesman_adding_a_second_tradesmen_should_override_the_first. (There’s nothing wrong with long method names, especially in tests; don’t roll your eyes.)