Learning: More Tools To Keep You Moving Forward

So, you’ve been working really hard. You are able to check everything below off the list…

• Involved in the community
• Setting goals
• Doing something every day
• Try ruby
• Ruby in 100 minutes
• Read Why’s poignant guide to Ruby
• Learn Ruby the Hard Way
• Ruby monk
• Ruby Rogues (listened to at least a few)
• Learn to program by Chris Pines

First off, if you were able to cross all those things off the list then seriously, great job!! You’re doing a lot, you’re working your booty off, and hopefully you’re feeling good about it. At this point, you should take a few minutes to take a look back at what you’ve accomplished. Think of everything you’ve learned and everything you didn’t know a few weeks ago. Smile about it, do a mini celebration, and get excited for the rest of your journey.

Here’s the next step… read Practical Object Oriented Programming in Ruby (POODR) by Sandi Metz. It’s amazing and you’ll want to reread it and keep it to refer to in the future. And start watching talks for past conferences. Confreaks is a great site that has talks from all sort of past Ruby conferences. It’s a great way to learn about new things that you might want to look into in the future (or now!). That’s all for now. Read that book carefully to really absorb everything, watch the talks to get inspired, and the next post on learning will be moving on to incorporating Rails!!!

Interesting Reads from the Week

I'm trying something new. I'm going to try to post interesting articles I've read (or meant to read) during the week every Friday. These articles/talks/blog posts/etc. may not have been published this past week, but it means I read or watched them this week. I'll try to also post who I heard about them from, but I didn't note that this week, so it'll be just the things I read for now.

Enjoy!

The Taxonomy of Terrible Programmers

Pairing vs. Code Review

Sublime Text Tips and Shortcuts

The Unreasonable Effectiveness of TDD

How Developers Stop Learning: Rise of the Expert Beginner

More Bot Bits

The final component of bot functionality was setting up the database. This was really the thing that I wanted to gain some experience with and by setting up a database not in a rails application, I was able to understand some of the components a bit better. For my purposes, this database would be used to keep track of points. Often times, people will award other people points based on funny or interesting things they post. They’ll also subtract points for things but in the past, we’ve had no way to keep track of this. This bot added the following functionality: adding and subtracting points, telling a user what their score is when they ask, and printing out the leaderboard when asked.

First, Chris and I chose a database. We decided to go with Sequel because it looked pretty interesting and simple to set up. I set up the connection first that created the database but then moved that into a separate file. This way I have the option to run the create table script only when I want to create a new database table. Then I set the database connection as a global constant like this DB = Sequel.connect('sqlite://bot.rb') to get things going and set out to write the related methods.

The first method looks to see if a nickname is already in the database or if we need to add it and acts on that.

def nick_id(nick) 
  set = score.where(:nick => nick) 

  if set.empty?
    nil 
  else
    set.first[:id] 
  end
end

So, we set the variable set which find the list of every score that has the nickname nick (nick being whatever the person’s nickname is). Then, if it doesn’t find anything, then it will return nil. Otherwise, the methods grabs the id of the first matching nick it finds with that name and returns it.

The second method inserts or updates the score.

def insert_or_update_score(nick, points)
  nick.downcase!
  if nick_id(nick)
    row = score.where(:id => nick_id(nick)).first
    updated_points = row[:points] + points      

    score.where(:id => nick_id(nick)).update(:points => updated_points)
  else
    score.insert(:nick => nick, :points => points) 
  end
end

So, first I need to make sure all the nicks are being evaluated in the same way. I discovered this when testing and found that two different nicks would be saved in the database based on if they were capitalized or not. Then, this method needs to fetch a record, then increment the number and then save it back. If there is no nick, then it creates the new nick in the database and gives it points.

Finally, I wanted to be able to lookup the score and if someone has no points then the method throws an exception.

def lookup_score(nick)
  score.filter(:nick => nick).first[:points] 
rescue 
  nil
end

I added a rescue so if there are any exceptions, the rescue catches the exception and returns nil. Chris warned me that when looking at future projects, the rescue option can be dangerous because it can hide serious errors but for our purposes, using rescue is perfectly acceptable.

THEN WE REFACTORED!
Setting the database connection as a global constant is not a good idea and having all of these methods in the main file just make it messy and unorganized. First, I changed the database connection to an instance variable by putting it into a singleton class and initializing it.

require 'singleton'

class DB
  include Singleton
  
  def initialize(file = 'sqlite://bot.db')
    @db = Sequel.connect(file)  #setup the DB connection
  end

This meant that I also had to change all of the DB[:score] instances in the code because it was now @db. Then, instead of just putting @db in each place, I extracted it into a method that does it for us.

def score
  @db[:score]
end

And that is how I set up the bot’s database.

IRC 101

IRC, internet relay chat, is one of the ways developers communicate… and something that can seem a little confusing when you first start, so here’s some IRC 101 so the next time everyone's talking about it, you'll know what's going on.

First, what is IRC? It’s basically internet chat rooms. A lot of people probably want to yell at me for that simplified explanation, but that's pretty much what it is. There are lots of different rooms based on lots of different topics. You pick a nickname when you join and then you can join different rooms and chat with people. You can also run your IRC configuration on a server which enables you to stay connected when you close your computer and read back when you are back at your computer with some time.

I personally don’t hang out in too many rooms. I’ve found that it’s also helpful to ask someone “in the know” about these channels. Some channels are super friendly. Others are really good about answering questions on specific topics or functionality (like the Pry channel). More are based around open-source projects (like the Spree channel). Finally, some channels are really unfriendly and people are kinda mean. I avoid those channels for obvious reasons.

Next, there are a few different ways to access the IRC servers. Some are more complicated and some are less. I, personally, use irssi, which accesses IRC via the terminal but can be a little complex to set up. I enjoy using irssi, however when people post gifs, they don’t show up inline, which means you have to click on them to see them, which can be a little annoying sometimes. Other options include Textual, Limechat, and Colloquy. There are various free trials and free versions, but a few are paid for. Here are some set up options from Chris and Sean . For irssi in particular, in addition to Sean's set up there are lots of additional scripts you can run to make lots of stuff happen including styling of the window, colors, replies, links, and much much more. Here's a pretty good guide to using irssi and here's an additional article abut IRC in general written by Spree Commerce. The Spree article gives even more options for accessing IRC.

Now for some basic functionality tips and tricks. When you want to join a channel, you just type /join followed by a space and the channel name. To direct a message to a specific person, just start the message with their nick name. You can even start by typing the beginning of the nickname and pressing tab to complete the name. To put yourself into a reply (like *allie_p goes to make coffee) just type /me in front of what you want to post in the chat. Finally, to send a message to someone just type /msg followed by a space and the nickname of the person you to message followed by the message you want to send. The message to that person will show up in a new window. With IRSSI, you can have multiple windows open (which means be in multiple rooms or conversations) and you can switch back and forth between them by pressing CTRL P or /win 3 (or whatever window you are trying to get to). To scroll up or down in a conversation, you use FN and then up or down arrows.

Final tips and tricks… check out http://textfac.es to learn about the weird faces you may see in the channels (I still don’t really understand half of them) and reacting gifs for great gifs to post in response to things.

If you’ve got more tips and tricks, feel free to add them in the comments!

Look what my Bot can do!

It’s amazing what a little chatbot can accomplish. It can make your day much brighter and more fun!! So, let’s talk about what Rosie can do, because it’s a lot.

So, first, Rosie can do some of the standard things like reply with gifs about coffee, District Taco, and lol’s. She also responds when you say good morning so that everyone every morning gets a fun response. She reacts to you when you say you love or hate coding, and she’s all about refactoring.

Those commands are accomplished via regular expressions. Regular expressions are a concise, flexible way to pick out specific words, phrases, characters, etc. Regular expressions look really terrifying when you first encounter then, but are actually really handy and not so scary once you get a handle on them. Based on Nell’s talk/suggestion at RubyConf, I made a permalink for each regex and put it as a comment in my code so I can always go back to it later. I used rubular when crafting the regex’s which made them a breeze. (Okay, not a breeze at first, but made it much easier to learn and figure out what each character did and how it altered what I was trying to do).

The next set up functions are random things that Rosie will say periodically.

on :message do |m|
  if rand(500) == 0
    m.reply "SQUIRREL!"
  end
end

This basically say that for each message sent, the script will see if that number matches 0 and if it does, then the bot will reply with “SQUIRREL!”. There’s another one of these built in there as well, but people will have to wait to see what that is.

Finally, there are some responses where rosie can choose to respond as a reply or as an action.
These options look like this:

on :message, /#{config.nick}\?/i do |m| 
  response = [
    [:reply, "Did someone ask for me?"],
    [:reply,    "http://31.media.tumblr.com/fe021d747a605a8a7cba5767011251e1/tumblr_mjpo4q44aj1rjatglo1_500.gif"],
    [:reply, "what do you want now?"],
    [:reply, "#{m.user.nick}, why are you bothering me?"],
    [:reply, "it wasn't me."],
    [:reply, "yyyyeessss?"],
    [:action, "hides"],
  ]
  msg = response.sample    
  if msg.first == :action   
    m.channel.action msg.last 
  else
    m.reply msg.last  
  end
end

So, each line…
The first line says that on the message whatever the configured nickname of the bot is (meaning that I can change Rosie’s name and the regex will still work) followed by the “?” then (next line) Rosie will reply with one of the options in the array. The next few lines show the options that Rosie can reply with and whether they are a reply or an action. A reply would look like this:
Rosie: It wasn’t me
While an action would look like this:
*Rosie hides
Then, msg = response.sample says picks a random value from the message array. (Next line) if the first element in that array is an action (:action), then (next line) add /me to it when it replies in the channel. Otherwise, reply like normal.

The next post will talk about functionality that incorporates some more complicated methods and a database!

Because it's been a little while... Here's another Euler!

Project Eulers 7 and 8

Just a few more Euler’s left and I realized the other day how long it had been since I’d posted some answers! I’m also posting both 7 and 8 because really, problem 7 uses the prime library again, so the answer is really short and sweet.

So, first, here is the problem:
By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6th prime is 13.

What is the 10 001st prime number?

First, here are the tests:

require 'problem7/problem7'

describe 'Prime number positions' do 
  
  it "is the 6th prime number" do 
    expect(Problem7.prime_place(6)).to eq 13
  end

  it "is the 10001st prime number" do
    expect(Problem7.prime_place(10001)).to eq 104743
  end

end

The tests and the code are pretty simple. You’re just using the resources in the prime library and then use the library to list (take) the numbers up until a certain position (ie- the 10,001st position) and then put the last number which is the answer to the question. So, here’s the code:

require 'prime'

module Problem7

        def self.prime_place(position)
          prime_place = Prime.take(position).last
        end

  puts Prime.take(10001).last

end

And now for Euler 8. This problem was actually really tough for me for two reasons… first, it seemed different than most of the others I had done up until now and second, how the heck do you test this thing?!

Here’s the problem:

 Find the greatest product of five consecutive digits in the 1000-digit number.

 73167176531330624919225119674426574742355349194934
 96983520312774506326239578318016984801869478851843
 85861560789112949495459501737958331952853208805511
 12540698747158523863050715693290963295227443043557
 66896648950445244523161731856403098711121722383113
 62229893423380308135336276614282806444486645238749
 30358907296290491560440772390713810515859307960866
 70172427121883998797908792274921901699720888093776
 65727333001053367881220235421809751254540594752243
 52584907711670556013604839586446706324415722155397
 53697817977846174064955149290862569321978468622482
 83972241375657056057490261407972968652414535100474
 82166370484403199890008895243450658541227588666881
 16427171479924442928230863465674813919123162824586
 17866458359124566529476545682848912883142607690042
 24219022671055626321111109370544217506941658960408
 07198403850962455444362981230987879927244284909188
 84580156166097919133875499200524063689912560717606
 05886116467109405077541002256983155200055935729725 
 71636269561882670428252483600823257530420752963450

So, first for the test. After asking around a bit, the best suggestion I got for testing was to break down the string and take 10 or 15 characters and figure out the largest product from that string and then do the same with the larger number.

Here are the tests:

require 'problem8/problem8'

describe 'largest products of consecutive numbers' do 
  it "is the largest product of 5 consective numbers" do 
    expect(Problem8.product(7316717653)).to eq 1764
  end

  it "is the largest product of 5 consecutive numbers" do 
    expect(Problem8.product(7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450)).to eq 40824
  end
end

And so, here’s the solution. First, I created an empty array. Then I wanted to use .each_cons which takes every set of consecutive numbers based on the number of characters you ask for (in this case, it would be 5 because I’m looking for the largest product of 5 consecutive numbers) but .each_cons wouldn’t work because you can’t call .each_cons on a string. So, first, I had to separate the string into individual characters by using each_char. Once the string was separated into each_char (each character) I used the map method to make each of the string characters into an array of integers. Then, I used each_cons(5) which separated the array of integers into arrays of every five characters. The I took the product of each of those integers and pushed it into an array. Finally, the max is called on that array which gives the largest number needed for the answer.

module Problem8
  
  def self.product
    arr = []

    "731671765313306249192251196744265747423553491949349698352"\
    "0312774506326239578318016984801869478851843858615607891129"\
    "4949545950173795833195285320880551112540698747158523863050"\
    "7156932909632952274430435576689664895044524452316173185640"\
    "3098711121722383113622298934233803081353362766142828064444"\
    "8664523874930358907296290491560440772390713810515859307960"\
    "8667017242712188399879790879227492190169972088809377665727"\
    "3330010533678812202354218097512545405947522435258490771167"\
    "0556013604839586446706324415722155397536978179778461740649"\
    "5514929086256932197846862248283972241375657056057490261407"\
    "9729686524145351004748216637048440319989000889524345065854"\
    "1227588666881164271714799244429282308634656748139191231628"\
    "2458617866458359124566529476545682848912883142607690042242"\
    "1902267105562632111110937054421750694165896040807198403850"\
    "9624554443629812309878799272442849091888458015616609791913"\
    "3875499200524063689912560717606058861164671094050775410022"\
    "5698315520005593572972571636269561882670428252483600823257"\
    "530420752963450".each_char.map(&:to_i).each_cons(5) { |a| p arr << a.reduce(:*) }     
    puts arr.max 
  end
end

Phew! Look forward to the last two Eulers, 9 and 10, which I’ll hopefully get to post soon.

Building a Bot

I recently mentioned in my mentorship goals that one of the things I wanted to quickly dive into were databases. There are a variety of database types and ways to work with them. I was able to get an introductory handle by looking over Learn SQL the Hard Way and doing some additional research but databases are difficult to understand until you really start doing work with them.

At the same time, the bot in an IRC channel I often use was acting up. Basically, the bot was/is pretty much broken and needs to be restarted but no one knows who is actually able to restart the bot. Chris and I decided that a great first project for us to work on via the mentorship program would be to build a bot and to add a database component to it.

So first, what is a bot? A bot is a program that you can connect into a chat room (in this case an IRC channel) which will then respond to different conversations or things happening in the chat room. Most workplaces I’ve spoke to that utilize hipchat, campfire, or other internal chat communication tools have some sort of bot that hangs out in the room as well and makes it more entertaining. It’ll pop up funny gifs or respond to things people say. It can also be useful by providing information about testing or alert the room when someone deploys code.

My bot’s name is Rosie. She’s awesome. I’ll write up a few posts in the future that describe more about what she does but for now, I just want to go over the setup. First, I used cinch. Cinch is a great, easy way to set up a bot and gives pretty straightforward instructions that get you moving quickly.

This is what the setup code looks like.

bot = Cinch::Bot.new do 
  configure do |c| 
    c.server = 'irc.freenode.net' 
    c.realname = 'Rosie' 
    
      c.channels = ['#rosie'] 
      c.user = 'rosie_' 
      c.nick = c.user 
  end

Now, to walk through each line.
The first line bot = Cinch::Bot.new do creates a new bot using cinch. This new method takes a block.
In the next line configure do |c| , we are in the block configuring the method. This method also takes a block and passes in the cinch configuration for the bot which means it passes in a reference to itself that you can configure.
The third line c.server = 'irc.freenode.net' shows the server we are connecting to.
Then c.realname = 'Rosie' is the real name that will show up when someone asks who is in the IRC channel.
Next, c.channels = ['#rosie'] is the channel that the bot connects to. Right now I’m just testing her out, so I have her connecting to an independent channel that no one is using.
Coming to the end, the 2nd to last line c.user = 'rosie_' gives the nick name of the bot that will show up in the channel.
And finally, c.nick = c.user sets the nickname to the same thing as the username.

So, there’s the initial setup. I’ll do future posts on both functionality and integration of a database, as well as one on what is IRC in general for those not familiar with it.

Mentorship Goals

As many of you know from past posts, I was recently awarded Chris Sexton from the Arlington Ruby group as my mentor. I say awarded because it’s been going really great and I think he’s awesome. I’m so glad Chris is my mentor and we’ve been meeting regularly to make sure I’m learning what I want to. This brings me to my next point, as many of you also know, I think it is very important to set goals. In addition to setting goals for myself so that I can achieve them, goal setting is a vital part of a mentor/mentee relationship. Part of being an effective mentee (I’m going to do a full post about this in the near future) is making it easy for someone to mentor you by being proactive and knowing what you want to learn and accomplish.

One of the first things I did, before chris and I even had a chance to sit down for our first meeting, was let him know what my goals were during this time period. These goals have already changed once or twice and I can always continue to add new goals as we go along, but providing Chris with my goals sets us up for success. I know I’m going to learn a lot and he knows exactly what I want to focus on to learn.

Here are the goals I sent him:
- Pair program at least once per month
- Determine projects to work on (building off of what I have already done and building new things)
- Feel more comfortable with defining my abilities
- Feel comfortable with looking at/thinking about projects that are in progress (not just building rails apps from scratch)
- Learn more about databases and become more comfortable working with them
- Determine how to set good programming goals (there's so much to learn, how do you determine what gets you to the next level and how to get there)
- Commit to OSS

I’ve already started my first project with him of building a bot! The bot is going to be awesome and we’re going to incorporate some information that needs to go into a database in order for me to really get a better sense of working with databases, how they work, and what problems might arise when using them. I’ll definitely be doing some posts soon on the process of building a bot.

Learning… The next few tutorials and tools

My apologies for not posting for a few weeks on this topic! I imagine that those of you who followed the last post on tools to get started with have completed those three resources and are very ready to move on.

Next on the list is learn ruby the hard way. This tutorial is great and you can get it free, online. I recommend working through it. This will take you a while and probably, at some point in the middle, you will lose steam and not want to do the rest of the lessons. BUT continue and push through it. Take notes. Do ALL the extra credit. Keep all your exercises in a folder. It gives you a really solid step by step guide to ruby that is a little more advanced than the last group of links I provided. It also provided me with a lot of good questions to ask more seasoned developers to get more information on how certain things worked or what certain things were.

If you’d like to simultaneously be reading a book while doing this, I recommend Chris Pines "Learn to program". To be honest, I didn’t read this book but have since skimmed through most of it. This will give you a good foundational background in programming. Now, this is the stuff that may get tedious and may seem boring (I know I had a really difficult time keeping motivated and focused through this part.) It is so annoying when you just want to build cool things but you just don’t know enough yet to build awesomeness. Don’t worry, the awesomeness is coming!!! But you’ve gotta make it through this first.

Next, do Ruby Monk. I did Ruby Monk way too late, but once I did it, it clarified a lot of definitions and parts of Ruby for me once I did it.

Additionally, start listening to podcasts and figuring out which resources you like. I really enjoy Ruby Rogues, especially their picks at the end but there are a lot of different podcasts, both free and for a low-cost.

Finally, I wanted to toss out two additional resources that aren’t necessarily tutorials. This is an awesome resource: http://iwanttolearnruby.com. It lists a lot of different tutorials and resources, notes the level and cost (if any). It’s a good place to find a lot of the resources I’ve mentioned and more. And last, this article came out this week and I thought it was a really great read with some good messages and thoughts to keep in mind about what she wishes people had told her when she started learning to code. https://medium.com/learning-to-code/565fc9dcb329

Keep going!!

RubyConf Randomness: Other things I learned that weekend

This post if all about the other random things I learned at RubyConf. Just as a note to begin, some of these items are talk-related, others are just literally random things I learned. In order to learn, I needed to ask. Don’t shy away from asking about a joke or tv character. It’s not embarrassing to even ask the small questions...I’m new to tech and therefore I don’t understand all of the star trek references or ruby jokes. Ask them!! Then you’ll be able to laugh at them in the future! It’s the little things that make a big difference.

1. Koybayashi. There’s more than one. I have a confession… I love eating contests and the sport of competitive eating. Yup, you read that correctly, eating contests. The best part of every year for me is the Nathan’s hotdog eating contest every July 4th. I love the commentators and the competitors, I know all of them and their stories and their past records. One of the most famous major league eaters is Kobayashi. He held the world record for number of hotdogs eaten for a long time until Joey "the jaws" Chestnut came onto the scene. Now, during Evan’s talk about Redis and Recommendation Engines, he had a slide about Kobayashi. This slide had no hotdogs and I was very confused. Turns out, there’s more than one famous Kobayashi. The Kobayashi he was referring to was Kobayashi Maru, (Straight from Evan!) a fictional test administered to Starfleet cadets in Star Trek. Cadets are evaluated on how they handle failure. Now that slide makes much more sense both in slide content and in placement within the presentation.

2. Talks I wish I had gone to. There are two talks that I really can’t wait to watch. These are Pat Shaughnessy’s Garbage Collection talk and Dave Copeland’s talk on branching, nil, and attributes. I saw lots of cool notes about these two sessions on twitter and heard great things from people who were at those sessions. Another note on talks, I thought the lightning talk by Andrew Harvey was really good. If he posts his slides, you should definitely check them out.

3. I didn’t do a full write up on notes from Day 3, session 3 about being an open source maintainer. I didn’t have many notes but hopefully this topic will be more relevant to me in the future. I wanted to put some little notes about it here though. Some key points I noted were the idea of rewriting the history, triaging a pile of issues when you first become a maintainer, and taking responsibility.

4. I learned about like 15 new languages while there. Seriously, who knew there were so many programming languages?! Some languages I heard of included poison, Dylan, and whitespace. I intend to fully ignore these until I’m a little more comfortable with ruby but I can’t wait to be at the point in my developer education where I can play around with these weird random languages and easily understand what’s happening.

5. The last session was a fireside chat with Matz. At some point someone asked a question about someone called Nobu and everyone laughed. For those of you who also didn’t get it, here’s what everyone was laughing at. There is a guy named nobu who has the most contributions to ruby and the running joke is whether or not he’s a bot or a real person. Apparently he’s a real person. Next time, I’ll be able to laugh too

6. I arrived late to board game night and therefore didn’t really jump into anything, but there were some really cool games being played! If you were there and remember any of the names, please leave them in comments! I’m always looking for new interesting games.

On a final note, I just want to say thank you to everyone that I met and had conversations with while at RubyConf! It was really fantastic to meet so many people doing so much cool stuff. And thank you to the organizers who put together the scholarship program! I wouldn’t have been able to go if it hadn’t been for that opportunity.

Hopefully I’ll see everyone in San Diego next year!!!

Are you good code or bad code? - Day 3, Session 4

This was the last session of the conference but fortunately, also one of the most fun sessions! The session was moderated by Matt Aimonetti and featured a panel discussed if bad ruby code exists. The panel was comprise of Aaron Patterson, Bryan Liles, and Bryan Helmkamp. If you have a chance, WATCH THIS TALK! As opposed to being a presentation, it was actually a really interesting discussion. I have a few notes from this session that I’ll write below but a lot of the conversation was mostly about questions to ask yourself as a developer when you’re writing code. Additionally, the panel members talked about their perspectives on good code, bad code, get it done code, etc. Overall, they were all really good points for me to continue to keep in mind as I work on different projects and in the future, work on more complicated projects.

First, there was a discussion about what is good code. The consensus seemed to be that good code was more testable, more maintainable, and more extendable. Most people seemed to settle on the fact that there is no bad code, but there definitely is code and better code. To this point, Bryan from Code Climate talked about the static analysis of code which helps people make more informed decisions. He hopes that the code climate process is helping to make better coders and also help determine what is better code.

Second, there was some discussion of “the rules”. I found this really interesting since I’m still learning the rules and the rules are important. When you’re first learning, it’s important to know the best practices and what the rules are. The goal is to get to a point where you can decide in an educated way if you want to break that rule or group of rules and why.

A question came up about refactoring and when you should take the time to look over your code, refactor and make those changes. The panel discussed always asking themselves the question of “how long would it take me to take this code and make it easier/better?” (easier/better meaning easier to work with or in). When the answer is around a week or longer, you’ve probably gone too far without pausing to refactor.

One suggestion based on this is when you’re working in a class, decompose the things into composed methods. In other words, factor out methods into smaller methods.

But seriously, watch this talk. It was entertaining, humorous, interesting and I feel like made me a better developer in a very different way than most of the other sessions.

The most important things I took from this talk:
1. Good development is knowing why versus how
2. A good developer knows the rules and also knows when to break them
3. Write the best code you can in the time you have
4. Focus on moving forward. Be a better developer today than you were yesterday, be better this year than you were last year, and so on.

Program on my iPad?! - Day 3, Session 3

TL;DR: have you ever programmed on your phone or iPad? I haven’t but now I totally want to.

I thought this session was plus/minus (sorry Charles Wood! I still love Ruby Rogues!). My main issue with the talk is that he showed this awesome demo of actually being able to pull up the command line on your phone or iPad in order to actually program but didn’t really go into how one would accomplish this.

Charles talked about the toolbox he uses to get his development machine in the cloud. Primarily, he uses SSH, Digital Ocean, tmux, emacs, Github, and Chef. First, the SSH is configured and public/private keys are created. You can create one key for each machine or a single key for all your machines. He discussed Digital Ocean as the server he uses.

Second, he prefers to use TMux. I’ve heard a lot about tmux for pairing and how it’s a great tool when you want to pair with someone (I’ve yet to use it). For this case, however, he also liked it because you can pick up where you left off instead of having to restart something or get back to where you left off. Additionally, you can do multiple or split screens which is useful.

I didn’t write down any notes about emacs, github or chef since I have a bit of a background on those (if you ever want a great presentation on chef, hit up Nathen Harvey… he did a 10 minute “what is devops and what is chef” talk for Rails Girls a few months ago that was so amazing).

I jotted down a few notes about security, since that seems like an important issue when you’re using a phone or ipad to log into your development environment. These security suggestions included turning off the root ssh, using public/private only, having a firewall, using something like proXPN (a tunneling service) and using sudo.

The main question I had after this session was “ok, but now how do I actually get this working?!” He did a good job explaining the tools, some of which I was familiar with, others not as much and while all the tools at the end sound great. I’m still not quite so sure how they all get pulled together to let me program on my iPad. After the session, I spoke with Conrad a little bit about this and he pulled things up on his phone (which again, was really cool) and I think I understand overall how I would go about doing this. It mainly has to do with setting up the SSH and a server and I think everything else stems mostly from that. The basic steps are to 1. set up or have access to a server. 2. Install with a package manager onto the server. 3. Ssh into the server. 4. Then you have an ssh client for iPhone, like prompt, which is a terminal emulator for ssh. (I’m a little unclear on that last part, so if you do want to get into this, I’d suggest taking the basic tools listed above and then doing some additional research on the actual setup).

Encouraging new Software Developers- Day 3, Session 1

For this session, I went to Kinsey’s session on becoming a software engineer. Kinsey is a newer developer and did a great job on her talk!! The talk was closely related to my lightning talk and discusses apprentice programs and what has really helped her become a software engineer along the way. Among other things, she talked about how Thoughtbot’s apprentice program really helped her learn and grow and discussed ways other companies can think about apprentice programs.

TL;DR: More interesting thoughts on mentorship and qualities of an effective mentor and my personal opinion on the proliferation of bootcamps.

Kinsey spoke of outreach and how the RailsBridge program truly changed her life. For me, my first introduction to coding was through Rails Girls so I agree that outreach and new programs coming into existence are important in order to expose people to what they can achieve. She also spoke about mentorship and the importance of that (which I obviously believe in). She noted some important aspects of an effective mentor are someone who can explain complex concepts simply, someone with an awareness of both themselves and the mentee, and finally, someone who has patience.

Finally, she spoke about her progression and the tools she and Thoughtbot used to help her grow. These included weekly retrospectives, pairing, and empathy. This talk was a great talk. I think the room was mostly filled with people who do want to mentor and want to help support newer developers which was great and the room was pretty filled, showing the level of dedication in the ruby community to support each other and help newer people just getting into the industry.

One side note that I’m compelled to mention related to new apprentice and bootcamp programs opening is the recognition that not everyone can do one of these programs. I think these programs are fantastic and I’ve met great people who have been a part of these programs. One challenge I’ve seen, however, is the expectation that if you haven’t done a bootcamp or apprentice program then you’re a riskier candidate for a job. Recently, when I talk about learning to code on my own, everyone asks me about participating in a bootcamp program, especially given how many are opening these days. These programs, while increasing some of the diversity concerns in the technology community, are still out of reach for many. A bootcamp’s tuition and living expense, as well as the requirement to move someplace for a few months can be out of reach for many. Oftentimes being part of an apprentice program requires those same sacrifices especially since often you are expected to stay in the same area after a bootcamp or apprentice program. There are merits to learning in a bootcamp-style environment however I hope those of us who have taken a different path but put in the same amount of time and dedication will still be considered as strong candidates for the same companies recruiting new hires out of these institutions.

Keynote: Code StoryTelling

The third day’s keynote was pretty interesting. Ernie Miller was talking about writing code and particularly writing ruby. The main premise of the talk was that your code should tell a story. In order to tell that story, things should be clean and clear. I learned lots of new terms and extensions of terms I already knew. A good way to tell the complexity of code is through branching. Branching shows how complex code is by showing how many branches it has. Branches are determined by places in which code could go more than one way. For example, an if statement counts as a branch because it shows code choosing one path or another.

Earlier in the talk, he spoke about rules of class macros. Classes should be easy to understand, order independent, free of branches, show what and not how, and idempotent. He also talked about callbacks. I didn’t previously know that there were so many different types of callbacks. There are reverse callbacks, around callbacks, and skip callbacks.

The final term I learned was prepend. Prepend relates to include and extend, but different. Prepend is related to include but in include, methods on the class are a higher priority than methods included from modules but prepend changes that! When you use prepend, the priority order changes so you can say prepend A for example and then A would be a higher priority than the other methods in the class.

Obviously this talk had a better flow than the notes presented here. He went over a lot of different ways to write ruby and styles. I just took notes on the terms I didn’t know previously and wanted to look into after the talk. Fortunately for everyone, the slides are up! https://speakerdeck.com/erniemiller/thats-not-very-ruby-of-you

UML: not just random letters - Day 2 Session 3

On day 2, I didn’t got to the second session because I was busy having an excellent lunch with the other ladies at the conference thanks to DevChix for organizing and sponsored by Thoughtbot! When I got back, it was time for session three. I wasn’t sure what to attend for session three (day 2 in fact was much higher level, I thought than day one so I was often choosing between sessions where I didn’t really understand any of them so it was a little bit flip of a coin, but the sessions ended up being really interesting). I ended up at The Big Picture with Jim Weirich.

TL;DR: UML can help diagram code which helps programmers see it and organize it with more clarity.

The Big Picture was all about UML which stands for unified modeling language. An initial warning, UML is a visual representation so I’m writing about some of the information but in order to really get the full picture and idea of what Jim discussed, I think it will be necessary to see the diagrams and models alongside the explanatory information.

Moving into the talk, there are three primary ways that you can use UML. You can use it to sketch a process. You can use it as a blueprint and finally you can use it as a programming language. Jim talks about using it primarily as a sketch. The first example he discussed in terms of explaining usefulness was showing dependencies. When you diagram something, you really think through the code and know what your code depends on. This is shown visually via the direction of the arrows. The direction of the arrow is the direction of the dependency. You can also use this diagram to break up certain sections of the code so, at one point, on the example, the controllers were outside of the box (in red) and the application was in the green box (see, this is where seeing the diagram is obviously useful).

One of the primary examples discusses was a sketch of Rake. Rake has few classes, but the classes that do exist contain lots of methods. There is no rules class in rake. There are also no domain specific locations in rake. The application is rake. Within that application, namespaces exist and the scope is constantly changing as you define a task. The file tasks ignore scope. I had never thought about the rake task in this way and broken it apart with this methodology so it was interesting to see the task essentially pulled apart into the different commands and components that comprise it.

There was a brief discussion of object diagrams and how it is important to keep in mind that an object diagram captures how an object looks at that exact time.

He then talked about another use of diagramming when talking about creation. It related to creating a process, but more importantly he used an AR Drone to demonstrate it so pretty much all my focus went to that leaving me with little/no notes on what creating a process actually means and why this methodology is useful for it.

Next we covered dynamic engagement which is a state diagram. In this diagram, you have a start state (represented by a black dot). Then the arrows represent transitions which happen with a trigger that make an action happen which finally switches the state.

Finally, we discussed interactions which are sequence diagrams. My notes for this part are a little shady but sequence diagrams are like object diagrams but with more lines and different lines. The diagrams show sequencing calls and are timing related.

Summarily, I can see where diagraming out code is interesting and useful. After this talk, I also heard others discussing how UML is a waste of time, which I can understand as well. I think in certain scenarios diagramming and utilizing UML could be very helpful and useful but in others, I can understand how it wouldn’t make as much sense.

Day 2 begins at RubyConf

So there’s this thing and it’s called JRuby and it’s like Ruby but it’s not Ruby. The talk was given by Charles Nutter and Thomas Enebo. This session was really interesting, at least the first part. I’ve never used JRuby before and didn’t really have a sense of what it was. The second part of the talk went into some more specific features and functions that will be added for the new release – that part was less interesting to me because I had never used JRuby before and therefore what I should be looking forward to in future releases didn’t really matter to me, but the first part of the talk was all an introduction to JRuby, what it is, what it does, and how it works. This, combined with some additional time and explanation with Conrad, really opened my eyes to the variety of different things going on in the Ruby world that are related to Ruby but not exactly Ruby.

TL;DR: JRuby does a lot of interesting things and I learned terms like JVM, jit, bytecode, and concurrency.

So, what is JRuby? JRuby is Ruby on the JVM (Java Virtual Machine). It is ruby implementation written partially in Java. It isn’t yet compatible with Ruby 2 but will be soon. JRuby is a different version of ruby entirely so you can use RVM to toggle between versions. Having Ruby on the JVM means that everything in the JVM is available to you. Essentially, this is really useful and cool because having the JVM available means that you can utilize Java libraries in your ruby code.

They then talked about garbage collection (more on that later) and jit runtime. Jit is a compilation called just in time compilation. In jit, when you run the compiler, you get an intermediate file (called bytecode) but the file isn’t optimized. So when you run Java, it takes the machine code and turns the parts you need into optimized code. Normal Ruby doesn't compile into machine code so JRuby runs like regular ruby but behind the scenes, it does a bunch of more complicated stuff. Traditional compilation happens when you run the compiler and get a binary file, not bytecode. This bytecode helps reduce overhead and they are currently working on improving the optimization even further in newer version of JRuby. The need for optimization comes from the longer setup time. Once the JVM is set up and running, it can be really fast (because it only optimizes pieces of the code as you need them) but it takes some time to get up and running.

They also talked about concurrency and parallelism. Concurrency means that is you have 100 users, then you need 100 way concurrency which is directly related to the amount of spacing (memory) you need at a given time. When you use threading (available in JRuby), it saves the amount of memory you need to use and therefore the amount of money you need to spend. This is also related to parallelism. Threading is not very commonly used in Ruby but to go into a little more explanation threading means instead of running 10 copies of the ruby code, you can run 1 copy of the code with 10 threads of the code. Related this, they talked about the thread-safe gem, hamster gem, and atomic gem. They also talked about shoes which I did some additional research into because it looks cool. Shoes is built using JRuby. It’s basically a gui (graphical user interface) environment which means it’s a way of writing graphical applications in ruby so that you have a user interface and you can so applications and not just web apps.

Now, back to garbage collection for a moment. JRuby has the best garbage collector. So what does that mean and what is garbage collection? Garbage collection runs code in your code. Ruby automatically throws objects away when you’re not using them in order to help with memory. Ruby marks items being used and tosses those that aren’t used… this is called mark and sweep. The JVM has a good garbage collector because of the way it optimizes the code (I think). For more on garbage collection, check out Pat Shaughnessy’s talk once it’s up on Confreaks (I missed it too, but it’s one that I definitely intend to listen to once it’s posted. I heard it was really good).

Finally, this talk about JRuby made me curious about the other stuff I had heard about… like CRuby, MRuby, Rubinius and what use cases were. A frequent use case for JRuby is when it is used to write a JRuby wrapper around Java code. CRuby is another name for MRI which stands for Matz Ruby Interpreter or the main documentation for the Ruby beginners are most familiar with. MRuby is a new version of a ruby-like language. Finally, Rubinious is like PyPy which lets you write python in python. Rubinious lets you write Ruby in Ruby which uses less resources and runs the ruby code faster.

Session 5: Regular Expressions

For those of you who don’t follow me closely on twitter, you may have missed that I recently wrote my first regular expression!! Now, it was a very simple one but I think regular expressions can be some of the most intimidating code. You look at this blob of symbols and weirdness and there is no chance in hell you’ll be able to interpret it until you actually do some research. The first time I saw a regular expression I literally thought, what the hell is that? And is that actually I’m supposed to be able to understand one day? And then I actually wrote one, which was awesome. BUT more awesome than writing my first regular expression was going to Nell’s talk on Regex’s. It was mind-blowing. I think the best thing about Nell’s talk was that it was high level enough that more experienced developers in the room were really interested in what she was saying and n00bs like me understood everything she said because she stepped through regex’s slowly, clearly, and explained it amazingly well. I know that this will be a talk that I continue to look back on as I write more regex’s and gain more experience with them.

TL;DR: Regular expressions explained in a comprehensible, clear way are not so scary and can be really powerful.

First, Nell spoke about the onigmo library, which I had never even heard of before. Basically, it is onigmo that reads a regular expression and parses it into abstract syntax tree and then it compiles that into instructions. The expressions relate to a finite state machine. Breaking this down the machine is the subject, the state is the state of that machine, and finite are what the possible states are.

When making a regex, in order to call the regex in code you set it up this way:

Re = ‘/force/’
String = “Use the force”
re.match(string)


She then went into exactly what happens. Basically, the regex starts at the beginning of the string and it works through the string until it finds the beginning of what could be a match… in the case ‘f’ of ‘force’. Once it finds that first letter, it will work through the remaining letters to determine if there is a match and if there is one, then it’ll return that match.

From here, the talk went into different ways you can create regex’s. For example, if there is a pipe in the phrase then a match can be one part OR the other part of a string. The example used was /Y(olk|oda)/ so a match would be either Yolk or Yoda. Another variation is a plus quantifier. The + at the end of a string means that you can have infinite repetitions of the last letter of the string. The example she used was /No+/ which means a match could be “Noo”, “Nooo”, or “Noooooooooooo”. There are also lazy quantifiers, star quantifiers, possessive quantifiers which she shows using a bunch of cool examples.

Then, and this part was just really fascinating, she brought it together using an example of a challenge sent out by Avdi a little while ago. The challenge was to make a snake_case into a CamelCase using a regex. Now, beyond just showing us that, she TDD’ed it!!! I had absolutely no idea how you’d TDD a regex (or that you even could) so that was great to walk through. She started by mapping out what needed to be done and then going to it. To give an example of picking apart a regex she did this:

Def upcase_chars(string)
Re = /\A_?[a-z] /
String.gsub(re){|char| char.upcase}


Which means: \A anchors the expression to the beginning of the string
_ is the underscore
? means that the underscore is optional (it will match the string with or without the underscore)
[a-z] matches any letters and not the underscore
and then the next line says for the string, substitute the characters for uppercase characters.

This regex continued to get more complex for the next few minutes including a look back, figuring out some additional complications based on the underscore, and then combining the methods to create the solution.

You can check out the final code and final specs here (which I highly recommend doing).

At the end she made some final recommendations for building regular expressions. First, develop regex’s in small pieces and the combine them. Second, use Rubular and make a permalink of it. This way you can put the permalink into the code as a comment! Last, don’t be afraid of regular expressions.

The Pry talk!

I was really excited for this talk. In my local user group, Arlington Ruby, someone discovered Pry a little while ago and so now we all use it and are a little obsessed with what it can do. My guide, Conrad, gave the talk and is one of the main men working on Pry so I was super excited to see what it could do. Right now, I use binding.pry a bunch and kinda understand what it does but this talk really helped and also showed me a ton of other stuff that can be done with Pry.

TL;DR: Pry is really cool and is very powerful with a ton of built in shortcuts for effective debugging and working with your code.

So, let’s start with what is Pry? Pry catches exceptions. It is a REPL which means read, evaluate, print, loop. It is more robust, fun and easy to use, and adds introspection to the REPL. Introspection basically means that you are able to look around and see what your code is doing. This is what I’ve used pry for in the past. You can put binding.pry into your code and run it in your terminal and your terminal will automatically open pry instead of IRB and will allow you to both step through your code or look at each step in your code individually allowing you to see what’s going on and help determine and solve problems more effectively.

Conrad talked about recommending REPL driven development. So, instead of working out the code and testing it, he suggests you work out the code you’re going to use in a REPL first and then write the tests and the code it.

Now, for the cool tips and tricks he mentioned (note: I haven’t had a chance to try these all out since I’ve been back)…
?$mongo shows the documentation for a method
$$mongo shows the source code
ls Moped::Query shows the methods available

For more fun stuff, you can install the pry-plus gem and then require ‘pry-rescue/rspec’
Typing play-l6 will prompt line 6 to play that 1 line
Edit –m edits the current method (so if you want to fix an issue)
And then try-again will rerun that 1 test so that you don’t have to deal with rerunning the entire test suite just to see if you fixed that one test.

You can also use pry to vertically in a method by using the up and down keys. You can use the cd command to move through the code horizontally.

Typing an underscore will refer to the last line and typing __ or two underscores will give you two lines back.
_ex_ raises the most recent exception
wtf? Gives you the first five lines of the stack trace so that you don’t have to scroll through a bunch of unnecessary stuff.
Finally whereami will show you where you are in the code!

This talk was really cool and super useful (as in, I can start using these shortcuts and tips immediately). It was a lot of fun to hear all about pry and all the things it can do.

RubyConf Session 3 - Recommendation Engines

I’m going to be honest here… my notes from session 3 are a little light for two reasons. First, I know Evan and he’s amazing and I know that if I had additional questions, I could always ask him after the conference and second because when you’re new, concentrating on so many high level talks in a day can be a little tiring. But still, I learned some great stuff! The nice thing about the presentation, as well, was that I had actually had a fair amount of exposure to the concepts he was speaking about through both projects I’ve built and through my shadowing opportunities.

Evan was talking about recommendation engines. His example was that he was building a social network for soccer. The client he was working with wanted to have a “feed” function a la facebook where people could see what was going on. Specifically, they wanted the users to see what was popular and relevant in real time using tags. Each post has polymorphic tags associations. When looked at a recommendation engine, he mentioned that the engines are based on approximation and are based in statistical methods. The trick was to quantify posts based on popularity and relevancy.

He then spoke about Redis and how Redis stores a key/value pair in memory essentially making it a glorified hash in the data process. One interesting thing about this is that the value doesn’t have to be a string. It can be a data structure (like a hash, list, set, or sorted set) which is pretty interesting and means you can have more flexibility with the data. Finally in Redis there are few persistence options but the ones that exist are adequate.

He then talked about using ActiveRecord::observers which pushed events to resque. Finally, in order to actually determine importance weight, he used different calculators. One was trendingness. A second was user interest. And the third was the post score calculator. The methods themselves were really interesting to look at, think about, and dissect how they interacted with one another, but we’ll need to wait for the slides to be posted to really pick through those. Finally, I think in order to limit the amount of data being processed, he set a small TTL. TTL means time to live. Basically, if you set a record to a specific time, it means you can read that record for x amount of time and after that it gets deleted and you can’t read that record anymore.

Evan’s talk also taught me that there are two famous Kobayashis… the major league eater and one related to Star Trek (more on this in the “random things I learned at RubyConf” post).

On Grit and Learning

This weekend, I was listening to the Ruby Rogues podcast from this week about how to learn. I’ve thought a lot over the past few years about how I learn, the importance of learning, and to be honest, how my upbringing and self-confidence has been affected by my learning. I am the middle child of three. I grew up in a single parent household but with a fairly traditional slant. I also grew up with a very very smart older brother. He was reading independently by the time he was three and often put himself to sleep by reading the dictionary...yes, the dictionary. He was the “smart one”. He was also the lazy one. Because he never had to work in school, he never did. He almost never turned in homework assignments but aced tests without ever opening a book. I was very different. For a long time, I was the “ditzy one”. I asked a lot of questions which were sometimes answered, sometimes laughed at, or sometimes explained by my brother using vocabulary I didn’t understand. I often had to think about concepts or reread things to understand and I had to study and work hard at school. As the most social of the three of us, I ended up being the outgoing, smart-ish enough child who was always expected to have a middle of the road career in something not super easy but also not too difficult.

Until I went to college, I believed that I was not so smart and would always have to work much harder than everyone else in order to learn something. When I encountered something challenging (especially math and science related things), my initial reaction would be that it is probably too difficult for me to understand as opposed to knowing I could understand it with a little bit of effort. A few months into school, I started raising my hand, answering questions and getting them right! Something that stumped my classmates, I would understand and when I couldn’t figure something out, I thought it through or discussed it with others to clarify. Turns out, I was smart, I just grew up convinced I wasn’t. Additionally, I realized that my ability to work hard was not due to the fact that I didn't understand something, it was because I strove to reach higher goals and wanted to understand something more fully than just “getting it”. This newfound “smartness” also came with self-confidence. Once I realized I had valid questions to ask and legitimate comments to make, I had no trouble speaking up.

This is where the Ruby Rogues podcast comes in… the first thing they spoke about was Grit and the importance of Grit. Grit is basically perseverance. It says that successfulness is not defined by innate talent or smartness but about GRIT and someone’s ability to stick with something and continue to push themselves to learn more. Sandi Metz did a phenomenal talk about this to the DC Rails Girls workshop in June as well which was the first time I had heard the GRIT theory. Other things discussed also resonated with me. I found myself alone, in my living room, often nodding at the conversation. For example, they discussed NOPS, which is a really interesting concept of recognizing when you are uncomfortable and going with it. I realized I did this when starting to learn. At the beginning, I was embarrassed to ask questions and they made me uncomfortable. One day I decided to just go with it and say I’m going to ask every question that comes to mind today. It was great. Everyone answered my questions and I learned so much more once I stripped myself of the feeling of embarrassment about needing to ask.

There were a few other good tips that relate to the lightning talk I gave at RubyConf (speaker notes coming soon! I promise). Things like knowing that everything is a rabbit hole and you need to give yourself license to not care about some things as you learn or explaining things as you learn them. This is actually mostly why I started this blog. I find that when I solve a problem I have and I want to blog about it, I understand the problem and solution much better because I want to explain it to other people and feel a responsibility to be able to explain it effectively and in a way others will understand (and now I understand pictures of rubber ducks I’ve seen related to debugging!! It’s called rubber ducking or teddy bear programming (same principle as rubber ducking but with a teddy bear) when you explain a solution or issue or definition to a stuffed animal or rubber duck in order to ensure you understand it). And a final great tip about constantly stopping to evaluate yourself, asking what did I do well this time and what wasn’t so good?

I know that at this point in my coding journey, someone is going to need to take a chance on me. In a recent interview, someone told me that no one would ever take a chance on me because I don't have a CS background or professional coding experience. I know enough but am still learning a lot and I just hope someone sees my perseverance, grit and passion for learning enough to know I’m a good bet as an employee. I also want to say to anyone who is currently learning, keep pushing yourself. Every day you know a little more, even if you don't always feel like you do.

Onto Session 2!

I fear I won’t be able to process everything and get it in a post before I start forgetting what my notes mean! Expect rapid postings in the near future.

Onto Session 2!

TL;DR: databases.

This session was about the Zombie apocolyse and data structures with Casey Rosenthal. I knew walking into this one that it would be a little over my head but after a post session debrief with Conrad (my guide) that helped frame database structures in general, everything clicked! I’m also just now starting to really get into database structures and understand more about how they work, how to work with them, and what are the ways you can structure different data types within databases so this ended up being a great session for me to be in. Also, it was about a zombie apocalypse so it had to be good. Let’s start from the basics. There are two types of databases, SQL databases and NoSQL databases. NoSQL databases are essentially anything that isn’t a SQL database. NoSQL databases can also be known as distributed key value databases. Examples of these databases include MongoDB and Riak. SQL databases include MySQL, SQLite, etc. There are a handful of differences but the main difference is that SQL databases are based in table modeling. SQL databases can be a bit more flexible if you have similar types of information coming in all the time, but they can also be harder to scale. SQL databases are also good as long as everything is on one machine because they are safe, have lots of features and have many other good aspects but features these same features are hard to implement once you are running on many machines. Why do you need to move to many machines instead of having just one machine? Because you can’t read the information quickly enough when there is a lot of it (essentially, the queries start taking too long and you need to split the information onto more than one machine). Finally, SQL databases enforce the structure. If you use a SQL database, all of the tables in the database require the same information. In a NoSQL database, this isn’t the case. NoSQL databases are designed to they can start as one thing but easily scale to become larger and hold different types of information. And because there isn’t the same table structure, it can be easier to store lots of different types of information. So, when using a NoSQL database, you don’t have to use commands like rake db:migrate because there are no data migrations (yeah, that kinda blew my mind and it was also where the whole rest of the talk suddenly clicked into place for me). AND there’s no schema file! A NoSQL database has tables but they aren’t specific so they’re called connections instead of tables. The downside, however, is that you can’t tell exactly what’s in the database unless you pull all the records

So, back to the actual talk…when thinking about what type of database to use, it’s important to think about how the information will need to be presented in the end. This was an idea that continued to surface throughout the talk.

Some important terms I learned when thinking about NoSQL databases (and databases in general) were high availability, strong consistency, and partition tolerance. High availability means you can connect to any part of the system and you can both read and write all the data. So, for example, if you have 3 different silos that each keep information, the databases are kept in sync with one another so that you can access all the same data from any of those silos. In other words, if a server crashes, the database still works (Casey has a great slide that shows this, so I definitely recommend looking up the talk on Confreaks when it’s up). Strong consistency means that parts of the database will remain in sync with one another. Finally, partition tolerance means that if the cable comes out of the wall, the database will remain running.

When you have a distributed system, there are a few data modeling options. You can do a document based inverted index or a term based inverted index. The document based inverted index means that you can write the information efficiently but that you’ll have an inefficient read process. The term based inverted index is the opposite. You have an efficient read but inefficient write system. So again, it comes down to really thinking about the data you have and what will be more important to your business processes.  Will you be reading a lot of data or writing a lot of data? The

He also talked about Highly Available systems (HA) of geohashes and one other type of HA system that I can’t remember. Lastly, I learned about some interesting components that are Riak-specific. Riak creates data siblings, which is also not possible in SQL but is possible in key value databases. Basically, when information is written into the system to the same key (so to the same data entry) from two different places (so two people are updating the same person’s file at the same time) the system will save both entries and connect them. In other systems, they just take the most recent timestamp as the most recent data but here, siblings are created and the two entries are both saved, become siblings and then the user is notified the next time that file is accessed being told “hey, you’ve got two entries here. Which one is correct?”

The rest of the talk went into some more detail on this information, how to locate zombies via zip code and other interesting components of the database but, for me, this is what I gleaned from the talk. For more examples, information, and the source code, you can check out zombies.samples.basho.com.

RubyConf: First session

My initial intention was to write up a post on what I learned at Ruby Conf this year and put everything in 1 big post, however, I've just finished writing up the first session and I'm already over a page, so I think it makes more sense to post as I complete write ups. Here's my first one about basically the first two hours of Ruby Conf 2013!

This past weekend I had the opportunity to attend Ruby Conf in Miami! It was fantastic. I learned a ton. Met a bunch of new people and really dove into some Ruby amazingness. I was also really excited because, while I have been to a few ruby conferences before, this one was the first where I really understood what was going on and could sit through sessions without being completely overwhelmed and feeling like I didn’t understand a majority of the session.

I was also a recipient of a RubyConf Opportunity Scholarship. This program paid for the conference registration and also connected me with a guide for the weekend. My amazing guide was Conrad Irwin who was able to answer any lingering questions I had from sessions I attended. Conrad was very helpful and really advanced the amount of learning I was able to do and amount of information I was able to process.

So, let’s begin… the day started with a keynote from Matz (Yukihiro Matsumoto). For some reason, I didn’t think Matz would actually be there but he was and it was great. His talk was more to set the tone of the conference than go into technical details but a few points he made were great. First, appreciate your garbage collectors. Garbage collection was actually talked about a handful of times over the weekend but this was the first. Second, appreciate and respect are key. I think this is one of the reasons why I love the Ruby community so much… because these ideals are held paramount and discussed throughout the conference, but especially at the beginning to set the tone. Finally, an interesting note about open source was made, that OSS is like a shark, it needs to keep moving or it will die. All great points to set the tone for the rest of the weekend.

Onto the track sessions.

The first session I attended was on “A Peek inside the Ruby Toolbox” with Loren Segal (who, by the way, is interested in mentoring a new developer who's learning to code. If you’re interested, you should tweet at him @lsegal). Loren spoke about the really good tools the Ruby community has like deployment/ops, documentation, and testing, but mostly focused on where we could improve. The talk started with Visualization. There are lots of great visualization tools out there but none for ruby. Some example given were visual studio, which is a diagnostic hub which shows CPUs, load times, etc. It also has a built in debugger. XCode was noted as a good visualization system. VisualVM which is JVM code. All of these tools really help with discoverability which was interesting to think about. Discoverability is basically being able to have a visual representation of what’s going on. The other tool mentioned was firebug which is considered a really awesome visualization tool and it is the inspect element function in FireFox. Right now, Ruby Mine is available for Ruby but it’s not awesome and fairly expensive. He also spoke about profilers like perf tools which results in a graphic diagram that runs through code and new languages like JRuby which have a JVM.

Next, he spoke about Linting… which is not picking lint out of your belly button or using a lint brush to make your clothing un-fuzzy. Linting tools are basic “check up” tools that help determine if your code is good or bad. Linting tools detect code smells and should find common errors. In Javascript, there is JShint. Currently in Ruby, a few tools exist… Reek, Flog, and Flay. The issue, however, is that these tools test the prettiness of code, not if it is good code (more on good code versus bad code in a later talk). These are some of the tools Code Climate uses to rate code there. There’s a new tool called Ruby-Lint but again, it’s new, and so Loren wasn’t sure how good it is. I’m excited to look into it more!

Next, he talked about Static Analysis. Static Analysis is bug checking/ defect finding. Here, I learned about Fuzz Testing (almost as cool of a name as linting but not quite). Fuzz testing is when you throw a bunch of crap into you application to see what breaks it. (I later learned the SQL is well known for its fuzz testing). It seems like there are lots of interesting things to look into further about fuzz testing but what currently exists are heckle, which fiddles with if statements to see If the tests fail and mutant. Finally, he also spoke about symbolic execution which runs code with no immediate values. I wasn’t able to really wrap my head around this… it’s something that has to do with math, testing values, and automatic test case generation. Right now there’s nothing in Ruby for symbolic execution.

In the category of random knowledge learned, In this talk, I also learned about what an IDE is! I hear people say it all the time, but never fully comprehended what it was exactly. Anyway, an IDE (integrated development environment) is having all the tools you need in one window so XCode is an IDE and so having an IDE would mean that instead of having a text editor, console, etc. all open, you’d have it all in one place.

Great session and lots of new stuff to look up. It will also be interesting to see what new tools are built based on these weaknesses in our toolbox.