I’ve been meaning to try the fork feature on Heroku for a while.
It does exactly what you expect, but that’s what’s so brilliant about it. It’s taken be less than 2 minutes to set up a staging environment for one of our apps in the EU region. Here’s what’s involved:
Clone an existing app, optionally choosing a region. This will also add your add-ons to the forked app at the same payment tier so keep an eye out for this.
heroku fork -a yourapp yourapp-staging --region eu
Creating fork yourapp-staging... done
Copying slug... done
Adding airbrake:developer... done
Adding memcachier:100... done
Adding scheduler:standard... done
Copying config vars... done
Fork complete, view it at http://yourapp-staging.herokuapp.com/
Get the forked app’s Git repo information so you can push code to it.
heroku info -a yourapp-staging
=== yourapp-staging
Addons: memcachier:dev
scheduler:standard
Git URL: git@heroku.com:yourapp-staging.git
Owner Email: nick@nickboyce.com
Region: eu
Stack: cedar
Tier: Legacy
Web URL: http://yourapp-staging.herokuapp.com/
Add a new git remote so you can push to the new app.
git remote add staging git@heroku.com:yourapp-staging.git
Push a branch to your new app.
git push staging custom-framing:master
You’re done!
Leave a comment
We recently did the WordPress work for the Art Everywhere project, and one of the requirements of the project was to include a Facebook like button for each artwork on the Choose Artworks page.
That page has around 100 artworks on it so immediately I heard alarm bells, until I remembered the Socialite plugin. This allows you to lazy-loading the Facebook buttons.
No matter what, we didn’t want all of those Facebook buttons to load at the same time, even if the rest of the page had already loaded, so we decided we would load them in on hover.
Initially we struggled to get this working how we wanted, as all the buttons would load when you hovered over any of the buttons. Finally Nick found the solution:
$(".artwork-info").hover(function () {
Socialite.load(this);
});
It turns out, all we had to do was pass this to the Socialite.load function. So, if ever you find yourself having to implement similar functionality, you know what to do.
Leave a comment
This week Adam Wiggins announced that he has stepped down as CTO of Heroku to pursue other opportunities.
At Easyart we’re big fans of Heroku (it’s used extensively for our new platform), and Adam’s general approach to modern web software design, so I thought it might be a good opportunity to review some of his nuggets of wisdom.
A manifesto for modern web software design and the principles. It’s clearly the concepts from which the Heroku ecosystem is formed, but the principles can be applied to any modern web application platform stack.
A few bits and pieces from this post:
Make it real. Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discussions around concrete examples, not handy-waving abstractions. Don’t say you did something, provide a URL that proves it.
Ship it. Nothing is real until it’s being used by a real user. This doesn’t mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Divide and conqueor. Big, hard problems become easy if you cut them into small pieces. How do you eat the elephant? One bite at a time. If a problems seems hard, think about how you can cut it into two smaller, easier problems. If one of those problems is still too hard, cut it in half again.
Throw things away. It’s not the code that is valuable, it’s the understanding you’ve gained from building it.
Decision-making via ownership, not consensus or authority. Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is “the buck stops here” and makes the final call on what happens with the owned thing.
It will be interesting to see what he turns his hand to next.
Leave a comment
I was interested to see jsonapi.org spring up on the web recently. Though it’s authored by Ember’s team, the references to Ember have been moved from the homepage to the history section, and it’s clear that the ambition is to set a standard for API compatibility between servers and clients.
Overall I applaud the ambition and it’s clearly written by clever people. That said, I believe consuming the proposed data structures is more complicated unless you’re using a compatible library.
Consider these examples…
If the value of a resource key is a JSON object, the value represents a single document.
If the value of a resource key is a JSON array, the value represents a list of documents.
Isn’t it better to have the URL scheme define if you are looking at a document or collection? i.e. GET /resource is a collection and GET /resource/document is a document?
To save HTTP requests, it may be convenient to send related documents along with the requested documents.
For example:
{
"posts": [{
"id": "1",
"title": "Rails is Omakase",
"rels": {
"author": 9
}
}],
"people": [{
"id": "9",
"name": "@d2h"
}]
}
So to list the post title and author name would be something like (pseudo code):
{posts.each (post)}
{post.title} by {people.where(id: post.rels.author).name}
{end}
Now, that’s pseudo-code, and in reality it would depend on what language or framework you are using as to how easy that “where” statement is. It’s definitely going to be a lot more complicated than my example to do it in vanilla JavaScript. I’d suggest that nesting the documents is much easier:
{
"posts": [{
"id": "1",
"title": "Rails is Omakase",
"author": {
"id": "9",
"name": "@d2h"
}
}]
}
And it can be consumed like this:
{posts.each (post)}
{post.title} by {post.author.name}
{end}
Yes, it’s imperfect and can result in more duplication and less flexibility, but I think for a lot of cases that isn’t an issue.
Leave a comment
Last week I attended Industry, organised by Gavin Elliott. I must say Gavin did a great job and it was a great conference. Here are my notes from the talks:
Rachel Andrew - “All of a sudden… no luck!” Things we have learned while supporting Perch.
Slides
There were some good points this talk, such as how email doesn’t scale well for support and how important it is to add features that benefit the majority of your customers, not the noisy minority. Also, Rachel described how engagement with customers makes it easier to determine what you should be doing. Essentially, customer support is your best source of market research.
This led me to think that as well as user testing, we should be engaging more with our customer services team to determine where we can improve things for our customers.
Harry Roberts - Architecting scalable CSS
Slides
I was looking forward to this talk as I am in the early stages of putting together the CSS for our new platform. Harry addressed a lot of things I have been thinking about recently.
He talked about breaking code into the smallest possible blocks, and how each block should do one thing well. Blocks can then be combined if needed. A great methodology for this is BEM which stands for Block-Element-Modifier. I also liked the idea of a shame.css file for hacks and quick fixes.
Christopher Murphy - We are navigators
This talk focused on the importance of education in the industry and how important our mentors can be.
Ashley Baxter - Changing a stagnant industry
I wasn’t really sure what to expect from this talk, and it was hard to believe this was Ashley’s first time speaking at a conference.
Ashley clearly has a lot of drive and has achieved some amazing things purely because she is passionate about what she does. I guess the main take away from this is not to let anything stand in your way and if you don’t like the way something is, don’t complain about it, make it better.
Noah Stokes - $50'000 mistakes
Noah has had quite an impressive career, working at Apple and also turning down job offers from the likes of Google, but it hasn’t all been a smooth ride. His story shows that with hard work and dedication, you can achieve anything.
Rasika Krishna - Cross-cultural UX
I’ve had my fair share of working on sites for other cultures. I’ve worked on Arabic, Chinese and Russian sites before and at Easyart we have French, German and Swedish sites as well as our UK ones, but it was really interesting to hear about how different other cultures can be.
I couldn’t agree more with Rasika’s point about it not being enough just running some text through Google Translate or switching the text-direction. I was also surprised to learn that in Malaysia, you need Government sign-off before launching a website.
Josh Brewer - Redesigning Twitter
Josh talked us through the most recent redesign of Twitter and the challenges they faced. There were a few takeaways from this talk, such as the importance of scaling features to meet a deadline, iterating in code early on in the design process and using version control for your PSD’s for collaboration (for this Josh recommended SVN as it handles binary files better than Git).
Jeremy Keith - What we talk about when we talk about the web
Jeremy raised some great points in this talk, some of which we really shouldn’t need to be told anymore, but it was a great overview of how the web works and what we can do to make it better.
The idea that the web is its own medium resounded with me, and that we should not be trying to replicate print. Jeremy also reminded us all about progressive enhancement and how it does not mean designing for the lowest common denominator. The principles behind progressive enhancement and mobile-first go hand-in-hand.
Leave a comment