Hangover.js

5,105 views

Published on

hangovers and javascript, together at last

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
5,105
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
9
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Hangover.js

  1. 1. hangover.js @alunny Friday, June 17, 2011 hey guys. I’m andrew lunny and this talk is called hangover.js i apologize to Jonathan Julian - hopefully he’s in the crowd here and can accept my contrition - but I didn’t come up with the title. he had one last year, but the content doesn’t overlap
  2. 2. me • chief n00b @ nitobi, vancouver bc • phonegap and stuff • build.phonegap.com Friday, June 17, 2011 i work at nitobi up in vancouver bc. i have a humorous job title to compensate for my meagre salary. we have a project called phonegap for building native mobile applications using web technologies. i work on a web service called phonegap build that does that in the cloud. but I don’t wanna talk about any of that
  3. 3. • shitty code is a social problem, not a technical one • heuristics, not solutions too long; don’t listen Friday, June 17, 2011 this is not gonna be a technical talk; it’s too early in the morning. this is gonna be a hand- wavey bullshit methodology thing, with a lot of clip art. it’s about why we have so much shitty javascript code i encourage everyone who wants an espresso or something to go line up for that now, rather than listen to me
  4. 4. If there’s something you don’t like Friday, June 17, 2011 if that sounds dumb, you should probably stop listening to me this was almost halfway funny at jsconf. not a whole lot
  5. 5. a hangover Friday, June 17, 2011 anyway, hangovers
  6. 6. Friday, June 17, 2011 there’s a really great book called Everyday Drinking, by Kingsley Amis. it’s a lot of good writing about some important topics. and it does cover hangovers one nice point mr amis makes is to distinguish between a physical hangover - so, having a headache, or a full body ache - and a meta physical hangover. so what’s a metaphysical hangover?
  7. 7. An ineffable compound of depression, sadness anxiety, self-hatred, sense of failure and fear for the future. Friday, June 17, 2011 this is what he says about a metaphysical hangover: [read quote]
  8. 8. huh Friday, June 17, 2011 now why would I mention this
  9. 9. oh yeah, JavaScript Friday, June 17, 2011 well we are at a javascript conference. do we write some javascript that gives us a metaphysical hangover? or am I stretching this metaphor a bit too far, especially at this hour? if i have one point today, it’s that JS is a self-loathing language. I’ll try to make a case for that, and we’ll see how that goes over the next fifteen minutes
  10. 10. Friday, June 17, 2011 so you guys all know ryan dahl, i assume, and he had this enigmatic tweet on the first night of jsconf. who knows what he really meant, i think he meant jsconf is like a prom for javascript developers. and ryan’s really smart, so I’m gonna assume that that’s insightful. we should probably take another moment to consider this tweet. [pause] has everyone had ample time to consider that?
  11. 11. #jsconf is fun Friday, June 17, 2011 there are lots of great things about jsconf, but i think the best is that you get a vacation from your application code you see all these cool open source projects and frameworks, and how much it would be to hack on them. you hear about new browser APIs and all the cools stuff that can be done with them and the thing that’s great about all this is you see the new sexy stuff in lightweight, hello world demos, which are always super attractive, because they’re empty codebases
  12. 12. new codebases Friday, June 17, 2011 new codebases are like robert smith, the lead singer of The Cure, during the 1980s. They’re slick, they’re stylish, and they’re exciting. They make you want to keep writing code. and that’s the feeling I’ve always gotten from attending jsconf
  13. 13. work sucks Friday, June 17, 2011 Unfortunately, when you return from jsconf, you get the same applications you’ve been working on for months. and there are TODOs and FIXMEs and whatever else covering over the crufty parts you don’t really have the time or the inclination to fix it, and there’s other shit you’ve gotta get done, so you just ignore all of the problems - the broken windows, in the pragmatic programmer terminology - for the time being, at least, in favour of immediate concerns incidentally, this may be the dumbest and the most inane slide in the history of jsconf. i realize this is a bold claim, but i have 3 different pieces of clipart in there, including one microsoft word licensed photograph, and the slide’s title is “work sucks” what this boils down to is that, you know, at work, we deal with old codebases
  14. 14. old codebases Friday, June 17, 2011 this is because old codebases are like robert smith, lead singer of The Cure, in this century: flabby, dishevelled, unmaintainable and frankly embarassing. and nobody in their right mind would want to be seen anywhere near them (I do still like The Cure, even if they have gotten a bit older)
  15. 15. • depression • sadness • anxiety • self-hatred • sense of failure • fear for the future Friday, June 17, 2011 so we this is the javascript hangover, with concomitant symptoms [list symptoms] this makes us unhappy, as you can tell from the sad man in the picture
  16. 16. examples Friday, June 17, 2011 I’m talking in a lot of generalities-- it would help to see some actual bad code in particular, I want to show you guys the code I hate the most of a project I regularly work on, and that I’ve been too lazy to fix
  17. 17. function GetFunctionName(fn) {   if (typeof fn === "function") {     var name= fn.name;" " if (!name) {       var m = fn.toString().match(/^s*function s+([^s(]+)/);       name= m && m[1];" " } " if (name && (window[name] === fn)) { " " return name; " } else { " " return anomToNameFunk(fn); " }   }else {   " return null;   } } Friday, June 17, 2011 this comes from the bowels of the phonegap-iphone repository, and annoys everyone to no end so this function takes a function as an argument, and returns the name of the function. sounds great right? no, it’s horrible firstly, it does a lot of unnecessary checks. if it’s a function declaration (it says function foo, not var foo = function), name property will be set on the function. otherwise, anything involving the local variable name will be spurious and unhelpful if it manages to resolve that function name, it resolves the name that it finds. otherwise it calls a new function, that must be good i’ve highlighted this anonToNameFunk, with a k, function, so let’s look at it
  18. 18. var _anomFunkMap = {}; var _anomFunkMapNextId = 0; function anomToNameFunk(fun) { " var funkId = "f" + _anomFunkMapNextId++; " var funk = function() { " " fun.apply(this,arguments); " " _anomFunkMap[funkId] = null; " " delete _anomFunkMap[funkId];" " } " _anomFunkMap[funkId] = funk; " return "_anomFunkMap." + funkId; } Friday, June 17, 2011 so this function anomFunkMap takes an anonymous function, creates a unique identifier for it, creates a new more-or-less bound function for the anonymous function that then deletes the reference to itself in the anonymous functions... i know, i know ... then assigns the newly bound function to the function map and returns NOT the identifier of the anonymous function in the map of anonymous functions, but the string to evaluate to find the reference to the particular anonymous function within the map of anonymous functions this is horrible
  19. 19. Friday, June 17, 2011 that was horrible. here’s a picture of a man literally surfing the web.
  20. 20. good cop bad cop Friday, June 17, 2011 rather than talking about that, let’s go on another tangent. I think JavaScript is a good cop bad cop language. the language itself - in terms of the semantic and syntactical features - give a wide degree of freedom and expressiveness to developers. but the community, for many entirely valid reasons, restricts the freedoms the language gives to the developers. either backwards compatibility, memory usage, or just the size of the code restricts what is recommended for client-side JavaScript code actually, in the JS community, this good cop bad cop thing is easily personified
  21. 21. good cop bad cop Friday, June 17, 2011 we have good cop brendan, who tells us about these cool new language features we can adopt to improve the expressiveness and beauty of our code then we have bad cop crockford, who tells us our code is shit and we should stop trying to be so clever. also, we should be worried about security
  22. 22. No solutions Only heuristics Friday, June 17, 2011 I touched on this earlier, but there’s not a single solution to badly formed JavaScript code. There’s not a one-time that you can pay off. There are only patterns, or heuristics, that we can follow every time we write code, and hope that we succeeed.
  23. 23. How to lose weight without diet or exercise Friday, June 17, 2011 It reminds of an old joke - how do you lose weight without changing your diet, or taking on any exercise
  24. 24. How to lose weight without diet or exercise Friday, June 17, 2011 and the correct answer is disease you can follow the better practices, or you can do things the hard way
  25. 25. How can I avoid bad code? Friday, June 17, 2011 so this is an obvious question, and the answers are well known this image is copyright shutterstock, incidentally
  26. 26. How can I avoid bad code? • write tests • write docs • don’t write long functions • keep execution stacks small • don’t be a doosh Friday, June 17, 2011 The best recommendations are obvious ones: write unit tests, document your assumptions, avoid long functions or big execution stacks, and don’t code like an asshole. Those are easy to suggest, but hard to follow.
  27. 27. heuristics require discipline and dedication there’s no shortcut Friday, June 17, 2011 these lessons are well known among most developers, but social problems make it difficult to enforce the best practices if there’s one thing you take away from this talk, it’s that those practices are best practices for a reason. and they certainly pay off the initial effort.
  28. 28. cheers & bye Friday, June 17, 2011 so that’s me done. thanks everyone

×