Deeply nested tables that are purely for layout. Horrible inline styles. He must be building emails…
The problem remains legacy email clients, and the bizarre long tail of support that results in. While desktop browsers have moved on and it has become relatively acceptable to focus support on “evergreen” browser, this move is happening much, much slower for email clients. The result is sprawling legacy code like the screenshot below.
Honestly. We don’t need to support Outlook 2013 do we? I can only imagine (with zero evidence, natch) that anyone still using broken HTML rendering mail clients like Outlook 20XX are doing so because they are in a corporate environment where they are not allowed to update or change their mail client.
But here’s the thing. Most of the clients I’ve worked with are commercial… public facing. How many folks are really using their corporate email client to read personal emails? I certainly wouldn’t be picking up emails from my personal accounts in a locked down environment. I imagine in many environments this may even be against company policy in the first place.
I do most of my email reading on my iOS devices, and it makes me cringe when I look at the size of some of the emails I receive: 90% (possibly another made-up figure) layout crap to support other email clients—clients that almost nobody uses outside of locked corporate desktops.
Modern handhelds have very good HTML email rendering. gMail even supports responsive emails now.
My host (Digital Ocean) provides weekly full-server backups, and I can snapshot on the fly before I make any dramatic configuration changes. But this isn’t really fine-grained enough for a production environment.
Finally got around to doing something about that. All of my code is in GitHub, so I’m only really worried about content – and for that I needed a good, simple solution for WordPress. A place to start at least.
I came across the excellent UpdraftPlus plugin for WordPress, and after some fiddling around, I got it working nicely with my Google Drive account. Initially I wanted to use Dropbox, but frankly Dropbox’s free space is pitifully small. In an ideal world I’d connect any backups to Apple’s iCloud storage… after all I’m paying for a terabyte of it. Sadly, none of the services I looked at support that. Apple! Google Drive with 15Gb storage to the rescue, via the creation of an API key and authorising my web server, the backs are running smoothly.
Writer Me likes to hang out with fellow writers, share fun links, talk about the process. There’s a lot of hair-pulling and alcohol involved. Developer Me likes to chat tech with fellow developers, share experiments and talk workflow. There’s a lot of hair-pulling and alcohol involve.
I tend to do most of my tweeting from @shellbryson. This leads to a problem: there are two sets of folks I’m interactive with and 1) when I’m on a roll with writing I’m posting a tonne of writing things 2) when I’m deep in code experiments… Basically I need to pick an audience and stick with it. It’s a marketing thing (sigh).
Yesterday I created a new Twitter account dedicated to Developer Me: @sherucode.
Banners and Avatars
New account, new art. I like my wee “sheru” Chibi—a left-over from working with the wondering AnimePicks team a few years back—but the avatar never really fit the developer me. Definitely not the writer me.
Head scratching, and with zero time to do a full brand, I opted for something playful, but… code-y. What better than to use what I have to hand? Shot with an iPhone, retouched in PhotoShop:
Twitter likes a big banner, so I took another photo of what was literally in front of me… my keyboard. Then off into PhotoShop. Layer masks, blurs and radial fills and masking of letters and we have:
It was fun to spend some time with PhotoShop again. Working for an agency means I tend to be given designs to implement, rather than having and hands-on during the design process.
Another crazy week as we get into the final few days before launch of a big new financial site at the studio. Meanwhile, I’ve managed to calve out a little time to play with React. I still have an issue with JSX and inlined CSS. It feels like a backwards step, mixing structure, JS and CSS together. All that careful separation of concerns that have been hard-fought over the years seem to somewhat fall aside when it comes to some of the modern framework.
Thing is, React is great. It makes a tonne of sense. It’s really cool to work with.
Manic week at work as we get closer to the release on a big financial site (hence the severe lack of updates here). Took some time out tonight to do some housekeeping.
Finally got around to adding IPv6 after reading various press regarding the increasing scarcity of IPv4 addresses. It’s a little more fuss to setup, but seems to work. Not that I can hit IPv6 addresses from this cable network…
While tinkering with the server, snapshotted, updated and patched everything.
A week ago I added Digital Oceans’ new monitoring beta tool, and it keeps bugging me that this server is using over 60% of its memory. Which doesn’t match what the memory monitor itself tells me on their admin panel. Something else to investigate…
Virgin Media were around today so we have a new 8-tuner set-top box and 200mbit internet. Long (very) story short, it’s taken 6 months to get a new modem from them. But hey, now we have the top tier TV and funky new 8-tuner set-top box too.
Added an Inspire section to this site for those days when everything on my laptop looks bad. Also because I’m currently in deep trying to figure our exactly what Project Sheru will look like (why is it so hard to make sites for yourself?).
There’s nothing like the crunch at the end of a project to find out which processes are really working for you. Agile is a great methodology for approaching a project, but it can easily (and frequently, in my experience) lead to “ticket overload”. This is especially apparent at the end of projects where throughput of tickets is critical as the project rushes towards a hard deadline.
So why the deluge of tickets? Perhaps it’s a sign that something didn’t work earlier on. That QA were onboard far too late, or poorly scoped tickets or poor executed code. Overly ambitious requirements, or fiddly design. All of the above. And some of that is just natural entropy in a project-especially the long run ones where process expands to fill all available time.
It’s not always hard. We’ll do better next time. But sometimes we forget that process is there to help. Not strangle. We forget that we should be hungry to deliver, and delivery is more important than process.
Given a week to deliver something, you find a way to deliver. Any away, whatever it takes.
Given three months to deliver something, process finds a way to trip you up.
I believe in release often. Release small. Real deadlines. Real opportunity for the client to see something to feedback, to catch those changes and design glitches, the bad code or trippy UX. Release every week, twice a week, every other-day. Sit the client down and walk them through it. Show something. Be cool with what you’re showing them. It’s work in progress.
Real agile is iteration. Not invisible sprints without consequence or comment. Breaking a waterfall project into sprint and calling it agile is not agile.
A rolling discussion tonight regarding media queries (breakpoints) and the units to use. em, px, rem? This (zellwk.com/blog/media-query-units) article suggests that em behaves the most consistently across all browsers, but then digging into the comments, there’s a counter argument for px.
I like to use em/rem for elements that are truly relatively scaled. So things like borders and absolutely positioned elements I generally stick to px units.
Personally, I prefer px. em and rem are both relative units, units that scale based on font-size set by the user (or defaulted in the browser). Now take mobile: what if the user is using enlarged fonts. If the media queries (breakpoints) are also scaled because of the units used, how will that impact mobile?
Feels like I need to experiment more around this, but to quote a colleague…
just do what you want and let the browsers deal with the headache
It’s fleshing coming at a personal project with the learning of some of the big Agency projects of the last couple of years. The techniques learned scale well for this smaller project, but there’s also loads of room for improvement as ever.
Today had a fight with filtering Categories in WordPress. WordPress won. But I will not be beaten forever!
I’ve pulled all of the colours from the Sheru experimental theme so it uses just 3 base colours now. The rest are processed on the fly.
The site is no longer restricted-width (well, to a point)
Content now scales
All that gloomy black is gone. Bring on the brightness.
Live editing of themes inside WordPress admin is the scariest thing (but, y’know, awesome). Could so easily fry a site, and it scares me even more to think the number of custom themes must out there in the hands of clients with this feature enabled. Carnage.
So, cough, throwing caution to the wind, made a couple of live edits to this blogs bog-standard theme to filter out these posts from the far more interesting (?) code-tips etc on the front page. Also hid “recent posts” for now. The Project Sheru theme will allow filtering of those, but for now… it didn’t crash.