You are currently browsing the category archive for the ‘Uncategorized’ category.
Seems to me that there are lots of developers out there who have taken up the MVC banner, and charged forth into battle; silently crying out, “MVC! MVC! All apps should be MVC!” Or maybe it’s just me that did that… 
Regardless, over the last few years, lots of people have adopted the MVC design pattern as their pattern of choice. But from what code I’ve seen, especially in the JavaScript world, most of it plain shit as far as following the pattern is concerned.
The most egregious guffaws are confusing object roles in an MVC system. I don’t know how many times I’ve seen objects that cross the Controller-Model or Model-View or View-Controller boundaries; intermingling roles within a single object. Other things I’ve seen are people defining objects to fill a particular role, then do all communication via two-way direct reference between objects. Or worse yet, I recently saw some code where the developer was having a controller make his view trigger an event to which the same view was the only listener! Yikes!
One could just call it stupidity on the part of the developers, but I’ll be more forgiving and say that all that boils down to simple ignorance of how the objects – and more importantly, how objects communicate in any MVC system – should work; or just plain ignorance of what MVC is all about.
The Model-View-Controller paradigm at its most pure is quite simple: It’s all about separation of concerns, and consigning “concerns” to three, specific classes of objects – Model, View and Controller objects. Each class has a specific purpose and role. In this installment, I’m going to talk about each of these classes, and how they should be used to build successful MVC applications.
Model
A Model is an application’s representation of the underlying data set; in other words, it’s data. It has accessor methods in the form of getters and setters to manipulate the data. It does not or should not contain business logic. Unfortunately, some 3rd-party libraries such as Backbone.js muddy the waters a bit by adding things like the “validate” method to allow data validation within the context of the model. I’ve always found this to be just plain wrong. While you certainly can put logic in the model by virtue of JavaScript not having any barriers to doing so, muddying the waters in the model’s role in this respect I believe does more harm than good.
To me validation is really the job of the controller, which should be the one that “owns” the business logic. However, I’m also in favor of placing validation logic in the view to encapsulate it and remove some of the burden from the controller, since validation is really view-specific.
A model’s role is simply to store runtime data. Consumers of the model can get or set attributes on the model. But when that data changes, the model is only responsible to notify listeners that it has changed. To me, that’s it.
View
To me, there are two types of Views: Smart Views and Dumb Views. Smart Views have a bit of logic in them, namely input and output validation logic to make them “smart” per se, but as the endpoint objects – that is, the objects that clients actually “see” – they should never contain core business logic. Actually Smart Views are simply Dumb Views with some validation. Some have argued that a Smart View could also be one that includes Model functionality, but I don’t subscribe to that at all. I think object roles should be distinct, and Views are responsible for presentation of data contained in their associated model. Period. As for “Dumb” views. They simply exist to display model data (and update the model if they’re used for input), and update themselves when the model changes. Pretty straight-forward.
But with any view, I found that following the following rule-of-thumb has saved me countless hours of anguish, and that is simply: A View knows about its DOM and its DOM only. It knows about no other View’s DOM. This is extremely important to consider, especially if you’re using Backbone.js whose views are normally attached to existing HTML elements, and not blitting out their own HTML. When you create a Backbone view and assign its “el,” you have to make sure that no other view – as you can potentially have several views on a page – can manipulate DOM represented by that “el.”
Admittedly, when I was new to Backbone, coming from a system I helped create whose views all contained their own HTML, I broke this rule because hey! jQuery lets you get the reference to any HTML element so long as it’s in the DOM tree. But I ran into a bit of trouble when I had multiple views on a page accessing the same region of the page and using the same el. It was a nightmare to try to maintain. I no longer do that, as I’ve learned that lesson, but mark my words: Your view should only be responsible for a distinct “el.”
Controller
Especially in JavaScript, a Controller is almost superfluous, as it is mostly used as an instantiation device for models and views. But it can carry “safe” business logic; that is, business logic specific to the operation of the application that doesn’t expose trade secrets. It is also used to control application flow. Circling back to Backbone.js, in earlier versions of Backbone, the “router” object was called controller, but was later renamed to router. I think this was a smart move because a router is simply a history manager wrapper. It doesn’t control application flow. That’s the controller’s job.
For instance, I’m currently building an application where I have a master controller that instantiates several sub-controllers representing sub-modules of the application. Based upon user input (a click of a button or a link on a page), the controller decides that module to instantiate and display. It then tells the router to update the route to reflect the “destination” in the browser’s URL. In this respect, I’m using the router simply as a view, as all it does is update the URL, or on the reverse, tells the controller to display the right module or section depending upon what was entered in the URL.
In other words, a controller is responsible for controlling application flow. That’s all it does. It can listen and respond to events in the model and views. It can even trigger events to other controllers. But in no way should it contain data manipulation or view functionality. Leave that to the models and views of the system.
Look, MVC is not rocket science. But it may feel as if it is especially if you’re doing it wrong. And believe me, lots of people are doing it wrong.
In addition to writing this blog, I also write a fairly popular blog called GuitarGear. To write that blog, I interact a lot on various forums, and meet other guitarists. Especially in the forums, there’s lots of debate about which pedal or amp or guitar – what have you – works in a particular situation. Some of the threads go on for several pages. Invariably though, someone will pipe in and say something to the effect of, “Just shut up and play.”
Sometimes I feel like saying this when I’m in meetings with fellow geeks and a side debate starts on some topic; especially on the merits of one technical direction vs. another. In the best of cases, these discussions/debates yield a good direction; actually, in the end, they almost always yield a direction. But invariably, that direction could’ve been arrived at in a much shorter span of time. I think that part of the problem, especially with well-established teams is that everyone’s comfortable with each other. That’s both a good thing and a bad thing. It’s good that you can rely on your work mates, but that comfort can dangerously lead to losing “the edge” of urgency to deliver as you belabor points. The plain fact of the matter is that we have product to build; we shouldn’t be wasting time on trivialities. So shut up and develop!
I read an article today that was published in yesterday’s San Jose Mercury News Business Section written by columnist Chris O’Brien entitled, “Key Job Sector Losing Ground,” describing how growth in science and engineering jobs over the past decade has remained flat relative to previous decades, and kind of being a doomsayer in that that flatness may have an effect on innovation. He does quote a researcher that said that perhaps that flat growth means a lack of demand for science and engineering jobs. Being in software engineering, I would tend to agree with that assessment. But I disagree that that flatness may lead to the possible constriction of innovation.
I think that the flatness is actually a correction of the excesses of the dot-bomb era. Even in 2007, there was a minor uptick in the technology sector, and several companies, including my former company, SuccessFactors, added LOTS of engineers in a very short period of time. Unfortunately, during a boom period, especially in technology, the focus tends to be on putting “butts in seats” quickly as opposed to getting the right butts in the right seats. I saw that at SuccessFactors, where we added lots of really mediocre engineers to our software development team. Most of these “engineers” were the typical, “code-first-think-later” code-monkey types. As a result, in 2008 when the economy soured, the company had to shed that excess and frankly, unneeded baggage.
I’m probably sounding a bit crass and elitist, but honestly, I truly believe that what’s happening with the technology job growth, especially here in Silicon Valley has more to do with companies being careful about choosing the right people to fill their employment needs, and choosing only those whom they feel will take them to the next level.
People talk about jobs being shifted off-shore. To me, it’s natural that they’d go there. Think about the jobs being shifted off-shore. I don’t think I’d be too far off the mark in saying that those are jobs that tend to be more maintenance and production-level types of jobs. The real innovation stays here. Even with my previous company SuccessFactors, despite senior management constantly saying that our engineering group was “global,” and always tried to blur the lines between domestic and offshore development, in reality, all the innovative work took place here in the States; and even new product development offshore followed the models and innovation established domestically. Plus their designs were always subject to approval from the US-based team. So in consideration of that, to me, this “flatness” is not really flatness. I believe it’s shedding the production and maintenance workers, and distilling down to a workforce of innovators here in Silicon Valley.
Call me insensitive, but as opposed to Mr. O’Brien, I’m in the industry, and have experienced the growth and decline of job number from behind the lines. Yes, I realize that I’m opining, but it’s not uneducated and not without experience in the sector.
Here’s a job description I got in my inbox today.
LUCILE PACKARD OF STANFORD MEDICAL CENTER
Sr. UI/Front end Deveoper
Perm, Up to 115K
Top of the Line Benefits
Our client, Lucile Packard Foundation is looking for a permanent UI Developer to join their team immediately on a full-time basis. Please find the responsibilities below and let me know if you might have interest.
Skillset & Requirements:
•7+ years experience developing complex dynamic web applications
•Development and Collaboration w/ both small and large development teams
•Expert knowledge of HTML/XHTML
•Ability to write code without WYSIWYG editor
•Advanced Object Oriented JavaScript
•Experience with JavaScript libraries such as jQuery and DWR
•Practical knowledge of AJAX using JSON
•Proficient in the implementation of Cascading Style Sheets
•Skilled in the use of CSS Selectors
•Competent in Web Design and graphic creation
•Experience w/ WebSphere or WebLogic is a plus
Notice I bolded the “Advanced Object Oriented JavaScript” line. This is the problem that I have with this job requirements list: The very next line mentions jQuery. Every time I see requirements lists like this it almost invariably means that they’re really not doing OOP JavaScript. Oh, they use objects and such, but their actual implementation of OOP tends to be fairly limited. Another problem related to that line is that there is not associated line that requires object oriented analysis and design. Essentially, that shop is doing DOM-level stuff. The effects are cool, but I can tell that the position is pure coding, very little engineering.
Having gone through many interviews in the latter half of last year, when I’ve interviewed with companies who have these kinds of descriptions, invariably, when they post requirements like this, they’re only paying lip-service to actual object-oriented programming. And if they do indeed do OOP, they design by code, which raises a HUGE red flag for me. Only a couple of companies that I interviewed with (one of which I joined) did some level of design, or at least wanted to begin a process that included design. Now by design, I don’t mean visual design, but engineering design, which includes UML diagrams (or industry-standard diagramming), and technical design documents. The best company that I interviewed with up in San Francisco actually spent the better part of the interview grilling me on an object diagram they had me create based upon a set of animals within a fictitious animal kingdom. I had to create the object hierarchy, and also draw out simple sequence diagrams to illustrate the interactions between the animals and their “world.” Very cool stuff, and just about the best interview I had ever gone through.
Unfortunately, a lot of companies just don’t take the time to do real engineering design. Most internet-based companies engage in “agile” development. Gawd I hate that term, mainly because practicing it has been so bastardized. What many organizations just don’t realize is that Agile development requires so much more developer discipline than most engineers are willing to commit. This is exacerbated by pressure from sales and product management to constantly deliver features and the time allotted for delivery just doesn’t allow for taking the time to do design.
As for the last line in the previous paragraph, that’s actually horseshit. In my experience, with good developer discipline, you can actually deliver more in the same amount of time because you don’t waste time flailing around with code. If you discipline yourself to design what you’re going to build, then coding is simply connecting the dots. It may seem counter-intuitive, but I will posit that if you’re not spending at least 60-75% of your development time designing, you’re really not being very productive. Food for thought.
Though I am now employed, the past few months have been illuminating with respect to the interview process. There is so much disparity between what employers are asking for in their job descriptions and what they actually do to evaluate the requirements that they claim they need in candidates. The most interesting thing I’ve run across is a requirement for MVC or object-oriented JavaScript. However, in about 90% of the interviews I’ve had, very little has been discussed with respect to general object-oriented principles, let alone object-oriented JavaScript. In fact, most interviewers simply ask if I know certain MVC frameworks such as “backbone” or “knockout.” When I’ve gotten those questions, though I answer that I am familiar with them, but have never built anything with them, I think to myself that the the interviewer is going to be entirely tactical with the interview, and only brush the surface of OO JavaScript.
I’ll just say it plainly: Just because someone happens to know a particular MVC or OOP framework doesn’t mean they actually understand OOP. No matter what framework you use, OOP is all about design, all about understanding the relationships and interactions between objects. Go ahead and make all the objects you want. But unless you have a clear idea of how they relate and interact, then you run the risk of doing A LOT of extra coding down the line to compensate for your lack of design. Mind you, I’m not just throwing this out as a matter of opinion, I’m coming from a position of experience.
Circling back to the crux of this article, that’s not to say that there haven’t been some great interview questions or exercises that cover OOP. There have been. But one in particular stands out above the rest, and it will be an exercise that I will use going forward. I got this from a great interview with a little company called Urban Mapping with which I interviewed a few weeks back. It was the first time I felt that a company “got it” with respect to object-oriented design. And you know what? The exercise had very little to do with JavaScript. Their thinking behind this exercise is that it’s more important to know the architecture behind what you’re building before you build it. AMEN TO THAT! So without further ado, let’s get into the exercise:
Let’s Build an Animal Kingdom
Given the following animals:
Dog, Cat, Eagle, Duck, Python, Anaconda, Iguana, Salmon, Lungfish, Frog
Build an object hierarchy that can describe this set of animals. After you’re done we’ll discuss. There isn’t necessarily a right or wrong answer to this. But we’re going to take this time to discuss your object-oriented awareness and acuity.
Here’s a possible solution to this hierarchy:
Once they’ve finished the diagram, you get into the application of the design. Note that this is not to be confused with implementation, but rather, providing a context to the design to see if there are any holes in it. But first, some questions:
- What was your reasoning behind building the hierarchy in this way?
- Would there be another way to approach this? (Another possibility would be to break it down by number of legs, but that is actually not optimal based upon the follow-up exercise of creating a world for the animals)
So the context we’ll use is this: Building a world to place the animals. So on the board, draw out an area that has a body of water, some trees, maybe a cloud to represent air, and some rocks. After you’ve drawn it out, then say that we’ll instantiate these animal objects in various places on the board. The idea is to reveal if the design will support the constraints of the environment. If they broke down the hierarchy according to number of legs, they may have missed the functional level. This is something that can be suggested and will almost immediately be revealed once you start going through instantiation.
If they did break it down by function, then chances are they will have missed the multiple inheritance. For instance, an anaconda can be created either in water or on land; same with the dog. You can lead them through this with some questions:
- Is it possible that an animal can be instantiated in different locations? (You’ll especially look to see that the duck can be instantiated as a swimmer, walker, or a flyer). That last bit was a little evil on my part.
- Given that animals can be created in a couple of possible locations, and that there constraints as to where they can be created, where would you place the method that would check for the location? The correct answer would be at the second level, so that those animals that inherit from two parents will inherit the location constraint from both.
Summary
So in this exercise, what are we trying to accomplish?
- The obvious answer is to see if they get object-oriented design at all.
- The second thing this reveals is how well the candidate can communicate and justify their ideas.
- And just as importantly as the other two, this exercise reveals if this person has the ability to work with the team.
Note that this exercise is best done with a couple of people in the room – probably no more than three – especially to address item 3 above.
Based upon my experience on the receiving end, doing this exercise was literally a breath of fresh air. Personally, I wouldn’t pull this on a junior developer, but this is something that I’d definitely use for senior front-end AND back-end developers. Remember, it’s not about the code with this exercise, it’s about the design thinking. Do a separate coding interview following this.
