Serious Fox Labs

Curiosities, Technologies, Fartscroll, & More...

[seriousfoxlabs]

Dissecting Bugs - How critical is critical?

One of the biggest issues that can plague a support team is the difference between what you and your client deems a ‘business critical’ bug. As touched on in my last blog post ‘client transparency - when to respond’, what a client may see as business critical may not be your definition. 

Probably the most important ways to avoid this sort of confusion is to educate your client (no matter how technical they are) as to how your support team classifies bugs - including the difference between a ‘severe’ bug and a ‘priority’ one.

By having this conversation at the beginning of a support contract, you are explaining to the client what they can expect from your service. This takes out the guess-work for the client, creating transparency and an educated working environment. 

To ensure our clients are on-board and understand our support hours and response times, we include these (and their definitions) within the support contract. This mitigates risk should you have an unreasonable client - by signing the support contract they are confirming they understand and agree with the terms. But remember - this is also an agreement your company is making with the client. Do not put times within this section that you do not plan to uphold. It is a two-way contract, and good client services means delivering when you say you will. 

Below is our table of response times at Serious Fox - as with all rules there are exceptions. This table does not replace human interactions with your client. It is important to ensure your client understands how to properly define bugs, which means you may need to help them the first few times. While it may be slightly time consuming in the beginning, this will save a lot of hassle later and secure good client relations. 

Things to note:  *Meaningful Response’ does not mean acknowledgement of bug, but rather a response with substance (ie. explanation, bug fix estimate). This does not take place of the initial ‘We’ve received your email and are looking into it,’ which should be sent as soon as a bug is received.   *All ‘response times’ have ‘Working Hours’ after. As a company, you must remember to put working hours into your support contracts - unless you plan on being available 24/7. 

As a client-facing member of the team, communication around bug definitions will be crucial to scheduling their urgency. Occasionally you may find bugs that don’t fit into the chart above. Sometimes bugs that are a priority to the client are not crucial to the operating of the system. By working together with the client to determine the impact of the bug and understanding their reasoning, you can educate them on severity while understanding their priority - then make a scheduling decision you both can be comfortable with. 

In summary, 'Communication' and ‘Clarity’. By communicating with the client and offering a clear definition of response times before a situation arrises, you create a more controlled and less panicked-driven working relationship. And to be honest, you’ll probably keep more support contracts and clients. 

Until next time, 

Allison

[seriousfoxlabs]

Client Transparency: When to Respond?

The other day I was doing some research on what other companies do for ‘timings of response.’ At Serious Fox, we have a few different project types that range from development to support and maintenance. This broad range of product puts the company in a interesting position when it comes to resourcing and response times - do you take a developer off a project to handle a support request, or do you schedule support time in each day to handle requests - knowing that time might not be used? (How to schedule resource for your office will be a subject I talk about in a future series of ‘running an efficient office’.) More specifically, how do you mitigate client relationships around this? 

At Serious Fox, we have two developers who are not scheduled at full capacity (most of the time) to ensure that they are available to handle urgent support request. This is done in hopes that any support request that need to be handed within a certain time frame can be done with little-to no- impact on other project’s sprint cycles. While this isn’t always the case in extremely busy times, it does allow for some flexibility when needed. 

What is ‘urgent’? 

This term brings us to the subject of this blog. What is defined by ‘urgent’ to a client is rarely ‘urgent’ to the development company. Generally, there is not a difference in this definition due to client-company maliciousness, but rather that to the client - this is their priority, while to the development company they have several other bugs that may be more business critical to their other clients. 

So how do you manage your own priorities while still making the client feel like one? One blog I read a few weeks back recommended that you use an ‘8 hour rule’ to set client expectations. When I first started reading the blog, I thought perhaps it was a ‘8 hours to fix a bug’ - but it wasn’t, they refuse to respond to any clients request until a 8 hour window has passed. As a client services representative, I gasped at this rule in horror. The few horrible clients this person has come across has tainted the experience for positive client relationships this company could have. At Serious Fox, we are all about trust and transparency, and implementing an ‘8 hour rule’ would definitely not be a trustworthy or transparent way of working. 

As we have a Client Service representative at Serious Fox (me), we can dedicate time to making our client relations a bit more client friendly.  It’s our policy (and recommendation) that no matter how insignificant a client request is, they get an email back that acknowledges the receipt of that email - even if all our response says is ‘Hey, we’ve seen this - and we will get back to you on it in a few days.’  It may not be exactly what the client was hoping to hear, but at least they know you saw the email and it wasn’t lost in cyberspace. 

As unlikely as an email getting lost in cyberspace (or junk mail) is - a lot of clients do worry about it. 

In this blog post about the ‘8 hour rule’ the author referenced the fact that they got 2 emails in a few hours. In my experience this is the cause of hours passing with no acknowledgement that the client is having a situation - even an insignificant one. In a world where most people are used to ‘instant gratification’ of texting, social media, etc. it’s no wonder we (both client and company side) get impatient with a lack of quick email response.  So, while we may not be able to immediately investigate a bug that is determined non-business critical (even though to a client, every bug might be seen as business critical) we will at least send the client an email acknowledging that we have seen the issue. This is important in maintaining a healthy relationship with the client - while it may not be the first thing on our to-do list, we will follow-up response in a reasonable timeframe. And while we may not be able to give them the instant or quick-fix they are asking for, we will let them know when we can get to it - which will at least help put the mind at rest that it’s being taken care of. 

Next week I’ll be discussing how to avoid the lack of understanding of a ‘business critical’ bug. 

Until next week, 

Allison

[seriousfoxlabs]

Is Client Transparency a Good Thing?

This is the first post in our Client Transparency Series

One thing I’ve always believed in, maybe to a fault, is client/company transparency - complete openness about the good and the bad things that come along in a project.  This is one of the reasons why I joined Serious Fox, I knew the company shared my client service values, as unconventional as those values are. From our point of view, there are three main areas of transparency: Price, Timings and Development Progress. We believe being open with a client around these three areas builds trust, and as most people know trust is the key to happy working relationships and creating workplace based in collaboration.

Obviously there is a lot of risk with complete transparency with clients. A lot of agencies I’ve worked in run from this kind of open/frank communication because with complete honesty comes the risk of having to admit that your company did something wrong, charged too much, or perhaps even worse - promised something that couldn’t be fulfilled. At Serious Fox, our point of view is that this risk comes with some pretty significant benefits. There is something to be said about gaining a clients trust, knowing that you can be honest with them about the good and the bad. By being honest about a project that will take little time and money (versus trying to milk the client for more money) means that when that timely, expensive project shows up - the dreaded time/price negotiation is minimal because the client trusts you are being honest.

This sort of transparency does put an Account Manager into some pretty difficult positions. Just the other day, I had to throw my hands up and admit a company mistake. We under-estimated the time it would take to fix a bug, and in turn we were going to go over on budget and missed the deadlines. While in the past I was coached not to admit blame, or try and dodge the subject, I took it upon myself to expose the real cause of the problem, which was our estimate. If you work in the development world, you know these things happen almost too often. Estimates are based on little investigation, and it isn’t until you really get into the code that you will realise how much time it will actually take to fix a bug - or create that new feature. It’s also one of the hardest situations to explain to a non-technical client. Normally in these situations, you either damage client relations by demanding more money for resource - which is above what you quoted and approved. Or, you end up fixing it for free - which means you have lost revenue and potentially set-up the expectation that these things will be fixed for free going forward. What was the outcome of this conversation? While the client was disappointed, we both agreed that estimates needed more investigation time - and a better, more efficient work flow was established for the two companies. 

Now I do realise that this is a bit of a ‘in a perfect world’ theory. Just as developers and account managers have been burned by clients - clients have been burned by companies. It will take quite a lot of work to earn the trust of some clients, and some trust may never be earned. But at the end of the day, Serious Fox will always walk away from a situation knowing that we did our best and told the truth - and whether or not the client wanted to believe us, that was the situation. In my experience, this has worked more times than not, and I have several life-long friends who used to be clients (or even still are). My hope is that through this way of working, we can stop arguing over timings and prices with our clients, and walk away at the end of the project with both parties feeling that they got a fair deal.

Over the next few weeks I’ll be taking a look at the pros and cons of transparency in the areas of Timings, Pricing and the Development Process.  Stay tuned!  Allison

[seriousfoxlabs]

Protip: Pasting code in Vim

On Ruby Rogues a few weeks back, Ben Orenstein mentioned he tries to spend 15 minutes a day improving his workflow and tools. I decided to take this onboard and this week I looked into how to paste code in Vim without loosing its indentation.

1. Turn off autoindent.

:set paste

2. Paste code

3. Turn autoindent back on.

:set nopaste

I found the solution here.

Enjoy Alex

[seriousfoxlabs]

Rails Performance: The Database

My primary toolkit is the Ruby on Rails framework, and I mainly work with applications that have been in production for a while, which usually means they're in need of a little pick-me-up. I thought it would be good to write a mini series about the things I typically look for when developing and maintaining Rails apps.

Picking up a Database

When I start working on an app with history the first thing I do after bundling and running the test suite is create a diagram of the database. This used to take up lots of time because I was doing it by hand, but recently I have been using rails-erd to automate the process.

Running "rake erd" creates a pdf based off the applications models.

This is a massive timesaver but it does take away the process of building the ERD diagram - which is invaluable for pointing out red flags such as associations that are not needed and fields that are no longer used.

At secondary school I was lucky enough to take a Oracle certification in database design, and one of the core things we learned was Database Normalisation, which came with a set of guidelines for creating good databases. 

The guidelines are broken into stages:

First Normal Form (1NF)

Related data should be grouped into separate tables, there should not be duplicated fields in the same table and each row should have a unique key (Primary Key).

Second Normal Form (2NF)

Separate fields into a new table that apply to multiple rows.

For example: if you have a projects table, the client should be in their own table so that when you update their address you only have to do it in one place, not in 10.

Tables should be related to each other using primary and foreign keys to join the related tables.

Third Normal Form (3NF)

Ensure the columns in the table are dependent on the primary key.

For example, if you have a teacher who is part of a department, they should be in separate tables because department is it own entity that can exist even if it hasn't got any teachers.

Fourth and Fifth Normal Form (4NF)

Both fourth and fifth normal form discuss multivalue dependencies, which in Rails-land are Has and belong to many and has many through.

For example: a skill should not be stored in the same table as a user.

The Rails framework is pretty good at ensuring that these guidelines are followed, the generators automatically create a primary key, if you use the references migration type it will automagically set up the foreign key relation.

These rules are definitely more of a suggestion and in some cases can be ignored if there are good reasons to do so: one example is optimisation. By storing all of a users skills as a serialised array in one field you could speed up a request by removing the need for doing a SQL join.

I glossed over some of the finer details, so if you are interested in finding out more on the subject, a great technical paper to read is A Simple Guide to Five Normal Forms in Relational Database Theory. If you prefer lighter reading the about series is pretty good.

Alex

[seriousfoxlabs]

SaveAs with Ruby on Rails

Last week while working on a project I had to implement a new feature which allowed users to save as when editing an existing project.

At first i decided i was going to create some entirely custom controller actions for that, but I soon had realised the complexity of the task. Alex then came up with the Deep Cloneable gem for me to use, and I have to say this has been a very handy one.

This gem extends the dup method allowing you to select precisely which attributes and relations you want to be cloned.

@project.dup include: {milestones: :tasks }

Here is how we built it:

1. Install the gem Deep Cloneable

2. Create a controller action.

#post method def save_as @cloned_project = @parent_project = Project.find(params[:id]) @cloned_project.assign_attributes(params[:project]) @cloned_project = @parent_project.dup include: { milestones: :tasks } if @cloned_project.name == @parent_project.name @cloned_project.name = "#{@parent_project.name} (copy)" end if @cloned_project.save! redirect_to projects_path else render :edit end end

3. Let's Clone!

Marin

[seriousfoxlabs]

Rails ProTip: Stop generating empty files you are not gonna use!

I regularly work on projects where there are default pending specs and helpers/assets that are empty. This is bad for two reasons: firstly RSpec and the Asset pipeline still check/load these files which slows things down, and secondly they make the project harder to navigate.

I recommend adding this too your application.rb today!

config.generators do |g| g.test_framework :rspec, views: false, routes: false g.helper_specs false g.stylesheets = false g.javascripts = false g.helper = false end

Alex

[seriousfoxlabs]

Bourbon Neat with default column dropping - UPDATED

We decided to move away from heavyweight class-based frameworks (like foundation/bootstrap) because 

We're wasting a lot of time just having to overwrite the default styling. 

Sometimes class-based grid systems make a designer do this: 

(Bootstrap isn't really to blame but it can make things more complicated than they need to be)

So we settled on bourbon neat - it's got exactly what we needed - a grid that we can customize on a per project basis. 

Weaning yourself off Bootstrap can be hard, especially since it is pretty much invaluable for fast prototyping. The one thing I missed the most was not having to worry about my media-queries when it came to columns in a layout - and Bourbon Neat didn't seem to come with this feature by default. So I came up with a little workaround. 

Probably not the official way to do it, and if you find a simpler way, let me know! 

I was trying to get my columns to drop to full width on resize like they do in http://neat.bourbon.io/examples/ without having to write

@include media ($breakpoint-variable) { @include span-columns ($breakpoint-columns); }

on every div that I wanted to drop to full width by default on resize, so I came up with a neat little workaround: 

@mixin col($col-no, $shift-no, $media, $drop-to, $shift-to) { @include span-columns($col-no); @include shift($shift-no); @include media($media) { @include span-columns($drop-to); @include shift($shift-to); } }

Why all the code? Well, ignoring shift will cause major problems if you have collumns within the same outer-container - having the shift outside of this mediaquery definition will offset the next container with an uneven percentage, making it impossible to align any of your columns properly.

(P.S I suspect I will run into some snags with this solution as well, as my initial attempts at creating this function led to a lot of bafflement with the shift problem, but for now it's the best solution I've found)

it will give you a nice bit of control, so for example, this is how we make a 6 column wide div, shifted by 2 columns, that drops to a  5 column with no shift on a tablet screen:

.div { @include col (6, 2, $tablet, 5, 0) }

Bang tidy. 

[seriousfoxlabs]

Why Multilayered Concepts Matter - The Who

For those of you who haven't read the first part of this series, you might want to have a look at the first part - the why. 

To sum up, this series is about building up a solid and thorough concept for your projects and products, through thinking about it as a concept with several different layers. The first step of the process was to ask yourself "why" - Why does anyone need this? Why should it exist?. The first step is often the hardest step. Having your precious idea smothered at birth by an avalanche of cold-hearted logic can be a tragic experience. No matter. You will have new ideas. Hopefully better ideas.  

Why your user is not everyone

Now that your idea has gotten through the crucial yes or no stage, it is time to improve it. One of the best things to start with is asking "Who?". Who is your user? Don't say everyone. Never ever say everyone. 

Even things that are used by everyone are not designed for everyone. Let's look at something everyone uses  - a toothbrush. Even a toothbrush is not designed for everyone. Children need smaller toothbrushes. People with dentures need special toothbrushes. People with different dental needs all need different toothbrushes - big, small, pointy, soft, hard, round, square - I digress. 

If you are thinking "yes but the basis of the toothbrush is still applicable to everyone" and you are right. If you wish to create something that everyone can use, design in pieces - design something that can be altered and added to and personalised so that everyone can eventually use it. But even then, your base-skeleton piece will still not be designed for everyone. And unless you're designing for something as universal as brushing your teeth, you will never have everyone use your product. 

The lesson being - pick a target user group. Don't make it too wide. Don't make it overly specific.   

When you design for a target group that is too wide you water down the concept - and run a huge risk of not appealing to anyone. When you know what kind of user you want to aim your product at, you can start honing in on what they would want, what they would need in a product. You can form a real connection with your user - appeal to their tastes, cater to their needs. 

How to find your user

There are many ways of defining a user, but here are a few questions you might want to ask yourself (and others): 

What age range are they in?

What gender(s) are they? 

Where do they live? 

How much money do they have? 

What is their level of education?

Are they single, in a family, a couple, a group?

What kind of occupation do they have? 

What topics interest them? 

What's really, really important to them? 

How technology-literate do you think they are?

What cultural influences and movements are they a part of?

You don't have to answer all of the questions to immaculate detail - but have a firm, solid argument for at least 5. 

As long as you have a very good idea of what group or groups of users you are aiming your product or service at, this will help you make productive and informed design decisions in later stages of development. 

This is not about being a eugenicist and bereaving whole groups of people of your services - it's about being smart. It's about creating healthy limitations.

It's often also not about who YOU want to use your product - it's about who it could be most useful for. It is rare to have a user before you have an idea, so a lot of this is reverse engineering your idea into a user with a need. Don't be self-centered. If your target user is other people that are like you - be honest. Doing a project for yourself is completely fine, just recognise that you are building for a very specific user - yourself, and the handful of people who are likely to be exactly like you.  

The other trap

This leads us nicely into the other big trap - overly specific target users. If you only want a handful of users in an extremely specific niche, then there is no shame in going specific. If you're aiming to get a larger audience, there's no point designing for an overly specific user profile. If you find yourself designing a service for Bill, 42, who wakeboards on Sundays, works in a bank, has a loving wife and a mistress on the side who he feels guilt about and does not really have the money to keep it a secret - well… lets just say fiction for the sake of fiction isn't going to help you very much either. 

Why you need to know your user

Finding your user is an exciting thing - it's the step that can open up completely new doors and help you create features you'd never thought about before. Having someone to design and build for gives you purpose, and an idea of who to ask when you need some direction. Having a user will help you decide what your product should look like, feel like, and be like to use. 

Remember that this ideal user is only a fantasy. It is impossible to completely predict how users will behave with your application, and you might end up with a large user base that is not at all what you had designed for. This is just the way things go, but having a defined user base for your concept will give you the constraints that help you move your project forward. 

Having an idea, understanding why that idea is a good idea, and deciding who the idea is for is really the biggest part of working out a concept. From then on, the evolution of the concept is both easier and quicker. 

[seriousfoxlabs]

Setting up Logwatch to email logs using Gmail

I thought I would share this quick guide to setting up sending yesterdays logs without needing to install Sendmail or another heavy weight email client.

Step 1. Install our lightweight SMTP client.

sudo apt-get install ssmtp

Step 2. Configure our client to talk to Gmail.

sudo vim /etc/ssmtp/ssmtp.conf

The config for Gmail should look like this:

root=YOUR_EMAIL_ADDRESS mailhub=smtp.gmail.com:587 rewriteDomain=YOUR_EMAIL_DOMAIN AuthUser=YOUR_USERNAME AuthPass=YOUR_PASSWORD FromLineOverride=YES UseTLS=YES UseSTARTTLS=YES hostname=smtp.gmail.com:587

Step 3. Check your configuration works

cat - | /usr/sbin/ssmtp -v

Now press ctrl-d and you should see something like this:

[<-] 354 Go ahead l4sm46964373een.13 - gsmtp [->] Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 03 Dec 2013 14:40:08 +0100 [->] From: YOUR_SENDER_EMAIL [->] Date: Tue, 03 Dec 2013 14:40:08 +0100

You also should receive an email.

Step 4. Install Logwatch.

sudo apt-get install logwatch

Step 5. Check if logwatch works with ssmtp.

sudo logwatch --detail high --mailto EMAIL_TO_SEND_TO --range yesterday

You should now get an email containing yesterdays logs. Last Step! setup a cron task to send your logs every day.

sudo crontab -e

Your task should look like this:

# m h dom mon dow command 0 1 * * * logwatch --detail high --mailto EMAIL_TO_SEND_TO --range yesterday

Enjoy!

[seriousfoxlabs]

ProTip: Reactivating iectrl vm's

If you are using iectrl to manage your Internet Explorer vm's and have had your XP activation expire, you can reactivate by running the command below:

iectrl reinstall 6,7,8

[seriousfoxlabs]

Why Multi-Layered Concepts Matter - the why

Defining "Concept"

"Concept" is a pretty vague word - more often than not used in places where it doesn't really belong. it can be a vision, an ideology, or even used to describe something unfinished. In this article, I'll be using it to describe the driving ideas behind a project or product. 

"Concept" is difficult to define for a reason: it's not one single entity, but rather a collection of ideas that come together to form a coherent picture. Take Meta Trails - you could say that the general concept behind it was to create a new type of learning experience. But obviously, that isn't the whole story. We have established the first layer of the concept - the coating that will cover the entire project, if you will - now, the Multilayered concept comes into play. 

Adding Depth to Concepts

You start by adding some depth to this idea. 

Why is it needed?

Who is it for? 

What does it do?

How does it do it? 

When is it needed?

 If you've thought about your idea for very long you may already have the answers to each of these questions - but you have to recognise them as separate layers of your concept. These questions determine what directions you head for in the development process. 

Why

Too often we can get bogged down in functionality without first understanding the ideas that are driving us to create that functionality. It is easy to have a basic idea - just realising there is a niche for a certain functionality. In our case, we realised that there was a niche for creating a self-learning application that would be more focused on showing the progress of the learner.

To some extent we have our why: no other service filled this exact niche.

Let's be honest though - the fact that something does not exist does always not mean it should. (see grilled cheese cookies). 

thinking mm? recipe here

So even though you've found your niche, you still need to justify it. Is there a genuine need for the kind of service you're providing? Are there many similar services that fulfil that need?  Try not to just follow the cultural zeitgeist of the day - it temporary, and it's often already been done.

How often have you heard someone say I'm going to make the next (insert popular web service here)? Often it's just because that service was successful, and they want a slice of that success.

If there is no more depth to a concept than that, it's usually doomed to failure. I'm not here to step on anyone's dreams - but really. It's very likely. 

Will it last?

With MetaTrails, we realised that people are more likely to try to teach themselves tech-centric skills than get a formal education. Since these skills are always evolving, there will always be something new to learn, even for those who did do a formal education.  This creates a continuous need.

Is it needed?

There are numerous services providing self-teaching resources, so we wanted to find another aspect of self-learning - learning progress. Why? Because getting an education is both about resources and feedback. Encouragement can help a self-learner keep going. If you give them an incentive, making a mildly game-like interface for their self-learning, it might help keep them going. 

You need to fully believe that what you're doing will make a difference to the area that you have chosen. A good difference. Something that will genuinely be useful to your intended audience. 

Let's Recap the process for Why: 

1. Find a niche for a functionality 

2. Understand if it is a temporary or lasting niche 

3. Justify why that niche should be filled 

Why is often the first step in the process, since you won't need to work out any of the other questions if the general concept fails at this stage.

Now we can move on to the other questions, which don't need to be asked in any particular order. But since I've already raised the topic, we'll start next week with: Who

If you're curious about Metatrails have a peek here  

[seriousfoxlabs]

A better way to handle SSH keys

I pair with quite a lot of developers and one thing I have noticed is most of them only use one SSH keypair for all of their services/servers. This isn't the worst security threat out there but it does pose a significant one. Also it is pretty inconvenient if your public key gets stolen like in the recent CircleCi attack as you need to change the keypair on every service you use.

A multi key setup is pretty easy to implement:

Step 1. Create somewhere to store the key:

mkdir ~/.ssh/github

Step 2. Create the SSH key:

ssh-keygen -t rsa -f ~/.ssh/github/id_rsa -C "github key"

Step 3. Add the key to your SSH config:

vim ~/.ssh/config

Host github.com User git IdentityFile ~/.ssh/github/id_rsa

  Note: you don't have to include a user.

Step 4. Test

ssh [email protected]

[seriousfoxlabs]

Rails tip: Titleize acronyms

I ran into a problem whilst trying to titleize a string containing an acronym. For example:

"building an API".titleize

Will output

=> "Building An Api"

Not exactly what I was after but with a small change to the Inflector class you can define your own acronyms.

config/initializers/inflections.rb

ActiveSupport::Inflector.inflections do |inflect| inflect.acronym "API" end

Now:

"Building An API".titleize