Month: February 2018

Home / Month: February 2018

When I first started contributing what I could to Visual Studio Code, I was under the impression that it was written using React. Even while working with the custom drop down component, I was still under the impression there were React Front-end technologies which enabled for the dynamic rendering of various components and functionalities. Only in recent, while debugging and looking for high-level understanding of different scopes, did I realize that Visual Studio Code developed without the front-end JavaScript frameworks such as Angular, Vue, React or even MeteorJS. Without sounding like I just discovered Pluto being once called a planet, this was very left field.

Programmatically Generated UIs is a term I’ve heard while doing research on iOS Development practices, but I never considered a full-blown web application (including all the HTML attributes and so on) being powered in such a way. I remember using basic JavaScript to change the DOM while learning how to do front-end validation for INT222 (now WEB222) at Seneca, but never to generate entire navigation bars or full-blown text-editors; the concept and understanding of said concept is both the scariest, and most interesting discovery I’ve attempted to learn and dig deeper into in the past few weeks. Looking back at the custom drop down source code, I realize that I was so caught up in the state persistence and accessibility concern of the bug I was working on, I never realized just how genius the component’s implemented; in-house, no external frameworks or libraries.

The Flipping of Comfort and Concerns

In every project to date; be-it Enterprise for SOTI, Open Source, or even just Seneca course projects, I’ve never considered a programmatically generated and managed user interface. While looking more into Visual Studio Code’s logic, I instead of becoming familiar with it, began to become more concerned quicker and quicker as I had to search for life cycle handlers which a standard layout or framework would handle. DOM manipulation is one thing, but recreating, redrawing, and DOM-managing the entire component while all being in-house along with storing application state is very much left field compared to my experiences. While looking over the code, I did find two valid and worthwhile reason for such design practice, which I’ll explain below.

The Liberation from Framework Idioms

In the past year working with Enterprise level Angular applications, I’ve come to understand the saying ‘going against the grain’ when it comes to working with frameworks and libraries; they are amazing when you implement within their design and allowance, and an absolute nightmare when the scope goes beyond or against the framework’s design. I see with Visual Studio Code, the happiest of mediums where more time dedicated on design and development, and less on fighting the code and assets which make up your product.

Examples

Adding all event listeners to the custom drop down element

Dynamic styling of the drop down based on context

Creation of the select list HTML element

Deeper Management of Application Logic and Views

Compared to having multiple components, edge-cases and sub-component requirements, you can manage all of which (cleanly) in a single well encapsulated scope. This is only possible because of the (granted, concerning) freedom which programmatically managed interfaces offer, since scopes of the element such as data, state, and interface itself derive from the same scope: in a single language and instance (compared to Angular’s HTML, TS, and SCSS separated file structure). One video that I had discovered last year which explains the benefits and reasoning why even iOS developers going this route compared to creating storyboard layouts:https://www.youtube.com/watch?v=up-YD3rZeJA

Final Thoughts

I’m looking forward to exploring new concepts such as this as I go about Visual Studio Code, and hoping that I never stop being thrown into challenging or adventurous situations where the only way out is to learn and understand it. I’m sure I’ve only uncovered only 5% of the entire concept, still unsure of every reason behind it, and even the proper implementation paradigms in Code; going forward with the bug fixes and improvements I hope will explain more and make me a better developer in the process.

How I Approach Bug Fixes in a new Code Base

February 22, 2018 | Open Source | No Comments

The one thing that Humphrey said which really resonates with me on the topic of bug fixing is summed up as this, “[on bugs] they’re easier to understand since the code foundations have already been laid out before you, all you have to do is understand it”. Even at work, I found myself for the past 4 weeks focused on bug fixes to our product prior to the Mobile World Congress (MWC) event, so I was both sick and very well experienced in trial-error approaches towards bug fixing. Here are three concepts / thoughts which I find often result in a step in the right direction when it comes to solving the infamous issue, resolving the ticket, or adding the feature which exists in a different scope.

Is the Bugfix a result of Data Corruption and or Race Conditions?

This issue I find a lot working with ‘data-driven’ applications, the type of applications where charts, tables, and UI elements themselves are powered by JSON responses from a backend. In this case, the expected response (contract) differs from what is actually returned. In my first COOP with TechnicalitiesPlus, part of the learning experience was debugging and discovering that the front-end code itself functioned as expected, and it was the persisted data which had changed. This break of contract / agreement is often easy to overlook, assuming that the data itself is always the expected ‘source of truth’. The issue which led to this experience? The JSON array was returning objects which lacked very specific attributes which existed in the database. This caused failure to render and a very frustrated 19 year old to lose hours thinking it was Front-end logic creating the issue. The amount of hours I spent learning that scope inside-out before verifying the data response itself is a lesson that I will not forget, and it is why my primary debugging check is to verify the data.

Is The Requested Feature Already Implemented Elsewhere?

I find a lot of the bugs that I commit to are feature extensions to an already working component, so this question often comes up quickly when I start going crazy with the keyboard and terminal. Often, the feature exists in a different scope such as a dropdown, component, or platform even. If so, you then have a good base to research and understand how said base was implemented, thus granting you a giant leap ahead. For my two accessibility bugs as of last week, neither were applicable for this approach. That being said, my good friend Svitlana’s (who can be found here) recent work with Visual Studio Code followed this exact pattern with her bugfix / improvement. Her approach was very similar to this, first discover where the functionality exists and understand how it works from there. We toyed with the idea of copying the entire function over to the new scope, or importing it directly; both ideas replaced with a much more suitable IAbstractAction class implementation which would call the imported function within the required scope. Essentially, it replaced the original idea of reverse engineering and dozens of lines of code with a single, fifteen line IAbstractAction class which did not repeat code or produce a new scope riddled with potential issues.

Will Calculated Trial and Error Produce a Visual Difference and or Indicator?

This is more of a workflow paradigm that I’ve adopted from the first days at Seneca, where if you don’t understand how to fix or implement a working concept, essentially do ‘smart’ brute force attempts. What do I mean by smart? Well, don’t make the mistakes that I did at first where every single compiler error results in a different implementation. First, focus on the scope which affects your area of the bug. Try to understand its circles of scope and interaction, and from there reach out to all that the scope touches where applicable.
Once I understand the basics of the scope such as adding a button to a list of common functions, here is the ‘smart’ brute force direction I sometimes approach issues from:

  • Add a static button to the list forcefully, omit programmatic idioms for now, do you see the visual change?
  • Make the button produce an alert / visual indicator of user interaction and handling, is the event handler working?
  • Now attempt to add the button programmatically if appropriate, does it appear? Make it.
  • Make said button’s scope directly relational to the scope you’re working with, does it interact with the components data, DOM, or other functions?

If the first failed, I’d probably try as many alternatives to adding the button to the DOM as I could. Only then, would I attempt the second point. Likewise with the third and fourth. This method of attack maybe is not the most efficient, but it produces a thorough understanding of the scope and attempts made to work in said scope. I find myself following this approach less and less as experience in the project grows, but I cannot deny just how much time I wasted using said approach, and the results which were produced only being possible in such a way. Break the DOM or logic 20+ times in 30 different ways? Check!

In the End, the Direction is What Matters

I keep saying ‘step in the right direction’, because I truly believe that if you’re new to a code base, it’s easy to get lost in all the functions, methods, variables; the lights and darks. I love the reinforcing concept of taking a ‘good’ step, meaning taking the risk and or time which results in me being closing to where I need to be to achieve this bug fix or feature implementation. Nothing is more depressing than taking a step and falling that much deeper into confusion or misdirection. It’s just like finding treasure, once you find enough clues or the map itself, and take the path which leads you to the correct direction, you’ll find the chest full of gold!

Debugging Freedom
Freedom

An OSD Contribution Update

For the last three years, I’ve grown a passion for extending technologies towards a direction which makes them more accessible for a wider range of users. It took a while to realize what accessibility truly meant in the world of development, software, websites and health organizations. Through the process, I took a course on behalf of my employer at the time to learn the three levels which make up the Web Content Accessibility Guidelines (WCAG) 2.0, A, AA, and AAA. This course took me through so many spirals of knowledge and issue, all-encompassing different scenarios and acceptance criteria for web development. After taking the course, I started to see software design and accessibility very differently. Contrast between colors, element organization, font-sizing even became subject of my mental focus at first.

When looking for issues and improvement requests in Visual Studio Code, I decided for this round that I wanted to explore and help improve how we handle accessibility within the platform. This led me towards two bugs which relate directly to the newly released custom drop-down component which was apart of the February 1.20 release. I thought this would be a great outlet for contribution since it’s a brand new component to the project, enabling me to also seat myself if possible in that domain and help update and upgrade the component over time.

Monokai Drop-down Selection Theme

This bug was originally an issue directed towards how the Monokai theme handled drop-down selection indicates the currently selected item. After discussing in the issue how to handle the fix, a proposed quick solution was implemented and tested. Changing the list.focusBackground to a different color of the Monokai theme, thus ‘fixing’ the issue.

The reason why I said ‘fixing’, is because this very small, single line fix also produced evidence towards a bigger issue with the drop-down component which would span all custom themes. Essentially, there was no way to promise this improved accessibility for custom themes which set list.focusBackground to a non-common theme color, since the attributes used in many components alongside the drop-down.

Christopher Leidigh known as @cleidighon on GitHub, developer for Visual Studio Code, and also contributor to the new drop-down component provided a non-intrusive update which provided a new attribute titled dropdown.listBackground which is used by the component if it exists. With this update, switching list.focusBackground back to the previous color and using dropdown.listBackground provides the bugfix without breaking the established patterns of decade old themes, and custom editor themes. I have a feeling that this will be expanded later to accommodate APIs and contrast-awareness functions. The final PR can be found here

Escape Key Should Revert Selection to Previous State

Again approaching accessibility improvements and learning more of the drop-down component, I was introduced to this bug. Essentially, it is a request to return the common behavioral pattern of when a user hits escape during text input modification, return to the original state. A simple concept, and I had an idea which is in my work in progress PR which is found here.

Essentially, store the currently selected index when opening the drop-down component, and in onExit and onBlur restore the selected item back to the original state. Simple enough I think. There isn’t any magical React / Redux paradigms occurring here, so I feel pretty confident in my initial approach and, based on Christopher’s initial review of my attempt, we share the same mindset for this update.

Conclusion

Was this a huge contribution / release? No. That I can admit, and if I do have time I’ll try to find a bug to make up for the lack of substance. This round of open source interactions allowed me to discover a few interesting lessons, some of which I consider as valuable:

  • A single one line bug fix can produce a tentacle of other bugs and or politics.
  • Accessibility is a characteristic which can be easily overlooked, and is overlooked often times by the common developer.
  • Working remotely with developers in different time zones can create one of the most interesting plots of disconnect and resource-management that I’ve ever seen. You see their replies in the morning when perhaps they are calling it a night. This grants you HOURS before they’d see your reply, providing space and resources to plan out both your intent and knowledge base towards the issue and the reply. Likewise, it’s very easy to fall into the trap of waiting around for a reply as I did during segments of this release, which is ill-advised if one is seeking continuous progress and movement.

Going forward I really hope to discover more improvements or bugs relating to the drop-down component or various other UI elements, ones revolving around accessibility being preference. Code is so much bigger than I would have ever imagined, and seeing the following response from a well-respected Developer such as Christopher admitting that even he is only scratching the surface lifts my spirits when I find myself lost in endless lines of code and confusion. With each new experience, I look forward more and more towards the next step into Open Source.

I love Bulma, I love contributing to projects instead of spinning up my shoddy implementation of a need, and I love when the two come together in such harmony it’s as if fate meant it. I discovered BulmaPress while looking for Bulma / Non-Bootstrap WordPress themes for a CMS project I’m working on. It looked to be relatively abandoned, sporting an old version of Bulma 0.2.1 and last being updated half a year ago.

Still, this didn’t deter developers including yours truly from forking and fixing or updating; a relatively painless experience since the project was built on-top of the underscores project, providing a solid foundation which only needed the Bulma part to be updated instead of the WordPress theme functions. It took several iterations to get the modern Bulma navigation pattern to work as expected, but once that was in place (you can see the code change required here), the rest fell much quicker.

Instead of keeping the fix to myself, I decided that any updates should make it upstream to benefit other users who discover the project. These fixes included removing the outdated Bulma code (replaced with a CDN), fixing the SASS compiler, and now writing a stable override structure which provides easy modification of Bulma variables.

The SASS was priority in my mind after correcting the navigation since no one sticks with the defaults, almost ever. Writing in CSS is a pain when it’s a full website theme, and once you learn SASS, SCSS, or LESS, CSS functions like assembly in comparison. Literally! For my project, I also needed the SASS configurable since this project would involve multiple different overrides and branding elements too.

As my first contribution got merged in, I became a contributor to the project and was also promoted to maintainer (meaning I could merge, triage etc). It’s a cool experience to see yourself at the top of a contributor board on an abandoned project: https://github.com/teamscops/bulmapress/graphs/contributors. The numbers do seem off, but I’ll let the GitHub magicians assume what they will about code changes. Later on, I’d begin to have questions tweeted or emailed to me on BulmaPress, which was another cool moment because I realized this abandoned project still had love from developers who perhaps like me, needed exactly it.

This is my first time working inside-out on a WordPress theme, my only previous experience being changing the default layout of the theme to support Bootstrap headers for a client two years ago. Working with only foundation, knowing that everything else can change if needed was an opportunity that I didn’t expect from BulmaPress. I had different ‘implement this feature so you can use it’ styled expectations, not so much ‘update this because a lot has changed in recent years’. There is still a lot to update and fix, such as the navwalker used for multi-tiered navigation menus (Which I don’t believe ever worked to begin with according to comments in the code), and fixing the demo domain issue where you which expired in January.