Tags: learning

103

sparkline

Sunday, January 15th, 2017

Browser Support for evergreen websites

Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!

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.

Saturday, December 24th, 2016

16 Web Conference Talks You Need to Watch This Holiday

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

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.

Saturday, October 29th, 2016

A Book Apart, Demystifying Public Speaking

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

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

The Amazing Women of CSS

Rachel lists some of the best CSS developers working on the web today:

Sunday, October 9th, 2016

Can we stop bad-mouthing CSS in developer talks, please? | Christian Heilmann

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?

gasp!

(no really; imagine if programmers stopped trying to bend CSS to their immutable will, and instead embraced its declarative power)

You Can’t Get Comfortable Anymore in Web Development | Rey Bango

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

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?

Friday, September 23rd, 2016

How do I learn? - Snook.ca

I can very much relate to Jonathan’s learning process (except for the bit about reading Hacker News—spit):

  1. Reading
  2. Building
  3. Writing

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

Shipping vs. Learning » Mike Industries

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

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.

Can’t code, won’t code - cracking the secret of gender imbalance in STEM

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

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.