Tags: teaching

54

sparkline

Tuesday, January 10th, 2017

Mentorship, From the Notebook of Aaron Gustafson

Here’s a great opportunity for somebody looking to level up in web development—mentorship from the one and only Aaron Gustafson.

Monday, November 28th, 2016

Starting out

I had a really enjoyable time at Codebar Brighton last week, not least because Morty came along.

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

Hey designers, if you only know one thing about JavaScript, this is what I would recommend | CSS-Tricks

This is a really great short explanation by Chris. I think it shows that the really power of JavaScript in the browser isn’t so much the language itself, but the DOM—the glue that ties the JavaScript to the HTML.

It reminds me of the old jQuery philosophy: find something and do stuff to it.

Wednesday, November 2nd, 2016

welcome.js | booktwo.org

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.

Wednesday, October 12th, 2016

Thimble by Mozilla - An online code editor for learners & educators.

This is a really, really nice tool for creating HTML, CSS, and JavaScript without needing a separate text editor. And then you can publish the results to a URL.

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 4th, 2016

Chasing Tools - TimKadlec.com

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:

  1. Who benefits from the use of this tool and how?
  2. Who suffers and how?
  3. How does it fail?
  4. Does the abstraction feed the core?

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?”

Fantastic coding tonight! Great to see you all. Thanks for coming and thanks @68MiddleSt & @clearleft for having us.

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:

Prioritising topics for discussion.

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.

Thursday, July 28th, 2016

Web Design in 4 minutes

This is a wonderful way of progressively explaining the layered approach to building for the web that Charlotte was teaching in her Codebar workshop.

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 teacher

ES6 introduced a whole bunch of new features to JavaScript. One of those features is the class keyword. This introduction has been accompanied by a fair amount of concern and criticism.

Here’s the issue: classes in JavaScript aren’t quite the same as classes in other programming languages. In fact, technically, JavaScript doesn’t really have classes at all. But some say that technically isn’t important. If it looks like a duck, and quacks like a duck, shouldn’t we call it a duck even if technically it’s somewhat similar—but not quite the same—species of waterfowl?

The argument for doing this is that classes are so familiar from other programming languages, that having some way of using classes in JavaScript—even if it isn’t technically the same as in other languages—brings a lot of benefit for people moving over to JavaScript from other programming languages.

But that comes with a side-effect. Anyone learning about classes in JavaScript will basically be told “here’s how classes work …but don’t look too closely.”

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.

It doesn’t sit well with me, though. I think that understanding how something works is important (in most cases). That’s why I favour learning underlying technologies first—HTML, CSS, JavaScript—before reaching for abstractions like frameworks and libraries. If you understand the way things work first, then your choice of framework, library, or any other abstraction is an informed choice.

The most common way that people refer to the new class syntax in JavaScript is to describe it as syntactical sugar. In other words, it doesn’t fundamentally introduce anything new under the hood, but it gives you a shorter, cleaner, nicer way of dealing with objects. It’s an abstraction. But because it’s an abstraction taken from other programming languages that work differently to JavaScript, it’s a bit of fudge. It’s a little white lie. The class keyword in JavaScript will work just fine as long as you don’t try to understand it.

My personal opinion is that this isn’t healthy.

I’ve come across two fantastic orators who cemented this view in my mind. At Render Conf in Oxford earlier this year, I had the great pleasure of hearing Ashley Williams talk about the challenges of teaching JavaScript. Skip to the 15 minute mark to hear her introduce the issues thrown up classes in JavaScript.

More recently, the mighty Kyle Simpson was on an episode of the JavaScript Jabber podcast. Skip to the 17 minute mark to hear him talk about classes in JavaScript.

(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.

Thursday, July 21st, 2016

Teaching web development to design students (Phil Gyford’s website)

Phil’s write-up of teaching web development to beginners is immensely valuable in the run-up to the Codebar workshop that Charlotte is running this weekend. This bit gave both us a real “a-ha!” moment:

It only occurred to me at the end that I should have encouraged the students to try and fix each other’s bugs. If anyone had problems I’d go round and help people and often it’d be a little typo somewhere. Helping each other would acknowledge that this is entirely normal and that a second pair of eyes is often all that’s needed.

Wednesday, June 29th, 2016

MarkSheet: a free HTML and CSS tutorial - Free tutorial to learn HTML and CSS

This looks like a great resource for beginners looking to learn HTML and CSS.

Tuesday, June 14th, 2016

My talk at Dot York: Learn and Teach | Charlotte Jackson, Front-end developer

Here’s the full text of Charlotte’s fantastic short talk at the Dot York event last week. I’m so, so proud of her.

Saturday, June 11th, 2016

Apprenticeship: A better path to mastering our craft | Louder Than Ten

I’ve been thinking a lot about learning, teaching, mentoring, coaching …this article by Ivana McConnell from last year is packed with gold nuggets of wisdom concerning apprenticeships.

As lifelong learners, we may be reluctant to call ourselves “masters.” But that’s missing the point, and it discounts the fact that teaching is learning. We’re not there to guarantee mastery—we’re there to give our apprentices fundamentals, to foster their respect, and make journeymen (or women) out of them. Mastery will come; we just offer the tools.

Thursday, June 9th, 2016

“Apprenticeships,” an article by Dan Mall

I really love what Dan is doing with his apprenticeship programme—I hope we can do something like this at Clearleft.

Tuesday, May 31st, 2016

DRY: Do Repeat Yourself - QuirksBlog

Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).

I will be pondering upon this.

Friday, February 12th, 2016

16 CSS Lessons via Post-it® Notes

’Sfunny—I was just talking about how important it is to keep document ways of teaching the basics of CSS, then I come across this delightful series of explanations.

(I hope Kaylan posts this to her own site as well as Ev’s blog.)

Teaching the order of margins in CSS | Charlotte Jackson, Front-end developer

Y’know, all too often we’re caught up in the latest techniques and technologies. It’s easy to forget that there are people out there trying to learn this whole web thing from scratch. That’s why I think blog posts like this are so, so important!

Based on her experience teaching CSS at Codebar, Charlotte describes how she explains margins. Sounds simple, right? But is that because we’ve internalised this kind of thing? When was the last time we really thought about the basic building blocks of making websites?

Anyway, this is by far the best explanation of margin shorthand properties that I’ve seen.

More of this kind of thing, please!

Wednesday, January 20th, 2016

2015 Year in Review | codebar

Codebar had a very good 2015.

Of the 137 workshops run, “100 of those workshops were organised by our two busiest chapters, London and Brighton”—50 each.