The Zen of Multiplexing (Revisited)

Technologies that are related to software engineering, occasionally produce the following phenomenon; they occasionally re-inventing the wheel. Not only that, but these technologies are always presenting themselves as mind-blowing, we-are-going-to-save-the-world solutions.

First Blood, Part One: Responsive Design

There is a bunch of programmers that always designed websites that did fit quite well in smart phones and tablets. Then they decided to make it to work properly and produced tons of libraries and related technologies that focused on presenting the content correctly on all screen sizes. Ok, and they think that this is a new piece of technology and not a bug fix. They have this great proposition: “Hey, now you can see this website on all devices, and we call it now responsive design”, and we charge accordingly.

First Blood, Part Two: The Zen of Multiplexing

Not so long ago, IP Networking was invented and people thought that it would be cool to have several services multiplexed on the newly founded network data channel. They conceived the ports on the Transport Layer. Ports were numbers assigned to specific services; thus we had the 80 port for the HTTP service, 22 for secure shell (SSH), 20 and 21 for FTP etc.

So far, so good, but it seemed that our fellow software engineers were not happy with that approach, and they decided to do something else instead. First, the idea of permitting only HTTP port (80) appeared. All other ports were designated as insecure (!) and one-by-one network administrators closed them with firewalls. But the need to multiplex was still there, and the re-invention pattern became a reality. The concept was simple; all protocols (or at least many) and services were rewritten to work over HTTP.

ws-mania

What Goes Around, Comes Around

The insecure port mechanism gave its place to a new set of vulnerabilities, like SQL injections, etc. In addition, all modern approaches appeared and many services were rewritten from scratch, utilising the new paradigm.

But in reality the gain was minimal, firewalls were replaced by intrusion detection systems that made deep packet inspections, to identify if the packets transferred over HTTP was indeed legal. All protocol replaced by HTTP, thus inheriting its good and bad characteristics.

The Final Frontier

It seems that there will never be an end to this. Software engineers seem that they feel the need to reinvent the wheel (or parts of it) every now and then, enforcing their clients to pay costly software rewrites.

Of course, many of those alterations contain improvements, sometimes significant ones, but I think that all these is a matter of control. Maybe programmers think that it is better to control all aspects of the software and service multiplexing is a significant one that cannot be left to the operating system or the network to handle it. But the question is, who pays the bill?

 

Top Free App … only 13.99

If you have an old enough mac computer (with mavericks) and you try to download the “free” version of iMovie, you need to pay 13.99 euros. Nice, huh.

Maybe they could have calculated the iMovie price along with the mavericks upgrade fee, because right now it is quite funny to pay 25 euros for the operating system upgrade, and 13.99 for the iMovie only (I will comment that all the pages, number etc are also free for only the new mac computer owners).

topfree

Lost Treasure of Old-Skool Gaming Found: Saboteur II

Yesterday, I was tidying up my old room and found hidden in a drawer a hidden treasure. It was the manual of an old game that I have bought back in the 80s, Saboteur 2. It was a cool game and I have spent quite some time on it, exploring and drawing maps of the fortress.

256px-Saboteur_II_Spectrum_Inlay

 

 

 

 

 

 

In the game you were a female ninja (sister of the guy that was the protagonist in Saboteur) and your mission was to disable a nuclear missile that was located in a fortress and escape.

The game was very addictive and the manual, brought back many fond memories (and the love for my old speccy). For archival reasons I attach the manual (in Greek) in this post. If you want the page in better resolution, just mail me.

Saboteur Manual (Greek) - Page 2
Saboteur Manual (Greek) – Page 2
Saboteur Manual (Greek) - Page 1
Saboteur Manual (Greek) – Page 1

 

 

 

 

 

 

 

 

First Rule of bkarak (me) of Computer Programming

My one (and only) so far rule of Computer Programming:

If a typical programmer can write a program in 100 lines of code, a bad programmer will need 120 lines, a good programmer 80 lines. But this is it, no programmer can write a shorter program.

 

Success!

Great! We did it! Nothing working, but nevertheless the letter on the heading should be green. right?

Thinking in jQuery

Recently I was doing some heavy-duty Javascript stuff for a web project. It was quite a while since the Firefox plug-in and in many ways, it was rather enjoyable experience (and in some other ways boring 🙂 ).

If you want to do some cool stuff in the web nowadays, the adoption of a Javascript library like jQuery is typical. I had some experience in the past, but the development process showed me that I was not so experienced as I thought. jQuery has good documentation that can be used as a reference, but it is not very usefull, when you want to understand some basic concepts and you are in a hurry of doing some stuff to work.

So, this blog entry has one goal, to transfer my experience of doing stuff with jQuery as a set of rules/advices that will save time to inexperienced users like me.

Rule #1: “When you are using jQuery, forget low-level Javascript functions”

It is a good practice to use always jQuery’s functions to do the stuff you want. Never rely on the low-leve Javascript function. The reason is simple. jQuery offers an encapsulating object for all the elements of the DOM tree. If you select some nodes with the jQuery selectors and then try to access their children with the common DOM function offered by the standard Javascript API, you are done for. You lose that encapsulation and you are back in black.

Rule #2: “Use # for the ‘id’ selector, ‘.’ for the class selector and always use backslashes in front of dots in ids”

No special reason, just remember these three examples:

  • $(‘#theCoolId’) – id selector
  • $(‘.myBigFatClass’) – class selector
  • $(‘#theCoolId\\.With\\.Dots’) – more complex id selector

Rule #3: “When you have to insert code into an element, use html()”

Simple as that, select the node and paste the code:

$('#theCoolNode').html('

Hey Stranger!

');

Rule #4: “By default the ajax() call is asynchronous”

… so if you want to load something, be sure to disable async, or else you will try to access something that is not ready. How can you do that? Simple!

$.ajax({
	type: "GET",
	dataType: "xml",
	url: "data/strings.xml",
	success: function(xml) { /* success */ },
	error: function() { /* error */ },
	async: false /* I will wait to load the XML */
});

Rule #5: “insertBefore() and insertAfter() take the selector as the parameter”

I do not know about you, but I always thought that it is logical for the insertAfter() and insertBefore() to select a node, then append the node. But this is not the way they are implemented. A small example:

$('

Hey Joe!

').insertAfter('#theCoolNode')

Rule #6: “It is always your fault”

Usually it is, accept it and try to understand how things are working :), instead of trying to convince everyone that you are Mr. Right!