jQuery is the best thing that has happened to Javascript since it got first class functions in version 1.2. The library is elegant, powerful and has exactly the right level of abstraction for working with the DOM. There is nothing more to say. Learn it and use it. Good resources are: the jQuery API, my view of the jQuery API

Learn Javascript

Javascript is the programming language of the web. Learn it! Javascript is different from most other programming languages. It is dynamic, it has prototypical inheritance, and works more like Scheme than any of the languages that you are probably used to. If you want to learn Javascript you should get the following books, The Little Schemer, The Seasoned Schemer, Javascript, the Good Parts, and possibly High Performance Javascript

Learn CSS

Many programmers think that CSS is the language of designers and not programmers. This is not the case at all. If you are lucky enough to have a designer on your team (most people don't), CSS is the language with which you communicate. It is the interface between designers and programmers and as a programmer you should know it better than the designers. By knowing CSS well you will reduce the misunderstandings between you and your designer.

Unfortunately, many designers don't care about how code looks, as long as the design looks good on the surface. It will be up to you to make sure that the CSS doesn't get out out of hand. It will also be up to you to keep the HTML clean, and a good way to do this is to use semantic HTML, combined with CSS. You have no idea what the designers can come up with.

<!-- 
  Old School rounded corners, invented by a GOOD designer. 
  All this code was actually needed to achieve the purpose.
  -->
<style>
.t {background: url(dot.gif) 0 0 repeat-x; width: 20em}
.b {background: url(dot.gif) 0 100% repeat-x}
.l {background: url(dot.gif) 0 0 repeat-y}
.r {background: url(dot.gif) 100% 0 repeat-y}
.bl {background: url(bl.gif) 0 100% no-repeat}
.br {background: url(br.gif) 100% 100% no-repeat}
.tl {background: url(tl.gif) 0 0 no-repeat}
.tr {background: url(tr.gif) 100% 0 no-repeat; padding:10px}
</style>
<div class="t">
  <div class="b">
    <div class="l">
      <div class="r">
        <div class="bl">
          <div class="br">
            <div class="tl">
              <div class="tr">
                Lorem ipsum dolor sit amet consectetur adipisicing elit
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

As an additional benefit you will become better at jQuery. Not only is CSS the query language of the browsers it is the query language of jQuery. Jariba!

Bulletproof Web Design is a good book web design, including CSS.

Decide how "Rich" your application should be

How rich should your application be? The scale varies from no Javascript to only Javascript, but you will probably want to land somewhere in between. Here are a few suggestions.

• No Javascript, everything is server generated.
• Slightly enhanced pages, simple validations, but no Ajax.
• Ajax enhanced pages, but every page still reloads frequently.
• Single page per area, entire area is handled by Javascript.
• Only Javascript, Ajax interaction with the server
• Only Javascript, no interaction with the server.

The important thing is to make a decision. If you don't make the decision, everyone will do different things on different parts of the application and you will loose consistency. In GUI, consistency is king. Make a decision and move on, you can always change your decision later.

Organize your code

Javascript

Make sure that all your Javascript code is namespaced properly. It is impolite to pollute the global namespace and it will bite you in the end. A simple variable declaration will do.

// Common namespace for your entire application
// This declaration lets you split your code of multiple files.
// If MyNamespace is defined use it, otherwise declare it.
MyNamespace = MyNamespace || {};

But, of course, it is also possible to get fancy and encapsulate the functions that you don't want to expose, if that is your cup of tea.

MyNamespace = MyNamespace || {};

MyNamespace.Tournament = function() {
	// Private stuff
	var tournamentCount = 0;
	function addTournament(tournament) {
		tournamentCount++;
	}

	return {
		//public stuff
		numberOfTournaments: function() {
			return tournamentCount;
		}
	}
}();

You should also separate your Javascript code into different files. The namespace idiom above helps to have the same namespace across multiple files. The same principles as with other type of code is valid with Javascript, organize the code by area, when it changes, where it is used, etc. Don't be afraid of the additional load time, splitting the files will give you. The files can easily be concatenated with tools like Rake, SCons, Ant or even a simple:

$ cat file1.js file2.js file3.js > all.js

They can also be compressed with JSMin or YUI Compressor.

Optimize your environment for development, not for production!

HTML

HTML is code! Divide your pages into partials by responsibilities. It allows you to keep your pages DRY and readable. The Single Responsibility Principle applies to HTML too.

Make sure you keep the Javascript with the code that it manipulates. If you, for example, have a calendar partial that uses jQuery DatePicker, you have to make sure that the partial includes all the necessary Javascript to configure the calendar. Don't keep Javascript code in the page away from the partial. Things that change together should be together.

CSS

Stylesheets are code too. They should also be split into areas that allow you to easily find and navigate them. Use Sass or SCCS to keep your CSS files DRY. Sass is good for designers to. It gives them the ability to use variable names, mixins, etc. and simplifies their usage of semantic names such as notice, and sidebar instead of yellow and left.

Optimize your environment for development, not for production!

Separate your Javascript from your HTML

All too often I see generated HTML pages with Javascript code in them. Don't do it. Keep the HTML free from Javascript.

<!-- DON'T DO THIS!  -->
<button id='update-button' onclick="MyNamespace.updateList();">Update List</button>

// In the Javascript file for the page.
MyNamespace.updateList = function() {...}

<!-- DO THIS! -->
<button id='update-button'>Update List</button>

// In the Javascript file for the page.
MyNamespace.updateList = function() {...}

$(function() {
  $("#update-button").click(function() {
    MyNamespace.updateList();
  });
});

It may seem like there is a lot more code in the good example, but notice the symmetry. The code that attaches the listener is in the same file as the code that uses the listener. This is good. Symmetry is good.

Use clone()

Separating the HTML and the Javascript goes both ways. Don't generate HTML code in Javascript. It doesn't matter that it is super simple to do it using jQuery.html(). Keep them separate, use jQuery.clone() instead.

// DON'T DO THIS
$("<li data-id='123'>My new item</li>").appendTo("ul");
// OR THIS
$("ul").append("<li data-id='123'>My new item</li>");

<!-- DO THIS -->
<ul>
<li id="list-template" class="template">All .template are hidden (display: none) in the CSS</li>
</ul>

// AND THIS
var $clone = $("#list-template").clone();
$clone.attr("data-id", "123").text("My new item").removeClass("template");
$("ul").append($clone);

The point of this is, again, to keep the HTML separate from the Javascript.

Decide how content flows between, the page, Javascript and the Server.

Once you have decided how rich your application should be, you have to decide on a method for moving the data between the HTML Page, Javascript and the Server. My preferred choice is to have every page that is served from the server include a context object with all the static data for the page and to have additional data that belongs to parts of the page be sent as data-attributes on the elements concerned.

The context object will contain all the data that is commonly needed in the page.

// Sample context object that is generated with the page.
MyNamespace = MyNamespace || {};
MyNamespace.Context = {
  user: {
    id: "28",
    name: "Anders Janmyr"
  },
  tournament: {
    id: "78344",
    name: "Fifa World Cup"
  }
};

I use the context object(s) to keep state on the client to. If it is important that the page looks exactly the same, even if the user reloads the page, I make sure that the state I stick into my context object is synched back to the server. This can easily be done, asynchronously, with Ajax and does not affect performance noticeable.

Elements specific data is sent along with the element it defines.

<!-- Element specific data attached to the elements with data-attributes -->
<ul id="tournament-menu">
  <li data-id="78344" data-participant-count="64">Fifa World Cup</li>
  <li data-id="666"  data-participant-count="44">Americas Cup</li>
  <li data-id="1464" data-participant-count="32">Rugby World Cup</li>
</ul>

The same argument as with the context object applies, as soon as I change an element in the GUI i need to feed that information back to the server. With elements I usually send the information to the server before updating the GUI, since element specific data is usually permanent data and not just session data.

An alternative solution to the context object above is to use the body element as the data-container, like this:

<body data-user-id="28" data-user-name="Anders Janmyr" data-tournament-id="78344" data-tournament-name="Fifa World Cup">

I tend to use the context object because I find it easier to add functionality to it than to the DOM element.

Only send the data that is needed to the client with the page. The rest of the data should be loaded on demand, with Ajax. Both JSON data and HTML templates can be loaded on demand. There is no need to deliver the entire page at once. Experiment and do what gives the best user experience.

Use file watchers to speed up feedback

If you compare the feedback cycle of Javascript and HTML development to Java and C# development, you are probably very happy with the short, tight feedback loop. This doesn't mean that you should be content. A feedback cycle cannot be too short.

xrefresh for Firefox and IE, and LiveReload for Safari and Chrome, are a couple of tools that will tighten your feedback loop even more.

Both tools are file watchers that listen to changes for files and refresh the browser when they change. If you combine this with two screens, you will have one screen for the browser, that updates continuously, while you edit your code on the other screen. Fabulous!

Conclusion

Rich web applications are very close to the traditional client-server model. We have to keep state on the client side to give the user a good experience. At the same time the application state, and indeed the entire application, can be swept away by a click of a button or a page reload.

This puts new demands on us as developers. We have to realize that we are responsible for the entire application, not just the business logic, but the HTML and CSS too. More that anything, we have to realize that Javascript is a first class programming language with its own programming techniques, which we need to master to be able to develop good web applications.

deadline, from New Oxford American Dictionary

1. the latest time or date by which something should be completed : the deadline for submissions is February 5th.

2. historical a line drawn around a prison beyond which prisoners were liable to be shot.

Deadlines in software development induce unnecessary stress, and transform otherwise enjoyable activities into chores.

We need to replace deadlines with livelines. A liveline is a deployed, working version of a product. It is after the fact, a milestone set when you are done.

How Deadlines Are Set

Deadlines are set in different ways in different projects.

In the classic Death March project, a deadline is set by someone outside the project with no clue whatsoever about how long it will take. Typically this kind of deadline is based on some external event, where the project will be demonstrated. The event may be a conference, or something similar.

In Scrum, the deadlines are set by the process itself. Most Scrum projects I have worked with use a two week deadline instead of the recommended 30 days. The team decides how many stories they can complete by that deadline, based on rough estimations done in the sprint planning.

Some projects set deadlines by a developer being asked (or asking himself) when the task will be done. The developer will say: "I'll have it done by 3 o'clock", a wild guess.

The problem with all these approaches is that the deadlines are, at best, based on guesses of the team doing the development. But guesses are guesses, not something you can set a deadline by.

And deadlines work both ways, a task is very rarely completed before it's deadline.

Kinds of Deadlines

Real Deadlines

If a task is not completed by a certain time someone will die. This kind of task is really common in novels and movies. A clock is ticking and if the task is not completed by the time the clock reaches zero, BOOM!

If have never seen this kind of deadline in software development, but they may exist.

Planning Deadlines

Some deadlines are set in order to simplify planning. In the large Death March projects, the plan is to show the project at a certain date. In integration projects, the deadlines are set to be able to synchronize with other teams working on the same product.

This kind of deadlines are actually understandable, but I am arguing that they actually slow down projects by introducing stress, which introduces bugs. The bugs introduce bugs in the dependent projects, and slows down many projects instead of just one.

Motivational Deadlines

Motivation deadlines are set to get people to work. The assumption is that if a deadline is not set people will procrastinate over different ideas, or just slack off since there is no date set for the release anyway.

This is, absolutely, the worst kind of deadline. If the team is not motivated enough to do a good job without a deadline, you need to get a new team, not set a deadline.

Why Deadlines Are Bad

Stress

Consider walking on a one foot wide plank. If it is on the ground it is easy. If it is two meters up it is difficult, but if you put it at twenty meters it is a whole different ballgame. That is what its like with deadlines, they put an unnecessary pressure on people.

Loss of Motivation

Work consist of whatever a body is obliged to do, and play consists of whatever one is not obliged to do. -- Mark Twain

In his book, Drive, Dan Pink differentiates between intrinsic motivation and extrinsic motivation.

Extrinsic motivation is motivation driven by carrots and sticks, rewards and punishment. It works well for simple, well-defined tasks.

Intrinsic motivation works well for creative, ill-defined tasks, like programming.

Intrinsic motivation is fragile, it disappears in the presence of carrots and sticks. A deadline is a stick, whether set by ourselves or someone else.

Livelines

A liveline is, quite simply, a task that is done. When a task is done, it is easy for others to use it, in their plans or in reality. If we want to build a stable house, we should build it on stable ground.

When using livelines the iteration length is the same length as a task. This is usually a lot shorter than the usual one to four weeks common in Scrum and other agile methods. It also leads to variations in the iteration length.

If you implement your task all the way into production, you get Continuous Deployment or Continuous Delivery. This puts a lot of pressure on your tooling and on automation but, I believe this is the way to go.

It is 2010, it is time to get rid of deadlines.

Functional code!

Turns out that JavaScript is functional, not as in working but as in a functional programming language. So when calling -[UIWebView stringByEvaluatingJavaScriptFromString:] you do not pass in for example:

return x * y;

But instead:

x * y

Yes even without the trailing ; character! The result returned from -[UIWebView stringByEvaluatingJavaScriptFromString:] will be the value of the last statement, if you add a trailing ; then the last statement will be an empty statement and you will get an empty string as a result. Took quite some time before I figured that one out.

UIWebView must be on screen to execute script

The UIWebView class will not render any content, nor execute JavaScript if it is not potentially on screen. So you must add the UIWebView to the view hierarchy even if you just have it around for executing some JavaScript in the background.

It is perfectly ok to let the web view be 0x0 pixels, or full transparency, but hidden does not seem to work either.

All access must be on the main thread

Not news since the documentation clearly says you should only work with UIKit classes on the main thread (with a few added thread safe additions in IOS 4). But this is a problem if you want to do background tasks with JavaScript, since you must call -[UIWebView stringByEvaluatingJavaScriptFromString:] from the main thread. Any long running JavaScript will block all user input and updates of the screen.

No fear though, you can make your JavaScript asynchronous. But then -[UIWebView stringByEvaluatingJavaScriptFromString:] will return before your script has finished and UIWebView do not have any obvious other way to communicate any results back to you. Obvious way that is. What you instead have to do to get asynchronious results back into the Objective-C world is by fake URL requests. Use a function like this to return results from the JavaScript world:

var returnAsyncResult = function(result, context) {
    window.location = 'result://dummy.com/' + result + '/' + context;
}

And then let the delegate for your UIWebView get the result as such:

-(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType;
{
    NSString* urlString = [[request URL] absoluteString];
    if ([urlString hasPrefix:@"result:"]) {
        NSString* path = [[request URL] path];
        NSArray* pathComponents = [path pathComponents];
        NSString* result = [pathComponents objectAtIndex:1];
        NSString* context = nil;
        if ([pathComponents count] > 2) {
            context = [pathComponents objectAtIndex:2];
        }
        [delegate javaScriptEvaluator:self
                      didReturnString:result
                              context:context];
        return NO;
    } else {
        return YES;
    }
}

Only String results

Turns out that -[UIWebView stringByEvaluatingJavaScriptFromString:] only returns strings as result. No problem for simple types such as said strings and numbers, but a big problem if you try to return a complex value such as an array:

[1,2,3]

This will not work, and will return a NSString of zero length. You must explicitly convert arrays to strings before returning them to the Objective-C world, easiest way would be something like this:

'[' + [1,2,3] + ']'

Conclusion

UIWebView is a blunt tool. Please do use http://bugreport.apple.com and file a request to make JavaScript Core a public framework. The more duplicates, the higher Apple will prioritize this issue on their todo list.

In the meantime UIWebView can be used to your bidding if treated with care.

I use Ruby because it makes me happy!

If you search Amazon for Ruby you get 8,829 Results and if you search for Rails you get
14,113 Results. What books should you get?

Here are the books I recommend:

Ruby

Beginning Ruby is a superb book for people coming new to Ruby.

If you are not a complete novice, you should instead go for
The Well Grounded Rybyist.

When you have finished the Well Grounded Rubyist, you are ready for Metaprogramming Ruby where you learn metaprogramming techniques to help you keep your code DRY and readable.

Rails

Since Rails is currently being updated to version 3, there are not that many books available. I can recommend The Rails3 Way, currently only available as a Rough-Cut.

The lack of updated books is not a problem. The The Ruby on Rails Guides are excellent. Make sure you select the edge version.

Even more information is available through the videos from Railsconf, subscribe to them in iTunes. The first videos where published, the day after they were filmed. Fantastic!

Have a happy Ruby-red summer.

Just like EJB2, Maven2 was born out of something so unbearable that anything else was bliss. Jelly anyone!

But just as EJB was fundamentally flawed, so is Maven2. Build systems, even advanced ones like Maven is fundamentally about two things.

1. Check if something that something else depends on has changed
2. If so, do something.

That's it, that is what is important.
The checking may contain various sophisticated methods for detecting if files, subsets of files, all files, web pages, twitter feeds, etc, has changed, but that is really it.
And the doing can be anything, Copy files, commit files, build websites, run tests, generate code, launch missiles, whatever!
But the key to doing this efficiently is a programming language with easy access to system commands and the ability to create simple abstractions, with methods, variables, and objects. The language should also, preferably, be one without a lot of ceremony, like Ruby, Javascript or Python.
There are already build systems like this out there, Buildr, SCons, and Rake come to mind, but they do not have the momentum of Maven, so a merger between Maven and Buildr would be wonderful.

So, Jason, hear my plea, Don't make me eat the elephant again!

The reason I left was that I wanted to work with one product and one team. I wanted to do everything right, I wanted to use pair-programming, domain-driven design and test-driven development. I had many plans. It didn't turn out that way, the people on the team I worked with did not want to use pair-programming, DDD or TDD!

After a few years I gave up and came back to Jayway and I love it. The company has grown quite a bit, while I was away, and that is a good thing. Three years ago I probably thought that it was a bad thing. It isn't! Three years ago we had to come into a company as resource consultants, but now we, many times, come in as a team or get to do the project in-house. This is a really good thing. Getting to work with other Jayway people is a real Joy. They are smart, motivated and pragmatic. If I leave the project for a week, someone steps into my role and, everything works out fine. People and interactions over processes and tools is very, very true!

There are a many reasons why I think it is so nice to work at Jayway.

Natural authority is a pattern from Adrenaline Junkies and Template Zombies that states:

The meaning of an authority is a person who knows a great deal about something. Another meaning, in authority, is a person who is in charge. If someone who is an authority also is in authority, this is a natural authority.

The person who knows best, gets to make the decisions. This is the way it is at Jayway. You are not assigned to a project, you are asked if you want to work on the project and, it is OK to say no.

Management. My wife recently told me about a danish entrepreneur, Lars Kolind. He is usually called in when a company is not doing as well as it should. He talked about something that he called Kolindkuren (the Kolind treatment). What he does in this treatment is that he turns things upside-down. And one specific thing he did was that instead of asking managers who they wanted as employees, he asked the employees who they wanted to have as managers. It turned out that no-one wanted many of the managers.

When I think about this and how this would work out if we did the same thing at Jayway, I don't think that anything would change. I am happy with my managers, I don't see them as managers, I see them as collegues who work to allow me to do the job I want to do. If I got to choose who I wanted to be my boss, I would choose exactly the people we have right now. And, I think we all feel the same way. An example of this came a few years ago.

Thomas, the president of Jayway was fired by the board. What happened then was amazing, one week after Thomas was fired, 90 percent of the employees had resigned. If Thomas can't work for you, then we wont work for you, was the clear message that was sent. And it had effect, Thomas is back, the board is gone, and we are all happy.

Competence is the driving factor of everyone at Jayway. We all have different interests, but the common denominator is that everyone loves programming and want to get better at it. Take a look at this weeks competence workshops, and remember that they are all voluntary!

Openness is very important to me. If I know why a decision has been made, I can understand why it was taken even though I may not agree with it. At Jayway all the managers write a short daily mail about what they are doing during the day. Every week Thomas updates the wiki with what is going on currently and what is planned for the future. Everything that does not have to be secret is open and available. If you want to find it, it is on the wiki.

If a doctor wants to chop of my leg I would be happier with the decision if I knew that he wants to do this because I have an incurable tumor in the leg, instead of him wanting to practice his amputation skills.

So, that is how it is to work at Jayway (at least in my mind). If you feel that competence and humbleness is more important than fancy titles, come and join us.

What is Twitter? Well, it's a micro blog. Users post so called tweets, messages with 140 characters or less. You can tweet, follow peoples tweets and search. That's basically it. And this is cool why?

Keep yourself updated

For me, one of the key features of Twitter is that there are really interesting people twittering. If you go to WeFollow you'll find people like Kevin Rose, Tim O'Reilly and Guy Kawasaki in the tech segment. Since they are active this means that you are able to listen to feeds from some of the, in their fields, most updated people. And Twitter is basically full of fantastic people to follow... like Chris Hughes (http://twitter.com/chews), less followed but equally interesting, who's Twitter Bio says "I was the one of first to hack the iPhone. BOOOM'"... In short, nothing is stopping anyone from evolving their web presence and getting people to follow them.

Before Twitter everyone knew people that where islands of new knowledge; people that seemed to have one ear to the ground and hear the most interesting things. With Twitter, these guys and girls broadcast their nuggets of information to the world, effectively building their personal brand and enabling everyone to listen to them. All of the sudden you have the opportunity to be as updated as these people are. Not only that, since you have the possibility to listen to multiple islands at once you can get a perspective of the entire world of islands...

Ok, there are great people to follow, and they share information, great links and insight, but this all sums up to a lot of information. Yes! In this day and age you have to accept a certain degree of white noise if you want to hear interesting signals... deal with it. Luckily there are plenty of tools to help you deal with it. I use TweetDeck on my Mac, but there are tons of tools out there...

The Twitter API

The Twitter API is in my opinion is one of the most obvious reasons for Twitter success. It is an open API which anyone can use to create applications that uses Twitter data... and it's silly simple, especially if you use the Java API java-twitter. The following is what is needed to login a user and print their friends timeline (the stream of tweets from people a person follows):

public void printFriendsTimeline(String username, String password) throws TwitterException{
	Api api = new Api();
	api.setCredentials(username, password);
	Status[] userTimeline = api.getFriendsTimeline();
	for (Status status : userTimeline) {
		System.out.println(status.getUser().getName() + ":" + status.getText());
	}
}
 

This means that anyone can do just about anything with the Twitter data. Your basic level of allowed requests is 100 request per hour and IP, but if your application is request-intensive you can ask Twitter for more and get up to 20.000 requests per hour and IP. Of course this has created a flora, or even an entire ecosystem, of applications and implementations where you can tweet, watch statistics, see the most tweeted links and everything you can imagine (just check out this list).

Some tweeting advice

Not that I'm an authority on this, but I still wanted to end with some advice on tweeting:

1. Create good content that you think people want to read. Did you published a blog post? Tweet about it. Going to a conference? Tweet about it. Did you find a new interesting framework? Tweet about it. Got a new fantastic insight? Tweet about it.

2. #tag your tweets. If you tweet "Just found out about this great API http://tr.im/hr8S" end it with describing #tags like this "Just found out about this great API http://tr.im/hr8S #java #dev #twitter" to make it searchable and to add more context.

3. Re-tweet/RT when you read a good tweet. RT is a user derived notation which is used when forwarding tweets. If you get "Jayway.com is a great company!" from me and love it you simply write "RT @mattiasask : Jayway.com is a great company!". Applications like TweetDeck also help you with this...

4. Try to get re-tweeted if you want to spread you tweets. A tweet can travel by RT from social graph to social graph and reach a lot of people that way. Read Guy Kawasakis' blog on how to get retweeted (http://blogs.openforum.com/2009/02/18/how-to-get-retweeted/) for more on this.

/Mattias Ask, @mattiasask

PS. I have to add cool thing about Twitter and the speed of updates, something Twitter co-founder Evan Williams talked about at TED this year. During the California forest fires in -07 Twitter followers where more updated about where the fires spread than the people listing to the traditional media sources where. Why? Because people in the actual areas where the fire spread were tweeting about it from their cellphones...

For good or for bad, the market is unprecedented in its power to generate wealth. What if we could use this power, not to generate wealth, but to generate good?

Since the market understands money really well, why not create representative money based on donations? If we do this, everyone will be able to handle donations as money. We could own it, measure it, trade with it, work to generate more of it... and every cent of it would represent donations for good causes.

This is what OpenCauses.org is doing.

OpenCauses.org really only aims to change one word. Instead of saying "I make donations to good causes" you will say "I buy donations to good causes". This slight change makes all the difference.

What is it we are doing?
We are creating the Open Causes Platform, a non-profit donation platform, which will enable donations to causes aimed at the UN Millennium Development Goals. The Open Causes Platform will also hold Cause Credits. Causes Credits is representative money based on donations. This means that each Causes Credit represents a donation made to a good cause.

When you donate through the Open Causes Platform you receive Cause Credits for your donation. Your Cause Credits are measurable and accumulative, and they are also transferable between users of the platform. All this combined effectively makes Cause Credits into a means of trade.

The Open Causes Platform is an infrastructural platform which exposes a number of web-services. With these services integrators can integrate basically any site or Internet connected product to the platform. Anyone can create pretty much any implementation of donation based services imaginable. They will be able to make donations, show how much users have donated, compare and transfer donation.

Using Cause Credits
If you, as a person or an organization, own 100 Cause Credits you have donated $100 through the Open Causes Platform. If you later donate $10 more, you own 110 Cause Credits.

Now, let's say that I have a cellular phone that I don't use. If you give me your 110CC, I'll give you my phone. If so, I have made the actual donations for $110 and you have bought my phone in two steps. The value of my phone has paid for the $110 donation. You now own a phone, but have not made any donations.

Summary
We are implementing a currency based on donations. Essentially we want to complement the market of today with a market based on generosity. Just imagine if every corporation where to accept a currency based on donations for 1% of their services and products... What couldn't we do then?

Mattias Ask,
Founder of OpenCauses.org

If you have any questions or want more information about the project, go to OpenCauses.org or contact me at mattias.ask@opencauses.org.

This weekend I was unpacking two of the last boxes in my new apartment and I finally found my old Amiga 1200. Since it have been stored in the attic for a couple of years and in before that it was stored in the cellar, I decided that it was time to check if it was still working. It took me a quite some time to configure the TV(!) to correctly show the display, but everything else worked like a charm. It had not been booted for over 10 years!

Anyway I found the source code in some random folder, created an LHA archive, found an old floppy disk and using an USB floppy drive I managed to transfer the archive to my PC. Some facts:

• The code had not been touched since march 1995
• It is more than 12 000 lines of (more or less) undocumented assembly code mostly in a single file
• The labels are things like s, s2, fl, bid, cnl2 and so on
• We didn't use a version control system. Instead all files were transfered on floppy disk between our computers

Yet we were still able to create a fun computer game that worked on all the different versions of the Amiga hardware. With todays powerful hardware, different programming languages, good IDEs and the large number of frameworks I simply don't know where to start. Why is that?

Perhaps the fact that we were very focused on what we wanted to do and not interested in how, we were able to overcome the complexity and simply get it done.