Tags: programming

149

sparkline

Thursday, September 21st, 2017

Web truths: CSS is not real programming | Christian Heilmann

A lot of “CSS is not real programming” arguments are a basic misunderstanding what CSS is there to achieve. If you want full control over and interface and strive for pixel perfection – don’t use it. If you want to build an interface for an inclusive and diverse web, CSS is a great tool.

Christian does a good job of describing the much-misunderstood declarative nature of CSS.

Also:

In any case, belittling people who write CSS and considering them not real developers is arrogant nonsense.

Monday, July 31st, 2017

bpesquet/thejsway: The JavaScript Way book

This looks like a good introductory book to JavaScript, DOM scripting, and Ajax.

You can read it for free here or buy a DRM-free ebook.

Hello codebar Sydney! | Charlotte Jackson, Front-end developer

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.

Tuesday, July 18th, 2017

CSS

Last month I went to CSS Day in Amsterdam, as an attendee this year, not a speaker. It was an excellent conference comprising the titular CSS day and a Browser API Special the day before.

By the end of CSS Day, my brain was full. Experiencing the depth of knowledge that’s contained in CSS now made me appreciate how powerful a language it is. I mean, the basics of CSS—selectors, properties, and values—can be grasped in a day. But you can spend a lifetime trying to master the details. Heck, you could spend a lifetime trying to master just one part of CSS, like layout, or text. And there would always be more to learn.

Unlike a programming language that requires knowledge of loops, variables, and other concepts, CSS is pretty easy to pick up. Maybe it’s because of this that it has gained the reputation of being simple. It is simple in the sense of “not complex”, but that doesn’t mean it’s easy. Mistaking “simple” for “easy” will only lead to heartache.

I think that’s what’s happened with some programmers coming to CSS for the first time. They’ve heard it’s simple, so they assume it’s easy. But then when they try to use it, it doesn’t work. It must be the fault of the language, because they know that they are smart, and this is supposed to be easy. So they blame the language. They say it’s broken. And so they try to “fix” it by making it conform to a more programmatic way of thinking.

I can’t help but think that they would be less frustrated if they would accept that CSS is not easy. Simple, yes, but not easy. Using CSS at scale has a learning curve, just like any powerful technology. The way to deal with that is not to hammer the technology into a different shape, but to get to know it, understand it, and respect it.

Thursday, June 22nd, 2017

Code clarity - Anthony Ricaud

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, May 11th, 2017

Programming Design Systems

This is a really intriguing book that combines design theory and programming—learn about contrast, colour, and shapes, with each lesson supported by code examples.

It’s still a work in progress but the whole thing is online for free. Yay for web books!

Thursday, April 20th, 2017

There are maps for these territories | Clearleft

A great piece from Danielle on the different mental models needed for different languages. When someone describes a language—like CSS—as “broken”, it may well be that there’s a mismatch in mental models.

CSS isn’t a programming language. It’s a stylesheet language. We shouldn’t expect it to behave like a programming language. It has its own unique landscape and structures, ones that people with programming language mental maps might not expect.

I believe that this mismatch of expectation is what has led to the current explosion of CSS-in-JS solutions. Confronted with a language that seems arbitrary and illogical, and having spent little or no time exposed to the landscape, developers dismiss CSS as ‘broken’ and use systems that either sweep it under the rug, or attempt to force it into alignment with the landscape of a programming language — often sacrificing some of the most powerful features of CSS.

Thursday, March 30th, 2017

Creating my first HTTP server in node.js | Charlotte Jackson, Front-end developer

Charlotte’s step-by-step account of setting up a Node server is going to be invaluable if and when I get around to dipping my toes in those waters.

Thursday, March 23rd, 2017

Modern JavaScript for Ancient Web Developers

Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:

The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.

Sunday, March 19th, 2017

Frameworks without the framework: why didn’t we think of this sooner? • Svelte

Interesting ideas around front-end frameworks:

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

The proposed alternative here is to transpile from the idiom of the framework into vanilla JavaScript as part of the build process, which should result in better performance and interoperability.

Friday, March 10th, 2017

153 ☞ A Crash Course in React

This is a nice understandable explanation of the basics of React.

There’s a real skill in explaining something so clearly that even n00bs like me can understand it.

Tuesday, February 21st, 2017

kamranahmedse/design-patterns-for-humans: Design Patterns for Humans™ - An ultra-simplified explanation

I’m crap at object-oriented programming (probably because I don’t get get enough practice), but I’ve had a quick read through this and it looks like a nice clear primer. I shall return and peruse in more depth next time I’m trying to remember how to do all this class-based stuff.

Tuesday, January 31st, 2017

100 Days Of Open Source (2017) — Joschi Kuphal · Web architect · Nuremberg / Germany

Joschi is documenting his commitment to “contribute at least one meaningful commit a day to a public Open Source project or a similar community effort.” So far it’s a really nice mix of coding and face-to-face activities.

Less Bro-gramming: Net Natives host and sponsor Codebar | Net Natives

An excellent potted history from Cassie on women in computing.

NASA’s “Keypunch girls” would work in cramped rows translating programming instructions onto paper pads, whilst the machine operators would sit in comfort, feeding the code decks through card readers and enjoying the esteem of the end result (I imagine it a bit like Mad Men, but with more sexism and astronauts).

Wednesday, January 11th, 2017

ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript

This looks a sensible approach to writing clean JavaScript.

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.

Turing Complete User

A superb 2012 essay by Olia Lialin. J.C.R. Licklider, Vannevar Bush, Ted Nelson, Douglas Engelbart, Don Norman, Lawrence Lessig, Jonathan Zittrain, Douglas Rushkoff and Cory Doctorow all make an appearance.

There’s a lot to think about here. I’m particular struck by the idea that calling people “users” isn’t necessarily the dehumanising Lakoffian language we think it is; users have power and control. If we stop treating people like users, we may end up infantilising and disempowering them.

But when you read it in a broader context, the denial of the word “user” in favor of “people” becomes dangerous. Being a User is the last reminder that there is, whether visible or not, a computer, a programmed system you use.

Monday, November 21st, 2016

You Are Not Paid to Write Code – Brave New Geek

Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can

A cautionary tale of the risks involved with embracing new frameworks.

But when you introduce a new system, you introduce new variables, new failure points, and new problems.

almost anything is easier to get into than out of.

Sunday, October 23rd, 2016

kdeldycke/awesome-falsehood: Curated list of falsehoods programmers believe in.

A collection of assumptions programmers often make.

“Dates and Times” is tied with “Human Identity” for the most links.

On Style Maintenance | CSS-Tricks

This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!

The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.

There’s a lot of really good stuff in here to mull over.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.