Yeti Media

Aug 1

HTML5 development

Yeti Media offers HTML5 development services, including cross-platform app development for mobile devices. We are also phonegap experts making it easy for you to get your HTML5 app into the Apple App Store and Google Play. We can help.

AngularJS token authentication

Angular token authentication by Yeti Media {fresh_software: “daily”} for REST resources in angular apps. Computer Vision in the Cloud.

Our API you will let you make apps that:

Detect Objects Recognize Text Detect Image Similarities Facial Recognition Rubix will allow the freedom for developers to add their own patterns to our training sets. Our SDK’s will be open source and support Ruby and Javascript when we launch this spring 2014.

New Yeoman generator-castrum

Nick Treadway just released a bloat free Sass responsive grid system and thats it! generator-castrum

More info coming soon on how to start using this new grid with your #html5 projects

Spark of Love Toy Drive

Yeti Media is proud to be teaming up with Starbucks, ABC7 and SoCal Fire Fighters Spark of Love again this year for the Spark of Love Toy Drive. We will be accepting New, Unwrapped toys or Sport Equipment valued at $10 or more.

Our own Nick Treadway built givethruyeti - if you’re in Southern California, go there to find a nearby participating Starbucks and some suggested donations, and help some needy kids have a happy holiday.

You can drop off new, unwrapped toys or sports equipment valued at $10 or more at a participating Starbucks (visit for a map of participating Starbucks locations) and you will receive one free Verismo latte.  You can also Tweet “I’ve Donated” with the hash tag #TeamSpark and follow @yeti_media to be entered to win a free Starbucks Gift Card valued at $25.

Writing is rewriting, Coding is refactoring

by Matt Cowley The first draft of any piece of writing is just that - the first draft. The real writing happens in the second, third, and thirtieth drafts, when intentions are made clearer, language is sharpened, and cliches roll like water off a duck’s back into the gaping maw of a thousand deaths. Also hyperbole is removed.

What that notion allows a writer is a way to get a sense of what the piece is, whether it’s a screenplay or a cover letter for a resume, without worrying about the details at first. First, what is it that you’re trying to say? Then, how best to say it?

Unfortunately, this process is not typically followed in ordinary speech. If it were, Harvey Fitzgerald from seventh grade would still be reeling from the zinging power of my retort after he called me a — well, it’s best not to dwell on those things.

Pardon me, I need a moment.

Ok. The rewriting process absolutely applies to writing software, though. It’s called refactoring. When placed in the ideal context of test driven development (TDD), it’s part of the red-green-refactor process.

"Red" in this case means a failing test. The test that fails is a statement of the problem: this is what I’m trying to say with this bit of code, or this is the impact I want it to have. It’s the equivalent of "give me 500 words on the elephants of Hackensack, New Jersey."

The “green” step is the first draft. There’s a tendency, especially in projects with tight deadlines, to try and write code once and move on, which means you have to write it correctly the first time - correctly and in the ideal way. One of the great breakthroughs of test-driven development is that your first pass should be considered just that - a first pass. Don’t worry about cleanliness, patterns, the Law of Demeter, the rule of threes, or the Heisenberg Uncertainty Principle. Just get the test passing.

What does thinking of code in this way do for you?

First, it allows you to keep moving. If you can write the fastest, simplest, messiest code that makes the test pass, you’ve suddenly got momentum. Keep the red-green-refactor loop moving, fast; incremental improvement is, perhaps counter-intuitively, faster than writing it perfectly the first time.

Second, it allows you to quickly validate that the problem you’re trying to solve makes sense. If you can’t write something quick and dirty to make the test pass, there could be something wrong with your test, or there could be something wrong or unclear about the task you’re trying to complete.

Also, crucially, it tells you that for this problem, a solution exists. That’s another kind of momentum, and a kind of self-validation - I may not be able to remember where I left my keys, but damnit I can get the names of students in a certain grade range with higher than c average to appear in a list (but only if they were born on a Tuesday in Belgrade).

Finally, and most importantly, it allows you to get to a working system, as quickly as possible. To be able to say at any point that the system as we’ve defined it so far works is of incredible value.

If you have a working system, and tests to prove it, then you can sit down, crack your knuckles, and make it purty. You can edit a thousand times, until you have the most beautiful, elegant code you can imagine, and know that at every step you’ll be the first to know if you’ve broken the system.

When you finally check in the completed code, thirty seconds or thirty minutes later, no one has to know the utter crap you wrote the first time you made the test pass. All they’ll see is the gleaming diamond of elegance you committed and pushed, and that that elegant diamond has added to the completeness and robustness of the system, by adding new tests and satisfying the test suite as a whole.

And if, in a code review or project retrospective meeting, you come across Harvey Fitzgerald from seventh grade, you tell him from me— well, I’ll think of something.

Remote Working Tip #232 - Don’t Follow the White Rabbit

by Matt Cowley

Remote work is hard, but it’s much easier as a remote team than as a solo freelancer.

We have a (loose) rule at Yeti - if you’re spending 20-30 minutes on a task without making forward progress, stop and ask for help.

Above all, don’t go down the rabbit hole. The white rabbit is tempting, and he’s offered tea, but don’t do it.

Progress can grind to a halt in software development for several reasons: environment, acceptance criteria, and code/syntax.


Coding environments can take an otherwise sunny week of coder happiness and turn it into an epithet-filled death march through hell. (“Oh, looks like I need to update rmagick. I’ll do that quickly and get right back to….ohh nooooooooo!!!!!”) Configuration, library installation, OS updates, can send you looking for just the one more stackoverflow post that will solve this next problem. And then there’s another problem.

If you see an environment rabbit hole looming, stop and ask someone on the team for a suggestion. It’s likely they’ve hit the same thing, or have a 5-minute solution, or a reference to the most efficient path.

Acceptance criteria

Acceptance criteria - what exactly is the bug that I’m fixing, or the feature I’m building? - is the easiest block to solve, and also sometimes the most difficult. Sometimes we’re trying to interpret a cryptic note (“the thing doesn’t pop”) or there’s a ramification to a new feature that isn’t covered in the ticket (“if i build this, all the user data will be posted to facebook; i wonder if that’s what they want?”).

The key with acceptance criteria is always communication. The two keys with acceptance criteria are communication and flow. If something is unclear, we make sure the ticket has a clear and concise description of what we need to know, make sure the client is aware of the question, and (here’s the flow part) move on to the next task until we can make progress again. Having a good issue tracker flow is vital.


This is probably the most dangerous category of rabbit holes, because coding is a solitary game. With a remote team, often the biggest interface we have with the other team members is our code. We have a strong desire for everyone else on the team to realize the truth, which is that we are the greatest coder in the known universe. So, asking why a bit of code isn’t working is hard to do.

Problem code can also be kind of a puzzle, which appeals to coder mindsets - if I fiddle with this long enough, I know I can crack this bit of syntactical puzzle and win the prize of..ok, well, there isn’t really a prize.

It’s also easy switch tactics completely if the path you’re on isn’t working (“I can’t figure out why the form isn’t submitting, so I’ll store the entire db in the session…that should work.”) And then, change tactics again. (“Session vars aren’t storing. What if I stick them in a file on the client machine and get it to send an email…”)

A quick exchange can cut an hour out a syntactic blind-spot problem. Stop, ask someone else on the team. There’s a good chance they’ll be able to give a quick suggestion to get the wheels moving again so you can sail off into the sunset of mixed-metaphor coder happiness.

I’m sorry, what?

Here’s the executive summary - if you’re working with a remote team, take advantage of the team part of that. If you think something should take five minutes, you’re probably right, so reach out for help if it’s taking an hour instead.

Stay out of Emergency Mode. Or, Fear is the mind-killer, process is the dragon slayer.

by Matt Cowley

More than once we’ve stepped in to rescue a project that’s failing. There’s a deadline looming, features aren’t working, there are no tests to speak of, the same bugs crop up, get resolved and then crop up again, like a wack-a-mole game.

The mindset is almost always the same: we can’t take time now to get tests in place or follow good development practice, because if the site doesn’t go live by we’ll lose funding, or the universe will die, or Milli Vanilli will begin a reunion tour.

Sometimes you really do need to just jump into cowboy mode and crank out a feature as fast as you can. When that’s the only legitimate business decision to make, then that’s what you do.

But, that’s almost never the only decision to make.

The trouble Emergency Mode is that it never ends. It feeds on itself. A typical cycle is:

  • we have 3 bugs and 2 features that have to be delivered by Friday EOD;
  • by the way, it’s now Friday morning;
  • we’ll just crank these out with no tests or code review, and merge them into master asap;
  • we’ll test on a development/staging server
  • because we haven’t had time to resolve some inconsistencies between the production and dev/staging environments, we can’t actually test the bugs there, ‘cause they only show up on production;
  • so, just test that the site still loads, and then push to production;
  • it’s Friday EOD, so we’ll go ahead and deploy to make sure we meet the deadline;
  • now we have 5 bugs instead of 3, and it’s Friday night.

And so on.

Emergency Mode leads to a culture of fear among developers. If there are no tests in place, and a fragile ecosystem, it’s difficult to know what the effect will be of any code change. Maybe there’s a class that desperately needs refactoring, because before any change can happen in it the developer must take 10-20 minutes to read through the opaque code and figure out where the change should happen, but he can’t refactor it if there’s no assurance that doing so won’t break a dependency.

Programming in fear is slower. But worse is writing code in an ecosystem that should inspire fear, without fear. That’s just reckless, and is the other possibility for working in Emergency Mode.

Programming in fear, and programming recklessly, leads to mistakes, poor design decisions, and problems in production code.

The solution? Stop working in Emergency Mode.

But, you say, I’ve got a deadline! I can’t take two hours for a task I know I can crank out in fifteen minutes!

When an application gets into Emergency Mode, that’s almost always a problem of planning and expectations. Either the tasks weren’t estimated well enough, or the feature list was too large for the time allotted, or scope creep happened.

Coding a feature takes the time it takes. When the deadline for a feature set is earlier than the features can be completed, there are only two options: reset expectations for delivery dates, or trim the feature set. The third option is delivering a lot of features that only work some of the time, if you hold your mouth a certain way and type only with your index fingers.

Whenever possible, trimming the feature set per release so that there’s time to deliver robust features with some degree of confidence is best. Release early and often, but with small and manageable feature sets.

When the feature set won’t budge, one approach we’ve taken is to kind of split the team. One developer is working in something close to emergency mode: cranking out code quickly, working in close contact with the project manager to respond to urgent requests. Another developer is taking time to build and expand the test suite, adding full-stack integration tests first, and then coverage for the most frequently touched classes. That effort is slow at first - there are environmental/setup issues to resolve, and the test harness can be tricky to build on a complex project. But, speed builds on itself, and soon both developers can commit to writing no new code without tests, and gradually begin expanding the test coverage across the codebase. Once that begins to happen, refactorings of difficult classes becomes possible, and a codebase that once resembled an enormous pile of knotted spaghetti, sliding off the plate and spilling sauce everywhere, becomes an ordered pile of ravioli, functionality neatly tucked inside like a delicious cheesy filling. And who doesn’t like ravioli?

Guillermo Iguaran Joins Rails Core

We are happy to announce that Yeti developer Guillermo Iguaran has joined the Rails Core Team. Guillermo started contributing to the Rails framework in 2011 and is an active contributor.

He also contributes to other open source projects like rubinius, jruby and others (See Guillermo Github account). He’s also the author of Light: an HTTP rack based server.

Guillermo has been working on Rails 4 lately. He is mainly focused on the Asset pipeline, releasing a new version of sprocket-rais. Also he extracted StrongParameters from rails as a gem, did a complete refactor of ActiveResource and removed rack-cache as a dependency from rails 4.

Here are a couple of Guillermo’s posts for the Yeti blog:

Congratulations, Guillermo! Great job. Yeti Media is proud to sponsor Guillermo’s contributions to Rails 4.

Nov 7

ActiveResource is dead, long live ActiveResource

by Guillermo Iguaran:

As many of you already know, ActiveResource was removed from the Rails master branch and won’t be shipped with Rails 4. The motivation behind the removal was the lack of maintenance and maintainers on Core Team. But its not all bad news, ActiveResource now lives as an independent plugin and is receiving more love from contributors. There is also a small team lead by Jeremy Kemper working on it. Since the extraction from Rails we have added some nice features:

  • Basic support for associations: has_many, has_one, belongs_to now can be used in ActiveResource models. Here is a small example of it:

If the request to http://37s.sunrise.i:3000/posts/1 returns comments then @post.comments will be available immediately, if not, it will be populated the first time that @post.comments is called with a request to http://37s.sunrise.i:3000/posts/1/comments

  • Basic support for callbacks, after_create, after_save, after_update, before_create, before_save, before_update, before_validation, after_validation and other friends that can be used with ActiveResource models. A simple example:

  • Support for APIs without a format in the path, you can now consume APIs that support setting of the desired format through the Accept header. I think this will be a nice feature appreciated by you RESTafarians ;)

  • Support for non-RESTful APIs, the ActiveResource models can set a collection_parser which can deal with API responses that do not match Rails (RESTful) conventions, a handy example to understand how it works:

  • Support for Singleton resources through the ActiveResource::Singleton mixin. An example:

  • Fixes, fixes and more fixes, we have merged a lot of fixes provided by contributors

We will release ActiveResource 4.0 in the next months (trying to be in sync with Rails 4 release) but I will be working soon in a plugin to backport all these changes to ActiveResource 3.2, then you won’t need to wait more to use all these exciting features in your current projects. Long live to ActiveResource!!!.

We will keep you posted with more updates about Rails 4 and all their related projects.

About Guillermo Iguaran:

Senior Software Architect and Open-source evangelist with more than 4 years of experience working as a software developer and programming with Ruby. Guillermo is a young developer and open source enthusiast who is rapidly moving up the ranks in the ruby community. Currently, he is a Rails Core Contributor and has contributed to some popular projects of the ruby world like Rubinius and JRuby.