I’m a modern-day hack: I read a bit, books and online, I mash together chunks of code and frameworks to try and make things work (or break), I like to try things that few have attempted, with pretty decent success. For the longest time I didn’t feel entirely comfortable in my shoes as a “programmer”, meaning that I was writing code, my shit was working, but I felt I never met the generally-accepted criteria of a modern programmer. One of the things that kept me feeling unworthy was my lack of the use of teh “MVC” in my works.

Model-View-Controller

I’m not going to go too far into what MVC is, if you’re reading this, then you already have a good idea already. Besides, there are internets out there to tell you what it is. I’m here to talk about why you should be using it.

The problem with MVC is that it’s misunderstood.

Misunderstood for several reasons:

• because I think the term itself has become a buzzword. To the layperson or aspiring programmer, the concept of MVC is just another term among a slew of catch phrases that one encounters trying to decode the mystery of developing for the web,
• next, it seems every new framework that totes the label ‘MVC’ isn’t really a true representation of the pattern, or else it’s some derivation of MVC that still doesn’t really explain what it is.
• last, MVC can be hard, or at least hard to pick up and understand. Let’s look at an example of that next.

Picking on someone…

Take the Actionscript framework Robotlegs, for example. There are several key components to setting up a project with that framework (have a look at their flow diagram):

• Views
• Mediators
• Context
• Commands
• Actors
• Services

Don’t get me wrong, Robotlegs is a great framework, but it’s no wonder people are confused! Before successfully getting a project off the ground with Robotlegs, I think it took me 2 or 3 attempts to get my head wrapped around the minimal requirements. I mean, in all of this, which one is the Model? Where’s the Controller? There isn’t even a ‘View’ class in Robotlegs.

It felt like pulling teeth to really ‘get it’.

If it’s so crazy, then why use it?

Lots of times when I read about MVC, I see lots of words like “clean code separation”, “visual flexibility”, “better workflow”, etc. I think everyone who has thought about MVC but isn’t using it yet needs that last little bit to really convince them:

MVC is about sanity.

Sanity because and MVC or similar (MVVM, MVCS, MV*) pattern helps you separate your application layers, which, without practice, is hard to do. But without regurgitating all the other buzz words and phrases to try and convince you it’s worth using, let’s make up a new idea about MVC:

Data state representation bindings.

Let me clarify that: bindings that automatically change the interface to represent the state of the data. This means (in the case of a browser
or something similar) that when you click an item, you don’t reach in with your code and change the page or another element on
the page, you change your data instead. And if you have your bindings set up properly (or your framework for that matter), then
the view updates for you. With this kind of setup you can wire as many views to a single piece of data as you want, and in order
to update them all, you only need change the state of the data, and they will all automatically update.

See? Sanity.

Time to grow up…

If you’re not using some MV -ish framework or some kind of bindings for your project, there will never be a better
time than now. You owe yourself a little sanity, take the plunge. You’ll thank yourself in the end.

af

Zombie.js

I’ve been waiting for quite a while to try out zombie.js. It seems like the
“End All.” of hard-to-test-super-complex-setup systems, for instance, a system
where you have a SSO with several redirects, then multi-panel single page app
with a lot of ajax requests and dynamic resources. Unit tests are one thing, but
I really wanted to test that the whole setup was going to perform as expected.

#epicfail

After a day and a half (and part of an evening), I think that zombie.js is
probably trying to be a little too magical. On my Vagrant box (Ubuntu Precise
server) I’m running Node v0.8.6. At first I tried the setup with Mocha as
prescribed in the docs, but to no avail. The biggest problem: our SSO
system does a couple redirects when you hit the application page, and just like
another user expressed in this discussion, my .then() callback fires way
too prematurely, and never hits the actual redirect. Specifying the wait time
didn’t help any either.

Frustration at it’s finest

I’m not one to give up, I rarely let a hard problem get by me, but this isn’t
just a ‘tricky’ API I think. I think it’s an immature project. Harsh, I know,
but have a look at this example:

1
2
3
4
5
6
7

var zombie = require('zombie')
  , browser = new zombie.Browser
  ;

browser.load('<html />', function () {
  console.log('foo')
});

According to the documentation, browser.load…

Loads this HTML, processes events and calls the callback.

But it actually gives:

1
2
3
4
5
6
7
8
9
10
11

TypeError: Object #<Browser> has no method 'load'
    at repl:1:10
    at REPLServer.self.eval (repl.js:111:21)
    at Interface.<anonymous> (repl.js:250:12)
    at Interface.EventEmitter.emit (events.js:88:17)
    at Interface._onLine (readline.js:199:10)
    at Interface._line (readline.js:517:8)
    at Interface._ttyWrite (readline.js:735:14)
    at ReadStream.onkeypress (readline.js:98:10)
    at ReadStream.EventEmitter.emit (events.js:115:20)
    at emitKey (readline.js:1057:12)

Am I just doing something plain wrong?

So the tally is…

Zombies 1, Aaron 0

As a side note, selenium is looking to do exactly what I want.

At my current position I’m getting the opportunity to do a lot of testing with
selenium (which I’ll talk about later) and vagrant. One of the things that
I need to accomplish during testing is dynamically starting the development environment
in “TEST MODE” to perform functional testing against the webapp backend.

Remote execute

I was ssh-ing into the server ok using this ssh script (based on paramiko),
something like:

1
2
3

>>> client = ssh.Connection('localhost', username='vagrant', password='vagrant', port=2222)
>>> client.execute('pwd')
['/home/vagrant\n']

The issue that I was having is changing directories. A simple cd .. didn’t seem
to want to do the trick:

1
2
3
4

>>> client.execute('cd ..')
[]
>>> client.execute('pwd')
['/home/vagrant\n']

I started thinking it’s a permission issue or something, but, no, the vagrant user
should be root, nothing seemed to make the simple command execution work, at least,
I can’t think of another way to change directory on a linux box. And to make things
more intersting, it didn’t seem to matter if I used PySFTP or the aforementioned
ssh.py, the result was the same.

Turns out to be simple

I’m not exactly sure why, but this post on teh Stack led me to the solution,
turns out it was simple:

1
2

>>> client.execute('cd ..; pwd')
['/home\n']

Just needed to execute the commands together. Why? Your guess is as good as mine…

Af

How’s that for a title? I just have to say, git is pretty awesome, but I’m assuming you knew that. I read an article today where (for the first time I’ve seen) someone was making a case for bazaar over git. I used bazaar for our development team for almost two years, it was my “upgrade” to “distributed” over subversion. Sorry, can’t find the article. In a nutshell, 20 out of dvcs users [on that webpage] prefer git over bzr. Maybe corn flakes too…

tldr;

Click the little ‘X’ in the upper-right corner…

good, bad, indifferent

I’m not really going to argue points about the two systems today, all I’ll say is that I’m totally digging git. And my motivation is several-fold:

• Video - Summary: Linus Torvalds tells Google staff how stupid they are ‘coz they don’t use git… over and over and over again.
• Like, the internets use github, both of them, duhh
• I get to use it at work :)

Further rationale

Bazaar was great, don’t get me wrong, but some of my newest most favorite features are (in no particular order):

• On-the-fly branching! How cool is that?? In bzr (or svn) a branch would require a different folder. In-place branches are wicked.
• Submodules Is there another system where this actually works?
• Rebase OMFG nuff said.

There’s more, but that’s on the top of my list right now.

mixin(setuptools)

One of the neat things about settling in with a new development team is the things that I learn. At the top of my list are:

• the things I’ve been doing right,
• the things I’ve been doing wrong.

Of the latter, the first that comes to mind is setuptools. I’ve been managing Python dependencies manually for the last several years, in my mind, somehow, convinced that efficient dependency management in Python was somehow flawed, or “seldom agreed upon”. Probably a result of me being in a hurry most of the time.

Thankfully, I’ve seen the light! A colleague at work turned me back on to virtualenv, and I now realize what I’ve been missing in python all along: a reliable, simple deployment strategy. I’ll have to write more on that workflow later.

mixin(git)

This part is my favorite: without too much trouble, you can configure setuptools to pull from a github repo (or probably any other repo). There are only two criteria:

• The remote project must be setuptools-compatible
• The endpoint must provide a tarball (equivalent to an .egg)

In the setup.py you only need specify the tarball location in a specific way in the dependency_links kwarg.

Eg:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

from setuptools import setup

#other stuff here
...

setup(
    name = "my-project",
    version = "1.0.0",
    author = "Aaron Fay",
    author_email = "me@gmail.com",
    description = ("Simple python setuptools package."),
    license = "BSD",
    keywords = "example python package setuptools",
    url = "http://my.url",
    packages = ['an_example_pypi_project',],
    long_description = "My description"
    install_requires = [
        'my_other_package==1.0.0' ## look here!
    ],
    dependency_links = [
        'https://github.com/AaronFay/my-other-package/tarball/master#egg=my_other_package-1.0.0'
    ]
)

The trick in all this is the #egg=my_other_package-1.0.0 part, setuptools will recognize the package name and match it up with a required package in install_requires. It even has a pretty smart way to differentiate package versions.

wrapping up

Without too much trouble, a very efficient development/production workflow can be set up with the combination of virtualenv, git, and setuptools. It’s definitely an exciting time to be in software development.

Until next time.

af