WickedGoodEmber

In which I live-blogged my trip to Boston for WickedGoodEmber 2014. Spoiler alert: it was very enjoyable.

If you're new to reading this, I highly recommend you start at the bottom (since it's written in descending chronological order).

June 23rd

While I'm still pleased with the conference itself, I've had some disappointing interaction with a conference organizer and I'm not sure I'll attend next year as a result.

June 18th @ 10:15AM

I'm now seated at my gate in Logan airport. The trip was easy—in fact, one of the things that I can say about Boston is that it was very easy to get around with the T, and I never once felt uncomfortable. It just felt like a very safe city. The weather was excellent too, though I'm glad we weren't a day delayed, because it's supposed to hit 30°C today, and 28°C was warm enough for me, thank-you-very-much.

In my experience, it's pretty rare for me to have my mind blown by a conference talk. The few that have were given by the Gary Bernhardts or the Bob Martins, and not everyone can simply be one of those gentlemen (I have a few by Sarah Mei on my watch list, and I suspect I'll add her to this list shortly). Even great, engaging speakers like Aaron Patterson don't tend to blow my mind, and polarizing speakers like DHH just tend to make me fume. I wasn't particularly expecting a grand revelation or epiphany about the industry or my practice from this conference—not that the speakers weren't great, because they were, but because that sort of tranformative talk is one in a hundred. Most are about specific topics which—while interesting to me and potentially quite relevant—aren't paradigm-shifting.

Instead, I tend to try to take all the talks in, and then a lot of the learning I do comes from my subsequent reflection. So I've been mulling the talks and the experience, and here are a few of my thoughts.

The closest thing that I came to revelation was with the D3 talk: when Phil tabbed back and forth between the tabular data and the visualizations, the difference in comprehensibility was stark. It was illuminating, a great reminder that I can help clients make sense of their raw data with only a little bit of work, and that provides a huge amount of business value to them. Likewise, hearing about Edward's troubleshooting console has me very interested in those possibilities, but I want to watch the video and review things a bit more carefully before I make a statement about it being revolutionary.

In terms of general Ember direction: the trifecta of improvements in process—Ember-CLI, HTMLBars, and query-params-new—are very nearly complete. I would be shocked not to see them all be considered best practice/rolled into stable by the end of the year. There were a lot of talks that were concerned about with the difficulties in handling offline applications. There's already Orbit.js, which released ember-orbit v0.1.0 at the conference, but if it's a popular enough topic that three conference talks touched on it, then it wouldn't shock me to see increased pressure for the inclusion of a solution into Ember-data proper in coming months.

What was notoriously missing was a talk on big datasets. That's more where my work has taken me, and I was somewhat sad to see it absent. Maybe I'll have to do up a talk for an unspecified future conference.

The conference itself was well-organized and well-presented. I'm sure there are things that Dockyard will change next year, but there wasn't anything immediately apparent that could have been fixed. I'd expect next year that the conference will be held on a weekend when other conferences aren't being held and there's more hotel availability. I also think it would be neat if the organizers picked a few spots out for post-conference drinks and food and reserved some space—it seems to me there's always a bit of a scramble to find a place to eat, and then at that time of day, it's a crap-shoot whether the restaurant has room to seat you. But these are nitpicks from what was an exceedingly well-organized conference, one that I'd be happy to attend again.

I came to the conference with the goal of being around the Ember community. The talks were interesting, and I wanted to network, but I also just wanted to take things in, and to be present at a conference for the esprit de corps. The Ember community is a great model of inclusivity and that makes it very desirable to be a part of, even aside from the cleverness of the software. (To compare, I felt much more at ease than at Railsconf two years ago. Maybe I'm just in a better place, life-wise, or maybe it was the smaller conference size, but the vibe seemed to be much more collaborative, and not at all confrontational or competitive. I've come out of the conference excited to continue my exploration with Ember, and not wishing for a viable alternative, like with Rails.)

I met my goal: I got to talk to a lot of very interesting, very intelligent people, followed a handful of new people on Twitter, and got to feel like I was part of the community, and not just a lonesome developer stuck in Moose Country, Canada. It's amazing how much you miss person-to-person contact; IRC doesn't quite suffice.

The last thing I want to add is that I was very pleased to see so many of the core team and big names at the conference. There are quite a few conferences that have been springing up and I know it must not be easy to travel so much, but there was a good official presence, and each one of those persons was approachable. So thanks to you guys for showing up and being willing to answer questions.

I think that's it. So long for now, #wgebos, and see you next year in… Boston? Providence? Who knows!

June 17th @ 11:00PM

Back and had a little bit of time to settle down. I went out to dinner with a group—Joe Fiorini, Patrick Holloway, Rob Park, and Eric Kelly. We went out to JM Curley's, which was a little burger joint downtown, and while it was very delicious, the conversation was even better. That group of guys is very smart, very in-tune with what is going on in Ember and with the web in general. Credits to themselves and to their employers.

It was a long day, and so I'm glad to be getting some sleep. It is quite warm in my room and I'm afraid I haven't really cooled off for the day, so it might be a night of tossing and turning.

June 17th @ 4:40PM — Ember Today and Tomorrow (Erik Bryn)

First up: the elephant in the room—HTMLBars. We're not talking about that. No trollface slide, but there ought've been one.

A brief history of the web.

The camera guy is standing behind Erik and it kind of looks like he has a slightly larger, slightly more bearded shadow.

Erik says the landscape is changing, and we're in a transitionary period, yet we haven't fully exploited the paradigm shift. We're returning to thick client/thin server. But there's a story around tooling that needs to be talked about. Ember-CLI is covering most of that. We're getting a taste of the future with ES6 modules thanks to CLI.

Now we're talking about javascript evolving. ES7 is slated to be the last huge language release: the consulting committee wants to do smaller iterations. There are some really cool features slated. Ember is using transitional transpilation to bring the best features to today.

Shifting gears: talking about modernization of Ember. HTMLBars will remove the dependency on jQuery, since IE6/7 are starting to go away. We're going to have things like Object.observe. Soon we'll have web components.

Erik's showing some examples of what code looks like with ES6/ES7. It's pretty amazing. A lot of the noise has been reduced.

Talking about tooling: considering lazy loading in Ember-CLI. There's some continued modularization of Ember, and the ultimate goal is to make it so that you only deploy the parts of Ember you use. We can do this thanks to CLI. That's really central.

Erik's saying Ember's had a great 2014. I'm inclined to agree.

Brian Cardarella asks about browser deprecations and how we'll handle older browsers. Erik replies he didn't mean to imply that we'd necessarily lose support, but that we will have versions of Ember that utilize these new features. Stefan Penner chimes in to say that we want to align our semantics to newer standards but also support the old features through that.

June 17th @ 4:35PM

We're raffling a few books off while we're waiting for Erik to set up. This is the oddest raffle I've ever experienced. It's a slingshot away from a football game.

Thanks go out to everyone—the sponsors, the camera guy, the band, the organizers, the speakers. And Erik's ready.

June 17th @ 4:00PM — Distributed Data (Edward Faulkner)

EDIT: Edward's got his presentation up (and, neato, it's an Ember app!).

EDIT 2: He said hi! Hi, Edward! It was nice to meet you.

Very quick break!

So Edward's been sitting next to me all day and I didn't know it. Haven't said hi yet. Whoops.

He's making the case for offline apps: high latency makes your app feel bad, and losing your user's work makes them hate you even if it's not your fault. On the upside: these are now competitive with desktop apps, and you can iterate like a web app but feel like a native app.

Here are his steps:

  1. Cache the code
  2. Store the data
  3. Synchronize.

Some of these problems are solved but not all.

Caching the code: ApplicationCache is apparently a thing. ServiceWorker isn't ready yet but can serve as a proxy server (intercept network requests and decide where to serve it from, i.e.).

Storing the data: all sorts of interesting options, such as localStorage, webSQL, and IndexDB and fileSystem. If using localStorage, there's a gotcha in that it's a synchronous interface whereas most alternatives are async. IndexDB is the champion of the standards, he says.

Talking about the object/relational debate.

Now on to Synchronize: suggestion is to stand on the shoulders of giants. There a host of problems; as he suggests in really tiny font, this could be a PhD thesis.

A few Ember-specific best practices / patterns: he suggests global state indicators ('You've been offline for 2 hours'); nested error routes; check-out-to-edit (merge when done); authentication (can be done offline with tradeoffs).

June 17th @ 3:30PM — Extending Browser Apps (Robin Ward)

Talking about RES. Highly selector-based code. Uses regex to determine appropriate URLs. I've spelunked in RES's code before, and it's a tightly coupled nightmare. Hard to disagree with what he's saying.

Now talking about Discourse. We have a front-end API with Ember, and we should utilize this to remove selector-based programming. Cool.

Robin talking about reopening classes as a way to hook in behaviour. ES6 kind of prohibits this, so initializers are the way to do it. You can also indicate load order for initializers, too.

You could supply your own resolver. You can overwrite defaults and extend into the application. Whoa, now showing off HAQL, which manpulates AST (which is part of the handlebars parser) to insert objects. Now talking about using ContainerView (which holds child views that can be mixed type). He's inserted an empty ContainerView which lets him add views from the console. But this is a lot of code, so they created {{plugin-outlet}}.

Question: how can views communicate with each other? Robin answers: Ember.Evented. He's created a general vent and injected it into everything. He cautions about its over-use, but I think this is a pretty viable strategy when you have a complicated layout situation. I've had this issue twice in my codebase—modal views need to listen to their controllers to know when to close, and my search technically exists on a level above my active routes—but I haven't really felt the need to quite create a vent. Ember's got good patterns for communication… it's not Backbone. If you were writing an application on Discourse's scale with a really complicated UI, this'd be absolutely the way to go.

This talk was definitely different than what I thought it was going to be, but it's very interesting. Lots of ideas for how to extend Ember apps. As a person who frequently writes browser extensions, I could see this being a very handy thing, and the notion of a front-end API for extensions is engaging. Even without Ember, I could see myself doing some work to make sure this was possible—I already try to make sure I'm using semantic classes to make HTML parsing easy.

June 17th @ 3:00PM

It's definitely quite toasty warm in here. More water! Snack break for a while and we'll be off again. So far I've been very pleased with the quality of the talks. With only one notable exception, they've all been strong overviews of the subject area, and they've all been relatively disparate. The one that wasn't an overview regards a domain where I've had little experience with. That said, as soon as Luke mentioned OT, I started to understand Dan's talk better. A bit of overlap in the domains, there.

I'm looking forward to these next three talks, but especially the keynote. Not sure what I'm expecting… To be really honest, all the fronts that I was particularly interested in have been covered, so what comes next is supplemental to my interests. That said, I'm pretty intrigued by the title of the talk up on the screen: 'Extending Browser Applications'.

I am not a very social person. I think I need to just suck it up and go say hi to some folks, but I get pretty overwhelmed in a crowd.

June 17th @ 2:20PM — Push Patterns (Luke Melia)

EDIT: Luke's shared his slides here.

After a desperate stretch and a rather jazzy Rickroll by the trio, we're back.

Pull: typical HTTP request: browser makes the request, and server responds. With push, server decides what to send and when (i.e. subscription to a channel).

Covering a brief history of PUSH. Late 90s: PointCast.

Push transports: four primary mechanisms.

  • Polling
    • Make XHR request for updates, wait N seconds, repeat.
  • Long Polling
    • Same as polling, but server response is delayed until there is data.
    • Quite a bit of overhead.
  • Server-Sent Events (SSEs)
    • Uses HTTP and receives with text/event-stream, and then response is sent separated by "\n\n" - Still unidirectional: server always sends data.
  • Websockets
    • Handshake over HTTP but connection immediately upgraded to socket connection: bi-directional
    • Quirks on some browser.

There are apparently push services available, like pusher.com.

  • Patterns for implementation:
    • Push Channel:
      • Well-suited to Ember apps using $.ajax.
      • Clients subscribe to one or more channels, and apps publish events to channels
      • Events have names and payloads, and these names can be used in Ember as controller/route actions to handle responses.

Learning about all sorts of interesting syntax for function definitions à la property. Knew about on but not about observesBefore. Also inside of initializers / injectors, you can pass { instantiate: false } to register which works for singleton objects.

This is pretty neat stuff. Luke shows off a pretty low-level example that works to call actions directly on a controller which manipulates the model.

  • Patterns (2):
    • Push to Data Store
      • Instead of sending to a model, send to a StoreUpdater, which updates the store, and Ember's binding takes care of the rest.
      • Suggestion: use same JSON responses as your standard API does for the data segment of the tuple, since pushPayload works that way.
      • Luke plugs Edward Faulkner's EmberConf talk re: animation to call attention to changes.
    • Find Subscribe
      • Enhance store to be able to call findSubscribe, which does a find
        • a subscribe.
      • Calling a find+subscribe in a Route's model hook and closing it off in deactivate.
      • Complicated
    • Operational Tranformation
      • Robust but complicated solution to distributed editing: operational transformation
      • Let's use the proxy pattern with ember
      • Share.js is an OSS implementation of OT / EmberShare is an ember layer.

Luke says more work needs to be done as a community to add more support for push.

June 17th @ 1:39PM — Autonomous Web Apps (Dan Gebhardt)

EDIT: Dan's released his slides.

He's released Orbit.js! I've read about it but didn't grok it well the other day.

He's interested in managing autonomy in terms of offline / asynchronous (non-blocking) UIs. Requires three data sources and synchronising them is non-trivial. Dan says we need to consider things more as transactions. If we have a set of changes that are considered one block, that enables us to do things like undo/redo.

When he started Orbit, he wanted to solve this with primitives / POJ. The primitives are Promises, Events, and Transforms. Problem: asynchronicity. Orbit tries to be very deterministic with its data.

This is a pretty technical talk.

Listeners/responders have to return promises—there's an explicit contract.

  • Requestable interface: find/add/remove/update/patch/findLink/addLink/removeLink - Transformable interface: transform

This could use some intermixed examples, I think. This is all really fascinating stuff but it's very architecturally heavy. Talking about Transform and RequestConnectors to manage transforms / lookups. Talking more about the orbit common library: models, relationships, id fields.

Here's a demo. Kind of neat. I think that this replaces/wraps a lot of what ember-data does and works kind of like a drop-in.

I don't think I'm doing this talk much justice. This might require some homework. Stay tuned.

June 17th @ 12:50PM

Lunch was plain but good—sandwiches and chips (though it sounds like the vegetarian options disappeared quickly). Have I mentioned the band yet? They have a trio that's playing during the downtimes. They're quite good and it's nice because it's volume appropriate—not once have I felt like I've needed to shout. Raise my voice, sure, a little, but that's more the people than the band.

Little snippets of conversation here and there. Chatted with Jeff more about CI and testing. Was a silent party to Robert Jackson and Joe Fiorini talking about Sass in broccoli (is it not working? I came in halfway through and couldn't ascertain – sounds like it needs to shell out to Ruby because libsass has a bug with @import in it, and that's just not very fast).

Talked a little too much about some screencasts I'm working on. Oops! Mum's the word until I actually start releasing them. I have a habit of over-sharing and it's something I'm working on.

This lunch break is looong. Time for more mingling!

A few photos of the venue…

Outside

Inside

Things are starting to warm up in here. Still comfortable, but quite humid.

June 17th @ 11:30AM — Ember: The Magic, Demystified (Robert

Jackson)

Robert's up. Hah. Tom Dale crack. Tom Dale is a funny guy.

Oh! His talk is regarding a tweet he made a while ago about what people regard the most confusing / magic things. I responded to that tweet. First up: Route lookup.

I can tell this is going to be one of those ones where you'll need slides to recap it. I'm not going to try to keep fidelity.

Application.create eventually calls Application#didBecomeReady. He breaks down route bubbling. Whoa. Nested functions calling their passed callbacks. It's simple but you need to stare at it for a minute to fully grok it, but he's time-limited so he's moving on.

Talks about how routes are autogenerated if not found. Pretty simple.

Apparently @machty is in the audience, but that's an actual sighting of @ebryn.

Route#setup gets or generates a controller, which depends on your model's plurality. Then setupController's called, which sets the model property, then render is called, which either uses specified template/view names or uses default ones. The view is set up, and then appended to the DOM.

Talking now about component lookup.

The thing you put in your components folder is a layout, and the template itself is the block param (relates to the use of yield). Feel like I don't have my head around that very well. There's some AST weirdness here, but they're calling resolveHelper, which gets a componentLookup instance from the container, which contains additional magic. Components are registered as a helper, but the lookup is through a componentFactory. This does a basic lookup for the template and injects the template as a layout (ahh!). Then we do a lookup for the component. if the template is registered or the component is found, it will resolve a template by generating a default component if the component isn't present. That's convoluted but it makes sense (the code's actually clearer than the written form).

Robert answers a handful of questions. He's done a great job demystifying lookup / context. Nicely technical.

June 17th @ 11:20AM

Over the break, talked to Katie Gengler, who gave me a solution to my testing issues with setInterval: just add a flag to disable it. There's no good way, she says, and this has persisted since before Ember-testing rolled around. Also mentioned that Backburner might now be watching for setIntervals… I'll have to check. We also talked about the idea of adding an Ember.run.later companion that would function like a setInterval, because it's a common problem, now.

Also talked to Joe Fiorini. He mentioned that Luke Melia (who's talking later today) gave a chat about deployment with Ember-CLI a while back. I'll see if I can't hunt that down a little bit later. EDIT: Joe beat me to it. Check it out right here.

Joe also mentioned that he wasn't trying to make fun of Ember, that he's got an app using it and likes it. I wasn't trying to give him a hard time. My best app is a Backbone app, too. ;)

Saw Sam Selikoff, whom I've chatted with in #emberjs. Didn't get a chance to say hi yet.

Might be worth mentioning that I'm idling in ##wickedgoodember on Freenode. Haven't heard about another back-channel, but maybe someone can let me know if there is one. I'm the only one on, so far. :(

Glad I wore shorts. It's warming up.

June 17th @ 10:45AM — Writing Tests (Katie Gengler)

**EDIT: Katie's put up her slides right here.

Do I ever need this talk. I've done some unit testing, but it was a pain to set up, and asynchronicity messes with my brain. I had a lot of issues dealing with a setInterval with a nested Ember.run cuasing tests never to complete, so I kind of gave it up. Hoping to find some illumination.

(Man, @habdelra's moustache is just phenomenal. Just out of this world.)

Katie: Why do we write tests?

  • Overcoming developer inertia
    • I hear this one. It's so much easier to get started when you have a failing test or a pending test (I often indicate where I was working by leaving one yellow/red).
  • Document behaviour
  • Prevent regressions

Test qualities that prevent testing consistency:

  • Slow
  • Expensive
  • Brittle
    • One change causes cascading failures
  • Flaky
    • Failing on one machine vs another

Ember-testing lets you thoroughly test your UI. JS testing scenario is somewhat unreliable and irritating. Ember tests are fast and easy.

Potential hint: Katie adds .spec-name-display classes to the DOM which shouldn't change so she can reason about the DOM even if designers change the actual layout of the page.

Most common cause of flaky behaviour: async.

Katie's talking about the testing pyramid: Unit > Service > UI testing. I had to pause and remind myself that Collaborator tests are technically unit tests, but that's totally fine.

Aside / minor TMI: I am so utterly spoiled by my Embody chair at home. These metal chairs are a harsh return to reality.

Jeff asks how she runs her tests in CI and what challenges she had. Katie answers that she runs with a Rake task but eventually will use Ember-CLI. Some of her tests use FactoryGirl-generated data returned from the back-end. I'd be curious to see how that works, but IMO testing consistency/format of data is a responsibility of the back-end tests.

EDIT: Katie sent me an email:

[O]ne thing I wanted to note is that the purpose of the tests using JSON responses generated by the server side is to test the integration of the ember app with the api, not to test the format of the data from the server. The backend is also tested, the ember app is tested with ember-testing by creating data directly in the store, and the integration of the two is tested with ember-testing using those generated responses, they cover the gap, as an alternative to super-slow traditonal end-to-end tests.

To which I replied:

So these function more as smoke tests / high-level integration tests? i.e. just one test or a couple per feature to ensure the hook-up between front and back end? I must have invented the idea that you were doing this to ensure the consistency of the server response with what Ember was expecting, which is a test that ought to be down-stack.

To which she replied:

Yep, they're smoke tests, just a couple per feature because maintaining the data is brittle. While the server can test that the data is the format expected, we could intentionally remove a field on the server side but neglect to make the change in the ember app … these tests ensure they are in sync.

That certainly clarifies! Thanks, Katie.

June 17th @ 10:10AM — D3 (Phil Renaud)

EDIT: Phil's slides are up and so are his examples.

Chatted with Jeff Winkler. Cool guy.

I'm very interested in this one, as I'd planned to try to pick up D3 later this summer.

Phil: We've become pretty good at recording data. Maybe too good. Twitter generates 500m t/d. Data's only valuable when it's understood. Well, if that wasn't a segue to D3, I don't know what is.

Phil shows off visualization of election fraud, comparing it to a painful and inscrutable tabular dataset. Huge difference.

D3 has methods to inject data into DOM (usually into canvases). That makes sense. That was something that I was contextually missing the few times I'd glanced at the D3 docs.

Just saw @rwjblue.

Aside: Phil shows off a comparison to Ember Components&mdasha Gravatar component to be specific. The component takes an email component and does client-side hashing to generate the URL. Had that issue in my own app lately, but I feel very uncomfortable about having an email DS.attr.

Phil's showing off some baseball statisics, showing a table converted to JSON. He's passing it as a model to an Ember Route, and iterates over the data in the template. Creating a component for each player. A joke about Bostonian pronunciation (call it 'Em-bah' if you can't say 'Em-bar'). Uses classNameBinding to add team colors to players. Conversion to bar chart based on number of hits (controller has a CP that returns the max hits, and that's passed into the component). Adds relativeHits to the component, which returns the percentage of hits compared to the max, which is converted into percentage CSS width.

Phil suggests we should let the user drive the data narrative / switch context to show different metrics. This is a massive case for the utility of SPAs. On-the-fly recalculation of specific metrics without reloading data. We're not even using D3 yet. EDIT: the more I think of this, the more I think this is more a case for the use of rich front-ends rather than SPAs. The case for SPA is more a question of the focus of the application than its utility, I guess, but a preponderance of these utilities would be a good indication for an SPA.

D3 gives us the ability to work with SVG shapes (drawing paths/lines/shapes is hard in HTML but easy in SVG).

Phil plugs c3.js, which is a reusable charting library. We're converting our bar charts to D3. Paradigm shift: instead of iterating through data, we'll pass it all in. We'll let the user filter, which will update both charts.

New components: StackedBarChart / AggregateTeamChart. Phil's hooking c3 into didInsertElement. Man, these things have taken off in the half-year they've been around (which makes me very interested to see the emergent behaviour that would come if the proposal to add services is approved).

This data visualization is blowing my mind. I remember writing YUI code five years ago to do this stuff and it took weeks, if not months. Phil did most of it live.Is there any other industry (medicine?) that turns over this quickly?

Some more esoteric D3 functions. Phil: "When you say that something's going to crash the browser, developers seem to take that as a challenge."—not exact words, but close to them. Showing off Charge, Charge Distance, Gravity, and Friction options for D3 nodes.

This was really cool.

June 17th @ 9:30AM — Ember-cli (Joe Fiorini)

EDIT: Joe's slides are up here.

Joe Fiorini's up. He's making a crack about Angular directives (now I know I'm at an ember conference).

Joe talks about 'native web apps' cf. native iOS apps. He's showing off the tool. ember new will create your directory structure and install packages.

CLI enforces a 'sane' directory structure. On the face of things, that makes me nervous because I hate the lock-in that a Rails project enforces, but I know that CLI is pretty sane, and I suspect most people will appreciate the structure.

We take a brief 10-second pause because Joe cannot stop his laptop from sliding off the lectern.

Joe's talking about namespacing, and coming to the resolver. Talking about the resolution cycle for modules.

"AMD syntax sucks." — Joe maps an AMD definition to ES6 module syntax. Much cleaner and more explicit—a win.

CLI comes with ember-qunit and qunit by default. Joe's going to show us a testing example. Live-coding! This is daring.

Generation is pretty cool, but like with Rails, I really want a way to open a file on generation. Sounds like a good pull request for when I get home.

Some minor issues with tests, but everything goes green eventually! Cheers for that.

CLI's configurable. Add-ons are now in master. Joe's going to demo them! He asks who wants to write Ember in LISP, in a dialect called Sibilant. Apparently you can specify git repos in package.json. Already learned something new. Joe tempts fate and runs npm install again over the wireless (which is holding up very well).

Live-coding is tricky, but Joe's doing pretty well. He gives credit to @stefanpenner and @rwjblue.

June 17th @ 9:15AM

And after a few train-related delays, I'm here and registered! Sat next to a guy named Jo(h)nny on the train, who was busy in vim with a Rails project. Kind of thought he might be coming here, and lo and behold, we got to talking and of course he's attending. Neat guy, but a short conversation.

The building is different than I expected. It's a sort of minimalistic building—predominantly white but with glass railings (that are made out of tesselating car windshields!!)—but there's a gigantic garage door that serves as the entrance. Basically, the left wall is entirely open. Feels nice with the breeze, but we'll see hot it goes when it gets warmer out.

There are some immediately apparent faces. Interestingly, Luke Melia was an easy one to pick out. Brian Cardarella would have been a little trickier, but he's wearing banana yellow. I think I see Erik Bryn, but it could just be a random guy with a beard. Not sure. There are a lot of beards here.

June 16th @ 9:00PM

Stuffed to the brim. Still no activity.

June 16th @ 6:00pm

Getting hungry. Nobody's around yet.

Created a widget on twitter to quickly show what's going on in the conference. See it at the top.

Going to go find something to eat in 15 if nobody is around to eat with.

June 16th @ 2:00pm

Today I'm on my way to WickedGoodEmber in Boston. I was initially very sad that I missed this year's Emberconf in Portland, but it was too far to fly and at a bad time in the year (my wife was still in school, to wit, and I couldn't exactly leave Linus alone for a week to jet off to the other side of the country). So when I heard Robert Jackson mention the conference, and subsequently realized that Porter offers a one-hopper to Boston, I was pretty ecstatic. Booked my ticket, found a place to stay, and now I'm sitting on the plane, customs form in hand.

(Just a brief note: If you've never flown Porter, you should. I find it a dramatically superior flying experience to just about every other airline. They can't expand service fast enough, in my opinion.)

I find bigger cities a little overwhelming, but I'm looking forward to being on the ground and getting to see Boston. I've never been before, but it's a city with a lot of history, and I like to see the way that the new appropriates the old. (There's a cliché in there about the evolution of software, but making that analogy is left to the reader). I also find being out with people somewhat overwhelming—a symptom of working at home with minimal contact, I guess—and so I'm hoping that I haven't completely forgotten all my social skills.

Once I arrive at the AirBnB I'm staying at, I suspect I'll find a bite of lunch, and then hopefully hit the Twittersphere to find out if or what people are doing tonight. Hopefully I can grab some dinner with some of the Emberenos. (Note to self: I don't know the name of the tilded-n character, and I can't look it up without wifi. Maybe change this once you get on solid ground?)

In the next few days of quiet, I have some client work to do, but I'm also really hoping I can spend some time finishing transcripts and getting some prep work done to release the first Embervid. I'm also going to take some notes at the conference, and I'll hope to reproduce them here.

More later.

About Me

I write about self-improvement at Think Really Hard.

I live in Brockville, Ontario, Canada, where I spend most of my time singing, cooking, and homeschooling my wonderful four-year-old Linus with my wife Becky.

Stay In Touch!