Robert O'Callahan: Against The "Internet Of Things" |
I was lucky to be at the Berkeley "programming systems" retreat in Santa Cruz a couple of weeks ago. One topic that came up was programming in the world of the "Internet of Things" --- the anticipated future where everyone has dozens of very small, very low-power devices with CPUs, sensors and radios. There's certainly a lot of interesting work to be done in that area, but nobody seems to have asked the question "do we really want an Internet of Things?" Because I don't, not until we've addressed the pervasive problems we already have with security, privacy, and general untrustworthiness of our computing infrastructure. It's obvious that these buy-and-forget devices won't get timely security updates (if updates are even adequate for security), so governments and criminal organizations will be battling for control over them, out of sight and mind of their nominal owners. So we're talking about is making the surveillance network of the NSA (and even worse actors) a lot more pervasive. These devices will be able to run for years without a battery change, so when you buy a new house or car, you will inherit a miasma of unseen machines doing everyone's bidding but yours.
There's going to be a big market for scanning and cleaning tools. A small handheld EMP unit would be great. Someone should get on this problem.
http://robert.ocallahan.org/2014/05/against-internet-of-things.html
|
Armen Zambrano: Technical debt and getting rid of the elephants |
http://feedproxy.google.com/~r/armenzg_mozilla/~3/rEUXZG3OyUE/technical-debt-and-getting-rid-of.html
|
Mike Hommey: More memory allocator flexibility now enabled by default, and jemalloc 3.6 |
A year and a half ago (already), I landed replace-malloc, a feature that allows more memory allocator flexibility in Firefox. It enabled building tools such as the dark matter detector (aka DMD) more easily. It also allows to replace our default allocator, (moz)jemalloc.
Until now, you had to explicitly enable the feature with –enable-replace-malloc. As of writing, it is enabled by default on all builds except Windows builds with jemalloc disabled (but that’s due to change too). Note Windows debug builds, as well as local Windows builds have jemalloc disabled by default.
It currently is only on mozilla-inbound, but should propagate quickly to other branches. It won’t, however, ride the trains: it will stay disabled on aurora, beta, release, esr.
Relatedly, two years ago (already), I landed jemalloc 3.0.0, and updated it until 3.2.0 six months later. It was and still is disabled by default. Sadly, it hasn’t seen an update since then. The recent increase in activity around improving the memory footprint of our own fork of jemalloc (dating back to before version 1.0) made me want to update it at last.
This is now done, and the tree contains a (slightly patched) copy of jemalloc 3.6.0. And combined with replace-malloc, it is now possible to test it on nightly builds (well, starting from the one after the next mozilla-inbound merge to mozilla-central) with the following:
$ LD_PRELOAD=/path/to/libreplace_jemalloc.so firefox
$ DYLD_INSERT_LIBRARIES=/path/to/libreplace_jemalloc.dylib firefox
$ MOZ_REPLACE_MALLOC_LIB=drive:\path\to\replace_jemalloc.dll firefox
$ am start -a android.activity.MAIN -n org.mozilla.fennec/.App --es env0 MOZ_REPLACE_MALLOC_LIB=/path/to/libreplace_jemalloc.so
No, you don’t need to rebuild Firefox to test it with jemalloc 3.6.0. The relevant library is now shipped in the nightly builds. Except on Android, as I haven’t figured where to put it, but you can take the .so
file from a local build and use it with a nightly build.
I would appreciate if several people could start using jemalloc 3.x this way. There is still work to do to make it the default. In fact, the list of dependencies of the tracking bug still has the same bugs I filed a long time ago. Hopefully, the ease of use will make someone want to scratch those itches. Please ping me if you want to take one of those bugs.
|
Mitchell Baker: Ronaldo Lemos Joins Mozilla Foundation Board |
Please join me in welcoming Ronaldo Lemos to the Mozilla Foundation Board of Directors. Ronaldo brings a passion for the open Web and a wealth of new knowledge to the Mozilla Foundation Board. Ronaldo is an internationally respected Brazilian academic, lawyer and commentator on intellectual property, technology, and culture. He is the director of the Rio Institute for Technology & Society, and professor at the Rio de Janeiro State University's Law School. He has also been the Project Lead for Creative Commons in Brazil since 2003.
Lemos was one of the creators of the Marco Civil da Internet, legislation for protecting civil rights, privacy and net neutrality for the Internet in Brazil—key, given Mozilla’s increasing focus on the role of policy in protecting (or harming) the open nature of the internet. Ronaldo also brings a broad view of the nature of the internet in markets like Brazil, where an increasing amount of people are coming online primarily via mobile.
Ronaldo has been working with Mozilla since 2005, helping Mozilla conduct activities in Brazil, working together on policy issues, and increasingly providing advice about Firefox OS as a tool for mobile empowerment. Ronaldo strengthens our voice and expands our reach. You can follow him (in Portugese mostly) on twitter at @lemos_ronaldo, Facebook and the Instituto de Tecnologia & Sociedade do Rio de Janeiro. We are excited to have Ronaldo’s expertise and energy as part of our leadership team.
https://blog.lizardwrangler.com/2014/05/22/ronaldo-lemos-joins-mozilla-foundation-board/
|
Ricky Rosario: dotjs: My first Firefox Add-on |
Inspired by defunkt's dotjs Chrome extension, I finally decided to play with the new add-on sdk to port the concept to Firefox. dotjs executes JavaScript files in ~/.js based on their filename and the domain of the site you are visitng. For example, if you navigate to http://www.twitter.com, dotjs will execute ~/.js/twitter.com.js. It also loads in jQuery so you can use jQuery with in your scripts even if the site doesn't use jQuery (it is loaded with .noConflict so it doesn't interfere with any existing jQuery on the page).
You can get the add-on for Firefox 4 on AMO and it doesn't require a browser restart (woot!). The code is on github. Feedback and patches welcome!
|
Jennifer Boriss: Firefox’s Redesigned Preferences Feel More like the Web |
http://www.donotlick.com/2014/05/20/firefoxs-redesigned-preferences-feel-more-like-the-web/
|
Sylvestre Ledru: Changes Firefox 30 beta4 to beta5 |
Extension | Occurrences |
cpp | 21 |
html | 16 |
js | 15 |
h | 9 |
css | 8 |
list | 3 |
ini | 3 |
webidl | 2 |
py | 2 |
mozbuild | 2 |
mn | 2 |
jsm | 2 |
xul | 1 |
xml | 1 |
mm | 1 |
gypi | 1 |
build | 1 |
Module | Occurrences |
layout | 18 |
browser | 18 |
gfx | 13 |
dom | 11 |
content | 9 |
toolkit | 6 |
media | 3 |
testing | 2 |
netwerk | 2 |
widget | 1 |
mozglue | 1 |
modules | 1 |
mobile | 1 |
js | 1 |
ipc | 1 |
docshell | 1 |
build | 1 |
List of changesets:
Margaret Leibovic | Bug 999760 - Fix mistake in uplift. a=bustage - ea7fa7d12c15 |
Matt Woodrow | Bug 1003707 - Pass surfaces sizes in to CreateSourceSurfaceFromNativeSurface instead of trying to extract it from cairo. r=Bas, a=sledru - 956578072396 |
JW Wang | Bug 1004669 - Fix leaks in MediaTaskQueue::Dispatch(). r=cpearce, a=sledru - 662c516a1858 |
David Major | Bug 1002748 - Blocklist libinject.dll. r=bsmedberg, a=sledru - b334e79cf04f |
David Major | Bug 988311 - Blocklist rf-firefox-22.dll. r=bsmedberg, a=sledru - 79e75d908e1d |
Chris Peterson | Bug 757726 - Part 7 - Reenable navigator.plugins enumeration. r=bsmedberg, a=sledru - a7b30030153c |
Mark Hammond | Bug 999518 - Don't hit the production FxA server during mochitests. r=froydnj, a=test-only - 2c4e64ce090e |
D~ao Gottwald | Bug 1007229 - Background tabs need to use the CaptionText color when using a high contrast theme on Windows 8/8.1. r=Gijs, a=lsblakk - ee16a6a74667 |
Gijs Kruitbosch | Bug 1004255 - Adjust flex so that inner panelUI-contents sizes correctly. r=mconley, a=lsblakk - 68037a299c56 |
Tim Taubert | Bug 966098 - Handle inactive/no windows case for "sync started" notification r=markh a=sylvestre - 937f11ea90b2 |
Neil Deakin | Bug 994194, don't set height of panels when they are on the toolbar, prevents scrollbars from appearing, r=mconley, a=lsblakk - 9bd4a69ee2e0 |
Tim Taubert | Bug 495123 - Save an empty window state if it's the last window closed and there were no others closed in series before r=smacleod a=lsblakk - f29ab60028d4 |
Giovanni Sferro | Bug 982189 - Fix Input type="number" immutability. r=jst, a=lsblakk - dcd4cf44e61b |
Andrea Marchesini | Bug 1000947 - Console::Methods must not throw exceptions. r=bz, a=lsblakk - e295406432eb |
Bob Owen | Bug 973837 - Don't allow view-source in s. r=johns, a=lsblakk - acb6d71ba45d |
Bob Owen | Bug 973837 - Check that view-source is not allowed for s. r=johns, a=lsblakk - ff4da156e917 |
Andrea Marchesini | Bug 1004814 - console.time/timeEnd work in workers. r=bz, a=sledru - aa9bc2b880a1 |
Stephen Pohl | Bug 989769 - Allow for vertical scrolls to interrupt horizontal swipes on OSX. r=smichaud, a=lsblakk - a713e6bd540d |
Chris Pearce | Bug 1008785 - Ensure the last video frame end time is correct on Android MP4 playback. r=kinetik, a=lsblakk - e9cfd7705824 |
Matt Woodrow | Bug 1008610 - Convert right xlib surface into a SourceSurface. r=Bas, a=sledru - 1c2c267a019f |
Gijs Kruitbosch | Bug 1000051 - Fix hidpi close icon size. r=dao, a=lsblakk - 504c3281b663 |
Gijs Kruitbosch | Bug 1008559 - setLocationAttributes, as called from buildArea, should remove anchor attribute if set. r=mconley, a=lsblakk - b927870d378d |
Jonathan Kew | Bug 1001233 - Convert bullet frame's margin to the block frame's writing mode when positioning bullet. r=smontagu, a=lsblakk - 542398357372 |
Gijs Kruitbosch | Bug 1009529 - Treat null features as '' features in window.open calls. r=bz, a=sledru - 41a1653a0199 |
Mark Hammond | Bug 966579 - Tweaks to mutation observer usage for fix intermittent chat orange. r=mixedpuppy, a=test-only - c3db2214834e |
Randell Jesup | Bug 981780 - Fix --disable-webrtc. r=glandium, a=sledru - 83f031a76d0a |
Landry Breuil | Bug 981780 - Disable some dom/media webrtc tests if webrtc isnt enabled. r=drno, a=sledru - 3f803365277a |
Mark Hammond | Bug 916497 - PageThumbs no longer expires thumbnails being tested to fix intermittent oranges. r=adw, a=test-only - c5f7b330dd3a |
Tim Nguyen | Bug 983978 - download-glow.png should be blue on Windows and Linux. r=Gijs, a=sledru - c3bcd563e6ce |
Gijs Kruitbosch | Bug 986866, Bug 1008647 - duplicate the 'show all bookmarks' item, r=mak, ui-r=shorlander, a=sylvestre - d087200dd934 |
Marty Rosenberg | Bug 995542 - Add extra consumers of the congruence-head when we split it from the class. r=sstangl, a=sledru - 9e2975cd6792 |
Bob Owen | Bug 996280 - Use the docshell's sandbox flags if we can't get the active document in IsSandboxedFrom(). r=smaug, a=sledru - 68b0fb01bfdc |
David Major | Bug 1000364 - Drop nonqueued messages for QuickTime's QTNSHIDDEN class. r=jimm, a=sledru - 19554eb3bed1 |
Gijs Kruitbosch | Bug 1008402 - Linux downloads button icon loses lwtheme color if using dark lwtheme (bright text). r=mconley, a=sledru - 792de35e26c0 |
Arnaud Bienner | Bug 1007278 - Restore the distinct text-color on disabled buttons. r=dholbert, a=sledru - 75ff52caee21 |
Margaret Leibovic | Bug 1005107 - Include charsetMenu.properties in localized files. r=Pike, a=sledru - 51262a06149a |
Ethan Tseng | Bug 1006530 - Closing a audio RTSP streaming via tab page causes system crash. r=sworkman, a=bajaj - 4f28715f9db6 |
r= means reviewed by
a= means uplift approved by
Previous changelogs:
Original post blogged on b2evolution.
http://sylvestre.ledru.info/blog/2014/05/20/changes-firefox-30-beta4-to-beta5
|
Sylvestre Ledru: Changes Firefox 30 beta3 to beta4 |
Extension | Occurrences |
cpp | 6 |
jsm | 4 |
js | 4 |
ini | 3 |
html | 2 |
h | 2 |
xul | 1 |
txt | 1 |
nsi | 1 |
nsh | 1 |
css | 1 |
Module | Occurrences |
browser | 7 |
dom | 5 |
content | 4 |
caps | 4 |
toolkit | 2 |
services | 1 |
netwerk | 1 |
layout | 1 |
build | 1 |
List of changesets:
Shawn Huang | Bug 1000961 - Make DBusReplyHandler use thread-safe ref-counting. r=echou, a=sledru - 306759b08bbf |
Ryan VanderMeulen | Backed out changeset ccde75e4b1af (Bug 1004152) for Mnw bustage. DONTBUILD - 1c4fdb3d772d |
Marco Castelluccio | Bug 981085 - Stop using OS.File in apps code. r=fabrice, a=lsblakk - ed09e2b74d14 |
Marco Castelluccio | Bug 972927 - Re-enable dom/apps tests on b2g. r=RyanVM, a=test-only - 9c41e6f07c3e |
Marco Castelluccio | Bug 991246 - Fix "aIdsApp is undefined" error in OperatorApps.jsm. r=cjc, a=lsblakk - a3d8c7c4f462 |
Carmen Jimenez | Bug 992589 - OperatorApps.jsm errors when running with and without Single Variant apps. r=ferjm, a=lsblakk - bbac2a994298 |
Shane Caraveo | Bug 983481 - Open a post activation landing page. r=markh, a=lsblakk - 315f0fda0470 |
Timothy Nikkel | Bug 1000423 - Properly convert from appunits/layout device pixels to layer pixels for composition bounds calculation. r=botond, a=lsblakk - d7abd8044d61 |
Mark Hammond | Bug 1006360 - prevent failures backing up bookmarks from stopping sync completing. r=rnewman, a=sylvestre - d202bb3a79cf |
Matt Woodrow | Bug 1003707 - Pass surfaces sizes in to CreateSourceSurfaceFromNativeSurface instead of trying to extract it from cairo. r=Bas, a=sledru - 7d945895a6d9 |
Nicholas Hurley | Bug 1007850 - Don't reset seer if it's not enabled. r=mcmanus, a=sledru - 9c27fdffe6f1 |
Ryan VanderMeulen | Backed out changeset 7d945895a6d9 (Bug 1003707) for bustage. - eb84c3250ae3 |
Marco Castelluccio | Bug 915879 - Wait for _writeFile to finish before continuing. r=fabrice, a=lsblakk - c81fd101b5a2 |
Robert Strong | Bug 1004168 - Add an INI file option to prevent requiring a reboot when there are files in use. r=jmathies, a=lsblakk - afcec252f3b7 |
Chris Pearce | Bug 1005622 - Reset media queues in Android media seek so that we don't think we're still at EOS after playing to EOS and then seeking. r=edwin, a=sledru - 63b001b6f985 |
Nathan Froyd | Bug 1009042 - add example.net to server-locations.txt; r=jmaher - 913fb15c7218 |
Bobby Holley | Bug 995943 - Clean up some silly stuff surrounding prefs in CAPS. r=bz - c1b7c8d03129 |
Bobby Holley | Bug 995943 - Allow access to file:// URIs from pref-whitelisted sites. r=bz a=lsblakk - 5b3bfd0a529a |
Edwin Flores | Bug 977089 - Don't pass ID3 headers to GStreamer. r=cpearce, a=lsblakk - e414a4798c7c |
Gijs Kruitbosch | Bug 1003542 - Remove extra space at bottom of single-item menus in bookmarks menu button panel menus. r=mikedeboer, a=lsblakk - d27918134b3d |
r= means reviewed by
a= means uplift approved by
Previous changelogs:
Original post blogged on b2evolution.
http://sylvestre.ledru.info/blog/2014/05/20/changes-firefox-30-beta3-to-beta4
|
Florian Qu`eze: Summer of Code 2014 projects |
The coding period is starting for Google Summer of Code 2014. I am pleased to list the 28 projects (7 more than last year!) that are mentored this year under the Mozilla banner.
The title of each project is linked to the location where the student will be posting weekly updates on their progress, if you want to follow along with a project you are interested in. I’m sure they would appreciate any help or advice you have :-) Please help them write useful code during the summer!
http://blog.queze.net/post/2014/05/20/Summer-of-Code-2014-projects
|
Andy McKay: Front end complexities |
There are many sins in recruiting. One of them is the broad categorisation of developers as front or back-end. But for that a new trend has been emerging and will continue to get stronger, a front-end developer encompasses a lot of skill sets and can't be easily classified.
Traditionally you take a site by getting some HTML, returning it from a server and slapping some HTML, JS and CSS on it. For this you'd expect a front-end developer to be heavily presentation oriented and wield CSS like a mighty sword.
But these days you'll see a lot more apps where the main work is done in the client and the server is just an API to return data (if one exists at all). Yet still developers are broadly placed into a bucket as a "front-end developer". In a world where lots of the logic and presentation is done in the front-end, does that make sense?
Take a good developer who can take data from multiple sources, store and sort it efficiently, test it well and have it accessible in a good API. So, does that describe a task on the front or back-end?
That could just as easily be a developer working on the back-end as a developer working in the front-end. You need to build, or use an existing framework to do all that on the front-end. For that you don't need to do any presentation or CSS work.
So when you think of hiring a "front-end" developer, think more importantly about what you expect that person to be doing: frameworks, presentation, performance, localisation, data... the list goes on.
|
Byron Jones: happy bmo push day! |
the following changes have been pushed to bugzilla.mozilla.org:
note: 1010751 changes the “from” header in email bugzilla.mozilla.org sends from:
From: bugzilla-daemon@mozilla.org
to:
From: "Bugzilla@Mozilla" <bugzilla-daemon@mozilla.org>
it’s possible this change may impact mail filters which current perform an exact match on the from field.
discuss these changes on mozilla.tools.bmo.
http://globau.wordpress.com/2014/05/20/happy-bmo-push-day-94/
|
Just Browsing: Wrapping the DOM Window Object |
In order to enable Kitt, our iPhone web browser, to run browser extensions, we needed a way to run content scripts in a webpage. In Chrome, content scripts are run in a sandbox to prevent the two contexts from interfering with each other. They share only the window
object. Although there are tantalizing signs that something similar might be possible on iOS 7, we weren’t sure whether this would be acceptable to Apple, so we decided to inject content scripts straight into the webpage and isolate them using closures.
This has been surprisingly successful, but we did start to run into problems when a content script uses jQuery on a webpage that also uses jQuery. The problem is the shared DOM. jQuery (and many other JavaScript frameworks) create a global symbol by hanging a new property off the window object. Since the window is shared, the window.$
might get overwritten. This doesn’t happen in Chrome because the DOM window isn’t really shared with the content scripts. Instead, a wrapper is used to isolate the JavaScript contexts so they only see their own expando properties. In this way each context can have a different window.$
property.
At first glance, writing a complete wrapper that explicitly wraps every window property seemed like a big effort, so we first tried to solve the immediate problem of jQuery conflicts in the easiest manner possible (some might call this laziness but I prefer to think of it as “proof of concept”):
var wrapper = Object.create(window); (function(window) { // content script })(wrapper);
By using Object.create
we get a wrapper whose prototype is the original window. The content scripts can still see the window’s expando properties, unless it overrides them, but the reverse is not true. Mission accomplished: loading jQuery into a content script will not mess up the native jQuery of the webpage. Just one problem: when we took this super lightweight wrapper for a test drive, we got an “Illegal invocation” error every time we tried to call one of its methods. Turns out that when you call methods on a DOM window, the this
pointer has to point at the actual window object. Attempt number two looked like this:
var wrapper = Object.create(window); for (var prop in window) { if (typeof(window[prop]) === 'function') { (function(prop) { wrapper[prop] = function() { return window[prop].apply(this, arguments); } })(prop); } }
This solves the “illegal invocation” problem. Right away, however, another issue cropped up. Content scripts that use JavaScript are likely to do so by accessing the $
symbol on the global object rather than referencing it as window.$
. So they will still be using the jQuery from the webpage. We could override the $
symbol explicitly, but this would be a jQuery-only solution that wouldn’t work for other libraries. After some head-scratching, we realized that we could create our own pseudo-global object using with
:
(function(window) { with (window) { // content script } })(wrapper);
As my colleague pointed out, usage of with
is generally frowned on due to the very characteristic we are exploiting here. Unfortunately, jQuery was still malfunctioning. More investigation revealed that the cause was the jQuery.isWindow
function. That’s right, jQuery doesn’t consider an object to be a window unless it is equal to its own window
property. And while we never found any explanation for this, our wrapper resisted all efforts to change the value of this property when using the DOM window as its prototype.
At this point, we gave up on the prototype altogther and wrapped everything:
var wrapper = {}; for (var prop in window) { (function(prop) { if (typeof(window[prop]) === 'function') { wrapper[prop] = function() { return window[prop].apply(this, arguments); } } else { Object.defineProperty(wrapper, prop, { 'get': function() { if (window[prop] === window) { return wrapper; } else { return window[prop]; } }, 'set': function(value) { wrapper[prop] = value; } }); })(prop); }
That’s the wrapper we’re using now and, combined with usage of with
as described above, it seems to be a pretty good approximation of the wrapper used in Chrome content scripts. And while it’s considerably longer than our initial naive attempt, it isn’t as complex as we had feared. There’s a lesson in there somewhere.
http://feedproxy.google.com/~r/justdiscourse/browsing/~3/18UPBStmVrk/
|
Tom Farrow: So, what’s a MozWeekend? |
Mozilla Weekend London is undergoing rapid planning, aimed at mid-July. Registration forms, for interested people, have been sent out, but the question has been risen, what is a Mozilla Weekend?
The words Mozilla Weekend mean exactly how they sound. A weekend of Mozilla. There are no limits to the usage of the term, but rather guidelines on principles they should follow, and that the event should not be limited to a single area of Mozilla.
Mozilla Weekend is a framework and toolkit for planning and running events. We noticed that although there are lots of resources out there explaining how to run an event, there are not many resources to be used during the planning and execution, only explanations on how to run the event. That’s what this project, ultimately, wants to change.
The branding, however, is completely optional. We don’t mind if you use our toolkit and framework (which are under development), at all, even without using the branding.
Mozilla Weekend London is community engagement and building event. We don’t have any focus on growing our community with this event. Instead, we want to build the people in the UK into a much stronger, thus powerful group.
We’ll be fitting in talks from Mozillians from different areas, explaining their roles and viewpoints on Mozilla right now, these talks having a strong emphasis on how we can form a better and stronger community.
Firefox (OS) Workshops, webmaker mini-jams, and groups discussions will all be prominent features. We want to truly create bonding between people in our community, so creating smaller groups where people can truly hear the voice of one-another is important to us.
Besides that, there will be a lot of social time. Pizza, coke, and conversation is all on the agenda.
The best way to contact us is via discourse. This will make our answers public and available for anyone else to see, and join in on the discussion. Simply sign up, hit new topic, and select London as the category.
If you need a faster response, or want to privately contact us, mozweekend@mozilla-community.org will route to myself and Elio who can answer most questions, or direct you in the right place if not.
https://tomfarrow.info/blog/2014/05/19/so-whats-a-mozweekend/
|
Alex Clark: Matplotlib Plotting Cookbook Review |
I was given a copy of Matplotlib Plotting Cookbook by Alexandre Devert and asked to review it. Thanks PACKT! Here is my review.
But first, I'll mention I've worked on two projects recently that involved rendering matplotlib graphs directly to the browser i.e. via content-type: image/png. This is fun! It's particularly enjoyable when you are trying to avoid performing the task "the right way", which is arguably outputting JSON to some JavaScript graphing library e.g. Highcharts. The dependencies are heavy i.e. pip install numpy, etc. but not that heavy and once they are installed, your web application can output graphs rivaling those produced by JavaScript, all written in Python [1]. Highly recommended!
I think the code examples in Chapter 1 alone are worth the price of admission. Here is a video of me walking through the Chapter 1 code examples:
You'll notice the typical fare here: bar, line and pie graphs along with some more complex boxplot, histogram, horizontal bar, scatter and triangle graphs, all in various colors. For reference, here are the excerpted commands called to produce these graphs:
Chapter 2 is all about customization e.g. via matplotlibrc. Here is a video of me walking through the Chapter 2 code examples:
For reference, here is the sample matplotlibrc included with the matplotlib distribution (lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc):
As you can see, there are a lot of knobs you can turn here.
Chapter 3 is all about "annotations". Here is a video of me walking through the Chapter 3 code examples:
"Annotations" includes related topics such as adding shapes and controlling tick spacing and labeling.
Chapter 4 is all about "working with figures". Here is a video of me walking through the Chapter 4 code examples:
"Working with figures" includes obvious topics like subplot and less obvious topics like setting the aspect ratio.
Chapter 5 is all about "working with file output". For reference, here are some of the images produced by the examples in this chapter (I wrote jpg files instead of png files due to a problem with my libpng: RuntimeError: Could not create write struct.)
Also covered in this chapter is pdf output.
Chapter 6 is all about "working with maps".
This chapter also introduces the imshow command.
Chapter 7 is all about "working with 3D figures".
For reference, here are the excerpted commands called to produce these graphs:
Chapter 8 is all about working with the "user interface" interactively.
Additionally, all of the popular graphical windowing environments are discussed: Tkinter, wxWidgets, GTK, Pyglet (three out of four of which I was able to install; GTK 2 vs GTK 3 confused me and I ran out of time debugging it.
Overall I enjoyed this book and would recommend buying it.
(You should probably hire me or follow me on Twitter or both. And speaking of PACKT, you should definitely buy my book too.)
[1] | Yes, I'm familiar with Bokeh. |
http://blog.aclark.net/2014/05/19/matplotlib-plotting-cookbook-review/
|
Joel Maher: Looking for long term trends and patterns in how I work |
Early last year (2013), I noticed I would work really productive for a couple weeks, and then get in a rut for a week here and there. After discussing this perceived trend with Clint, I started tracking it every week (end of work day on Friday). I have been tracking it for a year, and now I have data to examine in more detail:
For the first part of last year (through September 2013), I would go in 6 week cycles which appeared to be about 1 week after the uplifts. Oddly enough I wasn’t doing any specific work for uplifts, but I do recall a lot of odd issues that required debugging for each uplift. Quite possible the day or two spent handling these issues resulted in me getting backlogged on emails.
Oddly enough when I transitioned from full time mobile automation -> full time performance automation, my cycles became more regular. One exception was a focused project development week early in 2014 which had me doing other tasks and getting behind on a few other projects.
There is no direct correlation in the health data, but I have some theories. I record my general feeling of health (for the most part physical, not emotional). This is pure judgemental and there is no science behind it. 10 is good, 0 is bad, so when there is a dip in health on the graph, I usually see an increase in email volume the next week. No explanation for that, just an observation.
In summary, I have enjoyed looking back on this data. It was good to see a trend for most of 2013. Maybe next year I will see a different trend or pattern.
http://elvis314.wordpress.com/2014/05/19/looking-for-long-term-trends-and-patterns-in-how-i-work/
|
William Quiviger: Rebooting my blog |
My blog has been in a state of comatose for more than a year now and I’m excited to announce that it has finally woken from its long slumber! I’ve never been a big fan of blogging but I always made it a point to write a post once in a while to keep the community abreast with what I was up to. And then...alas, my laziness got the best of me in 2013 and I completely stopped posting anything. Like an abandoned garden invaded by thick prickly weeds, my blog got saturated with spam comments which rendered it unusable, requiring a lengthy and tedious clean-up and update of my blog platform (ie. Dotclear) which I naturally kept postponing to that ever-elusive “when I'll have more time” moment...
Anyway, this state of affairs obviously had to come to an end. I’m working on so many new exciting projects right now that this wretched laziness has been supplanted by a renewed enthusiasm to blog and share!
A lot has happened since my last blog post. The Mozilla Reps program, which I had been working on for more than 2 years, has made leaps and strides and is now in the able hands of Brian King and Rosana Ardila. This passing of the torch coincided with my switching teams last December, joining the fantastic CBT (Community Building Team) and reporting to Mozillian-extraordinaire, David Boswell. In my new role, I'm focusing my time on supporting functional teams across the project and helping them design for participation.
This blog reboot is all about sharing updates and insights on these new exciting projects and partnerships and all the great stuff the CBT is working on to help grow and strengthen Mozilla's contributor base.
Happy reading (I hope)!
http://somethin-else.org/index.php?post/2014/05/19/Rebooting-my-blog
|
Honza Bambas: New Firefox HTTP cache now enabled on Nightly builds |
Yes, it’s on! After a little bit more than a year of a development by me and Michal Novotn'y all bugs we could find in our labs, offices and homes were fixed. The new cache back-end is now enabled on Firefox Nightly builds as of version 32 and should stay like that.
The old cache data are for now left on disk but we have handles to remove them automatically from users’ machines to not waste space since it’s now just a dead data. This will happen after we confirm the new cache sticks on Nightlies.
The new HTTP cache back end has many improvements like request prioritization optimized for first-paint time, ahead of read data preloading to speed up large content load, delayed writes to not block first paint time, pool of most recently used response headers to allow 0ms decisions on reuse or re-validation of a cached payload, 0ms miss-time look-up via an index, smarter eviction policies using frecency algorithm, resilience to crashes and zero main thread hangs or jank. Also it eats less memory, but this may be subject to change based on my manual measurements with my favorite microSD card which shows that keeping at least data of html, css and js files critical for rendering in memory may be wise. More research to come.
Thanks to everyone helping with this effort. Namely Joel Maher and Avi Halachmi for helping to chase down Talos regressions and JW Wang for helping to find cause of one particular hard to analyze test failure spike. And also all early adopters who helped to find and fix bugs. Thanks!
browser.cache.disk.metadata_memory_limit
browser.cache.disk.preload_chunk_count
Since these tests are pretty time consuming and usually not very precise, I was only testing with page 2 of my blog that links some 460 images. Media storage devices available were: internal SSD, an SDHC card and a very slow microSD via a USB reader on a Windows 7 box.
[ complete page load time / first paint time ]
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 7.4s / 450ms | 880ms / 440ms | 510ms / 355ms | 5s / 430ms |
cache v2 | 6.4s / 445ms | 610ms / 470ms | 470ms / 360ms | 5s / 440ms |
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 7.4s / 635ms | 760ms / 480ms | 545ms / 365ms | 5s / 430ms |
cache v2 | 6.4s / 485ms | 1.3s / 450ms | 530ms / 400ms* | 5.1s / 460ms* |
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 13s / 1.4s | 1.1s / 540ms | 560ms / 440ms | 5.1s / 430ms |
cache v2 | 6.4s / 450ms | 1.7s / 450ms | 830ms / 540ms* | 5.4s / 470ms* |
* We are not keeping any data in memory (bug 975367 and 986179) what seems to be too restrictive. Some data memory caching will be needed.
The way I have measured browser UI jank (those hangs when everything is frozen) was very simple: summing every stuck of the browser UI, taking more then 100ms, between pressing enter and end of the page load.
[ time of all UI thread events running for more then 100ms each during the page load ]
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 0ms | 600ms | 0ms | 0ms |
cache v2 | 0ms | 0ms | 0ms | 0ms |
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 600ms | 600ms | 0ms | 0ms |
cache v2 | 0ms | 0ms | 0ms | 0ms |
Cache version | First visit | Cold go to 1) | Warm go to 2) | Reload |
---|---|---|---|---|
cache v1 | 2500ms | 740ms | 0ms | 0ms |
cache v2 | 0ms | 0ms | 0ms | 0ms |
All load time values are medians, jank values averages, from at least 3 runs without extremes in attempt to lower the noise.
1) Open a new tab and navigate to a page right after the Firefox start.
2) Open a new tab and navigate to a page that has already been visited during the browser session.
|
Henrik Skupin: Automation Training Day on May 21st |
For anyone who is interested in Test Automation we offer again a full day of trainings. You will be able to learn more about Javascript and Python, which are the languages used a lot for projects in our Automation team.
All the details about this all day event you can read here.
Please spread the news around so that we will have a fruitful day with a lot of discussions, and small or larger tasks accomplished.
http://www.hskupin.info/2014/05/19/automation-training-day-on-may-21st/
|
Kaustav Das Modak: Next steps for the Evangelism Task Force in Mozilla India |
|
Toni Hermoso Pulido: Reflexions sobre Mozilla avui en dia i m'es enll`a… |
Durant les darreres setmanes s'han succe"it diferents not'icies que han posat al centre d'atenci'o medi`atic Mozilla. Despr'es de tot aix`o, he arribat a la conclusi'o que calia fer l'esforc d'escriure quin eren els meus pensaments de forma p'ublica, per respecte a mi mateix, per`o sobretot tamb'e per la resta de companys que col·laboren en aquest projecte i especialment per la gent del meu pa'is a qui em dec pel que ha estat sobretot la meva tasca en aquesta iniciativa.
S'on molts anys que he contribu"it en el projecte Mozilla, amb els primers binaris del Firefox empaquetats en catal`a, que encara es poden trobar a l'FTP de Softcatal`a http://ftp.softcatala.org/softcatala/firefox/, i que ara ja tenen m'es de 10 anys… Estic orgull'os d'haver pres llavors la decisi'o de comencar a col·laborar-hi, perqu`e gr`acies a aix`o he pogut cr'eixer com a persona en molts aspectes, perqu`e m'ha facilitat poder compartir visions amb altres companys d'arreu del m'on, i perqu`e he pogut ajudar que la meva llengua, el catal`a, i tamb'e d'altres en situaci'o de minoritzaci'o (com ara l'aragon`es) puguin tenir una oportunitat 'digital' en aquest m'on on vivim… Dit aix`o, he de dir que ja fa anys que em trobo inc`omode amb aquesta participaci'o. La darrera vegada ha estat amb la decisi'o de permetre l''us del DRM en el navegador Firefox. Podeu llegir-ne diferents opinions al respecte extensament en diferents articles que es troben a la xarxa.
En tot cas, a nivell personal, la pregunta que em faig 'es: ?d'on sorgeix aquesta incomoditat que expresso? Doncs, b`asicament de les expectatives que em puc fer a partir de la meva participaci'o respecte a la realitat que percebo de l'organitzaci'o.
En aquesta percepci'o hi t'e a veure tant la part que percep com aquella percebuda i, sens dubte, totes dues han canviat objectivament al llarg d'aquests 10 anys. A continuaci'o mirar'e de detallar-ne, parcialment, l'evoluci'o.
Fa 10 anys, coincidint amb un recent canvi de govern i despr'es d'anys de sensibilitzaci'o social —tot i que amb una q"uestionable transversalitat i impacte—, hi havia un ambient d'esperanca pel que fa a les perspectives del programari lliure a Catalunya. En aquell context, un linuxaire en`ergic i jove com era jo llavors va comencar a col·laborar amb Softcatal`a i va assumir de primera m`a la traducci'o de la que era la suite Mozilla i poc despr'es els nous Firefox i Thunderbird.
Podr'iem dir que Mozilla havia nascut 6 anys abans, quan Netscape, l'empresa que desenvolupava la llavors suite d'Internet amb el mateix nom va decidir alliberar el codi d'aquest programari davant l'esdevinguda supremacia de l'Internet Explorer, navegador de s`erie dels populars nous sistemes operatius Windows. Mozilla, que era el codi en clau de la suite que distribu"ia Netscape, va esdevenir ensenya del que seria el moviment del codi obert (open source), que simplificadament podr'iem considerar com la resoluci'o del conflicte entre la cultura del programari lliure i la de les grans empreses de programari. El projecte Mozilla va avancar, no amb pocs problemes, al llarg dels anys sota el paraig"ues de diferents organitzacions: Netscape, AOL i finalment la Fundaci'o Mozilla, que va engendrar m'es endavant la seva Corporaci'o.
En aquells moments, el moviment del programari lliure, deixant apartada la disputa dial`ectica entre el que 'es codi obert i programari lliure, va bolcar-se en Mozilla per tal de batre l'enemic que representava Microsoft. L'empresa de Redmond no creia en Internet realment, essencialment perqu`e el model de negoci que aquesta obria representava una amenaca per al seu model basat en productes d'escriptori. Fruit d'aquesta lluita, encapcalada per Mozilla amb l'emblema del Firefox, la Internet, al voltant del protocol web, va madurar fins a nivells que ning'u hagu'es imaginat pocs anys abans, donant lloc al que es va con`eixer com a Web 2.0 i, poc despr'es, tamb'e a les actuals i omnipresents xarxes socials.
Qui hagu'es dit que el llenguatge JavaScript, obra tamb'e de Mozilla, que s'utilitzava al principi per a poc m'es que per a mostrar molestos di`alegs a la finestra del navegador, podria acabar ocupant a dia d'avui pr`acticament tota la diversitat de les aplicacions inform`atiques, tant a nivell de client com de servidor…
Gr`acies a, entre d'altres, a aquest 'impetu darrere de Mozilla, Silicon Valley va comencar a ser la Meca mundial de la innovaci'o; ja no tant en la fabricaci'o de maquinari i components inform`atics, sin'o en la creaci'o de programari cada cop m'es complex que sovint nom'es residia a 'Internet', el que avui en dia anomenem el 'Cloud'…
La conjunci'o de la xarxa i el codi obert va permetre la re-invenci'o i l'`exit de companyies com Apple, i l'emerg`encia de nous actors, ara esdevinguts hegem`onics, com 'es el cas de Google.
Finalment Mozilla, amb el seu navegador Firefox, podr'iem dir que va esdevenir victoriosa en la guerra dels navegadors, aconseguint que Microsoft perd'es la seva gran quota de poder i fent a m'es que s'erig'is una altra realitat econ`omica i social al voltant de la xarxa WWW. En aquella guerra encara no existia el concepte de l'”Open Web” que Mozilla ha utilitzat els darrers anys, i les banderes que erig'iem soldats rasos com jo eren el respecte pels est`andards oberts a la xarxa i el programari lliure (m'es que no de fet el codi obert). Crec que molts dels que vam ser membres de la infanteria d'aquelles confrontacions vam quedar embriagats d'aquella `epica…
Per`o, el m'on ha canviat substancialment despr'es d'aquella guerra, i molts crec que no hem estat conscients fins recentment de l'abast de les transformacions que hi hagut, de les quals, en certa manera, ens podr'iem arribar a sentir corresponsables o c`omplices. Tamb'e 'es el cas de Mozilla… La Internet, o especialment el Web, que en definitiva aquesta havia fet emergir, es va continuar desenvolupant a un ritme que va acabar esberlant les parets d'aquella incipient fundaci'o. Google, Facebook i alguns altres han contribu"it a fer que el Web arrib'es a usos inimaginables fins llavors: reinventant les relacions personals i tamb'e els modes de producci'o i col·laboraci'o. Per`o Mozilla, de ser inicialment l'impulsor principal en el desenvolupament del Web, va acabar esdevenint un actor m'es, important, per`o un actor m'es en definitiva…
Innovar en el WWW 'es car i, sobretot, a l'hora de fer un navegador, que no deixa de ser la porta d'entrada a Internet per a la immensa majoria de la gent (deixant apart les apps m`obils). Com a m'inim hi ha el cost del salari dels experts i desenvolupadors que ho fan t`ecnicament possible. I els diners, en el cas de Mozilla, avui en dia provenen majorit`ariament de Google.
Podr'iem considerar que Google ha agra"it aix'i a Mozilla la rellev`ancia que va tenir en la seva pujanca, per`o per a Mozilla, el que va ser inicialment un acord comercial ha passat a ser una relaci'o d'inc`omode depend`encia no nom'es econ`omica sin'o tamb'e de model tecnol`ogic. Mozilla no t'e m'es remei que seguir l'estela que marquen actors amb m'es recursos econ`omics que ella, perqu`e s'on precisament aquests els que estan creant la nova Internet que s'est`a construint, i on altres a m'es s'hi estan enriquint r`apidament i profusa.
T'e sentit que Mozilla cerqui desesperadament diversificar les fonts d'ingressos per tal d'evitar la pr`acticament total depend`encia que t'e de Google i, en aquest sentit, cal entendre la recent proposta d'afegir anuncis a la p`agina inicial i tamb'e la col·laboraci'o amb diferents operadores telef`oniques amb el desenvolupament del sistema operatiu m`obil Firefox OS.
Mozilla, per a continuar sent un actor important en el sector de la Internet, es veu obligada a ser cada cop m'es com la resta dels seus competidors. Cal una gran plantilla de treballadors per tal de no sortir de la carretera de la marxa tecnol`ogica, a m'es amb l'agreujant de trobar-se f'isicament en un dels indrets m'es cars i especulatoris del m'on (precisament per acci'o de l'efecte del propi WWW). Al mateix temps, per tal de ser vist i participar com un membre m'es en la lliga dels grans, s'incorre en la necessitat de tenir fastuoses seus a San Francisco o Paris, i provar de deixar la major empremta possible en el business-aquelarre del Mobile World Congress de Barcelona.
I, en tot aix`o, quin paper juga aquella armada global de 'gladiadors per la llibertat' que va emergir durant la guerra dels navegadors? Aqu'i 'es on sorgeix el conflicte amb el que seria 'la comunitat'. En una comunitat, segons el paradigma del codi obert del bazar (p. ex. el kernel de Linux), hi trobar'iem grups de participants diversos treballant al voltant d'un mateix projecte. Podr'iem trobar-hi empreses, 'freelancers' i voluntaris, els quals poden estar motivats tant per interessos lucratius com tamb'e per motius aparentment desinteressats; alhora, hi pot haver o no una entitat, com ara una fundaci'o, que estableixi una governanca entre els diferents participants.
En el cas de Mozilla, el 'core' de treballadors de Netscape sempre ha estat tamb'e el nucli principal en aquesta comunitat. Per`o, per la intr'inseca acceleraci'o del que implica el desenvolupament d'Internet, avui els treballadors de la corporaci'o de Mozilla representen amb escreix la participaci'o majorit`aria en la producci'o del que 'es el projecte Mozilla. Nom'es a certa dist`ancia hi segueixen empreses col·laboradores en el Firefox OS, com 'es el cas de Telef'onica. En aquest context, el que molta gent dins de Mozilla ent'en actualment com a comunitat 'es tothom qui, essencialment de forma volunt`aria, participa en tasques com ara la localitzaci'o per`o, sobretot, en l'amplificaci'o del soroll del m`arqueting social.
Tot i que el paper d'aquesta massa volunt`aria podr'iem dir que no 'es central en els processos de Mozilla, 'es innegablement un valor afegit per arribar all`a on la compet`encia sovint ho t'e molt m'es dif'icil. El conflicte 'es que aquesta massa sovint beu de l'idealisme de les guerres passades i aix`o no lliga massa b'e amb l'organitzaci'o actual tal i com 'es, o si es vol, com s'ha vist obligada a ser. En aquest sentit, programes de captaci'o de voluntaris del tipus Reps, han provat de generar un nou ex`ercit de voluntaris 'compliant' amb la nova realitat que ha emergit, m'es as`eptics en ideologia i tamb'e m'es amarats en 'branding'. En la mateixa l'inia, cal entendre la preparaci'o esdeveniments del tipus Mozcamps o MozSummits, que reuneixen cada vegada m'es i m'es gent d'arreu del m'on per tal de crear un sentiment d'experi`encia (i marca) compartida d'acord amb els objectius que van succeint-se en cada edici'o per`o, en tot cas, sense voler entrar en la pregunta m'es profunda, i alhora m'es evident, de… per i per a qu`e som aqu'i?
Malauradament, com que les pressions socioecon`omiques i tecnol`ogiques que explico a dalt condicionen m'es i m'es Mozilla, els encarregats en certes `arees de l'organitzaci'o s'on contractats i portats a parametritzar cada cop m'es com han de ser les contribucions i quin 'es el retorn que se n'ha d'esperar simplement per poder aix'i mantenir tota l'estructura amb el cap sobre l'aigua mentre puja la marea.
Arribats aqu'i, el dilema que crec que podem tenir molts dels que podem estar vinculats amb el pensament del programari lliure o de les llibertats civils 'es pensar que Mozilla ha esdevingut talment 'Too big to fail'.
En aquestes circumst`ancies, crec que el millor 'es assumir on som i comencar ja a treballar en una minimitzaci'o d'uns hipot`etics danys futurs. Per posar un exemple, aixoplugats en el si de Mozilla han pogut n'eixer projectes valents com ara Persona, en pro d'una Internet distribu"ida, per`o que ara ja no tenen continu"itat en l'organitzaci'o per la necessitat de focalitzar-se en treballar a partir d'una realitat basada m'es en productes i serveis centrals. Aquests queden a l'espera que tercers puguin utilitzar-los i fer-los evolucionar…
En el sentit d'aquest comentari, considero que el m'es adequat 'es que acceptem all`o que Mozilla no 'es ni podr`a materialment ja ser, sobretot quan sovint ens hem deixat portar per les projeccions que fem d'uns ideals propis. De la mateixa manera, demanaria a l'organitzaci'o abandonar l''us de certes evocacions discursives (que normalment s'articulen ja buidades de tot significat d'antuvi), descartar voler liderar cap 'moviment global' (fet que a m'es pot fer despertar moltes susceptibilitats en el context geopol'itic actual) per`o, en canvi, prestar-se plenament i conscientment a continuar excel·lint tecnol`ogicament en els principis de codi obert, fet que pot portar a conrear productes l'iders com han estat el Firefox i podria ser en un futur tamb'e el Firefox OS. El que 'es m'es, persones com jo continuarem col·laborant en tots aquells aspectes on tinguem converg`encia d'interessos que, sens dubte, podran continuar essent-ne molts.
M'imagino que tot aquest afer del DRM al Firefox ha estat un bon 'reality check' per a molts dels col·laboradors del projecte Mozilla, jo el primer… Per`o aix`o ara ens ha de permetre l'oportunitat d'afrontar de cara i de forma nua els reptes que ens presenta la societat tecnol`ogica actual des de la nostra i pr`opia perspectiva, que no 'es una tasca f`acil ni a vegades tampoc agradable…
Fotografia del monument que sarc`asticament alguns podrien anomenar: «Memorial als Caiguts per la Comunitat de Mozilla» a la seu de San Francisco de Mozilla.
http://www.cau.cat/blog/reflexions_sobre_mozilla_avui_en_dia_i_mes_enlla
|