Posts

Home / Posts

OSD600 Week Four Deliverable

Developers, programmers and even the occasional hobbyist are a hot topic this decade, knowing just their contributions alone can shape modern day enterprises and the technological stack of tomorrow’s gadgets. Google, a company familiar to anyone who’s rejected the living-under-rocks lifestyle is renown for providing their employees with perks that make even the most well-established yearn for. Perks so unique and sometimes life changing in fact, that they influence your reasons as to why you’d ever need anything else -or seek anything else.

It’s no secret that corporations attempt to entice as many developers as they can with perks, platforms and offerings that can sway even the hobbyist to their side. Github, the ‘go to standard’ of all forms of version control hosting has played their own moves in the same game, with the ever-so-popular Github Pages being their first means of developer seduction.

Created to ‘celebrate’ your projects, this platform allowed one to host a static website directly from their respective repository without too much work. These static websites allowed for elegant, simplistic means of conveying content, project details and relevant information for developers to pour their celebrations, contributions and modifications into with ease. Because they are legitimate, static web pages, even search engines provide promotion and easy discovery of your project at no extra cost.

For this week, our assignment was to go through a obstacle course of instructions, related to Git which would come to a closing Github Page being published under a forked Spoon-Knife repository. The first task was learn how to interact with branches, starting with commands such as:

After, we were granted the unfortunate opportunity to work with unfriendly git merges, all the while creating more branches to add to the chaos. By the end of the assignment, too many branches were created (a few on my part due to ‘experiments’) than should have existed. To remedy this issue, I quickly consulted Google’s wisdom which suggested:

Which would delete a local branch. Deleting from a remote branch it suggested, would look like the following:

Once the merging madness was complete, it was time to show off this item to the world. After converting the animals.txt file which we used above to HTML, the next step was to commit the file to this unique branch,

Once this was done, the page was accessible just like a standard web page using the following link: https://raygervais.github.io/Spoon-Knife/animals.html. I must promote this work of art here for I doubt Google’s web crawlers will value mine above the EXACT SAME FILE as my peers. Regardless, this introduction to Github’s Pages was an interesting lesson which I’m certain will be valuable for future projects.

Common Git Commands

Command Description
 

 
Creates a new local repository in the current directory
 

 
Create a working copy of a remote repository
 

 
List tracked changes in your files on the current branch
 

 
Create a new branch, then switch to it
 

 
Mark a release or changeset in the repository

For more commands, I’d recommend referencing Atlassian’s resources

Compiler Optimizations and Features

February 1, 2017 | Open Source | No Comments

An Intro, Deliverable Four for SPO600

When compiling projects, files and various utilities, the IDE you use takes care of quite a bit of background tasks, arguments and settings. Some of these settings and arguments can make quite the difference to the end product, relating to performance overhead, file size and included binaries which make up the final file. Exploring this topic, let’s examine some of these arguments and settings related to GCC, which are explained below, using a reference hello.c file which contains the following:

Arguments

Indicates that you’d like to name the output file as the argument provided, defaulting to a.out in most environments if this argument is not provided.

This enables debugging information

This indicates to the compiler that you do not want the program’s binary files to be optimized. There are a varying amount of optimizations that can occur to during the compilation of a program, and GCC allows for the a levelled approach to each optimization in the following way:

  • O1: This level compiles at a moderate pace, but reduces the code base to the smallest possible level. In doing so, a drawback is the lost of execution speed of the program.
  • O2: This level in contrast also compiles at a moderate pace, but only reduces the code footprint by so much, thus enabling a moderate rate of execution speed for the program.
  • O3: This level applies the most amount of optimizations to the source, making for slow compiler times but incredibly fast performance time in contrast. This, is due to a much larger file being created at the level which is highly optimized in contrast to the previous two options. This is the only tier which does not provide safety features.
  • Os: This level optimizes for code size only, without affecting the performance of the program.
  • Ofast: This follows the same optimizations as O3, with none accurate math calculations

This disables the builtin function optimizations found in various compilers. Doing so negates part of the compilers run time functions which would normally generate code to handle a subset of builtin functions more efficiently.

Effects on the Hello.c Program

The following results were recorded by using

which allows for recording the data into a text document for easier research.

Optimization Used File Size Notes
23.0KiB This was the original compilation to be used for the lab
9.8MiB The static argument option links a program statically to any dependencies, implying that the program does not require any dynamic libraries at run time to execute.
23.0KiB Removing the fno-builtin argument allows for the compiler to replace the print call with putchar instead, attempting to optimize the simply program this way.
15.3KiB Debugging information in the operating systems native format was not produced in this compilation. This reduces the size by 7.7KiB
16.0KiB Additional lines of code were added to the program, resulting in the the printf function being put inside a for loop, and displaying the current iteration of i.
17.0KiB Code is vastly more reliant on calls to memory locations in the file, with majority of the objects and variables being stored in registers

OSD600 Week Three Deliverable

Before I could attempt to fix this bug in Thimble, I had to setup a local brackets program first on my workstation. Doing so was simplistic, following a the steps found here:

  • Fork the Brackets repository and then clone it to your local machine using git clone –recursive https://github.com//brackets.git
  • In the cloned repository directory, run npm install to install the dependencies for Brackets
  • Run npm run build to create the built editor files that will be used by Thimble
  • Run npm start to start a server that will allow the editor to be accessed on http://localhost:8000/src


You can find out more information about setting up Brackets locally by referring to the instructions here
After successfully getting Brackets to run on my machine locally, the next step was to get Thimble and it’s services up and running. This involved forking and cloning the Thimble repository, and then running vagrant up. Because my workstation was running a minimalist package set, I had to install vagrant firstly before I could proceed. Then, running the previous command required my workstation to have Virtual Box installed, which at the time I didn’t. So, another call to the package manager and now I have Virtual Box running on the workstation. After installing any other dependencies, running vagrant up built thimble. The process took an estimated 20 minutes, but that was entirely dependant on the internet connection too. Once completed you can access Thimble by going to http://localhost:3500/en-US/#

SPO600 Week 2 Deliverable

Assembly language, a low level programming language which enables deeper integration with the supported machine’s architecture. An Assembly file is converted to machine code by using an assembler, which is a utility that converts the source code to binary. By utilizing Assembly, one has access to the respective register, flags, and memory operations of a CPU processor. These components differ by architecture, where aarch64 follows a different set of processor rule sets such as having a larger set of registers capable of floating point and data instructions, and different operation syntax.

For our introduction to programming Assembly for both architectures, groups of students were given a specific task. The program should loop a maximum of thirty times, while doing so printing the iteration of said loop to the screen. The implementations for both are linked to this blog post for those curious, both in binary and source code formats.

For the first few hours, Assembly seemed less like a comprehensible language and more like the ‘hell’ that many claim php to be. It took a while for the understanding to present itself just for the basic loop portion, let alone why we add the .data related variables into the correct registers for outputting. But, after quite a few tutorials both in person and through YouTube, I can safely say that I can read a hello world written in Assembly.

aarch64 Files

x86_64 Files

Open Source Contributions

January 22, 2017 | Open Source | No Comments

OSD600 Week 2 Deliverable

The world of Open Source communities is a special, magical place for developers to collaborate and contribute to projects that has the chance to affect millions of people. We, as a technologically driven generation have integrated applications into our lives that, developers built on top the foundations of open source platforms. With this statement, it’s easier to understand how a single algorithmic improvement to a code base shared among thousands of applications may benefit not just the developer, or the primary user of the program itself, but the entire populous which works with these applications daily, unaware of said applications dependence on the program you just contributed performance improvements and bug fixes to.

Contributions can improve a great many things, such as adding comments to others code, translating documentation, bug fixes and testing, performance improvements, new features, and specific requests from the development community such as migrations, integration and refactoring of code bases. With this, even the simplest addition of a key:value pair can benefit an application where appropriate. Take for example, popular npm packages such as glob, request, and mysql had a crucially important key:value pair missing from their package.json file (which is meta data read by npm for package discovery and information). Each missed the keywords element, which would allow others to search using general terms and discover said packages. Though these packages are popular, with some being install other 10,000 times a day currently, this element could potentially make or break the success of a package. In OSD600, our open source lab was to find and contribute the -missing-keyword fixes to packages that lacked said element, doing so with pull requests that followed the contribution paradigm set by the developers.

One critical platform stands among the rest for revolutionary Open Source projects, that being Linux. I’ve attached a video to this post explaining how Linux is built, which was published by the Linux Foundation in 2012. Needless to say, the potential that is enabled through Open Source is incredible.

Linux Package Build Process

January 18, 2017 | Open Source | No Comments

Code Building on Xerexes (x86_64)

SPO600 Week 1 Code Building Deliverable

GNUChess

1) Download newest file directory of gnuchess from
ftp://alpha.gnu.org/gnu/chess/gnuchess-5.9.90.tar.gz
2) Unpack into playground using gzip -d, followed by tar -xf
3) Ran ./Configure which presented no issues. I think someone else has already
installed this packaged before
4) Ran make, followed by make install.
5) Had to specify a local directory for the install files to avoid the program attempting
to install itself globally on the server.
6) In the src folder, copying the gnuchess.ini file to the specified folder (because it
does not copy correctly?) is required to run the application.
7) Enjoy terminal chess by running ./src/gnuchess

VIM

1) Cloned the git repo from github.com/vim/vim into my plaground directory
2) Ran ./configure –prefix=/home/####/playground/vim_install for predefined install
directory
3) Ran make, followed by make install.
4) Vim runs perfectly by running ./src/vim

The Differences between Git & SVN

January 18, 2017 | Uncategorized | No Comments

OSD600 Lecture Summary

Subversion (SVN) technologies used to be the go to for version control among developers, providing a workflow that many web developers endorsed comprising of a trunk directory which represented the latest stable release, and sub directories for new features that was labelled under individual branches in the directory structure. Furthermore, SVN utilized a centralized revision control model, citing this model would enable developers to have access to each part of the code base.

SVN is an Open Source technology licensed under the Apache license, but even with developer contributions the platform was limited in functionality and features. In recent years, SVN 1.8 attempted to remedy some of these limitations client side, while the server side repository followed SVN 1.5 operations. This included the concept of “renaming files” being a loosely stitched together feature which pre-1.8, would copy the file with the new name into the same directory, then delete the old file.

Git, created by Linus Torvalds quickly gained traction in the developer community for being more robust, feature-dense, and containing a workflow that was much more flexible in contrast. Git was built around the distributed revision control model, which allowed developers to work on separate branches and code bases without fear of destroying previous work. Git is now the leading version control system, employed across local and server repositories all over the world.

SPO600 Week 1 Deliverables

Django Open Source Python Framework

“Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Thanks for checking it out.”

License Type: BSD-3-Clause
Contribution Method: Mailing list, IRC, Ticket tracker / Pull Requests

Patch Review

This pull request was created by contributor timgrahm, who made 19 additions and 10 deletions to the tests/auth_tests/test_templates.py file.

Django uses Trac for managing the code base. This is a ticketing system which allows for open tickets to be reviewed, accepted and then checked into the code base assuming it passes inspection. If the ticket fails for a variety of common reasons such as duplicate, wontfix, invalid, needsinfo, worksforme or other, then the open ticket is closed and rejected. This is a good system for code review, but entirely relies on the developer community (which largely are volunteers) to keep up to date with many of the changes from multiple patches at once to ensure that updates do not break recently approved updates.

OptiKey Assertive On Screen Keyboard

“OptiKey is an assistive on-screen keyboard which runs on Windows. It is designed to be used with an eye-tracking device to assist with keyboard and mouse control for those living with motor and speech limitations, such as Amyotrophic Lateral Sclerosis (ALS) / Motor Neuron Disease (MND).”

License Type: GPL-3.0
Contribution Method: Pull Requests, Email

Patch Review

This pull request was created by contributor Razzeee, who changed seven files with 27 additions adn 176 deletions.

OptiKey relies on Email and Pull Requests from contributors through GitHub for code commits. JuliusSweetland originally started this as his way of giving back to the community, while providing those with ALS or MND an updated way to communicate. Though a hobby, Julius has found many collaborators who’ve helped him translate, optimize and increase the functionauilty while still being accessible to many. Because it’s managed solely by Julius, one downside to this system is that progression of the application is based on his pace. Being the sole reviewer of each patch, the project stalls if he cannot get to the patch reviews in a timely manner.

Kickstarter Android Application

OSD600 Open Source Blog

“Welcome to Kickstarter’s open source Android app! Come on in, take your shoes off, stay a while—explore how Kickstarter’s native squad has built and continues to build the app, discover our implementation of RxJava in logic- filled view models, and maybe even create an issue or two.”

Kickstarter, a company based around crowd funding and early adopting open sourced their respective iOS and Android applications on February 8, 2015. This the engineers response to Kickstarter becoming a Public Benefit Corporation, seeing open sourcing of their work could provide rich resources and ideas into the developer community as many others did.
The first two pull requests related to interface modifications and accessibility improvements. Expanding upon their knowledge and commitment to functional programming, the Kickstarter engineers created a lucrative experience for those browsing their source code by providing screenshots of the interface, excellent commenting, well rounded testing and their philosophy on view models.

The applications are written in the mobile devices native language, Swift and Java respectively for iOS and Android, and utilize many frameworks and third party extensions of each language.
The application is licensed with the Apache Version 2 license, which is explained here:

“The Apache License is permissive in that it does not require a derivative work of the software, or modifications to the original, to be distributed using the same license (unlike copyleft licenses – see comparison). It still requires application of the same license to all unmodified parts and, in every licensed file, any original copyright, patent, trademark, and attribution notices in redistributed code must be preserved (excluding notices that do not pertain to any part of the derivative works); and, in every licensed file changed, a notification must be added stating that changes have been made to that file.”

As of this moment, eleven issues on GitHub are open, many relating to the build process of the Android application for those wanting to extend the application beyond the original engineers implementations. Even more so, as pull requests are merged back into the code base after review, these updates are then patched into the next update of the application available to end users on the platforms app store. Brandon Williams, original developer of the iOS version has expressed interest in writing Kotlin code in their Android application while taking suggestions from the developer community.

Source Code to 2017

January 11, 2017 | Uncategorized | No Comments

With the start of the new year, and a semester which contains a promising set of courses that many are excited for, it’s appropriate that open source technologies have become the leading topic of this semester. OSD600 and SPO600 aim to guide us on many topics related to open source platforms, and promise that our contributions will benefit the everyday consumer in a variety of ways. With open source, the opportunities to shape the upcoming state of technology are endless, allowing us to contribute to the source code which will make up 2017.