Month: April 2018

Home / Month: April 2018

The day has finally come, the start of the much discussed 100 days of code! The official website can be found here: 100daysofcode.com, which explains the methodologies and why(s) of the challenge. I decided that it would be the best way to start learning new languages and concepts that I’ve always wanted to have experience in, such as Python, Swift, Rust, and GoLang. The first and primary scope is to learn Python, and have a comfort with the language similar to how I do with C and C++.

Expectations & Challenges

I’m not nervous at all with the idea of learning Python, but I’m concerned with being able to do an hour of personal programming daily at a consistent rate. Being realistic, right now I still spend three hours commuting on bus and trains, crowed to the degree where it’s not viable to even program on a Tablet or Netbook. These coding hours I imagine will be affiliated with the later hours, since I am no morning person.

I also expect to become rather well acquainted with Python 3 within a week or few, and have begun thinking of ways to further my development with the language by using or contributing to python projects such as Django, Home-Assistant, Pelican, and Beets for example. This will vary or expand as we get further into the process.

Once content, I want to move to Swift and relearn what I had previous did in the Seneca iOS Course, attempting to further my understanding and building applications in the same time. I think the end result being a iOS application with a Python back end would be a beautiful ending, don’t you agree? We’ll see.

Here We Go

I cannot say that I will blog everyday for the challenge, but instead will try my hardest to keep those interested through my twitter handle @GervaisRay. Furthermore, you can keep track of my progress here where I’ll attempt to update the week’s README with relevant context and thoughts.

This will be fun, and I can’t wait to see how I, and my peers do throughout the challenge.

An OSD700 Contribution Update

So here we are, potentially the last contribution to occur for OSD700 from this developer before the semester ends and marks are finalized. No pressure.

For this round, I wanted to tackle a feature request which I thought would be beneficial for those who utilize the date picker component (a common UI element). The concept is to dynamically remove and add years to the overall date picker based on the min and max date configurations. Sounds rather simple, right? I thought so, but I also had to admit my lack of experience working with the code which dynamically generated the calendar and years portion to this degree before. The inner workings are vastly complex and data driven, which in itself is an interesting design.

The process so far while working on this has been an off and on “hey I get this”, and “I have no idea what to do with the current concepts”. You can see throughout my work in progress the various off and on’s when it comes to understanding, implementing and asking for advice / suggestions which gets us to where we are now. Currently, as I’m writing this, with the help of mmalerba and WizardPC, I have the dynamic year portion working as desired; some artifacts needed to be addressed such as the displayed year range in the header needed to be updated, the years-per-page seem to overlap on the final year if over 24 years gap between min and max, and a potential ‘today’ variable which isn’t always the current date.

There have been many revisions to the code base that I’ve been playing in, often rearranging logic and algorithms to accommodate the four edge cases which are:
1. With no Min / Max provided: the Multi-Year Date Picker behaves as current implementation
2. Only min date provided: Year offset is set to 0, making the min-year the first entry
3. Only max date provided: Year offset is set to a calculated index which equates to max-year being the last entry
4. Both min and max provided: Follows same logic as case 3.

The process of making the first edge and second edge case were relatively painless, this in part also due to the advice and comments left prior to me even writing my first line for this feature set. I’ve included below this that revision and various revisions I had attempted (skipping over the minor changesets) until I finally had the working version a few days later. You can see the progress in my WIP pull request here.

Revision #1 (Min Date Working as Expected)

After I clarified that this was indeed what we wanted for the second use case (min provided), now came the harder algorithmic portion for use case 3 and 4. What I’m working around looks like the following:

Revision #2 (A lot closer to expected logic)

The snippet below was the logic which should be followed, at first I thought nothing of it, but I realized that (yearOffset – Math.floor(yearOffset) would 100% return 0.

Revision #3 (Snippet)

Final Working (Pre Syntax Cleanup)

Words cannot describe the waves of frustrated “this will never work” monologues and “this is progress” relived exhales occurred during the past week while working on this feature, nor can words describe the amount of dancing-while-no-one-is-around that I did when I finally reached the current implementation. Based on the use cases mentioned above, here is a visual for each:

Case 1: No Min / Max Date Provided

Case 1: Min Date Provided

Case 1: Max Date Provided

Case 1: Both Min / Max Date Provided

I simply cannot explain the thought process which came to the final conclusion, more so I am able to explain the biggest flaw I had in my own thinking. I over thought quite a bit, and more so became overwhelmed with the thought that I would not complete this or the code base was too complex (I will, it’s not). I suppose the time of day I typically worked on this bug didn’t cater well to the mentality while approaching the code, nor my mindset of ‘one more item due’. Once I took the weekend to correct that, and to slowly relearn the task required and the changes (instead of breaking the scope into much bigger unmanageable portions in attempt to ‘get it done’), thoughts and attempts became much clearer.

Whats left? Well, at the time of writing this post I still have to fix the headers, isolate, identify and fix any edge cases which the algorithm doesn’t take into account, and also clean up the code of any useless commented out code. I believe that it can be done, and after the progress today I can happily say that I’m more optimistic than I was on Friday to complete this feature request. I’ve loved contributing, learning what I can through toil and success and also feeling the “I can accomplish” anything high when the pieces finally click. Once I settle down in my new role, I hope to keep contributing both to Angular Material, and new projects which span different disiplines and interests.

A OSD700 Contribution Post

For the final release, one of the issues I wanted to focus on was this, which I figured would be an easy contribution toward the project and a check off of my final release requirements. After reviewing the comments on the issue, I was under the impression that I had to learn a new accessibly standard titled aXe. aXe was going to be the driving force behind this post, but to my fortune it’s more of a testing engine than a standard; testing instead web applications and pages against the WCAG 2.0 AA rulesets.

Evaluating the issues with a page relating to WCAG AA compliance is made easy with the aXe engine: https://axe-core.org/, and even displays in the results how to better improve or fix rulesets such as contrast and sizing. So, I was on familiar ground. A ground which many never bother to consider since they avoid the cracks and spots of mud as they walk along. I decided to use the engine’s results as a guide towards patching the cracks, cleaning up the mud. One has to wonder, what is the consequence of such patches?

I first looked into the Material Design stepper specification and accessibly pages, where items such as contrast and sizing were addressed in a stark-yet-not-half-assed manner. The rules made sense, but they still did not comply with WCAG AA requirements and better yet, disregarded many of the colour rules to forward a flat aesthetic. The website the documentation is running on fails multiple guidelines, meaning that this correction would come from ideas, discussion, and if accepted, deviation from the very guideline which established the design of the project. Damn.

Before

After

I left a comment which described the most transparent way of fixing the A11y issues with the stepper, opting to darken the text to meet the bare minimum of the compliance guidelines. It was as I was typing the comment and proposed changes, that I realized just how little people would care for such a change, or how quickly I’d be thrown off the boat for attempting to go against the design specification.

The change that I proposed is very small, bringing up the alpha layer of the RGBA font / background colours from 35% to 54%, which brings us to the compliant 4.5:1 contrast ratio. I figured this was better than changing the colours themselves which, good luck doing so since we are playing with #FFF and #000 through and through. Kids, this isn’t your Dad’s CSS.

In the past few weeks, I’ve been horrendous when it came to OSD700’s work, often appearing dark f or a week in span, my work for the course at a standstill in that time. Three days after posting the comment which I hoped would stir discussion, still not a single response. Perhaps I need to give them a week as well, moving onto a different issue as my secondary while waiting for the pitchforks or textbooks to fly in with fury once maintainers and developers alike stumble on it.

Regardless, one can only throw his paper plane into the sky and wait for the wind to determine it’s direction.

It’s hard to believe how quickly this semester has come to a close. Some of us including me even had countdown calendars, and yet the days escaped even quicker than we could count. It feels like just last week I started my second dedicated foray into Open Source technologies, and yet in the next two weeks it’ll be the end of such adventure (for now, that is). Similar to what I did when I completed OSD600, I thought I’d recap and share my thoughts as I complete OSD700, and perhaps also allude to the progression and experiences between the two which is only possible through fantastic instructors such as David.

From 600 to 700

The Rise of JavaScript

In David’s OSD600, I learned quite a bit about modern-day JavaScript practices and how they applied to current Open Source trends. Looking back now, I gather a few reasons why JavaScript completely swept over and took the FOSS realm by storm:

  • Thanks to Electron and HTML, making cross platform desktop applications is now as simple as writing a web application. I believe this is imperative in the popularity of JavaScript applications since working with GTK, qt, WPF, and Cocoa (just to name a few) can be disjointed and utterly mind jarring at times. If you know HTML and CSS, your application can share unified styling and components on all major platforms.
  • JavaScript has grown in the past decade to be one of the most flexible languages I’ve ever seen. Learning advanced JavaScript development means learning new patterns, new paradigms, new programming concepts such as callback / closure centric logic wrappers, and with the addition of Node for the backend, a semi-robust alternative to the languages of yesterday.
  • I’ve observed a radical shift both from SOTI and from developers I’ve talked to regarding their change of perspective between dynamically typed, interpreted languages such as Python, JavaScript and compiled languages such as C#, C++, and Java. Many whom admitted disdain for JavaScript were now advocating its usefulness for prototyping and rapid application development without the need to compile or grand environments being provisioned. Of course, you have individuals in both camps, some who claim that NODE and JavaScript are still too immature to be taken so seriously in enterprise, of which I do see some their points being incredibly realistic. Tried True > Bleeding Edge.

From Student to Intern

Likewise, it was through learning JavaScript in OSD600 that I had the confidence to learn Angular and it’s primary language, TypeScript. From there, the entire MEAN (MongoDB, Express, Angular, Node) JavaScript centric stack and all of it’s toil and glory. Flash forward three months later, and this new experience actually landed me into my first enterprise Internship with SOTI Inc, where I was a front end Angular developer. Using David’s knowledge and lessons, I learned quickly how to excel and push forward the tasks much bigger, much more complex than my potential, and became the lead front-end developer (still an intern!) of the SOTI Insight team.

I don’t think a single day goes by where OSD600 hasn’t had an impact on my current work in the best way. Looking back now, without that class I can say that I would not be in the position I came to, nor would I have the experience and drive which came from that class.

The Transitioning to 700, Thoughts Post-600

The same can be said for many who took David’s OSD600, and for those who in OSD700 are also finding their callings. With 700, instead of being shown around the nest and how various communities work we were thrown directly into the sky, told to choose a place to land and from there build our own nests alongside the given communities we chose. Here, some chose Visual Studio Code, Brave, Chart.JS, Angular.Material, ngx-bootstrap, Python even!

The experiences differ per person, but I don’t *think* any of us walked out with less than when we walked in. Instead, we walk into the last few classes with contributions and pull requests to our name, a steady stream of work relating to us showing up on most search engines at the very top (talk about good publicity for a developer!), and a confidence and skill set which isn’t easily obtained that will push our careers further than ever before.

Lessons and Thoughts Which Stood Out This Semester

Debugging through Different Directions

I’ve written about some of the debugging methods I’ve painstakingly learned over the past four years, a post which was directly inspired by David’s lessons and articles on the topic. Being the ever-learning, humbly experienced developer that he is, David shared with us his strategies for debugging applications built on top of the Electron framework; a lesson which the very next day even affected the nature of my tasks at SOTI in the best possible way.

Whereas I discussed in my post a lot of the common debugging issues and or missed areas which younger students that I tutored or myself often struggle with, David went straight into explaining how to bend Chrome and modern technologies to our will. He explained Dogfooding, Dependency Injection concepts, and navigating your way around a huge code base looking for a single event listener using modern day tools. Never before had I looked at the Chrome DevTools specifically with such admiration of what was possible through a web browser. It’s amazing how much effort and work is put into such tools and applications that the everyday person will never think about nor discover.

I took some of the tricks that David had displayed and applied it next day while debugging an item at SOTI. To my disbelief, no one else on the development team (which at that time was comprised of 4 senior JavaScript developers, 6 software developers) had heard of the debugging-on-DOM-Node-event trick, or even conditional breakpoints accessible through Chrome’s DevTools. Yet, it was exactly these two tricks (plus a few others) which finally allowed me to discover the flaw in the code; the line which broke the business logic.

Becoming a Small Community in The Class

Throughout most of our courses, we’re always anticipating to make friends in the classes we frequent and build relationships or networking potential with our peers. This means that when we see each other in the halls while rushing towards the next test, we’ll nod, see how it’s going, strike a conversation, or perhaps press forward since the Prof isn’t going to wait for you. I found this scenario through my few years at Seneca to be very predictable, to be the standard of meeting individuals who are in the same field as you.

In OSD600, and even more so in 700, I found David guided us towards something much bigger and more concrete. As per his intention, the class of OSD700 became a community where thoughts, stories, events and coding struggles were shared and enjoyed. Interesting developments or thoughts were shared on the Slack channel weekly, often by Sean who somehow managed to always have a new link or article to share! We attended a Rangle.IO event as a portion of the class, and even got to tour the Mozilla Toronto Office (MoTO) with Michael Hoye. The twitter tag #SenecaSocksCrew was created initially as a chance to get awesome looking VueJS socks, but later kept alive to become a symbol. An anchor for all of us to come back and relate to, to keep in touch and also to plan out new events together after the semester ends.

David got what he wanted, which was to join a class of extraordinary people into our own open source community. The community at the moment consists of the following incredible developers, who I’d recommend looking into for both their work, their blogs, and their continued plans to change the world:

Presenting your Best and Worst Work


This is an interesting one, because as the title suggests some days aren’t meant for presenting the goldmine of work you produced. Instead, we were encouraged to present any and all of it. What this meant was explaining our thinking, our trials and where we want to go next with the task at hand.

This was one topic which took me away from the comforts of a polished end result. Never before have I had to talk about failures, and work in progress to such degree, admitting that at the time of your presentation that there is still work to do, things to fix, and a long road ahead. It took a lot of time for me to adjust, to admit alongside my pampered and finished tasks that some were the polar opposite, coal in a cave full of unknown code waiting to break or be found. It was incredibly stress-inducing to me to go up in front of my peers, and explain why an item isn’t working, similar to a progress report. I’ve always been a perfectionist, so the introduction of this style of presenting was one which pulled me very left field, but also gave me the slowly-worked-to chance to learn from the presentation style and own up to the tasks in their unfinished entirety.

Contributing To the Everyday Persons Workflow

This title seems odd, even for me who wrote it. What I really mean by this, is that our contributions should be aimed at making the biggest splash it can for others. This doesn’t mean sending thousands of lines of code changes in a single Pull Request, instead it means making the project one bug less, one language translated more, one requested feature added, etc. David really tried to emphasize this as many of us looked at lines of code as the metric between an ‘A’ and ‘B’ graded release, instead of how this ‘very small’ change would improve the workflow of developers all over the world using said project, or how this bug fix will help clients and developers alike to push the project forward by removing technical debt for example.

It took awhile for me to learn this, since previous courses and egos always considered the better programmer to be the one who writes quality code, in bountiful amounts. My first few fixes were mere line changes, which though they qualified as a ‘release’, to me they felt like the shortest fragment of a ‘patch’. Over time, this changed as David stressed how these fixes were improving the lives of both the users and developers, beit bug fixes, new features, or even accessibility improvements (my niche I suppose). I saw that contributing didn’t have to be verbose, but instead helpful.

Where Do I Want To Go From Here

This isn’t my last blog post, nor is it my last blog post relating to OSD700. But, I figured this would be a nice place to put my ambitions and thoughts towards how I want to steer 2018. Not in any order of priority or execution:

– Learn VueJS / React
– Learn Python 3, Rust, GoLang
– Write a Full Stack Web Application from the Ground Up
– Write a Mobile Application from the Ground Up (iOS? Android?)
– Become a Mozillian!
– Become a Node Certified Developer
– Become a Linux Certified Administrator (maybe?!)
– Continue contributing to FOSS communities
– Continue working on Musical Adventures, release some of it!
– Continue being a member of the SenecaSocksCrew community

Going forward, I’m hoping to learn more lessons and also expose myself to newer technologies which contrast or conflict with my own current experiences and vices, my logic being that it will round me out as a programmer better than falling into a specific niche. I imagine my new career title will play well with this concept, going from Front-end Developer to Cloud Platform Engineer. 2018 is only a quarter of the way through, and there is still much that is possible before we see the end.

Or, How to Break Every Travis Build Your Commit Creates!

An OSD700 Contribution Update Part 2

Preface

This week, having thought I had climbed and conquered the smallest imaginable version of Everest, I climbed into my favorite chair, put on headphones, and let hours pass by while finishing Haunted Empire. My phone went off during this time, but unless it was a call or message, I thought nothing of it. I finished the book, pleased with the epilogue and wondering if had it been updated with the current exploits and affairs of Apple, would the ending remarks differ.

Mountains of Coding Guideline

Upon returning to the world, I was greeted with the results of my climb of Everest; a new mountain of style corrections and lint errors to be corrected. I thought I caught the majority in my previous climb? Why did my IDE (Visual Studio Code at the time) not catch the issues? Was this the first opportunity which would impact the impressions the maintainers of Angular Material have on me? On my contributions? I had to first discover why these slipped past my editor.

ESLint vs TSLint

Before going into the issues which I had to correct, I wondered why the codebase didn’t display the wonderful red lines (depending on your theme) which similar to writing your thesis, implies a mistyped item. In my case, the red lines would have displayed most of the issues listed below, but I never knew we were playing hide and seek during this playful hour. See, the reason for this game I found after a few minutes of experimenting and digging, was that my installed ESLint plugin did not bother with TypeScript files, and likewise for some reason my local instance didn’t have the TSLint plugin installed at the time. That second point really drove the entire issue, since installing the plugin instantly brought back my favorite frenemies and revealed any issues relating to my TypeScript files.

The lines returned, pointing out the flaws in the components I had worked on relating to the preconfigured rules for Angular Material, and that is also how I learned about their code style more so than the previous contribution. Below I’ve outlined some of the items which are easier to gloss over, and my thoughts as well.

Spaces vs Tabs, and Spacing Count

Angular Material indentation requirements is 2 spaces per indentation. Despite every source file containing this indentation style, Visual Studio Code still used 4 spaces as the defacto standard while the project was open.

Perhaps I am supposed to configure this beforehand, but the fix itself was as simple as toggle the indent settings at the bottom, CTRL + P / CMD + P, and using the reindent lines command to correct. Without getting into the whole space vs tabs argument, always ensure that your editor / IDE is configured to comply with the coding style of the project, regardless of what that specific compliance is. I’d love to push for a indentation standard which can be applied in ESLint / TSLint which editors such as Atom or VSCode can then extend into their linters. Maybe a summer project idea?

Formatting, Trailing vs Leading

We all pick up habits from people, projects, and our idols in ways both which we are aware of, and unaware of. I didn’t realize how much I favored leading commas until David pointed it out while I was working on the Thimble Editor a year ago. This habit came from my previous COOP with Technicalities, where experience there dictated that leading commas were a good design choice to be following in every project. I must have picked up and endorsed this coding practice for the vast majority of 2016 to 2017.

Using Thoughtful Examples

So this one is more of an opinion compared to style guide, but I do believe in the point which was conveyed and the requested change. Essentially, while working on https://github.com/angular/material2/pull/10666, I used the same example content as the StackBlitz, meaning I had the following data to work with:

At first, I thought that this was appropriate since if you typed D, then Dog and Dragon would be displayed while the C option group disappeared, implying what was expected workflow wise. Expanding from there, if the user typed Dr, Dog would follow C and disappear since it no longer complied with the conditional statement. It was a to-the-point example which I thought carried the concept across in this StackBlitz fork I had done.

Kristiyan, one of the maintainers of Angular Material, requested that instead of using this dataset, I use the United States (or a bigger data set), so that the users and document readers could play with the example and see more results being filtered down, brought back, or removed from the criteria entirely. It made sense, why demo a filterable list with only four elements when you could with fifty elements instead? I forked my original StackBlitz and then updated the data list to the new topic. I learned few items from this task which I’ve listed below, and if you want to see the final StackBlitz, you can find it here.

  • The USA has 50 states (yay geography teachings!)
  • Compared to Letters D, F, G, H, L, P, R, and U which have a single state, M and N have a damn huge number of states. An unbalanced amount if I may say so. 16 damn states between the two, which is double the amount per letter of the other set.
  • I really don’t know my geography (Jack can attest to this, who enjoys pointing out this flaw when ever we somehow brought up travel).
  • This is a much better example, both in content and concept. Filtering through states seems like such a common use case for some compared to sorting through 4 separate animals. It’s tangible, relatable.

Integrating Prettier Into More Workflows

I heard of the Prettier formatter a few months ago while working on a school project, and never really thought of how valuable it would be until after this small bit of debacle. It made me think, how much time is wasted on formatting per commit and how we spend N amount of time trying to correct it. Why not let the machine format or warn of bad formatting prior to the git commit so that everything which goes through the wire is already in the best state. I wonder this not for just Angular Material, but ALL established projects which has hundreds of contributors or more. The current offerings by such a formatter is impressive, but I was equally impressed with the upcoming support for Python, Swift, and Java. Likewise, all of the major editors are already supported (Atom, Emacs, Sublime Text, Vim, Visual Studio, VS Code, IntelliJ Platform).

Next?

Currently, both of the issues I intended to tackle for this release have pull requests by yours truly, and both pull requests have some E2E issues which I’m addressing in between writing this article. You can follow both issues here:

I really wanted to snag a third small item into the list, but time was not on my side for the past two weeks with other items and priorities had to be addressed firstly. At this rate, my current plan of attack for the final release (damn time is moving quick) is to pick similar sized issues which can be done in a few hours, and see how many are possible with valid fixes, good code, and not breaking every possible end to end test I can imagine.