Contract Work

Friday, January 31, 2014

Interesting Reads 1/25-2/31

Another busy week but I've got some good stuff today. For better or worse, the reads this week are mostly NOT code related, but they are fun.


Delicious Flags

Regex Crossword!! I haven't done this yet, but I totally want to!

Jewish Hair - Learning to love it

Conference calls in real life video

Wednesday, January 29, 2014

Storing cookies

Once we established the connection with the website and authenticated, we then needed to take the cookie that we got back and save it so that we could call it in the future. I did a bunch of research and looked at a bunch of different options. Quickly, I narrowed it down to a few possibilities. I was considering HTTParty which I had heard good things about and seemed to have good reviews from people about being easy to use and implement. The other option was Faraday which also seems to be pretty popular and was super easy to set up and get running, at least to establish the connection. I also researched an option that included using curl commands in order to save and then reaccess the cookie. There were a few faraday middleware gems that I experimented with but in the end didn’t need to use them. I ended up with this:

@authentication_cookie = response.env[:response_headers]["set-cookie"]

This line finds the header “set-cookie” in the response and sets it to the instance variable.
Then, I wrote this
response = conn.get do |req|
  req.headers['cookie'] = authentication_cookie
  req.url endpoint, params 

return response.body

This code makes another request from the same connection established earlier and sets the header cookies to authentication cookie. It then tells the connection to use a specific endpoint (using the API, based on what information you would like) and adds some parameters. This sets the response to whatever is returned from the api and then response.body takes that response and prints out the content of the response but without the headers or other junk we don’t really want to see.

Saturday, January 25, 2014

Interesting Reads 1/18 - 1/24

This week I started working with Purpose! Working with them this past week has been really interesting and really wonderful... BUT it means that I've currently got close to 80 tabs open covering things from "new stuff to learn" to "things to read" to "things to watch". So... I have definitely not had a chance to read everything on this list yet, but they all seem like excellent pieces for the week.


Ruby Conferences! (not an article but a new awesome site)

Monday, January 20, 2014

Contributing to OSS

So, if I haven’t said it enough, getting involved in the community is crazy important. I’ve recently been looking for a job. The process has actually been more difficult than I anticipated. A lot of people will tell you it’s incredibly easy to get a job in this field. I’d say that while there are positions available in the field, it is still challenging to convince a company, especially as a newer developer, that you are worth it and that you’ll totally blow them away… if they just give you the chance. Additionally, I want to make sure that where I end up is the right fit. I feel fortunate to have years of professional experience that have allowed me to really know myself as a professional and give me a better ability to determine if a company is a good fit for me or not.

While looking for a permanent position, i’ve been looking for great, challenging projects that continue to expand my skillset and make sure I’m learning as much as possible while I have the time. A few weeks ago, I was approached by a friend at a meetup who had a little too much on his plate and felt he had some work that would provide me with some good experience. Because he’s a friend, he knows my level and therefore I’m very comfortable asking questions. He also thought this project would be a good one because he could provide support, the gem needed to be built but isn’t super crazy complex, and he felt it could provide me with a good opportunity to contribute to OSS… something that is on my goals for this time period and definitely something I’ve been looking to do. Conversely, as a solo freelancer, he hasn’t had the opportunity to often pair or to take part in code reviews, a skill he wants to develop. We saw this as a win-win situation and there I was... working on a ruby gem. The gem posts are a little post-dated because I wrote them as I was working on the gem but didn't have a chance to post everything!!! So, I'll try to get these posts up quickly.

The gem has some simple functionality. It is essentially a way to work with a company’s API and download additional information about email blast campaigns beyond what they currently provide. The gem involves writing tests, utilizing an http client, and working with the API.

I have to admit that a large portion of me is/was terrified. I’m building something new. I’m actually getting paid to do it. AND it’s then going on the interwebs… as a gem… and a part of OSS… for other people to use!!! But fortunately, I’m not terrified enough to shy away from the opportunity.

Geoff had gotten me started by giving me access to a private repo, creating the gem structure, and providing a few details and resources he had thought through in regards to the gem. I started by creating the spec file and thinking through what this gem would do in order to write some tests that could be used essentially as an outline. I put all these tests as pending, but I was able to scope out the major functionalities by thinking about what the output would be and what we would need to make sure is working.

I then started on the actual code. I started by taking the tests and looking at what classes those would create. Classes should each have a single responsibility so I looked at each action that needed to happen and thought about a class structure based on that. My intention is to write the code all in the same file and then do some refactoring to break it up. The next step was looking at the http clients. There is an authentication component to this gem and once the authentication happens, a cookie is received and that cookie needs to be stored in order for it to be used in future actions.

Friday, January 17, 2014

Interesting Reads 1/11-1/17

Unlike last week, there was a bunch of good stuff to read this week! I've been thinking about conference RFPs and potentially trying to speak more so a lot of the links below feature aspects of speaking.

A lengthy but good read about houses in Detroit, totally unrelated to tech and coding but important things to think about.

A great Venn Diagram about being a developer, coder, hacker, etc. and the differences between them all

The Github Speaking Culture

Encouraging more female speakers through Passion Projects (an initiative I think sounds really cool).

A better resource for individuals who want to speak.

Advice on doing technical presentations

Monday, January 13, 2014

Bot Refactoring

When something is built, it’s never fully done. A application without bugs doesn’t exists and once you release something into the world, there are always issues that come up and ways to make the code better. Releasing the bot into the irc channel brought to the surface a few issues that I’m working on. For example, the bot awards points not just to nicknames but to any word that comes after a number with a + or – symbol in front of it. I’ve also had to change a few regular expressions to make them more specific.

One of the main things I started working on once the initial bot was out was refactoring. Refactoring is important. It’s a way of going back into your code, cleaning it up, making it easier to understand and more transparent. Refactoring also helps to DRY out code, meaning that you look at your code to see when and how you repeat yourself and take out that repetition.

In the bot, there are two main places to refactor based on methods that are called often. For a majority of the functions, I provided an array of responses or gifs as a variable. I then called m.reply variable.sample. So instead of continuing to write this over and over again, I turned these actions into a method.

The method looks like this:
def reply_random(m, list)
  m.reply list.sample
This is pretty easy to read but basically, the list is the array and so the method is to give a random reply based on the list given and replying with a random response from that list.

This is what a corresponding function now looks like:
  on :message, /.*(coffee).*/i do |m|
    reply_random m, [

The second method I created to DRY out the code was the second most common functionality. This is where there is an array of response that are either replies or actions and instead of writing out the whole process (as explained in this post about bot functionality) I created an action or reply response method, which operates similarly to the reply_random method above.

def action_or_reply_response(m, list) 
  list = list.sample    
    if list.first == :action   list.last 
      m.reply list.last  

and again, with this change, this is what the code looks like:
  on :message, /.*morning.*/ do |m|
     action_or_reply_response m, [
      [:reply, "Good morning to you too!"],
      [:reply, "it's a brand new day!"],
      [:reply, "I'm sleepy today"],
      [:reply, ""],
      [:action, "yawns"],
      [:action, "makes coffee"],
      [:action, "*throws open all the windows* it's a glorious day today"]

Friday, January 10, 2014

Interesting Reads 1/4 - 1/10

Well, I have to be honest, there wasn't much out there this week. Maybe it's because everyone was focusing in their first full week back at work in a while but there just wasn't much that caught my eye. I do have two link though... not as much good reads as good resources.


Full Stack Rails Developer Resources. Lots of good resources that really helps you think about what "full stack" really means.

This is an emoji cheat sheet because who doesn't need one of those handy.

Monday, January 6, 2014

Cooking and Coding

I’ve been playing around with this post in my mind for a while. See, one of the things I’m truly passionate about is cooking. I love to cook and I love to bake… each requiring a slightly different mentality. For those who do either, you understand the differences.

Cooking is oftentimes about getting into the kitchen, opening up the fridge and throwing some things together. There is tweaking that goes on along the way. You might add some more salt, or usually in my case a dash of cumin. You might substitute one ingredient for another. Sometimes the concoction is great. Other times, you watch it sit in the fridge because it didn’t turn out quite right.

Baking is a little different. There is a preciseness to baking. You need to measure and create the product according to the instructions. In baking, there are very few places where you can or should deviate from the given recipe. For example, my high school chemistry paper was on the chemistry of cooking. Even simply adding ingredients in a different order will give your product a completely different texture or volume.

For me, baking is my calm, happy place. It’s what I do when my brain is in overdrive and I just need to pound some dough, get my hands dirty with flour or batter, or just focus on bringing each of the pieces together.

The more I code, the more I think of how my journey mirrors that of me learning how to cook and bake, and how different parts of the coding process are exactly like cooking versus baking.

When I began learning how to code, it was hard. It was difficult to motivate myself to do something I wasn’t comfortable with. It was difficult to wrap my brain around all the pieces. I always wanted to see a picture of the final product and know what the final result was supposed to be before getting started. Furthermore, I only followed recipes. I had no ideas what spices went together or when I could substitute one ingredient for another. I followed the recipe to a T and if I didn’t have a spice or an ingredient… I gave up on the recipe and searched for something else to cook. Cooking also took me longer to get through because I wasn’t familiar with the process. The first time I deboned a chicken piece or roasted a squash, I needed to read the instructions a few times because I felt lost at the initial direction.

Once I started to become confident about my cooking, I was able to get better much faster. I cooked a few times a week and I didn't dread it. Cooking more often made my knife skills better and my prep time shorter. Additionally, it made me more adventurous. I was no longer afraid about something not turning out exactly like it should. I substituted ingredients based on what was in the fridge and created meals from my mind and not necessarily straight from the cookbook.

I’m still not a master chef. I never will be. I hope to continue to flex my culinary creativity muscle as I cook more and learn more. Each time I add a new ingredient or a new recipe into my repertoire, it teaches me about flavor profiles that belong together and how I can mimic that with other ingredients. Just like with coding, I am still honing my ability to figure out when something is just right… the right balance of flavors and textures.

Every code involves some cooking, some sense of does it taste right? Does it look right? Does the texture look good? Is it pretty? And what do others have to say about how I could improve the recipe in the future?

Now for baking. As I mentioned before, baking is precise. You need to have a gut feeling about baking. Do you add a little more flour? What happens if you throw a pinch of nutmeg into the mix? Does this dough feel right? And if it doesn’t, what alteration should I make? It has taken me a while to develop my baking gut feelings. When you screw up baking, it’s often a bigger disaster than with cooking. It’s easier to cover up mistakes with spices and other ingredients when you cook but when you bake, sometimes you don’t know something went very wrong until you pull it out of the oven. Other times, you know something doesn’t feel right but you’re not sure what the best way to make it feel better is. And sometimes, the best thing to do is to just punch and knead it for a little while.

I imagine I’ll develop my baker’s sense for coding as the years progress and in writing this, it makes me feel like testing and practice test driven development relate more to the baking side of coding than the cooking side, highlighting it’s importance.

Regardless of whether you’re baking or cooking or coding, all get better with time and practice. All give you raw ingredients that you intelligently mix together to make something better. And all provide you with challenges, problems, and hopefully, wonderful solutions.

Now, go grab a snack and get back to coding.

Friday, January 3, 2014