Today we came downtown to participate in a Local Hack Day hosted at Awesome Inc. The event wasn’t quite as directed as I had expected, but was, instead, just a space with network, power, and snacks. That’s awesome, but not terribly useful for the beginner who isn’t quite sure what they want to work on.
I’d love to see an event like this have some kind of mentor, and basic training in things like Github, editors, and perhaps suggested projects.
As it is, it’s a BYOP (Bring Your Own Project), so we spent a lot of time trying to figure out what we were going to work on, and obtaining the tools to work on it.
The people that were here were very welcoming and supportive, but assumed that you already had something in mind to work on.
I’ve been speaking at conferences for almost 20 years now. My first conference appearance was in 1996, about Perl, CGI, and the Apache Web Server. 20 years on, I still have a moment of panic, when I get on stage, and realize that I have no idea what I’m going to say. Somehow, however, it (almost) always seems to work out ok.
While I’m not quite the caliber of folks like Kathy Sierra or Damian Conway when it comes to holding a audience’s attention, only one person went to sleep the last time I gave a talk, and it was the last slot of the last day of a three-day event, so I think I’m probably doing something right.
Here’s a few tips that I’ve gathered over the years.
1) Slides are cue cards, not a transcript of your presentation
You don’t want your audience reading the slides while you speak. Slides are cue cards for you, and, possibly, for the audience to take home and remind themselves of what you say. Find a presentation format that lets you keep your detailed notes hidden, and make your slides eye-catching, but not text-heavy. Funny pictures help, but they’re not required. You want people looking at, and listening to, you, not reading prose on the screen.
2) One slide per minute
This is very individual, of course, but I try to always have one slide per minute of the presentation. Some points will take longer than others, but having the same slide up for ages gets people bored, and they tune out. The slide change gets people’s attention, but only very briefly. Too many slide transitions, and people think they’re missing something.
3) Repeat the question. Every question.
I am very hard of hearing. I find it very hard to hear your question. I assume I’m not the only one, and so repeating the question from the podium helps everyone in the audience who didn’t hear what was asked. And if there’s a recording, it ensures that the folks watching at home can hear the question, which is almost certainly off-mic. It also ensures that I’ve understood the question correctly – if I repeat the question incorrectly, you’re going to tell me that I didn’t understand. Finally, it shows each asker that you respect their voice, and are taking their question seriously.
4) Find an ally in the audience
There’s almost always someone in the audience who knows the topic better than I do. Identify then at the beginning of the talk, mention them by name from the stage, and warn them that you’re going to defer questions to them. This shows respect for them, and also gets you off of the hook for the questions that you don’t know how to answer. Sometimes, people show up to talks to show that they know more than the speaker. Sometimes they’re there to support you. Sometimes, they’re just trying to find a place to hang out and catch up on their email. In any of these cases, letting them know that you’re going to defer a few questions to them can avoid embarrassment later.
It’s ok to not have all the answers. Know where to send people for answers.
5) Test your examples
People will look at your slides afterwards, and try the examples. If they’re wrong, the rest of your presentation is wrong, also. Make triple sure that everything works as advertised.
6) Have bonus slides
You’re going to judge the time wrong. You’ll run over, or you’ll run short. Identify the optional parts of your talk, and put them in the bonus slides section. If you run out of time, no big deal. If you run out of content, they’re there for you and save that awkward 10 minutes where you’re trying to figure out what to say.
If you know for certain that you can’t fill the time, be sure to mention this at the start of the talk, so that people can plan accordingly. But try not to do that. These people have come to your talk when they could be doing any number of other things. It’s disrespectful to waste their time.
7) Have a simple URL for your slides
Every presentation I’ve ever given, someone asks where they can get the slides. Make a short URL, and put it on the first and last slides. All of my presentations are at http://boxofclue.com/ Sites like Slideshare are awesome, but the URLs are hard to remember. Use a short URL generator to make a short, memorable URL that can be written down in 3 seconds or less. Also, put it on your blog, on Twitter, and on the conference website, because people will realize as they leave the room that they don’t remember the URL. Or your name. Or what you said.
8) Have fun
If you aren’t having fun in your presentation, neither will anyone else. And then they’ll check email, check Facebook, and go to sleep. If the presentation isn’t something that you’re passionate enough about to make it enjoyable, you probably should find something else to talk about.
Twenty-some years ago, I made a terrible, stupid mistake, and it has shaped every part of my life since.
I can know that no amount of mooning about that will change it. I can know that things are awesome now – awesome to the point that I often feel sorry for the rest of you people. I can even know that much of the awesome can only exist because of the very thing that I so deeply regret. Including, but not limited to, my beautiful kids who I love so much it hurts. And yet, still, the regret is there. The never-ending what-if and why-didn’t-I.
This weekend, cleaning out the closet, I came across a stack of letters from a dear sweet friend, way back in 1991 and 1992, showing me what a good relationship looks like, and persuading me – although that wasn’t her direct intent – that the decision I was making was stupid, and that I’d regret it. It seems pretty clear that I believed her, and even agreed. But I made the decision anyways.
And here we are.
I’m glad I kept the letters, even though each time I come across them it’s so very heartbreaking. I’m glad I’m still friends with the person that wrote the letters.
But, boy, do I want to grab 20-year-old-me by the throat and shake.
I’ll be giving a presentation at LinuxCon next week about the ‘Big Tent’ at OpenStack. It’ll go something like this …
The OpenStack Big Tent
OpenStack is big and complicated. It’s composed of many moving parts, and it can be somewhat intimidating to figure out what all the bits do, what’s required, what’s optional, and how to put all the bits together.
The Problem
In the attempt to tame this confusion, the OpenStack Technical Committee defined what’s part of the Integrated Release and what’s not, so that you, the consumer, know what’s in and what’s out. One of the unintended side effects of this was that new projects were treated as second class citizens, and had trouble getting resources, developers, and a seat at the table at the developer summit.
As OpenStack continues to grow, this became more and more of a problem.
With the Liberty cycle, the Technical Committee has taken another look at what makes a project part of OpenStack, to make things better for the projects, as well as for the consumers.
Are You OpenStack?
The question that has been asked all along about any project wanting to be part of OpenStack was, is this thing OpenStack? To answer this question, a number of criteria were applied, including interoperability with existing bits, maturity, diversity (i.e., is this thing entirely developed by one company, or does it have broader participation?), and other things. This process was called Incubation, and once a project graduated from Incubation, it could be part of the integrated release.
As the stack grew, these questions became harder to answer, and more projects were getting left out of the tent, to everyone’s detriment, and to the growing confusion of the folks trying to use the software.
So, in recent months, the Technical Committee (TC) has decided to turn the question around. Rather than asking “Is thing thing OpenStack?” the new question is “Are You OpenStack?”
This changes how we look at making the determination on a few fronts.
OpenStack is People!
As Thierry Carrez Sean Dague said in their Summit presentation, OpenStack is composed of teams of people, working towards the betterment of the overall project. To that end, we’ll now welcome everyone to the table, if they are OpenStack.
So … how’s this defined?
Something is OpenStack if it:
1) Aligns with the OpenStack Mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.
2) Follows the OpenStack Way – Open Source, Open Community, Open Development, and Open Design. (More here)
3) Strives for interoperability with other things that are OpenStack.
4) Subjects itself to the governance of the Technical Committee
Tags
But while this solves one problem, it creates another. As a user of the OpenStack software, I really still need to know what’s in and what’s out.
There is no longer going to be a single release that is defined to be OpenStack, how do I know which bits I need, and which bits I can live without?
To help sort this out, a system of community-defined tags will be applied to the various pieces of OpenStack, starting with “tc-approved-release” which will, initially, just reflect what was already the integrated release. These tags will indicate project maturity, as well as other considerations. Packagers, like the CentOS Cloud Sig, can then use those tags to determine what they want to include in distributions.
Who’s In
As a result of this change, we immediately have several new projects that are part of OpenStack, that were previously held at arm’s length:
People are still going to expect a release, and exactly what that means going forward is a little unclear. Every six months there will be a release which will include stuff tagged ‘tc-approved-release’. It will be opt-in – that is, projects can participate, or not, as they like. Or they can release on their own cadence, as was discussed about a year ago.
There are still some details to be worked out, but the overall benefit to the community seems like it’s going to be huge, as we include more great ideas, and more passionate people, inside the Big Tent.
Zaqar (formerly called Marconi) is the messaging service in OpenStack. I recently had an opportunity to interview Flavio Percoco, who is the PTL (Project Technical Lead) of that project, about what’s new in Kilo, and what’s coming in Liberty.
The recording is here, and the transcript follows below.
R: This is Rich Bowen. I am the RDO community liaison at Red Hat, and
I’m speaking with Flavio Percoco, who is the PTL of the Zaqar project.
We spoke two years ago about the project, and at that time it had a
different name. I was hoping you could tell us what has been happening
in the Kilo cycle, and what we can expect to see in Liberty.
F: Thanks, Rich, for having me here. Yes, we spoke two years ago, back
in Hong Kong, while the project was called Marconi. Many things have
happened in these last few years. We developed new APIs, we’ve added
new features to the project.
At that time, we had version 1 of the API, and we were still figuring
out what the project was supposed to be like, and what features we
wanted to support, and after that we released a version 1.1 of the
API, which was pretty much the same thing, but with a few changes, and
a few things that would make consuming Zaqar easier for the final
user.
Some other things changed. The community provided a lot of feedback to
the project team. We’ve attempted to graduate two times, and then the
Big Tent discussion happened, and we just fell into the category of
projects that would be a good part of the community – of the Big Tent
discussion. So we are now officially part of OpenStack. We’re part of
this Big Tent group.
We changed the API a little bit. The impression that the old API gave
was that it was a queueing service, whereas what we really wanted to
do was a messaging service. There is a fundamental difference between
the two. Our focus is to provide a messaging API for OpenStack that
would not just allow users to send messages from one point to another,
but it would also allow users to have notifications right away from
that API. So we’ll take advantage of the common storage that we’ll use
for both features, for different services living within the same
service. That’s a big thing, and something we probably didn’t talk
about back then.
The other thing is that in Kilo we dedicated a lot of time to work on
these versions of the API and making sure that all of the feedback
that we got from the community was taken care of and that we were
improving the API based on that feedback, and those long discussions
that we had on the mailing list.
In Liberty, we’ve dedicated time to integrating with other project, as
in, having other projects consume the API. So we’re very excited to
say that in Liberty a few patches have landed in Heat that rely on
Zaqar for having notifications, or to send messages, and communicate
with other parts of the Heat service. This is very exciting for us,
because we have some stories of production environments, but we didn’t
have stories of other projects consuming Zaqar, and this definitely
puts us in a better position to improve the service, and get more
feedback from the community.
In terms of features for the Liberty cycle, we’ve dedicated time to
improve the websocket transport which we started in Kilo, but didn’t
have enough time to complete there. This websocket transport will
allow for persistent connections to be made against the Zaqar service,
so you’ll just connect to the service once, and you’ll keep that
connection alive. This is ideal for several scenarios, and one of
those is connecting to Zaqar from a browser and having Javascript
communication directory to Zaqar, which is something we really want to
have.
Another interesting feature that we implemented in Liberty is called
pre-signed URLs, and what it does is something very similar – if folks
are familiar with Swift temp URLs –
http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html
– this is something very similar to that. It generates a URL that
can expire. You will share that URL with people or services that don’t
have an username in Zaqar, so that they can connect to the service and
still send messages. This URL is limited to a single tenant and a
single queue, and it has privileges and policies attached to it so
that we can protect all the data that is going through the service.
I believe those are the two features that excite me the most from the
Liberty cycle. But what excites me the most about this cycle is that
we have other services using Zaqar, and that will allow us to improve
our service a lot.
R: Looking forward to the future, is there anything that you would
like to see in the M cycle? What is the next big thing for Zaqar?
F: In the M cycle, I still see us working on having more projects
consuming Zaqar. There’s several use cases that we’ve talked about
that are not being taken care of in the community. For instance,
talking to guest agents. We have several services that need to have an
agent running in the instances. We can talk about Trove, we can talk
about Sahara, and Murano. We are looking forward to address that use
case, which is what we built presigned URLs for. I’m not sure we’re
going to make it in Liberty, because we’re already on the last
milestone of the cycle, but we’ll still try to make it in Liberty. If
we can’t make it in Liberty, that’s definitely one of the topics we’ll
need to dedicate time to in the M cycle.
But as a higher level view, I
would really like to see a better story for Zaqar in terms of operations
support and deployment – make it very simple for people to go there
and say they want Zaqar, this is all I need, I have my Puppet
manifest, or Anisible playbooks, or whatever people are using now – we
want to address that area that we haven’t paid much attention to.
There is already some effort in the Puppet community to create
manifests for Zaqar, which is amazing. We want to complete that work,
we want to tell operations, hey, you don’t have to struggle to make that
happen, you don’t have to struggle to run Zaqar, this is all you need.
And the second thing that I would like to see Zaqar doing in the
future is to have a better opinion of what the storage it wants to
rely on is. So far we have support for two storages that are unicode
based and there’s a proposal to support a third storage, but in
reality what we would really like to do is have a more opinionated
Zaqar instance of storage, so that we can build a better API, make it
consistent, and make sure it is dependable, and provide specific
features that are supported and that it doesn’t matter what storage
you are using, it doesn’t matter how you deploy Zaqar, you’ll always
get the same API, which is something that right now it’s not true. If
you deploy Redis, for instance, you will not have support for FIFO
queues, which are optional right now in the service. You won’t be able
to have them because that’s something that’s related to the storage
itself. You don’t get the same guarantees that you’d get with other
storage. We want to have a single story that we can tell to users,
regardless of what storage they are using. This doesn’t mean that ops
cannot use their own storage. If you deploy Zaqar and you really want
to use a different storage, that’s fine, we’re not going to remove
plugability from the service. But in terms of support, I would like
Zaqar to be more opinionated.
On Wednesday morning I learned that my long-time friend Nóirín Plunkett has just suddenly passed away.
Update: It’s been mentioned that Nóirín stated, on their Twitter profile, a preference for the personal pronouns they/their. It’s been mentioned that I should update the below post to reflect that preference. Grief is a weird thing. We remember people as we remember them, not as other people want us to remember them. I knew Nóirín in an earlier chapter of their life, and I don’t intend any disrespect by how I recount those memories. Nóirín influenced different people in different ways. To me, Nóirín was a grammar geek, a friend, an unstoppable force, and a deep enigma. I miss the Nóirín that I knew, and I’m aware that Nóirín grew into a different person in their later years. Grief is both a very public thing and a very personal thing. I mean no disrespect of either Nóirín nor of their other friends and family. I just remember Nóirín differently than you do, and that’s probably ok.
I first “met” Nóirín on the Apache httpd documentation list, where they helped in the process of making the documentation into a literate manual, with consistent grammar, reasonable organization, and a more professional face. I then met them, in person, for the first time, at the ApacheCon planning meetings in Dublin, where they arrived with Colm and whipped things into order, imposing a great deal of organization on what had been a pretty chaotic process in previous years. I also had the great privilege of spending time in their home with her family while we were there, and these are some of the happiest memories I have of our friendship.
Nóirín contributed a great deal to the Apache Software Foundation over the years in a number of places. They continued her work on the httpd docs for a while, but began to move into community-facing things, such as ApacheCon, where they served as Conference Committee chair for a few years. They were instrumental in making the ASF more clueful about diversity issues. They also served a year on the board of directors.
In recent years, Nóirín has been more involved with the larger effort to improve the plight of women in technology, and their direct involvement in Apache has faded, and we’ve missed them. We will now miss them even more.
Nóirín’s motto was Festina Lente – Hasten Slowly, and this embodies their approach to life. They considered things carefully, and rushed to get things done, because life is too short to get everything accomplished that we put our minds to. In the end, theirs was far, far too short.
It’s also a jarring reminder that you may never have another chance to resolve that disagreement, so you’d better do it now, before it’s too late.
Goodbye, friend.
If you knew Nóirín, or benefited from her work, please consider donating to St John Abulance in their name.
I’m reading Isaac Asimov for the first time in at least 25 years. The stories hold up really well but his assumptions about technology are amusing. Films are still on reels. Star charts are in thick books. He invented positronic brains that fit in robot heads, but didn’t imagine digital storage of data or email. I wonder how today’s Sci Fi will hold up in 25 years.
