Category Archives: conferencing
ApacheCon@home
This year, for obvious reasons (covid), ApacheCon is taking place entirely online. Today was the first day. So what was it like?
Well, obviously it’s not a Jolly in a nice hotel in an interesting location, as the best events have been. Does that detract from it? Well of course those are part of the magic of the best ApacheCons – above all Budapest, where both the hotel and the city were fantastic. On the other hand, the money saved could buy quite a decent week’s holiday somewhere of my choosing! Better to focus on what did or didn’t work well in terms of presentations, communication, networking.
The economics of online worked nicely for lots of people, bringing in several thousand attendees compared to a few hundred at a “normal” event. A poll suggests that eightysomething percent of those thousands are attending their first ApacheCon: evidently a lot of people find it a lower hurdle (as I do). So we’re embracing a much bigger community, which is fantastic – so long as we don’t disappoint.
The times also worked nicely for us in European (and indeed African) timezones. While Americans, Asians and Antipodeans had it taking much of their nights at one end or t’other, here it opened at 09:30, and ended with BoF sessions at 21:00, much like a regular ApacheCon. The benefits of being in the middle of the world’s inhabited timezones!
After one or two initial glitches – a very short learning curve – the technology worked well. Presentations were clear, with the presentation window split to show the presenter, his/her screen, and a text chat window in separate panes: pretty-much ideal. “Corridor” action was, I thought, less successful, but then I’ve long found text chat easier to work with than face-to-face, which is why I don’t even have a webcam and audio system on my desktop ‘puter. Text chat there was a-plenty on every possible topic, but then we don’t need an organised event to benefit from that.
In terms of contents, the programme was easily as good as any I can remember. I enjoyed and was inspired by a number of talks, including some not merely on subjects but on projects with which I had no previous familiarity. In fact I think it worked rather better than sitting in a conference room, and I found it easy to stay alert and focussed, even in that after-lunch siesta slot when it can be hard to stay awake.
A major theme this year is the rapidly-growing Chinese community at Apache. In recent years it’s moved on from a handful of individual developers contributing to Apache projects, to quite a number of major projects originating in China and with Chinese core teams coming to Apache. Sheng Wu – a name I’ve hitherto known as a leading light of the Incubator and also lead on one of those projects – gave a keynote on the subject.
I don’t recollect when we had the main discussion of the language issues of Chinese communities coming to Apache, but some of these are now fully bi-lingual, with English being ultimately the official language but Mandarin also widely used. Mandarin was also used in a few of the morning’s talks – morning being of course the eastern-timezone-friendly time of day (and there was also a Hindi track). One Chinese speaker whose English-language talk I started to listen to proved hard to follow, and I found sneaking out unobtrusively a minor benefit of the online format!
The success of Chinese projects coming to Apache was demonstrated by two of today’s most interesting talks – by Western speakers (one American, one German) who don’t speak Chinese, but have become members of the respective core developer communities by virtue of participating. One was about the project itself, but Julian Feinauer’s talk was specifically focussed on the community: how a bi-lingual community works in practice (a question on which I’ve mused before, for example with reference to translations of my book, and regarding nginx). Answer: it’s working very well, with both languages, with machine translation to help “get the gist”, and with bilingual members of the community. And there are gotchas, when an insufficiently-comprehensive translation leads to confusion.
Summarising the Chinese theme, I think perhaps Sheng Wu’s keynote marks the point I dreamed of when I wrote the preface to the Chinese translation of my book.
Congratulations to Rich Bowen and his team on adapting to the circumstances and bringing us a fantastic event! More to come, about which I may or may not blog.
Traffic Server Summit (by ‘net)
I spent two days last week at the trafficserver summit.
Or rather, two evenings. The summit was held in Silicon Valley (hosted by linkedin), while I remained at home in Blighty with a conferencing link, making me one of several remote attendees. With an 8 hour time difference, each day started at 5pm and went on into the wee hours. On the first day (Tuesday) this followed a day of regular work. On the Wednesday I took a more sensible approach and the only work I did before the summit was a bit of gardening. Despite that I felt more tired on the Wednesday.
The conferencing link was a decent enough instance of its kind, with regular video alongside screen sharing and text (though IRC does a better job with text). The video was pointed at the speakers as they presented, and the screen sharing was used to share their presentations. That was good enough to follow the presentations pretty well: indeed, sometimes better than being there, as I could read all the intricate slides and screens that would’ve been just a blur if I’d been present in the room.
Unfortunately most of the presentations involved discussion around the room, and that was much harder, sometimes impossible, to follow. Also, speaking was not a good experience: I heard my voice some time after I’d spoken, and it sounded ghastly and indistinct, so I muted my microphone. That was using just the builtin mike in the macbook. I tried later with a proper headset when I had something to contribute, but alas it seems by then I (and I think all remote attendees, after the initial difficulties) was muted by the system. So I had something approximating to read-only access. And of course missed out on the social aspects of the event away from the presentations.
In terms of the mechanics of running an event like this, I think in retrospect we could make some modest improvements. We had good two-way communication over IRC, and that might be better-harnessed. Maybe rather than ad-hoc intervention, someone present (a session chair?) could act as designated proxy for remote attendees, and keep an eye on IRC for anyone looking to contribute to discussion. Having such a person would probably have prompted me into action on a few occasions when I had a comment, question or suggestion. Or perhaps better, IRC could be projected onto a second screen in the room, alongside the presenter’s materials.
The speakers and contents were well worth the limitations and antisocial hours of attending. I found a high proportion of the material interesting, informative, and well-presented. Alan, who probably knows more than anyone about Trafficserver internals, spoke at length on a range of topics. The duo of Brian and Bryan (no, not a comedy act) talked about debugging and led discussion on test frameworks.
Other speakers addressed applications and APIs, and deployments, ops and tools. A session I found unexpectedly interesting was Susan on the subject of how, in integrating sophisticated SSL capabilities in a module, she’s been working with Alan to extend the API to meet her needs. It’s an approach from which I might just benefit, and I also need to take a look at whether Ironbee adequately captures all potentially-useful information available from SSL.
At the end I also made (via IRC) one suggestion for a session for the next summit: API review. There’s a lot that’s implemented in Trafficserver core and utils that could usefully be made available to plugins via the API, even just by installing existing header files to a public includes directory. Obviously that requires some control over what is intended to be public, and a stability deal over exported APIs. I have some thoughts over how to deal with those, but I think that’s a subject for the wiki rather than a blog post. One little plea for now: let’s not get hung up on what’s in C vs C++. Accept that exported headers might be either, and let application developers deal with it. If anyone then feels compelled to write a ‘clean’ wrapper, welcome their contribution!
niq's soapbox 