Walking into Neal’s Yard at lunchtime. Thinner hair and shorter than TV suggests but genuinely possessing that beautiful, melodic, broadcast voice. In many ways looked more like a nervous office worker. Here for the Coraline opening according to Twitter.
London Zine Symposium
On Sunday I took a trip to the London Zine Symposium in the East End and filled up on a lot of zines, falafel and flapjack. Unfortunately due to other commitments I wasn’t able to spend the whole afternoon there but I was glad to get along to it and enjoyed a lot of what I saw.
The venue was pretty good, a slightly musty workshop-style space that was slightly overcrowded and under-ventilated but with a nice open courtyard and space for a wide variety of stalls. The organisation was also excellent with a lovely programme, a series of talks and a zine in a day effort. I always enjoy having an active, creative element to an event like this and the talks were really welcome as a way of having a bit more depth than just buying zines.
Personally I was looking for what has been happening in the zine scene as I haven’t really been that involved for a couple of years (I have been looking more towards the internet, of which more later) but I was also looking for relatively heavyweight zines that focussed on prose as I have enough poetry, sketchbooks, comics and collage books to last a life time. One thing that immediately struck me is that there is a wave of graphic design sweeping through and in particular screen printing seems to have taken off and people are really good at it.
In terms of content though I was disappointed, I haven’t gone through all my purchases carefully enough but there was very little that I was immediately excited about. The revolution still hasn’t come, grrrls and queers are still upset, girly kitsch is timeless and all the DIY guides still come from America. There was a sense that the topics are the same and in fact the forms are being recycled by a new generation to experience something for themselves. That’s a shame because actually when revitalising and reinventing something like DIY (as an aesthetic) or zines then everything should be up for grabs. It actually felt that a lot of the technology stuff I’ve been doing in the last year (unconferences, Social Innovation Camp) actually feel a lot more radical because they are pushing the boundaries of everything to do with their organisation, running and communication.
Of course things like zines are very broad church or at least should be. The old tensions are still there between the politics, the aesthetics, the purism but there also felt like there was now this tension between the artists and those people capable of organising very high production values and the older lo-fi crowd. It is all nonsense as usual and is probably a good sign as factionalism only occurs in large groups. The marginal tend to have to stick together out of necessity.
One thing that was clear though was that the Internet was often dismissed out of hand. That might seem natural at an event dedicated to physical works but I was disappointed as the next logical transition is to combine on and offline works in a continuum. I am a huge DIY zine fan and I have espoused the importance of the physical zine for a while. I have also been looking at the idea of Constructivism and the mass produced artefact. The photocopied booklet seems to me the logical extension of a lot of those ideas.
However as Internet access becomes more pervasive and the ability to create and host content online becomes less and less mediated it seems against the goals of the culture not to embrace it. The photocopy seems democratic but the truth is that by itself the handmade limited edition is more elitist or ghettoised than the webpage. Valuing the physicality of something is fine, valuing it over the ability to connect to an audience is an ideological limitation. The internet has done more to achieve the creation of communities and the connectedness of individuals than the physical zine has ever managed. We cannot pretend it is the 70s anymore.
For me the event itself showed a good example of how to combine the power of the web to organise and co-ordinate the event with physical tokens of attendance in the form of the programme. I will also be following the reaction to the event online via people’s blogs rather than through the zines. However in six months time the things I have seen and read will go on to form some kind of zine because it is something I still love and a format I feel is still enjoyable.
So what would have excited me? Well having a look at the pages people were creating for the on day zine I think that there is an undue emphasis on the personal or single creator zine currently. I found only one anthology zine (although there may have been two punk collectives who seemed to be creating single collective titles but collections of reviews, gig reports and interviews don’t really have the cohesive editorial content I was looking for) I would have liked a few more. I also would have liked more words, something really text heavy with an emphasis not on impressionist feeling but actually essays and arguments. Things that appeared to engage outside the personal, domestic world.
Things I did like were zines made up of digital camera photos and text messages, I enjoyed the way they reflected both changing creative possibilities but also the way our world is changing. I liked stalls that had a synopsis of the zines they were selling. I liked the artist’s books, but only so far as their cost made it feel difficult to buy something that might have good and bad moments. I liked the collectives who mixed the books with prints, cards and more conventional black and white photocopies.
I also really liked people who were selling their own food and cakes. What an obvious gap in most shows I’ve been to, don’t just sell the recipe booklets! The Symposium t-shirts were pretty cool too. It was a good afternoon and I would have liked a little more time but hopefully there will be another one next year.
Email “too easy”
I was just listening to Jon Ronson’s piece for Radio 4 about how writing to MPs via email is apparently deemed to be irrelevant and that, unsurprisingly the No. 10 Petitions are ignored. The thing that struck me was that it took a while for radio to be adopted as a tool by politicians. Why should it be surprising that the Internet should be viewed with equal suspicion by politicians?
Ultimately, like a lot of technology someone comes along who has grown up with it and uses it instinctively as part of their lives. You have kind of already seen this in the Obama presidential campaign (although far from perfect). You see it with computer games and social networking.
No-one thinks that an MP’s office shouldn’t have a phone or a fax but you wouldn’t send them a telegram. So let the Luddites pour scorn on web constituents, someone else will probably value the votes.
Password Ettiquette
Rules for website passwords vex me greatly. It’s one reason that I actually like OpenId despite all its potential problems. My problems all revolve around what are considered “safe” passwords.
Ever since I encountered the freedom of SSH passwords with their ability to use phrases and sentences as passwords I have been much more acutely aware of the failings of other password schemes. For example I get frustrated when I have to include a number and special character in my password but it cannot be longer than 10 characters. Surely having an 80 character password that I can remember because it has personal resonance is better than a single dictionary word written in l33t.
So I want to propose some rules for passwords that won’t be annoying.
- Allow passwords of near arbitrary length, they are strings after all
- Use complexity checks rather than arbitrary rules; for example many sites insist on a number in a password but accept a string containing only numbers which is less secure than a long string of only characters
- Don’t exclude spaces, punctuation, etc. Sure you may want to exclude newline, tabs and Bell but try to include the widest range of characters possible. Every excluded character should have a good reason for being excluded.
- I think its okay to check passwords against dictionaries and common formats like dates.
- Always explain to the user clearly what was wrong with an invalid password and give them the chance to retry. Don’t use error messages (you know, the ones in red and bold) for this but instead use normal text that explains clearly the requirements of the password and the reason why the password failed. Include examples of valid passwords (which of course can be part of the dictionary check)
- Encourage people to use at multiple words in their passwords. A lot of sites seem to want to push users towards having single words or multiple words mashed together which make it easier for a brute force dictionary attack
Google please adopt a humane markup language
What do Google Pages, Blogger and Google Sites have in common? A rubbish HTML WYSIWYG editor component is what. Using the WordPress editor I am consistently impressed at how good the HTML generated is and how rarely I need to go from the Visual view to the raw HTML.
With Google’s version though you never know when you’re going to be dealing with a set of <br> instead of the paragraphs that you might have thought you were working with. In fact sometimes when the visual editor is going wrong I dread to switch views and find out what has actually been going on behind the scenes.
There are two ironies in this, firstly Google Docs actually has a decent HTML editor dressed up as a word processor. It still suffers from switching between paragraphs and break returns but it is generally pretty good at keeping in the same mode once you’ve manually set it.
The second irony is that I have been using Markdown in both Couch.it and Tumblr and I have to say that while there is some overhead in learning the syntax the truth is that Markdown pretty much gets everything right from a HTML point of view and is much quicker to right than a WYSIWYG component that you have to keep double-checking.
Please Google, if you really cannot cooperate internally to create one HTML editor that does the right thing could we please have an option to use a humane markup language. I don’t mind which one: Textile, Markdown, Wiki Creole – take your pick. Throw a power user a bone!
Let’s hear it for the Groovlets
I am a big fan of Groovlets, the Groovy wrapper around servlets. Although it is theoretically possible to do this with any scripting language Groovlets are definitely the easiest to get working and the most powerful to use quickly, in my experience, as unlike Jython and Jruby you don’t have to deal with the original languages packaging system to get access to templating and data access.
I’ve created a little wiki (and it is quite small currently) to record my experiences of using Groovlets and to provide a few examples that I felt were lacking in the official pages. If you haven’t already seen it you may also want to have a look at my Gant wiki too.
Who hard-coded the VAT?
With the recent change in UK VAT rates there has been an intriguing chance to see which retailers have a decent data model and those who just assumed that VAT would never change.
If you look at your receipt then the companies that have a decent data model will probably just have a very ordinary looking receipt. Maybe if they are showing off then they will have a little message telling you the current rate.
However the companies that have a bad data model will have an additional line on your receipt that reads something like “VAT Discount” that subtracts 2% from your net bill. This means they have happily hardcoded the VAT rate throughout their system in the mistaken belief that it was a constant, like gravity.
In fact, so mild have the economic climes been recently that it seemed a reasonable assumption. I used to work on a retail system and while we did correctly data drive the VAT rates the data model had no way of tracking the change in VAT rate over time. If we changed the standard VAT rate it would also change it for all historical invoices prior to the switchover. For this reason when an invoice line was calculated the VAT also had to be calculated and written at the time order was finalised. It was obscure but the VAT rate was always the current rate and if you wanted to figure out the historical rate applied you had to do the work yourself.
Who would think that such a simple tax would cause such problems? Or allow you to see so much of the internals of big firm’s systems?
Working with Groovy Tests
For my new project Xapper I decided to try and write my tests in Groovy. Previously I had used Groovy scripts to generate data for Java tests but I was curious as to whether it would be easier to write the entire test in Groovy instead of Java.
Overall the experience was a qualified “yes”. When I was initially working with the tests it was possible to invoke them within Eclipse via the GUnit Runner. Trying again with the more recent 1.5.7 plugin, the runner now seems to be the JUnit4 one and it says that it sees no tests, to paraphrase a famous admiral. Without being able to use the runner I ended up running the entire suite via Gant, which was less than ideal, because there is a certain amount of spin-up time compared to using something like RSpec’s spec runner.
I would really like all the major IDEs to get smarter about mixing different languages in the same project. At the moment I think Eclipse is the closest to getting this to work. NetBeans and Intellij have good stories around this but it seems to me to be a real pain to get it working in practice. I want to be able to use Groovy and Java in the same project without having Groovy classes be one of the “final products”. NetBeans use of pre-canned Ant files to build projects is a real pain here.
Despite the pain of running them though I think writing the tests in Groovy is a fantastic idea. It really brought it home to me, how much ceremony there is in conventional Java unit test writing. I felt like my tests improved when I could forget about the type of a result and just assert things about the result.
Since I tend to do TDD it was great to have the test run without having to satisfy the compiler’s demand that methods and classes be there. Instead I was able to work in a Ruby style of backfilling code to satisfy the runtime errors. Now some may regard this a ridiculous technique but it really does allow you to provide a minimum of code to meet the requirement and it does give you the sense that you are making progress as one error after another is squashed.
So why use Groovy rather than JRuby and RSpec (the world’s most enjoyable specification framework)? Well the answer lies in the fact that Groovy is really meant to work with Java. Ruby is a great language and JRuby is a great implementation but Groovy does a better job of dealing with things like annotations and making the most of your existing test libraries.
You also don’t have the same issue of context-switching between different languages. Both Groovy and Scala are similar enough to Java that you can work with them and Java without losing your flow. In Ruby, even simple things like puts versus println can throw you off. Groovy was created to do exactly this kind of job.
If the IDE integration can be sorted out then I don’t see any reason why we should write tests in Java anymore.
Baby Punching or Not Loving Enough
One of things that kind of pisses me off about blogging is that when you discuss something that is inherently your view of a subject, particularly a technical one, the most common comments are: a) have you tried doing something else entirely (yes, but y’know the point of the post was talking about this thing) and b) how can you say X about Y?
The weird thing is that sometimes in the latter case you can say all this positive stuff and what gets commented on is the couple of things you didn’t like. Evanglists or just frothing converts can’t seem to consider that the thing they support is anything less than perfect. I’ve decided to call this Baby Punching. Every parent considers their baby to be the most special thing in existence; any kind of negative feeling is like punching that baby in the face.
These parental feelings are strongest early on when perhaps people are concerned that any kind of negative feedback from early adopters will kill their favourite outright. Which is a ridiculous attitude, feedback from early adopters is a chance to change things before it gets out to the wider public. The truth is that once something is established no-one goes back to look at what the early adopters thought.
Look at Steam, today its an invaluable tool that trys to balance the needs of game developers and gamers. Who remembers how awful it was initially? It was slow, Half-Life 2 took forever to decrypt and authorize and if you didn’t have always-on broadband then it was a pain to play, authorisation for other games was broken. It was not fun. Steam has improved over the years and not because it tried to stomp on the complaints of the early adopters.
So please, just because I don’t think your baby is as perfect as you do, don’t think I’m punching it.
Three Little Mockers
At my last client I got the unusual chance to try three Java mocking frameworks within the same project. The project had started to use EasyMock as the project team felt that Mockito didn’t really have any decent documentation (it does but it’s in the Mockito codebase, not on the Google Code wiki). However as a ThoughtWorks team was working next door there was a strong push to use that.
My personal preference is still for JMock so I also selfishly pushed that into the project to round out the selection. With all three there; we were ready for a Mock Off!
The first distinctive thing is that EasyMock and Mockito can mock concrete classes not just interfaces. The second thing that all three have very different methods of constructing and verifying mocks. EasyMock is record-replay, JMock constructs expectations that are automatically verified by a JUnit runner when the test stops executing, Mockito uses a TestSpy where you can verify what happened to the mock whenever you want.
The record-replay paradigm lead to EasyMock being discarded early on. It has two kinds of problems as far as I was concerned. Firstly you have the feeling of “inside out” where the test is copying the internals of the class under test. Secondly I was confused several times as to what state my mock was in and having to switch the mocks to replay mode felt noisy, particularly where you were setting multiple collaborators in the test (do you switch them to replay once their recording is done or do you record all mocks then switch all of the them to replay?).
Mockito’s easy mocking of concrete classes made it a valuable addition to the toolkit and it does deliver the promised noise free setup and verificiation. However its use of global state was frustrating, particularly in that you can create a compiling use of the API that fails at runtime. If you call verify without a following method then you get an error about illegal use of the framework. Although this is meant to happen in the test that follows the test with the illegal construction, in practice this is hideous pain when the test suite is a non-trivial size. It also meant that a test was appearing to pass when actually nothing was being verified and the error appeared in another pair’s test (the one that implemented the next test) making them think that something was wrong with their code.
Mockito also uses a lot of static imports (which I do have a weaknesses for) but it also means that you have to remember the entry points into the framework.
JMock by comparision to Mockito feels quite verbose, the price for having all that IDE support and a discoverable API is that you have to have a Mockery or two in all your classes and you are defining all your Expectations for the Mockery. There’s no denying that even with the IDE autocomplete you’re doing a lot more typing with JMock. From a lazy programmer point of view you are going to go with Mockito every time.
And that is pretty much what happened in the project. Which I think is a shame. Now in explaining this I am going to go into a bit of ThoughtWorks testing geekery so if you are lazy feel free to go off and use Mockito because the pain I’m talking about will happen in the future not now.
I feel that Mockito is a framework for Test Driven Development and JMock is a framework for Test Driven Design. A lot of times you want the former: tight-deadline work and brownfield work. You want to verify the work you are doing but often design is getting pushed to the sidelines or you actually lack the ability to change the design as you might want. Mockito is great for that.
However Mockito doesn’t let the code speak to you. It takes care of so much of the detail that you often lose feedback on your code. One thing that making you type out your Expectations in JMock does is make you think, really think, about the way your code is collaborating. I think you are much more likely to design your code with JMock because it offers lots of opportunities to refactor. For example if two services are constantly being mocked together then maybe they contain services that are so closely related they should be unified, logically or physically. You don’t see that opportunity for change with Mockito.
By using both JMock and Mockito I was able to see that Mockito did tend to make us a bit lazy and our classes tended to grow fatter in terms of functionality and collaborators because there was no penalty for doing so. I was also concerned that sometimes Mockito’s ability to mock concrete classes meant that sometimes we mocked objects that should have been real or stub implementations.
Mockito is a powerful framework and I suspect that Java developers will take to it as soon as they encounter it. However for genuine Test Driven Design I think Mockito suffocates the code and requires developers with a lot more discipline and design-nous, almost certainly not the people that wanted an easy to use framework in the first place.
Echo One 