Name: Marko Lalic
Contact/Email: marko.lalic@gmail.com
Background:
- I am a student at the Faculty of Electrical Engineering Sarajevo, currently in my first year of Master's studies of Computer Science and Informatics. I have seen programming as my primary hobby ever since primary school. During high school I won the privilege to represent my country at four international olympiads in informatics. This has given me a really strong background in algorithms, data structures and problem solving. Upon starting my university studies, I decided to focus more on improving my knowledge and skill in software engineering and application development, rather than algorithmic competitions. Thus, I am experienced in a wide array of languages and technologies: Python, C++, Android/Java, Javascript, CSS/HTML, etc.
I have been an active member of the Electrical Engineering Students' European Association (EESTEC) both on the local and international level as a member of various teams (IT team included) whereby I got the chance to improve my teamwork skills.
Perhaps the most relevant experience for this application would be my work as the technical leader and main developer of the EESTEC Distance Learning portal (on GitHub). The backend is written in Python, using the Django framework and as such, I have acquired a lot of important experience in developing Django applications by learning the ins and outs of the framework and being able to already identify some mistakes or oversights.
- Some other notable applications that I could mention would be:
Ketrem - an Android application for displaying and searching maps of cities in Bosnia (since Google Maps was not available until about a month ago
etfarduino - a project which allows the use of an Arduino board as a data acquisition device along with integration with MATLAB's Data Acquisition Toolbox. Written mostly in C++, with a GUI configuration tool being written in C++/CLI.
Project title: PTS rewrite in Django
Project details:
Current state of affairs
- The PTS is currently implemented using many different technologies: Perl, Python, Bash, XSLT. It offers two interfaces to access information about packages: e-mail and Web.
- The Web interface is based on serving static HTML files generated by a cron-job every so often according to XSLT rules. This means that the information shown for the packages on the Web is often outdated.
- The e-mail interface is based on processing received mails, forwarding them to appropriate users and storing relevant package information. However, all this is implemented across many different scripts making it hard to extend.
- Overall, the current implementation is hard to maintain and extend, but it is also not user-friendly with outdated information, non-intuitive subscription mechanism, etc.
Django rewrite
- The planned rewrite would maintain existing functionality while improving the design (and thus maintainability) of the PTS. Moreover, it would add important features such as the ability to write new easily pluggable modules for the application which would add more information to packages. More specifically, the application would have the following features:
Core API -- the core which would define an API that clients could implement in order to add extra information about packages to the Web interface. A common interface for various data sources which the PTS application could use to gather data about the packages could also be defined.
New Web interface -- including both a new GUI and new implementation in terms of Django templates/views
User management -- allow users to register and manage their subscriptions. Django 1.5's custom User models would be well suited for this.
Caching mechanism -- a caching mechanism, probably based on memcached
Mail interface -- keep the current behavior, but implement it as various Django management commands
Use a task queue -- for implementing asynchronous mail sending operations, importing data from various sources, etc. I have found that Celery is probably the best option in this regard.
- The planned rewrite would maintain existing functionality while improving the design (and thus maintainability) of the PTS. Moreover, it would add important features such as the ability to write new easily pluggable modules for the application which would add more information to packages. More specifically, the application would have the following features:
Synopsis: Package Tracking System (PTS) is currently a mess of various technologies and languages: Perl, Python, XSLT which makes it extremely hard to maintain and extend. It includes an e-mail and Web interface for viewing information about packages, but the information shown is rather fixed and adding something new is a daunting task. Finally, since it is based on generating static HTML files, it does not offer real-time up-to-date information. This project aims to rewrite the application using Python and the Django framework in order to solve these problems by making a modular modern Django application.
Benefits to Debian:
- Attract more contributors to PTS by making it more maintainable
- Attract more users to PTS by making it more user-friendly in this day and age: real-time, dynamic, easier subscription management, etc.
- Attract other developers to use information offered by PTS in innovative ways by providing them a more friendly interface to access the information
- Make PTS a real option for Debian derivatives for their own purposes
Deliverables:
- A finished PTS Django application packaged and deployed along with all its dependencies
- Documentation of the Django application source code in an appropriate format (using Sphinx probably)
- User guide explaining the basic use scenarios of the new PTS application
Project schedule: This would be just a rough proposal of a project schedule, subject to modifications after thorough discussion with the mentor.
May 27 - June 17
- Discussion with the mentors regarding exact features which should be prioritized in the implementation
- Discussion with the mentors regarding core API and Model decisions
- Defining the final project time schedule
June 17 - July 1
- Implement the e-mail interface
July 1 - July 15
- Implement the package data source API
- Implement gathering package data from all initially supported sources
July 15 - July 29
- Implement the basic Web interface
- Display information about packages
User registration & subscription management
- Initial deployment of the application to some server
- Implement the basic Web interface
July 29 - August 12
- Implement caching mechanisms
- Other scalability measures
August 12 - August 19
- Implement a REST interface
- Implement RSS
August 19 - September 22
- Bug fixes
- Extensive documentation work
- Benchmarking, optimizing bottlenecks
- Final deployment
Exams and other commitments: Two weeks of exams starting mid-June and ending early July (not sure about the dates as of yet). This does not mean that I would be completely unavailable for two weeks though, only that I could have a reduced number of available hours to work on the project.
Other summer plans: Only possible summer plans include a week of vacation at the end of July, but nothing is set in stone yet and depends on many factors, one of them being Google Summer of Code.
Why Debian?: The fact that the Debian community is one of the largest and most vocal proponents of open source software makes me eager to contribute to it as best as I can. However, another important reason is that by being in touch with such a community and working on a project of this importance would let me grow on both professional and personal level.
Are you applying for other projects in SoC? No