• 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

10. Not having fun. If you’re not enjoying your work, you’ll never be great at it. You can be mediocre. But why bother.
9. Thinking you’re the first to think of it. Whatever it is, someone thought of it long ago. It’s just as much about timing as it is about having good ideas. Keep your eyes and ears open until the time is right.
8. Thinking that your tools of choice are better than whatever else is out there. Whether it’s what language you prefer, what operating system you like or what editor you use, get down to brass tacks and make the tools work for YOU.
7. Thinking you won’t burn out. There are only so many 12-20 hour days that you can take. You won’t realize it until you’ve experienced it. But that doesn’t make it any less true. Work at a pace you can sustain. The occasional push is OK.
6. Thinking you can do everything alone. Even if you can, you won’t want to forever. Let others share the fun.
5. Thinking you’re going to get it right the first time. You won’t. Plan to throw the first one away.
4. Turning everything into a framework. Frameworks get complicated in the long run and don’t save as much time as you thought they would.
3. Writing something from scratch instead of taking the time to learn how to use the best tool on the market. Even though you think it’s a great idea now to write your own, your idea too will have shortcomings that will be just as much a pain to your client. Save everyone some time and just sit down and rtfm.
2. Thinking you know better than your client. They still sign your checks.
1. Over-engineering. Some problems just aren’t that complicated.

Firebug is the absolute must-have application for every web developer. Firebug gives me the ability to manipulate every aspect of my CSS style sheets in real-time, right in the browser. So a) I don’t need to buy any expensive software, b) I don’t need to constantly alt-tab back and forth between an IDE and a browser followed by a page refresh. The development process is much more fluid and interactive, giving me much greater control over the code.

I’ve been using Firebug for a number of months. It has made me infinitely more capable at developing CSS style sheets. I haven’t seen any apps that come even remotely close to Firebug in terms of the productivity gain that it yields.

Not only am I faster with Firebug. The overall quality of my style sheets is much better. With Firebug I can move elements around, resize them, change padding and margin values, change colors and fonts, and on and on.

The most valuable aspect of Firebug for me is that it encourages me to be more aggressive and take more risks when styling a site because. My development tool set is now much less intrusive, fading into the periphery and allowing me to connect much more organically with the code.

There have been a number of discussions out there in the ether about frameworks vs. libraries, what they are, how they differ, which is better and why. Here’s my $0.02 on frameworks. I’ll do a compare and contrast piece in a follow-up post.

Frameworks evolve. They’re the by-product of refactoring. Libraries on the other hand are designed.

Libraries are tools which can be used over and over again to accomplish a specific task. They’re not sexy. They’re simple. They can be clever. They’re intuitive and easy to use. They’re little rays of sunshine through the haze of trying to figure out and build a product your clients will love.

Frameworks, on the other hand beget more frameworks. Someone builds something. Along the way they see a pattern and extract it. This is good software engineering practice. But it’s evidence that the problem wasn’t thought through completely.

Authentication and authorization frameworks are common. Template-based presentation frameworks are also common. Persistence frameworks are ubiquitous. The list goes on and on.

What makes frameworks so insidious is the fact that they’re symbiotic with specific applications. When you use frameworks to build an application you eventually find yourself at a point where the application can’t evolve because the frameworks have become too unwieldy and cumbersome to be useful. You end up chalking the whole thing up to a learning experience and begin the process of throwing code overboard in an effort to save the sinking application. More often than not it’s easier to just start from scratch.

This evolutionary process isn’t necessarily a bad thing. Where it really gets nasty though is after you’ve shipped the software and have to maintain your application through upgrades. If you were able to avoid starting over from scratch, the effort and complexity involved in keeping your application consistent while simultaneously refactoring the frameworks and trying to deliver new features and bug fixes will make you want to set your hair on fire.

Over time you will either realize that frameworks are not the answer, or your competitors will and build better software faster than you can fix yours. Eventually, the framework will die.

I’ve wrestled with the box model variations between IE and Mozilla for years. And today I finally arrived at what seems to be the absolute easiest way to make things work.

#mydiv { width: 500px; padding: 10px; margin: 0; border: 0; }
* html #mydiv { width: 480px; }

The first line is valid and interpreted by both browsers. The second line is interpreted only by IE. Setting the width to the width you want (500px) minus (padding + margin + border) will give you the effect you want. You’ll have the same size box in both browsers. Yeehah!