There’s too much logic in this controller? This model has callbacks and observers?! Line 340 doesn’t seem to do anything at all. What am I looking at?

The sweat beads on your upper lip. You already assigned that task to yourself.

Take my name off it, pretend it never happened. No one will notice.

Sweeter temptations.

I can fulfill this ticket with only a couple of lines of code! It would be irresponsible to spend so much time on this when we can provide the user all the value with 1/10th the effort.

Out of the corner of your eye, you see the intern: Jessie. So young. So naive. So idealistic. What will they say when they see your PR? What kind of world are you leaving them? A world not worth living in? Not worth coding in?

No! I can do better. Be better. I’ll see this through to the bitter end!

So, how do we eat this elephant?

One bite at a time!

Exactly! Here’s your playbook:

1. Fully understand the code. State of mind is the key to success. Its difficult, but keep try thinking curiously, instead of judgmentally. Follow every rabbit hole, summon your limited social skills and actually talk to those whose names turn up on git blame. You know this is a mess and you’re doing god’s work to improve it, so whats the point of getting all worked up?
2. Write the tests first. Now that you understand the code, write and/or refactor the tests. Having proper test coverage will deepen your understanding of the nuances of the code and give you the confidence to make changes.
3. Code review early and often. The temptation to turn this into a Christmas morning for the team will be high, don’t opt for the big reveal, keep the lines of communication open. Make sure the rest of the team sees progress early, and often.
4. Test and deploy your changes without the new feature. I know, I know, the whole point of this was the new feature, but make sure the more readable, more maintainable and more scalable code actually works.
5. Write the feature. You did your job right, the new code is substantially more elegant and the task is easier to complete, test and deploy.

You did it! the repo is now in a better state than when you started, users have added value and the team is now faster and more agile than before.

Years from now, after you’ve passed into that great middle management team in the sky. Jessie will update the code to conform to the PanAsianEuroUnion’s privacy requirements, and they’ll ask their IDE’s AI, “Who wrote this?” And your name will be echo through the halls of Valhalla.

5 steps for fearless refactoring was originally published in WeWork on Medium, where people are continuing the conversation by highlighting and responding to this story.

For as long as I can remember, the de facto tagging library for almost every Ruby on Rails project has been Acts As Taggable On Gem which provides a simple interface to polymorphic-ally tag your models.

As excellent as acts-as-taggable-on is, FreezeTag offers some unique features which you may consider when choosing how to implement tagging in your project.

1. FreezeTag allows for a more “stateless” approach to tagging; tags are never deleted, instead they have an “expired_at” column, which is updated to make them inactive.
2. The associations are simpler; tags are held in a single table which holds the content of the tag (its name), any list it is attached to, and the association back to the model instance its attached to, which has some advantages including simpler querying, joining, etc.

Installation

Add this line to your application’s Gemfile:

gem 'freeze_tag'

And then execute:

$ bundle

Create the tables:

1. Run the installer:

$ rails g freeze_tag:install

This adds a migration to create your “freeze_tags” table

1. Confirm your implementation.

Since Freeze tags creates a polymorphic association between tags and models, its necessary to confirm the type of primary keys the models in your application use. Open the migration and choose the correct option for you.

2. Run the migration

rake db:migrate

3. Add:

include FreezeTag::Taggable

to the top of any model you’d like to start tagging.

4. Case sensitivity, add:

def self.freeze_tag_case_sensitive
  true
end

To your model. All tags, for that model, will be saved as lowercase

Tagging a record:

A single tag:

my_model_instance.freeze_tag(as: "Fancy")

Or apply multiple tags:

my_model_instance.freeze_tag(as: ["Fancy", "Schmancy"])

Or apply multiple tags and expire all other ones:

my_model_instance.freeze_tag(as: ["Fancy", "Schmancy"], expire_others: true)

There may be times you want multiple lists of tags, i.e. users with skills, AND hobbies:

All the same methods above work, simply pass a list as an argument.

my_model_instance.freeze_tag(as: "Web Design", list: "Skills")

You can also use the same style/attributes to tag while creating instances

my_model_instance = MyModel.new(name: "MyModelName", freeze_tagged: [{
  as: ["Cool", "Beans"],
  list: "Ideas",
  expire_others: true
}])

my_model_instance.save

Accessing tags:

All the current “active” tags as a simple array of strings.

my_model_instance.freeze_tag_list
["Happy", "Go", "Lucky"]

All the tags as a simple array of strings.

my_model_instance.freeze_tag_list(only_active: false)
["Happy", "Go", "Lucky", "Sad"]

All the tags, in a list, as a simple array of strings.

my_model_instance.freeze_tag_list(list: "Skills")
["Web Design", "Illustration"]

Active Record association of all tags

my_model_instance.freeze_tags

Active Record association of all “active” tags

my_model_instance.active_freeze_tags

You can change queries to the above to filter by anything.

my_model_instance.freeze_tags.where(list: "Skills")
my_model_instance.active_freeze_tags.where(list: "Skills")

Retrieving records that have been tagged:

Currently tagged with (only unexpired)

MyModel.freeze_tagged(as: "Fancy")

Previously tagged with (only expired)

MyModel.previously_freeze_tagged(as: "Fancy")

Ever tagged with (expired and unexpired)

MyModel.ever_freeze_tagged(as: "Fancy")

All the above methods work with a “list” argument as well

MyModel.ever_freeze_tagged(as: "Fancy", list: "Skills")

Accessing the model directly.

FreezeTag::Tag

Will give you direct access to the freeze tags table in a very standard way.

Introducing Freeze Tag: A gem for a more “stateless” tagging experience was originally published in WeWork on Medium, where people are continuing the conversation by highlighting and responding to this story.

Oh Amazon! The great provider of same-day-toilet-paper, second-day-flat-screen-TVs and most improbably: Amazon Web Services. Amazon’s commitment to Service-oriented-architecture has allowed them to make their in-house technologies available to less gargantuan engineering organizations.

This devotion to SOA has had some unforeseen consequences. Most notably the wacky, glitchy and sometimes painful UX that comes in the admin area of your AWS services console.

A more experts-only space is hard to imagine. Poking around here is likely to cause grief for you, your systems’ administrators, your security team and anyone else who considers themselves “DevOps” or “InfoSec”.

In other words, don’t expect a simple interface to make a simple, functional chat bot.

This brings us to the subject of this post: How to make, Lex, the natural language processing service, one of the newest, sexiest services, the service that powers Alexa, something you can actually use. This tutorial aims to get you started with an app which will act as an interface to manage a simple, FAQ style powered by Lex bot.

Part I: Create & configure your Lex bot

1. Login to your AWS console and navigate to the Lex interface

2. Create a bot

2.1. Give your bot a name, consider using “TestFAQ” which will allow you to follow this tutorial very closely.

2.2. Choose a voice, this bot functions as text-only, so it doesn’t really matter.

2.3. Choose a session timeout. I recommend keeping the default 5 minutes.

2.4. AWS helpfully chooses the IAM role, so no worries there.

2.5. Finally, since this example is not intended for children, we leave the “No” checked for COPPA.

2.6. Now click “Create”, like a boss.

Part II: Create an IAM service account

Your app will need programmatic access to AWS Lex in order to do its job.

NOTE: AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

1. Navigate to the IAM service

2. Select Users from the side menu, then click the “Add user” button

3. Name and allow programatic access for the service account

4. Give the account the AmazonLexFullAccess Policy

5. Finally review and create the account. Then grab the account’s Access ID and Secret Access Key. Store them somewhere secure for later access :-)

Part III: The Ruby on Rails backend

1. Clone this GitHub repository. This sample app contains lots of simple code to kick-start your project. You should consider all of this code boilerplate and don’t put too much stock in its structure or patterns. Make it your own.

2. Get it up and running in typical Rails fashion.

3. Set up the following environment variables using the aforementioned services account:

ENV['LEX_FAQ_AWS_ACCESS_ID'] # From above
ENV['LEX_FAQ_AWS_SECRET_ACCESS_KEY'] # From above
ENV['LEX_FAQ_AWS_REGION'] # 'us-east-1' or where you are :-)
ENV['LEX_FAQ_ADMIN_NAME'] # Basic Auth Name for admin panel
ENV['LEX_FAQ_ADMIN_PASSWORD'] # Duh

4. Create your first Answer via the console.

$ rails c
a = Answer.new
a.name = "First Answer Response"
a.utterances = ["Whats your favorite programming language?", "What do you like to program in?"]
a.response = "I like Javascript and Python, but Ruby is my favorite."
a.save

5. The answer model contains the code responsible for pushing to Lex:

def push_to_lex 
  begin
    data = { 
      name: self.lex_mapped_intent_name,
      description: self.name,
      sample_utterances: self.utterances,
      fulfillment_activity: {
        type: "ReturnIntent"
      },
    }

    resp = CLIENT.get_intent({
      version: "$LATEST", 
      name: self.lex_mapped_intent_name
    }) rescue nil

    checksum = resp.try(:checksum)

    if checksum.present?
      data[:checksum] = checksum
    end

    CLIENT.put_intent(data)

    bot = Lex::Bot.current
    bot.attach_answer_as_intent!(self)
  rescue => error
    puts ">>>>>>>>>>>>>>> #{error.inspect}"
  end
end

5.1. Breakdown: The data hash A simplified version of the payload outlined here.:

data = { 
  name: self.lex_mapped_intent_name,
  description: self.name,
  sample_utterances: self.utterances,
  fulfillment_activity: {
    type: "ReturnIntent"
  }
}

5.2. Breakdown: Does this already exist?

resp = CLIENT.get_intent({
  version: "$LATEST", 
  name: self.lex_mapped_intent_name
}) rescue nil

checksum = resp.try(:checksum)

data[:checksum] = checksum if checksum.present?

Checks to see if this intent already exists. If it does, it pulls the checksum and attaches it to the above payload. This updates the intent, instead of trying to create one with a conflicting name.

5.3. Breakdown: Put it:

CLIENT.put_intent(data)

NOTE: There is a lot more code in the bot and answer models that makes this work, so take a peek, the source is commented

6: Now actually push your Answer to lex

a.push_to_lex

7. Back to Lex, Use the auto-complete to navigate back to your Lex Web Interface.

7.1. Confirm your answer has been pushed and appears as an intent on your bot

7.2. Build your bot:

You can also build your bot via your Rails app by running:

Lex::Bot.current.build!

It can take several minutes for AWS to finish the build process.

NOTE: You won’t be able to “publish” your Bot until the build process is completed.

7.3. Publish your Bot:

You can also publish your bot via your Rails app by running:

Lex::Bot.current.publish!

Part IVa: The Rails front-end, User-facing

The sample app also includes a simple interface for potential users. So, if you haven’t already, start up your rails server and navigate to http://localhost:3000/.

Part IVb: The Rails front-end, admin interface

The second part of the front-end is the admin interface. Navigate to http://localhost:3000/admin/answers and enter the admin name and password you set in Part III, Step 3.

1. The admin home screen: A simple list of all the answers you’ve created.

2. Create a new answer via the admin interface.

3. Back to the Lex Screen:

Part V: The data flow

1. Text, a user_id, and an auth token are submitted from the client to your Rails app
2. The Rails app uses the AWS Ruby SDK to construct the appropriate payload and submit the text to Lex.
3. Lex processes the input and returns an “intent_name” in its payload.
4. The Rails app looks up an “Answer” based on the aforementioned intent_name.

Conclusion

I hope you found this tutorial helpful and you take from it inspiration to do even crazier things using Amazon’s incredibly powerful services including Lex.

Interested in joining our team? WeWork is hiring software engineers in Tel-Aviv and New York. View openings

Build your own chat-bot using AWS Lex and Ruby on Rails was originally published in WeWork on Medium, where people are continuing the conversation by highlighting and responding to this story.