• Search

• Recently Written

  • Economy or Agony?
  • Darnit! Basecamp did it again!
  • Document Templates for Entrepreneurs
  • Evans Codeworks is Hiring!
  • The easy way to learn .NET
  • Cornell entrepreneurship on MySpace
  • Speed up Rails apps with RPM
  • Inbound marketing
  • Excellent screencasts available on .NET MVC
  • Entrepreneurship videos from Stanford

• Categories

  • .NET
  • Cornell
  • Entrepreneurship
  • Evans Codeworks
  • Fitness
  • Fun
  • Online marketing
  • Productivity
  • Programming
  • Puzzles
  • Ruby on Rails
  • Software Performance Tuning
  • Uncategorized
  • Web Development

• Archives

  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007

Look forward to seeing the results.

We all need goals right? And why not a goal that gets me off my butt.

I’m making this commitment public to keep myself honest.

100 pushups by Autumn.

Ready, steady, go!

Here’s another site in the same vain as failblog. Super-funny stuff.

www.doingitwrong.com

Thanks to my cousin Dave for the link.

Get a first life

So funny.

I have to post this. I spent about an hour tonight in tears laughing so hard at what I found on this site. Super funny stuff.

www.failblog.org

Here’s a great post to read for anyone who’s interested in technology entrepreneurship.

It’s titled “Postmortem”. And it’s all about the the lessons learned from the experience of trying to get GameClay off the ground.

It’s probably counter-intuitive to many people, but failure is one of the things I really like to see on the resume of an entrepreneur. Nothing educates like failure.

Anyone who’s got the drive and tenacity to stick with a startup long enough to call it a failure doesn’t like to fail. They’re driven to succeed.

Failing is one thing. Failing, dusting yourself off, getting back out there an doing it again is something that only entrepreneurs who have what it takes to succeed will do. Someone who’s failed over and over again and continued to get back out there with a new idea is someone with a lot to teach about what not to do.

So, despite the end of GameClay, the experience of starting it clearly taught a lot to it’s founders. And that article is a great digest of some of the main lessons they learned.

Just a good reminder. Every good idea needs a champion.

Here are 100 reasons why.

Two apps in the last few months have helped me a great deal to stay organized. I recommend them highly.

Evernote

“Remember Everything” is their tagline. It’s an amazing service which is almost too powerful. I don’t use it all the time. But there are a number of things, images for instance, that I can ONLY track with Evernote. So it’s nice to have this tool in my arsenal in the fight against chaos.

Jott

Sometimes I need to leave myself a note. I don’t have a pen and paper, I’m not near email, so I use Jott. I just call up Jott, leave a voice message and Jott transcribes my message to text and emails it to me. It’s as easy as it gets. It’s just a really nice tool for those cases where all I have is my mobile phone.

I’ve kept up with the rise and fall of the GTD crowd. Maybe it’s never actually fallen. Maybe it never really rose. In any case, more structured approaches to staying organized never worked well for me because there are too many rules. I find that I’m much more capable and productive with a small number of really specific tools that allow me to stay connected in all of the odd circumstances I find myself in.

Lastly, I should mention Basecamp and Google Calendaras well. They’re my workhorses for collaborating and keeping organized.

So there you have it. Those are the tools I use to help me stay organized. What works for you? Drop me a comment or email to let me know.

Here are a few simple suggestions that will go a long way toward helping you write highly-performance systems.

Be smart: Performant systems are what you get when you avoid things that slow a system down. Computers are inherently fast. Just don’t get in their way. Know what things slow a system down and just avoid doing those things. Beyond that speed comes from applying common sense.

Stay Fresh: Keep your brain sharp by often taking breaks. Stop and take time to recharge your mental batteries when things start to seem complicated.

Use the right tools: Don’t use a sledgehammer to drive a nail. Don’t use “enterprise” technologies to build prototypes. Every tool has strengths and weaknesses. Effectively leveraging strength will make high performance possible.

Be careful with frameworks: Frameworks are good for abstracting repetitive tasks. They seldom offer speed and simplicity. Use them as needed. But don’t base your architecture or design on them.

Beyond these simple points it comes down to experience and knowing the ins and outs of the specific tools and technologies you’re using.

There a couple of ways to invoke javascript events via the onClick handler.

Approach #1

The one I see most often is this:

<a href="#" onClick="someFunction();">Click me. I know you want to.</a>

This is my least preferred. Why? Because depending on what the function actually does, there’s a good chance that what will happen is that someFunction will be called and the screen will then shift to the top of the document. This I find just annoying.

Approach #2

An improvement on that first case is this:

<a href="#" onClick="someFunction(); return false;">Click me. I know you want to.</a>

By returning false inside onClick you execute the javascript, but the screen won’t scroll to the top of the document. This is better. But, it’s still not perfect. The problem with this is that it doesn’t degrade well into browsers with javascript turned off. If javascript is disabled in the browser, clicking on the link will just pop the user to the top of the page and leave them there. This is unexpected and it’s not helpful to them in any way.

Approach #3

The best overall approach is this:

<a href="/javascript_required.html" onClick="someFunction(); return false;">Click me. I know you want to.</a>

In the event that the user has javascript disabled in their browser, they will be taken to a page (/javascript_required.html) where you can explain to them that they have javascript turned off and that it’s needed for certain functionality to work. In the event that their browser has javascript turned on, then they will see whatever behaviour you intend. It’s the perfect solution!

One note on these approaches: The second case is my preferred technique while developing and debugging applications. Without the "#" as the href, should your event handler throw an exception or otherwise run into trouble, your browser will just go to the url specified in the href attribute. If this takes you to another page you won’t get to see what went wrong. So, leave the href attribute as "#" while debugging. Switch it to something akin to "/javascript_required.html" when going to production.

← Previous Page — Next Page →