The NetCircle – Now hiring PHP Developer in Shanghai

The days when you could know everything over. But the will remains, as there are more sources of knowledge as the amount of data grows. We’ve learned to multitask and work on several monitors at the same time while listening to a podcast and watching a video on Youtube and our elbows rest on an open book. We can read more, faster, more personal and from different angles. We use our Feedreader to organize the never ending flood of blogposts. I’m depressed realizing it was months ago my google reader said anything different than the 1000+. IMHO there’s a trend towards multi author blogs who give you the overview of what’s going on and only if you show more interest in details you might need another specialized blog.

Better organization and predigested information doesn’t completely solve the problem. We need to realize that really important things show up on a regular basis. You might miss it on Twitter, but if it’s important enough somebody else will twitter it too, or pick it up and write a blogpost or maybe you hear your friends or colleagues talk about it or you see it on TV.

If it’s really important you won’t miss it, but you can’t always be the first one to find it. Especially if you have other thing to work on than being up to date. So we go to conferences every now an then to get updated, but here we have the same problem, everybody has a different knowledge level. I will run away screaming if anybody explains Twitter to me again, but there are people who don’t know it, who have the right to know it and even have the right to have it explained during the same conference were somewhere else people talk about the next big thing after Twitter or discuss different Twitter tools or whatever.

I don’t want to talk about the conference itself, but about one crucial problem I experience pretty often at conferences, barcamps, meetups, workshops. We have to pay attention to different knowledge levels and stick to them. I appreciate that speakers explain a lot in order to make sure the whole audience understands them, but IMHO this lowers the general standard of a session

Not everybody loved school but it made sense to have different classes, so the students have the same basis and can move forward faster without going back first. I’d love to have the same thing for the re:publica. They managed to make it quite popular and therefor it didn’t only attract the averyge nerd, which is absolutely great. And for those who want to learn about the basics of social media we need sessions like: Get started with Twitter. Second grade: Twitter tools for journalists. 3rd grade: Twitters impact on Massmedia. Fungrade: Twitterreading

This year was an inbetween state with both the hip, well informed Techcrowed as well as Newbies. In order to please both groups next year and let the conference grow we need diversificaion to add value to the event for everybody. Besides that thanks to everybody how was involved in the organisation!!!

oh! And internet connection would be nice next time…

For one of our web sites we programmed a server that provides us with information about the whole friendship network on this site: Who is friends with who, six degrees of separation information, etc. Back in 2007, we wrote that server in C and since we started using it, it was running with absolute reliability.

Suddenly it stopped working, without any prior warning. It did not crash, the process was still alive. It just did not response to any requests that we sent to it. All requests timed out. And even worse, there was no helpful log information that pointed us to any specific direction we could look for the error.

Check list

The good thing was, since we programmed the server, we already had several points to think about first. On top of a C programmer’s check list is the segmentation fault, that happens when trying to access a memory area that the process does not own. But we could almost exclude this point, since the server would have logged any segmentation fault it did. This point got crossed out.

This left a second point on our check list: Blocking. Our server creates worker threads that deal with each client’s requests. For responding to the requests, all threads are sharing the same information about the friendship network, or, in a mathematical term, the graph. Here we are using mutexes in order to keep the information consistent (by preventing to have more than one writing operation at a time or to have a read request while there was some data written).

Mutual exclusion? Dining philosophers? Race condition? Deadlock?

Continue reading →