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.

Mentorship from a n00b's perspective

Here are the slides and notes from my lightening talk at RubyConf 2013 in Miami.



While at RubyConf, I did my first lightning talk!!! I have to give a shoutout thanks to Jim for suggesting it in the first place and a bunch of the other Arlington Ruby folks for helping to encourage me and make sure I went through with it. I literally felt more and more nauseous as I wrote each letter of my name to give the talk. I walked up on stage and the room was packed! I took pictures of the empty room and posted them below to get a sense of the space and when I walked up on stage the only thing I was thinking was “What was I thinking?! Oh well, I’m here now so let’s do this!)

Here’s some more info on the talk that expands on the slides a bit.

I chose to talk about mentoring from a n00b’s perspective. I’ve been learning how to code for a little over a year now. Since I started, there have been a lot of people who have been really incredibly helpful. They constantly gave up their time to help answer questions, provide guidance, and give encouragement… and I’m grateful for each of these people but some were easier to learn from than others and that’s ok. Mentoring is hard. It’s difficult for the mentee and it’s difficult for the mentor. Here are some of my tips to being a more effective mentor.

1. Understand that at the beginning, I don’t know what to ask and everything sounds like a foreign language.
When I first started learning and people would say “what questions do you have?” or “how can I help?” I would just tell them I was fine because I didn’t know what to ask. I just went through the tutorials and kinda understood what was going on. And then, when I sometimes did ask a question, the answer often included words or acronyms that I didn’t understand. And so I really appreciated when people encouraged me to be unabashedly curious and to ask any and all questions that popped into my mind and even interrupt them if I didn’t understand a word they used.

2. Don’t go down the rabbit hole
In groups of beginners, I often see someone ask a question and the person explaining wants to give a full explanation. Therefore, they will answer the question, explain how it relates to all of these other things, and give additional articles and books to read if they want to know more. This seems really helpful in terms of laying out the complete picture but at some point the person who asked the question is completely lost and generally feel like they’re never going to be able to understand all this coding stuff. So make sure you’re checking in, not going too far unless the person asks additional questions, and let them know that they’ll get to the point where they’ll be able to answer these questions for others.

3. Understand if you’re not understood.
This one is really challenging. There are times when I ask a question and someone tries to explain the answer to me. They could try explaining it in 15 different ways using all sorts of examples and I just won’t understand but then another person will walk up, give an explanation, and it will just click! Don’t take this personally. It’s okay to ask others how they would explain a concept if you see the person just isn’t understanding you and it’s important to recognize that people learn in different ways and understand different teachers.

4. The answer to the dreaded “what should I read?” question
In forums, groups and on IRC, I see this all the time. Someone asks “what should I read to learn more?” and they get a flood of responses… books, authors, titles, blogs, everything… but no direction. They leave with a long list of things to look up but without any guidance on why to read certain books or when. So, give direction. Suggest a title but also provide information on why they should read the book, where they should be in their learning process when they read it and what sorts of information they should be hoping to glean from that book.

5. Don’t put your fingers on my keyboard
This one may be the most challenging for experienced developers. I know that it is painful when you have to say each letter, symbol, and space that a person needs to enter into the terminal. It’s easy to say, “let me just type in a few commands to move us through this piece” or when you encounter an error to want to just grab the computer to quickly research what the solution might be but if you have the patience to tell the person learning what to type or what to search, they’ll learn a lot more.

6. Help celebrate the small stuff and motivate to do the big stuff
When I first started learning (and even still), everything that I did was so exciting!! But I assumed that my little celebrations would be silly and miniscule accomplishments compared to the more experienced developers. It was both exciting and eye-opening when they helped me celebrate the small things making sure I realized that those small things weren’t so small. I mean, how many times have you celebrated when you got different error message? If no one tells you that is worth celebration, a n00b would never think it’s worth celebrating. And then motivate to do larger things. My local group helped push and encourage me to do a talk at a local meetup and to do this lightning talk. I would have never even considered either thing if they hadn’t suggested it to me.

This is a talk that I intend to expand upon and present in the future again to the local Ruby groups here in DC. I’m not sure when exactly that will be, but I’ll be sure to post on the blog when it happens. Thanks #rubyconf for all the support when I was up there on stage!

6, I have 6 Eulers

Euler 6! This is getting a bit more difficult to post about the Euler problems because I've actually completed all 10 a few weeks ago now. When I go to post, I find that I'm trying to remember what I did, where I was at, and what my thought process was. So, a word of advice, if you're looking to blog about a bug or something you're working on, do it right after you finish figuring it out.

Now, onto the problem!

The sum of the squares of the first ten natural numbers is,
 12 + 22 + ... + 102 = 385

 The square of the sum of the first ten natural numbers is,
 (1 + 2 + ... + 10)2 = 552 = 3025

 Hence the difference between the sum of the squares of the first ten 
 natural numbers and the square of the sum is 3025 − 385 = 2640.

 Find the difference between the sum of the squares of the first one 
 hundred natural numbers and the square of the sum.

This one was a good one to roadmap out before I got started. Once I broke it down into a few pieces, it was also not super complicated to solve. So I know I had to find the sum of the squares. And then, the square of the sums. And finally, the difference between the two. Breaking it up into the three pieces also lent itself nicely to writing tests because I wrote tests for each of those three pieces and then a test set for the numbers up to 10 and a test set for the numbers up to 100. Here are the tests:

require 'problem6/problem6'

describe 'up to 10' do 
  it "finds the sum of the square of the first ten numbers" do     
    expect(Problem6.sum(1..10)).to eq 385
  end

  it "finds the square of the sum of the first ten numbers" do
    expect(Problem6.square(1..10)).to eq 3025
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..10)).to eq 2640
  end
end

describe 'up to 100' do 

  it "finds the sum of the square of the first one hundred numbers" do 
    expect(Problem6.sum(1..100)).to eq 338350 
  end

  it "finds the square of the sum of the first one hundred numbers" do 
    expect(Problem6.square(1..100)).to eq 25502500
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..100)).to eq 25164150 
  end 
end

And here's the code. You'll see each of the three pieces and how they work together. And you actually don't even need the three pieces. (Looking at it again now as I post, I'm seeing that the question only asks for the different so you don't even need to define the sum and the square separately.) For me, when I originally did this, it was easiest for me to define each to visualize it better but now I see that was unnecessary and the final piece is really the only thing I need.

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| i*i }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = (number_set).reduce(:+)**2 - (number_set).map { |i| i*i }.reduce(:+)
  return difference
end

puts Problem6.difference(1..100)

end

If you wanted to keep each of the three parts, this is what the code would look like:

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| i*i }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = square(number_set)-sum(number_set)
  return difference
end

puts Problem6.difference(1..100)

end

The primary difference is that, instead of taking the information for the difference and repeated all that code, you are taking the result of the sum method and the result of the square method to find the difference.

The One Where I Get a Mentor

I am excited to announce that I’ve been selected as one of the first mentees for the new Arlington Ruby mentorship program! There is a lot of informal mentoring that goes on in Ruby communities which is really amazing, but sometimes it’s really difficult to get a mentor. Sure, there are lots of people you can ask questions to but having a more formal mentor is different. Knowing that time and dedication are required also makes it more difficult to ask someone to commit to you in that way. It involves both the mentor and mentee developing goals for what they want to learn and both people are invested in the relationship and progress.

Arlington Ruby has recently formalized their mentorship program. The goal of the program is not just to connect new programmers with experienced ones and it is not to just benefit the two people involved. The program involves peer mentoring and a lot of thought into how the mentors and mentees will additionally contribute to the rest of the community. You can check out the official guidelines here. In the meantime, I’m super excited to have Chris Sexton as my mentor!! For the next six months, I’ll ask him hundreds and hundreds of questions (he may not know what he’s gotten himself into) and I’m looking forward to developing some goals and posting about my progress and what we work on here.

Thanks Arlington Ruby for putting some serious thought into how to continue to make the Ruby community even better. Hopefully other Ruby groups will copy this format and it’ll become a way to build stronger local communities for all of us.

A Day in the Life of LivingSocial

On Wednesday, I had the opportunity to shadow at LivingSocial with Tony Pitale. Tony is awesome. He was a coach at the first RailsGirls workshop and really enjoys teaching (which is good for me because I enjoy asking a gazillion questions). LivingSocial is, by far, the largest company I have shadowed at so far. A lot of the initial part of our day just focused on looking at different tools that LivingSocial uses and how the company is structured.

There are over 100 developers that work for LivingSocial, which to me is interesting to think about in terms of culture. I’ve met with some smaller teams so far, teams that almost all work from one office, teams that work entirely remotely, and the in between but none with the sheer mass of developers that LivingSocial has. It was really informative for me, especially as I look at different company cultures as a job applicant, to learn about how tasks are determined, how teams communicate with one another, how standups work, and what sorts of professional development and peer learning opportunities exist at their size.

LivingSocial has a lot of different engineering teams. Each team is responsible for one to a few apps. That team is responsible for knowing all the logic of that application’s purpose and also helps different teams work on different code without stepping on toes, interfering with others, etc. There are a ton of different applications. In order for the applications to communicate with one another, a lot of synchronous API calls are utilized. This means, basically, that when an event happens, the event needs information from a different application in order to continue and make the process happen. There are also asynchronous API calls for other types of events and application communication.

Finally, LivingSocial uses a ton of different tools to measure and provide information about what’s happening. To just name a few we looked at were graphite, rearview, new relic, hive, and kibana. Each has it’s own purpose and tracks something different. The really cool thing about looking at all of these different tools was figuring out how they are used to see what’s happening. For example, when an alert, error, or bug report comes up, you can go into these tracking tools to get more information on what is happening and also to make improvements like site or transaction speed.

Other smaller things I learned:
*If you drag the icon of your sublime text file into the terminal, it’ll put the file path and you can run the file!
*Serializers. What interesting pieces of applications. Serializers say when you take a record out of a database, these are the attributes that we want back in JSON. They’re good to use when you’re building an API. You use something like serializers so that you don’t have to make a class with a method as_json which defines what would get returned as JSON. (Serializers relate to an interesting conversation I had with Jim Gay about presenters and what presenters are used for. As I learn more about rails, it’s also been really interesting to see how you can continue to break out these pieces of information to make cleaner, more organized code.
*when TDDing something, you can also use it to think as a design helper. If your test for a specific item is getting to large or crazy, it’s probably time to break it into different pieces and look at the code design a bit.
*A good way to organize TDD tests are by thinking through the logical order. So the test order should be setup, execution (thing you want to run), assertion (event did happen), teardown.


Overall, a really interesting day at a really interesting company with a really interesting setup and a really interesting teacher!!