Launching my Patreon page

In June, I launched IWantTo.Support, a website dedicated to displaying people and projects that you can support. Not just by helping them, but also financially. For a long time I've been thinking about this. While helping a project or developer by coding, documenting or promoting, it sometimes is actually nice to help them by buying them a beer, book or something else they want.

Now I am at a lot of conferences, so every once in a while I can buy someone a beer. I've also on occasion purchased something off an Amazon wishlist to show my appreciation. But not a lot of projects and developers actually allow simply donating some money. I think more people should give the opportunity of donating some money.

Earlier this year I got introduced to the concept of Patreon, which is used mostly by artists (yes, it was through Amanda Palmer that I found out about it). From the moment I heard by it I was intrigued by the approach they take to payments for content and I started wondering out loud if we could somehow use the concept for open source contributors.

So can we?

Yes, we can. And actually, Rafael already did. You can (and should) support him. His approach is one of monthly payments. Every month, you donate an amount in appreciation of his work for the open source community, which includes the hours he puts into usergroups but also the work he does on Pronto!, which is clearly mostly for (aspiring) speakers, but still takes quite some time.

The other approach you can take on Patreon is one where you pay per "thing". This makes a lot of sense for open source projects: They could charge people for each release, for instance. And Patreon protects you as supporter against projects that do a lot of releases, because you can choose a maximum amount of money you spend on a project per month. And of course, the project could simply limit the amount of releases that they charge for. This approach would be perfect for libraries, frameworks but also applications. I would happily support some of the projects I've been using in the past years in this way.

My Patreon

I have also chosen this second approach for my Patreon page. Since I don't release a lot of code, I can't really charge per release of my code. One thing I do on a (sort of) regular basis though is to write blogposts. Whether it is here, on the DWA site or elsewhere, I do write regularly. And while these articles are released for free, it is something people could support. It is an experiment, I have no idea if this will be successful and if it will be, how successful it will be, but let's hope it will work.

I've also added some rewards! When you start with a single dollar, you'll get an e-mail from me. If you donate more than $25 per thing, I will do a brainstorm session over skype or hangout on any PHP-related topic. If you donate over $30, I'll also send you some actual snailmail stuff like a postcard, perhaps some stickers or anything else I might have lying around. Again, it's all an experiment. I'm also very much open to any suggestions you might have to improve the rewards, so do let me know if you have any ideas about this.

Recurring support too much?

If recurring support for the same person (in this case: me) is too much (I can understand that) but you want to do a one-off donation, that is possible too. I've added an about page that contains a link where you can donate.

Accept donations

So, now that Rafael has taken the step to accept donations and I have taken the step to accept donations, will you? I would love it if more people would take the step of accepting donations, either one-off or recurring. Even if you only get a single donation. Even if you get no donation. If you don't try, you won't get anything anyway.

Migrating Octopress to Sculpin

Just over a week ago I wanted to publish my previous blogpost, only to find out that the Gist plugin I was using for the code samples didn't work anymore. Some research showed me that the something changed in the way the Gist API worked that warranted an upgrade of the plugin. So I thought I'd quickly update the plugin to make it work again. Instead, I completely broke my Octopress install. Any attempts to revive it failed big time, partially because of my lack of knowledge regarding Ruby and the gem system.

I considered my options. I don't know much about Ruby or gem, so digging into that, while it would teach me something, would take quite a while. Then of course, I've done some work with Bolt recently, so I could migrate to that. That would still be quite a bit of work because Bolt would have to use a database. Given my recent adventure with Sculpin and the fact that Sculpin out of the box nearly supports the format Octopress is using, I decided to migrate to Sculpin instead.

The migrating to Sculpin was actually nearly painless. There were a couple of small issues I ran into, and I'm documenting them here for anyone else attempting to do the same thing.

Twig code snippets

Since Sculpin is actually using Twig templating engine to generate the pages, having Twig code snippets in your blogposts is going to cause some issues. I solved that by adding the verbatim Twig-tag around the code samples, inside the triple-backtick codeblock seperator. I did look into installing the codeblock plugin, but decided in the end that it was overkill for what I was trying to do.


In Octopress I specified categories as a space-seperated list in my header. So it looked like this:

categories: php octopress sculpin

Unfortunately Sculpin did not understand this syntax. Instead, it wanted me to give a yaml-like list:

  - php
  - octopress
  - sculpin

Although this looked like a small change, because I have my full blog archive since 2004 on this site, I had to update all these. For a bit I considered automating this change, but I decided against that and simply went through all of the old articles to update this. Not the most fun job, but it actually made me realize the amount of stuff that is in here. It was fun reading back some of my old blogposts and realize how much I have learned since those days.

There may be other problems

There may of course be other problems with the migration if you're using other options in Octopress that I wasn't using. And as you can see, at the time of writing this, I haven't actually applied a theme yet to the new Sculpin installation. This is something I still need to work on. For now: It works, I can blog again. Yay for Sculpin!

Creating a Bolt theme from a template

A friend recently asked me if I could make a simple website for the new radiostation he was joining as a DJ. My usual job is big applications and web projects, so (while this may sound weird) a simple website is actually something I'm not that efficient in, but since finding Bolt I actually do that every once in a while. Setting up and configuring Bolt is such a simple task that I've been happily creating some simple websites for friends or contributing to website projects every once in a while.

My main weak point is frontend and design. This is something I have been painfully aware of for ages already. Luckily there are sites like TemplateMonster and Open Source Web Design that offer templates that can be used for websites where there is no dedicated designer/frontender, nor budget for one. After a quick talk with my friend there was some budget to get a paid template from TemplateMonster, but now this template needed to be applied to the Bolt installation I had set up and configured with the required contenttypes.

The thing with Bolt is: It's actually quite easy to create themes. One of the reasons is the fact that they use Twig as a template engine, but on top of that they've added some pretty nice and useful extensions. So, let me walk you through the steps I took to create the theme for this specific site, which is my usual workflow for creating a Bolt theme.

The directory structure

Bolt's themes can be found in the /theme folder, which is quite obvious. By default, Bolt comes with two standard themes: default and base-2014. These are very helpful, because they give you a good idea of the structure and approach you can take in creating the templates. But since it's Twig anyway, if you want to use another approach, that's not that hard.

To create a new theme, you create a new directory in the theme directory with a name that represents your theme. In my case, I created the directory /theme/atlantis.


Next up: Assets. Any stylesheets, javascripts and images can be put into the newly created directory. You could put them somewhere else, but it's obviously easier to keep it all in the same directory, especially since Bolt has some additional variables available in the templates such as paths.theme, which you can use in your templates to refer to the base theme directory (we'll talk about that later). I took the js, css and images directories from the design I purchased and put them in /theme/atlantis directory.

Switching the active theme

Another thing I need to do is to switch the active theme before I can actually test my work. For this, I need to open the app/config/config.yml file and update the theme value:

    theme: atlantis

Now Bolt will look for the template files in my theme/atlantis directory.

Breaking up the design

In most websites, every page consists of several parts. Some parts are very specific to the page you're viewing, others are shared throughout the site. For instance, the header and footer, sometimes also the sidebar. In this case, the header and footer are used throughout the site (except for the homepage), and only the middle part is different for different pages. So the first thing I needed to do was identify which parts of the HTML could be shared and put them into different template files. Luckily, the template I purchased was well documented and easily marked the "cut lines" for the header and footer. Pretty quickly, I had a _header.twig file and a _footer.twig file.

As usual, the header contains a lot of links to css files and javascript files. As I mentioned before, Bolt adds some useful variables to your templates that can be used to make sure the URLs you use are always correct. Imagine your template being renamed, or put into a subdirectory when you go live, if you use hardcoded URLs such as /theme/atlantis/js/jquery.js, this won't work anymore when the site is being deployed on production into /radio. Bolt's paths variable comes to the rescue.

So I went through the header to create relative paths for this. Just to give you an idea, this is part of the header now:

    <link rel="icon" href="{{ paths.theme }}/images/favicon.ico" type="image/x-icon">
    <link rel="stylesheet" href="{{ paths.theme }}/css/grid.css">
    <link rel="stylesheet" href="{{ paths.theme }}/css/owl.carousel.css"/>
    <link rel="stylesheet" href="{{ paths.theme }}/css/style.css">
    <script src="{{ paths.theme }}/js/jquery.js"></script>
    <script src="{{ paths.theme }}/js/jquery-migrate-1.2.1.js"></script>

For any images that are part of the theme, I did the same thing. I did this for the header and the footer (though the latter contained only two paths that I needed to update, so that was quite simple).

The main pages

The header and footer parts of the template are the same for each of the different templates that the purchased design defined, with the exception of the homepage (we'll get back to the homepage later). However, the content parts were different. That makes sense, because a DJ listing simply looks different from a news section. So from the HTML files I got with the purchased template, I took everything between the header and footer markers and pasted that into a new file. For instance for the DJ section, I created a new file called djs.twig for the listing and dj.twig for the detail page. Now, however, I'm not done yet, because I don't have the header and footer yet. Luckily, we can use Twig's include functionality for that. So at the top, I added:

    {% include "_header.twig" %}

And at the bottom, the predictable:

    {% include "_footer.twig" %}

In the contenttype configuration in app/config/contenttypes.yml, I can now point Bolt to these new templates and make Bolt use those for the dj contenttype, by specifying the templates:

    record_template: dj.twig
    listing_template: djs.twig

Now when I load up the djs page on http://localhost:8080/radio/djs (I use the built-in webserver of PHP to run this website locally using the following command: php -S localhost:8080 -t .), I get the page I just created. However, there is no dynamic content yet in my listing page, because I haven't actually created the dynamic content. It's the just default listing that the HTML file contained. Let's work on that next.

Dynamic content

In the static HTML of the djs.twig, I identified the snippet of HTML that I needed to repeat for each of the DJ's. It was a pretty simple piece of HTML. I quickly filled it with the placeholders for the content that should go in there, which resulted in the following snippet:

    <div class="grid_3">
            <div class="event">
                <img src="{{ thumbnail(dj.image, 270, 170) }}" alt="{{ }}"/>
                <h6 class="color_2">
                    <a href="{{ }}">{{ }}</a>
                <p>{{ dj.teaser }}</p>

In a Bolt listing page, the records in the database for the specified content type are always available in a variable called records. So surrounding the above snippet is a simple for-loop:

    {% for dj in records %}
        // snippet
    {% endfor %}

Now it actually works, and I get content from the database instead of the static HTML that I had. Yay!

For the record-page which shows the individual DJ (when they click on the name in the listing), I now have to do a similar thing. This page contains a record variable instead of a records variable, which is just a single record, so I don't need a for loop, but the process of making it dynamic is similar as above.

More dynamic content

When you look at the bottom of the DJ listing you'll notice two blocks of text. I could add those statically to the website, but if I were to do that, for every change to that text the radiostation would have to either edit the template themselves or content me. Instead, I wanted to make these blocks of text editable through the Bolt CMS interface. Bolt has a great system of fetching content when you need it. I've put that system to good use for the blocks on the DJ-listing as well as various other dynamic blocks throughout the site.

I've created a new contenttype called blocks for this reason. By creating this contenttype, the CMS backend contains a management interface allowing the radiostation to update the text without having to edit any files. But now I still have to display it in the site. This is where Bolt's fetching content feature comes in.

There are two blocks at the bottom of the page, so I'll fetch those blocks seperately in the location where I want them. This results in the following template code:

    {% setcontent block = 'blocks' where { identifier_string: 'djs_wie_zijn_wij' } returnsingle %}
    <h4 class="color_2">{{ block.title }}</h4>
        <div class="box3">
            {{ block.body }}

The first line actually does all the magic. It sets the value of the block variable to the result of a query where I look for a record with the string 'djs_wie_zijn_wij' in the field 'identifier_string'. Because I added the returnsingle parameter it will return a single record. If I didn't do that, it would be an array containing a single record, which is kind of useless. Now, after setting the value, I can simply echo the title and body of the block in the template. I do the same for the second block, just fetching the content by a different identifier_string.


Now that I've done the first section (DJs) the same thing can be repeated for the other sections as well. Since all sections except for the homepage use the same header and footer code I can easily re-use those by using the same include systements that I've used in the DJ section. Once I've done that, all I'm missing is the homepage!

The homepage

The process of getting the homepage up and running is actually very similar to what I've described above. I set it up slightly differently though. Because I don't have to reuse the header and the footer of the homepage (the homepage is the only page with this style) I don't have to create seperate header and footer templates, I can simply put it all into one file. I've called that file homepage.twig.

In the app/config/config.yml file I can define what the homepage should contain and which template it should use. This basically defines what information will be available in your template. I've configured the homepage to be:

    homepage: over/homepage
    homepage_template: homepage.twig

This means it's going to use the record from the 'over' contenttype with slug 'homepage'. My 'over' contenttype is used for a section of pages with information about the radiostation (the Dutch word 'over' translates to 'about' in English). The page with the slug 'homepage' clearly contains the information I want to display on the homepage.

Aside from the basic information for the homepage, I also want to display the most recent 5 newsitems, so I manually fetch that content and loop over it.

    {% setcontent latestnews = 'nieuwsberichten/latest/5' %}
    {% for news in latestnews %}
        // the content to display the newsitem here
    {% endfor %}

Now when I load my homepage, it also works!

Getting rid of more duplicated code

Actually, there is still more duplicated code in my templates. Using more include statements, I can easily get rid of that. But since the process of doing that is the same as what I've done with the header and footer, I won't describe it in more detail. Be pragmatic about extracting duplicated content though: Extracting every single detail into a seperate template file and including it wherever it is used can be a pain in the ass once your website enters maintenance, because you'll be searching for ages to get to that specific element that is causing problems in your site. Use your common sense to determine whether you want to extract something into a seperate template, and do it mostly for very common elements such as header, footer, sidebar and navigation.

PHP NorthWest 2015

As you may not have noticed already, I have been accepted to do the closing keynote at the fantastic PHP NorthWest 2015 conference. I am really happy to have been accepted, as this keynote is a personal message from me that I think is important to communicate. In my keynote "Developers Are Just Like Humans" I will be looking at how we as developers may have similar problems as humans and perhaps could solve them in a similar way. It is good to be aware of this.

As with previous years of PHPNW that was accepted as a speaker, I had already bought my ticket for this year's edition of PHPNW. This means I will once again be able to give my ticket to someone. I would prefer to give my ticket to someone who would not otherwise be able to attend PHPNW: A student, someone without a job or who can not otherwise afford to buy a ticket, someone who has not yet been introduced to the PHP community. Please note: I am only giving away a ticket to PHPNW; travel and hotel need to be arranged by the person getting the ticket.

Are you someone who fits the "would not otherwise be able to attend PHPNW" description? Or do you perhaps know of someone that fits the description? Send me an e-mail: with subject line PHPNW15. I will look at all the e-mails and contact the person I (random or otherwise) decide to give the ticket to.

I am looking forward to PHPNW!

WeCamp Day 5

I still owe you one day, so here it is. This blogpost came a bit late because as day 5 ended we still needed to get the island back into its regular state, get speakers back to the airport etc. Enough excuses... here's day 5.

The last day of WeCamp 2015 was an exciting day. After 4 days of preparations and hard work, this was the day that Team Enygma would present Project Cypher. A project that we had kept an utter secret aside from the name.

During the morning, I had another round of individual conversations with my team members to see how their short-term goals were working out. It was very good to see that all team members had either reached their goals or at least were very close to reaching their goals. Some also had a clearer view of what to do with their long-term goals thanks to the experience of WeCamp. One person had not actually reached his goal, but instead had gotten something completely different and unexpected out of WeCamp which he still counted as a win.

The preparations for the presentation of the product went well, although it was finished slightly too late (lunch had already started). Still, good enough.

Then it was time for the project presentations. Team Enygma was presenting as the last team, so we could see the other teams present their stuff first. It was awesome to see what people had come up with: Being able to use a Slack Bot to control an Arduino, community-minded projects for new speakers to get feedback on their project, even a daemon that you can use to play battleships. So very cool. The presentations also gave us an overview of what people had learned. An amazing amount of things were learned, that is clear.

And then... Project Cypher was presented. The idea behind the project was to be able to keep track of information about people you know. In the original project pitch by team member Remco it would be like a CRM for Friends (FRM?). The problem (and I can so relate to this problem): Forgetting about specific things (Where do I know this person from? What do they like? When is their birthday). As we worked on the project, we came to the conclusion that this was also the ultimate tool for stalkers, but it could also very easily be applied by the police for keeping track of criminals. So it was creepy, or not. Team member Paul (who wanted to learn to be a public speaker) killed it in the presentation, sharing what we had learned and also doing an awesome demo of our system in action: Everyone that was at WeCamp was in our database, nicely tagged and easily searchable. You might be able to imagine the feeling of pride I had when I saw all this. 4 people who had never before met had created this project in just 5 days, and learned so much in the process.

After that, it was time for the closing notes and saying goodbye to everyone. The crew and coaches stayed behind to have a final dinner together and chat for a bit more, processing everything that had happened along the way. Such a fantastic week. Thanks everyone who was there.

WeCamp Day 4

In terms of working, day 4 was actually only half a day. But since the last day of WeCamp would also just be half a day, some work had to be done. The team focussed on finishing their MVP and ended up actually finishing this as well! A great accomplishment for a team that, 4 days ago, did not know eachother at all.

After lunch the Pragmatist Survival Game was scheduled. We were randomly assigned team mates (get out of that little comfort zone you built during this week!) and went on to do four different games. The games were: A balance game to get team members over the water (preferably without falling in), trying to get as many floating items out of the water, making a fire and lighting gun powder with it and sword fighting. It was awesome to see everyone get into their pirate role so well, including the secret assignment each team got, which was to make a song or poem about Mikke One-Eye. For me personally it was fun to speak to and work with some people from outside of my team as well. And I succeeded pretty good in the whole "being a pirate" by stealing the tally stick of another team, thereby robbing them of the points they earned. Unfortunately our plan to add those points to our own points was stopped by the pirate leaders denying to add it to our points. Still, we earned a third place, which I think is pretty good, out of 8 teams.

Then it was time for the Enrise BBQ (which I was told by Eli should actually not be called a BBQ, but rather a grill-out). This was a perfect way to end the day with all attendees, plus some extra guests: Rick and Stefan from Enrise, Merel and a friend (Merel is the awesome graphical artist who did our coach avatars) and my wife and kids. The night ended in the big tipi around a campfire. I hear some people didn't go to bed until 5AM. Not surprisingly, this morning the stand-up had some people missing in action.

Today is the last day of WeCamp. It means polishing up the projects, preparing the presentation and delivering the presentation. For me it also means sitting down with my team members to evaluate their personal goals for WeCamp. It's going to be an interesting day.

WeCamp Day 3

Day 3 brought change. As I mentioned yesterday some of the personal goals that were set during the individual conversations with my team members affected the work we were doing. This meant, for instance, that Jasper took a more leading role within the team, and Kanban was being implemented for a better view on our progress.

There was also some discussion on functionality and focus, as the team members were realizing they were affected by scope creep. So the minimal requirements were defined more strictly and for all the "fluff" extra post-its were added to the Kanban board. The board now also had a split: The top of the board contained all the features that were really needed, and the bottom contained the nice-to-haves. There was even a small corner of the board dedicated to "super-bling".

The team became more and more of an actual team, with lots of discussions and a lot of pairing and helping eachother. This was great to actually watch and see it happen.

The goal that was set in the morning was to finish the minimum viable product, and the team worked really hard to reach this goal, working until very late in the night. When I left the team at about 11PM they were still at it, and from what I hear they worked until after midnight even. The goal wasn't fully reached, but we're close.

Today will be an interesting day, because the MVP needs to be finished, but there's also the Pragmatist Survival Game and the Enrise BBQ. I'm very much looking forward to seeing what will happen today, and I'll share with you tomorrow.

WeCamp Day 2

Yesterday was day 2 of WeCamp and it was an interesting day. While gathering requirements in day 1 we created two spikes, topics to research to find out if we could actually do what we assumed we could. So in the morning, two people started on the research, while two other team members started on setting up the vagrant box and the Laravel project (we decided to go with Laravel for our project on day 1).

The first bit of research was quickly finished with a successful result, however the second one caused some problems: It turned out we could not do what we had assumed we could do. This meant we had to go back to the drawing board for at least part of the application we're building.

After a very constructive and successful session we decided that our change in scope wasn't all that big. We could still build our main scenario in a slightly different way. So we decided on a new list of tasks to focus on and started building those. At the start I noticed that my team members were all working very much as isolated units, but as the day progressed a lot of interaction started happening between team members. This was a nice development.

Another thing I focussed on as a coach was to set personal goals with each team members. So during the afternoon, I had private conversations with each team member to determine what goals they wanted to set. We talked about work, life and ambition and set one or two long-term goals (for "life after WeCamp") and one short-term goal ("what do I want to have learned/done during WeCamp?"). Some of the short-term goals immediately had an effect on the work we were doing in the team, so we made some changes to the team dynamic to give the people with those goals the opportunity to reach those goals.

We wrapped up the day in a really positive vibe with some excellent progress on our project and went to dinner. After dinner it was time for the Persgroep Gamenight. I pretty much lost track of my team members at that point, each went to play their own choice of games. In my case, this was: Dixit, Exploding Kittens, Masquerade and more Dixit. Being the responsible adults we are here at WeCamp (grin) we turned off the light at 1:30 and went to bed.

As I'm writing this, day 3 has started and the team is already working on the project again. I'll try to summarize today in another blogpost tomorrow morning.

WeCamp Day 1

As we just started day 2 of WeCamp I'm reflecting back on the first day of the event. As I am being a coach this year, things are very different from last year for me. I'm hoping to have enough time to publish some notes and obversations every day.

Being a coach

Getting a team of random people to coach is an interesting exercise. First thing to do is to actually try and size up all the team members and see what kind of personalities you have in your team, and how each team member can fulfill a role in the team. Additionally, the skillset of your team members can vary greatly. Although randomly created, my team actually has a pretty nice set of skills, including good frontend skills, good backend skills and even some project management skills. After some initial hesitation, the personalities also seem to be able to work together quite nicely.

Being the coach of this team is an interesting experience. On the one hand, I am here to observe my team members so I can advise them in their further (personal) development as well as help them. On the other hand, especially at the start of the event, I am also looked at to take the lead and guide the team into the project. This is an interesting double role, especially since one requires me to not interfere with things while the other actually requires me to play an active role in the team. Trying to combine those two roles is interesting.

Being coached

Luckily after some feedback from last years coaches we decided to actually have someone coach the coaches this year. Because of that I am being coached by Jeremy Coates, who is doing an excellent job of giving us some theoretical background information and helping us with the actual practical work. His support in this process is really valuable.

The project has started

After our initial introduction round and brainstorming, we decided on a project to work on. Some really interesting discussions where held on which project to work on, and during the voting the votes were even shifted from one idea to another. We've then brainstormed for as many features as we could think, then narrowed our scope to a scenario that we could realistically finish within the time constraints of WeCamp. That scenario was cut up into a set of user stories as well as two spikes, points we needed to research before starting our actual work and this morning, work has started on bootstrapping the project and getting as much information as possible out of the spikes.

Let's see what we can do today. I'll let you know tomorrow.

You Need To Do What You Need To Do

One of the topics in The Art of Asking that I think more developers should be aware of is that you need to do what you need to do to do your thing. This sounds vague, but it is true. In the book, Amanda Palmer uses several examples of how this works for artists, but I think it is equally true for developers (although not everyone understands this):

At some point, Amanda is having a coffee with Samantha Buckingham, another crowdfunding artist. She releases her music on Patreon, and Buckingham was afraid it would not sit well with her fans that she would post pictures of her sipping a mai tai. After all, it was her fans' money being spent on such a holiday. The response Amanda gives:

What does it matter where you are or whether you're drinking a coffee, a mai tai, or a bottle of water? Aren't they paying for your songs so you can... live? Doesn't living include wandering and collecting emotions and drinking a mai tai - not just sitting in a room and writing songs without ever leaving the house?

Then she goes on to describe how Kim Boekbinder, another crowdfunding artist, thinks about this:

Kim had told me a few days before that she doesn't mind charging her backers during what she calls her "staring-at-the-wall time," which she thinks is essential before she can write a new batch of songs.

This attitude is important for us as well I think. Someone, many developers I encounter seem to think that you need to work furiously on writing new code, at least 8 hours a day, to do your work well. But this is far from true. I touched on this subject in this blogpost, but programming is a creative job. This means that sometimes, you need to take a step back. Go out for a walk, play a game on your Wii, Playstation or XBox, read a bit in a book, find the activity you need to get that inspiration. And don't feel guilty about doing it.

In my previous project, the office cafeteria actually had a pool table. At least once a day, I'd go down to the pool table with a co-worker and play some pool. I surely wasn't banging on my laptop for 8 full hours every day, but the games of pool surely helped me sometimes in finding the solutions or cooling down after a frustrating bug arose. Sometimes, we just need this change of scenery. Remember, you get paid simply to get the job done, regardless of how you do it. If your employer or client gives you a hard time about it, just tell them that you need this in order to do what they pay you to do.

As Amanda Palmer puts it quite nicely:

The relative values are messy, but if we accept the messiness, we're all okay. If Beck needs to moisturize his cuticles with truffle oil in order to play guitar tracks on his crowdfunded record, I don't care that the money I've fronted him isn't going towards two turntables or a microphone. Just as long as the art gets made, I get the album, and Beck doesn't die in the process.