GSOC 2017/Student application amitosh

Contact Information

Email	amitosh@fedoraproject.org
PGP Key	09D287C8
Time zone	UTC +5:30
Freenode IRC nick	amitosh
Github	Agathver
Blog	https://amitosh.in
Twitter	OriginalASM

About Me

Educational background

I am currently a second year B.Tech student in computer science and engineering at College of Engineering and Technology, Bhubaneswar, India. How computers and software worked have fascinated me since my middle school days. My first exposure to programming was with C in 6th grade. Since then, I have been constantly exploring new areas in programming. I chose to study computer science, in order to satisfy my curiosity for learning new things in the field of computer science and IT, and also due to fact that I perform academically well in computer science courses, due to my interest in the subject.

Why did I choose Fedora ?

My first exposure to Linux world was thorough Fedora. It was back in my 9th grade when I first installed Fedora 16 (Verne). So I was always interested to contribute back to the project if I got any chance. Fedora project is also a very good project with a large user base, so any effort in contributing the project will help a large community.

Contributions to open source

• Active contributor to a project called bcrypt. It is a very widely used NodeJS module that provides bcrypt hashing capabilities, which is commonly used to store passwords in hashed form.
• Member of the technical society of our college where we promote the use of FOSS technology among the students. I also help out students who decide to start using Fedora, Ubuntu or any other Linux system.
• Answering questions on StackOverflow, CodeProject and AskFedora about FOSS technologies as well as general programming and help questions.

Previous Google Summer of Code Experience

This is my first application to Google Summer of Code programme.

Proposal

I'm applying for the following project ideas as the part of Google Summer of Code 2017.

• Implementation of Web Components for PatternFly
• .NET Core Wrapper Library For systemd

Implementation of Web Components for PatternFly

The detailed proposal for this idea can be found here

Abstract

This project aims to implement core PatternFly widgets as Web Components (Custom Elements), in pure ES6.

Introduction

Web Components are a collection of technologies used for creating custom reusable widgets in pure JavaScript without requiring any toolkit such as jQuery or AngularJS. The main aim of web components is to be reusable as well as to provide seamless integration with HTML DOM.

PatternFly is a project for creating a set of UI guidelines as well as its reference implementation, for building the interface of enterprise applications. It is based on popular CSS library Bootstrap to provide styles and widgets, as well as a collection of other components frequently used in enterprise applications such as charts, wizards and information cards.

PatternFly web components is an effort to package existing PatternFly widgets into easy to use, reusable packages consisting of custom elements implemented using the Custom Elements API of the web components standard.

Project Goals

1. Implementing PatternFly widgets as HTML custom components.
2. Interop with front end frameworks like React and Angular.
3. Packaging widgets as self contained libraries, with minimal dependencies.

Deliverables

Implementation of the following widgets as HTML custom elements.

1. Spinner
2. Time Picker
3. Date Picker

Stretch goals:

1. Count Remaining Characters

Implementation

This project will implement PatternFly widgets as HTML Custom Elements, using a transitional design to support both Custom Elements v0 API as well as Custom Elements v1 API of the HTML Custom Element specification. One of the design goals is also to support the reuse of the same web components in Angular and React as well.

Timeline

Phase I - Learning, ideation and preparation

May 5th - 1st June (during community bonding period):

• Discuss with the community to decide on the exact particulars of the implementation, code styles, possible pitfalls etc.
• Develop additional widgets, which would help me practice my concepts about web components.

Phase 2 - Coding

Week 1 (1st June - 6th June):

• Implementation and testing of the spinner component.

Week 2 (7th June - 13th June):

• Submit PR for spinner.
• Improving spinner component based on review by the community.

Week 3 (14th June - 21nd June):

• Begin implementation of the time picker component.

Week 4 (21nd - 26th June):

• Testing the time picker component.
• Prepare for 1st term evaluation

Week 5 (29th June - 6th July):

• Submit PR for time picker.
• Improving time picker component, based on review.

Week 6 (7th July - 13th July):

• Begin implementing datepicker component.

Week 7 (14th July - 20th July):

• Continue with implementation of datepicker component

Week 8 (21st July - 26th July):

• Continue implementing the datepicker component.
• Prepare for 2nd term evaluation

Week 9 (29th July - 5th August):

• Start writing tests for datepicker component.
• Submit PR for datepicker component.

Phase 3 - Improvements, Testing and Documentation

Week 10 (6th August - 12th August):

• Improve datepicker component based on community review.
• Revisit all the components and fix any issues that remain.

Week 11 (12th August - 18th August):

• Ensure interop of elements with Angular, React and Custom Elements v1 API.
• Buffer time for unforeseen circumstances.

Week 12 (19th August - 25th August):

• Prepare for final evaluation.

Why did I choose this project ?

Web components are the future of how web apps are going to be developed in future. I am always keen to learn new technologies and learning to implement web components has been great so far.

In the due course of getting familiar with the code and development pattern of PatternFly Web components, I have been learning a lot about JavaScript and its behavior in browser . It is an exciting experience overall. I wish to have the same excitement while contributing to the project as the part of GSoC.

Experience

I have been learning HTML since 6th grade as a part of my computer science paper. I started learning JavaScript in 8th grade. I have been a freelancer developing web sites in ASP.NET and PHP since 2013. I have also done a few projects in AngularJS.

Last summer, I had interned at an educational startup (and subsequently worked part time of 8 months). This is where I was introduced to web components. The work involved using components from Polymer Project to build a progressive web app for reading books and taking notes. It also involved a lot of jQuery.

Contributions to this project

I have been working on implementing the accordion component.

Pull request: #30 - pf-accordion component

Related issue: #25 - pf-accordion development

.NET Core Wrapper For systemd

The detailed proposal for this idea can be found here

Abstract

This project aims to create a .NET core wrapper library for systemd, a service manager and process hypervisor in modern Linux systems. Using this library, actions such as monitoring and controlling the state of services, controlling power, devices and other system aspects of the underlying system can be performed from a language running on .NET, such as C#.

Project Goals

Create a .NET wrapper for systemd, that will be able to:

1. Fetch a list of services available on the host.
2. Fetch a service by its unit ID.
3. Control the state of a service - enable, disable, start, stop, restart, reload and kill.
4. Control the power state of the system - restart, shutdown, suspend and halt.
5. Create events to listen for various systemd signals.

Optional Goals (if time permits)

1. Logging interface to log using systemd-journald

Deliverables

1st evaluation

1. Implementation of the following interfaces in C#, and the binding using DBus APIs.
   1. org.freedesktop.systemd1.Manager
   2. org.freedesktop.systemd1.Unit
   3. org.freedesktop.systemd1.Job
2. Library will be able to query a service’s status, start, stop and restart services. It will also list all currently running services.

2nd evaluation

1. Implementation of systemd signals.
2. Implementation of the following interfaces in C#, and the binding using DBus APIs.
   • org.freedesktop.login1.Manager
   • org.freedesktop.login1.User
   • org.freedesktop.login1.Session
   • org.freedesktop.login1.Seat
3. Library will be able to shutdown and reboot the host, schedule reboots, display and logout users and their sessions.

3rd evaluation

1. A systemd wrapper library, published as a nuget package.

Implementation

We will be implementing the interface to systemd service manager and the systemd-logind manager. We are going to use the DBus API of systemd to make inter-process calls to systemd daemon. For DBus in C#, We will be using Tom Deseyn’s Tmds.DBus library.

The library

The library will contain a set of interfaces that specifies the general API for interacting with systemd from .NET. Any implementations are required to provide the same set of methods. This set of interfaces will make the primary part that a consumer using the library will use.

Implementation using DBus

The default implementation included with this library will be an implementation of ISystemdManager which will use DBus as its medium to connect to the local host’s DBus running on the system bus and the session bus.

The systemd service manager is available at org.freedesktop.systemd1.Manager DBus interface in the system bus and session bus. The systemd interface on system bus is used to control system wide services, and the interface on session bus is used to control user services.

The systemd-logind is available at org.freedesktop.login1.Manager DBus interface in the system bus.

The default implementation will be set of classes under the implementation namespace. The classes will proxy all method calls to DBus interfaces using Tmds.DBus.

The general pattern for all classes in the implementation will be: Constructor that accepts the underlying DBus interface for the class. Methods that when invoked will call methods on the DBus interface.

Timeline

Phase I - Learning, ideation and preparation

• May 5 - second week of May:
  • Learn more about systemd and its dbus interface.
  • Discuss with the community to decide on the exact particulars of the implementation, library pattern, code styles, possible pitfalls etc.
  • Learn about publishing packages to NuGet.
• Third week May - 1st of June (during community bonding period):
  • Setting up IDEs, Git repositories etc.
  • Setting up a local testing environment.
  • Creating classes and interfaces for systemd for use with the DBus API.

Phase 2 - Coding for the systemd manager:

• Week 1 (1st June - 6th June):
  • Connecting to a running systemd instance.
  • Handling and generating proper exceptions.
• Week 2 (7th June - 13th June):
  • Listing active services and their status.
  • Finding an installed service by its id.
• Week 3 (14th June - 21nd June):
  • Enabling and disabling unit files.
  • Start, Stop, Kill, Restart and Reload units.
• Week 4 (21nd - 26th June):
  • Fix bugs and write additional tests.
  • Prepare for 1st term evaluation.
• Week 5 (29th June - 6th July):
  • Begin implementing the systemd-logind wrapper.
  • Library will now be able to shutdown, restart and halt the host.
• Week 6 (7th July - 13th July):
  • Fetching users, sessions and seat from logind.
  • Operations on users, sessions and seats - Kill, Terminate
• Week 7 (14th July - 20th July):
  • Test seat operations on a real multi-seat setup.
• Week 8 (21st July - 26th July):
  • Write more tests
  • Prepare for 2nd term evaluation

Phase III - Testing, Optimization and Documentation

• Week 9 (29th July - 5th August):
  • Resolve discovered issues.
  • Incorporate suggestions by the community.
  • Check test code coverage of the library
  • Test on real hosts
• Week 10 (6th August - 12th August):
  • Write more tests if required.
  • Review inline documentation and fix them
  • Prepare HTML documentation
  • Document testing processes.
• Week 11 (12th August - 18th August):
  • Buffer time for unforeseen circumstances.
• Week 12 (19th August - 25th August):
  • Publish package to nuget, after approval.
  • Prepare for final evaluation.

Why did I choose this project ?

.NET core is a budding open source platform, based on the foundation of the well tested .NET framework. It is cross-platform and has the potential to become a great server side framework, in near future.

However, one of the of hurdles for developing solutions in .NET in Linux has been the lack of decent libraries for system integration. This project is a step towards bridging those gaps and bringing a deeper system integration to .NET core applications.

Experience

I have been writing code in .NET over last four years. I am confident enough about my skills in the language. I have completed a number of projects using .NET. I also have a good experience in object oriented programming concepts and software testing.

Being a long time Fedora user and a programmer with curiosity, I am familiar with the internal workings of a Linux system and system APIs. I have worked with DBus (though mostly in Python and Go) as part of two hobby projects.

Periods of unavailability or other constraints:

• May 2 to May 20: I have my end semester exams from during this period.
• August 3rd week onwards: My classes are expected to begin from 3rd week of August. During that period, I would be able to give less time to my project, (about 25 hours, instead of 30 - 35 in other periods).