Page 1 of 2
For the first cut at automating my JavaScript unit testing, I started running them from the command line via PhantomJS. PhantomJS is a headless browser so it will render my HTML & CSS and execute the JavaScript, but will not display it on the screen. The steps I followed were:
I installed phantomjs from here using homebrew brew install phantomjs.
I got the command for running Phantom.js here.
I found the default output from Phantom.js to be lacking in detail. I came across a good link here which shows how to add stack traces on failure and how to add colours to the output using a console reporter.
In future, I'd like to add this to a build system which will run jshint on my code and also do whatever minfication/optimizations are needed. It's looking like Grunt is a good tool for this so will investigate that further.
→ posted on July 10, 2013development
There's been a lot of blog posts from developers recently about the problems with iCloud syncing. The Verge has a great summary here. There are quite a few who are removing iCloud from their products and going with other syncing options such as Dropbox.
The impression I get from these discussions is that it's the reliability of iCloud that's the problem, i.e. if iCloud was rock solid then it would be a great option for your app. I disagree with this view and I think the design of iCloud is fundamentally flawed.
I think that even if iCloud Database syncing was perfectly reliable, it would still be a bad way of syncing data. One conclusion I've drawn from looking at web backends and Rails in particular, is that iCloud is only useful if you want to stick to Apple devices. There is no way to get at this data outside of iOS or OS X. In particular it is impossible to access this from a web application. For this reason, I think it's vital to have a proper backend if you are storing data in the cloud.
The other mode of iCloud syncing is the Document based syncing. The issue I have with this is that anything stored in iCloud is restricted to the application that created it. This is a major issue when an application stores data in a common file format (e.g. plain text or image formats such as PNG or JPEG) that you may expect to be able to use in another application. Dropbox is a far superior solution in this case. I feel much more confident in the apps which use this over iCloud, as I will always have access to the data files.
The other day, Brent Simmons posted a great proposal for an Apple backend service. They really need to do something here as their competitors aren't standing still. Microsoft is on the right track here with Azure and similarly Amazon's cloud computing services are going from strength to strength. It will be interesting to see if anything will be announced for iCloud at WWDC.
→ posted on June 4, 2013development
I recently tried implementing a JavaScript project at work using the testing methods I've learned from the Destroy All Software Screencast. It ended up being some of the best code I've written. The interfaces grew neatly, it wasn't not over designed and it was completely covered by tests. It's the project that I have the most confidence in its correctnesss. It's nice to know that despite any modifications in future, as long as all the tests pass it will pretty much always work first time.
Anywhere I've worked up to now, testing was always seen as something that you implemented after the fact. Code coverage was the main driver of the testing. However this approach completely misses the input that TDD has on the design of the application. By writing applications so that they can be tested easily, they turn out to be much better designed. They are less coupled and all the dependencies are visible. Having the design emerge from the growing system is better than imposing over elaborate architecture and patterns top down.
I found a couple of good resources recently on testing and the impact it has on your code. This is a good talk by Michael Feathers on the synergy between testing and design. He shows how testing problems are indicative of design problems. Misko Hevery's site has some great presentations and resources on how to design code that is testable.
→ posted on May 22, 2013development
Last year, the project I was working on at work switched languages for its UI code from C++ to HTML and JavaScript. For me, this meant learning JavaScript and web development.
When I was in college, we studied Java as the "proper" programming language and barely covered JavaScript - only as part of a HTML course. Back then, I never really saw it as anything more than a language for adding simple dynamic features to a web page. However ten years later, and (hopefully!) knowing a great deal more about programming, my opinions have changed. Now, I have a whole new respect for JavaScript, based on features that I wouldn't have been able to really comprehend back then.
I love the power that first class functions and closures give you. It's spoiled me as a programmer as I'm finding it hard going back to languages without those features! I know that they are coming, or have recently come, to Java and C++. However given the nature of exising legacy codebases in those languages and that projects may be restricted to earlier compilers, it'll be a while before they're mainstream.
There are no shortage of in-depth JavaScript books and tutorials which teach all the features of the language. However learning JavaScript syntax and features is not the problem. The real issue is knowing what features to avoid. Unfortunately it's incredibly easy to write unmaintainable code in JavaScript if you're not careful. Luckily there are some very good books written on this topic. The ones I recommend are:
→ posted on May 5, 2013javaScriptdevelopment
I spent a lot of time in my childhood and early twenties traveling on the Irish Rail Network. Mostly this seemed to involve waiting for ages at Limerick Junction or barely finding a space to stand on a packed train from Dublin. Those experiences didn't exactly leave me with a great impression of Iarnród Éireann.
Given this, I was amazed to find out recently, that Iarnród Éireann have an XML API for accessing realtime data about the trains running on their network. Credit where credit is due, this is an excellent idea and I wish more companies would implement something similar.
The API provides functionality for getting a list of the stations and what trains are due at those stations in the next ninety minutes. It also gives a list of all trains active on the network. It can filter by DART, Suburban or Mainline trains (that leaves some trains in an 'other' category - I'm not too sure what these actually are).
I used this API as part of a Backbone learning project. It was quite fun to do. The API returns latitude and longitude coordinates for each station and train, allowing them to be plotted on a Google Map widget. I never realised there were so many stations in Ireland until I saw them plotted on the map.
One issue I ran into was testing the application with live data. Given that I was programming this at night after work, you'd soon reach a time when there are very few trains left on the network!
One technical detail about the API is that it is in XML rather than JSON. This means that I can't use Ajax or JSONP to get the data, due to the same origin policy. Instead I had to bounce the results through YQL. YQL exposes a SQL like interface to web data. I'm only using a basic 'select all' query here but looking at their site you can do lots of cool and complex stuff. I found a good tutorial from Cypress North on how to use YQL in your code to consume an XML API.
→ posted on April 23, 2013development
I found this talk by Uncle Bob Martin to be really enjoyable and thought provoking. In it he talks about decoupling your application from the database and the web. It's ostensibly a Rails talk but I think it applies to every language.
It really crystalized the issues I've been having with developing Objective-C applications i.e. the intermixing of the database (specifically Core Data) and UI code. After viewing this, I was able to come to iOS development with a whole new perspective. It's so much clearer to me now how to architect applications, where code belongs and what interfaces are needed. After completely separating Core Data and UI code, the whole application has gotten a lot simpler and is much easier to unit test.
It also introduced me to Alistair Cockburn's Hexagonal Architecture. This is a really nice architecture for isolating the application from external entities such as the GUI or database. I've seen this crop up more and more on various Rails blogs under the term 'Hexagonal Rails'.
As a reference, here and here are a couple of other links from Bob Martin's blog talking about "clean architecture".
→ posted on April 17, 2013architecture
I've been working on a side project for the last month in order to learn about front-end web development. While not complete by any means, I think it's good enough to release as a beta. I plan to add features, improve the UI and refactor the code in future.
The motivation behind it was that I wanted to do a project using one of the JavaScript MVC Frameworks - for this one I chose Backbone. Also I'll be working more with HTML and CSS in work over the coming year and I need to ramp up on these.
Iarnród Éireann (the Irish Rail company) has a REST API which provides details of the stations in its network and the current status of its trains. My webpage plots these stations and trains on a Google Map and shows upcoming train information for each station.
I plan to write a series of posts on how I implemented this and the lessons I learned along the way.
The project is available here and the code is available on Github under the MIT licence. The roadmap.md document is where I'm tracking future work that needs to be done on the project. Any feedback would be much appreciated.
As far as the code goes:
→ posted on March 18, 2013projects
One of the things to learn about iOS is the MVC model. The Cocoa implementation of MVC has some differences compared to the traditional approach. For example, in Cocoa, views are not aware of the models and don't listen for model updates. Instead the all events pass through the controller, i.e. it listens for model changes and then tells the view to update itself.
In Rails, the constant refrain is that controllers should be thin. However on iOS they seem to be absolutely huge. One joke that I saw on Twitter was that on iOS, MVC stood for Massive View Controller. For example, the Recipe sample application from Apple has controllers with hundreds of lines of code with one topping out at 600 LOC.
One of my issues with these view controllers is that they don't follow the Single Responsibility Principle, but instead combine multiple functions. They act as delegates for multiple protocols e.g. table data source, fetched results controller delegate etc. I find it hard to distinguish the separate elements of MVC when one class is doing everything. Also in Objective C, once everything is in the same file, it's not obvious to which protocol an item belongs. I think this risks breaking the MVC boundaries. For example, during a refactor, if you're not careful, you can easily get model variables depending on controller variables and vice-versa.
I'd much prefer it if these controllers were split out into lots of different classes, each with a single job as per the SRP. This would lead to a more composition-based rather than inheritance-based codebase. I also think that this greatly helps with code navigation. Jumping to a small, focused file has the effect of filtering out irrelevant code. I've started using Sublime Text recently and it has great functionality for navigating between files, so I prefer having lots of smaller files rather than a few large monolithic classes.
(On a side note this is one thing that really annoys me about XCode. Given a properly nested folder structure with well named files, I think it becomes a lot easier to find your way around the app. For example even after only a few weeks learning Rails, I know exactly where to look to find the controllers, models, db code etc. But XCode is a disaster here. It doesn't push the groupings made in the app on to the file system underneath. It requires duplicate effort of organising the code both inside and outside the application to keep the codebase properly organised.)
→ posted on March 17, 2013development
I recently subscribed to Gary Bernhardt's Destroy All Software screencasts. I found these absolutely fantastic. There are only about ten to fifteen minutes each in length so it's no hassle to find the time to watch them. However they cover a lot in the short time.
They are mostly Ruby and in particular Rails focused but the topics are applicable to any software programming. For example, I've really learned a great deal about TDD from watching this.
The Github archive is useful, especially the Suck/Rocks Rails app. His Git config file is also really handy and I really like his log formatting. I would have liked to see him post a larger sample Rails app to Github (or for the ultimate in wishful thinking - the code for the Destroy All Software site). It would expand upon how his ideas work when confronted with the complexity and messiness of a real world system.
Overall I highly recommend the series for any programmer regardless of what language you are using. Unfortunately I believe he's stopping soon but you get access to the entire back catalog with a subscription and they're well worth it.
→ posted on February 27, 2013development
It's been a year, give or take, since I started looking into iOS development, and I wanted to write a post to reflect on where I am and what are the next steps.
Progress on iOS to Date
I spent the first three months of the year learning Objective C and hacking on some small programs.
I spent some time experimenting with Core Data and MVC and trying to get an automated testing system up and running.
The summer months were quiet due to work commitments. The project I was working on switched to JavaScript which I hadn't really used before. Due to this, I spent a lot of time learning JavaScript and web frontend and backend development.
After the summer I came back to the app with a better understanding of MVC as implemented in iOS and Core Data and I started working on it again. I read up on TDD and started implemented tests using Cucumber and Calabash. That took me up to about October.
Work has stalled on it since then due to a combination of real life commitments from both family life and work. And also Skyrim! Curse you Skyrim and the hours I sank into it :)
Current Status
Here's where I am currently
App work: I didn't get as much done as I had planned at the start of last year. I got diverted in other areas, namely:
Testing - TDD & BDD: I hadn't planned to look at any of this but ended up spending a lot of time here and learning a great deal. Familiarizing myself with this way of programming was probably the biggest benefit I gained from the last years experimentation. I probably could have completed the app if I didn't spend so much time on TDD and tinkering with automated testing setups on Jenkins. However I wouldn't have learned anywhere near as much about proper programming techniques if I did.
JavaScript: I spent a good deal of time learning proper JavaScript development. The basic syntax is very similar to Java which I already knew. However I wanted to learn how to program using JavaScript correctly i.e. modular code using RequireJS, TDD using Jasmine etc.
Ruby and Rails: again I had not planned on researching any of this but I got interested in it while looking at JavaScript. Have done a few tutorials and would like to write a Rails app at some stage.
I spent a lot of time over the last year becoming proficient in web app and backend development in JavaScript for a work project. I've been really enjoying this. My only previous experience of JavaScript and web development was back in college around 2000 and I wasn't too taken with it compared to Java and C development. But looking at it now and in combination with backends like Rails, I've been really impressed. I'm kind of kicking myself for tuning out on what was happening in web development over the past decade. I plan to branch out and do some posts on what I used to ramp up on this.
On the iOS front I feel that I have a good knowledge of Objective C. However the issue is finding time to finish the app. Any time I was able to set aside a sizable chunk of time I got a lot done but getting that time is the key.
Reflections
I think working on this side project has made me expand my horizons more as a developer. I couldn't have predicted the areas that I would have become interested in at the start of last year. I don't think it's a coincidence that as I've started looking at more stuff outside of work, that my work projects have become more interesting. I feel like I'm able to bring so much more to a project now especially in the areas of TDD and design.
Admittedly I haven't pursued the iOS work 100%, but I feel that the other languages I've been exposed to compensate for that. I think it was better to start out with iOS and then divert into other topics rather than not do any side work at all.
However at the end of the day the reality is that I haven't shipped anything on iOS yet. I've been justifying this to myself by claiming all these other intangible benefits. Given what I've learned, I don't think that I've wasted my time but still I'd like to get some iOS project finished. Unfortunately given my current life and work commitments I probably won't have time to work on it over the next three months. In the meantime, I'll post about my JavaScript and TDD experiences.
As regards the blog, looking back I am happy enough with what was posted in the past year. The main thing I'm not happy with is the regularity of the postings. The same things that have stopped me doing much software work, have also stopped me publishing much. In future I want to maintain a more regular posting rate. I aim to post at least once a fortnight and hopefully once a week.
→ posted on February 23, 2013development