Tab unloading was a feature I really wanted, but it was lower priority, and discussions with our design team always went into the sarlaac pit of heuristics - when is the right time to unload the tab, without annoying the user by having to reload the page when they want it?

Being a tab hoarder myself, I wrote an extension that implements this feature for my own benefit, and also to learn a bit about what worked and didn't. I had to live without it for a bit after the great WebExtension migration, until the right API was finally shipped that supported the features I needed.

You can install this extension here: https://addons.mozilla.org/en-US/firefox/addon/dormancy/

I'd like to share a few things I learned while making and running this extension.

TL;DR: My optimal heuristics for tab unloading are "unload tabs 15 minutes after last focused" + "never unload tabs in active window".

Here are my findings and recommendations for building a tab unloading feature. They're not exhaustive, just the set of things I learned in my experiments.

• Most important: Do not trust any ideas or assumptions you have about this. You must personally live with different heuristics for a few days or a week. Experience the pain of your assumptions. There's one assumption that is 100% correct: When this feature is tuned incorrectly, it is SUPER ANNOYING.

• Personal and team testing is not enough. Do some research with real users. Write a test extension, and a blog post where people can test and provide feedback. Get as diverse set of testers as possible, and trust their feedback.

• This is a feature for power users. The telemetry for tab-counts shows this to be true. The unloading heuristics should take that into account. The users who will ever see this feature in action are tiny subset of overall browser users, so it should be tuned specifically to their behavior. That behavior should be explored in the research (more on this below).

• Time-since-tab-was-focused is the most important heuristic for me. While running Dormancy, I learned that 5 minutes of inactivity on a tab is wayyyy too low. I've settled on 15 minutes - it basically never surprises me, and I rarely experience a tab reload.

• Ignore-active-window is the second most important heuristic, but only matters for multi-window users obviously. IIRC our telemetry says there aren't many multi-window users... well, maybe not enough for defaults around this. But for people with multiple long-lived windows, keeping active window alive is fantastic.

About tab usage behavior - I've only scratched the surface of this. I wrote a few extensions that reflect my behavior dashboard-style in the toolbar so I can get a sense for levels of activity for different actions:

• Show number of open tabs across all windows
• Show number of tabs opened today
• Show number of tabs closed today
• Show number of tab switches today

These are shipped as separate extensions because you cannot adjust the width of toolbar icons, and I want all counts visible. They're all one extension, and the source code is on Github.

I've only done some basic counting, but research into more complex interactions and behavior should be done. For example, how people traverse tabs will determine whether the feature really works for them. If they use keyboard shortcuts to move across large sets of tabs, it will not be effective in single window mode using only a timeout, because the last-focused-time will constantly be reset.

If you'd like to learn more, there's a bug filed for this feature, with many years of discussion.

While the global perception of Portland is of a liberal weirdo wonderland, some of our city's beloved bars and world-renowned products and brands are part of the Trump support network in the Pacific Northwest.

Meet Gordon Sondland, who donated $1,000,000 for Donald Trump inauguration parties, and has received the ambassadorship to the EU. Read more about him on Wikipedia.

He's the founder and CEO of Provenance Hotels, a company that owns a group of hotels in the Pacific Northwest, and a few other places around the country..

I started to make a list of these hotels, so I could recommend to people to stay elsewhere. While reading the Provenance website, I found this page:

Whoa. These are some of the most successful names in Portland independent businesses. These are the people who make the things I love, and the spaces and menus I enjoy on a Friday night. What the fuck.

The Provenance website lists these "co-conspirators" (their words, not mine... but apt!) in Portland.

I know these businesses aren't evil. But I believe that the world around us is constructed by the decisions we make. So I cannot support these businesses while they partner with Provenance Hotel group and Gordon Sondland.

Please support these businesses by letting them know your concern about the part they play in enriching the people that keep Trump in power, and support a civil society by spending your money elsewhere until they've stopped doing business with Provenance.

• Jacobsen Salt
• Salt & Straw
• Lightning Bar Collective (Bye and Bye, Sweet Hereafter, Jackknife, Century)
• Quin Candy
• Austin Howe
• Imperial, Vitaly Paley
• Feast Portland
• Steven Smith Teas
• 503 Media and Events, David Rae
• Gemo Wong, Nike

I hope these business will cut ties with Provenance, so I can support them again someday.

Hotels Owned By Provenance

Portfolio of Provenance Hotels Group

• Portland, OR
  • Hotel deLuxe
  • Hotel Lucia
  • Sentinel
  • Dossier
  • Heathman Hotel
  • Westin Portland
  • The Benson
• Seattle, OR
  • Hotel Max
  • Hotel Theodore
• Tacoma, WA
  • Hotel Murano
• Nashville, TN
  • Hotel Preston
• New Orleans, LA
  • Old No. 77 Hotel and Chandlery
• Stillwater, MN
  • Lora

Contribute? Feedback?

Contact Dietrich Ayala (@dietrich on Twitter or https://mastodon.social/@dietrich )

If you're a Portland business owner listed above, and have stopped doing business with Provenance, thank you! Please reach out and I'll add a note about it.

I'm on the developer relations team at Mozilla. The "devrel" role has many parts, but generally means communicating to developers about web technologies important to Mozilla and our mission, and being an advocate for developers in our product development process.

I spent 2017 on typical developer relations activities - coding, writing, speaking - but entirely in UTC+5 and higher timezones. I'd lived in Asia before, and learned how much presence matters in order to learn about a place, and also I wanted to reduce my carbon footprint by not flying back and forth across mega-oceans.

From a "devrel at Mozilla" perspective, I had specific reasons for doing this:

• The largest internet populations are in Asia, as well as the largest offline populations. We need to be where the users are, and where growth will happen in the future.
• It's estimated that ~90% of the world's electronics are manufactured in Shenzen, China. If we want to make a safer internet, then Shenzhen is a place we must be.
• I wanted to learn about how technology decision making is happening - by developers, or otherwise, in as many different communities in Asia as possible.

I'll be publishing a series of briefs on what I learned this year about things like mobile payment patterns and the rise of physical computing, the transient nature of mobile web task workflows, where technical decision making happens, the relationship between the web and messaging apps, cultural and community verticalism, timezone bias, app investor ecosystem, ethical echo-chambers, Chinese maker spaces, a survey of noodle soups across Asia, and more.

But first, here's my 2017 in review.

Firsts

It was a year with a few firsts:

• First keynote speaking appearances, three different events, each very different from the other.
• First time at #1 on Hacker News
• First press briefings, in Taipei and Singapore
• First modules published on NPM!

Events

In 2017, I spoke at or facilitated 22 events in 12 different countries.

I specifically chose a diverse set of events, in an effort to learn about communities of technology decision-making outside the typical web developer or open source events. I spoke to high school and university students, designers, developers, open source die-hards, startup founders, entrepreneurs, investors, device manufacturers, academics, and people in various levels and roles in governments.

Some of the speaking happened because I submitted a proposal to conference CFPs, some from events reaching out to Mozilla for a speaker, some because I reached out to the organizer asking to speak, some from just being present and offering to speak, and one because I had a drink with a friend who introduced me to another friend whose dad ran a conference and thought I'd be a good match.

• Barcamp Yangon, Yangon, Myanmar, Jan 28-29, "Virtuality Reality on the Web"
• Phandeeyar, Yangon, Myanmar, Feb 2, "Preparing for the App-ocalypse: The Web and the Age of Physical Computing"
• Code for Nepal, Kathmandu, Nepal, Mar 4, "Preparing for the App-ocalypse"
• Digital Nepal, Janakpur, Nepal, Mar 8
• FOSSAsia, Singapore, Mar 17-19, "Integrated Physical Computing on the Web" (video)
• Thailand Startup Summit, Bangkok, Thailand, Mar 31 (keynote), "Touching the Future: Merging the Physical and Digital for Creative Experiences on the Web"
• Dev Day Danang, Danang, Vietnam, Apr 16, "Preparing for the App-ocalypse: The Web in the Age of Physical Computing"
• ThingsCon Shenzhen, Shenzhen, China, May 17, "App-ocalypse Now: The Future of User Onboarding in IoT"
• Tech In Asia Singapore, Singapore, May 17-18
• CommunicAsia, Singapore, May 23-25
• WebConf.asia, Hong Kong, June 3, "Touching the Future: Designing Physical Experiences with the Web"
• HKOSCON, Hong Kong, June 9-10 (keynote), "Preparing for the App-ocalypse: The Web in the Age of Physical Computing"
• Mozilla Developer Conference, Taipei, Taiwan, Sept 22, "Designing Physical Experiences: The Web in the Age of Room-Scale Computing"
• MDN Roadshow, Kuala Lumpur, Malaysia, Sept 23, "Designing Physical Experiences: The Web in the Age of Room-Scale Computing"
• MDN Roadshow, Penang, Malaysia, Sept 25, "Designing Physical Experiences: The Web in the Age of Room-Scale Computing"
• ICMAC, Denpasar, Indonesia, Nov 16-17 (keynote), "(Em)Powering Smart Cities: Designing for Resiliency in the Leapfrog Age"

I also spoke at, designed and ran or facilitated various trainings, workshops and briefings:

• Speaker training for the Mozilla Taipei university program, Jan 17
• Facilitator for Common Voice design sprint, Mozilla Taipei, Apr 28-29
• Spring Firefox press briefing, Taipei, May 19
• Spring Firefox press briefing, Singapore, May 26
• Augmented City VR/AR Workshop, VRARA & Intel, Singapore, Jul 15
• Speaker training for Mozilla dev conf, Mozilla Taipei, Sept 20

Intent To Ship

Early in 2017 I scratched an itch I'd been having around the "Intent to..." messages on Mozilla's dev.platform mailing list, and Blink's blink-dev mailing list. These "intent" messages are sent when either of these engines is changing their implementation of the web platform. These messages are extremely useful for communication between the browser vendors - which was validated by how quickly the tweets from this account got picked up by key members of Gecko and Blink development teams, being retweeted and favorited regularly.

Now, nine months after starting the account, it has only ~1600 followers, but they are largely influencers in web/browser devrel, or web platform implementors. And the tweets from the account had 375k impressions in the last month, according to Twitter's analytics.

• @intenttoship on Twitter
• Bot source code on Github
• The bot runs on Glitch.com, with a cron.org keepy-uppy job

Feed-to-tweet is a module I wrote for easily creating Twitter bots driven by feeds

• Feed-to-tweet source code on Github
• Feed-to-tweet on NPM

Infinite-rss is a module I wrote for generating test feeds through URL configurations

• Infinite-rss source code on Github
• Infinite-rss live endpoint on Glitch.com

Performance

Around the Quantum launch I started some work around performance testing, digging into some low-level performance characteristics of Firefox while running the Speedometer 2.0 benchmark. It resulted in some handy cross-browser automation tooling - I implemented part of Chrome's Puppeteer API in Node.js.

Once it was easy to run Speedometer with multiple browsers and different versions, I added some measurements of things like CPU usage and disk IO. The work isn't done yet, but the most interesting learning yet is that it's beginning to look like the quantity of writes, irrespective of the amount of data, is the determining factor in performance on Mac for this particular test. More to come in 2018 on this.

• Automation scripts for cross-browser Speedometer testing on Mac
• Puppeteer for Firefox on Github
• Puppeteer for Firefox on NPM

Speech Recognition

I worked with Andre Natal to take the work done in the Voice Fill Test Pilot experiment for Firefox, and make it accessible to developers both for web and Node.js use.

Voice Fill is an extension, which uses a cloud-based speech recognition service run by Mozilla. It's a private cloud service - not connected to any type of account, and no audio is saved on our servers.

This means that developers who want to add speech recognition to their web pages, apps and devices can do so without having to buy into a cloud provider ecosystem.

I started by modularizing the extension code into a single library for web pages.

• Source is at speaktome-web on Github
• Module is at speaktome-api on NPM

I also wrote a module for using the service from Node.js in your own devices - a RaspberryPi with a USB microphone, for example. This was a fun jaunt through the various libraries that deal with mics and recording and codecs and I only cried a little bit. But it works pretty well now, so time well spent.

• Source is at speaktome-node on Github
• Module is at speaktome-node on NPM

WebExtensions

I've been writing browser extensions for Firefox since 2005, and in 2017 Mozilla made the biggest change in how extensions are written since they were initially added to the browser: The WebExtensions API. It's a change that sets the stage for Firefox to be much faster and safer while still being customizable. I spent some time migrating some of the extensions I'd written that I just couldn't live without, and also doing some experimentation with making new browser APIs and a few more experiments.

• Tab hiding: The tab groups extension needs an API for hiding and showing tabs, so I wrote an experimental version of that API.
• Dormancy: Once the tab.discard API was implemented, I ported Dormancy, an extension that unloads the web content in tabs after five minutes of not being used. Source code on Github, AMO listing
• Peek: An experiment in quick access to web content without breaking the user workflow. Source code on Github, AMO listing
• Tab Statistics: Extensions for showing different statistics about how you use tabs. It is implemented as a single extension, but since WebExtensions only allows a single menu item per extension, I listed four different versions on AMO, each showing a different piece of information. Source code on Github
  • Tab Count on AMO
  • Tabs Opened on AMO
  • Tabs Closed
  • Tab Switches
• Force Google Locale: Detect your locale, and add it to Google URLs. Source code on Github, AMO listing
• Vim Keybindings: HJKL navigation on web pages. Source code on Github, AMO listing
• Always Right: New tabs in the same place all the time forever. AMO listing, Source code on Github

Miscellanous Projects

• Web and Messaging: Research exploring how the web and messaging apps can play together. Research on Github
• TreeViewSortable: An extension for the Atom Editor for sorting the file tree in different ways. Source code on Github
• Twitter Inline Oembed: Embed Tweets in a single line of code in your blog posts. Source code on Github, On NPM

Writing

While I had a few posts that I really liked and were successful, I really thought I'd write more this year, and am disappointed by how little I managed to publish. I have a huge number of partially completed posts in my drafts folder. I need to create a habit of flexing the writing muscle regularly.

The big traffic post was about my absurd number of tabs. I did some basic performance testing across a bunch of versions of Firefox, which showed dramatic improvements in startup time even with more than 1000 tabs. I really didn't expect such a response - #1 on HackerNews (537 comments!), coverage by loads of mainstream tech news outlets like ZDNET, and pretty massive comment thread on /r/programming.

• Jan 11 - Infectious Ideas: Scaling the Physical Web (Medium post)
• Jan 31 - Barcamp Yangon 2017: Technology, Community and the Largest Unconference in the World (Medium Post)
• Mar 28 - FOSSAsia 2017 (blog post)
• Jun 12 - Trust, Lies and Fitness Wearables, for ThingsCon's State of Responsible IoT report
• Jul 06 - A-Frame Quickstart for Augmented City (blog post)
• Jul 12 - Augmented City - VR (blog post)
• Jul 20 - Augmented City - Singapore (blog post)
• Jul 21 - The New Firefox and Ridiculous Numbers of Tabs (blog post)
• Aug 08 - The Secret of Flow State - Productivity for Busy People, for SuperYesMore's Human in the Machine series
• Sep 21 - Always Right – An Extension Migration Story, for Mozilla Hacks

I've got a Firefox profile with 1691 tabs.

I started trying to write down why, but gave up for now. It was becoming an overly long exploration of product design and the future of the web.

It's Friday. Let's keep things simple.

As you would expect, Firefox handled this profile quite poorly for a long time. I got used to multi-minute startup time, waiting 15-30 seconds for tabs from external apps to show up, and all manner of non-responsive behavio(u)r.

And then, quite recently, everything changed.

Quantum Flow

Right now, more effort is being put into making Firefox fast than I've seen since... well, since I've been working on Firefox. And I've been at Mozilla for more than a decade.

Part of this effort is a project called Quantum Flow - a bunch of engineers making changes that directly impact Firefox responsiveness. To learn more and follow along with these efforts, read Ehsan Akhgari's weekly posts.

A lot of the improvement in this particular scenario is from Kevin Jones' work on bringing the overall cost of unloaded tabs as close to zero as possible. While the major work has landed, the work continues in Bug 906076. Huge amounts of thanks for the recent wins for us pathological tab hoarders go to Kevin, Dão Gottwald, Mike de Boer, Tim Taubert, David Teller, Mike Conley, and Gijs Kruitbosch.

Test Scenario

I took my 1691 tab browser profile, and did a wall-clock measurement of start-up time and memory use for Firefox versions 20, 30, 40, and 50 through 56.

These are my personal results. You might not get the same results. If you test 1691 (or even 1692) tabs and find something totally different, I'd love to hear about it.

Notes:

• I shut down most things on my Macbook (yeah the little one that's more like a glorified iPad).

• I turned off wifi. This is a measurement of Firefox, not the network, nor web page rendering.

• I measured by eyeball, using "time cat" on the command line. This might seem weird, but c'mon - I'm measuring minutes. Microsecond precision is not required.

• I measured startup time five times, dropping highs and lows. Even that wasn't really necessary - the times were startingly consistent. With almost 1700 tabs and >5 minute startup, the standard deviation was negligible.

• For measuring startup time, I killed the timer when the "server not found" page finished being rendered in the active tab. After lots of testing, I consistently found this to be the point at which the application as a whole became responsive and usable.

• For memory, I waited for one minute after the startup measurement point and then grabbed the total value from the bottom of about:memory. I waited one minute, because I observed a consistent spike in memory after startup which went away within the first minute and then stabilized for a long period after. It's all kinds of initialization that doesn't need to block the app from starting, but needs to happen once you get to browsing.

• I tested Firefox versions 20, 30, 40, and 50 through 56. I tried testing Firefox 10 but it permahung while loading the profile.

Start-up Time

Graph of startup time with 1691 tabs across Firefox versions 20, 30, 40 and 50 - 56. The Y axis is minutes. Yes, Firefox 51 took almost 8 MINUTES to start up. However, as of Firefox 55 it only takes 15 seconds. For 1691 tabs. Really. I no longer fear restarts. Lately, I just restart Firefox for fun sometimes.

It's interesting that Firefox startup time got consistently worse over time until Firefox 51. It'd be interesting to do this test with varying numbers of tabs and find out at what point these types of regressions become noticeable.

Memory Usage

Graph of memory use one minute after startup with 1691 tabs across Firefox versions 20, 30, 40 and 50 - 56. While consistently using around two gigs of memory, we've now reduced to less than half a gig. Yes, this is without actual web pages loaded, but look at this, haters: I've now got 1.5 gigs of memory to load web pages into that I didn't have before.

The efforts that the Firefox and Gecko and Servo teams are putting into making a SUPERFUCKINGFAST browser are having a real impact, and that's exciting to see.

We brought a group of developers and designers together for a day to explore how a city can be experienced using VR and AR. The day was split into a lightweight ideation workshop in the morning and team coding after lunch. The technical focus was to use A-Frame, a declarative 3D authoring tool for VR on the web, to rapidly prototype the ideas from the morning.

A post shared by rockintosh (@rockintosh) on Jun 9, 2017 at 8:52pm PDT

Event Concept: The Un-Hackathon

Augmented City is an experimental event series created collaboratively by the XR Alliance and Mozilla. The kickoff of this first installment was supported by Intel, and was in Singapore on July 15, 2017.

Vanessa Radd, Chris Gomez and I met at FOSSAsia in March, and they reached out about doing an event together where professionals can learn and create VR and AR experiences together as a group.

We wanted an event that...

• Had a specific theme, instead of an overly broad prompt of "make stuff!"

• Was oriented towards experienced professionals, not beginners (there are loads of those events already)

• Welcomed both developers and designers

• Had a focus on actually making something, not a series of talks

• Was not competitive - no "winners" and "losers", no prizes

• Treated the participants humanely: One day, no overnights, start at a reasonable hour, and serve healthy food (no pizza!)

The theme that Chris came up with was "augmented city", which is flexible and broad enough that we could do a series of events, possibly in different cities, experimenting with the format to refine it over time.

Event Design: The Un-Hackathon

In May I'd helped out at the Mozilla VoiceJam, a two-day design sprint with Michael Henretty and Shing Lyu, which invited local designers, researchers and developers to get together to come up with ways to get people to donate their voices for Project CommonVoice.

At that event we used some of the human-centered design practices in Mozilla's Open Innovation Toolkit to help the group come up with ideas and refine them over two days.

At this event, I wanted to take it a step further and see if we can take a group from innovation prompt to working code in one day.

I wanted the participants to spend time thinking divergently on the overall topic, in order to reset their imaginations - sort of a palate cleanser for the day. I also wanted them thinking divergently within their selected project area, to reduce attachment to previously conceived project ideas (their own, or seeded by our prep materials).

The prompt for the day was:

"How can we augment or virtualize our experience of Singapore in ways that are interesting, engaging and fun?"

The main parts of the final program:

• Prep participants in advance on A-Frame.
• Create teams on arrival.
• Ideation round on innovation prompt.
• Ideation round on project ideas.
• Team coding.

We wanted a mix of developers and designers, so on the Eventbrite page, offered tickets for each. This means we knew in advance that the ratio was almost 50/50.

How The Day Went

Prep: We published a few blog posts to prep the participants for A-Frame and how to do VR on the web, including those in the pre-event emails. However, in a show of hands at the actual event, we found almost nobody read any of the material. Lesson learned!

Teams: As we knew the participants were split down the middle, I put post-its marked with numbers in two stacks by the doors, one stack for developers and another for designers, that matched with corresponding numbers on the tables. This way, teams were selected at random, divided evenly by role, and and no time was wasted during the event on team-making. A sound strategy in theory. In reality, the people who showed up were almost exclusively developers.

Topic Ideation: This was a sped-up version of the Idea Generation process of diverging then converging ideas from the group, done in teams with post-its at their tables. The teams seemed to have a blast, and the exercise seemed useful in helping design the landscape of ideas for the rest of the day.

Project Ideation: We used the same Idea Generation process as before, but seeded it the top two categories from the first ideation round. The goal here was to narrow down all the project ideas generated based on the categories in the first round, into one project idea. It definitely was successful in generating project ideas from categories, but the narrowing didn't really work - teams had multiple ideas and really needed more time to coalesce on one.

Coding: Almost two-thirds of the time of the event was allocated to actually making the selected idea. This was good, as the first two hours was spent getting people up to speed on A-Frame. As people got more comfortable with the tool and dev workflow, the pace and excitement quickened, with people showing the things they got working. Some teams worked together on one idea, some teams worked on their individual ideas, but communicating and sharing as they went.

Closing: At 5:30pm, people were still focused and coding, with the occasional whoop when something worked. We did a quick share around the room, had a conversation about how people felt about the event itself, and closed it down.

Notes for Next Time

• Move any prep material into the event itself. Next time I'd add a one-hour A-Frame bootstrap workshop into the program, maybe even before the ideation section...

• Make teams only once everyone is in the door. Was a nice experiment, but too much can go wrong, forcing time to be used to readjust teams later anyway.

• Before team-making, do a whole-group activity, even it's speed intros.

• Redesign the ideation parts to be one session with multiple activities that results clearly in one and only one project.

• Glitch worked. People were able to get examples up and running in no time at all, and started remixing them to meet their own project needs.

• Common issues that came up when working with A-Frame: How to load transparent PNGs, how to position a specific part of a 360 degree photo as the default view, and how to train AR markers, how to use the and reference assets, and what exactly to modify when you've got an asset, a link and the actual entity itself.

• Things that came easy in A-Frame were almost entirely due to the flow of being able to remix the examples on aframe.io on Glitch. Once I showed people that flow, things really got moving. However, it also meant that the projects all contained the same layouts, default entities, text, etc. Need to find a way to use that flow but encourage visual differentiation.

• I need to make a better set of A-Frame starter Glitch examples for AR scenarios based on my demos. Right now they're too hard to remix.

Overall the event went really well. Most gratifiying was seeing how focused everyone was in the afternoon, and how many people stuck to the theme. People definitely were deep in the flow, using A-Frame to bring their ideas to life, which is a win.

The resources, links and projects from the event are all collected on the augmented-city/singapore repo on Github.

See you at the next one!

A post shared by rockintosh (@rockintosh) on Jun 9, 2017 at 8:52pm PDT

VR

With every passing day, virtual reality is becoming less weird and more a fact of life for developers and designers everywhere.

VR hardware isn't ubiquitous yet, and is actually still both cumbersome and expensive. Momentum is gathering regardless, both in experimentation and business investment.

The web is the largest deployment surface with the least friction for content of any kind. Given the still early stage that VR is at, being able to make it and publish it on the web provides the innovation vector that is required for VR to succeed.

WebVR

WebVR is a standard for exposing VR hardware capabilities to the software context of web applications, and then rendering the page to that hardware. The specification describes an API in JavaScript for enumerating HMDs and controllers, among other things.

Mozilla, Google and others have been working together over the last couple of years to develop the standard, and are now starting to ship the initial versions. The specification was tagged at version 1.1 but is not yet finalized, so implementations may yet change.

• WebVR spec development is driven by the W3C WebVR Community Group
• WebVR draft specification on W3C's Github
• WebVR API documentation on MDN
• Most conversation happens on the WebVR Slack

Browser Support for WebVR

• Firefox: Supported on Windows and Android since version 55 (beta at the time of this post), and in nightly builds on Mac.
• Chrome: Supported, but off by default, need to flip a flag.
• Edge: Supported unprefixed as of build 15002+ on Desktop, Mixed Reality, Mobile and Xbox.
• Safari: Unsupported, but Apple just joined the WebVR community group, so there's a possibility of support but no explicit statement yet.
• Samsung: Supported on Samsung Internet Browser for GearVR.

Mobile and the WebVR Polyfill

Smartphones can be used for WebVR experiences inside "cardboard" or other devices designed to contain a smartphone for HMD-like experiences.

These most often use the WebVR Polyfill, a JavaScript library created by Google which mimics the WebVR API functionality, rendering the scene for each eye in software. Libraries like Three.js and A-Frame use the polyfill when no hardware is detected.

If you open an A-Frame scene on your mobile phone and touch the HMD icon, the polyfill will kick in and you'll see the scene rendered for each eye separately, and you can then insert the phone inside a VR viewing device.

The polyfill uses the orientation web API, so even responds to your movement, allowing you to look all around within the scene.

HMD Support

Currently both retail versions of the HTC Vive and the Oculus Rift work with Firefox and Chrome's implementations of WebVR. Instructions for all of these combinations are at Mozvr.com.

Microsoft Edge only supports their Mixed Reality hardware at this time.

David Rousset wrote a great overview of writing a WebVR application that works in all hardware platforms, with this excellent visualization of browsers and hardware platforms. One thing to add is Firefox Android also supports WebVR from version 55.

A post shared by rockintosh (@rockintosh) on Jun 9, 2017 at 8:52pm PDT

Augmented City

The Augmented City event is an all-day workshop focused on quickly prototyping AR/VR experiences on the web, and with a theme of Singapore itself.

What does an augmented Singapore look like? What can it do? What can you do in it? Maybe it tells its own story - its history. Maybe it shows you what music is happening nearby, or which hawker stalls you should try. Maybe lets you see trees that used to be, or shows visualizations of the changing waterline over time as the city grew.

Some more ideas:

• I love these visuals from @rockintosh on Instagam - the ArtScience Museum disintegrating and floating away is fantastic.

• Use public data to create 3D and virtual maps with tools like Vizicities.

• Vive put up a post with a bunch of examples of teaching history through VR, and the BBC made this exploration of the Pantheon in Rome. I've been playing with a model of Kowloon Walled City in Hong Kong (but it's not ready yet...). What in Singapore's history can you recreate virtually?

• These "following eyes" from NYPSIDM students here in Singapore are fantastic. Imagiine an AR version, placed all around the city!

• Tell a story about the musical history of Singapore, or showcase contemporary music using AR. I like this use of AR for scanning record covers to listen and learn more about the music they contain.

• To be honest, I want an AR app that translates the kopitiam menus into something I can understand so I can order coffee the right way... somehow I always order it wrong!

A-Frame

This guide will help you quickly get up to speed on using A-Frame, Mozilla's library for declarative authoring of 3D content for virtual reality and augmented reality web experiences. The guide contains links to documentation, learning tools, useful components, tips and tools for debugging, and locations for finding help.

Documentation and Learning

• The official A-Frame website has documentation and examples.
• A-Frame School is a short interactive curriculum for learning A-Frame.
• Check out the A-Frame posts on the Mozilla Hacks blog.
• If you're a podcasty person, check out this interview with A-Frame core developers on the Voices of VR podcast, to learn more about how A-Frame got to where it is, and where it's going.

Start Coding

Glitch.com lets you author and run full web projects, with HTML, CSS, JavaScript and Node.js. Create a free account and you can start hacking on A-Frame right away. If you're a more experienced developer, check out the A-Frame installation page to add it to your development environment.

• Get started with the A-Frame Glitch example. Click the link and choose "Remix your own". Then try moving the objects around, changing their color, or animating them, to get a feel for what A-Frame can do.
• Try remixing some more advanced examples like the trippy shooting stars or a webcam circus mirror.
• Here's a basic A-Frame example on Codepen

Features and Components

Some basic things to try:

• Positioning of objects in your scene
• Animation of objects in your scene
• Link traversal - navigating between different VR web pages!

A-Frame's extensibility is an entity component system, which has enabled a huge number of components to be created to add functionality. A few useful modules are listed below. You can create your own components also.

• Add physics to your scenes and objects with Don McCurdy's aframe-physics-system component. Check out Belén Albeza's guide to A-Frame physics on Mozilla's Hacks blog.
• The A-Frame environment component allows you to preconfigure and generate whole worlds.
• Networked A-Frame lets you build multi-user easily. Can you think of a way to augment your city by creating social experiences in VR and AR?

Other A-Frame Projects To Try

• Create your own city with the A-Frame City Builder
• Learn how to build your own Minecraft in A-Frame
• Read through this list of authoring tools
• Awesome A-Frame has links to all kinds of A-Frame libraries, examples, projects that will inspire and amaze.

Objects and Models

A-Frame supports loading glTF, OBJ and COLLADA models, and there are loads of ways to create your models in those formats, as well as find models you can use. Read more on the 3D Models page on the A-Frame site.

Tools and Debugging

The most important tool for working with A-Frame is the Inspector, shown in the screenshot above. You can read all about A-Frame Inspector and more tools here.

Participating and Getting Help

• Stack Overflow is the best place to ask a technical question about A-Frame.
• The A-Frame Slack is fantastic for realtime feedback, community and conversation.
• Follow on Twitter at @aframevr.
• Get inspired by A Week of A-Frame, weekly blog posts by core team member Kevin Ngo, who writes up all the cool projects, demos and components.

Read more on the A-Frame Community page.

The conference is entirely open source and volunteer-run, which is really neat. Kudos to the organizers for putting it on, which is a huge amount of work. The focus on free and open source software and tracks on relevant topics like AI, Bitcoin, and IoT combine to make a great collection of people to put in one place for a weekend.

Mozilla didn't directly sponsor this year, but instead sent some of our Tech Speakers who had talks accepted and myself. We were seven people from six countries, speaking about VR, WebAssembly, Web-RTC, security, IoT, AR and more. Big thanks to Bob Reyes, Diky Arga Anggara, Noritada Shimizu, Santosh Viswanatham, Shah Mijanur Rahman and Trishul Goel for speaking at the conference and putting in a bunch of hours at our table every day.

The number of speakers was enough of a presence to earn us a table in the exhibition hall, so we took advantage of the opportunity and demo'd A-Frame VR and AR on mobile devices for all three days.

The response was fantastic - lots of people having their first VR experience of any kind, and everyone was mindblown that the demos were built using web technologies, running in a browser, and on a mobile phone.

After three days of rapping with everyone who came by the booth, here are a few impressions:

• Most people, developers included, haven't strongly engaged in VR yet. If you assume everyone is doing it, you're probably in the VR industry and you're wrong. I've been demoing VR at conferences for the last couple of years and I always ask if people have tried it before and the answer is usually "no". VR may be in the limelight in tech news, but the on-the-ground experience says it's still very early days.

• A-Frame has excellent name recognition. This conversation a lot: "This was made with a JavaScript library called A-Frame." "Oh, A-Frame!" "You've used it?" "No, but I've heard of it and it looks awesome!".

• Almost nobody was talking about bots.

• Almost everybody was talking about AI and machine learning.

• People are still asking us about Firefox OS.

Conference

What I liked:

• Great crowd. It really feels like a practitioners conference where people are learning reciprocally.
• Talk topics are really good. Very little fluff on the schedule. Great mix of interesting and practical topics. Good job by organizers here.
• Excellent conference website and apps. They're writing their own FOSS event management stack, and it seems pretty great so far.
• Communication from organizers prior to the event was really good. Combination of emails for important things, and Google Group and Slack for general communication really worked well.

What I'd like to see next year:

• Speakers should not have to pay for tickets.
• Need a venue that's centrally located, easier to navigate and that lets attendees focus on the conference.
• Singapore already has lots of events, and is famously expensive for hotel and venue space. To make a truly pan-Asian conference, should move around to different cities.
• The schedule was changed at the last minute without warning to speakers, causing some to miss their talks. Need to lock the schedule down, and communicate changes very clearly.
• Day two and three each have 15 tracks! I'd prefer to see a smaller and more focused set of tracks.

Social, Photos, Whatnot

• FOSSAsia pool on Flickr
• FOSSAsia official photog's photos
• #fossasia on Twitter
• #fossasia on Instagram
• My FOSSAsia 2017 tweets

Our Talks

Huge thanks to Engineers.sg, who recorded almost all of talks. The complete set of FOSSAsia 2017 recorded talks is here on their website.

• OpenSec and Why WebAppSec Matters - Shah Mijanur Rahman (SYLHET, Bangladesh)

• Tea Linux OS, Designed for Programmer / Developer - Diky Arga Anggara (Semarang, Indonesia)

• Creating your own Pokemon-world in Web based Virtual Reality - Santosh Viswanatham (Hyderabad, India)

• WebRTC - future of Video Chats - Trishul Goel (Delhi, India)

• WebAssembly: now web is a new compiler target architecture - Noritada Shimizu (Tokyo, Japan)

• Integrated Physical Computing on the Web - Dietrich Ayala (Portland, OR, USA)

THANKS FOSSASIA!

MozFest is an annual celebration of the open Internet movement. It's where passionate technologists, educators, and makers come together to explore the future of the open Web.

Sounds pretty cool... but what does an "annual celebration" of web exploration actually look like? Well, here's something a bit more of a visual:

Imagine an nine-floor open-plan art school in London, completely taken over for a weekend by over 400 artists, designers, activists, teachers, hackers and makers, putting on hundreds of workshops, talks and building and showing interactive art, games and various other exhibits of thrilling wonder.

It's truly spectacular and an overwhelming thing to experience.

My biggest wish for Mozfest is for it to leave London - to transform into a regional distributed series of festivals that bring these wonders to the world outside of London (I hear it exists!). Hopefully that will happen someday.

But for now, read on to learn about some of the spaces, projects and exhibits I participated in this year.

Dilemmas in Connected Spaces

Mozfest is composed of a number of "spaces", most of which are housed on specific floors: Journalism, Science, Arts, Youth, etc. This year I was one of the curators and coordinators of the Dilemmas in Connected Spaces... space.

There are a zillion websites, tutorials, workshops and classes that provide how-to knowledge of IoT, so we decided to not use our space to duplicate those efforts.

Instead, we designed our space to explore the challenges that arise from the ubiquity of connected physical computing devices in our lives. and then built it with 500 cardboard boxes!

We divided the space into different zones: The Open IoT Studio, Home, Garden and the Nomad Tent Camp. I decided to explore the dilemma of over-stimulation in our digital lives by running the Nomad Tent Camp, a chill zone where almost nothing was scheduled - a place for weary Mozfest travelers to rest their weary feat, chill out and talk with other explorers. I set up a couple of large spray shelters as tents, and filled the area with comfy chairs. Sure enough, all weekend long we had people coming through and doing naught be relaxing and chatting with strangers they met at this quiet oasis amongst the chaos.

(Somehow I have no pictures of my own zone! Please use this placeholder to imagine it.)

If you'd like to learn about the rest of the Dilemmas in Connected Spaces activities, you can follow Jon Rogers and Michelle Thorne's Open IoT Studio, read about Ian Forrester's Home space and hear what Michael Saunby did in the Garden on this radio interview.

Mozfestation.... GET INFECTED... WITH IDEAS!

Katie Caldwell, Liz Hunt and I worked on a project that came out of their work in the Connected Devices group on Project Magnet and some of my Bluetooth experiments called Mozfestation. We wanted a way to encourage people to explore more of the festival than they would've otherwise - and to get exposed to as many ideas as possible during the weekend. And I had a 100 beacons...

So we made iOS and Android apps for discovering, accessing and saving beacons (a hacked version of Magnet's React Native app, made web pages for 100 curated things at Mozfest, made a leaderboard for showing top-visited beacons and the users who'd seen the most beacons, and then put posters and flyers all over the festival to let people know about it.

In the end, it was a ton of work and a ton of fun. We learned a ton about large-scale beacon deployments, minimum-viable-gamification, mobile app uptake tactics and loads more. It was a huge experiment and it was FASCINATING. There's a lot involved in the design, implementation, festival execution, and the analysis of the data collected, so I'll go over all of that in a separate post.

**A-Painter: 3D Painting in Virtual Reality!

**

One addition to the space was Mozilla's A-Painter, a purely web-based virtual reality 3D painting experience. It's a web app written using A-Frame, the web toolkit for building 3D and VR experiences in the browser. A-Frame is both incredibly powerful and incredibly easy to use, and it was showing up all over the festival, almost anywhere that someone was doing a session or exhibit about VR.

We set up the A-Painter space next to the nomad tent camp, which is on the 6th floor of the school, where the fashion classes are taught. The whole space is littered with mannequins that have paper-prototypes of clothing concepts on them. We clustered a bunch of these around the space and even used two of them to hold the HTC Vive's positional sensors.

https://twitter.com/JoelGethinLewis/status/792388060164067329

Vanity Trumps Privacy Trumps Vanity

Since the demise of Firefox OS, I've been collecting all of the old Flame developer devices that I can get my hands on. These are smartphones, no... computers, packed with sensors, and with screens built-in, and with the ability to run applications built using the web stack but with access to WAY more functionality than traditional web pages. I've been using them as IoT devices, art pieces, privacy tools and more. I've been playing around with using them as camera arrays, and have a few side-projects (as yet unfinished) doing things like turning them into piecemeal mega-screens, chandeliers, etc.

So when Kevin Fann started talking about his idea for an exhibit at Mozfest that explored the tension between vanity and privacy, all I could think about was how the selfie is a fantastic expression of that tension, and I've got all these smartphones... no, cameras lying around.

Kevin, Jordan Gushwa and I designed a walk-through experience with loads of phones on selfie-mode and even a secret hidden camera that records live video and displays out outside the exhibit... so you don't know you're being recorded until after you exit.

Kevin created eye-catching frames and placements for all the phones, and selected a few relevant video clips to have repeating on some of the phones. I wrote some code that streamed the live video from the hidden phone over Web-RTC to a Raspberry Pi hooked up to a screen outside the exhibit.

Kevin packed everything up into suitcase, which could not have looked more bomb-like:

Here's a video tour of the wall in all its glory:

https://twitter.com/dietrich/status/792302372861177856

The end-result was epic: People were mesmerized by so many phones showing them the live camera view of themselves.

Mozfest 2016. It's over. I'm exhausted. It was a parade of wonders. I hope someday it will come your way.

Cheers.

A couple of weeks ago, Eddie and Evan from Project SensorWeb helped me put together a NodeMCU board and a PM2.5 sensor so I could set up an air quality sensor in Portland to report to their network. They're still setting up the project so I haven't gotten the configuration info from them yet...

But you don't need the SensorWeb server to get your sensor up and running and pushing data to your own server! I want a copy of the data for myself anyway, to be able to do my own visualizations and notifications. I can then forward the data on to SensorWeb.

So I started by flashing the current version of the SensorWeb code to the device, which is a Nodemcu 0.9 board with an ESP8266 wifi chip on board, and a PM2.5 sensor attached to it.

I used Kumar Rishav's excellent step-by-step post to get through the process.

Some things I learned along the way:

• On Mac OS X you need a serial port driver in order for the Arduino IDE to detect the board.
• After much gnashing of teeth, I discovered that you can't have the PM2.5 sensor plugged into the board when you flash it. After getting the regular version flashed correctly, I tested with Kumar's API key and device id, and confirmed it was reporting the data correctly to the SensorWeb server.

Now for the changes.

• I set up the Maker channel on IFTTT, which allows me post data to an HTTP endpoint to get it into IFTTT's system.
• I then created a new IFTTT recipe that accepts the data from the device and pushes it into a Google spreadsheet.
• I forked the SensorWeb code and modified it to post to the Maker channel instead of the SensorWeb server. I flashed the device and viola, it is publishing data to my spreadsheet.

And now once SensorWeb is ready to take new devices, I can set up a new IFTTT recipe to forward the posts to them, allowing me to own my own data and also publish to the project!

Last month I spent a week working on IoT projects with a group of 40 researchers, designers and coders... in Anstruther, a small fishing village in Scotland. Not a high-tech hub, but that was the point. We immersed ourselves in a small community with limited connectivity and interesting weather (and fantastic F&C) in order to explore how they use technology and how ubiquitous physical computing might be woven into their lives.

The ideamonsters behind this event were Michelle Thorne and Jon Rogers, who are putting on a series of these exploratory events around the world this year as part of the Mozilla Foundation's Open IoT Studio. The two previous editions of this event were a train caravan in India and a fablab sprint in Berlin (which I also attended, and will write up as well. I SWEAR.).

Michelle and Jon will be writing a proper summary of the week as a whole, so I'm going to focus on the project my group built: Bubble.

Context

From research conducted with local fishing folk, farmers from a bit inland, and a group of teenagers from the local school, we figured out a few things:

• Mobile connectivity is sparse and unreliable throughout the whole region. In this particular town, only about half the town had any service.
• The important information, places and things aren't immediately obvious unless you know a local.
• Just like I was, growing up in a small town: The kids are just looking for something to do. Initially we focused on the teens... fun things like virtual secret messaging at the red telephone boxes. Imagine you connect to the wifi at the phone box, and the captive portal is a web UI for leaving and receiving secret messages. Perhaps they're only read once before dying, like a hyperlocal Snapchat. Perhaps the system is user-less, mediated only by secret combinations of emojis as keys. The street corner becomes the hangout, physically and digitally.

We meandered to public messaging from there, thinking about how there's so much to learn and share about the physical space. What's the story behind the messages to fairies that are being left in that phone box? I can see the island off the coast from here - what's it called and what's out there? Who the hell is Urquardt and what's a "wynd"? Maybe we make a public message board as well - disconnected from the internet but connected to anything within view.

We kept going back to the physical space. We talked about a virtual graffiti wall, and then started exploring AR and ways of marking up the surroundings - the people, the history, the local pro-tip on which fish and chips shop is the best. But all of this available only to people in close physical proximity.

Implementation

Given the context and the constraints, as well as watching direction some of the other groups were going in, we started designing a general approach to bringing digital interactivity to disconnected spaces.

The first cut is Bubble: A wi-fi access point with a captive portal that opens a web page that displays an augmented reality view of your immediate surroundings, with messages overlaid on what you're seeing:

A few implementation notes:

• We used a Raspberry Pi 3, running as a wi-fi access point.
• It ran a node.js script that served up the captive portal web UI.
• The web UI used getUserMedia to access the device camera awe.js for the AR bits and A-Frame for a VR backup view on iOS.
• We designed a logo and descriptive text and then lasercut some plaques to put up where hotspots are. Designs, board, battery and boxes:

Connected to the front-end:

In the final box:

Challenges:

• Captive portals are hobbled web pages. You can't do things like use getUserMedia to get access to the camera.
• iOS doesn't have any way to let web pages access the camera.
• Power can be hard. We talked about solar and other ways of powering these.
• Gotta hope they don't get nicked. Bubble was an experimental prototype. There are no plans to work further on it at this time. If you're interested, everything is on Github here. You can read more about the design here (PDF).

Thanks to fellow team members Julia Gratsova, Katie Caldwell, Vladan Joler. (Sadly, no Julia in the phonebox!)

So I wrote a small Firefox add-on that changes the functionality of the "play" button in Web IDE to also open the Developer Tools once the app has launched.

Warning: It's not pretty. There's probably a better way to do it. Take a look at the source here and let me know if you have ideas.

INSTALL

A couple of other things I want to add:

• First force-stop app when you hit Play. Currently the new app source doesn't get reloaded because the old app instance is running, which is wrong and maddening.
• Always show dev tools. The way the pop in and out is very heavy feeling. Just keep them open all the time.

But two things were driving me batty about the Pocket feature built into Firefox:

1. The design of the popup experience when you save a page to Pocket is... unfortunate. It stays up far too long, and it doesn't go away when you switch tabs. Yeah, it stays open for a given URL even when you're on a tab with a completely different URL! But regardless of whether you think that's as crazy as I do, I never want to add tags so just don't need it at all.

1. The Pocket toolbar button doesn't indicate whether you've already saved the page or not. You have to click the button to figure it out. Now this might not be a problem for everyone. But the way I use my browser can best be described as "tabsplosion". I don't know when or where these tabs come from, or how they get there, or whether I saved it already or not. So this tiny piece of ambient visual signal would be useful for me.

So I took a couple of hours over the last few evenings and scratched the itch. I made a Firefox add-on which does the following:

• Adds a new Pocket button to the toolbar. (You can remove the old one by right-clicking it and choosing "Remove from Toolbar"). Mine is red. I want to make one that has nice gold double-stitching on it...

• The new button shows a check mark badge when the page is already saved.

• You can click the button to either add or remove the page from Pocket.

• No popup.

That's it. Simple, clear and out of your way.

INSTALL HERE (WARNING: Experimental side-project software. You've been warned.)

Source code: https://github.com/autonome/doublestitch

If you try it out, let me know if you find any bugs or have any ideas for improvements!

I wanted to use it for a couple of projects, but the code was tied pretty closely to that specific content and layout.

This week I finally got around to moving the code over to Mozilla Webmaker, so it could be easily copied and remixed. I made a couple of changes:

• Update font to Open Sans
• Make it easy and clear how to re-theme the colors
• Allow arbitrary content in squares The JS code is still a bit too complex for what's needed, but it works on Webmaker now!

View my demo quilt. Hit the "remix" button to clone it and make your own.

The source for the core JS and CSS is at https://github.com/autonome/quilt.

Here is a list of things I recommend that you see, do, eat and drink and some handy tips. I've focused on places that are in or near downtown, though included some spots worth going out of your way for.

That said, downtown is not Portland. Well, obviously it's part of it, duh. But it's not overly representative of the Portland you've heard so much about. Get out of downtown for an evening or afternoon - and check out one of the neighborhoods. Nothing listed here is very far from downtown - Portland is pretty small.

I've left a LOT out. And forgot the rest. If you have recommendations, leave them in the comments.

UPDATE: Blue Star donuts, which are far more delicious but far less penis-shaped than Voodoo donuts, will be giving away free beignets on Friday Dec 5.

GENERAL TIPS

• Portland has no Uber or Uber-like services. If you have Car2Go in your city you can use that here too. Curb is the app for local taxi service through a couple of providers. You can get a bus to pretty much anywhere without too much of a wait. Ride the MAX and streetcar if you're headed to areas that they service.
• Oregon has no sales tax. Do your Christmas shopping while you're here.
• It gets dark around 16:30 - 17:00, so factor that into any plans for hikes, etc.
• If you go into the mountains, check the road conditions to see if you need chains for the car, or if the area is accessible at all.
• Go to Powell's books. Go a few times. Then go back again. Check out the Science Fiction pillar there - how many have you read?
• Get high... for a good view of the city: Have a drink at Departures, dinner at Portland City Grill or visit Pittock Mansion for great views of the city. Even driving over the Fremont bridge (Highway 405) provides a spectacular view of downtown, the Willamette River and our many bridges.
• There aren't a ton of restaurants/bars/coffeehouses that can hold large numbers of people. If you break up into groups of four (max), you'll have a much better time and the servers, chefs, baristas and bartenders will like you for it.
• Be patient. Oregon is home to the slow-food movement in America. Regardless if this explains why your coffee took 20 f*ing minutes to make, it'll make you feel better to think about that. See also the above note about small group sizes to mitigate the waits.

• Tipping: I tip a dollar for a good coffee. I generally tip ~20% for any kind of sit-down meal. But I also worked as a barista, server and chef before getting into tech, so I'm biased towards tipping ;) CARTS - Just the 9th & Alder pod for the purposes of this post. If you're from California - up here they are not "food trucks", they are "food carts"... even when they are trucks.

• Hoang's - Get soup #17.

• Nong's khao man gai - Simple and good and oddly famous.
• Wolf & Bear - Israeli street food that is amazing. And vegan.
• Güero - Excellent tortas. Add an egg.
• La Jarochita 2 - Great Mexican cart. The only Mexican cart (aside from Güero) worth going to at the 9th and Alder cart pod.
• Brunch Box - A cart that graduated to a proper storefront, but is right by the 9th and Alder carts. Great egg sandwiches for breakfast (try the Black and Blue) and terribly good burgers the rest of time. Very fast.

• Kargi Gogo - Georgian food. The country, not the American state. Irakli says it's legit too. DRINK

• Multnomah Whiskey Library

• Clyde Common
• Pepe le Moko
• Teardrop

• Bailey's Taproom COFFEE

• Courier - They also make fresh canneles daily.

• Heart - Excellent coffee.
• Barista
• Coffeehouse Northwest
• Stumptown
• Case Study
• Coava - Not downtown but my favorite coffee roaster in town.

• Ristretto - Not downtown, but fantastic coffee in beautiful spaces. The Nicolai location is especially great - check out the custom metalwork and crazy woodwork, and visit Schoolhouse Electric in the same space. EAT - I've only noted a few of my go-to places, or those that are near where Mozillians are staying, or open late, etc. I've got a somewhat-up-to-date list here with more recommendations, but there's just really too much to cover. Go out and explore.

• Clyde Common - Always interesting menu, good whiskey selection, great cocktails. Fries + harissa and a cocktail is a great way to end your day and start your evening.

• Tasty and Alder (downtown) - Shared plates, everything is good.
• Luc Lac - Vietnamese + cocktails, serves food VERY late, and closest place worth going to that's also near the Waterfront Marriot.
• Bunk - Excellent sandwiches.
• Lardo - Excellent sandwiches as well.
• Racion - Amazing cocktails and fun Spanish-tinged molecular gastronomy.
• Little Big Burger - Fast and good late night burger.

• Not downtown, but places I always want to go back to...

  • Biwa - Izakaya, open late, always amazing. Burger served only after 11pm.
  • Tarad - Northern Thai food, open late. Pok Pok gets all the attention but after living in northern Thailand, this is where we go for the real thing.
  • Mee Sen - Another good Northern Thai food spot we go to.
  • Podnah's BBQ - Worth heading up into NE Portland for.
  • La Taq - Next door to Podnah's, fantastic Mexican bar food.
  • Sweedeedee - Most likely to feel like you're in Portlandia at this spot. Amazing house-baked breads. Tiny. Expect a long wait but good people watching and excellent food.
  • Por Que No (Mississippi location) - Great tacos.
  • Ha & VL - Get the special soup of the day, whatever it is. NEIGHBORHOODS - Places to walk, eat, drink, shop and experience parts of Portland that are far more interesting than downtown.

• Alberta St - Between NE 15th Ave and NE 31st Ave

• Belmont St - A few blocks on either side of SE Belmont and SE 34th
• Division St - Between SE 30th and SE 39th
• East Burnside - From NE Grand Ave to NE 12th Ave and then up and down NE 28th and Burnside
• Hawthorne Blvd - Between SE 32nd Ave and SE 49th Ave
• N Mississippi Ave - Between N Fremont Ave and N Skidmore Ave
• NW 23rd Ave - Between W Burnside and NW Thurman Ave

• NE Williams Ave - Between NE Fremont Ave and NE Skidmore Ave EXCURSIONS

• Columbia Gorge - See Multnomah Falls, the view from Vista House, climb Beacon Rock, stop at the Bonneville Dam and see Herman the Sturgeon, drive across the Bridge of the Gods (and back), then go for lunch at one of the Hood River breweries. Some easy/moderate 1-2 hour hikes I like: Angel's Rest, the Multnomah/Wahkeena Falls loop, Triple Falls, Horsetail Falls, Punchbowl Falls, all listed here.

• Mount Hood - Drive out Highway 26 to the historic Timberline Lodge with amazing views of Mt Hood (if it's clear), then down to Hood River and head home through the Columbia Gorge on Hwy 84.
• Mount St Helens - A couple of hours north, but the view of the blast zone and crater from the visitor center on the NW side is well worth it if the view is clear. On the SE side you can hike one mile underground through Ape Cave, and check out the amazing rock formations and brave the cable bridge at Lava Canyon.
• Oregon Coast - About two hours drive. Walk the promenade at Seaside, get ice cream at Tillamook, watch storms from the tip of Oregon at the mouth of the Columbia river.