We’re at the first day of QCon London 2013. It’s big. The opening keynote was attended by a couple of thousands and there’s an iPhone app. A mixed bag of talks and some great people and suppliers to meet. I can’t believe it’s gone so quick, here’s the summary so far:
From Richard Chamberlain:
A UI developer reports on experiences working in a bank – Horia Dragomir
Put a UI Developer in a Bank; See what happens
A lot of negativity on the subject, but ending up getting around to some good points. A lot of them mirror Caplin’s experience at some prospective customers.
Banks have top developers
The talk starts off by saying developers at banks are very clever, have amazing domain knowledge and know how to architect incredibly complex apps. Banks are now valuing good User Experience, however typically little is done to foster a good working environment for UI developers. Some of my notes follow, most of them aren’t rocket surgery!
If you want a good UX you need to hire a good UI developer
Definitely don’t hire or repurpose .Net or Java developers as is often the case. Hiring an agency or a company like ours to give you a kick-ass UX up front is a great idea, but release on release you need to evolve your design and having someone in-house long term is a must
Build apps for your customers
Rather than to please managers. Banks often seem to be very hierarchical and people often value senior employees opinions over user feedback
Huge release cycles for teams providing services for your apps are a pain
If you need some data through an API that is being developed and it’s not quite right and also on a 6 month release cycle then any release can make or break your app. Smaller release cycles and close communication are key to getting the services you want.
QA need to work with the team and not to the spec
Horia recounted the time QA pointed out one experience when QA got another developer to “correct” his code as it didn’t match the spec. He had actually evolved the design with customer feedback.
Tools and equipment
There’s little point in developing a web application if you don’t have firefox and chrome installed. Your web devs need to test on all versions of browsers and all the devices they are going to support. They also need an IDE that isn’t eclipse or visual studio. They will also need stackoverflow to google for weird IE work-arounds. Another story here of how he had to go into a mobile phone shop to test his app!
Scaling Mongo DB – Alvin Richards
Scaling for Humongous amounts of data with MongoDB
Before this talk I was skeptical about NOSQL databases in a production environment. Alvin showed off some good features of mongoDB that makes it something to investigate further. Auto-sharding and balancing of data between shards is a cool feature. Also the theory of “don’t love each piece of data equally” was good. With mongoDB you can specify when writing how much replication your data needs to have until you consider the operation complete.
Non-important data can just be written to memory on the primary server, with mustn’t lose data you can specify that the data needs to be replicated to a secondary server in a different data centre before it’s complete. This increases latency, but you’re pretty sure you won’t lose it. This is available via the insert API.
From Mike Salsbury:
Keynote: The power of abstraction – Barbara Liskov
Keynote: The power of abstraction
See mural picture posted earlier.
Java EE7 Platform – Arun Gupta
The Java EE 7 Platform: Higher Productivity & Embracing HTML5
I was torn between this talk and the one on Web development: Your doing it wrong. I’ll hopefully catch up with that talk on the podcasts later. The Java EE 7 talk delivered what you’d expect from the title. It covered the upcoming features in Java EE 7.
This included websockets support, and the example showed converting a POJO to a websocket endpoint by adding a couple of annotations and a suitable method. A simple chat application was not much longer. These are attractive demos, but I’m not sure where the mindshare is with websockets by now.
There were also various other feature enhancements with point increments on versions, together with a few major version upgrades for particular APIs.
The talk finished with a plug for the ‘Adopt a JSR’ program.
Testing iOS apps – Graham Lee
This talk came with a health warning at the beginning that it would be Mac centric (really!), and that if your desktop was so locked down you couldn’t install new apps then you probably wouldn’t get much out of it. This situation doesn’t describe our development department, although I can imagine that many bank IT departments may not be so open.
The talk highlighted several different testing frameworks that could be used to test iOS applications and via WebView. The last was probably the most interesting to me, as it highlighted a way of using WebView so that you can utilise your existing JavaScript testing framework to test iOS apps embedded within web views. This isn’t necessarily exactly what we want to do, but could be a very interesting approach for CI.
Another CI friendly approach would be to use Catch, which is available on Github. The other approach was to use the normal embedded tools. E.g. XCUnit and Instruments. Although one twist was downloading the Network Link Conditioner tool to simulate network latency.
Calabash was a BDD style approach using Ruby and the spec approach. That would fit in nicely with some of our other frameworks in style.
Other talks
I also drew a picture in a talk by Fernando Orllana and found out more than i ever needed to know about mobile security, good to see my banking app is *really* secure and that banks are embracing mobile development.
Catching up with Atlassian guys and JFrog was good although I preferred Atlassian as they bought us all beer. Looking forward to tomorrow.
“QA need to work with the team and not to the spec: Horia recounted the time QA pointed out one experience when QA got another developer to “correct” his code as it didn’t match the spec. He had actually evolved the design with customer feedback.”
So the app was updated without an issue being raised, or the tests being updated, or the QA being informed of the change? It sounds like the developer needed to with with the team, not the QA. But perhaps I am a little defensive.
Inevitably products go through change via a process of discovery and customer feed; agile promotes communication as opposed to documentation and contract negotiation – my view is that team members should make every effort to make everyone else aware of the changes they have been asked to make and it should at the very least be updated in whatever tool is being used so that everyone is working to the same goal. This is a very common problem; at one of the places I worked at all change requests had to be channeled to a senior BA who then made the required updates to JIRA and raised stories etc. as required – to me this was a little too process driven but it worked and ensured that the whole team was aligned.
Whoa, not blaming the QA here! QA weren’t in the team – problem #1 !