You are viewing an old page from the historical archives.
Information on this page may be out of date and has been preserved purely for historical purposes.
It may include broken links to websites that no longer exist.
Click here to return to archives
Best Of 2007
Best of the Web 2007
Our Favorite Discoveries for Programmers

300 Ideas for Game Play Mechanics

Three Hundred -- Three Hundred Mechanics_1195371383421.png
Sean Howard, over at, is making good progress on his goal to come up with 300 unique ideas for game play mechanics. At this point Sean had developed 58. Now, these aren't just one or two sentences like, "Make the blood blue, instead of red.", but are equivalent to full length articles. There are some real nuggets of gold in there. And Sean is nice enough to give them away for nothing more than a mention in your game. If you want to build a game, but can't think of an idea, or you need a little something to spice up an existing game you are working on, check out Three Hundred Mechanics.

Technical Debt - Nice Programming Metaphor and Long Blog Essay

Screenshot - 11_4_2007 , 6_30_18 AM_thumb.png
A nice way to look at the cost of cutting corners and making strategic decisions about putting things off..

The term "technical debt" was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.
What is Technical Debt? Two Basic Kinds
The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)


COfundOS: A site where people can join and fund Open Source Software

Screenshot - 10_30_2007 , 6_00_58 PM_thumb.png
Looks nice.. similar to http://micropledge but focused more on open source.  Looks like they don't charge a fee for their service?

The Cofundos process itself is schematically depicted in the figure and works as follows:
Somebody misses an open-source software tool or library for a specific purpose, a feature in an open-source software or a plugin for an existing software. He describes the project to develop the software.
Requirements-Engineering: Other people help enhancing the description of the project by adding specific requirements and comments.
Bidding: Users who also like the project and need the resulting software, bid a certain amount of money, which they will donate to the project performer after its successful completion.
Offering: Specialists who are capable to perform the project and to develop the respective software offer to realise the project for a certain amount of money and within a certain timeframe.
Call for competitive offers: As soon as the sum of the bid amount exceeds the money requested by the first offer, a call for competitive offers is started and lasts for three week.
Accepting an offer: After the three weeks call period for alternative offers is elapsed, all bidders are requested to vote about which offer to choose. Bidders votes are weighted by the amount of their bid. The specialist with the majority of the votes is selected to carry out the project.
Voting about project success: After the specialist announces the completion of the project or the development timeframe as suggested by the specialist elapsed, the bidders vote about how the initially defined requirements (agreed on by the specialist) are met by the provided solution.
Donation to the specialist carrying out the project: If the majority of the bidders agree that the requirements are met, bidders are requested to make the respective donations.
If the majority of the bidders decide that the requirements are only partially met by the implementation, an extension will be granted to the specialist for improving his implementation.
If the majority of the bidders decide that the requirements are not met by the implementation, the project failed, no donations will be made and the project might be reopened for bidding.

Good Article For Beginners On Version Control (w/ Pictures & Examples)

A Visual Guide to Version Control - BetterExplained_1191263713421.png
There is a very good introduction to version control at BetterExplained.


Also be sure to check out this article by dc member nevf: "Get up and running with TortoiseSVN and Subversion in 15 minutes."

Continue reading and discuss.

7 reasons I switched back to PHP after 2 years on Rails - Blog Article

Screenshot - 9_24_2007 , 10_04_56 AM_thumb.png
Very interesting article that hits home with me as someone who enjoys PHP and is not all that fond of the Ruby syntax etc., but thinks that the focus on MVC stuff from Rails is a good idea..

I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.


Programming Can Ruin Your Life: A Fantastic Blog Essay on the Mind of a Coder

Screenshot - 9_13_2007 , 2_58_59 PM_thumb.png
I was going to post the in the Developer's section of our forum but in my view it's too important for that.

I urge all programmers and loved ones of programmers to read this essay.  It may seem pessimistic but it's beautifully written and better captures any description of the pitfalls (and amazing drive) of programmer-centric mindset that i have ever read.

I think most programmers will recognize some of themselves in this essay -- but it's real value may be to those people who live with coders and want some insight into why they are the way they are.

So if you're a coder with a significant other, print this out and give your loved one a copy to read.  It may help them understand why you are the way you are..

...Programming changes the way you think...
Programming presents you with a problem and allows you to eventually solve it provided you don’t quit. A solution is out there somewhere. Make enough attempts and chances are you’ll eventually prevail. Aren’t computers great? They afford a large degree of freedom in problem solving. If nothing else, you are able to make as may attempts as you please and it will happily execute each one. This instills in you a sense that failure is not final. Any obstacle can be hurdled. This is not true in the real world. While you may find second chances now and again, the wheels that turn in the big blue room are largely unforgiving. Time marches on in one direction.

When faced with an interesting programming problem your mind will chew it over in the background. Maybe it’s an algorithm you need to develop, maybe it’s a tricky architecture problem, maybe it’s data that needs to be modeled. It doesn’t matter. Your mind will quietly work the problem over in search of a solution. The “ah-ha!” moment will come when you’re in the shower, or playing Tetris. This practice of constant churning will slowly work its way into the rest of your life. Each problem or puzzle you encounter will start it’s own thread; the toughest and most troubling of which will be blocking...

Bjarne Stroustrup (creator of C++) talks about the development of C++0x

blog clipart
Bjarne Stroustrup (creator of C++) talks about the development of C++0x, the next generation of C++ standard.  This is a 1+ hour video of a talk.

A good programming language is far more than a simple collection of features. My ideal is to provide a set of facilities that smoothly work together to support design and programming styles of a generality beyond my imagination. Here, I briefly outline rules of thumb (guidelines, principles) that are being applied in the design of C++0x. Then, I present the state of the standards process (we are aiming for C++09) and give examples of a few of the proposals such as concepts, generalized initialization, being considered in the ISO C++ standards committee. Since there are far more proposals than could be presented in an hour, I'll take questions.


I wrote a wrong reply in this thread about my conflicted feelings as a 20+ year c++ coder --mouser

microPledge: Funding Software by Pledging to Donate Money

Screenshot - 8_10_2007 , 2_09_49 PM_thumb.png
Interesting idea.. More formal version of the kind of thing we do in our Coding Snacks section.

Have an idea? Just need funding?
Want to join with others to support to an idea?
This site is for you.

License fee:
Open source license: Free.
Closed source license: 3% of each progress payment.
Proprietary license: 6% of each progress payment.
Quitting a project early: 10% of your earnings so far; microPledge will pledge the fee to the project so it can be earned by any subsequent developer.
Refunds. Unless you are doing open source, you must refund all your earnings back to pledgers if you don’t finish the project. Either that or you must release your source.
Upload cap: for project releases above 10MB, $0.20 per MB in excess.
Incubator: $20 basic fee. Challenges cost $60 per hour of arbitration after the first hour.

I hope services like this succeed and that this will become a viable way of funding software in the future.

Article: Please don't steal this Web content

Screenshot - 8_2_2007 , 11_25_29 PM_thumb.png
Nice short article about the practice of automated website "scraping", where sites are created by scripts to steal content from other sites, in order to show up in web searches and get advertising money.

VanFossen isn't referring to the kind of plagiarism in which a lazy college student copies sections of a book or another paper. This is automated digital plagiarism in which software bots can copy thousands of blog posts per hour and publish them verbatim onto Web sites on which contextual ads next to them can generate money for the site owner.

Such Web sites are known among Web publishers as "scraper sites" because they effectively scrape the content off blogs, usually through RSS (Really Simple Syndication) and other feeds on which those blogs are sent.
"It wasn't the issue of money," Leder added. "When other people's business model is based on stealing content, that's a significant problem."

The article mentions an interesting search engine for finding copies of your site content on the web: CopyScape.

For Coders: Static Versus Dynamic Typing (A great overview)

blog clipart
I'm in the process of reading this, and even though I haven't finished yet, it has already proven itself as a "must read" as a great overview of the issue of static versus dynamic typing.

Angle Brackets and Curly Braces
Programming with "Duh" Typing
by Bill Venners
July 6, 2007

    To what extent does the productivity of dynamic languages come from the lack of typed variables versus the reduction in "finger typing" required when you don't have to declare the types? The technique of type inferencing in static languages may shed new light on this old debate.

Over the years here at Artima we've had a number of debates and discussions about static versus dynamic typing. Here are a few:

    * Are Dynamic Languages Going to Replace Static Languages?, discussion of a weblog post by Robert C. Martin.
    * Typing: Strong vs. Weak, Static vs. Dynamic, discussion of a weblog post by Aahz.
    * Strong versus Weak Typing, discussion of an interview with Python's creator Guido van Rossum.
    * Implicit versus Explicit Dynamic Typing, discussion of a weblog post by Christopher Diggins.
    * To type or not to type, discussion of a weblog post by Jim Waldo,
    * Use the Best Tool for the Job, discussion of a short article by a younger me.

World of Borecraft: The Trouble with Video Games

Screenshot - 7_2_2007 , 1_27_02 PM_thumb.png
Here is an article about problems with computer/video games with purported educational value that I thought was interesting. See what you think.

...Any child of the 1980s and 1990s will remember Mavis Beacon Teaches Typing and Math Blaster Mystery: The Great Brain Robbery, games that promised to make skills acquisition fun. They'll also remember ditching Mavis Beacon for something with guns as soon as their parents' backs were turned. Making games educational is like dumping Velveeta on broccoli...


The Best Introductory Language

Screenshot - 4_13_2007 , 12_20_35 PM_thumb.png
Now I'll just bet the best way to start programming is NOT to jump into C/C++, which was what I did.

...This paper examines several approaches to which programming language is the best, and afterwards gives several useful relations for which languages should come first. Finally it gives a final verdict, defends it and then gives some other good food for thought...


Software patents, and the crazy business side of software.

blog clipart
Here is an interesting essay on software patents, and the business side of software development:

The most common is to grant patents that shouldn't be granted. To be patentable, an invention has to be more than new. It also has to be non-obvious. And this, especially, is where the USPTO has been dropping the ball. Slashdot has an icon that expresses the problem vividly: a knife and fork with the words "patent pending" superimposed.

The scary thing is, this is the only icon they have for patent stories. Slashdot readers now take it for granted that a story about a patent will be about a bogus patent. That's how bad the problem has become.

The problem with Amazon's notorious one-click patent, for example, is not that it's a software patent, but that it's obvious. Any online store that kept people's shipping addresses would have implemented this. The reason Amazon did it first was not that they were especially smart, but because they were one of the earliest sites with enough clout to force customers to log in before they could buy something. [1]

We, as hackers, know the USPTO is letting people patent the knives and forks of our world. The problem is, the USPTO are not hackers. They're probably good at judging new inventions for casting steel or grinding lenses, but they don't understand software yet.


Another nice essay by Paul Graham

The Hacknot Book (big free pdf ebook) - Essays on software development

Screenshot - 3_29_2007 , 2_08_19 PM_thumb.png
Here is a cool, free pdf ebook of software development essays from Hacknot

The Hacknot Book
"Hacknot: Essays on Software Development" contains 46 essays, each of which was originally published on this site between July 2003 and October 2006. Soft copies of the book may be downloaded for free.
The book is available in two formats - Novel and A4. If you are printing the PDF yourself...


Coding Horror: Top 6 List of Programming Top 10 Lists

blog clipart
Thought this would be appreciated here:

Presented, in no particular order, for your reading pleasure: my top 6 list of programming top 10 lists. To keep this entry concise, I've only quoted a brief summary of each item. If any of these sound interesting to you, I encourage you to click through and read the original author's thoughts in more detail.


Fifteen Commandments of Programming

Screenshot - 2_19_2007 , 6_54_01 AM_thumb.png
The fifteen Commandments of Good Programming.
The following are the fifteen commandments of good programming. They are an imperative to having a smooth time after initial deployment of your program at the customer’s site. Follow these steps and you will have much lesser work maintaining the software that you have made.


Yehuda: Winning is Incompatible with (Almost) Everything

Screenshot - 2_16_2007 , 12_35_57 PM_thumb.png
This is an interesting article about the meaning and implications of winning (in games and other stuff).

To summarize some of my earlier thoughts, most games have scores which indicate relative success to other players, as well as relative success to our own previous scores. Yet, at the end of most games, we discard these scores and simply assign a "1" (for win) or a "0" (for loss) to all participants.
Or More Specifically
My goal is to separate "winning" from "goals" and "competition". Consider a game of Chess.
In the game of Chess, the goal is to checkmate your opponent. The game is competitive, in that one player works to thwart the other from doing so. The game is designed to end as soon as one player achieves their goal, thus preventing the other player from achieving theirs.

The Importance of Fun as a Motivator for Designing Open-Source Software

Screenshot - 2_14_2007 , 6_31_54 PM_thumb.png
Here is an article from an online, peer-reviewed journal that discusses motivating factors in open-source software.

The goal of the study on Fun and Software Development (FASD) is to precisely assess the importance that fun has as motivation for software developers to engage in open source projects. A survey carried out both under open source developers and programmers working in Swiss software companies yielded that the fun motive accounts for about 27 percent to 33 percent of open source developers’ motivation.
Fun is a pervasive feature of software development, not only for open source programmers but in the area of commercial software development too: Open source developers that are paid for their work are observed to be very motivated and prepared for future effort, especially if they enjoy their development time. Furthermore, the fun that programmers experience functions as a good proxy for their productivity. Therefore, employers that want to enhance the programmers’ productivity can safely invest in an environment of fun for developers in their company.


Why Java Failed to Dominate the Web

Screenshot - 2_9_2007 , 9_21_23 PM_thumb.png
Nice long thoughtfull article by Bruce Eckel..

Several of Bruce Tate’s books focused on the flaws in Java and the need to let go of some of the ideas that haven’t worked out. And blogs like this and this have been appearing more frequently. And of course there’s Steve Jobs now-famous quote (referring to the iPhone): “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”
This backlash has only been necessary because of Sun’s death grip on the idea of ubiquitous, omniscient Java. It was admirable once, but a language only evolves if its designers and advocates can acknowledge problems. Pretending that a language is successful in places where it’s not is just denial.
Some adaptations have occurred. Finally admitting that EJBs have cost the world enormously, the EJB3 team...

Why Small Programs Can Take Years To Complete

Screenshot - 2_3_2007 , 8_24_57 PM_thumb.png
Here's a review of Dreaming in Code and an interesting discussion of some of the factors that can make finishing programs take far longer than they otherwise might.

One way to look at Salon co-founder Scott Rosenberg's new book, "Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software," is as an attempt to tell the story of a specific software development project -- the effort by industry legend Mitch Kapor and a band of ace programmers to create Chandler, a kind of turbo-powered personal information management program that would dazzle users with its ability to enhance their productivity...

Article here:

And read an excerpt of the book here: https://www.donation...index.php?topic=7322

Clash of the Languages

Cool statistics on programming language popularity up to date with long term graphs:

25 steps for building a Micro-ISV

Screenshot - 1_22_2007 , 8_20_29 PM_thumb.png
Some good practical information for small software development development websites.

As promised, here's my 25 steps for building a Micro-ISV which are hard learned steps based on our experience getting TimeSnapper to where it is today. Each of these steps is both harder than it looks, and easier than you'd think.

It's hard because there are pitfalls, procrastination, miconceptions, anxiety, conflicting opinions and confusion at every step. It's easy because, hey, you're a smart guy or gal, so you can do this stuff in your sleep.

Scott Berkun Defends Simplicity in Software

Screenshot - 1_10_2007 , 2_34_34 PM_thumb.png
Scott Berkun responds to an earlier essay by Joel Spolsky questioning the adage that Simple is Better in software..

In defense of simplicity
Recently two notable design advocates, Don Norman and Joel Spolsky, challenged the value of simplicity in design, and I’m here to offer a late defense.
It’s easy to confuse success with quality, and both articles discount our secret inability to make satisfying choices. We are attracted to things with more features, that cost less, or come in larger quantities, despite our inner suspicions that we’re likely to complain about those purchases soon after. We date people, eat food, take jobs and buy products for superficial, misguided reasons all the time. We’re easily seduced, and every marketer knows we always have been and always will be.

But we shouldn’t confuse the success of feature-laden crap as a signal for the irrelevance of simplicity any more than the success of Rocky IV and Burger King signaled the irrelevance of good film-making or fine dining. It just means there are gaps between what we need, what we want, and why we buy, and that the masses are by definition less discriminating than the niches of people with refined tastes for a particular thing. is funded by donations from readers like you. If you find this site useful, please consider becoming a supporting member by making a small one-time donation, in the amount of your choice.

Return to