Final submission post: Engelsystem

This summer has been really amazing, I learnt a lot and worked crazy hours it has been a crazy yet amazing ride. I am not going to stop working on open source projects and posting the blog post.

In this post, I would like to summarize all the work that I did during this summer. Working with FOSSASIA was an amazing experience for me. I got to learn a lot during this summer. Thanks to such amazing mentors.

My project Engelsystem is an online tool for helper and shift planning on major events. It lets the user organize their helper in teams, they share in layers or let them decide when and where they want to help themselves.

GithHub Commits
GithHub Commits


Codacy certifications

The Project was provided an A-Grade certificate from CODACY.

Here the link to view all my GitHub contributions to the project during this summer,

commits new 2
My GitHub Contributions (DishantK1807)

The list of issues solved and features implemented by me is provided below.

  1.    Themes


Creating new themes for Engelsystem. Two themes have been added to the system, Engelsystem color scheme-1 and Engelsystem color scheme-2.


  1.    Languages for Localisation



  1. [Language support-I]

Implement localization in different languages as it will make this system reach many people across the world. There 10+ International languages added to the system. The list of languages can be checked in the issue tracker


  1.    Added Travis-CI


Setup the Travis-CI for Engelsystem. Added a stable .travis.yml file to the system


  1.    Feature Request: User: Registration form



  1. [Marking First Name and Last Name as required]
  2. [Adding more item to the Registration form]

Adding more fields to the registration form(First name, Last Name, GitHub, Facbook, Twitter, Organization)


  1.    Feature Request: Admin: Export database of all Angels



  1. [Use temporary files for exporting the database]
  2. [Improve User export]
  3. [remove password hashes from the export]
  4. [Restore Frab import]

Exporting the database of the angels in the .csv format.


  1.    Feature Request: Admin: Shifts: Batch Deleting of Shifts



  1. [Adding checkboxes and delete button]

Implementing batch deleting of Shifts in the shifts page allowing the admin to delete multiple shifts at once. Created checkbox for selecting the shifts to be deleted and a delete button in the Shifts page to delete the selected shifts.


  1.    Feature Request: User: Registration Form and Shifts [Captcha]



  1. [Captcha in the Registration form]
  2. [Captcha in Shifts       page]
  3. [Documentation for captcha]
  4. [Refining captcha code]
  5. [Removing keys and added it via config.php]
  6. [enable and disable re-Captcha]

Implementing Google re-Captcha in the Registration form and Shifts pages for enhancing the security

  1.    DB: Convert char(1) to Booleans


This issue was listed in the engelsystem/engelsystem issue tracker.


  1.    Bug: Disallow self-signup of shifts



  1. [Create new Groups Page]
  2. [Providing Privileges to the new Groups Created]

Disallowing self-signup of restricted shifts when an Engel is approved for certain groups. Created a page to create new groups and provide specific privileges to them so that they won’t get Admin privileges to automatically signup for the Shifts

  1.  Feature: User: Date/time picker for Shifts


Implementing a date/time picker in the Shifts view for selecting the shifts.

  1.  Documentation: Setting up the system


Added documentation for setting up the system on the local as well as online server.


  1.  Feature: User : Registration Form: Check if E-mail already exist


Implement a check in the registration form to check if an Email already exists in the system.

  1.  User : Registration Form : Update database for setting email as unique


Set constraint in the registration from to set email as unique.

  1.  Solving bug


  1.  Implement database migrations


Worked in implementing database migrations for the system.

  1.  Improving code quality and documentation.



  1. [Code and branch cleanup]
  2. [Updating documentation]
  3. [Translate comments in install.sql]
  4. [Translating comments of user_shift.php and sys_template.php]
  5. [Cleanup Project: Delete Branches, set up development branch, deploy dev branch to heroku]
  6. [Improving documentation]


  1.  Feature Request: Creating new Settings page for Admin


Created a separate settings page for Admin, which allows admin to change specific Admin settings

  1.  Updating settings page for User


Updating the settings page for both Admin and User to change the new fields that were added to the registration form.

  1.  Updating users_view.php


Updating the users_view.php for the changes made in the Users table.

  1.  Update user_model.php


Updating the users_model.php for the changes made in the Users table.

  1.  Adding more search options in user_model


Implementing function for search by Facebook link, GitHub link, Twitter link, Organization name.

  1.  Feature Request: Languages as profile attributes



  1. [Updating the DB for `Users` table]
  2. [Updating the registration form]
  3. [Displaying native and other languages in the users view]
  1.  Adding forgot password link in the registration form


Adding forgot password link in the error message of the registration form, when “Email already exist” error message is displayed.

  1.  Integrate more automated testings to the system


Integrated Travis-CI, Codacy, Code climate, Circle-CI, Gemnasium to the system

  1.  Fixing errors Codacy and Circle-CI issues


  1.  Improving Code quality: Removing whitespaces, translating comments and soving CI issues


  1.  Implementing MVC model for the system



  1. [ Implement MVC for admin free, groups and import pages]
  2. [Implement MVC for admin rooms, settings, shifts pages]
  3. [Implement MVC for guest start, stats and user atom pages]
  4. [Implement MVC for user ical, messages, myshifts pages]
  5. [Implement MVC for user news, questions, settings and shifts pages]
  6. [Implement MVC for user_shifts]
  7. [Implementing MVC for the existing controller files]

There were 26 pages. Create controller files for all of them. For the pages which accesses the SQL queries, needed to be separated them into model files. There were only model files for a few pages.

  1.  Managing different events on the same system



  1. [Creating new table ‘Events’]
  2. [Create new Events page]
  1.  Implement an upgrade process for Engelsystem similar to WordPress



  1. [Add enable/disable for Auto-upgrade]
  1.  Writing tests for Travis-CI



  1. [update .travis.yml for setting up the database]

Setting up the database in travis. Updated .travis.yml for setting up the database for testing.

  1.  Writing test codes for all the model files



  1. [Write test codes for ShiftType, Shift models]
  2. [Test codes for NeededAngelType, Room, Angeltype Models]
  3. [Unit Tests for Groups, GroupPrivileges, NewsComments, News, Privileges model files]
  4. [Unit Tests for Questions, Settings, User AngelTypes, UserGroups, User, WelcomeMessage model files]
  1. Update Documentation
        Updated the documentation for the code.

This kind of make me feel happy that I have around 230 commits on the master branch now and I believe that I will be working a lot more on EngelSystem to bring a lot of cool and useful feature to it. In case you have any suggestion feel free to file issues on EngelSystem Issues.


Continue ReadingFinal submission post: Engelsystem

Auto Upgrade feature in Engelsystem​

In one of my previous blog posts here, I talked about the Upgrade process of WordPress, how it works. In this blog, I am going to talk about how I implement the Auto-upgrade feature in Engelsystem.

The Upgrade process implemented in Engelsystem includes both core and child upgrades.


  • A Verison.txt file in included in the repository. It contains the version number of the current release of the Engelsystem.
  • Implemented a check in index.php to compare the version number in the local repository and the `fossasia/engelsystem` repository. In Engelsystem index.php is run every time when we open the System. Therefore, everytime we open Engelsystem, it automatically checks for updates.
    if ($check_autoupdate_enable == true) {
      $online_ver = file_get_contents("");
      $current_ver = file_get_contents(" ./Version.txt");
      if (strcmp($current_ver, $online_ver) != 0) {
        return info('<a href="' . page_link_to("user_settings") . '">' . _('There is an Update available on GitHub! Go to settings and update') . '</a>', true);

    The above code compares the version number in the local server and the fossasia repository. If the version number is different a notification in displayed in the alert box the Engelsystem to the Admin, to update the system.

  • In the Settings page, Admin can update the System as shown in the screenshot below,
    Admin Settings Page
                                                                   Admin Settings Page

    The admin can click on the “Update System Now!”, to update the system to the latest version.

  • The is also an option provided in the UI to enable/disable the Auto-update feature.
  • When the version in the Version.txt on local server and fossasia repository are different, the changes the pulled to the local server using the command:
    git pull origin master , which will pull the changes from the FOSSASIA repository to the local server, and a Message will be displayed that the “System is Updated to Latest Version!” .

    After Updating
                                                                After Updating
  • Also, there is an option in the UI to check to Updates manually.

    We are developing new Features for the Engelsystem. Developers who are interested in contributing can work with us.

    Development:             Issues/Bugs:

Continue ReadingAuto Upgrade feature in Engelsystem​

Unit Testing and Travis

Tests are an important part of any software development process. We need to write test codes for any feature that we develop to check if that feature is working properly.
In this post, I am gonna talk about writing Unit tests and running those test codes.

If you are a developer, I assume you have heard about unit tests. Most of you probably even wrote one in your life. Unit testing is becoming more and more popular in software development. Let’s first talk about what Unit testing is:

What is unit testing?

Unit testing is the process through which units of source code are tested to verify if they work properly. Performing unit tests is a way to ensure that all functionalities of an application are working as they should. Unit tests inform the developer when a change in one unit interferes with the functionality of another. Modern unit testing frameworks are typically implemented using the same code used by the system under test. This enables a developer who is writing application code in a particular language to write their unit tests in that language as well.

What is a unit testing framework?

Unit testing frameworks are developed for the purpose of simplifying the process of unit-testing. Those frameworks enable the creation of Test Fixtures, which are classes that have specific attributes enabling them to be picked up by a Test Runner.

Although it is possible to perform unit tests without such a framework, the process can be difficult, complicated and very manual.

There are a lot of unit testing frameworks available. Each of the frameworks has its own merits and selecting one depends on what features are needed and the level of expertise of the development team. For my project, Engelsystem I choose PHPUnit as the testing framework.


With PHPUnit, the most basic thing you’ll write is a test case. A test case is just a term for a class with several different tests all related to the same functionality. There are a few rules you’ll need to worry about when writing your cases so that they’ll work with PHPUnit:

  • The test class would extend the PHPUnit_Framework_TestCase class.
  • The test parameters will never receive any parameters.

Below is an example of a test code from my project, Engelsystem


class ShiftTypes_Model_test extends PHPUnit_Framework_TestCase {

private $shift_id = null;

public function create_ShiftType(){
$this->shift_id = ShiftType_create('test', '1', 'test_description');

public function test_ShiftType_create() {
$count = count(ShiftTypes());

// There should be one more ShiftTypes now
$this->assertEquals(count(ShiftTypes()), $count + 1);

public function test_ShiftType(){
$shift_type = ShiftType($this->shift_id);
$this->assertTrue(count(ShiftTypes()) > 0);
$this->assertEquals($shift_type['name'], 'test');
$this->assertEquals(count(ShiftTypes()), 0);

public function teardown() {
if ($this->shift_id != null)



We can use different Assertions to test the functionality.

We are running these tests on Travis-CI

What is Travis-CI?

Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted on GitHub.

Open source projects may be tested at no charge via Private projects may be tested at the same location on a fee basis. TravisPro provides custom deployments of a proprietary version on the customer’s own hardware.

Although the source is technically free software and available piecemeal on GitHub under permissive licenses, the company notes that it is unlikely that casual users could successfully integrate it on their own platforms.

To get started with Travis-CI, visit the following link, Getting started with Travis-CI.

We are developing new feature for Engelsystem.  Developers who are interested in contributing can work with us.

Development:             Issues/Bugs:

Continue ReadingUnit Testing and Travis

Creating New Groups in Engelsystem

User roles determine the access level or permissions of a person authorized (by an Administrator) to use the Engelsystem. If a user (other than admin) have access to only a specific set of pages and features that are assigned to the Group to which the user belongs.


In Engelsystem, the Privileges to specific pages and features can be set through GroupRights. There are initially 7 groups present in the Engelsystem namely:

  1. Guest
  2. Engel
  3. Shift Coordinator
  4. Team Co-ordinator
  5. Burokrat
  6. Developer
  7. Shirt Manager

Each user role is capable of everything that a less powerful role is capable of. All of these 7 groups have different Privileges assigned to them. When a user registers on Engelsystem, it is initially assigned to Group-2 i.e Engel by default, then admin can add a user to different groups according to the requirements.


There was a problem with this feature.


If the user was added to the group with some Admin Privileges, he/she was able to sign up for restricted shifts as well.


Added a new page to Engelsystem for creating new Groups with specific privileges which can be that can be provided by the Admin to that group.

Create Groups page


New groups can be created by Admin, with default Privileges set to privileges as provided to the Engel group.These Privileges can be set while creating a group or can be edited in the GroupRights shown as follow:

Edit Privileges in GroupRights

The group is successfully created and can be viewed in GroupRights page, where the Admin can edit the Privileges of this and the other groups.

New group in GroupRights

Providing Privileges to user other than Admin is important as it ease the workload of admin, plus there’ll be other users who’ll be handling different tasks in an Event which is important in managing an Event.

We are developing new feature for Engelsystem and we will be applying this WordPress like update system toEngelsystem in the upcoming weeks. Developers who are interested in contributing can work with us.

Development:             Issues/Bugs:

Continue ReadingCreating New Groups in Engelsystem

Implementing MVC on Engelsystem

Engelsystem is an MVC based PHP application, but there was a 4th ties, Pages, introduced with the traditional MVC pattern. It seems to have everything an event manager could want.

The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on.

Like everything else in software engineering, it seems, the concept of Model-View-Controller was originally invented bySmalltalk programmers. More specifically, it was invented by one Smalltalk programmer, Trygve Reenskaug. Trygve maintains a page that explains the history of MVC in his own words.

Block Diagram for MVC
                                                                  Block Diagram for MVC


The components of an MVC pattern are explained as follows:

  1. MODEL: The Model is the name given to the permanent storage of the data used in the overall design.
    Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.
  2. VIEW: The View is where data, requested from the Model, is viewed and its final output is determined. A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.
    Traditionally in web apps built using MVC, the View is the part of the system where the HTML is generated and displayed. The View also ignites reactions from the user, who then goes on to interact with the Controller.
  3. CONTROLLER: The final component of the triad is the Controller.A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen.
    Its job is to handle data that the user inputs or submits, and update the Model accordingly. The Controller’s life blood is the user; without user interactions, the Controller has no purpose.


Even though MVC was originally designed for personal computing, it has been adapted and is widely being used by web developers due to its emphasis on separation of concerns, and thus indirectly, reusable code. The pattern encourages the development of modular systems, allowing developers to quickly update, add, or even remove functionality.



Initially, in Engelsystem there were files distributed in 4 tiers, Model, View, Controller, Pages, which are mentioned as follows:










There were 26 Pages files, in which there were both sql queries along with the controller code. All these files were refactured into Controller and Model(which contains sql queries) files seperately to implement proper MVC pattern in Engelsystem.


We are developing new feature for Engelsystem and we will be applying this WordPress like update system toEngelsystem in the upcoming weeks. Developers who are interested in contributing can work with us.

Development:             Issues/Bugs:

Continue ReadingImplementing MVC on Engelsystem

WordPress Upgrade Process

Have you ever wondered how WordPress handles the automated core, plugin, and theme upgrades? Well, it’s time for some quick education!

WordPress is an Open Source project, which means there are hundreds of people all over the world working on it. (More than most commercial platforms.)

There are mainly 2 kinds of Automatic upgrades for WordPress:

  • The main Core’ upgrades
  • The ‘Child’ upgrades, that works for themes and plugins that are being used in your WordPress.

We all see the plugin and theme installer while installing any theme or specific plugin required by the user, where it downloads the plugin to /wp-content/upgrade/ , extracts the plugin, deletes the old one (if an old one exists), and copies the new one. It is used every time we install a theme or a plugin to the WordPress.

Since this is used more often than the core updater (most of the time as many different plugins are used), it’s the sort of upgrade we’re all used to and familiar with. And we think ‘WordPress deletes before upgrading, sure.’ This makes sense. After all, you want to make sure to clean out the old files, especially the ones that aren’t used anymore.

But that not how the WordPress Core updates work.

Core updates are available when there is a new version of WordPress is available with new features or some solved bugs.

Core updates are subdivided into three types:

  1. Core development updates, known as the “bleeding edge”
  2. Minor core updates, such as maintenance and security releases
  3. Major core release updates

By default, every site has automatic updates enabled for minor core releases and translation files. Sites already running a development version also have automatic updates to further development versions enabled by default.

The WordPress updates can be configured by 2 ways:

  • defining constants in wp-config.php,
  • or adding filters using a Plugin

Let’s discuss for both the methods.

Configuration via wp-config.php

We can configure the wp-config.php to, disable automatic updates, and the core updates can be disabled or configured based on update type.

To completely disable all types of automatic updates, core or otherwise, add the following to your wp-config.php file:


To enable automatic updates for major releases or development purposes, the place to start is with the WP_AUTO_UPDATE_CORE constant. Defining this constant one of three ways allows you to blanket-enable, or blanket-disable several types of core updates at once.

define( 'WP_AUTO_UPDATE_CORE', true );

WP_AUTO_UPDATE_CORE can be defined with one of three values, each producing a different behavior:

  • Value of true – Development, minor, and major updates are all enabled
  • Value of false – Development, minor, and major updates are all disabled
  • Value of 'minor' – Minor updates are enabled, development, and major updates are disabled


Configuration via Filters using Plugins

Using filters allows for fine-tuned control of automatic updates.

The best place to put these filters is a must-use plugin.

Do not add add_filter() calls directly in wp-config.php. WordPress isn’t fully loaded and can cause conflicts with other applications such as WP-CLI.

We can also enable/disable all automatic updates by changing the values in the following filter:

add_filter( 'update_val', '__return_true' );

We can set the parameters update_val as mentioned below:

  • To disable the automatic updates we can set update_val to automatic_updater_disabled
  • To enable the automatci updates we can set update_val to different values as mentioned below:
    • auto_update_core to enable all the updates
    • allow_dev_auto_core_updates to enable the devlopement updates
    • allow_minor_auto_core_updates to enable minor updates
    • allow_major_auto_core_updates to enable the major updates

WordPress has a magnificent auto-update system that notifies you when new versions of the WordPress core, installed plugins or themes are available. The notifications are displayed in the Admin Bar and also on the plugins page where you can get more details about the new version.

To install the new version, you simply hit the “Update automatically” button. WordPress will automatically download the new package, extract it and replace the old files. No FTP, removing old files, and uploading is required.


There is also a dedicated page for updates which can be reached from the dashboard menu. It’s helpful when you want to do bulk updates of multiple plugins instead of updating each one separately. It also has a “Check Again” button which checks for new updates. By default, WordPress does this check every 12 hours.


In the later weeks, we will be applying this WordPress like update system to Engelsystem. Developers who are interested to contribute can work with us.

Development:             Issues/Bugs:


Continue ReadingWordPress Upgrade Process

Read and Understand Codacy Reports

To begin understanding reports, let’s start with what Codacy is.

So. What is Codacy?

Codacy is an automated code review tool that helps developers to save time in code reviews and to tackle technical debt. It centralises customizable code patterns and enforces them within engineering teams. Codacy tracks new issues by severity level for every commit and pull request.

It can be integrated with the GitHub repository to review every commit and pull request in terms of quality and errors. It checks code style, security, duplication, complexity and coverage on every change while tracking code quality throughout your sprints.

You can integrate Codacy in your private/public repository by going here. Sign up with your Github account and follow the steps mentioned. More information regarding GitHub integration can be found here.

Features of Codacy:


Now we get to understanding Codacy reports.

Below shows and image of how a Codacy dashboard looks like, to evaluate a project. To evaluate a project we should know what are the Software Metrics”.


A software metric is a standard of measure of a degree to which a software system or process possesses some property. Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonymous. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in the schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. You can learn about software metrics by visiting here.

A Codacy Dashboard provides answer to the following 3 main things:

  • What is the state of your projects code quality?
  • How is it evolving throughout time?
  • What are the hotspots in your code?

Component of the Dashboard:

  • Introduction: The Dashboard is the central screen of any project on Codacy.
  • Project Certification: After running a complete on the project or the GitHub repository, Codacy provides an overall grade to the project from A-F. The grade depends on the following parameters.
    • Error Prone
    • Code Complexity
    • Code Style
    • Unused Code
    • Security
    • Compatibility
    • Documentation
    • Performancedashboard-certification
  • Issues Breakdown: Issues breakdown represents the different issues from different areas in a pictorial representation. It provides a quick overview of the total number of issues in the repository and the breakdown per category.
    Issues Brakedown
    Users can click on the specific category for more details.
  • Code Coverage: If you setup the code coverage on your repository, you will be able to see the overall covered percentage on the dashboard. It will also show the files with the worst code coverage allowing you to directly jump to the file to see the details.
  • Goals: Users can define individual goals to remove errors and get better grades for their projects.
  • Historic data: Codacy dashboard also provides an analysis of the Historic data, so as to keep a track of the progress on improving the code, milestones covered in reaching the goal.

Codacy provides a nice dashboard showing the metrics. Codacy saves hours in code review and code quality monitoring, from small teams to big companies. And as the Codacy team itself says “LOVED BY DEVELOPERS”, being a developer I wouldn’t deny this statement. It helped a lot in improving the code quality of my project Engelsystem.

Development: Issues/Bugs:

Continue ReadingRead and Understand Codacy Reports

Continuous Integration and Automated Testing for Engelsystem

Every software development group tests its products, yet delivered software always has defects. Test engineers strive to catch them before the product is released but they always creep in and they often reappear, even with the best manual testing processes. Using automated testing is the best way to increase the effectiveness, efficiency and coverage of your software testing.

Manual software testing is performed by a human sitting in front of a computer carefully going through application screens, trying various usage and input combinations, comparing the results to the expected behavior and recording their observations. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations.

Continuous integration (CI) has emerged as one of the most efficient ways to develop code. But testing has not always been a major part of the CI conversation.

In some respects, that’s not surprising. Traditionally, CI has been all about speeding up the coding, building, and release process. Instead of having each programmer write code separately, integrate it manually, and then wait until the next daily or weekly build to see if the changes broke anything, CI lets developers code and compile on a virtually continuous basis. It also means developers and admins can work together seamlessly since the programming and build processes are always in sync.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

Solve problems quickly

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

  • Say goodbye to long and tense integrations
  • Increase visibility which enables greater communication
  • Catch issues fast and nip them in the bud
  • Spend less time debugging and more time adding features
  • Proceed with the confidence you’re building on a solid foundation
  • Stop waiting to find out if your code’s going to work
  • Reduce integration problems allowing you to deliver software more rapidly

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.”

– Martin Fowler, Chief Scientist, ThoughtWorks

Continuous Integration is backed by several important principles and practices.

Practices in Continuous Integration:

  • Maintain a single source repository
  • Automate the build
  • Make your build self-testing
  • Every commit should build on an integration machine
  • Keep the build fast
  • Test in a clone of the production environment
  • Make it easy for anyone to get the latest executable
  • Everyone can see what’s happening
  • Automate deployment

How to do Continuous Integration:

  • Developers check out code into their private workspaces.
  • When done, commit the changes to the repository.
  • The CI server monitors the repository and checks out changes when they occur.
  • The CI server builds the system and runs unit and integration tests.
  • The CI server releases deployable artifacts for testing.
  • The CI server assigns a build label to the version of the code it just built.
  • The CI server informs the team of the successful build.
  • If the build or tests fail, the CI server alerts the team.
  • The team fixes the issue at the earliest opportunity.
  • Continue to continually integrate and test throughout the project.

The CI implemented in Engelsystem are as follows:

  • Travis-CITravis CI is a hosted, distributed continuous integration service used to build and test software projects hosted on GitHub. It is integrated using the .travis.yml file in the root folder.
    language: php
    - '5.4'
    - '5.5'
    - '5.6'
    - '7.0'
    script: cd test && phpunit
  • Nitpick-CI:Automatic comments on PSR-2 violations in one click, so your team can focus on better code review. It requires one click for integratting with the repository.
  • Circle-CI: CircleCI was founded in 2011 with the mission of giving every developer state-of-the-art automated testing and continuous integration tools. It is integrated using a circle.yml file in the root folder of the repository.
    version: 5.4.5
    branch: master
    owner: fossasia
    - ./
    - curl -s | php
    - php composer.phar install -n
    - sed -i 's/^;//' ~/.phpenv/versions/$(phpenv global)/etc/conf.d/xdebug.ini
    - php test/
    - bash <(curl -s
  • Codacy: Check code style, security, duplication, complexity and coverage on every change while tracking code quality throughout your sprints.

Development: Issues/Bugs:

Continue ReadingContinuous Integration and Automated Testing for Engelsystem

Implementing Captcha for Engelsystem

Knock, knock. Who’s there? A spam bot.

If you’re a web administrator or website owner, then you are bound to know the ugly truth that is the Spam Bot. Someone, somewhere in the world must have made a deal with the Devil in hopes of a larger payout that didn’t exactly pan out the way they.

The goal of the volunteer system (Engelsystem) is to facilitate the work of event organizers and event volunteers. It would be creating problems if bots signup for shifts and fill all the vacancies.

Thanks to the mastermind behind them, those pesky little underlings crawl the web ready to cause mischief at every turn. This means more work and more time eaten up for the honest web admin/event organizer who is left to clean up the mess left in their wake.


CAPTCHAs are nothing new to the experienced web surfer. Sites/web apps, both large and small, use the system for one reason or another.

But, ever wonder where in the world the people who coined the phrase, CAPTCHA, came up with that nonsensical name? Well, you may find it interesting to know that the strange word is actually a clever acronym meaning the following:

Completely Automated Public Test to tell Computers and Humans Apart.

What a mouthful! Now aren’t you happy that they shortened it?

The actual meaning of the word essentially explains exactly what its purpose is: keeping pesky bots out and letting in well-meaning humans (or at least that is the hope).

We worked on implementing Google reCaptcha to the registration form and to the shifts signup page.


On websites using this new API, a significant number of users will be able to securely and easily verify they’re human without actually having to solve a CAPTCHA. Instead, with just a single click, they’ll confirm they are not a robot.11

Client-side integration:

if (isset($_REQUEST['g-recaptcha-response']) && !empty($_REQUEST['g-recaptcha-response'])) {
      $curl = curl_init();
      curl_setopt_array($curl, [
        CURLOPT_URL => 'hppts://',
        CURLOPT_POST => 1,
          'secret' => '', // Enter your private key here.
          'response' => $_REQUEST['g-recaptcha-response'],
      $response = json_decode(curl_exec($curl));
      $msg .= error(sprintf(_(print_r($response)), $nick), true);
    else {
      $ok = false;
      $msg .= error(_("You are a Robot."), true);

Captcha Shifts Signup Page
                                                     Captcha Shifts Signup Page

If the System is hosted on an online server, the user needs to register and get the API keys for implementing Google reCaptcha here.

Final Thoughts

Spam is a big issue for all websites, including sites ran on WordPress. Although CAPTCHA forms don’t completely eliminate spam mongers, when you use it with other popular spam blocking plugins like Akismet, you really do have the advantage on the spam bot battlefield.

Development:                                           Issues/Bugs:

Continue ReadingImplementing Captcha for Engelsystem

Why Coding Standards Matter

Coding standards are a set of guidelines, best practices, programming styles and conventions that developers adhere to when writing source code for a project. All big software companies have them.

A coding standards document tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to the standards outlined in the document. This makes sure that a large project is coded in a consistent style — parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application.

When you start sharing code or start reading code shared by others, you begin to realize that not everybody writes their code they way you do. You see that other, ugly coding style, and think “everybody needs to write in the same style so that things are easier for me to understand.”

Thus, it is natural that everybody wants their own habits turned into the standard, so they don’t have to change their habits. They’re used to reading code a certain way (their own way) and get irritated when they see the code in a different format. The thing about defining a coding style standard is that there are no objective means by which to judge one style as “better” or “more-right” than another. Sure, we can talk about “readability” and “consistency” but what is readable is different for each coder (depending on what they’re used to) and consistency follows automatically because, well, why would you use another style?

Other than in the broadest outlines, defining a coding standard is an exercise in arbitrariness. Who says that a 75 character line is better than 72, or 80? Who says putting braces in one place is better than putting them elsewhere? And who are they to say; by what standard do they judge?

The point of a coding style standard is not to say one style is objectively better than another in the sense of the specific details (75 characters and one-true-brace convention, for example). Instead, the point is to set up known expectations on how code is going to look.

For example, my project Engelsystem,it is a project written by more than one person. If you examine some Script A and see one coding style, then examine Script B and see another, the effect is very jarring; they don’t look like they belong to the same project. Similarly, when I, a Developer, (who uses one coding style) attempts to patch or add to a separate project from other Developer (who uses another coding style) the mix-and-match result in the same project (or even the same file!) is doubly jarring.

Another example that I can think of: a manager who insisted on being part of every major code review. During the reviews, he would flag formatting issues, that were almost always a matter of his own preference, as “errors”. The worst part of the story is that he hadn’t written down his coding standards anywhere! I guess he thought developers would learn his style through osmosis. Sometimes, it felt as if he made up rules on the fly. As I mentioned in my post on conducting effective code reviews, it is useless arguing over formatting issues if you don’t have coding standards.

As Open Source PHP developers, we need to define and adhere to a coding style not because one is better than another but because we need a standard by which to collaborate/contribute. In that sense, coding style is very important; not for itself, but for the social effects generated by adherence to defined standards.

It is for this reason that I abandoned “my” coding style to adopt the Drupal coding standard for my Google Summer of Code project (Engelsystem). Sometimes you need to give up a small thing to gain a greater thing; by giving up my coding style, I had to change my habits; but now, anybody familiar with the Drupal standard can read my code and add to it in a recognizable way.

Why Designers Should Care About Coding Standards

For many web designers, matters of code standards and style are often left in the hands of their fellow developers. You give developers their deserved space to wield their magic to turn your designs into functional products that people love to use. The team’s coding standards are often the last thing on your mind. So why should you and other designers care?

Tech debt steals time away from new features and enhancements

The next time you are ready to go with a newly designed feature, you might find its development gets stuck behind a mountain of tech debt. Addressing tech debt at a reasonable pace throughout the life of a product can prevent it from piling up to a point where feature work gets put on hold. Better yet, if these issues are caught during initial development, that tech debt might be avoided in the first place.

It can be in your best interest to encourage developers to address issues in the code as they arise, rather than focusing only on design. Failing to fix these issues will cost you in future sprints.

Get better at your own craft

Understanding what it takes to build great software ultimately makes you a better designer. Whether you want to improve how you write your own front-end code if that’s your thing or gain a better appreciation of the time and effort it takes to build products, your practical experience will allow you gauge future work and effort.

A lot of similarities exist between coding standards and design standards. Just as you wouldn’t want a designer to go off-brand, developers have the same standards they want to maintain their code.

Code should look good too

Steve Jobs was famously renowned for being picky about both the externals as well as the internals of Apple products. Your beautiful UI work can only go so far if it isn’t built on a solid foundation of code. Pushing through a feature without appreciating the work to build it properly can lead to bugs later. The right amount of time and attention at the initial development cycle can reduce these mistakes.

Designers can be champions for well-written code. Just as you appreciate the details in designing great user interfaces and experiences, appreciation of the time and effort it takes to build those properly goes a long way.

In the later weeks, other developers and I would be working on adding more features to the system(Engelsystem), following the coding standard, as mentioned above. Anyone who would like to work in the project is welcome. Developers can feel free to take up any issues they would like to work on just like any other open source projects.

Development:                                           Issues/Bugs:

Continue ReadingWhy Coding Standards Matter