Development Tools, SRP, Demeter, Architecture and Putting Code and Functionality Where it Belongs

05 December 2016

Dirty, but damn good at what it does.

Avoid Dirtying Your Models For Performance Improvements

A common thread I’ve seen, especially when going through older apps, are model attributes where they don’t belong. I’ve noticed the intent or reasoning behind this comes in two flavors, performance based, and convenience based. It’s important to remember that we have different tools to solve different problems. Let your relational database handle attributes on the model they belong in, and use other tools for convenience and speed. What follows are my thoughts on both refactors and greenfield designs in order to keep your data where it belongs. In the end, it all ties together and keeps things simpler, more powerful, and most importantly, quicker, both in the short and long term.


Fix Elasticsearch 2.x to 1.7 Downgrade Issue: unexpected field in shard state index_uuid

05 December 2016

The Issue

While booting up a client’s app locally, I ran into the following from Elasticsearch:

[ERROR][gateway.local.state.shards] [Kymaera] failed to read local state (started shards), exiting...
org.elasticsearch.ElasticsearchException: unexpected field in shard state [index_uuid]
{1.7.6}: Initialization Failed ...
1) ElasticsearchException
  NullPointerException2) ElasticsearchException[unexpected field in shard state [index_uuid]]
  CorruptStateException[unexpected field in shard state [index_uuid]]

Some quick searching led me to this github issue.

Unfortunately, following their approach (simply delete your ES data), failed for me. What follows is a simple, but more complete fix which took care of my problem. This is on an OS X El Capitan install; the error came from an ES 2.1 install I had, which caused problems when I did the following:

Read More... Elasticsearch 5 Capabilities, Release Date

04 December 2016 logo, a One More Cloud company

So far, I’ve found my favorite challenges in development and consulting all focus on performance; whether it’s building something from scratch that scales, or taking an older system and bringing it up to speed. A common thread throughout is using a cache or search service to tremendously boost speed. My first foray was with Solr, when I used it to achieve a 1588x speed increase for a client’s reports.

A similar product is Elasticsearch, and since I favor Heroku, Bonsai is my go to provider. Elasticsearch 5 was recently released, which offers some great performance increases and new features. I wasn’t able to find any official word from Bonsai about ES 5 offerings, so I reached out to them, and quickly received a response from their team, saying they do offer it.

I’m writing this in the hopes that anyone else looking for that information is able to find a suitable answer here for availability:

  • Private Elasticsearch instances: ES 5 is available
  • Public/Shared Elasticsearch instances: ES 5 will be available in Q1

If you’re like me, and enjoy spending your time making things go fast, you’ll be happy to know that this newest release of Elasticsearch will soon be available on a fantastic provider.


How To Run Simultaneous Rails Apps With Ease During Development

04 December 2016

An artsy quark. Smaller pieces combining to make the whole greater than the sum of the parts, just like proper microservices.

Sometimes while you’re developing Rails apps, especially microservice architectures, you need to be able to run multiple apps on your development machine. Read on to see how I quickly and easily solved that problem using Foreman (Update 12-12-09: Use Heroku Local instead) and a few configuration changes.


Gem Release: Google Analytics Chrome Developer Cookie

03 December 2016

Google Analytics Chrome Developer Cookie

Want to add easily configurable google analytics tracking code to your Rails application, but not register you and your development team’s clicks and views? This gem has you covered.

If you’ve ever developed a website with Google Analytics tracking code on it, I’m sure you’ve run into the problem before where you load up your development machine and start registering visits. Not ideal, especially if you start refreshing the page a lot. Or, even worse, frontend CI running after each commit… There’s an awesome Chrome plugin that solves this: Developer Cookie. It allows you to set a custom cookie value, so that if your machine’s cookie matches the value in the analytics script, it doesn’t register a click. Very handy.

In order to make this even more accessible, I’ve created a gem which lets you insert and easily configure not just the developer cookie functionality, but also Google analytics functionality. Configure a few environment variables, javascript_include_tag the analytics js and you’re off. I’ve also added it to the Base Rails 5 App.

Check out the github page for quickstart and a more detailed description.

Thanks for checking it out, and let me know if there are any useful things you’d like to see added to it.


Previous Page: 5 of 11 Next