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.

beb33d18-1ad5-11e7-9dc8-8a2eb09c7e4a

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.

8659e41e-1b8c-11e7-950a-fe651f9184b5

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.

Advertisements

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:

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.

acts

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:

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:

c86ee1da-e8cc-11e6-8882-ca1026572680

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:

2b795340-f7ba-11e6-860d-d931e0c08f37

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.