There’s been so much written about Steve Jobs that there’s not much to add. Like millions of others, I remember the first time I ever used an Apple product. It was to play Number Munchers and Oregon Trail. My first Macintosh experience was on an LCII in one of the few airconditioned rooms in Taiwan – my elementary school’s computer lab. While I was too young to appreciate the differences between the (at the time) very outdated Apple II and our fairly outdated IBM compatible XT Turbo, the Macintosh was clearly completely different. I managed to swing an editor job on our 5th grade newspaper which afforded me almost unlimited time to learn how it worked. Everything was exciting on that machine, even word processing!
I bought my very first Apple product in college, the 2nd generation iBook with a 500Mhz G3 processor and OS X. It was a little underpowered, but the hardware design was incredible and I remember being thrilled when I got several OpenGL school projects to run on Windows, Linux, and my new Mac.
To me, Steve Jobs embodies hope. A college dropout becomes a billionare. A man with limited technical skills becomes the an incredible driver of technology. Fired from his company, failing at NEXT, he stakes almost all of his personal fortune and strikes gold with Pixar. He affects industry after industry, despite many many setbacks along the way. Sure, he was a jerk, but that’s a hopeful story too – jerks can learn to movitate people and soften when they get older. Of course, none of these thoughts are based on personal experience, but it’s the perception I get. Steve’s life to me is a story of hope triumphing over reality.
I’m excited to read his biography, and I’m sad I never got the chance to meet Steve, except through his products, but here’s to a legacy of hope.
Others have written about this before, but I’ll underscore the sentiment that managing a local development environment on OS X where that environment requires Open Source Software is a royal pain. At the companies I’ve been involved with, we generally eschewed local development environments and instead gave everyone access to a development server that included the requisite databases and web servers and vhost entries. It worked OK, but there are some significant drawbacks. Namely, unit testing, environment experimentation, single point of failure if the dev environment goes down, and the needs of a developer to refresh their own copy of a dev database or make other similar changes tend to suffer.As a hobbyist with a simpler environment, or as a developer that’s deploying to Heroku or other cloud platform, local development is the way to go, and here is where Mac OS X makes life difficult. There are several package management systems out there that tend to step on each others’ toes (and it seems language and framework ecosystems always prefer the one that you’re not using). Mac OS X also tends to haphazardly ship versions of Python or Ruby or whatever that are a couple of versions behind, then not upgrade them until they do an OS refresh. That refresh (cough, Lion) will fail to mention it’s upending your world until you try to use your environment that’s always worked.Here’s my solution: just use VirtualBox. Deploy an Ubuntu or Debian server, link that server to your local development directory and you’re done. Then use the excellent package management that Linux affords to setup your environment in about ten seconds. This has another advantage in that you can also use all your deployment hooks (Chef or Puppet) that you’re using on your production servers.Once you’re up and running, here’s how I work: I edit and run git from outside the virtual machine, and run the environment and web browser from within the machine. Still todo: see if I can use my OS X browser to hit the virtual machine’s private IP so that all my tools are running externally (a little easier for workflow) so the virtual machine is just acting like an external server.Now you have a fully fledged (free, and always available) server, and you can still retain your Mac toolchain when and where you want it without worrying about Apple and OS X pulling the rug out from under you. Remember: encapsulation of a work environment is just as important as encapsulation of code.
My first app store experience was many years ago, before Apple, before iOS, before any of the other app stores you see today. It was Redhat’s Redcarpet subscription service which delivered a library of applications (packages) via the internet in an easy to use command line tool. There was even a GUI if I remember correctly. Then Debian/Ubuntu came around with their package repositories and it was such a major usability difference between Linux and Apple/Microsoft that it was only a matter of time before it caught on. Of course, the ideals behind the Linux offerings of ease of use, reliability, and compatibility are supplanted somewhat by the key aims of profitability and control inherent in modern app stores, but who’s counting?Things I wish the Apple App Store had (these are post-Lion upgrade thoughts)
- Some way to know what the schedule of app update notifications is – it’s unclear to me if this is daily, whether I have to have the appstore application running all the time, etc.
- The App Store should intelligently close your application when updating an existing application.
- The App Store should be able to store your credentials, and not require credentials for doing an update if the app is in safe state (e.g. closed).
- There should be a compatibility layer in Lion that lets you run your iOS apps on your Mac. I’m sure this is coming, but I wonder when.
- The App Store should offer to scan your hard drive and find applications that it can manage for you.
- On the Featured and other pages, you should be able to hide apps you’ve already installed.
- Somewhere down the line, it might be interesting to have a “lists” feature like Amazon. Apple could even show what apps certain celebrities use in lists like the inflight magazines do for travel accessories. Maybe that’s too much on the pointless-marketing side.
I’m sure there are some other options that I’m missing, but overall I’m happy with the experience. The App Store managed Lion install was incredibly painless, and so much nicer than having to mess with the Apple store, or a nasty CompUSA.
Just got around to provisioning Django and Python on my (relatively) new MacBook Air for a project I’m working on in my spare time. The fact that it’s months since I got this machine shows you just how much spare time I have. That said, I have a confession: I completely suck at deploying things on OS X. Particularly development things. I can do this well on Linux environments, but for some reason I just have a really hard time getting Django running on a clean OS X environment.Generally speaking, here’s how it goes:
- Install the latest Django.
- Clone my project from Github. Follow their excellent documentation to get my keys setup, etc.
- Run “python manage.py runserver”.
- Remember my project requires the Python Imaging Library (PIL).
- Download and start the install of the PIL. Am told it requires Python 2.5 or greater by the OS X installer.
- Download Python 3.2, this doesn’t work.
- Download Python 2.7, this doesn’t work.
- Download Python 2.6, this doesn’t work.
- Download Python 2.5, this works.
- Now try to run Django and spend 45 minutes in PYTHONPATH hell.
- Give up and just re-run the Django installer, this fixes all my environment and pathing problems, and now it works.
- Want to kill everyone because this should be easier.
PROTIP for myself: install Django last.If anyone out there has any other tips for how to make this process easier, I’d love to hear them.
I’ve been having problems with horrible performance on my Mac desktop. Constant grinding of the hard driver, non-stop lagging apps. Turns out MDS (the spotlight process) seemed to be constantly running. Google brought some suggestions such as completely rebuilding the spotlight index, but this ultimately didn’t work. Even turning spotlight off seemed to miss the mark.Finally, I made two changes which solved the problem completely:
- I added /Library/Backblaze to the Spotlight exclusions list.
- I forced a Time Machine backup, then added that volume to the exclusions list.
That’s it! A simple fix restored the performance of my machine. I’m unsure as to why it started happening all of a sudden, but I’ll take it.UpUpdate 2/5/2011: A clue to what might be going on as evidenced by the following command:
- sudo fs_usage -w -f filesys mdworker
This command shows exactly what Spotlight is doing, and essentially it appears that whenever a file is accessed on the filesystem, Spotlight gives it a look for indexing. This means when you’re backing up (either via Backblaze or Time Machine) lots of files are getting “touched” and thus need to be examined by Spotlight. This impacts an already I/O intensive process, bringing the system to a crawl. Since this post, I’ve had zero performance problems and I’m going to consider this one solved. Also, on my MacBook Air, Backblaze had already added itself to the exclusions list, so it’s possible that this has been addressed when you do a fresh install of Backblaze nowadays.
The Wife’s machine was running out of hard disk space, so I decided to to buy her a new 500GB drive and swap it out this weekend. The words I used to describe the process were “Easy Peasy”. Well, this was the first restore from a Time Machine backup that didn’t go perfectly. Go figure. The Wife is incredibly fond of her MacBook as well, and she was very concerned that I’d somehow “killed him.”The machine couldn’t seem to boot. Gray screen on booth with a spinner. Boot from the OS X DVD, and run Repair on the disk, doesn’t work. Boot into safe mode. THAT doesn’t work. Boot with verbose mode, and that seems to be hanging on the wireless driver startup. Nothing. Seems. To. Work.Then, I just decided to reinstall Snow Leopard, and it works. Install the updates, and everything’s back to normal. Weird.Now the MacBook, The Wife, and myself are all happy.
I recently upgrade VMWare Fusion to version 3. VMWare has steadily increased the stability and featureset of this product, and I appreciated it how they gave us early adopters free upgrades to version 2, but I guess that all ended recently.One really cool new feature is something I stumbled upon after I upgraded my hard drive to a new 500GB spindle on my laptop, and partitioned my Macbook Pro to install Windows 7 via Bootcamp. After fighting with Crossover Games for roughly 3 months trying to get Team Fortress 2 to not crash 15 minutes into the game, I was ready to succumb and admit defeat. TF2 is one of the slower loading games (in my opinion) and I was tired of crashing out during Sentry Data System’s weekly TF2 bouts each Friday night because it messes up your stats. At least, that’s what I’m telling everyone.Anyway, apparently VMWare Fusion can boot up a Bootcamp partition within the emulator, which I find to be really really useful and it’s one of those features that should be there, but you never expect it to be implemented. My first few attempts didn’t work, but I did manage to track down a registry hack (http://communities.vmware.com/thread/80060) that worked like a charm.