-- Geeks, drugs, and deception. An entertaining look into the (fictional) lives of techno con artists, and how a recently-fired comic book artist get pulled into their inner circle.
"
-- Particularly useful reference when trying to eek out a few extra milliseconds of load times in older browsers.
-- Interesting tech, and somewhat engaging, but disappointing ending (or lack thereof.)
, by Neil Strauss
-- An engaging, first-person account on transforming from an urban writer into "Jason Bourne."
, by Cory Doctrow
-- A high school hacker fights the 'Department of Homeland Security' to reclaim American civil liberties after anti-terror tactics are taken to a new level.
-- Techniques-for, and the value-of sketching interactivity before developing products. Good ideas. OK book.
" -- About finding untapped opportunities in your market and repositioning yourself to capitalize on them. Easy to grasp; Longer then it needed to be.
" -- A thin book with some good best-practices, but a little disappointing. Perhaps it's JavaScript's fault, not the author's ;-)
" -- Good overview of usability issues in designing HTML forms, backed by examples and eye-tracking research. I bought the 
" by Marshall Goldsmith
-- Discusses interpersonal skills (and how to identify and fix them) that most commonly hold executives back in their career advancement.
"
-- Lesson: Cut the corporate B.S. and stop wasting your time. Focus only on what matters most.
"
-- Lessons on handling tough conversations: firing people, relationship problems, hostage negotiations (well, maybe not that last one.) Wasn't an exciting read, but I've been paying more attention to "turning points" in conversations since reading it.
"
-- Lessons in building reusable ("pluggable") Django applications. Assumes you know the basics of Django and Python.
"
-- I really enjoyed this one. Lots of suggestions and strategies for negotiating.
Every time I hear stories about runaway cars, I’m reminded of the eX-Driver anime series http://en.wikipedia.org/wiki/%C3%89X-Driver
Updates from erik RSS
-
erik
-
erik
glad my pre-”drive by wire” car only “suddenly accelerates” when I ask it to. Mechanical controls FTW!
-
erik
Really interesting UI for an IDE:
http://www.cs.brown.edu/people/acb/codebubbles_site.htm Great for wall-sized, multi-touch displays ;-) -
erik
careful out there — it’s hailing downtown!
-
erik
Internet Explorer: Global Variables, and Stack Overflows – File away under "Obscure details to remember about bizarre JavaScript behavior in IE" — this case, " any recursion that happens through the window object is limited to a stack depth of 12" -
erik
Cocoa Text System – Nice examples on how to modify OS X keybindings. I didn't realize you could define macros like this. -
erik
Teambox | Project collaboration – Looks like a nice way to collaborate on projects. I like the use of short status messages (ala Twitter) and simple task lists. -
erik
I expect future cars to have location-aware speedometers that display your current speed relative to the speed limit of the road you’re on
-
erik
enjoying the surprisingly heavy snow — almost doesn’t look like Texas outside
-
erik
jsmacro 0.2.3
The latest jsmacro (v0.2.3) adds support for “else” clauses to “if”, “ifdef”, and “ifndef” statements. Combine this with the command-line variable definition support and you can now do fun things like this:
//@ifdef IE6_BUILD ...custom IE6 code here //@else ...code for other browsers here //@endOf course, this goes against the idea that your JavaScript would remain usable for development without needing to be processed, but it’s just an example. Longer term, I hope to have a different approach available that will allow conditional code substitution so that browser specific optimizations won’t get in the way of an easy development/test/debug process.
-
erik
“Coders at Work”
I finished reading “Coders at Work“
last night. In it, author Peter Seibel interviews 15 legendary programmers, discussing how they got started with computers, how they learned to program, how they read and debug code, etc. The interviews cover a wide range of opinions and approaches, and offers a fascinating look at “computer science” history.
The format of the book is a little unusual, in that it’s entirely interview transcripts. No analysis. No author-interpretation. Just recorded conversations. At first it’s a little surprising that one can publish a book like this; But then you get into the content and it’s wonderfully engaging. Analysis and interpretation would just get in the way of letting these folks talk. Reading direct quotes makes the content all the more exciting.
The book isn’t for everyone (obviously), but I rather enjoyed it. There’s some great stories about the history of our profession, and many topics raised that inspired additional research. (I went out and found a number of research papers referenced in the interviews, and bookmarked a lot of content for further exploration.) There’s also a fair amount on the history of different programming languages, and I have a fascination with programming languages, so it was a great fit.
A few take-away themes and ideas:
- While programming was no easy task in the early days, at least it was possible to fully-understand the hardware and all the software running it (as opposed to modern computers.) The modern computing environment presents very different challenges to present-day programmers, especially those new to the field.
- Even some of best use print statements.
- Passion and enthusiasm separate good programmers from great ones.
- In academia, you have time to think about the “best” solution, without the deadlines imposed on commercial developers.
- There’s certainly a component of “doing great work” that requires being in the right place at the right time — sometimes it’s just a matter of getting staffed on the right project.
- There’s some negativity towards C/C++ in here, mostly due to it’s negative impact on compiler and high-level language development. (i.e., one school of thought is that you give people a high-level language and make the compiler smart. The other is that you give people a low-level language and let them do the work. Unfortunately, humans aren’t so good at hand-writing code optimized for concurrency, but once you have a language that let’s them try, it’s hard to fund compiler research.)
Here’s a few of the quotes I highlighted while reading:
“One of the most important things for having a successful project is having people that have enough experience that they build the right thing. And barring that, if it’s something that you haven’t built before, that you don’t know how to do, then the next best thing you can do is to be flexible enough that if you build the wrong thing you can adjust.” — Peter Norvig
“…there are user-interface things where you just don’t know until you build it. You think this interaction will be great but then you show it to the user and half the users just can’t get it.” — Peter Norvig
“I get so much of a thrill bringing things to life that it doesn’t even matter if it’s wrong at first. The point is, that as soon as it comes to life it starts telling you what it is.” — Dan Ingalls
“…a complex algorithm requires complex code. And I’d much rather have a simple algorithm and simple code…” — Ken Thompson
“If you can really work hard and get some little piece of a big program to run twice as fast, then you could have gotten the whole program to run twice as fast if you had just waited a year or two.” — Ken Thompson
“if they’d have asked, ‘How did you fix the bug?’ my answer would have been, ‘I couldn’t understand the code well enough to figure out what it was doing, so I rewrote it.’” — Bernie Cosell
“You have to supplement what your job is asking you to do. If your job requires that you do a Tcl thing, just learning enough Tcl to build the interface for the job is barely adequate. The right thing is, that weekend start hacking up some Tcl things so that by Monday morning you’re pretty well versed in the mechanics of it.” — Bernie Cosell
“…computer-program source code is for people, not for computers. Computers don’t care.” — Bernie Cosell
“if you rewrite a hundred lines of code, you may well have fixed the one bug and introduced six new ones.” — Bernie Cosell
“I had two convictions, which actually served me well: that programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do” — Bernie Cosell
“You never, ever fix the bug in the place where you find it. My rule is, ‘If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine?’” — Bernie Cosell
“Part of what I call the artistry of the computer program is how easy it is for future people to be able to change it without breaking it.” — Bernie Cosell
-
erik
textorize: Pristine font rendering for the web – OS X command-line tool (in Ruby) for rendering bitmap text. -
erik
manuel’s cyberlisp at master – GitHub – "A Lisp-to-JavaScript compiler" -
erik
django-devserver – GitHub – A replacement for django's runserver that supports additional debugging/profiling for request handling. Could be handy in development. -
erik
jsmacro 0.2.2
jsmacro 0.2 was a full rewrite (because version 0.2’s are always a full rewrite.) It’s now a little closer to what I was originally thinking. Instead of a line-by-line state machine, the parser now uses regex, and dynamically calls macro-handling methods based on the name of the macro. That’s a little vague, but in practice it means that extending the macro language is easier, and it may be possible to do it on-the-fly (as in, writing new macro implementations within the JavaScript source file that’s being parsed — which is a geeky goal I’m going for.)
Other new additions:
- Test files are now picked-up automatically when named correctly. This makes it painless to add more tests.
- Added support for setting DEFINE flags from the command-line. Handy if you automate builds for different environments (like IE6 vs. the rest of the world.)
- Added support for #ifdef and #ifndef
The next big hurdles will be how to handle
elsestatements, and coming up with a reason to implement some type of #inline capability. -
erik
XUI | javascript micro-framework – A JavaScript "framework" for mobile devices. Something to dig into later… -
erik
Bummer, the iPad SDK is for paid developers only.
-
erik
Common Lisp: A Gentle Introduction to Symbolic Computation – Yet another Lisp book. Apparently I can't get enough of these… -
erik
jsmacro — an oddly named JavaScript preprocessor
For awhile now I’ve wanted a JavaScript preprocessor to conditionally include debug and testing code when needed. It’s always registered as merely a “nice to have”, so I hadn’t sought one out. However, I had a little time over the weekend and wanted to play with the idea, so here it is: jsmacro (on GitHub.)
[Note that before writing this I did seek out existing implementations, and found js-preprocess to be the most interesting; However, I needed something that would work as part of an existing build chain, so authoring the tool in Python instead of JavaScript made more sense.]
Currently, jsmacro is poorly named, as I didn’t write the macro system that was in my head. Instead, it’s currently a basic preprocessor supporting only DEFINE and IF statements, which happened to be all I needed at the time. Usage works like this:
Input JavaScript
//@define DEBUG 0 var foo = function() { //@if DEBUG alert('This.'); alert('That.'); //@end print "Hi"; };Pass the above JavaScript through jsmacro from the command line like this:
./jsmacro.py -f infile.js > outfile.js(assuming the files are all in the same directory), and you get the following:Output JavaScript
var foo = function() { print "Hi"; };The tool has registered the variable ‘DEBUG’ as 0 (i.e., false), so the conditional include statements omit the alert() calls. If DEBUG had been set to 1 (i.e., true), the alert() statements would remain (though all jsmacro instructions would be removed either way.)
One of the tricky things about doing macros or preprocessing in JavaScript is that I wanted the code to be valid JavaScript before the tool is run (which is why C-preprocessors won’t work.) The idea is that you develop as you normally would, but wrap your debug and testing code in conditional jsmacro statements so that they are automatically removed as part of your build process.
There’s nothing fancy about the current implementation (it’s a crude state machine that scans line-by-line, top-to-bottom looking for regex patterns and deciding whether to output the line of not.) Crude as it may be though, it completely solved a problem for me, and hopefully it will help you out as well.
-
erik
JavaScript speedups in Firefox 3.6 ? Mozilla Hacks – the Web developer blog – Nice summary of the performance improvements in FF 3.6's JavaScript environment.