Google Summer of Code 2015

The Ninux community is applying to become Mentoring Organization for the Google Summer of Code 2015.

Ninux participated in the GSoC several times:

• 2010 with Freifunk umbrella organization, see 2010 ideas page and look for ninux

• 2011 with Freifunk umbrella organization, see 2011 google melange page, 4 projects are from ninuxers

• 2012 as indipendent Mentoring Organization, see google melange Ninux 2012 page

• 2014 with Freifunk umbrella organization with 1 project: Netengine

Recently one of our community members also wrote a guest blog post on Google Open Source Blog: Orgs Get Ready: Preparing for GSoC 2015 with Freifunk.

What is Ninux?

Ninux is a Community Network, that means we are a community of volounteers that are using the open source approach in building and interconnecting wireless and wired networks in the Italian peninsula.

Our networks, according to the Picopeering Agreement, are free to join, everybody is welcome!

We invest quite a lot of time and energy in teaching new people how to use, build and extend the network.

Our key aim is freedom of communication through electronic means.

We are not an internet service provider, we don't provide free internet connection, although some community network members might share their internet connection with anyone or a few other friends through the network.

If you're curious to see where our networks are located, check out our community map or our experimental new map.

What is the Google Summer of Code?

The Google Summer of Code is an international program that offers student developers stipends to write code for various open source and free software projects.The program offer funds for several open source, free software, and technology-related projects over a three month period. Since its inception in 2005, the program has brought together nearly 2500 successful student participants and 2500 mentors from 98 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.

Find more info about the GSoC in the Frequently Asked Questions page.

Why do we want to participate in the GSoC?

There are several good reasons for which we participate in the GSoC:

• it's a nice way to help young people learn how to participate to FOSS projects

• it's a fun way for us to become better at teaching technical things to newcomers

• it's a good way to attract young developers in our community

• it's an effective way to get stuff done in a shorter time

• it's a great way to make mentors and participants feel part of a community!

Moreover, Google also gives additional Travel Funding to attend to events and conferences which are related with the task the student will be working on, which is a great way to meet ninux contributors!

General Guidelines for students

General guidelines for students that want to apply with us.

Get in touch & introduce yourself

These ideas were contributed by ninux developers and constributors. If you wish to submit a proposal based on these ideas, you may wish to contact the developers on the mailing list or on our jabber chat ninux.org@chat.jabber.ninux.org and find out more about the particular suggestion you're looking at.

Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

When writing your proposal or asking for help from the ninux community don't assume people are familiar with the ideas here. The Ninux people are all volounteers and keep up with the activity of the community at their own pace.

Introducing yourself to the general ninux-development mailing list is a very good idea!

Coming often on our jabber chat ninux.org@chat.jabber.ninux.org is another very good idea.

Read the GSoC student manual

Participating in the GSoC is not a joke! It requires effort and motivation.

To be aware of what you are doing, please read the amazing GSoC Student Guide.

Student application template

• What is your full name?
• Where are you from?
• Where do you live?
• What are you studying?
• Which programming languages are you most comfortable with?
• Have you ever contributed to any FLOSS project?
• Do you have any other work experience that you can show? Github repositories, websites, ecc.
• In what project idea are you interested?
• Give a general description of how you are going to meet the expected results: describe milestones with dates and describe what you intend to achieve in each milestone
• Why are you the right person for this task?
• How many hours are you going to work on this a week? 10? 20? 30? 40?
• Will you have exams during the summer? If yes, when?
• Do you intend to do other paid work during the summer? If yes, in which period?
• Are you comfortable working independently under a supervisor or mentor who might not be readily available via chat or phone 24 hours a day? Are you willing to put enough effort in acquiring the required skills you need to accomplish the project?
• To what extent are you familiar with the software you're proposing to work with? Have you used it? Have you read the source? Have you modified the source?

• Are you willing to use the additional travel funding offered by Google to attend events like the Battlemesh or the Chaos Communication Camp?

• Do you have a public twitter or github profile?
• Leave us your phone number and email address

Hints

Submit your proposal early: early submissions get more attention from developers for the simple fact that they have more time to dedicate to reading them. The more people see it, the more it'll get known.

Do not leave it all to the last minute: while it is Google that is operating the webserver, it would be wise to expect a last-minute overload on the server. So, make sure you send your application before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a low vote because of that.

Know what you are talking about: the last thing we need is for students to submit ideas that cannot be accomplished realistically or ideas that aren't even remotely related to Ninux. If your idea is unusual, be sure to explain why you have chosen Ninux to be your mentoring organisation.

Aim wide: you can and should submit more than one proposal

The PostgreSQL project has also released a list of hints that you can take a look.

General Guidelines for mentors

General guidelines for mentors that want to propose a project idea.

Read the GSoC mentor manual

Mentoring a student for the GSoC is an amazing thing but it requires quite some deal of effort.

To be aware of what you are doing, please read the amazing GSoC Mentors Guide.

Adding a proposal

Follow the template of other proposals!

Title

Difficulty

Required skills

Brief explaination

Expected result

Mentor

When adding an idea to this section, please try to include the following data:

• if the application is not widely known, a description of what it does and where its code lives
• a brief explanation
• the expected results
• required skills for working on your project
• the difficulty level (beginner, intermediate, advanced)
• if applicable, links to more information or discussions
• mailing list or IRC channel for your application/library/module
• your name and email address for contact (if you're willing to be a mentor)

If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.

Subscribing as mentor

To subscribe as mentor, you need to complete a few easy steps.

• Send an email to contatti [at] ninux [dot] org to let us know which project you want to mentor for

• Log in to Google Summer of Code 2015 Melange

• Apply as a mentor for Ninux

• Subscribe to the ninux-development mailing list

Ideas

Here is a list of our project ideas.

Enhanced crawling for the Ninuxoo search engine

Difficulty: Beginner developer

Required skills:

• Python
• MySQL (for database queries)
• FTP protocol general knowledge
• HTTP protocol general knowledge

Brief explaination:

Ninuxoo is a search engine for SMB/CIFS and FTP shared folders. It is a popular service inside the ninux.org community network and its source code can be found on github: https://github.com/ninuxorg/ninuxoo.

Currently, the crawling of FTP shared folder is broken and we are aiming at adding new features to the crawler.

Expected result:

A new version of ninuxoo with:

• fixed crawling of FTP shared folders
• added possibility to crawl files shared through HTTP
• the crawlers should be aware of possible loops caused by symlinks

Mentors:

Claudio Pisa, active ninux contributor and creator of ninuxoo.

Claudio Mignanti, ninux developer.

Social profiles:

Claudio Pisa:

• @cl4u2 on Twitter

• @cl4u2 on Github

Claudio Mignanti:

• @claudyus on Github

Netdiff: add support for NetJSON

Difficulty: Beginner/Intermediate developer

Required skills:

• Python
• Routing protocols
• JSON

Brief explaination:

Netdiff is an experimental pure python library that we are developing to parse network topologies from routing protocols like OLSRd 1 and batman-advanced and detect changes in network topology.

We want to be able to parse more routing protocols and convert their output to NetJSON, a draft standard JSON format we are working on with other community networks, more information here: https://github.com/interop-dev/json-for-networks and we also want to be able to easily calculate changes in the network topology (new links, dropped links).

Expected result:

The goals of this project are the following (ordered by priority):

• design a class which is able to convert a networkx topology in a NetJSON topology
• add a clean way to calculate differences between two networkx topologies
• write a parser which understands the output of the OLSRd1 jsoninfo plugin and converts it to an internal networkx topology
• write a parser which understand the output of the batman-advanced JSON topology tool (alfred / vis) and converts it to an internal networkx topology
• write a parser which understands the output of the OLSRd2 JSON topology tool and converts it to an internal networkx topology

• propose an experimental integration with nodeshot: read topology data and update the links in the database

Each one of the main features will need to be unit tested and documented in the README. The library needs to maintain compatibility with python 2.7 and python 3.

At least 4 tasks out of 6 will need to be done in order to consider the project successful.

Mentor:

Federico Capoano active ninux contributor.

Social profiles:

• @nemesisdesign on Twitter

• @nemesisdesign on Github

Proxoo: distributed SMB/CIFS to HTTP proxy for ninuxoo

Difficulty: Intermediate developer

Required skills:

• Python
• WSGI
• CGI
• Lua or shell scripting
• Basic HTML
• Basic security notions

Brief explaination:

Ninuxoo is a search engine for SMB/CIFS and FTP shared folders. It is a popular service inside the ninux.org community network and its source code can be found here: https://github.com/ninuxorg/ninuxoo.

Web browsers do not support the SMB/CIFS protocol natively, thus the files provided in the search results of ninuxoo cannot be accessed directly. Users must instead copy and paste the smb:// URLs provided by the ninuxoo search results into other programs (typically file managers) on their systems.

To circunvent this problem we would like to develop Proxoo: an SMB/CIFS to HTTP proxy to be deployed in several locations inside the community network. We imagine Proxoo as a CGI application that takes an smb:// URL as parameter (e.g. through an HTTP GET request) and returns the content of the file pointed by the smb:// URL through an HTTP response. We would like Proxoo to be deployed on many different web servers (apache, nginx and possibly uhttpd), thus with different implementations (e.g. Python-WSGI, Bash-CGI).

Moreover, to avoid loading a single point on the network (and following a decentralization philosophy) we would like ninuxoo to point users to their nearest Proxoo instance.

To achieve this goal:

• ninuxoo should be aware of the Proxoo instance locations. These could be listed, for the moment, on a wiki page that can be parsed through e.g. the beautifulsoup python library.
• ninuxoo should be aware of the network topology graph to compute the shortest path between the user and the proxy (this sounds hard but it's instead quite easy to achieve through an already provided JSON description of the network and the networkx python library)

Expected result:

• a ninuxoo version that allows users to retrieve SMB/CIFS content through HTTP using their nearest Proxoo instance. Achieved through:
  • a server-oriented Python-WSGI implementation of a SMB/CIFS to HTTP proxy (with input validation)

  • an OpenWrt-oriented CGI (written shell or lua) implementation of a SMB/CIFS to HTTP proxy (with input validation)

  • a web-page parsing module to retrieve the IP addresses of Proxoo deployment locations (Python)

  • integration in ninuxoo of the shortest-path module provided here

  • modification of search result links so that these contain the URL of the Proxoo instance that is closest to the user

Mentor:

Claudio Pisa, active ninux contributor and creator of ninuxoo.

Social profiles:

• @cl4u2 on Twitter

• @cl4u2 on Github

Nodeshot: debian package generator

Difficulty: Intermediate developer

Required skills:

• Python
• Debian Linux
• Django (minimum knowledge)
• Fabric python library (optional)

Brief explaination:

Nodeshot is a crowdsourcing platform for geographic data with some features that are specific for community networks.

You can see the development version in action in our experimental network map.

Performing the manual development install described in the documentation is time consuming and often seen as serious barrier for new potential contributors.

The goal of this project idea is to simplify the basic installation of Nodeshot in order to lower the barrier for new users, potential contributors and mobile app developers. We don't want a mobile developer to give up developing a simple mobile app just because he cannot setup a nodeshot development instance in the first place.

Expected result:

We want to reach a point in which one can perform a basic installation of nodeshot on debian based systems by simply doing:

wget <deb-package-url>
sudo dpkg -i <deb-package.deb>

That command should replicate a result similar to what one would achieve by performing the following steps of the manual install procedure:

• install dependencies
• create database
• install python packages
• project configuration

In addition a daemon script to start/stop/restart the django development server also needs to be written.

The package generation must be automated, ideally using the fabric python library, a good example can be seen on the fabric debian package generator script of the LXC-web-panel project. This kind of automation is crucial because core devs will have to release new packages at each new nodeshot release.

The debian package will also be automatically tested by a jenkins instance, the student will be helped in setting up this last task.

Mentors:

Federico Capoano, nodeshot core developer and active ninux contributor.

Claudio Mignanti, ninux developer.

Social profiles:

Federico Capoano

• @nemesisdesign on Twitter

• @nemesisdesign on Github

Claudio Mignanti:

• @claudyus on Github

Libre Mesh: OLSRd1 plugin

Difficulty: Intermediate developer

Required skills:

• Lua
• OLSRd1 configuration

Brief explaination:

The student will have to learn the Libre Mesh modular structure and implement a lime-proto-olsrd module in order to configure OLSRd routing daemon and setup networking interfaces to keep packets flowing without breaking other protocols, the module will be written in Lua, will have to be documented and be ready to be used in production before the end of the GSoC 2015.

Expected result:

At the end of the GSoC, Libre-Mesh firmware should be capable of autoconfiguring OLSR mesh networks and interoperate seamlessy with already existent ninux OLSR network.

Mentor:

Gioacchino Mazzurco, Libre Mesh core developer, ninux and guifi contributor.

Social profiles:

• @G10h4ck on Github

Libre Mesh: OLSRd2 plugin

Difficulty: Intermediate developer

Required skills:

• Lua
• OLSRd2 configuration

Brief explaination:

The student will have to learn the Libre Mesh modular structure and implement a lime-proto-olsrd module in order to configure OLSRd routing daemon and setup networking interfaces to keep packets flowing without breaking other protocols, the module will be written in Lua, will have to be documented and be ready to be used in production before the end of the GSoC 2015.

Expected result:

At the end of the GSoC, Libre-Mesh firmware should be capable of autoconfiguring OLSRv2 mesh networks and permit to explore the capabilities of the new protocol.

Mentor:

Gioacchino Mazzurco, Libre-Mesh core developer, ninux and guifi contributor.

Social profiles:

• @G10h4ck on Github

Nodeshot: Ansible playbook

Difficulty: Advanced developer

Required skills:

• Python
• Ansible
• Linux
• Debian

Brief explaination:

Nodeshot is a crowdsourcing platform for geographic data with some features that are specific for community networks.

You can see the development version in action in our experimental network map.

The current automated install script for nodeshot is implemented with the Fabric python library and has several limitations.

We want to overcome the current limitations by porting the fabric script to a Ansible, the popular configuration management tool written in Python.

The deploy procedure is fully described in the "Production Instructions" section of the Nodeshot Manual Install guide.

This project idea can potentially give a huge contribution toward the realization of a distributed architecture of one of Ninux's core services, the visual map of our network.

With the tools we currently have today, setting up a distributed cluster of nodeshot instances would be very hard to manage. If we had an ansible playbook though, things would become easier and also more interesting to potential volounteer sys admins.

Expected result:

We expect the following fabfile: https://github.com/ninuxorg/nodeshot-fabfile to be converted in an ansible playbook (we expect to publish it in a new repository in ninux Github organization).

The ansible playbook must support the configurable options supported in the fabfile and should mantain compatibility with (at least) Debian 7 and Ubuntu 14 LTS.

The usage of the playbook will have to be documented in the README file.

The ansible playbook will need to be automatically tested by a jenkins instance, the student will be helped in setting up this last task.

Mentor:

Federico Capoano, nodeshot core developer and active ninux contributor.

Claudio Mignanti, ninux developer

Social profiles:

Federico Capoano

• @nemesisdesign on Twitter

• @nemesisdesign on Github

Claudio Mignanti

• @claudyus on Github

Nodeshot: performance improvements

Difficulty: Advanced developer

Required skills:

• Python
• Django
• SQL
• Javascript
• Web application performance

Brief explaination:

Nodeshot is a crowdsourcing platform for geographic data with some features that are specific for community networks.

You can see the development version in action in our experimental network map.

The current development version is not yet optimized for fast loading and there are several optimizations that can be done.

This project idea is about establishing a base line for measuring basic performance measueres and then optimize the bottlenecks.

Expected result:

The student has to come up with a solution to solve the following issues:

• develop a test suite with basic performance measurements for the 5 most used pages
• automatically export the result of each test in a format that can be easily represented with a graph

• integrate django-pipeline in nodeshot to minify and combine javascript and css

• configure django-pipeline to download external javascript libraries via bower

• find a way to automatically generate compressed gzip versions of the combined and minified static assets
• implement django caching for the 5 most used pages of nodeshot - caching must take in consideration user access levels
• optimize slow queries when viable
• implement django caching for complex queries

• test Django Rest Framework UJSON Renderer to see if there are performance gains

• enable gzip compression of django responses
• create a compressed version of the main GeoJSON response used by the UI, this involves modifying small parts of the UI too

• implement Mozilla's Local Forage Javascript library in the frontend UI

Mentors:

Claudio Mignanti, ninux developer.

Federico Capoano, nodeshot core developer and active ninux contributor.

Social profiles:

Claudio Mignanti:

• @claudyus on Github

Federico Capoano:

• @nemesisdesign on Twitter

• @nemesisdesign on Github

Nodeshot: websockets

Difficulty: Advanced developer

Required skills:

• Python
• Django
• Javascript

Brief explaination:

The current websocket implementation in nodeshot is far from being production ready and has been infact disabled.

WebSocket will enable us to do very useful things like bidirectional communication between browsers and servers for real time notifications, analytics, events and so on.

Expected result:

The student has to come up with a solution to solve the following issues:

• integrate django-websocket-redis in nodeshot

• integrate the deployment instructions in the nodeshot documentation

• implement a websocket mirror of the following API views:
  • geojson node list
  • search API
  • notifications
• implement a way to send messages from the server to the browser when key events happen, so that the UI can update itself in realtime:
  • a new notification has arrived
  • a new node has been added
  • a node has been deleted
  • a node has been changed
• implement at least 3 of the previous websockets features in the UI

All the new implementations will need to be properly unit tested.

Mentors:

Federico Capoano, nodeshot core developer and active ninux contributor.

Claudio Mignanti, ninux developer.

Social profiles:

Federico Capoano:

• @nemesisdesign on Twitter

• @nemesisdesign on Github

Claudio Mignanti:

• @claudyus on Github