Innovactive a Hack Reality 2

May 10, 2013 11:04 by l.maiorfi

La nostra società sarà presente a Hack Reality 2 il 25 Maggio (l’evento si svolgerà in contemporanea a Milano e Trento) in triplice veste: come sponsor (insieme a Microsoft, BlackBerry, SeeedStudio, OpenPicus e altri), come tech-provider/giudici nell’ambito dell’Hackathon e come speaker nel workshop del pomeriggio sullo sviluppo di applicazioni IoT con Microsoft .NET Micro Framework.

Per  chi non lo sapesse, Hack Reality 2 è l’iniziativa organizzata da WhyMCA.org in materia di IoT, domotica, automotive, smart cities, m-payment e wearable devices.

La location principale di quest'anno sarà il Talent Garden a Milano, dove ci saranno, oltre all'hackathon,  mini-sessioni e incentrati sulla diffusione dell'informazione e su come cambieranno le forme di interazione nei prossimi anni, workshop di elettronica per adulti e per bambini, un'area espositori con le tecnologie che danno vita a questo processo di cambiamento e molto altro.

Inoltre, si tratterà del primo hackathon italiano in parallelo fra Milano e Trento, in partnership con CREATE-NET, centro di ricerca, sperimentazione ed innovazione nel dominio delle telecomunicazioni nonché promotore di progetti di ricerca in ambito Internet Of Things.

Trovate maggiori informazioni qui.


Currently rated 2.0 by 6 people

  • Currently 2/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Innovactive a Codemotion 2013

March 20, 2013 17:37 by L.Maiorfi

Innovactive sarà presente a Codemotion 2013 con una sessione nella track “Makers” sullo sviluppo di applicazioni embedded moderne con .NET Micro Framework.

Nel dettaglio (per citare l’abstract della sessione), “in questo Talk verrà presentata una tra le più moderne e produttive piattaforme di sviluppo embedded attualmente esistenti: il .NET Micro Framework di Microsoft (.NETMF).”

Per maggiori informazioni, potete consultare il sito ufficiale di Codemotion 2013.


Currently rated 2.2 by 37 people

  • Currently 2.189189/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Javascript OOP con AMD e RequireJS

December 8, 2012 11:30 by L.Maiorfi

L’abbondanza di nuovo materiale reperibile in rete in tema di “modularità” delle applicazioni Javascript, tipicamente per quanto riguarda applicazioni web particolarmente“client-side” (o addirittura SPA) ma anche per quanto concerne applicazioni NodeJs, unitamente ad iniziative quali TypeScript, dimostrano il bisogno che la moderna comunità degli sviluppatori ha di metodologie e best practices finalizzate alla riduzione del rischio di “spaghetti-code” nella creazione di progetti Javascript complessi, quali quelli che quotidianamente vengono affrontati da chi utilizza questo linguaggio per professione.

Senza addentrarci in temi troppo “accademici”, credo non si possa negare che gli elementi più critici in tal senso sono due:

  • Scarsa propensione all’OOP
  • Difficoltà nella gestione delle dipendenze

Quanto al primo punto, in realtà non si può dire che Javascript non sia un linguaggio object-oriented, anzi al contrario lo è, ed addirittura molto più di altri (anche le funzioni sono oggetti, ad esempio); quello che con più esattezza motiva la scarsa propensione ad essere utilizzato come linguaggio adatto all’OOP è semmai la sua peculiarità ad essere più “object-oriented” che “class-oriented” (o “type-oriented”), cosa che di fatto mette a disagio chi ha più dimestichezza con linguaggi quali C++, Java e C#, caratterizzati da un paradigma effettivamente molto differente.

In merito al secondo punto, se facciamo ad esempio riferimento ad una applicazione web più o meno tipica, non possiamo non notare come l’inclusione di 10-15 script “*.js” fatta da parte dei vari frammenti di markup HTML che popolano ciascuna pagina/vista dell’applicazione ha l’effetto di “inquinare” (non a caso si parla di “namespace pollution”) lo spazio in cui operano gli oggetti attivi all’interno dell’engine (che sia quello interno al browser o quello definito in nodejs) che sta eseguendo la nostra applicazione, senza considerare l’intricato rapporto di dipendenze che molto spesso esiste tra gli script in questione.

Sebbene non mi senta di dire che si tratti della soluzione “ottima” o “definitiva”, ho trovato particolarmente efficace la soluzione illustrata di seguito, in cui il primo punto critico è affrontato utilizzando un pattern per la traduzione dei concetti tipici di un linguaggio OOP quale Java, C++ o C#, mentre il secondo viene sostanzialmente risolto mediante l’adozione del cosiddetto “Module-pattern” (nella “accezione” AMD, più precisamente), reso per l’occasione meno “complicato” dall’utilizzo del framework RequireJS, che sta di fatto diventando uno standard infrastrutturale anche in molti framework più “verticali”.

Per rendere l’illustrazione di questo approccio più eloquente possibile, direi di utilizzare l’esempio che segue, costituito dalla seguente struttura di file:

  • default.htm
  • scripts (dir)
    • scripts/main.js
    • scripts/person.js
    • scripts/student.js
    • scripts/require.js

Il file default.htm, un po’ scarso nella sua espressione puramente UI dal momento che tutto l’output del demo si svolge all’interno della console del browser, è il seguente, in cui è evidenziata la parte di dichiarazione delle dipendenze gestita da RequireJS:

 

   1: <!DOCTYPE html>
   2: <html>
   3:     <head>
   4:         <title>RequireJS + OOP demo</title>
   5:         <!-- This is a special version of jQuery with RequireJS built-in -->
   6:         <script data-main="scripts/main" src="scripts/require.js"></script>
   7:     </head>
   8:     <body>
   9:         <h1>RequireJS + OOP demo</h1>
  10:         <p>L'output di questo esempio è tutto nella console!</p>
  11:     </body>
  12: </html>

 

Lo script person.js è il seguente:

 

   1: // "define" è una funzione di RequireJS deputata alla dichiarazione
   2: // di un modulo. Il parametro passato rappresenta la funzione invocata da
   3: // chi dipenderà da questo modulo in fase di risoluzione delle dipendenze.
   4: // Il valore di ritorno sarà passato (da RequireJS) al "richiedente".
   5: define(function() {
   6:  
   7:     // Questo modulo "esporta" un oggetto che ha lo scopo
   8:     // di dichiarare la definizione di una "classe" Person
   9:     
  10:     // Questo è un costruttore della "classe" Person
  11:     var Person=function()
  12:     {
  13:         // questo è un field privato
  14:         var _age=18;
  15:         
  16:         // questo è un metodo "privilegiato", ossia chiamabile
  17:         // pubblicamente ma che ha diritto di accesso a field privati
  18:         this.setAge=function(newval) {
  19:             _age=newval;
  20:         };
  21:         
  22:         // questo è un altro metodo "privilegiato"
  23:         this.sayAge=function() {
  24:             console.info(_age);
  25:         };
  26:         
  27:         // questa è una proprietà pubblica, inizializzata
  28:         this.name="(default name)";
  29:     };
  30:     
  31:     // Questa è una proprietà statica
  32:     Person.s_Description="Persona";
  33:  
  34:     // Questo è un metodo pubblico non "privilegiato"
  35:     Person.prototype.walk = function(){
  36:         console.info ('I am walking!');
  37:     };
  38:     
  39:     // Idem questo (che è "overridato" sulla classe Student derivata)
  40:     Person.prototype.sayHello = function(){
  41:         console.info ('hello');
  42:     };
  43:     
  44:     // metodo pubblico che accede ad una proprietà
  45:     Person.prototype.sayName=function() {
  46:         console.info(this.name);
  47:     };
  48:     
  49:     // "esporto" la definizione di Person
  50:     return Person;
  51: });

 

Mentre Student.js è il seguente:

 

   1: // il modulo definito di seguito utilizza anche l'array di stringhe
   2: // come primo parametro ad indicare che il modulo in questione dipende
   3: // a sua volta dal modulo "person". In questo modo RequireJS caricherà
   4: // e "valuterà" lo script person.js prima di eseguire la funzione di
   5: // definizione del modulo corrente
   6: define(['person'],function(Person) {
   7:  
   8:     // definiamo qui la "classe" Student, derivata da Person
   9:  
  10:     // definiamo un costruttore (niente overload, però!)
  11:     var Student=function(city) {
  12:         
  13:         // definisco una proprietà
  14:         this.school=null;
  15:         
  16:         // e un field privato, inizializzato con il parametro del ctor
  17:         var _city=city;
  18:         
  19:         // metodo privilegiato, può accedere a "_city"
  20:         this.saySchoolAndCity = function(){
  21:             console.info(this.school + ' in ' + _city);
  22:         }
  23:     };
  24:     
  25:     // Student EREDITA da Person
  26:     Student.prototype = new Person();
  27:  
  28:     // correggiamo il "puntamento" del costruttore di Student,
  29:     // che altrimenti per default punta a quello di Student
  30:     Student.prototype.constructor = Student;
  31:  
  32:     // facciamo l'override del metodo "sayhello()"
  33:     Student.prototype.sayHello = function(){
  34:         console.info('hi, I am a student');
  35:     }
  36:  
  37:     // aggiungiamo il metodo "sayGoodBye()"
  38:     Student.prototype.sayGoodBye = function(){
  39:         console.info('goodBye');
  40:     }
  41:     
  42:     // ed esportiamo questa definizione di Student
  43:     return Student;
  44: });

 

Per verificare il funzionamento del tutto possiamo utilizzare un main.js come quello che segue:

 

   1: // questo script dipende da "person.js" e da "student.js", che verranno
   2: // caricati e valutati da RequireJS, il quale eseguirà la funzione passata
   3: // come secondo parametro al termine della risoluzione del grafo delle dipendenze
   4: require(["person","student"], function(personModule,studentModule) {
   5:         //qui person.js e student.js sono stati caricati, lanciamo il "main"    
   6:         runMain(personModule,studentModule);
   7:     });
   8:  
   9: // Questa funzione rappresenta l'entry-point della nostra applicazione
  10: function runMain(Person,Student) {
  11:  
  12:     // Istanziamo due persone
  13:     var person1=new Person();
  14:     var person2=new Person();
  15:     
  16:     // Invochiamo dei metodi (pubblici o privilegiati)
  17:     person1.sayName();
  18:     person1.sayAge();
  19:     
  20:     // Settiamo una proprietà
  21:     person1.name="Rick";
  22:     
  23:     // Proviamo a settare un field privato (nessuna eccezione, ma non ha effetto!)
  24:     person1._age=19;
  25:     
  26:     // Verifichiamo lo stato di "person1"
  27:     person1.sayName();
  28:     person1.sayAge();
  29:     
  30:     // Eseguiamo il metodo privilegiato e riverifichiamo che "_age" sia cambiato
  31:     person1.setAge(20);
  32:     person1.sayAge();
  33:     
  34:     // Verifichiamo che l'altra istanza ha il suo stato distinto da "person1"
  35:     person2.sayName();
  36:     person2.sayAge();
  37:     
  38:     // Proprietà statica, esposta solo da Person, non dalle sue istanze
  39:     console.info(Person.s_Description);
  40:     console.info(person1.s_Description);
  41:     
  42:     // Istanziamo la classe Student, nel primo caso senza passare parametri al ctor
  43:     var student1 = new Student();
  44:     var student2 = new Student("Camerino");
  45:     
  46:     // settiamo una proprietà erediatata
  47:     student1.name="Jeffrey";
  48:     
  49:     // verifichiamo l'override
  50:     student1.sayHello();
  51:     
  52:     // verifichiamo i metodi della classe base e l'accesso ai field della classe base
  53:     student1.sayName();
  54:     student1.walk();
  55:     
  56:     // verifichiamo che il ctor ha inizializzato (se eseguito con parametri)
  57:     // correttamente field o proprietà
  58:     student2.school="MIT";
  59:     student2.saySchoolAndCity();
  60:     student1.saySchoolAndCity();
  61:     
  62:     // eseguiamo un metodo definito solo in Student
  63:     student1.sayGoodBye();
  64:     
  65:     // verifichiamo che le istanze hanno stato distinto
  66:     student2.name="Henry";
  67:     
  68:     console.info(student1.name);
  69:     console.info(student2.name);
  70:  
  71:     // verifichiamo la "tipizzazione"
  72:     console.info(student1 instanceof Person); 
  73:     console.info(student1 instanceof Student);
  74:     console.info(person1 instanceof Person);
  75:     console.info(person2 instanceof Student);    
  76:     
  77: }

 

Così facendo, dovremmo ottenere un output di questo tipo:

(default name) person.js:46
18 person.js:24
Rick person.js:46
18 person.js:24
20 person.js:24
(default name) person.js:46
18 person.js:24
Persona main.js:39
undefined main.js:40
hi, I am a student student.js:34
Jeffrey person.js:46
I am walking! person.js:36
MIT in Camerino student.js:21
null in undefined student.js:21
goodBye student.js:39
Jeffrey main.js:68
Henry main.js:69
true main.js:72
true main.js:73
true main.js:74
false main.js:75

 

Per approfondimenti:

https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript

http://phrogz.net/JS/classes/OOPinJS.html

http://phrogz.net/JS/classes/OOPinJS2.html

http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth

https://github.com/amdjs/amdjs-api/wiki/AMD

http://requirejs.org/docs/start.html


Currently rated 1.4 by 53 people

  • Currently 1.377358/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5