OctoBlog

Working in public

2017-03-15T06:11:00Z

I spent a few days in Las Vegas this week, and as I was strolling down Fremont street yesterday afternoon I stopped to watch this guy paint.

I watched him start with a completely blank peice of paper. Then he started applying paint (with spray paint cans!), using other peices of paper to block off sections of his "canvas", and removing or smearing paint with rags.

After a while he had created this painting:

As I was watching him paint it occurred to me that this is the ultimate example of "working in public".

Every single drop of paint was added in full view of anyone who cared to watch. He never raised a curtain to protect a "trade secret". He never obscured the view of his work in progress to preserve a special technique.

He never worried that I might watch what he was doing and then go home and do it myself. In fact, it's just the opposite. As I watched him paint I continually thought "Wow, that takes some skill! I couldn't pull that off with 15 hours of work, and he's doing it in 15 minutes."

He's well aware that if I were looking to pick up his techniques that I was never going to be his customer in the first place. He knows that letting me see the process of creating this painting is part of what makes the end result impressive.

A little later in the day I passed the same spot again, and there was a different guy doing the same thing, in the same spot, with the same gear.

I don't know which painter is the "master" and which is the "apprentice" in this situation (I have a guess), but it's clear that there's a group of people all working together. I'd bet that whoever is the "ring leader" managed to recruit others to the cause by working in public and demonstrating mastery of skills.

So, to wrap up, I think there are two main benefits that these guys (and their group) get from working in public.

Their customers have a better appreciation for the end product that they produce and the skill it takes to produce it.
They have increased visibility and a means to recruit new painters.

Note: This post is as much for my own benefits as anyone's. I'm still working to internalize the concept of working in public, and still trying to figure out exactly what it means for my type of work. I think this is a good example to keep in mind when The Fear^TM pops up and tries to convince me that I need to "protect my secrets".

Btw, the first painter that I saw is a guy named Tony Vegas. You can see (and buy) some of his art here.

Going Serverless @ Okc.js

2016-04-19T15:09:00Z

Today at Okc.js I'm presenting a talk called "Going Serverless" about the Serverless framework and Amazon Web Services.

Slides

Going Serverless

Demo Project

https://github.com/jagthedrummer/going_serverless_demo

How much should custom development cost?

2015-05-26T22:19:00Z

I remember when my parents took me to get my first car. Like many teenage boys my list of requirements for a car looked something like this:

Things I want in a car

sporty
fast
red or black
deluxe stereo system
power everything
new
"cool"

Unfortunately the budget at hand meant that I could have few of those things.

I also had another requirement that was a little bit unique. I played drums in a band and I needed something that would allow me to move my drum set.

My parents recognized that this was the single most important requirement for this new vehicle. In order to make sure that I stayed on task they had me load up my drums set and we took it to the (used) car dealership. Every time that a vehicle caught my eye the very first thing that we did was move the drum set from my parents car into the new candidate to make sure that everything would fit. Much to my dismay, this process immediately ruled out a wide range of fast/sporty/cool cars, but it ensured that I never had any chance to get the least bit emotionally attached to any option that wouldn't fulfill the primary goal of the purchase.

Knowing what really matters

My original list of requirements were almost all based on what I thought would make for a "cool" car. I wasn't even that into cars, but still wanted to have a cool one. This was strictly about status. My parents knew that I needed to focus on utility instead. They also knew that budget was important.

Had I gone to the dealership on my own I'd have described wanting a Porsche and then been shown a Pinto based on my budget. Car dealers know that it's very common for a person to have desires and budgets that are at odds with each other (I mean, who doesn't?), so the very first question that they ask is: "What is your budget?"

The available budget is the single most important factor in the first step of narrowing down which cars are realistically in play. It's a waste of time for everyone involved for a dealer to show and test drive a car that is significantly lower or higher than the target budget range. (You might think that ones significantly lower would be a safe bet, but that's most often not the case. That's due to people seeking both utility and status in a vehicle.)

Now to bring us to the original question:

How much should custom development cost?

To continue with the car scenario, we might ask :"How much should a vehicle cost?"

The question itself doesn't contain enough information to be answerable. We need to know much more about the intended use of the vehicle to even begin to answer that question.

Are we talking about a car for a family or some sort of business use?

Any family buying a car will almost certainly have a budget in mind when they go to buy a new car.

If we assume that it's for a business then the real question is "How will this vehicle help the company make money?" Only after answering that question will we be able to start to decide on a reasonable budget for this vehicle.

For instance, if the business is a bicycle messenger service, then the budget for a new vehicle is drastically lower than if it's a moving van company. Likewise the moving van is drastically less expensive than a big rig for hauling cargo long distance. Or maybe the business plans to race this new vehicle in a major stock car tournament.

In each of these cases the use to the business and the expected return on investment dictates a budget range that is reasonable to spend on a new vehicle. There may be wide variation within that range, but the range itself is set by the expected return to the business by incurring that expense.

The variations in price within the available options will represent a variety of factors including:

Quality
Extra features
Risk management (warranty coverage)
Status signalling
Speed of delivery (for custom orders)

Custom development is very much like this.

I sometimes hear from business owners, or people with an idea for a business who ask me to give them a quote on some custom development project. They want to spend a few minutes describing their idea to me and then have me tell them what it should cost.

Often they describe a Porsche of a project, but then have sticker shock when it comes to building their custom Porsche. Many times this is due to focusing on features and status signals more than utility.

I recommend that business owners do two things to make things go smoother.

1. Understand and group your requirements.

As with most things, a project of this sort ends up being a series of trade offs and compromises. More than just having a set of requirements you also need to understand which business objective each requirement is trying to accomplish so that you can make the most effective trade offs. I'd recommend grouping your requirements (and the business justifications for them) into 3 main groups.

Must have - Without these the site is useless to you.
Probably need - These are not mission critical, but are almost certainly needed but theoretically could be traded away in a worst case scenario.
Nice to have - These are things that have the lowest expected ROI and are the first to go if there are scope/budget concerns.

Thinking of your objectives and requirements in this way allows you to more easily resolve any conflicts that may lurk in competing objectives and requirements.

It also means that you can be shooting for varying levels of success that might be characterized as "Good enough", "Pretty damn good" and "OMG Home Run!!!".

2. Develop a budget. At least just a ballpark.

I know that it's tempting to just throw requirements out there and get proposals, but the truth of the matter is that if you looked hard enough for almost any project you'd be able to find somebody who'd propose it at $500 (you don't want that person), and you'd be able to find somebody to quote it for $500k (you probably don't want that person either). Having a ballpark budget in mind helps to avoid wasting anyone's time (most importantly, yours!).

Ideally you'd want your budget to structured in 3 parts, to match the 3 groups of requirements.

Baseline budget - The minimum amount you are looking to spend to get your "Must have" objectives met.
Middle of the road budget - A range reflecting what you'd like to spend to get all of your "Must have" and most or all of your "Probably need" objectives met.
Top end budget - The maximum amount you are willing to spend to meet every single one of your objectives.

Obviously your budget should be related to the business objectives you have for this project. For instance if your plan is for the project to generate $1 million in sales over the first year you'd obviously want to have a much different budget than if you only expect it to do $100k.

What's your project?

Do you have a business or project idea that you'd like to get off the ground? Do you know whether you need a Porsche or a cargo van?

I can help you assess your true needs and lay the ground work to make your dream a reality.

PS. I ended up with a 1984 Dodge Duster hatchback. :)

Analysis of the rumored Heroku pricing changes

2015-03-31T01:35:00Z

It was recently reported that Heroku will soon be making some changes to their basic dyno pricing structure. I wanted to take a look at the changes and see what they will mean for all of the apps that I host there, some already on a paid tier, and some using their generous free tier.

The changes

You should read the original post if you want all of the details, but the basic rundown is this:

Free tier : Will be limited to 1 web dyno and 1 worker dyno, will sleep after 1 hour of inactivity, can be active for up to 12 hours a day, and can not support custom domains. Dynos have 512 MB RAM.
Hobby tier : Dynos can run 24x7 for $7/dyno/mo and custom domains are supported. Max of one dyno per Procfile entry. Dynos have 512 MB RAM.
Standard tier : All Hobby features, plus multiple dynos per Procfile entry, app metrics, faster builds and preboot. 512MB or 1GB RAM for $25 or $50/dyno/mo.
Performance tier : All Standard features, plus the availability of isolated high-performance dynos with 6 GB RAM for $500/dyno/mo.

So let's look at a few different configurations and see how monthly costs would differ between the current pricing and the new pricing.

A Disclaimer

For the record, I do not work for Heroku and was not paid or otherwise encouraged by them to write this. My goal here is not to convince you to move to Heroku, but rather to take a fair look at how these changes will affect apps currently hosted at Heroku, both free and paid.

Also, I'm assuming fairly simple (and possibly naive) usage patterns. One of the big benefits to Heroku (and other services like it) is that you can be very intelligent about how and when you run your infrastructure and scale up and down based on demand and/or time of day. For the sake of easy calculations I'm going to be looking at static dyno configurations. Many of these are real configurations that I've used, and some are better thought of as a base-line minimum for busier sites, which would be augmented with some additional dynos on-demand.

I'm also interested in helping developers understand that the economics of changes like these may not be as cut and dried as they appear at first.

Which leads me to my next point…

Valuing your time

One of the things that's motivating me to explore this pricing change is that I've seen some grumbling from developers who are ready to move away from Heroku simply because they're not getting everything they need for free anymore and think that there are "cheaper" options.

On the raw numbers, yes, there may be cheaper options out there. However, moving to those other options will take time and effort, and unless you value your time at $0/hour there is a real cost to you in spending the time to make the change. This is true of any big change in hosting providers.

For the purposes of this conversation let's say that your time on the open job market, as a person who is technically capable enough to use Heroku effectively is $85/hour. This is a very realistic number, and in fact, is on the low end for contract developers. But it's a convenient number for our purposes. If you know how to use Heroku and you don't believe you time is worth at least $85/hour I'd reccomend that you read everything you can find from Patrick McKenzie, aka patio11.

Keeping it free

The current free tier at Heroku basically allows you to run one dyno 24x7 at no cost. Dynos are currently put to sleep after 1 hour of inactivity, but I think that only applies to web dynos, and they can be kept alive by setting up site monitoring tools to ping them at least once an hour. So, basically 1 free dyno 24x7.

The new pricing indicates that the best you can do on the free tier is to run one web dyno AND one worker dyno each 12x7. If you currently have a site with only one web dynor or with just one worker dyno it seems that you'll be out of luck for staying on the free tier if you want to keep your dynos alive all the time. If you can schedule your dyno availability around business hours (for example) and allow them to sleep at night, you may be able to squeak by on the free tier.

Starting to pay

If you really need your one web or worker dyno to live 24 hours a day 7 days a week OR if you want to host your web dyno at a custom domain, then under the new pricing structure you'll pay $7 a month, or $84 dollars a year.

I know that some people will balk at this figure, but based on the number we agreed to above, if staying on Heroku saves you even 1 hour over the next year it has paid for itself.

If we assume, for a moment, that you have the option to move to some other hosting service that is free, you can't spend more than 1 hour making the transition to the new service, and you really can't spend any time at all over the next year doinking with your new hosting provider.

If you value your time at all it's worth it to pay the $84/year to keep a project running there that was previously free.

Currently paid, but small apps

Let's say that you currently have one web dyno and one worker dyno staying alive 24x7, both on the 1X or 512 MB dynos. (I'm running exactly this configuration for a couple of small apps.) Currently you get one of those dynos for free, and you pay about $35/month for the other one.

Under the new pricing structure you'd pay $7/month for your web dyno, and $7/month for your worker dyno, for a total of $14/month. This is clearly a better deal and represents a savings of over 50%.

Larger, but still small paid apps

Let's say that you currently run 2 web dynos and 1 worker 24x7, on the 1X dynos. One of those dynos is free, and you're paying $35/month for the other two, for a total of $70/month.

On the new structure you'll need to step up to the Standard pricing to be able to run the 2 web dynos simultaneously, so you'd be paying $25/month for each of 3 dynos. So all together you'd be paying $75/month instead of $70/month, for a total increase of $60/year.

Again, if you value your time in the least, an increase of $60/year is pretty poor motivation to change infrastructure providers.

If you're looking for places to complain about the new pricing this is one of your only sweet spots. ;) From here on up the new pricing is advantageous to Heroku customers.

Larger still, but barely

Let's say you have 2 web and 2 worker dynos running 24x7 on 1X dynos. Currently you pay $35/month for 3 of them, with one being free. Total cost is $105/month.

The new pricing would see you paying $25/month for each of those dynos, for a total cost of $100/month.

So, it's not a huge difference, but about a 5% savings on the new plans if you run 4 1X dynos 24x7.

Getting bigger

Let's jump up and say that you're using 2X dynos and have 2 each of web and worker dynos. The details of the calculation start to get a little messy, but the Heroku pricing calculator shows the total cost to be $250.50/month.

The new pricing structure has 2X dynos at $50/month, giving you a total of $200/month. A 20% savings.

What about really big

The bigger your app, the better the news.

If you currently run 16 1x dynos you pay about $538/month. Under the new pricing you'll pay $400.

If you currently run 16 2x dynos, instead of paying your current $1,114/month you can pay a more comfortable $800. 28% saving.

32 2X dynos? How about $1,600/month instead of $2,26? 30% savings? Yes!

It just keeps getting better

As you can see, the larger your app, the more savings you'll see under the new pricing.

Show me all the numbers!

Here you can see that the savings for 1X dynos trends towards 27% as you add more an more dynos.

For 2X dynos the savings trends towards 30%.

For performance dynos the savings trends towards 13%.

Conclusion

If you already pay Heroku just about anything for hosting your app(s) this new pricing is nothing but Good News^TM.

If you're currently relying on the free tier, you can continue to host your project there for $84/year. Your time as a developer is worth AT LEAST $84/hour. So, if you value your time at all you should stop trying to find a "cheaper" alternative and just give Heroku your credit card.

The only good reason to move away as a result of these (rumored) changes is if you enjoy managing infrastructure as a low level. If you're into that, then great! Have fun managing servers.

What do you think?

Did I miss something in the rumored pricing? Do you run a configuration on Heroku where the new pricing isn't a good thing? Tweet at me or send me an email.

NDC London - Client MVC != Server MVC

2014-12-03T13:35:00Z

Today at NDC London I'm presenting a session called "Client MVC != Server MVC". Here are links to my slide deck, an example GitHub repo, and a bunch of JSBins that step through the process of building up a small app.

ThunderPlains 2014 - Supercharge your productivity with Ember.js

2014-10-09T14:54:00Z

Today at ThunderPlains I'm presenting a session called "Supercharge your productivity with Ember.js". Here are links to my slide deck, an example GitHub repo, and a bunch of JSBins that step through the process of building up a small app.

Slides

http://jagthedrummer.github.io/ember_thunder_plains/

Repos

Pattern Lab - An Ember CLI demo app.

Pattern Lab API - A Rails app providing a JSON API for the Ember app.

JSBins

A very simple app

A very verbose and simple app

Dynamic routes & Nested routes/templates

Pattern display component

Create a new pattern

REST Adapter

Introducing Remarq.io

2014-08-29T07:18:00Z

Remarq is a tool for constultants and agencies to allow them to create beautiful PDF reports. Reports can be authored in Markdown and then converted to high quality professional PDFs with no extra effort.

Focus on creating value

Spend more of your precious time focused on delivering real value to your clients by creating great content. Write your reports with simple Markdown and stop fighting with word processors or page layout software.

Increase perceived value

Great looking PDF reports are perceived to contain more value than the same information delivered via standard web pages or emails. Increased perceived value means that your clients trust and value your opinion more highly.

Beautiful custom branding

Customize your report style to fit your brand with custom fonts, colors, and page layout. You never have to worry about sending out a report that doesn't look awesome.

Check out the web site to learn more.

Client MVC != Server MVC - EmberFest 2014

2014-08-28T11:42:00Z

Today at Ember Fest I'm presenting a session called "Client MVC != Server MVC". In it I compare and contrast the Ember style of MVC with the Rails style. Here's a link to the slides for the talk, and to a bunch of bonus JSBins that step through the process of building up a simple Ember application.

Slides

http://jagthedrummer.github.io/ember_mvc/

JSBins

A very simple app

A very verbose and simple app

Dynamic routes & Nested routes/templates

Pattern display component

Create a new pattern

REST Adapter

Repos

Pattern Lab - An Ember CLI demo app.

Pattern Lab API - A Rails app providing a JSON API for the Ember app.

Supercharge your productivity with Ember.js - That Conference 2014

2014-08-12T14:27:00Z

Today I'm presenting a session at That Conference called "Supercharge your productivity with Ember.js". Here are links to my slide deck, an example GitHub repo, and a bunch of JSBins.

Slides

http://jagthedrummer.github.io/ember_supercharge/

Repos

Pattern Lab - An Ember CLI demo app.

Pattern Lab API - A Rails app providing a JSON API for the Ember app.

JSBins

A very simple app

A very verbose and simple app

Dynamic routes & Nested routes/templates

Pattern display component

Create a new pattern

REST Adapter

Bootstrap glyphicons with ember-cli

2014-05-25T03:53:00Z

In a couple of previous posts we've seen how to use bootstrap-sass-official in an ember-cli app. Not long after I published the second post, my friend Tute pointed out that my solution left the bootstrap glyphicons in a broken state. So, let's get those working!

@jagthedrummer how did you handle glyphicons? Mine get 404s.
— Tute Costa (@tutec) May 24, 2014

Luckily this ia a pretty easy fix. We just need to add a few lines to Brocfile.js.

First we should remove this line :

module.exports = mergeTrees(app.toTree());

And replace it with these lines :

// Put the bootstrap fonts in the place that the bootstrap css expects to find them.
var pickFiles = require('broccoli-static-compiler');
var bootstrapFonts = pickFiles('vendor/bootstrap-sass-official/assets/fonts/bootstrap', {
    srcDir: '/',
    destDir: '/assets/bootstrap'
});

// Merge the bootstrapFonts with the ember app tree
var mergeTrees = require('broccoli-merge-trees');
module.exports = mergeTrees([app.toTree(),bootstrapFonts]);

That's it! This will place the font files that provide the glyphicons in the right place ('assets/bootstrap/') so that they can be used by the css files generated from bootstrap-sass-official.

I just added some glyphicons to watch.canary.io using this method and you're welcome to checkout the source code to see how it all fits together.

UPDATE : Joseph DeVenuta points out that the format of the bootstrap-sass-official package has changed.

@jagthedrummer think I found an error in your ember-cli glyphicons example https://t.co/38jsbxuNV5 This works for me https://t.co/qJmupOVg24
— Joseph DeVenuta (@j_venator) July 14, 2014

At the time this post was originally written the first argument to pickFiles was vendor/bootstrap-sass-official/vendor/assets/fonts/bootstrap. It has been updated to vendor/bootstrap-sass-official/assets/fonts/bootstrap in order to match the new format of the package.