CMS Supermondays

Starting with a plethora of upcoming events (*cough* Maker Faire is looking for volunteers) and a plea for more hands on deck to help, Supermondays kicked off its foray into CMSes (and one “anti-CMS”, Jekyll).

PyroCMS: Jamie Hurst

Jamie Hurst spoke about PHP framework PyroCMS. It’s been available for a few years “but only really usable for 2″. Interesting, like Drupal , it’s changing its codebase: it was on CodeIgniter, but is changing to Laravel. Like Joomla or other enterprise CMESes, there’s a Community version (on Github) and a Professional one (though at £90 per site as a one-off payments, it’s one of the cheaper options).

Hurst uses PyroCMS because of the opportunities to customise it (Plugins (like WordPress shortcodes); Widgets, and Modules).

I started looking around the web, and Zac Vineyard of Tutsplus also lauds its ability to be customised out of the box:

building a theme in PyroCMS is easier than it is to do in WordPress and other systems, which leads to time savings. At the core of how PyroCMS outputs data is the Lex tag parser. For designers and front-end developers, tags are a simple syntax to display content and perform basic logic operations. For developers, tags are the way in which you can get your data into layouts.

WordPress WTF: Adam Onishi

Adam Onishi braved coming up from London to talk. As it turns out, he was one of the people behind 12 devs of Christmas!

He pointed out some of the headscratching elements of WordPress (the_post doesn’t really show a post, show_search_form doesn’t show a search form, there are IDs *everywhere* in the code), and lamented the pretty but not entirely functional admin bar (he wishes that we could use Markdown like Ghost and even uses the Markdown on Save Improved plugin for his own blogging, and watches the WP Clarity initiative with interest, but realises this is a hard sell for content editors that are used to using Word). He also points out that Squarespace has nailed working with content.

And despite all the little quirks, Onishi loves how it’s open source (it’s even on Git now), and the community, from the Codex to the Wordcamps where you can even end up talking to Matt Wullenberg.

CMS Horror Stories: and How to Deal with Them

Pete Duncanson had the audience nodding in grim acknowledgement talking about some of the client issues from pink text to instant updates, to his experiences using Umbraco: “I know it’s .net but don’t hate me”.

I particularly liked his idea under the topic of restriction of letting clients select CSS style (e.g. “tweet button”) rather than faking it up themselves or “you telling them ‘open Notepad, copy that text…which they then spend the next few weeks emailing you about as they’ve lost the file”.

His idea of prempting in CMSes (icons etc) was similar to Alan Cooper’s idea of considerate software.

Finally, his idea of being bendy is allowing for change and scaling (i.e. not listening to them when they say that they’ll only ever have 10 staff and so won’t need subfolders or paging).

Drupal Myths and Legends

Adam Hill talked about some of the misconceptions (and not so misconceptions) of Drupal. He admitted some are based in truth: the theme does look like crap out of the box (and in itself is a vast improvement on the Drupal 6 default), but it can be configured to look at what you want.

While the UX out of the box does have some holes,it can be configured to be better (e.g. configuring the back end UI and making content editing smarter).

Issues of security and not working on cheap hosting are grossly overrated, given that whitehouse.gov runs on it and I run multiple sites on cheap-ish Hostgator shared servers.

The stories of scary learning curves is true, as is the slightly dodgy version control system (at present, until Drupal 8 at least), but there are dedicated teams both for security and learning.

By the way, I wish Adam had been brave enough to use the famed Drupal (and other CMSes) learning curve cartoon:

CMS Learning Curve

Here there be dragons. Or template.php .

The Emperor CMS Has No Clothes

Philip Poots was the voice of dissent in the room as he talked about Jekyll. While I’m reminded that a number of developers have a post on moving to Jeykll as their last post (i.e. it’s a bit of a pain to update for blogging), Poots pointed out that a number of prominent sites use the system for its simplicity and speed: it first came to prominence when it was used for the Obama campaign, and is currently used in sites as the Hawaii.gov site, Sage One Help, and the latest Thinking Digital site (which took 2 hrs to put up as opposed to a CMS quote of a week).

I also learned a new term: ‘stynamic‘, a portmanteau of ‘static’ and ‘dynamic’ that appears to have been coined by the Hawaii.gov team. Of course it’s as clunky and potentially cringey as any of these types of phrase, but it is worthwhile in reminding devs and others that there is a half way between the good ol’ static sites and dynamic CMSes.

Echoing earlier discussions in the night, Poots admitted that for all of the potential uses for Jekyll, the biggest area where it falls down is Markdown …and particularly getting marketers to use it. He admits its an issue, but demoed a possible solution: an HTML to markdown solution that for someone looks for anything like Word, but is actually working in Markdown.

Common Themes

Above all, I was struck at how many CMSes are in a state of transition at present, to the point that they might become unrecognisable to the original members of their respective communities. For example, PyroCMS is ditching CodeIgniter—the framework that seems to have drawn many people to it in the first place—for Laravel, Drupal is dramatically changing its codebase and building more things to the initial install to be more like WordPress, and WordPress is becoming more CMS-like …to be more like Drupal. However, as Pete Duncanson pointed out later, having other systems to compare from is a good thing: he’s installed WordPress on sites and then gleaned lots of good ideas to add as feature requests for Umbraco.

The other aspects that came through were the ideas of community and experience. Pretty much all of the CMSes talked about had strong communities for help. However, as Adam Hill pointed out later, in the cases of communities such as Drupal, being a long term member of the community helps you know about how to engage with the community, be it knowing which modules are good, or even knowing how to read the modules sections (e.g. you probably don’t want to download a module that’s old and/or has hardly any downloads, and you should probably have a look at the issues queue to see if there are serious problems).

Super Mondays: Lightning Talks

It was a lot of talks on offer for this month’s Super Mondays, ranging from being a design student to creating your own automated lighting system. What came through loud and clear though was the dedication that the speakers had to their crafts (be they day jobs or insane hobbies). The level of cross-fertilisation was also apparent as speakers noted that they had given the talks at different user groups or even locations (hi, Refresh Teeside!)

Rails Girls

Fiona McDonald

Not many in the audience had heard of Rails Girls, much to Fiona McDonald’s surprise, as she’d done a local talk at a local Rails User Group not that long ago! So apparently there’s not much overlap between audiences. She talked about the Rails Girls initiative, a series of events which started in 2010 in Finland as has now taken place across the world.

As much as she’s aware of the arguments as to whether there should be female-only tech events, McDonald was impressed at how the women/girls were able to go in knowing nothing about Rails and come out two days later (the events happen over a weekend) having coded an app, using such helper tools as Bento Box.

I’m not entirely sure if I should detail all the benefits of why it’s worth getting involved (OK, a couple of the male mentors started relationships with the girls involved—and are still together today), but McDonald pointed out that we should be doing all we can to get diversity in the rails and more general tech community (she was happy that this wasn’t one of the events where she was the only girl in the room. Oh how I know that feeling).

Code Club

Kamran Chohdry

In a perfect segue from a question to McDonald about getting to girls in schools about coding, Kamran Chohdry spoke about Code Club (yet another person talking about what they do in their spare time).

Code Club has exploded as of late. Its aim is simple: to teach coding to children in primary schools age 9-11—before IT is actually taught in schools—and “get them beyond Microsoft office”. They’re taught Scratch, Hard Scratch, HTML/CSS, and basic Python respectively over the course of a year.

The Club are looking for devs who can volunteer. This involves committing to an hour a week (in the computer lab), a CRB check (the school will usually help—and it was pointed out by an audience member that STEMNET can help you do it for free), and potentially help set up the labs with Scratch or Python. It’s also worth asking as a parent/guardian if there’s a school or Running Club nearby.

As it turned out, an audience member’s son has used a Code Club programme, won a Rasberry Pi and is now planning to become a games developer!

And apparently this is the start of a wider sea change—programming is going to be taught from age 5 up, but there isn’t necessarily the capability in schools in order to teach it.

Git, Bitcoin & Matroyoshka Dolls

Chris Price

“Who uses Git? That’s a change from a few years ago.” There weren’t quite so many that used Bitcoin, or even knew what matroyoshka dolls were (until someone else called them Russian Dolls) but never mind.

His analogy was brilliant: the concept of nesting dolls is how potentially catastrophic changes (changing values in Bitcoin, commit changes in Github) are protected in their systems. Doug Belshaw also pointed the audience to check out trybtc.com to mess around with bitcoins.

From Student to Work

David Ingledow

“Use Github”. More generally, the key theme of David Ingledow’s talk was about how students need to not only capture but share the ideas (and code) they generate. Not that Github or Git was taught at uni. Still, in his discussion of transitioning from being a interaction design student (at Northumbria, yay) to a working designer at a startup, he reflected on after all of the collaboration, preparation, and late nights, it was all too easy for graduates to let their work die post grad show. And that was a pity.

On another note, I was interested to hear what it was like for a designer to move from uni to a startup. Ingledow loves it, thanks to the ‘all hands on deck’ attitude that is needed. Given the growing startup community in the NE, it could well be that more and more grads end up in a similar role as him. Hopefully they learn Git first.

Switching to Jekyll

Dan Richardson

Going from a former student to one that is still one (but did a summer placement), Dan Richardson discussed moving to the static generator Jekyll. Most people have heard about it in dev world (and that it’s based in Markdown), if you’ve used Shopify you’d have used the liquid HTML system.

The lack of database can have issues e.g. you need to use third party plugins like Disqus or Salesforce for comments and forms, and it’s obviously not great for things like GUI text additions. Still, it has a lot of potential, particularly when you can host a small site for free on Github Pages or very cheaply on Amazon AWS.

Some other options are Octopress and Nanoc.

The related blog post is available on the Canddi website and an audience member mentioned the 2010 post by Paul Stamatiou on moving from WordPress to Jekyll.

So much to learn

Ben Cooper

How do you keep going in a world of continuous innovation and Smashing Magazine articles? Ben Cooper (who emphatically calls himself stupid but I suspect the audience would disagree) gave some of his comments from his years of experience. He asked the audience to focus and continually think of your core skills (that old ‘jack of all trades’ mantra) rather than running frantically to learn frameworks and libraries that you don’t need and don’t understand the core code.

I personally don’t entirely agree with discarding superfluous frameworks. However, I do think that it does require an understanding of what you’re doing: e.g. playing with new languages is more of a sense of awareness or seeing if something is a ‘gateway drug’ to a new type of coding. Still, his call to avoid heedlessly following trends is savvy even in other areas such as design trends (flat design anyone?).

When it comes to actually being part of the community, Cooper took the opposite track and regaled people to share (blog/speak) and be enthusiastic: “passion trumps being smart”. Oh, and to to not rise to the trolls. (“Stackoverflow, I’m looking at you.”) In this respect, he reminded me of Wil Wheaton’s mantra “don’t be a dick” and the concept of having “strong ideas held weakly” (a trait that has often been attributed to experience design luminary Don Norman). Again, his concept of having focus or doing things your own way came through: he uses twitter but just as an RSS. Which is fine. But I love using it to share and help.

Home Automation

Steve Jenkins

“Why did I do this? Because I can. Because it’s cool”. With no real logical justification to make a “smart” lighting system (it’s inefficient in all ways) but a burning desire to do it anyway, Steve Jenkins set about buying a Lightwave RF (“It was available from B&Q”) and attempting to make a system to make sense of it. Luckily, he applied for and got access to the API, but it’s still very much a work in progress… and then went down a rabbit hole of ideas and various platforms and roundtripping.

Still, apparently Geofence works reasonably well (“though when my phone comes out of Airplane Mode every morning it gets confused”).

He’s keen to see what happens with SmartThings though. He looked at Lockitron “but I figured I’d wait and upgrade my house”. John McClaire did a similar project on Kickstarter.

The hours and time to date? About 2 days spread out over time (though “with very hacky code”) and about £400. And counting….

Has it made a difference? “Well, it’s made me more lazy”.

Of course, there are questions about proprietary software: there’s a horror story of a guy in IBM replicating his house in Second Life only for Japanese and American people to turn his lights off and on at 4am! He’s used his own server and the like so thinks he’s safe—and it’s only lights— though he dis ask people to “please don’t hack my house”.

If that doesn’t put people off doing it, they were directed to have a chat to Alistair and the local Maker Space….

The Trials and Tribulations of WYSIWYG Editors

Kerry Gallagher

“You’ve all used WYSIWYG editor. They’re mainly a joke right?” With that , Kerry Gallagher dissected a commonly hated aspect of CMS and HTML development. For those of use who have never actually rolled their own editor (me!), it was interesting to see what goes on behind it.

It turns out that editing comes down to one element: ‘contentiseditable’: which is surprisingly supported back to IE5.5!

Of course, it’s not that easy: there are some bugs between browsers, particularly with undo and redo (though there are changes to standardisation).

Mozilla’s Educational initiatives

Doug Belshaw (slides)

Wrapping up the night was Doug Belshaw of Mozilla. His first slide began with a werewolf picture from Mozfest. (Wait, is it a full moon out tonight?)

He spoke about three Mozilla Webmaker initiatives.

The Webmaker project is a fun project aiming to get people (particularly children) involved with making with the web rather than just consuming with it. The projects (X-Ray Goggles, Thimble, and Popcorn Maker) are fun and a subtle gateway drug into coding. I was involved with mentoring with these projects at the recent Maker Party here in Newcastle, see my notes of the day for more on the topic.

Belshaw’s pet project in Mozilla though is web digital literacy (which isn’t surprising, given he did a PhD thesis on the topic!). There are three competencies—exploring, building, and connecting—which Mozilla and the wider community are focusing on.

Finally, Mozilla are also pushing the concept of Open Badges (a means of showing learning and accreditation in a diffused way). The project is relatively mature with buy in from Disney amongst others.

And they’ll all be showcased at Mozfest (27-29 October in London).

Thoughts

There’s an argument that put enough of anything together and you’ll see a pattern (certainly Damian Hurst’s dotted pictures played on this conceit). Still, over the series of nine talks, I noticed an ongoing trend:

  • The need to evangelise, and the wider community support that this entails. There were no less than three talks about learning and teaching. Of these, McDonald’s struck me the most as she mentioned the struggle of pushing something forward such as teaching girls Ruby whilst holding down a full time job. (In fact, she wasn’t able to launch the event herself as she was moving to Barcelona). I wonder whether there does have to be organisational recognition for mentoring and furthering diversity. Should companies be enabling and even expecting their employees to further the tech community?
  • The importance of sharing. A few speakers touched on this, or demonstrated it: certainly Jenkins’ talk on home automation led to more than one glint in people’s eyes. It also reminds me of how people always know something or know about something more than someone else (again, a mentoring principle in that unless you’re an absolute beginner, there’s someone less experienced than you that you could help).
  • The cool stuff that’s going on. OK, that’s pretty obvious every month, but still.

Speedy Mondays (Super Mondays July 2013)

To be honest, the mood at the Beehive at Newcastle University was anything but speedy, as the region basked in the ongoing heatwave. Regardless, the July Supermondays had a need for speed, from optimisation to psychology. There was also mention of a new usergroup (JSNortheast, meeting the first Monday of every month).

Richard Powell: Speed and Front End Development

Richard Powell gave a three-prong attack for considering speed in development: load time, perception of speed, and back end development. Of these, load time is the most important: apparently 80-90% of website load time is on the front end. (Even tumblr doesn’t get this right).

Much like Stephen Jones at a recent WP meetup, he recommended optimising and minifying files (for CSS using sprites/icon fonts/base 64 encoding, and concatenating JS and CSS files), obfuscating (JS variables), gzip txt files (70% file reduction). He also discussed being defensive about plugins (e.g. rather than using a tap navigation plugin, it could be done in 3-4 lines of code) loading JS last (even with Async, it doesn’t always work), and using lazy loading. And think about coding efficiently!

In regards to runtime, his analogy for DOM Interaction was memorable: “think of it like taking the dog for a walk and it making a mess: you have to touch it, but you don’t really want to.”

He pointed out that CSS positioning can be expensive: opacity, transforms, and surprisingly static positioning (browser has to recalculate on each load). One nice way to stop something being slow is to give it a rotate position of 0 (it gives it its own engine).

He gave a plea for API devs to think about how they serve up the content, and also not send people off on a wild goose chase to other files for more info.

He made notes in relation to perception (a theme carried on in the following talk): a site with progressive loading feels faster than one without, and to not block the API.

Out of the three, he emphasised the need for load time most (which requires collaboration).

Not sure if loading or…

Slide of the night.

Finally, he points out that it’s worth thinking about the tools we can use for testing: Chrome Dev Tools are good, and sites such as JSLint that let you compare code.

Graham Morely: the Psychology of Speed

Being in a car can be fast, but nothing feels quite so fast as being in a go-kart careening down a hill. Morely focused on how web designers and developers can make a site feel faster.

As it turns out, the speed of a site can have serious business impact. Examples Morely cited included Amazon tests that 100ms of extra load time=1% drop of sales, a page on Yahoo being 400ms slower causing 3-9% increase ‘black clicks’, and Mozilla getting 60m more downloads by increasing speed of download on their page for IE (and conversely the cost of 1s delay: 7% conversions, 11% page views , 16% decrease satisfaction).

Interestingly, speed isn’t always important: ATMs that dispensed money too quickly weren’t trusted.

He quoted Souders’ rule that  satisfaction = perception – expectations and used it as a guideline for work: people are happier with a site that feels faster than they’d expect it to. That said this can be done with information tricks e.g. if you’re in a search sites: going beyond “search hotels” to “search 52,420 hotels” with a loader looks faster.

He cited Neilsen’s studies on page times (though noting they’re perhaps 10 years old):

  • 0.1-0.2s =  instantaneous
  • 0.5-1s = immediate
  • 2-5s = flow, as it takes about 2s for a person to turn a page and find their position.
  • 7-10s (has to be) captivating

You should only spend 10s or more if it’s a natural break in user flow (you may wish to have alternate solutions such as let the user leave the page and email them when the task is done).

He helpfully gave a number of resources to investigate:

Mobile design guru Luke Wobrewski has also just written about perception of speed on mobile.

Oli Wood: Optimising Canddi

Oli Wood spoke from a recent project (Canddi) and his trials and tribulations attempting to optimise it. Above all, his key messages were to measure for what’s important (for them is how many inbound customer requests can be processed) and to just attach it (“Back of a fag packet calculations can be good enough”).

There are no silver bullets (they got expensive machines, hosting, PHP-FDM, all sorts of things, none really worked)

… aim for a silver shotgun cartridge (lots of little small things that can be nailed).

There are no silver bullets… aim for a silver shotgun cartridge.

More practically, he pointed out the importance of testing somewhere not live (as the team use AWS, they can clone and get a ‘good enough’ results) and to use realistic data (get enough on the test site to be good enough, no more) with defined test scenarios.

Build a pipeline view (find where the bottlenecks are).

Identify symptoms (what you can see) but solve problems (your 100% CPU usage could be that you need more machines, or just that you write crappy code).

Do less big things less often (doing big commands only when you have to).

Do frequent things much faster, avoid waiting, pull less data (“who writes MySQL? Who writes SELECT *?”). Hunt for collisions

Cache the painful thing: in memory (can be very effective, even in PHP), with tools such as redis (“almost one-click install, insanely quick”)/memcache (may be slightly better as it spreads across machine), url/browser cache

Use the tools:

  • Ab (“install with one command on Apache, and does a quick and dirty hit”. It’s useful for testing in background) +  Seige (far more detailed in regards to flags which can help to pinpoint where breakpoints are) and EC2 instances. “Install 2 or 3 ubuntu boxes, add EC2 on them and then test”
  • Use iostat (will tell you pretty much everything) or sar (-p is also very useful as it can tell you how busy multiple machines are), strace (“terrifies the life out of me” as it tells you what happens inside the processor “run it, get the text file, google the crap out of it”), iftop (for networks), xdebug + webgrind (don’t run on a live server!) as well as mongo tools such as mongosniff (‘terrifying, powerful, but go to google groups for it’. nginx is faster than apache (sadly)
  • They were on PHP, then moved to nodejs and with regis (if you can get it)

Your aim is to create a loosely coupled components which are horizontally scalable to make the business work (much like the 80/20 rule, beyond a certain point, “it just turns into geekery”). They managed to get the site 10x faster.

Elixr: Paul Callaghan

Paul Callaghan discussed Elixr, a new programming language that runs off Erlang. It’s still in its early stages but has been adopted by Soundcloud amongst other companies, and looks to be to ruby programmers what Coffeescript is for python devs. He pointed out a few useful concepts from the language such as creating a pipeline (a series of actions that can then be tracked in various places).

 Stefan Dantchev: Birthday Attack when randomisation probably helps

The night finished with high stakes of cryptography breaking. Well not quite. Dantchev’s examples were more theory than practical, but an interesting exploration of what we need to be aware of when it comes to code breaking and hashes. He used The Birthday Attack scenario—given a room of people, who many need to be there before it’s likely two share a birthday?—as a means of showing how this works, namely that you use a recursive (factorial) function of the likelihood of it not happening to figure it out. (For birthdays, that number therefore comes up as 23 people, at which point it’s just under 50%).