119 slides from Sarah on a wide range of SVG magic (with code).
Sunday, August 13th, 2017
Monday, August 7th, 2017
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
Thursday, August 3rd, 2017
I’ve never been so excited by a single diff in a JSON file.
Service workers are coming to Safari.
Monday, July 31st, 2017
People of Sydney, you’re in luck. Charlotte is starting up a Sydney chapter of Codebar. If you know someone there who is under-represented in the tech industry, and they’re looking to learn how to code, please tell them about this.
Some want to become full-time developers, whereas others want to learn the basics of coding to enhance their current jobs. Some want to learn programming as a hobby. Whatever the reason, we’d love to see you there!
Also, if you’re a developer in Sydney, please consider becoming a tutor at Codebar.
I promise that tutoring is not scary! We ask that you let us know which areas you feel comfortable tutoring when you sign up, so you choose what you teach. It’s absolutely okay to not know answers during sessions, but knowing how to look for them is helpful.
Oh, and if you’ve got a space in Sydney that can accommodate a class, please, please consider become a Codebar sponsor.
Monday, July 24th, 2017
Putting on a conference
It’s been a few weeks now since Patterns Day and I’m still buzzing from it. I might be biased, but I think it was a great success all ‘round—for attendees, for speakers, and for us at Clearleft organising the event.
I first had the idea for Patterns Day quite a while back. To turn the idea into reality meant running some numbers. Patterns Day wouldn’t have been possible without Alis. She did all the logistical work—the hard stuff—which freed me up to concentrate on the line-up. I started to think about who I could invite to speak, and at the same time, started looking for a venue.
I knew from the start that I wanted it to be one-day single-track conference in Brighton, much like Responsive Day Out. I knew I wouldn’t be able to use the Corn Exchange again—there’s extensive rebuilding going on there this year. I put together a shortlist of Brighton venues and Alis investigated their capacities and costs, but to be honest, I knew that I wanted to have it in the Duke Of York’s. I love that place, and I knew from attending FFconf that it makes for an excellent conference venue.
The seating capacity of the Duke Of York’s is quite a bit less than the Corn Exchange, so I knew the ticket price would have to be higher than that of Responsive Day Out. The Duke Of York’s isn’t cheap to rent for the day either (but worth every penny).
To calculate the ticket price, I had to figure out the overall costs:
- Venue hire,
- A/V hire,
- Printing costs (for name badges, or in this case, stickers),
- Payment provider commission—we use Stripe through the excellent Ti.to,
- Speaker’s travel,
- Speaker’s accommodation,
- Speaker’s dinner the evening before the event,
- Speaker’s payment.
Some conference organisers think they can skimp on that last part. Those conference organisers are wrong. A conference is nothing without its speakers. They are literally the reason why people buy tickets.
Because the speakers make or break a conference, there’s a real temptation to play it safe and only book people who are veterans. But then you’re missing out on a chance to boost someone when they’re just starting out with public speaking. I remember taking a chance on Alla a few years back for Responsive Day Out 3—she had never given a conference talk before. She, of course, gave a superb talk. Now she’s speaking at events all over the world, and I have to admit, it gives me a warm glow inside. When it came time for Patterns Day, Alla had migrated into the “safe bet” category—I knew she’d deliver the perfect closing keynote.
I understand why conference organisers feel like they need to play it safe. From their perspective, they’re already taking on a lot of risk in putting on a conference in the first place. It’s easy to think of yourself as being in a position of vulnerability—”If I don’t sell enough tickets, I’m screwed!” But I think it’s important to realise that you’re also in a position of power, whether you like it or not. If you’re in charge of putting together the line-up of a conference, that’s a big responsibility, not just to the attendees on the day, but to the community as a whole. It’s like that quote by Eliel Saarinen:
Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.
Part of that responsibility to the wider community is representation. That’s why I fundamentally disagree with ppk when he says:
The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population.
That makes it sound like a conference’s job is to represent the status quo. By that logic, the line-up should include plenty of bad speakers—after all, the majority of web developers aren’t necessarily good speakers. But of course that’s not how conferences work. They don’t represent typical ideas—quite the opposite. What’s the point of having an event that simply reinforces the general consensus? This isn’t Harrison Bergeron. You want a line-up that’s exceptional.
I don’t think conference organisers can shirk this issue and say “It’s out of my hands; I’m just reflecting the way things are.” The whole point of having a conference in the first place is to trigger some kind of change. If you’re not happy with the current make-up of the web community (and I most definitely am not), then a conference is the perfect opportunity to try to demonstrate an alternative. We do it with the subject matter of the talks—”Our code/process/tooling doesn’t have to be this way!”—and I think we should also apply that to the wider context: “Our culture doesn’t have to be this way!”
Passing up that chance isn’t just a missed opportunity, I think it’s also an abdication of responsibility. Believe me, I know that organising a conference is a lot of work, but that’s not a reason to cop out. On the contrary, it’s all the more reason to step up to the plate and try your damnedest to make a difference. Otherwise, why even have a conference?
Whenever the issue of diversity at conferences comes up, there is inevitably someone who says “All I care about is having the best speakers.” But if that were true, shouldn’t your conference (and every other conference) have exactly the same line-up every year?
The truth is that there are all sorts of factors that play into the choice of speakers. I think representation should be a factor, but that’s all it is—one factor of many. Is the subject matter relevant? That’s a factor. Do we already have someone on the line-up covering similar subject matter? That’s a factor. How much will it cost to get this speaker? That’s a factor. Is the speaker travelling from very far away? That’s a factor.
In the case of Patterns Day, I had to factor in the range of topics. I wanted a mixture of big-picture talks as well as hands-on nitty-gritty case studies. I also didn’t want it to be too developer-focused or too design-focused. I was aiming for a good mix of both.
In the end, I must admit that I am guilty of doing exactly what I’ve been railing against. I played it safe. I put together a line-up of speakers that I wanted to see, and that I knew with absolute certainty would deliver great presentations. There were plenty of potential issues for me to get stressed about in the run-up to the event, but the quality of the talks wasn’t one of them. On the one hand, I wish I had taken more chances with the line-up, but honestly, if I could do it over again, I wouldn’t change a thing.
Because I was trying to keep the ticket price as low as possible—and the venue hire was already a significant cost—I set myself the constraint of only having speakers from within the UK (Jina was the exception—she was going to come anyway as an attendee, so of course I asked her to speak). Knowing that the speaker’s travel costs would be low, I could plug the numbers into an algebraic formula for figuring out the ticket price:
costs ÷ seats = price
Add up all the costs and divide that total by the number of available seats to get the minimum ticket price.
In practice, you probably don’t want to have to sell absolutely every single ticket just to break even, so you set the price for a sales figure lower than 100%—maybe 80%, or 50% if you’re out to make a tidy profit (although if you’re out to make a tidy profit, I don’t think conferences are the right business to be in—ask any conference organiser).
Some conferences factor in money for sponsorship to make the event happen. I prefer to have sponsors literally sponsoring additions to the conference. In the case of Patterns Day, the coffee and pastries were sponsored by Deliveroo, and the videos were sponsored by Amazon. But sponsorship didn’t affect the pricing formula.
The Duke Of York’s has around 280 seats. I factored in about 30 seats for speakers, Clearlefties, and other staff. That left 250 seats available for attendees. But that’s not the number I plugged into the pricing formula. Instead, I chose to put 210 tickets on sale and figured out the ticket price accordingly.
What happened to the remaining 40 seats? The majority of them went to Codebar students and organisers. So if you bought a ticket for Patterns Day, you directly subsidised the opportunity for people under-represented in technology to attend. Thank you.
Speaking personally, I found that having the Codebar crew in attendance really made my day. They’re my heroes, and it meant the world to me that they were able to be there.
Friday, July 21st, 2017
Donate money to support Codebar:
By donating to codebar you are helping to promote diversity in the tech industry so that more women, LGBTQA and other underrepresented folks will be able to get started with programming and raise their skills to the next level.
Tuesday, July 18th, 2017
In July we started receiving audio signals from outside the solar system, and we’ve been studying them since.
Tweets contain sound samples on Soundcloud, data visualisations, and notes about life at the observatory …all generated by code.
ARP is a fictional radio telescope observatory, it’s a Twitter & SoundCloud bot which procedurally generates audio, data-visualisations, and the tweets (and occasionally long-exposure photography) of an astronomer/research scientist who works at ARP, who is obsessive over the audio messages, and who runs the observatory’s Twitter account.
Tuesday, July 11th, 2017
We don’t want the field to de-democratize and become the province solely of those who can slog through a computer science degree.
So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.
Sunday, July 9th, 2017
I love seeing people go from Codebar to full-time dev work. It’s no surprise in Zara’s case—she’s an excellent front-end developer.
Wednesday, July 5th, 2017
A series of posts on the decisions and trade-offs involved in being a tech lead:
I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.
Sunday, July 2nd, 2017
This is a really great screencast on getting started with React. I think it works well for a few reasons:
- Sarah and Chris aren’t necessarily experts yet in React—that’s good; it means they know from experience what “gotchas” people will encounter.
- They use a practical use-case (a comment form) that’s suited to the technology.
- By doing it all in CodePen, they avoid the disheartening slog of installation and build tools—compare it to this introduction to React.
- They make mistakes. There’s so much to be learned from people sharing “Oh, I thought it would work like that, but it actually works like this.”
There’s a little bit of “here’s one I prepared earlier” but, on the whole, it’s a great step-by-step approach, and one I’ll be returning to if and when I dip my toes into React.
Sunday, June 25th, 2017
A great collection of learned lessons from implementing service workers.
I really, really like it when people share their own personal experiences and “gotchas!” like this.
Thursday, June 22nd, 2017
Oh No! Our Stylesheet Only Grows and Grows and Grows! (The Append-Only Stylesheet Problem) | CSS-Tricks
I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:
The developers are afraid of the CSS.
Breaking down programming tasks into smaller chunks …and naming things.
I’ll take a piece of paper and write the function names I’m going to implement. Or I’ll do it directly in my code editor, with real functions or comments.
It allows you to focus on one problem at a time. When you’re writing those function names, you are thinking about what the code should be doing. When you’re implementing the functions, you are thinking about how the code should do it.
Thursday, June 8th, 2017