Choosing a bug

At the time of this writing, Thimble has 185 opened issues (so choosing a bug to fix shouldn’t be that hard). After a few minutes browsing, I decided to go with this one (since it’s one of the oldest bug and its been opened for almost 2 years now). Before I could fix the bug, I had to setup my environment. Oh man, what a nightmare! I’m sort of like a robot when following instructions (I follow them line by line and never assume anything). I found it confusing and it didn’t mention that Bramble needed to be executed with Thimble (I mean, it sort of did, but since I already had Bramble installed, I didn’t read the Bramble installation part). I correct myself, I’m a broken robot haha.

So I decided to read the Thimble source to understand what needed to be installed. After a day or so, I decided to rewrite the instructions. I was a bit worried that they might refuse it (since I’m new to the project) but everyone in the project was really friendly and helpful! After about 3 revisions, I landed my first PR. Awesome! Time to fix my bug!

Gathering info

Actually… before working on a fix, I went back and forth with the Thimble developers until we all came to an agreement. Keep in mind, before asking a question, put yourself into their shoes. Not all developers are nice and not every developer have free time, so choose your question carefully. Don’t sit there and wait for instructions. Be friendly and show them that you’re interested in fixing their project.

It’s ok to be clueless. I was clueless, but I knew that I had to keep the ball rolling. I gave them 4 different possibilities of where the export button could go and even asked them for their opinion. Within hours, I got a few replies. After talking back and forth, we refined the location of the new export button and I was ready to start working on a fix!

Fixing the bug

Since it was an UI issue, fixing it was quite easy. All I had to do was to copy the old working code and paste it to a new section of the page (yep! good old c&p). But before I could do that, I had to find out where the "Export" button needed to go. Quickly looking at the project structure, I saw a MVC like pattern and went straight into the views folder. This is where I found the nav-options.html file and quickly knew I was in the right place 🙂

At first I was confused at what gettext() did. Assuming it was a function that returns a value based on a key (key-value pair) I searched the project for the key word “exportProjectLink”. I had over 20 hits! Jeez, do I really need to look at all 20 files? Actually no. Looking at the file names, I noticed that each file corresponded to a language representation of thimble (Ex: en-US is English US, pt-BR is Portuguese from Brazil, ru is Russian and so on). I didn’t care about these other languages so I went straight into locales/en-US/

I made the necessary changes and bam! It worked!

I wish I had more free time to fix these bugs. I’m taking 8 courses and I barely have time to breathe! I hope to fix a bunch of Thimble bugs over the reading week 🙂

Of course I’m not perfect. There has been small changes made to my code since the initial commit to the PR but once it lands, all these commits will be squashed! My mistakes will be erased and I can claim to be a pro-dev 🙂

Thimble and Brackets Running

Have you ever wanted to combine multiple git commits into 1? I know I have! I’m a bit embarrassed to push a piece of code to github and have 10 commit messages while I only edited 1 file. Since I work on 3 different work stations, I constantly push code to git and continue working on it from my other work station. You can imagine how ugly the commit history looks by the end of the day. Here’s an example:

To avoid this problem, I used to make a backup of my latest code, delete all commits and push my new code. If I only knew about squash earlier (no, not the fruit).

Why don’t we “squash” these commits into 1?

Looking at my logs (git log) I see that I made 16 commits (Jeez).

Lets squash these ugly commits! Run the following command:

git rebase -i HEAD~16

This will show all 16 previous commits on my current branch (master).

Lets pick the first commit (SHA: 59b6bfa) and squash the rest (change pick to squash).

Save and quit (Since I use vi, type :wq to save and close the current file).

Git will now give us a second change of being able to change the commit messages (incase you didn’t like them before).

In this case, I was happy with the previous commit messages and I didn’t want to change them.

Save and quit (Again, with vi is :wq) and you should see that the commits have been combined.

Bam! Now lets do a git push and see if those ugly commits was changed to 1 commit:

Yes! This is probably one of the best feature in github 🙂

The “inherits” module (written by the creator of npm, Isaac Z. Schlueter) is quite an old piece of code (First published in 2011). It has over 1 million downloads per day, and over 25 million downloads last month! One might think that a popular module like this one shouldn’t have any errors in them. Well… after looking at its package.json file, I noticed that it didn’t follow npm standards.

As you can see, there were a few missing fields (Even though they aren’t required by default). Although the repository field had a valid link, it was missing the “type” field. Now, why would he create a package.json file that doesn’t follow his own standards? Who knows really. Being an old module, I believe that this is the main cause for this oversight (The standards might have changed since 2011). If something is working the way you expect it to, then there’s no reason to believe you missed something.

After looking at other npm modules, I noticed that over 40% of them have package.json files that doesn’t follow npm standards. What if someone were to write a bot that can check for invalid package.json file and fix them? Now that would be something 🙂

Have you ever wanted to revert to an older iOS/tvOS firmware? With every major iOS/tvOS update, older gen devices always suffers the same issues. Battery drain. The device becomes slower. Some features are removed (Like swipe to unlock) and so on. The most annoying part is that if Apple stops allowing older firmwares to be installed (Aka: Apple stops signing older firmwares), you are stuck on that unwanted firmware “forever”. Unless of course you saved your shsh blogs 🙂

tsschecker is an amazing tool written in C that allows you to save your shsh blob while apple is still signing them. With these blobs, you might have the ability to downgrade your device using “prometheus tool” or any other downgrade tool.

tsschecker isn’t the first app on the market that allows you to save your shsh blobs, but it’s been around since Dec 2015. It currently has 6 opened issues and around 7 people who contribute to it (@tihmstar being the project owner).

Why not contribute? It’s an amazing tool that protects you from future headaches!