DEV Community: Jerod Santo

What do you consider your greatest developer strength? Weakness?

Jerod Santo — Fri, 28 Jun 2019 16:48:29 +0000

On JS Party #78 we talked all about developer strengths and weaknesses (and even shared our own). That got me thinking... we all have strengths and weaknesses. Sometimes we have them in common, sometimes they're totally unique because of our background/experience. Let's share 'em! I'll go first:

Strength 💪

One of my greatest strengths as a developer (which I learned is shared by some of my JS Party co-panelists) is STUBBORNNESS! I will continue to bang my head against a wall until there's a hole large enough for me to slip a solution through.

Weakness 😭

One of my greatest weaknesses as a developer is I am not good at thinking in libraries, so I often fail to generalize my code for reuse. Or, if I do generalize it for reuse, I don't package it up and release it for others.

Your turn 🤝

What do you consider your greatest developer strength? Weakness?

There's only one way to validate an email address

Jerod Santo — Tue, 18 Jun 2019 15:16:46 +0000

The only thing that you can reliably do to validate an email address is to send it an email. YOU SEND IT AN EMAIL! That's the only way you can do it. I know what you're thinking,

"I have the best regular expression for this!"

// Detect dark theme var iframe = document.getElementById('tweet-845821937452486657-237'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=845821937452486657&theme=dark" }

No, you do not. You think you do, but you don't. Your regular expression is invalid; it's not good enough. You know the old adage:

"A developer, when faced with a problem, thought 'I know. I'll use regular expressions.' Now he has two problems."

That's what you have - you have two problems. I've known this for years, and yet I was still convinced recently to add a regular expression-based email validation server-side;

(First of all, never trust a client, right? You can do it all you want there, but it can bypass all your checks. It's gotta be server-side.)

// Detect dark theme var iframe = document.getElementById('tweet-834831478919987205-757'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=834831478919987205&theme=dark" }

I put a regular expression-based email validation and I thought "This one's pretty good."

In fact -- man, I don't know what came over me; I was actually even talked into copy-pasting one off of a gist! 😭

It looked pretty good, and it covered most of the bases, and sure enough, last week I got an email from a prospective user saying

"Hey, I'm trying to sign up for Changelog Weekly, but it says my email address isn't valid, and it obviously is valid, because I'm emailing you with it right now..."

And I thought, "I'm an idiot. Why did I put a regular expression-based email validation on my system?"

So don't do that. I know you can find one on Stack Overflow... I'll tell you right now, it's not good enough. Email addresses are SO complicated. There's so many valid things...

If you're going to do it -- and I'll admit that I kept it in there, but I just check that there's some stuff, and then an @, and then some stuff.

~r/^\S+@\S+\.\S+$/

That's pretty much what you're gonna be able to do... And that's just to basically make sure that you don't get some junk into your database... 🙅‍♀️

But still, all you've gotta do is send them an email, and if they click on it, well that's a valid email address. If they don't click on it, then who cares...? That's a hard-learned lesson!

If you want to validate an email address, send it an email. Problem solved.

Until bots start clicking on emails. Then we're gonna have a whole new issue... But so far I don't think there are bots that will

create a fake email address
sign up for your thing, and then
access that email address and click on the link

When we get there, then we'll have to come up with something else. But until then, just send it an email.

What you've just read is an excerpt from JS Party #39. I fixed up the formatting a bit for readability, but these (almost) exact words were spoken by me during the Pro Tips segment of that episode. In addition to tips like this one, we also discuss news & trends, interview awesome guests, teach each other things like we're 5, and have lots of fun doing it. You should totally come party with us live on Thursdays or subscribe to the produced version! Take a listen and let us know what you think. 💚

39: Experimenting with some new ideas 🔬

JS Party

Your browser does not support the audio element.

1x initializing... ×

Is JavaScript the "CO2" of the web?

Jerod Santo — Mon, 17 Jun 2019 14:21:04 +0000

"The vanilla JavaScript guy" joined JS Party last week and a fun metaphor was discussed:

Is web development stuck in the Hummer days? If so, is vanilla JS a bicycle? A Lime scooter? How far can this metaphor stretch?

You will 💯 want to listen to this and let us know your thoughts on the matter. The CO2 metaphor starts around the 20-minute mark (jump there) 💚💚💚

JavaScript is the CO2 of the web

JS Party

Your browser does not support the audio element.

1x initializing... ×

8 great reads for aspiring JavaScript devs 📚

Jerod Santo — Thu, 09 May 2019 13:57:43 +0000

Divya, Emma, and I had a gab session on BOOKS during the final segment of JS Party #73.

The list of recommended reads from that convo was too good to only exist buried in the episode's show notes, so here they are: some must-read books for aspiring JS devs!

1. Refactoring UI

The pitch:

Learn how to design beautiful user interfaces by yourself using specific tactics explained from a developer's point-of-view.

Emma recommends. Divya adds her +1, saying:

It's excellent. For people who don't consider themselves designer, but want to learn more. It's sooo good.

2. The Pragmatic Programmer

An absolute classic by Andy Hunt and Dave Thomas. The pitch:

Straight from the programming trenches, The Pragmatic Programmer: From Journeyman to Master cuts through the increasing specialization and technicalities of modern software development to examine the core process—what do you do, as an individual and as a team, if you want to create software that’s easy to work with and good for your users.

What Jerod says about it:

A spectacular book that every developer would do well to read.

3. The Mythical Man-Month

The pitch:

A book on software engineering and project management by Fred Brooks first published in 1975... Its central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping.

Jerod says:

It can be summarized in a single sentence. "9 pregnant women can't have a baby in 1 month." Take that sentence and apply it to software development.

4. You Don't Know JS

The pitch:

A book series exploring the parts of JavaScript that we all think we understand but don't REALLY know.

Emma says:

Kyle Simpson is one of the most prolific teachers I've found.. all of his books are free, which is incredible... it wasn't until he explained closures that I understood it.

5. Professional JavaScript for Web Developers

The pitch:

This book provides a developer-level introduction along with more advanced and useful features of JavaScript.

Emma says:

This is quite a BIG book. I pieced through it, and enjoyed it.

6. Learn JavaScript & jQuery

The pitch:

We understand that all kinds of people build websites these days (and that they don’t all have a degree in computer science). So, if you want to use JavaScript to make your web pages more interactive, interesting, and usable, we can help. Even if you have never done any programming.

Emma says:

This one is more for beginners... I only read the JavaScript portion. They use these beautiful graphics to explain concepts like scope and event delegation. It's extremely beginner friendly.

7. Code Complete

The pitch:

A software development book, written by Steve McConnell and published in 1993 encouraging developers to continue past code-and-fix programming and the big design up front and waterfall models. It is also a compendium of software construction techniques, which include techniques from naming variables to deciding when to write a subroutine.

Divya says:

One of the books that I always come back to when I think about the overarching philosophy of decisions I make. It's a long read, but is available online for free.

8. Learning JavaScript Design Patterns

The pitch:

Design patterns are reusable solutions to commonly occurring problems in software design. They are both exciting and a fascinating topic to explore in any programming language... In this book we will explore applying both classical and modern design patterns to the JavaScript programming language.

Emma says:

Highly recommend if you want to learn more about designing code in effective ways.

Divya adds:

That was my goto Bible, so to speak, when I wasn't using frameworks. I was just doing things vanilla style... that book helped me understand what a singleton is.

There's your rundown. ✊

Interested in the people behind these recommendations? Want to know how to talk about books that you haven't read? Curious how Jerod made it through half a dozen books in two-weeks time? Listen to the entire episode right here 👇

Fresh voices!

JS Party

Your browser does not support the audio element.

1x initializing... ×

Of course, if you dig this show you'll probably like all of our podcasts. Check out our Master feed where you can get every episode we publish (including exclusive master-only content). 💚

Stop limiting your open source library’s potential

Jerod Santo — Thu, 04 Apr 2019 13:45:24 +0000

This morning I stumbled across Griffith – a React-based web video player. That's cool and all, but you know what'd be even cooler? A web video player that we all can use.

There's a recurring theme in open source where TECHNOLOGY_X gets popular and then a bunch of libraries and tools get created specifically for (or ported to) TECHNOLOGY_X, but they can't be used with TECHNOLOGY_Y or TECHNOLOGY_Z.

This is especially common in front-end-javascript-land where there are so many frameworks that come and go over the years. Examples!

You want a search box but you find an Angular search box
You want a geocoding library but you find a jQuery geocoding library
You want a datepicker but you find an Ember datepicker

It doesn't have to be that way!

With a little forethought you can build a generically-useful library and then provide small wrapper libraries that adapt the generic library to specific framework use cases. This is called the adapter pattern and I swear it's not as bad as we make it out to be in this tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1110224694093987842-463'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1110224694093987842&theme=dark" }

Nicolás Bevacqua has been applying this principle to much success for years. He's a great example to follow if you need some help figuring out the details!

Case in point: he created Dragula – a generic drag-n-drop library you can use directly with vanilla JS. He then followed it up with adapters (which he calls bridges – same difference):

The official Angular bridge
The official Angular 2 bridge
The official React bridge

What's even cooler about this approach is that Nicolás has paved the way for others to come along and build an Ember adapter for Dragula, an Aurelia adapter for Dragula, etc.

And when TECHNOLOGY_X++ comes along next year? You can guess what it'd take to build it an adapter for Dragula....

When you hard-attach your library to a specific technology or framework, you limit its potential impact. By thinking ahead and putting in a little more effort, your library could benefit orders of magnitudes more people. Maybe even future-you, once you've moved on to TECHNOLOGY_X++...

Note: read the original article on changelog.com

Chris Coyier on The Great Divide

Jerod Santo — Thu, 28 Mar 2019 15:13:20 +0000

Two front-end developers are sitting at a bar. They have nothing to talk about.

Chris Coyier joins Suz Hinton and myself to continue the discussion on The Great Divide in front-end-land. We also use this as an opportunity to gush on how much CSS-Tricks has done for the community, get Chris' perspective on the history of the website, and finish up by sharing some amazing Pens on CodePen.io.

The great divide reprise

JS Party

Your browser does not support the audio element.

1x initializing... ×

Get the show notes and transcript on changelog.com ✊

There are plenty of good reasons to do open source for free

Jerod Santo — Thu, 28 Mar 2019 14:52:16 +0000

We recently covered a post on Tidelift's blog¹, where Havoc Pennington makes the argument that open source has a working-for-free problem.

The narrative around open source is that it's completely OK—even an expectation—that we're all doing this for fun and exposure; and that giant companies should get huge publicity credit for throwing peanuts-to-them donations at a small subset of open source projects.

He also likens the plight of the open sourcerer to that of the reluctant designer who submits hermself to spec work in the hopes of future compensation. I don't think that analogy is usefully transferrable.

Why the spec work analogy falls flat

When a designer creates spec work, they are speculating about the future value of that work. Hence the name. Most often this work is prompted by a 3rd-party who hangs that future value from a stick and dangles it a few inches from the designer's nose. This is problematic, because:

The designers work for free and with an often falsely advertised, overinflated promise for future employment; or are given other insufficient forms of compensation.

Open source software, on the other hand, is rarely (ever?) conceived under these circumstances. We've talked with many open source developers over the years and I've never heard a Genesis story that sounded like spec work. The reasons we hear why people create open source usually sound like:

"I was scratching my own itch"

"None of the existing solutions fit my needs"

"I thought others might find it useful"

"It's my little gift to the world"

Designers begrudgingly submit spec work. Developers joyfully open source their work.

We still have a problem

I think it's worth drawing the distinction above, but do not misread my overall sentiment: I do believe there's a money problem in open source. If you listen to our shows you know I believe that. It's just that in open source that problem doesn't manifest until much later in the process.

It waits until the software has matured, the value has been proven, the community has been built. Then, it sucks the joy out of the developer(s) who gave a gift to the world and turns it in to the worst kind of job. An unpaid job!

Focusing on the 'why'

So, going back to the beginning. If you open source your work to (speculatively) make lots of money... you're doing it wrong. There are much easier means to that end. But there are plenty of good reasons to do open source for free. Here's three of them:

1. Free is accessible

If you want your software to improve the lives of as many people in the world as possible, do it for free². The fact is that many people can't afford to buy your software and many of those who can afford to buy it won't anyways. This 'why' was described wonderfully by Jérémy Lal with this comment (emphasis added):

I’ve been contributing to open-source for more than ten years. Why ? because open-source made software accessible to people without funds to try new and crazy ideas. Not for exposure, not for publicity, and certainly not for big companies. Open-source, and free licenses, are the nicest thing that ever happened to humanity. Also i did not make a single dollar out of it.

2. Free is payment

That may sound like a contradiction, but hear me out. The reason that I began producing open source software was because I had benefited from so much of it. I cut my developer teeth on Vim and the Linux command-line. I started my career writing Perl scripts and later Ruby and Rails-based web applications. The saying, "we stand on the shoulders of giants" may be cliché now, but clichés become clichés because of their wide application!

When I came to a point with my developer skills where I was confident enough to contribute back, I felt obliged to do so. It's a small way of paying it forward, or in other words: payment for all of the freeloading I'd been doing³. I don't think I'm alone in this.

3. Free is fun

Open source has grown and matured over the years, but let's not forget that much of open source software exists because the creators were just having fun.

There's nothing fun about enforcing the commercial side of a license. There's nothing fun about picking which features go in the 'open core' and which features require payment. There's nothing fun about selling support or hosting.

What is fun is creating something new, giving it a name, and just putting it out there to freely be used and enjoyed by others.

What about you?

I'd love to hear the 'why' behind your open source work. Are you hoping to get a job from your efforts? Is fame the driving factor? Are you paying it forward or just having fun? Sound off in the comments and feel free to link up your project(s) so others might join you in your work. ✊

Disclosure: TideLift sponsors changelog.com. We only partner with folks who ensure our editorial and creative freedom.↩
It must be free as in beer. It might be free as in freedom, too.↩
And continue to do! 😉↩

GitHub Actions is the next big thing

Jerod Santo — Thu, 24 Jan 2019 15:18:12 +0000

This is a must-listen episode of The Changelog with Kyle Daigle (GitHub's Director of Ecosystem Engineering). ICYMI: Actions is GitHub's new automation platform that was announced in October and is still in beta.

Build your container apps, publish packages to registries, or automate welcoming new users to your open source projects — with access to interact with the full GitHub API and any other public APIs, Actions seem to have limitless possibilities.

331: GitHub Actions is the next big thing

The Changelog

Your browser does not support the audio element.

1x initializing... ×

Get the show notes and transcript (coming soon) on changelog.com ✊

3 ways to retain your dev flow between sessions 💪

Jerod Santo — Thu, 17 Jan 2019 15:27:58 +0000

Context switching. Computers are great at it, humans suck at it.

Every time we developers lose the context of our current task we're forced to waste precious time getting it back. The harder the problem we're trying to solve, the longer it takes to reinstate its context in our mind. This is why many developers strive to reduce interruptions, set aside large blocks of time, and create an environment that helps them get into the flow and stay there.

The problem is, there are times when we absolutely must leave our development context behind and pick it back up later. Sometimes it's 30 minutes, sometimes it's overnight. I find these times very frustrating and have found a few techniques that help me quickly get my flow back upon returning.

1. Note to self

Leave yourself a little note saying what you were up to. This is probably the most obvious technique, and can be quite effective. The problem I've found with this is that I often forget to do it or am just too tired/lazy at the end of the day to do it consistently.

I need to write myself a note to remind myself to write myself notes. Guh, yeah.

2. Always be failing

Leave one or more tests in your test suite failing (you are writing tests, yes?). When you return to the project your first step is to run the test suite and you'll see the failing test(s). This one works really well, but much like leaving yourself notes it's something that you have to actively participate in. It can actually take more time and effort to employ than leaving notes.

3. Git dirty

This is my favorite and most oft used technique. Leave your Git (or the DVCS of your choice) staging area in a dirty state.

When you return, you'll see all the changes you most recently made before you left off. This, combined with a quick perusal of the commit log will quickly bring your context back. The advantage of this over the others is that it is somewhat participation-free. Simply fail to commit your last changes and they'll be there waiting for you. At least for me, this is far more likely to happen than technique #1 or #2.

4. ???

Those are a few things I've been doing to get my dev flow back quickly, but I'm sure there are others. Do you have any tricks up your sleeve? I'd love to hear 'em!

Graph databases 101

Jerod Santo — Tue, 20 Nov 2018 14:31:31 +0000

Dgraph founder Manish R Jain gave us an excellent explanation of graph databases on episode 322 of The Changelog.

(Thanks to listener Evan Genest for highlighting this fact on Twitter.)

I extracted that section from our trusty episode transcript for your reading pleasure:

I think graphs are probably the simplest things to think about, really. People think about SQL tables - you have a row and you have some columns. Think of a graph as three columns where you have a subject, a predicate, and an object. If you put together a whole bunch of these things, you get a graph. A subject is essentially – think of it as an entity; a predicate is the relationship, and the object is either another entity, or a value.

The subject could be, let’s say, me. The relationship might be “lives in” and object might be “San Francisco.” Or it could be me - the name is Manish, and that’s sort of like a property. So you just put together a whole bunch of these facts, or triples, and you get a graph.

Then other people who live in San Francisco would have similar facts, and then you could run a graph query around “Hey, tell me all the people who live in San Francisco and who eat sushi.” So you pick up all the people who live in San Francisco, you intersect with people in the world who eat sushi - which are completely different facts. You didn’t create them as “This person lives in San Francisco AND eats sushi.” This is something that we’re doing on the fly. So you pick up all the people in San Francisco, you pick up all the people in the world who eat sushi, you intersect the two lists, and now you get people in San Francisco who eat sushi. Now you can take that result and say “Intersect it with all the people who have been to Japan.” You pick up another list of people who have been to Japan, intersect it with this, and now you get people who live in San Francisco, who eat sushi, and who have been to Japan.

So the power of graphs is really in these joins that you can do, coming from just very simple facts.

Listen for yourself starting at 30:09 or start right from the top:

322: There and back again (Dgraph's tale)

The Changelog

Your browser does not support the audio element.

1x initializing... ×

Thanks, Manish! 💚💚💚

Drupal is a pretty big deal 🎙

Jerod Santo — Thu, 01 Nov 2018 13:51:13 +0000

Did you know Drupal has racked up over 40,000 contributors since it was first created in 2001?! Neither did we, until the super awesome Angie Byron joined us on The Changelog last week to tell us all about it.

We also learned just how awesome the Drupal community is (much like Dev.to!) and how they work to keep that the case. You don't want to miss this episode:

321: Drupal is a pretty big deal

The Changelog

Your browser does not support the audio element.

1x initializing... ×

Find the full show notes and transcript on changelog.com.

Make an open source maintainer's day with this one weird trick

Jerod Santo — Mon, 22 Oct 2018 13:51:20 +0000

Little bits of appreciation can make big differences in maintainers' lives. Here's one way you can show appreciation that will take less than five minutes out of your day and just might make someone else's. 🙌

The one weird trick

Think of an open source project that you use often.
Open your browser to its GitHub Issues (or alternate platform equivalent).
Open an issue, thanking the maintainer(s).

That's all there is to it! Weird, right? Let me get out ahead of some FAQs. 💡

How do I pick an open source project to thank?

Tools are easy: just think about what you've been using lately to get stuff done. Chances are it's open source! Libraries are even easier: check your package.json, Gemfile, or Cargo.toml and find a dependency that has made your life easier. Done and done!

What do I put in the Issue subject?

I suggest going with "Thanks!", but feel free to get creative with it. 😀

What do I say in the Issue body?

Tell them how long you've used the thing, how it's made your life easier, why you think it's awesome, etc. You don't have to write a book!

I also like to mention that I expect them to immediately close the issue, to spare them the awkward decision of whether or not to keep it open indefinitely.

Do I have to use Issues?

No way! Tweet at them, email them, or send them a letter by carrier pigeon. It doesn't really matter which medium you use. It only matters that go out of your way to say thanks.

Do you actually do this, Jerod?

Yes! But not as often as I should. Most recently, I realized just how much time I'd saved thanks to the excellent HTTPoison library, so I thanked the author. It made Eduardo's day, which subsequently made my day, too! Weird how that works, huh?

A bonus trick 🎁

If you want to go the extra mile, JS Party panelist Feross has a super cool npm package called thanks. It will crawl your package.json and print out a list of maintainers who accept donations. Because saying thanks can make someone's day, but giving thanks is on a whole other level. 💚