What does this have to do with web startups you ask? Well, since that time in pretty much any competitive game, I’ve noticed that there are a few key focus areas that separate winning teams from loosing teams. You can grade a team based on these things and predict very well how they would do. After spending the last few months working on a web startup, I’d like to share the things I learned first hand and the fundamentals that governed the game. Please excuse my naivety if this post seems obvious, or overgeneralizing to you as I sure didn’t know these things well enough going into the process and had I read this post I may have been that little bit more effective. Hopefully it’ll help someone else out there trying to do the same.

The three fundamentals I found were the Idea, Traction and Technical Execution. Each of these has equal weight. Now let me go much deeper into each of these to explain why they’re important, what I really mean by each and more specific details.

Idea

The idea is essential to the business, however commonly too heavily relied upon as someone thinking they can have a great product. The idea for me, is more encompassing than the typical “I have a business idea!” with no more further thought. It includes things that people like Paul Graham would ask you: “How big is the possible addressable market? Who are your competitors? How will you make money? Does it fix a need or problem people have? What’s new about your idea?” This is where the Lean Startup movement really shines because basically you quickly pivot until you find an idea that works. You define an idea that works by one that finds traction readily available. The better the idea the easier the traction will be to aquire.

Technical Execution

Can your team sustainably put together a solid product and iterate? If you’re going to compete in a red hot market like web startups you need to have the chops to code a product quickly and iterate on it to improve it. In some rare cases technical execution can be nearly all you need; These are typically areas that are on the edge of what is possible technically, where the idea is more obvious and can provide first mover advantage if executed.

Technical execution is everything from design to site speed. Its the quality of the product you have produced. If you’re Zappos its customer service, if you’re Netflix its streaming bandwidth and if you’re TechCrunch its the quality and relevance of your posts. I say sustainably because writing good code is only a small piece of pulling a product off. You need to be able to have a nice work environment and work together as a team. Politics and disgruntled team members will distract you into ruins unless you’re vigilant.

Traction

More precisely the ability to gain traction. This was one of the realizations that hit home the hardest: you can build the best product in the world, that everyone wants and still fail. Relevant people need to hear about it. Good startups will have a plan (not “Well, we’ll just post it on HackerNews”) for getting people to actually start using and continue using their product. I feel like most web startups these days fail, not because the idea sucked or the team made a bad product … but because no one ever heard about it.

Some Examples:

Google stole market share from Lycos, Yahoo!, Excite, AskJeeves and the like through having better search results. Their superior PageRank algorithim drove traction through an established business/product model.

Facebook seems like traction wizardry to me. It came into a market already dominated my MySpace. However going after college students first and starting in the best place to do that (Boston, MA is probably the best/largest college “town” in the world) was a brilliant circumstance that I think led to its success over MySpace. College students share things … fast, and have enough time/willingness to try them out.

TLDR;

Startups need to focus on one question: Are you building something well, that people want, will pay for and will somehow hear about?

Lacking in any one of these areas can kill off your startup entirely. Most startups need to beat their competition in all three fundamentals and blow them away in one.

Discussion on HN: http://news.ycombinator.com/item?id=2530902

The web technologies I’m talking about are webGL, websockets and node.js. WebGL enables web developers to utilize many of OpenGL’s features inside a web browser and bring 3D applications to the web. Websockets allow a client to communicate with a server with significantly less overhead than ajax, making real time applications on the web much more doable. Node.js allows the server to salably handle all these websocket connections. The real kicker is that they’re all coming to maturity at the same time and cater to each other in a huge way.

When you think of 3D on the web, you typically think of games first. Games in 3D are fun, but what if you could do multiplayer gaming inside a web browser, with a server that could scale? This is a reality that I think is now upon us and on a night before YCombinator starts announcing who gets into their summer program and developers are showing off their apps, I’d like to share with you a simple app I made to demonstrate what I mean. I made a simple chat application using the above technology stack (and others: socket.io, now.js, three.js). Keep in mind its mostly just a proof of concept, I wrote it in a few hours and is very primitive.

Demo: http://labs.travisglines.com

You can move around with the arrow keys and hit enter to send the text you have written. Its extremely simple and there are plenty of bugs/errors/vulnerabilities I’m sure, but it gets the point across.

I personally can’t wait for 3D to come to the web (hopefully its in the form of WebGL instead of Adobe’s Molehill) and think its just a matter of time until it happens. One of the things that people are instantly going to want to do is interact. In 3 dimensions that means sharing 3 position variables, chat and actions all in real time. Luckily enough node.js came along just in time to make the process nearly trivial and in 57 lines of server side code I can share 3 position variables and let users chat with each other. The individual pieces are themselves very cool, but with all of these technologies coming to maturity at roughly the same time the opportunities and possibilities are huge. Things like a web based MMO game, 3D shopping with friends in realtime (something I’d like to pursue here soon if we don’t get accepted to YC) and more are all possible at this point.

Whenever new technologies or server stacks come out, it seems there is always a company that succeeds and champions the tech. I look forward to what comes out of these technologies in the next few years and am excited for the company that gets it right.

I’m a huge fan of your browser, Chrome OS and your efforts to bring applications to the web. However I find that one thing missing would help me greatly: an SSH client built into Chrome.

I’ve even found more people looking for the same:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss/browse_thread/thread/50ec071f2512371d

http://www.google.com/support/forum/p/Chrome/thread?tid=5953879cbacec9f0&hl=en

Like said in those threads it could be extremely simple … type “ssh://username@domain.com:port_number”. You could even bookmark it and simply click it to go to the server, it would ask you for a password and bingo you’d be in. Heres a screenshot:

If you wanted to get real fancy with it you could do some theme overriding, ssh key stuff and scp file upload/download tool.

I use windows as my main operating system (software availability/drivers being the main motivation for this) and typically ssh into linux servers from there. This means that I have to use Putty or another SSH client to navigate to them. One main problem is if I’m on a friends/family member/library’s computer it probably has Google Chrome but no SSH client. This means I have to go out and download Putty onto their system if I can at all. (Administrator privileges required) An SSH client built in would solve that in one fell swoop.

I would love to use just one application to communicate with outside servers (and have applications live on the web, not on my desktop) some day and think that integrating an SSH client could be a huge step forward in this goal.

This morning I purchased the domain name nodrr.com (instead of tweet you nod … if that makes any sense … kind of a play on node.js + twitter + some physical action) for this purpose. It’s currently just after 4:15 PM on Saturday afternoon the East Coast of the US, I just went out Thursday night for a bit with friends so I’m not feeling all socially isolated by this, I just watched The Social Network (inspiration) and I’m feeling the need to code … lets make a Twitter clone in node.

I’ll be live blogging the whole time with edits, updates and battleplans. Please forgive my lack of attention to grammar/spelling/common sense English writing skills as I’ll be focusing on coding, not so much whether that use of ellipsis was correct. Watch my coding progress on github as well if you’d like: https://github.com/tglines/nodrr

4:25PM – First things first:

• Set up EC2 Micro Instance with Ubuntu 64-bit
• Set up git/github link on the EC2 instance
• Download and install Node.js, npm and some of the libraries I’ll be using
• Provision an AWS elastic IP and point nodrr.com at my EC2 instance

4:40PM – Box is up:

• EC2 is up, dns records are pointed to the elastic IP and we’re SSH’ed In
• Compiling node

5:10PM – Git project initialized, node built, npm installed.

• Grabbed express, connect-auth, mongoose, jade for now from npm
• Now installing mongodb packages
• Cue the Daft Punk
• Vote for the news item on HackerNews

5:35PM – Project directories setup, main script started … getting an unexpected error

• Grabbed a few more npm libs – connect-mongodb and connect-force-domain
• Getting and error with express.bodyDecoder() … hmmm

5:50 PM – Theres the bug … connect renamed bodydecoder to bodyparser

• Gotta keep up on this stuff – https://github.com/senchalabs/connect
• Back on track here

6:05 PM – Facebook Connect Setup

• Got oauth through npm
• Set up the app on facebook
• Jade template isn’t getting the title ….

6:10 PM – Battling a new one

• The Error …

6:23 PM – Hello World

• Got a hello world up (taking down now so dont check yet)
• Fixed the express.js local variable passing change … see my error above about the title
• Lets start putting in some real stuff here … auth/login … forms … all the good stufff

6:40 PM – Some Frontend

• Added a reset style sheet from yahoo and included style.css
• Included jquery from google’s cdn and a template main.js

6:55 PM – Dinner Break

• Be back in a bit

7:10 – Back @ it

• The buffalo chicken/cuscus was very tasty.
• Lets do a color scheme like: http://nodejs.org/
• Working on facebook login auth … we’ll later add more providers like twitter/github/google etc

7:30 PM – Once More Into the Breach

• Now Getting this error on redirect attempts: Error: Can’t set headers after they are sent.
• hmm…

8:10 PM – Redirect Problem = Solved For Now

• The redirect problem with facebook connect has now been solved
• After initial login with connect throwing the user to a make a username page.

8:45 PM – We Have Nods!

• The first nods are going in the database now, some serious securing to do
• Heres a screenshot:
  

9:05 PM – Stylin

• A little more style:
  

11:22 – Another Screenshot

• User Pages Much Better
• Need Pagination and character limits
• Screenshot:

12:18 – Check it Out: http://www.nodrr.com

• It works pretty decently but needs a lot of features to be more usable
• Please keep in mind that this was just a demo and proof of concept
• Check out my real startup @ www.exipe.com
• Time for bed.

1. There’s a steep asynchronus learning curve

Even though I’ve made many a javascript application before working on this project, including fooling around in node some, I found adapting to the asynchronous programming style a significant challenge. Every database interaction you do, every file system read or write, even http requests are asynchronous and need callbacks. This means that quite often if you want to do 10 different things for example you can end up with spaghetti code with 10 different scoping levels of indentation. As you learn and grow with the tools in node you learn that you can attach listeners to things and create separate functions to mitigate these problems and shortly after it almost feels natural.

2. The Node.js project and its libraries move fast, and you have to keep up

As many of you know node is a very new open source framework that has undergone many changes (some of which can break things) in the last few months. (since I started working with it on Exipe) This meant that I needed to be careful to notice what changed in the update and make sure I fixed anything that broke when updating. Some would ask “why don’t you just use the old version?” My response to that is the bug fixes and improvements are well worth the small changes in node. Another thing that happens is libraries such as mongoose (which we have been using to interact with our MongoDB database) undergo many changes as well. If I had any advice to give here it would be keep up with the latest going on in node and the packages/libraries you use because if you fall behind there may be no one willing to support an older version.

3. The community support is amazing and very active

Like many programmers I frequent sites like github, google groups and stackoverflow. Upon asking questions, posting comments or sharing bugs about anything node related on those sites I’ve found a response that was fast, cordial and most importantly … correct. This has made any headaches in dealing with such a new framework relatively painless because so many others are going through or working on the same issues. I think I even heard that the node github page is more active than the rails project page.

4. Some of the libraries can save you a ton of time

I found that one of the features I wanted in the site was a facebook login. While I’ve previously dealt with facebook connect in php and found it relatively painless there I expected something like that might be a headache in node. After finding the connect-auth library it turned into a piece of cake with a little monkey see monkey do thrown in from following the examples. I wanted to interact with S3 to store images and found a wonderful project called knox. Pretty much anything you can think of theres probably a tool that integrates with node that is of high quality and actively developed.

5. Server stuff is often easier to handle

Working on php applications I often remember having to learn the black magic of configuring apache to do what I wanted. While not rocket science it seemed to be overly difficult and finding easy to understand, accurate documentation was hard. In node, if you use it as the server things like changing the port you’re hosting it on is as easy as changing which number you tell it to listen on. (these things are often/can be internal to node)

6. You can “cut corners” on requests easier

It is fairly trivial to tell node to return a web request (say a user voting on a link) before interacting with the database, thus minimizing the time that the user is waiting for feedback. While I never got deep enough on a big project to want to do this with php, I’m not sure of how to do it off the top of my head.

7. Interacting with other websites is simple

Telling your webserver to go out, download a web page, parse it and return something of significance to you is very easy in node. Something I have found more challenging in other languages and frameworks. (while possible and very doable they don’t support it so directly as node does)

8. You can MVC all you want

In one of my previous posts I talk about a simple MVC setup with node.js. Similar to frameworks in other languages it is not only possible, but easy to set up and powerful

9. NPM is awesome

If you want to install/update any of the packages you are using for node it is always very easy to do so with a tool like NPM. A simple npm install whatever_package and bingo you have it, ready to go.

Hopefully this post has convinced some people to try out node for its active community/powerful tools and dissuaded some not intent on the extra learning/maintenance because that’s what I’ve found you’re probably in for. Whether node.js is the choice for you or not, I’ve found that the pros outweigh the cons in development of exipe and have loved working with the framework. Shameless plug: If you feel like checking out what a node.js website feels like head over to www.exipe.com and sign up for our beta coming in March.

For those of you from HackerNews waiting for me to open source the more specific/thorough example of a node MVC setup, worry not as its nearly done and I’ll share it soon

• Node.js (http://nodejs.org/) of course
• NPM (http://npmjs.org/) to easily install packages for node.
• Express (http://expressjs.com/) – a very nice web development framework built on connect (allows “controllers”)
• Mongoose (http://mongoosejs.com/) – a solid orm for mongodb in node.js that just released a much improved version (allows “models”)
• Jade (http://jade-lang.com/) – a template engine for node that allows some cool shorthand (allows “views”)
• Other tools were used of course but those were the essentials.

The application directory looks something like this:

1
2
3
4
5
6
7
8
9
10

/app-root
  /models
  /views
  /controllers
  /public
  /tests
  /scripts
  /logs
  /tmp
  app.js

Inside the application I instantiate express, include my mongoose models and include my routes/controllers from the controllers directory at the bottom. Inside the controllers I call res.render to render the jade views and it all works very nicely. If people would like me to elaborate on this more let me know.

A huge shoutout and thank you to the LearnBoost guys (TJ Holowaychuk, Guillermo Rauch, Aaron Heckmann, and many more that aren’t associated with LearnBoost) who’ve made Node.js web application development a breeze.

Node.js scales better and can do more with a simpler interface than Apache and PHP

The combination of apache and php to serve web sites is a threaded system. When a request comes in to apache it spawns a new thread and php renders the page. During heavy load apache’s spawning of threads can actually be the bottleneck in the system if the database is really fast. Node uses a very different system, running under Google Chrome’s V8 javascript engine it runs an event based system on one thread. It has callbacks for just about everything and the thread never needs to wait for i/o to finish before moving on to something else. During high load node excels because of this asynchronous system where it doesn’t use nearly as much memory because it does not spawn threads. (A great talk on the difference: http://jsconf.eu/2009/video_nodejs_by_ryan_dahl.html) Another thing to keep in mind is websockets are starting to gain a backing and having many requests coming into apache over websockets is not just complicated but slow.

Unix based OS

While this will probably be linux both technologies work great on FreeBSD and Apple’s OSX. This is really nothing new because there are things like wamp that exist for the lamp stack on windows. I however, cringe when someone tells me they are developing anything other than a flash or windows application on windows.

MongoDB

The NoSQL trend is gaining huge traction these days because of its extreme performance advantages. As opposed to MySQL and its other sql friends MongoDB keeps as much in memory as possible while still keeping it usable. I make this point because Redis provides the speed of memory but without the tools you would find in an sql database. Some benchmarking that proves my point: http://jayant7k.blogspot.com/2009/08/document-oriented-data-stores.html

I see a NUM future on the web, with users running real time web applications that utilize websockets. They are sending at least a factor of ten more requests per second and the lamp stack’s days are most certainly numbered

Check out my latest project: http://www.clubloc.com

Its an ongoing project of mine that’ll let you listen to music while seeing cool visualizations in canvas. I’ll be updating it soon to let users have their own playlists and share them with friends. Eventually I want it to have a chat capability that lets you meet local people and share what you’re listening to.

I side step the legal barriers to this by using a neat trick, if you can figure it out props to you.

It gets its inspiration from the notorious demo by 9emelents at: http://9elements.com/io/projects/html5/canvas/

The problem was that Google App Engine’s time is always running from Coordinated Universal Time (UTC), even when you use something like:

1
2

import datetime
datetime.datetime.now()

How you should and I have compensate for this is taking the difference of the time you want to UTC time in order to shift the time to the time zone of interest:

1
2
3
4
5

import datetime
time = datetime.datetime.utcnow() - datetime.timedelta(hours = 5) # for East Coast United States
time = datetime.datetime.utcnow() - datetime.timedelta(hours = 6) # for Central United States
time = datetime.datetime.utcnow() - datetime.timedelta(hours = 7) # for Rocky Mountains United States
time = datetime.datetime.utcnow() - datetime.timedelta(hours = 8) # for West Coast United States

This will give you the correct time in your time zone

I eventually figured it out and I’ll post my solution here just to make it easier for others:

1. Make sure the email in your main settings.py is valid and yours/part of your groups.
2. Also make sure that that email is included in the developers in the dashboard of the application. (https://appengine.google.com/)
3. If its not:
1. Log into the dashboard with the original user
2. Go into the developers section and invite them to also be an administrator to the application

This simple walk through doesn’t only pertain to those that use Google app engine, it applies to all users of Google app engine.

Hopefully it will save someone some time.

]]> http://www.travisglines.com/web-coding/google-app-engine-patch-invalid-sender-error/feed 0