http://tantek.com/2015/057/b1/disappointed-in-w3c

Our PL reading group read the paper “

http://www.msully.net/blog/2015/02/26/microkanren-%ce%bckanren-in-haskell/

As I’ve just been explaining to my son, when he’s my age and looks back at the history of the Internet, 26 February 2015 will be seen as a very important day.

Why? The Mozilla blog summarises it well:

We just accomplished something very important together. Today, the U.S. Federal Communications Commission voted for strong net neutrality protections. This happened because millions of people — including many hundreds of thousands in Mozilla’s community — joined together as citizens of the Web to demand those strong protections.

Net Neutrality can be a difficult thing to understand and, especially if you’re not based in the USA, it can feel like something that doesn’t affect you. However, it is extremely important, and it impacts everyone.

Last year we put together a Webmaker training module on Net Neutrality. I’d like to think it helped towards what was achieved today. As Mitchell Baker stated, this victory was far from inevitable, and the success will benefit all of humankind.

It’s worth finding out more about Net Neutrality, for the next time it’s threatened. Forewarned is forearmed.

Image CC BY Kendrick Erickson

http://dougbelshaw.com/blog/2015/02/26/net-neutrality/

Title: Analysing Gaia with Semmle Abstract: Semmle has recently added support for JavaScript to its analysis platform. As one of our first major JavaScript analysis...

https://air.mozilla.org/brown-bag-analysing-gaia-with-semmle/

We just accomplished something very important together. Today, the U.S. Federal Communications Commission voted for strong net neutrality protections. This happened because millions of people — including many hundreds of thousands
in Mozilla’s community — joined together as citizens of the Web to demand those strong protections.

This is an important victory for the world’s largest public resource, the open Web. Net neutrality is a key aspect of enabling innovation from everywhere, and especially from new players and unexpected places. Net neutrality allows citizens and consumers to access new innovations and judge the merit for themselves. It allows individual citizens to make decisions, without gate-keepers who decide which possibilities can become real. Today’s net neutrality rules help us protect this open and innovative potential of the Internet.

Mozilla builds our products to put this openness and opportunity into the hands of individuals. We are organized as a non-profit so that the assets we create benefit everyone. Our products go hand-in-hand with net neutrality; they need net neutrality to bring the full potential of the Internet to all of us.

Today’s net neutrality rules are an important step in protecting opportunity for all. This victory was not inevitable. It occurred because so many people took action, so many people put their voice into the process. To each of you we say “Thank you.” Thank you for taking the time to understand the issue, for recognizing it’s important, and for taking action. Thank you for helping us build openness and opportunity into the very fabric of the Internet.

Video message from Mitchell Baker, Executive Chairwoman, Mozilla Foundation

https://blog.mozilla.org/blog/2015/02/26/a-major-victory-for-the-open-web-2/

When the new participation plan was forming one of the first questions was: how can the Reps program enable more and deeper participation in Mozilla? We know that Reps are empowering local and regional communities and have been playing an important role in various project like Firefox OS launches, but there wasn’t an organized and more importantly scalable way to provide support to functional teams at Mozilla. The early attempts of the program to help connect volunteers with functional areas were the Special Interest Groups (SIG). Although in some cases and for some periods of time the SIGs worked very well and were impactful, they wasn’t sustainable in the long run. We couldn’t provide a structure that ensured mutual benefit and commitment.

With the renewed focus on participation we’re trying to think differently about the way that Reps can connect to functional teams, align with their goals and participate in every part of Mozilla. And this is where the “Impact teams” come in. Instead of forming loose interest groups, we want to form teams that work well together and are defined by the impact they are having, as well as excited by future opportunity to not only have deeper participation but personal growth as part of a dedicated team where colleagues include project staff.

The idea of these new impact teams is to make sure that the virtuous circle of mutual benefit is created. This means that we will work with functional teams to ensure that we find participation opportunities for volunteers that have direct impact on project goals, but at the same time we make sure that the volunteers will benefit from participating, widening their skills, learning new ones.

These teams will crystallize through the work on concrete projects, generating immediate impact for the team, but also furthering the skills of volunteers. That will allow the impact team to take on bigger challenges with time: both volunteers and functional teams will learn to collaborate and volunteers with new skills will be able to take the lead and mentor others.

We’re of course at the beginning and many questions are still open. How can we organize this in an agile way? How can we make this scalable? Will the scope of the role of Reps change if they are more integrated in functional activities? How can we make sure that all Mozillians, Reps and non Reps are part of the teams? Will we have functional mentors? And we think the only way to answer those questions is to start trying. That’s why we’re talking to different functional areas, trying to find new participation opportunities that provide value for volunteers. We want to learn by doing, being agile and adjusting as we learn.

The impact teams are therefore not set in stone, we’re working with different teams, trying loose structures and specially putting our energy into making this really beneficial for both functional teams and volunteers. Currently we are working to the Marketplace team, the Firefox OS Market research team and the developer relations team. And we’ll be soon reaching out to Mozillians and Reps who have a track record in those areas to ask them to help us build these impact teams.

We’re just at the beginning of a lot of pilots, tests, prototypes. But we’re excited to start moving fast and learn! We have plenty of work to do and many questions to answer, join us in shaping these new impact teams. Specially help us now how your participation at Mozilla can benefit your life, make you grow, learn, develop yourself. Emma Irwin is working on making education a centerpiece of participation, but do you have any other ideas? Share them with us!

http://ombrosa.co/2015/02/26/impact-teams-a-new-approach-for-functional-impact-at-reps/

Weekly Mozilla Reps call

https://air.mozilla.org/reps-weekly-20150226/

The users of Socorro at Mozilla, the Stability team, have very specific needs that vary over time. They need specific reports for the data we have, new aggregations or views with some special set of parameters. What we developers of Socorro used to do was to build those reports for them. It's a long process that usually requires adding something to our database's schema, adding a middleware endpoint and creating a new page in our webapp. All those steps take a long time, and sometimes we understand the needs incorrectly, so it takes even longer. Not the best way to invest our time.

Nowadays, we have Super Search, a flexible interface to our data, that allows users to do a lot of those specific things they need. As it is highly configurable, it's easy to keep the pace of new additions to the crash reports and to evolve the capabilities of this tool. Couple that with our public API and we can say that our users have pretty good tools to solve most of their problems. If Super Search's UI is not good enough, they can write a script that they run locally, hitting our API, and they can do pretty much anything we can do.

But that still has problems. Local scripts are not ideal: it's inconvenient to share them or to expose their results, it's hard to work on them collaboratively, it requires working on some rendering and querying the API where one could just focus on processing the data, and it doesn't integrate with our Web site. I think we can do better. And to demonstrate that, I built a prototype. Introducing...

Spectateur

Spectateur is a service that takes care of querying the API and rendering the data for you. All you need to do is work on the data, make it what you want it to be, and share your custom report with the rest of the world. It uses a language commonly known, JavaScript, so that most people (at least at Mozilla) can understand and hack what you have done. It lets you easily save your report and gives you a URL to bookmark and to share. And that's about it, because it's just a prototype, but it's still pretty cool, isn't it?

To explain it a little more: Spectateur contains three parts. The Model lets you choose what data you want. It uses Super Search and gives you about the same capabilities that Socorro's UI has. Once you have set your filters and chosen the aggregations you need, we move to the Controller. That's a simple JavaScript editor (using Ace) and you can type almost anything in there. Just keep the function transform, the callback and the last lines that set the interface, otherwise it won't work at all. There are also some limitations for security: the code is executed in a Web Worker in an iframe, so you have no access to the main page's scope. Network requests are blocked, among other things. I'm using a wonderful library called jailed, if you want to know more, please read its documentation.

Once you are done writing your controller, and you have exposed your data, you can click the Run button to create the View. It will fetch the data, run your processor on that data and then render the results following the rules you have exposed. The data can currently be displayed as a table (using jsGrid) or as a chart (using Chart.js). For details, please read the documentation of Spectateur (there's a link at the top). When you are satisfied with your custom report, click the button Save. That will save the Model and the Controller and give you a URL (by updating the URL bar). Come back to that URL to reload your report. Note that if you make a change to your report and click Save again, a new URL will be generated, the previous report won't be overwritten.

As an example, here is a report that shows, for our B2G product, a graph of the top versions, a chart of the top signatures and a list of crash reports, all of that based on data from the last 7 days: https://spectateur.mozilla.io/#58a036ec-c5bf-469a-9b23-d0431b67f436

I hope this tool will be useful to our users. As usual, if you have comments, feedback, criticisms, if you feel this is a waste of time and we should not invest any more time in it, or on the contrary you think this is what you needed this whole time, please please please let us know!

http://adrian.gaudebert.fr/blog/post/2015/02/26/spectateur-custom-reports-for-crash-stats

The following post is a summary of a series of earlier Heretic posts on the subject compiled into one comprehensive list - compiled by the wonderful folks at Unreasonable.is

Your pitch deck MUST start with a description of what it is that you’re doing. Your second slide (after the cover slide) is titled “What is NAME-OF-YOUR-COMPANY” (e.g. “What is eBay”). Explain in simple English what you’re doing. This is not the place to be clever, show off your extraordinary grasp of the English language or think that your pitch deck is a novel where you build tension and excitement in the first half and surprise the reader in the end.

If I (or any investor for that matter) don’t understand what you are doing in the first 10-15 seconds you already lost me. I know investors who don’t go past slide two if they don’t grasp what the company does.

Simple and obvious, eh? The crazy thing is, I get tons of decks which make me literally go “WTF?!” Let me illustrate the point. Here are two pitches which get it right (names and some product details have been changed):

What is ACME CORP?

• A unique coffee subscription business…
• 1) Rare, unique, single-origin coffee
• 2) Freshly roasted to order each month
• 3) A different coffee every month, curated by experts
• delivered monthly through the letterbox.
• A subscription-only business—sign up online—available for self-purchase or as a special gift

Moving on — pitch #2:

ACME CORP is an E-FASHION club that provides affordable trendy shoes, accessories and PERSONALIZED style recommendations to European Women!

Clear. They are a shopping club focussed on shoes for European women. Crisp and clear. No fancy language. Just the facts.

And now for something different—pitch #3:

ACME CORP is an online collaboration hub and development environment for makers, hobbyist and engineers.

I have mostly no clue what they are doing. Worse — as I actually know the team and their product — this isn’t even an accurate statement of what they are up to. What they build is Github plus a deployment system for Arduinos. Their statement is overly broad and unspecific.

So your first slide (not the cover — your first actual content slide) is the most important slide in your deck. It’s the slide where I decide if I want to see and hear more. It’s the slide which sets the tone for the rest of your interaction. And it’s the slide which forms my first image of you and your company. Spend time on it. Make it perfect. Pitch it to strangers who know nothing about your company and see if they get it. Show them just this one slide and then ask them to describe back to you what your company does. If they don’t get it, or it’s inaccurate, go back and revise the slide until you get it right.

The Team Slide

We all know that investors put their money into teams not ideas. Ideas are cheap and plentiful. Incredible execution is rare. Ideas evolve (yeah — sometimes they “pivot“). Great teams excel at this, mediocre teams fall apart. So you invest into people.

Which means your team slide better be good.

I can’t tell you too much about the composition of your team — as this is highly dependent on your idea and the industry you’re in.

Teams of one are usually a bad sign. If you can’t bring a team to the table when you ask for funding it just doesn’t reflect well on your ability to recruit. Teams that have a bunch of people listed as “will come on board once we can pay her/him a salary” don’t work. People who are not willing to take the risk are employees, not cofounders.

Don’t bullshit when you talk about your team. Sentences such as “X has 10 years of Internet experience” make me cringe, then laugh and then delete your email. Every man and his dog has ten years of “Internet experience” by now. Be honest, tell me what your team did. If your team hasn’t done anything interesting. Well, that’s something you should think about. You won’t be able to hide it anyway. “Y is a Ruby ninja?” I let your teammate speak with one of our portfolio companies for three minutes and I know if he’s a ninja or a backwater coder who still designs MySpace pages for his school chorus. Oh, and by the way: Nobody is a fucking ninja, superstar or what-have-you. Cut the lingo.

Lastly—and this shows your attention to detail — make sure the pictures you use have a common look and feel and don’t look like a collection of randomly selected vacation snapshots. Unless you’re all totally wasted in the shots. That might be funny.

Let’s Talk About Advisors

Typically you add them to your team slide. And most of the time you see something along the lines of a list of names a la “John Doe, Founder ACME Corp.,” sometimes with a picture.

Here’s the deal—advisors provide two signals for an investor:

1. Instant credibility if you have “brand name” advisors
2. A strong support network

The first one only works if you have truly recognizable names which are relevant to your field. Sergey Brin works, a random director at a large company doesn’t. The second one is trickier. In pitch presentations I often wonder what those people actually do for you — as often the entrepreneurs either just rattle down the names of the advisors on their slide or even glance over them and say something to the tune of, “and we have a bunch of awesome advisors.”

If you want to make your pitch stronger I recommend you make sure that your advisors are relevant (no, your dad’s buddy from the plumbing shop down the road most likely doesn’t count) and that they are actual advisors and not only people with whom you emailed once. You can spend 15 seconds in your pitch describing the relationship you have with your advisors. (e.g. “We assembled a team of relevant advisors with deep expertise in X, Y and Z. To leverage their expertise and network we meet with them every month for a one-hour session and can also ask for advice via phone and email anytime in between.”)

By the way, there is something to be said about the celebrity advisor. As awesome as it might be that you got Tim Cook from Apple to be an advisor I instantly ask myself how much time you actually get out of him—he’s busy as hell. So you might want to anticipate that (silent) question and address it head on in your pitch.

The Dreaded Finance Slide

The one slide that is made up out of one hundred percent pure fantasy. And yet it seems (and it is) so important. Everybody knows that whatever you write down on your finance slide is not reality but (in the best case) wishful thinking. That includes your investor.

Why bother? Simple. The finance slide shows your investor that you understand the fundamentals of your business. That you have a clue. That he can trust you with his money.

So what do you need to know about your finance slide? As so often in life the answer is: it depends. Here’s my personal take. For starters you want to show a one-year plan which covers month-by-month revenue and costs. Lump costs into broader buckets and don’t fall into the trap of pretended accuracy by showing off precise numbers. Nobody will believe that you really know that your marketing costs will be precisely $6,786 in month eight. You’re much better off eyeballing these numbers. Also don’t present endless lists of minutia details such as your telecommunication costs per month. Show your business literacy by presenting ballpark numbers that make sense (e.g. salaries should come as fully loaded head counts—not doing this is a strong indicator that you don’t know the fundamentals of running a business).

On the revenue side you want to do a couple of things. First of all explain your business model (this is something you might want to pull out on its own slide). Then give me your assumptions—sometimes it makes sense to work with scenarios (best, base and worst case). And then use this model to validate your revenue assumptions bottom-up. If you say you will have 5,000 customers in month three, what does that mean in terms of customer acquisition per day, how does that influence your cost model, etc.

This is probably the most useful part of putting together your financials. It allows you to make an educated guess about your model and will, if done right, feed you tons of information back into your own thinking. Weirdly a lot of entrepreneurs don’t do this and then fall onto their face when, in a pitch meeting, their savvy investor picks the numbers apart and points out the gapping holes (something I like to do—it really shows if someone thought hard about their business or if they are only wanna-be entrepreneurs).

And then you do the same for year two and three — this time on a quarterly basis.

Above all, do this for yourself, not because you need to do this for your investors. Use this exercise to validate your assumptions, to get a deep understanding of the underlying logic of your business. Your startup will be better off for it.

The Business Model Slide

You have a business model, right? Or at least you pretend to have one? If you don’t and you believe you can get by, by using a variant of the “we’ll figure it out” phrase you better have stratospheric growth and millions of users.

Here’s the thing about your business model slide in your pitch deck: If you spend time to make it clear, concise, easy to understand and grasp, I am so much more likely to believe that you have at least a foggy clue about what you’re doing. If you, in contrast, do what I see so many startups do and give me a single bullet, hidden on one of your other slides which reads something like “Freemium Model” and that’s it… well, that’s a strong indicator that you haven’t thought about this a whole lot, that you are essentially clueless about your business and that I really shouldn’t trust you with my money.

With that being said, what does a great business model slide look like? It really depends on what your business model is (or you believe it is to be precise—these things tend to change). What I look for is a clear expression of your model, the underlying assumptions and the way the model works out. Often this can be neatly expressed in an info graphic—showing where and how the money comes in, how the value chain looks like and what the margins are alongside the chain. Here’s an example: it’s not perfect yet much better than simply expressing your model as “we take a 25% margin.”

Spend some time on your business model slide. Make it clear and concise. The litmus test is: Show someone who doesn’t know anything about your company just this one slide and ask them to explain back to you your business model. If they get it and they get it in its entirety you are off to the races.

The Ask

You know that you always have to have an ask in your pitch, right? It might be for money, it might be for partnerships or just feedback—but never ever leave an audience without asking for something.

There’s a lot of art and science to asking. Here’s my view on the science piece: Let’s assume you pitch for money. Don’t start your pitch with your ask. By putting your ask first you A) rob yourself of the wonderful poetry of a well delivered pitch (as everyone only thinks about the dollars), B) you might loose a good chunk of your audience who might not fall into your price bracket (believe me, more often than not they gladly invest if they just hear you out and get excited by your company) and C) you will have every investor judge every single slide against the dollar amount you put up.

That said, don’t just close your pitch with a “We’re raising $500k. Thank you very much.” but give me a bit more detail what you need the money for and how long it is projected to last (pro tip: Make sure you budget for enough runway—raising for too short an amount of time is a classic beginners mistake). You want to say something like: “We’re raising $500k which will go towards building out our engineering team, building our Android app and getting the first wave of marketing out which should get us to 500k users. The round is projected to last 12 months and will validate our milestones.”

A Word About Design

One question I get quite often about pitch decks is: How much text should be or need to be on the slides? This can be a tricky question—you will both present the deck to an audience (in which case you tend to want to have less text and more emphasis on your delivery) and you’ll send the deck to investors via email (in which case a slide with just an image on it won’t work—the recipient doesn’t have the context of your verbal presentation).

Guy Kawasaki famously formulated the 10/20/30 rule: 10 Slides, 20 Minutes, 30 Point Minimal Font Size. This is a great starting point—and what I would recommend for your in-person investor presentation. But it might not work for the deck you want to email.

Here’s what I would do (and have done): Start with a slide deck where each and every slide can stand on its own. Assume you give the slide deck to someone who has no context about you and your startup. And at the same time—treat your deck like a deck and not a word document. Keep text short, reduce it to the bare necessity, cut out unnecessary language. Keep the whole deck short—one should be able to flip through your deck in a few minutes and digest the whole thing in 10-15 minutes.

Once you have this, which will be the deck you send out to investors, you take the deck and cut out all the words which are not necessary for an in-person presentation. This will give you the deck that you present. Keeping the two decks in sync with regards to slides, order and design will make it easier for someone who saw your deck recognize it in your pitch.

Flow

The best pitch deck fails to deliver if your overall flow isn’t right. Flow has as much to do with the logical order of your slides as it has with a certain level of theatrical drama (tension/relieve) and your personal delivery.

Guy recommends ten slides in the following order:

• Problem
• Your solution
• Business model
• Underlying magic/technology
• Marketing and sales
• Competition
• Team
• Projections and milestones
• Status and timeline
• Summary and call to action

Personally I think this is as good an order as most. Some people like to talk about the team earlier (as investors invest into people first and foremost), others have specific slides talking about some intricate issues specific to the business they are pitching.

For me, it comes down to a logical order: talk about the problem you’re solving first, then present the solution (the tension and relieve arch), and what feels good for you. I prefer a slide deck that is a bit off but comes with amazing in-person presence over a great slide deck and an uninspired presentation any day.

Note that you want to have a bit of drama in your deck—yet it’s not your school play where you try to outcompete Shakespeare. Don’t spend half an hour on building tension and then, TADA!, present your solution. In the end it’s all about balance.

And hey, send me your deck and I’ll provide honest, direct feedback. I won’t bite. Promise.

http://blog.finette.com/what-every-entrepreneur-should-know-about-pitching/

Starting program: /Volumes/BruceDeuce/src/mozilla-36t/obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -f run.js
warning: Could not find malloc init callback function.
Make sure malloc is initialized before calling functions.
Reading symbols for shared libraries ....................................................................+++......... done
Richards: 144
DeltaBlue: 137
Crypto: 215
RayTrace: 230
EarleyBoyer: 193
RegExp: 157
Splay: 140
NavierStokes: 268
----
Score (version 7): 180

Program exited normally.

Please keep in mind this is a debugging version and performance is impaired relative to PPCBC (and if I had to ship a Baseline-only compiler in TenFourFox 38, it would still be PPCBC because it has the best track record). However, all of the code cleanup for IonPower and its enhanced debugging capabilities paid off: with one exception, all of the bugs I had to fix to get it passing V8 were immediately flagged by sanity checks during code generation, saving much labourious single stepping through generated assembly to find problems.

I have a Master's program final I have to study for, so I'll be putting this aside for a few days, but after I thoroughly bomb it the next step is to mount phase 4, where IonPower can pass the test suite in Baseline mode. Then the real fun will begin -- true Ion-level compilation on big-endian PowerPC. We are definitely on target for 38, assuming all goes well.

I forgot to mention one other advance in IonPower, which Ben will particularly appreciate if he still follows this blog: full support for all eight bitfields of the condition register. Unfortunately, it's mostly irrelevant to generated code because Ion assumes, much to my disappointment, that the processor possesses only a single set of flags. However, some sections of code that we fully control can now do multiple comparisons in parallel over several condition registers, reducing our heavy dependence upon (and usually hopeless serialization of) cr0, and certain FPU operations that emit to cr1 (or require the FPSCR to dump to it) can now branch directly upon that bitfield instead of having to copy it. Also, emulation of mcrxr on G5/POWER4+ no longer has a hard-coded dependency upon cr7, simplifying much conditional branching code. It's a seemingly minor change that nevertheless greatly helps to further unlock the untapped Power in PowerPC.

http://tenfourfox.blogspot.com/2015/02/ionpower-passes-v8.html

We have a load of bugs in Tech Evangelism which are not taken care of. Usually the pattern is:

1. UNCONFIRMED: bug reported
2. NEW: analysis done

http://www.otsukare.info/2015/02/26/old-bugs-care

I have to build LLVM and Clang a lot for my research. Clang/LLVM is quite large and takes a long time to build if I don’t use -j8 or so to parallelize the build; but I also quickly discovered that parallelizing the build didn’t work either! I work on a laptop with 8gb of RAM and while this can easily handle 8 parallel compiles, 8 parallel links plus Firefox and Emacs and everything else is a one way ticket to swap town.

So I set about finding a way to parallelize the compiles but not the links. Here I am focusing on building an existing project. There are probably nicer ways that someone writing the Makefile could use to make this easier for people or the default, but I haven’t really thought about that.

My first attempt was the hacky (while ! pgrep ld.bfd.real; do sleep 1; done; killall make ld.bfd.real) & make -j8; sleep 2; make. Here we wait until a linker has run, kill make, then rerun make without parallel execution. I expanded this into a more general script:

This approach is kind of terrible. It’s really hacky, it has a concurrency bug (that I would fix if the whole thing wasn’t already so bad), and it slows things down way more than necessary; as soon as one link has started, nothing more is done in parallel.

A better approach is by using locking to make sure only one link command can run at a time. There is a handy command, flock, that does just that: it uses a file link to serialize execution of a command. We can just replace the Makefile’s linker command with a command that calls flock and everything will sort itself out. Unfortunately there is no totally standard way for Makefiles to represent how they do linking, so some Makefile source diving becomes necessary. (Many use $(LD); LLVM does not.) With LLVM, the following works: make -j8 'Link=flock /tmp/llvm-build $(Compile.Wrapper) $(CXX) $(CXXFLAGS) $(LD.Flags) $(LDFLAGS) $(TargetCommonOpts) $(Strip)'

That’s kind of nasty, and we can do a bit better. Many projects use $(CC) and/or $(CXX) as their underlying linking command; if we override that with something that uses flock then we’ll wind up serializing compiles as well as links. My hacky solution was to write a wrapper script that scans its arguments for “-c”; if it finds a “-c” it assumes it is a compile, otherwise it assumes it is a link and uses locking. We can then build LLVM with: make -j8 'CXX=lock-linking /tmp/llvm-build-lock clang++'.

Is there a better way to do this sort of thing?

http://www.msully.net/blog/2015/02/25/parallelizing-compiles-without-parallelizing-linking-using-make/

Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

https://air.mozilla.org/product-coordination-meeting-20150225/

Watch mconley livehack on Firefox Desktop bugs!

https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-3/

http://relengofthenerds.blogspot.com/2015/02/release-engineering-special-issue-now.html

This morning I've been reading various posts about the difficulty ahead for the Pointer Events spec, namely, Apple's (and by extension Google's) unwillingness to implement it. I'd encourage you to read both pieces, and whatever else gets written on this in the coming days.

I want to comment not on the spec as such, but on the process on display here, and the effect it has on the growth and development of the web. There was a time when the web's course was plotted by a single vendor (at the time, Microsoft), and decisions about what was and wasn't headed for the web got made by employees of that corporation. This story is so often retold that I won't pretend you need to read it again.

And yet here we are in 2015, where the web on mobile, and therefore the web in general, is effectively in the control of one vendor; a vendor who, despite its unmatched leadership and excellence in creating beautiful hardware, has shown none of the same abilities in its stewardship and development of the web.

If the only way to improve and innovate the web is to become an employee of Apple Inc., the web is in real danger.

I think that the larger web development community has become lax in its care for the platform on which it relies. While I agree with the trend toward writing JS to supplement and extend the browser, I think that it also tends to lull developers into thinking that their job is done. We can't simply write code on the platform, and neglect writing code for the platform. To ignore the latter, to neglect the very foundations of our work, is to set ourselves up for a time when everything collapses into the sand.

We need more of our developer talent and resources going into the web platform. We need more of our web developers to drop down a level in the stack and put their attention on the platform. We need more people in our community with the skills and resources to design, implement, and test new specs. We need to ensure that the web isn't something we simply use, but something we are active in maintaining and building.

Many web developers that I talk to don't think about the issues of the "web as platform" as being their problem. "If only Vendor X would fix their bugs or implement Spec Y--we'll have to wait and see." There is too often a view that the web is the problem of a small number of vendors, and that we're simply powerless to do anything other than complain.

In actual fact there is a lot that one can do even without the blessing or permission of the browser vendors. Because so much of the web is still open, and the code freely available, we can and should be experimenting and innovating as much as possible. While there's no guarantee that code you write will be landed and shipped, there is still a great deal of value in writing patches instead of just angry tweets: it is necessary to change peoples' minds about what the web is and what it can do, and there is no better way that with working code.

I would encourage the millions of web developers who are putting time into technologies and products on top of the web to also consider investing some time in the web itself. Write a patch, make some builds, post them somewhere, and blog about the results. Let data be the lever you use to shift the conversation. People will tell you that something isn't possible, or that one spec is better than another. Nothing will do more to convince people than a working build that proves the opposite.

There's no question that working on the web platform is harder than writing things for the web. The code is bigger, older, more complicated, and requires different tooling and knowledge. However, it's not impossible. I've been doing it for years with undergraduate students at Seneca, and if 3rd and 4th years can tackle it, so too can the millions of web developers who are betting their careers and companies on the web.

Having lived through and participated in every stage of the web's development, it's frustrating to see that we're repeating mistakes of the past, and allowing large vendors to control too great a stake of the web. The web is too important for that, and it needs the attention and care of a global community. There's something you can do, something I can do, and we need to get busy doing it.

http://blog.humphd.org/repeating-old-mistakes/

Help define, plan, design, and implement Bugzilla's future!

https://air.mozilla.org/bugzilla-development-meeting-20150225/

This blog started as a scratch pad of simple solutions to problems I encountered. So why not go back to basics?

Yesterday I was asked by someone if there is a possibility to store the state of a collection of checkboxes in a single value. The simplest way I could think of doing this is by using binary conversion.

You can see the result of my approach in this JSBin:

Storing a list of booleans as a single number

What’s going on here? The state of a checkbox is a Boolean, meaning it is checked or unchecked. This could be true or false, or, as JavaScript is a lenient language, 1 or 0. That’s why we can loop over all the checkboxes and assemble a string of their state that compromises of zeros and ones:

var inputs = document.querySelectorAll('input');
var all = inputs.length;
for (var i = 0; i < all; i++){
  state += inputs[i].checked ? '1' : '0';
}

This results in a string like 1001010101. This could be our value to store, but looks pretty silly and with 50 or more checkboxes becomes very long to store, for example, as a URL parameter string.

That’s why we can use parseInt() to convert this binary number into a decimal one. That’s what the second parameter in parseInt() is for – not only to please Douglas Crockford and JSLint (as it is preset to decimal – 10 – people keep omitting it). The counterpart of parseInt() in this case is toString() and that one also takes an optional parameter that is the radix of the number system you convert from. That way you can convert this state back and forth:

x = parseInt('1001010101',2);
// x -> 579
x.toString(2);
// "1001010101"

Once converted, you turn it back into a string and loop over the values to set the checked state of the checkboxes accordingly.

A small niggle: leading zeroes don’t work

One little problem here is that if the state results in a string with leading zeroes, you get a wrong result back as toString() doesn’t create them (there is no knowing how long the string needs to be, all it does is convert the number).

x = parseInt('00001010101',2);
x.toString(2);
"1010101"

You can avoid this is in two ways: either pad the string by always starting it with a 1 or by reversing the string and looping over the checkboxes in reverse. In the earlier example I did the padding part, in this JSBin you can see the reversing trick:

Storing a list of booleans as a single number (reverse)r

Personally, I like the reversing method better, it just feels cleaner. It does rely a lot on falsy/truthy though as the size of the resulting arrays differs.

Limitation

In any case, this only works when the amount of checkboxes doesn’t change in between the storing and re-storing, but that’s another issue.

As pointed out by Matthias Reuter on Twitter this is also limited to 52 checkboxes, so if you need more, this is not the solution.

http://christianheilmann.com/2015/02/25/simple-things-storing-a-list-of-booleans-as-a-single-number/

The Web Compatibility Summit was organized in Mountain View (USA) on February 18, 2015. I summarize the talks that we have been given during the day. I encourage to continue the discussion on compatibility@lists.mozilla.org.

If you want to look at the talks:

• Web Compatibility Summit 2015 Part 1
• Web Compatibility Summit 2015 Part 2

Intro to Web Compatibility

Mike Taylor (Mozilla) has introduced the Web Compatibility topic. The Web being a giant set of new and old things. We need to care for a lot of different things sometimes incompatible. Features will disappear, new features emerge, but you still need to make the Web usable for all users whatever their devices, countries, browsers.

Mike reminded us of the evolution of User Agent strings and how they grew with more and more terms. The reason is that the User Agent string became an ID for having the content rendered. So any new User Agent is trying to get access to the Web site content by not being filtered out.

Then he went through some traditional bugs (horrors) be JavaScript, CSS, etc.

WebCompat.com has been created to give a space for users to report Web Compatibility issues they have on a Web site. But the space is useful for browser vendors, it is relatively easy to tie the bug reporting of browsers directly to webcompat.com.

Discussions

Beyond Vendor Prefixes

Jacob Rossi (Microsoft) introducing the purpose and the caveats of vendor prefixes. Vendor prefixes have been created for helping people to test the new API safely without breaking other browser vendors. It shields against collision with other implementations, but it also creates Web Compatibility issues. The main issue being that Web developers use these on production sites and on articles, examples, documentations.

Microsoft tried to contact Web sites with bogus code examples and articles. They also created new content with the correct way of writing things. The results were promising for the FullScreen API but the experiment was less successful for other properties. Basically, fix the problem before it happens.

So how do we keep the possibility to have a large surface for feedback and at the same time limit the usage so that it doesn't become a requirement to use a specific browser. The first idea to put new features behind flags. Then the issue becomes that the feedback is shallow. So Jacob is floating the idea of an API trial, where someone would register to get a key for enabling a feature. It would help the developer to test and at the same time, make it possible to set deadlines for the test.

It would probably require a community effort to set up. It has a cost. Where this discussion should happen? It could be a community group at W3C. Not all APIs need to be used at scale for having a real sense of feedback. IndexedDB, appcache would have been good candidates for this thing. If there was a community site, it would be yet another good way to build awareness about the features.

A good discussion has been recorded on the video.

How CSS is being used in the wild

Alex McPherson (QuickLeft) introduced the wonderful work he did about CSS properties on the Web as they are currently (2014) used by Web devs. The report was initially done for understanding what QuickLeft should recommend in terms of technology when they tackle a new project. For this report, they scrap the CSS of the top 15000 Web sites and checking the frequency, values, doing graph distributions. The purpose was not to be an exact academic research. So they are definitely caveats in the study, but it gives a rough overview of what is done. The data were collected through a series of HTTP requests. One of the consequences is that we probably miss everything which is set through JavaScript. A better study would include a browser crawler handling the DOM. There are probably variations with regards to the user agent too.

It would be good to have a temporal view of these data and repeat the study continuously. So we can identify how the Web is evolving. Browser vendors seems to have more resources to do this type of studies than a single person in an agency.

Engaging with Web Developers for Site Outreach

Colleen Williams (Microsoft) talked about what it takes to do daily Web Compatibility work. Contacting Web developers is really about trying to convince people that there could be a benefit for them to implement with a wider scope of platforms.

Social networking and using linkedin are very useful to be to contact the right persons in companies. It's very important to be very upfront and to tell developers:

• Who we are?
• What we are doing?
• Why are we contacting them?

Microsoft IE team has a list of top sites and systematically test every new version of IE into these sites. It's an opportunity for contacting Web sites which are broken. When contacting Web sites, it's important to understand that you are building a relationship on a longterm. You might have to recontact the people working for this company and/or Web sites in a couple of months. It's important to nurture a respectful and interesting relation with the Web developers. You can't say "your code sucks". It's important to talk to technical people directly.

Do not share your contact list with business departements. We need a level of privacy with the persons we are contacting. They keep contact with you because they are eager to help of solving technical issues. Empathy in the relationship goes a long way in terms of creating a mutual trust. The relationship should always go both ways.

Having a part or the full solution for solving the issue will help you a lot in getting the issue fixed. It's better to show code and help the developer demonstrate what could work.

Companies user support channels are usually not the best tool, unfortunately, for reaching the company. There's a difference in between having a contact and having the right contact.

Web Compatibility Data: A Shared Resource

Finally Justin Crawford (Mozilla) introduced the project about having a better set of site compatibility data. But I encouraged you to read his own summary on his blog.

Unconference

We discuss at the end of the day using an unconference format. Alexa Roman moderated the session. We discussed about User Agent Sniffing and the format of the UA string, console.log for reporting Web Compatibility issues, API trials, documentation, etc.

More information

You can contact and interact with us: IRC: irc.mozilla.org #webcompat Discuss issues on compatibility@lists.mozilla.org Twitter: @webcompat Report bug: http://webcompat.com/

http://www.otsukare.info/2015/02/25/webcompat-summit-2015

Release notes

http://feedproxy.google.com/~r/armenzg_mozilla/~3/gaPvSo9Tx_A/mozci-024-released-support-for.html