Enterprise software, CRM, measuring apps, financial applications and some sort of site builders are some of the things that I have looked into previously.

In the near future I will unveil some of the projects that I have been working on lately. Stay tuned.

It is important however to know the difference between the two. OpenId is used for authentication – is the user who he says he is – and OAuth is used for authorization is this specific user allowed to do this specific action. Well, in the case of OAuth i guess it is more, is this application allowed to do this action on behalf of this user. A use case described in the post OpenID & OAuth – complimentary or competing? is:

Let’s say you are registering as a delegate on a conference website. With OAuth it is possible for the conference website to automatically add the event to your google calendar or yahoo calendar with your consent (assuming google and yahoo support OAuth). How does it work ? Well, once you decide to let the conference website add an event to your google calendar, you get redirected to google. On google , you explicitly authorize the conference website to modify your calendar. After this authorization, the conference website will have permission to modify your calendar data.

The problem with OAuth is that you have to login to every site that you wish to give an application access to. For this reason Google has published a hybrid protocol, and tries to make this a new standard. They created a demo, and released the source for that.

This really looks like a technique that could be used for my applications. I am looking into this, and hopefully will have a quick tutorial on the subject in the near future.

Maybe it is because it is easier to talk about all the things you ought to do right, instead of just writing the damn thing. It is also a lot safer for the ego in some way. You can postpone putting your idea out there – because no mather how good an idea it is, someone is bound to be of another oppinion. I will try to not let myself be blinded by all the negative what if’s.

For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.

In the near future I will be creating technical proofs of concept (because the design part is not my strong side) of several of my ideas. This way it will be easier to assemble a team, and decide what to actually do.

This way, I will also have something real to write about.

The headline should be about the dishes, the work, the source of the pain, or the pleasure. It’s all about stirring an emotion.

I am however quite clear that there are many other factors in starting a new web-based application. Many of them are mentioned in Startups in 13 Sentences.

I especially agree with the second sentence on the list. Start up quickly! I believe this to be true, in the sense that from when you begin the project untill the beta is released, and actual users begin to use it, there should be as small an amount of time elapsed as possible. The reason, is listed in the list as well, is that when you do as 37 Signals would want you to, you could end up doing all the wrong things.

It is just like the actual development of software. Test early and test often.

In the weekend I found the following video with Perry Belcher which stated that you should pretend that using social media is like attending a party.

The overall model for his method is as follows.

1. Properly qualify the prospects on the phone
2. On the first meeting you should determine if you can work together. (And that you actually can make a solution on budget and on time. If so, book the next meeting.
3. On the second meeting you should do the presentation of your solution. If the previous steps have been done correctly, your chances of landing the client should be about 80%.