It’s going to be all about discovering music in a super simple way.

Not that I blog often, but this is my last post for the indefinite future – I’m trying to focus my time on a few important things (one being the new iSound site). Checkout the iSound site to stay tuned.

Here’s how I got it to work after some pain.

1. Make sure you have http://www.macports.org/install.php

Get the Snow Leopard version (need Xcode and X11 installed before using macports)

2. Install mysql and server with macports

sudo port install mysql5

sudo port install mysql5-server

3. Run mysql install of packages

sudo -u _mysql mysql_install_db5

4. Add load daemon so mysql starts at boot time

sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

I tried to kick-start mysql many different ways. 
Finally I just added this boot daemon,
restarted the machine and everything was running.
Before, I wasn't able to get the /tmp/mysql.sock to work - kept getting error:
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)'

/opt/local/bin/mysqld_safe5

/opt/local/lib/mysql5/bin/mysql_secure_installation

mysql5 -u root -p

sudo /opt/local/share/mysql5/mysql/mysql.server start

sudo /opt/local/share/mysql5/mysql/mysql.server stop

I was running through some sites I like recently to see which programming languages they use. Most of the new sites I respect seem to be using RoR or Django, but it’s crazy how strong php is on some of the biggest sites out there. For those who hate its mess, I’m sorry to say that php is not going away anytime soon.

If you’ve got others feel free to add them in the comments.

(random order)

mint.com – java
twitter – RoR
facebook – php, C++
last.fm – php, java, C++ (client)
ilike – RoR
google – python for web interactions
yelp – python
posterous – RoR, Java
playdom – php, java
zynga – php
slide – python
dropbox – python
digg – php
amazon – java/c++
youtube – python (started in php)
flickr – php
imdb – perl
hi5 – java?
friendster – php
ning – php
hulu – RoR
netflix – java, C++
wikipedia – php
wordpress – php

If you’re interested in general popularity visit the TIOBE site

OK, so this post really has nothing to do with php or RoR or anything specific about any language…

Language debates will never end; they’re like the religious debates of the technical world; some people take fiercely loyal sides, while others claim to be language agnostic.

I’m not attempting to break down the features of each language here. What is important is to pick the best language/framework and I think it’s relatively easy if you put a little time in.

The important thing to note, is that every language is different and that there are better and worse languages. Period. We don’t need empirical evidence to prove this; the mere fact that languages are different means that one is “better” than another.

Say Cosmo (the coolest new language) is just 10% more productive than Costanza (the old stand by language).  Now imagine you’re working on a project for 1.5 years and it ends up being 50,000 lines of code – 5,000 extra lines (or several extra iterations of features) ends up being a decent win for what is probably an imperceptible difference in the start.

The problem with this example, is that programming productivity is never going to be a linear curve; as a project gets bigger and less agile, differences become more and more apparent with less efficient technologies; and so that 10% gain initially may end up being closer to 100% or more.

The point is, it is always worth the time and effort of choosing (and learning) the best language for the job.

Developers:

It is easy for developers to get stuck using the same tool sets they’re used to, and to be less objective about viewing a language based purely on productiviety. Take some time to learn some of the other languages and frameworks before you start with your same old bag of tools. You should always be looking at new ways of being more efficient, and that includes something as core as the language you use to build things.

Rails guys tend to get heat for acting holier than thou; mac guys tend to have this stigma as well; don’t let this turn you off. There’s usually a reason why people act cultish about their tools.

Regardless, I recommend playing with different frameworks and languages to get a first hand idea of how development in each will be. Make sure the scope of the language will cover what you want to build; then build the most simple application you can think of in each language/framework and see how “easy” each one is. This doesn’t need to be a technical analysis of each feature set; start building and the better toolset will just feel better and faster to you.

I know this sounds like a lot of extra effort, but it will pay off big time down the road when you are cruising along with the best language and toolsets, and your competitors are using something just a bit slower.

Non-Developers:

Non-developers tend to become overwhelmed with the choice of platform and language; and honestly they should not be making this choice as it will probably be on a whim, based on some marketing material or blog post they just read; or it will be based on a developer they know who could be biased towards inferior tools.

If you aren’t the one who’s going to be coding, then find someone who understands the startup landscape and who also codes. It’s important that they understnad that productivity is paramount when deciding on a language.

Here are the potential problems with asking some developers what the best language for a project is:

a) The good ones will be able to pick up any language, so they may say they’re language agnostic, and therefore just recommend what they’ve currently been working in.

b) Others will be passionate about a language because of the tool sets and skills they’ve developed, and will be reluctant to recommend any other language (their language has become their religion).

c) Others won’t look at the bigger picture of getting things done as quickly as possible; it is VERY easy to over complicate a system.

Big Win:

There are small and big wins in the startup world; having the best technology foundation is a big win.  One of the cornerstones to any startup’s success is how quickly the team can iterate on new cycles of the product; this is the number one reason for it being important to pick the right foundation on which to build.

Answer:

So what is the answer to the post title? Find someone who understand technology and productivity very well and have them choose. If it’s a web application I’d have them start by looking at RoR, Django and the Zend framework for PHP.

So which would I pick? Until Cosmo gets built, I’d go with RoR right now, but I haven’t used Django yet, and before I start any new project I want to give that a pretty good test drive.

So if languages are our religions: be somewhat fickle and open minded to the new messiah; if you don’t convert, at least you’ll have more knowledge and faith in your current beliefs.

Note: The post title is not comparing apples to apples; comparing cakephp to ruby on rails would be better etc.

Software scalability seems to be a perpetual hot topic among web developers. The thing is, 99.99% of web applications have no need to worry about scaling – ever. The debate is just pointless rhetoric – although I do understand people’s obsession with it. It’s easy and fun to play the optimization game and run benchmarks. It makes for interesting discussions; it is not productive though.

If you’re building a start-up, ignore the debate and focus on what’s important: getting your product to market.

Pick a development stack based on iterability (yes, that’s not a real word), not on scalability; that is, a stack that will let you get out as many code changes and implementations as quickly as possible.

I’ve heard people say that “ruby on rails won’t scale”, or “django is inefficient” or “cakephp is for amateur developers.” Do these frameworks use extra CPU cycles for their ease of use? Yes. Will you ever notice this? No. If you do, congrats, you’ve made it – prepare for two months of no sleep, some expensive server (bandaid) costs and dashing to find people who have been here before to help.

The risk of not spending time on scalability up front:
- You lose some potential and current users from frustration once you’ve achieved success.

The reward:
- You get to market faster, which beats the competition
- You see if you’re idea is viable; and if not, move on or do another iteration.

Most startups are ephemeral; don’t spend time building a foundation for a skyscraper when you’ll probably end up with a shack.

Build many pretty shacks until yours becomes the “it” shack. Then build a house around that shack when it’s necessary. You’ll disturb some of the inhabitants of your shack, but at least you didn’t spend all your time building a house that no one is living in. Now you have a popular house that you can work on turning into a high-rise. Cheesy analogy, but it works.

So what do I mean by putting off scalability?
Example:
Team A: Picks the LAMP stack, uses a framework like code igniter, installs one cloud server and starts developing and releasing.

Team B: Picks the LAMP stack, writes their own basic functions in OOP that are “light”, shards their DB based on what they “think” will cause a heavy load, load balances their webservers, gets a mysql cluster running, builds memcached into their apps and now starts developing and releasing.

Team B probably had fun and also wasted valuable time and resources. Team A got their app up quickly, found out what users like and don’t like and can now handle scaling issues.

I’m not saying code irresponsibly – don’t put a SQL query in a loop that queries it 100 times when you could simply write a join.

Code with good practices, pick the best (read easiest) tools for the job and choose a very agile and popular development framework to get your product to market.

For those using linux as their primary desktop OS, there currently isn’t a graceful solution – Zimbra puts out a great product and I wouldn’t be surprised if they have a complete solution for linux soon.

Below is my hacked together, cross-platform version, for my PIM (personal information management).
This will work on Mac and Windows, although there are simpler, all-in-one solutions for those operating systems.

Desktop

1. Mail: Use Thunderbird. Always use IMAP (much better than POP).
2. Calendar: Use the Thunderbird plugin Lightning.
3. Contacts Sync: Use Zindus to sync your Thunderbird address book to your Gmail address book – you can create a gmail account just for this if you don’t have one.
4. Calendar Sync: Use Provider for Google calendar – create a Google calendar account if you don’t have one.
5. Tasks: Use Zenbe Lists. The tasks in Thunderbird have never worked well for me.

iPhone

1. Mail: Use the standard iPhone/IMAP setup.
2. Calendar: Use Nueva Sync.
3. Contacts: Use Nueva Sync.
4. Tasks: Install the Zenbe Lists App.

Login to your Nueva Sync account and give it access to both your Google Gmail contacts and Google calendar.
On the iPhone go to Settings -> Mail, Contacts, Calendars -> Add Account -> Microsoft Exchange. Configure the ActiveSync settings with the Nueva Sync credentials (server = www.nuevasync.com) and turn on the Contact and Calendar syncing.

This solution has worked well for me to manage all my appointments, contacts, to-dos etc between Ubuntu and my iPhone.
Hopefully this will save you some time tracking all this stuff down.

Image from silverbackapp.com

Usability testing is one of those boring buzz words that makes me start day dreaming about how many five year olds I could beat in a fight. But the fact is, that it’s not only crucial and necessary; it’s actually very fun to do. Seeing people use your site, who have no idea what you do, is very eye opening.

So….

Test the crap out of your site – early and often; it’ll save you dev time and bad product decisions.
It’s hard – err impossible – to look at our own sites and see the issues others see, because we each know our site too damn well.

Building great features, and having a great looking site is not enough; a site can look good and still be very hard to use! You can easily miss fundamental problems that make the site confusing and make users miss your great features.

It is amazing to see how little people use some of the features that we’ve built and why they aren’t using them – they literally just don’t see them!

Statistics testing

You can get a very accurate and analytical idea of how users are spending time on your site by looking at the traffic stats.

1. Embed google analytics in your site – you should be using analytics already.

2. Go to Content-> Top Content in your analytics account.

You should page through to see the top pages people are visiting on your site.

3. Break your pages down into categories.

a. Highly trafficked

b. Moderate

c. Low

d. Never used

You should also use the “Find page containing” feature to filter the results and look at specific pages.

Another feature that works great is “Site Overlay” (under the Content section); this feature shows a visual representation of where people click on each page of your site.

Categorizing the pages will give you an idea of where they fall and where you want them to be; this doesn’t have to be exact; it’s just a general idea of where they fall in your overall site traffic.

4. Once you have a list of the pages you can:

a. Get rid of pages and sections that aren’t adding value and aren’t used.

b. Move important sections to more prominent locations.

c. Move or change links and menu items that are getting lost.

In-person testing

Traffic statistics can tell you what pages are the most popular, but they won’t give you a real user perspective of why those pages are popular, or what users find confusing. People may struggle to even understand fundamentally what the point of your website is, or may be missing great features all together because they don’t know they’re there.

There’s a great chapter in Don’t Make Me Think, by Steve Krug, on usability testing that gives more detail on what I’ve listed below. I highly recommend reading this chapter and the book in general; it has great advice on making websites simple and easy to use.

1. Get 3 to 4 strangers who’ve never used your site before and offer them some cash ($40 or so) to use your site for an hour while you watch.

Don’t worry so much about the demographic of the users – you just need some people who use the web and haven’t used your site. You’re watching how people use your site, not trying to recruit new users.

2. Setup a computer in a private room so there are no interruptions during your session with the user.

3. Get a screen capture program so you can record the user’s behavior for later review.
Camtasia studio ($300) is easy to use and works very well; you can capture the user’s screen activity and audio (to record their comments). If you’re using a mac then give Silverback a try. I can’t personally attest to it’s value, but the reviews are good and the price is great ($50).

4. Explain to the user how the test is going to work.

Tell them:

a. There is no wrong way to use the site and no wrong answers – you simply want to see how they use it.

b. That they should talk out loud as they use the site so you can hear what they’re thinking.

c. Not to get offended if you don’t answer their questions. The point of site testing is to see how the user uses your site and therefore you can’t help them if they’re struggling.

5. Start the testing when they’re ready.
Show them the site first and ask them what they think the purpose of the it is – they should be able to answer this after looking at the home page for a few seconds.

6. Tell them they can click around freely and watch where they go first and what they say.
Encourage them to keep talking out load as they browse the site. Don’t take all their comments to heart, some will be minor and inconsequential, others will be major usability issues that need to be fixed.

7. Create a couple of tasks for the user to complete.
For instance: Ask them to find a photo they like and tag it if you’re running a photo site. It’s up to you to decide what the most important actions are on your site. Leave the tasks as open as possible so the user can pick how they want to complete each one – don’t tell them to tag a photo of a rabbit; tell them to tag a photo they like.

8. After you have enough data from the three users, review it immediately with the team.

Testing Tools

Usertesting.com is a great site that shows you a 15 minute video of a tester using your site and answering questions you specify. They charge about $20 per video and it’s been well worth it for us! You give the user a list of tasks to perform and then watch and hear as they click and talk their way through the process. What I like about this site is: a) it’s very easy to sign up and instantly get testers and b) it’s anonymous so it seems as though the users are likely to give honest feedback. I will continue to use this service to test all new major site features.

Feedback Army is a user feedback or survey site. You get 10 surveys answered for $7. This has worked well for answering very specific questions and getting a larger sampling of the issue. Usability issues tend to be easy to spot as you watch someone use the site, so you only need a few users to hash these out. Questions like: “Do you like our site name? Why? or Why not?” can generate a wide array of answers and it’s good to get a median response by sampling a larger group.

As mentioned above, these are good and simple ways to do user testing.

1. Camtasia studio – We have used this software and it works well. ($300)
2. Silverback – This comes highly recommended for mac users ($50).
3. Morae – I haven’t used this, but it looks like it gets the job done ($200)

If you haven’t got specific feedback, in-person, from users before, you’ll be blown away to see how obvious some usability mistakes you’ve made are. People are impatient on the web; they want instant gratification and you need to give it to them.

By default Ubuntu comes with the tiny version of VIM (Vi Improved).
First you’ll need to get the regular version.

1. Install
apt-get install vim
2. Open a file for editing
vim filename
3. Turn on syntax highlighting -or-
Press ESC :syntax on ENTER
3. Edit the config file to always do syntax highlighting
As root type: vim /etc/vim/vimrc and find and uncomment the line that says "syntax on"


I’m happy to say that we (OneSeason.com) closed our funding with Charles River Ventures earlier this month and announced the funding this week. We’re excited to work with CRV and be a part of their list of great companies they’ve invested in. George Zachary is the lead partner on our investment and will join our board of directors. James Hong (hotornot and a great product guy) and Ronnie Lott (49ers cornerback and safety) will join our advisory board. I also want to give a special thanks to all our original investors who have supported us from the beginning!

The secret to raising venture capital is (drum roll…):

Right now you’re probably saying: “thanks for the advice jackass.”

The point I want to make with this post is that, unless you’re a “name brand” entrepreneur (someone who has already had a big success), pitching VCs before you have traction and a live product is a waste of time. Some businesses, like the hardware industry, require more capital to just get a working demo; but the internet industry, for the most part, requires little to no capital to start a business.

We spent a lot of time pitching VCs before OneSeason was launched. We flew to meetings and talked to people all over the country about a year before we even launched. It was a good learning experience, but definitely detracted from building the business.

What is the money for?
You need to get creative and look at what you plan to spend the money on. Most early startup expenses can either be deferred or replaced with equity.

Once you have a live product and some users who are passionate about your product, then you can feel confident that you aren’t just wasting your time with the venture guys. Ideally, you should strive to keep running your business until the VC guys start calling on you. The balance of power will have shifted back to your side and at that point, you can get a deal done that you want. The industry tends to have an inordinate amount of hype around it. Remember that there are just as many positives as there are negatives with taking investment capital; don’t think that it is the be all end all. Raising a venture round does NOT mean that you have built a great company.

The bottom line is: Focus on your company, make it great and the money will come.

I’ll write more specifics about the industry, pitching, angel investors and managing your capital in future posts.