Rob Conerys Blog

Men In Tech

2012-05-11T10:00:00-05:00

The tech industry, like many, is rife with sexual discrimination and muted policies towards equality in the workplace. I used to let it ride. No longer - this is my story.

The Boner

This all started, as most stories do, on a regular day. The sun was shining, I was in a good mood all things considered. I drove to work in light traffic in my new car that I could afford because I have this job in the technical industry. I'm a programmer - which is usually quite shocking to people when I tell them.

"You don't look like a programmer! When did you get into computers? That's kinda hot..."

I'm used to it. For some reason being a guy means I'm supposed to be digging ditches or playing football for a living where tight outfits and showing off my body - you know: no shirt, sun glistening on ripped pecs. That kind of thing.

Yet I'm not that guy - even though I'm 6'3 and workout a lot (and some say I look the part) - I'm a programmer and I work in an industry dominated by women who can't get passed the idea that I'm a programmer and I'm hot (I've overheard many of the moms at our playground call me a FILF).

Not everyone has a hard time with the idea that I'm a programmer - it's young women mostly - the kind that just graduated and want to get rich while drinking with their friends while wearing the latest in geek fashion accessories. Dark skirts, thick-healed shoes with their hair pulled back into that "Girl With the Dragon Tattoo" kind of thing.

It's the world I work in - every day. My boss (the senior dev) is a Dragon Girl - you'd swear she buys her clothes from the Stieg Larsson catalog for the wannabe-techie-who's-never-coded-before.

Sigh. So anyway - today we're doing our morning Intentions (for those not familiar with Agile - that's where we all stand together and describe our Work Intentions for the day) and my annoying coworker is, once again, staring at my crotch.

I'm used to it. I try and dress nice for work and sometimes that means wearing things that accentuate "the male form". Normally I'm happy in a pair of baggy 501s but I'm trying to dress "professionally" and move up in life - and my dad told me I need to use what God Gave Me. Whatever that means.

That was his generation where men ran around in fear of their wives - pushing the strollers and wearing the Bjorn while the wife barks commands in her pony tail, vest-jacket and yoga pants. Thank God I don't live in that generation....

I shift my stance a bit and give this lame girl a look as if to say "grow up scumbag" - and she just laughs. Women can be so annoying... and then I hear my name called.

I freeze. Shit! This numb-tits was just staring at my junk and got me so wound up I forgot what I was thinking about! All of a sudden I feel like everyone's eyes are on me and my pants...

In my mind I try to get the image of that chick out of my mind - and I can't. I feel like they're all looking at the bulge in my pants and I wonder why I wore this thing to work then get mad at myself for even questioning myself and my wardrobe and why can't these fucking women GROW UP and understand that YES I'M A MAN SO FUCKING WHAT.

For the life of me I can't remember what I was going to say.

He must have a boner or something.

Light giggles. I'm completely embarrassed. Yes this really happened. I'm so completely astounded that one of these idiot girls said that to me... I can't believe I work here, with these people. I love my job and I love to program - but dealing with these fucking morons is taking its toll.

I look over to my boss who's just giggling slightly. "Should we move on then Rob?" she says. I look over to the corner office where the founders - all women - are sitting around a table tensely discussing company strategy... I feel trapped - in a Good Old Girl network where "just another boner comment" will get me a nice, matronizing look from someone who has no idea what it's like to be a man in this hell hole.

"Whatever" is what I manage to say. What else can I say? And I begin to remember my parents and their advice...

Women Want Only One Thing

I grew up in Los Angeles. Meat-fest and the place where men get crotch implants for their 16th birthday. I never cared about the size of my privates and my parents, when I was in junior high and hight school kept insisting that men grow differently and to be proud of my body.

Yet every day there were billboards, magazine articles, storefront windows, music videos - literally wherever you turned: men in tight pants with their bulge right in your face.

I was 12 and started to believe that men with a big bulge seemed to have everything they wanted. My dad used to lecture me constantly:

Keep those pants buttoned up and believe that all women want in. That will keep you safe.

I remember thinking my dad was just another prude male - his thinking straight out of the Victorian Era where men wore those ridiculous, fluffy outfits that managed to hide most of their body except for their bulge.

Fast-forward to high school. I was a junior and took part in a typical story of following friends into a room at a party, talking to this girl that seemed to be nice, my friends leaving the room at some point, being drunk, and ultimately being pressured to do something I wasn't prepared to do.

A familiar story for many men - I know. Just stick with me for a second because I was one of those statistics. Many men are - and most women don't seem to understand that. Say stupid shit first, apologize for hurt feelings later.

It was 3am when I made it home. My crotch hurt. I didn't know it would hurt like that and I remember feeling shamed and numb. I tried to sneak in and not tell my parents - they would be furious with me. My mom... God knows what she would do to this girl if she ever found out who it was.

I told myself not to regret it - it just a physical act that I was going to do someday anyway - and now it's done. Big Deal. I wanted to be in love the first time, I wanted to have it be something special - not something induced by alcohol and clever conversation...

But we can't all get what we want can we?

Sororities

I had a few more experiences in college but I was a bit more on my guard. I didn't put myself in situations where women were drinking and there were dark rooms. I came to realize that we all want the same thing in the end - and that not all women were scumbags waiting to get into my pants.

But working at my job these days - I'm taken right back to my high school days. The so-called "Sisgrammer" thing is in full effect with these young women coming out of school thinking everything is a sorority party.

Drinking at work, long stares at my crotch, quips about boners in my pants.

The other day we were out at a user group meeting (my first one) and I showed up - and one of the women there asked me

Are you here to take our drink order?

I was speechless. I left this shit behind me in college - yet here it is in front of me. I couldn't think of a retort so I just smiled wryly and muttered something non-confrontational. She cocked her head a bit as she looked me up and down - noting my bulge - and said

Sorry - but you don't look like a programmer - no offense

Yes. I'm a man. My junk doesn't look like yours.

I look up at the TV that's there next to the bar and coincidently there's a commercial for GoDaddy with Michael Phelps in his speedo, gyrating in front of the camera with his gold medals dangling around his bulge...

I recall a Nokia video that I watched the other day on Vimeo where these Sis-grammers strut around in their Dragon Girl outfits while these men, dressed in leather pants with a huge bulge and these shoes, glasses and shirts that made them look like Men With a Dragon Tattoo - gyrating in front of the camera...

All to sell Nokia/Windows Phone 7's. The scene reminded me of that party - my First Time Party - surrounded by women that "wanted to get some". The sexual pressure coming at me from everywhere... finally relenting.

Let's just say that Nokia phone isn't high on my list.

My resentment grows as I stare back at the clueless bitch who's still staring at me with that sorority sister smile... I don't want to resent her, I want to move on with my life an my career...

Another GoDaddy commercial comes on the TV.

I turn and leave.

This Too Shall Change

I know what you're thinking: "So what - another victim story where a person who can't hang blames women in tech for all his problems". I hear this a lot when I speak up.

It would be easy to believe that - to accept the boner comments, the stares, the imagery on TV. But I don't think I'll do that.

Inequality, segregation, prejudice and bigotry have been common in human history - but they aren't permanent. I choose to be patient, to work hard and eventually... someday... possibly... rise to a position where - hey look! I'm your boss!

Sorry what was that? Oh right - that comment - well yeah actually I do remember that. Hard feelings? No - I realize that people say weird things sometimes... speaking of...

I called you into my office today to have a chat with you about a comment you made in the office - or was it on Twitter? Or maybe at a conference? Either way you seem to have offended someone from the opposite sex (again! Imagine that!).

Unfortunately for you we're not at a bar, and I'm not taking your drink order...

I'll take my time explaining what professionalism is, and what it means in the workplace. I'll take care not to offend you as I explain the roles of men and women in any industry. I'll listen to your excuses, and I'll listen to you politely explain that I should lighten up.

Then I'll fire your fucking ass.

No offense.

The Weekend With NodeJS

2012-04-18T10:00:00-05:00

I try not to work on the weekends and instead spend the time learning something new and, hopefully, different. To that end: Tekpub jas just released Hello NodeJS. What are you doing this weekend?

All Roads Lead to Node

You ever head to the local user group meeting or conference - or maybe just casually drop by a colleague's office - and they're discussing some new technical concept? One that you may, or may not, know much about?

This happens to me just about every day - whether on Twitter, reading a blog post, or just talking on Skype with a friend. The odd thing is that these conversations - the idle musings on the New and Shiny - always seem to fall back on The Keystone: the Shiney New Hotness that, if you don't know about it, means you're a trog.

For me, that's been NodeJS this last year and some. At conferences, or in an IRC chat - someone, somewhere would drop a reference to "Well I really like the way Node does that... " and I would find myself staring blankly off a cliff.

I always wished there was some type of "What The F*** Is NODE!!!!" reference for people that might care. If only to avoid falling off the face of a geek conversation.

Alas - nothing like that has come along. So I went ahead and made one that you could watch over the weekend easily, with a beer or a glass of wine, and go back to work on Monday feeling like you know more.

Part Reference, Part Exploration, Part Musing

This production isn't a reference and it's not anywhere near a "Mastering NodeJS" kind of deal. Node's moving much too quickly for such a thing. Instead I wanted to aim this at the curious who want to not only take part in the Arm-Wavey New Hotness conversations - but also contribute.

So, to that end I made sure to include:

What the Hell Is Node and Why Should I Care? This is the first episode and I do your basic breakdown in a straightforward way showing you what people are talking about, why they're talking about it, and where the general excitement is coming from.
Events, Blocking, and Buzzwords You would be surprised at the amount of misinformation out there about Node's ability to be "non-blocking" - and what that means for you as a developer.
Data To my mind, this is vastly underserved when discussing Node. So I peeled back the lid and dove into data access with Node. I wanted to show what Redis is and does, why MongoDB is such a natural fit, and also that using a relational system with Node is rather easy.
Sockets If you've ever seen a Node demo, you've seen a socket.io demo. This is where one browser triggers an event on the server which broadcasts a response to other browsers. It's incredibly simple and will likely short circuit your brain.
Frameworks There is a robust, emerging dirth of app frameworks for building apps with Node. I drill into 3 of the most popular: ExpressJS, Tower, and Geddy. Each has its strengths and corresponding weaknesses.

At the end of the production you'll hopefully have a good, solid understanding of what makes Node tick, what "Evented I/O" means, and why people are very excited about what Node can do.

I do hope you enjoy it.

Leaving Your Mark

2012-04-17T10:00:00-05:00

Don Syme makes a very interesting postulation over on his blog: "Is Javascript code always so full of bugs?" His post goes on to show what happens when you turn on script errors in IE - which is striking. But is it really that easy?

Slop

The rampant amount of errors you run across (if you use IE with script error notification enabled) will make you sad for the internet. It lead my friend Miguel deIcaza to postulate:

Guess a sloppy language encourages sloppy practices

A broad stroke, but you can't deny that Javascript has a number of pain points. Inexperience writing in a painful language on top of shifting platforms (browsers) with changing standards... it's easy to agree with Miguel's sentence.

But it made me wonder:

Do we get mad at Javascript so much because we can see the problems so readily?

It's right in front of our noses (especially if you have script errors on) - and the source is there for everyone to read and run through JSLint (Javascript validator).

Side note: for fun I ran Don's blog through JSLint and it was red red and more red. This isn't a critique of Don, more of a wow dude might be more right than he knows kind of thing.

Your Slop

What if you could lift the lid on every site out there and peer inside at the source code? What if you could flip a switch that says ignore every try/catch, every begin/rescue and let the errors flow freely?

I think the internet would stop working.

I think blaming a language for being sloppy is probably a bit off base - as Phil put it:

sloppy developers promote sloppy code. It's just most sloppy code is hidden from us more than JavaScript is. ;)

I think Phil's right. But it brings up a question: when you write code, how many errors do you write per hour? And, more importantly, how do you know they're there and then fix them?

Forged From The Fiery Pits of Exception Hell

Think of all the code you've written over the years - Javascript, Ruby, PHP, C# - whatever. Where is it now? How many bugs, logic errors and overall madness have you given birth to?

About 1 time out of 9 I can write a routine that works the first time. And when that happens I usually let out a "YIP!" - and then immediately distrust whatever it was that I wrote.

There's no way I can get it right the first time - Odds are that I can't. I know that so I test my stuff as much as I possibly can. Even then I know I'm letting crap out the door. It's human nature.

Our brains are wired to improve upon millions of years of pain and suffering (if you believe in evolution). Why shouldn't our code be the same way? What do we know of any other way to create... anything?

If you have kids and were present at their birth, you very much know what I'm talking about

The Mark of the Maker

Our code is forged from the pain of misunderstandings, miscommunications, hubris, bullheaded ego and a smidge of inspiration and love. After a period of slow-torture and water boarding, our applications take shape.

The true question is:

Do you forge your code carefully, fold it gently, and pound the finest edge found anywhere in the land? Does your code bear the marks of its maker?

The steel of the sword is only valuable as a measure of vanity - a tree limb can take a man's head if it's properly swung. It's the Mark of the Maker the tells the true tale of the weapon.

What does your Mark look like?

Cleaning Up Deep Callback Nesting With Node's EventEmitter

2012-04-05T10:00:00-05:00

One problem people face when starting out with Node (and Javascript in general) is handling the asynchronous, deep callback nesting issue. EventEmitters help fix that.

The Registration Problem

Consider this: you want customers to register with your site. When they do, a number of things need to happen:

The information needs to be validated
The customer record inserted
An email sent to say "thank you"

In a typical scenario, there's probably more - but let's use this for now.

You might know straight away how to do this in Ruby or C# - but how would you handle this with Node and Javascript?## O Christmas Tree

This is some code that you might see in a Customers module:

Yuck.

This code is not only hideous-looking, it's also synchronous and a nightmare to maintain. Node allows you to do this much better with EventEmitters. Let's see how to use Events to clean this code up.

Emit It

There are two ways to do this: encapsulate the eventing, or make your entire object an EventEmitter through inheritance. I'll do the latter.

The first thing to do is reference Node's event module and the util module as well - it has some helpers we'll need. Then we rewire the module to handle the events - I'll explain in a second, but here's the final code:

So what's going on here? Well first - there are no more callbacks - we don't need them! We have events to listen to.

I'm using Node's built-in EventEmitter object to "graft" on some functionality to my Customer object. Javascript doesn't have inheritance, per se, but you can take the prototype of one function and pop it on another.

Node helps you with this using the "util" library. On line 42 we're telling the util to push the prototype from events.EventEmitter onto our Customer function. Notice that this is a function, not an instance of a function as I had in the first example above.

Next, on line 7, I had to invoke the "base" constructor to be sure that I don't miss any internal instancing or setting of values. Turns out for EventEmitters you don't need to do that and you can omit this line - but it's safe to just do it, no matter what.

In the body of each method I'm simply "emitting" an event to all listeners (there's obviously some code missing here - pretend that I have an insert routine and so on). I can emit an event for whatever happens along the way - a successful validation fires "validated", a failure might fire "validationFailed". This frees up our code to do what it needs to do and no more, making it much cleaner and clearer.

On line 29 I've added a final event trigger if everything works out: "successfulRegistration". This is what calling code will really be interested in the most - either that or "failedRegistration" - and we pass along the customer record (more on that in a second).

On lines 35 through 38 we've implemented a bit of workflow. This doesn't need to be inside the Customer function - you can arrange these events wherever and however you like. The calling code can remove every event listener and replace it with its own if it wanted to reorganize the flow here.Speaking of calling code, here's what it might look like:

You hook into the events, then run register() and respond as needed.

All Over The Place

Node is built on top of EventEmitters - you'll find them everywhere. Understanding them is key to writing cleaner code that's more functional and maintainable - and it also helps keep things asynchronous.

n the first example, we had a synchronous drop all the way down - even though we were using callbacks. Our code above isn't synchronous at all - we've hooked into an event and when Node is ready, it will process the emitted event callback.

Neat stuff!

This

2012-04-03T10:00:00-05:00

Someday, this war's gonna end

Created by: OnlineCriminalJusticeDegree.com

via Ape, Not Monkey

Inversion Of Control: An Architect's Version of Global Variables

2012-04-01T10:00:00-05:00

One of the tomes we live by: "Global Variables are EVIL!!!!!!" - so we abstract our stuff into patterns and build up highly ceremonial and ornate bits of dramaware called "IoC Containers". For what? To use Global Variables - That's Why.

You Love Globals

No really. You do. Let's just embrace that this very second. Tell me what this difference isbetween this code sample:

I'll tell you the difference: in one sample the coder admits they have a problem.

In the other they pretend the problem's not there by wrapping it in ceremony, abstraction, configuration files, and Gang of Four nonsense. Can you guess which one is which?

After all is said and done I think it's fairly clear: we're addicted to globalization.
Possibly you disagree with me. In fact I have a feeling that you
really disagree with me. And that's OK - it takes a while to admit it.
It took me forever to realize that I've been globalizing everything since my VB Days.
Look at this way: at least you're aware of it now.

Free The Global Love

One thing we've always been told: "Globals are bad". They're bad because
outside forces can change the state of a given global variable which would, in turn,
leave your application in a somewhat random, difficult to debug state.
Sounds horrible, no? If you think so, take a look at the first sample above. What
silliness do you see there? Me changing a global setting of course! Now I
understand completely that this is a bad idea - but think about it a bit more. I
changed the container setting by simply by using the Rebind() method on the
kernel - why is this even possible?

Every now and again I think it's really a good idea to look at the code we're writing
really carefully... and ask if what we're doing makes any sense at all.

If I Were Creating Rails.app

2012-03-29T10:00:00-05:00

Nothing but respect for Yehuda, but I'm thinking the Kickstarter model for creating a tool might not fit terribly well in the OSS landscape. I could be wrong. Either way - I have an idea.

Don't Fund It, Sell It.

Here's my premise: a lot of people have their Rails environment dialed in. The one's that are having a bit of a harder time tend to be the folks just getting started or perhaps upgrading. These are the people that might very well plunk down $5 for a tool to help them.

The premise of the Kickstsarter effort is to (basically) - well here I'll let Yehuda explain:

My plan is to deliver a .app that can be downloaded and dragged to the user's /Applications folder. At first, the application will have two facilities:- Install Rails into the system: This will install a working copy of Ruby, Rubygems, Rails and all necessary gems into the user's system, available from the Terminal. It may also install rvm and other common system tools, depending on the feedback I get from the community as I develop this project.

Open a Terminal with a working Rails environment: This will leave all necessary resources in the .app file or Application Support, but open a terminal window with the $PATH and other variables set up.

I think this sounds interesting. Hackers out there will probably say "I can do this with a Shell Script! So what!" and that may very well be true. But there are a number of devs out there who are very new to Rails and are getting frustrated at the choices involved.

Choice is a good thing. Frustration is not. Frustration by choices means you don't understand the choices (typically). To me, this is what Rails.app should focus on.

Help When and Where Needed

For people who have been working with Rails daily - the choices might not seem so difficult:- RVM or rbenv? - Haml or Erb? Or Liquid? - CoffeeScript? - SASS or LESS? - Postgres or MySQL (well... this one shouldn't be so hard really). Or MongoDB? - ActiveRecord, DataMapper, or Sequel? - Vim, Textmate, or Sublime Text 2? - RSpec, Cucumber, or Test::Unit? Or all 3? Or just 2?

I'll stop here. If you're new to Rails and/or Ruby you might think it's a bit of a madhouse with so many options. To me, that's the joy of it all.

I also want to put a personal note here: some people are callously saying "the guy who screwed up Rails now wants to get paid to fix it" - the guy being Yehuda.

The problem isn't Rails itself (ActiveRecord discussions aside) really - it's the toolsets and "peripheral knowledge" that goes into it. Yehuda didn't create RVM, SASS, or any of the other choices here, so it's not fair to crucify a guy who's trying to fix something.

So how do you know what to use?** Educate yourself. Quickly. That's what Rails.app should do.**

Cheat Notes

The problem is frustration at getting started and setting up your app. If we focus completely on the problem it becomes obvious that the solution should primarily educate, secondarily create.

Given this - I have some ideas:

Suggest "templates" for building a Rails app. "Traditional" with Rails/ActiveRecord/Test::Unit/Postgres with an explanation of what this setup is good for
"Highrise was built with this toolset" or something. Another template could be "Mongified" with MongoMapper (or Mongoid) and MongoDB. Each template would explain the design goals and why they were made, plus some live references.
Indexed reference to every Railscast ever created. 90% of the time when I get stuck - this is what unstucks me. Build in a summary and allow some linking over to Ryan's awesome site.
A reasonable, concise explanation of the more popular tools out there, what they're good at, and where their github repo is.
Integration directly with Github and perhaps some "git love" built in?
Integration with the Cheat Gem
Simplified and condensed Rails guides, built right in.
A StackOverflow search link that, by default, searches within the Rails tag.

That seems pretty good for now. Ideally the app could be used offline so it would be great to "scrape" the sources if the licensing permits. You could literally just hook in the Cheat Gem and go from there.

Now, if User X wants to use MongoDB with Rails - enter "Mongo" in the search box. What pops out would be:

The Mongo Template
MongoMapper, Mongoid (and whatever other gems) with explanations and github locations.
The Cheat Gem results for MongoDB The goal here is to give the user a "flavor" for what working with Mongo in Rails will be like - the gems involved, the issues people might have had, the love people are giving it. Which brings us to an interesting aspect of this application.Nothing is more compelling and useful then"love" from other users. There are a number of places to scrape "love" from (stop it) - but even if you just started with stats from Github (commit frequency, watchers, fork counts, open issues)
there's a lot of information to gather there.You could do an end user a tremendous service by gathering all of that and showing it next to each gem or toolset.

Get Going!

Ultimately the goal is to cut down the time "exploring" and "learning" by gathering the useful information, educating your user, and then getting them started. This is where Yehuda's idea takes shape:

Select a template or clone one, modifying it as you like (use Mongoid instead of MongoMapper). Share it on Github too (format TBD)!
The app creates a gemset, a .gitignore, set's up common configuration stuff, creates a deployment file using Cap (or whatever), installs your gems, initializes your DB and executes a core set of tests that act as guides to get you going.
If you don't like it, the app goes 100% backwards - erasing the DB, the files, the gemset and so on.
If you do like it - you're off and running!
As you build your app, you can come back to Rails.app for help as needed.

Think back to when you were getting started with Rails - it was one Google search after another, one blog post after another, trying to get up to speed (it's still this way for me!). The one thing you can truly do to make developers stoked with a Rails.app is to help them understand.I dunno! Maybe I should build this :).

Loading Data From The API - How Much Is Too Much?

2012-03-26T10:00:00-05:00

I'm really liking what's coming together with this Hypermedia-ish API. So many ideas and approaches are starting to come into focus. Like this one: how much structured data do I pass on the initial load of the API?

Data Or Code?

Here's the deal: the API i'm putting together for Alt.Tekpub is starting to "formalize" itself into an initial "burst" of data, with "auxiliary" stuff requested later on. At this point I need to reduce the chatter - so I'm handing down a structured JSON set from the get go:

You'll notice the "productions" bit is an empty array - that gets set by a query call later on.The thing I'm facing right now is this:

Do I organize the productions into semantic groups, then send? Or do I just send that information down and let the client do what it will?

Let's review the options shall we?

Option 1: Structure This In MongoDB

The interesting thing that's happening here... sort of... is that my API is starting to define a document structure that at some level I can just store and edit later on. If I went full tilt down this road, I'd end up with one document in my database.

And that's dumb.

The good news is that MongoDB helps you with this structuring and through a bit of Map/Reduce and some other means, I can whip out a nice API document and send that down. The bad part is that the API document would have lots of repeated data and basically be 100K bigger than it needs to be.

The code on the server is ridiculously light, but the code in the DB grows a bit. It's all javascript so... hmmm.

Option 2: Knit Up The API Using Node

That's sort of what I'm doing now. I can see how I could peel off a single "Tekpub" document and then assemble it with Node. The categories would have productions embedded, features would again have embedded productions, and the productions array would have yet more productions.

This is highly repetitive and again an extra 100K (which really isn't all that much). The engineer in me hates this. The UI programmer digs it as it's less client code I need to write...

Option 3: Roll It To The Client

Right now the productions have tags - so I can figure out rather easily how to pull out Microsoft, Ruby, Javascript stuff and so on:

Filtering The Ruby Productions

var _ruby = function(){
  return data.productions.filter(function(p){
    return p.tags.indexOf("ruby") > -1;
  });
}

The upside here is that the client has a lot more freedom in how to display the information. The downside is that I've shifted some responsibility "down stream" and that doesn't feel too good for some reason.

My Gut Feeling

It seems a good rule of thumb: less is more when you're coding... anything. Duplicating data just doesn't seem like any kind of win.

I talked to Derick about this today and his opinion was that "normalization isn't really a concern when doing an API load" and I agree - this puts a burden on the client to structure the data and it defeats the purpose of a sweet chocalatey API.

It's just not clear! The API has a notion of "Channels" and the link is just not obvious - that the "tags" on each production denotes a relationship to a "Channel".

What do you think? If you're a Hypermedia Cowboy... I'd really love to hear from you.

Alt.Tekpub: Working More With The Hypermedia (style) API

2012-03-22T10:00:00-05:00

Continuing on with building out a NodeJS app with Express and other buzzwords - I decided to build out a page using my API, while I build the API.

In Progress

I wanted to re-iterate, one more time, that this is a work in progress so some of the things you see me do won't make sense in a grander scheme. For instance - in production I probably wouldn't have the entire home page content load with $().ready() and a GET call to my server. That's kind of dumb.

Yet it makes sense if you want to be sure that you're giving your future clients what they need to build an app on top of your API. Let's see what that looks like.Also, I wanted to mention again the code is up at http://github.com/robconery/alt-tekpub. It's a major work in progress and it's there as reference, not for consumption.

Expanding The API

I've decided to build out a Single Page App and see what happens. I know this sounds stupid to quite a few people - but again this is a workout for the API mostly, helping it take shape. But what shape is that?

Let's put on our native (aka thick) client hats - pretend we're building an Android/iPhone app. You scroll around and find the Tekpub icon and press it. What do you expect to see next? Me, personally, I would expect to see (in terms of data):

Some sort of intelligent list of productions (intelligent meaning not just a data dump)
A sense of "state" - whether I'm logged in, what I can watch, my profile stuff, etc.

This means, basically, that the API needs to "prime" the application with a good amount of information from the start. Initially I provided a bunch of links (GETs) to pull production data as-needed, but this doesn't make much sense - the client apps will need this data no matter what.

In addition, I need to send down client information as well. If some type of token is passed in I can look the client up and populate the Customer stuff - I'm going to punt on that right now as it's really involved, I just want to take small steps for now.

Let's switch over to the client now - see if what I'm musing makes sense. I'll be using basic Javascript/CoffeeScript at this point - you'll see both as I haven't really made up my mind as to which I'm going to use.

The Client

I'm going to build the client bits out in CoffeeScript as I don't know Objective-C and I think I can approximate a decent Client/Server situation using Javascript.

The first thing I need to do is make sure the API is exposed. I've already created an API route and wrapper (which I'll refactor later) - and if I go to localhost:3000/api I get a lovely splash of JSON:

Previously I stated that I couldn't bring myself to use a $.get() to pull this code down - favoring a preload instead. I'm going back on that for now as I want to see how responsive this API is.

But how do we consume this?

Looking over the JSON, it's a nice description of Tekpub and what you can do with it. So let's create a Tekpub object:

The Basic Tekpub API Object

class Tekpub
  constructor: (preload) ->
    @special = preload.productions.special
    @featured = preload.productions.featured
    @blurb = preload.blurb
    @title = preload.title
    @customer = preload.customerwindow.
    Tekpub = Tekpub

In short, this function literal will take a preload of JSON data and set some literals internally. This means that my blob of JSON has to be organized to distinguish "special" and "featured" productions. I didn't have this before - what I had was GET urls for loading this data.

Let's switch back to the API in Node and see how this can work. This is written in Javascript.

The API

The overall approach is starting to crystallize a bit in my mind. I'm going to preload an object on the client with JSON so it can operate as needed, right from the start. I don't want to go too far, but here's what I think is reasonable: Load all productions.

I don't know how the client will want to use them - just send them all down.Run the filters for the client - no need to make the client do the filtering. I could send the criteria down for the filtering, but that's putting a bit too much in the hands of the client. Yes, I know it's a bigger JSON load but it's not that much, really.

I need to send some stubbed Customer information. Sorry for the huge picture here - it's a lot of code. I'm using a picture because this will change, I'm sure of it:

One thing to notice: "productions.all" is stubbed. Same with "productions.featured.productions". This object literal here is a bit of a "template" if you will. The "_execute" function will populate it:

The API Execute Method

  var execute = function(callback){
    Production.all(function(err,response){
      result.productions.all = response;
      special = response.filter(function(p){
        return p.slug == "ftspeaker";
      });
      result.productions.special.production = special[0];
      result.productions.featured.productions = response.filter(function(p){
        return p.slug == "mvc3" || p.slug == "fttriageoren" || p.slug == "ftspeaker";
      });
      callback(null,result);
    });
  };
  return {
    execute : execute
  }

We're hitting the database (Production is an object that abstracts basic queries - I'll talk more about that later) and pushing the resulting docs (response) into productions.all. Then, we're filtering those results, dropping them into featured and special.

This will work for now - not sure how well it will scale if we move to 1000 productions :) but it makes a nice proof of concept.

Now that we have the data - let's wire up the Client.

Back To The Client

I don't like having templating script blocks all over the view pages. They look a bit wonky in my mind, so I'm going to put them into partials. I'll create two partials: specialTemplate and featuredTemplate.

Tekpub has the notion of a "Special" production - one that we're exceedingly proud of. So let's build that template and stick it onto the home page (again, this will change so I'm just snapshotting the code. If you want it, it's up at github):

This is Handlebars.js - it's exceedingly fast and pretty easy to understand. I'll inject the "special" data into it, and it will render out the production YouTube preview as well as some nice quotes.

Next, I need to render it somehow. I can add this to my Tekpub client object:

This code takes the JSON assignment (preload) and renders a template that I specify. I'm trying to lean on conventional naming so I don't need to execute the same template rendering code all over the place - but in short loadTemplate() will find the "specialTemplate", compile it, and then render it with the "@special" data - which is populated in the constructor.

Now I need to do the same for featured.

There's something tricky going on here. Notice the "include" statement? That's how the Jade ViewEngine works with partial views. I know I'll be reusing that production view and I'm trying to keep these templates as clean as I can. So I need a 3rd partial to work with - and I'll call it simply "production.jade":

Things are really starting to take shape. I have my views, my partials, some client script and an updated API. Let's make it work.

Hooking It All Up

Back on the index view (my home page) I need to render out the partials, as well as make sure that I'm calling the API and loading up my Tekpub client object with the API data. Might seem like a lot - but my view is exceedingly light. LOVE IT:

I have to say - that was pretty easy and took me about 2 hours to stitch together.

Have a look:

Thoughts

I always look for a time during an "exploration process/spike" where things start to flow and make sense. This was one of those times. The lightness of the code (in my eyes) and the way I was able to hand off small chunks of process and layout - it really felt good to me.

One thing in particular that I wanted to dive into was using CoffeeScript alongside Javascript to actively build something out. Specifically I wanted to see if the negative things were actually negative things. I did get tripped up a bit once or twice - but in the end, reading the Tekpub class code above was more than compelling for me.

I like the aesthetics of it. Then again, I also like Ruby. What do you think?

Also, as I was building this out I was starting to see the divide between what Backbone can handle, and what I don't need Backbone for. Simple presentation like this - I don't need Backbone for. However when it comes to adding things to an Invoice, switching the view around for previews/downloads and purchases - yeah Backbone will work great.That comes next.

CoffeeScript or Straight Up Javascript? It's Decision Time

2012-03-21T10:00:00-05:00

One of the perils of riding blind into the Wild West of Web Programming: Everyone has an opinion on what you should do. What tool you should use, what language you need to flex. It's almost as if they don't want you here...

Decision Time

Up to now I've been using CoffeeScript mainly for my tests - such as they are. I find it highly descriptive and easy to read: a must when reviewing a test suite. This instantly brings up two questions:

If it's so readable and descriptive, shouldn't you be using it always? Javascript is offensive.
It's sad that you think Javascript isn't readable. Do you code often?

I've had equally passionate, stubborn, smart, friendly, and overall lovely devs hit me from either side of the CoffeeScript divide. One friend told me he couldn't read my test suite unless I used CoffeeScript ("what's with the noise dude?") and another ask me if it's possible to see the generated JS so he "could read it with some level of sanity".

I want to reiterate this: both of these guys are well known, super-smart developers as opposed to the thrash/bash crowd on Reddit or HN. These are my friends. Each is suggesting (strongly) I should "choose a side and grab a pistol".

I'm leaning towards that. It doesn't make sense to have both - I want to pick one and move on...

They Keep Pulling Me Back In

I've tried to avoid this decision because, frankly, I think it's overheated and runs the risk of derailing my entire effort here.

Consider: If I choose to go 100% with CoffeeScript, the hard-core JS crowd will ... be the hard-core JS crowd and dismiss the efforts thus. If I go with pure Javascript I'll end up writing (overall) more code - if only for the lack of syntactic niceties from CoffeeScript - as well as alienating the folks who've come to heavily prefer CoffeeScript.

And no - these aren't people who are afraid of anything - they are some of the smartest people I know.This is about the time where I'm reminded:

CoffeeScript is just Javascript. Get over it.

Cheers - consider me the Cow jumping over your condescending Moon. CoffeeScript is Javascript - except that it's not. It's CoffeeScript. It becomes Javascript and I'm well aware of that. Pedantry aside, let's move on.

The only way to intelligently ponder this issue is to distill the rhetoric and see if there's something compelling that I can ... drizzle with my experience. Let's do it.

CoffeeScript Sucks

This seems to be the canonical rebuttal against the use of CoffeeScript. I appreciate the author's candor and detailed approach to what he sees as a shortcoming in CoffeeScript. Let's see if I can work this down to something croonable.

Debugging.

The author points out that debugging a problem involves looking at the compiled JS and then stepping back into CoffeeScript to see where you messed up. This is a reasonable point: by using CoffeeScript you've just added syntactic complexity to your application: You could have a CoffeeScript error during CoffeeScript compilation that you need to solve. This, by definition, wouldn't happen if you weren't using CoffeeScript.

You could have a logic error you need to figure out, and now you're climbing through 2 stacks instead of 1. If you're working in the browser this can be an issue, to be sure - you'll have to debug the generated JS, not the CoffeeScript. If you're working in NodeJS (which understands CoffeeScript) - you can get "odd" error messages returned that lack syntactic guides as to where the problem is. Not a very big issue - but it slows down the overall development process.

Believe it or not - this problem is seen mostly in testing. It takes some time to get the hang of writing CoffeeScript tests and understanding the output if there's an error. Sometimes it's helpful - other times it's simply not. For instance - it's all too common a mistake to use a "var" keyword when declaring a variable in CoffeeScript. This kind of thing is pounded into your head when writing Javascript to avoid global naming issues.

Consider this code here (a mocha test):

If I run this, I receive an error:

Word is not defined? Of course it's defined! It's VAR dude! Oh right - there is no var is CoffeeScript!

Sure would be nice if the error message said that. And yes - it's a bit of a nit, to be sure. But when you read this output when running a test - wouldn't your first inclination be to check your code under test to see if there's a problem?

Notice that I have no line numbers here. I do have a file reference which works - but it's not nearly as clear as the same kind of output from Mocha if you have an error in straight-up Javascript.

This kind of thing slows you down a touch, and it does happen. I don't like going slower.

Readability != Comprehension

One point that's majorly in CoffeeScript's corner is the ability to read quickly what the code is trying to do. This is especially hard in Javascript given the event loop and asynchronous structures the language leans on. Yes, if you're Batman you can read Javascript quickly and surmise the code's purpose.

But that's reading code - and it's quite different than "readable code" as dumb as that might sound. In the Ruby community, Rubyists will thrash themselves to make a chunk of code aesthetically pleasing as well as immediately "grokkable". This is the goal of the language, and I find it to be amazingly compelling.

C-based languages were written to be understood by machines, not humans, so there's a gap there. But let's get back to the point: is CoffeeScript more comprehendable than Javascript?

This is an excerpt from Ryan Florence's blog (it's beautifully laid out btw):

My takeaway from this is:

If you like C-based languages and you know Javascript deeply enough that glyphs make sense and you don't mind extra punctuation, use Javascript.But... Use CoffeeScript if you're averse to C structures and glyphs add noise to your code and you don't want extra code in your code for doing mundane stuff.

Remember, we're talking comprehension here, not syntax excitement. Which sentence sat happier in your brain? If we're going to get literal on comprehending editorial intent: it's a hard and fast rule that you start with a premise and build on it. That's writing 101 (and speaking 101 for that matter): lead with the punchline (or abstract) and then make your case.That's what CoffeeScript favors. But this is a small, silly example anyway.

Throw in the function() keywords a few times with some braces, parens and semi-colon eye-stabbery, then we can talk about "comprehension".

Overall I find this latter point a bit weak - yet it is a point: if you know/like/love C-structure, then Javascript is your buddy.

The rest of Ryan's post amounts to arm-waving about "what others might do" and how CoffeeScript allows you to shoot yourself in the foot if you point a gun at your foot and pull the trigger. Not terribly convincing stuff. Let's move on to Javascript.

You're Stuck If You Don't Know Javascript.

This is more my thought then Ryan's (and is common knowledge as well) - but I'll throw it in: if you don't know Javascript and you use CoffeeScript... you're in for trouble. This probably means you were weaned on Ruby/Python and you're hoping CoffeeScript will shield you.

This is a bad choice. If you don't understand the thrash-fest that is Javascript not defensively-written, you'll be in for a nightmare. It's true that CoffeeScript shields you from a lot of Javascript's warts - but you really need to understand those warts (and what you're avoiding) should you ever get backed into a corner.

Thinking logically - if you need to know Javascript in order to use CoffeeScript - why use CoffeeScript at all?

That, to me, is a very very compelling question. I can get over the code noise, and I can figure out the good patterns - so why mess with an interpretor? It seems like extra work for what amounts to syntactic sugar... is it really worth it?

Javascript Sucks.

I come from a C-language background (largely C#) so braces/punctuation don't scare me. I can scan Javascript quickly and understand most of what's happening - and I actually find it much more "legible" than CoffeeScript.

function()

I don't need to add much to this. I've pondered just how much I've written the word "function(..)" over the past years - and a thought occurred to me:

If I had a nickel for every time I wrote "function()", I could almost fill the void that is Avery's head.

(this is a derivation of a joke: "what would you rather have: 1 million dollars or Avery's head full of nickels" - it's a tough question).

I don't mind writing the word, I mind the repetition of it. Javascript is a functional language. As such your write... FUNCTIONS. Having a keyword called "function" seems a bit ridiculous. I'll get some hate for this - you can write me a little hate function and see how many function keywords you can use.function()

Moving on...

Aren't We Trying To Move Forward?

I was talking to a friend the other day and he just flat out said it:

I don't get why people like Javascript. It's a Neon and Acid Wash language

Again - this is a very smart person with way more experience then me reflecting on how Javascript is a language that's fascinating on some levels and, frankly, had its day. Many people love it, have come to terms with its existence - do we really need to go there again?

This opinion, while a tad blunt, isn't completely without merit. The language has flaws - flaws that are quite glaring and ones that will bite you by default. Global leaks, scoping issues, inconsistencies in comparisons and equality... this is all well known stuff.

When I started using Ruby (and Python... for a bit) it was such a fun exploration of what a modern, dynamic language could do. Learning those languages was joyous! Working with Javascript has been ... well a difficult walk down a painful memory lane for me (personally).

I find myself enjoying Node a lot - Mongo too. It's really fun to be learning and helping in a growing ecosystem. But... Javascript... it's so hard for me to look at the code I write and feel the same level of excitement and engagement that I did with Ruby.

Of course - this is my personal opinion and I know there are good parts (and yes I've read Crockford). My point here is that Javascript has a tarnished past. I know people are trying to spread Good Habits and that's exciting... but it also has its negative aspects.

There's a lot of elitism, snottiness, and overall pedantry in the hardcore Javascript crowd. Accidentally write a global variable and put your work out there for all to see... look out.

What To Do?

I'm on the fence here, but I feel compelled to make a choice. I'm leaning in the CoffeeScript direction because I enjoy the terser syntax and the Ruby aesthetic, but I also know that there will be times when it slows me down.

I'd love to hear your feedback, but please (as always) provide some reasons I can sink my teeth into and think about. Opinions are welcome too - just try to balance them on things other than links and quotes.I'll be moderating this thread heavily.