Skip to content

All posts by moore - 23. page

The Rails Low Level Cache

I think the Rails low level cache is the bees knees. It lets you store complicated values easily, manage TTLs, and improve the performance of your application.

I’d be remiss in stating that you shouldn’t cache until you need to.  Caches will introduce additional complexity into your application, make troubleshooting harder, and in general can be confusing.  How do you know if you need to introduce a cache?  Profile.  Using rack-mini-profiler is a great quick and dirty way to profile your code.

The rails low level cache is fairly simple to configure (especially if you’re using a PaaS like Heroku–you can drop in a managed memcached service easily).

From there, you need to build a cache key.  This is a string, up to 250 characters in length, that uniquely identifies whatever you’re trying to cache.  Basically anything that would cause a change in the contents of the cached object should be included in this key.  However, since you are going to calculate this key every time the value is requested, you don’t want the cache key to be expensive to calculate, otherwise the value of the cache will be degraded.  Good things for the key: timestamps, max updated_at values for a collection, user ids or roles.

Then, putting a value in the cache is as easy as:

def pull_from_cache
  cache_key = 'mykeyval'
  myval = Rails.cache.fetch(cache_key, expires_in: 1.hours) do
      @service.build_expensive_object()
  end
end

In the case above, the cached value will automatically expire in 1 hour.  If you don’t set the expiration time, then the cached value will eventually be removed via LRU.  How long that is depends on the size of your cache and what else you are putting in there.

If you want to test that something is being put in the cache, you can run a unit test and see how many times build_expensive_object() is called.

#...
object.service = @service
expect(@service).to receive(:build_expensive_object).once
object.pull_from_cache  
object.pull_from_cache
#...

In a production troubleshooting situation, you may need to evict something from the cache.  You can do so from the rails console by finding the cache key and running Rails.cache.delete('key').

Using the low level cache is a great way to push read heavy hot spots of your rails application (database queries or other complicated calculations) into memory and make your application faster.

Online teaching tips for synchronous classrooms

I’ve been teaching AWS courses for the past year or so.  Many have been with an online teaching environment.  This opens up the class to more people–there’s less cost in taking a course from your office or living room, as compared to flying an instructor out for an on-site.  However, this learning environment does have challenges.  Below is my set of best practices, some suggested by other instructors.

Pre class:

  • Set up your physical environment.  This includes making sure you have a fast internet connection, a room with no noise, and that your computer and audio equipment are set up.
  • Set up the virtual room.  Load the materials, set up any links or other notes.  I like to run virtual courses entirely with chat (audio conferences are really hard with 20 people) so I make a note about that.
  • Test your sound.  This includes having a friend login and listen to you beforehand.  This run through can help make sure your voice (which is your primary engagement tool) is accessible to your students.
  • Email a welcome message to all the students, 2-3 days before class starts.  Include when the class is happening, how to get materials, etc.  I’ve definitely had interactions with students from these emails that led to a better outcome for everyone.

During class:

  • Calculate your latency.  Ask an initial question that requires a response as soon as the question is asked.  Something easy like “where are you from?” or “how many years of AWS experience do you have?”  Note the latency and add it into the time you wait before asking for questions.
  • Ask for questions.   How often can vary based on previous AWS experience, but every 5-10 slides is a good place to start.
  • Answer questions honestly.  If you don’t know, say so.  But then say, “I’ll find out for you.”  (And then, of course, find out.)
  • Allow time for students to read the slide.  At least 15 seconds for each slide.
  • You, however, should not read the slide.
  • Draw or use the pointer tool to help engage the students and pull them into the material.
  • Find out what students want out of the class.  Try to angle some of the content toward those desires.  You may be constrained by knowledge or time or presentation material, but you can at least try.
  • Engage your students.  I like to make corny jokes (“have you heard the one about the two hard problems in computers science?“), refer back to technologies they mention having familiarity with, and talk about internet kitten pictures.
  • Remember your voice and energy are the only things keeping these students engaged.

After class:

  • Follow up on any loose ends.  This could be questions you didn’t get answered or more mundane items like how they can get a certificate of completion.  I had one student who couldn’t get access to the materials and it took a few weeks of bugging customer service reps across organizations before he did.  Not a lot of time on my end, but a big deal for him.

Note that I didn’t cover the content or particular technology at all.  They aren’t really relevant.

 

Useful Rails Gems: Pretender

I’m constantly amazed at how productive you can be with rails. It simply lets you work on typical webapp problems at a much higher level. At 8z, we had a web application and a customer support team. Occasionally the customer support person had to ‘impersonate’ a normal user to troubleshoot an issue. We built a piece of software that let them assume that role. (We called it ‘sudo‘, obviously.) It’s been a few years, but as I recall it was complicated and error prone, lived on a different domain and wasn’t fully functional.

I needed to add similar functionality to a rails web app, and was able to find a couple of gems that looked useful. I selected pretender, mostly on the basis of documentation and google search results placement. I followed the instructions, tweaked a few settings and was off to the races in about an hour.  (Note this isn’t a fair apples to apples comparison of the underlying technologies, due to the differences in available open source libraries between the mid 2000s and the late 2010s.)

Now, all this gem does is what it says it does. It lets a certain user or set of users in your application pretend to be another user. It doesn’t handle auditing or anything else you might want with an elevated privilege system.

But it does do what it does well.

Ask the hard questions

Do you know that moment which happens at almost every meeting or conference call, when a participant refers to a concept that you don’t quite understand?  That moment happens to me often, and has throughout my career.

“The marketing funnel is part of the sales process.”

“We can just flurbuzz the bazznod.”

“We have plenty of runway.”

That is the moment when you can ask the hard question.

“Why is that connected?”

“What does that mean?”

“I’m sorry, I don’t understand.  Could you repeat that?  How do you define runway?”

Asking these questions is important.  Otherwise you and the other parties will be talking past each other, which will only lead to pain down the line when the misunderstanding is crystallized in people, process or code.

I’ve been asking these kinds of questions my entire career.  When I worked at a web consulting company in the early 2000s, there were often company wide conference calls discussing our precarious financial state.  I got a reputation as “the question guy” because I wasn’t afraid of asking the awkward question, even of the CEO in front of the entire company.  I was interested in hearing as real of an answer (as they could share).

If you’re interested in asking hard questions, here are some tips:

  • Pay attention beforehand.  If you are asking a question about something that was just mentioned, or that you should have known, you won’t have credibility.
  • Don’t worry about looking dumb (except if you weren’t paying attention, see above).  If it is a fuzzy concept, chances are others in the room are wondering what it is.  Besides, the goal is to increase your knowledge.  Check your ego.
  • Ask the question from a place of humility and make it about you.  Maybe you just really don’t understand.  I always like the phrase: “I’m sorry, I don’t understand what you just said.”
  • Approach with positive intention.  Don’t ask gotcha questions or try to prove you are smarter than the speaker.
  • If the answer is a bit fluffy or you don’t understand it, ask a second time.  “Thanks, but I’m afraid I still don’t get it.  Could you explain it to me again?”
  • If the speaker doesn’t answer or hedges again, offer to take it offline.  Depending on who is in the meeting, you don’t want to waste everyone’s time.  But then make sure you follow up.
  • Recognize if the topic is sensitive (financial matters) you may not get a clear answer.  At that point, getting the speaker to define terms but perhaps omit numbers is a win.

Again, the goal here is not to ‘get’ the speaker, it’s to help get everyone on the same page.  Asking tough questions to pin down some of the nebulous concepts we work with every day can help everyone make better decisions.

Reference checking: not just for VCs and employers

Fred Wilson has a great post on reference checking.  From the post:

The thing I have learned in thirty plus years of making reference calls is to pay attention to how things are said more than what is said. And pay particular attention to what is not said.

As always, there’s a number of great stories in the comments, including “warm up your network” when you are going to be referenced checked, and the story of a reference check poaching a candidate.

However, reference checks aren’t just for CEOs, hiring managers and VCs.  They are a powerful tool for job candidates.  It is tedious and time intensive, but is an additional source of information about a company for which you are considering working.  LinkedIn is in particular very useful here, because if you are thinking about working for company XYZ you can find out not only who works now for them, but also who used to work for company XYZ.  You can also find out who knows someone who knows someone who used to work for them.  Yes, this takes additional time, but if you’re going to be spending 40+ hours a week at a company, isn’t it worth gaining some perspective from people who are or were on the inside?

Consider it one more method of doing your research.

 

When doing a startup, don’t forget to calculate emotional runway as well as financial runway

When I joined The Food Corridor, the concept of financial runway was well known to me from my consulting days.  You figure out your monthly expenses, your savings, and any income you have coming in.  Divide your savings (or at least the amount you want to spend) by the expenses less the income, and you get the amount of time available to work on the startup before you run out of money.

You definitely want to pad this a bit, because if you run out of money, you’ll need some time to find another source of income.  You can also pad this with debt, selling other assets, part time work, investment, etc.  Heck, maybe the startup will even make some money too.

But the goal is to have an idea of how long you can go before you have to call it quits for financial reasons.  Then you can see if you think you can build the company in that amount of time.  (Hint, it’s going to take longer than you think to build the company.)

Emotional runway is another key aspect of surviving a startup.  Startups are full of a lot of stress.  Some examples:

  • Making decisions on limited data
  • Dealing with a product that is broken because of the speed at which you built it
  • Screwing up and apologizing to customers for said screwup
  • Dealing with financial uncertainty
  • Hiring
  • Firing
  • Limited or nonexistent support structure
  • Trying to figure out how to build a company
  • Personnel conflicts
  • Missing family time because of work
  • Lack of vacation/benefits
  • And, of course, the possibility of running out of money

All of the above make it tough to ‘tough out’ a startup.  These are all costs that you will have to bear.  Just like you only have a certain amount of savings to spend down, you also only have a certain amount of emotional wealth to spend.  (There are times when a startup will deliver emotional wealth too.)

One of the hardest parts of the current startup for me is keeping an eye on my emotional runway.  Taking some time off, celebrating successes, being open about the stresses with co-founders and family, and just being aware of what puts “money” into the emotional piggy bank and what takes it out are all ways I’ve dealt with this.

Railsconf Call For Proposals

Railsconf, a conference focused on, well, Ruby on Rails, is happening in Pittsburgh in April this year.  I attended last year and it was a fantastic experience.  I enjoyed the people I met, the problems I saw discussed, and the size and content of the presentations and workshops.  It definitely had a vendor experience (thank you, Heroku, for the t-shirts), but wasn’t too explicit.

Railsconf organizers are now accepting proposals for workshops, panels and speaking.  For some reason the CFP isn’t on the website, but I noticed it was announced via twitter.  I just submitted, so I can’t speak to the entire process, but the initial submission was pretty painless, just few sections on what you’re interested in presenting and why you might be a good fit.

They actually have a blind submission format, so I had to edit my initial submission to remove any reference to my identity.  Seems like a good idea.

So, go forth and submit!

Do your research

The internet makes some things frighteningly easy.  Trolling, for example.

But the fact it makes research easy is a win for everyone.  James Altucher has a post on how research helped him win a deal.  I remember when research meant you had to head to the library, look in a card catalog and/or ask a librarian, and skim through books.  If you wanted to take the information home, you used to have to check out the book.  Some books were too valuable to leave the library, so you had to make photocopies of relevant pages.

That’s all changed, obviously.  Now you can research a person or entity without leaving your home, though you still can leverage what libraries provide.  And you can research non famous people in far more depth than you ever could in the past.  When you meeting with a potential business partner, interviewee, or client, you can google the heck out of them.

The benefit of doing so is twofold.

  1. You have a better idea of how the person operates and how serious they are at whatever endeavor you are discussing
  2. You can connect to them and discuss their needs and ideas more intelligently

These are both worthwhile goals and will lead to better outcomes.  If you don’t do any research, that sends a message as well–“I don’t care much about this meeting” or “I’m too busy to do any research.”  That may be OK, but be aware that you are sending these messages.

So, if you want to do research on someone, how do you go about it?

I’d start with setting a time limit and a goal, otherwise you can get bogged down or sidetracked.  An example: “I’m researching this client and want to know their key business goal.  I’m going to invest an hour of time in this.”  Write this down, and check back in as you do your research to make sure you are heading towards your goal and not down a rabbit hole.

Then, start digging.  I used the term “google” above to refer to searching, but I’d suggest using more than one search engine, as they each give a slightly different view of the web, and I’ve definitely had useful results pop up from Bing or Duck Duck Go.  If this is a business meeting, LinkedIn connections can be useful.

If the client maintains a blog or social media account, spend some time reading that.  You don’t have to read every tweet, but getting a feel for what’s on their mind, especially in recent posts, can be illuminating.

The amount of effort to put into such research depends on how much it will help you and how important the interaction with the research subject is.  That is, if you are discussing going into business with someone, research the heck out of them.  If you are interviewing for a very interesting job, spend some time.  If, instead, this is a random coffee meeting, you may not want to invest any prep time.

You may find something disturbing in your research (a conviction report for example).  Integrate this into your decision making process, but be aware that the content may not be accurate, or may not apply to the research subject, or may be far enough in the past to be irrelevant.  Also be aware of any discrimination laws that may apply, such as employment laws.

If you find an interesting blog post or article that is relevant to my audience, you can promote it before the meeting (post it to Hacker News or Reddit, tweet it out).  Your research subject probably won’t notice, but if you’ve already done the research and found something of value, you might as well share it.  And on the off chance they do see the post, they’ll likely be flattered.

When the meeting occurs, feel free to casually mention some of the research.  I’ve been on the other side of it (someone read a blog post I wrote and mentioned it in an interview) and I can tell you it was quite a pleasant surprise.  And it can be a great starting point for a conversation.  But don’t get bogged down in discussing something the person wrote years ago, just use the research you found as a way to connect.

No matter how thoroughly you research someone online, realize that online we are all painting some kind of picture of ourselves.  Some people and companies are more transparent than others, but the mere fact that you have to pick and choose what to post means that you’re getting a curated view.  Non verbal communication matters too  If you’ve done the research, you’re ready to go into that meeting and take the connection and the relationship to the next level.