Archive for the ‘Technical’ Category

Top Free Software and Webapps

Posted December 18, 2007
Filed under: Technical |
* Leave a Comment

Let’s sidetrack abit here for some free opensource ware goodness. These tools greatly enhance our efficiency at absolutely no cost!  As we wrap up the year 2007, it’s the perfect time to put together an authoritative guide to our favorite pieces of free software and web services for common computing tasks on every platform. After the jump, check out our favorite freebies to date in over 20 categories and counting, as we add your suggestions to the list.

Application Launchers

Backup Utilities

BitTorrent

Bookmarks

Calendar

Desktop Search

Disk Space Visualizers

DVD Rippers

File Syncing

Image Editing

Image Viewers/Managers

Instant Messenger

Macro Makers

Media Players

Password Managers/Helpers

PDF Readers/Writers/Editors

Personal Finance/Money Managers

Start Pages

Telephony Managers/Helpers

Text Editors

To-do List Managers

Virus Killers and Malware Cleaners

Web Clippings

Wikis

Zip File Extractors

Top 101 Lists

Posted November 26, 2007
Filed under: Interesting, Lifestyle, Personal Finance, Technical |
* Leave a Comment

Coming up with 101 lists has been a trend these days! I’ve been saving these lists in my delicious account and elsewhere but thought I’d share them with you all in case you haven’t seen them yet!

So, here is a Master List of the best ‘101′ lists out there! This is an ongoing list and I plan to add to it as I find more! If you know of some good 101 list and would like me to add to it, please let me know in the comments! or via the Contact Form

Enjoy!

101-fun-thumb.jpg

  1. 101 Self Improvement Resources @ Pick the Brain
  2. 101 posting ideas that will make your blog sizzle @ I Help You Blog
  3. 101 Commonsense Management Tips @ business Intelligence Lowdown
  4. 101 Link Building Tips to Market Your Website @ SEOBook
  5. 101 Amazing Earth Facts @ Space
  6. 101 Real Estate Blog Topics @ Real Estate Tomato
  7. 101 Uses For PLR Articles @ memwg
  8. 101 Blog Posting Ideas @ SEO 2.0 Onreact
  9. 101 Best Web Freebies You Probably Don’t Know @ JennyHow
  10. 101 Essential Freelancing Resources @ FreeLanceSwitch
  11. 101 Free Ways to Increase Your Blog Traffic @ CanIMakeBigMoneyOnline
  12. 101 Essential Blogging Resources @ Blogtrepreneur
  13. 101 Suggestions for Squeezing More Fun Out of Life @ Pauls tips
  14. 101 Ways to Monetize Your Website or Blog @ Vandelay Design
  15. 101 Reasons to FreeLance @ hrworld
  16. 101 Ways to make Your Blog More Popular and Successful @ SEO 2.0 Onreact
  17. 101 Tools to Convert Video, Music, Images, PDF and More @ Cogniview
  18. 101 Ways to Make Money off Open Source @ Manageability
  19. 101 Simple Vegan Meals @ The Urban Vegan
  20. 101 Resources for Self Published Writers @Self Publishing Blog
  21. 101 Blog Tips I Learned in 2006 @ DailyBlogTips
  22. 101 Ways to Save Money @ CreditCave
  23. 101 Dumbest Moments ( biggest boors, boffoons and blunders of 2007) @CNN-Money
  24. 101 Cities for Drinking @ Citytoplist – they have various lists of US cities with some fun things to check out!
  25. 101 CSS Tips and Tutorials and Examples @ lxpages
  26. 101 CSS Resources to add to your toolbelt of awesomeness @ jasonbartholme
  27. 101 things that the Mozilla browser can do that IE cannot @ xulplanet
  28. 101 Tips to Improve Your Web Presence @ SearchEngineOptimization
  29. 101 Blogging Building Tips @ DeWittsMedia
  30. 100 Blog Topics I Hope You Write @ ChrisBrogan
  31. 101 Ubuntu Tips Tricks and Tutorials @ lxpages
  32. 101 Ways to Run Out of Things To Blog About @ ProBlogger
  33. 101 FeedFlares for a Better Tomorrow @ FeedBurner
  34. 101 Zen Stories @101ZenStories
  35. 101 Easy Ways to Use Google Website Optimizer @ ConversionRateExperts
  36. 101 Ways to Put 101 dollars in your pocket this month @ Blogging Away Debt
  37. 101 Steps to becoming a better blogger @ Lifehack
  38. 101 Tips For Improving Children’s Behavior @ ParentingIdeas
  39. 101 Ways to Organize Your Life @ Project Management Source
  40. 101 resources to help you build a better web form @ Jasonbartholme
  41. 101 Web Marketing Ideas and TIps @ SEO Pedia
  42. 101 New Uses for Everyday Things @ Real Simple
  43. 101 Essential Blogging Skills @ Skelliewag
  44. 101 Tips I learned from Blogging @ Etienneteo

As if these weren’t enough lists to read!

45. here is a very comprehensive list of 1001 Lists to Read Before Your Die @Terabell

46. Check out List of Bests for other people’s best lists where I think you can add your own list to the huge resource!

47. Finally, If YOU would like to create your own 101 list, there is a meme going around the blogoshpere about doing 101 things in 1001 days! It is hosted at triplux; The site has other people’s 101 things-to-do-lists where you can get plenty of inspiration!

UPDATE: two more lists added today!

Free Programming Tips are Worth Every Penny.

Posted October 22, 2007
Filed under: Technical |
* Leave a Comment

Sometimes people say to me, “Hey, Wil, you’ve been programming since dinosaurs roamed the earth… do you have any advice for young whippersnappers like us?”

And I always respond, “Hey, you kids, GET THE HECK OUT OF MY YARD!”

No, no, I usually demur with, “Oh, gosh, I don’t know,” as I look down shyly and shuffle my feet.

But, I’ve thought about it a lot recently, after writing so much solo code for Delicious Library (for the first time in many years), and then taking on a new programmer and trying to impart my style on him. And what I’ve come up with is a style I call:

* The Way of the Code Samurai *

Now, I don’t actually know much about real samurai, but the basic thing I’ve heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.

That’s how you should code.

- Think first. Think some more. Think about the whole problem. Think about a little part of the problem you’re going to start with. Think about the whole thing again, in relation to your idea on the starting point.

Don’t write code until you know what you’re doing. Now, you may not be able to “know what you are doing” just from thinking, in which case you should start a TEST project and write a bunch of ugly code to make sure your ideas are correct.

Then, start again, in a new directory. We had seven or so different test project directories during the making of Delicious Library — one for the video barcode reader, one for the store, one for amazon XML parsing, one for talking to Bluetooth scanners, etc. We learned how to do what we were going to do BEFORE we uglied up the main project with a bunch of code.

Then we copied the good parts out of the test project, and left the cruft. This let us observe rule #2…

- Write all your code “clean,” the first time you write it. Make classes for everything. Use enumerated types. Don’t take shortcuts. Don’t have any part of the code where you say, “Oh, yah, I just glossed over that for now.” You are NOT going to go back and fix it. Seriously, how often do you say to yourself, “I think I’ll dive into this messy code today and try to make it nice and pretty without adding any functionality?” Nobody is going to pay you for that. In fact, I got called on the carpet for cleaning code during a major update to a piece of software at a previous job — “What are you doing spending time modifying code that already works? Just add your new features and be done.” Never mind that I couldn’t understand the code, or that clean code is stable, maintainable, extensible code.

Don’t gloss over anything. Write every line to be bulletproof. Write every method as if every other method was out to get your code and try to make it crash, and your job was to make sure it wasn’t going to happen in YOUR code. Assume the user is going to hit keys randomly. Assume the network is going to get disconnected. Assume the hardware will fail.

Explain your routines aloud. Do you find yourself saying, “Well, this isn’t totally correct, but it works because I know that at this point…” STOP. Redo it. Write it the correct way.

And, if you’re in code anyways to extend it or fix a bug, CLEAN IT. Clean as you go, always. Don’t consider code to be static. Turn those constants into an enumerated type like you always meant. Take those hard-coded strings and make class variables for them. Replace english phrases with NSLocalized versions. Clean, clean, clean as you go.

- Less source code is better. This is almost always true. The exceptions to this are so rare that every time you think you’ve found one you should REALLY doubt yourself. Less lines of source code almost always means less code that new programmers have to understand when they come on the project. It means less stuff for you to remember next year when you are in the middle of another version. It means fewer places for you to have mistyped something. It means fewer instructions to execute. It means fewer things to change when you re-architect.

There are some interesting corollaries here. For instance, if you’re writing a class to display some text in red (for some reason), don’t add a bunch of methods “for the future” that allow you to draw the text in blue or green or purple. Because that’s more code than you need right now, and “less code is better.”

But, if you suddenly realize you want to draw purple text, you could write the red code again, except put in the color purple. But, “less code is better,” so you really need to abstract out the text-drawing code and make it take a color parameter, so you can re-use the same code.

The lesson I’m getting at is, don’t try to make code general until you actually need it in more than one place. The worst libraries in the world are the ones people write without actually writing any code that uses them to do actual work for actual users.

And don’t write longer, more obtuse code because you think it’s faster. Remember, hardware gets faster. MUCH faster, every year. But code has to be maintained by programmers, and there’s a shortage of good programmers out there. So, if I write a program that’s incredibly maintainable and extensible and it’s a bit too slow, next year I’m going have a huge hit on my hands. And the year after that, and the year after that.

If you write code with more code that’s fast now, you’re going to have a hit on your hands. And next year, you’re going to have a giant mess to maintain, and it’s going to slow you down adding features and fixing bugs, and someone’s going to come along and eat your lunch.

I’m not saying slow code is good. There’s a time and a place for optimizations…

- The time and place are AFTER YOU ARE DONE. Optimize methods ONLY after they work and are bulletproof AND you’ve done testing in Shark and discovered the method is critical.

Don’t optimize as you write. Why not? Because, in all probability, you’re wasting your time. The VAST majority of the code programmers optimize is executed so rarely that its total speedup to the program can be measured only in nanoseconds. Also, you’re probably not very good at it. No insult, but machines and libraries are complex systems, and your guesses as to what’s slow are probably pretty bad. You need to run testing tools to find out what is ACTUALLY slow. The results are often surprising. (For instance, in the Mac OS 10.3, having lots of tooltips in a view that you remove and add back to a window a lot is EXTREMELY slow. This is not something you can possibly know to optimize without doing testing in Shark.)

The next time you go to make something a little harder to read but a little faster, ask yourself, “How often will this REALLY get called?” Is the answer less than a hundred times a second? Because processors can now process several BILLION operations a second.

Now, Delicious Library isn’t the zippiest program in the world on all hardware, but, actually, it’s a LOT faster than it was initially. Those huge, beautiful covers really suck down memory. When we first wrote Library, if you loaded more than about 400 items, the cover images would suck up all your main memory and the program would just crawl. (It was like iPhoto 1.)

I re-architected the entire cover caching and compositing system, and got it so that we could comfortably handle several thousand items, and, if you use the table mode, possibly tens of thousands (I’ve never had that many items). This took several weeks to do. Now, I’m not as zippy as iPhoto 4, but I’m actually pretty close to the performance of iPhoto 2, and considering I’m just one guy and this was Delicious Library 1, I’m pretty proud of that.

What’s the point? The point is, if I’d spent a bunch of time optimizing other parts of the program as I wrote it, I would not have had those weeks at the end to fix the imaging path, which was the slowest part. I would have had to have shipped with a program that could only handle a couple hundred items, and then I would have immediately had to patch it when people started scanning in thousands.

Ultimate Web Development Cheat Sheet Guide

Posted August 27, 2007
Filed under: Technical |
* Leave a Comment

So you’re sitting there on Saturday morning, sipping on a nice warm cup of coffee or tea, smell the freshness of the morning, and whipping up some html, CSS and trying out some new AJAX programming. You’re stuck on something, you wish you had a quick cheat sheet to get you back on track. Look no further if you’re a web developer! This is the Ultimate Web Development Cheat Sheet Guide!

JavaScript

JavaScript Cheat Sheet

Addison-Wesley’s JavaScript Reference Card

JavaScript Quick Reference

JavaScript and Browser Objects Quick Reference

JavaScript in 10 Minutes – Thanks Joseph

CSS

CSS Help Sheet

CSS Shorthand Guide

CSS Cheat Sheet

Cascading Style Cheat Sheet

CSS Cheat Sheet

CSS Quick Reference

Leslie Franke CSS Cheat Sheet

Design 215 CSS Quick Reference

CSS Level 1 Quick Reference

CSS Level 2 Quick Reference

CSS Property Index

HTML/XHTML

HTML Help Sheet

XHTML Cheat Sheet

HTML Cheat Sheet

HTML Character Entities Cheat Sheet

PDF HTML Cheat Sheet

Character Entity References in HTML 4 and XHTML 1.0

HTML & XHTML Cheat Sheet

HTML Tags

HTML Quick Reference Guide

A Simple Guide to HTML

Reference HTML Cheat Sheet

HTML Tags Cheat Sheet

AJAX

What’s Ajax? Cheat Sheet

Prototype Cheat Sheet

Scriptaculous Combination Effects Cheat Sheet

Scriptaculous Cheat Sheet – Thanks Joseph

AJAX for ASP.net Cheat Sheet

ASP.net AJAX Client Life-Cycle Events

MooTools Cheat Sheet – Thanks Joseph

Colors

RGB Hex Color Chart

Interactive Color Picker

HTML Color Codes

Color Reference Guide

Microformats

Microformats Helper Cheat Sheet

Microformats Cheat Sheet

Jack Daniel’s Microformats Cheat Sheet

Browser Compatibility

W3C DOM Compatibility Tables

Browser Compatibility Interactive Table

XML

Fusebox 4.1 XML Cheat Sheet

VoiceXML Reference

MathML Reference

XML Schema 2001 Reference

XML Schema 2000/10

XSLT Quick References

XML TopicMaps 1.0 – Quick Reference Card

XML Quick References

XML Schema – Structures Quick Reference

XML Schema – Data Types Quick Reference

XSL FO Reference

XSLT Quick Reference Card

XSLT Reference