Tech Drum - Nir's Tech blog

React + MobX - 101 Todo App for beginners - Part 1

2017-05-19T18:29:00.001+03:00

This walk-through-tutorial (yet another) is to guide you through the usage of the MobX library, while building a React application.

The application we'll build is a simple Todo App.

The post discusses the following topics:

What is MobX - A very short explanation about what MobX is.
Why do you need it? - Reasons to consider using MobX.
Why not Redux (another state management library)?
Code tutorial - Part 1 (out of 2)

What is MobX - https://mobx.js.org/

In short - MobX is a state management library.

In "long" - MobX is a JS library that allows you to define "observable" state (/model/your JS Objects) containing your App information.

The library gives you the power to derive any computed model that depends on observables automatically!
As MobX puts it:

Anything that can be derived from the application state, should be derived. Automatically

In aspect to React:
This gives you the power to mutate the state directly by reference from your components without calling React's setState, and triggering render only on the components that need to be re-rendered.

Pretty nifty.

For more about MobX: https://mobx.js.org/

Why do you need it?

First of all, no one said you should use it. There are plenty React based applications that work just fine without MobX.

However, you should consider MobX for the following reasons, that may give you some advantage.
For instance:

Simpler Components - Having a shared state in your App between several components can be cumbersome to share, especially if one component is deeply nested in another component that uses same data.
It would mean, that you'd need to pass to all the children of the top-most component that state, resulting many components that are on the way passing on that same state, but never using it.
Components that change state to other components, the state of your application distributed among many components, and other complications.
With MobX, you can specify for each component the exact props it should use.
Organized state model - Your application state with MobX is mostly organized in one or few objects that hold only the state of your application. That makes it easy to reason about the application's model.
Optimized App - render only components that need to render instead of

That sounds like I'm trying to "sell" you MobX.
I find it to be a good library for state management (not saying it's the only, check Redux too), despite the "magic" which I dislike in principal in software, and the awkward feeling I get when this reminds me of "two-way-data-binding" stuff (which the industry has a love-hate relationship since the ages of JavaFX, Flex, and probably even earlier libraries and frameworks).

It comes with a small cost of adding a library to your App, and learning how to use it.
If you have a small application, with a very simple model, you might not even need it.

Why not Redux?

In case you don't know Redux, as mentioned on their site is:
"A predictable state container for JavaScript apps."

In other words - it's a state managing library, like MobX is. But different.
The "what" is similar, the "how", a bit different.

So first of all - why not use it instead?
There's really no good answer for that, and IMO it's a matter of personal style and what you're comfortable with. It does seem to have less "magic" though.
(The "magic" i refer to are the observables in MobX - this is where the MobX fun happens).

Some say that MobX is easier to get started with as there's less code to write.
It supports several (optional) “stores” vs one store in Redux which can be annoying if you already have an existing App and you need to start consolidating all your state to a single place.
It conforms to a non-FP paradigm, where your state can be mutable (the observable objects in your state).

In any case, I would advise to try Redux before you make your decision.

Code walk-through

Lets get our hands dirty.
We're going to build the Todo App using MobX & React at last.

Step 0: Fork or clone the Git Repo
Go here and fork/clone it: https://github.com/nirgit/todoMobxTutorial

You will now have a skeleton application which is ready and set up, using ES6 with JSX & Webpack.
MobX is also included in the package.json, so you won't need to add it as a dependency.

Go to the project's directory and run from the console / shell:

> npm run start

Now go to http://localhost:8080

Your web page should look like this:

Step 1: Creating a plain React Todo App

Lets create our plain Todo application based on React only.

Stop Webpack watching your changes
Go to the project's directory and run from the console / shell:

> git checkout step1
> npm install
> npm run start

Re-open http://localhost:8080, you should now see this:

Great!

You now have a functional React Todo app.
You can open the app.js file and see all the code pretty much.
You won't find anything unusual.
Note how the entire state though is stored on the App component, so once we will refactor the code a little bit, we will have to pass in the todos as a prop to the child components, and probably stuff like a callback to toggle the todos "isDone" field, so we can use setState in order to make it work.

Go back to your shell and now, checkout the step1_2 branch.

> git checkout step1_2

Open the App.js file and take a look at the render method.
See the line?
...
<TodoList todos={this.state.todos} toggleDone={this.toggleDone.bind(this)} />
...

Notice how we pass in to the TodoList component the toggleDone callback, which is still defined on the App component. If you would decide to create Todo components, you'd probably pass on that callback into each of those components.
And so you will have a component which passes a function to a child (TodoList) which does nothing with that function but pass it on to its children, which affect a state that's found on its grand parent.
A bit Messy.
If you'd have this situation in a large scale application, not only it may be confusing, but it could be practically impossible to reason about the full state of your application at any given point in time.

Lets add MobX and see what happens.

Step 2: Adding MobX to our React App

MobX uses a very small set of core API.

@observable
The API's most significant and basis to all the MobX "magic" is the observable function / decoration (function if you decide not to use the decoration syntax from ES Next).
On this post we'll stick with the decoration as it feels (subjective) a cleaner way to declaratively state the fact a piece of data/object is being observed.

@observer
We have an "observable" data, now what?
We need someone to "observe" it, and react to the changes.
MobX being a library in its own right, does not provide an @observer for React Components "OOTB" ("out of the box").
In order to use such @observer we need to use the MobX-React NPM package.
Then we can "decorate" our React Components with an @observer decoration.

The reaction to the changes made to the observable object will result in calling the render method of the React component observing that object. Pretty cool.

Code example:

So every time you will change the bestMovies collection, the render of MovieList component will be triggered.

Stop your app from running if it is, go back to your shell and now, checkout the step2 branch.

> git checkout step2

and run the following to install missing missing NPM pacakges and re-run the app:

> npm install && npm run start

You shouldn't see any visual difference, but open the browser's Console and see what you got:

See how now you get a log print in the console when a component renders.

Try clicking a checkbox, you should get the following prints:

See how now you get only part of the prints?

Lets do a quick analysis:

App Component - renders because its render function is using the isDone flags of the Todos in order to render the Progress Bar.
ProgressBar Component - renders for obvious reasons.
TodoList Component - renders because it passes all of the properties of the Todo objects, including the isDone property when rendering.
It does that by using the ES6 spread operator (see in the code "{...t}")
The TodoLine Component - A new component created representing the Todo lines, as it makes it clearer to see MobX's benefit.
Notice how only the TodoLine Component whose line we changed rendered.
All the rest - stayed the same without getting re-rendered.

You can run the quick following check.
Go to the todoLine.js file and change the following line:
export default observer(TodoLine);

to this line:
export default TodoLine;

See how we omitted the MobX observer?
Now go back to the browser, and try to check the same checkbox as earlier.
Keep your console opened. You should get the following prints:

Hopefully you got something out of this post, as it should give you an idea of what MobX is by now. Stay tuned for Part 2 blog post that will discuss topics like:

Adding Actions and Action Handler
Adding a Provider component
Adding Containers

Or go explore more yourself on https://mobx.js.org/.

Enjoy,

Bit.ly Resolver - Chrome extension

2016-11-14T22:35:00.000+02:00

It's been a while since I last blogged about anything...

Something that's been bothering me for a long time since I've been on Twitter, are bit.ly links.

Naturally Bit.ly links got a serious boost in usage with Twitter's launch, and they serve a great tool of compacting links and embedding them beautifully inside Tweets.

However, many times, looking at those links, you can't help but wonder - "where will it take me if I click it? Am I going to get a worm or a virus on my laptop?"
Sometimes, people are just lazy to put any context telling you what this link is about, and so, they tweet or post a bit.ly link with their cat's photo.
(Usually it is not their cat's paw-n-shop ya' know...).

So being very lazy that I am, yet curious as a cat.. I decided to pick up the glove, and create my very own Chrome extension (sorry y'all other folks using other browsers), that shows you the REAL URL behind that bit.ly link you're gazing it right at this second, simply by hovering on it.

Welcome - Bit.ly Resolver Chrome Extension

You can simply click it, in order to install that extension on your browser.

GitHub link for those of you who are interested:

As a bit.ly :) : http://bit.ly/2fzMal8
Or simply as: https://nirgit.github.io/bitlyResolverCE/

See you in a bit.ly!

Typescript, React and Sass - All in one - Skeleton Project built with Webpack

2016-05-21T23:53:00.000+03:00

Just recently I had the need to set up a project that included

Typescript, React, Sass and building it with Webpack, and couldn't find any good up-to-date source on the web for a

skeleton project to base it on.

So I decided to create my own.

You can check it out (free of course) on my GitHub account:

https://github.com/nirgit/react-typescript-skel

Hubot Script for Image Search on Bing

2016-05-09T22:40:00.002+03:00

How to write a Hubot script that integrates with Bing in Javascript

In case you haven't heard of Slack, I recommend you check it out.
Slack is a Messaging App with an extremely cool edge of customization abilities.

One of those abilities allows you to install an App that plugs-in to Slack, called Hubot.
A Hubot is a Bot app, that can listen to your commands on Slack, and perform a task.

After installing your Hubot on your machine, you will notice it has a "scripts" directory.
You can use this directory to write your own custom scripts which the Hubot will execute!
Very cool!

The scripts can be written in CoffeeScript and in Javascript.
You can simply copy-paste the code below, but notice that it will not work, unless you get your own Bing API key.
You can easily get it for free here.
This is how the screen looks like at Bing after you will (create an account as needed and) login.

Be sure to copy the API Key that (highlighted in red) shows in the box,

and replace it with the 'key',

which equals to 'XXXX-....-XXXX' in the code below.


The expected result

Enjoy hacking & slacking!
Nir

The code

// bing.js

'use strict'

var querystring = require('querystring');
var http = require('https');

// replace the 'XXXXX...' string here with your own Bing API KEY
var key = 'XXXXX-XXXXX-XXXXX-XXXXX';

var HOST_NAME = 'bingapis.azure-api.net';
var DEFAULT_NUMBER_OF_IMGS = 20;
var SAFE = {
  low: 'Off',
  medium: 'Moderate',
  high: 'Strict'
};

var HTTP_REQUEST_HEADERS = {
  "Accept": "*/*",
  "Content-Type": "application/json",
  "Ocp-Apim-Subscription-Key": key
};

function getParams(query, count, offset, safe) {
  count = count || DEFAULT_NUMBER_OF_IMGS;
  count = Math.max(5, Math.min(50, count));
  offset = offset || Math.floor(Math.random() * 4);
  return {
    'hostname': HOST_NAME,
    'method': 'GET',
    'path': buildQueryParameters(query, count, offset, safe || SAFE.medium),
    'headers': HTTP_REQUEST_HEADERS
  };
}

function buildQueryParameters(query, count, offset, safey) {
  return '/api/v5/images/search?q=' + query + 
'&count=' + count + '&offset=' + offset + 
'&mkt=en-us&safeSearch=' + safey;
}

function getImagesFromBing(query, hubotCallback) {
  var body = [];
  var params = getParams(query);
  var req = http.request(params, function(res) {
    res.setEncoding('utf8');
    res.on('data', function (chunk) {
      body.push(chunk);
    });
    res.on('end', function () {
       var data = body.join('');
       var dataAsJson = JSON.parse(data);
       var values = dataAsJson.value;
       var imgs = values.map(function(val) {
         return val.contentUrl;
       });
       hubotCallback(imgs);
    });
  });
  req.end();
}

module.exports = function(robot) {
    robot.hear(/bingme (.*)/i, function(res) {
        var photoname = res.match[1];
        res.reply("Looking for a photo of \"" + photoname + "\" on Bing!");

        var escapedQuery = querystring.escape(photoname);
        getImagesFromBing(escapedQuery, function(imgs) {
          var randomPhotoIndex = Math.floor(Math.random() * imgs.length);
          res.send(imgs[randomPhotoIndex]);
        });
    });
}

Spaceship X - Game Launch on Android Play

2016-01-17T13:34:00.000+02:00

Spaceship X - Timeless Hero

A retro flavoured Spaceship shooter saving the Galaxy!

Exciting!
I have released my first Game App to Google Play!

It is free to download:
https://play.google.com/store/apps/details?id=nm.ibex.spaceshipx

The game's website:
http://leapingibex.wix.com/spaceshipx

Have fun!

Simple Webapp example using Flux with React

2015-04-18T23:34:00.000+03:00

If you've been following the latest Front-End news for Web for the past year,
you have probably seen the huge buzz around ReactJS.

Just in case you haven't, you can visit ReactJS on the Facebook Github's page at: https://facebook.github.io/react/ or just Google it and read about it.

So for those of you that do know what React is all about, you may have also heard about Flux.
If you haven't :) I recommend you to read about it a bit
here as well http://facebook.github.io/flux/docs/overview.html

If I have to try and sum it up on one leg, I'd say that Flux is an application architecture for building
big web-apps on the front-end that scale. - Well, that's pretty vague :)

A main concept regarding this architecture is about a Uni-directional flow where an "Action"
(a Application Event) is triggered by the View part (Your components, which are shown the users),
using a "Dispatcher" (Some kind of an Event Hub) which propagates the Actions
on to the "Stores" (Your application's model), which hold the state (data) of your application,
perform the necessary update and logic, and updates the View back using listeners.

This illustration might help understanding the Flux flow a little better:

Why is Flux a good idea? - There are several reasons, but I will mention only 2 which I think
are the most important.

1. Simple Application Architecture - You can show this diagram to someone who never
heard of Flux before, and explain it in 2 minutes.

2. Scalable - Flux lets you scale. Meaning, it's relatively easy to add new features to
your application, debug it, and keeping it performant.

Why?
There's a really good talk about it by Facebook which is worth watching:

After all that being said, I really wanted to do some basic implementation of Flux myself,
to "feel" how it works. And so I created a very small Repository on Github that implements
Flux which you are welcome to look at and use.

The example code

The application built on top of that is a classic Todo App: https://github.com/nirgit/Flux1

The code uses several 3rd party libraries such as RequireJS and React Templates but even if you are not familiar with RequireJS, or with AMD, my guess is you will still be able to understand how
it works.
React Templates is an amazing 3rd party library that helps you implement the "render" method
of React Components in an HTML like syntax. Totally cool.

Good luck!

Grunt - Create your custom local Grunt plugin

2014-01-25T23:42:00.001+02:00

This post describes how you can write your own Grunt Plugin in Javascript and install it locally,
in order to use it on your own (Grunt) project build file.

If you don't know what Grunt is then to explain it on one leg -
"Grunt is a pluggable (JavaScript) task runner", which can be used to build JavaScript projects.

Such typical build of a Javascript project may contain a Linting task, minification task, and so on...

So, you can read more about Grunt if you want to get a better understanding.

And now, to the recipe!
Ingredients:
1 NPM installed on your machine
1 GIT installed on your machine
1 Skill writing a tiny bit of Javascript
A zest of patience

Instructions:
1. First thing would be to install a Grunt plugin that is used for templates scaffolding.
In order to do that, you need to run the following in your shell:

$ npm install -g grunt-init

2. Clone a GIT repository which is going to be used as your template for creating your glorious
Grunt Plugin. (https://github.com/gruntjs/grunt-init-gruntplugin)
So, run the following in your shell:

$ git clone https://github.com/gruntjs/grunt-init-gruntplugin.git ~/.grunt-init/gruntplugin

3. Create an empty directory where you want to place your Plugin like "my-custom-plugin", and cd into it.

$ mkdir my-custom-plugin
$ cd my-custom-plugin

Then run the following in your shell:

$ grunt-init gruntplugin

4. You should now be prompted with a serie of questions in the shell, in order to create your plugin.
You should be seeing something like this:

Please answer the following:

[?] Project name (grunt-my-custom-plugin)

[?] Description (The best Grunt plugin ever.) the best custom plugin ever!

[?] Version (0.1.0)

[?] Project git repository (ssh://<Your GIT remote Repository URL>)

[?] Project homepage (none)

[?] Project issues tracker (none)

[?] Licenses (MIT)

[?] Author name (nirgit) Nir M

[?] Author email (getnirm@gmail.com)

[?] Author url (none) tech-drum.blogspot.com

[?] What versions of grunt does it require? (~0.4.2)

[?] What versions of node does it run on? (>= 0.8.0)

[?] Do you need to make any changes to the above before continuing? (y/N) N



Writing .gitignore...OK

Writing .jshintrc...OK

Writing Gruntfile.js...OK

Writing README.md...OK

Writing tasks/my_custom_plugin.js...OK

Writing test/expected/custom_options...OK

Writing test/expected/default_options...OK

Writing test/fixtures/123...OK

Writing test/fixtures/testing...OK

Writing test/my_custom_plugin_test.js...OK

Writing LICENSE-MIT...OK

Writing package.json...OK



Initialized from template "gruntplugin".

You should now install project dependencies with npm install. After that, you

may execute project tasks with grunt. For more information about installing

and configuring Grunt, please see the Getting Started guide:



http://gruntjs.com/getting-started



Done, without errors.

5. Now you should have your directory containing a Grunt Plugin template.
Open the file you have inside the "tasks" directory in order to edit it.

6. The file should look as follows:

7. Just in order to get started, lets strip the file and change it to contain the following:

/*
 * grunt-my-custom-plugin
 * 
 *
 * Copyright (c) 2014 Nir M
 * Licensed under the MIT license.
 */

'use strict';

module.exports = function(grunt) {

 grunt.file.defaultEncoding = 'utf8';

 // Please see the Grunt documentation for more information regarding task
 // creation: http://gruntjs.com/creating-tasks

 grunt.registerTask('my_custom_plugin', function() {
  grunt.log.writeln('Hello my great Grunt Plugin!') ;
 });
};

The my_custom_plugin shown in bold above, is the name of your task in the Grunt build, that
you'll execute at the end.

Lets change the Gruntfile.js in the root directory of the Plugin so tests won't execute when
we will run "grunt" on the plugin's source. Otherwise the build would fail.
So now the Gruntfile.js last line should look like:

grunt.registerTask('default', ['jshint']);

8. Go back to the root directory of your Grunt Plugin and run the following:


$ npm install


$ grunt


Running "jshint:all" (jshint) task

>> 3 files lint free.



Done, without errors.

9. Almost done.
Now go to your own project where you want to use your plugin and add the following line to the
Gruntfile.js of your project:

grunt.loadNpmTasks('grunt-my-custom-plugin');

This will load your Grunt plugin task to your Grunt's project.

10. Next step would be to install the plugin locally in the node modules of your Proect.
You should now run in the root directory of your Project (where you want to use your plugin) the following:

$ npm install /<PATH_TO_YOUR_PLUGIN>/my-custom-plugin

11. You should now be able to execute:

$ grunt my_custom_plugin

And see:

Running "my_custom_plugin" task

Hello my great Grunt Plugin!



Done, without errors.

That's all folks.
Hope this was helpful to get you started with Grunt Plugins.
Don't forget to publish it (npm publish) afterwards to the rest of the Node community if you think it may be helpful to others as well.

Check out the official guide for creating Grunt plugins at:
http://gruntjs.com/creating-plugins

Good luck!

Lottery for winning a copy of the "Android NDK Cookbook" is now opened

2013-06-16T07:16:00.000+03:00

In continuation to last week's post for winning a free copy of the eBook "Android NDK Cookbook",
the lottery starts today!

3 Lucky people will be given a free copy of the "Android NDK Cookbook" sponsored by "Packt Publishing".

Description of the book

Android Native Development Kit Cookbook will help you understand the development, building, and debugging of your native Android applications. You will discover and learn JNI programming and essential NDK APIs such as OpenGL ES, and the native application API. You will then explore the process of porting existing libraries and software to NDK. By the end of this book you will be able to build your own apps in NDK apps.

Check it out on Packt Publishing: http://www.packtpub.com/android-native-development-kit-cookbook/book

How to participate?

Simply send an email by clicking here or by sending it to
containing a subject line "Android NDK Cookbook lottery".

Deadline

The contest will close on 30th June 2013. Winners will be contacted by email, so be sure to use

your real email address!

Good luck !

Win a free eBook copy of "Android NDK Cookbook"

2013-06-08T23:12:00.000+03:00

Are you an Android developer or interested in Android development?
This might interest you!

On the 16th of June 2013 I will conduct a lottery on the blog, to win a free eBook copy of "Android NDK Cookbook".

The lottery will last for 2 weeks (until June 30th) where you will be able to participate to win a free copy of the book.

Description of the book:

"Android Native Development Kit Cookbook" will help you understand the development, building, and debugging of your native Android applications. You will discover and learn JNI programming and essential NDK APIs such as OpenGL ES, and the native application API. You will then explore the process of porting existing libraries and software to NDK. By the end of this book you will be able to build your own apps in NDK apps.

Further details of the book can be found here: http://www.packtpub.com/android-native-development-kit-cookbook/book

Stay tuned for the 16th of June!

* The copy of the book is sponsored thanks to "Packt Publishing".

Javascript Closure Functions Memory Model - How does it work?

2013-05-26T01:04:00.001+03:00

Hey everyone,
For those of you who are writing code in Javascript or wish to do so, it is essential to understand
the concept of closures, and how they work.

I must say that when I started looking into it, it was somewhat difficult to find proper material
on the web, to get a good grasp of how things work. So this post's idea is to try and shed some
light on this matter. I don't guarantee that this will make you understand everything, but do hope
it will help in some way.

*Note: I could have some mistakes in this post of course, and would be very happy if you send me
any corrections or comment as this is suppose to help people, and show the power of Javascript closures.
Everything that's written in this post is according to my understanding of how things work.
So regard this writing with care. I tried to do the best I could when I wrote this post.

The post topics will contain 2 parts:
1. What is a Closure?
2. How does the memory model look like.

1. What is a Closure?

"... is a function or reference to a function together with a referencing environment—a table storing a reference to each of the non-local variables (also called free variables) of that function. A closure— unlike a plain function pointer—allows a function to access those non-local variables even when invoked outside of its immediate lexical scope." - From Wikipedia.

A simple example to such Closure is a counter.
Consider the following script for example:

function createCounter() {
var counter = 0 ;
return function() {
counter++ ;
return counter ;
}
}

var counter = createCounter() ;
counter() ; // returns 1
counter() ; // returns 2
var counter2 = createCounter() ;
counter2() ; // returns 1
counter() ; // returns 3

How does this work?
The createCounter function being executed creates a new Execution Scope, which contains references to a variable named counter and returns an anonymous function.

So how does that function know about counter when it's executed?
In Javascript any function, has some kind of property called a "Scope Chain", which defines the scopes the function is bounded to. When we define a function in Javascript, the "definition scope" is such scope that is stored in the function's "Scope chain". So when we define and return the anonymous function in createCounter that anonymous function is binded to a scope where it was defined.
Thus, when the function is being executed by calling "counter()" a new "execution scope" is being created and added to the function's scope chain. So when the function needs to look up counter it looks up it's "scope-chain", and finds it eventually on the "definition scope" of the function.

Another thing to remember is that every time you run a function you run it inside a "context".

What is a context?
A context is the object the function is executed on. It is recognized with the this keyword.
It is defined when we write the following code in Javascript for example:

// context here equals to obj1 (this === obj1)
obj1.sayHello() ;

// context here equals to the global object which in case of a browser, is *window (this === window)

sayHello() ;

* It might be equal to undefined (this === undefined) in case we're running in 'strict mode'.

You can check more about it at MDN - Function Context.

2. How does the memory model look like?

I think it's important to understand how the memory model looks like, graphically, to get a better

notion of how things work. Even though you could handle without it, I find illustrations very

helpful understanding how something works.

Simple example

When you define a regular function, like:

function foo(number) {
[ function_body ]
}

We get something of the following in memory:

If we execute foo(3), we will get something of the following in memory:

So when foo(3) is executed, a new "Activation object" is created.
Passing to it the function's parameters and arguments array, and adding it to the scope chain of foo(3).
So the next time foo will be looking up for the "num" parameter, it will be looking it up the
scope chain starting from the closest(last) scope that is relevant to the execution, which in this
case is of course the "Activation". If it won't find num there, it will continue to the next scope in the
chain, until it finds it.

Closure example

Lets take the Closure example we referred to earlier - the counter function and see how it

would look like in memory.

Quick reminder, our counter function looks like this:

function createCounter() {
var counter = 0 ;
return function() {
counter++ ;
return counter ;
}
}

This maps to a memory model which looks (somewhat) like this:

You might wonder why the Closure's scope chain also refers to the Global Object.
The reason is that when we create a closure, it copies the scope chain of the execution context scope chain which in this case belongs to createCounter().
What makes the Closure a closure is the interesting side affect in Javascript, that instead of the Activation Object being destroyed after createCounter execution, it remains alive, because there is a reference to it, from another function - the closure.

Now, lets create such counter by executing the following:

var myCounter = createCounter(); [1]
myCounter() ; [2]

So on line [1] we create myCounter which is a reference to the closure on the above illustration.
When we execute line [2], we get 1 as an answer, and the second time we will get 2.
How it looks in the memory is shown in the next illustration:

When we execute myCounter which is our closure in this case, we are incrementing the counter variable, but in order to do so, the variable needs to be reached somehow.

This is where the "scope chain" takes its place. The first "environment" where the variable is going to be looked up is at the top of the scope chain, in our case - the "Activation Object" of myCounter.

Since the variable is not an inner variable, nor a parameter, the look-up for the variable continues, and moves on to the next scope in the chain which is the "Activation Object" of createCounter ! There it is found, read and assigned. (As counter++ is actually counter = counter + 1 ).

Note that every time you call createCounter a new Activation Object is created with a new counter variable which equals to 0. This is how you can create as many separate counters as you like, without them affecting each other.

I hope this helped you in some way to understand the memory model of functions and closures a little better. Any comments / suggestions and complaints are most welcome.

Enjoy "closuring".

GWT Chrome extension with JSONP Server communication

2013-03-08T15:37:00.002+02:00

I thought this post would be a good idea for people who want to know how to make an 'end-to-end'
GWT Chrome extensions, with a connection to a server of their own.

While this demonstrates specifically how to enable to communication from a Chrome extension, there is
no difference in code if you wish to deploy your client code else where (not on Chrome).
Many web applications choose to deploy their Server code & Client code on the same application server, like JBoss or Tomcat.

As you know in GWT there are several ways to communicate with a server.
One of them is RPC for instance, which gives you the ability to invoke methods on a Java interface,
not having to deal with anything but Java code. Which is cool, as it makes a very smooth transition from
the client side code to the server side code.

However, when we want to implement this in a Chrome extension things get a bit trickier.
The reason is that you'd have to separate your server module from your Chrome extension module
(as we can't deploy Server side classes to Chrome - it runs only JavaScript),
and would need a shared model between the two in order to communicate.
It's not hard to do at all, it's only a longer example to make.
(In Eclipse, if you create a new "Web Application Project" using Google's plugin, you will have the client & server code in the same project, with a "shared" directory which serves a model bridge between the two).

Another option that exists, is using JSONP communication to the server.
In our case - this makes it a lot simpler.
We will expose some REST API on a Server we'll implement, for getting images, and send a JSONP request from the QuickPik extension to retrieve those images. Obviously, it can be anything else you want it to be in your application.

TO THE CODE!!!

The Server

In order to create a REST service and expose it, we will use the Jersey library which is an implementation for
building RESTful web services. It's very simple.

The following QuickpikService class, is our REST service:

package quickpik.server.web;

import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.Date;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.MediaType;

import org.codehaus.jettison.json.JSONException;
import org.codehaus.jettison.json.JSONObject;

import com.sun.jersey.api.json.JSONWithPadding;

@Path("/quickpik")
public class QuickPikService {

private final static int BUFFER_SIZE_IN_BYTES = 1024;
private final static String FLICKR_API = "http://api.flickr.com/services/feeds/photos_public.gne?format=json&tagmode=all&tags=" ;

@GET
@Path("searchPhotos")
@Produces({ "application/x-javascript", MediaType.APPLICATION_JSON})
public JSONWithPadding getPhotos(@QueryParam("searchExp") String searchExp,
@QueryParam("callback") String callback) {
// "log" the call
System.out.println("[" + new Date() + "] searching for: " + searchExp) ;
URL flickrUrl = getSearchURL(searchExp) ;
JSONObject data = tryToGetSearchResult(flickrUrl);
return new JSONWithPadding(data, callback);
}

private URL getSearchURL(String searchExp) {
String composedURL = FLICKR_API + searchExp;
try {
return new URL(composedURL);
} catch (MalformedURLException e) {
e.printStackTrace();
throw new RuntimeException("URL composition failed. Please check your URL: " + composedURL, e) ;
}
}

private JSONObject tryToGetSearchResult(URL flickrUrl) {
try {
return getSearchResult(flickrUrl) ;
} catch (IOException | JSONException e) {
e.printStackTrace();
throw new RuntimeException("Failed searching.", e) ;
}
}

private JSONObject getSearchResult(URL flickrUrl) throws IOException, JSONException {
InputStream is = flickrUrl.openStream() ;
String result = readDataFromStream(is);
// Flickr specific string prefix for the JSON feed.
if(result.indexOf("jsonFlickrFeed(") >= 0) {
result = result.substring("jsonFlickrFeed(".length(), result.length()-1) ;
return new JSONObject(result) ;
} else {
return new JSONObject("{}") ;
}
}

private String readDataFromStream(InputStream is) throws IOException {
StringBuilder data = new StringBuilder() ;
byte[] buffer = new byte[BUFFER_SIZE_IN_BYTES] ;
int bytesRead = is.read(buffer) ;
while(bytesRead != -1) {
data.append(new String(buffer, 0, bytesRead)) ;
bytesRead = is.read(buffer) ;
}
is.close() ;
return data.toString() ;
}
}

That's it. This our REST service, and we are exposing our API by using the @Path annotations
on the class and on the public method getPhotos. There are also other annotations such as the
@GET annotation and the @Produces annotation which state that the method is invoked on
an HTTP GET, and returns (@Produces annotation) a JSON (with Padding eventually = JSONP) object.

As you can see, in the class, we are using a Flickr API to get our images data from.

Now all that's left in order to make this service work, is to define the Jersey servlet in the web.xml file,
which is done this way:

<web-app>
...

<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>quickpik.server.web</param-value>
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

...
</web-app>

After doing that, we're able to refer to our REST service by using a URL in the browser:
http://localhost:8080/<web-app-name>/rest/quickpik/searchPhotos?searchExp=<our-search-term>

In order to verify this worked indeed and to get a better understanding of how the strucutre of our JSON result looks like, before even writing code to the GWT Chrome extension client,
i did a small test using jQuery, to see whether this worked. - You can find it in the GitHub repository.
What I did in a nutshell, was to call the REST API:
$.getJSON('http://localhost:8080/qpserver/rest/quickpik/searchPhotos?searchExp=hello&callback=?', jsonCB);

So I executed an AJAX call to search for "hello", and passed a callback - jsonCB to process the result.
jsonCB looks like this:

Note the highlighted text! - This is how we get the URL information of the photo items being sent back to us from the server.
So now we know that inside "result" which is a JSON object, resides an array of objects, that contain each
an object called media with a field called m.
You can discover this by simply debugging the returned values from the Server in the browser.

So now, we can finally add some code to our GWT Client.

Client side - GWT Chrome extension

In the previous posts of QuickPik, you might have noticed, that in order to add an additional ImageDataSource, all you need is to implement an Interface IImagesDataSource and add that ImageDataSource to the DataSource enum.
It's much easier than it sounds.
So we need to do the following:
1. Write an ImageDataSource that "talks" to our Server.
2. Edit the manifest.json file to allow communication to our server in order to comply with the
"Content Security Policy" of Chrome's extensions.

IImageDataSource implementation - ServerDS

public class ServerDS implements IImagesDataSource {

private final static String QUICKPIK_SERVER_URL =
"http://localhost:8080/qpserver/rest/quickpik/searchPhotos?searchExp=" ;

...

@Override
public void getImages(final String searchExpression, final FilterLevel filter,
final Callback<PhotosSearchResult, Void> callback) {
String url = QUICKPIK_SERVER_URL + searchExpression ;
JsonpRequestBuilder jsonp = new JsonpRequestBuilder();
jsonp.requestObject(url, new AsyncCallback<ServerResult>() {
public void onFailure(Throwable throwable) {
// do some error handling..
}

public void onSuccess(ServerResult result) {
handleLoadedImagesResult(searchExpression, filter, result, callback) ;
}
});
}

private void handleLoadedImagesResult(String searchExpression, FilterLevel filter, ServerResult result,
Callback<PhotosSearchResult, Void> callback) {
JsArray<ServerImageItem> imageItems = result.getItems();
LinkedList<Photo> photos = collectImages(imageItems);
callback.onSuccess(new PhotosSearchResult(searchExpression, filter, photos, 0, false)) ;
}

private LinkedList<Photo> collectImages(JsArray<ServerImageItem> imageItems) {
LinkedList<Photo> photos = new LinkedList<Photo>();
for (int i = 0; i < imageItems.length(); i++) {
ServerImageItem imageItem = imageItems.get(i);
Photo p = new Photo(i+"", imageItem.getImageURL(), imageItem.getImageURL()) ;
photos.add(p) ;
}
return photos;
}
}

I'll try to explain the code very shortly:
1. At the top of the class you can locate the URL to the server we will be using to get the images from.
2. getImages method which must be implemented is passed a searchExpression a filter and
a callback. We will ignore the filter to make things simpler.
GWT offers a class called JsonpRequestBuilder which allows us to invoke an asynchrounous
call to the server, and passing a callback to deal with the result of the invocation.
3. If the call was successful, we have to handle the result somehow. We do that by calling a handle method.
4. In the handleLoadedImagesResult method, we got an object called ServerResult.
ServerResult is a custom object created especially for this operation. It is a wrapper to
a JavaScriptObject, that gives access to the result.items object array. (Remember from the jQuery test?)

This is how ServerResult looks like:

public class ServerResult extends JavaScriptObject {

protected ServerResult() {
}

public final native JsArray<ServerImageItem> getItems() /*-{
return this.items ;
}-*/;
}

The native getItems method, is a convention of GWT to write JavaScript code to the underlying JavaScriptObject that the Java object wraps. So when you invoke getItems, behind the scenes the
JavaScript code "return this.items" is executed, returning the JavaScript items Array.

I also mapped the objects in this array to a Java object in the same way I did with ServerResult.
Following the same idea, ServerImageItem looks like this:

public class ServerImageItem extends JavaScriptObject {

protected ServerImageItem() {
}

public final native String getImageURL() /*-{
return this.media.m ;
}-*/;
}

Here we use getImageURL method to return the (JavaScript) object's media.m property.

(This is exactly the same structure that was referred to when testing with jQuery above).

So after this long explanation, all we do in the "handle" method, is basically gathering all of our
images URLs, creating a Photo list, like expected in the callback passed to us in the getImages method
invocation and invoking the callback, passing it an expected PhotoSearchResult object containing
our Photos.

5. Now we must add our ServerDS to the DataSource enum, so it will be included as a data source
when we run a search.
We do that simply by adding the (bolded) line below:

public enum DataSource {

// add here your data sources
FLICKR(false, new FlickrDS()),
QUICKPIK_SERVER(true, new ServerDS())
;
....
}

Notice how I intentionally turned off FLICKR Data Source, setting its isEnabled flag to false.

6. Last thing that needs to be done, is to enable our Chrome extension to make calls to our server by
editing the manifest.json file, adding the following line to it:

{
....
// A relaxed policy definition which allows script resources to be loaded from localhost:8080 over HTTP
"content_security_policy": "script-src 'self' http://localhost:8080; object-src 'self'"
}

That's all folks, all you need to do now, is build the Server (I did it with Gradle in this project), compile
your GWT client, deploy it on Chrome and watch it work.

You can access all the code on GitHub, and download it.

Code on GitHub
All of the project's code can be found on GitHub at: https://github.com/nirgit/Quickpik-with-server

RPM example - Application packaging

2013-01-30T15:41:00.003+02:00

This post is about something quite different than the others.
It concerns packaging your software as an RPM file making it ready for delivery.
If you have never used RPM before and/or you're not an experienced Linux user, this post is intended for you.

I'm far from being an expert in this area, and I would guess there is probably a better way of achieving the goal I want to show here. Please share your thoughts and experience if you have any.

I assume you already heard of RPM, and understand it's benefits and so on.
This post is not to convince you to use RPM, only how to create such RPM file which you could use.

What's in this example?
I created a "Hello World" Java application, and using Ant, I compile it, and Jar it.
This application could be anything you want - this is just a "place-holder" for you, to replace with
your real stuff.

So, after having an RPM file, we'll be able to install it to the system and remove it afterwards.
The path which the program will be installed into will contain the "Hello World" application Jar.

RPM Structure quick overview

As you probably know by now, RPM files are created using a ".spec" file.
This file tells the rpmbuild tool which we will use how to create the RPM package.
The .spec file contains several sections:

Headers - Headers of the spec file contain stuff like a Summary of what the package is,
Name of the package, Version & Release information, License & Package and an
attribute named BuildRoot. BuildRoot is important - it specifies the location
of where your package will be temporarily installed.
What I mean by temporarily, we'll get to later.
%description step - This is where you can type just about anything you want describing
your awesome application.
%prep step - In the step, preparing your Source files to be built (using Ant in our example).
"What's to prepare?" - you ask? - Well, in order to build an RPM package, you must provide
RPM a .tar file or a zipped file of some kind to it's SOURCES directory, (I'll explain the
structure of RPM further down), so what you need to do in this step is to extract your
archived sources.
%build step - This is where the actual build of your application happens. In our case, we'll
execute ant on our build.xml file, that compiles and Jars the application - real simple.
%install step - This is the step that happens after the %build step, and will determine how
your installed package will look like. We will copy the necessary binaries (Jar in our case) to a relevant directory.
%files section - This section determines which files from the %install step to pack, and with what access rights.
%clean section - This section runs after packaging was done, and cleans up all the leftovers from your build and your install steps. It's important to delete all the old files, especially if you build several RPM packages, you don't want to have files of another RPM build process in your way.

Okay. I know this still doesn't tell you how to do stuff, but this introduction is quite important in my opinion.

So take a deep breathe one last time, and we'll go over the rpmbuild directory structure and understand the steps we need to take in order to accomplish our mission.

"rpmbuild" Directory structure

An important part of the way RPM works, is its directory structure where work is being done.

You should be able to locate your rpmbuild directory on your machine, which usually should

show under your home directory.

The rpmbuild directory contains the following sub-directories:

BUILD - This is the directory where your sources will be built, and where the artifacts of your build will be located. The %build step, reads from the directory and writes to it.
BUILDROOT - This is the directory where you will "temporarily" install your binaries to.
You can think of it as the "INSTALL" directory. After the build step, the BUILDROOT
serves as a directory to contain the files in a given directory structure. Those files in this
specified directory structure will be installed afterwards using RPM.
To clarify: If you place under BUILDROOT a directory called my-app-123 then on the
real install of the RPM package, your package will be installed under /my-app-123.
This step reads from the BUILD directory and writes to the BUILDROOT directory.
RPMS - This is the directory that will contain your RPM package in the end.
SOURCES - This is the directory where you should place your archived sources.
SPECS - This is the directory where you should place your .spec file which will create
the RPM package.
SRPMS - This is a directory where source RPMs are created and stored.

Each of those directories, can be referenced in the .spec file using RPM variables.

Variables

%_specdir	~/rpmbuild/SPECS
%_sourcedir	~/rpmbuild/SOURCES
%_builddir	~/rpmbuild/BUILD
%_buildrootdir	~/rpmbuild/BUILDROOT
%_rpmdir	~/rpmbuild/RPMS
%_srcrpmdir	~/rpmbuild/SRPMS

Now that we finished our overview. Let's go over our 8 steps to create a packaged application with RPM.

Create an application (write source code) - in our case, a simple "Hello World" application.
Create the build file for the application - Ant's build.xml file in our case.
Create an archive from our application's sources.
Place the archive (tar) at ~/rpmbuild/SOURCES directory.
Copy the .spec file into the ~/rpmbuild/SPECS directory.
Create the RPM package using: rpmbuild -ba <spec_file>
Install the package.
Uninstall the package.

Now, lets go a bit into details:

You can download the pre-made application entirely from GitHub: rpm-example-project.zip
in order to skip steps 1,2 and 3.
(You can also access the repository - http://github.com/nirgit/RPM-Project-Example).
After downloading the zipped application, and extracting it somewhere on your machine,
you can take a closer look into its hierarchy. You will find under the Application directory,
a directory called src which contains the sources of our application, and you will find
the build.xml file which builds the application.
You will also find 2 other files - the application.tar containing the application sources,
and the project.spec file.
You need now to copy the .spec file into the ~/rpmbuild/SPECS directory, and the
application.tar file into the ~/rpmbuild/SOURCES directory.
In order to create the package now, you're required to run the rpmbuild tool, by
executing: > rpmbuild -ba ~/rpmbuild/SPECS/project.spec
Since I use Ubuntu, I also use alien to install the package. In case you're running on
a Linux flavor such as CentOS, I think you can simply run the regular RPM install.
With alien: > sudo alien -i ~/rpmbuild/RPMS/i386/Example-RPM-Project-1.0-1.i386.rpm
Without: > rpm -i ~/rpmbuild/RPMS/i386/Example-RPM-Project-1.0-1.i386.rpm
After the install you should be able to find the package installed under the root:
/Example-RPM-Project-1.0-1
Under it, you can find the app.jar.
You can uninstall the package using RPM's command: rpm -e <package_name>
or (in my case using Ubuntu): sudo dpkg --remove example-rpm-project

The SPEC file

This is the SPEC file associated with the RPM package.
I hope it will serve you as a good starting point for your own SPEC file.

################################################################

# This is an example of a simple RPM spec file.

################################################################

Summary: An RPM Spec example

Name: Example-RPM-Project

Version: 1.0

Release: 1

License: Apache 2.0

Group: Applications/Sample

URL: http://www.mycompany.com

Packager: Nir Moav <getnirm@gmail.com>

BuildRoot: %{_buildrootdir}/%{name}-%{version}-%{release}

%description

This is a sample SPEC file for the RPM project

demonstrating how to build, package, install(deploy)

%prep

# extract the tar file containing all the sources, to the build directory.

tar -xvf %{_sourcedir}/*.tar -C %{_builddir}

%build

echo "Building the project..."

cd Application

# running ant to build the java project (could be make/maven/gradle or anything else).

ant

%install

# This is the hierarchy which is going to be inside the package (RPM/Deb) eventually.

echo "Install phase..."

mkdir -p %{buildroot}/%{name}-%{version}-%{release}

cp -R %{_builddir}/Application/output/jars/* %{buildroot}/%{name}-%{version}-%{release}

%post

#This runs post the install - maybe you want to execute the application already then

echo "Post install.."

%postun

#this runs after the uninstall

echo "Post Uninstall..."

%files

# tells which files to contain in the package and with what access rights

# the triplet contains of (<file mode>, <user>, <group>). Make the necessary changes.

%defattr(-,nir,nir)

%clean

# Clean up! Must run this! after build and install steps execute, this will make

# sure that the directories are remained clean, so in case you're building another

# package, you don't want to pack the previous build's artifacts.

rm -rf %{_builddir}/*

rm -rf %{_buildrootdir}/*

That's all folks!

I hope you managed to read through this long post, and found it useful.

Enjoy,
Nir

SpacePong - version 2 - HTML5 Game with GWT

2012-12-05T23:23:00.002+02:00

Hey,
This is just a small update of the game, to make it a bit more fun to play actually.
So now you can pick different levels to play and have something a bit more challenging.

The source code has changed of course, and you can find it like before on GitHub:
https://github.com/nirgit/GwtPong/tree/space_pong_ver_2_0_0

Space Pong

Enjoy!

GWT HTML5 Game Example - Pong

2012-11-28T01:32:00.000+02:00

Hi everyone,

This post is intended to present a very simple example of a game, made with the HTML5 support of GWT.
The game uses only GWT, without any other 3rd party libraries such as PlayN which works with GWT and is rather famous and meant for creating games based on HTML5.
Take a look at PlayN's website: http://code.google.com/p/playn/

GWT provides an API to the underlying HTML5 Canvas, and lets you use it to create
custom graphics.

This example shows the game of Pong. Though the game might be a little buggy, it nevertheless makes use of the fundamental HTML5 Canvas features, such as drawing simple geometric shapes, such as rectangles, circles, gradients and with those elements creating a very simple and compact code for a game.

You can find all the code on GitHub for you to clone: https://github.com/nirgit/GwtPong

Click the screenshot to play:

Have fun playing!

Gradle - Opinion, experience and examples

2012-11-11T17:41:00.000+02:00

Opinion and Experience

I had quite a short experience with Gradle, but the impression it left is of an incredible tool.

I don't want to diss any other build tools out there like Ant or Maven, they're great,
and if you're a real savvy, you'll get the job done probably pretty fast.
I generally believe that one needs to use the right tool for the right task, but I'd dare say
that whatever you're doing with Maven or Ant you could probably do better with Gradle -
it is simpler, faster, shorter to write any build file, much more concise yet very powerful.

I have also my experience with Ant for years and with Maven, and I can tell you that I appreciate
Ant very much as a build tool. It does exactly what you expect it to do.
When you read a build.xml file, you'd hardly find something you don't understand.
It's just clear how things work, and what is expected at the end.
The problem is, you need to write so much "build code" in order to get your job done, especially
in a complex system, when you have includes of other extension.xml files you rely on and so on.
What about dependency resolution? - OK, so you could use Ivy, but that's just for dependency resolution.
It's not a "full" build tool in the sense of Maven that comes with creating your packages out of the box, deploying it to your tomcat and distributing it to your Repository.

Yes, Maven can be great but I must say that my 'like' metric towards it is not so stable.
It is too complicated to get simple stuff done... compiling GWT? - Get a plugin!
In Ant, it's really simple to compile a GWT project + you get the example from the GWT website.
In Gradle you can simply execute Ant Tasks, so no plugin extra work needed.
Want to include / exclude resources from your WAR file... why does it have to be complicated?
Dependency management and resolution is awesome, distributing your artifacts into a repository
is great, and fairly easy to do.

However, despite the good stuff of these build tools, I must say that from my personal experience Gradle tops them.
Gradle like many other posts on the internet would say - brings all the good stuff from the worlds
of Ant and Maven while keeping the ugly stuff out.

What do I mean by that?

It is the easiest build tool I've seen to get started with - simply download, extract and set the GRADLE_HOME environment variable on your path.
Like Ant - no other configuration is needed! Sweet.
Very well documented!
You can execute any Ant task from the Gradle build files. Any.
Dependency resolution - from Maven repositories, it leverages the existing repositories you may already have in your corporation without needing to change anything, while decreasing the verbosity of dependency declarations in the build file itself.
Gradle is based on Groovy, so you can just program your build.
And you can use all the libraries of Groovy. And it runs on the JVM, so you could theoretically use any Java library you like when running the build.
Did I already say powerful?
It is dynamic - You can tell Gradle in run-time for example, which sub-projects you'd like to include in your Project's build. I did that, using naming conventions for instance when I had a process that was auto-generating entire projects ready to be built in a pre-compilation phase. Incredible!
No need to sit and rewrite ant targets to do jobs like clean, compile, jar, war etc... it is all there already!
The integration with Eclipse is excellent. All you need is there.
It just works!

Let me give you an example of how a simple Gradle build (build.gradle) file looks like:

apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.6
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'My project', 'Implementation-Version': version
}
}
repositories {
mavenCentral()
}
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}

I think that what is so nice about this build file, is that you can understand it right away.
Lets go over the lines to try and understand this file:

The first two lines declaring the "apply plugin...." means that you are telling Gradle to use plugins such as 'java' for example to it would know how to compile Java source to classes.
Gradle is based on plugins, which facilitate all the needed 'know-how' and logic of performing
various tasks. - You could write your own custom plugins as well.
The 'eclipse' plugin for example generates the needed files for importing your Gradle project into Eclipse.
You can read more on that on - The Eclipse Plugin.
sourceCompatibility - tells Gradle what version of Java your source files are written in.
You can also specify the 'targetCompatibility' attribute in order to compile your sources into a lower version of Java.
version - Declares a variable called 'version' with the version number of your package
(Be it a JAR or WAR file). The Jar files that are generated with the Gradle 'build' task, have a Maven convention. So the version number is appended to the name of the package at the end. (for example: "MyPackage-1.2.jar", in case version was given the value "1.2").
jar { ... } - This is a Gradle Task is a "task" (can be thought of an Ant task) which is part of the 'java' plugin that assembles a Jar file from your compiled code.
You can add to the manifest file your own attributes, such as a version number.
Note that 'Implementation-Version': version is using the version number declared earlier in paragraph 3, but you could have used any other variable to place your value in there.
repositories { mavenCentral() } - determines the repositories from which you want to perform dependency resolution.
In this case - using the Maven Central repository.
dependencies { ... } - determines the needed dependencies for your build.
Like Maven's dependency scope, in Gradle there are also so called 'scopes' which you declare for your dependencies: compile, runtime, testCompile & testRuntime.In this case we declare for example the following:
testCompile group: 'junit', name: 'junit', version: '4.+'Which makes sure to use the JUnit version 4 and above during compilation of test files.

That's it.
It's really short and simple!
Now you can just run from your command line : > gradle clean build
And you will get your project cleaned, compiled, packaged ("Jarred"), tested and with a JUnit test report, all under the 'build' directory of your project.
Of course, you can also distribute the artifacts (your Jars) to your repository, or just copy them
flat to an "Artifacts" directory of your project and so on.

But this was only to demonstrate how easy it is to create a build file, that does so much.

Examples

Running an Ant Task from Gradle build file:

You can run an Ant tasks from a Gradle build file simply by writing something like this:

ant.echo(message: "Building a project....")

This task in particular is not that useful... it's just a print, but it demonstrates how easy it is to execute Ant tasks!
Especially if you consider migrating from Ant, and you have custom Ant Tasks written
which you want to re-use - then you could easily do this.

Running an external Java program from an external Jar:

This could be handy if you want to run anything which is for example at a pre/post phase
of the build.
The snippet below shows how you would apply an XSLT on a XML file, using
the xalan library:

ant.java(jar: "lib/xalan.jar", fork: "true") {
arg(line: "-xml" + " abc.xml")
arg(line: "-xsl" + " myXslt.xsl")
}

(the "lib" directory is at the project's root directory as were the "abc.xml" and "myXslt.xsl" files).

Including Sub-Projects in your Project's build dynamically:

When your project is comprised from sub-projects, it is necessary to tell Gradle about
those sub-projects in a dedicated file called settings.gradle.
In that file, one needs to "include" the sub-projects that need to be built by Gradle.
So typically you could see something like this:

include 'server', 'client'

The great thing about Gradle is that in the settings file you can pretty much put just about anything
you put in a build file. The settings file is executed in the initialization phase of the build.
So if you want to dynamically include sub-projects into your build because you're generating them
from another process, or because you have many of them, or for any other reason, you can do
something like this:

new File(".").eachFile(groovy.io.FileType.DIRECTORIES) { f -> if(f.name.startsWith("subProjectPrefix") {

include f
} }

This will just iterate over the root directory of your project, check if the current directory
it iterates on starts with the "subProjectPrefix" prefix, and includes it if it does.

This was really just the tip of what Gradle can offer you.
You can find many examples on the internet as well as on Gradle's installation directory.
(Look under %GRADLE_HOME%/samples - there are many build files examples).
So if you're using Ant, Ivy or Maven I recommend you to look into it, and give it a try,
I don't think you will regret it.

Gradle - http://www.gradle.org/

Merge on check-in, is there more to this?

2012-09-28T01:12:00.000+02:00

In case you find yourself merging code very frequently when trying to commit/check in/push your changes to the version control system (VCS like GIT or SVN), you should start asking yourself -

"Why am I merging so many times? What is the reason for this?".

If you are making lots of merges to your code - it could indicate a design problem in your project.

(I am trying to be very careful here, as each project is unique in its characteristics - the amount of code and modules, the amount of people working on it, and so on, so it does not necessarily point that out).

"How come?" you might ask...
Basically merging happens when more than one party checks out a piece of code makes changes to it and then checks it in. Only the first party that checks in is avoiding a merge, but all others that made changes (to a now stale version of a file) will have to merge their changes with the latest commits.

I heard many times the good argument that claims that to check-in small pieces of code at a time reduces the amount of merges and helps avoiding big sudden changes to the code which could render it buggy.

While a "small" size of code is something subjective the idea is clear and makes sense.

It is easy to keep track of small changes. A single bug fix or small enhancement and so on.

Although this is a good practice and will help you reduce the amount of merges, there are sometimes still situations where merges happen more than they should.

There could be another reason why you're merging more than you should, and this reason could be - a design "problem" in your code.

Such "problem" could be for example :

1. Classes that represent two (or more) logical units or well defined purpose.

Then it's clear that if 2 people (or more) would need to make some changes regarding different functionalities of this class, because this is the way work was distributed in their team, those people are very likely to face merging issues when they will try to check-in their code.

While if the class would have been splitted into 2 (or more) distinguished classes with clear purpose, then the 2 parties wouldn't need to face a merging issue.

Unless... (here comes #2)

2. Dependencies - sure almost everyone has dependencies and that is how things work.

But what happens if you are starting to have a lot of dependencies? Then you're also likely to face a merge.

Only this time you'll have to change your dependants' code (code who uses your class/interface as API) in order not to break compilation, and in those dependants is exactly where the merge lies.

(Someone who just worked on that class earlier using your now 'old' API... and now you have to adapt their new code! - I'm not talking about changing your interface or API as part of a general change in the infrastructure of the system, that is obvious, and intended to affect client code. I'm talking about the times where it was not meant to be or shouldn't be due to bad design, wrong API usage and so on.)

Although adapting client code might sound less problematic, reducing those incidents as much as possible by reducing the amount of your dependencies, will help you avoid more merges. (Changer point of view).

Also as a client, It would be less likely that someone would come and change your client code, and adapt it in a way that you did not mean.

So if you're having lots of merges, try to understand why you have them before trying to resolve them. Sometimes it is very tempting to go on with the merge, as today there are good automatic tools to perform a merge. But, maybe you'll find something interesting, or come up with a way to refactor code that was taken for granted as a "law of nature".

You'll eventually earn less merges, a more modular well defined code, and become less error prone,

After all, who hasn't made a mistake once of accidentally dropping some code on a merge?

So not every merge is a reason to start wondering why this is happening, but it should make you at least aware of the situation and think whether it could be different.

Hope this post wasn't stating the obvious.

GWT Chrome extension using version 2 manifest

2012-08-26T19:54:00.000+03:00

Hi everyone,

A while ago I wrote a small post about how to create Chrome extension using GWT, claiming
you could use GWT to make powerful Chrome extension.
One of the comments was regarding the usage of the manifest version.
When you write a Chrome extension, you must provide with a file called manifest.json which
serves as some kind of descriptor file to your extension.
It contains all sorts of things, such as the name of the extension, description, icon, action,
javascript files involved, and so on...

One of the entries in that file is the version entry.
As for today Chrome supports the current version - 2, and also supports (for the moment)
version 1.
However, this is changing, and Google already announced that they will stop supporting version 1
in the future (see http://developer.chrome.com/extensions/manifest.html#manifest_version), due
to security reasons.

So I was asked whether it was possible or how is it possible to deploy the GWT extension with the
version 2 attribute in the manifest.json file.

Version 2, is stricter in terms of security than version 1. Especially when it comes to using external JavaScript files.
You can read about security concerns over here:
http://developer.chrome.com/extensions/content_scripts.html#security-considerations
http://developer.chrome.com/extensions/xhr.html

One of the problems I faced, was the inline scripting I had (JavaScript showing inside the HTML).
That problem came not only on my "Hosting" HTML file, but also on the compiled outputs of GWT,
where HTML file which was needed was created and contained JavaScript code.
When that happened, I couldn't execute the extension on Chrome using version 2 in the manifest.json file.

I wrote in response to a comment someone left regarding this problem, that in case Google would have a way to separate JavaScript files from HTML, then problems would be solved.
Back then, I didn't see such options for the GWT compiler.

However, after doing some more searching, I found out that it does exist (!).
And so by adding a simple line in the .gwt.xml file of the application, you can compile all
your GWT application output into a single JavaScript file. Meaning - no HTML files containing
inline JavaScripts.

The line one needs to add is:
...
<add-linker name="sso" />
...

I added it to my Quickpik.gwt.xml file, and so when you run the GWT compiler, you get at the end
one JavaScript file containing the entire code of your app. Awesome!

You can access the entire code on Github and download it from there:
https://github.com/nirgit/Quickpik

You can simply click on the "Downloads" on the right hand of the screen, in order to download
the repository as a ZIP file.

In case you're a GIT user, my suggestion is that you just clone the repository. It's really small.
Simply open your GIT shell and type:
git clone https://github.com/nirgit/Quickpik.git

The extension is already ready to be used in Chrome, and you can deploy it by opening Chrome's
Tools -> Extensions tab, and checking the "Developer mode" box.
Afterwards, you will be able to deploy the extension by selecting the "Load unpacked extension..."
option and selecting the war directory of Quickpik.

I am hoping this is somewhat useful.
I think GWT is an absolutely great tool, and one that can be a lot of fun writing Chrome Extensions.

Until next time!

Source on a Github repository

2012-07-11T00:00:00.001+03:00

Hey everyone,

This is a really short note.

From now on, in case I will publish more code in the future I will try to make sure it is uploaded

to Github, so anyone could profit from it.

The Github repository URL: https://github.com/nirgit

Enjoy.

Quickpik - GWT Chrome extension - Search photos

2012-07-09T12:45:00.000+03:00

As a continuation to my previous post, this isn't about discussing anything.
It is about doing - giving an example of something quite simple & cool which you could do yourself using GWT, to build a chrome extension.

Being a bit of a GWT enthusiast, I built an extension for Google Chrome called QuickPik - which allows users to search for images from right from the toolbar.

Quickpik is using Google Images & Flickr (Yahoo) APIs.
You can run a simple search, and get some images as results. It's really simple.

You can just download the zip file from the link below, extract it and install the .crx file right into Google Chrome by dragging the file into it. If you're scared of some evil code running on your browser - just open the source code in the zip file, build the extension yourself, and then install it.

Keep in mind that the idea of this post is to show how easy it is to create a
cool extension for Chrome.
The code might not be extremely well documented, nor does it strictly follow Google's best practices like the MVP pattern or bundling CSS or Image resources and so on, but...

You can expect something compact and simple enough once you open it and take a look.
I don't think there should be a problem understanding much of the code.

Would love to get feedback if this helped anyone.

Both source code & Chrome extension below are available to download in one zip file.

Have fun !!!

The project on Github: https://github.com/nirgit/Quickpik
A Zip file to download: http://www18.zippyshare.com/v/16094412/file.html

Building Chrome extensions with GWT

2012-06-05T20:38:00.000+03:00

Recently i took a look into Google Chrome Web Store.
The web store as you can take a look for yourself, is loaded with apps, which many of them are given free.

I decided to understand what it takes from a simple developer like myself to build such an app which I can run on my browser & distribute on the Chrome Web Store.

Surprisingly, it does not take a lot of effort to write such an app/extension, especially if you're already familiar with a little bit of web development.
Google Chrome Extensions: http://code.google.com/chrome/extensions/overview.html

So what you really need is some knowledge of JavaScript, HTML & CSS to make a neat extension.

For me the real story began when I realized that for such requirements, one could actually use the (amazing) GWT framework to write such an extension.
If you never looked into GWT, my personal recommendation is that you absolutely must in case you're into web-development. GWT is a truly incredible tool from my experience.

If you look at the file structure of such an extension, you can see from the "Google Chrome Extensions - Getting Started" tutorial (http://code.google.com/chrome/extensions/getstarted.html) that we're talking about 4 important files:

manifest.json - This file if you like is some kind of a descriptor of your extension.
An HTML file "hosting" your extension.
A JavaScript file containing all the cool interaction with your extension, and your script.
A CSS file - for styling.

When you write your GWT application in Java and compile it afterwards, you get such files, except for the first one. That you will have to add yourself to the project.

So enough of "blabing" - Lets dive right into "How to do it" (if you're impatient, just scroll to the bottom of the page to download a zip file of the project):

1. Start a new web-application project in Eclipse, and let it create the default skeleton of the project.

2. After the project has been created, make some clean up in the project's structure by deleting the "server" and the "shared" packages.

3. Edit the .gwt.xml file and make sure the file's contents is something like:

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to='mychromeext'>


<inherits name='com.google.gwt.user.User'/>



<inherits name='com.google.gwt.user.theme.clean.Clean'/>





<entry-point class='com.techdrum.chrome.ext.example.app.client.MyChromeExt'/>

<source path='client'/>

<set-property name="user.agent" value="safari"/>
</module>

4. Delete the auto-generated Async file and it's matching service file.

5. Write some GWT code in the MyChromeExt.java file, something very simple like -

package com.techdrum.chrome.ext.example.app.client;

import com.google.gwt.core.client.EntryPoint;

import com.google.gwt.user.client.ui.Button;

import com.google.gwt.user.client.ui.RootPanel;

import com.google.gwt.user.client.ui.TextBox;

/**
* Entry point classes define <code>onModuleLoad()</code>.
*/
public class MyChromeExt implements EntryPoint {
/**
* This is the entry point method.
*/
public void onModuleLoad() {
final Button sendButton = new Button("Send");
final TextBox nameField = new TextBox();
// We can add style names to widgets
sendButton.addStyleName("sendButton");
// Add the nameField and sendButton to the RootPanel
// Use RootPanel.get() to get the entire body element
RootPanel.get("nameFieldContainer").add(nameField);
RootPanel.get("sendButtonContainer").add(sendButton);
// Focus the cursor on the name field when the app loads
nameField.setFocus(true);
nameField.selectAll();
}
}

6. Almost done! Create a new file called "manifest.json" and place it under the "war" directory.

The file should contain the following:

{
"name": "My GWT ext",
"version": "1.0",
"description": "Simple GWT Extension!",
"browser_action": {
"default_popup": "MyChromeExt.html"
},
"permissions": [
],
"web_accessible_resources": [
"mychromeext /E949D2D1E7CE643145D4D3D5FC28BB31.cache.html"
]
}

*Note the stressed file name!

7. Compile the project.

8. Match the file name with the .cache.html suffix under the directory mychromeext to the one mentioned in paragraph 6.

So if you have something like BF13DA7B8EE69ECA8CAA8F35290E1E1E.cache.html

then your new manifest.json should look like:

{
"name": "My GWT ext",
"version": "1.0",
"description": "Simple GWT Extension!",
"browser_action": {
"default_popup": "MyChromeExt.html"
},
"permissions": [
],
"web_accessible_resources": [
"mychromeext/BF13DA7B8EE69ECA8CAA8F35290E1E1E.cache.html"
]
}

9. That's it! Now you're ready to deploy your new extension on Google Chrome.

To do that - open Chrome, and open the Extensions window:

10. Make sure to check the "Developer Mode" box, and then click on "Load unpacked extension..."

Select the war directory of the compiled project, and your new extension should appear on the Chrome toolbar next to the address bar.

When clicking on it, you'll see your app:

Congratulations!

Get the full code of the project here.

GWT - FlowPanel + CSS vs HorizontalPanel and VerticalPanel

2012-05-07T11:27:00.000+03:00

I've been working with GWT for the past half year, and am extremely excited about this awesome web-framework !
I recommend anyone who is doing web-development to look into it. As a person that came from the world of Java Swing, the transition was very smooth, and most importantly - fun !

Anyhow, this is not the focus of this particular post. I'm not here to say how great GWT is or
persuade you to use it (although you really should if you want to create amazing rich web apps!!!).

This is about GWT's particular widget - FlowPanel and its advantages over using HorizontalPanel & VerticalPanel.

The "problem" is as follows:
Using HorizontalPanel or VerticalPanel to layout your widgets can be very intuitive and comfortable, especially if you come from the world of Java Swing, where Layout Manager extending components help you to lay out your widgets, without forcing you to think too much how they do it.
GWT widgets are a little different.
GWT is a compiler in it's core, that takes Java code, and compiles it into JavaScript that eventually runs on your browser. Different widgets compile into different HTML elements that are attached into the DOM and need to be rendered, so it is very important to keep your DOM as compact and simple as possible so the browser has to deal with less elements thus rendering your page faster, and is also helpful when you need to look yourself at the DOM to find a specific element or understand the hierarchy.

Using the HorizontalPanel or VerticalPanel, can create some serious performance overhead, and especially when you have lots of those in your application.
The reason is because GWT compiles HorizontalPanel & VerticalPanel into HTML Tables.
When you have a lot of those tables, and with many widgets inside you will end up having
lots of those "<td></td>" , "<tr></tr>" tags which resemble the lines and cells of the tables,
and of course the encapsulating tags of the "<table></table>" & "<tbody></tbody>".

FlowPanel on the other hand is compiled into a "<div></div>" - plain and short.

So as you can see, the problem is that when you have lots of those Vertical/HorizontalPanel - you end up generating a lot more elements in the DOM.

This in turn reflects on the performance of your application. Each time you'd want to manipulate those tables - add a cell, remove one, change content, the look-up into the DOM is longer, and the operations consume more processing.
After the change you will end up making to the DOM, the browser will have to re-render those changes in order to reflect them to the user - the more complicated hierarchy you will have the slower the rendering will be performed.

Ok, now I feel I repeated myself enough, so the point should be clear.

So, after understanding why it's better to use (in many cases, although not necessarily all), here's what needs to be done in order to make the change:

Replace your VerticalPanel (or HorizontalPanel) widget with FlowPanel widget.
In case you're using HorizontalPanel and wish to place widgets next to each other, don't forget to use CSS float attribute.

Example:

import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.FlowPanel;
import com.google.gwt.user.client.ui.Label;
import com.google.gwt.user.client.ui.TextBox;

public class MessagePanel extends Composite {

// Using FlowPanel instead of HorizontalPanel
private final FlowPanel contentPanel;

// Widgets of the message panel.
private Label messageCaption ;
private TextBox messageContent ;
private Button send ;

/**
* C'tor
*/
public MessagePanel() {
this.contentPanel = new FlowPanel();
initWidget(this.contentPanel) ;
// Lets add contents to the panel.
addContents();
// add styles !
addStyles() ;
}

private void addContents() {
// add a name caption
messageCaption = new Label("Message:");
contentPanel.add(messageCaption);
// add an input text field
messageContent = new TextBox();
contentPanel.add(messageContent);
// add a "send" button...
send = new Button("Send message!");
contentPanel.add(send);
}

private void addStyles() {
messageCaption.getElement().getStyle().setProperty("float", "left") ;
messageContent.getElement().getStyle().setProperty("float", "left") ;
send.getElement().getStyle().setProperty("float", "left") ;
}
}

Of course, the code above is only to demonstrate what you can achieve, but not necessarily

how you should really implement it. CSS styles should be put in a CSS file and you should follow GWT's best practices.

In any case, the outcome of instantiating this widget and adding it results the following:

And results in the following hierarchy in the DOM (from Chrome) :

<div>

<div class="gwt-Label" style="float: left; ">Message:</div>

<button type="button" class="gwt-Button" style="float: left; ">Send message!</button>

</div>

So, as you can see this part of the DOM is very concise and straightforward.

Change to FlowPanel to boost your application's performance & to generate simpler DOM.

Happy tuning !

Spring ROO 1.2 review

2012-04-29T13:16:00.002+03:00

This post as the title mentions, is about my personal impressions and thoughts about the
'Spring ROO' framework, version 1.2.1.

What is ROO?
ROO is a tool, which helps automating the development process of web-applications written in Java.
It supports different kinds of technology stack, such as GWT & Spring MVC in the front end, JPA & Hibernate, EclipseLink in the back-end and such.
The framework is entirely based on the Spring framework, in order to accomplish the goal of creating a full-blown, end-to-end web-application.
The idea is to be able to rapidly create and maintain a web-application with a few 'shell' commands, and then let the users (the developers) fill in the gaps and customize business logic, application state and so on.

ROO monitors the changes the developer makes while writing code, and adapts the application's infrastructure to match and support the developer's actions.

I recommend you visit the ROO website in any case to get the best understanding of the tool.

Before I start telling you what I did and experienced I have to say that I enjoyed working with ROO.
The installation was fast & easy, the ROO shell was easy to use and the documentation was satisfying.

So! after some short-long intro, let me tell you -

What did I do?

1. Created a simple web-application based on a multi-module project - Server & Client modules.
2. Used GWT as the front-end, JPA over Hibernate with a DB in the back-end.
3. Wrote custom code and integrated it in the auto generated files of ROO.
4. Tried to change/add/remove a service (BL) & repository (DAO).
5. Inspected generated code.
6. Tried to remove project's dependency from ROO.

What I experienced
1. The amount of code generated for the client module (GWT) was quite overwhelming. So many files were created to show/edit/create/delete a single entity named Product in the DB. While some of the generated code is absolutely necessary, a lot of code was created to support every possible option on the front-end.

Unfortunately, this is not configurable, and I could not find a way to tell ROO exactly what I wish to generate ('scaffold'), like - "only desktop support", "only mobile support", "only view/read" capabilities, etc... You can only pick which Entities on your model to scaffold (support on the front-end and back-end). All this leads to a very big codebase, which won't necessarily be used.
This leads to verbosity and a lot of redundancy, which makes your codebase larger and
more complex for no reason.

2. Front end's design - Is following Google's best practices which is really great. You can learn
quite a bit of Google's understanding the design of a web-application on the front end.

3. Generated code looks fairly neat, however all generated code managed by ROO is "hidden" in AspectJ files. - Some people don't like this.

4. No easy removal* of ROO from the project in my opinion... - You could just stop ROO from monitoring your application and continue developing your project. But, all the generated AspectJ files remain. This could be a problem for the future, in case you want to change your classes' implementation. (* - Please see comments at the bottom).

5. Writing tests & integrating them with Services layer was easy.

6. Great end-to-end integration tests, that run on the Browser using Selenium (some kind of a web-driver script player).

It feels to me that even though ROO's GWT add-on tried very hard to give a real added value to developers, it added more complexity than simplicity, and that is in my opinion due to the fact that
a lot of code is being generated. And that makes it hard in the beginning to dive into the code.

Not to mention how much tweaking needs to be done to disable features for instance.

And in case you're letting ROO manage your project further, you will have to keep track of that
stuff all the time. So if you 'messed' up by scaffolding some entity which you didn't want, you'll spend
your time removing the unwanted code. where is the Undo feature of the shell?

ROO just doesn't feel as fine grained as I would expect it to be.

Conclusion
I think that ROO is walking in the right direction, empowering developers to deal only with the logic of their web applications and not trouble themselves with infrastructure and design problems of standard web-applications.
I am not sure I would use it (especially not the front-end) in production, yet.

Despite all that, it still benefits as a really nice tool for prototyping (or quickly setting up a back-end & DB configuration), and for learning how to implement a web app with best practices.

What can you profit from it:

1. It is an amazing tool to create a web-app POC very fast!
2. It is an awesome tool to learn new technologies and see how they work with each other.
3. Spring ROO applies best practices.
Explanation: ROO has a 'plug-ins' platform, which lets anyone to generate code following a simple command in the shell.

Google for instance wrote such a plug-in for ROO to integrate with GWT. As a result you get the BEST, latest results for architectural/design/technology/practices on your web-app.

4. It's a great tool to get your backend Spring based infrastructure ready with a DB, in a few minutes, or see how it should be done properly.
5. Runtime performance - Best runtime performance you could have achieved yourself probably.
All generated code/configuration is processed in compile time as regular Java files only!
Following best practices of Spring & other vendors like Google, you can rest assure that there should be no performance issues caused by this tool. (or with very little chance for it to happen - even the best software giants have bugs sometimes).
6. Did I mention the great integration tests running automatically on the browser?
I personally loved this feature!

I think it would be wise to keep an eye on ROO for the future, as it has already been out there for some time, and keeps on improving.

Visit 'Spring ROO': http://www.springsource.org/spring-roo

DI with Guice for Java Swing

2012-03-20T01:32:00.000+02:00

If you're familiar with Dependency Injection (DI) concepts and frameworks such as Spring,
you know the great benefits it introduces when developing an application.
Spring which I daily use (and praise), is a framework (or an application platform if to be more accurate) that one of its core features and philosophy is DI.

Some of the benefits of DI are well known:

Simplified code.
Reduced dependencies.
Helps 'modularity' and creation of reusable components.
Helps you test your application better.
Lazy loading.

Surely there are other benefits you could think of which were not mentioned above.
So, why not bring all that good stuff to your Rich Client ?

The connection of DI to the title of this post is how to integrate DI in your front-end in case you are building a Rich client application, using Java Swing or GWT for example.

You could follow the MVC pattern (which is well known, and can be great) to build your rich client, and integrate it with a DI framework. However I strongly recommend you consider the MVP pattern for an even better design of your front-end. Which I find it to be much 'cleaner'.
(In MVC some of the business-logic code is scattered between the controller and the View. It's harder
to re-use your View objects/Widgets, especially in case you want to give it to someone else to use, or integrate them in another product).

Smarter people than me talk about it, and you can find great talks on YouTube regarding this subject.

You can later also check Google I/O's excellent talk for "Best Practices for Architecting GWT App" http://www.youtube.com/watch?v=PDuhR18-EdM

So, if we follow the MVP design pattern and Google's best practices (even if we don't use GWT),
we end up with few key components in our app, i'll try to give some description what they do:

"The" Event Bus - The component where presenters 'listen' to, and can fire events to.
The Presenters - The components which encapsulate the logic of your application.
The Views / Displays - Simply a view - can be a panel with widgets in it. No logic in here!
A Model - Where you keep important data that can be accessed by one or more presenters.

"Show me the code!"

Lets assume you're writing your rich client in Java Swing.
We will use the lightweight DI framework "Guice" by Google:
http://code.google.com/p/google-guice/ to help us achieve our goal.

Lets go over some steps to realize what needs to be done in order to get this to work - don't forget to download Guice and put it's Jars in the classpath.
(Or, scroll all the way down to download the zip file containing the source code).

1) Define a simple View as a dumb object, not knowing anything about logic:

public class ContentPaneDisplay extends JPanel { .... }

2) Define a high level IPresenter interface and the IContentPanePresenter interface:

public interface IPresenter {
/**
* A method of all implementing presenters for presenting themselves on a given container.
* @param c
*/
void go(Container c) ;
}

public interface IContentPanePresenter extends IPresenter {}

3) Define a Presenter that will use view object above as its display:

public class ContentPanePresenter implements IContentPanePresenter {
public static interface IDisplay {
JComponent getAsComponent() ;
}
private final IDisplay display ;
....
}

4) Make ContentPaneDisplay implement the ContentPanePresenter.IDisplay interface.

5) Configure the Display class and the Presenter class to be used by Guice:

public class ApplicationDIModule extends AbstractModule {
@Override
protected void configure() {
// Lets configure some stuff !
bind(IContentPanePresenter.class).to(ContentPanePresenter.class).in(Singleton.class) ;
bind(ContentPanePresenter.IDisplay.class).to(ContentPaneDisplay.class).in(Singleton.class) ;
}
}

6) Add the @Inject annotation to the ContentPanePresenter to be injected the display:

/**
* C'tor
* This is where DI takes place!!!
* Guice will instantiate and provide this presenter with a matching display!
* @param display
*/
@Inject
public ContentPanePresenter(IDisplay display) {
this.display = display ;
...
}

7) Now all that's left is to call the Guice injector to get the ContentPanePresenter:

private static void go(Container container) {
// Guice.createInjector() takes your Modules, and returns a new Injector instance.
Injector injector = Guice.createInjector(new ApplicationDIModule());
// lets get the 'Main' content pane Presenter !!
IContentPanePresenter contentPanePresenter =
injector.getInstance(IContentPanePresenter.class) ;
contentPanePresenter.go(container) ;
}

I hope this post was beneficial to you, and you got exposed to something new.
Watch the Google I/O YouTube video about "Best Practices for Architecting GWT App", it's really worth it.

Click this link to download the source code from GitHub.

More (software) performance, less carbon dioxide

2012-01-22T18:52:00.000+02:00

This post is a little different than the older ones.
This time, it's about how "Making a performant software, helps reducing carbon dioxide emissions".

So, what's the connection you ask, and why is it even important?
I'm not writing this post to convince you that global warming is not a theory. It sure isn't.
The vast majority of researches on this topic amongst the scientific community, indicate we are facing a new reality where nature starts kicking back, corresponding our irresponsible actions as humans.

You're encouraged to read and explore this must topic (IMHO) yourself to realize how it effects your life directly, and how it effects our planet.
A great book, which I very much enjoyed reading and also inspired me to make this post is:

"Hot, Flat, and Crowded" by Thomas L. Friedman. (There's also a 2nd edition of the book).
(His website: http://www.thomaslfriedman.com/)

However, I think there are many other ways you can choose to enrich and extend your knowledge about this concerning subject, from books and magazines to getting involved in your own community and raise awareness.

So, assuming we understand the importance of a change we should make, not only because of
energy problems in the world, not only because of extreme climate changes and amounts of Greenhouse gas particles in the air, although extremely important, this is also a lot about how to make your software more competitive than others in the IT market.

You create an added value in terms of "green" to your customers, bringing them more benefit in
energy consumption, which translates to reduced electricity bills, and helps tagging their company
as "greener".

So this is about how you as a software engineer can help make this change.

The idea is very simple(yet, a little harder to implement and keep in mind):
The more computations your software makes, the more CPU is needed for computation, and
more energy is needed to cool it down.
Since a CPU is an electronic device like anything else pretty much on your computer, and consumes
energy (Watts). The more you use it, the more energy you consume. Rather logical!

If we can reduce the amounts of computations on our CPU, than less energy will be needed.
If our software won't perform any computations, then the CPU usage will be at minimum.

What can you do!?

Improve your computations in the code.
Replace for a faster algorithm than the one you're using
Make stress tests - measure CPU performance with profilers.
Add "Green" Unit tests to your software to make sure CPU utilization doesn't exceed a certain limit you or your company set to itself.
Perform long and "heavy" processing during night time or when electricity is cheaper.
Create an acceptance test for your software, making sure in all cases computations don't exceed a certain bar, or make sure average computation per day stays low.

So, as you can see the theory is extremely simple to understand.
The question is, how much can we 'save' or what do we save ?

Lets make a simple example.
This is totally not based on any scientific research, and is using only given inputs from official manufacturers and website i found on the web and using some common sense.

Suppose your computer has a CPU from a known brand like Intel or AMD.
Such CPU can consume up to 130W (Watts) for TDP - which is the maximum amount of power needed to cool down that CPU so it can work properly.

If you are running on a high loaded server which is operating 24h / 7d than you get
24 x 365 (hours) = 8760 hours of using this CPU.

Lets assume that the average CPU utilization stands on 80%, because of your software computations.
This translates to an average of 104W in order to keep that CPU working.

The price for a Kilo-Watt is something your local electricity company charges for, and it changes depending on many factors.
However, I found some numbers on the web, and as I see it may vary, but since this should be
a constant in the "cost calculation formula" as the electricity price is (usually fixed, or has a fixed average), we'll just use some number, say 15 cents for a Kilowatt (kw).

So now we can calculate how much we would need to pay just for this CPU to work:

(104W) * (24 * 365h) * (15cents)
-----------------------------------------------           =     13,665 cents.
                    1000

So that's 136$ dollars for the entire year. Doesn't look so much ?

If hypothetically you will be able to reduce the average CPU consumption to 25%, you will get:

(32.5W) * (24 * 365h) * (15cents)
-----------------------------------------------           =     4,270 cents.
                    1000

and that is 42.70$ dollars a year. That's about 68% less to pay. And if you or your client have dozens of servers or more, say 100, then you could save (approx.):   (136 - 42.70) * 100 = 9,330$.
And that's already some money, especially as it accumulates over years and years.

Not to mention all the carbon dioxide emissions you reduce by making your software more efficient!
A coal based power plant can emit up to 1 Kilogram of Carbon Dioxide per 1 Kilowatt!
(Again I must stress that different numbers could be found on the web, but the idea is very clear).
Which means that by utilizing 25% of your CPU instead of 80% you reduce carbon dioxide emissions
dramatically! And in numbers you emit 284.7 Kg, instead of 911.04 Kg !
And that is only for one CPU!
I'm sorry, I just can't shout it loud enough.

Just imagine having this amount of garbage bags pile around your own house !!!
I'd rather live without any garbage bags around my house at all I can tell you that ! But I would definitely be happy to reduce the amount as much as I can.

Remember, just because it goes into the air, doesn't mean it is not there ! - it even rhymes !

Change starts today.

Password encryption in Java

2011-12-13T23:43:00.000+02:00

This time, it's about security.
And specifically about how as a developer, you should protect the passwords of your users.

I think there can't be enough emphasis of how important it is to keep the password of your users safe.
So, instead of 'lecturing' about why you should do it, lets dive in right away into how you do it.

So, given the fact you have different users on your system, and each of them has a password,
we would like to keep their passwords safe.

This translates to storing their passwords somewhere (a DB for example), encrypted.

So before we really give code example how it's done, a small note on encryption:
When you pick an encryption algorithm to apply on your passwords, try to think if you ever
plan on decrypting them. In most cases the answer is 'NO'.
(Picking a symmetrical algorithm also means that in case an attacker finds out the key,
they can use it to decrypt the passwords).

Thus, we'll drop all symmetrical algorithms such as AES(Rijndael), RSA based, etc.. and pick
an asymmetrical encrypting algorithm such as hashing.

Hashing algorithms such as SHA are asymmetrical-key algorithms, meaning that for an attacker
that put their hands on the encrypted password it is impossible to recover the original password.
Different inputs for SHA can yield the same output, but with a very low probability.

Now that we understand why we should use a Hashing algorithm, we can explain the steps for
encrypting and give an example code how it's done in Java.

Encryption recipe:

1. Take password and salt* as an input.
2. Apply some hashing algorithm on the input. (We will choose SHA-256)
3. Repeat step 2 a large amount of times where the input to the algorithm is the last output of the encryption.

*salt - Is an additional fixed input for adding complexity for the encrypted password.

Lets write this in Java:

package nm.example;

import org.apache.commons.codec.binary.Base64;
import java.security.MessageDigest;

public class PasswordEncrypter {

    private final static int NUMBER_OF_HASHING = 10000 ;
    private final static String CHARSET = "UTF-8" ;
    private final static String ENCRYPTING_ALGORITHM = "SHA-256";

    /**
     * Encrypts a given password.
     */
    public static String encryptPassword(String salt, String password) throws Exception {
        // Transform the given password & salt to Base64 in order
        // to work on a closed set of 64 characters instead of Unicode.
        Base64 base64EncoderDecoder = new Base64();
        String b64password = base64EncoderDecoder.encodeAsString(password.getBytes(CHARSET)) ;
        // Create the salt & transform it to Base64.
        String b64Salt = base64EncoderDecoder.encodeAsString(salt.getBytes(CHARSET));
        // The encryption!
        byte[] proposedDigest = getHash(b64password, b64Salt);
        return base64EncoderDecoder.encodeAsString(proposedDigest) ;
    }

    /**
    * From a password, a number of iterations and a salt,
    * returns the corresponding digest
    */
    private static byte[] getHash(String password, String salt) throws Exception {
        MessageDigest digest = MessageDigest.getInstance(ENCRYPTING_ALGORITHM);
        digest.reset();
        digest.update(salt.getBytes(CHARSET));
        byte[] passwordBytes = password.getBytes(CHARSET);
        byte[] input = digest.digest(passwordBytes);
        for (int i = 0; i < NUMBER_OF_HASHING; i++) {
            digest.reset();
            input = digest.digest(input);
        }
        return input;
    }
}

So the output for:
PasswordEncrypter.encryptPassword("secret-salt", "my-password")
is "NiNP/e/NOzmoCQGaShXENFzpYXv7+EclH9st+dnfBWE="

As you can see I'm using the Apache Commons Codec library for Base64 encoding,
which is available at: http://commons.apache.org/codec/download_codec.cgi

Happy encrypting.