Saturday, 21 March 2015

Ushahidi Web Further Impressions

In an earlier post i gave a brief explanation of a open-source project i would be working on called Ushahidi Web. I have now committed to the project at least 12 hours of my time into the project and have now gained enough knowledge to make a few very basic assessments about the project itself. My opinions about the project should be taken lightly as i do not pretend to know everything about the project and could have possibly had greater success working on the project if i had time to learn more about it. 

For the project i decided (after getting no response on IRC) to work on a new feature proposed in the issues category (#1016). The feature that was requested was to make it so you could display more map markers on the map using the side menu filters. Starting out this seemed like it would be a decent task for a new participant of the project. Or so i thought.

Again, it is important to remember that i do not know nor pretend to know everything about this project. The first problem i hit was trying to figure out how the pages were wired together as i had never worked with the Kohana framework before. I read through their documentation and after a couple of hours playing with Google Chromes inspect object i was able to determine how the main_js.php view is hooked into the Json.php and main.php controllers. Unfortunately this is where things started to become more problematic. 

I originally found it strange that the main_js.php view was not actually found under the views folder but rather was placed in themes folder. To a new project coder this made it difficult to figure out how pages were constructed. Another thing i found problematic is that there was very little documentation on how pages were put together. Even when i looked at the documentation for the Kohana framework i found that there were many points where method names did not seem to show up under Ushahidi's Models or Controllers nor under Kohana's built in options.

Up to this point i was able to commit and add some code to the main GUI page and JSON get methods that allowed the filters to have a multiple select option. This was however the end of my success. 



I went on the IRC again in hopes that i would be able to get some  help in determining how Ushahidi calls Event::run methods but unfortunately there was no reply. Additionally when i looked back at the features section i had noticed that many of the features being requested were being added to Ushahidi's version 3 feature list. This lead me to believe they were more then likely not working on version 2 as much anymore. 

Overall i found working on this open source project to be rather frustrating as the lack of beginners documentation and limited communication on the IRC channel left me trying to figure out the project using 'black box' testing. This is not to say i would not work on this project in the future when i have more time. For now though i am too busy (being a student) to continue working on this project blindly in light of a newer version being released potentially at anytime.

Monday, 9 March 2015

Ushahidi Web Initial Impressions

Recently i was tasked with participating in a open-source project that available on Git Hub. Reading through multiple projects, of which i learned about through Code Triage, I gaining a general idea of what projects were currently available and openly being worked on. Additionally when reading through the documentation i gained a general respect for protects which included more initial setup help as well as having extended documentation. For these reasons i ended up joining a project called Ushahidi Web. I chose this project in the end for a many reasons, the main ones being:

  • This project was recommended to us by the task creator
  • The project had a very simplified installation setup
  • The Project community was active recently and still had an open IRC
After i had established that this was the project i wanted to be involved in i started to go through their install guide that they use to test/run the project. While their article covered most of the steps on how to install the application it did not have steps for installing directly into a separate PHP environment like WAMP. This created a couple of issues in installing/compiling the project in one step. These issues were not directly related to the project itself (as its instructions were meant to run on Linux). I did have to find a handful of workarounds to initial WAMP issues. The two large issues i had related to:
  • MySQL user@localhost access denied
    • This issue was caused by user not having grant access and a password
      • This was a default in WAMP on 'root' user
      • By creating a new user and giving him select, update, delete and 'show data schema' this issue was resolved
  • URL 404 error on any page not running off index.php 
    • This issue was caused by a feature called 'rewrite_module' being off
      • Once this was toggled back on I was able to log in and navigate around the different pages without issue
The project has been impressive so far in how easy they have made getting into the project community. After dealing with the initial installation issues i was ready to start working. At this point i went back to the community and posted a question on the IRC channel. At this point i am looking for a little help from the community to see if they can better assign me a issue/feature to work on. The worst case scenario is that i will simply end up looking around the reported issues page and see if there is anything that i can contribute. In doing this i will learn more about the project and gain a better understanding of Ushahidi Web.


Saturday, 24 January 2015

Sencha Touch 2.x.x Vs. Native

In my recent adventures as a junior programmer at a company i was introduced to a new development environment built using a framework called ExtJS. The purpose of said framework was to allow a company to build mobile applications based off of HTML5 and javascript. Specifically this framework targets two types of mobile devices; the primary one being IOS and the other being Android.

Already you may be asking yourself, why would i want to build a mobile application in this framework rather then use XCode or Android Studio (both native build environments)? I asked myself the same question when the software package was placed in my hands. When i originally started working with Sencha i was also taking classes to try and learn how to use XCode on OSX and had very little understanding of either environment.  Over time i have learned a fair amount of the nuances about both these software products and have come to see the advantages of using one over another. Theses are the issues i will be discussing; starting with cross compatibility:

Cross compatibility: 
Right out of the gate Sencha has the advantage here. The very concept of Sencha is to allow a app developer to easily swap between different platform builds using a combination of plugins and simple setting toggles. They have accomplished this. Android Studio and XCode both use their own proprietary setups that are not intended to be cross compatible as XCode (Apple) does not make plugins for Android and vice-versa. The fundamental concept though is that Sencha only has a serious advantage is starting from scratch.

In our case the IOS app was complete, and we only really needed an Android variant. This rendered the primary Sencha advantage obsolete and added complexity of not using native environment options directly (extra settings). Additionally we later learned that for $30,000 we could get a converter software for converting objective-c into Android APK, which when compared to the salary of a programmer was a bargain.

Advantage: Sencha (only from scratch)

Ease of use:
This issue became a fundamental problem for Sencha as time went on. The more complex your app became the more difficult it became to fix/enhance. The framework did not allow for creating sub-folders for views. This created an issue once the amount of views/models/stores we had exceeded 30 as it was very difficult to locate the code you wanted. On top of this issue there were no 'real' custom controls. I use the word 'real' loosely as you could technically override HTML placement; but, this tended to lead to other formatting issues later as you would have to push existing functionality out of the way rather then remove it. This created extra overhead on load and caused weird CSS shifts. In XCode, the programmer could easily make custom cells that could contain custom constraints and easily be manipulated into menus and lists. Additionally Sencha lacked basic controls like navigation controller (which had to be programmed by hand). This added unnecessary complexity considering the commonness of use. Looking at Android Studio, they to had this sort of controller functionality.

Advantage: Native (no contest)

Reliability:

This is the crux of the matter. Sencha's upgrade ability is basically abysmal.  When we tried adding another developer to the project, we were forced to upgrade to the newest version of the software because the existing software had been 'improved'. This transition forced us to move from Sencha Touch 2.3.1 to version 2.4.1 which were primarily feature enhancements. This process completely and utterly destroyed the build. Code that had been proven to work on version 2.3 now was unable to compile properly as the update had apparently misplaced bootstrap configurations and resource management files had been spread to the wind. Additionally since Sencha compiler is a set of different frameworks it kept multiple versions of the same files, making it very difficult to know who the culprit broken files were. In XCode and Android Studio i simply updated my IDE environment, switched to the new API Compiler i wanted, and pressed build. No mess, no issue.

Advantage: Native (no contest)

In conclusion, i have found that the supposed advantages of being able to move cross platform using a interpretive language creates more problems then it is trying to solve. Unless the application you are building is simple, a project can easily get out of hand and unmanageable. As a software development company this is an unacceptable practice as it will eventually be the reason the software is abandoned.