CSS is mainly known as a language to arrange a website’s frontend, more precisely, the presentation layer of a website frontend. However, CSS’ real biggest strength is its powerful selector mechanism. Before you can assign a certain color, font size or background image to a site element you need to point to this element.  While a lot of semi-professional frontened developers tend to assign classes and unique IDs to HTML tags heavily, the more professional folks utilize the power of more complex CSS selectors to address the desired elements based on their HTML tag names and their place within the DOM tree, the object structure of a website.

SQL - the Structued Query Language - is a language to query databases. It allows to request certain pieces of data out of data stored in a database. Even so you normaly do not directly assign a color or background image to the data retrieved from a database, in the first step, you also selected data of interest that you want to pick up for later purpose. Pretty similar to CSS!

As you can see, SQL and CSS are both capable to select a set of data out of a (maybe even bigger) set of data. In the first case, it’s about to query a database, the latter about retrieving parts of a document.

In my early day of working in the computer industry, I was afraid of those beasts of applications such as database servers, servlet containers or virtual machines in any flavor. They looked big and scary to me, they have thousands of parameters and you can buy a lot of books about them.

However - at some point in time I realized: Hey, it’s just an application! It might have millions of lines of code, classes and files, but hey, in the end they are just using variables, loops, switches and all those fundamental stuff that I also use to build my applications. Even my applications might be less complex compared to those beats, however, in the end, there is no difference between them. Once I realized that, all awe was gone immediately. Sure -  I still have esteem for what those guys do, but myself I am not feeling any less capable anymore. I could also build a beast in future if I just have enough time and support. That’s it. No other hidden magic.

I don’t know if you ever had such a train of thought helping you to solve one of your major issue in a second, but to me this was one of the most important ones I ever had in my professional life.

TIm Berners-Lee kicked off the semantic web and he already kicked off the non-semantic web also known as the WWW of these days.  As you may already know, the semantic web is about making the meaning of information available and accessible to machines. This can be archived by adding useful meta data to the data itself. An example here: When I put the token “Berlin” into a webpage I also add some meta data to it explaining that I mean the city “Berlin” In Germany. In conjunction with other statements on the web explaining that Germany is a country and that a city is “an urban area with a high population density and a particular administrative, legal, or historical status” things start to make sense.

The interesting part here is that a lot of meta data is already existing in your web application but is not exposed as payload on the websites generated when calling a URL. This meta data might be hidden within database table definitions or tables’ relationships, class definitions within you object oriented code, business logic tying together certain objects, packages, modules. Within your code, you normally declare that “Berlin” is a city, either by holding this value in a object that represents a city and/or by obtaining the value from a DB table called “cities”, “city” oder similar. But this information gets lost in the end once the page has been generated.

Instead, this information is hidden in the non-visible part of your application nested deep in code or in databases just being utilized to generate web documents but not being part of the web documents itself.

So, one could say, the semantic web is about making all that hidden meta data visible to the world wide web and therefore to an unlimited number of clients and agents on the web. In fact, it brings together the web’s databases and objects and puts them centered onto the stage instead of hiding them in the back. By the way - if you take a deeper look at RDF and/or OWL, you will find out that they have a lot in common with relational databases …

A platform in Technology is something on that something else can be built on. A foundation, that can be used to start building things on a more abstract level ultilizing high level services provided by the platform. A modern web application architecture treats the “main” user interface just as its first client, not as an inherent part of the story. That’s also one of the ideas of SOA.

If you read that blog post on eBay’s Developer Portal you will notice that the eBay API and the eBay website are different in functionality. This means in fact that the eBay website itself is not built on the same platform that is being offered to 3rd parties.

Why is this? eBay was pretty early when the idea of APIs arised and quickly offered functionality via XML/SOAP based APIs to 3rd parties. However, the whole bunch of code making up the eBay website was already there and it was decided that duplicating (and maintaining) code is the better way to go instead of making the existing code reusable for other clients (what a can be a very painful path, by the way) .

Therefore, to me, eBay isn’t a real platform today.

The world around us isn’t simple. Take a look at the sky and see those heavy complex figures made up of clouds, consider the human genome or talk to an astronomer just once to realize that things aren’t as simple as we wan’t to model them mostly in business and technology.  A common rule for nearly everything is “Keep it simple” - and yes, this is a good thing. However, don’t let it trick yourself - process charts, software architectures and any kinds of models in general needs to be complete at first. If they are not, they won’t be applicable at a certain situation.

So what is the trick here? First of all: Don’t over-simplify! Accept the fact that things are complicated sometimes. One way of building solid simple models is to really put all the complexity on the table first and then try to carefully abstract and harmonize certain simgle aspects. If t hisdoen’t work out well here and there you might need to keep certain complexity that you wanted to boil down originally. If you try to do anyway, your model won’t work in certain situations and therefore won’t work at all.

Keep in mind: Keep it simple, but don’t overdo.

If there is one comprehensive definition of what computer science essentially is, then it is building layers of abstraction to make things easier and less awkward to use. Much more, by putting more and more layers of abstraction in there, some things might become possible which were not even thinkable before.

I guess that people in the ancient world (where they first discovered the phenomenons of electricity) but also the masterminds of some decaded ago never even thought about that it might be possible one day to send data across the globe just by utlilizing electricity (and nowadays also light by the way); that there might be machines available some day that fit right under a desk and are able to do more calculations per second that you could even imagine (the number just has too many zeros - the human mankind isn’t used to big numbers at all).

However, electricity itself is very … ehm … basic. Electricity is pretty far away from an iPhone or a modern computer at least from a user perspective. In fact, you do not need to care about electricity anymore after putting a power plug somewhere into the wall. Colorful images do appear on your TFT display in a pretty magically way. However, it’s good to know that in the end, it’s all based on electric signals and that there are so many layers of abstraction acting for me right know allowing me to write this post and make it available to the world so easily. If I would only have electricity itself then writing a post that can be read all over the world is pretty absurd, isn’t it?

The people putting those layers of abstraction in place are computer scientists. In fact, the degree of abstraction can be endless and mostly it’s not about starting at the lowest level of abstraction anymore. Often it’s about working on a new layer above the latest existing layer. There is not only one single stack of layers of abstraction, much more, the whole thing looks like a tree. The root is made up of some very basic physical effects, such as electricity which nearly all stacks share. But if you move up the tree, you will find out that there are endless branches which might share several other additional layers of abstraction and which often - unlike with a real tree - could also grow together again.

If you are in technology yourself, you will recognize application frameworks (JEE, Ruby on Rails, Zend Framework, etc.) as just another layer of abstraction within the stack to make things easier and to hide certain “basics” from you. You just directly deal with a HTTP request object (with nice getter-methods) instead of parsing a raw HTTP request byte stream picking the important pieces of data out of it on your own anymore, don’t you? IP and TCP is also just there. You don’t really care about it anymore when writing a web applicaition.

Same with Grid and Cloud Computing. Those layers just hide the complexity given by hosting a software. You just “plug” your application to a grid (as you do with the power plug of your computer already) and hosting capacity is just there. As much as you need. If you turn on more lights (or get more users on your site), the demand is automatically contended.

That’s what it’s all about. Abstraction.

Caching is one of the most famous buzz words among developers, engineers and architects when it comes to scalability and performance of applications. It sounds magically and mystically and helps us techies to put MBAs and wannabes into their bounds of IT skills. However, as often the case in information technology (but also in other disciplines such as economics, physics or maths) experts tend to obfuscate pretty simple things in a way that noboby else understands them anymore.

But … here is the plain truth:

Caching is just about locating something as close as possible to its consumer.

Let’s consider the following example: At my home, beer can be stored in different places. Each place is harder for me to reach. Starting with the liquor store around the block (far way), followed by the basement (not very near) to the fridge in my kitchen (near). If I want to grab a beer with least efforts (way to walk and time it takes to do so), I may want to make sure that I always locate some beer in my fridge. I need to cache the beer. As beer is a consumer item I will also need to make sure that the cache is re-filled continuously.

Why is this good? First of all, if I have some beer cached, I can get it very fast if I want to. I do not need to do very much for it. Much more, I am also quickly available to handle some other longings (”Give me pizza!” says the brain) as I am not locked with the task of getting a beer for so long.

That’s it. If you take the tale from above and put it on information technology, it seems to be very obvious, that this method can also help us to speed up (web-) applications. As you may know, it takes longer to read data from a harddisk instead of reading it out of the RAM. Also it is faster to read something from a harddisk instead of reading it from a network host somewhere in the distance (especially if this host itself needs to read the data from its own local harddisk).

Therefore, it might be a good idea to put certain data into a place nearby where it can be accessed fast and easy. Especially in web applications you should always remember, that we just talk about single documents that are rendered (”shown”) in a user agent (”browser”) on request. If you have a document to show to people you should always first identifiy if the page contains any data that is meant only to a specific requestor. If not, try to stop generating that document again and again with each single request and instead pre-generate it on a regular basis (each minute or so) while caching the result (static page) for serving . Sure, caching can also make sense for just a specific user, but if you can pre-generate documents for all users of your site at once, the effect is much more impressive.

Imagine that there is a “virtual requestor” inside of your application requesting a specific URL again and again and making that generated (and now static) document available to public. If you have a lot of traffic, this approach can help you to save thousands of expensive network- and database connections.

As you can see, caching itself is nothing really cool. However, electrons are also not very interesting by default, but when pushing them through a wire, they can turn on the light.

Today, I plugged my new apple steel keyboard to my Intel based PC. Ultra slick, ultra flat, ultra cool. Best keyboard I ever had in my live so far. Works nicely on XP, Vista and Linux. However, maybe I should also switch completely to a Mac now?

… I’m sick and tired of hearing it! Sorry, just wanted to say that.

… even most of the people are telling so. However, they just mix up the terms, they don’t get the point. A cookie can hold an value (identified by a key) that could be used as a refrence to a (http) session object somewhere to identify a user (session) in the end. A cookie could also serve as the foundation for usage tracking on a page (page impressions, etc.) but a cookie is not a tracking system by itself.

It’s like a piece of paper: You can store some information on it or you could do some origami with it. Nevertheless, both are just use cases of paper, but not paper itself.

Duh.