Sending Email with .NET: From Zero to Hero

Last month I published my first video course on Dometrain, “Sending Email with .NET: From Zero to Hero”: I just got this review from somebody who completed the course:

“⭐⭐⭐⭐⭐ Fantastic job! When I saw the course was over 9 hours, I wondered what you would talk about for that long. Now my head is swimming and it feels like 18 hours got packed into a 9 hour course. I didn’t realize how much I didn’t know about email. Thanks for putting this together.”

I didn’t set out to make a 9-hour course about sending email with .NET - I figured the course would run to 3, maybe 4 hours. But once I’d covered all the underlying standards like SMTP and MIME, modern .NET libraries like MailKit and MimeKit, tools like Mailpit, Mailtrap, ngrok, the chaos of HTML email standards and the tools like MJML that exist to work with it, how to set up all the various DNS records, SPF, DKIM, DMARC, troubleshooting, logging, sending mail from background services… there’s a lot to talk about.

The course is “Sending Email with .NET: From Zero to Hero”, you can buy it at dometrain.com, and it’s 40% off at the moment. Check it out. I think it’s awesome.

The Problem with “Vibe Coding”

The whole “vibe coding” thing is another reminder that quite a lot of people working in tech don’t understand the difference between programs and products.

To me, programs are “works on my machine” code. The kind of things many of us crank out a few times every week. Experiments, prototypes… that script you hacked up to rename all the MP4 files in a folder? You know the one. No error checking. Hard-coded path names. Does it work on Windows? Who cares? I’m on Linux right now and I got work to do.

I have dozens of these kinds of programs I use every day. They’re tools I use to automate bits of my work. They crash all the time (“what? Oh… that person has a backslash in the title of their presentation… interesting.”) - but that doesn’t matter; I fix them, I get the results I need, I move on. The code is just a means to an end. The result is what matters.

If you’re writing software that you’re planning to ship; to distribute to other people, perhaps even sell it to paying customers? Well, now that’s a whole different ball game.

Probably the single most important lesson I’ve learned in my career, the thing that I would argue is the hallmark of “experience”, is understanding just how much work it takes to turn a working program into a viable product. It’s why developer estimates are so notoriously optimistic - and why experienced developers are so notoriously cynical. Let’s say you crank out a bit of code that’ll take responses from a web form and add them in an Excel spreadsheet. That’s not that hard… yay! we just built a Typeform competitor in one afternoon! Except, no, you didn’t. You made one thing work one time on one computer. You haven’t considered encoding, internationalization, concurrency, authentication, telemetry, billing, branding, mobile devices, deployment. You haven’t hit any of the weird limits yet - ever had a system work brilliantly for the first 65,535 requests and then fall over? You don’t have a product. At best, you have a proof-of-concept of a good idea that, if some very smart people work very hard, might become a viable product.

One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users.

But that’s not product development, it’s programming. They aren’t the same thing. Not even close.

Lunch'n'Learn with the Amsterdam Java User Group

I’m in the Netherlands. Last week was running some presentation training with a group at Info Support in Veenendaal, the weekend was catching up with friends in Amsterdam, and tomorrow I’m speaking at a student conference in Utrecht. One of the things about travelling for a living is that there’s no such thing as “out of office”, and the Todo List doesn’t stop just ‘cos you’re away for a week or two. My schedule said that today I’d be preparing examples and demos for a Zoom masterclass I’m giving on Thursday with the folks from Tech Cornwall.

So when I got an email from Geertjan Wielenga, who runs the Amsterdam Java User Group, asking if I wanted to do a lunch’n’learn session, I naturally said “no” - mainly ‘cos I’d already have left Amsterdam for Utrecht. But, as Geerjan pointed out, the two cities are ridiculously close together… so I decided, what the hell. Usually, when I do in-person events, I bring something that’s prepared and polished: talk, slides, video… you know. What some folks call a “Dylan Talk”. Today, we did the complete opposite: all I brought with me was a list of topics I’m still working on, and after sandwiches and coffee in Geertjan’s kitchen, we spent a fun hour putting together demos, learning about the weird and wonderful edge cases of modern web standards (did you know border-radius can have EIGHT different values? 🤯)

Here’s a few links to the stuff we looked at:

• Organic blobs in CSS with border-radius at bram.us

• The HTML <dialog> element at MDN

• The story of #rebeccapurple

and the code from the session is all up on GitHub:

• https://github.com/dylanbeattie/modern-web-dev

Fun session. And a nice reminder that not every tech event needs to be rehearsed and polished - sometimes all you need is people, coffee and curiosity.

's-Hertogenbosch

There is a place in the Netherlands called ’s-Hertogenbosch. Yes, that’s not a typo. Its official legal place name begins with an apostrophe. The locals all call it Den Bosch (and never, ever mention that you won’t find Den Bosch on a map ‘cos why would anybody possibly need to know that?)

And, seeing it on a railway departure board earlier this morning, it occurs to me that if there’s anywhere in the world that figured out a lot of database stuff right from day 1, it’s probably the good people of ‘s-Hertogenbosch.

(obviously and shamelessly stolen from https://xkcd.com/327/ so if you like it go and buy one of Randall’s books or something. The anniversary edition of What If? is particularly good.)

An Interactive CSS Flexbox Playground

CSS flexbox is fantastic… but it’s also incredibly complicated. A flex container has half-a-dozen different CSS rules which control how content will flex and flow within the container, and figuring out the exact combination that you’ll need to implement a particular design can be a lengthy and error-prone process.

So I built a thing to make it a little easier to see what’s going on. It’s an interactive CSS flexbox playground. Based on - and with visuals inspired by - Chris Coyler’s excellent CSS Flexbox Layout Guide over at css-tricks.com, it’ll let you pick different values for all the various CSS flex properties and see how they affect your layout.

Check it out here:

https://dylanbeattie.net/tools/flexbox/

If you like this kind of thing, I’m running a couple of events next week talking about web standards - HTML, CSS, JavaScript, native browser APIs; all the cool stuff that used to require thousands of lines of JavaScript frameworks and polyfills that just works now because browsers are getting better all the time

On Monday 24th March I’m doing a ‘lunch & learn’ in Amsterdam:

https://www.meetup.com/amsterdam-java-user-group/events/306823736/?eventOrigin=your_events

then on Thursday 27th March, I’m running an online session with Tech Cornwall. 11:00-13:00 on Zoom, it’s free for members and £99 (+ VAT and booking fees) for non-members: check that out here:

https://techcornwall.co.uk/training/modern-fundamentals-of-web-application-development-masterclass/

Hopefully see you a few of you there.