In the past few weeks, I’ve been reading about some little aspects of web programming that I’d never really considered the existence of, let alone closely examined: for example, the DOM event model. There’s a deep amount of learning to be done here about the history, the problems that are being solved, and the present state of this system. While reading and researching, I was reminded of a discussion I tried to have with the School of Computer Science’s faculty during a planning retreat, back when I was a student representative. I do not remember the specifics very well because it was years ago, but it was along these lines:

Chair: (to all present) “Are there any other suggestions for areas of improvement in our teaching?”
Me: “I think we should do more to teach people about making applications for the internet — there’s a lot of deep information there, and we don’t really teach it. Sessions and login/password handling, HTTP verbs, caching, CGI, how web frameworks like Rails work — academically, we seem to live in a world where the internet doesn’t exist.” (only I was probably way more awkward)
Chair: “One issue with that is that we’re not in the business of teaching technologies; we teach concepts, and students are expected to be able to figure technologies out on their own”
A Professor: “I include some slides about HTTP when I teach my (optional) 4th year networking course” (which requires an optional 3rd year networking course)
Another Professor: “I teach students about REST and design principles in my (optional) software design course” (which has a reputation as a course for people who want to do nothing but write essays about design patterns)
Another Professor: “You have to use GET requests for the server we you write in second year — we talk about HTTP verbs then (we talk about GET)”
Chair: “Well, it’s not our job to hold people’s hands and give them every bit of knowledge, especially not about specific technologies. We’re not going to make a Ruby on Rails course. The concepts are being taught, you just seem to have missed them”

I am probably editorializing too much, because everyone there was reasonable and (mostly) friendly, but I was given a distinct sense of “learner’s machismo”, that if I don’t know the answer to a question it’s because I’m not trying hard enough, not because there’s anything wrong. I had spoken to several students and gathered their requests: education on the internet was perceived as sorely lacking, and a very useful thing to add.

There is a new stream in the School which is called “Software Engineering”, as opposed to the generic Computer Science program. It sounds like they’re doing some more hands-on work in it than we did in the CS stream, so perhaps new students will have an opportunity to learn these sorts of things. It’s difficult for universities to face the topic of “abstract vs applied knowledge”, especially in the realm of Computer Science, because both sides have valid arguments.

My experience and training at school was not to be a competent programmer. I really didn’t program much over the 4 years at all — probably less than half as much as friends of mine who went through 2-year college Software Engineering programs. And what’s worse, code quality was worth almost nothing throughout my time in school: deadlines were hard and fast and we were typically marked on correctness and presence of documentation. Almost no time was spent reading code or talking about how to write good code, or to design good code. It seemed like the portions of our education that most closely related were talks about coupling, cohesion, UML and sequence diagrams.

Colleges are supplying a high level of technical knowledge for our field, and the candidates seem less confident that they know theory, but appear to be very well versed in it. In my experience, University students seem to be half way between good programmers and good researchers, without being either. Well, now I’ve wandered off topic. Code quality would be a great thing to try to teach, but for now, I want to reiterate that the web is complex, and we need to have more information about creating applications for it included in our education.

I just finished catching up on the final season of house. Spoilers: dinosaurs conquer the earth and convert it to a day spa.

I haven’t faithfully watched House for the last 8 years. I actually hadn’t seen more than the first season or two before last summer – but it’s had a constant presence. Several of my long-time friends have been fanatics about this show for longer than I’ve known them. It would regularly come on in the background while I did homework. House has been a commonplace meme on the internet. The finales are always held up as hallowed mindfucks. And I did catch the odd episode — I even tried to catch up once when there were only 4 seasons or so, and I only got midway through the second season before throwing my hands up in the air, proclaiming “I can’t watch a show where every single episode is the same!”

Almost two years ago, a friend of mine (one of those fanatics) was watching back through it. Pretty much every time I walked into his room, he’d have House playing, no matter what else was going on or what time of day it was. I would often just sit down on his bed and watch some of it, because it seemed so ridiculously entertaining. The one thing I could consistently count on was a really high production value. Despite the content seeming mundane, it always felt good to watch.

Last summer, when I should have been exploring San Francisco, I instead made a habit of laying on my bunk bed and watching episode after episode of House. I started at Season 4, in which House runs a competition to see who will be on his team, and gradually whittles down a long list of candidates in humorous ways. The clearly developing story helped to wipe away the sense of monotony that I came to hate in my previous attempt. Those episodes successfully held my attention until I got hooked! I stopped midway through the sixth season, wanting to leave some of the show for the future (I do this a lot — for example, I’ve still got a missing season of Scrubs to watch), and I’ve occasionally done little bursts, aiming catch up not long after the finale.

That must have been boring for you — my apologies! As a part of finishing the show, I wanted to recount my experience with it. Every time you finish a series of novels or television show, there’s a time similar to a period of grieving. You can go back and rewatch the characters play out old interactions, but it’s more like high-fi memory than re-experiencing the things you first saw.

We place value on the stories that connect us to events like television shows or reading books. As we spend more time with them, we become more dedicated, and we pile up rich memories surrounding them — often more about our interactions with others than about them. For many people, their love of Harry Potter, Star Wars, Twilight, or Lord of the Rings isn’t really a love of the thing itself, but a love of the feelings they had and the people they knew while they experienced it. Media is an excellent source of nostalgia.

Anyway, here’s to you, House.

When it comes to web development, you could fill warehouses with the stuff I don’t know. Five years ago, I knew a certain amount less than I do now — but there was also dramatically less to know. Reading this post (hn) today helped me to realize that if I do not take action, I may at some point look back at this point as the zenith of my knowledge, relative to what it takes to get a web application up and running.

As such, I’ve spent the last hour or two getting reacquainted with heroku (which, holy damn, heroku is so easy to use). I’ve followed their python tutorial and installed flask and whatnot, and realized that I’m very fortunate to already grok virtualenv, pip, flask, and gunicorn. The heroku docs do an excellent job of explaining how to set things up, if not what precisely they are. So, I decided to do some gap filling — here’s a brief overview of what these things are and why someone would use them:

virtualenv

Virtual Environments are used to create a python environment which is isolated from the rest of the machine. You can install packages into it and easily pack it up to move elsewhere, or duplicate it if needed. I can think of 5 things virtualenv makes it easy to do:

1. Run multiple versions of python on one computer
2. Avoid ongoing dependency conflicts between your own projects*
3. Test/play with new libraries without messing other projects up*
4. Identify requirements when packaging your code up to deploy
5. Manage installed packages without being root or configuring by hand

* okay, these are the same problem, but they can come up independently of each other.

For ruby folks: think of virtualenv in the same vein as rvm, but with different philosophies. Some folks on hackernews suggested that an even better analog is rbenv, which I’ve never used — but it sure sounds right!

Typical usage is:

$ ls
$ virtualenv env
$ source env/bin/activate
(env)$ easy_install cool_module
(env)$ vim app.py
(env)$ cat app.py
import cool_module

# code which uses cool_module
...
(env)$ python app.py
# runs successfully
(env)$ deactivate
$ python app.py
# cool_module fails to import

Note the following:

• On windows, ‘source env/bin/activate’ is ‘env\Scripts\activate.bat’
• in bash, ‘source’ can be replaced by ‘.’ — it’s common to see ‘. env/bin/activate’ used
• ‘env’ is just a common name; you can name an environment whatever you’d like
• there are useful virtualenv switches which can be found by just running ‘virtualenv’, particularly ‘–distribute’, which adds pip by default.
• ‘deactivate’ is added to your path by virtualenv; it is not a separate program.
• virtualenv is a program that needs to be installed, either manually, via easy_install, pip, or a package manager. It will be part of future versions of python, but your computer does not have it by default because you have python.
• there are many different setups of “where you put code” vs “where your env lives”, this is just one.
• two advantages of not putting your code anywhere inside of your env/ folder are that you can put ‘env’ in your .gitignore, and that if things get messed up somehow, you can have a clean slate python-wise by rm -rf’ing your env directory.

Using virtualenv is very easy to do, and it will quickly become part of the mental model of your working environment. There is some streamlining left to do — ‘. env/bin/activate’ is cumbersome — but it’s a great tool.

pip

I can’t write anything much about pip that hasn’t been written. People have discussed python package management systems very thoroughly! A quick sum-up, then:

Pip is a nice package manager for python. It tracks dependencies, can install/uninstall modules, and can distill a list of requirements (‘pip freeze’), which is both human and machine-readable. Pip can even read from one of its requirements-lists and duplicate an environment. There are apparently things about pip that aren’t great, but I encourage you to go google about them if you care to.

Common usages are: ‘pip install cool_module’, ‘pip uninstall cool_module’, ‘pip freeze’, ‘pip install -r requirements.txt’

Flask

Flask is a web application framework, like Bottle or Sinatra, and to a lesser extent like Django, Rails, or Symfony. It actually started off as a joke! It has a fairly small code footprint and nice documentation. It uses the Jinja templating engine by default and Werkzeug for routing (if you know those things that’s meaningful), and is a very common choice for writing api servers at the moment. It’s pretty darn easy to get started with.

Because it has such a small codebase, it’s pretty easy to hack up and extend if you need to do that kind of thing (you probably don’t), and it’s got a lot of features to allow for modular code. It’s also got a lot of extension stuff available that can fill most of the gaps you might be looking for. If you’re coming from Django, it’s like starting with the minimum and building up to what you need instead of starting with the maximum and wishing you could shed a few pounds.

Rather than outright duplicate the fine documentation work that’s been done, I suggest you take a look at the Flask docs themselves for an introduction to how to use it.

Warnings: Advanced practices are not very well covered by the documentation, and there are some weird practices around importing and using flask extensions due to a funky design decision they made when Flask was young and are still safely backing out of. Occasionally you’ll find extensions written for an “old style” of Flask extension import. The “new style” of extension importing is intended to support both new and old Flask extensions, but it still occasionally breaks. It’s beyond me when it does — I had this happen attempting to use Flask’s OAuth extension.

gunicorn

Ah, now we’re almost completely outside of my sphere of knowledge. Gunicorn stands for “green unicorn”, and it’s a web server. It’s better than the one that comes with flask, and is quite popular. Alternatives are things like Tornado, nginx, or apache.

Before you think “oh, I have apache installed! I’ll just go do that then instead”, be warned: mod_wsgi can be a pretty major pain to set up and diagnose problems for. I’ve heard that mod_passenger is a better way to go, but I haven’t tried it myself. If you can avoid putting python on apache, it’s probably a good idea.

More things

I don’t know anything about front end frameworks like jQuery, Backbone, or Bootstrap, and I haven’t ever written coffeescript. They’re what I’m going to mess around with a bit this weekend — Backbone is just too new for me to have played with yet (or, I feel like it is!), while jQuery’s anonymous callbacks-with-params mess with my head when I try to build a mental model of how information flows through a program. I feel like I’m supposed to “just trust” that information is there, and that’s weird. We’ll see how I feel in a few days!

(Also, so long and thanks for a super towel day)

conventions are a flawed solution to the code-style problem

In my personal code, I like to write names_like_this, and Types_Like_This, and CONSTANTS, and I indent by 2 spaces. I put {‘s on new lines for functions, but not for control structures. And whenever I have 2+ single-line ifs, I’m unlikely to bother writing {}’s out.

No programmer needs to be told about the nature of the debates on style in code. To any non-technical person reading this: imagine multiple Sheldon Coopers arguing about an issue more esoteric and asinine than he normally bothers with. Except that for us, it does tend to matter, and here’s two reasons why:

If there isn’t a consistent set of rules about code style, things will be harder to read for everyone, and there will be more mistakes. Picture collaboratively written prose where the authors insist on spelling words in their own unique ways. That’s why we need to choose a single style in the first place.

If the style is not the one you naturally think in, you will face at least some period of difficulty reading and writing it. Imagine if we decided english would be written with capitalization inverted from how it is today, and instead of spaces, we’d use ^ marks. tHINGS^WOULD^LOOK^LIKE^THIS,^AND^PEOPLE^WOULD^RIGHTLY^COMPLAIN. It’s jarring and uncomfortable — but you would eventually get used to it.

The mental and temporal cost of choosing a specific style for a new project, imposing a style on written code, or changing styles in an existing project is huge. Builds break, people hunt for inconsistencies for days, people write code and then groan and rewrite code, people use complicated regular expressions that become time-sinks. Code linters tell us about our follies: but we have to fix them. Each wasted second is small, but it’s a break in focus, and it’s huge across a hundred developers over a year.

I propose a Code Style Switcher

I followed the following line of reasoning:

1. We can identify elements of code style
2. We can specify a set of code style conventions
3. We can formalize a set of conventions
4. We can automatically detect failures against code conventions
5. We can recommend style-fixes <- this is about where existing technology ends
6. We can automatically apply style-fixes
7. We can read a file in and spit it back out semantically identical, but formatted in a different style
8. We can make a system where everyone writes and sees their own style

From there, I thought of a few other cool things — given a code corpus:

1. We can detect code conventions
2. We can detect personal code conventions
3. We can detect ‘problem spots’ where inconsistencies arise
4. We can calculate a minimum-effort code convention for a team, if we want to

The key idea is that every developer could write their own code, in a way that makes sense to them. Every developer would see code that makes sense to them. There would be no build-breaks based upon lint failures, no “boyscouting” to bring non-conformant files you touch up-to-snuff. And no fussing in code reviews about bracket placement or which character is used for whitespace (and the quantities of chosen).

This is a big problem, and it’s silly that we haven’t universally solved it, when it’s exactly the sort of problem computers are good at solving. (it’s basically machine learning search and replace).

Implementation

A proof of concept would likely operate on a very small scale with specific configurable elements —  e.g. {} placement and indentation. A suitable expansion from that point would be to deal with naming conventions (camelCase versus underscores, _names, TypeNames, etc). From there, the horizon point would be an extensible style language capable of defining a style for any parseable token or combination of successive tokens for a given language, as well as the ability to exclude certain tokens from being processed.

Eventually, the switcher would have to be set up as a plugin for an editor, to allow reading/displaying and writing files in a given style. I’ll likely make a stylesheet generator at some point that shows you “your style” given a piece of code and identifies inconsistencies. The underlying implementation will likely be a c library for the sake of portability, but that may come after prototypes written in higher level languages more suited to string processing or with nice native data structures (perl, python, ruby, or js)

Code would likely be stored on the machine in whatever style the author defined for it, but when committed to a repository, it would likely be wise to somehow reconcile the styles. That could be accomplished with post-commit or post-push scripts, but I’d like to think about that problem more. It’s a long ways down the road. I also need to think more about how to get from detecting a failure to applying a fix. The possibility of semantic breaks is very real, and determining “the safe route” may not be tractable for me.

Anyway, now I’ve just got to do it! I’ll add more posts as I make progress — remember though, I’m pretty busy 🙂

Post-script: I hardly even noticed, but I’m on day 18 now. I need to get a “next thing” figured out fast — at the top of my head are speed-reading, reading philosophy and learning math. I do intend to continue blogging every day to increasing my luck surface-area, also to help in attaining/retaining a producer’s spirit.

After work today, the temperature was right and I had an errand to run, so I walked about a half hour from the office to Dufferin Mall. I’ve been thinking a bit lately about music and how to make it, so I cranked one of my favourite mashups and counted bars to try to get a feel for how the pieces were structured. It made for a great study; because the mashup had a variety of sources (though largely within electronica), there were a range of speeds, rhythms, and styles for me to try to get the feel of. The mix wrapped up pretty much perfectly as I arrived at the mall.

As I walked up to the mall, switching gears from headspace to the real-world, I thought a bit about awareness, and it brought my mind to a friend’s book I’m reading about the simple concepts behind buddhism. I got into a very thoughtful, appreciative mood while I walked around the mall, trying to be calm and just to see. I watched people buy, and argue, and examine things – something notable was that I only saw two people smile the entire time I was in the mall. I also saw a little girl get very excited about one of those car-machine-rides that’s always outside of zellers/wal-mart/toys-r-us sort of places, but I didn’t actually see her smile.

On my way back from the mall, I noticed a little elderly asian woman jog-walking down the other side of the street, a man who looked very quietly angry, and a bunch of other things. I tried to keep my attitude of observation with me. Coming to the corner of Dufferin and Bloor, I sat down on a bench near the church entrance, and while I did my best just to see the world, my mind took note and waxed reflective. I began to think about the nature of happiness and how it relates to life goals and situations. The words of Solomon were in my mind — also echoed in the simple buddhist book — that even if a person manages to possess all that they wish for, they will leave it behind when they die. My feet got restless, so I turned on a tune and strolled west along Bloor.

I eventually walked past a sign that read “Samosa – 3/$1” and also advertised Dosas. I like these things, and I was still fairly hungry, but I wasn’t done thinking yet. The store that the sign belonged to sat on a corner of a one-way street that exits onto Bloor, so I walked up the street a short ways and sat down to let the song finish and to try to collect my thoughts. This is roughly where I got to:

I thought of the following possible “descriptions” of how happiness could work, as a mechanism:

• There could be just a single sense of happiness, which is:
• independent of your actions / life’s situations
• fully dependent on your actions / life’s situations
• dependent on your actions / life’s situations to a point (positive, negative, or both)
• variably dependent on your actions / life’s situations
• There could also be two senses of happiness: a momentary, event-based happiness, and a rest-happiness felt in the absense of a direct event which affects your mood.

The variable-dependent and dependent-to-a-point situations are very similar. For the variable dependency, one’s happiness can be noticeably affected by an event or situation, but gradually, as one becomes happier and happier (or less and less happy), the effect of an event or situation is lessened. In the “to a point” situation, a situation or event has the same effect over and over again until a certain level is crossed, at which point the event no longer affects how happy a person is.

The fully dependent version would suggest that you could do the same thing over and over again (provided it won’t make you sick or via some other means start harming you — so eating, sleeping, etc don’t count as counterexamples — think instead of reading a joke) and it should continuously increase your level of happiness by the same amount, after every reading.

The fully independent version suggests that no matter what you do — whether you accomplish something, or lose something, or stay the same, you will remain exactly as happy as you are right now. I’ve noticed anecdotally that events do bring (at least temporary) bursts of happiness to me. So full independence does not seem to be a realistic situation, unless you add a second form of happiness: rest happiness. The happiness you have when there is no force acting upon you is what would be independent of events and situations, and it is posited to be essentially unchanging. It could likely be altered through prescription drugs or mental illness, but that’s outside of my desire to speculate upon 🙂

The fully dependent model from two paragraphs ago also didn’t sound very reasonable — so that leaves us with the variable model, the to-a-point model, and the two-happinesses model, and possibly mixes of these concepts.

Having narrowed down the field of possible mechanisms of happiness, I decided to think about the consequences of each of the remaining candidates, to see if I could rule anything else out or find that any categories were actually collapsible. I felt that they were! Essentially, the dependent and independent versions are what matter; I was unable to rule out either of them as a broad class in earlier thought experiments, so it’s worth considering as a whole what each might mean.

Happiness independent of situation or action means that a person could win the lottery and marry a perfect mate and raise perfect kids and accomplish all of their goals and be renowned and respected and essentially have all of their wishes granted, and yet be no happier on average than a person who lives in a waste matter sewer after breaking multiple limbs falling into it. It means that regardless of your actions, your desires will never be fulfilled.

Happiness dependent upon your situation (to at least some degree) means that your happiness is affected positively when good things happen and negatively by the bad. Winning the lottery should then make you extraordinarily happy in a lasting, fulfilling way, but this does not appear to be the case. After great personal victories, people seem to experience a short bout of happiness, which subsides. There appears to be a cooldown on happiness levels. This means that, to reach and keep a certain level of happiness, one must continuously find fulfilment and enjoyment — they will never reach a point where this need ceases.

Thus, both roads lead to the same place: no matter what a person does, they will never ‘feel complete’, or find true, lasting happiness by accomplishing a goal. That, I think, is one of the things worth seeing about buddhism: fulfilment, real happiness, and painless existence are not the idea. It appears that one must simply accept that they will never feel truly fulfilled in a lasting sense. Two corollaries arise: regardless of how great or crappy your life is, momentary happiness is available, and even if you can’t find permanent fulfilment, it is not beyond possibility that a person could flood their life with positive events to try to maintain a feeling of fulfilment. It would just be tiring and wasteful. It’s much the same as food — you can always eat it, but you’ll never be done. And you could probably find a way to eat it continuously, but it wouldn’t be a pleasant experience.

This felt like a worthy result to arrive at, and I found it surprisingly comforting. Seeking fulfilment is not utterly pointless, but it’s also not worth fretting over if I feel that I am not at my happiest at a given moment. Another story from the simple buddhism book came to mind: a man who felt he had many problems sat with buddha and listed each one of them out, then asked for buddha’s help. Buddha responded that he couldn’t help with the problems listed, but might be able to help with a different problem. The man asked which, and Buddha responded “that you think you must solve your problems”.

Having reached a good thought destination, I went in for some food — delicious and cheap, wow! $5 for a styrofoam container full of rice with 2 large splotches of different veggie curries on top, and $1 for 3 samosas! I didn’t go for wild, but I could have paid $3 for 10 samosas! They were incredibly delicious. I ate as I walked home, grabbed some strawberries (going to taste test the expensive ones and the cheap ones), and of course thought some more. I also took an opportunity to smell some flowers, and to enjoy a stunning vista of the moon framed by high park apartment buildings and a construction crane on Bloor.

A productive walk. This is why (and how) I enjoy my free time.