Several people have asked me about living in Thailand. After spending a year in Chiang Mai, here are a few suggestions, recommendations and things I wished I knew ahead of time.
- Learn to speak Thai, at least a little bit. We took classes over Skype video for 2 months from Brett Whiteside and it really helped. I can speak and understand enough basics for cordial and respectful interactions with people, and to eat wherever I want :). If you’re going to be there for a while learn to read Thai. It’s seriously worth it, if only for reading menus and signs.
- Always print a detailed map of wherever you’re going. Anywhere. All the time. Really.
- Make a custom Google map with the locations of: post office, utility offices (power, water), telco, police station, etc. Just in case.
- Banking: ATMs cost US$5 per transaction, and result in currency conversion fees. Instead, open a Bangkok Bank account and get a debit card. Getting a bank account took some paperwork, about an hour of waiting in the bank, and I think you have to pay a small fee. Bangkok Bank is the only Thai bank with a US branch (in NY). This means that you can make direct transfers from US banks to your Bangkok Bank account, allowing for money access with a minimum of delay and fees.
- 3G: I used AIS, which has unlimited (5GB IIRC) 3G monthly pre-paid option. Absolutely recommended for access to Google Maps while lost ;).
- Thai street food is often safer than food from “western” places. The food at the carts is usually bought fresh that day, and is cooked in front of you. The food at “western” hotels and restaurants is cooked out of sight, and they try to store food, which is risky since there’s not really health department inspections like in the states, to ensure the storage is properly done. You’ll find infinite opinions about this – this is my personal experience. There’s no magic solution. You will have some intestinal discomfort at some point.
- Western toilets are everywhere. At some point however, you’ll need to use a squat toilet. Chiang Mai Rock Climbing Adventures has humorous yet informative instructions for properly using a squat toilet.
- Use Foursquare or some other check-in service. I often couldn’t find a place that I wanted to return to, or had forgotten the street, etc.
- 7-11. Is awesome. In Thailand you will pay your utility bills, refill your phone minutes, purchase concert tickets, and many other things there.
- Temples: Wear long pants and shirts with sleeves. Be quiet and respectful. Donate money to them.
Most importantly: Go anywhere and everywhere. Always take a different route. Pull over often. Walk down unfamiliar streets. See every temple. Explore every market. And always carry your camera.
This year we started talking about ways to improve the methods in which develop Firefox features. This is a snapshot of where we’re at, and what’s coming next.
We began with some conversations about current problems regarding coordination, speed, contribution, regressions, ease of development: my initial dev.planning post, Joe Walker’s post ‘How to Eat an Elephant’, my blog post, dev.planning add-on bundling post.
There was general recognition that the Firefox development model is not agile nor flexible enough to meet the needs of our 2012 goals. We need to be able to ship features that are developed mostly outside of what’s considered the “core” Firefox team. We need to better support the use of external code repositories and bug tracking systems. We need to support features written using the Add-on SDK, both inside and bundled with Firefox.
Here’s where we’re at:
- A group of people formed to start discussing how to make these things happen: the Jetpack Features group. We meet every other Friday (meeting details and notes).
- We have a project branch (Cedar) where we can experiment and do performance testing.
- We corralled the Firefox and Toolkit module owners and the leads of the SDK project in a room to orchestrate the mechanics of landing the SDK inside Firefox itself (notes).
- L10n: The Jetpack team are hard at work on closing this gap with both localized strings in script and localization of HTML content inside add-ons.
- Performance: Jeff Griffiths blogged recently about the performance impact of the core SDK runtime on startup time. More performance tests are coming.
- Feature bundling: The BrowserID feature will likely ship in Firefox as a bundled add-on. There are still open questions though: Is it uninstallable? Does it even show up in the Add-ons Manager? Can it upgrade outside of the Firefox dev cycle? More work to do here.
- Automation: We have the Jetpack unit tests being run with every Mozilla-central check-in (though hidden by default currently). We have the SDK unit tests running on every SDK check-in for both Nightly and Aurora (tree). We still need the Mozilla-central unit tests run on every SDK check-in (that’ll come with integrating the SDK into Firefox), and performance tests run for Mozilla-central and SDK check-ins.
What’s coming up in 2012:
- Completing the picture of addon-as-feature integration into the Moz-ecosystem: l10n, performance and unit test automation.
- Ship BrowserID as a bundled add-on.
- Ship the SDK inside Firefox (the relevant parts, anyway).
- Ship Web Apps as a bundled add-on, if it makes sense to do so.
A friend recently asked me to take a look at his resume. After reading countless resumes and doing hundreds of interviews for Mozilla over the last 5+ years (whoa, almost 6 now!), a bunch of stuff came jumbling out. With his permission, I’ve copied the feedback here. Maybe it’ll be of use to someone looking for a manager’s eye on their resume. Most of the comments make sense on their own, so I didn’t copy the resume itself here.
Hey! Overall, looks good – you look like a solid candidate for a Java programming gig, with some potential for leadership, but not interested in it. Probably a senior coding member on a team (given the # of years experience) or a lone-wolf programmer that a manager could hand a project off to and expect you to run with it.
A couple of thoughts below with my critical hat on, ranging from grammar to technical. Please take with many grains of salt – obviously I’m not representative of all hiring managers. Also, I didn’t have the context about whether this is tailored for a specific position, or if you are just getting ready to hit the market. Is the resume tailored for your ideal job, or the job you’d settle for? Hard to evaluate without that context.
- My biggest criticism is that your personality doesn’t come through, only your technical skills. Everyone has a list of current/former employers, a list of acronyms, and *some* have a list of side projects (you get points for that in my book). The summary is your first chance to personalize what is otherwise an abstract description of a skill set, so take advantage of it. For example, you could start with “I am a lead developer” instead of “Lead developer”. Honestly, do you really talk in robot language like that in real life? No. Would you want to work with someone that did? Probably not. So, look for any opportunity to be more than just a developer of code.
- Clarify if you’re looking to lead or not, or even open to it. For me, this will contextualize my technical assessment of a candidate. Are you interested in project management? Are you interested in people management? Your resume currently says no, that you only want to code, but can work with non-programmers as necessary.
- “My main focuses are…” – is both redundant (focus implies main-ness) and misapplied (focus shouldn’t ever be used in the plural, by definition, IMO). Could say something like “My core responsibilities are…”, etc. You use focus later in a similar way in the Objective section: “expand professional focus” to include some other languages. That’s the opposite of focusing
- I’d take “SOAP/RESTful” out of the summary, is overly specific, not necessary.
- “often responsible” – Nah, you *are* responsible for that stuff. No need to lessen your impact with qualifying adjectives, especially in your resume of all places.
- The Objective section seems to say that you want more variety in your work than you currently have, and that you’d like to learn a few specific programming languages. Is that about right? It sounds like you’re bored. That isn’t bad, but that’s the impression I get. Again, what to put here really depends on what your actual objective is. Is it to get a job writing re-usable Java libs for web front-ends? Or a job writing Python scripts against big data-sets? You should decide that up front, and be as clear as possible about it. If you need two resumes, so be it.
- The bits about the actual work you did are great. Instead of just listing the thing, you explain the impact that the thing had, the long term result for the business, etc.
- If you have degrees from those college years, note them. The multiple year sequences you were at Acme College don’t provide value, could just pick one or aggregate into one period where it makes sense.
- Needs a spell-check and grammar pass (eg: devloping, importanly, colloborating)
Final thought: What questions would I ask you after reading this resume, when we did a phone screen? What are things not called out explicitly in a resume, but are part of an experienced developer’s toolbox… IOW, the stuff that shows you know not only how to write code, but to *ship* software.
- I’d probably ask a couple of technical questions of medium difficulty, just to confirm that you can talk comfortably at the level of technical knowledge described in the resume.
- I’d dig into problem scenarios like the hardest problem you had to solve, both architectural and bug-wise. What tools/patterns you used, etc.
- I’d ask about performance problems – triaging them, debugging them, what tools for profiling, potential bottlenecks, etc.
- I’d ask about your testing and validation approaches, what unit test toolkits you’ve used, what automation you’ve written.
- Would ask you to describe your launch processes – things like staging servers, failover scenarios, backups, etc.
Ok, so maybe we aren’t in the post-browser age *yet*. But we’re getting there, and quickly. Most of the “apps” I use on my phone are useless without an always-on data connection, and they communicate with their respective motherships via HTTP. We’re staring down a near-future with multiple Web-stack operating systems for both desktop and portable devices. We have server-side application platforms that look startlingly like pieces of a traditional Web client.
All of those places are the Web, so that’s where Mozilla has got to be, when and if it’s possible to do so. And between desktop Firefox, mobile Firefox, Chromeless, B2G, Pancake, Open Web Apps and the various Firefox features developed by the Labs and the Services groups, we’ve got a lot of application logic that needs to exist in various forms across those disparate environments.
Up until recently, even including most of the mobile efforts to date, we’ve had a pretty narrow idea of what constitutes Firefox: Mozilla’s browser application with a front-end built in XUL, and rendering content using Gecko, stored entirely in a single source repository.
This narrow view is insufficient given the needs of internet users and the plans we have to serve those needs in the immediate future. This has been starkly illustrated by the recent move to a native UI for mobile Firefox, projects like Pancake, and the expansion of the development of Firefox features by groups outside of the core team.
A few months ago I dumped a couple of thoughts into a thread on the mozilla.dev.planning newsgroup about these things. More than anything, that thread showed me that the broad spectrum of activity in Mozilla today makes our narrow view of Firefox a huge barrier to future success. Some people didn’t agree that there was a problem at all. Some people railed against Jetpack or Github, while admitting they’d never used either. Some people agreed that developing Firefox is slow and fragile, and pointed at the relative historical success of that approach. Disturbingly, I got a bunch of private emails thanking me for starting the conversation… what does *that* mean?! Overall though, there was a lot of agreement on this point: We need more people to be able to work on Firefox faster, and in a more heterogeneous environment.
There’s a bunch of work towards that end going on right now, both in Firefox team itself and in Mozilla generally, around lowering the barriers to contribution. Specific to Firefox core development though, one experiment in alternate approaches is the attempt to ship the BrowserID feature as a Jetpack-based add-on that is developed on Github and bundled with Firefox. There are a lot of moving parts, but the exercise is helping us figure out the up- and downsides to building features as add-ons, as well as providing performance data about the Add-on SDK. Maybe it’ll work, maybe we’ll have to re-route and patch it against the core. Maybe we’ll land somewhere in-between.
Regardless of that experiment’s outcome, I think we need to be experimenting hard with how we develop Firefox, and asking questions about the longer-term development landscape:
- Code changes currently have non-deterministic effects in the Firefox ecosystem. We have a jumble of services that stagger into existence at startup, and then race for the exit at shutdown, beating up the file-system at both ends of the application lifecycle. “Async” is a pattern, not a system – without a system, making a bunch of things asynchronous means that the application’s behavior as a whole is generally less predictable. Is there a more systematic way that we can manage the loading and unloading of core browser services?
- Calcification: Check out the “cleanup page”. There are long-despised-and-untouched pieces of our core infrastructure, such as URL classifier, importers, autocomplete, and parts of Places. Why is it so hard to change these? What are the barriers to making them better?
- Modularity: Cu.import is great in that it provides some of the benefits that we used XPCOM JS services for, but without the XPCOM. But are we using it enough? Jetpack development puts much more emphasis on modularity via a core built on CommonJS, and I’ve found it to make browser features written in Jetpack far easier to follow, debug, and contribute to. Maybe we should be putting code into modules where we’d normally add it to browser.js, or XBL widgets moreso than we are now? This could reduce our dependence on the XUL window mega-scope that we get in browser.js, which I’d argue leads to code that is easier to developer, debug, test and maintain.
- Abstracting the application logic away from XUL/XPCOM where possible, allowing for more portable code. This doesn’t make sense in a lot of places in the front-end, but in others such as sync or expiration policies or tab grouping algorithms or frecency generation, it might. These are things which could be useful across a number of different application contexts.
So where from here? There’s general agreement that the Add-on SDK needs to ship in the browser. This might help address some of the questions above. However, it won’t immediately help us share code with other Firefoxes or Mozilla projects, or make core development inherently less-fragile or our application behavior any more deterministic. And there are tools like Cu.import, which we have now, and Harmony modules, which we might have soon (can we use those in chrome?!) that could help with the modularity part.
But only some of this is about the technology – other parts are social. As I said above, some people do not agree that developing Firefox is slow and fraught with peril. Is that plain ol’ resistance to change, or just the lack of a clear alternative? And maybe we code reviewers should be more forward-looking, demanding larger refactorings instead of non-invasive surgeries. But that’s challenging when you’re constrained for time, or the regression cost of refactoring is so high that you become risk averse.
I’d love to hear your thoughts on the future of Firefox application development – especially the core Firefox team, and the people working on Firefox features in other groups or via add-ons. Myk Melez has been corralling a group to talk about feature development with the Add-on SDK specifically, but it quickly spreads into these broader issues. He’s starting a list for it, but until then there are regular meetings, details available in his dev.planning post.
The Mozilla Open Data Project is an index of all of the open APIs and data-sources available in the Mozilla project.
It’s also something that does not exist yet!
Or maybe it does, but I couldn’t find it…
Anyways, we’ve got massive amounts of data available throughout the project, from check-in logs to performance data to bugzilla APIs. However, there’s no central location that lists all of the sources that currently exist. This also means that’s it’s not easy to scan and see what’s not available that should be.
Maybe this is something we should list on a public index that already exists, like Programmable Web.
For now, I started a list here: https://wiki.mozilla.org/Modp
Please add any sources of data or public APIs that you know of to that list, or here in the comments and I’ll add them for you.
UPDATE: To clarify, this is different than the community metrics work being done by the Metrics team. But we’re talking about having this information available in the metrics portal at some point in the future, likely driven off a publicly editable source.
I remixed about:memory using D3 to make a treemap visualization of how loaded URLs are using memory in Firefox.
Load it by clicking the widget on the add-on bar, or Cmd/Ctrl+Shift+Y
This visualization focuses on which web pages are using large amounts of memory – this is not a complete accounting of all memory being used. This doesn’t yet show how much is being used by some of the Firefox internals.
Add-on installation does not require a restart. Only tested on Nightly builds.
Dormancy ‘retires’ tabs that have gone unused for a while, freeing up that memory. It then restores the tabs to life when accessed.
While Firefox 9 adds restore-on-demand for users that restore their session by default, many users will never benefit from it. This add-on targets users who don’t restore session, but do have long-running instances of Firefox and many tabs. This might land as a core feature in Firefox 9 (https://bugzilla.mozilla.org/show_bug.cgi?id=675539).
NOTE: This is highly experimental, has only been tested on the Nightly builds, and probably will destroy your session. You’ve been warned.
Tabs are considered inactive when they haven’t been selected in longer than 5 minutes. To change that, set this pref to a value in milliseconds:
Tabs are checked for inactivity every 5 minutes. To change this, set this pref to a value in milliseconds:
- Awesomebar entry for dormant tabs shows data URI
- Sometimes dormant tabs have no title and no favicon
EXPERIMENTAL. MAY EAT YOUR SESSION OR DO OTHER BAD THINGS.