News and some cool links

I visited ngMelb a week or two ago and had some fun hot-seating on an AngularJS directive example.

I’ve agreed to give a talk at the next one in about a month’s time. I’m not sure what I’ll talk about yet, but I’m pretty excited to share and get feedback on whatever it is!

And some links:

What we’ve been working on – a parallax library

I guess this counts as a quick update, because I’m not actually going to post any code.

Lately we’ve been working on a parallax scroll website for a client of ours. The most similar one to the design we’re working on is victoriabeckham.landrover.com/INT

Anyway, it turns out there aren’t many good libraries out their for facilitating the scroll workflow, so we wrote our own! (Later we found skrollr, which is similar, but has a different design philosophy with different trade-offs.)

Here are some of the essentials of what we’ve done:

  • Works in FF 4+, Chrome, Safari, iOS and Android. IE9+ is solid but we haven’t finished on IE8 yet. Will test in Opera soon.
  • Does its best to ensure everything is graphics accelerated. It’s pumping at 60fps on my machine in Chrome Canary.
  • Scroll effects are specified separately to the CSS and the HTML; you attach a ‘scroll behaviour’ to an element, which is analogous to a CSS class, and the effects corresponding to that behaviour are in their own file
  • It has a neat way of sequencing effects, mentioned below.

[Read more...]

Fat model, thin controller, sensible view

Just thought I’d push out a quick thought. This is one of my guiding philosophies for software development, HT to the brilliant Arlen Cuss for introducing me to the idea. It applies any time your code follows even a loose MVC structure:

  • Put lots of code in the model
  • Put very, very little code in the controller – just enough to connect the model and view
  • Put as much code in the view as is needed

The idea is that business logic should be centralised into the model as much as possible. Controllers should have essentially no knowledge of the business logic. Views obviously need to know some business logic – they can’t be totally generic.

Most programmers instead try thin model, fat controller, thin view. But it doesn’t really work: the view can’t stay thin if the user interface is genuinely complex, and you end up with duplicated code in many controllers.

Anyway, I’ll probably expand on this later – it ties in deeply to mgnb software’s development philosophy – so stay tuned for more!

Introducing: Taskello

First up, if you don’t already know what Trello is, you need to go there and find out. We use it every day.

We were have a problem at mgnb software: we manage many projects for many clients using Trello, and often need to context shift between projects. Trello helps us collaborate and keep track of tasks within each project, but there is no way to create a single task list out of many Trello boards.

Enter: Taskello. I wrote it to provide a task list that you build out of Trello cards. You just log in, connect to your Trello account, and then you can drag cards from your Trello boards into your task list. When you’re done, just drag the card back into Trello.

It certainly needs a lot of work (we’re not completely happy with the workflow), but it fills the gap we had. Plus, it gave a nice test case for an no-backend app: Taskello is written in AngularJS and uses Firebase for data storage. Later I’ll write another post about some of the technical challenges

AngularJS-large

Report from the coal mines: quick notes about AngularJS

In short:

  • Behaviours provide a good way to sequester of DOM manipulation code, and I know they can be composed, but it’s immediately obvious how to connect them together
  • The view syntax is great because it’s just HTML. Would love to be able to compile a page on a server a-la Meteor.
  • Inheriting scopes work well because they run in parallel to the DOM inheritance.
  • They nailed controllers and dependency injection.
  • Services are a free-for-all and could use some structure. Using a library like Backbone is not acceptable because it doesn’t take enough advantage of two-way data binding and updates. Promises are hard to use, too. The example on the website all just make a REST call every time a controller is loaded, which is suboptimal. Tried to address it with my library at https://github.com/mbertolacci/angular-service-utilities