Tuesday, 31 December 2013

Cyberwar

Last month I watched an entertaining BBC documentary about Computer Security, Defeating the Hackers. It deals with several common topics like the threat to security posed by Quantum Computers, and the solution provided by Quantum Cryptography. It also mentions a new concept to me, Ultra Paranoid Computing (well, it seems quite new to everyone, as there's no wikipedia entry), bringing up the idea of using passwords that we are not aware of and as such we can not reveal. This other post explains it a bit more, but above all, the most interesting part to me of the documentary is the section dealing with the Stuxnet worm. Well, indeed, being a computing and history/social issues freak as I am, it felt like quite embarrassing to me being absolutely unaware of such a "bomb". So far I think it's the most important CyberAttack ever done, and it gives me the creeps to think how these things can evolve in the future (ok, admittedly this time the output of the attack seems pretty good, Iran's nuclear program being damaged and delayed, but bearing in mind that the perpetrators were 2 ultra-nationalist governments: USA and Israel, I'm quite sure they could launch the attack against any other less "evil" target at any moment, just to ensure their "supremacy" and their role of "policemen of the planet". This paragraph in wikipedia is quite unsettling

Sandro Gaycken from the Free University Berlin argued that the attack on Iran was a ruse to distract from Stuxnet's real purpose. According to him, its broad dissemination in more than 100,000 industrial plants worldwide suggests a field test of a cyber weapon in different security cultures, testing their preparedness, resilience, and reactions, all highly valuable information for a cyberwar unit.

Last week I stumbled upon another related documentary (indeed, even more interesting), produced by Spanish public TV (unfortunately it's only in Spanish). En Portada has been producing some excellent documentaries for many years (for example the one from a few months ago about the fascist Greek party (paramilitary unit) "Golden Dawn" was outstanding), which is something really praiseworthy in a place where 99% of the TV production is stinky crap that is direct responsible for the illiteracy, passivity and amorality (or just plain degeneration) of a whole society. This program deals again with the Stuxnet case, and also mentions some other examples of cyberwar, like the attacks on Estonia (this was well known to me), and 2 cases where cyberwar was combined with "traditional" war: an Israeli attack on Syria in 2007 and a Russian attack on Georgia in 2008.
There's also some interesting info about the Bahnhof service provider. This program is previous to all the NSA surveillance scandal, so they do not mention how in the last months many organizations are starting to look at European companies to store their data to the detriment of USA ones, now seen with huge suspicion. I hope this trend continues on and it means some boom for European Data Centers and IT professionals.

Related to Security, some weeks ago Martin Fowler came up with a brilliant concept, Data Austerity , pretty interesting food for brain in these times of "Big Data coolness" everywhere.

Tuesday, 24 December 2013

Some Thoughts on C# 6

I'm a Programming Languages freak. Though I've never been into compilers programming, I've ever had an enormous interest in their input, languages (and even their output, MSIL and so on). This explains why I follow with much attention the development of ES6, Java 8, anything related to Groovy... and I've been quite upset by the lack of news regarding C# 6.

Hopefully, this summer we got some information from the very Anders. There he mainly highlighted the importance of Roslyn, how the next C# will come with the new managed C# compiler (as a service), and how this will allow for further development of the language in the future. I quite like what he mentions about his work on TypeScript making him more appreciative of Dynamic features (I'd like to see the astonishing dynamic features added to C# in v.4 getting some more love in the near future)

Last week some more news about probable new features in C# 6 were released on the web. Well, quite a bunch of things, but in first instance I felt a bit disappointed.
The one I'm mostly interested in is that they call (oddly enough) "Monadic null checking" and that is just the equivalent to Groovy's Safe Navigation Operator. I've really missed this feature so many times that I even wrote a sort of workaround for it both for C# and JavaScript.
On second thought, I'll say that Read Only Autoproperties and Property Expressions seem also rather appealing to me, but anyhow, as some people mention in the comments, these are mainly cosmetic/wrist friendly additions, but nothing involving any real change. Some people mention that if you want a really modern language for the CLR, you should switch to F#. I don't like the idea, though multiparadigm, F# favors Functional Programming over OOP, so it involves a sort of paradigm shift that I haven't done yet (I'm used and rather keen of the soft functional features in JavaScript and C#, but I really need to devote some time to understand the advantages of a more purely functional approach).

All this has made me think about what features I would add to a modern language like C# (or Java 8), and well, indeed, there are not so many. C# is (for the most part) a mainly statically typed language, so some of the things I love in JavaScript (or Groovy) can't easily be applied/used (I'm referring to expanding classes or instances with new methods or altering the inheritance chain). Also, I'm not sure to what extent Python's metaclasses (little to do with Groovy's ones) could be used. Anyway, after some pondering, I've come up with this (wish) list:

  • Some kind of Multiple Inheritance of Behaviour, like the one enabled by Java 8 with its Default Interface Implementation. Scala traits seem even more powerful, so they would be more than welcome (and would probably involve just some more compiler magic, but no IL changes).
  • When writing this post, I realized that Iterators (Generators in normal Programming Languages parlor) could gain some more power (send, throw, close, delegated yield).
  • Some more investment in the DLR and dynamic. Not sure if at this point (where Lightweight Code Generation has been superseded by Expression Trees in most cases) extending the access to the IL code could get us any benefits.
  • Allow Attributes (Annotations in the Java world) to receive delegates (lambdas) as parameters. This is possible in Groovy land, but in C# all you're left with is an error prone hack.

In terms of the CLR, I think Microsoft have got it quite wrong with TypeScript. They've decided to follow that (to my mind utterly stupid) trend of avoiding JavaScript and writing something that compiles to it. Sure JavaScript is riddled with some quirks and gotchas, but it's one of the most powerful languages ever designed, and what we need is speeding up the development and adoption of ES6, as it fixes many of those problems. So, what I'd like to see is a modern JavaScript engine for the CLR (something like Oracle's Nashorn).

Saturday, 14 December 2013

Fun with ES6 proxies

Proxies have been (and still are) a long awaited addition to JavaScript. Finally it seems like they'll be one more weapon of the ES6 arsenal. Though I remember having read information about them a few years ago, they're so new that only Firefox (always miles ahead of any other browser in terms of JavaScript innovation) implements them. You'll read that you can enable them in node.js with the --harmony-proxies argument, but that's an implementation of the old Proxy specification (Harmony Proxies: Proxy.create...) that is obsolete and has been superseded by Direct Proxies.

Ever that I've used proxies in other languages it's been for method interception, so when reading the documentation my attention was mainly drawn to the get and apply traps. It seems interesting to me that they enable 2 different approaches for the same purpose.

Let's say you have an object with just one method, something like this

var cat = {
	name: "Kitty",
	sayHiTo: function _sayHiTo(subject){
		return "Hi, " + subject + " my name is " + this.name;
	}
}; 

and you want to intercept calls to its sayHiTo method. You can wrap your cat object in a Proxy and use a get trap, so that when the method is requested (got) you return the wrapping function:

var proxiedCat = Proxy(cat, {
	get: function(target, name, receiver){
		return function(subject){
			console.log("intercepting call to method " + name + " in cat " + target.name);
			return target[name](subject);
		}
	}
});

Notice that target is the object being proxied, name is the property being requested, and receiver is the proxy itself.

We can use a different approach for this, just wrap the sayHiTo function in a Proxy and use the apply trap.

cat.sayHiTo = Proxy(cat.sayHiTo, {
	apply: function(target, thisArg, args){
		console.log("intercepting call to " + target.name + " in cat " + thisArg.name );
		return target.apply(thisArg, args);
	}
});

With the first approach you would be intercepting calls to any method in the class, so the thing seems clear to me, if you want to intercept all methods (or want to use any other trap besides get), this is the way to go. On the contrary, if you just need to intercept one (or a few) specific methods, using the second approach seems more appropriate.

The thing is that we've been intercepting (or decorating) function calls for years, just by doing something like this:

function formatString(st){
	return "X" + st + "X";
}
console.log(formatString("hi"));
console.log("formatString.name: " + formatString.name);

formatString = (function(){
	var target = formatString;
	return function formatString(st){ //notice that I'm naming the function expression, so that function.name continues to return "formatString"
		console.log("intercepting call to " + target.name);
		return target(st);
	};
})();
console.log(formatString("hi"));
console.log("formatString.name: " + formatString.name); //returns formatString

so one could wonder if there's any advantage in using "function proxies" (I mean wrapping a function in a proxy with just an apply trap:

duplicateString = Proxy(duplicateString, {
	apply: function (target, thisArg, args){
		console.log("intercepting call to " + target.name);
		return target.apply(thisArg, args);
	}
});
console.log(duplicateString("hi"));
console.log("duplicateString.name: " + duplicateString.name); 

well, the functionality is the same, so the only advantage that I can see is that the code is more semantic (the Proxy call clearly indicates that you are intercepting that function).

One very interesting point with ES6 proxies is that they try to be as transparent as possible. For example an instanceof of a proxy, or a myProxy.constructor, will work just as if we were applying it to the the proxied object (target). Also, if we proxy a function, myProxyFunction.name will return the name of the target function. This makes me wonder if there's anyway to know if a given object is a normal object or a proxy around it. So far, I haven't found a way to distinguish them.

You can see some code here, and run it from here (in Firefox+Firebug)

By the way, time ago I uploaded a small interception library to github based on the old approach.

Friday, 6 December 2013

One more Programming Mashup

It's been a while since my last "list of interesting programming stuff" kind of entry, so here it goes a new installment.

  • JavaScript is already very well packed with reflective features: Introspection, Object Expansion, Runtime Code Evaluation (eval is not evil), so it called my attention to find Reflect API planned for ES6. As the document says, it does not provide new functionality, but is a convenient way to place this already existing functionality (I've always considered Object as an odd location for functions like: freeze, seal, getOwnPropertyDescriptor). It's also interesting to see how nicely it plays with proxies.
  • Talking of proxies, it's clear that it's one of the hottest and more expected additions to JavaScript, and we'll see all sort of interesting uses of it, one that I pretty much like is this one, adding negative indexes to arrays. If you take a look at the code you'll see it's just a couple of lines!
  • I pretty much like the usage (and the code) for this Dependency Injection library for JavaScript
  • With my love for Prototype based languages, I've never been much keen to use any of the many class emulation libraries for JavaScript, and indeed I don't like the idea of adding Classes syntactic sugar (internally it'll continue to be based on prototypes chains) to ES6. But when one comes across so many discussions about different approaches to inheritance, with names like "parasitic inheritance":
    • http://www.benlakey.com/2013/05/javascript-prototypal-inheritance-done.html
    • http://helephant.com/2009/08/17/javascript-prototype-chaining/
    • http://stackoverflow.com/questions/7250423/javascript-parasitic-inheritance?rq=1
    • http://javascriptissexy.com/oop-in-javascript-what-you-need-to-know/http://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical?lq=1
    • http://stackoverflow.com/questions/16929353/parasitic-combination-inheritance-in-professional-javascript-for-web-developer
    • http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/">
    one can end up changing his mind and thinking that the homogeneity that the class construct will bring to most developments, can be indeed a promising prospective.
  • I've found interesting this entry about how a bad design it is when a class requires its inheritors to call some of the parent methods. There's no way to force that an inheritor will do that, so if he skips that call, this new Child class will be wrong. As the article mentions, we should change the design to use the Template Method Pattern (one of my favorite ones)
  • I've always felt quite happy using normal objects when I need a Dictionary in JavaScript, so this post has been a real eye opener.

Wednesday, 27 November 2013

Exberliner, refugees in Germany

Exberliner is a really inspiring publication (it already prompted this post last year). The base idea (an in English lifestyle magazine for expats in Berlin) should not be particularly appealing to a scarcely social, not cool in the slightest individual like me... but it's crystal clear that Berlin is a different place, and what in other cities would be a hipsters oriented magazine, in Berlin involves articles about social issues, historical background and so on. For example, the April number contained great articles about the urban (gentrification) plans for the city and the wipe out of part of the socialist architectural heritage.

November's issue made a non stop reading session in my flight back, and helped me understand things I'd seen the previous days both in Berlin and Hamburg. Already in October 2012 I had come across a refugees support camp in OranienPlatz (O-Platz), and information about demonstrations and a march in solidarity with refugees. The same landscape has been present in my ensuing visits to the world capital (it's very funny to see how to me Berlin has turned into the Welthaupstadt that the nazi scum dreamt about, but just for all the contrary reasons: freedom, art, dynamism, convergence of ideas, alternative thinking...) This November, apart from the camp, I found many stickers, posters, flags hanging from autonomous centers and alternative book shops... reading: Refugees Welcome and Lampedusa in Berlin/Hamburg.

Also, when paying a visit to one of my favorite Berlin spots, the desolated site between the Spree and Kopenickerstrasse with its abandoned factory covered in graffiti and murals, I found a middle east family trying to build a shanty under the shelter of the factory.

Exberliner's november issue is called "Looking for Asylum in Berlin" and nicely explains the current situation through different interviews and articles. In the last years Germany has become one of the top destinations for people seeking asylum in Europe. The reasons for this are not completely clear, but one of them is the false belief that achieving asylum in Germany is easy. Reading the experiences of some refugees it's pretty clear that it's not. Years of stagnation in a Heim (emergency refugee centre), without any idea of whether your request will be accepted or not, whether you'll be moved to another Heim in another city, the inability to work as you lack the permissions needed for that... As more refugees have been arriving into Germany (and primarily Berlin) and no move has been done by the government to speed up the asylum request procedures or to improve the conditions in which they are kept until the final decision is done different support initiatives has emerged, one of them being the protest camp in OranienPlatz. The "Lampedusa in Berlin" phrase comes from the fact that many of those refugees enter Europe through Lampedusa.

It's shocking to see that lately there's been an increase of Russian gays seeking asylum in Germany on the basis of the wave of homophobia that Putin's government and the Orthodox Church have unleashed. It seems like in the last months Russian neonazis and other pieces of human debris have been moving their focus from dark skinned people to gays.

Apart from these sad refugees stories, there's also an interesting column about Die Linke, their last electoral results (unfortunately, not too impressive), their difficulties to get rid of the past and the permanent boycott they're subjected to.

Sunday, 24 November 2013

A slight taste of Perl

Over the last weeks I've been learning some Perl. Yes, I know it sounds like odd, what the hell is doing someone quite obsessed with language evolution learning a dusty 90's language?
Well, let's explain. First, a new project sprang up in my employer involving Perl and relocating for some months to the very beautiful city of Toulouse. Spending some months in Toulouse seemed appealing enough to me to make Perl look as cute as ES6 or even more :-) so I just eagerly jumped into the project.
Second, Perl is way much better than I would have expected. I guess I'll be blogging about it in the nearby future, so I'll just say here that you can do perfectly modern programming with Perl 5. This does not change the fact that the language is riddle with very idiomatic "features" that I frankly consider SHIT (the default variable/parameter thing above all), but well, it's just a matter of avoiding those things (and praying for not having to work with code written by others that consider those features cool and useful).

The thing is that while learning Perl I've come up with some very familiar features that until that moment I used to identify as JavaScript specific. Probably the most obvious are shift, unshift and splice for arrays. While the functionality is common to almost any language/library, the choice of names is not (I guess Append, RemoveFirst... are quite more natural).

A fast search brings up a related entry in the excellent 2ality blog. Well, there are a few more influences not mentioned there that I can think of:

  • Perl's undef is mainly the same as JavaScript's undefined
  • While (contrary to JavaScript) Perl lacks a Boolean type, the coercion rules applied to normal values in if conditions and son on are pretty similar. 0, "", and undef are considered false. Notice though, that "0" and an empty array/list will be considered false in Perl, but true in JavaScript.
  • I would not call this an influence, but an inherited disease... the most basic function to obtain the current datelocaltime, considers months from 0 to 11, rather than 1 to 12... one of the most common JavaScript gotchas.
  • Update, 2013/12/27 Removing a key from a dictionary/hash is pretty similar (and not particularly intuitive, I would prefer a .remove method), use the delete operator in JavaScript:
    delete myObj.key;
    or the delete function in perl:
    delete(myHashRef->{key});

There has also been some more recent influences. JavaScript 1.7 first (implemented by Firefox since quite a few years ago) and ES6 now, implement destructuring assignment, a beauty that Python also drew from Perl. Moose, a modern object system for Perl 5 sprung up a JavaScript equivalent, Joose.

Sunday, 17 November 2013

Stree Crap 2

While being in Hamburg last week, I came across another insult to aesthetics that makes a good follow up to this previous post. I was quite interested in paying a visit to the Bismarck memorial in Hamburg, mainly because its Berlin counterpart makes one of my favorite monuments, though not for the Bismarck statue itself, but for the 4 other statues surrounding it. You can read the wikipedia article for some basic info, I'll just say that they look incredibly imposing and powerful (reminding me in that sense the astonishing 2 statues flanking the entrance to the Altes Museum.

Hamburg's memorial is quite interesting, Bismarck stands sober and serious watching over one of the most affluent cities of the country he managed to unify (specifically over St. Pauli, the most leftist, anarchic, party going district in Hamburg). It's quite remarkable how with his cape and sword he looks more like a Teutonic Knight than like a statesman of the end of the XIX century.

And here you have some pics of the offence, when street art turns into street crap

As for Bismarck, he seems to be a rather interesting personage, and not just for founding the most important country in modern Europe. From my basic understanding of his biography, I have mixed feelings about him. On one side he was deeply anti-socialist, but on the other side he was responsible for creating the concept of Welfare state that civilized people (i.e Europeans, Canadians...) have today, along with trying to avoid war by all means (without him, WWI well might had occurred some decades earlier).