Mozilla Nederland Logo De Nederlandse Mozilla gemeenschap

Frédéric Harper: YulDev, connecting with other developers

Mozilla planet - ma, 21/04/2014 - 17:46



Montreal’s Developers, would you like to have more occasions to network with your peers, no matter which technology they are using? If it’s the case, YulDev is for you: a new monthly meetup where you can network with developers, and talk about whatever you like. The simplicity of just discussing code (or anything else) with a drink (juice, coffee, beer, glass of wine…) and other developers.

We are lucky in Montreal: there are many user groups for developers! Most of them have one point in common: they often focus on one technology or a group of related ones, and the primary goal is to learn from a speaker. Like you, I have much interest when it comes to technology, but I also have limited time in a week. Therefore, I cannot attends all the user groups or events I would like too, and I feel I’m missing opportunity to meet new amazing developers. With this in mind, I created YulDev, a Montreal style (French & English) user group or I should say, networking group as there will be no presentation (maybe greetings from your host in the beginning, but nothing else). In a 6@8 formula, the goal of this monthly event is to mingle, talk with people you know, and of course, meet new one. You never know what will happen next: new job, new friend, possible customer, a startup idea, interest in a new language, discovering a new user group you did not know about, and of course, an amazing evening with great developers.

So don’t wait, join the group, share about it with your co-workers, and RSVP for our first meetup in May. Don’t underestimate the power of networking in our industry!

P.S.: If you are the lead of a group for developers in Montreal or a media, and would like to promote YulDev, please let me know. If you are a company, and would like to sponsor the group, let’s talk about it (more information soon about our needs).

YulDev, connecting with other developers is a post on Out of Comfort Zone from Frédéric Harper

Related posts:

  1. User groups: learn, meet and share Please note that this blog post talk about Make Web...
  2. So you want to find a co-founder for your startup idea in Montreal? I’ve got asked quite often about the startup industry in...
  3. Empower Mobile Web Developers with JavaScript & WebAPI at PragueJS HTML5 is a giant step in the right direction: it...
Categorieën: Mozilla-nl planet

Joel Maher: Hi Vikas Mishra, welcome to the Mozilla community!

Mozilla planet - ma, 21/04/2014 - 14:38

I remember right before the winter break where I was off for a couple of weeks to end the year, A new person showed up and started working on some of my bugs. This was Vikas and he was eager and motivated to do a lot of great things.  Fast forward to today, and I still chat with Vikas weekly in irc.  When he gets a break from school and other activities of interest, he will be hunting for bugs to fix and usually knocking them out 3 or 4 at a time. In fact, I was surprised when I did a query on bugzilla, and on github to see that he is involved in a variety of projects at Mozilla such as Phonebook, Marionette, Talos, and test automation.

I wanted to learn more about Vikas, so I asked him some questions

Tell me about where you live?

Currently I live in Goa, India which is famous for its beaches and attracts many tourists from both India as well as foreign nationals. The best thing about this place is my campus which feels like a home away from home now. I like this place for its beautiful weather, its beaches and ever friendly nature of people living here. This place has brought  a lot of changes in my personality and has given me a chance to make some new friends who are always ready to help.

Tell me about your school?

I am a first year undergraduate student at Birla Institute of Technology and Science Pilani, Goa Campus (popularly known as BITS Pilani Goa) pursuing Msc.(Hons) Economics. I am enrolled in a dual degree scheme offered by my college where in I get an option to take a B.E degree depending on my first year’s performance and I hope to get a C.S major. My favorite subject so far has been Computer Science as I’ve always been fascinated towards computers and love to code

How did you get involved with Mozilla?

My first interaction with the Mozilla community was when I started using firefox few years back. Last December I decided to start contributing to some open source organizations and searched for organizations to start with and decided to go with Mozilla. I started with Mozilla since its a very large community so there’s always lots of help available. My experience with Mozilla community so far has been absolutely great, I had no idea how the open source community works and was afraid to ask silly questions as I thought people wont have time to answer those questions. I remember when I was assigned my first bug and Joel Maher was my mentor, while setting the local environment I kept on getting errors and used to pastebin those to him and it took me hours to set it up but he was totally cool with it even though I  myself was annoyed with those ever lasting errors. Even now I get stuck at some places but he’s always there to help me. Besides him there are other members too who have helped a lot and are always ready to help if required. My experience so far has been brilliant and am looking forward to learning new things and meeting some great people in the future as well.

What hobbies and activities do you enjoy doing?

Nowadays I spend most of my time coding and learning new stuff. I love the concept of open source software and love to interact with the community and gain valuable experience. Besides coding I enjoy playing football, cricket, and am a complete movie buff. I also love to hang out with friends and spend time with them.

Where do you see yourself in 5 years?

Down the lane in 5 years I see myself as a software engineer working for Mozilla (preferably in the Ateam) solving problems and developing new tools.

What advice would you give someone?

Although I don’t see myself as someone who can advise about life but If someone asked me I’ll advise him/her to enjoy life to the fullest and do whatever he/she loves to do no matter what others expect them to do and if they are related to the software industry obviously I’ll advise them to contribute to the open source community :)


I have enjoyed watching Vikas learn his way around Mozilla.  If you have worked with him, you probably already know why I have enjoyed my interactions with him, if you haven’t had the chance to work with him, say hi in irc, his nick is :mishravikas.

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Dennis v0.3.11 released! Fixes and Python 3 support

Mozilla planet - ma, 21/04/2014 - 14:00
What is it?

Dennis is a Python command line utility (and library) for working with localization. It includes:

  • a linter for finding problems in strings in .po files like invalid Python variable syntax which leads to exceptions
  • a statuser for seeing the high-level translation/error status of your .po files
  • a translator for strings in your .po files to make development easier
v0.3.11 released!

v0.3.11 adds Python 3 support (there might be problems, but it's working for me) and adds error detection for the case where there's a } but no {.

Definitely worth updating!

8 out of 11 people who have heard of Dennis and continue to ignore its baby mews of wonderfulness also have a severe allergy to rainbows and kittens.

Categorieën: Mozilla-nl planet

HITBSecConf/Haxpo 2014

Mozilla-NL nieuws - ma, 21/04/2014 - 13:06
Date: woensdag, 28 mei, 2014 - 08:00 tot vrijdag, 30 mei, 2014 - 17:00Wie: OpenbaarTags: ExternMozillabooth

Imagine an area dedicated to hackerspaces;
makers with 3D printers, laser cutters and other fabrication goodies coupled with TOOOL‘s Lock Picking Village, HITB and Mozilla’s HackWEEKDAY developer hackathon, a hackerspaces challenge featuring LEGO Mindstorms EV3, our Capture the Flag ‘live hacking’ competition and topped off by a 3 day IT exhibition featuring Microsoft and Google as the main anchors.

Categorieën: Mozilla-nl planet

Want Marriage Equality? Follow the Obama/Biden Model, Not the Mozilla Model. - Slate Magazine (blog)

Nieuws verzameld via Google - zo, 20/04/2014 - 17:06

Slate Magazine (blog)

Want Marriage Equality? Follow the Obama/Biden Model, Not the Mozilla Model.
Slate Magazine (blog)
In the days since Brendan Eich quit Mozilla, supporters of same-sex marriage have debated the wisdom of using pressure to punish their opponents. Eich, an executive with no known record of antigay bias in the workplace, was forced out for having ...

en meer »
Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 2: control flow

Mozilla planet - zo, 20/04/2014 - 10:45
IfThe `if` statement is pretty much the same in Rust as C++. One difference is that the braces are mandatory, but brackets around the expression being tested are not. Another is that `if` is an expression, so you can use it the same way as the ternary `?` operator in C++ (remember from last time that if the last expression in a block is not terminated by a semi-colon, then it becomes the value of the block). There is no ternary `?` in Rust. So, the following two functions do the same thing:
fn foo(x: int) -> &'static str {
    let mut result: &'static str;
    if x < 10 {
        result = "less than 10";
    } else {
        result = "10 or more";
    return result;

fn bar(x: int) -> &'static str {
    if x < 10 {
        "less than 10"
    } else {
        "10 or more"
}The first is a fairly literal translation of what you might write in C++. The second is in better Rust style.

You can also write `let x = if ...`, etc.

LoopsRust has while loops, again just like C++:fn main() {
    let mut x = 10;
    while x > 0 {
        println!("Current value: {}", x);
        x -= 1;
}There is no do...while loop in Rust, but we do have the `loop` statement which just loops forever:fn main() {
    loop {
        println!("Just looping");   
}Rust has `break` and `continue` just like C++.For loopsRust also has `for` loops, but these are a bit different. Lets say you have a vector of ints and you want to print them all (we'll cover vectors/arrays, iterators, and generics in more detail in the future. For now, know that a `Vec<T>` is a sequence of `T`s and `iter()` returns an iterator from anything you might reasonably want to iterate over). A simple `for` loop would look like:fn print_all(all: Vec<int>) {
    for a in all.iter() {
        println!("{}", a);
}If we want to index over the indices of `all` (a bit more like a standard C++ for loop over an array), you could dofn print_all(all: Vec<int>) {
    for i in range(0, all.len()) {
        println!("{}: {}", i, all.get(i));
}Hopefully, it is obvious what the `range` and `len` functions do. Switch/MatchRust has a match expression which is similar to a C++ switch statement, but much more powerful. This simple version should look pretty familiar:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        y => println!("x is something else {}", y),
}There are some syntactic differences - we use `=>` to go from the matched value to the expression to execute, and the match arms are separated by `,` (that last `,` is optional). There are also some semantic differences which are not so obvious: the matched patterns must be exhaustive, that is all possible values of the matched expression (`x` in the above example) must be covered. Try removing the `y => ...` line and see what happens; that is because we only have matches for 0, 1, and 10 and obviously there are lots of other ints which don't get matched. In that last arm, `y` is bound to the value being matched (`x` in this case). We could also write:fn print_some(x: int) {
    match x {
        x => println!("x is something else {}", x)
}Here the `x` in the match arm introduces a new variable which hides the argument `x`, just like declaring a variable in an inner scope.

If we don't want to name the variable, we can use `_` for an unnamed variable, which is like having a wildcard match. If we don't want to do anything, we can provide an empty branch:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        _ => {}
}Another semantic difference is that there is no fall through from one arm to the next.

We'll see in later posts that match is extremely powerful. For now I want to introduce just a couple more features - the 'or' operator for values and `if` clauses on arms. Hopefully an example is self-explanatory:fn print_some_more(x: int) {
    match x {
        0 | 1 | 10 => println!("x is one of zero, one, or ten"),
        y if y < 20 => println!("x is less than 20, but not zero, one, or ten"),
        y if y == 200 => println!("x is 200 (but this is not very stylish)"),
        _ => {}
}Just like `if` expressions, `match` statements are actually expressions so we could re-write the last example as:fn print_some_more(x: int) {
    let msg = match x {
        0 | 1 | 10 => "one of zero, one, or ten",
        y if y < 20 => "less than 20, but not zero, one, or ten",
        y if y == 200 => "200 (but this is not very stylish)",
        _ => "something else"

    println!("x is {}", msg);
}Note the semi-colon after the closing brace, that is because the `let` statement is a statement and must take the form `let msg = ...;`. We fill the rhs with a match expression (which doesn't usually need a semi-colon), but the `let` statement does. This catches me out all the time.

Motivation: Rust match statements avoid the common bugs with C++ switch statements - you can't forget a `break` and unintentionally fall through; if you add a case to an enum (more later on) the compiler will make sure it is covered by your `match` statement.Method callFinally, just a quick note that methods exist in Rust, similarly to C++. They are always called via the `.` operator (no `->`, more on this in another post). We saw a few examples above (`len`, `iter`). We'll go into more detail in the future about how they are defined and called. Most assumptions you might make from C++ or Java are probably correct.
Categorieën: Mozilla-nl planet

Rizky Ariestiyansyah: Tnotify, a Terminal Notification

Mozilla planet - zo, 20/04/2014 - 05:42
Hello guys, this is short post to tell you about tnotify the easiest, most attractive way to fire off notifications from your terminal. This application is available on ruby gem repository, you know why...
Categorieën: Mozilla-nl planet

Gervase Markham: 10 Year Blogaversary

Mozilla planet - za, 19/04/2014 - 21:12

10 years ago today, I started blogging.

At the time, I thought I was rather late to the blogging party. In hindsight, it seems not. Since then, through one change of host (thanks, Mozillazine!), there have been 1,463 posts (including this one), and 11,486 comments. Huge thanks to everyone who’s read and/or commented (well, if you commented without reading, not so much) in the last 10 years. It’s uncertain whether I or the blog will last another 10 (the Lord is in control of that) but here’s to however long it is!

Categorieën: Mozilla-nl planet

Sylvestre Ledru: Firefox 29 beta 8 to beta 9

Mozilla planet - za, 19/04/2014 - 18:59

For the last beta for Desktop, this beta is smaller than the previous. This beta mostly fixes the remaining critical bugs including a critical Netflix bug with Silverlight. Some search configuration bugs with Bing and Yahoo have been fixed.

  • 34 changesets
  • 56 files changed
  • 490 insertions
  • 270 deletions

ExtensionOccurrences cpp16 h10 js8 html8 xml3 jsm2 in2 css2 xul1 sjs1 nsi1 ini1 idl1

ModuleOccurrences content13 browser10 gfx7 js5 widget4 extensions4 toolkit3 security3 mobile3 xpcom2 netwerk1 ipc1

List of changesets:

Tim TaubertBug 966843 - Fix intermittent browser_615394-SSWindowState_events.js hangs. r=smacleod, a=test-only - 7938ad1529f9 Jeff GilbertBug 892990 - Cap waiting time for wait-for-composite in WebGL reftests. r=bjacob, a=test-only - a27d9f49afac Matt WoodrowBug 988309 - Add nsRenderingContext constructor for a DrawTarget. r=roc, a=sledru - 843dc71f729b Matt WoodrowBug 991767 - Use Moz2D for printing surfaces. r=roc, a=sledru - 55422890fb8f Nicholas HurleyBug 994344 - Prevent access of null mDB in seer. r=mcmanus, a=sledru - e24aafe4dffd Nathan FroydBug 993546 - Refactor malloc-wrapping memory reporter implementations. r=njn, a=abillings, ba=noidlchanges - c8f1a4f5ca4d Mike ConleyBug 996186 - Customize mode briefly makes titlebar transparent during transition. r=Gijs, a=sylvestre - caf2147c04f4 Gijs KruitboschBug 987792 - increase panel buttons' labels' clip rect height, r=jaws, a=sylvestre - 23311c5022ea Mike ConleyBug 996148 - With tabs in titlebar disabled, the private browsing mask can be incorrectly positioned in certain modes. r=MattN. a=gavin. - 5a2fd00c18e0 Richard NewmanBug 941744 - Remove Send Tab intent filter from RELEASE_BUILDs. r=nalexander, a=sylvestre - b30d5dfe0421 Dan GlastonburyBug 966630 - Clamp level to TexImage operations to [0..31]. r=jgilbert, a=abillings - 17432cc5074d Jan de MooijBug 995607 - Fix an AutoDebugModeInvalidation issue. r=shu, a=abillings - 838a0ac967ae Marty RosenbergBug 982398 - Make sure a script isn't lazy before calling it. r=jandem, a=sledru - d5a00d84b8d6 Mike ConnorBug 958883 - Use HTTPS for Yahoo searches, part 1. r=gavin, a=sledru - c5d91a0d3a2e Mike ConnorBug 958883 - Use HTTPS for Yahoo searches, part 2. r=mfinkle, a=sledru - 38f6b630f2cd Mike ConnorBug 984530 - Bing search tags are not working properly. r=mfinkle, a=sledru - 148684fea6d4 Mike ConnorBug 983723 - Yahoo search tags are not working properly. r=mfinkle, a=sledru - 4873bad57984 Sean StanglBug 856796 - Attempt detection of YARR bug. r=till, a=sledru - 51375c4deaf6 Matt WoodrowBug 995065 - Backout Bug 947227 on the release branches. r=jgilbert, a=sledru - cea0324a3ac6 Robert StrongBug 996960 - Add new RTL languages to locales.nsi - Uyghur ug and Urdu ur. r=ehsan, a=sledru - 92cae49290ae Camilo VieccoBug 987816 - verifying with certificateUsageVerifyCA always return failure. r=dkeeler a=lsblakk - b192379d4d65 Masayuki NakanoBug 964718 Don't dispatch DOM event if internal event doesn't need that. Otherwise, implement Duplicate() method r=smaug, a=sylvestre - aaf5030cbf98 Olli PettayBug 957666 - Send back a huge retry reconnection time in delayedServerEvents.sjs. r=ehsan, a=test-only - 3051963e5ec3 Nicolas B. PierronBug 992968. r=efaust, a=sledru - df4f53346f73 Tim TaubertBug 947570 - Disable browser_597071.js until rewritten for Marionette. r=smacleod, a=test-only - 85e9ba2c9371 Patrick BrossetBug 993190 - Use the outline highlighter on fennec. r=miker, a=sledru - ddbb75065940 Mike ConnorBug 997179 - Bing is not present in default search engines. r=mfinkle, a=sledru - bd52a0b3dc58 Tim TaubertBug 824021 - Don't clear set of windows to resurrect on write when receiving messages. r=yoric, a=test-only - 5f78c1ba85e3 Ralph GilesBug 995289 - Use fmod to wrap custom waveform phase. r=padenot a=sledru - 3b65e1a1c52a Monica ChewBug 997759: Prefs for phishing and malware tables are comma-sep lists (r=gcp,ba=sledru) - 034a63535df0 Sebastian HengstBug 997625 - Sync panel: Checkbox for syncing passwords enabled (not disabled) while sync credentials need reauth r=ttaubert a=sylvestre - 0add478cf3b4 Bobby HolleyBug 994335 - Null-check aProtoDoc in nsXULPrototypeScript::Serialize. r=smaug, a=sledru - 7f0030f9aac0 Matthew NoorenbergheBug 988156 - Backout fd0d0f6002dc (Bug 846566) for causing fullscreen videos on Netflix to appear black. r=smichaud a=sylvestre - 9ce31b9cd02d Tim TaubertBug 996159 - Fix sync config section on Windows with 125% DPI. r=gavin a=sylvestre - bd6fdc0dcac0

r= means reviewed by
a= means uplift approved by

Previous changelogs:

Original post blogged on b2evolution.

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - an intermission - why Rust

Mozilla planet - za, 19/04/2014 - 00:54
I realise that in terms of learning Rust, I had jumped straight to the 'how' and skipped the 'why'. I guess I am in enough of a Rust bubble that I can't imagine why you wouldn't want to learn it. So, I will make a bit more of an effort to explain why things are how they are. Here I will try to give a bit of an overview/motivation.

If you are using C or C++, it is probably because you have to - either you need low-level access to the system, or need every last drop of performance, or both. Rust aims to do offer the same level of abstraction around memory, the same performance, but be safer and make you more productive.

Concretely, there are many languages out there that you might prefer to use to C++: Java, Scala, Haskell, Python, and so forth, but you can't because either the level of abstraction is too high - you don't get direct access to memory, you are forced to use garbage collection, etc. - or there are performance issues - either performance is unpredictable or its simply not fast enough. Rust does not force you to use garbage collection, and as in C++, you get raw pointers to memory to play with. Rust subscribes to the 'pay for what you use' philosophy of C++. If you don't use a feature, then you don't pay any performance overhead for its existence. Furthermore, all language features in Rust have predictable (and usually small) cost.

Whilst these constraints make Rust a (rare) viable alternative to C++, Rust also has benefits: it is memory safe - Rust's type system ensures that you don't get the kind of memory errors which are common in C++ - memory leaks, accessing un-initialised memory, dangling pointers - all are impossible in Rust. Furthermore, whenever other constraints allow, Rust strives to prevent other safety issues too - for example, all array indexing is bounds checked (of course, if you want to avoid the cost, you can (at the expense of safety) - Rust allows you to do this in unsafe blocks, along with many other unsafe things. Crucially, Rust ensures that unsafety in unsafe blocks stays in unsafe blocks and can't affect the rest of your program). Finally, Rust takes many concepts from modern programming languages and introduces them to the systems language space. Hopefully, that makes programming in Rust more productive, efficient, and enjoyable.

I would like to motivate some of the language features from part 1. Local type inference is convenient and useful without sacrificing safety or performance (it's even in modern versions of C++ now). A minor convenience is that language items are consistently denoted by keyword (`fn`, `let`, etc.), this makes scanning by eye or by tools easier, in general the syntax of Rust is simpler and more consistent than C++. The `println!` macro is safer than printf - the number of arguments is statically checked against the number of 'holes' in the string and the arguments are type checked. This means you can't make the printf mistakes of printing memory as if it had a different type or addressing memory further down the stack by mistake. These are fairly minor things, but I hope they illustrate the philosophy behind the design of Rust.
Categorieën: Mozilla-nl planet

Peter Bengtsson: Grymt - because I didn't invent Grunt here

Mozilla planet - vr, 18/04/2014 - 23:58

grymt is a python tool that takes a directory full of .html, .css and .js and prepares the html for optimial production use.

For a teaser:

  1. Look at the "input"

  2. Look at the "output" (Note! You have to right-click and view source)

So why did I write my own tool and not use Grunt?!

Glad you asked! The reason is simple: I couldn't get Grunt to work.

Grunt is a framework. It's a place where you say which "recipes" to execute and how. It's effectively a common config framework. Like make.
However, I tried to set up a bunch of recipes in my Gruntfile.js and most of them worked well individually but it was a hellish nightmare to get it all to work together just the way I want it.

For example, the grunt-contrib-uglify is fine for doing the minification but it doesn't work with concatenation and it doesn't deal with taking one input file and outputting to a different file.
Basically, I spent two evenings getting things to work but I could never get exactly what I wanted. So I wrote my own and because I'm quite familiar with this kind of stuff, I did it in Python. Not because it's better than Node but just because I had it near by and was able to quicker build something.

So what sweet features do you get out of grymt?
  1. You can easily make an output file have a hash in the filename. E.g. vendor-$hash.min.js becomes vendor-64f7425.min.js and thus the filename is always unique but doesn't change in between deployments unless you change the files.

  2. It automatically notices which files already have been minified. E.g. no need to minify somelib.min.js but do minify otherlib.js.

  3. You can put $git_revision anywhere in your HTML and this gets expanded automatically. For example, view the source of and look at the first 20 lines.

  4. Images inside CSS get rewritten to have unique names (based on files' modified time) so they can be far-future cached aggresively too.

  5. You never have to write down any lists of file names in soome Gruntfile.js equivalent file

  6. It copies ALL files from a source directory. This is important in case you have something like this inside your javascript code: $('<img>').attr('src', 'picture.jpg') for example.

  7. You can chose to inline all the minified and concatenated CSS or javascript. Inlining CSS is neat for single page apps where you have a majority of primed cache hits. Instead of one .html and one .css you get just one .html and the amount of bytes is the same. Not having to do another HTTP request can save a lot of time on web performance.

  8. The generated (aka. "dist" directory) contains everything you need. It does not refer back to the source directory in any way. This means you can set up your apache/nginx to point directly at the root of your "dist" directory.

So what's the catch?
  1. It's not Grunt. It's not a framework. It does only what it does and if you want it to do more you have to work on grymt itself.

  2. The files you want to analyze, process and output all have to be in a sub directory.
    Look at how I've laid out the files here in this project for example. ALL files that you need is all in one sub-directory called app. So, to run grymt I simply run: grymt app.

  3. The HTML files you throw into it have to be plain HTML files. No templates for server-side code.

How do you use it? pip install grymt

Then you need a directory it can process, e.g ./client/ (assumed to contain a .html file(s)).

grymt ./client

For more options, check out

grymt --help What's in the future of grymt?

If people like it and want to add features, I'm more than happy to accept pull requests. Some future potential feature work:

  • I haven't needed it immediately, yet, myself, but it would be nice to add things like coffeescript, less, sass etc into pre-processing hooks.

  • It would be easy to automatically generate and insert a reference to a appcache manifest. Since every file used and mentioned is noticed, we could very accurately generate an appcache file that is less prone to human error.

  • Spitting out some stats about number bytes saved and number of files reduced.

Categorieën: Mozilla-nl planet

Justin Dolske: PoV Firefox

Mozilla planet - vr, 18/04/2014 - 22:44

A nice project by Antonio Ospite:

It’s a device made of a programmable LED strip attached to a jump rope, which can be used with high exposure photography for Light Painting. The principle behind it is the same as those cool POV (Persistence of vision) displays.

Very cool!

(via Hack A Day)

Categorieën: Mozilla-nl planet

Christian Heilmann: Web Components and you – dangers to avoid

Mozilla planet - vr, 18/04/2014 - 16:54

Legos by C Slack

Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

Web Components are a natural evolution of HTML. HTML is too basic to allow us to create App interfaces. When we defined HTML5 we missed the opportunity to create semantic widgets existing in other UI libraries. Instead of looking at the class names people used in HTML, it might have been more prudent to look at what other RIA environments did. We limited the scope of new elements to what people already hacked together using JS and the DOM. Instead we should have aimed for parity with richer environments or desktop apps. But hey, hindsight is easy.

What I am more worried about right now is that there is a high chance that we could mess up Web Components. It is important for every web developer to speak up now and talk to the people who build browsers. We need to make this happen in a way our end users benefit from Web Components the best. We need to ensure that we focus our excitement on the long-term goal of Web Components. Not on how to use them right now when the platforms they run on aren’t quite ready yet.

What are the chances to mess up? There are a few. From what I gathered at several events and from various talks I see the following dangers:

  • One browser solutions
  • Dependency on filler libraries
  • Creating inaccessible solutions
  • Hiding complex and inadequate solutions behind an element
  • Repeating the “just another plugin doing $x” mistakes

One browser solutions

This should be pretty obvious: things that only work in one browser are only good for that browser. They can only be used when this browser is the only one available in that environment. There is nothing wrong with pursuing this as a tech company. Apple shows that when you control the software and the environment you can create superb products people love. It is, however, a loss for the web as a whole as we just can not force people to have a certain browser or environment. This is against the whole concept of the web. Luckily enough, different browsers support Web Components (granted at various levels of support). We should be diligent about asking for this to go on and go further. We need this, and a great concept like Web Components shouldn’t be reliant on one company supporting them. A lot of other web innovation that heralded as a great solution for everything went away quickly when only one browser supported it. Shared technology is safer technology. Whilst it is true that more people having a stake in something makes it harder to deliver, it also means more eyeballs to predict issues. Overall, sharing efforts prevents an open technology to be a vehicle for a certain product.

Dependency on filler libraries

A few years ago we had a great and – at the same time – terrible idea: let’s fix the problems in browsers with JavaScript. Let’s fix the weirdness of the DOM by creating libraries like jQuery, prototype, mootools and others. Let’s fix layout quirks with CSS libraries. Let’s extend the functionality of CSS with preprocessors. Let’s simulate functionality of modern browsers in older browsers with polyfills.

All these aim at a simple goal: gloss over the differences in browsers and allow people to use future technologies right now. This is on the one hand a great concept: it empowers new developers to do things without having to worry about browser issues. It also allows any developer to play with up and coming technology before its release date. This means we can learn from developers what they want and need by monitoring how they implement interfaces.

But we seem to forget that these solutions were build to be stop-gaps and we become reliant on them. Developers don’t want to go back to a standard interface of DOM interaction once they got used to $(). What people don’t use, browser makers can cross off their already full schedules. That’s why a lot of standard proposals and even basic HTML5 features are missing in them. Why put effort into something developers don’t use? We fall into the trap of “this works now, we have this”, which fails to help us once performance becomes an issue. Many jQuery solutions on the desktop fail to perform well on mobile devices. Not because of jQuery itself, but because of how we used it.

Which leads me to Web Components solutions like X-Tags, Polymer and Brick. These are great as they make Web Components available right now and across various browsers. Using them gives us a glimpse of how amazing the future for us is. We need to ensure that we don’t become dependent on them. Instead we need to keep our eye on moving on with implementing the core functionality in browsers. Libraries are tools to get things done now. We should allow them to become redundant.

For now, these frameworks are small, nimble and perform well. That can change as all software tends to grow over time. In an environment strapped for resources like a $25 smartphone or embedded systems in a TV set every byte is a prisoner. Any code that is there to support IE8 is nothing but dead weight.

Creating inaccessible solutions

Let’s face facts: the average web developer is more confused about accessibility than excited by it. There are many reasons for this, none of which worth bringing up here. The fact remains that an inaccessible interface doesn’t help anyone. We tout Flash as being evil as it blocks out people. Yet we build widgets that are not keyboard accessible. We fail to provide proper labeling. We make things too hard to use and expect the steady hand of a brain surgeon as we create tight interaction boundaries. Luckily enough, there is a new excitement about accessibility and Web Components. We have the chance to do something new and do it right this time. This means we should communicate with people of different ability and experts in the field. Let’s not just convert our jQuery plugins to Web Components in verbatim. Let’s start fresh.

Hiding complex and inadequate solutions behind an element

In essence, Web Components allow you to write custom elements that do a lot more than HTML allows you to do now. This is great, as it makes HTML extensible (and not in the weird XHTML2 way). It can also be dangerous, as it is simple to hide a lot of inefficient code in a component, much like any abstraction does. Just because we can make everything into an element now, doesn’t mean we should. What goes into a component should be exceptional code. It should perform exceptionally well and have the least dependencies. Let’s not create lots of great looking components full of great features that under the hood are slow and hard to maintain. Just because you can’t see it doesn’t mean the rules don’t apply.

Repeating the “just another plugin doing $x” mistake

You can create your own carousel using Web Components. That doesn’t mean though that you have to. Chances are that someone already built one and the inheritance model of Web Components allows you to re-use this work. Just take it and tweak it to your personal needs. If you look for jQuery plugins that are image carousels right now you better bring some time. There are a lot out there – in various states of support and maintenance. It is simple to write one, but hard to maintain.

Writing a good widget is much harder than it looks. Let’s not create a lot of components because we can. Instead let’s pool our research and findings and build a few that do the job and override features as needed. Core components will have to change over time to cater for different environmental needs. That can only happen when we have a set of them, tested, proven and well architected.


I am super excited about this and I can see a bright future for the web ahead. This involves all of us and I would love Flex developers to take a look at what we do here and bring their experience in. We need a rich web, and I don’t see creating DOM based widgets to be the solution for that for much longer with the diversity of devices ahead.

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Django Eadred v0.3 released! Django app for generating sample data.

Mozilla planet - vr, 18/04/2014 - 13:20

Django Eadred gives you some scaffolding for generating sample data to make it easier for new contributors to get up and running quickly, bootstrapping required database data, and generating large amounts of random data for testing graphs and things like that.

The v0.3 release is a small one, but good:

  • Added support for Python 3.3 and later (Thank you Trey Hunner!)
  • Fixed test infrastructure and added tox support.
  • Fixed documentation.

There are no backwards-compatability problems with previous versions.

To update, do:

pip install -U eadred
Categorieën: Mozilla-nl planet

Mozilla: nieuwe browserengine Servo doorloopt Acid2-test succesvol -

Nieuws verzameld via Google - vr, 18/04/2014 - 11:43

Mozilla: nieuwe browserengine Servo doorloopt Acid2-test succesvol
Mozilla Labs meldt dat de in aanbouw zijnde Servo-renderengine de Acid2-browsertest met succes heeft weten te doorlopen. Servo kan zijn layout-taken in een parallele omgeving laten draaien, waardoor het beter uit de voeten kan met multicore-cpu's en ...

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 1: Hello world

Mozilla planet - vr, 18/04/2014 - 07:02
This is the first in a series of blog posts (none written yet) which aim to help experienced C++ programmers learn Rust. Expect updates to be sporadic at best. In this first blog post we'll just get setup and do a few super basic things. Much better resources are at the tutorial and reference manual.

First you need to install Rust. You can download a nightly build from (I recommend the nighlties rather than 'stable' versions - the nightlies are stable in that they won't crash too much (no more than the stable versions) and you're going to have to get used to Rust evolving under you sooner or later anyway). Assuming you manage to install things properly, you should then have a `rustc` command available to you. Test it with `rustc -v`.

Now for our first program. Create a file, copy and paste the following into it and save it as `` or something equally imaginative.
fn main() {
    println!("Hello world!");
}Compile this using `rustc`, and then run `./hello`. It should display the expected greeting \o/

Two compiler options you should know are `-o ex_name` to specify the name of the executable and `-g` to output debug info; you can then debug as expected using gdb or lldb, etc. Use `-h` to show other options.

OK, back to the code. A few interesting points - we use `fn` to define a function or method. `main()` is the default entry point for our programs (we'll leave program args for later). There are no separate declarations or header files as with C++. `println!` is Rust's equivalent of printf. The `!` means that it is a macro, for now you can just treat it like a regular function. A subset of the standard library is available without needing to be explicitly imported/included (we'll talk about that later). The `println!` macros is included as part of that subset.

Lets change our example a little bit:
fn main() {
    let world = "world";
    println!("Hello {}!", world);
}`let` is used to introduce a variable, world is the variable name and it is a string (technically the type is `&'static str`, but more on that in a later post). We don't need to specify the type, it will be inferred for us.

Using `{}` in the `println!` statement is like using `%s` in printf. In fact, it is a bit more general than that because Rust will try to convert the variable to a string if it is not one already*. You can easily play around with this sort of thing - try multiple strings and using numbers (integer and float literals will work).

If you like, you can explicitly give the type of `world`:
    let world: &'static str = "world";In C++ we write `T x` to declare a variable `x` with type `T`. In Rust we write `x: T`, whether in `let` statements or function signatures, etc. Mostly we omit explicit types in `let` statements, but they are required for function arguments. Lets add another function to see it work:
fn foo(_x: &'static str) -> &'static str {

fn main() {
    println!("Hello {}!", foo("bar"));
}The function `foo` has a single argument `_x` which is a string literal (we pass it "bar" from `main`). We don't actually use that argument in `foo`. Usually, Rust will warn us about this. By prefixing the argument name with `_` we avoid these warnings. In fact, we don't need to name the argument at all, we could just use `_`.

The return type for a function is given after `->`. If the function doesn't return anything (a void function in C++), we don't need to give a return type at all (as in `main`). If you want to be super-explicit, you can write `-> ()`, `()` is the void type in Rust. `foo` returns a string literal.

You don't need the `return` keyword in Rust, if the last expression in a function body (or any other body, we'll see more of this later) is not finished with a semicolon, then it is the return value. So `foo` will always return "world". The `return` keyword still exists so we can do early returns. You can replace `"world"` with `return "world";` and it will have the same effect.

* This is a programmer specified conversion which uses the `Show` trait, which works a bit like `toString` in Java. You can also use `{:?}` which gives a compiler generated representation which is sometimes useful for debugging. As with printf, there are many other options.
Categorieën: Mozilla-nl planet

Armen Zambrano Gasparnian: Mozilla's pushes - March 2014

Mozilla planet - do, 17/04/2014 - 23:18
Here's March's monthly analysis of the pushes to our Mozilla development trees (read about Gaia merges at the end of the blog post).
You can load the data as an HTML page or as a json file. TRENDSMarch (as February did) has the highest number of pushes EVER.
We will soon have 8,000 pushes/month as our norm.
The only noticeable change in the distribution of pushes is that non-integration trees had a higher share of the cake (17.80% on Mar. vs 14.60% on Feb.).
  • 7,939 pushes
  • 284 pushes/day (average)
  • Highest number of pushes/day: 435 pushes on March, 4th
  • 16.07 pushes/hour (average)

GENERAL REMARKSTry keeps on having around 50% of all the pushes.
The three integration repositories (fx-team, mozilla-inbound and b2g-inbound) account around 30% of all the pushes.
  • March 2014 was the month with most pushes (7,939 pushes)
  • March 2014 has the highest pushes/day average with 284 pushes/day
  • February 2014 has the highest average of "pushes-per-hour" is 16.57 pushes/hour
  • March 4th, 2014 had the highest number of pushes in one day with 435 pushes

  • The data collected prior to 2014 could be slightly off since different data collection methods were used
  • Gaia pushes are more or less counted. I will write a blog post about in the near term.
Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Ben Hearsum: This week in Mozilla RelEng – April 17th, 2014

Mozilla planet - do, 17/04/2014 - 20:29

Major Highlights:

Completed work (resolution is ‘FIXED’):

In progress work (unresolved and not assigned to nobody):

Categorieën: Mozilla-nl planet

Dietrich Ayala: Firefox OS and Academic Programs

Mozilla planet - do, 17/04/2014 - 20:10

Although Mozilla feels almost like a household name at this point, it is a relatively small organization – tiny, actually – compared to the companies that ship similar types of software [1]. We must, however, have the impact of a much larger entity in order to ensure that the internet stays an open platform accessible to all.

Producing consumer software which influences the browser and smartphone OS markets in specific ways is how we make that impact. Shipping that software requires teams of people to design, build and test it, and all the countless other aspects of the release process. We can hire some of these people, but remember: we’re relatively tiny. We cannot compete with multi-billion-dollar mega-companies while operating in traditional ways. Mozilla has to be far more than the sum of its paid-employee parts in order to accomplish audaciously ambitious things.

Open source code and open communication allow participation and contribution from people that are not employees. And this is where opportunities lie for both Mozilla and universities.

For universities, undergraduates can earn credit, get real world experience, and ship software to hundreds of millions of people. Graduate researchers can break ground in areas where their findings can be applied to real world problems, and where they can see the impact of their work in the hands of people around the world. And students of any kind can participate before, during and after any involvement that is formally part of their school program.

For Mozilla, we receive contributions that help move our products and projects forward, often in areas that aren’t getting enough attention only because we don’t have the resources to do so. We get an influx of new ideas and new directions. We gain awesome contributors and can educate tomorrow’s technology workers about our mission.

I’ve been working with a few different programs recently to increase student involvement in the Firefox OS:

  • Portland State University:  The PSU CS Capstone program, run by Prof. Warren Harrison, has teams of students tackling projects for open source groups. The teams are responsible for all parts of the software life-cycle during the project. In the spring of 2013, a group of five students implemented an example messaging app using Persona and Firebase, documenting the challenges of Web platform development and the Firefox OS  development/debugging workflow. This year’s group will implement a feature inside Firefox OS itself.
  • Facebook Open Academy: This is a program coordinated by Stanford and Facebook, that puts teams from multiple universities together to build something proposed by an existing open source project. The Firefox OS team includes students from Carnegie-Mellon, Purdue, Harvard, Columbia in the US, and Tampere UT in Finland. They’re adding a new feature to Firefox OS which allows you to share apps directly between devices using NFC and Bluetooth. With 14 members across five universities, this team is collaborating via Github, Google Groups, IRC and weekly meetings for both the front-end and back-end parts, providing experience with remote working, group coordination and cross-team collaboration.
  • University of MichiganProf. Z. Morley Mao’s mobile research group has started looking at device and network performance in Firefox OS. They’ve got a stack of phones and SIM cards, and we’re working with them to find ways to improve battery life and network efficiency on our devices. They’ve started a collection of focus areas and related research on the Mozilla wiki.

If you’re at an academic institution and would like to learn more about how to get your department or your students involved, or if you’re a Mozillian who wants to coordinate a project with your alma mater, email me!


1. Mozilla has ~1000 employees. According to Wikipedia, Google has ~50,000 employees, Apple ~80,000 and Microsoft ~100,000.

Categorieën: Mozilla-nl planet

Robert Nyman: The day Santa died

Mozilla planet - do, 17/04/2014 - 19:48

Today, just as we prepare for an Easter break, I heard my youngest daughter arguing with her older sister, and then the younger came running to me.

Dad, does the Easter Bunny and Santa exist?

As a parent, or anyone speaking to a child, you don’t want to take away their dreams or hopes. At the same time, it’s a rough world, so you see it as your responsibility to teach them as much as possible about how the world works so they both know more but also, to be honest, avoid the risk of them being ridiculed for not knowing something.

So should I leave it be and then she’ll eventually find out? Or should I tell her the truth, with the risk of making her sad? I do believe in honesty but at the same time I don’t want to be cynical.

I thought a bit about it, what to say and how to approach the situation. After some thinking, I decided to ask her what she thought:

What do you think? Do you believe they exist?

Yes. Or… I think so.

Have you ever seen any of them in real life?

Well… We had a bunny at the kindergarten once. Who wore shoes. And then you were Santa once, daddy.

Right. So do you believe they exist?

Hmm… No, not really, I guess.
sounding more like she wished they existed, than actually thinking they do

And then she bounced off, having learned another lesson abut life.

Categorieën: Mozilla-nl planet