Category Archives: Operating Systems

My semester in UCOSP

If you do not know what UCOSP is then you should consider reading my explanation post: What is UCOSP? Otherwise in short: UCOSP is a practical experience for Canadian Computer Science students to work on open source as a distributed team. For my UCOSP project I wrote a zip extraction library for BB10.

How I got enrolled

I found out about UCOSP in mid June while I was still at Microsoft for my internship. My self-assigned task that day was to arrange all my courses for the next school year. Many of the courses I wanted to take required pre-approval from professors which in turn required an essay, so planning ahead was vital.

While finishing up one of my essays I saw one of my friends online so I chatted with him. I tried to convince him to take one of the cool courses along with me. Meanwhile he asked if I had been invited to some course called “UCOSP”. In his words: “open source project course”. Little did he know that those words describe the perfect course ever! Imagine getting credits for doing open source projects!

Yet I had a stumbling block. Enrollment required an essay due the next day. Meanwhile said friend has one of the highest GPAs in our year and thus got invited. My own GPA is not bad per-say but it must not have been high enough for the invitations. Which makes sense since UCOSP is a new program at our university, they would want to run the pilot with our best students. Yet this means my work is just that much harder: I have to write an essay that qualifies for UCOSP but also one that convinces the professor to risk letting me in on his shiny new pilot course.

As if that was not hard enough my friend wasn’t sure he was allowed to give me the name of said university professor! So I sent an email off to the UCOSP steering commity asking for the contact. They replied the next morning with the professors name, and I sent off an essay email soon after. Five days later I got an email saying I was accepted.

Our Hackathon

At the beginning of every UCOSP semester all the students along with their project mentors are brought together for a hackathon. This semester the hackathon was in Toronto and hosted by Mozilla. Next semester I hear it will be in California hosted by facebook!

IMG_20130919_105120

Calgary’s Glenmore Reservoir from the airplane

Being on the wrong side of North America meant I had a long flight on the 19th of September. To make the trip more nerve-racking I’m far too cheap for a taxi. Instead, after my four hour flight I took the Airport express bus to the subway, after which I walked to the University of Toronto Campus for the evening meetup.

IMG_20130919_165118

View from the Univeristy of Toronto’s Computer Science’s upper meeting room.

While the hackathon wasn’t starting until the next day, we had an optional meet-and-greet at the University of Toronto. Somehow everyone from my team made it except our mentor. Which is okay since there were only one or two mentors there in total. Beyond some ice-breakers, we also met some of the professors organizing UCOSP. In all it was a nice low key event.

 

IMG_20130920_065936

Left half of Mozilla’s entrance way. I should have taken a fuller photo but I only even took this one for the banner’s sake.

The walk from our hotel to Mozilla was long and took us through Toronto’s banking district known through out Canada as Bay Street. We ate breakfast at First Canadian Place, I had eggs.

IMG_00000010

The hackathon in full swing! Look at that coding! The intensity! You can tell work is getting done because no one is talking.

At this point I have to apologise, I took almost no photos of the hackathon itself. I have a few but most are test photos from my developer phone. Speaking of which, our mentor gave us each a developer phone!

IMG_20130920_070913

Our BB10 developer phone!

I have far too many smartphones at this point but this is still the first phone someone has ever given me. The phone itself is a Blackberry Q10 with a different shell. Since matte black is my favourite color I have to admit that I prefer this dev phone over the Q10. Since the BB10 emulator requires VMware under linux, which I do not own, this dev phone was critical.

You might be curious at this, I have yet to tell you what we were even working on!

Our Project

My team’s project was to port popular Cordova plugins to BB10’s new Cordova based html5 platofrm. Cordova is a compatibility layer over a mobile platform’s app embedded web browser which exposes phone features as web APIs. In iOS terms is wraps the WebView and provides access to memory cards, cameras, and etc. Cordova is the offical open source name of PhoneGap after Adobe bought and open sourced PhoneGap. At the time of our hackathon, Blackberry’s offical html5 platform was proprietary and called WebWorks. Our work was to coincide with the development of WebWorks 2.0 which was based on Cordova. Plugins are extra APIs. For example the API I ported exposes extraction of zip files. Our mentor set a goal of four plugins, of course more would be welcomed.

Back to the Hackathon

IMG_00000018_hdr

I might have been playing with the phone’s built in instagram-like filters when I took this photo, or maybe the HDR. Otherwise I cannot explain the lighting.

For our part this hackathon. was spent setting up our development environments. Sad to say but the setup process is a PITA. Clocking in at 15 steps when I wrote it up, there is zero chance I would have figured it out without our mentor’s inside knowledge of BB10. At this point I should mention that our mentor works at Blackberry so in a way our project was an extension of BB10’s development.

In a far too real way, half our pain was rooted in BB10’s closed nature. We had to request keys from Blackberry and these keys were only batch generated every two hours. Once the server sent you a key, you had to setup two different processes for package signing. The dev phone themselves needed to be put into dev mode after every reboot or you would hit misleading error messages. By far, the most painful mobile dev environment I’ve ever setup and it stands it stark contrast to Firefox OS’s dead simple html5 environment.

IMG_20130921_155015

This may have been the morning of the 21st, or the evening. In either case we were all tired.

 

IMG_20130920_102218

Midway through the 20th, Mozilla gave a demo of asm.js. I’ve seen it before, but it was exciting to see a demo of the tech from Mozilla themselves.

IMG_20130922_090127

I’ve never been on a real tram before so it was nice to have the chance on my way back to the airport.

In prior years UCOSP tried to go right up until the offical end hour but this year they organized things to allow early departures. This gave me plenty of time for my airport commute.

IMG_20130922_171439

Somewhere over the prairies. Judging by the abundance of lakes, I’d guess Manitoba.

Rest of the Semester

Once home I met with my professor on Monday to plan how the work would go. He suggested writing a list of commitments for the week in our weekly monday meeting. Then during the next meeting I had something concrete to report on. For the first week I took it slow to catch up on missed school work. In the later weeks the goals were sub-milestones for my zip plugin.

At the semester’s end he had us UCOSP students give a presentation on our projects to each other and to the students in his other capstone course.

In the end we hit our goal at four plugins but there is a chance we were still the least successful this semester. We got the work done and I’m proud of that, but we didn’t act as a distributed team. We set out as two subgroups of two devs a group. Due to some hardware, failure my partner didn’t have a development environment setup until half-way through the semester. By this time I was deep into my zip extraction plugin so instead of joining me on the zip plugin, my partner decided to start out on his own plugin and salvage what was left of his semester. I regret not keeping in better contact with him. I had pinged him a few times but I held back checking too often for fear of being nosey.

Thus, I cannot report doing the fun distributed team things like code reviews or hanging out on irc. With that said, please don’t let my experience discourage you. Stuff happens and sometimes things go wrong, but in general they go right. The other UCOSP students from my university reported lots of code reviews, wikis, and even team blogs! Just imagine, next year you could be hanging out with team members from across Canada working on your own UCOSP project! Apply today!

Intro to Mozilla IRC Lingo

If you are new to Mozilla’s IRC channels, as I am, then you might have noticed some new and unknown words. All companies and communities have internal lingo built up over many years. Mozilla is different from a typical company because regular internal communication is done in the open. This means we get to hear said lingo used among employees who all know the terms by heart.

It can be intimidating coming to any community with such history and culture as Mozilla. This feeling is perfectly normal and will dissipate in time. To help the process let us explore some of the common terms unique to Mozilla. Thus you’ll know the terms the next time another Mozillian uses one.

R+

Mozilla has a healthy culture of code reviews. Real, concrete, effective code reviews mean approval is not trivial. An r+ means completing a code review and approving the commit. Some aspects of the patch may need changing but for the most part the patch is clear for commit. The wiki has more details on r+’s and their exact meaning if you want to get technical: https://wiki.mozilla.org/Firefox/Code_Review#What_does_r.2B_mean.3F

R-

The opposite of an r+ is the r-. Given when a patch is rejected, an r- does not mean the change cannot be fixed. Since r- can come across discouraging I suspect reviewers only use the term when talking to long term contributors.

CLOBBER

In all situations I’ve seen where CLOBBER gets mentioned it has been out of frustration. To clobber a tree causes a massive slowdown and annoys other developers but I do not understand the exact cause. The wiki provides some details but I’m not familiar with the build system: https://wiki.mozilla.org/Clobbering_the_Tree

ping

To get someone’s attention on IRC it is typical to mention their name in a message. This triggers highlighting of your message and triggers a bing sound on some IRC clients. If someone is on IRC but not active it is common for mozzilians to “ping” them. Such a ping takes the form, “<username>: ping”. For example when pinging me you would say “danieru: ping”. You’ll notice that this typical usage excludes any details about why the person is getting pinged. Instead it has been suggested that a ping should also contain a sentence mentioning the ping’s purpose. So going back to our example you might want to say “danieru: ping, I need help compiling fxos. I’m getting linking errors with example()”.

pong

In response to a ping the person pinged will often say “pong”. This means you may see “ping, pong” if both users are online at the same time. For any native English speakers reading the humour comes from the usage of “ping” which is a network tool used to check connectivity as a way to check for the attention of other Mozillians. Then in response “pong” interprets the ping as the “ping” in ping-pong, a sport also known as table tennis. Sorry if this ruins the humour.

++

In programming languages inspired by C the operator ++ is  the pre or post incrementor. It is used like thus: “var++”. This operator will make the incremented variable equal to the original value plus one. Thus on Mozilla IRC, ++ is another way of saying “+1”. In turn “+1” is an expression meaning “I like this” or “This is true”. So if someone says ++ it means they are agreeing with something said earlier.

And that completes my knowledge of Mozilla specific terminology. If you know any other terms please mention them or ping me.

land

Commit a patch to the inbound branch or repository after the patch has been reviewed with a R+. For Mozilla Central this would be mozilla-inbound or for Gaia the gaia/master branch.

Uplift

Merge or promote a patch from the inbound repository to the stable branch. For Mozilla Central this would be Mozilla Central or for Gaia this would be a tagged version branch such as 1.2.

Sec-Critical

When security bugs which cover normal browsing get found they are marked sec-critial. These bugs cannot be viewed by the general public until they have been fixed. Once a fixed version of our software has been shipped the sec-critical bug is made public. For example  see Bug #785967

Chemspill

When a security bug is found it may force our hand and require an early general release of our software. This early release is known as a chemspill.

Clownshoes

Bugs vary in scope and size yet in general a bug will only have one developer writing code to fix it. This can create a situation where the bug is larger than the person. Or as the analogy goes: the person is wearing oversized clownshoes.

TODO: No other terms I know of. Can you suggest any?

Ubuntu 13.10 Blackberry OS 10 Cordova plugin development setup

After upgrading to Ubuntu 13.10 the QDE setup for 13.04 needs new dependencies. The change itself is small, just install the following libraries before you run qde:

sudo apt-get install libgtk2.0-0:i386 libpangox-1.0-0:i386 libpangoxft-1.0-0:i386 libidn11:i386 gstreamer0.10-pulseaudio:i386 gstreamer0.10-plugins-base:i386 gstreamer0.10-plugins-good:i386 gstreamer0.10-ffmpeg:i386libcanberra-gtk-module:i386 libcanberra-gtk0:i386 libcanberra-gtk3-0:i386 libcanberra-gtk3-module:i386 libxtst6:i386

If you do not install those you will get errors like:

After upgrading to Ubuntu 13.10 the QDE setup for 13.04 needs new dependencies. The change itself is small, just install the following libraries before you run qde:

If you do not install those you will get errors like:

java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: 
	/home/danieru/.bbndk/configuration/org.eclipse.osgi/bundles/364/1/.cp/libswt-pi-gtk-4236.so: libgtk-x11-2.0.so.0: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません
	no swt-pi-gtk in java.library.path

 

 

Unboxing the Firefox OS ZTE Open, + setup

My Firefox phone arrived today! The ZTE Open is an interesting device. ZTE is selling it on ebay for ~$80. By no means is it a high end device. In theory I like the idea that developers are not running devices 7 times more powerful than their users. Targeting the emerging market only pushes down the average device’s horsepower. As a bonus this dev phone is cheap and does not require subsidization or give aways like the earlier androids or blackberry dev phones. The price itself puts it in impulse buy territory.

First I must admit to being struct by the box’s slipcover. The cardboard look is utilitarian and sparse.
IMG_20131021_161027

The box under the slipcover is more typical for a smartphone. I can imagine seeing this box on a retail shelf.IMG_20131021_161127 IMG_20131021_161226

Included with the phone is a micro usb cable, headphones, and a usb charger. Without listening to them I suspect the headphones are not going to sound good.  The battery is pre-inserted in the phone.IMG_20131021_161349 IMG_20131021_161514

We must insert the battery which requires finding the latch in the the lower right corner. I’ve photographed the location since it was harder to find than expected. You will not feel the latch during normal usage.IMG_20131021_161615

Upper left is the microSD card slot, the right is the fullsized sim slot. IMG_20131021_161702

First bootup splash screen. IMG_20131021_162055

Second bootup splash screen. IMG_20131021_162059

Once booted we enter the setup process. There are things I think should be changed. Please do not that this as criticism but instead as justifications for my suggestions which will find their way into bug reports.IMG_20131021_162130 IMG_20131021_162154 IMG_20131021_162333

Once we’ve entered the wifi password and joined the network we’re sent back to the network select screen as shown below. This was not what I expected. I thought we’d go on to the contacts screen since we’ve done everything we can do with the wifi. IMG_20131021_162405 IMG_20131021_162406

This screen is what I do not understand. We already have network access, and we’ve had minutes to initiate the GPS. I should not have to tell the phone anything of what it is asking. Notice how the time has defaulted to the epoch, unix timestamp zero. Now assuming we need this screen only as a fallback I wish we were not expected to guess what those buttons will change. It should tell me we are looking at:

  1. Region
  2. Nearest City in timezone
  3. Date
  4. Time

I bring this up because I got confused. I thought #2 meant province / state. I do not know what or where “Pago Pago” is. I thought #3 is date format. Similar to how golang defines date formatting. Instead it was the date selector.

IMG_20131021_162407

Considering the emerging market nature of FxOS’s target market I think this risks confusion. I know that when selecting a timezone I must pick Edmonton. I know this only from installing linux several times. We cannot expect regular people to know they must select a city, which they may not live in, which must be close, but which must not be in the next timezone. To make matters worse the list is ordered alphabetically. Without knowing the exact city to select we must search through a list containing every city on our continent.

Good would be to order by location. Better would be to have them select their location on a world map. Best would would be to use our GPS if we have a signal.IMG_20131021_162520

Now onto the time selector widget. This is what said time selector looks like right after we hit “change”. Notice how it knows the current date. Remember how the screen prior defaulted to timestamp zero. The phone already knows the current time!

Better would be to preset the setup screen’s time to whatever time this time selector widget thinks it is. Best would be to send off an NTP packet and get the real time over the network. Remember, we already setup the wifi connection.IMG_20131021_162617

This title is too long.  I had to change my app’s title to fit the app screen, this screen needs the same treatment.IMG_20131021_162850

I wish something in bigger letters told me this is a newsletter signup screen. Instead I thought it was a registration screen. IMG_20131021_162900

The following tutorial is good and does the job. I’m sure they would prefer a tutorial which used the real homescreen instead of the abstract images. I understand that feature is extra work on a level beyond the other suggestions. I just hope it is on someone’s todo list. IMG_20131021_162920 IMG_20131021_162930

Note how it asks us to find new apps to the homescreen’s left, we will have a problem with this later. IMG_20131021_162938 IMG_20131021_162947

Also note how it asks us to swipe down. IMG_20131021_162957 IMG_20131021_163009 IMG_20131021_163023

Keeping in mind the instructions we saw earlier I wanted to install the app i made a few days ago. This screen is supposed to be where one finds new apps. Yet these search results do not look like the “IP Address” apps I saw in the Firefox Market. Instead these look like website bookmarks.IMG_20131021_163340

Rather we must go to the homescreen’s right where we find the Firefox appstore. And it is here we find my app. IMG_20131021_163523 IMG_20131021_163621 IMG_20131021_163640 IMG_20131021_163650 IMG_20131021_163737

As we noted earlier one should be able to bring down the notification screen by swiping down from the top. Instead we must press, hold, then pull down. Swiping down without holding is interpreted as swiping left or right.

IMG_20131021_163812

Now just for interests’ sake let us analyse the ZTE Open’s box in relation to the other dev phones I have. The Nexus 4 aims to look premium. The box is trying to convey that a $300 phone can be no less premium than the $600 competitors. The Blackberry 10 box aims to feel exclusive through the mission statement on the box. All the Blackberry dev phones are given as gifts to developers. They want you to feel honoured and inspired to develop an application.

The exact mission statement is:

Exclusive for the Blackberry Developer
Community. Not a production modal.
Evaluation unit -- not for resale.

Millions of possibilities..

By my guess the ZTE Open aims to look grassroots or atleast non-intimidating. The Blackberry mission statement is the opposite. Blackberry wants to look established and confident. ZTE Open wants to look new and promising.

IMG_20131021_172233

To be honest I think the box achieves the goal. I do not expect FxOS to be complete. I expect it to have room for improvement and to be welcoming of my contributions. That is what FxOS needs right now, the luxury boxes can come later.

FxOS app development is super easy!

Over the years I’ve setup several app development environments:

  1. Meamo
  2. Android
  3. Ubuntu Touch
  4. Blackberry

None of those compare to how pleasant Firefox OS’s dev environment is. This morning in viruses class I installed the Firefox OS simulator. Unlike the above platforms the simulator is not a full weight virtualized operating system. It is nothing more than a firefox addon!

The other platforms would take a full day or more to setup their virtual machine and the compile tool chain. Instead I was making real progress on my first FxOS app before my morning’s first class was over!

Now 12 hours after starting my app is live on the Firefox Marketplace!

The app itself is here: https://marketplace.firefox.com/app/my-ip-is/

The source is in this git repo: https://github.com/daniel-dressler/whatismyipaddress

Next I plan to port the html5 WordPress Update Assistant I wrote last year. The entire process is pure fun and I am surprised at how easy FxOS has made app creation.

myip_logo_128

The FxOS app icon style appears to be circles. This is in contrast to iOS’s rounded squares, and Android’s objects.

screenshot_1

I used Firefox’s “building blocks” which provide FxOS look and feel through css sheets. Other apps in the marketplace use bootstrap or jQuery Mobile. The high quality apps use the building blocks plus heavy themeing.