mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Mozilla's Webmaker app will make it easy for anyone to create Web apps on ... - The Next Web

Nieuws verzameld via Google - do, 23/10/2014 - 15:35

Mozilla's Webmaker app will make it easy for anyone to create Web apps on ...
The Next Web
Mozilla is working on an app for Android, iOS and Firefox OS that gives smartphone users the ability to easily create and share Web apps. It's called Webmaker, after the initiative that Mozilla created to promote Web literacy. The app is still in ...

Categorieën: Mozilla-nl planet

Gavin Sharp: r=gfritzsche

Mozilla planet - do, 23/10/2014 - 00:14

I’m happy to announce that Georg Fritzsche is now officially a Firefox reviewer.

Georg has been contributing to Firefox for a while now – his contributions started with done some great work on Firefox’s Telemetry system, as well as investigating stability issues in plugins and Firefox itself. He played a crucial role in building the telemetry experiments system, and more recently has become familiar with a few key parts of the Firefox front-end code, including our click to play plugin UI and the upcoming “FHR self support” feature. He’s a thorough reviewer with lots of experience with Mozilla code, so don’t hesitate to ask Georg for review if you’re patching Firefox!

Thanks Georg!

Categorieën: Mozilla-nl planet

Matt Brubeck: A little randomness for Hacker News

Mozilla planet - do, 23/10/2014 - 00:00

In systems that rely heavily on “most popular” lists, like Reddit or Hacker News, the rich get richer while the poor stay poor. Since most people only look at the top of the charts, anything that’s not already listed has a much harder time being seen. You need visibility to get ratings, and you need ratings to get visibility.

Aggregators try to address this problem by promoting the items as well as popular ones. But this is hard to do effectively. For example, the “new” page at Hacker News gets only a fraction of the front page’s traffic. Most users want to see the best content, not wade through an unfiltered stream of links. Thus, very little input is available to decide which links get promoted to the front page.

As an experiment, I wrote a userscript that uses the Hacker News API to search for new or low-ranked links and randomly insert just one or two of them into the front page. It’s also available as a bookmarklet for those who can’t or don’t want to install the user script.

Install user script (may require a browser extension)

Randomize HN (drag to bookmark bar, or right-click to bookmark)

This gives readers a chance to see and vote on links that they otherwise wouldn’t, without altering their habits or wading through a ton of unfiltered content. Each user will see just one or two links per visit, but thanks to randomness a much larger number of links will be seen by the overall user population. My belief, though I can’t prove it, is that widespread use of this feature would improve the quality of the selection process.

The script isn’t perfect (search for FIXME in the source code for some known issues), but it works well enough to try out the idea. Unfortunately, the HN API doesn’t give access to all the data I’d like, and sometimes the script won’t find any suitable links to insert. (You can look at your browser’s console to see which which items were randomly inserted.) Ideally, this feature would be built in to Hacker News—and any other service that recommends “popular” items.

Categorieën: Mozilla-nl planet

Peter Bengtsson: localForage vs. XHR

Mozilla planet - wo, 22/10/2014 - 21:10

tl;dr; Fetching from IndexedDB is about 5-15 times faster than fetching from AJAX.

localForage is a wrapper for the browser that makes it easy to work with any local storage in the browser. Different browsers have different implementations. By default, when you use localForage in Firefox is that it used IndexedDB which is asynchronous by default meaning your script don't get blocked whilst waiting for data to be retrieved.

A good pattern for a "fat client" (lots of javascript, server primarly speaks JSON) is to download some data, by AJAX using JSON and then store that in the browser. Next time you load the page, you first read from the local storage in the browser whilst you wait for a fresh new JSON from the server. That way you can present data to the screen sooner. (This is how Buggy works, blogged about it here)

Another similar pattern is that you load everything by AJAX from the server, present it and store it in the local storage. Then you perdiocally (or just on onload) you send the most recent timestamp from the data you've received and the server gives you back everything new and everything that has changed by that timestamp. The advantage of this is that the payload is continuously small but the server has to make a custom response for each client whereas a big fat blob of JSON can be better cached and such. However, oftentimes the data is dependent on your credentials/cookie anyway so most possibly you can't do much caching.

Anyway, whichever pattern you attempt I thought it'd be interesting to get a feel for how much faster it is to retrieve from the browsers memory compared to doing a plain old AJAX GET request. After all, browsers have seriously optimized for AJAX requests these days so basically the only thing standing in your way is network latency.

So I wrote a little comparison script that tests this. It's here: http://www.peterbe.com/localforage-vs-xhr/index.html

It retrieves a 225Kb JSON blob from the server and measures how long that took to become an object. Equally it does the same with localforage.getItem and then it runs this 10 times and compares the times. It's obviously not a surprise the local storage retrieval is faster, what's interesting is the difference in general.

What do you think? I'm sure both sides can be optimized but at this level it feels quite realistic scenarios.

Categorieën: Mozilla-nl planet

Introducing the 2015 Knight-Mozilla Fellows

Mozilla Blog - wo, 22/10/2014 - 20:22
The Knight-Mozilla Fellowships bring together developers, technologists, civic hackers, and data crunchers to spend 10 months working on open source code with partner newsrooms around the world. The Fellowships are part of the Knight-Mozilla OpenNews project, supported by the John … Continue reading
Categorieën: Mozilla-nl planet

Doug Belshaw: Interim results of the Web Literacy Map 2.0 community survey

Mozilla planet - wo, 22/10/2014 - 19:02

Thanks to my colleague Adam Lofting, I’ve been able to crunch some of the numbers from the Web Literacy Map v2.0 community survey. This will remain open until the end of the month, but I thought I’d share some of the results.

 overview

This is the high-level overview. Respondents are able to indicate the extent to which they agree or disagree with each proposal on a five-point scale. The image above shows the average score as well as the standard deviation. Basically, for the top row the higher the number the better. For the bottom row, low is good.

 by location

Breaking it down a bit further, there’s some interesting things you can pull out of this. Note that the top-most row represents people who completed the survey, but chose not to disclose their location. All of the questions are optional.

Things that stand out:

  • There’s strong support for Proposal 4: I believe that concepts such as ‘Mobile’, 'Identity’, and 'Protecting’ should be represented as cross-cutting themes in the Web Literacy Map.
  • There’s also support for Proposal 1: I believe the Web Literacy Map should explicitly reference the Mozilla manifesto and Proposal 5: I believe a 'remix’ button should allow me to remix the Web Literacy Map for my community and context.
  • People aren’t so keen on Proposal 2: I believe the three strands should be renamed 'Reading’, 'Writing’ and 'Participating’. (although, interestingly, in the comments people say they like the term 'Participating’, just not 'Reading’ and 'Writing’ which many said reminded them too much of school!)

This leaves Proposal 3: I believe the Web Literacy Map should look more like a 'map’. This could have been better phrased, as the assumption in the comments seems to be that we can present it either as a grid or as a map. In fact, here’s no reason why we can’t do both. In fact, I’d like to see us produce:

Finally, a word on Proposal 5 and remixing. In the comments there’s support for this - but also a hesitation lest it 'dilutes’ the impact of the Web Literacy Map. A number of people suggested using a GitHub-like model where people can 'fork’ the map if necessary. In fact, this is already possible as v1.1 is listed as a repository under the Mozilla account.

I’m looking forward to doing some more analysis of the community survey after it closes!

Comments? Questions? Send them this way: @dajbelshaw or doug@mozillafoundation.org

Categorieën: Mozilla-nl planet

Benjamin Smedberg: How I Do Code Reviews at Mozilla

Mozilla planet - wo, 22/10/2014 - 18:00

Since I received some good feedback about my prior post, How I Hire at Mozilla, I thought I’d try to continue this is a mini-series about how I do other things at Mozilla. Next up is code review.

Even though I have found new module owners for some of the code I own, I still end up doing 8-12 review/feedback cycles per week. Reviews are only as good as the time you spend on them: I approach reviews in a fairly systematic way.

When I load a patch for review, I don’t read it top-to-bottom. I also try to avoid reading the bug report: a code change should be able to explain itself either directly in the code or in the code commit message which is part of the patch. If bugzilla comments are required to understand a patch, those comments should probably be part of the commit message itself. Instead, I try to understand the patch by unwrapping it from the big picture into the small details:

The Commit Message
  • Does the commit message describe accurately what the patch does?
  • Am I the right person to make a decision about this change?
  • Is this the right change to be making?
  • Are there any external specifications for this change? This could include a UX design, or a DOM/HTML specification, or something else.
  • Should there be an external specification for this change?
  • Are there other experts who should be involved in this change? Does this change require a UX design/review, or a security, privacy, legal, localization, accessibility, or addon-compatibility review or notification?
Read the Specification

If there is an external specification that this change should conform to, I will read it or the appropriate sections of it. In the following steps of the review, I try to relate the changes to the specification.

Documentation

If there is in-tree documentation for a feature, it should be kept up to date by patches. Some changes, such as Firefox data collection, must be documented. I encourage anyone writing Mozilla-specific features and APIs to document them primarily with in-tree docs, and not on developer.mozilla.org. In-tree docs are much more likely to remain correct and be updated over time.

API Review

APIs define the interaction between units of Mozilla code. A well-designed API that strikes the right balance between simplicity and power is a key component of software engineering.

In Mozilla code, APIs can come in many forms: IDL, IPDL, .webidl, C++ headers, XBL bindings, and JS can all contain APIs. Sometimes even C++ files can contain an API; for example Mozilla has an mostly-unfortunate pattern of using the global observer service as an API surface between disconnected code.

In the first pass I try to avoid reviewing the implementation of an API. I’m focused on the API itself and its associated doccomments. The design of the system and the interaction between systems should be clear from the API docs. Error handling should be clear. If it’s not perfectly obvious, the threading, asynchronous behavior, or other state-machine aspects of an API should be carefully documented.

During this phase, it is often necessary to read the surrounding code to understand the system. None of our existing tools are very good at this, so I often have several MXR tabs open while reading a patch. Hopefully future review-board integration will make this better!

Brainstorm Design Issues

In my experience, the design review is the hardest phase of a review, the part which requires the most experience and creativity, and provides the most value.

  • How will this change interact with other code in the tree?
  • Are there edge cases or failure cases that need to be addressed in the design?
  • Is it likely that this change will affect performance or security in unexpected ways?
Testing Review

I try to review the tests before I review the implementation.

  • Are there automated unit tests?
  • Are there automated performance tests?
  • Is there appropriate telemetry/field measurement, especially for error conditions?
  • Do the tests cover the specification, if there is one?
  • Do the tests cover error conditions?
  • Do the tests strike the right balance between “unit” testing of small pieces of code versus “integration” tests that ensure a feature works properly end-to-end?
Code Review

The code review is the least interesting part of the review. At this point I’m going through the patch line by line.

  • Make sure that the code uses standard Mozilla coding style. I really desperately want somebody to automated lots of this as part of the patch-submission process. It’s tedious both for me and for the patch author if there are style issues that delay a patch and require another review cycle.
  • Make sure that the number of comments is appropriate for the code in question. New coders/contributors sometimes have a tendency to over-comment things that are obvious just by reading the code. Experienced contributors sometimes make assumptions that are correct based on experience but should be called out more explicitly in the code.
  • Look for appropriate assertions. Assertions are a great form of documentation and runtime checking.
  • Look for appropriate logging. In Mozilla we tend to under-log, and I’d like to push especially new code toward more aggressive logging.
  • Mostly this is scanning the implementation. If there is complexity (such as threading!), I’ll have to slow down a lot and make sure that each access and state change is properly synchronized.
Re-read the Specification

If there is a specification, I’ll briefly re-read it to make sure that it was covered by the code I just finished reading.

Mechanics

Currently, I primarily do reviews in the bugzilla “edit” interface, with the “edit attachment as comment” option. Splinter is confusing and useless to me, and review-board doesn’t seem to be ready for prime-time.

For long or complex reviews, I will sometimes copy and quote the patch in emacs and paste or attach it to bugzilla when I’m finished.

In some cases I will cut off a review after one of the earlier phases: if I have questions about the general approach, the design, or the API surface, I will often try to clarify those questions before proceeding with the rest of the review.

There’s an interesting thread in mozilla.dev.planning about whether it is discouraging to new contributors to mark “review-” on a patch, and whether there are less-painful ways of indicating that a patch needs work without making them feel discouraged. My current practice is to mark r- in all cases where a patch needs to be revised, but to thank contributors for their effort so that they are still appreciated and to be as specific as possible about required changes while avoiding any words that could be perceived as an insult.

If I haven’t worked with a coder (paid or volunteer) in the past, I will typically always ask them to submit an updated patch with any changes for re-review. This allows me to make sure that the changes were completed properly and didn’t introduce any new problems. After I gain some experience, I will often trust people to make necessary changes and simply mark “r+ with review comments fixed”.

Categorieën: Mozilla-nl planet

Michael Kaply: Disabling Buttons In Preferences

Mozilla planet - wo, 22/10/2014 - 17:55

I get asked a lot how to disable certain buttons in preferences like Make Firefox the default browser or the various buttons in the Startup groupbox. Firefox does have a way to disable these buttons, but it's not very obvious. This post will attempt to remedy that.

These buttons are controlled through preferences that have the text "disable_button" in them. Just changing the preference to true isn't enough, though. The preference has to be locked, either via the CCK2 or AutoConfig. What follows is a mapping of all the preferences to their corresponding buttons.

pref.general.disable_button.default_browser
Advanced->General->Make Firefox the default browser
pref.browser.homepage.disable_button.current_page
General->Use Current Pages
pref.browser.homepage.disable_button.bookmark_page
General->Use Bookmark
pref.browser.homepage.disable_button.restore_default
General->Restore to Default
security.disable_button.openCertManager
Advanced->Certificates->View Certificates
security.disable_button.openDeviceManager
Advanced->Certificates->Security Devices
app.update.disable_button.showUpdateHistory
Advanced->Update->Show Update History
pref.privacy.disable_button.cookie_exceptions
Privacy->History->Exceptions
pref.privacy.disable_button.view_cookies
Privacy->History->Show Cookies
pref.privacy.disable_button.view_passwords
Security->Passwords->Saved Paswords
pref.privacy.disable_button.view_passwords_exceptions
Security->Passwords->Exceptions

As a bonus, there's one more preference you can set and lock - pref.downloads.disable_button.edit_actions. It prevents the changing of any actions on the Applications page in preferences.

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 34 beta1 to beta2

Mozilla planet - wo, 22/10/2014 - 17:31

  • 60 changesets
  • 135 files changed
  • 2926 insertions
  • 673 deletions

ExtensionOccurrences js32 cpp23 cc17 jsm9 html9 css9 jsx7 h7 ini3 sh2 patch2 mm2 manifest2 list2 xul1 xml1 txt1 py1 mozilla1 mk1 json1 build1

ModuleOccurrences browser60 gfx21 security12 content11 toolkit5 layout4 widget3 testing3 media3 gfx3 js2 xulrunner1 xpcom1 netwerk1 mobile1 +gfx1 dom1

List of changesets:

Justin DolskeBug 1068290 - UI Tour: Add ability to highlight New Private Window icon in chrome. r=MattN a=dolske - aa77bc7b59e3 Justin DolskeBug 1072036 - UI Tour: Add ability to highlight new privacy button. r=mattn a=dolske - d37b92959827 Justin DolskeBug 1071238 - UI Tour: add ability to put a widget in the toolbar. r=mattn a=dolske - 1c96180e6a5b Blair McBrideBug 1068284 - UI Tour: Add ability to highlight search provider in search menu. r=MattN a=dolske - 9d4b08eecd9a Joel MaherBug 1083369 - update talos.json to include fixes for mainthreadio whitelist and other goodness. r=dminor a=test-only - 184bc1bea651 Bas SchoutenBug 1074272 - Use exception mode 0 for our D3D11 devices. r=jrmuizel, a=sledru - 46d2991042df Gijs KruitboschBug 1079869 - Fix closing forget panel by adding a closemenu=none attribute. r=jaws, a=sledru - e6441f98f159 Patrick BrossetBug 1020038 - Disable test browser/devtools/layoutview/test/browser_layoutview_update-in-iframes.js. a=test-only - da7c401c5aa7 Jeff GilbertBug 1079848 - Large allocs should be infallible and handled. r=kamidphish, a=sledru - 03d4ab96c271 Mike HommeyBug 1081031 - Unbust xulrunner mac builds by not exporting all JS symbols (Bug 920731). r=bsmedberg, a=npotb - 5967c4a96835 Mark BannerBug 1081906 - Fix unable to start Firefox due to 'Couldn't load XPCOM'. r=bsmedberg, a=sledru - c212fd07fd32 Georg FritzscheBug 1079312 - Fix invalid log.warning() to log.warn(). r=irving, a=sledru - ae6317e02f72 Mike de BoerBug 1081130 - Fix importing contacts with only a phone number and fetch the correct format. r=abr, a=sledru - 1f7f807b6362 Simon MontaguTest for Bug 1067268. r=jfkthame, a=lmandel - 4f904d9bcff2 Simon MontaguBug 1067268 - Don't mix physical and logical coordinates when calculating width to clear past floats. r=jfkthame, a=lmandel - 29dd7b8ee41f JW WangBug 1069289 - Take |mAudioEndTime| into account when updating playback position at the end of playback. r=kinetik, a=lmandel - 31fc68be9136 David KeelerBug 1058812 - mozilla::pkix: Add SignatureAlgorithm::unsupported_algorithm to better handle e.g. roots signed with RSA/MD5. r=briansmith, a=lmandel - 2535e75ff9c6 David KeelerBug 1058812 - mozilla::pkix: Test handling unsupported signature algorithms. r=briansmith, a=lmandel - a7b8a4567262 Jonathan KewBug 1074223 - Update OTS to pick up fixes for upstream issues 35, 37. Current rev: c24a839b1c66c4de09e58fabaacb82bf3bd692a4. r=jdaggett, a=lmandel - 6524ec11ce53 Gijs KruitboschBug 1050638 - Should be able to close tab with onbeforeunload warning if clicking close a second time. r=ttaubert, a=lmandel - 98fc091c4706 JW WangBug 760770 - Allow 'progress' and 'suspend' events after 'ended'. r=roc, a=test-only - 915073abfd8b Benjamin ChenBug 1041362 - Modify testcases because during the oncanplaythrough callback function, the element might not ended but the mediastream is ended. r=roc, a=test-only - c3fa7201e034 Jean-Yves AvenardBug 1079621 - Return error instead of asserting. r=kinetik, a=lmandel - 9be2b1620955 Andrei OpreaBug 1020449 Loop should show caller information on incoming calls. Patch originally by Andrei, updated and polished by Standard8. r=nperriault a=lmandel - 742beda04394 Mark BannerBug 1020449: Fix typo in addressing review comments in Bug 1020449 that caused broken jsx. rs=NiKo a=lmandel - 0033bca3ce22 Mark BannerBug 1029433 When in a Loop call, the title bar should display the remote party's information. r=nperriault a=lmandel - 530ec559a14c Simone BrunoBug 1058286 - Add in-tree manifests needed for tests. DONTBUILD a=NPOTB - 0b7106ef79d2 Jonathan KewBug 1074809 - For OTS warning (rather than failure) messages, only log the first occurrence of any given message per font. r=jdaggett, a=lmandel - 1875f4aff106 Ed LeeBug 1081157 - "What is this page" link appears on "blank" version of about:newtab. r=ttaubert, a=sledru - c00a4cfe83e9 Matthew GreganBug 1080986 - Check list chunk is large enough to read list ID before reading. r=giles, a=sledru - bb851de524c2 Matthew GreganBug 1079747 - Follow WhatWG's MIMESniff spec for MP4 more closely. r=cpearce, a=sledru - f752e25f4c42 Steven MichaudBug 1084589 - Fix a Yosemite topcrasher. r=gijskruitbosch a=gavin - 3a24d0c65745 Mike de BoerBug 1081061: switch to a different database if a userProfile is active during the first mozLoop.contacts access to always be in sync with the correct state. r=MattN. a=lmandel - 6b4c22bfe385 Mark BannerBug 1081066 Incoming call window stays open forever if the caller closes the window/tab or crashes. r=nperriault a=lmandel - 8c329499cf7d Matthew NoorenbergheBug 1079656 - Make the Loop Account menu item work after a restart. r=jaws a=lmandel - ada526904539 Mike de BoerBug 1076967: fix Error object data propagation to Loop content pages. r=bholley a=lmandel - 880cfb4ef6f8 Mark BannerBug 1078226 Unexpected Audio Level indicator on audio-only calls for Loop, also disable broken low-quality video warning indicator. r=nperriault a=lmandel - 5ad9f4e96214 Nicolas PerriaultBug 1048162 Part 1 - Add an 'Email Link' button to Loop desktop failed call view. r=Standard8 a=lmandel - f705ffd06218 Mark BannerBug 1081154 - Loop direct calls should attempt to call phone numbers as well as email addresses. r=mikedeboer a=lmandel - 191b3ce44bea Nicolas PerriaultBug 1048162 Part 2 - Display an error message if fetching an email link fails r=standard8,darrin a=lmandel - 3fc523fcc7da Mike de BoerBug 1013989: change the label of the Loop button to Hello. r=MattN a=lmandel - 2edc9ed56fa4 Romain GauthierBug 1079811 - A new call won't start if the outgoing call window is opened (showing feedback or retry/cancel). r=Standard8 a=lmandel - a4e22c4da890 Mike de BoerBug 1079941: implement LoopContacts.search to allow searching for contacts by query and use that to find out if a contact who's trying to call you is blocked. r=abr a=lmandel - bda95894a692 Randell JesupBug 1084384: support importing contacts with phone numbers in a different format r=abr a=lmandel - 8c42ccaf8aa1 Mike de BoerBug 1084097: make sure that the Loop button only shows up in the palette when unthrottled. r=Unfocused a=lmandel - 5840764c4312 Randell JesupBug 1070457: downgrade assertion about cubeb audiostreams to a warning r=roc a=lmandel - 9e420243b962 Randell JesupBug 1075640: Don't return 0-length frames for decoding; add comments about loss handling r=ehugg a=lmandel - bb26f4854630 Ethan HuggBug 1075640 - Check for zero length frames in GMP H264 decode r=jesup a=lmandel - 452bc7db811e Luke WagnerBug 1064668 - OdinMonkey: Only add AsmJSActivation to profiling stack after it is fully initialized. r=djvj, a=lmandel - eb43a2c05eb3 Bas SchoutenBug 1060588 - Use PushClipRect when possible in ClipToRegionInternal. r=jrmuizel, a=lmandel - 6609fd74488b Gijs KruitboschBug 1077404 - subviewradio elements in panic button panel are elliptical and labels get borders. r=jaws, a=lmandel - 2418d9e17dd0 Markus StangeBug 1081160 - Update window shadows for Yosemite. r=smichaud, a=lmandel - fc032520a26e Chenxia LiuBug 1079761 - Add 'stop tab mirroring' one level higher in the menu. r=rbarker, a=lmandel - 4018d170ab06 Mike HommeyBug 1082323 - Reject pymake in client.mk. r=mshal, a=sledru - f19a52b7e6ec Tomasz KołodziejskiBug 1074817 - Allow downgrade of content-prefs.sqlite. r=MattN, a=lmandel - 2235079fe205 Gijs KruitboschBug 1083895 - Favicon should not change if link element isn't in DOM. r=bz, a=lmandel - 73bc0bc9343b Dragana DamjanovicBug 1081794 - Fixing a test for dns request cancel. On e10s, the dns resolver is sometimes faster than a cancel request. Use a random string to be resolved instead of a fix one. r=sworkman, a=test-only - 6d2e5afd8b75 Nicolas SilvaBug 1083071 - Add some old intel drivers to the blocklist. r=Bas, a=sledru - 53b97e435f10 Nicolas SilvaBug 1083071 - Blacklist device family IntelGMAX4500HD drivers older than 7-19-2011 because of OMTC issues on Windows. r=Bas, a=sledru - b5d97c1c71b7 Ryan VanderMeulenBug 1083071 - Change accidentally-used periods to commas. rs=nical, a=bustage - 8cc403ad710b

Categorieën: Mozilla-nl planet

Robert Nyman: The editors I’ve been using – which one is your favorite?

Mozilla planet - wo, 22/10/2014 - 16:09

The other day when I wrote about Vim and how to get started with it, I got a bit nostalgic with the editors I’ve been using over the years.

Therefore, I thought I’d list the editors I’ve been using over the years. I remember dabbling around with a few and trying to understand them, but this list is made up of editors that I’ve been using extensively:

    Allaire HomeSite
    Ah, good ol’ HomeSite. You never forget your first real editor that you used for your creations. It was later bought by MacroMedia and then, in 2009, it was retired. Its creator, Nick Bradbury, wrote a bit about that in HomeSite Discontinued. I also sometimes used TopStyle, also created by Nick, as a complement to HomeSite – and that one is actually still alive!
    Visual Studio.NET
    I was young and I needed the money.
    TextMate
    After my switch to Mac OS X, I quickly started using TextMate and it was my main editor for a good number of years.
    MacVim
    When I had used TextMate for a long time, a number of developers told me I should really get into Vim, where MacVim seemed like the most suitable alternative. I tried, really hard, with it for about 6 months; learned a lot, but eventually went back to TextMate.
    Sublime Text
    Later, along came Sublime Text and seemed to have a lot of nice features and active development, while TextMate had been pretty stale for a long time.
    MacVim (again)
    And now, as explained in my recent blog post on Vim, I’m back there again. :-)

I also do like to dabble around with various editors, to see what I like, get another perspective on workflow and general inspiration. One thing I’m toying around with there is Atom from GitHub, and I look forward to testing it more as well.

Which editor are you using?

It would be very interesting and great if you’d like to share in the comments which editor you are using, and why you prefer it! Or with which editor you started your developer career!

Categorieën: Mozilla-nl planet

Nick Cameron: Thoughts on numeric types

Mozilla planet - wo, 22/10/2014 - 05:31
Rust has fixed width integer and floating point types (`u8`, `i32`, `f64`, etc.). It also has pointer width types (`int` and `uint` for signed and unsigned integers, respectively). I want to talk a bit about when to use which type, and comment a little on the ongoing debate around the naming and use of these types.

Choosing a type
Hopefully you know whether you want an integer or a floating point number. From here on in I'll assume you want an integer, since they are the more interesting case. Hopefully you know if you need your integer to be signed or not. Then it gets interesting.

All other things being equal, you want to use the smallest integer you can for performance reasons. Programs run as fast or faster on smaller integers (especially if the larger integer has to be emulated in software, e.g., `u64` on a 32 bit machine). Furthermore, smaller integers will give smaller code.

At this point you need to think about overflow. If you pick a type which is too small for your data, then you will get overflow and usually bugs. You very rarely want overflow. Sometimes you do - if you want arithmetic modulo 2^n where n is 8, 16, 32, or 64, you can use the fixed width type and rely on overflow behaviour. Sometimes you might also want signed overflow for some bit twiddling tricks. But usually you don't want overflow.

If your data could grow to any size, you should use a type which will never overflow, such as Rust's `num::bigint::BigInt`. You might be able to do better performance-wise if you can prove that values might only overflow in certain places and/or you can cope with overflow without 'upgrading' to a wider integer type.

If, on the other hand, you choose a fixed width integer, you are asserting that the value will never exceed that size. For example, if you have an ascii character, you know it won't exceed 8 bits, so you can use `u8` (assuming you're not going to do any arithmetic which might cause overflow).

So far, so obvious. But, what are `int` and `uint` for? These types are pointer width, that means they are the same size as a pointer on the system you are compiling for. When using these types, you are asserting that a value will never grow larger than a pointer (taking into account details about the sign, etc.). This is actually quite a rare situation, the usual case is when indexing into an array, which is itself quite rare in Rust (since we prefer using an iterator).

What you should never do is think "this number is an integer, I'll use `int`". You must always consider the maximum size of the integer and thus the width of the type you'll use.
Language design issues
There are a few questions that keep coming up around numeric types - how to name the types? Which type to use as a default? What should `int`/`uint` mean?

It should be clear from the above that there are only very few situations when using `int`/`uint` is the right choice. So, it is a terrible choice for any kind of default. But what is a good choice? Well first of all, there are two meanings for 'default': the 'go to' type to represent an integer when programming (especially in tutorials and documentation), and the default when a numeric literal does not have a suffix and type inference can't infer a type. The first is a matter of recommendation and style, and the second is built-in to the compiler and language.

In general programming, you should use the right width type, as discussed above. For tutorials and documentation, it is often less clear which width is needed. We have had an unfortunate tendency to reach for `int` here because it is the most familiar and the least scary looking. I think this is wrong. We should probably use a variety of sized types so that newcomers to Rust get aquainted with the fixed width integer types and don't perpetuate the habit of using `int`.

For a long time, Rust had `int` as the default type when the compiler couldn't decide on something better. Then we got rid of the default entirely and made it a type error if no precise numeric type could be inferred. Now we have decided we should have a default again. The problem is that there is no good default. If you aren't being explicit about the width of the value, you are basically waving your hands about overflow and taking a "it'll be fine, whatever" approach, which is bad programming. There is no default choice of integer which is appropriate for that situation (except a growable integer like BigInt, but that is not an appropriate default for a systems langauge). We could go with `i64` since that is the least worst option we have in terms of overflow (and thus safety). Or we could go with `i32` since that is probably the most performant on current processors, but neither of these options are future-proof. We could use `int`, but this is wrong since it is so rare to be able to reason that you won't overflow when you have an essentially unknown width. Also, on processors with less than 32 bit pointers, it is far to easy to overflow. I suspect there is no good answer. Perhaps the best thing is to pick `i64` because "safety first".

Which brings us to naming. Perhaps `int`/`uint` are nor the best names since they suggest they should be the default types to use when they are not. Names such as `index`/`uindex`, `int_ptr`/`u_ptr`, and `size`/`usize` have been suggested. All of these are better in that they suggest the proper use for these types. They are not such nice names though, but perhaps that is OK, since we should (mostly) discourage their use. I'm not really sure where I stand on this, again I don't really like any of the options, and at the end of the day, naming is hard.
Categorieën: Mozilla-nl planet

Raniere Silva: The Status of Math in Open Access

Mozilla planet - wo, 22/10/2014 - 04:00
The Status of Math in Open Access

This week, October 20–26, 2014, held the Open Access Week (see the announcement) and will end with Mozilla Festival that has a awesome science track. This post has some thoughts about math and open access and this two events.

Leia mais...

Categorieën: Mozilla-nl planet

Curtis Koenig: Thanks for all the Fish

Mozilla planet - wo, 22/10/2014 - 03:11

I’ve always loved that book or in fact any of Douglas Adams books as they made me laugh while reading for the first time. And like the ending of that series it always seemed a good way to start a ending. This is only the 3rd real job I’ve ever had and they’ve all ended with that as the subject line, so by now you all know where this is going.

The last 3 years 9 months and 21 days have been the best of my adult working life. Mozilla has been more than a job, more than a career. It was a home. The opportunity to apply ones talent in conjunction with values and mission is a gift. It’s a dream state, even on bad days, that I gladly would have remained a slumberer in. The Community of Mozilla is a powerful and wonderful uniqueness that embodies the core of what it means to be Open, and if we ever lose that we’ve lost a precious gem.

I hope to work with many of you again at some future time. If we cross paths somewhere I’d happily lift a libation in remembrance.

With that I shall end with one of my favorite bits of poetry:

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

Then took the other, as just as fair,
And having perhaps the better claim
Because it was grassy and wanted wear,
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I,
I took the one less traveled by,
And that has made all the difference.

 

/Curtis


Categorieën: Mozilla-nl planet

Mozilla opens up: What The Open Standard's editor says about civilization ... - Upstart

Nieuws verzameld via Google - wo, 22/10/2014 - 01:08

Upstart

Mozilla opens up: What The Open Standard's editor says about civilization ...
Upstart
The UpTake: Add Mozilla to the ranks of companies coming out with editorial products, though in Mozilla's case, The Open Standard is much more than another way to hawk Firefox. Its founding editor, Anthony Duignan-Cabrera, lays out his vision for the ...

Categorieën: Mozilla-nl planet

Mozilla opens up: What The Open Standard's editor says about civilization ... - Upstart

Nieuws verzameld via Google - wo, 22/10/2014 - 01:08

Upstart

Mozilla opens up: What The Open Standard's editor says about civilization ...
Upstart
The UpTake: Add Mozilla to the ranks of companies coming out with editorial products, though in Mozilla's case, The Open Standard is much more than another way to hawk Firefox. Its founding editor, Anthony Duignan-Cabrera, lays out his vision for the ...

Categorieën: Mozilla-nl planet

Ben Kero: Missoula visit, day 1

Mozilla planet - di, 21/10/2014 - 22:30

NOTE: This is a personal post, so if these sort of things do not interest you please feel free to disregard.

Yesterday I drove from Seattle to Missoula to visit my mother and help her sort out her health issues. I left later than usual, but with the drive time reduced by an hour compared to Portland combined with the relatively straight and boring I-90 I made it to Missoula with energy to spare (which also might have been why I was up far later than my arrival time).

The purpose of my visit is to visit my mother, show that I still care about my family, and help her sort out her medical issues (she’s currently going through her third round of cancer). When I arrived last night around 2300 I didn’t get a very good look at her. She had stayed awake past her normal 2000 time to await my arrival and greet me. Last night was relatively uneventful besides my restful sleep. She showed me to the apartment’s single bedroom. Each surface was meticulously cleaned, although none of the multitude of tchotchkes or personal accessories were organized or put away. While using the bathroom I noticed there was a small mop and bucket. Normally I wouldn’t think much of it, but in previous weeks my sister told me that my mother had given herself a panic attack making sure the apartment was spotless for my arrival. Unfortunately my trip over was waylaid for a few weeks, so I hope that she hasn’t been in such a state the whole time.

Last year I sent her an air purifier to remove all the pet danger from the air, and although she couldn’t figure out what it was or its purpose, thankfully she had finally figured it out and was using it. As a result the air was much cleaner and her phlegm-laden smoker’s cough was slightly better than last time I visited.

This morning I woke up later because I also fell asleep quite late into the morning combined with the timezone change. She has a few friends here in Missoula who (as far as I can tell) provide her with some company and source of gossip and usefulness. when I emerged from my room this morning I found her on the phone with one such friend. I didn’t get much from the conversation, but apparently the daily phone calls are a routine for her. That’s good.

What I really didn’t like though was the television. During the day it was a large part of her unchanging environment. Equipped with a “digital cable” box, this tube never showed anything besides Informative Murder Porn. Likewise, the bookshelves were chocked full of James Patterson books, promising more tripe romance and novelized informative murder porn. Although I fear that it’s rotting her brain I refrained from commenting about it.

After my emergence this morning we finally got a good look at each other. She finally noticed my attempt at growing a beard and I finally noticed her emaciation. Her weight is below 100lb now, and she looks positively skeletal. It’s not a pretty sight. It appears she attempted to dye her hair recently, but even with that effort it’s resisted, instead opting for a grey and wispy appearance. I offered to pick her up a meal with my lunch, but she refused saying that she already had breakfast.

We talked for a while about how she’s been. Besides the new medical situation nothing ever seems to change with her. She remains cloistered in her dark, smoke-smelling apartment with nothing to keep her company save her pets, her informative murder porn, and trashy novels. She hasn’t expressed any dissatisfaction with the situation, so perhaps she enjoys it. I haven’t asked, and haven’t decided if it’s appropriate to ask yet. Perhaps it’s imposing my values on her to think that she would be unhappy with this bountiful life she’s living.

This morning we talked about her medical situation. The gist of the situation is that she believes that she’s been caught up in a catch-22 with a set of doctors, each waiting to hear from another before proceeding to make a diagnosis and start a treatment. I asked her about what she knows (red blood cell count is down), and what kind of treatment she was currently undergoing. The answer was no treatment, so I continued by asking which doctor’s she’s seen and what their next steps would be (or what they’re waiting on). I got quite a few answers about quite a few doctors, and was unfortunately unable to follow most of it. I asked her to write a list of doctors down, along with what she thinks they’re waiting on and the last time they’ve been in contact. Hopefully when I get home this evening I can help untangle this and get her the treatment she needs. She didn’t seem particularly worried about things, which frustrated me. The scenario in front of me was her off-the-cuff attitude about it combined with the television showing an emotionally charged lady with a bloody knife crumpled into a heap on the ground, the police intervening to save the day and arrest the paedophile, had caused me to want to ragequit and give her some time to compile the list of doctors. I do not have much hope of returning home this evening to any list.

This afternoon, as usual for my Missoula visits, I’ve holed up at The Break coffee shop. It’s an old standby for spending uninterrupted time on my laptop to get a little work done. It’s also conveniently located far away from that apartment, and near the other goodness of downtown Missoula. The espresso might have been burnt, but the well worn tables, music reminiscent of my high school days in Missoula, and mixed clientèle lead to a very pleasing atmosphere. As I sit at my stained and worn coffee table typing away at my laptop I can see a young man in a cowboy hat and vest conversing with a friend in a denim jacket over a cup of joe, a dreadlocked young lady enjoying an iced coffee alone, equipped with Macbook and textbooks. Various others including a suited businessman, and a few white collar workers taking a lunch break are around. The bright but persistently drizzling conditions outside add to the hearth-like atmosphere of the shop. This place is going to get sick of me before the week is out.

This afternoon I’m going to attempt to do a bit do a bit of work and get in contact with my father and sister for their obligatory visits. I hope that I can return to my mother’s place and provide some sort of assistance besides moral support.

I’ll be in Missoula until Thursday evening.

Categorieën: Mozilla-nl planet

Mic Berman: What Does Your Life Design Look Like?

Mozilla planet - di, 21/10/2014 - 19:53

I would guess many people would react to this title like what on earth is she talking about? Design my life - what does that even mean? Many people I coach and work with have not thought about their life’s design - meaning the focused work you do, is it in support of your values and vision? the people you surround yourself with - do they inspire and motivate you? the physical space you live in - does it give you energy?  

 

Your life design includes more than your career. I invite my clients to think beyond what's on paper. Your career is your role, salary, title, industry company. I’m asking you also think of -  who you will be surrounded with, where it might take you beyond the role right now, how it will honour or not honour your values and how it will fit with your vision for your life.

 

If we jump mindlessly from one opportunity to the next - even if they are great opportunities on the surface eg more money, bigger title etc it can cost us in our personal lives in ways we may not consider. Arianna Huffington recently wrote about this in her book Thrive, “Our relentless pursuit of the two traditional metrics of success - money and power - has led to an epidemic of burnout and stress-related illnesses, and an erosion in the quality of our relationships, family life, and, ironically, our careers”. In addition to this sentiment, everyone’s heard repeated stories of those on their deathbed who never regret not having worked more or harder - what they always say is they wished they'd spent more time with people they loved or doing things that inspire and nurture. These are our regrets. So how do you want to design your life with no regrets in mind?

 

Here are my 3 tips on designing which I hope inspires you to re-create your designed life:

  1. Know your values and how you want to honour them

  2. Define your vision if not for 5 years at least for the next year - what are the big impressions you want to leave

  3. Who are your stakeholders (the people that matter to you) and how will you honour them

Categorieën: Mozilla-nl planet

Mic Berman: How are you discerning who and what influences you?

Mozilla planet - di, 21/10/2014 - 19:24

Being discerning about my influences and experiences - I choose the people, experiences and beauty to influence my life. I find people aren’t always choosy about who or what they allow in their lives - they tend to revert to a default based on who they’ve known forever or do so without thought. I am more discerning now - and decide who I will give my time to, when I might read email, pay attention to my phone, and certainly who I will listen to, take advice from and experiences I want.

On Friday nights I’ve begun turning my phone off from dinner until Saturday night and sometimes Sunday morning - it gives me the opportunity to not be distracted by anyone and fully present in how I design my weekend to maximize rejuvenation and reflection.

I have found several friends that are smarter than me in key areas I love to learn about and so I soak up their thoughts, we share our challenges and learn from each other, we push each other to be even better and stronger than we know and acknowledge where we’re at or how we’re feeling without judgement.

For a complete shift in perspective and experience, I love growing our organic market-garden farm, it’s a venture that gives me solace, grounding, joy on a spiritual and physical plane that is entirely unique - to grow my own food and share this bounty with those that appreciate what it takes is beyond joyful. Particularly when I also then learn what can be done with e.g. ground cherry tomato’s and chocolate or wild leeks and miso :)

And I choose to include some element of beauty in my daily life and surroundings. That might mean picking a simple bouquet of wild flowers to infuse a team meeting room in the fresh scent of lilac’s. Or it could be appreciating fine art in painting or sculpture and the profound and thought-provoking impact the artist intends.

Categorieën: Mozilla-nl planet

Doug Belshaw: A 10-point #MozFest survival guide

Mozilla planet - di, 21/10/2014 - 19:11

It’s the Mozilla Festival in London this weekend. It’s sold out, so you’ll have to beg, borrow or steal a ticket! This will will be my fourth, and third as a paid contributor (i.e. Mozilla employee).

Here’s my tips for getting the most of it.

1. Attend the whole thing

There’s always the temptation with multi-day events not to go to each of the days. It’s easy to slip off into the city – especially if it’s one you haven’t been to before. However, that would a real shame as there’s so much to do and see at MozFest. Plus, you really should have booked a few days either side to chill out.

2. Sample everything

Some tracks will grab you more than others. However, with nine floors and multiple sessions happening at the same time, there’s always going to be something to keep you entertained. Feel free to vote with your feet if you’re not getting maximum value from a session – and drop into something you don’t necessarily know a lot about!

3. Drink lots

Not alcohol or coffee – although there’ll be plenty of that on offer! I mean fluids that will rehydrate you. At the Mozilla Summit at the end of last year we were all given rehydration powder along with a Camelbak refillable bottle. This was the perfect combination and I urge you to bring something similar. Pro tip: if you can’t find the powder (it’s harder to come by in the UK) just put a slice of lemon in the bottom of the bottle to keep it tasting fresh all day!

4. Introduce yourself to people

The chances are that you don’t know all 1,600 people who have tickets for MozFest. I know I don’t! You should feel encouraged to go up and introduce yourself to people who look lost, bewildered, or at a loose end. Sample phrases that seem to work well:

  • “Wow, it’s pretty crazy, eh?”
  • “Hi! Which session have you just been to?”
  • “Is this your first MozFest?”
5. Take time out

It’s easy to feel overwhelmed, so feel free to find a corner, put your headphones on and zone out for a while. You’ll see plenty of people doing this – on all floors! Pace yourself – it’s a marathon, not a sprint.

6. Wear comfortable shoes/clothing

There are lifts at the venue but, as you can imagine, with so many people there they get full quickly. As a result there’ll be plenty of walking up and down stairs. Wear your most comfortable pair of shoes and clothing that’ll still look good when you’re a sticky mess. ;-)

7. Expect tech fails

I’ve been to a lot of events and at every single one, whether because of a technical problem or human error, there’s been a tech fail. Expect it! Embrace it. The wifi is pretty good, but mobile phone coverage is poor. Plan accordingly and have a backup option.

8. Ask questions

With so many people coming from so many backgrounds and disciplines, it’s difficult to know the terminology involved. If someone ‘drops a jargon bomb’ then you should call them out on it. If you don’t know what they mean, then the chances are others won’t know either. And if you’re the one doing the explaining, be aware that others may not share your context.

9. Come equipped

Your mileage may vary, but I’d suggest the following:

  • Bag
  • Laptop
  • Mobile phone and/or tablet
  • Pen
  • Notepad
  • Multi-gang extension lead
  • Charging cables
  • Headphones
  • Snacks (e.g. granola bars)
  • Refillable water bottle

I’d suggest a backpack as something over one shoulder might eventually cause pain. You might also want to put a cloth bag inside the bag you’re carrying in case you pick up extra stuff.

10. Build (and network!)

MozFest is a huge opportunity to meet and co-create stuff with exceptionally talented and enthusiastic people. So get involved! Bring your skills and lend a hand in whatever’s being built. If nothing else, you can take photos and help document the festival.

The strapline of MozFest is ‘arrive with an idea, leave with a community’. Unlike some conferences that have subtitles that, frankly, bear no relation to what actually happens, this one is dead on. You’ll want to keep in touch with people, so in addition to the stuff listed above you might want to bring business cards. Far from being a 20th century thing, I’ve found them much more useful than just writing on a scrap of paper or exchanging Twitter usernames.

This isn’t meant to be comprehensive, just my top tips. But I’d be very interested to hear your advice to newbies if you’re a MozFest veteran! Leave a comment below. :-)

Image CC BY-SA Alan Levine

Update: my colleague Kay Thaney has a great list of blighty sights that you should check out too!

Categorieën: Mozilla-nl planet

Mic Berman: What do you want for you life? knowing oneself

Mozilla planet - di, 21/10/2014 - 18:51

There are many wiser than me that have offered knowing yourself as a valuable pursuit that brings great rewards.

 

Here are a few of my favourite quotes on why to do this:

 

This is how I invest in knowing myself - I hope it inspires you to create your own practice

  1. I spend time understanding my motivations, values in action or inaction, and my triggers. I leverage my coach to deconstruct situations that were particularly difficult or rewarding, where I’m overwhelmed by emotion and don’t feel I can think rationally - I check in to get crystal clear on what is going on, how am I feeling, what was the trigger(s) and how will I be at choice in action going forward.
  2. I challenge myself in areas I want to understand more about myself by reading, going to lectures, sharing honestly with leanred or experienced friends.
  3. I keep a daily journal - particularly around areas in my life I want to change or improve like being on time and creating sufficient time in my day for reflection. I’ve long run my calendar to ‘maximize time and service’ i.e. every available minute is in meetings, working on a project, etc. This is not only un-sustainable for me, it doesn’t leave me any room for the unexpected and more importantly an opportunity to reflect on what may have just happened or prepare for what or who I may be seeing next. This is not fair to me nor to the people I work with.
Categorieën: Mozilla-nl planet

Pagina's