Claus Witt

In my previous post about SSO for webapplications I have missed the obvious – why not use OpenId and OAuth.

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.

I have been getting a thought into my head the last couple of days. I have been talking a lot about things surrounding web application building the last weeks. Primarily it has been about all the things that are common to most of the application ideas that I have. While reading about Scaling Twitter though, I got to thinking. I might be worrying a bit too much about things that are not even important before there are a lot of active users actually using the product on a daily basis.

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.

I found a video about How To Create The Perfect Lead Magnet. It will take five minutes of your time, but I am pretty sure you will learn something. I did.

While reading through the latest posts on Perry Belchers blog I found an image of a sign with the text “Hate washing dishes? Let us do it! Kids eats free”. As Perry says

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

Writing your own PHP Framework, should you do it?

While I worked at Wildside in Århus, Denmark, I wrote a MVC Framework for using in Typo3 extensions. The reason for this was that we were working on an application which required such a framework to structure the project to be as maintainable as possible without loosing performance. We started looking at different options, and none of them seemed right for the job, and most of them were either not usable in the context of Typo3, or not mature enough for production use.

When the project started there was a tight coupling to Typo3 since the application was pretty much just an extension to the website.

Since then a lot have changed, and I am now working directly for the client, who was a customer of my old company 9iA as well. The system is now more of a standalone web application and the requirements of the framework has changed many times since its first version in may last year.

The framework is, however still tight coupled to Typo3, but Typo3 is pretty much only used for templating and authentication.

In the last year and a half I have worked with a lot of php frameworks – saying that I have used all of them is off course an exaggeration, but I have been using most of the top ones in some way or the other. And not one of them work in exactly the way I would want them to.

Now I am wondering wether to rewrite my mvc framework to be standalone. It would not demand more than 30-50 hours of work to do that, and on top of that be able to integrate Zend Frameworks Components and an existing ORM like perhaps Doctrine.

The other possibility is to rewrite the application to use an existing well tested framework. If Flow3 had been ready for production (and working in php 5.2.x) that would probably had been the case. But now I’m just not sure.

No mather what we decide to do, the current version will go live without any kind of rewrite. But the learning experience from writing your own PHP MVC Framework might be nice to gain, at some point – even though most of it is written allready.

What would you do? And if you would use an existing framework – which one would you recommend?

Btw, no mather what we choose to do, the framework will be released to the public as soon as all bugs that I have found have been fixed, and some basic documentation have been written.

Having business ideas is not enough. As I have previously written I have a lot of them. My ideas have primarily been generated out of what I know, and as such from the needs that I either have had myself, privately or profesionally, or that I have experienced first hand from others. As such I follow the ideas of 37 Signals quite good, which states that you should build software that deals with your own problems.

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.