Tuesday, August 12, 2014

The End is Near!

Hello everybody following, so we are near the finish line.
This is a really important week and we are under pressure because we need to complete all test by Monday.
Since August 11 I focused my work on developing all remaining part of the code and making some fixes at the code written, even some tests were developed.
The mojolicious routes were defined and we have all main functions working on the WebUi.
Always during the past week I planned to make some improvement introducing some widgets to monitor more sensors in our home, but for time reasons we need to postpone those improvements.
Now we need to work hard making some test and documentation of the code written to the best possible.
Documentation is the most important part to make easy understanding the code; in fact mudler changed a little my time schedule because we agreed that it is more important documentation of other parts.
We have even planned to externalize some part of the project as modules, because a more light project is certainly more maintainable than a self contained one.
A young project like this need to attract more developer and, if it is considered valid, could be used and developed from many other developer; this is achieved developing a good code with a good documentation!
I am very excited for the end of this experience but even a bit sad. This experience helped me to get in touch with the open source and this is really important and even fun.
So that's all folks, we need to work hard for the last week! 


Tuesday, August 5, 2014

Let's get some screenshots!!

Hello everybody, as the beginning of each week let's talk about project!
This is a very important week because time is running out so we need to complete pending tasks and get ready for August 18th, final term evaluation is coming!
So during past week I worked on WebUI and some little fixes on the code written.
About WebUI we reached a good point where layout is quite defined and the need is only a little tuning.
I tried to create a simple layout and usable layout, let me show you some screens!

This is the home page with tiles that represent our switch for the relays. 
Every tile can be in state on or off and we can understand this looking at opacity of tiles.
Tiles could be filtered by tag with the search form or by room with dropdown menu.


This is the login page to access at the admin zone.


As you can see, here we have the nodes Tables where we can add/delete/modify Nodes data and add/remove rooms.


Finally the GPIO table where we can manage our gpio.
So hope you like it, I know that is a bit "rude" but improvements will come soon.
For now that's all folks, and any kind comments are well accepted! See you ASAP still here!



Tuesday, July 29, 2014

A little Bug on Linux 3.16-rc6...

Hello everybody, here I am again to report an interesting bug that I saw just a little while ago.
The error was about GCC compiler that have produced a bugged kernel when compiling linux-3.16-rc.
We could find some detail in kernel mailing list ( "Random panic in load_balance() with 3.16-rc").
And here we could find a little extract of the mail:
...
movq $load_balance_mask, -136(%rbp) #, %sfp
subq $184, %rsp #,
movq (%rdx), %rax # sd_22(D)->parent, sd_parent
movl %edi, -144(%rbp) # this_cpu, %sfp
movl %ecx, -140(%rbp) # idle, %sfp
movq %r8, -200(%rbp) # continue_balancing, %sfp
movq %rax, -184(%rbp) # sd_parent, %sfp
movq -136(%rbp), %rax # %sfp, tcp_ptr__
#APP
add %gs:this_cpu_off, %rax # this_cpu_off, tcp_ptr__
#NO_APP
...

Note the contents of -136(%rbp). Seriously. That's an
_immediate_constant_ that the compiler is spilling.

Somebody needs to raise that as a gcc bug. Because it damn well is
some seriously crazy s**t.

However, that constant spilling part just counts as "too stupid to
live". The real bug is this:

movq $load_balance_mask, -136(%rbp) #, %sfp
subq $184, %rsp #,

where gcc creates the stack frame *after* having already used it tosave that constant *deep* below the stack frame.
The x86-64 ABI specifies a 128-byte red-zone under the stack pointer,and this is ok by that limit. It looks like it's illegal (136 > 128),but the fact is, we've had four "pushq"s to update %rsp since loading

the frame pointer, so it's just *barely* legal with the red-zoning.
Linus Torvalds reported this even on gcc-bugzilla.
Now seems that on rc7 introduced a workaround for buggy versions of gcc compiler.
So that's all folks, hope this will be fixed soon!


Javascript, Mojolicious and even more...


Hello everybody, here you are looking for some news and updates about the project!
Let's start talking about the WebUI that is taking some time to be developed but we already knew this and and we have taken into account.
Nevertheless, we are well on this because we have the major part of user UI, tiles are well structured and javascript should run fine too.
During this days, in fact, I spent some time on javascript function and tiles disposition so I changed the tile structure to have a more minimalistic feel of those.
A simple selector based on rooms was introduced and, with a little amount of time, tag search will be soon introduced.
For GSoC we planned to create a WebUI that looks like a TV remote control with a lot of toggle buttons and a page for those that would require more tweak options, but future enhancement we planned will introduce more and more functionalities.
We introduced the a tile class to have a structure for tiles that could be dispatched from mojolicious to the web page.
We even worked on some other parts of the code. Changes have been done on  SQLite DB too introducing a new entity (Pin) that will represent the real board's pins.
This was required by drivers of GPIO to cope the need of dual drivers requirements.
During this days the work will be focused on creating the admin panel and test the results.
Work on documentation and testing will go on too as fast as possible.
So that's all folks! See you soon and Good Work!


Tuesday, July 22, 2014

Creating some Documentation

Like every week beginning we are again here talking about our project.
This week I made a choice about task scheduling, deciding to work simultaneously on documentation's creation and WebUI design.
I agreed with my mentor this choice because I saw that documentation is an easy task that could be done during WebUI developing period even if this task was scheduled later in the timeline. Another reason is that if it passed a long period between the development of a module and its documentation, it would certainly be more difficult to remember the implementation choices and how it works.
So I started to creating a comprehensive documentation for the developed modules using perlpod.
But this didn't stop work on WebUI and his parts.
Now we have a structure for the tiles and his disposition in the page.
I chose isotope for buttons arrangement as suggested by mudler, than I created a page where we could find the button detail and a page where there are the grid view of this tiles.
I have planned to use some kind of images and a transitional background to understand if the GPIO is on or off.
To ensure the DB back end interoperability I will create a class that will provide me all info about the tiles and their status simply querying seamlessly the DB.
Now I must focus my work on creating an easy to use admin page for adding GPIO conf and more in an intuitive manner.
I hope that job will go on fast and we will collect a good results.
So for next news in a week folks. Stay tuned! 




Tuesday, July 15, 2014

Ready for mockups

Like every week beginning here we are with some news about work!
In previous post I wrote about the UX design ad how much this is important for the user.
What we see is what we are left imprinted and a good interface is the best business card for the project.
So keeping this in my mind I planned to give a nice interface looking around and taking a cue from some UX that we all see frequently like Google+.
Google design guideline compel us to create more easy and minimalistic interfaces for our software, but even without sacrificing functionalities.
So I decided to start the project using Bootstrap as simple and ready-to-use framework to get responsive the WebUI.
Setting up bootstrap is simple but tweaking it not, especially if we want some particular design for our website.
My idea is to get an interface with a toolbar on the top that will contain all action for the webui (like MacOS interface), and a middle part were we could find some different tiles for every action.
In this part I will define a simple static layout for our Remote Controller, but in future (even after GSoC) I planned to introduce custom per user layout.
The big clue is the admin area that is really difficult to be simple and powerful but we will work on it.
During the past week I created also a login form and a little account toolbox for our WebUI as little draft of how this will be in future releases.
Last but not least I have a little problem with mockup softwares... I'm not much able to use them so I hope to soon upload some mockups.
So That's all for now folks! Thanks for your attention!



Tuesday, July 8, 2014

The WebUI

After midterm evaluation the developing of most difficult part is begun. The WebUI.
In a successful software the WebUI is the distinctive because is what we see most frequently and a good design is imperative.
To achieve this goal we use mojolicious that is a simple and even powerful web framework in Perl.
I have a little experience whit it but this is the right chance to gain more.
I started, during the past week, to setup the framework in our project but now is time to design something that can be easily understood from the user.
The UX must be simple for a standard user and even for an admin that will make some complex and tedious tasks (add a new GPIO, configure tags, etc.). My hope is to get the best result in the shortest possible time.
Now I'm talking very frequently on Skype with mudler to define what is the best design and what are the most dangerous mistakes trying to stay away from them.
One last thing, during the previous days I tested the SQLite Backend more deeper but the developing of the testsuite was postponed because of UX task. I plan to work on them as soon as possible.
That's all folks! Stay tuned and good work! 



Tuesday, July 1, 2014

First check point ok!

Very well I'm still here and I'm fine!
The past week was dedicated to the midterm evaluation, I had a little anxiety but I passed this step.
First of all let me thank my mentors Vytas and Mudler for their help and their positive evaluation of my work, my hope is to get to the end of this experience making some good code for all people who like this project.
However during the past days I continued my work on the project in both branches previously developed.
For the RPC branch I created a test suite for the dummy module.
But this caused the need of some other fixes in core modules, like the introduction of a new kind of signal (term) to stop safely mojolicious and the introduction of a yaml file to configure the RPC server.
Even on the SQLite branch we had some news. A script was added to fill the database with some testing data.
During a deep test of this code I encountered a problem in the Connector module implementation that was fixed introducing two accessors to the Node entity.
Then a little change introduced in the Config module let us the possibility to not specify some unrequired values.
So that's all for now, thanks again to my mentors. Stay tuned!





Monday, June 23, 2014

The midterm...

Finally the midterm evaluation week!
Let's take a brief summary of what happened, during the past week some fixes were done to the developed code.
The IntelliHome::RPC::Service::Base module was added to the RPC branch introducing inheritance of a base module for the RPC services.
This gives us the possibility to forget the {'with_mojo_tx'} = 1 declaration in every module.
The other thing that's could be considered as done is the porting of the Parser with the SQLite backend.
First test results are good and the software seems to work fine but more intensive test must be done ASAP.
And now let's talk about the midterm evaluation of this week...
This is the first evaluation period that gives us feedback about our work as students or mentors.
But during this period work must proceed so I'm still working on the test suite and developing modules in any case.
Hope everything will be fine and good work to everybody! 



Tuesday, June 17, 2014

The SQLite week....

Hello folks this was a fruitful week; here comes some updates!
During the past week I worked on the SQLite DB interface for vocal parser.
This work was scheduled for a previous week but it was delayed by studying the best approach to the deployer and because I started the RPC daemon before the scheduling purpose.
But now we got the deployer script for DB to make some test and results are... Errors! :D
I created the deployer using DBIx::Class::DeploymentHandler that will also handle schema upgrades as well as they will be written reflecting the changes to the SQLite database.
After the fist run the script gaves me many errors about the DBIx schema class implementation and that took a while to fix as well as possible.
Meanwhile my work on the SQLite parser interface proceeded and now I think we got a functional implementation for this module. The last thing to do is ensuring the backwards compatibility with the old plugins structure.
During this week I planned to make fully functional this module and making tests and unit tests, fixing bugs eventually.
Also on the RPC feature branch I'm going to introduce a base class for services introducing the inheritance and make life easier for whom will write some new modules.
For now... That's all folks! Good work to everybody!







Monday, June 9, 2014

Working on RPC and DB.

OK it's Monday and a new week is starting... What's the state of play?
My past week job was split in two branch that are going on simultaneously:
  1. Writing the parser interface for the DB;
  2. Enhancing the system RPC functionalities;
Looking at the first branch I created the interface for the new DB with some convenience functions like the existing Mongo interface but still the code need some little fix.
This is caused by the significant difference of the two DB approach and from the introduction of the new Entity in the relational schema.
Another noteworthy problem is the automatic deploy of the DB.
If we suppose to have a SQLite DB rather than a MySQL standard daemon running on our system, the DBIx::Class manual suggest us to create a .sql file that contain all the tables structure.
But this method force us to update two file if we make some update to the schema so, with help of my mentors, we found some DBIx deployer that could create the DB just reading the developed schema.
This is an excellent news but we need to test if this solution works for our purposes and even with SQLite DB, but that's a simple check to do ASAP.
The second part of job was focused on enhancement of RPC daemon functionalities creating a new module.
The parsing module add the parse method to the RPC daemon that is a kernel feature for this software.
This module is important even because contains the structure of future modules that will enrich the capabilities of G@H, and this bring us forward even on the roadmap.
For this week we need to improve more the RPC functions and even complete the Parser DB porting to make possible the switch between backends.
Now It's time to get back to work! Stay tuned! 



Tuesday, June 3, 2014

Week two, Jobs Fast forward...

Ok we are in the third week of GSoC 2014.
During the past week the focus of the work was on the relational DB.
The schema was quite revisited because my first draft didn't include some important attributes like drivers that was introduced in this week.
The driver gives us information of how the GPIO must be used to have a state switch or to retrieve information from input GPIO.
The user entity is no longer connected to the room, because if we have a relation between user and GPIO we obtain a more deep granularity for the access permissions.
The plugin entity, which was designed to collect some information about the plugins, will be replaced from some MOP function to achieve more flexibility and speed.
Now the focus of our work in this week is on creating an interface for the parser to the new database.
This is a very important part because we need to switch from a DB to another ensuring backwards compatibility with the old modules.
Another job done in the past week was the developing of the basis of the module for the RPC server.
I know that it was scheduled only for the 4th week but googling on mojolicious I found on metacpan two useful modules that export this functionality very well.
Mojolicious::Plugin::JsonRpcDispatcher and MojoX::JSON::RPC makes very simple to create a RPC JSON server so I decided to use those to complete this task.
Now we have a RPC server that automatically create hooks for the existing modules.
That's all guys it's time to get back to work! Cheers!

Monday, May 26, 2014

Week one, tasks done!

During the last week I have studied the code and create a ER model for structuring the database of the program.
Converting the existing database will be a quite easy task because in the code is planned  the possibility to simply switch type of database.
The ER model that i developed is in the image below:


I shared the model image even on Google drive (here) and maybe I will update this later if there is this need.
In this model I found some new entity that will be soon developed in the code.
The most important entity is Trigger that is the set of all words that the program will recognize when users uses some voice commands and there was introduced the support for locales.
This "table" must be super-optimized to reduce the latency and to improve the real time response of the system.
A separation between triggers and commands was made, there is the possibility to make different types of commands (not only gpio on and off) and in the GPIO there is the type attribute for defining if the GPIO is in,out,in/out for example or such a specific type.
The room entity was introduced to make more accurate infos about the node location and to plan a room based configuration for the setup phase of the system.
At last the possibility to make different remote commands layout per user (to control all house services) was introduced to allow some kind of customization of the UI layouts.
About this last thing, even if it is not possible in GSoC period, maybe will be a good idea to develop a configuration language for sharing across the UIs the custom remote command layouts.
This the model is the foundation of the work that will start this week, structuring the database and the test of this.
During this week I even planned the communication protocol between all UIs and RPC server that will use the following tuple:
"trigger,command,reference (id/keyword for the target device)"
But I will go deep when I will develop the RPC daemon.
Last but not least important I created some mockups for the WebUI interface but I have some paper draft so in my spare time I will copy those ideas on some kind of mockup online software.

So that is all, good work to everybody! 

Tuesday, May 20, 2014

First day...

Today is the first day of GSoC and I'm going to examine what are the tasks that I will complete for this week.
Since March 21 I'm studying the code and the structure of the project looking for the best approach for the DB. I think that a relational database is the best way to get high performance on an embedded device like RaspberryPI (maybe in future will be possible to buy a low cost board with more resources but now those are not so easy to found), because I think this is the lighter way to reach a good performance on this kind of hardware.
Moreover my mentor suggest me to look at CHI to introduce some kind of caching to improve even more the system's response time so I have to understand how CHI create and store caches.
For the next week I must have a ER structure to develop the DB structure as flexible as possible.

The second part of this contest (after the midterm evaluation period) will be focused on the WebUI.
So in this week I will study the best structure for the JSON RPC server and plugin loading and triggering.
Structuring a good RPC daemon create the condition to split up WebUI and service, allowing us to plan, in future version of the software, the possibility to create many kinds of UI (Mobile app, WebUI, PC fronted) without any changes to the core and that's good!
So I'm analyzing the Mojolicious plugin bootup method as the basis of the developing of this feature and I'm making a draft of the communication protocol that will be used by UIs.

As last task I'm going to make a brainstorming for the WebUI to put down some ideas. But this is a long task that could be very hard especially if the goal is a nice and useful interface (I hope to reach a good result).

Last news is that following the hint of my mentor I changed my timeline splitting the test suite developing period to meet the need of creating new tests only when I well defined my modules structure, mudler made me notice that developing a priori tests could make me some unnecessary troubles.

So good work to everyone and happy GSoC! 


Glory glory glory to the Hypnotoad!

Saturday, May 17, 2014

Well... The wellcome pack in da house

One of the most important experience in my life is about to start and I'm so excited!
Contribute to a FOSS project was in my TODO list since I was 14 and now GSoC and the Perl Foundation are offering me this opportunity to improve a project (that is really interesting) and my personal programming skills.
But with this post I want to show you the GSoC 2014 wellcome package:


Those maybe look like simple things but what they represent is really important.
And I want to thank you all for this and moreover for the future work experience! :D