Hey. I’m Marcus Cavanaugh, a programmer/entrepreneur in Des Moines, Iowa.
I work on an online gaming startup that I hope to ride to profitability.
I earned a B.S. in Computer Science and a B.A. in Music from Drake University this year.
Tech interests include Python, Javascript, REST, concurrency, and the singularity.
I also enjoy playing jazz piano, frisbee,
super smash brothers, running, and puppy chow. More →
You can also find me on
Twitter,
Hacker News,
Flickr,
Last.fm,
via
,
and elsewhere, perhaps. I hear Google can find anyone these days.
Following these steps precisely, I was able to enable tethering on the iPhone 3GS without losing Visual Voicemail:
Start fresh: If you’ve messed with tethering or jailbroken settings, restore the original factory settings. Don’t restore from a phone backup. Instead, set the phone up as a new device after selecting “Restore”. Otherwise prior settings may interfere.
Visit http://help.benm.at/ from your iPhone and follow its instructions to install the tethering carrier file.
Reboot your phone after installing the new carrier settings.
Open the Phone application, and touch “Voicemail” to dial into your voicemail manually (without visual voicemail). Leave yourself a message, and then hang up.
Stay in the phone application; after a few moments it should prompt you for your voicemail PIN. Enter it as prompted.
Reboot your phone. Tethering and voicemail should be functional.
I didn’t mess with any ATT_US.ipcc files, and I think that doing so may have triggered the original voicemail problems. Make sure you start with a fresh, non-messed-with install, and if you can get the Voicemail PIN prompt, you should be good to go.
UPDATE: It appears this solution worked momentarily, but Visual Voicemail remains inactive. Alas. I’m trying out PhoneTag, a voicemail transcription service which might prove to be even more useful than Visual Voicemail itself. When AT&T officially enables tethering, this situation will probably be resolved.
With few exceptions, Mac applications have intuitive, well-designed interfaces. Apple meticulously crafts its applications down to the last pixel, striving for a simple, fluid user experience. Third-party applications sport equally impressive interfaces, as seen in Tweetie, TextMate, Adium, Colloquy, MarsEdit, Disco, and more. Even the most intuitive Mac applications face stiff competition (c.f. Things vs. The Hit List and Coda vs. Espresso).
Modern Cocoa applications typically exhibit clarity and consistency; the best ones show off with graphics and animations that enhance the user experience, rather than detract from it. Well-designed Mac applications don’t put form over function; they employ both good form and good function.
Heck, the most homely interfaces come from cross-platform applications such as Microsoft Office, the Adobe Creative Suite, and Firefox. Despite efforts by Microsoft, Adobe, and Mozilla to port and maintain applications for both OS X and Windows, their applications feel out of place, tubby, and crufty on the Mac.1
Developing for multiple operating systems at once is like talking on a cell phone while driving: You can accomplish each task successfully, but you’ll excel at neither. Unless you develop an application with a native GUI toolkit and relentlessly embrace native operating system conventions, you will achieve mediocre results. The more you disregard or abstract away your target platform, the more diluted your user experience becomes.
Cross-platform GUI toolkits provide passable interfaces everywhere but exceptional interfaces nowhere. If you care about your application’s aesthetics, do not use a cross-platform GUI toolkit.
The only acceptable cross-platform UI toolkit lives in your web browser. If you want your application to work on both Windows and OS X, create a web application. In the browser, you can freely design a custom user interface that won’t seem out of place on any operating system. Users understand that web sites operate under different rules.2
The decision to target multiple platforms is a tradeoff between the size of your target audience and the quality of your application’s interface. When the size of your target audience is paramount, go ahead and pull out your cross-platform toolkit of choice. But remember that the size of your audience means little unless they actually purchase your application.
Customers prefer applications that look appealing and behave intuitively. Cross-platform applications rarely exhibit those qualities.
Granted, Microsoft Office 2008 for Mac is a substantial improvement. But it can’t escape its Windows heritage, and it pales in comparison to iWork. ↩
Adobe AIR doesn’t count. While AIR applications could be as simple as a web site siphoned into a native window, they often incorporate buttons and GUI controls that poorly imitate native controls. Flash interfaces suffer from the same flaws explained above. ↩
Faced with an itch for learning, a looming project, or a cool startup idea, you want to create a website in Python. Good choice; Python will serve you well.
Scour the web you will, searching for cloud-parting, eye-opening wisdom that will lead you to the promised land, where the One True Framework will shine upon you and lead you to riches, fame, and world domination. Only one hurdle stands in your way:
No framework stands out as an unquestioned leader in Python web development as of 2009. To top that off, the top frameworks differ enough that you will miss out on cool features no matter which framework you pick.
Absorb that thoroughly. You’ll have to make a choice.
“There should be one — and preferably only one — obvious way to do it,” proclaims the Zen of Python. Understandably, web framework developers (myself included) often bristle during framework discussions. We await the day when a framework will capture the market and stand before us in obvious superiority. (“Wouldn’t it be nice if my framework was the chosen one?”, you ponder.)
Back to reality: Which Python web framework should you choose? Your project’s requirements will guide you along the way. The best framework for your project should become clear if you consult the requirements of your project.
The Frameworks
The Python.org Wiki includes a list of frameworks long enough to drive anyone into perpetual indecision. Disregard the unpopular frameworks; community support is essential. I suggest you decide between four frameworks: Django, Pylons, TurboGears 2, and web2py. I have experience with Django and Pylons, but I will also touch on TurboGears 2 and web2py for completeness.
Django
Django is the most popular framework, with extensive documentation and great community support. In its own words: “Because Django was developed in a fast-paced newsroom environment, it was designed to make common Web-development tasks fast and easy.”
Django includes an awesome admin interface, one of the main advantages it has over other frameworks. Django’s admin interface allows you to create/edit/update/delete your database entries online. This incredibly slick interface can be added to your project with a line or two of code. The Django admin wasn’t designed to handle all content entry for your site, though; it was designed with the common case in mind. If you need custom permissions, a different visual design, or other changes, you’ll have to either modify Django’s admin or address those areas yourself.
Django developed its ORM (and template language) from scratch. While that may have been a pragmatic decision at the time, Python now has SQLAlchemy, a superior database layer that has gained a lot of momentum. Django’s in-house ORM lacks multiple database support, and forces constraints on your database models (e.g. that every database table must have a single, integer primary key). If you choose Django, your project gains a near-inseparable dependency on Django’s ORM and database requirements.
If you accept those limitations, you gain access to Django’s many pluggable components. Django offers a comment system, user authentication and registration, RSS helpers, and more. These add-ons can speed up development time. But if you need to later customize those components, you may end up writing more code than if you had created those components yourself based upon your own requirements.
Pylons
Rather than encompassing everything into a monolithic safe haven, Pylons allows you to pick and choose the best Python components for your web project. Out of the box, Pylons supports Mako, a very fast templating engine, and SQLAlchemy, widely considered to be the best Python ORM available. SQLAlchemy includes multiple database support and just about any crazy combination of database requirements needed, and it handles ORM very well — yet it also allows you to provide raw SQL as needed.
Pylons has been criticized in the past for its loosely-coupled nature and incomplete documentation. But Pylons has picked up steam recently, introduced a new website and book, and has improved its documentation tremendously.
I maintain that the Pylons is no more difficult to learn than Django. The ORM and templating language are independent projects apart from Pylons, whereas with Django they are bundled together. Django provides consistency, but Pylons provides flexibility.
Note well: Flexibility does not preclude consistency.
TurboGears 2.0
TurboGears 2.0, a ground-up rewrite of TG1, builds on Pylons to add features that a more centralized framework provides, such as form widgets and admin interface. Like Pylons, TG2 uses SQLAlchemy. If you like SQLAlchemy but aren’t comfortable with Pylons’ decoupled approach, consider TurboGears 2.
Ensure you look at the right version, though — TG2 is still in beta as of March 2009, and the TurboGears home page features TurboGears 1 most prominently. You’ll want to look at TurboGears 2.0 instead.
web2py
web2py seeks a more lightweight approach to web development. I have no experience with web2py, but have heard positive reviews, so rather than pontificating, take a look at these resources:
If you’re building the next CMS or content-oriented site, focused on articles, blog entries, and the like, you’ll be more happy with Django than anything else. Django excels at content-management — that’s what it was designed for. Its admin interface can eliminate a lot of redundant content management work associated with a text-heavy site.
If you’re a startup aiming big, you would benefit from Pylons or TG2. You’ll want flexibility. With Pylons, you will have more control over your site — you won’t run into the framework’s limitations as much as you would using Django. Multiple database support may be essential if you need to scale. Pylons’ interchangeable nature means that you can exchange the ORM, templating language, or any other component as needed. If you really want flexibility, don’t let the framework get in the way. Pylons (or TG2) really shines in this area.
If you want something lightweight, either Pylons or web2py might fit the bill; Pylons doesn’t require you to use any database or templating language at all. When the rubber hits the road, though, you just want to get something done, and for a site with few requirements, any of the aforementioned frameworks would work well.
Different Philosophies
Django resembles Apple — always in control, presenting a cohesive, unified platform. But neither Django nor Apple strive to accommodate every use case; they strive to do a few things really well. Django handles content management better than any other framework.
Pylons adopts a Unix-like philosophy — loosely coupled components that work together to form a better whole. That allows Pylons to adopt the best components available, such as SQLAlchemy and Mako. Pylons won’t get in your way; that flexibility can be very valuable. Pylons’ improved documentation has reduced its learning curve substantially; learning Pylons should prove no more difficult than learning Django. Plus, if you learn Pylons, you’ll know how to use SQLAlchemy in Python projects that need database connectivity.
Look deeper than their respective “first blog” tutorials — any decent framework will let you create a blog in minutes. If you’re learning for fun, play with both. Good programmers use the best tool for the job.
Remember: Wading through framework blog entries won’t make your project progress any faster. Once you have evaluated your options, pick the framework that best suits your project. Then move forward.
In Python web development, there is more than one obvious way to do it.
You will not find the One True Framework. Not yet.
Manyhaveasked whether or not Google Adsense can be configured to open links in a new window. Google’s Adsense Program Policies forbid site owners from modifying Adsense javascript code to achieve that:
AdSense participants are not allowed to alter any portion of the code or change the behavior, targeting, or delivery of ads. For instance, clicks on Google ads may not result in a new browser window being launched.
The ability to open Adsense ads in a new window can be useful and legitimate: Consider Pogo.com, an online gaming site that displays ads while users play online games. If Pogo’s ads opened in the same window, players would lose their place in the game when they click on advertisements.
With the release of Google AdManager in 2008, Google indirectly gave Adsense customers the ability to force Adsense ads to open in a popup window. AdManager allows site owners to sell, schedule, and manage advertisements on their own site. Site owners can include advertising they created themselves, such as promotions and new site content, in addition to ads from external advertisers. Google AdManager links with your Adsense account; site owners can configure AdManager to place Adsense in any ad slot that isn’t occupied by other AdManager ads.
Critically, AdManager allows site owners to specify whether their ads open in the same window or a popup window.
The trick: If you have no other ads configured, AdManager will simply display Adsense ads.
Thus, to create Adsense ads that open in a popup window, create your slots through Google’s AdManager instead. As you create each slot, set the “Target Window” option to “_blank”.
Since Google offers this as a fundamental feature of AdManager and Adsense, it should be perfectly safe to follow this technique in compliance with Google’s policies.
I used to check Weather.com’s hourly forecast rather frequently to decide whether or not the weather outside was nice enough to go for a run. It served me faithfully for several years, until some brilliant mind decided that an hour-by-hour granularity wasn’t enough.
Nay! If an hourly forecast is good, a 15-minute-ly forecast must be even better!
Behold the useless landscape of pixels that now occupies Weather.com’s hour-by-hour forecast:
My friends, you have seen an 850-pixel-tall vertical span of Weather.com. Yet that swath doesn’t even span two hours!
Hogwash, I said: It’s time for something better. Enter AccuWeather.com, a site I had long ago dismissed as a cheap weather-widget-on-your-site knockoff. I was pleasantly surprised to find that not only did AccuWeather actually give me a useful hourly forecast, it also presented a nice default dashboard with much more useful information in less space:
Yes, the hour-by-hour portion of that clip only shows weather every two hours, but if you can’t interpolate from that, I can’t help you.
AccuWeather even presents a reasonably-done “I don’t live in your area but I’ll pretend that I do” video forecast.
Douglas Hofstadter wrote about the potential for computers to create music and the impact it would have:
What worries me about computer simulations is not the idea that we ourselves might be machines; I have long been convinced of the truth of that. What troubles me is the notion that things that touch me at my deepest core — pieces of music most of all, which I have always taken as direct soul-to-soul messages — might be effectively produced by mechanisms thousands if not millions of times simpler than the intricate biological machinery that gives rise to a human soul. This prospect, rendered most vivid and perhaps even near-seeming by the development of EMI, worries me enormously, and in my more gloomy moods, I have articulated three causes for pessimism:
Chopin (for example) is a lot shallower than I had ever thought.
Music is a lot shallower than I had ever thought.
The human soul/mind is a lot shallower than I had ever thought.
When it comes down to it, Hofstadter has an interesting point — music, fundamentally, can be created according to various formulas. Pick any genre of music, and you could write a computer program to synthesize a score of music that reflects the style of the time, just as you could teach humans to compose works in that style. He continues:
The loss described in (3), of course, would be the ultimate affront to human dignity. It would be the realization that all of the “computing power” that resides in a human brain’s 100 billion neurons and its roughly ten quadrillion synaptic connections can be bypassed with a handful of state-of-the-art chips, and that all that is needed to produce the most powerful artistic outbursts of all time (and many more of equal power, if not greater) is a nanoscopic fraction thereof — and that it can all be accomplished, thank you very much, by an entity that knows nothing of knowing, seeing, hearing, tasting, living, dying, struggling, suffering, aging, yearning, singing, dancing, fighting, kissing, hoping, fearing, winning, losing, crying, laughing, loving, longing, or caring.
Although Kala Pierson and many others may hail its coming as “truly a thing of beauty”, the day when music is finally and irrevocably reduced to syntactic pattern and pattern alone will be, to my old-fashioned way of looking at things, a very dark day indeed.
Deep thought… it’s hard to reconcile music’s inherent mathematical origin, in contrast to music’s view as human emotional expressions.
This article was discussed on Reddit, where a commenter named adrianmonk responded:
IMHO, what he leaves out is that:
Humans had the insight to invent music in the first place.
The fact that Chopin’s body of work can almost be reduced to a (rather
large) set of parameters which can be fed into a system to produce
Chopin-like works does not take away from the genius in finding those
parameters. There have been many, many mediocre composers in the world; if
you fed their work into this system, it would perhaps be as similar to their
work as its Chopin output is similar to Chopin. But its output for these
other composers would no doubt be as mediocre as their body of work. So
which is more valuable, the ability to produce many works of a similar style
to existing ones, or the ability to find a style that is worth producing
within?
We’re not at the point where computers are cranking out new genres; composers continue to explore and innovate. So far, that’s where we retain the advantage: music constantly evolves as composers react to the entire community of musicians and composers. We operate via a feedback mechanism between audiences, composers, and musicians, which encourages the field to continue to grow and change in ways that technology can’t yet synthesize.
