Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
Sunday, January 15th, 2017
Tuesday, January 10th, 2017
Here’s a great opportunity for somebody looking to level up in web development—mentorship from the one and only Aaron Gustafson.
Saturday, December 24th, 2016
Ignore the clickbaity title—you don’t need to do anything this holiday; that’s why it’s a holiday. But there are some great talks here.
The list is marred only by the presence of my talk Resilience, the inclusion of which spoils an otherwise …ah, who am I kidding? I’m really proud of that talk and I’m very happy to see it on this list.
Monday, November 28th, 2016
I particularly enjoy teaching people who have zero previous experience of making a web page. There’s something about explaining HTML and CSS from first principles that appeals to me. I especially love it when people ask lots of questions. “What does this element do?”, “Why do some elements have closing tags and others don’t?”, “Why is it
textarea and not
input type="textarea"?” The answer usually involves me going down a rabbit-hole of web archeology, so I’m in my happy place.
But there’s only so much time at Codebar each week, so it’s nice to be able to point people to other resources that they can peruse at their leisure. It turns out that’s it’s actually kind of tricky to find resources at that level. There are lots of great articles and tutorials out there for professional web developers—Smashing Magazine, A List Apart, CSS Tricks, etc.—but no so much for complete beginners.
Here are some of the resources I’ve found:
- MarkSheet by Jeremy Thomas is a free HTML and CSS tutorial. It starts with an explanation of the internet, then the World Wide Web, and then web browsers, before diving into HTML syntax. Jeremy is the same guy who recently made CSS Reference.
- Learn to Code HTML & CSS by Shay Howe is another free online book. You can buy a paper copy too. It’s filled with good, clear explanations.
- Zero to Hero Coding by Vera Deák is an ongoing series. She’s starting out on her career as a front-end developer, so her perspective is particularly valuable.
If I find any more handy resources, I’ll link to them and tag them with “learning”.
Friday, November 25th, 2016
It reminds me of the old jQuery philosophy: find something and do stuff to it.
Wednesday, November 2nd, 2016
See, view source is a human right. Since the beginning of the web, thousands, probably millions, of users have bootstrapped their way to technical understanding through exploring the way the existing web is put together. I did. You might have done. And you, we, should be able to. And more than that, we should be encouraged to. For fun, for experience, for education, for revolution.
James is right. And he’s made a script to encourage further exploration.
welcome.js adds a friendly message to the console when it’s first opened, as well as links for users to find out more about the console, and programming in general.
Tuesday, November 1st, 2016
The New Digital School - An Alternative to Design Education by Tiago and Cláudia Pedras — Kickstarter
You can back Tiago’s excellent New Digital School. It’s a fantastic project with the web at its heart, and I really hope it gets funded.
Saturday, October 29th, 2016
Lara’s new book really is excellent. I was lucky enough to get an early preview and here’s what I said:
Giving a talk in public can be a frightening prospect but with Lara Hogan at your side, there’s no limit to what you can accomplish. This book is your shield and sword. Speak, friend, and conquer!
Wednesday, October 12th, 2016
It’s a bit like CodePen but it shows the whole HTML document, which makes it particularly useful for teaching front-end development to beginners (ideal for Codebar!).
CodePen for snippets; Thimble for pages.
Tuesday, October 11th, 2016
Sunday, October 9th, 2016
I agree with Chris’s conclusion here, but for a different reason. Here’s a shocking thought: what if the cascade is a feature not a bug?
(no really; imagine if programmers stopped trying to bend CSS to their immutable will, and instead embraced its declarative power)
We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.
Tuesday, October 4th, 2016
I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:
- Who benefits from the use of this tool and how?
- Who suffers and how?
- How does it fail?
- Does the abstraction feed the core?
Friday, September 23rd, 2016
I can very much relate to Jonathan’s learning process (except for the bit about reading Hacker News—spit):
I think I read about 20-30 times more than I write, but the writing part is still crucial for helping me get stuff straight in my own head.
Monday, September 12th, 2016
Some typically smart thinking from Mike—what if success were measured in learning rather than shipping?
Organizations that learn the quickest seem the most likely to succeed over the long haul.
This really resonates with me, and it aligns so closely with our values at Clearleft that I think this is something we should be pursuing. Fortunately Mike’s post comes with plenty of examples and ideas.
Monday, August 8th, 2016
Exploring web technologies
Last week, I had two really enjoyable experiences discussing completely opposite ends of the web technology stack.
Tuesday is Codebar day here in Brighton. Clearleft hosted it at 68 Middle Street last week. I really, really enjoy coaching at Codebar. I particularly like teaching the absolute basics of HTML and CSS. There’s something so rewarding about seeing the “a-ha!” moments when concepts click with people. I also love answering the inevitable questions that arise, like “why is it like that?”, or “how do I do this?”
Thursday was devoted to the opposite end of the spectrum. I ran a workshop at Clearleft with some developers from one of our clients. The whole day was dedicated to exploring and evaluating up-and-coming web technologies. Basically, it was a chance to geek out about all the stuff I’ve been linking to or writing about. During the workshop I ended up making a lot of use of my tagging system here on adactio.com:
- My thoughts on web components,
- Links to resources on web components,
- My posts on implementing service workers,
- Lots and lots of links to handy service worker resources,
- Links relating to performance,
- A whole bunch of accessibility links, and
- Everything I’ve linked to regarding progressive web apps.
Web components and service workers ended up at the top of the list of technologies to tackle, which was fortuitous, given my recent thoughts on comparing the two:
First of all, ask the question “who benefits from this technology?” In the case of service workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.
The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”
Those two questions turned out to be a good framework for the whole workshop. The question of how to evaluate technologies is something I’ve been thinking about a lot lately. I’m pretty sure it will be what my next conference talk is going to be all about.
You can read more about the structure of the workshop over on the Clearleft site. I’m looking forward to running it again sometime. But I’m equally looking forward to getting back to the basics at the next Codebar.
Adult training represents a way into coding for millions of women who never learnt when they were younger. Meetups such as those run by organisations such as Women Who Code and Codebar can introduce women to the collaborative, problem-solving world of programming.
Thursday, July 28th, 2016
Monday, July 25th, 2016
A workshop for codebar students: Build a portfolio or blog site | Charlotte Jackson, Front-end developer
Charlotte did a fantastic job putting this workshop together on the weekend. It was inspiring!
class keyword. This introduction has been accompanied by a fair amount of concern and criticism.
Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.
The most common way that people refer to the new
My personal opinion is that this isn’t healthy.
(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)
Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.
In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.