Most people who use GraphQL haven’t read the spec, often because it sounds or looks intimidating. This post simply and cogently shares the essentials of the query language section of the spec.
You’ll learn CSS fundamentals like the box model, cascade and specificity, flexbox, grid and z-index. And, along with these fundamentals, you’ll learn about functions, color types, gradients, logical properties and inheritance to make you a well-rounded front-end developer, ready to take on any user interface.
There are a lot of screencasts, recordings of user group gatherings and conference talks available online. I try to commit myself watching at least two new talks every week, and I’ve been doing this for quite some time now. I created this list of online talks that I really enjoyed watching. I’ll also be updating this list whenever I’ve watched another awesome talk that is worthy enough. Suggestions are always appreciated through a pull request.
This is just one of four (as of now) mysteries put together by Julia Evans to help us practice our debugging skills. Can you crack the case?!
A nice primer on the many aspects of building full-text search, such as: data preparation, indexing, searching, term frequency, and computing relevance. It’s amazing what 150 lines of code can get done…
A solid primer on using
openssl to encrypt all the things, which in this day and age is a skill that shoiuld be taught in secondary school right alongside how to bake a cake and change a tire.
John Resig and Loren Sands-Ramshaw first announced the beta of their GraphQL book (discussed here) nearly three years ago. After years of writing and re-writing, it’s now ready to be released. Loren had this to say in the linked announcement post:
This project has taken much longer than we expected, and the length of the book has wound up being much longer than we expected. We’d like to give a huge shout-out to our 740 beta readers who stuck with us through four major versions of the in-progress text.
The GraphQL Guide aims to be the most comprehensive guide to GraphQL, from a beginner introduction to advanced client and server topics.
The NFT Canon is a go-to resource for artists and creators, developers, corporations and institutions, communities and other organizations seeking to understand or do more with non-fungible tokens.
It’s a curated list of readings and resources on all things NFTs (inspired by the a16z Crypto Canon), and is organized from the big picture of what NFTs are and why they matter, to how to mint, collect, and do more with them — including various applications such as art, music, gaming, social tokens, and others.
We will continue to update this as more people try out new things, share their work, or publish resources for learning about NFTs. If you have suggestions for quality pieces to add, let us know @a16z.
A good resource and primer for our upcoming NFT episode of The Changelog with Mikeal Rogers.
In which Lj Miranda proposes an exercise that data scientists can do to learn relevant software skills (with a tangible output in the end).
Create a machine learning application that receives HTTP requests, then deploy it as a containerized app.
I’m willing to wager that this is a worthy goal even if you’re coming from the software engineering side of the spectrum. Don’t worry, he’ll walk you through the steps.
Working with Docker CLI is very straightforward - you just
push containers and images, but have you ever wondered how do the internals behind this Docker interface actually work?
Behind this simple interface hides a lot of cool technologies and in this article you can learn about one of them - the union filesystem - the underlying filesystem behind all the container and image layers.
In this game, your goal is to create a sequence of functions which transforms the colored cubes into the desired pattern.
It starts off pretty easy, but there’s plenty of challenge once you get past the first few levels. A wonderful companion to our recent FP episode of JS Party with Eric Normand (a must-listen if you’re FP curious, IMHO).
Mike Bostock celebrates D3’s 10th by reflecting on what he’s learned over the years. There’s a lot to glean from Mike’s reflections. I really enjoyed this sentiment under the “Don’t go it alone” section:
To avoid entrusting your emotional wellbeing to internet randos (see #8), you must develop relationships with a small, stable group of people that you respect. In other words, find a team (or community) that can provide validation, feedback, support, and mentorship. Maybe this is obvious to everyone but me — yes, Mike, friends are good — but I feel like it’s worth repeating today when so much human interaction happens at a distance.
Martin Heinz shares some of his favorite git features: word diff, auto-correct, plugins, and commit signing.
Git is the perfect technology to maximize cheat sheet value. It has a large surface area of commands and requires some esoteric combos to get things done. (Why is there still not a
I wanted to write to you all and share that I’ve launched my first eBook called “Serverless For Everyone Else” - within the first three hours of launch, nobody bought a single copy and I thought that I’d got it all wrong.
Alex digs into the gritty details of why he wrote the book and what happened after his initial failure. And since Alex is super nerdy like you and me, the post is filled with fun moments like this one:
How did I fulfil the upgrade / discount? I did it by writing a function and deploying it to my Raspberry Pi, so that Gumroad would send a webhook, my code would query the dollar amount, and then send out an email to the customer over AWS SES.
How do you advance your Linux skills when you are already comfortable with the basics? My solution was to come up with 10 subjects to learn and create an accompanying mini-project.
I learned Linux the slow/hard way: by fumbling around in the dark for months/years. This intentional approach will probably serve you much better than mine did.
Samuel Taylor (yes, that Samuel Taylor) shared a few things that works for him when joining a team and learning the codebase.
I have switched teams more often than I have had to implement an AVL tree, and you can guess which one of those two was taught in school. I wish someone had taught me how to join a new team! While learning a new codebase can be daunting, I’ve found a few things that work for me. You should do at least three things when joining a new team. The order of these three can be whatever you like, but all three should be done as soon as reasonably possible.
I love this post format and may do one myself here soon. It’s just lists of things Chris Kiehl changed his mind on over the years, opinions he’s picked up along the way, and old opinions he hasn’t changed. This opinion made me chuckle:
90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
Penetration testing is when you (or someone you authorize) run a security assessment of a computer system by trying to break in to it.
In this repo, Carlos Polop (who is a pentester and cyber security researcher) shares his methodology for pentesting. This is just one piece of a larger collection of Carlos’ HackTricks book.
- Contributing to your team’s internal documentation
- Getting paid to write and work with an editor
- Improving your code review process
- Using templates for writing tech specs and reports
- Prioritizing learning how to write better emails and chat messages
Mikel Evins on REPL-driven programming:
Interactive development with a proper repl-driven environment is the exception. Most programming is done in other ways.
As a consequence, there are a lot of programmers out there who’ve never even heard of it, who have no idea that it exists. My intuition is that some fraction of those programmers would prefer well-supported interactive programming, and would benefit from it, if they just knew what it was.
Maybe if enough programmers are exposed to that style of programming then we’ll begin to see new tools that embrace it.
An epic 5-part series on building HTML forms right.
Forms are arguably the most important parts of any web application. Without forms, we would not have sites like Google, Facebook, Amazon, Reddit, etc. However, the more I browse the web, the more I see poor implementations of forms.
In this series, we will examine the proper steps to creating forms for the web, how to think about the code we write, and considerations to make along the way.
Austin plans on turning this series into a full-blown book this year, so expect more from him in this arena very soon.
From the foreword:
Most people today don’t know what the command line is, much less why they would want to bother with it. As computing pioneer Alan Kay said in a 2017 interview, “Because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that ‘Guitar Hero’ is the same as a real guitar.”
Off to a good start…
Inspired by traditional UNIX philosophy, driven by an interest in encouraging a more delightful and accessible CLI environment, and guided by our experiences as programmers, we decided it was time to revisit the best practices and design principles for building command-line programs.
One of my favorite moments from our recent Postgres episode of The Changelog was when Craig taught me a few
psql tricks. This tutorial is a bit like that, only way more dense and easily referenced. 👌