Feed http://www.luigibifulco.it/blog/it Kirby Thu, 01 Jan 1970 00:00:00 +0000 The blog feed for Baseblog. Aggiornare Node.JS ed NPM su sistemi Windows http://www.luigibifulco.it/blog/it/blog/aggiornare-node-js-ed-npm-su-sistemi-windows blog/aggiornare-node-js-ed-npm-su-sistemi-windows r Ultimamente mi sono imbattuto nell'aggiornamento di Node.Js ed NPM su sistemi Windows per avviare un progetto con Angular2. Per esperienza il consiglio che posso darvi è di NON usare il comando 'npm i -g npm' per l'aggiornamento di npm ma di usare un modulo delegato all'aggiornamento su sistemi windows: npm-windows-upgrade.

I passi per effettuare l'aggiornamento sono molto semplici

  • Avviare la PowerShell di Windows con permessi di Amministratore
  • Eseguire in sequenza i seguenti comandi dalla shell
Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
npm install -g npm-windows-upgrade
npm-windows-upgrade

Una valida alternativa è utilizzare il package manager Chocolatey in questo modo:

choco install nodejs
]]>
Configurare Virtual Hosts su Nginx http://www.luigibifulco.it/blog/it/blog/virtual-hosts-su-nginx blog/virtual-hosts-su-nginx r Quella dei Virtual Hosts è una tecnica messa a disposizione da alcuni web server per sfruttare un unico processo server associato alla porta HTTP con più nomi host. Senza i Virtual Host per utilizzare più nomi host saremmo costretti ad avere più istanze del server Http sulla stessa macchina con porte diverse oppure più istanze su più macchine con la stessa porta. Per il mio sistema di video sorveglianza ho intallato il web server Nginx, e dato che sto utilizzando una webapp che non offre il multi-istanza a livello applicativo l'unico modo per avere più istanze della stessa applicazione è appunto utilizzare i Virtual Hosts. Fortunatamente il web server Nginx offre questa caratteristica e devo dire che dopo averla provata il trade-off difficoltà di configurazione/efficacia è sicuramente accettabile.

Veniamo ai dettagli tecnici, se avete già installato Nginx normalmente troverete tutti i suoi files di configurazione nella directory /etc/nginx. Bene in questa directory sono presenti due sotto directory che servono al caso nostro: sites-available e sites-enabled. L'installazione di default avrà creato per voi due files col nome default, dove in sites-available sarà presente il file di configurazione di default del server nginx e in sites-enabled il link simbolico a questa configurazione del server. Come il nome della folder lascia intuire il fatto che sia presente un link simbolico alle configurazione dei "sites-available", ovveri dei siti disponibili, abilita la configurazione del server.

Premesso questo creare un virtual host su Nginx diventa davvero banale poiché basta creare una copia del file di configurazione di default presente in sites-available e rinominare tale copia col nome del virtual host che vogliamo creare, requisito fondamentale del nome host scelto è che deve corrispondere ad un nome di dominio correttamente tradotto da un servizio di risoluzione dei nomi interno o esterno.

Tornando al file di configurazione ricordatevi di rimuovere la clausola default_server sulla dichiarazione della porta di ascolto, altrimenti Nginx si arrabbia poiché non permette l'attivazione di due default_server. E cosa non meno importante nella sezione location dovete indicare il nome host che avete scelto per il virtual host.

Per fare un esempio, supponendo di voler creare un Virtual Host sorveglianza.myhome.it per il server nginx che risponde al nome myhome.it e che punta alla default root /var/www/html/ vi basta seguire i seguenti passi.

Innanzitutto posizionamoci sulla directory dove potremo poi creare il nuovo file di configurazione:

cd /etc/nginx/sites-available/
sudo cp default sorveglianza.myhome.it

sudo nano sorveglianza.myhome.it

Dove vedete le righe:

listen 80 default_server;
listen [::]:80 default_server;

eliminate la stringa default_server lasciando il carattere ';'
inoltre dove vedete la direttiva:

server_name _;

sostituitela con:

server_name sorveglianza.myhome.it;

aggiornate la root del virtual host con quella desiderata:

root /var/www/html/web/sorveglianza

salvate il file e attivate il virtual host creando il link simbolico con il seguente comando:

sudo ln -s /etc/nginx/sites-available/sorveglianza.myhome.it /etc/nginx/sites-enabled/sorveglianza.myhome.it

a questo punto è necessario riavvaire nginx:

sudo systemctl reload nginx

Infine guarnite il tutto con la configurazione degli host sul file /etc/hosts aggiungendo l'host sorveglianza.myhome.it e mappandolo con l'ip fisico del server.

Da adesso accedendo all'host sorveglianza.homepc.it invocherete l'istanza che punta a /var/www/html/web/sorveglianza mentre accedendo all'host www.myhome.it continuerete a vedere l'istanza di deafult.

]]>
A low budget surveillance system http://www.luigibifulco.it/blog/it/blog/a-low-budget-video-surveillance-system blog/a-low-budget-video-surveillance-system r If you are thinking to realize a cheap video surveillance system your are in the right place. Just a few days ago i made this kind of system. It provides some usefuel features such as:

  • motion detection
  • live stream
  • low power consumption
  • security
  • storage
  • and last but not least it's a low budget project

The generic architecture is very simple. For the entire system you need:

  • a low power server machine
  • a router/switch connected to the internet
  • an IP Camera (Ethernet or Wireless)
  • a motion detection software
  • a multiplatform notification system
  • a storage in the cloud

Low power server:

The choice is very difficult and there are many variables to consider. The device power and the installed operating system are basic for your choice. Finally I decided to buy a Raspberry Pi 3 , it's very cheap, it's a low electric power consumption device, and it has enough computing power for our purpose. Price 45€

Network topology

This should be a very simple problem to solve. But if you are trying to mount an IP Camera you need to keep IPCamera network detached from your home network, so if you want to save bandwith you can preserve it at any time. For my purpose i mounted a normal router/switch that is connected to a power line connected to my IpCamera. The server is connected to the router also, and it serves as bridge and Http Reverse Proxy between the two networks. Every time i need to access to the system on demand i need to pass trough the proxy. Continous monitoring can be made in the survellance dedicated network. Price: 10~40€

IPCamera

There many models provided. I bought a Sricam AP004 that has a PTZ built-in system and 10-leds system for night vision. It serves a MJPG stream or a H.264 stream at 720p. I used MJPG stream for motion detection and HD stream for video recording. Price 100€
For my needs i had to buy an outdoor IPCamera there are more cheaper IPCamera if you need for example an indoor system. If you have more than one IPCamera consider to install a proxy server to manage multiple camera instances in order to invoke a unique HTTP URL.

A motion detection software

This was the most difficult part of the system, i'm a developer and i used the OpenCV library for building my own but after hours and hours of research i found the kerberos.io project. It provides a server written in C++ that rely on OpenCv library for image and video processing. It includes an optional web console useful to configure the server, image storage settings and motion detection parameters. While i write these lines the project is at the 2.0 stable release and it does the work pretty well. Kerberos.io is not the only motion detectoin software but i have to admit that is the best trade-off in the open source world. Mostly it is compatible with the RaspberryPi and it's precompiled for Raspbian and ARM based system. Price 0€

A multiplatform notification system

Even in this branch i had to do much research to preserve the low budget requirement. Finally i found Pushbullet with its REST API you can implement a fast notification system with a few lines of code.
If your motion detection software sends the motion detected event, it's easy to bind Pushbullet to your system to check what happened at home. Price 0€

For example with this Javascript function you can send a notification to your registered Android devices:

var PushBullet = require('pushbullet');
var pusher = new PushBullet('<YOUR PB API KEY>');

function push(){
    pusher.devices(function(err, response) {
      if(err){       
        return;
      }
      response.devices.forEach(function(device){
        if(device.type==='android'){
          pusher.note(device.iden, "Warning!", "Alarm trigger", 
              function(e,r){
                      if(e){
                         return;
                        }
                   });
               }
           });
    });
}

Storage service

A storage service in the cloud is very important for a surveillance system because:

  • we don't want to loose our recordings and image
  • we want to save space on local drive

Storage services are provided by many players in this field you can choose from Google Drive to DropBox or any other service you want. If you are going to use Kerberos.io you can consider that it is possible to subscribe to a cloud service for image upload.
Price: 0~1.50 €

Conclusions

With this system and if you don't have particular needs the entire budget can be estimated about 150~200€ + a lot of patience and a little human work. I think that it's a very low budget and the result is very impressive. Next steps could be an home made PIR motion detection. Maybe in the next article i will show you how it could be done. See ya.

]]>
Decorator pattern in Java with Spring http://www.luigibifulco.it/blog/it/blog/java-decorator-pattern-with-spring blog/java-decorator-pattern-with-spring r Decorator pattern is largely used in many development scenarios, enabling developers to create more maintainable code and to extend application functionality without deep impact to the entire project. Every time we think a structural pattern we think to an Adapter or a Bridge pattern. Decorator pattern solves same problems but for other domains: it is a valid alternative to functionality extension in terms of type inheritance.
Use of Decorator pattern can be found in the Java IO API where every Input or Output stream is decorated with new functionality and wrapped in a new type of Stream. In the same way we can extend code with this pattern when we need to add new beahvior to application functionalites or add a new functionality behavior.

Decorator pattern components

Every time you have to implement a decorator pattern the components that plays around are the Interface or the functionality contract, the basic behavior of that funcionality and the behavior we want extends to the basic functionality. In Java this can be translated to the extends keyword of the java class that implements a java interface. The Decorator component extends the functionality of the basic component, in Java this can be done through "extends" keyword. Extends keyword in its java technical acception (or more simply inheritance) is not always suitable specially if we have to extend a large set of methods and every method has a variety of extensions to implement. To keep the "Open Closed Principle" of software design it's more nice to look at functionality extensions in tems of compositon. So the basic component can be used as the delegate of the decorator component and the decorator component can be used as primary service as we want to use the decorated behavior. All these components share the interface in terms of what they have to do. In Spring this can be done in a elegant way through Spring Annotations, let's see a very simple example...

A Simple Spring Example

To show you how we can implement with Spring the decorator pattern you have to know what is Autowiring and some of Spring Annotations like @Component, @Autowired and @Primary. If you want to see the example in action you have to know Spring Boot, but you are free to use other containers.
So suppose to have this dummy interface:

public interface IExampleService {

    public String startExample();

}

And its basic realization:

@Component("delegate")
public class ExampleService implements IExampleService {

    @Override
    public String startExample() {
        return "Example started";
    }
}

If you are watching the @Component annotation you are on the right way, you can see we annotated it with a @Component annotation with a specific value, except of this feature the service can be used as a normal Spring service.

Now suppose to extend the startExample method with a further presentation message and in the same time use the basic startExample method, the basic approach could be to extend the ExampleService class. Another more elegant approach could be to incapsulate the basic ExampleService class in a ExampleServiceDecorator class. ExampleServiceDecorator will implements the same interface to be sure we are extending the same methods, it's important to keep the various interface implementations separated in order to keep the system decoupled. Spring help us to keep the system decoupled: let's see how. The class shown below represents the DecoratorService:

@Component
@Primary
public class ExampleServiceDecorator implements IExampleService {

    @Autowired
    @Qualifier("delegate")
    private IExampleService delegate;

    @Override
    public String startExample() {
        String started = delegate.startExample();
        return started + " and decorated with decorator example";
    }

}

as we can see this class uses the IExampleService interface but it doesn't know what kind of implementation we want to use. The relevant infos we write are that it has to use a "delegate" component of type IExampleService. Spring will follow this info to inject the delegate component. Remember that previously we annotated the basic service with the "delegate" string in the @Component value .

Finally we can use the EaxmpleDecoratorService as follow:

@SpringBootApplication
public class PrimaryServiceApp implements CommandLineRunner {

    @Autowired
    private IExampleService primaryService;

    @Override
    public void run(String... args) throws Exception {

        System.out.println(primaryService.startExample());

    }

    public static void main(String[] args) {
        SpringApplication.run(PrimaryServiceApp.class, args);
    }

}

In this example we are invoking th IExampleService startMethod() with its decorated implementation, so we are using the starExample() extended functionality without inheritance. The important thing is that every class doesn't know what kind of IExampleService it's using. Furthermore it'is possible to inject the extended functionality as default service because we have annotated the ExampleDecoratorService with @Primary annotation.

It's possible to create more decorators with the same approach but you have to explicitly inject a named component with @Qualifier annotation to annotate a generic decorator beahavior implementation.

Conclusions

I just used this pattern to decorate a Mapper service component that is reponsible to map a bean properties to another bean, but there are many fields of use of the decorator pattern so don't be scared to decorate too much your application :). If you want to see the entire working example you can check out my repository, hope it will be useful.

]]>
Java Bean Mapper Comparison http://www.luigibifulco.it/blog/it/blog/java-bean-mapper-comparison blog/java-bean-mapper-comparison r In my development experience i always had to use a software layer to copy the values from a bean to another bean. This technique, can be applied in many ways and it is very useful when you have to decouple a domain model from another, or simply to decouple client model from server model. For example, in an layered architecture, it is not reccomended to expose directly the entity read from DB on a facade layer.
It is reccomended instead, to expose a model that we'll call the DT Model; an instance of a class from this domain is a Data Transfer Object, or simply a DTO. A DTO is the object that you really want to expose and to keep the other objects in the internal layers there is one way: you have to copy the values from the internal bean to the DTO.

Mapping techniques

A Java Bean Mapping framework solves these problems, there are many kinds of java bean mapping techiniques:

  • Simple Pojo Mapping
  • Flattening mapping
  • Projection mapping
  • Complex Pojo Mapping

Probably you will need all of them and for each you have to deal with some aspects such as:

  • Property mapping (deep, skip, recursive)
  • Custom type conversion
  • Validation

Runtime VS Compile-time Conversion

For every developer the best way to do the hard work is to automate the process of copying values from source bean to the destination bean. There area many frameworks that do automatic mapping with a little effort by developers, the only difference between the various frameworks is how they store and collect the mapping info. There are two main type of mapping conversion:

  • Runtime automated conversion
  • Compile time automated conversion

The first uses informations written in XML files or in Java annotations to know what type and what fields it has to map. Tipically these types of mapper use reflection to scan java bean structure and to recognize which field has to be read from source class and in which field it has to write the value to target class.

The second uses informations given, such as Java annotations or XML config files, to simply generate Java source code or to enhance a class file respectively before or during compilation phase.
This techinique ensure good performance because the hard work is made only one time, during compilation. However class enhancement can be done at runtime too, when application starts for first time.

What i have to use?

If you have to copy properties and you don't need all other aspects in Bean Mapping you are free to use tools like Apache Common BeanUtils or Spring BeanUtils.

Dozer

The most used mapping framework i know is Dozer from Apache Software Foundation. Dozer can be used with XML Files or Annotation to write mappings. A common usage is to declare the mapper in CDI or Spring container and to load all mappings from XML files, every time you need to map beans you can call the map method:

<bean class="org.dozer.spring.DozerBeanMapperFactoryBean">
   <property 
                  name="mappingFiles" 
                  value="classpath*:/dto-mapping-*.xml">
   </property>        
 </bean>

@Inject
private Mapper mapper;

DestObject destObject  = mapper.map(sourceObject, DestObject.class); 

Basically Dozer can do many other things: you can specify BeanFactory or custom contervers and when you declare a mapping it enables to write deep property map to implement flattening or projections conversion.
Dozer makes heavy use of reflection to scan properties and to do method invocation of getters and setters.

ModelMapper

Another bean mapping framework i used is ModelMapper. An intelligent model mapping framework, it uses some conventions on field names to determine how data should be mapped. For example if you have:

// Assume getters and setters on each class
class Source {
 Vehicle vehicle;
 Equipment equipment;
}

class Vehicle {
  String type;
  String model; 
}

class Equipment {
  String code;
  String description;
}

you can map properties in a flat object like this:

// Assume getters and setters
class TransportDTO {
  String vehicleType;
  String vehicleModel;
  String vehicleEquipmentDescription;
}

assuming you have a Vehicle instance, the mapper will automatically generate a TransportDTO for you:

ModelMapper modelMapper = new ModelMapper();
TransportDTO  trDTO = modelMapper.map(vehicle, TransportDTO.class);

MapStruct

I really love this framework beacuse basically it makes use of code generation to do the mapping in a static way. The generated mapping is based on a simple java method invocation thus is faster than reflection base mapping framework. MapStruct make use of annotation processor for generating source code and can be easily plugged to the most used build tools like Maven, Gradle or Ant.
MapStruct has a nice Java8 implementation, to integrate it with Gradle you can use this script:

ext {
    javaLanguageLevel = '1.8'
    generatedMapperSourcesDir = "${buildDir}/generated-src/mapstruct/main"
}

sourceCompatibility = rootProject.javaLanguageLevel

configurations {
    mapstruct
}

dependencies {
    compile( 'org.mapstruct:mapstruct-jdk8:1.0.0.Final' )
    mapstruct( 'org.mapstruct:mapstruct-processor:1.0.0.Final' )
}

sourceSets.main {
    ext.originalJavaSrcDirs = java.srcDirs
    java.srcDir "${generatedMapperSourcesDir}"
}

task generateMainMapperClasses(type: JavaCompile) {
    ext.aptDumpDir = file( "${buildDir}/tmp/apt/mapstruct" )
    destinationDir = aptDumpDir

    classpath = compileJava.classpath + configurations.mapstruct
    source = sourceSets.main.originalJavaSrcDirs
    ext.sourceDestDir = file ( "$generatedMapperSourcesDir" )

    options.define(
        compilerArgs: [
            "-nowarn",
            "-proc:only",
            "-encoding", "UTF-8",
            "-processor", "org.mapstruct.ap.MappingProcessor",
            "-s", sourceDestDir.absolutePath,
            "-source", rootProject.javaLanguageLevel,
            "-target", rootProject.javaLanguageLevel,
        ]
    );

    inputs.dir source
    outputs.dir generatedMapperSourcesDir;
    doFirst {
         sourceDestDir.mkdirs()
    }
    doLast {
        aptDumpDir.delete()
    }
}

compileJava.dependsOn generateMainMapperClasses

For defining a mapper with MapStruct you have to write a simple java interface with one or more map methods and annotate it with a @Mapper annotation and annotate methods with Mappings annotations to give the mappings rule:

@Mapper(defaultComponentModel="spring")
public interface VehicleMapper{

    @Mappings({
        @Mapping(source = "vehicle.type", target = "vehicleType"),
        @Mapping(source = "vehicle.equipment.desc", target = "vehicleEquipDesc")
    })
    TransportDTO vehicleToTransport(Vehicle v);    
}

When you compile the Mapper interface MapStruct will generate a Java class with a default name (in this case VehicleMapperImpl). The vehicleToTransport method can be invoked to do the mapping. Another useful thing is the CDI/Spring integration, simply adding the defaultComponentModel attribute on the interface, the generated source will contains CDI or Spring annotations so the Mapper can be injected in your SpringBeans or EJB.

Conclusions

If you don't have particular constraints i believe that Mapstruct is definitely the best way to realize Java Bean Mapping since it has the same Dozer features but it is more fast.

]]>
JAX-RS: Generare un client REST da una interfaccia Java con RestEasy. http://www.luigibifulco.it/blog/it/blog/jax-rs-generate-client-from-interface blog/jax-rs-generate-client-from-interface r Alcuni giorni fa mi sono imbattuto in un problema che forse già in molti hanno dovuto affrontare e per il quale in pochi mi hanno saputo dare un consiglio o una risposta certa per risolverlo; vuoi per pigrizia o per mancanza di necessità insomma nessuno mi ha saputo dire con quale framework potevo risolvere il seguente problema: data una interfaccia Java con tanto di annotations JAX-RS (2.0) esiste un modo per generare un client Http in Java??
In termini di design-pattern ciò di cui avevo bisogno è un proxy Rest. Ci tengo ad enfatizzare questo aspetto poiché le parole chiave che mi hanno aiutato nella ricerca della soluzione si sono rivelate davvero importanti. Ma veniamo a noi....allora la buona notizia è che esiste una soluzione chiavi in mano, la cattiva notizia è che non si tratta di un metodo standard previsto dalla specifica JAX-RS, tuttavia sono pienamente convinto che la tecnica che vi mostrerò verrà sicuramente contemplata nelle future versioni dello standard. Allo scopo, ci viene in aiuto un framework, che mi ha fatto risparmiare un bel po' di tempo, trattasi di Resteasy: un REST framework sviluppato da JBoss.

Resteasy è paragonabile a framework come Jersey, Apache CXF o Spring Rest Template, in pratica tutti implementano la specifica JAX-RS e risolvono tutti lo stesso problema di base, in più ognuno offre qualche caratteristica aggiuntiva per agevolarci durante lo sviluppo di Rest Services.

Ad esempio, Reasteasy, come Jersey, offre un framework per la parte server-side, un framework per scrivere i test unitari e delle estensioni alle API lato client. Ovviamente le API lato client non sono necessarie se non abbiamo bisogno di invocare RestService da un ambiente diverso dal browser.

Come tutti sappiamo JAX-RS fornisce delle annotations per generare un servizio Rest da un interfaccia Java, o meglio per generare uno stub del servizio che è capace di coprire aspetti che normalmente un servizio Rest offre in quanto tale, ovvero binding dell'operazione al metodo HTTP, modalità di serializzazione dei dati, etc.
Ad esempio il seguente servizio, mappa due operazioni una di tipo GET e l'altro di tipo PUT:

public interface RestService
{
   @GET
   @Path("get")
   @Produces("text/plain")
   String get();

   @PUT
   @Path("put")
   @Consumes("text/plain")
   void put(String body);

}

Se dovessimo sviluppare un client rest normalmente dovremmo istanziare un client http e invocare le URL che mappano le operazioni REST, in più dovremmo controllare lo stato della risposta, leggere e deserializzare il payload. Con un set minimo di librerie base e un po' di integrazione si riuscirebbero a coprire tutti questi aspetti oppure possiamo decidere di usare Resteasy Proxy Framework che con poche linee di codice ci permetterà di fare tutto quello che abbiamo appena descritto .... e devo dire che lo fa anche bene :).
Quindi per generare il nostro proxy ci basterà utilizzare questo code snippet e il gioco è fatto:

Client client = ClientFactory.newClient();
WebTarget target = client.target("http://example.com/base/api");
ResteasyWebTarget rtarget = (ResteasyWebTarget)target;

RestService service = rtarget.proxy(RestService.class);
service.put("hi,  i'm invoking RestService in a simple way");

Il cuore di questo pezzo di codice è il metodo proxy. Ciò che abbiamo fatto è stato semplicemente passare l'interfaccia del servizio al metodo proxy in modo da farci restituire un client http funzionante. Da questo momento in poi tutte le chiamate ai metodi scateneranno delle richieste http che rispecchiano esattamente ciò che si aspetta il servizio descritto dalle annotation JAX-RS. In altre parole abbiamo ottenuto il lato opposto di ciò che normalmente fa un framework Rest per generare la parte server.

Buon
rest
client a tutti :)

]]>
DSL in linguaggi OO http://www.luigibifulco.it/blog/it/blog/dsl-in-java blog/dsl-in-java r In questo articolo vi mostrerò una semplice tecnica che evidenzia un concetto molto potente della programmazione, ovvero la possibilità di poter creare un DSL (Domain Specific Language). Un DSL ci permette di scrivere codice pulito e di poter impostare la scrittura del codice di dominio in modo semplice e funzionale. Nella programmazione orientata agli oggetti tale concetto è applicabile utilizzando insieme diversi design-pattern e interfacce di tipo "Fluent". Per semplicità immaginiamo di sviluppare per il dominio automobili e di dover rappresentare una "preview" di un'auto. La cosa che ci viene immediato fare è creare il bean Car con le sue proprietà.....

// imports...

public class Car {

   private String brand;
   private String engineType;
   private int passengerCount = 2;

   // getters and setters for each field
} 

...ogni volta che abbiamo bisogno di creare un oggetto Car ci viene naturale istanziare e impostare le proprietà dell'oggetto in questo modo...

Car car = new Car();
car.setColor(RED);
car.EngineType("DIESEL");
car.setBrand("Fiat"); 

Un DSL (nell'esempio specifico un Internal DSL) ci permette di evitare di scrivere codice in OO style e di immaginare la scrittura di codice in maniera più funzionale. Per creare un DSL bisogna innanzitutto stabilire quale aspetto del dominio vogliamo rendere funzionale e quali funzioni vogliamo dare, l'insieme delle funzioni sarà il nostro DSL.
Nel nostro caso ci piacerebbe avere un DSL per la creazione di automobili del tipo:

/*creaAuto().diColoreRosso().adAlimentazioneDiesel().con4Posti() */

che dal punto di vista funzionale diventa:

/* automobile = crea()
                      .automobile()
                      .colore("rosso")
                      .alimentazione(benzina)
                      .posti(4);
*/

Per ottenere lo stesso effetto in Java abbiamo bisogno di un oggetto intermedio che ci permette di creare oggetti di tipo Car e di esporre i metodi di facciata per la modalità di creazione e impostazione delle proprietà, ad esempio la classe CarBuilder scritta in questo modo, può fare al caso nostro:

public class CarBuilder {

   public static Car newCar() {
     return new CarBuilder();
   }

   private final Car car;

   private CarBuilder() {
     car = new Car ();
   }

   public Car build() { return car; }

   public CarBuilder brand(String brand) {
     car.setBrand(brand);
     return this;
   }

   public CarBuilder engineType(String engineType) {
     car.setEngineType(engineType);
     return this;
   }

   public CarBuilder passengers(int passengers) {
     car.setPassengerCount (passengers);
     return this;
   }
} 

A questo punto creare oggetti di tipo Car diventa veramente semplice, ma l'aspetto davvero importante è che abbiamo creato un vero e proprio linguaggio funzionale alla creazione di oggetti Car.

Car car = CarBuilder.newCar()
                     .brand("Fiat")
                     .color(RED)
                     .engineType("DIESEL")
                     .passengerCount(4)
                     .build();

L'esempio è davvero banale ma esprime concetti davvero potenti. Inoltre con Java8 risulta ancora più semplice applicare concetti di questo tipo.
La cosa importante è capire che possiamo sfruttare in un solo colpo due tipi di linguaggi quello Java che ci garantisce il mantenimento di informazioni strutturali e il controllo sui tipi evitando di fare casini e quello funzionale (il DSL) che ci permette di by-passare il compilatore quando ad esempio desideriamo semplicemente creare "un auto solo di colore rosso " oppure un "auto modello Fiat" :)

]]>
Nunchuck.js - How to move and rotate a 3d Cube http://www.luigibifulco.it/blog/it/blog/nunchuck-js-rotating-cube blog/nunchuck-js-rotating-cube r Today i will show you how i used my nunchuck.js library to remote control a 3D Cube with a nunchuck controller.
If you don't know how to connect and read data from a nunchuck check this article.

Then you can download nunchuck.js library from NPM:

npm install nunchuck-js

The package provides a server that has to be launched where the nunchuck is wired (usually with a RaspberryPi over i2c), the server tries to connect to the device and once started is reachable on port 8888. To start the server launch these two commands:

cd  node_modules/nunchuck.js/src/nunchuck-remote/
node server.js

Open your browser and point to the server:

http://<ip.of.your.raspi>:8888/cube.html

When the server receives a request to cube.html page, it automatically starts connection with the nunchuck and sends data to the browser over a websocket channel. The video posted below shows a live demo on what you can do with this server:

...a closer look...

Essentially we have two basic components the server and the client. The server uses the nunchuck.js modules to read and decode data from nunchuck and sends them as a JSON string over the websocket. On the other side, the client uses the THREE.js library to render a cube then receives and parse the JSON data to rotate and position the cube.

The server

The core components of the server :

  var nunchuckModules = require('nunchuck-js').nunchuck;
  var NunchuckDevice = nunchuckModules.device;
  var NunchuckDecoder = nunchuckModules.decoder;
  var WebSocketServer = require('websocket').server;

Instatiates the nunchuck device and the websocket server:

var nunchuck = new NunchuckDevice(0x52, 1,[]);
wsServer = new WebSocketServer({
    httpServer: server
});

when the client requests a connection the server instantiates the decoder and sends the datas received from the device:

//connection object previously obtained from accept method
  connection.on('message', function(message) {
          if(message.data!=="start"){return;};

          /*initialize the nunchuck*/
          nunchuck.init();
          console.log("nunchuck initialized....");

          /*starts the decoder and send data*/
          var decoder = new NunchuckDecoder(nunchuck);          
          decoder.start(function(stream){
            var obj = decoder.asObject(stream);        
            connection.sendUTF(JSON.stringify(obj));
          });

    });

The client

The client requests a websocket connection and parses the data:

connection.onmessage = function (message) {
    // try to decode json (I assume that each message from server is json)
    //console.log(message);
    try {
      var json = JSON.parse(message.data);
    } catch (e) {
      console.log('This doesn\'t look like a valid JSON: ', e);
    }
    callback(json);
    // handle incoming message
  };

The callback function simply scales nunchuck values to a more comprehensible THREE.js way, for instance acceleration X value is scaled to a range between -1 and 1 with a 3 digits fixed precision. Then passes the values to the render function:

function(o){
    //parse accelerometer and stick values
    var a = o.accelerometer;
    var s = o.stick;

    var normaX = scale(a.aX,0,255,-1,1);
    var normaY = scale(a.aY,0,255,-1,1);
    var normaZ = scale(a.aZ,0,255,1000,2000);
    var normX = scale(s.x,0,255,-1000,1000);
    var normY = scale(s.y,0,255,-1000,1000);

     //render points
    render(normX,normY,normaX/10,normaY/10,normaZ);
  });

The render function uses the THREE.js objects to do the final work:

function render(x,y,ax,ay,z) {
    cube.rotation.x += ay;
    cube.rotation.y -= ax;
    camera.position.z = z;
    camera.position.x =x*-1;  
    camera.position.y = y*-1; 
    renderer.render(scene, camera);
  };

You can check my repo for the complete and working source code. Hope you like it.

Luigi's Dev Corner

]]>
Pi+NodeRed = A lot of fun and less code! http://www.luigibifulco.it/blog/it/blog/raspberrypi-nunchuck-nodered-a-lot-of-fun blog/raspberrypi-nunchuck-nodered-a-lot-of-fun r Let's start from beginning. Some days ago, thanks to a my friend, i discovered the Node-RED project. A great visual tool for wiring IoT devices, and integrate them with API and services.
Another thing very nice is that you can install Node-RED on a RaspberryPi, and wire a lot of nodes. Yes Node-RED has a visual block tools and the blocks are nodes and its built on node.js, so prepare to be confused with all these nodes :). You can wire input nodes with output nodes and put between them functions node, switch nodes and many other useful nodes. There are a lot of core nodes shipped with basic Node-RED distribution.
I just have a RaspberryPi and i wrote a library for the Nunchuck controller in Java, so Node-RED it's a great chance for me to make a porting of the code in Javascript in an elegant way. With Node-RED i have to simply design my library as a set of nodes. Next, i will share with you how i you can use a Node-RED node for a nunchuck controller wired with a RaspberryPi,

What we need:

  • a Raspberry Pi Model B Revision 2.0 (512MB)
  • The latest Raspbian image installed (Jessie while i wrote these lines)
  • A cheap Nunchuck controller
  • An I2C adapter (or similar wiring)
  • A node.js installation
  • A Node-RED installation
  • The node-red-contrib-nunchuck module
  • A lot of patience

For the Raspberry and a Nunchuck it is a commonplace to say that you have to buy them. But don't worry, the entire bundle does not cost too much.
If you just have a Raspberry i suggest to upgrade to Raspbian Jessie so you can install a newer version of Node.Js. Furthermore, it comes with a lot of updated packages, one of them is gcc 4 that it's very important to compile some modules we need.

Wiring the nunchuck on the Pi

The nunchuck controller sends data over an I2C bus. There is a lot of documentation about the I2C protocol, because since October 10, 2006 no licensing fees are required to implement the I²C protocol. So the first thing we have to do is to wire the controller pins to the GPIO pins with the RaspberryPi board. There a lot of guides to do the hard work, i used this doc to understand the basic things, the interesting part for our purpose is to identify the pins for the I2C interface as shown in the image below:

p1-pins

If you have all well done, you should see wired pins as the image below:

pi-i2c1

On the other side and if you won't break the nunchuck you can use a simple adapter, i bought the mod-wii-icsp-nunchuck but you can use the WiiChuck too, the basic difference is that the second comes without pins. So i wired the pins on the ICSP adapter and this is the result:

pi-i2c2

Configuring I2C on the Raspberry

If you have Jessie installed on your Raspberry you don't have to do much work because I2C driver and kernel modules are just installed and ready to use. The only thing you have to check if your /boot/config.txt file has the correct parameters setted. Or simply use the raspi-config to enable I2C under "Advanced Options".
To manual enable I2C add the following line to /boot/config.txt:

dtparam=i2c_arm=on

The default I2C baudrate is 100000. You can modify using this line of code:

dtparam=i2c_arm_baudrate=400000

If you have modified your config.txt file you have to REBOOT the RaspberryPi. Now you can check that it's ok.

Test data reading from Nunchuck

Install the i2ctools and i2cdev libraries on your system:

sudo apt-get update
sudo apt-get install i2ctools libi2c-dev

Keep wired the nunchuck controller with the raspberry and launch to i2cdetect command:

i2cdetect -y 1

you should see an output similar to this shown below, if so your nunchuck controller is correctly wired with your PiBoard and now we can capture data from it using Node-RED:

i2cdetect_output

Installing Node.js, NPM and Node-RED

The official Node-RED site project provides a detailed documentation and there is a section dedicated to the Raspberry PI.
With Jessie distribution Node-RED comes preinstalled on the system but the bad news is that there is an older version of Node.Js and some modules are incompatible. I suggest to remove the default Node-RED installation and to upgrade to newer versione of node.js. First of all remove all node dependencies:

sudo apt-get remove nodered
sudo apt-get remove nodejs nodejs-legacy
sudo apt-get remove npm   

then you can install new dependencies:

wget http://node-arm.herokuapp.com/node_archive_armhf.deb
sudo dpkg -i node_archive_armhf.deb
sudo apt-get install build-essential python-dev python-rpi.gpio

if you don't have npm installed you can install it from Jessie repository:

sudo apt-get install npm

and then you can install node-red directly from npm:

sudo npm install -g --unsafe-perm  node-red

To start Node-RED you can launch this command from shell:

node-red-pi --max-old-space-size=128

a server was spawned on port 1880 and you can use it together with the core nodes of Node-RED. If you never used Node-RED you can follow this tutorial to create your first flow.

Installing the node-red-contrib-nunchuck module

Good guys. We have a RaspberryPi with a nunchuck controller wired on I2C bus interface and a working Node-RED installation, we are Node-RED flow master, so we are ready to capture controller input and create a great "Nunchuck2Pi" flow. :). Node-RED comes with no nodes for nunchuck so i created one. To install the nunchuck node execute these commands from shell:

cd /home/pi/.node-red/
npm install node-red-contrib-nunchuck

if you have compilation errors, probably you don't have lib-dev dependencies, to install them launch:

sudo apt-get update
sudo apt-get install i2ctools libi2c-dev

then you should see a node_modules directory with a node-red-contrib-nunchuck within. Restart Node-RED go to the web visual tool (http://:1880/) a nunchuck node should be available in the input category.

nunchuck-node-palette

Put the nunchuck node and configures it:

nunchuck-node-config

The nunchuck node has one output, a JSON object, for debug purpose you can config the nunchuck node with a low frequency (e.g.: 1000 ms) and connect a debug node to see the object properties sent by the nunchuck node.

nunchuck-first-flow

Creating your first flow with the nunchuck node

To create a simple nunchuck flow you have two ways:

  • import the flow shown below from code (copy and paste)
  • manually create your own flow

In any case you have to use a function node to process data and to recognize something was changed, this is because the node doesn't matter about what changed it simply reads and decodes data from controller at the requested frequency. In future releases i'm thinking to put a config check to change this behavior, such as "send data only if something was changed". The Node-RED nodes philosophy is to do simple things so i'm more disposed to split this nunchuck node in two nodes: the reader and the decoder :).

The example below shows a function node that pipe nunchuck output, recognizes stick moves from X axis and send an event.:

var xevent = msg.payload.x ;
if(context.xevent !== xevent){
 context.xevent = xevent; 
 node.send(msg);
}
return;

Put the function node between the nunchuck node and the debug node:

nunchuck-function-node

Or simply import this snippet:

[{"id":"3818fd96.c7e702","type":"function","z":"e8c028bd.173fd8","name":"processXStickData","func":"var xevent = msg.payload.x ;\nif(context.xevent !== xevent){\n context.xevent = xevent; \n node.send(msg);\n}\nreturn;","outputs":1,"noerr":0,"x":353,"y":158,"wires":[["e7a89ba0.185768"]]}]

Putting all together and create your own flow!! For example I used this simple nunchuck flow to move the PTZ of my ipcam.

put-all-together

Conclusions

Node-RED is a great tool and can be used on many others platforms than the Pi. The IoT world is very tricky and at the same time attractive. I think that Node-RED solves many problems to design what we have in mind and enables new IoT developers to access this fantastic world.

Goodbye from Luigi's Dev Corner.

]]>
CorsProxy: un server http per aggirare le Same Origin Policy http://www.luigibifulco.it/blog/it/blog/cors-with-corsproxy blog/cors-with-corsproxy r State sviluppando in Javascript e avete bisogno di invocare delle XHR su un dominio diverso dal vostro? Bene se le Same Origin Policy vi danno proprio così fastidio e non riuscite a mettervi d'accordo per inserire gli header previsti per fare CORS ( Access-Control-Allow-Origin, etc), vi consiglio di provare questo simpatico tool che vi permette di aggirare facilmente la Same Origin Policy.

Per chi non lo sapesse le Same Origin Policy sono delle regole di sicurezza dei browser e prevedono la possibilità di eseguire del codice Javascript interoperabile solo con il DOM di risorse scaricate dallo stesso dominio (ovvero il same origin). Tale concetto viene esteso anche alle XHR, quindi se scarico il codice Javascript dal dominio A che tenta di aprire una XHR verso il dominio B, un browser che rispetta queste ormai consolidate regole di sicurezza mi blocca la XHR poiché riconosce che si sta tentando di accedere ad un dominio diverso da quello di origine. Per farla breve se scarico questo codice Javascript dal dominio http://127.0.0.1:8080:

var request = new XMLHttpRequest();
var url = "http://www.luigibifulco.it/blog/it"
request.open("GET", url, true);
request.onload = onload;
  function onload() {
          if (request.status === 200) {
              console.log("OK")
          } else {
              console.error("Status code was " + request.status);
          }
      }

non funzionerà per i motivi che vi ho già spiegato, nella fattispecie il dominio 127.0.0.1:8080 è diverso da www.luigibifulco.it!!

Il CORS è un meccanismo per condividere risorse tra domini diversi tra loro in modalità trusted. In pratica se il dominio A apre una XHR verso il dominio B, B a sua volta può rispondermi con un header per dire ad A, "si mi ricordo di te", oppure "no non ti conosco". Quindi se nella risposta HTTP B mi risponde con:

Access-Control-Allow-Origin: A

allora la XHR non mi verrà più bloccata dal browser. Per fare questo tipo di CORS è necessario però mettersi d'accordo con il proprietario del dominio che dovrà condividere le risorse.

Cors-Proxy non è altro che un server http che fa da proxy per le richieste verso altri domini. La caratteristica interessante di questo proxy è che ci permette di inoltrare le richieste verso gli altri domini utilizzando delle url del tipo:

 "http://localdomain:localport/externaldomain:externalport/path/to/resource"

Si può installare da linea di comando con NPM:

npm install -g corsproxy

una volta installato basta dare il comando corsproxy avviando così un server http sulla porta di default 1337. A questo punto possiamo provare una richiesta verso il mio blog per fare un test:

"http://127.0.0.1:1337/www.luigibifulco.it/blog/it"

Corsproxy può essere tranquillamente utilizzato per fare CORS senza aspettarsi header particolari dal dominio target. Il trucco c'è e si vede chiaramente, infatti il "Same Origin Domain" diventa "127.0.0.1:1337".
Quindi l'invocazione della XHR al dominio esterno di prima potrà essere fatta in questo modo:

var request = new XMLHttpRequest();
var proxy = "http://127.0.0.1:1337/";
var url = proxy+"www.luigibifulco.it/blog/it"
request.open("GET", url, true);
request.onload = onload;
  function onload() {
          if (request.status === 200) {
              console.log("OK")
          } else {
              console.error("Status code was " + request.status);
          }
      }

Ovviamente dovremmo scaricare il codice accedendo dal proxy :).
Un saluto e alla prossima.

]]>
GWT 2.8.0 e JsInterop http://www.luigibifulco.it/blog/it/blog/gwt-2-8-0-jsinterop blog/gwt-2-8-0-jsinterop r GWT 2.8.0 è stato (quasi) rilasciato

Mentre scrivo queste righe è già da un mesetto che è stata rilasciata la Beta1
di GWT 2.8.0 che di fatto diventerà la RC1. Infatti per il momento l'unica differenza tra la Beta e la RC è che la Classic Dev Mode sarà ufficialmente
deprecata e quindi non più supportata.

EDIT: prima di continuare a leggere è bene che tu sappia che sul sito ufficiale del progetto GWT sulle note di rilascio della 2.8.0 beta è stata riportata la specifica finale della JsInterop, per la quale appena possibile scriverò la seconda parte di questo post

EDIT: [aggiornamento al 29 Luglio 2016] sul repository ufficiale sono presenti le note di rilascio della RC1 di GWT 2.8 la novità più interessante è l'emulazione Java 8 delle nuove API dell'SDK (interfacce funzionali, stream, etc), correzione di bug importanti durante la fase di compilazione, e compilazione JS con le nuove keyword di ES6

Una piccola nota dolente di questo rilascio è la scarsa nota di degno che sta avendo sul sito gwtproject.org, mi stupisce come non sia stata ancora enfatizzata la Js Interoperability che di fatto rivoluzionerà l'approccio di GWT verso Javascript. C'é anche da dire che lo stato dell'arte è una beta quindi tutto può cambiare. Ultimamente GWT è stato un po' offuscato dall'imminente ES6. La verità è che GWT continuerà ad esistere e, per la gioia degli sviluppatori Java, permetterà di creare moduli scritti in Java completamente integrabili con Javscript. Infatti tra le novità più importanti di questa tanto attesa release troviamo:

  • il supporto a Java8
  • JsInterop
  • Ottimizzazioni di compilazione delle SDM (Super Dev Mode)
  • Compilazione ES6

Tralasciando la parte sulle doverose ottimizzazioni della SDM mi soffermerei di più sulle prime due. Secondo me non è un caso che siano state rilasciate insieme, Java8 infatti offre delle API e dei costrutti per il supporto alla programmazione funzionale mentre la JsInterop permette di comporre i tipi che vogliamo esportare in Javascript tramite delle annotation pensate per istruire il compilatore a generare il codice che vogliamo esportare. GWT continuerà ad essere uno strumento che permette di colmare le lacune di Javascript offrendo un valido ponte tra il linguaggio Java e il mondo Javascript. Oggi le esigenze sono diverse e di fatto Javascript ha meno lacune da colmare; nonostante esistano validi framework come Angular.Js, Ember, Backbone, Ampersend, e affini non possiamo chiudere gli occhi e non fare i conti con l'avvento di ES6, poiché i linguaggi a supporto di questo standard cambieranno il modo di approcciarsi a Javascript. GWT sfruttando Java8 e JSInterop sta anticipando i tempi e di fatto potrà porsi architetturalmente al di sopra di queste evoluzioni di Javascript. Il risultato finale sarà una perfetta amalgama tra i prodotti della compilazione GWT e i moduli Javascript (ESX style) .

Il pezzo mancante

Se pensiamo al fatto che Javascript offre già costrutti a supporto della programmazione funzionale è facile intuire come JsInterop sia il pezzo mancante del ponte di comunicazione tra Java e Javascript. Mi riferisco al fatto che prima risultava non immediato, (ma non impossibile) esportare il risultato della compilazione di GWT da un tipo Java a un namespace Javascript. Praticamente JsInterop ci aiuta a scrivere codice pulito proprio per esportare le nostre librerie Java e poterle utilizzare in Javascript.

Uno sguardo più da vicino

Questa è la nostra classe java
package it.luigibifulco;

@JsType
public class MyJsType {
  public boolean bool = true;

  public MyJsType(boolean bool) {
    this.bool = bool;
  }

  public String aPublicMethod() {
    return "Hello ";
  }

  public static String aStaticMethd() {
    return "What's the meaning of life?";
  }
}
Ecco come possiamo usarla in Javascript dopo l'export di JsInterop
   var myType = new it.luigibifulco.MyJsType();

   if (myType.bool) {
       alert("Ask me what's the meaning of life...");
   }

L'idea di avere un core ben strutturato e ben definito con un linguaggio fortemente tipizzato come Java e riuscire ad utilizzarlo per creare velocemente funzionalità con un linguaggio scarsamente tipizzato come Javascript non è una grande novità, ma è sicuramente una strategia vincente. Sfortunatamente devo dire che vedo pochi, anzi pochissimi, progetti con una architettura del genere, ciò forse è dovuto alla complessità di manutenzione di uno stack del genere. Con l'avvento di JsInterop credo che gran parte di questi problemi siano risolti poiché la fase di traduzione e di export del modulo Java al modulo Javascript sarà totalmente gestita da GWT .
Lo sviluppatore si dovrà preoccupare solamente di istruire il compilatore per fargli capire cosa deve esportare durante la fase di compilazione. Abbiamo già visto infatti l'annotation @JsType che praticamente permette di marcare tutte le nostre classi che saranno esportate in un namespace Javascript, dove il namespace di default è il GLOBAL namespace.

In realtà esistono altre annotation di JsInterop per esportare proprietà metodi e perfino per non esportare alcuni metodi e proprietà di un JsType. Vediamole più da vicino.

@JsType

Come vi ho già detto l'annotation @JsType permette di istruire il compilatore per esporre un tipo Java al mondo Javascript. Una caratteristica interessante di @JsType è che non segue l'ereditarietà dei tipi Java, quindi bisogna esplicitamente annotare anche i tipi di una classe di figlia nonostante estenda una classe padre già annotata con JsType. JSType in presenza di ereditarietà si comporta piuttosto bene. Ad esempio:

Supponendo di avere questo scenario
package it.luigibifulco;

@JsType
public class Parent {

 public void String parentMethod() {
   return "parentMethod";
 }

 public static Child createChild() {
   return new Child();
 }

}

public class Child extends Parent {

 public void String childMethod() {
   return "childMethod";
 }

}
Il risultato sarà il seguente
var child = it.luigibifulco.Parent.createChild();

child.parentMethod() //it works 

child.childMethod(); //WARNING breaking code it will not works

In pratica il compilatore si preoccuperà di esportare solo ciò che gli abbiamo suggerito e avendo dichiarato i metodi della super classe come pubblici si è preoccupato di esportarli in automatico. Riusciremo quindi a creare un tipo della classe figlia poiché viene utilizzato da un metodo della classe padre ma non riusciremo ad invocare il metodo della classe figlia poiché non abbiamo mai istruito il compilatore di dover esportare anche la class Child. A rigor di logica mi sembra che questo tipo di approccio non faccia una piega :).

@JsMethod, @JsProperty, @JsConstructor

Come avete potuto notare con @JsType possiamo esportare tutto quello che abbiamo dichiarato nella nostra classe. Se vogliamo esportare solo una parte del tipo Java verso il mondo Javascript ci vengono in aiuto le altre annotation di JSInterop per annotare solo alcune pezzi di una classe. @JsMethod da utilizzare per esportare un pezzo come metodo, @JsProperty da utilizzare per esportarli come attributi della nostra classe Java e infine @JsConstructor per esportare un metodo o un costruttore java come costruttore Javascript.

Ad esempio:
package it.luigibifulco;

public class Vehicle {

 @JsProperty
 public int wheels;

 @JsConstructor
 public Vehicle(int wheels) {
   this.wheels = wheels;
 }

 @JsMethod
 public String modelType() {
   return "Generic Model";
 }

 @JsMethod
 public static String start() {
   return "Vehicle started";
 }

 public int getWheels() { return this.wheels;}

}
La chiamata al metodo getWheels fallirà perché non è stato annotato e la classe Vehicle non è annotata con @JsType
var car = new it.luigibifulco.Vehicle(4);

var wheels = car.wheels; //it will work

wheels = car.getWheels(); //it will NOT work

In realtà il mapping non è uno-a-uno infatti JsInterop ci permette di esportare metodi Java come proprietà Javascript o come costruttori Javascript.

@JsIgnore

JsIgnore ci torna utile se vogliamo andare per esclusione nel decidere cosa esportare o meno da un tipo Java.

Utilizzando questo approccio:
package it.luigibifulco;

@JsType
public class Vehicle {

 public int wheels;

 public Vehicle(int wheels) {
   this.wheels = wheels;
 }

 public String modelType() {
   return "Generic Model";
 }

 public static String start() {
   return "Vehicle started";
 }

 @JsIgnore
 public int getWheels() { return this.wheels;}

}

abbiamo di fatto ottenuto lo stesso risultato di prima con due sole annotation.

JsFunction

Una annotation degna di nota è la @JsFunction che ci permette di esportare una interfaccia Java come una funzione Javascript e che potrà essere utilizzata come closure in Javascript quando dichiariamo come parametro di input l'interfaccia Java. Questo approccio è davvero semplice ed efficace poiché abbiamo la possibilità di scrivere un contratto tra chiamante e funzione chiamata. Un'aspetto davvero interessante è che abbiamo la possibilità di iniettare dei valori alla closure. Non ci avete capito nulla? Niente paura l'esempio che vi mostro di seguito vi chiarirà tutto:

Java

@JsFunction
interface CommandFunction {

  int exec(int requestNumer);

}

@JsType
class Executor {

  public static int action(CommandFunction cmd) {
     return cmd.exec(40);
  }

}
Javascript
it.luigibifulco.Executor.action(
  function(cmdId) {     
     console.log(cmdId); //it will print 40
     return commandExecuted();
    }); //

  function commandExecuted(){
    return "0";
  }

Per semplicità in questo caso abbiamo iniettato, banalmente un CmdID del comando, avrebbe molto senso sfruttare questa caratteristica per iniettare un gestore degli eventi ad un controller :) .

Namespace

Ogni annotation di JsInterop offre un parametro namespace che ci permette di creare dei veri e propri moduli Javascript e in generale di gestire il modo in cui i nostri tipi Java saranno esportati in Javascript.

@JsType(name = "MyType", namespace = "lb")

In questo modo si può fare in modo che la classe MyType sia utilizzabile dal namespace lb

lb.Mytype

E non finisce qui! Possiamo creare veri e propri package e mapparli con un namespace javascript sfruttando il file package-info.java:

@jsinterop.annotations.JsPackage(namespace = "lb")
package it.luigibifulco

....attivare la JsInterop

Per avviare la compilazione JsInterop bisogna attivare un flag del compilatore di GWT

-generateJsInteropExports true

Il consiglio che posso darvi è provarla subito. Le impressioni sono davvero buone, GWT+JsInterop allenta il gap esistente tra Java e Javascript diminuendo l'effort di sviluppo e permettendo di integrare moduli Java e moduli Javscript già esistenti. Prima di creare questo articolo ero indeciso se usare Typescript o GWT ma con JsInterop ogni dubbio è stato fugato.

]]>
Padroneggiare il module pattern: javascript e global scope http://www.luigibifulco.it/blog/it/blog/javascript-mastering-global-scope blog/javascript-mastering-global-scope r var Module = (function () { // code we want to isolate })();

Quale modo migliore per iniziare questo articolo se non con un paio di linee di codice?
Ebbene si, in Javascript, il module pattern non è un opzione, è assolutamente necessario. Se non volete avere guai con il global scope, vi consiglio di seguire alla lettera i consigli che troverete nelle prossime righe.

In un universo parallelo ...(senza moduli)

Immaginiamo di voler sviluppare le API di una calcolatrice:

//calculator API
type = 'NORMAL'

init = function(type){//initialize calculator type
   type = type;
}

switchType = function(type){
      type = type;
}
sum = function (a,b){return a+b;}
diff = function (a,b){return a-b;}
prod= function(a,b){return a*b;}
div = function(a,b){return a/b;}

showCalculator = function(){ //show calculator by type

    if(type==='NORMAL'){
     //show normal calculator
    }
    else{
     //show advanced calculator
    }
}

in questo modo le variabili sum, diff etc. dichiarate come funzioni saranno accessibili da qualsiasi scope e quindi ad es: la chiamata a funzione:

sum(1,2);

andrà a buon fine e potrà essere invocata da qualsiasi punto del codice... ma potrà anche essere malauguratamente sovrascritta. Immaginiamo ora di proseguire con lo sviluppo della nostra calcolatrice decidendo di estendere la nostra applicazione con una calcolatrice scientifica, la prima cosa che ci viene naturale fare è riutilizzare le funzioni già realizzate e magari aggiungere l'operazione potenza:

pow = function(a,b){
 if(type==='ADVANCED'){
        return Math.pow(a,b);
   }
}

Global scope pollution

Il global scope pollution, letteralmente inquinamento del contesto globale, è la cattiva pratica di dichiarare oggetti globali in Javascript, e che in quanto tali potrebbero essere utilizzati in altri pezzi di codice e che potrebbero a cambiare il comportamento del nostro software con effetti decisamente non voluti.
Nell'esempio delle API della calcolatrice abbiamo inquinato il global scope con la variabile type...
Ora provate a chiedervi cosa succederebbe se provassimo a fare una cosa del genere:

init('NORMAL');
type='ADVANCED'; // type is global and can be manipulated by other scripts....

In realtà quello che vorremmo è l'utilizzatore delle Calculator API non abbia la possibilità di accedere alla variabile type né tanto meno possa avere la possibilità di sovrascriverla. Dietro questo banalissimo esempio si nascondono concetti molto importanti:

  • Javascript ha un unico namespace globale degli oggetti.
  • Le variabili con scope globale sono accessibili e modificabili da qualsiasi altro script.
  • E' scoraggiata la dichiarazione di oggetti nel global namespace
  • E' bene dichiarare nel global namespace o per meglio dire esportare solo gli oggetti che effettivamente vogliamo esporre e tramite i quali sarà possibile invocare i metodi da esso esposti o alle proprietà pubbliche.

Modular Calculator:

Ecco come diventerebbe il nostro Calculator nella sua versione modularizzata:

var Calculator = (function(){
         var type = 'NORMAL'; //default type

          var normalCalculator = {};

         var sum = function(a,b){
                      return a+b;
          }
          var diff= function(a,b){
                     return a-b;
          }
           var prod = function(a,b){
                     return a*b;
          }
          var divide = function(a,b){
               return a/b;
          }
          normalCalculator.sum = sum;
          normalCalculator.diff= diff;
          normalCalculator.prod=prod;
          normalCalculator.divide=divide;

          return normalCalculator;
})();

Innanzitutto cominciamo col dire che l'unico oggetto globale dichiarato è la variabile Calculator che di fatto rappresenta il nostro modulo. Le uniche funzioni invocabili da questa variabile sono quelle che abbiamo restituito con l'oggetto normalCalculator, la cui visibilità resterà locale alla funzione anonima. Ultimo ma non meno importante: tutto ciò che non viene restituito dal modulo di fatto non risulterà visibile.
Inoltre il modulo sarà facilmente manutenibile poiché il codice ad esso inerente è ben circoscritto e facilmente leggibile. Di fatto possiamo già utilizzare le API in questo modo:

var result = Calculator.sum(1,2);
cosole.log(result); //prints 3

Estendiamo il nostro modulo...

Volendo possiamo estendere il nostro modulo riutilizzando i metodi di facciata già esposti. Infatti si potrebbe tranquillamente creare un modulo AdvancedCalculator che esporrà l'operazione aggiuntiva pow:

var AdvancedCalculator = (function (NormalCalc) {

    NormalCalc.pow = function (a,b) {
        return Math.pow(a,b);
    };

    return NormalCalc;

})(Calculator || {});

avendo due moduli separati il nostro codice risulta ancora più pulito, tant'è vero che non abbiamo avuto bisogno della dichiarazione della variabile type per modellare il concetto di diverse tipologie di oggetto. Il type nel nostro caso è implicito nell'utilizzo del module pattern:

var result = Calculator.sum(1,2);
cosole.log(result); //prints 3

result = AdvancedCalculator.sum(4,5); //the extended module expose the same functions plus the pow operation
cosole.log(result); //prints 9

result = AdvancedCalculator.pow(2,2); //invoking new operation of the advanced calculator module
cosole.log(result); //prints 4

Nota bene!

result = Calculator.pow(2,2); //NOW WORKING it not throws error

E' doveroso far notare che dopo aver esteso il modulo originario abbiamo perso l'isolamento del modulo Calculator da dove sarà possibile invocare il metodo pow. Niente paura, tutto risolvibile esistono dei pattern anche per questo, per il momento e per non confonderci meglio fermarsi qui.

]]>
Realizzare progetti Javascript Scalabili: Parte 1 http://www.luigibifulco.it/blog/it/blog/large-scale-javascript-projects-1 blog/large-scale-javascript-projects-1 r Large scale e Modular Design

La scalabilità di un progetto è alta se con l'aumentare del numero di funzionalità realizzate il progetto continua ad essere facilmente manutenibile e la creazione di ogni una nuova funzionalità mantiene un basso impatto.
La scelta delle tecnologie a supporto della scalabilità di un progetto è un punto focale. Per garantire la scalabilità, non basta conoscere il "framework" o il linguaggio di tendenza e può venir comodo conoscere i "Pattern" strutturali che ci aiutano almeno concettualmente a modellare il nostro progetto. L'idea che sta alla base dei progetti scalabili è la modularità (Modular Design).
La progettazione modulare permette di pensare il nostro software in tanti piccoli pezzi dove ogni pezzo coprirà una o più funzionalità richieste dal sistema. Possiamo immaginare quindi la progettazione come un puzzle dove ogni pezzo serve il suo compito, ogni pezzo non sa che serve a comporre un unico grande quadro.
Se i pezzi del puzzle si incastrano bene potremmo facilmente incorniciare il nostro puzzle, diversamente ci sarà da rivedere qualcosa quando abbiamo pensato i nostri pezzi.
La mia esperienza sulla progettazione di sistemi software è stata sempre supportata dal linguaggio Java che in termini di scalabilità copre davvero tanti punti, purtroppo non coperti dal linguaggio Javascript. Ma quali sono i punti chiave di un progetto scalabile e soprattutto perché sforzarsi di farlo con Javascript?

La modularità è importante ma non è tutto, infatti se abbiamo tanti moduli e non sappiamo come farli comunicare tra loro, come distribuirli tra diversi gruppi di lavoro, come metterli insieme una volta ricevuti, allora sarebbe bene porsi queste domande e capire come rispondere.

Facciamo un passo indietro....

Per mettere un po' di ordine sarebbe bene capire quali sono i punti a supporto della modularità, ve ne elenco alcuni (cito i più importanti):

  • Possibilità di creare moduli (e fin qui...)
  • Possibilità di dichiarare dipendenze tra moduli
  • Possibilità di distribuire un modulo e le sue dipendenze
  • Possibilità di caricare un modulo e le sue dipendenze
  • Possibilità di installare i moduli senza avere impatti sul sistema
  • Possibilità di attivare e/o disattivare meccanismi di comunicazione tra tutti o un gruppo di moduli
  • Ultimo ma non meno importante Test Unitario dei moduli

Javascript (nella sua versione ES5 [1]) non offre nessun meccanismo nativo per la gestione dei moduli. Per chi proviene da Java ad esempio sa che è possibile dichiarare un Package che conterrà un insieme di Classi e che saranno facilmente distribuibili attraverso un archivio di tipo JAR, tali concetti non permettono in modo automatico di creare moduli come li abbiamo descritti in precedenza ma sicuramente ci agevolano nel realizzarli. In Javascript dimenticate tutto questo : oggetti e First-Class-Function sono le uniche basi che abbiamo per realizzare un sistema modulare. C'è tanta lavoro da fare, ma una volta fatto ne vale la pena.

Perché sforzarsi di modularizzare in Javascript:

Ad oggi Javascript permette di realizzare molte cose e viene usato sempre più spesso per grandi progetti. Avere determinate caratteristiche a supporto di questo linguaggio sta diventando una vera esigenza. Ho visto tanti progetti, medio/grandi realizzati con Javascript e posso assicurarvi che il refactoring e la manutenibilità non sono certo una passeggiata, specie se si tratta di single page app e rich client.
Node.JS, TypeScript, Babel sono ormai esempi calzanti di infrastrutture basate su Javascript che forniscono meccanismi "naturali" per modularizzare il nostro sistema. Babel e TypeScript di fatto sono estensioni di Javascript che prevedono una fase di compilazione, e di fatto implementano ES6. Avere il supporto semi-nativo alla gestione dei moduli purtroppo non basta poiché non si possono mettere da parte tutte le librerie che non sono scrite in TypeScript[2] o con Babel e affini.

L'idea di modulo

Un modulo è un pezzo completamente indipendente, in quanto non ha nessuno riferimento ad un altro modulo della nostra applicazione, l'unica cosa che un modulo deve sapere è cosa esporre. Un modulo deve essere auto-consistente. In una applicazione Web , ad esempio, ci piacerebbe avere un modulo di Login che offre una View in HTML e stili CSS, un controller della View e perché no le funzionalità di un servizio di autenticazione utilizzabili dal nostro controller[3].

L'idea di dipendenza tra moduli

Sarebbe utile poter importare il nostro modulo di Login nella nostra applicazione, configurarlo, avviarlo, stopparlo e perché no disinstallarlo o disabilitarlo in modo che non abbia più impatto sulla nostra applicazione.

L'idea di comunicazione tra moduli

Se la nostra applicazione ha bisogno di sapere che nel modulo di Login è avvenuta una autenticazione con successo o l'utente ha digitato degli input non validi sarebbe utile esporre delle funzionalità base di facciata per sottoscriversi alla ricezione di eventi, in puro stile event-driven.

L'idea di distribuzione di un modulo

Un modulo potrebbe essere impacchettato ed etichettato con una versione. La nostra applicazione che importa il modulo di Login potrebbe dichiarare la dipendenza con tale modulo, ad esempio, alla versione 1.0 oppure alla versione 2.0.

Il module pattern in Javascript

Come abbiamo già detto Javascript non offre nessun meccanismo nativo per la definizione di moduli. La buona notizia è che in Javascript qualsiasi cosa è modellabile come un oggetto che, in quanto tale, espone proprietà e metodi. Ciò viene garantito, paradossalmente, dall'aspetto funzionale del linguaggio Javascript. In sostanza, con semplici concetti base e lavorando un po' di immaginazione, è possibile creare semplici moduli in javascript.
Un esempio molto semplice per rendere l'idea del module pattern in Javascript potrebbe essere:

var module = (function() {
  //all module methods goes here
    function privateMethod() {
        //...
    }

    function privateMethod2() {
        //...
    } 
    return {
       //return a facade for your module :)
        publicMethod: function() {
            privateMethod();
        }
    }
})();

Un esempio molto banale ma allo stesso tempo efficace: questo modulo implementa una serie di funzionalità come metodi privati e sa cosa deve esporre restituendo una facade dei metodi pubblici. Il tutto viene guarnito dalla IIFE (immediately-invoked function expression) finale che permette di restituire ed assegnare alla variabile module il nostro modulo.A questo punto saremo in grado di invocare il metodo pubblico:

module.publicMethod();

Ovviamente non è tutto rose e fiori, infatti per poter usare il nostro modulo l'interprete Javascript deve poter caricare i sorgenti dal file dove è stato dichiarato. Un approccio semplice potrebbe essere quello di caricare tutti i nostri moduli in sequenza... o ancora meglio caricarli quando servono in modalità asincrona. Per risolvere questi problemi sono stati realizzati strumenti specifici e molto potenti per caricare moduli, definirli e mantenerli divisi in più file.Personalmente mi trovo molto bene con RequireJs. Notate ad esempio come la definizione di un modulo con RequireJS risulta molto più leggibile:

define('exampleModule', function () {
    return {
        publicMethod: function () {
            return 'I'm a public method of this module';
        }
    };
});

Torneremo più nel dettaglio su RequireJS poiché sarà uno degli strumenti fondamentali per realizzare un progetto Javascript scalabile. Per il momento ci basta sapere cosa è un modulo, come è possibile crearlo in Javascript e che esistono strumenti come RequireJS che ci semplificano la vita in merito.

[1]in ES6 è prevista una sintassi che permetterà di creare moduli, importarli ed esportarli.
[2] Con TypeScript è possibile creare dei wrapper di librerie Javascript già esistenti, c'è da dire che a mio avviso la modalità è un po' macchinosa.
[3] In contrapposizione o in parallelo ancora non si è capito esistono i web components che permettono di definire moduli e utilizzarli in una maniera dichiarativa come semplici tag html (ad es: Polymer).

]]>
Windows 10 includerà un sistema di package management stile apt-get http://www.luigibifulco.it/blog/it/blog/windows-10-one-get blog/windows-10-one-get r Dopo l'uscita di Windows10 sarà possibile provare il sistema di CmdLet descritto tempo fa da Garrett Serack in questo articolo. Il nome del progetto è OneGet ed è open source, infatti è presente il progetto su GitHub e la struttura del repository è ben documentata.
Sinceramente non sono riuscito ancora a provare OneGet e ricitando le parole di Garrett:

OneGet is a unified interface to package management systems and aims to make Software Discovery, Installation and Inventory (SDII) work via a common set of cmdlets (and eventually a set of APIs). Regardless of the installation technology underneath, users can use these common cmdlets to install/uninstall packages, add/remove/query package repositories, and query a system for the software installed. Included in this CTP is a prototype implementation of a Chocolatey-compatible package manager that can install existing Chocolatey packages.

sembra che il problema di avere un repository popolato sia superato poiché OneGet è compatibile anche con i repository di Chocolatey. Effettivamente sia OneGet che Chocolatey sono basati entrambi su NuGet quindi c'era da aspettarselo.

Per chi è abituato ad usare apt-get l'esperienza di utilizzo di OneGet sarà un po' diversa, infatti invece di offrire dei command switches offre una serie di CmdLet. Un esempio di CmdLet per cercare i nostri pacchetti potrebbe essere:

# get a list of registered package sources
PS C:\> Get-PackageSource

Name         Location                      Provider     IsTrusted
 ----         --------                      --------     ---------
chocolatey   http://chocolatey.org/api/v2  Chocolatey   False

oppure per installare un pacchetto:

# Install a package
PS C:\> Install-Package -name zoomit

Name           Version     Status      Source        Summary                                                    
 ----           -------     ------      ------         -------                                                     
zoomit         4.50        Installed   chocolatey     ZoomIt is ascreen zoom and...

Una differenza importante tra OneGet e Chocolatey è che OneGet sarà utilizzabile solamente dalla PowerShell di Windows, mentre Chocolatey una volta installato, sarà utilizzabile anche da una normalissima shell di Windows.

]]>
Chocolatey: package manager per Windows http://www.luigibifulco.it/blog/it/blog/chocolatey-package-manager blog/chocolatey-package-manager r Oggi parliamo di package manager.... per Windows(?). Sicuramente gli utenti di apt-get, il famoso package manager della distribuzione Linux Debian/Ubuntu sapranno di cosa voglio parlare. Un package manager permette di installare delle applicazioni, delle librerie, o più genericamente delle dipendenze presenti su un repository remoto con un semplice comando che di fatto esegue in automatico una serie di passi che normalmente saremmo costretti ad eseguire "a mano".

Un package manager permette di risparmiare quindi una notevole quantità di tempo. Di solito ogni distribuzione Linux ha il suo package manager (slapt per Slackware, yum per Fedora, apt per Debian e Ubuntu).
Purtroppo il sistema operativo di MS, non offre di default un package manager e ad oggi soffre ancora di questa mancanza (solo questa?).

Una piccola nota: distinguerei, nel modo più assoluto, un package manager dagli store delle app per sistemi operativi tipo Android, iOS o WP e affini poiché secondo me un package manager è un qualcosa di più generico e permette di installare una serie di dipendenze sul nostro sistema in modo arbitrario e che per lo stesso motivo risulta essere molto più "customizzabile" rispetto a un sistema che offre il download di applicazioni pronte all'uso.

Fatta la doverosa premessa, posso già dirvi che dopo aver installato e provato Chocolatey sono rimasto molto contento e soddisfatto. Questo package manager per Windows è davvero fenomenale. Si installa da linea di comando con una semplice istruzione e permette di installare una miriade di librerie e applicazioni che normalmente il sistema operativo in questione non offre. Personalmente Chocolatey mi è stato molto utile per automatizzare l'installazione del mio ambiente di sviluppo su Windows; di solito ho bisogno sempre della stessa combinazione di piattaforme, librerie e linguaggi per sviluppare quindi mi è bastato istruire Chocolatey per installare a cascata una serie di dipendenze. Tuttavia potrei tranquillamente aggiungere al mio sistema nuove dipendenze senza dovermi preoccupare dei tediosi passi di installazione, devo solo sperare che il pacchetto sia presente sul repository.

Bene, veniamo a noi...se volete utilizzare Chocolatey, basta installarlo con questa semplice istruzione da una shell di Windows con permessi di Amministratore, (quindi siate sicuri che il cmd.exe sia stato lanciato con l'opzione "Esegui come Amministratore"), a questo punto lanciate il seguente comando:

C:\>@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object     net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Se tutto è andato a buon fine, Chocolatey è stato installato sul vostro sistema e il comando choco dovrebbe essere richiamabile da qualsiasi punto della shell. Con il comando choco potete installare tutti i pacchetti disponibili sui repository di Chocolatey. Ad esempio per installare Java8, Python e Git sul mio sistema mi è bastato dare in sequenza questi tre comandi:

choco install jdk8
choco install python
choco install git

N.B: nel 99% dei casi ho dovuto lanciare la Shell (o Console che dir si voglia, cmd.exe per intenderci) con i permessi di Amministratore. Quando c'è da fare un install, vi consiglio di lanciarla direttamente con tali permessi senza pensarci su due volte :o).

Il comando choco offre tutte le opzioni normalmente offerte da tutti i package manager per cercare i pacchetti, installarli, disinstallarli e aggiornarli.
Il comando più interessante è questo qui:

choco upgrade all -y

che si preoccupa di aggiornare tutti i vostri pacchetti senza bisogno di fare nulla. Dopo aver condiviso con voi le basi di questo fantastico strumento, se siete interessati a smanettare con Chocolatey vi lascio il link della documentazione. Buone installazioni a tutti :)

Luigi

]]>
Lotta alla frammentazione dei sistemi: Sviluppo di Desktop App con Electron http://www.luigibifulco.it/blog/it/blog/desktop-app-with-electron blog/desktop-app-with-electron r Avete mai sentito parlare di Atom? Se la risposta è no allora siamo in due. Sto ancora ripensando come sono meravigliosi questi link ipertestuali e come sia possibile scovare un framework del calibro di Electron mentre in realtà si era in cerca di un semplice text editor.
In pratica stavo cercando un editor testuale leggero per lo sviluppo web e ho letto che Atom poteva fare al caso mio. Inoltre scopro che Atom in pratica è sviluppato con tecnologie web in un "webkit-wrapper". Questa parolina magica ha attirato notevolmente la mia attenzione ora vi spiego perché....

....dovete sapere che il sottoscritto si sta imbattendo da alcuni mesi in una serie di tecnologie e framework volti a risolvere il problema della frammentazione dei sistemi. Oggi risolvere questo problema è possibile grazie ad un principio base, ovvero riutilizzare un'applicazione che di fatto gira in un browser, quindi una webapp, in un contesto di riferimento che la incapsula per farla girare su un altro sistema. Mi spiego meglio: trattandosi di applicazioni web stiamo di fatto dicendo che vogliamo riutilizzare il codice HTML, CSS e Javascript, codice che normalmente viene eseguito da un browser; ora immaginiamo di sfruttare "l'oggetto browser" come sand-box dedicata della nostra applicazione. L'aspetto ancora più interessante di questo scenario è la possibilità di invocare delle chiamate al sistema operativo direttamente dal codice Javascript. Quando una webapp contiene chiamate a codice nativo, ha quindi bisogno di essere linkata a librerie native nella fase di compilazione questa caratteristica rende una webapp una hybrid-app. Con questa tecnica è possibile minimizzare l'impatto che ad oggi le applicazioni stanno avendo dalla frammentezione dei sistemi. Esistono molti framework in ambito mobile per risolvere il problema della frammentazione dei sistemi operativi per tablet e smartphone (Androit, iOS, Windows Phone, Blackberry OS, Firefox OS e chi più ne ha più ne metta), tra questi posso citarvi Meteor, PhoneGap, Cordova, (magari appena ho un po' di tempo spenderò due parole anche su questi tool).

Detto questo possiamo tornare a noi, :). Tornando ad Atom scopro che in pratica è sviluppato con il pattern "app ibrida"... si ma chi c'è sotto? chi opera dietro questo hackable-text-editor? Riporto le prime righe del README di Atom:

Atom is a hackable text editor for the 21st century, built on Electron, and based on everything we love about our favorite editors. We designed it to be deeply customizable, but still approachable using the default configuration.

Ebbene si c'è Electron: un framework che ho provveduto subito a provare e che in pratica permette di sviluppare una desktop-app con le stesse tecnologie di una normale webapp che siamo abituati ad utilizzare da un normalissimo browser. Inoltre Electron offre un insieme di API che permettono di invocare da Javascript delle funzioni messe a disposizione dal sistema operativo (accesso al filesystem, visualizzaizone notifiche, etc.). Un aspetto sottile ma allo stesso tempo interessante è che Electron al contrario di altri framework come PhoneGap non si concentra sul target mobile, piuttosto cerca di risolvere lo stesso problema ma in ambito desktop e vi assicuro che non si tratta di un ritorno al passato.

Bene, passiamo ai dettagli squisitamente tecnici: Electron si appoggia su Chromium per renderizzare le pagine web e i file CSS e unisce il browser su cui si basa Chrome al progetto Node.Js per istanziare un embedded-server localmente. Viene utilizzato anche Node.js, che di fatto fa da ponte per le chiamate al sistema operativo, in pratica è possibile invocare e riutilizzare qualsiasi modulo di Node.Js.

Insomma l'approccio sembra davvero ottimo, e vi dirò di più provarlo è stato ancora più gratificante poiché sono riuscito a trasformare una mobile web app, in una desktop app con tanto di eseguibile .exe per Windows in poche ore. Si può installare tranquillamente da npm:

npm install electron

Fondamentalemente una Electorn App si compone di tre file un manifest, un entrypoint HTML e una entrypoint javascript. Il manifest sarà il nostro file package.json dove possiamo dichiarare il proprietà come nome dell'applicazione, versione e nome dell'entrypoint javascript:

{
  "name"    : "my-app",
  "version" : "0.1.0",
  "main"    : "main.js"
}

In questo modo Electron saprà quale file javascript potrà interpretare come main della nostra applicazione. Nel main.js con la funzione require possiamo iniettare una serie di oggetti javascript che ci saranno utili per scrivere la nostra applicazione ad esempio per controllare il ciclo di vita della nostra applicazione, oppure per controllare il browser. Un semplice main di una nostra applicazione potrebbe essere:

var app = require('app');  // Module to control application life.
var BrowserWindow = require('browser-window');  // Module to create native browser window.

// Report crashes to our server.
require('crash-reporter').start();

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is GCed.
var mainWindow = null;

// Quit when all windows are closed.
app.on('window-all-closed', function() {
  // On OS X it is common for applications and their menu bar
  // to stay active until the user quits explicitly with Cmd + Q
  if (process.platform != 'darwin') {
    app.quit();
  }
});

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
app.on('ready', function() {
  // Create the browser window.
  mainWindow = new BrowserWindow({width: 800, height: 600});

  // and load the index.html of the app.
  mainWindow.loadUrl('file://' + __dirname + '/index.html');

  // Open the devtools.
  mainWindow.openDevTools();

  // Emitted when the window is closed.
  mainWindow.on('closed', function() {
    // Dereference the window object, usually you would store windows
    // in an array if your app supports multi windows, this is the time
    // when you should delete the corresponding element.
    mainWindow = null;
  });
});

Infine non ci resta che scrivere, o riutilizzare se ce l'avevamo già, la nostra index.html e il grosso è fatto. A questo punto posizionatevi nella directory dove avete salvato i vostri files e lanciate electron:

electron ./

La community di Electron sembra davvero molto attiva sono riuscito a trovare un repository con diversi esempi che mostrano come scrivere una Electron App e vi assicuro, come vi ho già dimostrato, che non si tratta di nulla di trascendentale.

P.S: in tutto questo... devo ancora provare Atom :)

]]>
Cookie Disclaimer con CookieCuttr http://www.luigibifulco.it/blog/it/blog/cookie-disclaimer blog/cookie-disclaimer r Se state cercando un modo semplice e veloce per adeguare il vostro sito alla tanto dibattuta legge sull'informativa dell'utilizzo dei cookie, vi posso consigliare questa simpatica estensione di jQuery che si preoccupa di estendere la funzione $ con il metodo cookieCuttr().
Nello specifico vi basterà invocare la funzione in questo modo:

$.cookieCuttr();

per ottenere magicamente una header bar, poco fastidiosa e completamente customizzabile.

Inoltre CookieCuttr permette di verificare se l'utente ha accettato o declinato l'utilizzo dei famigerati cookie analitici interni o di terze parti e comportarvi di conseguenza ad esempio inibendo le attività di tracciamento delle visite e quant'altro. Ad esempio nel mio sito ho inserito il controllo sulla logica di tracking in questo modo:

if (jQuery.cookie('cc_cookie_accept') == "cc_cookie_accept") {
   console.log('analitycs cookie accepted');
}
else{
  console.log('analitycs cookie declined');
}

Un disclaimer realizzato in questo modo rispetta a pieno la normativa, fiuuuu multa scampata. Ciauz.

Luigi Bifulco

]]>
Appify: page templating dinamico http://www.luigibifulco.it/blog/it/blog/appify-page-templating blog/appify-page-templating r Appify evolve sempre di più ed è con questo blog che ho intenzione di documentare le capacità di questo framework. Infatti sono felice di comunicarvi che Appify metterà a disposizione un meccanismo di templating delle pagine semplice ed efficace.

Pages e container

Appify è un framework per applicazioni mobile HTML5 strutturato a pagine(pages). Una pagina è semplicemente un div che contiene una porzione di codice HTML che Appify interpreterà per agganciare i Controller. Il sistema di templating vi aiuterà a mantenere il codice delle vostre pagine più pulito poiché il codice di ogni pagina può essere dichiarato in modo isolato. Il contenitore delle pagine è a sua volta un documento HTML che le contiene tutte, per semplicità chiameremo questo documento "container".

appify-template

Possiamo quindi dichiarare una pagina nel container in questo modo:

<div data-appify-template="pages/example-page.html"></div>

Come si può facilmente notare l'attributo data-appify-template è stato valorizzato con una url che corrisponde al percorso dove Appify si aspetta di trovare il file contenente il codice html della pagina desiderata.
Quando verrà invocato il metodo "startApp()" in pratica Appify si preoccuperà di capire quali sono tutti i div che hanno questo attributo e scaricherà tutte le pagine per voi attaccandole al DOM del nostro container.

Il container delle pagine risulterà molto più pulito poiché basterà dichiarare una serie di pagine:

<div data-appify-template="pages/example-page1.html"></div>
<div data-appify-template="pages/example-page2.html"></div>
<div data-appify-template="pages/example-page3.html"></div>
<div data-appify-template="pages/example-page4.html"></div>

mentre il codice di ogni pagina sarà localizzato nei relativi file html.

Dynamic content loading vs Static content loading

Riepilogando il sistema che abbiamo appena visto si chiama "dynamic content loading" e si contrappone al sistema, già esistente in Appify, "static content loading". Il dynamic content loading può essere usato in Appify per evitare di avere un container poco leggibile specie quando la mole di pagine della nostra applicazione aumenta a dismisura. Trattandosi di un contesto "mobile web app" è doveroso precisare che il download delle pagine avviene allo start della nostra applicazione. Nei prossimi articoli vi mostrerò come istruire Appify per scaricare nuove pagine solo quando l'utente effettivamente cerca di visualizzarle, ovvero il lazy-loading delle pagine.

]]>
Appify in pillole - Parte 1 http://www.luigibifulco.it/blog/it/blog/appify-in-pillole blog/appify-in-pillole r Tanto per cambiare mi è scappato un framework. Appify si aggiunge alla lista di framework per lo sviluppo mobile, categoria: frontend mobile html5 framework. Lo ammetto, forse esistono troppi framework e ognuno risolve problemi specifici e/o esigenze generiche. E' giusto che sia così basta sapere cosa si vuole e come lo si vuole. Ho creato Appify per risolvere diversi problemi: sviluppo rapido di applicazioni mobile con tecnologie orientate al web, facile manutenibilità del codice, scalabilità, possibilità di condividere moduli con i relativi canali di distribuzione. Appify permette di sviluppare complesse applicazioni mobile senza dover per forza utilizzare il linguaggio Javascript. Il linguaggio Javascript, per applicazioni complesse può risultare difficile da manutenere, Appify offre una struttura ben definita dell'applicazione utilizzando meccanismi di auto-generazione dello "skeleton" dell'applicazione e di auto-generazione del codice Javascript. Il tutto utilizzando il codice Java, HTML5 e CSS3.

Premessa

Sviluppare web application lato frontend in Java ed eseguirle in Javascript oggi è possibile grazie ai compilatori Java-2-Javascript, il più famoso di questi è offerto dal Google Web Toolkit, più semplicemente GWT. Il toolkit di Google è utilizzato da diversi framework come Vaadin, Sencha, SmartGWT che offrono delle API per sviluppare applicazioni web di tipo enterprise, scalabili
e interamente in Java.
La mia esperienza con questi framework mi ha fatto capire i vantaggi di avere a disposizione degli oggetti grafici complessi (Widget) immersi magari in un MVP/MVC pattern. D'altro canto se le Widget sono scritte in Java devono essere poi tradotte in Javascript/Dynamic HTML e linkate a risorse CSS, questa fase avviene nel momento della compilazione delle Widget. Scrivere la View con questo approccio, vuol dire scatenare una compilazione per ogni modifica all'interfaccia grafica. Legarsi troppo alla compilazione da Java a Javascript per lo strato View può risultare controproducente specialmente se non si modularizza l'applicazione.

L'idea

L'idea che sta alla base di Appify è avere la nostra View scritta interamente in HTML quindi senza farsi generare nulla, per la parte di UI, dal compilatore, e poter scrivere in Java solo la logica applicativa che sta dietro i nostri oggetti grafici. In altre parole in Java scriviamo lo strato di Controller, Service e Model. Dopo aver creato un piccolo proof-of-concept ho verificato la fattibilità dello sviluppo e ad oggi sono arrivato a un punto accettabile per poter pubblicare qualcosa. Ovviamente c'è ancora molto da sviluppare ma il framework è già utilizzabile per piccole applicazioni.

L'obiettivo

Appify si pone nella categoria "Mobile Frontend Framework" e oltre a risolvere il problema di poter scrivere la nostra webapp in Java si appoggia a tale linguaggio per offrire una modalità di sviluppo semplice e veloce. Con le stesse API possiamo scrivere velocemente piccoli prototipi e allo stesso tempo farli evolvere in applicazioni più complesse senza stravolgere le iterazioni di sviluppo.
Tutto ciò è possibile grazie al meccanismo delle Annotations offerto da Java e massicciamente utilizzato da Appify per permettere di sviluppare:

  • Controller
  • Service
  • Navigazione tra pagine con transizioni e animazioni
  • Model View/View Model binding

Inoltre Appify offre il supporto per iniettare diversi servizi utilizzabili da una mobile app:

  • Supporto per il rilevamento della posizione (Geolocation)
  • Supporto per il rilevamento dello stato della batteria (Battery)
  • Supporto per la lettura e la scrittura su db locale per la persistenza dei dati (Storage)
  • Supporto per la gestione dell'Application Cache (Application Cache)
  • Supporto per la gestione dell'accesso alle risorse remote in contesti offline (Offline)
  • Supporto per l'accesso alle proprietà dello Schermo (ScreenOrientation)

Stato dell'arte

Attualmente il codice di Appify è ospitato sul mio repository GitHub e rilasciato sotto licenza GNU GPLv3. Sul repository è possibile recuperare anche un po' di documentazione. Appify è un progetto nato da poco ma può essere già utilizzato per sviluppare semplici applicazioni mobile. Chiunque può contribuire allo sviluppo di Appify o darmi dei feedback sull'utilizzo dello stesso tramite segnalazioni su GitHub, commentando questo blog o contattandomi personalmente.

Un piccolo assaggio

Nei prossimi articoli fornirò un piccolo tutorial su come utilizzare questo framework, nel frattempo potete provare questo link per poter visionare come ho "Appifizzato" il mio blog utilizzando Appify. In ogni caso la documentazione su GitHub descrive a pieno le possibilità del framework.

Buon divertimento e "appify'em all" con Appify.

Luigi Bifulco

]]>
Quasi quasi ti prototipo http://www.luigibifulco.it/blog/it/blog/quasi-quasi-ti-prototipo blog/quasi-quasi-ti-prototipo r L'altro giorno vi ho anticipato che mi sarei cimentato nella creazione di un prototipo utilizzando App.js. Nello specifico il prototipo serve per testare l'affidabilità di due caratteristiche di HTML5. Le Geolocation API e le Application Cache API. Non entrerò nel dettaglio di queste API, se non sapete cosa sono vi basta sapere che Geolocation permette di ottenere la posizione del dispositivo, mentre Application Cache permette di accedere alla vostra applicazione anche quando il dispositivo è offline. Se non si è ancora capito stiamo parlando di API utilizzabili in un'applicazione web ed essendo, a mio avviso, due caratteristiche molto interessanti per lo sviluppo di applicazioni mobile, vale davvero la pena tenerle sott'occhio.

7 giorni prima....

Mi chiedono di sviluppare un applicazione mobile web... deve funzionare anche offline e deve accedere alla posizione GPS del dispositivo. Ansia e angoscia devastano la mia mente, ok esistono le API ma quanto sono affidabili? Trovo delle demo in rete, non basta, non abbassano il mio livello di paranoia. Quanto sono accurate le coordinate? Come gestisco le risorse offline? E con le risorse esterne come la mettiamo? Mille dubbi mi assalgono. Ok devo sviluppare un prototipo che utilizzi a pieno le API. Porc... devo fare pure la parte grafica!!!

Un buon punto di partenza

Da buon purista mi sono concentrato prima sulla struttura del prototipo e cosa mi caccia il buon motore di ricerca? App.js , vediamo... proviamo...interessante!! Vi dico subito che App.js è un framework leggero e minimale per creare semplici pagine responsive e con componenti grafici di tipo touch. Inoltre le pagine possono essere controllate con un sistema davvero molto semplice.
Partiamo dalle pagine ovvero le view della nostra applicazione:

<div class="app-page" data-page="home">
      <div class="app-topbar">
        <div class="app-title">Prototipo</div>
      </div>
      <div class="app-content"> ... </div>
</div>

 <div class="app-page" data-page="page2">
      <div class="app-topbar">
        <div class="app-button left" data-back data-autotitle></div>
        <div class="app-title">Page 2</div>
      </div>
    <div class="app-content"> ... </div>
</div>

Davvero molto intuitivo e semplice non credete? Bene ho creato due pagine ora se devo ottenere il riferimento alla home page per creare un po' di logica dietro i pulsantini, App.js mette a disposizione una funzione controller che può essere usata in questo modo:

App.controller('home', function (page) {
   //page is a simple DOM element referred by the home page of  data-page attribute
}

Non mi resta che caricare la mia applicazione specificando la pagina iniziale:

 App.load('home');

Templating, eventi touch compatibili con i moderni browsers, navigation stack, possibilità di creare dei veri e propri controller delle funzionalità della mia applicazione e ciliegina sulla torta... Data Binding:

var contact = { firstName : 'Bruce' , lastName : 'Lee' };
App.load('contact', contact);

App.js mette a disposizione anche delle fluidissime transizioni per creare delle applicazioni web molto simili ad applicazioni native.

Solo per prototipi?

Non credo che App.js si possa considerare un vero e proprio framework, e non è adatto per sviluppare applicazioni scalabili. E' sicuramente un ottimo strumento per ottenere per dare una struttura semplice alle vostre applicazioni mobile. Utilizzato insieme ad altri framework come AngularJs o VueJs e jQuery oppure Zepto si può andare oltre lo sviluppo di semplici prototipi diventando molto utile per sviluppare applicazioni più complesse con una base davvero semplice. Intanto ho terminato il mio prototipo, nel prossimo articolo vi darò più dettagli sul risultato dei test che andrò a fare su Geolocation e Application Cache. Nel frattempo potete dare un'occhiata al codice che ho pubblicato su github

]]>
App.js prototype http://www.luigibifulco.it/blog/it/blog/app-js-prototype blog/app-js-prototype r In questi giorni sto guardando i diversi framework sviluppati per mobile. Nativi,web, ibridi ognuno a suo modo risolve uno o una serie di problemi. C'é a dire che nell' open source ovviamente non si può avere tutto e subito. Al momento non esiste nessun toolkit che mette insieme i diversi framework, forse non esiste ancora tale esigenza.
Parlando di esigenze, oggi ho bisogno di creare un prototipo per una web app mobile. Il tempo nel mio settore è un vincolo, App.js oltre ad essere semplice ed intuitivo mi permetterà di dare una struttura al mio prototipo. Appena l'avrò finito vi farò sapere se le aspettative sono state soddisfatte. A presto.

Luigi Bifulco

]]>
Gods of Build Tools http://www.luigibifulco.it/blog/it/blog/gods-of-build-tools blog/gods-of-build-tools r L'esigenza di uno strumento per automatizzare il processo di build di un'applicazione è un aspetto ad oggi praticamente scontato.

C'era una volta Make...

Quando ho provato per la prima volta Make per compilare il mio primo HelloWorld in C devo dire che è stato maledettamente gratificante. Soprattutto perché finalmente avevo capito cosa si celava dietro il famoso make clean, invio, make install quando dovevo installare altre applicazioni sotto Linux. Il concetto che sta alla base di un makefile è un semplice file di testo che contiene costrutti del tipo:

target … : prerequisites …
        recipe

...lindo e pulito...

Ovviamente per il linguaggio Java non poteva mancare il relativo Make. Con Ant (acronimo di Another Neat Tool ) mi sono commosso: "Che bello Make per Java!!!". Uno strumento per il build automatico di applicazioni scritte in java, sviluppato in Java. Ant è basato su XML quindi facilmente estendibile ed offre il concetto di task e di target, dove un target in pratica è un contenitore dei tasks.
Quando ho visto Ant mi sono reso conto che avevo a che fare con uno strumento molto potente. Ant lascia spazio alla libera immaginazione degli sviluppatori in merito ai processi di build e permette di creare in pratica qualsiasi tipo di target e di creare catene di processi interdipendenti tra loro in modo molto semplice ed intuitivo. Il libero arbitrio offerto da Ant non è per tutti, se i task non sono correttamente correlati tra loro si corre il rischio di cadere in un baratro senza fine, soprattutto se si cerca di fare cose "troppo complicate".

...la coppia perfetta...

Uno strumento di build completo offre di solito un sistema di gestione automatica delle dipendenze.
Sostanzialmente Ivy risolve il problema della gestione automatica delle dipendenze in modo transitivo.
Di fatto lo si può vedere come un'estensione di Ant che lo completa offrendo un modello molto generico e che si adatta a qualsiasi tipo di esigenza. Ivy+Ant risulta essere un connubio perfetto per chi vuole integrare nel build di Ant un gestore automatico delle dipendenze.

...l'antagonista che diventa protagonista...

Rimanendo in tema di strumenti di build principalmente per applicazioni scritte in Java non è possibile non nominare Maven dall'ebreo "l'unico che comprende". Effettivamente un nome azzeccatissimo dato che parliamo di uno strumento di build automatico che implementa una serie di concetti basilari oltre al task o il target. Anche Maven permette di gestire le dipendenze di un'applicazione e come vi dicevo non fa solo questo, Questa caratteristica lo ha reso molto famoso, diventando di fatto il diretto competitor di Ivy+Ant poiché risulta essere nativamente più completo e anche perché di fatto non usa Ivy per svolgere questo compito.
Anche Maven è basato su XML ed offre un Object Model, ovvero il POM, molto vasto: le direttive offerte sono moltissime e scrivere un POM può risultare, oneroso, talvolta macchinoso. Senza il plugin per Eclipse manutenere un POM può diventare un lavoro frustrante. Per scrivere un semplice POM basta rispettare la sintassi XML offerta:

    <project>
      <modelVersion>4.0.0</modelVersion>
      <groupId>com.mycompany.app</groupId>
      <artifactId>my-module</artifactId>
      <version>1</version>
      <properties>
        <mavenVersion>2.1</mavenVersion>
      </properties>
      <dependencies>
        <dependency>
          <groupId>org.apache.maven</groupId>
          <artifactId>maven-artifact</artifactId>
          <version>${mavenVersion}</version>
        </dependency>
        <dependency>
          <groupId>org.apache.maven</groupId>
          <artifactId>maven-project</artifactId>
          <version>${mavenVersion}</version>
        </dependency>
      </dependencies>
    </project>

Gli utenti di Maven credo si possano dividere in due categorie: chi pensa di avere a disposizione una bacchetta magica e chi ha capito di avere a che fare con uno strumento completo. Se compreso a fondo Maven risulta essere un ottimo tool per gestire l'intero ciclo di vita del software, dalla creazione del progetto al suo sviluppo, dalla generazione di artefatti fino ad arrivare al test e infine al deploy. Maven è estendibile con una vasta gamma di plugin che permettono di aggiungere dei pezzi specifici al ciclo di vita del nostro software.

...tutti gli altri son nessuno...

Gli strumenti visti fino ad ora hanno una stretta correlazione con la tipologia di progetti "buildabili" in termini di tecnologie e linguaggi utilizzati: Make per C/C++, Ant/Maven principalmete per Java (potrebbe essere usato anche per progetti in C). E' facilmente intuibile come la frammentazione di queste tecnologie si è portata dietro anche la frammentazione dei relativi strumenti di build. Giusto per fare un elenco:

  • NAnt per .NEt
  • SBT per Scala
  • MSBuild per .NET
  • Buildr per Ruby
  • A-A-P per Pyhton
  • Grunt per Javascript

...il poliglotta...

Immaginate di prendere Ant, completarlo con la parte buona di Maven, integrate il tutto anche con Ivy. Aggiungeteci la possibilità di creare dei build file con un linguaggio semplice, intuitivo: bene avete appena ottenuto Gradle.
Gradle viene erroneamente paragonato a Maven ma in realtà risolve una serie di problematiche legate proprio all'utilizzo di Maven. Si colloca al di sopra degli strumenti di build tool fin'ora elencati integrandoli tra loro e creando un vero e proprio livello di astrazione. Gradle è basato su Ant utilizza i repository di Maven e di Ivy e permette di scrivere gli script di build con un linguaggio funzionale nella fattispecie Groovy. Il Domain Specific Language offerto aiuta gli sviluppatori a manipolare i classici oggetti identificabili in un processo di build:

  • il progetto
  • le sue dipendenze
  • le opzioni di compilazione
  • testing
  • deploy

Giusto per dare un'idea per scrivere il build di un semplicissimo progetto java basta scrivere queste righe di codice:

apply plugin: 'java'
   dependencies {
       compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
       testCompile group: 'junit', name: 'junit', version: '4.+'
   }

Inoltre gradle si astrae dalla tipologia di progetti che vogliamo "buildare" proponendosi come unico strumento di build. Gradle è molto giovane ed ha ancora tanta strada da fare, gli obiettivi che si propone sono lodevoli e personalmente faccio il tifo per Gradle.

]]>
Node.js non è Javascript http://www.luigibifulco.it/blog/it/blog/node-js-non-e-javascript blog/node-js-non-e-javascript r

In informatica JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi, comunemente utilizzato nella programmazione Web lato client per la creazione, in siti web e applicazioni web, di effetti dinamici interattivi tramite funzioni di script invocate da eventi innescati a loro volta in vari modi dall'utente sulla pagina web in uso (mouse, tastiera ecc...). [fonte Wikipedia]

Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. [fonte Nodejs.org]

Dopo un po' di citazioni passiamo ad un po' di domande: utilizzare Node.js implica l'utilizzo di Javascript o viceversa? Le scelte e i compromessi che portano ad usare Node.js quali sono? Quali sono i motivi che mi spingono ad utilizzare un modello event-driven? Perché dovrei scegliere Node.js? Ed infine Javascript è un linguaggio funzionale? Si lo so sembra di stare a 'Chezzenger' :D.

Cominciamo col mettere un po' di ordine. Come già spiegato in altri articoli Javascript non nasce come linguaggio funzionale nè tantomeno è stato progettato per esserlo. E' nato come linguaggio per interagire con i browser: leggero, scriptabile, interpretato, sicuro(?). Se dovessi rispondere alla domanda "Javascript è un linguaggio funzionale?" risponderei con un'altra domanda (lo so non è educato ma la premessa è doverosa), "Cosa si intende per linguaggio funzionale?"

Perché Javascript non è un linguaggio funzionale

In informatica non esiste una vera e propria definizione di linguaggio funzionale, ne esiste una precisa in matematica. Se per linguaggio funzionale intendiamo un linguaggio che espone first-class-function, lambdas o clojures, allora Javascript come anche Java8 è un linguaggio funzionale (ma sappiamo che non è così).
Se consideriamo invece fattori come: immutabilità, tipi di dato algebrici (nativi), pattern matching, assenza di polimorfismo allora Javascript non è un linguaggio funzionale.

Il modello ad eventi

I vantaggi del modello ad eventi sono notevoli. Un linguaggio basato su questo modello svincola il programmatore dai problemi legati alla programmazione concorrente. Di fatto i motori di questo tipo sono basati su librerie fornite ormai da tutti i sistemi operativi che sono in grado di gestire l'I/O in modo asincrono. Pertanto, senza scendere troppo nei dettagli, è possibile farci inviare una notifica dal sistema quando accade un determinato evento. Un modello specifico molto utilizzato di modello ad eventi è il single-thread-event-model, si tratta, semplificando, di un unico thread in continuo loop che processa gli eventi e fa in modo che questi vengano gestiti in background senza che lo sviluppatore debba preoccuparsi di gestire problematiche del tipo "produttore/consumatore". Questo modello in teoria è ritenuto più efficiente e scalabile, nella pratica bisogna aprire la scatola e capire cosa c'è dentro per averne la conferma.
Un modello ad eventi è realizzabile con la stragrande maggioranza dei linguaggi, quelli che si prestano di più sono C,C++,C#, Python, Ruby e Java.

Event-driven != Asincrono

Il fatto che un linguaggio o la tecnologia su cui si poggia sia event-driven non implica per forza che siamo in un contesto asincrono. Per avere un contesto completamente asincrono ogni evento dovrebbe essere gestito in modo indipendente e processato in modo da essere sicuri che non impatti la gestione di altri eventi. Questo tipo di modalità asincrona è molto potente ma è anche molto difficile da gestire e lo sviluppatore dovrebbe avere la possibilità e la responsabilità di gestire la concorrenza degli eventi. Un modello ad eventi single-thread se gestito male potrebbe rallentare la gestione degli eventi perdendo di fatto la capacità di esecuzione asincrona del programma.

Si ma quando arriviamo a Node.js?

Ah si dimenticavo Node.js. Bene ora che ci siamo schiariti le idee possiamo parlare di Node.js. Cominciamo subito col dire che Node.js è single-thread. Detto francamente se dovessi scegliere Node.js per rimpiazzare il classico LAMP stack direi "perché no": è semplice, leggero, immediato, e poi che bello posso usare Javascript lato server e lato client. E' proprio questo il punto: di fatto usare Node.js non vuol dire usare Javascript, poiché Javascript non contiene parecchie caratteristiche che hanno dovuto inserire in Node.Js. Con questo voglio semplicemente dire che se pensate che conoscere Javascript vi basta per utilizzare Node.Js allora iniziate male.

Trade-offs e targets

C'è da dire che se mi chiedessero di creare una web app scalabile, funzionale, clusterizzabile, basata sulla gestione concorrente e performante degli eventi.... bhe qui c'è da ragionarci.
I trade-off in questo caso sono ad ampio spettro e per ottenere le performance bisogna fare alcuni sacrifici. Potremmo considerare Erlang che oltre ad essere un linguaggio completamente funzionale ed orientato agli attori, offre un modello ad eventi concorrente e nativo, un aspetto da non sottovalutare per la sua semplicità nel gestire gli eventi concorrenti. Se non vogliamo imparare un nuovo linguaggio possiamo optare per EventMachine che sfrutta il Reactor Pattern per la gestione degli eventi, ed è disponibile in Java, Ruby e C++.
Se conosco solo e solamente Java e voglio usare solo la JVM benissimo allora si può valutare l'utilizzo di librerie come Netty di JBoss (che uso ampiamente al lavoro sui nostri sistemi in produzione) oppure Apache MINA.
Cito ma non entro nel merito di Twisted: ammetto le mie lacune su Python che vuoi per pigrizia o per mancanza di opportunità, non ho mai provato ad utilizzare.

....Node vs Java: che spiacevole scontro....

Cosa ha che non va Node.js? A dirla tutta nulla. Per essere pratici se voglio utilizzare una CPU a 16 core devo avere 16 istanze di Node.js, e come già detto se Javascript viene usato male perde la sua caratteristica di linguaggio funzionale. L'immutabilità per la gestione parallela è un elemento importante. A mio avviso sapendo che esistono valide alternative dare uno sguardo altrove non è una cattiva idea; inoltre l'apertura di Java con Java8 al paradigma funzionale dovrebbe dare, a breve, i suoi frutti .

Volendo toccare il tasto "performance" vi dico solo che ho avuto il (dis)piacere di confrontarmi con persone che paragonano le performance di Node.js con quelle di un Container JavaEE, che è come chiedersi se per fare il caffè mi serve la moka o la tazza.... chiaro che i due risolvono problemi diversi quindi non sono paragonabili.

Per concludere credo che Node.js attualmente sia molto usato perché risolve problemi specifici di oggi che non saranno i problemi di domani. Gli stessi problemi sono già risolti in altri linguaggi e framework senza rinunciare ai vantaggi offerti da Node.js. Credo che attualmente Javascript resti un ottimo linguaggio per la programmazione lato client. In un futuro non molto lontano non è da escludere che ci ritroveremo ad utilizzare un Node (senza .js) ... e l'echo gridò ES6.

Luigi Bifulco

]]>
Javascript per sviluppare? No Grazie http://www.luigibifulco.it/blog/it/blog/js-is-dead blog/js-is-dead r In questi anni di esperienza ho avuto l'opportunità di sviluppare su diversi progetti: piccoli, medi e grandi. Attualmente sviluppare lato backend è diventato davvero semplice, gli strumenti offerti sono molteplici e permettono di soddisfare gran parte delle esigenze. Lato frontend nel mondo Web le cose si complicano, specialmente se non sei un veterano del web. HTML5 viene incontro a molte delle problematiche già ampiamente discusse dalla comunità di sviluppatori, ma la strada, a mio avviso, è ancora dura da percorrere.
Come tutti sappiamo il linguaggio di programmazione per eccellenza che offrono tutti i browsers è Javascript. Permettetemi di dire che ancora oggi molte persone si lasciano ingannare dal prefisso "Java" e concordo sul fatto che Livescript sarebbe stato un nome più adatto. Quando Javascript si chiamava ancora Livescript forse nessuno riusciva ad immaginare quanto sarebbe diventato famoso. Una cosa è certa, rimane pur sempre un disgustoso, ambiguo linguaggio di programmazione e allo stesso tempo molto potente. Bene ora che mi sono fatto nemico il 70% degli sviluppatori web possiamo andare avanti :). Nessuno mi toglierà dalla testa che per uno sviluppatore Java il linguaggio Javascript diventa una idiosincrasia, molte volte mi piace citare questa proporzione che secondo me è vera e bilanciata:

"Javascript:Java=Assembler:C"

Dando uno sguardo ai vari strumenti offerti per lo sviluppo web posso dire che conoscere Javascript è doveroso ma utilizzarlo, specialmente per grandi progetti, non è una grande idea. Le modalità di debug in Javascript sono migliorate parecchio grazie alla spinta che i vari browsers stanno dando in tal senso, ma non basta. Basti pensare che in passato i motori Javascript furono rilasciati senza nessun strumento per lo sviluppo massivo. Tant'è vero che sostanzialmente Javascript fu pensato per la sola manipolazione del DOM e per interagire con oggetti semplici del browser.
Sarà perché la parola script mi ricorda un piccolo pezzo di codice che Javascript non mi sembra adatto per lo sviluppo di grandi applicazioni ma con questo non voglio assolutamente insinuare che non si presta per quello per cui è stato pensato: permettere agli sviluppatori di interagire con il browser. E non ci dimentichiamo che è l'unico linguaggio attualmente offerto che ci permette di eseguire del codice al'interno di un browser.

Cosa intendo per un ambiente strutturato

Fortunatamente molte persone pensano che gli sviluppatori abbiano bisogno di un linguaggio di programmazione progettato per sviluppatori e non per smanettare. Parliamo quindi di sviluppatori che hanno bisogno di concentrarsi su domini di ben altro livello, che quindi non desiderano un linguagio che debba farci concentrare puramente sul dominio web.
Lo sviluppatore web dovrebbe avere a disposizione:

  • un editor di intefacce grafiche
  • un ambiente di sviluppo con suggerimenti e sintassi evidenziata
  • un sistema di debug affidabile
  • un compilatore che applichi un controllo sui tipi e le strutture utilizzate
  • uno strumento di gestione delle dipendenze
  • modularizzazione, ereditarietà e incapsulamento
  • introspezione degli oggetti
  • ultimo punto ma non meno importante: documentazione.

Conclusioni

Tuto quello che posso dirvi per ora è che esistono una marea di tecnologie che offrono parte di queste caratteristiche senza compromettere i vantaggi dell'utilizzo di Javascript. Tecnologie come GWT, Dart, Typescript e molte altre sono ottimi esempi di cosa intendo. Nel prossimo aritcolo cercherò di spiegare come funzionano questi strumenti e come vengono incontro ai problemi degli sviluppatori web.

Luigi Bifulco

]]>