jonpearse.net

A letter to myself 10 years ago

Fri, 03 Jan 2020 00:00:00 GMT

This is something I’ve been trying to write for over two and a half years, but I’ve never really been all that happy about how it’s turned out during that time. I came close in 2017, but even then I think I was so close to what I wanted to write about that I couldn’t see the wood for the trees.

Maybe it’s because I’ve been giving myself a lot more time this past couple of years, maybe it’s because things changed fairly profoundly in May/June last year prompting me to think much more about my future.
Whichever way, Simon Clark’s “A letter to myself 10 years ago” inspired me to have a bash at the format myself, and it seemed to … work.

I’m still not 100% happy with it, but this is definitely one of those things where it’s better to publish than not, so this is what it is: a letter to myself 10 years ago.

Hi me, it’s you. Or a potential version of you. If it helps, think of me as the third ghost from “A Christmas Carol”. Whichever way, things are about to get all kinds of interesting for you, so here are a few things I know now that I wish I’d known when I was you.

Enable will go under in 9 months. It’ll be a shock, and while you’ll interview with a couple of companies, you’ll also be offered the perfect opportunity to go freelance.
And you’ll love it: you’ll love the flexibility, you’ll learn a huge amount about both yourself and new technologies, and you’ll work with some great people on some interesting brands.

You’ll also burn out. Hard.

You’re good, you’re fast, and you already have high expectations of yourself. There will be tight deadlines, difficult projects, and unpleasant end clients. Because you won’t want to let people down, you’ll work increasingly long hours in order to get projects delivered in something that at least approximates on time. At one point, you’ll realise the only way you can deliver a project on time is to work on less than two hours’ sleep a night. For two weeks straight.
And you’ll do it.

You’ll first realise something is wrong in the beginning of 2015: you’ll reach the end of a long, difficult, and largely pointless project and you’ll feel completely exhausted. You’ll want to take some time out, but you’ll also be tied up in contracts and not want to let anyone down.
So you’ll not do anything substantiative about it: to start with you’ll reason you’ll be going on holiday soon enough, so you just need to get through the next couple of months until then. When you return and feel no better—despite having the best holiday you’ve had to date—you’ll reason that it’ll all resolve itself over time: maybe next week, or at the end of the next project.
Just like the apocryphal frog in the rapidly-heating water, you’ll not realise how bad it is until it’s too late.

By 2017, you’ll need frequent pep-talks to get yourself going in the morning, or to get out of the car and into the office once you’ve driven to whichever client you’re working with at the time. You’ll take to hiding in bathrooms and crying when it all gets too much, and panic attacks—both minor and more intense—will become commonplace and leave you both unwilling and unable to leave your flat.
You’ll also begin to let people down: not clients—not yet, anyways—but friends, family, your partner. You’ll avoid making plans, miss social engagements, and not be there when you really should’ve been.

The shoe will eventually begin to drop in summer 2018: not fully, but enough you finally realise how unwell you are and start to take time out to deal with it. This won’t be the end of it: you’ll have a couple of hare-brained ideas which will make things slightly worse, and summer 2019 will be all kinds of unpleasant for only tangentially-related reasons, but hopefully it’s the start of something better.

That’s not to say it’s all going to be bad, in fact there are a lot of good things to look forward to: you’ll travel plenty, you’ll meet some incredible people, and you’ll have plenty of fun while doing it. But it will be more than a little overwhelmed by all the bad stuff going on at the same time.

So here’s what you should do, and what I’m currently doing:

Work less

It probably seems obvious, but you don’t need to take on all the work that’s being offered to you, and even with the work you will take on, you definitely don’t need to work evenings and weekends.

Take more time off

Again this should be obvious, yet here we are. Book breaks between contracts and within long contracts. Don’t be afraid to take time unscheduled time off: if your clients are worth keeping they’ll understand, and if they don’t understand they’re not worth keeping—good will goes both ways.

Get out of marketing/advertising

You dallied with it at Carlson and you’ll return to it as a freelancer: it may be fun and creative in the short-term, but ultimately none of it matters a damn.
Far too many of the long hours you’re going to pull over the next decade will be for sites that precisely no-one outside your team and the end-client’s marketing manager will ever care about. They could disappear off the face of the planet—and many will after only a few months—and the world will continue to turn, people will continue to go about their lives, and you’ll have absolutely nothing but stress and bad posture to show for it.

You’re doing good, meaningful work right now at Enable: don’t let yourself get distracted from that. It is so not worth it.

Talk about things

You’ll actually do this, but mostly to vent rather than anything more productive. Talk to people, weigh their advice, do something about it.

Get help

You’ll spend several years trying to convince yourself you can handle this by yourself, or that you aren’t deserving of proper help because others have it worse than you. You can’t, and ‘worse’ is subjective—you deserve to be happy.

Forgive yourself

Seriously: it’s not your fault, and you are not beholden to your past. Learn from the mistakes, move on (and if you work out how, let me know)

Oh, and take a trip to London and give your grandmother a hug: she doesn’t have long left and you will miss her. So much.

I’m thinking about writing more about this: maybe something sooner about plans, and later about progress/how I’m doing. If nothing else, having spent the past several years trying to bottle everything up and pretend it’s OK, I want to be more open and honest with myself.

Besides: I know I’m not the only one going through this, or something like this. Maybe this will be useful, or maybe it’ll just be visible.
To wit, if I’ve said anything you’re curious about, or you want to reach out for any reason—even if it’s just to say ‘hi’—please do.

Acknowledging happiness

Fri, 03 May 2019 01:00:00 +0100

It will come as no surprise to anyone who knows me or follows me on twitter that things haven’t been especially fantastic in my world for a little while now. I wrote about a part of it a little over two years ago and have been meaning to write more since, but suffice to say things have generally been trending downward until my mental health took a fairly profound (but not entirely unexpected) nose-dive last summer from which I am still recovering.

I will write about it sometime, for no other reason than to try and better understand it myself, but not yet.

Because despite everything, this week has been awesome.

I started with a new client on Monday: the work is far from world-changing, the clients’ location means I am spending in excess of three hours a day commuting to and from the office, and I don’t feel like I’ve had a good nights’ sleep all week. But strangely none of that seems important.
Because every day this week I’ve been leaving the office with a smile on my face. The tiredness and frustration that I’ve come to expect has been replaced by satisfaction and accomplishment.

Earlier today I was stopped in the middle of wrangling Date objects in Javascript by a sudden realisation of just how happy I was: I wanted to sing or shout, but instead—in deference to my colleagues—chose to spend a few moments in quiet mindfulness.

This post is an extension of that. This feeling won’t last, the contract will end, and the problems I’ve been dealing with will still be there. This too, soon, shall pass.
But too often when things are going badly, we reach for social media to rant and complain, and while the moment passes the tweets and posts do not. Perhaps we should acknowledge happiness more, and that’s what this post is about.

How has your week been? Maybe it’s worth remembering.

Extracting SVG spritesheet dimensions with gulp

Wed, 05 Sep 2018 01:00:00 +0100

I’ve been working on something of a legacy project for a client of late, and about 5pm yesterday QA raised a bug. In the spirit of Sara Soueidan’s recent invocation to “Just Write”, I thought I’d write it up in case it’s helpful for anyone else.

At some point in the history of the project in question, it was updated to use SVG spritesheets in lieu of custom icon fonts. To do this, the author had used gulp-svg-sprite which, among other things, spits out the dimensions of the individual files into a CSS file for later use.

This has worked fine, right up until I created an icon with a gradient and came across a known bug where gradients aren’t handled correctly and therefore don’t work in Firefox. Unfortunately, while the issue has been fixed in the repo, it doesn’t seem to have been made available in a public release at time of writing.

After a bit of poking around, I opted to fix this by replacing gulp-svg-sprite with my usual combination of gulp-svgstore and gulp-svgmin, with a wee bit of custom glue to generate the required CSS file.

Let’s write some code

The usual invocation when using gulp-svgstore is something like this:

const gulp = require( 'gulp' );
const svgstore = require( 'gulp-svgstore' );
const rename = require( 'gulp-rename' );

gulp.task( 'svg-sprites', () =>
{
	return gulp.src( 'path/to/*.svg' )
		.pipe( svgstore() )
		.pipe( rename( 'spritesheet.svg' ) )
		.pipe( gulp.dest( 'output/directory' ) );
} );

If you’re not au fait with gulp, this ingests all SVG files in the specified directory, compiles them into a single file of SYMBOL elements and saves the resulting file in output/directory/spritesheet.svg.

So what about generating the CSS file?

I’m sure there are other ways of doing this but, inspired by an example in the gulp-svgstore documentation, I elected to process the output stylesheet thus:

const gulp = require( 'gulp' );
const svgstore = require( 'gulp-svgstore' );
const rename = require( 'gulp-rename' );
const through2 = require( 'through2' );
const cheerio = require( 'cheerio' );

gulp.task( 'svg-sprites', () =>
{
	return gulp.src( 'path/to/*.svg' )
		.pipe( svgstore() )
		.pipe( rename( 'spritesheet.svg' ) )
		.pipe( gulp.dest( 'output/directory' ) )
		.pipe( through2.obj( function( file, encoding, callback )
		{
			// load the file using cheerio in XML mode
			let $ = cheerio.load( file.contents.toString(), { xmlMode: true } );

			// find all symbols and generate a string of CSS
			let sCssString = $( 'svg > symbol[viewBox]' ).map( ( idx, el ) =>
			{
				// get the viewbox attr + split it out into components,
				// also grab the ID
				let $el = $( el ); // caching for later
				let aViewbox = $el.attr( 'viewBox' ).split( /\s+/ );
				let sId = $el.attr( 'id' );

				// return a formatted string
				return `.${sId}-dims {\n`
					+ `\theight: ${aViewbox[3]}px;\n`
					+ `\twidth: ${aViewbox[2]}px;\n}\n`;
			} ).get().join( '\n' );

			// write our CSS back to the file stream
			file.contents = Buffer.from( sCssString );
			this.push( file );
			callback();
		} ) )
		.pipe( rename( 'dimensions.css' ) )
		.pipe( gulp.dest( 'output/directory ' ) );
} );

I’m using through2 (mostly out of habit) to give me a slightly nicer interface for dealing with the inbound/outbound file stream, and Cheerio to parse the SVG and provide a jQuery-like interface for ease of traversal.

Otherwise, the actual process of finding SYMBOLs and generating individual CSS rules based on their IDs is relatively simple.

Things to mention

I mentioned gulp-svgmin earlier, but have not included it in either section of code as it’s not really part of the process in question, but for completeness’ sake, I tend to use it after gulp-svgstore to tidy up the generated code and remove any unwanted elements/attributes.
In the case of this project, I also used it before gulp-svgstore to try and normalise everything before generating the spritesheet (because legacy/folk blindly exporting from Illustrator without tidying things up first).

More significantly, I also found that in some cases, gulp-svgstore occasionally strips the viewBox attribute from the SYMBOL element (even if the source SVG file had one). I wasn’t able to work out why (it was late in the evening and I wanted to go home), so I wound up processing individual files in a separate gulp task:

const gulp = require( 'gulp' );
const rename = require( 'gulp-rename' );
const through2 = require( 'through2' );
const cheerio = require( 'cheerio' );
const basename = require( 'path' ).basename;
const rename = require( 'gulp-rename' );

gulp.task( 'svg-sprite-dimensions', () =>
{
	return gulp.src( 'path/to/*.svg' )
		.pipe( through2.obj( function( file, encoding, callback )
		{
			// load the file
			let $ = cheerio.load( file.contents.toString(), { xmlMode: true } );
			let $svg = $( 'svg' );

			// get the viewbox, height and width attrs
			let sViewbox = $svg.attr( 'viewBox' );
			let fHeight = parseFloat( $svg.attr( 'height' ) );
			let fWidth = parseFloat( $svg.attr( 'width' ) );

			// if we have neither height nor width, then try a viewbox
			if ( Number.isNaN( fHeight ) || Number.isNaN( fWidth ) )
			{
				let aViewbox = sViewbox.split( /\s+/ );
				fWidth = aViewbox[2];
				fHeight = aViewbox[3];
			}

			// get a filename so we can generate our rule
			let sFilename = basename( file.path, '.svg' );

			// create our rule + push it back
			file.contents = Buffer.from(
				`.${sFilename}-dims {\n`
					+ `\theight: ${fHeight}px;\n`
					+ `\twidth: ${fWidth}px;\n`
					+ `}\n`,
			);
			this.push();
			callback();
		} ) )
		.pipe( concat( 'dimensions.css' ) )
		.pipe( gulp.dest( 'output/directory' ) );
} );

It’s a slightly different approach, but the overall process is pretty much the same: it just modifies the contents of the individual streams being processed & concatenates the result, rather than doing it all in one place.

Of course, whether or not you need to do it this way will depend on circumstance: I’ve tested the first approach—processing the spritesheet—with a number of other projects I’ve worked on in the past couple years and it’s worked fine each time. I’m assuming there’s something about the way some of the SVGs were generated in this most recent project that required the alternative approach 🤷‍♂️

Of course, the internet being the internet, there’s almost certainly a node module that does this automatically and I didn’t find it while I was searching last night, but this was an interesting foray into the world of node and gulp so hey.

Maybe this will be useful to someone—share and enjoy :)

UX Special and CSS Day 2018

Tue, 19 Jun 2018 01:00:00 +0100

I’m on my way back from Amsterdam and the 6th iteration of the ever-wonderful CSS Day conference. This time around, the first day—the theme of which varies from year to year—was all about UX.

This is a quick write-up of everything while it’s still relatively fresh in my mind: I’ll probably miss a few bits out (because there was a lot of information in a relatively short spot of time), but it should hopefully give you a reasonable taste of ~~what you missed~~ what happened over the two days.

Day One: UX Special

Alla Kholmatova started the conference talking about the importance of building a set of design principles: the underlying guidelines by which the design process should be run. These should be genuine, opinionated, actionable, and memorable—with no more than three to five in total. They should also be defined with the audience and goals in mind, rather than being abstract, and should be continually re-assessed to ensure that they still work.

Jenny Shen told us how to build bridges, not walls when designing for users across cultures. She emphasised the importance of understanding both the local culture and traditions of our audience, as well as the existing conventions already being used within the web and mobile apps—for example, that while western sites/apps use the ‘Hamburger’ or ‘three dots’ icon to denote a menu/additional options, in China a ‘Discover’ option is far more widely used and understood. She also mentioned that when looking for existing research, your search should be for content in your audience’s native language, rather than your own.
And never use machine translation: just… don’t.

Jane Austin gave us ten (actually eleven) ways to irritate our design teams. She talked about the double diamond and the importance of building the right thing, and building the thing right. Also, that it is sometimes far more productive to stay with sketches and wireframes for longer as people find it easier to be critical of them, without getting too invested in/distracted by the visual designs. For the curious, the eleven ways were:

asking designers ‘just to colour in the wireframes’
treating designers as feature factories (+ don’t fake agile)
treating projects as ‘ship and forget’, with no time to fix and revisit at a later stage
doing the above until technical debt has piled up so high that it is impossible to ship anything at all
poor hiring and onboarding practices
not providing designers with a future
not allowing proper time for research (+ responding to what people want, rather than what they need)
overloading everyone with meetings (managers typically split their days into 30min slots, whereas designers—and developers—work in multi-hour chunks, leading to scheduling conflicts)
having a poorly set-up workspace (walls on which to stick post-its are absolutely essential)
culture (if the culture is bad, people won’t want to work for you)
micromanagement (no-one likes a hovering art director)

Benjamin de Cock explained how clever design and animation can help user experience, but only if done properly. Subtle transitions and animations can be really useful to illustrate how an interface is working, and purely decorative elements can make an interface seem more ‘friendly’ and welcoming, but taken too far they can actively get in the way of what users are trying to achieve. Websites should also respect the user’s preferences—if iOS users have opted to reduce motions in their UI, your website should also do so.
From a development perspective, only the transform and opacity CSS properties are ‘cheap’ to animate, and with a little lateral thinking, many effects can be created with combinations of the two. Where this is not possible, SVG animations should be used instead, especially as they will use subpixel aliasing, resulting in smoother animations.

Nadieh Bremer shared her experience of working on Data Sketches, a data-visualisation project in collaboration with Shirley Wu. She talked through her process of creating a visualisation, starting with sourcing and ascertaining the accuracy and completeness (use google, don’t be afraid to break out the spreadsheets), and emphasised the importance of sketching ideas out as a way of catching any errors in the design or data before committing too much to code.

Vitaly Friedman talked about how terrible the average ecommerce experience is for users: extra costs, limited payment methods, enforced sign-up, and a perceived lack of trust in the platform leads to an almost-70% abandonment rate (in particular, 54% of users will abandon the process when asked to sign up, 75% if they have to go through a ‘recover password’ process). He also talked about the importance of reviews (4.83/5 stars is optimal, apparently), breadcrumbs, and ‘thumb-driven design’: that folk using mobile devices are more accurately able to hit targets in the centre of a touchscreen than in the corners.

Ida Aalen told us how she does user testing on a budget, impressing that developers and designers aren’t suitable candidates for testers (they’re all a little too genre-savvy), as well as warning against testing by usability experts who apparently miss 50% of actual user issues, whilst 33% of raised issues are actually false flags.
Instead, we should be going out into the world—with snacks—and testing with real live people, asking them to perform tasks (without helping) whilst thinking out loud and explaining what they’re doing.

Andy Budd closed the day out talking about becoming an ‘Accidental Design Leader’ (although everything he said could apply to anyone in a leadership position). He highlighted that many people see leadership as power and that power is necessary to make change, whereas in many organisations it’s far more complex than that, and that leaders should stand between them and the larger organisation.

Day Two: CSS Day

Eric Meyer began the day talking about the ‘Friction of Web Standards’; explaining that some apparently simple browser features take far longer than might be expected to become standards because they’re actually quite difficult beneath the surface. His example was the humble border radius, and how it interacts with background images, box shadows, and differing border styles and thicknesses. He also highlighted the ‘long tail’ of the internet: that the first website still works, and that the browser default styles for blockquote elements have a left margin (or inline-start margin, if you will) of 40px because that’s what Mosaic did, and therefore the implicit requirement of decisions to be made ‘right’ rather than ‘quick’.

Richard Rutter talked us through the ‘Golden Rules for Typography on the Web’: how display text—for titles and such—should often be treated differently to paragraph text, and how both should be sized across different devices to attain maximum readability. He also talked about variable fonts—a part of the CSS Fonts level 4 spec—which allows full manipulation of a number of different axes (font weight, slant, spacing, etc) whilst only distributing a single file over the wire.

Hidde de Vries took us on a journey through 100 years of graphic design to show us that the ’Web is ready for great graphic design’. Through the works of Jan Tschichold and Josef Müller-Brockmann, he explained how CSS Flexbox and Grid in conjunction with CSS viewport units can make our lives substantially easier without having to resort to 12-column layouts and CSS frameworks like Bootstrap.

Sara Souiedan then proceeded to blow our minds with a fast-paced introduction into the world of SVG filters. In contrast to the somewhat limited set of CSS filters (which are applied one after the other), SVG has nineteen individual filters which can be combined in any way you wish, and therefore can be used to do Photoshop-like effects in the browser in real time. She started off with a simple drop shadow (which, unlike CSS, supports complex shapes rather than just rectangles) before showing us how to implement displacement effects and, eventually, a rather attractive crumpled paper texture via judicious use of noise generators (I will so be experimenting with this!)

Greg Whitworth talked about container queries, why we don}t have them yet, and why we probably don’t actually need them because CSS flex and grid along with object-fit and viewport units can do a lot of what we are trying to achieve in a much more performant way, albeit with a little more lateral thinking. He talked about ResizeObserver (wonderful but almost completely unsupported) and IntersectionObserver and how they can be used to provide container query-like behaviour when required, but also highlighted the importance of deciding whether the designed behaviour was actually strictly required as opposed to merely being desirable, and therefore whether it was actually needed at all.

Hui Jing Chen talked about how we as CSS folk are ‘programmers of boxes’ as she covered the intricacies of boxes in CSS. With the help of some especially endearingly-illustrated slides, she talked about box positioning, flow context (aka, how to clearfix without, well… clearfix), and finally CSS flex and grid, and how it all works together with writing direction and the myriad possibilities it all gives us.

Ire Aderinokun talked about building websites for the ‘next billion users’, likely to be users of much-improved assistive technologies, non-English speakers, folk using the internet primarily on mobile devices, and those with poor internet access. She talked about building performant sites, that are easy to internationalise, and that are highly accessible (something we seem to have forgotten over the years). This applies equally in code, where we should be using the right tool for the job (CSS for presentation, JS for behaviour), ensuring our CSS classes and variables are named globally (‘sidebar’, rather than ‘left’), and choosing CSS selectors appropriately (ID and class are way more performant than :nth-child and pseudos).

Finally, Bruce Lawson took on the subject of CSS-in-JS, talking about some of the reasons for the cultural clash that has been taking place since its arrival in the world, and offering a potential solution in the shape of Stylable: a component-friendly pre-processed framework that compiles down into vanilla CSS. There was also distribution of mohawked potatoes through the audience, but … you kinda had to be there.

All of which is a lot of words that really can’t do the conference justice: there was so much tremendously good stuff covered at the conference, and I’ve come away with a list of projects, techniques, and APIs, some of which will be worked into projects directly, and others—like everything from Sara’s talk—that I can’t wait to take a deeper dive into and have fun with. The hardest part thus far is prioritising everything instead of trying to do it all at once!
More than that, though, it was the opportunities to meet developers, designers, UXers, and others from all over the world (albeit, mostly from the Netherlands) and to chat ideas, inspiration, and web tech in such an enthusiastic and relaxed atmosphere.

If you want more, take a look at the CSS Day twitter feed, Stephanie Nemeth took some amazing sketchnotes, and you’ll almost certainly want to keep an eye on the CSS Day Vimeo channel where videos of the conference will be joining those from previous years over the next few months.

And, of course, CSS Day will be returning next year with a UI special: provisional dates are June 13–14th, but keep an eye on the website for updates. I’ll see you there!

Gem updates

Wed, 06 Jun 2018 01:00:00 +0100

I’ve had some downtime of late following the end of my most recent contract, and I might possibly write about the larger part of my motivation behind this at some later point, but it has given me the opportunity to do some ‘personal’ projects, including a few bits and pieces that I’m releasing as open-source.

Thus, a quick summary of a few Ruby Gems I’ve released/updated recently.

`devise_date_restrictable`

This is an extension for the widely-used Devise gem that allows restriction of user access by date (either before- or after a single date, or between two dates). It’s fairly self-contained and simple to use, so if you’ve used Devise before, there shouldn’t be anything too surprising in devise_date_restrictable.

Careful observers will note that this isn’t an especially new gem. I originally wrote it about a year ago for Sønr and released it as 0.0.1 at the time, it’s just taken until now to have enough time to polish it into a properly releasable (ie, 1.0.0) state.

For more information, check out the Github repo or RubyGems page.

`simple_ar_localizer`

This is a utility gem that ties into Rails’ I18n framework and—hopefully—gives you a slightly easier interface for localising ActiveRecord objects without having to mess around with awkwardly-nested YAML files. This is especially useful if, like me, you like breaking your localisations up into per-model files to keep everything in a reasonably obvious place.

Out of the box, it handles ‘human’ model names and attribute names (including pluralisation), as well as validation/error messages defined on both a per-model or per-attribute basis. Beyond that, it has a fairly extensible configuration to allow you to use it in any way you so desire.

Again, this is something that came from Sønr and that has been released into the wild in case it proves useful for anyone else.

More information—including documentation + examples—can be found in the Github repo.

`grouped_property_scss_linter`

This is definitely not a new gem and I’ve written about it before, but in the process of rebuilding this site I found that it really didn’t like CSS custom properties (‘variables’). A little digging and bugfixing later, and it’s back to being useful once more.

Whilst I was at it, I also informed it of a few properties—mostly surrounding CSS Grid—about which it had hitherto been unaware. I’m still not 100% sure whether grid content or -parent properties should go first, but at least it doesn’t ignore them completely!

As with everything else more information, documentation, and the like is on Github.

…

Share and enjoy!

Creative Constipation

Sat, 29 Jul 2017 01:00:00 +0100

The observant among you will have notice that I have, once more, gone a year without updating this site.
Whilst I can attribute at least some of this inactivity to a general lack of free time, a lot of it comes down to what I have chosen to call ‘creative constipation’, a phrase for which I can only apologise. (but c’mon: the alliteration was too good to ignore!)

This is not an especially new thing for me: over the past couple years, I’ve been growing increasingly… discontent with many aspects of life, most of which are focussed around ‘the job’.
For much of that time, though, I’ve found it difficult to really put my finger on what exactly is wrong. It has been obvious that at least some of it was to do with the kind of work that I’ve been doing (as well as the quantity in which it has sometimes arrived), but I know that’s only a part of it: that there is something far deeper and just that little bit out of touch.

If you can’t define a problem, it’s bloody difficult to work out how you’re going to solve it.

But that changed last month with a week-long trip to the Netherlands for the brilliant CSS Day Conference.

It goes without saying that the conference itself was amazingly good, and was worth the ticket price alone to listen to the inventors of CSS talk for an hour on the early days of CSS, what they thought of more recent developments, and what they’d have done differently in retrospect.

But of the talks, there were four that especially spoke to me: Rachel Nabors spoke about CSS Animations, Ruth John about the Web Audio API, Rachel Andrew about CSS Grids, and Jen Simmons about writing modes and CSS (and a bit of CSS Grid for good measure).
With the exception of all things CSS Grid (which is cool stuff, yo), none of them really had anything to do with the kind of work that I do on a day-to-day basis, but they reminded me that the web can be fun and deeply creative in a way that I’d almost forgotten.

But beyond the conference, while we were in the Netherlands, we visited Museum Speelklok in Utrecht, and the Gemeentemuseum in Den Haag.
I’d learned of Museum Speelklok—the museum of self-playing instruments—thanks to Martin Moulin of ridiculous marble machine fame, and we visted Gemeentemuseum because they had two exhibitions running simultaneously: one celebrating the centenary of the birth of De Stijl, and the other a retrospective on the work of Piet Mondriaan (in fact, the largest collection of his work ever exhibited).

Both museums were hugely inspiring: the first as both a musician and a maker, and the second… well, strangely, that inspired me to do some strange things with CSS, but more about that in a future post (suffice to say, I really like neoplasticism).

Between CSSDay and wandering around various museums, I came home from the Netherlands fired up to do some really cool stuff.

And this is where we come back to creative constipation: I wanted to do something creative, I’d spent a few hours here and there sketching up some ideas, I made some free time during which to work on everything. I even started playing with some neoplasticism-inspired CSS hacks.

But then when the time came, when I had a glorious weekend to myself… nothing. All that inspiration and… nothing.

The same applies to making: I started the year with a flurry of electronics projects, I invested in some new kit, and acquired a bulk order of components so I could ‘just build’ when the inspiration struck rather than having to order stuff in first… and yet, with all the time in the world, nothing.
And then music: I have a couple guitars, a recorder, a flute, and a keyboard knocking around the flat. The other week, I found that Korg has released a software version of their Wavestation as an iPad App (and I love me the Wavestation), so I bought it and got a USB–MIDI interface so I could hook my old keyboard up to my iPad … but still, nothing.

I have a surfeit of inspiration, I have sketches and notes of ideas, I have the tools by which I can bring that inspiration and those ideas into reality, I even have the time to do it… and yet, nothing.

I am creatively constipated, and it sucks.

And that, I think, is the crux of everything that has been going on these past two years: with the greatest of respect for those with whom I have been working, a majority of the projects I’ve worked on have felt … samey and uninspiring—the same old stuff dressed in new clothes. Whilst it has been many things, and has given me the opportunity to work with some amazing people (you know who you are ❤️), it has left me feeling creatively unfulfilled and wanting.
If creativity is a muscle, mine has withered and wasted, and leaves me unable to flex it when I want… and it sucks.

Things need to change, and now I’ve gotten to the bottom of ‘why’, I can start thinking about what I need to do to change it. I already have some fairly big plans under way, but top of that list is re-engaging with my creativity.
Some of the things I’m planning scare me, but I think that’s a healthy sign: I’ve lived too comfortably for too long and it’s made me fat and lazy. It’s time to do something different.

This is going to be fun. And scary. But mostly fun.

On linting, and bringing order to SASS

Fri, 15 Jul 2016 01:00:00 +0100

2019 update: with SASS being ported from Ruby to Dart, SCSS-Lint is no longer being maintained, and the SCSS-Lint team recommends using other tools instead. This post is left for curiosity’s sake.

Recently I’ve been working on-and-off on my front-end tookit (ie, the basic CSS/JS/etc I use to bootstrap projects). I’m almost ashamed to admit that it’s taken this long, but let’s file it along with the shoemaker’s children and move on.
Whilst the overall process is something for another blog post, it’s spawned a couple of interesting side-projects, one of which has got to the stage where I can consider it ‘ready for the world’.

This particular side project came about after going to work with the lovely folk at Mr B & Friends in Bath, who sometime earlier this year began to roll out SASS linting using the SCSS-Lint Node plugin.

Now, those who have worked with me in the past might think that I have something against linting: certainly, I’ve been known to express an opinion or two.
The truth is, though, I’m actually really quite fond of linting… as long as it’s sane.

Let’s talk CSS Property Ordering

When you get started with SCSS-Lint, one of the linters enabled by default is called PropertySortOrder and forces a strict ordering of properties within each rule.

This makes reasonable sense when writing ‘Vanilla’ CSS, as there are some benefits to doing so beyond just ‘looking good’.
However, when writing SASS—or any other precompiled format—I would suggest that by the time your code has been through the precompiler and anything else in your toolchain, there’s a good chance things aren’t quite as neat as they might have been to start with.

Besides which, I don’t know about anyone else, but I’m not especially great at remembering a specific order of all 500+ CSS properties, and having to constantly parse the output of a linter and rejig my code gets very old very quick.

Less order, more collation

That’s not to say this kind of linting is bad, just a little unnecessary. There is a lot to be said for keeping your CSS neat, and to this end many developers—myself included—have taken to grouping similar/related properties together within rules (SMACSS, for example, talks about categorising properties).

However, I’m not especially fussed about the particular order of individual properties within each of these groups or categories. As long as—say—positional properties are all grouped together, I’m not too bothered if top is specified before left or vice-versa.

Hopefully this strikes some kind of happy medium: your SASS is—hopefully—clean and readable, but without the overhead of having to worry about exactly which properties go in which order.
Less worrying about pleasing the linter makes for happier developers, who can then concentrate on more important things. Those owls won’t lobotomise themselves, after all.

I did have a look around for an SCSS-Lint plugin that allowed this kind of fuzzy grouping of properties, but my search came up blank.
So I wrote my own…

Introducing `grouped_property_scss_linter`

grouped_property_scss_linter is a catchingly-titled SCSS-Lint plugin gem designed to replace the default PropertySortOrder and provide a saner linting experience, based on grouping CSS properties within a rule.
As long as the groups are in the right order and have suitable (and configurable) separation, the linter is happy.

Thus, whilst…

.myClass {
	height: 200px;
	color: #333;
	width: 200px;
}

… is bad, either of

.myClass {
	height: 200px;
	width: 200px;
	color: #333;
}

.myOtherClass {
	width: 200px;
	height: 200px;

	color: #333;
}

… is just fine.

Which hopefully makes for happier developers, and that can only be a good thing. Unless you’re an owl.

I’ve spent the past month kicking it around in various projects, and it seems to be working OK… well enough that I think it’s ready to be inflicted upon the world.
It’s currently available—with a readme—on my github account. Check it out, kick it about a bit, let me know what you think.

But what about…

As I mentioned earlier, there are good reasons for using strict-ordering within your CSS, and this linter doesn’t really help you get there.

Fortunately, for those using a Node toolchain to compile SASS, there’s a Node module called postcss-sorting that will order your CSS properties to your satisfaction after everything’s been compiled.
Other solutions for other platforms may exist, I’ve not really looked as yet.

Finally, for those who want this kind of grouped property linting but aren’t using SASS, the stylelint Node module does approximately the same thing for vanilla CSS, and may have influenced this linter gem more than a little.

#TILJS: Converting from NodeLists to Arrays

Thu, 14 Jan 2016 00:00:00 GMT

2021 update: NodeList has had its own forEach iterator for a little while now, so unless you’re—for some reason—supporting IE11, you probably shouldn’t be using anything I wrote about in this post. I will, however, leave it here for curiosity.

A couple days ago, the highly esteemable Mr Jegtnes launched TIL JS: a side-project born from a desire to improve his JavaScript skills.

It’s a brilliant idea, and given two of my goals this year are to [a] ditch jQuery, and [b] get properly into Node / polish my JavaScript, I thought I’d ~~jump on the passing bandwagon~~ join in, thus…

Background

Anyone who’s used jQuery or any of its clones will be instantly familiar with its $(selector) syntax, which allows targetting of arbitrary elements within the DOM by CSS selector. It’s extremely powerful, and for anyone who remembers the bad old days before jQuery, makes life whole amounts easier.

In recent years, similar functionality has been added to native Javascript in the shape of the querySelector and querySelectorAll functions, the former returning a single Node, and the latter a NodeList.

However, whilst NodeList objects might look a little like array to the casual observer they aren’t, as anyone who attempts to use any of the new(-ish) array iterator functions will find out very quickly.

The magical invocation

Fortunately, converting from a NodeList to an Array is simple:

var myArray = [].slice.call( myNodeList );

You could even abuse Javascript’s prototype inheritance and do something like:

NodeList.prototype.toArray = function()
{
	return [].slice.call( this );
};

… which would give you the ability to do this:

var myArray = document.querySelectorAll( '.foobar' ).toArray();

Those of a more Ruby-bent might prefer to_a() instead, but that feels a little too much like crossing the streams…

While I’m writing, (another) quick note on the state of this site… which basically comes down to the usual “I either seem to have the motivation to write, or the time, but never both at the same time”. I’m trying to change this, don’t hold your breath.

Briefly: detecting changed form inputs with jQuery

Thu, 14 Aug 2014 01:00:00 +0100

I was working on a project a few months back that required me to detect whether the user had changed the values of HTML form inputs, and prompt them suitably. After a little poking into the defaultValue, defaultSelected and defaultChecked DOM properties, I knocked together a quick jQuery selector.

It’s since worked its way into a number of other projects—this site included—so I thought I’d post it in case anyone is interested or has suggestions for improvements. Share and enjoy :)

( function( $ )
{
	/**
	 * Selector that returns form input elements that have been changed by the
	 * user since the page was uploaded.
	 *
	 * Example use:
	 *
	 *    $('form :input').filter(':changed').each(function() { … })
	 *
	 * @param   oEl     the element itself
	 * @param   index   the current loop index (unused)
	 * @param   meta    metadata about the selector (unused)
	 * @param   stack   a stack of the elements to loop (unused)
	 */
	$.expr[':'].changed = function( oEl, index, meta, stack )
	{
		// 0. drop out
		var sN = oEl.nodeName.toLowerCase();
		if ( ( sN !== 'input' ) && ( sN !== 'textarea' ) && ( sN !== 'select' ) )
		{
			return false;
		}
		if ( oEl.getAttribute( 'data-no-check' ) != null )
		{
			return false;
		}

		// 1. custom hook for SELECT boxes
		if ( sN == 'select' )
		{
			// a) iterate through all options. If one has changed, we've changed
			for ( var i = 0; i < oEl.options.length; i++ )
			{
				if ( oEl.options[i].defaultSelected != oEl.options[i].selected )
				{
					return true;
				}
			}

			// b. nothing has changed
			return false;
		}

		// 2. otherwise, for radios and checkboxen, use (default)checked
		var sType = oEl.getAttribute( 'type' );
		if (
			( sType !== null )
			&& ( ( sType.toLowerCase() == 'radio' )
				|| ( sType.toLowerCase() == 'checkbox' ) )
		)
		{
			return ( oEl.checked != oEl.defaultChecked );
		}

		// 3. everything else uses (default)value
		return ( oEl.defaultValue != oEl.value );
	};
} )( jQuery );

At some point, I’ll get around to making it play nice with Zepto as well: it’s not being picked up quite right at the moment…

Let’s talk about shoes

Sat, 09 Aug 2014 01:00:00 +0100

Nope, this isn’t a article about some exciting new framework or development methodology, I’d like to talk very briefly about footwear. In particular, the kind a shoemaker’s children are supposed to lack.

Because just over a year ago, I relaunched this site with an article where I talked about Getting On With It: relaunching my website, and filling it with useful if imperfect stuff.
I set up a wee whiteboard next my desk which rapidly filled with hastily-scribbled ideas for things I could write. I reinstalled PlainText on my iPad, hooked it up to my Dropbox account and created a nice directory structure into which I could dump articles. It felt good to be doing something.

… all of which explains exactly why it’s taken 366 days to actually publish the next article.

Whither art thou, motivation?

I’ve just caught myself “but if”-ing again… which gives me an idea for a new blog post, which I might even get around to writing #motivation

@jonpearse, June 25th 2014

My clients have kept me very busy over the past twelve months (for which I’m not complaining at all!) and during that time, I’ve worked on a decent variety of projects. They’ve ranged from the comfortably pedestrian to the really quite overwhelmingly huge and complex. It’s meant for a few very long (100+ hour) weeks here and there, but on the whole it’s been a pretty enjoyable experience.

There’s been much to write about, too, from abstract discussions of process and architecture through to the ten lines of Javascript I’d written earlier that day to solve a wee problem. A few projects have meant that I’ve been dogfooding a fair amount recently as well, which is always good when you want things to write about.

Or would be, except I’m not what one might call a natural writer. There are rare occasions where I can sit down and write, but for the most part, writing a decent non-rambling article that’s actually worth reading takes a lot of time and effort (it’s taken two hours to get this far through this article, for example).
And for all that I might have some really interesting ideas, often I don’t have the time to sit down for several hours at a bash, but more often than not, I lack the motivation to do so.

Oftentimes it leads towards the curse of ‘but if…’: periodically, I’ll tell myself that I need to write something, whatever that might be, and then start thinking things that start ‘but, if…’: I could write now, but if I go change something, or do something slightly different, or have a different tool, I’ll be able to write better…
… which, of course, is rarely the case.

Ironically, the conclusion to this is pretty much the same as the conclusion to my last post—stop procrastinating, start doing. Only it turns I like ‘doing’ development more than I like ‘doing’ writing about it.

Returning to the barefoot children

I’m not going to make any promises of any kind: I have two more posts lined up, one of which is mostly written, so there might be some activity here over the coming weeks. Whether or not I actually publish either of them, and whether or not I publish any more following those … remains to be seen

Whatever happens, when I’ve had time to spare over the past few months, I’ve been chipping away at this site in the background. For the most part the changes are fairly subtle, but they’re there.
In no particular order:

Browser support

Previously, whilst this site worked best in a modern browser, it paid enough lip service to older browsers that it mostly worked pretty well. The most recent update does away with this, so if you’re using an older browser (in particular, IE8 and older), you’re going to get a decidedly sub-optimal experience. I’d apologise, but it’d not be sincere…

A brief diet

The lack of having to support gronky old browsers means I’ve been able to slim everything down a little, in particular I’ve completely done away with modernizr, which whilst awesome, is almost entirely unneeded. There is still some capability detection going on, but it’s old-school “are you IE” stuff done on the server-side to deal with IE9’s lack of flexbox support.

I’ve also run the version of FontAwesome used on this site through the amazingly useful Fontello to remove the 380-some icons I’m not actually using. Along with a bit of CSS slimming here and there, pages are about 80–100K smaller than they used to be.

New functionality and tweaks

Due to ‘but, if…’-ing, the site now has both commenting (um, yay‽) and image galleries, both of which were blocking a couple of post ideas I’ve had.
I’ve also been around and generally improved things all over the place: notably, I’ve changed the heading font up a little, because whilst I like Lato, it does get a little bit too much after a while. Plus, a little more Karma is never a bad thing :D

I’ve also made a bunch of tweaks to the administration interface, but you’ll never see any of that…

Now 100% open-source

Actually, this isn’t anything especially new, but I saw Julie Ann Horvath talk at HybridConf last year about open source, and it inspired me to chuck the source code for this site up on github.
When it comes to it, I started off in this game hacking at other people’s code to see how it works—and in fact still do—so I figured it was kinda right that I allowed others to do the same.

If you’re curious, go take a look, and feel free to adapt/play/use as you see fit.

And now…

… well, we’ll see. Hopefully the next post won’t be quite so far away.

Enough pencil sharpening

Thu, 08 Aug 2013 01:00:00 +0100

I was tidying my flat the other day, and happened across my collection of posters taken from Ze Frank’s excellent “Invocation for Beginnings”.
If you’ve not watched it, go ahead—I’ll be here when you’re done.

As I flicked through them, one section in particular stood out:

There is no need to sharpen my pencils any more.
My pencils are sharp enough;
even the dull ones will make a mark

Whilst I usually come away from watching the video with a vague sense of “I gotta do something”, this time it stuck with me.

Back in the dim and distance past, I had a website: it wasn’t much, but it was somewhere I could write about whatever was on my mind at the time.

And write I did: over the several years and many forms in which the site existed, I frequently found myself writing. Sometimes it was commentary and reflection on world news, other times it would be odd bits of technical whimsy that took my fancy. Much of it, however, concerned the mundanities of a guy in his early 20s trying to find his way through life.
Very little of it was in any way edifying, and much of it will never see the light of day again, but I enjoyed it.

But my life changed—I graduated university and set about finding a job. Other things happening around the same time meant I found myself writing progressively less and less.
In addition, as time went by, some of the content on the site looked increasingly inappropriate in my new role as a professional developer.

In February 2006, after months of almost complete stagnation and little motivation to do anything further, I took the site offline completely.

I’d always planned to rebuild it: to spend time working on a new design, a better technical solution; to work on filling it with content that better suited my professional image.
If nothing else, I realised I missed writing: I was reading blogs and magazines, going to conferences, travelling, always learning. I saw things I wanted to write about, conversations I wanted to engage with, new tricks that I wanted to share, but I lacked the platform.

And there was always Something. Sometimes it was waiting for that ‘perfect’ design to coalesce in my head (I’m no designer), but most of the time it was a form of technical OCD—I wanted to build it on top of my pet project, which required my pet project to be at least reasonably complete.

Trouble was, it never was: I’d get 70% of the way through writing it before realising I was doing it Wrong, scratching it, and starting all over. It started life in 2007 as an overly-complex CMS, and had eventually transformed into only a slightly less-complex MVC framework (christened ‘jaspr’) by the time I finally killed it last year.
A great learning exercise, perhaps, but not one that was going to get me a website.

So what happened?

I’ve had enough.

To paraphrase Ze, it’s time to stop sharpening my pencils; to stop waiting for that perfect moment of zen-like inspiration when everything Just Makes Sense. It’s definitely time to stop trying to reinvent the wheel, especially when I’m trying to do so in PHP.

It’s time to just do it, to knock up a quick and dirty website and put it out there. Maybe it won’t be perfect, it almost certainly won’t be complete, but it’ll be a start.

If nothing else, I’ve been freelance for almost three years, and the lack of any form of professional web presence is starting to get embarrassing.

What now?

This site isn’t finished: in the short term, I want to add a portfolio section and turn it into a proper ‘professional’ web presence; hopefully raise my profile a little. I might even take a look at the design while I’m at it.

I’m going to write—I’m not going to guarantee any kind of regularity, but as the inspiration strikes, expect to see new articles popping up on here now and then.

But most importantly, I want to give back to the community: I’ve been in this game for nigh on 10 years, and in that time Google has been an invaluable part of my professional development. I wouldn’t be where I am today were it not for the thousands of blogs, magazine articles and Stack Overflow answers I’ve read over the years whilst learning new skills and puzzling over problems.

Now, it’s time to give back: it’s going to be fun.

And please god, let me enjoy this: life isn’t just a sequence of waiting for things to be done.

For the technically curious…

The site is a quick and dirty Rails app (I am a total convert: thanks Seb), which may or may not get totally replaced at some indeterminate time in the future, and is hosted on a Rackspace Cloud Server.

A note about browsers

I take a fairly pragmatic approach to browser support—whilst it’s nice if things look the same in all browsers, it’s not essential. My attitude is generally that as long a site is usable and doesn’t look too horrendous, that’s just fine.

As such, this site looks just fine in all decent browsers and IE9. If you’re using an older browser, you’ll notice things look a little less great, but you can still use the site just fine.
That everything doesn’t completely break in IE6+7 is a bonus and entirely unintentional.