Tag Archives: architecture

Lessons Learned

It’s been a while since I have posted here, mostly because we are busy building things at Okta. In the past while I have been building our UI framework and generalizing UI components, and thought I should share some high level bullet points of my experience.

1. You are building a framework

Unless you are building a small website, no matter if you’re using backbone, angular, ember, react, vanilla JS or whatever MVC framework the cool kids are using nowadays, in order to have a consistent user experience, without a significant amount of copy/paste boilerplate code, you need to have a solid framework layer. It’s easy to think (as I have) that “we are focusing on building a great product, not a framework” and it couldn’t be more true. However, in order to build a great product, you need a great framework to support you. The investments we made in our framework turned to be a key component in enabling us to move fast, without compromising quality.

2. Abstracting 3rd party widgets is probably a good idea

No matter how stable and mature your 3rd party dependencies are, and how great the developers are, APIs change. By abstracting external dependencies you gain the flexibility of upgrading even a major version, without refactoring a large amount of code. The best way to avoid major refactoring when that happens, (or to get stuck on an older version), is to have your own internal layer of abstraction around it. After all, it’s a know fact that all problems in computer science can be solved by another layer of abstraction except for the problem of too many layers of abstraction.

3. Documentation and code review help spreading the word

It’s really awesome to be generalizing code and writing frameworks around common patterns, but it doesn’t help a lot if the other developers in your org are not aware of it. We’ve found that the combination of code review, and a centric doc site help a lot with training and exposing what features are available. A rotation between developers to help extending the framework is a win win as well: developers get to better know the framework and it’s internals, while the framework gets more contributions.

4. Tests are crucial to success

As any large software application, it would have been impossible to maintain our application without a good amount of tests which validate that:

  • The code does what you think it does
  • Side effects are easier to catch.
  • Future development can be done (in less horror)

Our UIs have proven to be incredibly stable when it comes to regressions, and this is mostly due to our investment in unit tests and end-to-end tests.

5. Cleaning up after generalizing is a good idea

Typically, we decide to generalize a pattern after we are sure we will use it more than once. This way we can assure we are generalizing the right thing, and not what we assume is the right thing. In order to keep the codebase clean and honest, its important to go back to the previous implementations and apply the new pattern. This solves two main problem:

  • It assures that we correctly solved the problem
  • It assures that the next developer running into the same problem will not copy/paste an obsolete/one-off solution

6. You are, by definition, writing tomorrow’s legacy code

It’s impossible follow trends and rewrite your whole application using the new shiny framework that pops up every other week (Heck, The angular 1.x app you wrote last year is considered legacy code today). Instead, we focus on choosing tools that promotes practices we have learned to be useful, with current technology. With the pace the industry is moving forward, future challenges are likely to be along the line of “how to stay current”. There’s no answer to that challenge, but modularity has to be a key component.

If you want to be working with a company which faces these sort of challenges, We are hiring!

Keep it Simple, Stupid!

Keep it Simple, Stupid!A while back I wrote a blog post on coupling and the observer pattern. Looking back, I did a pretty poor job describing what it wrong about it. I will attempt to correct this.

We all want simple and descriptive code. Code that is self documented. Code that makes sense, Code that tells us a story. Lets look at a kind of code I have seen many times, in many different variations, using observer based asynchronous javascript code:

 
var ListView = {
  init: function() {
    this.feed.onItemsReady(this.onFeedItemsReady);
  },
  onFeedItemsReady: function(items){
    // do something
  }
  // ...
}

At first, this looks descriptive, and it is, kinda. It’s an object describing the implementation of a publisher it is observing.
That doesn’t sound right. It is telling us about the implementation details and why it is doing things rather than what this object is responsible for and what it is doing. We already know all that!
Continue reading

3 Tips For Writing Better Backbone Views

Backbone
One of the good things about Backbone.js is it doesn’t tell us how to do things. It leaves it for us to decide what are the best practices for writing views (or any components).
This is also one of the worst things about Backbone. it makes it almost too easy to take the wrong path, and write views that will be hard to maintain.
The principle we should follow when writing a view is to keep it encapsulated, and keep it as “dumb” as possible – a view should know only the bare minimum it needs to know in order to do it’s job, and do bare minimum it has to do.

Here are 3 simple tips that can help us achieve this:
Continue reading

PubSub / Observer Pattern and Coupling

PubSub (or the observer pattern) is obviously the hottest pattern in client side development, and I would like to take a shot at trying to refine the best practices for using it in a flexible and robust way.

The definition provided in the original Gang of Four book on Design Patterns states:

“Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically”

As in any design pattern, an important part is to keep the application loosely coupled and with high cohesion.
Continue reading

Reinventing the Wheel

I ran into this old post by Jeff Atwood, that makes a good point. Reinventing the wheel is most probably the best way to learn about “wheels”, and about the problems they designed to solve.
There is no better way to learn about anything than actually implementing it.

However, consider a project that, say, 3 engineers are working on, and each one of them reinvents a different “wheel”?
Here’s what will happen:

  • Engineer #1 will write a HTTP server
  • Engineer #2 will write a RoR like backend MVC framework
  • Engineer #3 will write a jQuery like dom abstraction JS library

You see where this is getting…
There are at least two main problems here:

  1. This project will probably be buggy, will take forever to develop, and will be impossible to maintain.
  2. The next engineer coming after you, is more likely to have experience with jQuery than in your home brewed fooQuery.js and will probably have more desire to gain expertise with jQuery over your amazing home brewed library.

Basically the more code we own, the more liability we have to maintain, test, debug, fix, improve, write documentation etc.
Given the limited resources we all have, the last thing we need is to own more code.

This is especially true when all the above problems are already solved with efficient, fully tested, fully documented open source projects we can use. for free. with communities and all the other good stuff that comes with open source projects.

This is exactly the reason why engineers should own or participate in pet projects.
A pet project is the perfect place where its not only okay to reinvent the wheel – it is desired — this is exactly the room to do crazy things, experiment, learn, and develop your professional skills.

Software Engineering Interview Questions

Edit, 6/26/2012:
This post is my personal rant about interview questions. If you got here looking for actual programming interview questions, I can recommend these books: Cracking the Coding Interview and Programming Interviews Exposed. These books helped many engineers getting their dream jobs.

It’s no secret I’ve been in a lot of interviews in the past couple of years, both as an interviewer and as a candidate. When it comes to tech interview questions, to simplify things, I can break it into 3 major types:

  1. Implementation questions
  2. Architecture/design questions
  3. “Problem solving” questions

The first type intends to check your experience with current industry standard tools. For instance, as a javascript engineer you will be asked about specific jQuery method, what problem it designed to solve, and how you can effectively use it, how a web browser works, or what is the HTTP protocol.

The second type intends to check your software design skills, and your ability to design a complex application. As a front end engineer, you will probably asked about MVC concepts, RESTful architecture, or design patterns.

The third type intends to check how well you handle with random problems you didn’t expect. However, in many cases, this part is a tricky, and mostly out of scope.
It’s not that I don’t think a good engineer should have strong “problem solving” skills. I do.
I just think most of these “problems” you are being asked about has nothing to do with what most of us actually do on a daily basis.

In my past interviews I was asked algorithmic questions, mathematical/geometry questions and physics questions. Hell, I’m surprised I wasn’t asked to solve rocket science problems. After all, my “problem solving skills” are being measured.
Continue reading

Book Review: RESTful Web Services

 I’m working on a project that includes writing a client for a fairly sophisticated RESTful API.

To get some better understanding of both client and server RESTful philosophy I purchased and read RESTful Web Services by Leonard Richardson, Sam Ruby (O’Reilly Media, 2008).

I tend to agree with the foreword by David Heinemeier Hansson: “Every developer working with the Web needs to read this book.”

The web is RESTful and therefor, when working with the web one shall at least understand RESTful concepts.

This book is doing a great job describing to details the concepts of addressability, statelessness, connectedness, and the uniform interface, and clarifying why they are important fundamentals of the web.
It gives a great overview of HTTP, URIs, Design of a REST server and client.

If I had to take one thing from the book, I would take the importance of state management.
It is crucial to understand where the state of the application belongs to.
Saving the application state on the back-end breaks the stateless nature of a web app, and could end up with an application that is hard to maintain and scale.
Keeping the state in the client side (or even better – in the URI), and keeping a sane, loosely coupled design leads to scalable web application.

One thing I was not very impressed with are the code examples.
I skipped most of them, since I didn’t buy this book to learn how to implement a REST server using RoR or Django, but choosing XHTML as the document format is very odd, and using a <div> or a <span> to represent semantic data is even odder.
Calling HTML5 XHTML5 is annoying, but given this was published in 2008 I given it the benefit of the doubt.

Bottom line, this was a good read and I highly recommend it.
If you are looking for a book to give you some detail oriented overview of REST concepts, this book is for you.