Release 0.4 – OSD600

For my final release, I didn’t work on as much bugs as I wanted to. I should have claimed more bugs ahead of time, and unfortunately, the bugs that I wanted to work on were already taken. As a result, this release is very small.

The first bug I should mention is something I’m still working on and hope to get it done before the final deadline (April 21st).

Issue #700: https://github.com/mozilla/brackets/issues/700

Pull Request: https://github.com/mozilla/brackets/pull/708

This bug isn’t really a bug. It’s approximately two warnings:

Deprecated: Do not use $().on/off() on Brackets modules and model objects. Call on()/off() directly on the object without a $() wrapper.

main.js:12 Registering for deprecated event 'currentDocumentChange'. Instead, use MainViewManager.currentFileChange.

As you can see, this issues encircles two deprecated events, and it clutters the Developer Console. My initial solution was to remove the first deprecation message in brackets/src/brackets.js:

DeprecationWarning.deprecationWarning(“Deprecated: Do not use $().on/off() on Brackets modules and model objects. Call on()/off() directly on the object without a $() wrapper.“, true, 4);

My next solution was to modify brackets/src/extensions/default/brackets-paste-and-indent/main.js. “currentDocumentChange” was giving the problem. Following brackets/src/document/DocumentManager.js documenation, it suggested I used EditorManager.on(“activeEditorChange” … instead.

These changes got rid of the warnings when I tested it. Unfortunately, when pushing these changes to GitHub, Travis CI didn’t like it.

Later on, I was suggested a different method to solving this issue by @gideonthomas.

Following his steps, I seem to be having an issue with brackets-paste-and-indent submodule. And this is what I’m currently working on.

The second issue I fixed was that of my own.

Pull Request: https://github.com/mozilla/brackets/pull/697

I was previously notified by another student who had worked on the Allow JavaScript toggle that the README in brackets was missing some of the documentation for it. I personally knew how the JavaScript toggle worked as I had worked on something similar. So I simply added a few missing lines as well as correcting a few typos here and there.

The third issue I fixed was https://github.com/mozilla/thimble.mozilla.org/issues/1962.

When opening the drop-down for the Language menu, it would be cut off if your screen wasn’t tall enough.

My original solution was to give it a max-height property where it’d not pass the green portion of the page and to add a overflow auto property to the public/resources/stylesheets/userbar.less file. The overflow auto property would automatically at a scrollbar if the content within it was clipped in correspondence with the max-height property.

Due to a terrible oversight on my part, I was told by @flukeout that a fixed height wouldn’t be practical as every screen has a different size… He suggested I use the “vh” measurement unit which would give me the height relative to the viewport. He told me to use that in conjunction with the calc() function to let me subtract 85 pixels from 100vh (100% of the viewport). This would make it dynamic and solve the problem.

Lab 9 – Heroku PaaS – OSD600

In this lab, I was able to extend my repo by creating a simple server, and deploying it to the cloud hosting platform, Heroku. Following the instructions, I created a server file with code that defined HTTP routes, where these routes, when accessed in the browser would call on functions I made in the seneca.js file and format the returned values to JSON. I was then able to test the server locally. Thankfully, everything worked.

Moving on, I created a Heroku account and ran the setup on my computer. Creating a file called “Procfile” in my local repository, I had to give Heroku an instruction that would start a web process and run a command that would start the server I created. To generate the URLs I’d be able to access my server on the cloud, I ran the “heroku create” command. Unfortunately, it did not automatically create a remote for me as I had to use the command prompt on Windows.

Finally, I pushed my local repo to the git repo Heroku had created for me. I then simply started an instance of a web server with my code. I could visit the URL and it would work the same as it did locally. One final addition I needed to make was to add a new route — a route called healthcheck — that simply returned the uptime of the server in JSON. The last step of the instructions would have me push to my original repo on GitHub.

Besides having to redo labs 7 and 8 because I switched computers, it wasn’t all that difficult. I had to update my PATH variable so Windows command prompt would know about git, and so when I ran “heroku create”, it wouldn’t give me an error along the lines of “spawn git ENOENT”.

Release 0.3 – Auto-close tags – OSD600

Looking back to my first pull request for this two-year-old issue (https://github.com/mozilla/thimble.mozilla.org/issues/1262), I started working on this on approximately the 19th of February. Granted, of course, I didn’t work on this everyday. In fact, I took long hiatuses in between. Often, I’d come back immediately after someone (flukeout, gideonthomas, humphd) requested change(s) after asking someone to review it. So it was only as long as I had made it. However, there was a learning curve/barrier I needed to get past and “somewhat” understand at the beginning if I was going to get anything done.

Issue:

This issue all started with a tweet made by a user. He suggested there be an option to disable or enable the ability to auto-close HTML tags. This is something I actually wanted to, and for any editor. I personally hate it when editors auto-complete any of my code for me. Perhaps I’m not used to it, but it’s frustrating. So this issue, when solved, would be something I took advantage of. What’s amusing is no one got around to solving/doing this issue, and it was two years old.

Pull Requests:

• Brackets: https://github.com/mozilla/brackets/pull/601
• Thimble: https://github.com/mozilla/thimble.mozilla.org/pull/1787

Solution:

(UI & UI Event Handling) (Thimble)

Knowing that the Brackets side would be the most difficult and time-consuming, I started with Thimble. Creating the UI was the first thing I did, and it was as simple as copy-and-paste. Toggles already existed. All I did was change the name of a couple attributes (id, class, etc.). One thing unique about this small task was that I had to work with localization. I modified a couple of files in the en-US folder and followed the localization documentation provided so I could see what the final product would look like.

Accepting the UI, I moved on to coding the event. Again, code already existed. It was almost as simple as copy-and-paste. To give you a run down of these blocks of code, the idea was that the editor is supposed to remember whether the Auto-close tags toggle is either enabled or disabled (having refreshed Thimble or even first landing on the page), and depending on the value, the toggle UI would have to reflect that (on/off). This was the first block. The second block was the toggle click event in itself. If the toggle was triggered call the bramble.configureAutoCloseTags(…) function and pass in an Object that contains the appropriate preference values to reflect the state of the close tags preference.

(Events & State Handling) (Brackets)

Brackets was undoubtedly the most difficult part. It required the most coding and thinking. I needed help as I had no idea where to start. Starting out, I was told to take a look at a similar pull request made years ago (https://github.com/mozilla/brackets/pull/378). This pull request was for the word wrap toggle. Indeed, it was very similar. Or so I thought. Regardless, I thought the best thing I could do to begin was emulate what was done in that PR, changing the names of variables and code where appropriate. It didn’t turn out so well. In fact, I had to scrap the whole thing. Nothing worked. When I hit the toggle, close tags weren’t disabled.

It was a nightmare, but I also knew that it wouldn’t be as simple as copy-and-paste. Somehow, through help I got it working. This involved building on top of the above additions, but also removing and renaming some things. However, this wasn’t the end of it. While the toggle worked as expected, when you refreshed the page, it would not remember what the last setting was for close tags.

Unfortunately, the issue was much deeper than I thought and required gideonthomas to create a whole other branch that I merged into mine. We realized that close tags was a preference that already existed and that it accepted Objects, not booleans. It wasn’t as simple as passing in true or false.

But in yet another surprise, another issue arose. The issue was that upon first landing on the editor, the auto close toggle was supposed to be enabled by default. It wasn’t. In bramble/lib/UI.js, BrambleStartupState.ui(“autoCloseTags”) would return a null object instead of the actual object. If you refreshed the page, it would return the actual object. My solution to this was a one-time assignment of the appropriate object (an Object with the default values — “true” for everything).

To top this pull requests off, I made the respective additions to the README and then it was good to go.

What confused me and still continues to confuse me is just about everything on the Brackets side of this issue — working with states and manipulating them. If code hadn’t already existed, I wouldn’t have even thought to attempt this. This is just the challenge of working with code that isn’t yours. I’m sure if I had written my version of this from scratch, people would be in my position. Either way, I’m glad this feature has landed as it is very useful and needed.

Lab 8 – Automated Unit Testing – OSD600

Things I did in this lab was install the Jest module in my repository, created a JS file that would contain all of my unit tests, and modified my package.json to automatically run these tests like in the previous lab we did with linting.

I learned an effective way of trying to break my code, test it, and fix it. It required me to add more validation on top of my code to meet the expected results of these tests.

I recall doing a small amount of unit testing back in my Java course years ago but it was treated more like an afterthought, and to be honest, I treated it that way as well. In code I’ve written in the past, I hadn’t really written unit tests, but rather, through using the software or application itself, tried to break it as if I was the user. And I thought that was quite effective. But I understand that in real-world applications, both of these methods need to be done. And with unit testing, at least you have the tests recorded and readable

Unfortunately, I did encounter a problem which I wasted around 20 minutes on — and it had nothing to do with this lab. Linting was complaining about this: error Expected linebreaks to be ‘LF’ but found ‘CRLF’ linebreak-style

This was when I ran the ‘npm run test’ on Git Bash. I realized that this wasn’t the case in the Travis CI build.

Lab 7 – Open Source Tooling – OSD600

In this lab I learned how to set up tooling for a repository. I learned how to set up a new Node.js module and customise it. I did a little JavaScript coding for my module which validates a Seneca email, or create one very primitively. I also learned how to set up linting for my project as well as made sure it automatically ran when executing npm. Finally, I set up Travis CI on the repository so that every time I pushed a commit, it would run these tests. I added the badge to my README file.

I ran into a number of problems while doing this lab. First of all, being on Windows, I couldn’t use Git Bash for the first parts. Configuring eslint was also a mess. For some reason, on Git Bash, I could not use the arrow keys to select the options I wanted. Instead, it was trial and error, using the number keys (alternative I found through research) to guess which option I had chosen. Another long, arduous process was attempting to satisfy the linting check. It’s incredibly critical and took me many commits to get it right. It ensures consistency at the cost of convenience. One thing that really irritated me though was that I couldn’t use the common way of concatenating strings (+). Instead I had to use a built-in function. It also complained about how I couldn’t use ‘var’, but instead a ‘let’. A final complaint I have is how long it takes a new Travis CI build to start after pushing a new change. However, I shouldn’t complain because it is free, after all.

The long and gruelling process of working with code you don’t know – OSD600

This release I’ve been working on https://github.com/mozilla/brackets/pull/601 for a long while now is a good example. It’s especially something else when you have to write documentation for it. There are some concepts that I still don’t understand but have been closely copying/following along already existing code. I know of a student that has undergone something similar with almost the same code. And I think it’s generally a bad idea to not be consistent with the rest of the code in the project because you’ll inevitably be asked to change it — and this isn’t necessarily a bad thing.

However, one thing that has surprised me about this course is the amount of help you can get. Generally, with assignments and such, you’re on your own. If you hit a barrier, you have no one but yourself, and if you don’t figure it out in time, you’re done. But with a programming assignment, there are thousands of ways to solve a problem. With this course, the developers in charge of the open source project you’re working on expect code that assimilates and is consistent with their code. It’s different, but at least they help and actually care. After all, it is their product.

Release 0.2 – OSD600

The bugs I chose for Release 0.2 wasn’t the difficulty I had in mind. I had originally looked at and was attempting to solve two bugs that were relatively difficult, but ended up withdrawing from one of them because it dealt in more complex design that I struggled a long time to do. The other bug is still in progress and was not included in this release.

Instead I chose the following issues:

• #1333
• #1755

With #1333, the problem was that the Publish Dialog Box, when opened, stayed opened when you clicked your Published Project’s Link. It should close when you click the link, otherwise it gets in the way. Most developers tend to have their page kept in a separate tab anyway and so constantly opening the Publish Dialog Box is redundant, and leaving it open takes up a good chunk of the screen.

The solution, was simple. I added an id tag to the <a> tag of the link so I could manipulate in JavaScript. Then, in the JS file responsible for the handling of the Publish Dialog Box, I added a click() event for the <a> tag, using the id, to call an already existing function that closes the dialog box. This is the result:

With #1755, the goal was to show project descriptions under the projects in the Your Projects page if a description had been assigned to a project. This required me to add a <div> in the <a> tag of the Project table cell. These cells are dynamically created, of course. This <div> would contain the project description. I took a wild guess that the description member was called “description” and I was correct. The file that contained the definition of a Project was confusing and ultimately I made this guess, and it worked. I also needed to add a class attribute to the cell that contained the Delete button/graphic because in projects that did not have a description, the alignment of the Delete cell would be disproportionate, therefore very ugly. Heading over to the CSS file responsible for the styling of the Your Projects page, I made sure to align the Delete cell vertically in the middle. Guessing what the correct styling to align the Delete cell in the middle of every project cell was regardless if it had a description or not took a bit of researching and luck. Styling the project description’s <div> also took some research. I learned that the ellipsis we wanted when or if the description line was too long would not work without specific CSS attributes. I had help on the PR on what unit of measurement I should use on the max-width attribute which manipulated the max width of the text. We decided on “vw” as the unit of measurement, something new I learned. This is unit is based on the relativity of the viewport. I also implemented suggestions on the overall styling of the project description. The result was this:

What I need to do differently in my next releases is work on issues that are bigger and more difficult. I know asking for help is integral to open source, but I also hope to rely less on others because it’s disappointing not to be able to solve my issues on my own. Perhaps I should be more wise in the issues I choose as well.

One funny thing I learned or rather did inadvertently was code in a language I didn’t even know. I just went by code already written in the project already (granted it was one line of code). And I still don’t know what language that was.

What still confuses me, outside of these issues and in general, is pretty much any code I didn’t write, especially when it is complex. In some cases, there isn’t documentation.

Lab 6 – VS Code Editor – OSD600

The editors I chose in my experiment were Atom and Visual Studio Code. I knew from the beginning what editor I would choose before even testing any because of a personal bias. Unsurprisingly, I ended up going through with it. The editor I chose was Visual Studio Code.

One of the reasons I knew I would favour Visual Studio Code over other editors is simply because I’ve been using Visual Studio for 8 years. I feel comfortable with it, and there are parallels with Studio, though I knew there would be beforehand. This is irrelevant, but Atom was a 114MB download, and that didn’t help me in my opinion of it compared to VS Code’s 32MB. I also noticed that Atom has a longer start-up time. And VS Code’s start-up time is much shorter, even with a default folder structure (Brackets) set up to load. I’d also assume (I didn’t research) that Microsoft would have a bigger community and have more updates for Visual Studio Code than Atom. So Atom really didn’t stand a chance for me personally.

Here is what a folder structure looks like open:

To open a file or folder, it isn’t any different from most editors out there:

When working with open source projects, every project and every developer has his or her own style of spacing/tabbing. They’re very picky when it comes to this, and in past primitive editors I’ve used, I’ve had to manually mimic spacing, wasting my time having to make extra commits and such on Git. I can avoid that by customising how many spaces a tab will account for in VS Code:

Strangely, you customize the editor preferences in a JSON file. At least you can find everything there is regarding editor preferences in one file. The same goes for keybindings/shortcuts which are in a whole different file:

It gives you a lot of flexibility in the variations. Speaking of variety, through extensions, you can customize VS Code to enlist a slew of helpful add-ons, and it’s easy to access. On the left, there is a pane that contains several buttons. The very last one opens up the extensions pane where you can type into the search bar a keyword to find the extension you want:

CTRL-F as usual lets you search for keywords in your editor. But you can also do a global search of all files and folders open in VS Code by clicking the Search icon you see here:

I wanted to be extra condescending by highlighting the Search icon as if you couldn’t find it yourself.

There are countless extensions available for Visual Studio Code. I thought of ones I might use myself and was surprised to realize that they do in fact exist. What’s great is that the editor provides a 5 star rating and # of installs a certain extension has. If of course also gives you the publishing details such as the author, contributors, etc. It’s useful if you want to see what else a certain author or group developed. But most importantly, it’s a great way to make sure you don’t waste your time installing something that doesn’t work or is quite frankly, bad.

Visual Studio Code offers default themes that come with the editor, however there are many that you can download as an extension. This is just one of them, and it stood out as being creative. What this changes is the colour of the editor as a whole, including the code.

This is another one that is handy. Rarely do I make mistakes in the spelling of words but there is no harm in downloading a spell checker, especially one that also works with camel case when you write variables.

This one really speaks for itself. Very useful for web development. There’s not much I can talk about here.

As you can see, the npm extension is incredibly useful if you’re working with package.json files. It lets you know whether or not a dependency you’ve recorded is even installed, whether the version is correct, or even modules that are installed but defined.

This is not a mistake I make often but is handy if you have OCD when it comes to incredibly neat coding. There are a variety of whitespace related extensions, but this one had a 5 star rating, and so I couldn’t help but install it.

All in all, Visual Studio Code was something I had in mind from the beginning and I’m glad I actually like it and that it happened to be consistent with my most used IDE. It also happens to be diverse in its supported operating systems, so that’s a big jump from using Notepad++.

 

Lab 5 – OSD600

This blog is late, but for completion sake and since I have the time right now, I’ll publish this.

The issues I chose were:

• https://github.com/mozilla/thimble.mozilla.org/issues/1333
• https://github.com/mozilla/thimble.mozilla.org/issues/1755

The first issue was one I finished early, back in Release 0.1. I had time and the issue looked simple, which it was.

For issue #1333, the problem was simple. The publish URL link in the “Publish Dialog” box, when clicked, launched your published project’s webpage in a new tab. Great. However, when you return to the Thimble tab, the “Publish Dialog” box was still open. This issue fell under design — it was not necessarily a bug. I knew what I needed to do was find the corresponding <a> tag, and create a click event for that to close the dialog box, of which there obviously was a function for since I could mimic this behaviour.

Issue #1755 was also simple, and it had to do with design. We wanted to include the project descriptions (if they had one) under the project titles on the “My Projects” page. What I knew I’d be working with was the corresponding HTML file, and the CSS file. I would have to add a div or a span to store the description in, and in the CSS try my best to style it. I would need guidance on how the issue creator wanted it to look like.

Lab 4 – OSD600

This week I learned about how to create branches, how to create and checkout a branch at the same time, create a branch based on the current commit of a specific branch or a specific commit on a specific branch.

I’ve learned how to merge and how to solve conflicts that arise during the merging process.

I’ve learned how to go back to a previous commit, squash commits into one commit, and rename the past commit message. I’ve learned that I can use interactive rebase to do such things.