宇多田ヒカル – First Love
不知道是不是因為漫畫大多都是日漫，所以不知不覺中有種受到日式文化感召的影響，開始聽起了日本歌，也想多了解這個國家、文化、甚至是人民。因為有在聽 KKBOX，所以就想聽聽看最近熱門的日語排行榜，裡面第二名的就是當時（199X）年超紅的 First Love，旋律整個就是相當懷念！
不知道是不是出於無聊，就想來查查看這個專輯（歌）的過去。一看 Wikipedia 才知道這個專輯在當時的音樂界是多麼的出名。
2014年3月10日，由EMI唱片公司發行限量15000套的《First Love －15周年特別紀念版－》，除了歌曲重新經過音質處理，並收錄1999年於東京Zepp Tokyo舉辦的LUV LIVE演唱會DVD。
Recently, I have been assigned as a reviewer for a patch provided by our partner and this is okay to me because as a peer of Settings app, it’s part of my duty to review these patches. But … sadly, there are so many problems in that patch and I thought “Ok, it’s fine, because we all would make mistakes at first especially if you are not familiar with the part of codes”, so I tried my best to comment down all problematic codes with references (like to MDN or some related codes) to make sure they can get familiar with them more quickly and easily.
After several rounds of this process, we finally made it and I thought this patch was good enough to be landed, so I gave them r+ on this patch.
If the story ended here, then I don’t have to write any bits of words like this article. As you may know, this is not the end.
After signing-off this patch, there are still some other reviewing processes undergoing for different part of codes. For me, I have done my works, so I just left them alone and kept focusing on new features. Someday in the morning, I randomly checked the messages on Github and noticed there was one comment about the r+ patch, just out of curiosity, I decided to click it and checked it out.
That was a comment about missing change on the entry point and this definitely broke Settings app (You can’t even do anything). But … I was sure that this did work when I gave r+ because I did try the entry point to jump to that specific app when reviewing. So what’s going on right now !?
After a while, I finally realized that they just changed the code without any further notification and because the code change is kinda huge, no one would realize this problem when reviewing patch. So what does this mean ? If you really want to set someone up in this review process, you just have to get his/her r+ on your patch and use some magical git commands to break it and NO ONE WOULD NOTICE THIS AND WOULD BLAME ON THE REVIEWER !! (I wasn’t blamed yet, but if this patch got merged and I didn’t notice this, I would be the one)
We all know this is the critical flaw in our review process, but in order to trust anyone, we haven’t forced people to tell us if the patch got changed after r+. By doing so, this would make the review process more easy and we don’t have to get stuck in some kinds of principles. Sadly, this happened to me few days ago.
Not sure what to fix here because if you are familiar with git, you can do whatever you want on commits. It is a double-edged sword which provides you so many advantages and also some shortages. I just hope this was not made on purpose …
It’s been a while not writing any article on my blog recently. For me, there are too many things happened within these two months no matter on life, works … etc. There are some good parts and also bad parts but I don’t want to talk too much on the later ones.
So, let me talk more about what good parts happened here recently.
Same as usual, there are too many things waiting to do / review in Mozilla. After last Friday, we just passed the due of 2.1 (but this doesn’t mean we have no 2.1+ blockers any more xD) and it’s like a “gap” now that we can refactor our old spaghetti codes to make them clean and better.
For example :
In addition to codes, I had to review partner’s codes back & forth and this reallllllly takes time … There is a huge communication gap between each others about due and how to implement features. No matter how, I think this part can get improved in later days.
And there is one more good news – We (All Mozilla employees) are going to Portland from 1st Dec ~ 6th Dec this year ! Can’t wait to go there to meet some new friends and also pass by LA to find my best friend !
For side works, I have focused mainly on Node.js (express 3 framework) and iOS development. I want to make an online service focusing on solving problems for backpackers when traveling and my friends and I are actively collect data for these stuffs (like hostels, food, drinks … etc).
In order to achieve this, I have to learn how to write with Swift for iOS app. I did write an app before (with obj-c) but it’s totally different from Swift in syntax and some concepts behind. But as a front-end developer, Swift looks more nature and easy to me but the only bad part for Swift is that you can’t find too many answers to specific problems because It is too young xD. But whatever, I like it so bad !
And for Node.js part, as a full-stack (I thought I was front-end) developer, you have to focus both on backend / front-end (including database, IT … blah). I am not really good at db / IT stuffs but I think this is such a good time for me to learn.(I did try some setup before but not so much) So, to conquer these, I did swipe my card on Linode to rent a machine and register one domain name for that service. By doing so, you can think this behavior of a resolution and you can’t go back ! (Because this would cost you money monthly XD)
I like the feeling to be pushed to the edge of cliff and this would force me to learn something new
This is what I found in our Taipei office “Squash bugs for a better
When using version control tools like git, hg … etc , we all have one common concept in mind that we have to commit often to make sure all stuffs can be tracked and understandable when reading histories. By doing so, sometimes we may break a bug to many chunks and this would make us hard to track at the first glimpse. All you can do is trying to find the first commit about the bug and keeps reading commit by commit to know the whole story.
For personal / small project, I think this is ok. But for a big project like Gaia or some other open source projects, this would not be a good idea to do so.
Go check Gaia repository first, you will notice there are more than 35,000 commits and 470+ contributors in this project. To be honest, this is really a huge repository. There are so many people working at the same time in different timezones trying to make FirefoxOS better, so there must be really hard to control. But after being part of Mozillian, I finally understand how they try to maintain it.
Our latest commit history
As you may see, for us, each commit will be reflected to one bug with bug number on the title. By doing so, we can easily understand what this patch is for and what it is going to fix. With bug id, I can easily search Mozilla’s bugzilla to understand the discussion histories and design specs there.
In addition to this, if each commit is mapped to each bug, then we can easily revert any patch that broke Gaia! For example, you can check the picture and notice that there is a revert commit made by crh0716. That’s because the patch broken something in Gaia, anyone can go ahead and find out the patch then back it out !
It’s amazing, isn’t it ?!
If you read this line, it means you did read the whole article and want to know something about this ! From my experiences, I noticed there are less people knowing how to do this (I met few contributors and they all messed the git history up in the end xD ! It happens every time LOL).
So, I made a quick screenshot to help you understand how to do this. Just to remind you, there may be some other ways to achieve this, but this is how I do in my daily life.
Hope this helps ! And any feedback or comment is appreciated ! Cheeeeeers !