Category Archives: Code

Request Loop

It’s been a while since I last posted…

There is always a reason for that. My reason was a sum of many different variables. Just as the great mentor said, luck is the sum of many coincidences, that’s what happened in my case as well.

Where do I begin?

Jobwise: Capital controls, working day and night, a lot to do and no time to do it…

Blogwise: I had a very strange setup with my blog (and a very very outdated one I might add). Since I am using Heroku, they decided to change their stack and migrate from Cedar 10 to Cedar 14 . Ok I said what the hell lets do it.

Alas, I had a serious problem with libssl0.98 which was built inside my php module and was not supported in Cedar 14. (whoever wants to do the upgrade have a look here first).

Long story short I fixed it, and I also found that many posts I did with various hacks for the pg4wp plugin were incorporated into a single release from kevinoid : here

I will contribute also into some changes that have to be taken into account since the module is quite old and I have previously stated that it’s not at all well written.

That’s not the main point of this post though.

I wanted to share an experience I keep coming across lately.

Now according to popular trends we are experiencing (and will experience in the future) a huge bloom of the microserviced architecture. This guy here explains how and why they decided to go for the microserviced architecture.

I agree. There are many benefits when having a monolithic single (and obsolete at times) repo for web applications. It is a nice solution when your company is scaling, and you have to maintain a lot of different parts. Especially if you have different teams and each team wants to “do their own thing” about a solution.

However it’s not the solution to Everything!

I will elaborate more:

I recently had to debug an http step based procedure (client requests this page, books this ticket, goes there, etc.) that was using 3 different instances of different technologies over http. The one was python and wsgi, the second was php with apache and the third one was ruby with unicorn.

Try to debug this. I dare you. Seriously. I had in my local setup all 3 different instances running with 3 different IDE’s and all running their debugger. Ok, ok you say that Docker will simplify the installation. I agree it does, but it does not help the debugging at all.

The most important thing though isn’t the debug/testing of many different apps over http.

It’s the HTTP by itself.

And believe me, I have seen a lot of “Senior” Devs falling into the same trap of API’zation and doing over and over the same architectural error.

The Request Loop

You won't guess how many time's I've seen this happening...
You won’t guess how many time’s I’ve seen this happening…

Consider the following diagram:

This is the actual loop - when one request is still open, another comes along, and things get messy...
This is the actual loop – when one request is still open, another comes along, and things get messy…

The Browser  sends a request to the Frontend app. Now the Frontend App could forward it (or change it a bit) to the Backend App.

In our setup the backend app was a PHP app.

Now since PHP by default does not support threading (not pthreads), each HTTP request is a different PHP thread, served via apache.

This is very complicating, since you keep a connection (process) open and you open another one which could (at some point maybe) rely on data from the first one. You cannot access that data in between processes.

Not to mention that, you can not either debug this thing, since you insert a break point in the first request procedure, and the second request (which happens a few ms after) is being served without the debugging stopping at that point.

My point is that when you decide to go Microservice’d

Try to avoid request looping, when you need to do something that is synchronous. Or, use something different. Do threading. Use a message queue, or something else.

You will be surprised how much time you will spend trying to debug and understand what is wrong in this set-up.

I will close with the following meme:

Some people, when confronted with a problem, think, “I know, I’ll use threads,” and then two they hav erpoblesms.

5 Programming Languages Marked for Death

Now, every developer has some preferences

Preferences depending on the language he or she wishes to write to. But as people evolve and new technologies arise languages are more or less being used by people. By the time some people abandon a language, there is high chance this language will die.

Quiz: Name the Movie.... :D
Quiz: Name the Movie…. :D

According to Dice.com…

The future dead languages are the following:

Perl

There was a time when everyone seemingly programmed in Perl. But for those of us who used the language regularly, there was something about it that didn’t seem right. One programmer I knew called it a “piecemeal” language, because it seemed as if the creators had just piled features on top of features without giving much thought as to how everything fit together. Indeed, even its creators seemed to (implicitly) acknowledge that something was wrong, kicking off work on Perl6, currently under development as a complete revamp of the language. Work on Perl6 started in… the year 2000. Where is it? Who cares? Perl is dead. Don’t bother learning it. Incidentally, here’s a “Goodbye World!” written in Perl:

#!/usr/bin/perl
 print “Content-type: text/html\n\n”;
 print “Goodbye, world!\n”;>

Ruby

Just ten years ago, Ruby was all the rage. Invented in 1995, the unique language hit its stride by themid-aughts. People who use Ruby on a regular basis absolutely love it. But those of us who grew up with C-style languages tend to have a little trouble learning its ropes. Here’s a simple “Goodbye World!” in Ruby:

puts ‘Bye bye, Miss American Ruby! Drove my Chevy to the Levie…’
puts ’2011 was the day that Ruby died, yeah…’

By all accounts, it’s a cool language and everybody has good things to say about it… except Twitter. In April 2011, Twitter announced that they had rewritten much of their code in order to move away from Ruby and its popular Web framework, Ruby on Rails, claiming the platforms were inefficient. That, I would argue, was the day Ruby started to die; over the past three and a half years, interest has begun to wane. If you love Ruby, you can thank Twitter for its demise.

Visual Basic.NET

Ten years ago, I landed a job rewriting massive amounts of code for a company that shall go nameless, converting from VB6 to Visual basic.NET. I only lasted a couple months before I bailed: It was an excruciating task. Microsoft’s long love of the BASIC programming language extends all the way back to 1991, when the company purchased a pretty awesome (for its time) visual programming designer from Alan Cooper. He originally used a different language, but Bill Gates told him to replace the language with BASIC, which he felt was the easiest language in use at the time. For most of the 1990s, we got to see this new breed of BASIC, dubbed Visual Basic, grow to include objects and other newer programming techniques. Then something interesting happened. The guy who headed up the creation of Borland Delphi, Anders Hejlsberg, moved over to Microsoft and headed up the creation of a new language called C#. This language was very similar to Java. It took a while for people to start using it, but once they did, they loved it. C# soon became Microsoft’s flagship programming language. To this day, there are many, many C# jobs, and C# programmers command high salaries. While Microsoft created C# to target its own CLR runtime, its engineers also created a version of Gates’ beloved BASIC language, named it Visual Basic.NET. The language still bore the syntax of BASIC, but the coding approach was similar to that of C#. Both languages moved forward, but it was inevitable that the world would embrace one (C#) at the expense of the other. That’s why Visual Basic.NET has been reduced to C#’s little stepbrother in hospice care. Here’s a Visual Basic.NET program from Microsoft’s website:

‘ Allow easy reference to the System namespace classes.
Imports System
‘ This module houses the application’s entry point.
Public Module modmain
   ‘ Main is the application’s entry point.
   Sub Main()
     ‘ Write text to the console.
     Console.WriteLine (“Hello World using Visual Basic!”)
   End Sub
End Module

Adobe Flash and AIR

Technically these are platforms, not languages. I’m including them because, in order to use them, you need Adobe’s own version of EcmaScript, called ActionScript. ActionScript is a close cousin to JavaScript, which (love it or hate it) is one of the most popular languages today due to its implementation in all browsers. ActionScript adds a few details to EcmaScript (which is the official name of the standard, of which JavaScript is an implementation); you won’t really find ActionScript anywhere except for Adobe Flash. Do you use Flash? Steve Jobs hated how it hogged his devices’ processors, and refused to allow it onto the iPhone. As the iPhone (and subsequently the iPad) grew in popularity, Web developers found themselves forced to create websites that didn’t rely on Flash. Developers who made a living coding up ActionScript for Flash-powered sites screamed bloody murder. (I personally saw a Flash developer tell off a room of JavaScript developers for destroying his career.) Adobe tried to keep its programming platform alive via AIR, paired with a tool for building AIR apps called Flex. AIR was, in the estimation of many, a disaster. It wasn’t clear what Adobe wanted out of the whole process; did they want people to ditch Flash and use AIR instead? Or were they expecting AIR and Flash to live on together? For a short time it looked as if AIR would take off, thanks to its use in a popular Twitter platform called TweetDeck, which required users to install the AIR runtime on their computers. That might have opened up millions of PCs for AIR apps, except Twitter bought TweetDeck in 2011 and rewrote it using native code instead of AIR. So much for AIR. And between the deaths of both Flash and AIR, Adobe’s ActionScript can kiss the world goodbye as well. Here’s some sample ActionScript code. (If you use the Flex command-line tools you can compile this into a Flash thingamajob that you can embed in an HTML page):


package {

import flash.display.*;

import flash.text.*;

public class HelloWorld extends Sprite {

private var greeting:TextField = new TextField();

public function HelloWorld() {

greeting.text = “Hello World!”;

greeting.x = 100;

greeting.y = 100;

addChild(greeting);

}
}
}

Delphi’s Object Pascal

With sincere apologies to my fallen Delphi comrades, I must announce the death of Object Pascal. Okay, Delphi (the tool for developing Object Pascal) actually lives on, having moved between companies (it originated with Borland, and now sits with Embarcadero). The original Delphi and its Object Pascal language actually presented a great working environment; the language was a bit wordy, but the compiler was fast and it was much easier to create Windows programs in compared to Visual Basic (I’m talking pre-Visual Basic.NET here, around 1995). The momentum didn’t continue. It’s hard to say just why, since the platform was really quite good. Meanwhile, Borland began supporting C# and C++ in its Delphi line of products. Long story short, Delphi was eventually sold off to Embarcadero, which continues to produce it. It’s big, and it’s sophisticated, and continues to do reasonably well—but its focus is not Pascal. Yes, you can still do Pascal programming in it, but few people do; in fact, you can use Delphi to build for many different platforms including iOS, Android, and, soon, Linux. But if you go to the Embarcadero website, you’ll see that they mainly promote Delphi’s C++ support. So, Object Pascal is dead. I say this with sadness, as I’ve spent quite a bit of time programming in Pascal and especially Delphi’s Object Pascal. But that’s life. 5 Programming Languages Marked for Death.

One Liners and Overengineering

Sometimes being a developer is hard work

And that is because you have to study and understand the code other people write. Now, this has many aspects in terms of understanding. There are many people who write code. Some of them are good at it, some are not. It all comes down to two categories in my opinion.

“I’m bored of this thing” people

These people  write code just enough to finish the feature. Not very descriptive code, just enough to get the job done, nothing more. Their variables are often misunderstood, they do not have the proper names or sometimes they have a twofold meaning. Something like:


$thisVariableMightContainAStringOrATraitedSuperObject

Their code structure nonetheless is pretty much the same like :


function addOrSubtract ($addOrSubtract, $firstOperand, $secondOperand)
{

if ($addOrSubtract == '+') {

  return $firstOperand + $secondOperand;

else {

  return $firstOperand - $secondOperand;

}

Their tests also are somehow like the above example. They tend to irrationally use the same structure, using the “feature” of loosely typed languages.

One Liners

Now these people I love. They are trying to do the same thing with the above people, only, they delve into it. They are bored also at first, but when they see that their code can be optimized, they are “one-lining-em”. They do not use the wrongly inferred type as the above people, and their code is “a mystery” yet “it gets the thing done” in one line. Supreme elegance in my opinion.

example :


[].forEach.call($$("*"),function(a){
a.style.outline="1px solid #"+(~~(Math.random()*(1<<24))).toString(16)
})

Now these One Liners are writing the best optimized code.

The above line was taken from this guy’s blog who explains the exact function of what it does. It is amazing how much you can learn by just one line of code.

What it does is to apply a single pixel outline to all the elements of a page, randomized with a different color. Simply paste the above line in your browser’s console and see what happens. The purpose of this line is to debug your css layout in the page.

If you have a look at the above page you will see that this line is taken from a simple gist and there are a lot of people who are suggesting revisions on how to write that single line.

I will conclude by saying that programming

is something that is quite complex at times. People who do it for a long period, tend to do the above things in order to “escape” the routine of writing plain code. Over-engineering and trying different things (in all the acceptable frameworks of programming, like optimization, maintainability, debug free code) is something that is being constantly done, to keep oneself from doing something different even if one does not have the capability of doing so.

What I mean is that, after you have seen all the technologies, you have used all the “regular path” ways of a construct, you are always trying to do something in a different – peculiar way so as to “escape” the straight-forward, more “boring”, more “effort consuming” way.

And believe me, I have seen this from many, many people that are indeed very good engineers.

After all, Lazy people make the best inventors…
Doing a thing as simple as touching one's left ear, could prove quite complex...
Doing a thing as simple as touching one’s left ear, could prove quite complex…