Developer Links

by Joey deVilla on March 27, 2007

For you developers out there: some of the most interesting application development links I found today…

  • Security and Obscurity [DMiessler.com]: Many of us are familiar with a concept know as Security by Obscurity. The term has quite negative connotations within the security community — often for the wrong reasons. There’s little debate about whether security by obscurity is bad; this is true because it means the secret being hidden is the key to the entire system’s security. Obscurity itself, however, when added to a system that already has decent controls in place, is not necessarily a bad thing. In fact, when done right, obscurity can be a strong addition to an overall approach.
  • Ruining the User Experience [A List Apart]: AJAX can be used to make wonderful web applications, but for people without JavaScript (especially those using mobile phones), AJAX means unusable sites. Aaron Gustafson suggests that site designers should consider these levels of user need:
    1. No frills.
    2. Make it pretty.
    3. Make it sing.
  • Applied Web Heresies [Phil Windley's Technometria]: Phil Windley’s notes from the ETech 2007 tutorial by Avi Bryant, Applied Web Heresies, in which Avi invites the audience to join in an exercise in coding a Seaside-like web app framework. I met Avi at DemoCamp 5, where he demoed DabbleDB, a nifty little app that takes spreadsheets misused as databases and converts them into proper database-driven applications.
  • How to Beat Google, Part 1 [Skrentablog]: “Grow a spine people! You have a giant growing market with just one dominant competitor, not even any real #2. You’re going to do clean-tech energy saving software to shut off lightbulbs in high-rises instead? Pfft. Get a stick and try to knock G’s crown off.”
  • 7 Signs Your Project Will Never Make it to Production [Rail Spikes]: An article from a Ruby on Rails group blog where my friend Luke Francl is a contributor. The seven signs, according to Ben Moore, are:
    1. The client doesn’t have any wireframes or UI mockups.
    2. The client would rather describe the app over the phone than with a document.
    3. Creating the app fulfills a personal mission for the client.
    4. The client asks: “Are you interested in working for equity?”
    5. After a payment or two, the client asks you to reduce your rate.
    6. The client says “I’m going to lean on you heavily to tell me what this application should do.”
    7. The client doesn’t have a customer who wants to use the app before it’s built.

Leave a Comment

Previous post:

Next post: