Release 0.2
Progression
The term “release 0.2” isn’t directly related to new software features. In the first half the semester we were taught the necessary skills and given the guidance to embark into the open source world. Release 0.2 reflects how we have grown as developers throughout the semester. Instead of new software updates, it’s new and improved skills as inspiring developers.
It was time to take the training wheels off and take on a larger and more complex piece of work. Obviously, this measure varies with every individual, but it was a chance to one-up our previous work.
In my previous post “Open-Source Reflection and Release 0.2 Goals”, I described my experience as a new comer to open source development and discussed future goals.
Capitalizing on my new-found appreciation for open source, I found myself regularly browsing GitHub’s explore page for new repos and developing my own npm package. I even found myself drafting up new features and ideas that I felt could be a great addition to Thimble.
I strongly believe that in order to grow in this industry you have to stay curious. Exploring new tech and ideas. This is something that’s not necessarily taught in school since students are usually assigned tasks as opposed to creating them.
So, I did just that. Before I was even aware of the second release I began to take on new issues.
Mozilla Thimble
- Change Publish popup title when project is Live #1918
- Home page content overflowing container on window resize #2518
- Github icon on Get Involved page is black in Firefox. Should be white. #2536
- Feature Request: Mobile preview with various screen size options #2557
Mozilla Brackets
Although these changes weren’t overly complicated, this was a great opportunity to improve knowledge, practice skills and build confidence.
Issue
For the purpose of this release, I will be focusing on a particular issue that is larger and/or more complex than anything else I’ve worked on.
Add pref toggle for enabling/disabling slowparse and UI suggestion #2580.
Mozilla Thimble is a great tool for teaching and learning web literacy in a simple, hands-on and visual fashion. An interactive web editor packed with beginner-friendly features it only made sense to include a hint feature to suggest changes to invalid HTML.
flukeout has been working on a new feature which implements slowparse to check for invalid HTML.
David Humprehy suggested that users should be able to disable the slowparse UI, considering it’s a big change.
Planning
When it comes to new projects, I can easily become overwhelmed which negatively impacts performance and motivation to complete tasks. That’s why for this release I put an emphasis and breaking down the desired goal into sub-tasks and clarifying them along the way.
With the guidance of Professor Humphrey, I was already of to a great start. I found something as simple as creating a to-do list was a big help.
Implementation
David had suggested before making and code changes to describe those changes in the appropriate readme files. (Tips for Creating an Effective README)
getAllowHints() - returns the current allow hints setting as a Boolean (i.e., enabled or disabled).
enableHints([callback]) - turns on hints/suggestions for the editor (default)
disableHints([callback]) - turns off hints/suggestions for the editor
Describe what a new feature does really help in the readability of the projects and aids and future references to the code.
Next, it was time to declare and define these new functions to the Bramble API. At this point, I was able to look at how existing pref toggles were described and replicate them with the appropriate naming.
I’d also like to mention that I’ve been trying to make it a habit of committing regularly as I make changes. Compared to my first release I would bundle up a ton of changes into one commit. I find this is a more efficient way of documenting your working and saving it in different states.
The next task was to “shim” the Bramble API to Thimble. Shim? No clue. I went to straight to Google for further information.
In computer programming, a shim is a small library that transparently intercepts API calls and changes the arguments passed, handles the operation itself, or redirects the operation elsewhere. Shims can be used to support an old API in a newer environment, or a new API in an older environment. Shims can also be used for running programs on different software platforms than they were developed for.
-Wikipedia
That surprisingly made sense after only 3 re-reads. Thimble uses a forked version of adobes/brackets named bramble for the editor which connects to Thimble. The shim acted as the intermediary between the two.
case "BRAMBLE_ENABLE_HINTS":
PreferencesManager.set("allowHints", true);
PostMessageTransport.reload();
break;
case "BRAMBLE_DISABLE_HINTS":
PreferencesManager.set("allowHints", false);
PostMessageTransport.reload();
break;
Wire up the UI
Now it was time to piece to implement the Hints toggle in the user preferences gear. I was able to use the dev tools inspect to capture the names of the existing toggle. 
Once I found the appropriate ID I would search for every mention of it in the project.
Present
As it stands the slowparse feature is still in development and hasn’t been added to the project yet. Once the feature is complete, I will be able to coordiante with flukeout in order to connect the toggle prefrence to the feature.
I’ll be sure to update this post with future progress of this feature.
