One reason that automated UI tests can be unreliable is that they tend to be sensitive to what else is on screen at the time and even things like the current screen size. Developers running the tests locally also find it annoying to have windows opening and closing on their machine while the test runs and are unable to do anything else because their clicking might interfere with the test. At LMAX Exchange we solve that by isolating tests in their own X session, created using vncserver.

Once an application goes live, it is absolutely essential that any future changes are able to be work with the existing data in production, typically by migrating it as changes are required. That existing data and the migrations applied to it are often the riskiest and least tested functions in the system. Mistakes in a migration will at best cause a multi-hour outage while backups are restored and more likely will subtly corrupt data, producing incorrect results that may go unnoticed for long periods making it impossible to roll back.

Just like production code, you should assume things are going to go wrong in your tests and when it does you want good logging to help track down what happened and why. So just like production code, you should use a logging framework within your DSL, use meaningful log levels and think about what info you’d need in the logs if something went wrong (and what you don’t). There’s also a few things we’ve found very useful specifically in our test logging.

With Selenium 1, JavaScript alert and confirmation dialogs were intercepted by the Selenium JavaScript library so they never appeared on-screen and were accessed using selenium.isAlertPresent(), selenium.isConfirmationPresent(), selenium.chooseOkOnNextConfirmation() and similar methods. With Selenium 2 aka WebDriver, the dialogs do appear on screen and you access them with webDriver.switchTo().alert() which returns an Alert instance for further interactions. However, when you use WebDriverBackedSelenium to mix Selenium 1 and WebDriver APIs – for example, during migrations from one to the other – the alerts don’t appear on screen and webDriver.

Today LMAX Exchange has released ElementSpecification, a very small library we built to make working with selectors in selenium/WebDriver tests easier. It has three main aims: Make it easier to understand selectors by using a very English-like syntax Avoid common pitfalls when writing selectors that lead to either brittle or intermittent tests Strongly discourage writing overly complicated selectors. Essentially, we use ElementSpecification anywhere that we would have written CSS or XPath selectors by hand.

In programming courses one of the first thing you’re taught is to avoid “magic literals” – numbers or strings that are hardcoded in the middle of an algorithm. The recommended solution is to extract them into a constant. Sometimes this is great advice, for example: if (amount > 1000) { checkAdditionalAuthorization(); } would be much more readable if we extracted a ADDITIONAL_AUTHORIZATION_THRESHOLD variable – primarily so the magic 1000 gets a name. That’s not a hard and fast rule though.

Probably the best thing I’ve discovered with my recent playing is Travis CI. I’ve known about it for quite some time, even played with it for simple projects but never with anything with any real complexity. Given this project uses rails which wants a database for pretty much every test and that database has to be postgres because I’m using it’s jsonb support, plus capybara and phantomjs for good measure, this certainly isn’t a simple project to test.

I’ve been playing around with ruby on rails recently, partly to play around with rails and partly to take a run at a web app I’ve been considering (which I’ve open sourced because why not?). It turns out the last time I played with it was back in 2005 and slightly amusingly my thoughts on it haven’t changed all that much. The lack of configuration is still good, but the amount of magic involved makes it hard to understand what’s going on.

Given our DSL makes heavy use of aliases, we often have to provide a way to include the real name or ID as part of some string. For example, an audit record for a new account might be: Created account 127322 with username someUser123. But in our acceptance test we’d create the user with: registrationAPI.createUser("someUser"); someUser is just an alias, the DSL creates a unique username to use and the system assigns a unique account ID that the DSL keeps track of for us.

Rich Bowen – We’ve Always Done It That Way: Principle 13 in the Toyota Way says that one should make decisions slowly, by consensus, thoroughly considering all options, and then implement those decisions rapidly. We believe a similar thing at the ASF. So to people who have only been around for a short time, it looks like we never change anything. But the truth is that we change things slowly, because what we’re doing works, and we need to be sure that change is warranted, and is a good idea.

Jeffrey Ventrella in The Case for Slow Programming: Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done. Jeffrey’s right in suggesting that we sometimes need to go slower to go faster, unfortunately he makes the mistake of believing that committing and releasing in very short cycles is the cause of these problems:

Lawrence Kesteloot has an excellent post Java for Everything. About a year ago, though, I started to form a strange idea: That Java is the right language for all jobs. (I pause here while you vomit in your mouth.) This rests on the argument that what you perceive to be true does not match reality, and that’s never a popular approach, but let me explain anyway. There are two key realisations that are vital to understanding why this argument has merit and the first one is right there in the introduction: what you perceive to be true does not match reality.

When generating a JavaScript file dynamically it’s not uncommon to have to embed an arbitrary string into the resulting code so it can be operated on. For example: function createCode(inputValue) { return "function getValue() { return '" + inputValue + "'; }" } This simplistic version works great for simple strings: createCode("Hello world!"); // Gives: function getValue() { return 'Hello world!'; } But breaks as soon as inputValue contains a special character, e.g.

In Software is sometimes done Rian van der Merwe makes the argument that we need more software that is “done”: I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

When you have automated testing setup with a big display board to provide clear feedback, it’s tempting to try and use it for things it wasn’t intended for. One example of that is as a kind of reminder system – you identify a problem somewhere that can’t be addressed immediately but needs to be handled at some point in the future. It’s tempting to add a test that begins failing after a certain date (or the inverse, whitelisting errors until a certain date).

Every web based product is adding “responsive design” to their feature lists. Unfortunately in many cases that responsive design is actually making their product much harder to use on a variety of screen sizes instead of easier. The problem is that common CSS libraries and grid systems, including the extremely popular bootstrap, imply that a design can be made responsive using fixed cut-off points and the design just automatically adjusts. In reality making a design responsive requires tailoring the cut off points so that the design adjusts at the points where it stops working well.

Ever since the public beta of OS X I’ve been meaning to get around to learning Objective-C but for one reason or another never found a real reason to. I’ve picked up bits and pieces of it and even written a couple of working utilities but those were pretty much entirely copy/paste from various sources. Essentially they were small enough and short-lived enough that I only needed the barest grasp of Objective-C syntax and no understanding of the core philosophies and idioms that really make a language what it is.

Apple have released Swift, their new programming language – designed to be familiar to Objective-C programmers and work well with the existing Cocoa frameworks. It’s far too soon to make substantial judgements about the language – that can only come after actually using it in real projects for some time. However, there’s nothing that stands out as incredibly broken, so with Apple’s backing it’s extremely unlikely that it won’t become a very commonly used language. After all, there’s plenty wrong with every other programming language and we manage to make do with them.

Did you know that it’s perfectly fine to enjoy programming in both static and dynamic languages? — Honza Pokorny (@_honza) May 26, 2014 I do a lot of coding in Java and JavaScript and it’s never bothered me that one has static types and one dynamic (and I’ve used plenty of other languages from both camps as well – it amuses me slightly that the two I use most often tend to be viewed as the worst examples of each type).

Writing automated tests to prove software works correctly is now well established and relying solely or even primarily on manual testing is considered a “very bad sign”. A comprehensive automated test suite gives us a great deal of confidence that if we break something we’ll find out before it hits production. Despite that, automated tests shouldn’t be our first line of defence against things going wrong. Sure they’re powerful, but all they can do is point out that something is broken, they can’t do anything to prevent it being broken in the first place.

Kevlin Henney’s talk from YOW is a great deconstruction of the SOLID principles, delving into what they really say as opposed to what people think they say, and what we can learn from them in a nuanced, balanced way. Far too often we take these rules as absolutes under the mistaken assumption that if we always follow them, our software will be more maintainable. As an industry we seem to be seeking a silver bullet for architecture that solves all our problems just like we’ve searched for a silver bullet language for so long.

I wanted to create a CSV file showing the number of JUnit tests in our codebase vs the number of Spock tests over time. I can count the number of tests, along with the revision pretty easily with: git svn find-rev HEAD find src/test -name '*Test.java' | wc -l find src/test -name '*Spec.groovy' | wc -l But that outputs the results on three separate lines and I really want them on one line with some separator (comma, space or tab).

Marco Cecconi - I don’t love the single responsibility principle: The principle is arbitrary in itself. What makes one and only Reason To Change™ always, unequivocally better than two Reasons To Change™? The number one sounds great, but I’m a strong advocate of simple things and sometimes a class with more reasons to change is the simplest thing. I agree that we mustn’t do mega-classes that try to do too many different things, but why should a class have one single Reason To Change™?

Previously in the Testing@LMAX series I’ve mentioned the way we’ve provided isolation between tests, allowing us to run them in parallel. That isolation extends all the way up to supporting a multi-tenancy module called venues which allows us to essentially run multiple, functionally separate exchanges on a single deployment of LMAX Exchange. We use the isolation of venues to reduce the amount of hardware we need to run our three separate liquidity pools (LMAX Professional, LMAX Institutional and LMAX Interbank), but that’s not all.

One of the most common reasons people avoid writing end-to-end acceptance tests is how difficult it is to make them run fast. Primary amongst this is the time required to start up the entire service and shut it down again. At LMAX Exchange with the full exchange consisting of a large number of different services, multiple databases and other components start up is far too slow to be done for each test so our acceptance tests are designed to run against the same server instance and not interfere with each other.

Testing time related functions is always a challenge – generally it involves adding some form of abstraction over the system clock which can then be stubbed, mocked or otherwise controlled by unit tests in order to test the functionality. At LMAX we like the confidence that end-to-end acceptance tests give us but, like most financial systems, a significant amount of our functionality is highly time dependent so we need the same kind of control over time but in a way that works even when the system is running as a whole (which means it’s running in multiple different JVMs or possibly even on different servers).

LMAX Exchange has invested quite a lot of time into building a suite of automated tests to verify the behaviour of our exchange. While the majority of those tests are unit or integration tests that run extremely fast, in order for us to have confidence that the whole package fits together in the right way we have a lot of end-to-end acceptance tests as well. These tests deliver a huge amount of confidence and are thus highly valuable to us, but they come at a significant cost because end-to-end tests are relatively time consuming to run.

One of the things we tend to take for granted a bit at LMAX is that we store the results of our acceptance test runs in a database to make them easy to analyse later. We not only store whether each test passed or not for each revision, but the failure message if it failed, when it ran, how long it took, what server it ran on and a bunch of other information. Having this info somewhere that’s easy to query lets us perform some fairly advanced analysis on our test data.

The key to making continuous integration work well is to ensure that the build stays green – ensuring that the team always knows that if something doesn’t work it was their change that broke it. However, in any environment with a build pipeline beyond a simple commit build, for example integration, acceptance or deployment tests, sometimes things will break. When that happens, there is always a natural tendency to commit an additional change that will fix it.

Here’s a fun one, we have some code generated using javassist that looks a bit like: public void doStuff(byte actionId) { switch (actionId) { case 0: doOneThing(); break; case 1: doSomethingElse(); break; default: throw new IllegalArgumentException("Unknown action: " + actionId); } } This works perfectly fine on Java 6 and Java 7 but fails on Java 8. It turns out the problematic part is "Unknown action: " + actionId. When run on Java 8 that throws “java.

The truth is out: money is just an IOU, and the banks are rolling in it: What the Bank of England admitted this week is that none of this is really true. To quote from its own initial summary: “Rather than banks receiving deposits when households save and then lending them out, bank lending creates deposits” … “In normal times, the central bank does not fix the amount of money in circulation, nor is central bank money ‘multiplied up’ into more loans and deposits.

Esoteric Curio折伏; as it relates to coding Our job as a team is to reinforce each other and make each other more productive. While I attempt to conquer some of the engineering tasks as well as legal tasks, and human resource tasks I face, I need concentration and it world certainly help to not be interrupted. I used to think I needed those times of required solitute pretty much all the time. It turns out that I have added far more productivity by enabling my teams than I have personally lost due to interruptions, even when it was inconvenient and frustrating.

Geekdom is not a club; it’s a destination, open to anyone who wants to put in the time and effort to travel there… …dive headfirst into the things that interest you. Soak up every experience. Lose yourself in the pursuit of knowledge. When you finally come up for air, you’ll find that the long road to geekdom no longer stretches out before you. No one can deny you entry. You’re already home. via Hypercritical: The Road to Geekdom.

As a follow up to the earlier link regarding the performance of animations in CSS vs JavaScript, Christian Heilmann – Myth busting mythbusted: Jack is doing a great job arguing his point that CSS animations are not always better than JavaScript animations. The issue is that all this does is debunking a blanket statement that was flawed from the very beginning and distilled down to a sound bite. An argument like “CSS animations are better than JavaScript animations for performance” is not a technical argument.

Myth Busting: CSS Animations vs. JavaScript: As someone who’s fascinated (bordering on obsessed, actually) with animation and performance, I eagerly jumped on the CSS bandwagon. I didn’t get far, though, before I started uncovering a bunch of major problems that nobody was talking about. I was shocked. This article is meant to raise awareness about some of the more significant shortcomings of CSS-based animation so that you can avoid the headaches I encountered, and make a more informed decision about when to use JS and when to use CSS for animation.

The Guardian: Are iPads and tablets bad for young children? Kaufman strongly believes it is wrong to presume the same evils of tablets as televisions. “When scientists and paediatrician advocacy groups have talked about the danger of screen time for kids, they are lumping together all types of screen use. But most of the research is on TV. It seems misguided to assume that iPad apps are going to have the same effect. It all depends what you are using it for.

If you’ve gotten used to your trackpad scrolling the same way as on iOS and (by default) OS X but you’re using Linux you’ll want to go to the “Mouse & Touchpad” settings panel and tick “Content sticks to fingers”. Yeah I know,shockingly simple but for whatever reason I had assumed “Content sticks to fingers” related to some weird drag and drop system…

This is mostly a note to myself, but often when I setup a new Linux install, I find that JUnit tests run significantly slower than usual. The CPU is nearly entirely idle and there’s almost no IO-wait making it hard to work out what’s going on. The problem is that JUnit (or something in our tests or test runner) is doing a DNS lookup on the machine’s hostname. That lookup should be really fast, but if you’re connected to a VPN it may search the remote DNS server which takes time and makes the tests take much longer than they should.

Chris Poole – Small things add up: By migrating to the new domain, end users now save roughly 100 KB upstream per page load, which at 500 million pageviews per month adds up to 46 terabytes per month in savings for our users. I find this unreal. Just by moving images to a domain that doesn’t have cookies. Impressive, especially given that users upload data significantly slower than they download it and HTTP 1.

Ron Qartel: Developing First Class Software with the Developers that Google Rejects Focus on building a great team and a great way to develop, not on hiring individual hotshots. I would caution however that XP isn’t necessarily the “great way to develop” that will work best for your team and your circumstances, but its certainly a good starting point. Just remember that the one key Agile principal is to continuously improve the way you work. So don’t just follow “the rules”.

There’s lots of projects these days moving from one language to the next. Whether that’s a good idea or not varies but let’s accept that it was the right choice and the world is a better place for it. One thing really bugs me: inevitably justifications of how successful that move has been includes a claim that the number of lines of code were so significantly reduced. We rewrote 1.5 million lines of Java in just 6,000 lines of haskell!

Out of the box, Fedora 19 doesn’t have support for the broadcom wifi chip in the MacBook Pro 15″ Retina. There are quite a few complex instructions for adjusting firmware and compiling bits and bobs etc, but the easiest way to get it up and running on Fedora is using rpmfusion. You can do it by downloading a bunch of rpms and stuffing around with USB drives, but its way easier if you setup network access first via either a thunderbolt ethernet adapter (make sure its plugged in before starting up as hotplugging thunderbolt doesn’t work under Linux), or via bluetooth.

Password managers are like exercise, some people are really into and and you know its good for you but it always seems like too much effort. A few times I’ve actually gotten around to trying out password managers and I went pretty far down the rabbit hole with LastPass at one point, but its never stuck with me before. LastPass was ok, but just seemed clunky and instead of making life easier always seemed to make things take just a little bit more effort.

If you ever copy or rsync your home directory to another drive on Linux (especially Fedora 19), you may find that Google Chrome starts to crash whenever you type punctuation, including space characters, into HTML form fields like input or textarea. You may also find that ‘useradd’ complains that it can’t create home directory. It turns out that this is because of SELinux having incorrectly file labels for the files in the new home directory. Simply run:

Transitioning to a new Mac has always been a very smooth experience – the first run setup offers to migrate everything for you and generally it gets everything right so your new Mac comes up looking just like your old one. Recently I’ve acquired a new MacBook Pro with Retina display and decided that after all these years of migrating everything over I’d set up from scratch. Mostly just to make me consciously choose to reinstall things instead of a heap of cruft coming across automatically which I don’t actually use anymore.

Couple of very interesting articles today on architecture of CSS. Firstly Thierry Koblentz questions the benefits of separation of concerns – advocating a coding style where most style rules map a single classname to a single CSS property. In complete contrast Ben Darlow argues the importance of semantic meaning, pushing back against techniques like OOCSS and BEM which move away from semantic class names in the name of modularity – generally resulting in long strings of class names on elements.

If you have: A javascript project using require.js Which is optimised using r.js Includes Rickshaw or any other library that uses the prototype class system Then you are very likely here because you’re trying to enable JavaScript optimization (minification) and finding that suddenly stuff breaks. The problem is that the prototype class system allows overriding methods to call the original method by adding a $super as the first parameter to the function. From the prototype docs:

One of the biggest challenges with selecting a web host is that it’s very difficult to determine the quality of a provider without actually setting everything up and seeing how it goes for a while. Generally that means that you either wind up avoiding the very low cost providers out of fear they won’t be reliable and possibly paying too much, or spending a lot of time and effort setting up with a provider only to then discover they’re unreliable or the performance isn’t as good as you expected.

Note to self: when you next need to handle drag and drop events in javascript, just use jquery.event.drag from ThreeDubMedia. Simple jquery based API and automatically handles the most annoying part of javascript drag handlers – dealing with cases where the user starts dragging inside an element, drags right out of the element and then releases the mouse.

I’ve recently embarked on a fairly complex new application, a large part of which is a webapp written in JavaScript. The application uses require.js to handle modules and loading of dependencies and we want to be able to unit test our JavaScript. In order to test specific pieces of the application, we want to be able to inject stubs or mocks into the module being tested. For example, if we had a module: define(['dataSource', 'utils'], function(dataSource, utils) {.

According to the ant documentation: It is possible to include the same file more than once by using different prefixes, it is not possible to import the same file more than once. Unfortunately, it turns out this isn’t quitetrue. In most cases, ant will indeed ignore a request to import a file for the second time, so: <import> <file name="utils.xml"/> <file name="utils.xml"/> </import> will only import utils.xml once. This is true even if there’s a chain of files being imported (so A imports B and C, then B imports C as well, C will only be imported once).

Most people believe that ant will only ever execute a target once per execution of ant. So if we have targets A, B, C and D, where A depends on B and C and C and D both depend on D. <target name="A" dependencies="B, C"/> <target name="B" dependencies="D"/> <target name="C" dependencies="D"/> <target name="D"/> When we run ‘ant A’, we expect each task to execute once, D first, then B and C, ending with A. Since there is no dependency between B and C, they may execute in any order, so we might also get D, C, B, A.

This information is all covered in much more detail elsewhere on the web but for my own future reference, here’s a primer on doctypes, compatibility modes, charsets and fonts which was required to explain why certain Chinese characters weren’t showing up in IE8. Of course the best answer is that you need to have the East Asian Font pack installed and then it just works (usually) but this tends to be useful background and saves “server side” folks from a number of gotchas.

Ah Apple maps, ever the source of a good sensationalist headline. This time the Victorian police have warned people not to use Apple Maps to get to Mildura. This is definitely a bug with Apple maps, no question it should be and has been fixed. What’s interesting though is that the Victorian police thought it would be easier to attempt to notify every iOS 6 user about the problem via the media and get them to use an alternate mapping application than it would be to call Apple and get them to fix the source data.

From Straights Times: A flier aboard Sunday’s Swiss airline flight – a 57-year-old Chinese man […] felt disturbed during his meal when the passenger in front of him reclined his chair.[…] “The older of the two felt disturbed during his dinner. When the younger did not respond to his protests, he hit him on the head with the flat of his hand. It was a real slap,” said the guide, Ms Valerie Sprenger. A fight then broke out between the two men, who rolled in the plane’s aisle.

Of all the data types, double is probably one of the most misunderstood. A huge amount of folk lore has been built up around it to help protect developers from falling into its many pitfalls. Lately I’ve done a lot of work replacing usage of BigDecimal with double and learnt a lot about where those pitfalls are and how the folk lore can be misleading. The great challenge with double is that it has a degree of inaccuracy because of the way the number is actually stored.

Farnam Street Blog holds up a coding competition as evidence that: If you want to make your computer programmers and engineers more effective give them “privacy, personal space, control over their physical environments, and freedom from interruption.” The only trouble is, the coding competition is fatally flawed as a measure of normal developer productivity. It’s setup such that developers work on their own: Each participant was also assigned a partner from the same company.

Sarah Goff-Dupont has a post on the Atlassian blog about how Atlassian is using feature branches and still doing continuous integration: In the not-so-recent past, continuous integration in the context of story branching was considered so impractical as to be outright incompatible. Who has time to manually configure a CI scheme for dozens of active branches that will only live a couple of days? Nobody –that’s who. And story branch-loving teams would frequently encounter *ahem* “surprises” when merging work onto the main code line –“master”, in Git-speak.

There’s a huge amount of complaining and problem solving for various dependency management solutions (particularly maven, but ivy and friends certainly aren’t immune). Problems range from having optional dependencies unnecessarily included to having duplicate classes or class conflicts and the solutions tend to be complex and involve a lot of trade offs. All these problems stem from breaking the golden rule of dependency management: Own your own repository – Sutton’s golden rule of dependency management

Having configuration differences between development and production is largely unavoidable, but it’s important to keep the number of differences to a minimum to avoid unexpected bugs appearing in production that don’t occur in development mode. More than that though, it’s important to minimise configuration. Configuration is Code Often things are put in configuration files so that they are easy to change later, often without a full redeployment of the software, but that also implies it can be changed without going through the full testing that a release would usually be subject to.

Most systems have multiple configuration profiles – one for production, one for development and often other profiles for staging, testing etc. Minimising differences between these configurations is critical but there are inevitably some things that just have to be different. This then leaves the question, what should the default settings be? There are three main options: Default to production values Default to development values Refuse to start unless an environment has been explicitly chosen My preference is to default to development values.

There is a lot of discussion at the moment about the Oracle v Google trial today, mostly centring around how impossible it is for the jury to understand the very technical concepts involved in the case. As Daring Fireball puts it: How could a randomly-selected jury possibly decide this? No knock intended against the jurors themselves — and it sounds like they’re doing their best to make an informed decision. But there’s a difference between a jury of your citizen peers and a jury of your technical peers.

I thus think (= hope) that it’s a mistake to extrapolate from today’s crappy input systems on tablets to a future of tablet-based couch potatoes still watching Hollywood crap. We’re one innovation away from lowering the creativity hurdle on tablets. Maybe it’ll be a truly responsive keyboard. Or something that translates sub-vocalizations into text (because I’m too embarrassed to dictate into my table while in public places). Or, well, something. via Joho the Blog » Will tablets always make us non-social consumers?

We all know by now that continuous integration is part of good software development – check in regularly and have a suite of automated tests run to confirm that everything is working as expected. If a test fails, jump on it quickly and get the build back to green. Simple right? But what happens when something goes wrong in a way that can’t be fixed quickly? For example, the build server has a hardware fault or runs out of disk space.