Jeremy Paxman recently wrote an article criticising open plan offices. They have been a bugbear of mine for a while also. My working life has been spent in open offices or cubicles (never hot desking thank God) and they're terrible compared to proper offices. Background noise, air-con issues, lack of privacy and personal space are just some of the issues.
Paxman's article put me in mind of a TV series which featured a lot of open plan offices. This was the Brits who Built the Modern World series on the BBC which detailed the work of the architects such as Norman Foster and Richard Rogers, who were the pioneers of High Tech Architecture. It's an excellent series and I highly recommend it. The buildings shown typically had a fantastic exterior with really distinctive features. I was really impressed with the level of quality and inventiveness that went into these structures.
However the interiors of these buildings were typically vast open office spaces. The inventiveness that characterized the outsides, had completely vanished when it came to fitting out the inside. Bog-standard, modular office furniture. was the norm. One of the best examples was Norman Foster's Willis Building in Ipswich. This has a stunning exterior of dark glass panels and a rooftop garden, all combined with a soul-destroying, open plan interior.
The really odd thing for me was that the architects really bought into the open office ideals. They truly thought that this was the best way to design a workplace. I would have loved to have seen what they could have done, if they had put the effort in to design proper working spaces which combined private, focused space along with collaborative areas. They thought they were designing workplaces which were more efficient and collaborative, but to my mind all they succeeded in doing was creating an environment where everyone is distracted and disrupted most the time. It's a real pity and a waste of their talents.
PS Let's hope no-one ever interviewing me for a job in an open plan office reads this :)
→ posted on December 9, 2014development
My current project at work is a large scale Backbone application. The company had no prior experience in web programming before this project and was mainly used to programming in Java. So in order to staff up the project, we needed some way of converting our Java programmers into Backbone programmers.
To do this we looked at the various training materials available on the web. There are a number of excellent resources out there, such as Addy Osmani's book, the MVC Todo app and the Backbone docs themselves. We wanted to develop a selection of documentation/training materials that we could hand to a new member of the team to get them up to speed.
One of the newer books that we've looked at is Beginning Backbone by James Sugrue. Disclosure: I've previously worked on the same team as James for two years at my current company.
The book begins with a good introduction and overview of Backbone from an architectural point of view and gives examples of companies who have built products on Backbone. I liked this approach, as it's one thing explaining why you should use Backbone from a coding perspective but it's also nice to be able to justify the choice from a risk perspective to management. Having concrete examples of successful companies helps us make that case.
Each of the components of Backbone is dealt with comprehensively. The models, collections, views, events and router are explained with plenty of examples. Templating described alongside the views using both Handlebars and Mustache.
After the introduction we get a walkthrough of how to create an application. The application is surprisingly comprehensive. It's a Twitter clone and not the standard todo app. It deals with linking models to views, reusing views, and how to tie it together with events.
From there the book branches out to cover the wider Backbone ecosystem. Backbone is not an all encompassing framework. In fact it quite a simple framework with a lot of scope for customisation. It is a foundation upon which you will layer many plugins and libraries, and so understanding what additional addons are available and how to use them is vital to getting the most out of Backbone.
The book covers
We had started coding well before the book was written and a lot of the choices we had made on Backbone plugins are mentioned in the book. It was nice to get some validation of those choices. In addition reading this section of the book prompted us to look at introducing view models to our code.
One of the problems we had was that it's easy to see how a simple todo application can be built from Backbone, but it's harder to extrapolate from there and design how a larger application should hang together. We encountered problems at scale e.g. managing views and their resources when having high double digit numbers of views and templates. The book introduces two plugins - Marionette and Thorax - which extend Backbone to give more comprehensive view management. Even if the specific plugins described in the book are not for you, at least you will be made aware of the issues that await in the future.
The formatting of the code samples is off in quite a few places. The indentation is out and there are some spaces missing turning
var myarray into
varmyarray. These are more than just code formatting errors - these would lead to compile errors in the code. There is a Github repository of the code samples in the book though, which partially makes up for this.
→ posted on October 2, 2014
For the past year and a half, my team at work have been using TypeScript to implement a large single page application in Backbone. We're over three quarters of the way through the project, closing in our our first release and here are my thoughts on using TypeScript to date.
Reasons for choosing TypeScript
The company has settled on TypeScript for web programming due to a number of factors.
Firstly is the additional security/peace of mind provided by type checking. For example, this prevents a lot of mistakes in calling functions with the wrong parameters. It makes some refactorings easier, as the compiler can tell you when you're calling functions that no longer exist or are passing the wrong types to a function.
A nice feature is that TypeScript has support for implicit interfaces. The compiler will figure out if a class implements an interface rather than requiring that the class declares a list of implements X clauses in its definition. This reduces the friction of dealing with the type system.
Better tooling. The idea behind this was that, given that TypeScript has a proper type system, this would allow better tooling such as Intellisense. The theory was that programming in TypeScript would be a better experience because the IDE would be better.
As an aside, I would question the value of Intellisense and the type of code it leads to. Take Java for example. When you combine Intellisense with modern IDEs' ability to automatically import files, you greatly lower the barrier to coupling. It is no problem to include remote files, grab the inevitable Singleton instance, and execute large Law of Demeter busting method chains on them.
I think Java tools have given the ability to create larger programs than can be properly maintained.
These features were seen as key to creating a more maintainable source code base especially at large scale.
My Experience with TypeScript
In the end, the code had the same classes with the same class names but the class implementations were far more readable due to the OO nature of TypeScript and the ability to define and program to interfaces.
When we started on TypeScript it was version 0.8. The compiler was a bit rough then and crashed on some invalid input rather than reporting errors. It has been steadily improved since then and version 1.0 is perfectly fine for us, reporting the correct errors for all the previously crashing cases. Also the language has been added to and improved over time.
Things I didn't like about TypeScript
Continuing with the last point, with some TypeScript features, you need to know what type of code was generated e.g. did a variable assignment get generated in the constructor or on the prototype. For example, this is necessary when integrating with Backbone. Instance variables in TypeScript are not defined on the prototype but instead in the constructor after the call to super. This means that they are not defined by the time the Backbone constructor is called. The Microsoft solution is to put the call to super in the middle of the constructor but this looks wrong to any Java programmer and I could see them inadvertently breaking the code by moving super to the top of the constructor.
TypeScript's support for Generics was almost good but again there are some issues. The main one I ran into is that you can't create a new instance of the generic type e.g. for a generic type T you can't do
var x = new T(). There are ways around this by passing in functions that create objects but the code they lead to is fairly bad.
The idea that types would lead to better tooling didn't pan out for us. Taking IDEs first, I think the main tool that supports TypeScript is Visual Studio. There is also JetBrains' WebStorm. As IDEs go these seem perfectly fine. It's a bit hard for me to evaluate this as I'm not a fan of large IDEs. One issue with these is that, especially in the case of Visual Studio, they require large license fees. I don't like criticising tools on cost issues, as I feel that companies should treat these as a required cost of hiring programmers. Unfortunately, a lot of companies don't, so if I'm required to buy a personal license, I much prefer to buy a license for a tool like Sublime Text.
TypeScript files import other files by means of a reference path at the top of the file. This is almost like Java except unfortunately the compiler does not enforce these, thus requiring them to be manually maintained. This is impossible to get right for a large project. The only essential ones are those for your base classes but if you leave out the others then IDEs have problems locating type declarations. If you have extraneous references that are not technically needed then this can lead to the TypeScript compiler generating invalid code that defines subclasses before their parent classes. When run, these cause runtime exceptions. Not a great situation.
Integration with Third Party Code.
I think there is a large risk in using these, given that they are neither maintained by the library owners in question or by Microsoft themselves. It is problematic to update the libraries as now you have to also update the .d.ts. files. Everything going well, the Definitely Typed version will be updated to the latest version but there are no guarantees. What happens if the maintainer of this repository gets fed up and stops updating the files?
→ posted on September 19, 2014development