Community, Javascript

What ES6 features can be used in Node with no transpiler [Part 1]

As soon as I started attending the great London JS community meetups I immediately noticed mixed feelings around ES6.
It seems people is definitely looking forward to it becoming mainstream and they’re hungry for information about it, but at the same time they tend to stand clear of it in production.
Skepticism? Lack of success stories? maybe…
At the time of writing ES6 is not fully supported everywhere and our code needs to be transpiled to older versions of Javascript in order to run properly on all the targets.
Hence, where ES6 is not supported the code we wrote is NOT what gets executed, and all the new cool features provided by ES6 become mere syntactical sugar that comes at a high potential cost:

  • bugs\incompatibilities difficult to debug (as, again, the code we wrote is not the code that is executed)
  • performance issues difficult to overcome (as a new performance enhancement can be transformed in a not-so-performing piece of “old” javascript)

I can imagine some pioneers’ smirk right now. Yes we can run our node app using the ES6 staged features, or even the features currently under development, but is it really a choice? Are we confident enough to run our production app on a beta (or even alpha depending on the maturity of the single feature we plan to toggle) ?

So, let’s consider the bright side for a minute…
Last time I checked the Node docs I read that some ES6 features are ALREADY supported with NO RUNTIME FLAG REQUIRED.
So, I would not go for yet another post on how to fake… ehm…”transpile” ES6 in your Node project, nor I would suggest you to enable all the WIP features.
I’d rather check what is possible to use AS TODAY in Node (version 4.1.0), and identify what are the benefits they come with.

Our trip is going to be long, so let’s start from listing what is available from the menu:

  • Block scoping
    • let
    • const
  • Classes
  • Collections
    • Map
    • WeakMap
    • Set
    • WeakSet
  • Typed arrays
  • Generators
  • Binary and Octal literals
  • Object Literal extensions
  • Promises
  • New String methods
  • Symbols
  • Template strings
  • Arrow functions

Block scoping

let & const

These new features are real game changers (even if you are a “var” aficionado).
While the memory allocated by var lives within the function scope, the memory allocated by let and const lives within the code block.


Syntax sugar aside, a much more granular memory management is VERY welcome.
Before ES6, each time a var was declared a memory location was kidnapped for the entire function scope.
Check the examples in the reference docs, but also consider this example using files and repeat with me: “yes, my app won’t be memory hungry anymore”.
Screen Shot 2015-09-30 at 21.45.47


As the docs reads Classes “are syntactical sugar over JavaScript’s existing prototype-based inheritance. The class syntax is not introducing a new object-oriented inheritance model to JavaScript.”


Syntax sugar, no memory management nor performance benefits.

Where are the others?!

I won’t cover the whole menu all at once
but part 2 will come soon, stay tuned ;)

Community, Haxe

WWX 2014 follow up – thoughts on haxe

I just came back from the World Wide haXe conference held in Paris this weekend and want to share my thoughts.

I’ve been evaluating haxe as a viable option for my company’s daily development other times in the past as I really think the language is great and the technology has a huge potential.
What always made me choose for a different solution was the lack of tools, the focus on the gaming industry, and the lack of documentation.
So I left for Paris with a defined set of questions and got a range of answers from very disappointing to mind blowing.

Let’s start with the good news, and let’s talk about

Case histories

what to say… I’ve been mind blown, two huge success stories and both OUT  of the gaming industry.


The haxe foundation (finally) decided to focus on documentation and rolled out


I’ve been VERY bothering throughout the whole conference about tooling, I asked almost all speakers about the tools they used in the daily development.
Coming from 5 years across IntelliJ, Visual Studio, Xcode and Eclipse I feel the need for a major IDE and a working automated build pipeline for my technology of choice.

I got quite disappointed by the choice of the haxe foundation to focus the effort in sponsoring yet another haxe IDE , only for haxe development, namely HIDE, instead of focusing on a major IDE support.
I got even more disappointed when more and more speakers and attendees were trivialising what I felt as a major issue and were pointing out that sublime text is simply “good enough”.
Luckily business stories are choosing a different approach and both TiVo and Prezi showed they’re using intellij for development, and the guys from TiVo said that the work to be done on that plugin is still quite a lot, for instance there’s no unit test runner.
Tools are far from being at the level of other languages, but luckily all of them are open source and can be improved by the community, and at the time writing it is possible do what a mature language environment should allow:

Even if the road is still uphill we can spot the top getting nearer.

Other news

More news were presented, briefly:

  • there’s a brand new python target
  • it’s now possible to script Unity from haxe, thanx
  • there’s plenty of new libs and macros  are just few
  • an interesting “twisted” point of view of “haxe as compiler target” bubbled up from the community in the person of
  • new version of OpenFL (even though it wasn’t presented at the conference it’s worth mentioning) 
  • NME is still alive! I thought NME became OpenFL but they’re just two different projects and now the haxe foundation is trying to merge the effort of the two teams
  • Date and String encoding issues are the next thing to fix in the TODO list of Haxe for the upcoming year
  • short lambdas!!! (no, just kidding)

here’s the link to the slides of the keynote


I had good time in Paris, got answers to all of my questions and I came back thinking Haxe is a viable option for a business, even if tools are still quite not there the power of the technology is worth enough to give it a shot.
If I had to set a TODO list for haxe it would look like this:

  • fix language problems on String encoding and Date object
  • focus on getting BIG PLAYERS involved, hire a CEO, move to the US. Exit the startupper garage and think big.
  • focus on tools:
    • intellij plugin experience should be near to java\as3
    • maven mojo is still behind
    • focus on conversion tools from * to Haxe (TiVo moved to haxe also because most of the “dirty job” was automated)
  • focus on community: encourage the creation of user groups in key locations

Last but not least, once again I was very impressed by the vibrant community that drives this technology, thank you all guys for your effort to make this technology grow better and better, and a special thanx the whole crew of SilexLabs to have organized the event.


Writing and Debugging a Maven Mojo

I set up my environment to develop a mojo and be able to debug it on intellij (version 13 at the time writing).

Here’s a very lean list of the things you need to do the job:

create the mojo project from org.apache.maven.archetypes:maven-archetype-mojo

  1. create your mojo entry point, it’s just a java class extending AbstractMojo and override execute() method
  2. comment your mojo class with a javadoc “@goal whatever” and “@phase whateverphase” . Those apparently useless comments are actually used to determine which goal and phase are associated with your mojo. You can ignore @phase and determine that later, but @goal (AFAIK) is mandatory
  3. create a test project that uses your brand new mojo as a plugin, specify an execution and a goal to be invoked (the same goal you wrote in the comment at step 3). At this point you can specify the phase you want your mojo to be executed into if you didn’t specify it in your comment.
  4. mvn install your mojo
  5. mvnDebug install (or specify the phase you need) your test project. mvnDebug will listen on port 8000 on localhost for incoming debug connections.
  6. in intellij, create a “Remote” run\debug configuration and change the settings as follows:
    1. transport: socket
    2. debugger mode: attach
    3. host: localhost
    4. port: 8000
  7. set a breakpoint on execute() and start debugging your mojo!


Good to knows:

  1. you can map a (private) variable of your mojo to a configuration parameter on your pom, just decorate your private variable with a javadoc comment such as @parameter alias=”whateverParam” (this will map <configuration><whatever> to the private String(?) decorated with that comment.
  2. you can map whatever class to manage configuration parameters of your mojo: just create a class and make it implement The properties of the class are resolved and populated by reflection (it’s a very useful if you need nested objects as configuration!!!)
  3. more to come… :)
Services, Tools, Tutorials

Twitter streaming APIs returning unauthorized message to cURL

Twitter recently published the new 1.1  Streaming APIs discontinuing the previous one, with this new APIs the authentication method changed and the user:pass pair is no more enough, now you need to:

  1. Create your app at
  2. Create the access token from your app’s details page (refresh after a while, it takes few seconds and the page doesn’t autorefresh)
  3. Go to the OAuth tool tab and insert the URI you want to query, the query parameters and the request type, then click the button to generate the OAuth signature for your request.
  4. The page is now showing the cURL command, copy and paste on your terminal and you’re done


Mac, Tutorials, Uncategorized

How to make a VM boot your OSX partition from Windows

Let’s say you own a mac and you installed Windows into a second partition of your hard drive via Boot Camp, and let’s say you need to access your alternate OS from its partition often but you won’t reboot everytime.
Several softwares enable you to do that using OSX as your main OS: Parallels, VMware Fusion, and VirtualBox are just the most known guys out there and all of them have options to boot a vm from a physical installation of Windows.

But what if you are in the opposite situation and you’re using Windows as the main OS and want to boot a vm from the OSX installed in the main partition of your hard drive?
Here’s how I made it possible with VMware Fusion 6 and VMware Player 6 for Windows.

OSX partition running on Winows 7 on VMware Player

NOTE: First of all I’ve to say this is a hack, not something I’d recommend for daily work, moreover remember that there’s your physical installation of OSX inside that vm so don’t mess anything up otherwise you’ll have to fix them the next time you’re booting to OSX.

These are the steps to follow to create a VM booting from your physical OSX installation:

  1. Boot your OSX and install VMware Fusion 6 (you don’t need the pro version for this) on OSX
  2. Create an empty OSX VM. Don’t use “Install OSX from recovery partition”, you don’t need a new installation, you’re going to make the VM boot your physical installation, so just create a custom VM. In my case I created it for Mavericks (10.9) and I really don’t know if it works with other versions of OSX.
  3. Open Terminal and type “diskutil list” in order to get the list of your partitions, you should get something like this.
    Terminal diskutil list
    in the picture you can see that OSX is installed in partition 2 of disk0 (it should be the same for you, if it’s not just take a note of your partition number and use that instead)
  4. Reboot to your Boot Camp Windows installation and install VMware Player 6 (again, you don’t need any pro version, moreover the player is free for non commercial usage)
  5. Open the blank OSX VM settings with VMware Player (Fusion should have created a .vmwarevm file that Windows sees as a folder, inside that folder there’s the actual VM file which has a .vmx extension)
  6. Remove the current Hard Disk from the settings (the blank VM should have a SATA virtual disk sized 40gb) and replace it with a physical disk, here’s the steps to follow:
    1. Click the “Add” button at the bottom of the hardware tab in Virtual Machine Settings dialog and click next
    2. Select Hard Disk from the hardware types list and click next
    3. Select IDE from the virtual disk type options and click next
    4. Select Use a physical disk (yes, for advanced users) and click next
    5. Select Use individual partitions and click next
    6. Now, remember the partition you listed on the terminal when you booted on Mac? Select the partition where your OSX is installed, the partition file system should be Apple HFS… and click next
    7. Choose a name to save that virtual disk configuration and click finish!
  7. You should now have a configuration similar to this

Now your VM is ready to boot your OSX partition! Just tweak your VM RAM and CPUs to make it usable.


  1. VMware tools won’t install, at least it won’t for me, so the drag n drop file feature won’t work
  2. Bootcamp drive will not be accessible from OSX VM because in use by the running Windows instance, same will happen for every volume you mounted in Windows, such as CD-rom and USB keys
  3. I don’t know if it matters in any way but I’ve installed a driver to enable writing HFS+ filesystem from Windows (otherwise it was read only). The driver I use is Paragon HFS for Windows.

Once more, this is a hack and I don’t suggest you to use this approach for daily or frequent usage.


I don’t assure you it works in every machine nor I tried in other machines, it works on mine which is a MBP 6,1 (mid 2010).

Mac, Tutorials

How to fool Bootcamp assistant and install Windows from an USB drive

I’m running Mavericks (10.9) on a mbp version 6,1 and Bootcamp assistant doesn’t let me create install windows from an USB drive.

Here’s how to fix it:

  1. Locate Boot Camp in /Applications/Utilities folder and backup it somewhere
  2. Right click the copy in Utilities folder and click on Show package contents.
  3. Locate Info.plist file and open it with a text editor
  4. Locate the tag “PreUSBBootSupportedModels” and change its name in “USBBootSupportedModels” (just remove “Pre”)
  5. Save that plist, it will require you to authenticate as administrator
  6. Now you should be fine if you’re running a system older than Mavericks.
    If you’re running Mavericks you need to replace existing app signature as an extra step, otherwise Bootcamp assistant will close unexpectedly:

    1. Open the terminal and type “sudo codesign -fs — /Applications/Utilities/Boot\ Camp\”
    2. The command will print out “Boot Camp replacing existing signature” then quit.
  7. Now your assistant should display a new “Create a Windows 7 install disk” option