I foolishly had lost my admin password for my Macbook Pro, OS X 10.6.6 and needed it urgently to install some new software.
Did some research and found many complicated, potentially harmful ways to “recover” your password. Some involved booting from the install disk (which I don’t have), with others you would end up losing all of the files in you user account, etc.
Finally found this tutorial, which is
works like a charm
doesn’t muck anything up or lose files
Saved me a lot of time and grief, could do the same for you.
A true story: first interview
About ten years ago I interviewed a programmer candidate for some dev work. His code truly sucked: he had a very basic grip of procedural programming and that was about it. A for loop was at the absolute limit of his skills, and he had never heard of Object-oriented programming. And this was a very hoary, established approach by this point. Of course, we could not hire him.
But, he seemed like a nice and intelligent fellow and I felt bad that he had no idea what he was doing. I tried, gently, to explain how he was really very much a beginner, and that he should look into OOP, recommended a book or two, and we parted ways.
10 years later: second interview
I am interviewing a candidate for a job at my then current company. It was the same guy! This was an amazing occurrence. What a great opportunity: I could see what he’d picked up in the decade since we last spoke, and just imagine what a motivated person could learn in 10 years!
And what he’d learned was: not a damn thing. He’d learned a new technology, true, but his code was just as gormless as it had been 10 years ago: still no inkling of basic OOP, design patterns, naming conventions. It’s like he had been in a programming time capsule.
10 years is a long time! 10 years!
This made me very sad. He could have become a master of his craft in that time, but that decade of experience added up to very very little.
I’ve worked with and managed many programmers. Some are more intelligent or have a better working memory, but the ones who are truly successful are the ones that continue to deliberately work on their craft. I’ve seen middling junior programmers (at a similar level to the schmo of my story) become very good programmers in a few years, simply by deliberately trying to be better. Reading, seeking input from senior developers, working on good coding habits, classes, and a focused desire to get better are all anybody needs.
In 10 years, anybody can become an excellent developer.
Similarly, if you do not improve over 10 years, your value as a programmer will be close to zero.
If you are not getting better, you are getting worse
If you’re going to stay in tech, you’ve got to continuously improve. New technologies and approaches come out constantly. It’s not enough to learn one technology stack and one approach: no matter how good you are now, you will get left behind in a few years. And, the more you learn, the more you will enjoy programming!
For a much more detailed and inspiring exploration of this topic, see this classic article: “You and Your Research”
I gave a talk with Joe Ferrari, my co-conspirator on a pretty complicated iPad app that we built with Adobe AIR 3.2 in just 8 weeks. Joe doing most of the work, and we had some help from another dev as well. It was a small but appreciative audience. I personally love to see case studies and would like to see more of them.
The app has confidential client stuff so I can’t show or talk about any of that, but we can share our slides from the presentation. I’ll update this post later with some helpful links that I haven’t had time to organize.
Keynote users all too often get a terrifying message “This isn’t a valid keynote document” and are then screwed, having no way to open or fix their toiled-upon Keynote presentations. This happened to my wife last night and it took me a while to track down the answer, which is pretty straightforward.
If you get this issue, don’t worry! The answer is described perfectly here:
Hopefully this post will make it a little easier to find this information.
And, boo to Apple for not fixing this glaring hideous bug.
Went to a great talk last night at the Eyebeam Center given by some of the Google Data Arts folks: Aaron Koblin, George Michael Brower, and Jono Brandel.
They showed how to set up a scaffolding for playing with Canvas2d and the amazingthree.js. One of the great teachings was how to set up the main animation loop in your HTML5 project.
You can use a timeout, as most people do, but that always felt “tacky” to me. It turns out there is a draft spec for a feature that gives a more natural way to code this: requestAnimationFrame
It’s dead simple to use and makes for much more elegant code. The fallback implementation is to use timeout, so it works on all browsers. Where it is fully implemented however, your app will behave nicely and won’t update when the tab is not visible, which is great!
The code you need has been made available by the always helpful Mr. Doob, in requestAnimationFrame.js
This is all that it takes, go nuts kids!
Be aware: you can’t be sure what the resulting frame rate is, it might be 30 fps, 60 fps or something else. But it’s bad practice to program to frame rate anyway, you should always be animating in terms of time.
Paul Irish has a much more in-depth explanation of this approach.
My Firefox was updated to 4.0.1 at work, against my will, which broke many of my installed plug-ins, and introduced me to this new annoyance:
I researched and found that they introduced a new feature in Firefox 4 intended to protect Flash from crashing the whole browser. This is laudable, but I find that the Flash Plugin (debugger) has become so unreliable that I’ve had to switch to Chrome if I want to look at any videos or other Flash content.
On April 20th, Miguel Cordones, Kevin Lockwood and I co-presented on Appcelerator at the weekly flashcodersny meeting. We were discussing the Appcelerator training course we’d just taken a few weeks before, the first to be offered in New York City.
What is Titanium Appcelerator?
The training was very good, Kevin Whinnery really knows his stuff. It was pretty damn pricey, not sure I’d recommend it if your company wasn’t paying for it. That said, it was worth it to me. One of the main pitfalls of getting started with Appcelerator is that their main sample app, KitchenSink, is a really shitty example of how to structure your code! It’s a great example of how to access all the features of the SDK, and essential for fleshing out details that are not available in the documentation. Otherwise it’s full of things you don’t want to emulate for an app. A much better example is the Tweetanium sample app, which follows standard JS best practices.
You don’t feel like attending no stinking class? The training materials from the class are available on-line here.
I’m still not decided on this technology. Appcelerator has a lot of promise and they’re adding features frantically. But, I haven’t had time to get a real app together and go through the whole experience, so I’ll delay judgement until I can do that. But, I do plan to build out an app, and will definitely use this technology for prototypes in the meantime. It’s definitely worth checking out. I know at least one startup, getglue.com, seems to be relying on Appcelerator.
I don’t love their new licensing model (it used to be free, which of course was preferable!), which seems about the same as Corona’s. The company is very sales-driven, and contacting them about anything will lead to some salesperson calling or emailing you, which is really annoying and off-putting.
Would love to hear other’s experience with the technology.
Have you ever wondered why managers just don’t seem to truly understand the insidious effect of crunch time on programmer productivity? The failure of crunch time is well known, but many people don’t have a visceral sense of this.
Now I know why!
I’m in a dual role at my current job and sometimes I am a hands-off manager, other times an architect. Two of my projects went into the danger zone, in consecutive weeks, and I had to put in an epic day for each. This gave me first-hand experience at what it’s like to have a 14-hour day as a programmer, versus a 14-hour day for a manager in the last 2 weeks.
I can now say from direct experience what I’ve long suspected: A 14-hour day of programming is an order of magnitude more draining than a 14-hour day of management.
After my long day of hacking, me and the other programmer were laughing about how brain-dead we were. Everything took forever, obvious things eluded us, weird things kept tripping us up, and so on. I estimate we were at about 30% productivity, and probably should have been forcibly kept away form the keyboard. I doubt we accomplished much worthwhile that day, and the risk of us making a hash of things was very high.
To give an idea of how pathetically impaired we were, it took me 30 minute to debug an embedded font problem in Flash, that should have taken 2 minutes tops. Can you see the problem here? (I couldn’t!)
On the flipside, after my all-night slog of project management, the next day I was tired. But I was not impaired noticeably, probably 85% of normal.
The skills for management and programming are very different, of course, but the big difference is the level of concentration required.
My dear friend and colleague, the sage Joe Ferrari, said it’s the difference between being a player and a coach. I loathe sports analogies in general, but I think this one is spot on!
In spite of the mythology, all-night heroic programming efforts are almost never technical successes (although they still may be politically worthwhile). You usually end up with crappy code, and burnt out programmers. It should always be understood in these situations that you are stealing productivity from the rest of the week!
Took the great class, taught by Kevin Whinnery, in NYC on March 28-29th. The test was hard, but I’m now an officially certified Titanium Appcelerator developer! A very worthwhile experience, I will blog about it in more detail soon.
And I’ll be discussing it at flashcodersny later this month.
From the Appcelerator Developer blog: