I attended PyCon last week. It's a great conference. You should attend. While I should write up a detailed trip report, I wanted to quickly share one of my takeaways.

Ansible was talked about a lot at PyCon. Sitting through a few presentations and talking with others helped me articulate why I've been drawn to Ansible (over say Puppet, Chef, Salt, etc) lately.

First, Ansible doesn't require a central server. Administration is done remotely Ansible establishes a SSH connection to a remote machine and does stuff. Having Ruby, Python, support libraries, etc installed on production systems just for system administration never really jived with me. I love Ansible's default hands off approach. (Yes, you can use a central server for Ansible, but that's not the default behavior. While tools like Puppet could be used without a central server, it felt like they were optimized for central server use and thus local mode felt awkward.)

Related to central servers, I never liked how that model consists of clients periodically polling for and applying updates. I like the idea of immutable server images and periodic updates work against this goal. The central model also has a major bazooka pointed at you: at any time, you are only one mistake away from completely hosing every machine doing continuous polling. e.g. if you accidentally update firewall configs and lock out central server and SSH connectivity, every machine will pick up these changes during periodic polling and by the time anyone realizes what's happened, your machines are all effectively bricked. (Yes, I've seen this happen.) I like having humans control exactly when my systems apply changes, thank you. I concede periodic updates and central control have some benefits.

Choosing not to use a central server by default means that hosts are modeled as a set of applied Ansible playbooks, not necessarily as a host with a set of Ansible playbooks attached. Although, Ansible does support both models. I can easily apply a playbook to a host in a one-off manner. This means I can have playbooks represent common, one-off tasks and I can easily run these tasks without having to muck around with the host to playbook configuration. More on this later.

I love the simplicity of Ansible's configuration. It is just YAML files. Not some Ruby-inspired DSL that takes hours to learn. With Ansible, I'm learning what modules are available and how they work, not complicated syntax. Yes, there is complexity in Ansible's configuration. But at least I'm not trying to figure out the file syntax as part of learning it.

Along that vein, I appreciate the readability of Ansible playbooks. They are simple, linear lists of tasks. Conceptually, I love the promise of full dependency graphs and concurrent execution. But I've spent hours debugging race conditions and cyclic dependencies in Puppet that I'm left unconvinced the complexity and power is worth it. I do wish Ansible could run faster by running things concurrently. But I think they made the right decision by following KISS.

I enjoy how Ansible playbooks are effectively high-level scripts. If I have a shell script or block of code, I can usually port it to Ansible pretty easily. One pass to do the conversion 1:1. Another pass to Ansibilize it. Simple.

I love how Ansible playbooks can be checked in to source control and live next to the code and applications they manage. I frequently see people maintain separate source control repositories for configuration management from the code it is managing. This always bothered me. When I write a service, I want the code for deploying and managing that service to live next to it in version control. That way, I get the configuration management and the code versioned in the same timeline. If I check out a release from 2 years ago, I should still be able to use its exact configuration management code. This becomes difficult to impossible when your organization is maintaining configuration management code in a separate repository where a central server is required to do deployments (see Puppet).

Before PyCon, I was having an internal monolog about adopting the policy that all changes to remote servers be implemented with Ansible playbooks. I'm pleased to report that a fellow contributor to the Mercurial project has adopted this workflow himself and he only has great things to say! So, starting today, I'm going to try to enforce that every change I make to a remote server is performed via Ansible and that the Ansible playbooks are checked into version control. The Ansible playbooks will become implicit documentation of every process involved with maintaining a server.

I've already applied this principle to deploying MozReview. Before, there was some internal Mozilla wiki documenting commands to execute in a terminal to deploy MozReview. I have replaced that documentation with a one-liner that invokes Ansible. And, the Ansible files are now in a public repository.

If you poke around that repository, you'll see that I have Ansible playbooks referencing Docker. I have Ansible provisioning Docker images used by the test and development environment. That same Ansible code is used to configure our production systems (or is at least in the process of being used in that way). Having dev, test, and prod using the same configuration management has been a pipe dream of mine and I finally achieved it! I attempted this before with Puppet but was unable to make it work just right. The flexibility that Ansible's design decisions have enabled has made this finally possible.

Ansible is my go to system management tool right now. And I still feel like I have a lot to learn about its hidden powers.

If you are still using Puppet, Chef, or other tools invented in previous generations, I urge you to check out Ansible. I think you'll be pleasantly surprised.

http://gregoryszorc.com/blog/2015/04/17/my-current-thoughts-on-system-administration

In this beta, we disabled the define EARLY_BETA_OR_EARLIER (used by some features to get testing during the first half of beta cycle).

In this release, we took some changes related to reading list, polishing of in-tab preferences and some various minor crash fixes.

We also landed the stability fixes which should ship with the release 37.0.2.

• 52 changesets
• 86 files changed
• 3766 insertions
• 2141 deletions

List of changesets:

http://release.mozilla.org/statistics/38/2015/04/17/fx-38-b4-to-b5.html

Pontoon is a web application, which is great. You can run it on almost any device with any operating system. You can be sure you always have the latest version, so you don’t need to worry about updates. You don’t even need to download or install anything. There’s just one particular occasion when web applications aren’t so great.

When you’re offline.

Mostly that means the game is over. But it doesn’t need to be so. Application caching together with web storage has made offline web applications a reality. In its latest edition released yesterday, Pontoon now allows translating even when you’re offline. See full changelog for details.

There are many scenarios where offline localization is the only option our localizers have. Decent internet connection simply cannot be taken for granted in many parts of the World. If it’s hard for you to belive that, visit any local tech conference. Or, if you started localizing at home, you can now continue with localization on your daily commute to work. And vice versa.

The way it works is very simple. After Pontoon detects you no longer have a connection, it saves translations to localStorage instead of server. Once you get online again, translations are stored to server. In the meantime, connection dependant functionality like History and Machinery is of course unavailable.

Offline mode was single-handedly developed by our new contributor Sandra Shklyaeva. She just joined Mozilla community and has already fixed one of our oldest bugs. She’s attacking the bugs everybody was pushing away. I can’t wait to see what the future holds (shhhhh)!

Sandra has an interesting story on what got her attracted to Mozilla:

I was exploring some JS API on the developer.mozilla.org when I noticed pretty tabzilla on the top. I clicked it and my chrome became unresponsive completely XD. Maybe it was just a coincidence… Anyway, the tabzilla has caught my attention and that’s how I found out about Get Involved stuff in Mozilla.

If you also want to get involved, now you know where you can find us!

http://horv.at/blog/offline-localization-by-sandra/

I'm living in Japan. And time to time, I'm confronted with issues on the Japanese market when using Firefox on Mobile (Firefox OS and Firefox for Android). There's a situation in Japan which has similarities with the Chinese Market. For example, many sites have been designed with old WebKit CSS properties only, such as flexbox. The sites have not been updated to the new set of properties.

We started our testing with a list of around 100 Japanese Web sites. This list needs to be refined and improved. After a first batch of testing one year ago, we ended up with a list of about 50 sites having some issues. Most of them have been tested against a Firefox OS User Agent aka something like User-Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 (the version number is irrelevant).

Here I'm making a summary of the issues to help us

1. refine our future testing
2. have a better understanding of the issues at stake

We currently have 51 bugs on bugzilla (json) related to issues with Web Compatibility on Japane Web Sites. On these 51 sites, there is 1 duplicate and 13 resolved.

Type Of Issues

• HTTP Redirection to a mobile domain based on User-Agent: HTTP header
• JavaScript redirection to a mobile domain based on navigator.userAgent on the client side through window.location
• Content customization based on User-Agent: or navigator.userAgent
• Display of a banner to switch to a mobile version of the site based on User-Agent: or navigator.userAgent. Example: Asahi Web site
• Receiving a mobile site with outdated WebKit CSS only properties
• Site using a Web framework or JavaScript library which is exclusively compatible with a set of browsers. Example: Sencha on Nezu Museum. Not a lot can be done here.

Todo List For Better Testing

• Most of these are only the surface as we have tested most of the time, only the home page. We need to try to test a couple of subpages
• The sites need to be tested again with screenshots for:
• Firefox OS User Agent (User-Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0).
• Firefox for Android User Agent (User-Agent: Mozilla/5.0 (Android; Mobile; rv:40.0) Gecko/40.0 Firefox/40.0).
• Firefox for Android Modified User Agent (User-Agent: Mozilla/5.0 (Android 5.0; Mobile; rv:40.0) Gecko/40.0 Firefox/40.0) (this is a fake Firefox for Android UA, but some sites keep sending different versions or no version at all based on the following detection /.*Android ([0-9])\.([0-9])/ or match(/Android\s+(\d\.\d)/i. DO NOT DO THIS AT HOME at least not without a sensible fallback)
• A recent Android Chrome User Agent
• A recent iOS Safari User Agent

Some Ideas and Things We Can Do Together

There are a couple of things which can be done and where you can help.

• Translating this article in Japanese.
• Advocacy around you.
• Publish an article about Web Compatibility and Recipes in Japanese Press (Web Designing, Web Creators, etc.). I can help. Or maybe we could propose a monthly column in Web Designing on "let's fix this it" where we would go through a known site issues and how to solve them.
• Contact Web sites directly and pointing them to the bugs.
• Share with us if you know a person or a friend of a friend working on these sites/companies. Talk about it around you! A CTO, a Web developer, someone who can help us negociate a change on the site.
• Report sites which are broken on webcompat.com. It helps.

Old WebKit CSS, Flexbox Nightmare

Maybe in all these efforts in contacting Web sites, the flexbox story is the most frustrating one. I talked a couple of times about it: Fix Your Flexbox Web site and Flexbox old syntax to new syntax converter. The frustration comes from two things:

1. It's very easy to fix.
2. The sites are using outdated 1st version of Flexbox which was developed for WebKit only.

Swicthing to the new standard syntax would actually improve their customers reach and make them compatible with the future. It must also be frustrating for Apple and Co, because it means they can't really retire the old code from their rendering engine without breaking sites. Chicken and egg situation. If you remove the support, you break sites but push sites to update. If you keep the support, sites don't fix, but users using other browsers can't go to these sites. If they don't go to these sites, the browser doesn't show up in the stats, and so the site owners say: "We do not have to support this browser, nobody is using it on our site." Yes… you know. Running into circles.

In the end it forces other browser vendors to do dirty things for making it usable for everyone.

Fixing Your CSS - Easy!

Hallvord Steen has developped a quick tool to help you fix your CSS. It's not perfect, but it will remove a big part of the hard work on figuring out how to convert this WebKit only flexbox or gradient to a standard one supported everywhere.

Conclusion

All of these is part of a much bigger effort for Web Compatibility in general. In the next couple of days, I will go through all bugs we already have opened and check if there are new things.

If we get the flexbox/gradient right and the User Agent sniffing, we will have solved probably 80% of the issues of Web Compatibility issues in Japan.

Otsukare!

http://www.otsukare.info/2015/04/17/web-compatibility-japan

Well, Takashi Yoshi has succeeded where I failed (I'm still pretty confident on Darwin Nuke, though), and I have confirmed it on my systems using his RootPipe Tester tool. Please note, before you run, that this tool specifically exploits the vulnerability to write a setuid root file to disk, which if he weren't a nice guy means he now owns your system. Takashi is clearly a good guy but with any such tool you may wish to get in the habit of building from source you've closely examined, which he provides. The systemsetupusthebomb vulnerability is indeed successful on all versions of OS X going back to at least 10.2.8.

The workaround for this vulnerability is straightforward in concept -- disable writeconfig or neuter it -- but has side effects, because if you monkey with writeconfig the system will lose the capability to control certain configuration profiles (in 10.4, this generally affects the Sharing pane in System Preferences; 10.5+, which specifically exposes systemsetup, may be affected in other ways) and may also affect remote administration capabilities. Takashi and I exchanged E-mails on two specific solutions. Both of these possible solutions will alter system functionality, in a hopefully reversible fashion, but a blown command may interfere with administering your computer. Read carefully.

One solution is to rename (or remove, but this is obviously more drastic) writeconfig to something else. Admittedly this works a bit too well. RootPipe Tester actually crashed, which may be useful to completely stop a malicious app in its tracks, but it also made System Preferences unstable and will likely do the same to any app expecting to use Admin.framework. Although 10.4 seemed to handle this a bit better, it too locked up the Sharing pane after banging on it a bit. However, you can be guaranteed nothing will happen in this configuration because it's not possible for it to occur -- apps looking for the victim ToolLiaison class won't be able to find it. Since I'm rarely in that panel, this is the approach I've personally selected for my own systems, but I'm also fully comfortable with the limitations. You can control this with two commands in Terminal on 10.4-10.6 (make sure you fixed the issue with sudo first!):

go to a safe state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo mv writeconfig noconfig
go to original state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo mv noconfig writeconfig

For added security, make noconfig a custom filename only you know so an attacker won't be easily able to find it in an alternate location ... or, if you're nucking futs, archive or delete it entirely. (Not recommended except for the fascistic maniac.)

Takashi found the second approach to be gentler, but is slightly less secure: strip the setuid bits off. In this mode, the vulnerability can still be exploited to write arbitrary files, but as it lacks the setuid permission it cannot run as root and the file is only written as the current user (so no privilege escalation, just an unexpected file write). Applications that use Admin.framework simply won't work as expected; they shouldn't crash. For example, System Preferences will just "look at you" in the Sharing panel when you try to change or start a new system service -- nothing will happen. For many users, this will be the better option. Here are the Terminal commands for 10.4-10.6:

go to a safe state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo chmod u-s writeconfig
go to original state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo chmod u+s writeconfig

Choose one of these options. Most of the time, you should leave your system in the safe state. If you need to change Sharing or certain other settings with systemsetup or System Preferences, return to the original state, make the change, and return to the safe state.

Of course, one other option is to simply do nothing. This might be a surprising choice, but Takashi does make the well-taken point that this attack can only be perpetrated upon an administrative user where root is just your password away anyhow, and no implementation of this attack other than his runs on PowerPC. This isn't good enough for me personally, but his argument is reasonable, and if you have to do a lot of configuration changes on your system I certainly understand how inconvenient these approaches could be. (Perhaps someone will figure out a patch for System Preferences that does it for you. I'll leave that exercise to the reader.) As in many such situations, you alone will have to decide how much you're willing to put up with, but it's good to see other people are also working to keep our older Macs better protected on OS X.

Ob10.4Fx IonPower status report: 75% of V8 passing, interrupted briefly tonight to watch the new Star Wars trailer. I have cautious, cautious hope it won't suck, but J. J. Abrams, if you disappoint me, it will be for the last time (to paraphrase).

http://tenfourfox.blogspot.com/2015/04/systemsetupusthebomb-revisited.html

Are you jealous of the badges that npm modules or rubygems have, showing off their latest published version? Of course you are. I was too. When looking at a repository, the version may change as code is merged in, before being published to crates.io. Now, instead of looking at a repo and wondering what version is latest, that repo can add a crates.io badge.

Here’s hyper’s:

Besides wanting to be able to use badges like these for my own repositories, I also wanted a simple example of using hyper to create a simple app. Bonus points: it users the hyper Server and Client, together.

Go ahead, get your merit badge.

http://seanmonstar.com/post/116574828167

The Participation Forum

https://air.mozilla.org/participation-at-mozilla-20150416/

Q: I accidentally deleted all the files in the root directory of my hard disk for the second time this month. I managed to reinstall everything, but is there a way of avoiding the problem?

A: There are two approaches you could try, both of which have applications for other things too:

• Modify the files so that they cannot be deleted without first explicitly making them deletable. You can do this with the DOS utility Attrib which was supplied with your system. … To protect the file use the command:

  ATTRIB +R filename

  The +R switch means “make this file read-only”.

• Stop using the DEL command to delete files. Use a batch file instead which will prompt you before taking action.

  … …

  This batch file has a useful enhancement beyond the precautionary message. You can use it to specify multiple files, for example:

  DF *.BAK FRED.BAS ?.DOC

  With one command this would delete all .BAK files, FRED.BAS, and all .DOC files whose names begin with a single letter.

A delete command which takes multiple arguments – wow…

http://feedproxy.google.com/~r/HackingForChrist/~3/yefHIhWJGrU/

An old slogan, due for a comeback? :-)

http://feedproxy.google.com/~r/HackingForChrist/~3/-7UuFVdsCs8/

Mozilla hosts Kids Vision Bay Area Mentor Series

https://air.mozilla.org/kids-vision-mentorship-series-20150415/

This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

https://air.mozilla.org/quality-team-qa-public-meeting-20150415/

Duration: 10 minutes This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order...

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

Watch mconley livehack on Firefox Desktop bugs!

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

• 10943 pushes
• 353 pushes/day (average)
• Highest number of pushes/day: 579 pushes on Mar 11, 2015
• 23.18 pushes/hour (highest average)

• Try keeps on having around 49% of all the pushes
• The three integration repositories (fx-team, mozilla-inbound and b2g-inbound) account around 26% of all the pushes.

• August 2014 was the month with most pushes (13090  pushes)
• August 2014 had the highest pushes/day average with 422 pushes/day
• July 2014 had the highest average of "pushes-per-hour" with 23.51 pushes/hour
• October 8, 2014 had the highest number of pushes in one day with 715 pushes 

http://relengofthenerds.blogspot.com/2015/04/mozilla-pushes-march-2015.html

The introduction of TCP sockets support in Firefox OS made it possible to run a web server from the front-end, and all is written in JavaScript. Think of having something similar to express.js… but running on a browser (because after all, Firefox OS is a superturbocharged browser).

Again, JS server superstar Justin d’Archangelo wrote an implementation of a web server that works on Firefox OS. It’s called fxos-web-server and it includes a few examples you can run.

None of the examples particularly fit my use case–I want to serve static content from a phone to other phones, but the examples were a bit more contrived. So I decided to build a simpler proof-of-concept example: catserver, a web server that served a simple page with full screen Animated GIFs of cats:

Browserify

The first thing I wanted to do is to use Browserify “proper”, to write my app in a more modular way. For this I had to fork Justin’s original project and modify its package.json so it would let me require() the server instead of tucking its variable in the window globals – sadly I yet have to send him a PR so you will need to be aware of this difference. The dependency in package.json points to my fork for now:

Building (with gulp)

My example is composed of two “websites”. The first one is the web server app itself which is what is executed in the “server” device. The sources for this are in src.

The second website is what the server will transfer to devices that connect to it, so this actually gets executed in the client devies. This is where the cats are! Its contents are in the www folder.

Both websites are packaged in just one ZIP file and then installed onto the server device.

This build process also involves running Browserify first so I can get from node-style code that uses require() to a JavaScript bundle that runs on Firefox OS. So I’m using gulp to do all that. The tasks are in gulpfile.js.

Web server app

Thanks to Justin’s work, this is fairly simple. We create an HTTP server on port 80:

And then we add a listener for when a request is made, so we can respond to it (and serve content to the connected client):

The “decide what to send” part is a bit like writing nginx or express config files. In this case I wanted to:

• serve an index.html file if we request a “directory” (i.e. a path that ends with “/”)
• serve static content if we request a file (i.e. the path doesn’t end with “/”)

Before serving a file we need to tell the client what kind of content we’re sending to it. I’m using a very simple “extension to content type” function that determines MIME types based on the extension in the path. E.g. ‘html’ returns text/html.

Once we know the content type, we set it on the response headers:

and use Justin’s shortcut function sendFile to send a file from our app to the client:

With the request handler set up, we can finally start the server!

But… how does it even work?!

Welcome to the Hack of The Week!

When you say “sendFile” what the server app does is: it creates an XMLHttpRequest with type = arraybuffer to load the raw contents of the resource. When the XMLHttpRequest emits the load event, the server takes the loaded data and sends it to the client. That’s it!

Naive! Simple! It works! (for simple cases)

Ways that this could be improved – AKA “wanna make this better?! this is your chance!”

As I mentioned above, right now this is very naive and assumes that the files will exist. If they don’t, well, horrible things will happen. Or you will get a 404 error. I haven’t tried it myself. I’m not sure. I’d say there is no error handling (yet).

The extension to content type function could be made into a module, and probably extended to know about more file types. It probably exists already, somewhere in npmlandia.

Another idea I had is that instead of loading the entire resource in memory and then flush it down the pipe as sendFile does, we could use progress events on the XMLHttpRequest and feed it to the client as we load it–so that the server device won’t run out of memory. I don’t know how we could find the length of the resource first, perhaps a HEAD request could work!

And finally we could try to serve each request in a worker, so that the server doesn’t block when responding to a large request. Am I going too far? I don’t even know if the TCP sockets work with workers, or if there are issues with that, or who knows!? This is unexplored territory, welcome to Uncertainty Land!

Even extremer ways to get very… “creative”

What if you wrote a PHP parser that runs in JavaScript and then parsed .php files instead of just returning their contents as text/html?

I’m only half kidding, but you could maybe execute JS templates on the server. Forget security! You trust the content, right?

Another thing you could do is take advantage of the fact that the server is also a browser. So you can do browsersy things such as using Canvas to generate images, instead of having to load libraries that simulate canvas in node. Or you could synthesise web audio stuff on demand–maybe you could use an OfflineAudioWorker for extra non-blocking goodness! Or, if you want to go towards a relatively more boring direction, you could do DOM / text handling on a server that can deal with that kind of stuff natively.

With all the new platforms in which we can run Firefox OS, there are so many things we can do! Phone servers might be limited by battery, but a Raspberry PI running Firefox OS and connected to a power source can be an interesting platform with which to experiment with this kind of easy-to-write web servers.

But I saw NFC mentioned in the video!

Indeed! But I will cover that in another post, so we keep this one focused on the HTTP server

Happy www serving!

http://soledadpenades.com/2015/04/15/running-a-web-server-on-the-front-end/

37.0.2 mobile fix a critical issue for our Japanese users.

A 37.0.2 Desktop release is planned to fix some issues (especially graphic). It should be published in the next few days.

• 1 changesets
• 4 files changed
• 4 insertions
• 5 deletions

List of changesets:

http://release.mozilla.org/statistics/37.0.2/2015/04/15/fx-38-0-2.html

td;dr

Look! A flashy demo with buttons!

Background

A long time ago, we were investigating a way to expose text-to-speech functionality on the web. This was long before the Web Speech API was drafted, and it wasn’t yet clear what this kind of feature would look like. Alon Zakai stepped up, and proposed porting eSpeak to Javascript with Emscripten. This was a provocative idea: was our platform powerful enough to support speech synthesis purely in JS? Alon got back a few days later with a working demo, the answer was “yes”.

While the speak.js port was very impressive, it didn’t answer many of our practical needs. For example, the latency was not good enough for making a responsive UI, you could wait more than a couple of seconds to hear a short phrase. In addition, the longer the text you wanted to synthesize, the longer you needed to wait.

It proved a concept, but there were missing pieces we didn’t have four years ago. Today, we live in the future of 2011, and things that were theoretical then, are possible now (in the future).

asm.js

Today, Emscripten will compile C/C++ code into a subset of Javascript called asm.js. This subset is optimized on all current browsers, and allows performance to be about 2x native. That is really good. eSpeak is a pretty lightweight library already, the extra performance boost of asm.js makes speech instantaneous.

Transferable Objects

Passing data between a web worker and a parent process used to mean a lot of copying, since the worker doesn’t share memory with the parent process. But today, you can transfer ownership of ArrayBuffers with zero copying. When the web worker is ready to send audio data back to the calling process, it could do so while maintaining a single copy of the audio buffer.

Web Audio API

We have a slick, full featured Audio API today on the web. When speak.js came out in 2011, it used a prefixed method on an element to write PCM data to. Today, we have a proper API that enables us to take the audio data and send it through an elaborate pipeline of filters and mixers, or even send it into the ether with WebRTC.

Emscripten Got Fancy

This was my first time playing with it, so I am not sure what was available in 2011. But, if I have to guess, it was not as powerful and fun to work with. Emscripten’s new WebIDL support makes adding bindings extremely easy. You still get a chance to do some pointer arithmetic, but that’s supposed to be fun. Right?

So here is eSpeak.js!

I wanted to do a real API port, as opposed to simply porting a command line program that takes input and writes a WAV file. Why? two main reasons:

1. eSpeak can progressively synthesize speech. If you provide a callback to espeak_Synth(), it will be called repeatedly with as many samples as you defined in the buffer size. It doesn’t matter how long the text is that you want synthesized, it will fill the buffer and return it to you immediately. This allows for a consistent low latency from the moment you call espeak_Synth(), until you could start playing audio.
2. eSpeak supports events. If you use a callback, you get access to a list of events that provide a timestamp in the audio, and the type of event that occurs there, such as word or sentence boundaries.

And, of course, with all the recent-ish platform improvements above, I was really time for a fresh attempt.

Future Work

• Break up the data files. Right now, eSpeak.js is over a 2MB download. That’s because I packaged all the eSpeak data files indiscriminately. There may be a few bits that are redundant. On the flip side you get all 99 voice/language combinations (that’s a good deal for 2MB, eh?). It would be cool to break it up to a few data files and allow the developer to choose which voices to bundle or, even better, just grab them on demand.
• Make a demo of the speech events. It makes my head hurt to think about how to do something compelling. But it is a neat feature that should somehow be shown.
• ScriptProcessorNode is apparently deprecated. This is going to need to be ported to an AudioWorker once that is widely implemented.

I’m done apologizing, here is the demo.

http://blog.monotonous.org/2015/04/14/reintroducing-espeak-js/

Earlier this year I embarked on a journey to investigate how we could improve participation in the Mozilla QA community. I was growing concerned that we were failing in one key component of a vibrant community: recognition.

Before I could began, I needed to better understand Mozilla QA’s recognition story. To this end I published a survey to get anonymous feedback and today, I’d like to share some of that feedback.

Profile of Participants

The first question I asked was intended to profile the respondents in terms of how long they’d been involved with Mozilla and whether they were still contributing.

This revealed that we have a larger proportion of contributors who’ve been involved for more than a couple of years. I think what this indicates we need to be doing a better job of developing long-term relationships with new contributors.

When asked which projects contributors identified with, 100% of respondents identified as being volunteers with the Firefox QA team. The remaining teams breakdown fairly evenly between 11% and 33%. I think this indicates most people are contributing to more than one team, and that teams at the lower end of the scale have an excellent opportunity for growth.

Recognizing Recognition

The rest of the questions were focused more on evaluating the forms of recognition we’ve employed in the past.

When looking at how we’ve recognized contributors it’s good to see that everyone is being recognized in some form or another, in many cases receiving multiple forms of recognition. However I suspect the results are somewhat skewed (ie. people who haven’t been recognized are probably long gone and did not respond to the survey). In spite of that, it appears that seemingly simple things, like being thanked in a meeting, are well below what I’d expect to see.

When looking at the impact of being recognized, it seems that more people found recognition to be nice but not necessarily a motivation for continuing to contribute. 44% found recognition to be either ineffective or very ineffective while 33% found it to be either effective or very effective. This could point to a couple of different factors, either our forms of recognition are not compelling or people are motivated by the work itself. I don’t have a good answer here so it’s probably worth following up.

What did we learn?

After all said and done, here is what I learned from doing this survey.

1. We need to be focused on building long-term relationships. Helping people through their first year and making sure people don’t get lost long-term.

2. Most people are contributing to multiple projects. We should have a framework in place that facilitates contribution (and recognition of contribution) across QA. Teams with less participation can then scale more quickly.

4. We need to be more proactive in our recognition, especially in its simplest form. There is literally no excuse for not thanking someone for work done.

5. People like to be thanked for their work but it isn’t necessarily a definitive motivator for participation. We need to learn more about what drives individuals and make sure we provide them whatever they need to stay motivated.

6. Recognition is not as well “baked-in” to QA as it is with other teams — we should work with these teams to improve recognition within QA and across Mozilla.

7. Contributors find testing to be difficult due to inadequate description of how to test. In some cases, people spend considerable amounts of time and energy figuring out what and how to test, presenting a huge hurdle to newcomers in particular. We should make sure contribution opportunities are clearly documented so that anyone can get involved.

8. We should be engaging with Mozilla Reps to build a better, more regional network of QA contributors, beginning with giving local leaders the opportunity to lead.

Next Steps

In closing, I’d like to thank everyone who took the time to share their feedback. The survey remains open if you missed the opportunity. I’m hoping this blog post will help kickstart a conversation about improving recognition of contributions to Mozilla QA. In particular, making progress toward solving some of the lessons learned.

As always, I welcome comments and questions. Feel free to leave a comment below.

Cheers!

https://ashughes.com/?p=289

Si de protecci'on a la privacidad se habla, tenemos que reconocer los esfuerzos que realiza Mozilla para mantenernos seguros en este mundo donde todos quieren espiarnos y robar nuestra informaci'on a cualquier costo. Por esa raz'on, Mozilla recibi'o el premio a la compa~n'ia m'as confiable en Internet.

Firefox ya incluye la funcionalidad No rastrear, que le indica a los sitios web que no monitorizen tu actividad web, las compa~n'ias no est'an obligadas a hacerle caso. Sin embargo, Mozilla no se detiene y en la pr'oxima versi'on de Firefox introducir'a un nuevo filtro de seguridad que ya podemos activar de forma manual.

Antes de seguir, es importante que conozcan ?qu'e es el rastreo en l'inea u online? El rastreo online consiste en la recopilaci'on de los datos de navegaci'on de una persona a trav'es de los diferentes sitios web; esta recopilaci'on se hace, por lo general, solo con ver el contenido de un sitio web. Los dominios rastreadores solo intentan identificar a una persona a trav'es del uso de cookies o mediante la utilizaci'on de otras tecnolog'ias, como por ejemplo, la huella digital.

Pero ?qu'e soluci'on ofrece Mozilla? La protecci'on de rastreo te permite tomar el control de tu privacidad. Aunque Firefox proporciona  La Protecci'on de rastreo de Firefox te devuelve de nuevo el control de tu privacidad, bloqueando activamente los dominios y sitios web que son conocidos por rastrear a sus visitantes.

?C'omo activar la Protecci'on de rastreo?

1. En la barra de direcciones, escribe about:config y pulsa IntroRetorno.
   • El aviso de about:config “!Zona hostil para manazas!” o “!Esto puede cancelar su garant'ia!” puede aparecer. Haz clic en !Tendr'e cuidado, lo prometo! o !Ser'e cuidadoso, lo prometo!, para continuar.
2. Busca privacy.trackingprotection.enabled.
3. Haz doble clic en privacy.trackingprotection.enabled para cambiar su valor a true.

Esto activar'a la Protecci'on de rastreo. Si m'as tarde quieres desactivarla, repite los pasos anteriores para cambiar el valor a false.

C'omo usar la Protecci'on de rastreo

Una vez activada la Protecci'on de rastreo, ver'as un escudo en la barra de direcciones cuando Firefox est'e bloqueando el rastreo desde ese dominio o desde contenido mixto.

Para desactivar la Protecci'on de rastreo en un sitio web en particular, simplemente haz clic en el icono del escudo y selecciona “Desactivar protecci'on para este sitio”. Una vez que la Protecci'on de rastreo se desactiva en un sitio web, podr'as ver un escudo con una cruz roja. Puedes volver a activar la Protecci'on de rastreo en ese sitio web volviendo a hacer clic en el escudo y seleccionando “Activar protecci'on”.

Para ver qu'e recursos est'an siendo bloqueados, abre la consola web y busca en los mensajes que est'an en la pesta~na Seguridad.

Si deseas probar esta funcionalidad, debes instalar la versi'on Nightly que se encuentra en nuestra zona de Descargas para tu sistema,

Fuente: Ayuda de Firefox

http://firefoxmania.uci.cu/firefox-impedira-que-recopilen-nuestra-informacion/

We got a lot of stuff done in 2015q1--it was a busy quarter.

Things to know:

• Input is Mozilla's product feedback site.
• Fjord is the code that runs Input.
• We maintain project details and plans at https://wiki.mozilla.org/Firefox/Input.
• I am Will Kahn-Greene and I'm the tech lead, architect, QA and primary developer on Input.

Quarter 2015q1 (2015-01-01 -> 2015-03-31)
=========================================


Bugzilla
========

Bugs created: 73
Creators: 7

         Will Kahn-Greene [:willkg] : 67
     Gregg Lind (User Advocacy - He : 1
                  Shashishekhar H M : 1
              Matt Grimes [:Matt_G] : 1
           Mark Banner (:standard8) : 1
                         deshrajdry : 1
                      L. Guruprasad : 1

Bugs resolved: 97

                            WONTFIX : 13
                              FIXED : 82
                          DUPLICATE : 1
                         INCOMPLETE : 1

                         Tracebacks : 4
                           Research : 2
                            Tracker : 6

Research bugs: 2

    1124412: [research] evaluate SUMO search APIs for best results
        given a piece of feedback

Tracker bugs: 6

    907871: [tracker] add analytics infrastructure and reports to
        Input
    967037: [tracker] add classifier page to Firefox OS feedback form
    968230: [tracker] capture carrier in Firefox OS form
    1092280: [tracker] heartbeat v2 (Input-specific changes)
    1104932: [tracker] about:support support tracker
    1130599: [tracker] Alerts phase 1

Resolvers: 6

         Will Kahn-Greene [:willkg] : 65
                      L. Guruprasad : 16
     Ricky Rosario [:rrosario, :r1c : 7
                             aokoye : 5
                            mgrimes : 2
                         deshrajdry : 2

Commenters: 22

                             willkg : 579
                           rrosario : 25
                         deshrajdry : 10
                            mcooper : 10
                          lgp171188 : 10
                            mgrimes : 9
                                cww : 8
                              glind : 8
                         adnan.ayon : 6
                             aokoye : 4
                               robb : 4
                            brnet00 : 3
                          mozaakash : 2
                        John99-bugs : 2
                           chofmann : 2
                            bwalker : 1
                              laura : 1
                          standard8 : 1
                    shashishekharhm : 1
                          christian : 1
                            fwenzel : 1
                          dlucian93 : 1

git
===

Total commits: 276

      Will Kahn-Greene :   189  (+9707, -3904, files 558)
         L. Guruprasad :    38  (+916, -402, files 160)
         Ricky Rosario :    36  (+1756, -10764, files 314)
            Adam Okoye :     6  (+210, -12, files 12)
               deshraj :     3  (+19, -19, files 5)
         Michael Kelly :     2  (+2, -2, files 4)
      Adrian Gaudebert :     2  (+20, -6, files 4)

Total lines added:   12630
Total lines deleted: 15109
Total files changed: 1057

Everyone
========

    Adam Okoye
    adnan.ayon
    Adrian Gaudebert
    brnet00
    bwalker
    chofmann
    christian
    cww
    deshrajdry
    dlucian93
    fwenzel
    Gregg Lind (User Advocacy - Heartbeat - Test Pilot)
    John99-bugs
    L. Guruprasad
    laura
    Mark Banner (:standard8)
    Matt Grimes [:Matt_G]
    mcooper
    Michael Kelly
    mozaakash
    Ricky Rosario
    robb
    Shashishekhar H M
    standard8
    Will Kahn-Greene

2014q1: April 1st, 2014:        15195 total  6953 Python
2014q2: July 1st, 2014:         20456 total  9247 Python
2014q3: October 7th. 2014:      23466 total  11614 Python
2014q4: December 31st, 2014:    30158 total  13615 Python
2015q1: April 1st, 2015:        28977 total  12623 Python

http://bluesock.org/~willkg/blog/mozilla/input_2015q1