Starting to get addicted to unit testing…

During the last months, I started paying more attention to unit testing and writing tests in my symfony apps. But not until this awesome post from Bernhard Schussek, I really understood how you can make your testing life easier and get tests done better, faster and be more efficient.

It also helped me to understand, to which granularity you can and should break down your tests as well as your methods in the lib classes.

So this really is a BIG FAT recommendation on reading the article!!

What I learned from it and what I am doing ad enjoying right now, when creating new functionality:

  • If I have a complex method to write, I break it down into the smaller parts that need to be done step by step. For this, I write the logic with methods that are not even exisiting yet.
  • Next, I write the unit TESTS for these non-exisiting methods, filled with test cases that make sense in the current context of the problem and help to make sure the method works
  • Next, create an empty stub of the new method, so you can start running the test without a crash – but of course it will fail
  • Add functionality to the method to make sure you finally pass all tests.

This really makes the whole process a lot of fun because it really is rewarding to see the “All tests successful.” or “# Looks like everything went fine.” at the end.

And you can continue with your next part of the more complex functions with a good feeling of confidence, that in the end it will all work fine 😀

Playing with my new pet: APE

My Questions to APE – answered

I’m planning to use APE (www.ape-project.org) for my next big project. It provides “Real-Time-Push” functionality based on Java Script, making real-time web applications possible.
After playing with it for some time now, getting the demos to run and trying out some stuff on my own, I wanted to share some of the things I learned.
Before I started playing with APE, I put down some basic questions occuring in my head. I would have liked to get them clarified directly to get a better overview of what I’m dealing with. Unfortunately, the documentation is a little bit thin on giving you a “basic big picture” before it goes into API calls and Event details.
So, a couple of days ago, I just put down the basic questions I had at the beginning – and hopefully, as I got a better understanding now, I found answers – and maybe you can use my notes to get the big picture easier than I did…

My initial Questions and their answers after playing with it

Ape works with pipes – what are pipes?

A kind of virtual “handles” in the framework to communicate with the server or another users. If you joined a channel, the server will tell you which users are connected to it – along with their “pipe”. And you can send a message to that pipe – the server will forward it to the user.

How does the server know if a user is allowed to join a channel?

If the server does not have any additional intelligence, it does not care. Its up to the server, to decide what to do.
A client JavaScript can simply call a .join(“myChannel”) and if it exists, he’ll join. If not, the channel will be created.

If I’m implementing a chat with privat chatrooms, how can I prevent a “bad” user from joining a private channel if he guesses the name or finds out about the user?

A client sends a message to another user “on a pipe” to the server, the server will pass on the message – so there is no public/private channel, but a direct user pipe that cannot be intercepted

How do channels get their name at all?

You need to know the name to connect to it – or you just create one with a given name

If a user knows a channel’s name, can he join it?

If his JavaScript lets him…

What’s the difference between a MultiPipe and a UniPipe

Uni-Pipe is a direct pipe from user to user. A multi pipe is what we would call a public chat room.

Is everything I send to the channel sent to everybody?

Well, yes and no…
In the end, the server INITIALLY is quite dumb… but it provides a lot of opportunities.
Clients can send commands to the server, the server receives data and decides what to do with it.

  • If Alice sends a “say”-command (literally speaking) on a channel she joined, the server side module will decide to forward the message to all users in the channel.
  • If Alice sends a “leave”, the server would notify all others of her disappearing.
  • If Alice sends “Say ‘Hi’ to my friend Bob” (talking to Bob’s pipe), the server would forward the message to Bob, notifying him that it was Alice

Well, finally, and how does it really work? Does “Push” create incoming connections?

Simple answer: Its not “really” push, so no incoming connection.
Actually, the idea behind the client-server communication is quite simple:
Your client side JavaScript connects via AJAX to the server. This connetion will be kept open by the client and the server. Now, as soon as there is data to be sent, either from client to server or back, this open connection will be used.
So, the CLIENT always opens the connection and the server just has the option to either keep the user waiting or send him something, immediately.
And then it is up to the client side JS framework, to deal with the data.
In a default config, this “long request” will be refreshed every 25 seconds, as a keep-alive to the server. After 40 seconds of no answer, the server will consider a user as timed out.

Wrap up:

APE is cool! APE is fast! APE is fun! And there is some documentation…
At the time of this writing (March 2010), getting into it is a little bit tideous because of the fact that some documentation between the APE comics and the API description is missing. Thats why I provided my notes, hoping it will help some-one.
From what I learned so far, APE is providing a great base for getting your stuff done.
All the functionality that you can find in the demos MAINLY relies on heavy clients, while the server is just passing on messages. However, you can put additional logic into your server, it can talk to a MySQL DB, provide authentication, you name it. You just have to do it.
So, APE provides everything you need to get your real time application up and running, you just have to define the “protocol”, being the commands the client can send to the server and what the server will do with it.

And, hey, come on, seeing stuff being updated directly in your browser as it happens, WITHOUT FLASH, is just awesome 😉

Planned something new: KaroAPI

Planning, planning, planning…
Last night I read some stuff about RESTful applications… and of course, quickly, the following plan came to my mind: I need it! Somewhere!
And of course, as always, the best baby for testing and applying new techniques is www.karopapier.de
So I decided I need a KaroAPI, using RESTful approaches.

Digging through it, the next question came: Should I use XML or JSON for the output? Or both?

JSON has the advantage to be shorter, I like it better AND: It could be used in a new JavaScript based frontend. Imagine to simply to a AJAX/JSON request for the details of a game and nicely format the data in a Browser.

XML, older, more widely spread, is more commonly used and maybe can be parsed with some clients more easily – and applying XLS/XLST it could also be readable and nicely formatted for humans.

Next thought was: “Well – offer both” – creating an object with PHP and then either apply a json_encode or XML_Serialize should not be a big deal, right?
Well, we would see…

And not enough of all the big plans, I thought I could give symf Symfony2 a try.

Sooooo:
Big plan, draft 0.3:

  • KaroAPI
  • JSON and XML representation of data (for bots, clients and other KaroTools)
  • use Symfony2 for the implementation

Added to the todo list… the big problem – already so much on this list. And I never manage to do it one by one, but get distracted by so many other interesting things…
Like, lately, when I introduced APE into the chat. But, Hey, I did not even blog on that yet…