“More stuff about .NET? There’s been … uh … not much stuff on .NET yet this year, Jeremy!”
Logging code. Euch. It’s just … stuff … that always without exception ends up being slathered all over your code like chocolate sauce on profiteroles. Sticky, gooey, sickly.
As a developer that likes to understand where code works and where code doesn’t I rely on logging to be there, but I’d rather that it wasn’t in my face. The chocolate sauce gets everywhere.
For example, I’ve seen horrible patterns where logs are injected in through constructors, which seems attractive (yay! testable!) but means that every test has to inject the logger in.
Which is just bloat: sure, we want to test logging works, but not everywhere.
My prompt for the Selenium testing code in the last post was the need to write some “smoke tests.” Is the code stable, or is it on fire?
So the last couple of posts were a bit fluffy and wordy. Here’s a more geeky one to redress the balance.
The smoke tests I described last time around use Selenium from C#. This is a fine tool but my first attempt at automating the smoke tests was slow and brittle.
This was partly because I didn’t want to make changes to the carefully crafted front-end code. Finding what I wanted in the DOM meant I went through quite some contortions. Then someone would refactor the structure and the tests would fail even though the site was just fine.
Never mind that the site might not actually work. Just feel the beauty of the CSS model and the pixel-perfect layout!
I’m getting a bit involved with automated testing in the current gig. So the next few posts will go into some things I’ve found as we explore the best way to do testing on larger Agile Web projects.
Like many teams we find it hard to judge the right level at which we should test our code. Unit tests? Integration tests? End-to-end tests?
As is fashionable we’re using Behaviour Driven Development, through the .NET SpecFlow library. This is a version of the Cucumber toolset that takes Gherkin files and compiles them out to C# stub tests that can then be implemented.
Now we started by going the whole way from the UI to the database. In theory this is great, we’d have wonderful coverage and could use the tests to drive how the UI worked. In practice it didn’t prove so good.
A few years back I worked with an energy firm to help put together release processes.
In the UK the energy market is split into power generating firms, retail sales firms and a company that owns the wires that join it all together. A handful of large firms own different pieces of the split and trade with their competition.
These large firms themselves are a bit of a mix: they combine the retail side, who are competitive sales people working on the edge; the generating side who are conservative engineers; and the trading side who are wanna-be City traders.
Amusingly the stereotypes could be seen across the headquarters building where I worked. Retail was next door but had helpfully left contact details on the reception desk in case the Fair Trading regulators came to call. The traders barked at each other on the telephone over stacks of monitors. And the engineers supporting the power stations had very neat desks lined with manuals for Visual Basic and Oracle.
I was there to help the release process for the power station teams. And, as it happens, I didn’t have much to do – as despite using twenty-year-old technology their release processes were close to the modern DevOps approach.
Yes, it’s been a while since I posted a blog entry. In January 2013 I started at a new gig building an from scratch an internal system with a great team using all the latest fashionable buzzwords. BDD, Specflow, Kanban, Knockout.js, all good fun.
I seem to have found a niche as the liaison between the development team and the infrastructure people. May as well paint a target on my forehead, I think.
Anwyay. I reckon its time I put down in writing some of what I’ve learned so I can start to make sense of it.
One of the questions that comes up in chats about cloud hosting is “which host.” On the whole in the Microsoft world the three ‘safe’ choices that management have heard of are Windows Azure, Amazon AWS and their own data centre.
The team that I’m with took over development of a high-profile internal Web system from a third-party Microsoft consultancy but my development colleagues and me were uneasy about the choice of SQL Azure as the database. I’d found it slow when I migrated a database-intensive system to Azure. Were there alternatives, we wondered?
In summary: yes. At this established mid-size company Azure was not a good fit on performance, pricing or flexibility. So a team of developers hired for Azure have ended up working with AWS!
Individually, they’re lovely: now it’s open-source, StyleCop seems to be (finally!) getting the love and attention it needs, NuGet has rapidly come of age to be the one-stop-shop for package management in .NET without the angle-bracket heartache that is Maven, and Jenkins, well, Jenkins just rocks.
But together they don’t play nice at all.
Best not iisreset an Azure instance
Like, I suspect, many other developers, I think I need to know more about my deployment environment than perhaps is good for me. But with PaaS (platform-as-a-service) hosting, sometimes that can give, well, unexpected results.
For example, Windows Azure offers a (really very handy) facility to open a Remote Desktop session to a Windows Server host that runs an Azure instance. You’re logged in as local Administrator, too, so you can cause some serious damage in there if you want.
Or even if you don’t want.
Previously I ranted about JQuery Mobile and the immature state of mobile development tools. While I was on that project I reckoned it might be a good idea to use an emulator so I could test what my mobile Web site might look like in real life.
A nice idea, but in practice it seems the mobile toolchain is… rather more full of good intentions than actual capability.
Er, you what?
I like Stack Overflow and the other StackExchange sites. They’re very clever: you go there in response to a Google search, and find yourself trapped into answering questions about all sorts of things.
I mean, Joel and Jeff even sent me a hat, and a couple of pens, and a T-shirt, for answering a question about… worktop surfaces. And if that doesn’t count a sign I get easily distracted from the day job, nothing will.
One thing I’ve started to notice is that plenty of people end up asking questions that can be answered by themselves by understanding a little more about the tools they already have. A good example is the WCF Service Trace Viewer.