I wanted to give my one cent about the GNOME project, and where I think it could be successful. It would be two cents if I were actually involved in any constructive manner, but I am not. So it is one cent.

Ever since I started contributing to GNOME, the looming questions have been mobile, web, and social. Every keynote at GUADEC has tugged us in that direction, or promised to “reboot” the effort. If it is Big Board and Mugshot, Pyro Desktop, Telepathy and the collaboration it was supposed to bring, the countless OpenedHand and Nokia innovations, etc. We have all been running around like a chicken with its head cut off ever since I remember, trying to capture the essence of these new trends and remain relevant.

We failed.

Apple revolutionized not just mobile, but reinvented the mainstream computing form factor. Facebook made “social” ubiquitous, and Google is doing what it is doing to the web. In the meantime, I never gained any following on Last.fm from all those years of scrobbling music with Rhythmbox and Banshee, I never got an opportunity to use Telepathy tubes with any real live person, and apparently my Mugshot profile is gone. My eyes also got tired of squinting at XTerm on my N900.

Last year in Berlin, the lack of direction was apparent. Almost every keynote that I remember was given by one kind of designer or seo company. Somewhere along the line we confused design with leadership. At least there wasn’t as much self delusion about our bright future on mobile.

But there is a way out of this rut. And it requires acknowledging our weaknesses and exploiting our strengths.

Our weak areas are apparent: We are not mobile and we are very far from it. We will never achieve any significant social critical mass, we have had limited successes in embracing web technologies, but the web will always be a better web. Deploying “apps” is a nightmare.

Our strengths are pretty obvious too: In the last few years we successfully refreshed the desktop work flow and our entire framework. We support many productivity and authoring tools. We created a distraction free environment that lets users get work done. We run on commodity hardware. We are free. We have a windowed multitasking environment. We work really well with a screen, mouse and keyboard (not to be taken for granted, look at all the awkward Android tablet keyboard combos out there). More than one web browser supports us. There is a more than fully functional office suite that works well with us. Etc.

So instead of aspiring to be in every consumer gadget out there, I think we should aspire to be the work horse of choice for every content creator out there. This includes mobile/web developers, graphic designers, artists, bloggers, video bloggers, authors, journalists, podcast producers, and every other kind of content creator that makes the mobile web and social such a vital space for the rest of the world. We need to refocus on the desktop.

Let’s leave the mission of bringing free software to mobile and the web to others. Other groups are doing a great job there. They are in their element; let’s remain in ours. We should focus on the production end of the New Media pipeline.

Projects such as The GIMP, PiTiVi, Anjuta, Blender and Libre Office should be our bread and butter. We should strive to stay ahead of the curve on the authoring end. We should document and support Android and Unity development. The Wacom tablet support that landed recently is a good example of what we could be doing.

It feels like GNOME is being maintained by a skeleton crew, and a shrinking set of corporate stakeholders. I think it is time to be realistic about what we could excel at, and go there. We don’t have to be on every existing form factor to achieve world domination. The cloud, and all these cheap new gadgets have lowered the barrier to access. We could lower the barrier of authorship, and enable people to create new and rich content.

Normally, a small book like this (193 pages) would be a quick read for me, but this book took me literally months. Not, I hasten to add, because of any problems with the book or the writing style, that was all fine. The problem was that this book uncovered a bunch of things I am personally working through. I found myself reading a few pages, highlighting some lines, then walking away thinking. Repeat a few times a week. Occasionally, I’d go back and re-read entire chapters.

For me, bragging has negative connotations and is something I avoid like the plague. Stereotypes of obnoxious, pretentious people, loudly telling all within range just how great they are. The very last thing I ever want to be. Whether that is cultural, learned from family, something I developed myself growing up, or a mixture, I don’t know. But it is part of who I am. This book is all about encouraging people to find a comfortable place in between these extremes. As Peggy is quick to note, this means different things to different people, so you need to pay attention to what is authentic for you, as that authenticity is important. People have generations of experience spotting fakes, and worst of all, deep down, you’ll know you are faking it too.

Because of the book title, it took several people pushing to get me to even start reading this book. Chapter#1 opened with a line that stopped me dead in my tracks.

“Myth#1: A job well done speaks for itself.”

I’ve always thought that if I did a good job, or handled a tricky situation well, people would notice. If I solved some complex problem, that people would understand the complexity, understand the importance of the achievement and appreciate the work. In those circumstances, having others recognize and complement the achievement was fine, but any attempt on my part to “brag” about my work would in some way “cheapen the victory”. After reading this book, I now think that is *sometimes* true but not always true. While the people working beside me in the same trenches, working side-by-side with me on the problem might understand the scale of the accomplishment, most people simply don’t know the details. Over time, people might eventually notice that a recurring problem hasn’t happened in a while, or they might simply forget about a previously-annoying problem because it hasn’t happened in a while… but they’d never stop and wonder why. Another common trend is for people to not notice one problem is fixed, but instead notice that a different problem has “appeared”. Oh, and meanwhile, people don’t know what you are working on. Over time, this becomes frustrating for everyone. After reading this book, I’ve learned that I need to make sure I inform people of the work I’m doing, and why it’s important to them. I don’t need to go into all the complexities of the project, unless they ask for more details, but it’s important to make sure others are aware of my work, and the impact it has on them and their work.

I found this a tough read, yet super worth the time. And, yes, I strongly recommend it.

“It ain’t bragging if you done it” (Dizzy Dean)

A few days ago a vertical video went viral of the student Jeff Bliss telling his teacher off for being a bad teacher who just hands out materials without explaining anything.

And we all applauded him for his gall and his eagerness to learn and to point out the obvious flaws in the education system. Teachers are not paid enough, are under more stress to be seen as someone who has students with good grades rather than understanding and have to deliver course materials they don’t believe in but are forced to go through as those are the ones that are easy to mark.

Terrible, isn’t it? So why do people in our little world of web development constantly and voluntarily become this bad, bored and ineffective teacher?

What am I talking about? The thing I mentioned in large detail in my talk at BaconConf this year but here it is for the generation who wants things in 140 chars or as a cute image with large letters on it:

Whenever you answer a question of another developer with “just use $x” you breed an expert idiot. You did not teach them anything, you showed a way out of learning.

In my ongoing task to de-clutter my life I just un-subscribed from several communities on Google+, namely the HTML5 community and the JavaScript one. Not because I am not interested in these matters any more, quite the opposite: because I care much about these communities and all I found there is frustration and annoyance. Nearly every single question new developers have is answered in three ways:

• Use jQuery – here is a plugin
• Just Google for it
• You’ll need to use framework $x / JavaScript and/or HTML5 is not good enough for that

None of these answers are satisfactory if you really want to help someone who needs to solve a problem and learn how to repeat the solution in the future. The latter in most cases is a plain lie and shows that you are blaming a technology for your lack of interest in it.

What gets answered far too quickly is the “how” – how to achieve a massively complex result (which yet has to be proven to be really necessary) without thinking about it or understanding the solution that you apply. We assume that is enough and that we are doing something good – we let a new developer have a positive experience of having something achieved very quickly and that will obviously entice him or her to learn more and go explore in more detail later on.

That is not necessarily the case. We showed people a shortcut and how to focus on the outcome and hope the step where they understand what they are doing comes later. Sadly in a lot of cases this never comes but it fills people with fake confidence that gets shattered once they have their first job interview in a real company who cares about what they build.

If you want to teach people, make them understand the “why” and let them find their own “how”. That is much harder work, but also much more rewarding when you see them grow and explore.

We do not teach people how to write by copying and pasting the style of other authors. We tell them about similes, metaphors, rhetoric devices, orthography and grammar rules. Why bother with that? We could just show them TXTSPK and explain that anyone who knows English will understand what they try to convey. The reason why we do it is that we teach the fun of playing with language and finding your own style.

“But I don’t have time for that – I just want to help someone solving their problem”

Is a very common, admirable, but misguided idea. What you do is advertise the solution that made most sense to you as you already solved the problem. You steal the learning experience away from the other person and the way we learn is our most personal asset and differs vastly from person to person.

If you don’t want to really teach and see people grow and learn on their own terms, please stop spouting truisms and “best quick solutions” in places where people come to learn. If all they want is for you to solve their issue, they should hire you to do so for them.

Don’t be the grumpy teacher you learned to first despise and later on pity. We can do better on the web.

So I've now built my first real application using AngularJS. It's a fun side-project which my wife and I use to track what we spend money on. It's not a work project but it's also not another Todo list application. In fact, the application existed before as a typical jQuery app. So, I knew exactly what I needed to build but this time trying to avoid jQuery as much as I possibly could.

The first jQuery based version is here and although I'm hesitant to share this beginner-creation here's the AngularJS version

The following lists were some stumbling block and other things that stumped me. Hopefully by making this list it might help others who are also new to AngularJS and perhaps the Gods of AngularJS can see what confuses beginners like me.

1. AJAX doesn't work like jQuery

Similar to Backbone, I think, the default thing is to send the GET, POST request with the data the body blob. jQuery, by default, sends it as application/x-www-form-urlencoded. I like that because that's how most of my back ends work (e.g. request.GET.get('variable') in Django). I ended up pasting in this (code below) to get back what I'm familiar with:

module.config(function ($httpProvider) { $httpProvider.defaults.transformRequest = function(data){ if (data === undefined) { return data; } return $.param(data); }; $httpProvider.defaults.headers.post['Content-Type'] = '' + 'application/x-www-form-urlencoded; charset=UTF-8'; }); 2. App/Module configuration confuses me

The whole concept of needing to define the code as an app or a module confused me. I think it all starts to make sense now. Basically, you don't need to think about "modules" until you start to split distinct things into separate files. To get started, you don't need it. At least not for simple applications that just have one chunk of business logic code.

Also, it's confusing why the the name of the app is important and why I even need a name.

3. How to do basic .show() and .hide() is handled by the data

In jQuery, you control the visibility of elements by working with the element based on data. In AngularJS you control the visibility by tying it to the data and then manipulate the data. It's hard to put your finger on it but I'm so used to looking at the data and then decide on elements' visibility. This is not an uncommon pattern in a jQuery app:

<p class="bench-press-question"> <label>How much can you bench press?</label> <input name="bench_press_max"> </p> if (data.user_info.gender == 'male') { $('.bench-press-question input').val(response.user_info.bench_press_max); $('.bench-press-question').show(); }

In AngularJS that would instead look something like this:

<p ng-show="male"> <label>How much can you bench press?</label> <input name="bench_press_max" ng-model="bench_press_max"> </p>

if (data.user_info.gender == 'male') { $scope.male = true; $scope.bench_press_max = data.user_info.bench_press_max; }

I know this can probably be expressed in some smarter way but what made me uneasy is that I mix stuff into the data to do visual things.

4. How do I use controllers that "manage" the whole page?

I like the ng-controller="MyController" thing because it makes it obvious where your "working environment" is as opposed to working with the whole document but what do I do if I need to tie data to lots of several places of the document?

To remedy this for myself I created a controller that manages, basically, the whole body. If I don't, I can't manage scope data that is scattered across totally different sections of the page.

I know it's a weak excuse but the code I ended up with has one massive controller for everything on the page. That can't be right.

5. setTimeout() doesn't quite work as you'd expect

If you do this in AngularJS it won't update as you'd expect.

<p class="status-message" ng-show="message">{{ message }}</p>

$scope.message = 'Changes saved!'; setTimout(function() { $scope.message = null; }, 5 * 1000);

What you have to do, once you know it, is this:

function MyController($scope, $timeout) { ... $scope.message = 'Changes saved!'; $timeout(function() { $scope.message = null; }, 5 * 1000); }

It's not too bad but I couldn't see this until I had Googled some Stackoverflow questions.

6. Autocompleted password fields don't update the scope

Due to this bug when someone fills in a username and password form using autocomplete the password field isn't updating its data.

Let me explain; you have a username and password form. The user types in her username and her browser automatically now also fills in the password field and she's ready to submit. This simply does not work in AngularJS yet. So, if you have this code...:

<form> <input name="username" ng-model="username" placeholder="Username"> <input type="password" name="password" ng-model="password" placeholder="Password"> <a class="button button-block" ng-click="submit()">Submit</a> </form>

$scope.signin_submit = function() { $http.post('/signin', {username: $scope.username, password: $scope.password}) .success(function(data) { console.log('Signed in!'); }; return false; };

It simply doesn't work! I'll leave it to the reader to explore what available jQuery-helped hacks you can use.

7. Events for selection in a <select> tag is weird

This is one of those cases where readers might laugh at me but I just couldn't see how else to do it.
First, let me show you how I'd do it in jQuery:

$('select[name="choice"]').change(function() { if ($(this).val() == 'other') { // the <option value="other">Other...</option> option was chosen } });

Here's how I solved it in AngularJS:

$scope.$watch('choice', function(value) { if (value == 'other') { // the <option value="other">Other...</option> option was chosen } });

What's also strange is that there's nothing in the API documentation about $watch.

8. Controllers "dependency" injection is, by default, dependent on the controller's arguments

To have access to modules like $http and $timeout for example, in a controller, you put them in as arguments like this:

function MyController($scope, $http, $timeout) { ...

It means that it's going to work equally if you do:

function MyController($scope, $timeout, $http) { // order swapped ...

That's fine. Sort of. Except that this breaks minification so you have to do it this way:

var MyController = ['$scope', '$http', '$timeout', function($scope, $http, $timeout) { ...

Ugly! The first form depends on the interpreter inspecting the names of the arguments. The second form depends on the modules as strings.

The more correct way to do it is using the $inject. Like this:

MyController.$inject = ['$scope', '$http', '$timeout']; function MyController($scope, $http, $timeout) { ...

Still ugly because it depends on them being strings. But why isn't this the one and only way to do it in the documentation? These days, no application is worth its salt if it isn't minify'able.

9. Is it "angular" or "angularjs"?

Googling and referring to it "angularjs" seems to yield better results.

This isn't a technical thing but rather something that's still in my head as I'm learning my way around.

In conclusion

I'm eager to write another blog post about how fun it has been to play with AngularJS. It's a fresh new way of doing things.

AngularJS code reminds me of the olden days when the HTML no longer looks like HTML but instead some document that contains half of the business logic spread all over the place. I think I haven't fully grasped this new way of doing things.

From hopping around example code and documentation I've seen some outrageously complicated HTML which I'm used to doing in Javascript instead. I appreciate that the HTML is after all part of the visual presentation and not the data handling but it still stumps me every time I see that what used to be one piece of functionality is now spread across two places (in the javascript controller and in the HTML directive).

I'm not givin up on AngularJS but I'll need to get a lot more comfortable with it before I use it in more serious applications.

My first experience with Mercurial (Firefox development) was very unpleasant. Coming from Git, I thought Mercurial was slow and perhaps even more awkward to use than Git. I frequently encountered repository corruption that required me to reclone. I thought the concept of a patch queue was silly compared to Git branches. It was all extremely frustrating and I dare say a hinderance to my productivity. It didn't help that I was surrounded by a bunch of people who had previous experience with Git and opined about every minute difference.

Two years later and I'm on much better terms with Mercurial. I initially thought it might be Stockholm Syndrome, but after reflection I can point at specific changes and enlightenments that have reshaped my opinions.

Newer versions of Mercurial are much better

I first started using Mercurial in the 1.8 days and thought it was horrible. However, modern releases are much, much better. I've noticed a steady improvement in the quality and speed of Mercurial in the last few years.

If you aren't running 2.5 or later (Mercurial 2.6 was released earlier this month), you should take the time to upgrade today. When you upgrade, you should of course read the changelog and upgrade notes so you can make the most of the new features.

Proper configuration is key

For my workflow, the default configuration of Mercurial out of the box is... far from optimal. There are a number of basic changes that need to be made to satisfy my expectations for a version control tool.

I used to think this was a shortcoming with Mercurial: why not ship a powerful and useful environment out of the box? But, after talking to a Mercurial core contributor, this is mostly by design. Apparently a principle of the Mercurial project is that the CLI tool (hg) should be simple by default and should minimize foot guns. They view actions like rebasing and patch queues as advanced and thus don't have them enabled by default. Seasoned developers may scoff at this. But, I see where Mercurial is coming from. I only need to refer everyone to her first experience with Git as an example of what happens when you don't aim for simplicity. (I've never met a Git user who didn't think it overly complicated at first.)

Anyway, to get the most out of Mercurial, it is essential to configure it to your liking, much like you install plugins or extensions in your code editor.

Every person running Mercurial should go to http://mercurial.selenic.com/wiki/UsingExtensions and take the time to find extensions that will make your life better. You should also run hg help hgrc to view all the configuration options. There is a mountain of productivity wins waiting to be realized.

For reference, my ~/.hgrc. Worth noting are some of the built-in externsions I've enabled:

• color - Colorize terminal output. Clear UX win.
• histedit - Provides git rebase --interactive behavior.
• pager - Feed command output into a pager (like less). Clear UX win.
• progress - Draw progress bars on long-running operations. Clear UX win.
• rebase - Ability to easily rebase patches on top of other heads. This is a basic feature of patch management.
• transplant - Easily move patches between repositories, branches, etc.

If I were on Linux, I'd also use the inotify extension, which installs filesystem watchers so operations like hg status are instantaneous.

In addition to the built-in extensions, there are a number of 3rd party extensions that improve my Mozilla workflow:

• mqext - Automatically commit to your patch queue when you qref, etc. This is a lifesaver. If that's not enough, it suggests reviewers for your patch, suggests a bug component, and let's you find bugs touching the files you are touching.
• trychooser - Easily push changes to Mozilla's Try infrastructure.
• qimportbz - Easily import patches from Bugzilla.
• bzexport - Easily export patches to Bugzilla.

I'm amazed more developers don't use these simple productivity wins. Could it be that people simply don't realize they are available?

Mozilla has a bug tracking easier configuration of the user's Mercurial environment. My hope is one day people simply run a single command and get a Mozilla-optimized Mercurial environment that just works. Along the same vein, if your extensions are out of date, it prompts you to update them. This is one of the benefits of a unified developer tool like mach: you can put these checks in one place and everyone can reap the benefits easily.

Mercurial is extensible

The major differentiator from almost every other version control system (especially Git) is the ease and degree to which Mercurial can be extended and contorted. If you take anything away from this post it should be that Mercurial is a flexible and agile tool.

If you want to change the behavior of a built-in command, you can write an extension that monkeypatches that command. If you want to write a new command, you can of course do that easily. You can have extensions interact with one another - all natively. You can even override the wire protocol to provide new capabilities to extend how peers communicate with one another. You can leverage this to transfer additional metadata or data types. This has nearly infinite potential. If that's not enough, it's possible to create a new branching/development primitive through just an extension alone! If you want to invent Git-style branches with Mercurial, you could do that! It may require client and server support, but it's possible.

Mercurial accomplishes this by being written (mostly) in Python (as opposed to C) and by having a clear API on which extensions can be built. Writing extensions in Python is huge. You can easily drop into the debugger to learn the API and your write-test loop is much smaller.

By contrast, most other version control systems (including Git) require you to parse output of commands (this is the UNIX piping principle). Mercurial supports this too, but the native Python API is so much more powerful. Instead of parsing output, you can just read the raw values from a Python data structure. Yes please.

Since I imagine a lot of people at Mozilla will be reading this, here are some ways Mozilla could leverage the extensibility of Mercurial:

• Command to create try pushes (it exists - see above).
• Record who pushed what when (we have this - it's called the pushlog).
• Command to land patches. If inbound1 is closed, automatically rebase on inbound2. etc. This could even be monkeypatched into hg push so pushes to inbound are automatically intercepted and magic ensues.
• Record the automation success/fail status against individual revisions and integrate with commands (e.g. only pull up to the most recent stable changeset).
• Command to create a review request for a patch or patch queue.
• Command to assist with reviews. Perhaps a reviewer wants to make minor changes. Mercurial could download and apply the patch(es), wait for your changes, then reupload to Bugzilla (or the review tool) automatically.
• Annotating commits or pushes with automation info (which jobs to run, etc).
• Find Bugzilla component for patch (it exists - see above).
• Expose custom protocol for configuring automation settings for a repository or a head. e.g. clients (with access) could reconfigure PGO scheduling, coalescing, etc without having to involve RelEng - useful for twigs and lesser used repositories.
• So much more.

Essentially, Mercurial itself could become the CLI tool code development centers around. Whether that is a good idea is up for debate. But, it can. And that says a lot about the flexibility of Mercurial.

Future potential of Mercurial

When you consider the previous three points, you arrive at a new one: Mercurial has a ton of future potential. The fact that extensions can evolve vanilla Mercurial into something that resembles Mercurial in name only is a testament to this.

When I sat down with a Mercurial core contributor, they reinforced this. To them, Mercurial is a core library with a limited set of user-facing commands forming the stable API. Since core features (like storage) are internal APIs (not public commands - like Git), this means they aren't bound to backwards compatibility and can refactor internals as needed and evolve over time without breaking the world. That is a terrific luxury.

An example of this future potential is changeset evolution. If you don't know what that is, you should because it's awesome. One of the things they figured out is how to propagate rebasing between clones!

Comparing to Git

Two years ago I would have said I would never opt to use Mercurial over Git. I cannot say that today.

I do believe Git still has the advantage over Mercurial in a few areas:

• Branch management. Mercurial branches are a non-starter for light-weigh work. Mercurial bookmarks are kinda-sorta like Git branches, but not quite. I really like aspects of Git branches. Hopefully changeset evolution will cover the remaining gaps and more.
• Patch conflict management. Git seems to do a better job of resolving patch conflicts. But, I think this is mostly due to Mercurial's patch queue extension not using the same merge code as built-in commands (this is a fixable problem).
• Developer mind share and GitHub. The GitHub ecosystem makes up for many of Git's shortcomings. Bitbucket isn't the same.

However, I believe Mercurial has the upper hand for:

• Command line friendliness. Git's command line syntax is notoriously awful and the concepts can be difficult to master.
• Extensibility. It's so easy to program custom workflows and commands with Mercurial. If you want to hack your version control system, Mercurial wins hands down. Where Mercurial embraces extensibility, I couldn't even find a page listing all the useful Git extensions!
• Open source culture. Every time I've popped into the Mercurial IRC channel I've had a good experience. I get a response quickly and without snark. Git by contrast, well, let's just say I'd rather be affiliated with the Mercurial crowd.
• Future potential. Git is a content addressable key-value store with a version control system bolted on top. Mercurial is designed to be a version control system. Furthermore, Mercurial's code base is much easier to hack on than Git's. While Git has largely maintained feature parity in the last few years, Mercurial has grown new features. I see Mercurial evolving faster than Git and in ways Git cannot.

It's worth calling out the major detractors for each.

I think Git's major weakness is its lack of extensibility and inability to evolve (at least currently). Git will need to grow a better extensibility model with better abstractions to compete with Mercurial on new features. Or, the Git community will need to be receptive to experimental features living in the core. All of this will require some major API breakage. Unfortunately, I see little evidence this will occur. I'm unable to find a vision document for the future of Git, a branch with major new features, or interesting threads on the mailing list. I tried to ask in their IRC channel and got crickets.

I think Mercurial's greatest weakness is lack of developer mindshare. Git and GitHub are where it's at. This is huge, especially for projects wanting collaboration.

Of all those points, I want to stress the extensibility and future potential of Mercurial. If hacking your tools to maximize potential and awesomeness is your game, Mercurial wins. End of debate. However, if you don't want to harness these advantages, then I think Git and Mercurial are mostly on equal footing. But given the rate of development in the Mercurial project and relative stagnation of Git (I can't name a major new Git feature in years), I wouldn't be surprised if Mercurial's feature set obviously overtakes Git's in the next year or two. Mind share will of course take longer and will likely depend on what hosting sites like GitHub and Bitbucket do (I wouldn't be surprised if GitHub rebranded as CodeHub or something some day). Time will tell.

Extending case study

I have removed the case study that appeared in the original article because as Mike Hommey observed in the comments, it wasn't a totally accurate comparison. I don't believe the case study significantly added much to the post, so I likely won't write a new one.

Conclusion

From where I started with Mercurial, I never thought I'd say this. But here it goes: I like Mercurial.

I started warming up when it became faster and more robust in recent versions in the last few years. When I learned about its flexibility and the fundamentals of the project and thus its future potential, I became a true fan.

It's easy to not like Mercurial if you are a new user coming from Git and are forced to use a new tool. But, once you take the time to properly configure it and appreciate it for what it is and what it can be, Mercurial is easy to like.

I think Mercurial and Git are both fine version control systems. I would happily use either one for a new project. If the social aspects of development (including encouraging new contributors) were important to me, I would likely select Git and GitHub. But, if I wanted something just for me or I was a large project looking for a system that scales and is flexible or was looking to the future, I'd go with Mercurial.

Mercurial is a rising star in the version control world. It's getting faster and better and enabling others to more easily innovate through powerful extensions. The future is bright for this tool.

USDailyVoice
Mozilla Offers Free Smartphone for Firefox App Developers – While Stocks Last
USDailyVoice
Mozilla Offers Free Smartphone for Firefox App Developers – While Stocks Last Mozilla is taking no prisoners when it comes to getting its Firefox OS off to a flying start, having just introduced a pretty tempting deal-sweetener for developers willing ...
Mozilla offers developers phones to write Firefox OS appsCNET
Mozilla offering free phones in hopes of bolstering Firefox OS app developmentEngadget
Mozilla Starts Doling Out Phones To Developers With Brilliant HTML5 App IdeasTechCrunch
PC Magazine -The Next Web -ZDNet
alle 31 nieuwsartikelen »

Old school add-ons were developed with a similar mindset, which is that creating new windows is ok, and using XUL this became an easy to-do common practice. The times have changed, and opening new windows is no longer considered acceptable practice, opening tabs is now the preferred user experience.

Now, Firefox has a huge cast of popular, restart addled, old school mannered add-ons, which is a problem. So how do we retrofit these geezers?

I see three parts that need to be addressed:

1. New XUL windows (windows created by the add-on)
2. XUL overlays (content added to windows created by Fx or another add-on)
3. Back-end logic

I plan to write more about all three topics later, because the real solutions require more words and work than the shortcuts will.

Shortcuts Chrome.manifest

Because of Bug 559306 we can now include the old school add-on’s chrome.manifest file in jetpacks. There are some limitations however, for more information on that see this page on the chrome.manifest in restartless add-ons. For instance, overlays will not be regestered, resource uris, components, and more. One can register a chrome uri however, with a skin and locale.

This means that add-ons which implement XUL windows can continue to use them as a Jetpack.

These windows should be redesigned however, but this is no longer a bar to entry, and the resdesign of these windows can be done in a separate step from the conversion to Jetpack.

Also, remember that any windows open which are associated to an add-on should be closed when the add-on unloads, if you do not do this then your add-on will not pass a full review on addons.mozilla.org.

Browser UI

Again, there are a few useful third party modules which handle most common use cases, and if they do not cover your use case then they should provide some direction how to implement them.

I’ve got a module in mind that should help with converting overlays, it’s a messy prototype right now though, so we’ll see how that goes..

Components

There are a few useful third party modules out already which handle things like registering custom uris (this includes about: uris, resource: uris, and whatever:), content policies, and in many cases there are better alternatives. For instance I’ve seen quite a few add-ons register components just in order to hear their ‘startup’ event, this is no longer necessary, with a Jetpack you can simply call require('self').loadReason in main.js.

We have come to build the most important thing in the world today, perhaps the most important thing ever. It connects us. It widens us. It deepens who we are. We don’t know what it is or what it will be in the future, but we do know it has made us better so far. Our dream is to enlarge it so that all people can join us and share the good in it while ameliorating the bad. This thing we are working on has no borders and – as far as we can see – no end. If everyone can join it, with equal access and no undue ownership, the world will be a much better place. That is why we are working here today.

~ Kevin Kelly / WIRED 21.05

If you haven’t heard about Firefox OS before, or would like to learn more about it, you should come to this month’s Mobile Monday Detroit. I’ll be presenting at the meeting about Mozilla’s motivations for Firefox OS, how we’re opening up mobile hardware, and roadmap for the future.

It has been estimated that in the next 10 years, five billion people will gain access to the internet. Many of these people will be accessing the internet using mobile connection exclusively.

One of the main goals of Firefox OS is to provide a device to people that brings with it the full web as compared to the limited subset of the web that is currently accessible on more basic feature phones. This also means providing web applications better access to hardware, so application developers can provide rich environments comparable to that of other mobile phone operating systems.

As we build these hardware APIs, we have been working very hard to standardize them and push for other browsers to adopt them. You can follow along with the progress of the WebAPI project by visiting our wiki. All of the FirefoxOS roadmaps, feature lists, etc can all be viewed online. This project really defines openness

Mobile Monday Detroit is hosted at Compuware’s headquarters in downtown Detroit, at One Campus Martius. The event will start at 5:30pm and run until 8pm. Food and drinks will be provided. Please RSVP (it’s free!) if you plan on attending so the organizers will have a good idea of how much food to order.

Randy Nunez from Ford will also provide information on a variety of additional open source mobile OS platforms that are catching the attention of the developer community.

Monday, May 13, 2013
5:30 PM to 8:00 PM
Compuware Building
One Campus Martius, Detroit, MI (map)

Tagged: detroit, firefox, firefoxos, mozilla, planet-mozilla, presentation

Many of the most popular add-ons have a common function, they block content. Adblock Plus blocks ads, NoScript blocks scripts, and Ghostry blocks tracking software which uses images, scripts and other means to do their business.

This is why I wrote a content-policy module for Mozilla’s Add-on SDK. The API is rough at the moment, and I plan to change that quite a bit. For the moment though we can take the No Google Analytics add-on as an example source here:

lib/main.js

const { ContentPolicy } = require('content-policy'); const GA_REGEX = /(.*\.)?google-analytics\.com$/i; const { URL } = require('sdk/url'); ContentPolicy({ shouldLoad: function({ location }) { // if the hist is google-analytics.com then block it if (URL(location).host.match(GA_REGEX)) return false; // returning false rejects the request before it starts return true; // returning true does not reject the request } });

I’ll improve the match later, but you can see how easy that is, and I promise I’ll make it easier.

T3
Mozilla offers developers phones to write Firefox OS apps
CNET
In an effort to ensure there will be good Firefox OS apps in the Firefox Marketplace, Mozilla is offering developer phones to programmers who have compelling ideas for software. In a blog post Thursday, Mozilla employee Havi Hoffman tried to drum up ...
Firefox OS devs offered free phones by MozillaITProPortal
Mozilla offers developers free Firefox OS handsets to build appsT3
Mozilla offers free Firefox OS phones to developers - SmartCompanySmartCompany.com.au
ZDNet -SlashGear -PCR-online.biz
alle 35 nieuwsartikelen »

Mozilla’s mission compels us to provide people with an Internet experience that puts them in control of their online lives and that treats them with respect. Respecting someone includes respecting their privacy. We aspire to a “no surprises” principle: the idea that when information is gathered about a person, it is done with their knowledge and is used in ways that benefit that person. People should be made aware of how information is collected and used. Each individual should also be able to decide whether the exchange of personal data for the services received in return feels fair. This can be challenging to achieve, especially when balanced against convenience and ease of use: people expect a fast, streamlined user experience without excessive prompts and confusing choices. But we are always striving toward this ideal.

Mozilla is an active participant in the ecosystem of today’s Web economics. Much of the content and information that people enjoy and benefit from is funded by digital marketing and sponsorship. This is a valid business model. We simply believe that when personal data is collected to deliver these services, the collection should be done respectfully and with the consent of the consumer. Commerce works best when users understand the transactions they engage in. The best long-term customer relationships are built on trust.

Mozilla aspires to enable personalization — the customization of ads, content, recommendations, offers and more — that doesn’t rely on the user being in the dark about who has access to that information, and with whom that information is shared. As a major Web browser provider and, now, OS developer, Mozilla’s role is to experiment and innovate toward that aspiration. As an open source project, where contributions are welcomed by all, we encourage all in the industry to help, by constructively proposing approaches and collaborating with us in the open.

Here are a just a few examples of the work Mozilla is doing to explore personalization with respect:

• Persona is an identity system for the Web. It gives people control over their Web logins. People choose what identity to present to a given service. In particular, people can keep their work, personal, and other facets of their lives distinct.
• Do Not Track allows you to tell a website that you would like to opt-out of third-party tracking for purposes including behavioral advertising. It lets users express how they would like information about themselves to be handled. It has many benefits. People who use Firefox must actively enable Do Not Track, making it very clear that the user has made an explicit choice Also, Do Not Track is independent of any particular technology, providing resilience in the face of technology evolution. We continue to work with a broad range of interested parties to see the Web adopt Do Not Track.
• Third party cookie policies are being evaluated to strike a better balance between personalized ads and the tracking of users across the Web without their consent. For example, an experimental version of Firefox allows cookies to be set by first parties and by third parties where Firefox has stored a cookie for the party’s domain, but to block by default third-party cookies whose domain is not known from Firefox’s cookie store. We’ve been evaluating that approach, as well as others, working with stakeholders from across the industry.

It should be possible to delight users (and yes, the right offer at the right time can be a delight), while treating them with respect. We continue to experiment with and evaluate new ways to put users in control of their Web experience and encourage you to join us in building toward this vision. We will share more updates soon.

The last six months have involved a lot more writing of code than the previous couple of years.

I’ve been tweeting little things I learn on a daily basis and thought I’d look back on this week.

format()

A reocurring problem with report writing is getting numbers formatted properly for the occassion. I discovered ‘format’ in Python this week:

print "{0:.2f}%".format(float(1)/3 * 100)

That prints out a float to 2 decimal places. I looked around and Dive Into Python has similar syntax, but without the format() function. So, the equivalent would be:

print "blah %.2f" % (float(1) / 3 * 100)

So, why use one over the other? A user on StackOverflow suggested that compatibility with 2.5 might drive a person to use ‘%’ over ‘format()’, but otherwise, the poster suggested that format() is the cleaner looking and more flexible choice.

set search_path = bixie

I’m working on a new schema for a project. We’re rolling out a prototype quickly, so we’re going to house it in our existing production database for now. To keep things easy to clean up, Laura suggested that we put things into a separate schema. For managing our database models, I’ve switched to using SQLAlchemy, and also alembic for migrations. This made it super easy to specify that I wanted all the Bixie related tables in their own schema:

class BixieCrash(DeclarativeBase): __table_args__ = {'schema': 'bixie'} __tablename__ = 'crashes'

And that was it.

Then, to avoid having to add ‘bixie.’ to all the table paths in test queries, I put this command into the tests:

cursor.execute(""" SET search_path TO bixie """)

I imagine there are some other ways to handle this. We’re not really using the ORM for anything other than schema loading, so I’ll probably add that to our connection initialization code for the new app. Then developers can write their queries as without any concerns about being in the correct schema.

And I’ll glow just a little bit about deploying alembic on stage!

set colorcolumn=80

I’ve been trying to write prettier Python. Today’s micro-effort was figuring out how display a vertical line to tell me when I exceed the 80 character width. The proper command to add to .vimrc is:

:set colorcolumn=80

Which looks something like:

Why Mozilla's innovation chief jumped to the world of patents
InfoWorld (blog)
Todd Simpson, formerly chief of innovation at Mozilla, has made an intriguing job change. From working at the community-driven organization on open source projects, Simpson has joined InterDigital, a company commonly accused of being a patent troll.

This week I’ve been:

• Taking a day off. It was Bank Holiday on Monday – a national holiday in the UK. I still however spent 4pm-5pm… <drumroll>
• Hosting the weekly Web Literacy standard call. We motored through our first pass of defining the skills under the competencies in the ‘Connecting’ strand.
• Writing a post for Week 1 of the Mozilla #teachtheweb MOOC: How transferable are coding skills to other domains? Why is learning a little code important?
• Responding to enquiries by people and organisations about integrating with the OBI.
• Travelling to and from London to meet with Lord Jim Knight and STiR education about using Open Badges for teacher education in India.
• Enjoying a conversation over lunch London with the ever-enthusiastic Eugenie Teasley from Spark + Mettle.
• Collating questions about Open Badges and then answering them in this blog post.
• Suffering from a migraine on Thursday. I couldn’t see much due to the aura so I called it a day about 10:30am. I lay down and listened to podcasts. The Moral Maze episode on The Ring of Gyges was fascinating.
• Travelling to BBC North in Salford to deliver a session on Open Badges. It went pretty well, but I felt like I wasn’t getting my words out properly or explaining things as well as I usually do. It’s often an issue post-migraine. Slides here.

Next week, after five straight weeks of travelling and hotels, I’m home for the entire week. Woohoo! The week after I’m in Toronto for the Mozilla All-Hands meeting, so plenty to psych myself up for…

Facebook, Mozilla and the MacArthur Foundation Team Up for a Hackathon to ...
Betabeat
Hosted in conjunction with the MacArthur Foundation, Facebook, Mozilla and the Family Online Safety Institute, the event focused on building a “more equitable, social, and participatory internet.” Teams showed up at the space and were treated to a hot ...

en meer »

Summary

I just finished up an overhaul of ElasticUtils and then an overhaul of the search infrastructure for support.mozilla.org. During that period of time, I thought about extending the ElasticUtils documentation to include things I discovered while working on these projects. Then I decided that this information is temporal---it's probably good now, but might not be in a year. Maintaining it in the ElasticUtils docs seemed like more work than it was worth.

Thus I decided to write a series of blog posts.

This one covers indexing. Later ones will cover mappings, searching and other things.

It's also long, rambling and contains code. The rest is after the break.

read more after the break...

[Comments]

The Next Web
Mozilla Offering Free Phones to Firefox OS Developers
PC Magazine
Mozilla is on the hunt for developers to build applications for its upcoming Firefox mobile operating system, and to sweeten the deal, the company is now throwing in a free Firefox OS Developer Preview device. Those with a Firefox OS app they'd like to ...
Mozilla Starts Doling Out Phones To Developers With Brilliant HTML5 App IdeasTechCrunch
Mozilla offering free phones in hopes of bolstering Firefox OS app developmentEngadget
Mozilla Courts App Developers to Firefox OS With Free Phones - The Next WebThe Next Web
Silicon Valley Business Journal -ZDNet -The Full Signal
alle 23 nieuwsartikelen »

There are two exciting keynotes planned for Releng 2013

John O'Duinn, Director of Release Engineering at Mozilla will kick off the workshop with his keynote Release Engineering as a Force Multiplier.  The build and release process used to be a pain point at Mozilla, but now makes the company and community more productive as a whole.  John will describe how the team added support for project branches to allow concurrent development, rethought continuous integration and increased capacity by moving to a hybrid-cloud build infrastructure. These changes improved several aspects of the business, including switching to a rapid release model and reducing turnaround time on a release from weeks to hours.  As a result,  Mozilla improved its abilities against much bigger and better funded competitors in the marketplace while also allowing them to enter new markets and help ensure its long-term success.


Roman Scheiter, Engineering Services Director at LinkedIn, will present the afternoon keynote entitled Against All Odds – Completely Overhauling Linkedin's Release Process.  This session will cover the evolution of LinkedIn’s release process from its earliest days to the point where the rapidly growing engineering team necessitated a radical shift. This shift, an executive sponsored effort to address technical debt and introduce new thinking to boost engineering efficiency allows six hundred developers to release thousands of changes per week without compromising quality.  As part of this undertaking, LinkedIn learned many best practices, developed tools and custom infrastructure, and lived through the internal cultural changes needed to make this independent release process work.   Roman will detail the evolution and results of this shift so you can learn directly from LinkedIn's pain.
  In addition to these fantastic keynotes, we also have talks from release engineers and researchers from Netflix, Google,  Microsoft, Gnome, Red Hat, IBM, several universities and more!  We'll also have a panel at the end of the day to discuss the future of release engineering.

Check out the full program on the Releng 2013 site.  To register for the conference, which is managed as part of the larger ICSE conference, you can follow this link and choose the one-day-workshop.  See you in San Francisco on May 20!

Week 3 of #teachtheweb is right around the corner, and I thought it might be nice to do a quick shareout of the planning and running of the MOOC. Kudos! Before I say another word, I have to give my partner in crime a gigantic love bomb. The word “collaboration” only begins to describe the epic brain connection Michelle and I have seemingly developed. Additionally, as Michelle noted, the entire Webmaker Mentor team has been massively supportive and absolutely integral to getting Mozilla's first MOOC off the ground. High-fives all around! Conspiring We've been having calls with wonderful community members who signed up to help create the #teachtheweb experience. We've been calling them the Super Mentor Calls. The Super Mentor Kick-off call on April 19 had 41 attendees from 17 different countries. They are designers, developers, educators, makers, architects, librarians, youth workers, entrepreneurs, teens and more, who answered our call to be super mentors in #teachtheweb. This call was used to help the Super Mentors understand what we were asking them to do throughout the 9-week course. This blog post explains the job. We also used the opportunity to explain the concept of a cMOOC and to thank everyone for signing up before they even knew what they signed up for. Follow our Twitter List of Super Mentors The next week, April 25, we took some time to celebrate Super Mentor makes after many created introductions using Webmaker tools. We gave each other virtual high fives for being engaging, thoughtful digital citizens and shared a few moments of excitement centered around the fact that the Webmaker Community is full of intelligent human beings looking to change the world. Next, we explained our launch strategy with a “Heads up! It's going to get busy!” and proposed the formation of Study Groups. We created a lightweight google doc and asked if anyone would be interested in running a smaller study group during the experience. Many were, and the Google Doc started filling up with ideas for Study Groups based on interest, language and/or geography. We also talked about the content creation procedure and came up with a plan to braindump into Etherpads, filter and curate. We want to make sure any one who wants to contribute to the content of #teachtheweb can. If you want to help plan, see the planning page! We talked about the connection between #teachtheweb and #MakerParty (#teachtheweb is kind of like Party Prep), and the Super Mentors began to volunteer to spread the word about both initiatives in their local areas as well as online. Finally, Super Mentors volunteered to help moderate the various #teachtheweb channels during the May 2nd Live Session and #teachtheweb Kick-off. On the #teachtheweb launch date, May 2nd, we had a relatively quick call with Super Mentors to celebrate the G+ Community's growth and talk about the Live Session. Super Mentors signed up to participate via video, monitor channels, serve as tech support and help out on IRC. The session went, I heard, nicely. You can watch the video here. Yesterday, May 9th, we spent a little time talking about how to get participants more involved and how to be better at sharing with each other and the larger community. We decided to try to give each other weekly report backs on how Study Groups were doing in the following Super Mentor calls. Content Creation Each week a post is released in the Planning section of #teachtheweb, which invites any and everyone to contribute their thoughts to a particular topic. The Super Mentors get extra reminders, but the content creation process is completely open. If you're interested in contributing your thoughts to a particular topic, check the planning page for new topic etherpads each Monday. Monday is also the day that we've been distilling these Etherpads into a digestible blogpost with extra readings, resources and tasks. The filtering and curation of everyone's braindump is massively interesting but quite difficult. The posts need to be relatively short to keep people engaged. We would rather that people spend their allotted MOOC time completing the weekly Make Projects and reflecting on their own work, instead of focusing too heavily on truncated descriptions of complex topics. We believe in Making as Learning, so we want to spend as much time as possible making, sharing, remixing, iterating and making some more. Tuesday's we post new topics to the #teachtheweb site. We also do shareouts in the Weekly Webmaker Community call. Thursday's are the days we do live sessions (only 3 throughout the 9 weeks, one on May 2nd, May 23rd and June 13th) and Twitter Chats. Which leads me to the visualization piece of this post. This morning, I really just wanted to MAKE stuff. So I started fishing through the Twitter archive Jeannie Crowley created for #teachtheweb. Then I got a data bug and started looking at other numbers. I made two things: A Visualization of Relationships between Words used in #teachtheweb Tweets [caption id="attachment_1916" align="aligncenter" width="800"] Click the image to play with this interactive visualization thingie[/caption] A Slightly Interactive Infographic [iframe src="//infogr.am/teachtheweb-27148" width="550" height="2161" scrolling="no" frameborder="0" style="border:none;"] teachtheweb | Infographics MOOC Attrition One of the things that has been bugging me is the rumors of MOOC attrition rates. I've read percentages from 85% to 98% in the last couple of months, and I was worried that the participants in #teachtheweb will soon be dropping out and the conversation will come to a standing halt. Up until a few days ago, I was basically waiting for the ball to drop. Then I read this post from a mathematician at Stanford and decided to just stop worrying about it. It's easy to sign up for things. You just put in one of your many email addresses and that's that. It's easy to begin the journey into a specific community. You just use the hashtag, comment on people's posts, follow some people and start trying to know people through their digital representations and artifacts. But it's not easy to remain an active member of a community. Being active takes time, perseverance, patience, understanding, collaboration, connection, mentorship, and a whole mess of other things. We all participate in multiple communities, and it's natural that one community or another will take precedence on a given day. I just hope that the those of you who have found the Webmaker Mentor Community through #teachtheweb decide to give this community precedence from time to time. We're teaching the world the Web – and we definitely need your help.