Just some shower thoughts about AI that I had recently. What we have right now is undoubtedly useful. But I wonder if we're too naive to think that we can truly build something smarter than us.
If we should use the right tool for the job, then I think that our brains and AI are two different tools, useful for two different jobs. And we should keep them that way. Just how higher level languages and lower level languages have their pros and cons, each useful in different situations and in different ways.
Hope I can help fellow web devs dodge a bullet… When you deal with legal documents, it's better to forget about HTML semantics and especially CSS styling. If you get too smart around ordered lists and they render incorrectly for some reason, you're on the hook!
Hi there! I'm sharing with you a little tool I made for myself.
Sometimes it's easy to lose track of time and have deadlines get you caught off-guard. Especially when you have some vacations planned. You're like "pfft, there's plenty of time…" and then the invitable "oh, shit" moment comes.
The idea behind this tool is to give you a concrete, visual view of exactly how many workdays and workhours you have. It also allows you to mark your vacations, so you can know how much time you really have. On top of that, you can add your goals and the estimated time you think they'd take in order to get a rough estimation of how they fit in.
Apart from tracking quarters, you can configure it to track any period of time, in case you follow some different parttern. I hope you find it useful!
But I think something's missing from it — the simple act of consistent self-reflection on what you're doing and why. Cultivating this habit is what I call a "metasystem." What do you think about this idea? Does it make sense? How could it be better?
Makes sense! One way to to this is using the Daily Activity Schedule by psychiatrist Dr. David Burns. The schedule consists of two columns: The “Prospective” column, where you write and hour-by-hour plan for what you would like to accomplish each day, and the the “Retrospective” column, where you record what you actually did during the day. The simple act of filling the retrospective column each day pushes you to think about what you do, as you mentioned in your article.
I was suffering from the paradox of choice lately when choosing a framework for a long-term company project. Nowadays it's like thinking of holiday gifts for distant relatives… There's no clear winner, yet there are lots of people with strong opinions out there. They put stickers on their laptops and preach as if {{insert framework here}} was their life. That's when I realized — your framework is not your religion.
TL;DR: Picked React because it's the biggest and most stable cult, but you should experiment with other cults as well because it's about the ideas, not the specific frameworks.
---
Hope this can help someone out there who is also pulling the lever of the framework roulette and has to make a decision.
Have you ever used something that "just works" and it actually has done so always, without a miss? I don't think I have. And the more magical something is, the harder it is to debug. When it comes to code, I think it makes more sense to keep things clear and obvious, rather than whimsical and obscure. Make the final product magical, not the software that runs it. What do you think about that?
Nope, that doesn't work as well. I tested it before finishing up the article a few days ago. If you put `<style>` in the `<body>`, it gets removed when the email is forwarded and it still looks like shit.
That's why I said "if you could". I know it's not valid HTML. For some reason, style tags are only allowed inside the <head/>. My point was that I find it strange that HTML in general has this limit and that script tags are allowed in the <body/> as well.
Browsers are actually okay with <style> tags in the <body> and apply the rules inside. Although MDN says they must be placed in the <head> [1]. Email clients seem to be a lot more restrictive, apparently. Or lazy.
Huh, I didn't know browsers are behaving this way these days. I believe I tried this several years ago and it didn't work. Or did I just read the standard? I'm not sure. Anyway, I always assumed it wouldn't work.
When I first got introduced to email development, I remember I wanted to throw myself off a cliff. I couldn't believe how nonsensical everything was. I kept track of everything in a little text document, which I've now turned into a post.
If you happen to be starting out with emails, I hope this can get you up to speed with exactly how everything is fucked. And if you're an Outlook survivor, I hope you'll find something you can relate to…
Since you mention MJML: I wrote a little tool called mjmgr which was meant to be a prototype of a MJML email manager for a bunch of providers. So that you can keep the source code of the MJML email checked in, but deploy it as compiled templates across various email template providers.
I only really did sendgrid and mailgun, but as a POC it worked well. Just putting this out there because it's useful but I don't touch it much anymore.
This is cool! My CMS (Craft CMS) has an MJML plugin as well as some good inlining plugins, making it possible to build emails using the CMS as the base. My goal was to have a system that put email templating on equal ground to content display, and MJML was a really key part of that. Love seeing the cool ideas MJML has inspired in the ecosystem.
For the most part you can kind of have header and a footer which you reuse across all email and then just more or less text in the middle. Maybe an image every once in a while. If you can get business partners to agree to that I've found that to be an ideal middle ground.
I guess I was too broad and pessimistic. By "code does not matter" I meant that it's not worth it to micro-optimize and dig into unnecessary details. It's fine if it's not perfect and has its rough edges, as long as it works correctly and looks as intended.
And I agree that programming is the art! I love it and I haven't given up on it. I just decided that it's better to focus on new and interesting problems.
If we should use the right tool for the job, then I think that our brains and AI are two different tools, useful for two different jobs. And we should keep them that way. Just how higher level languages and lower level languages have their pros and cons, each useful in different situations and in different ways.