Contract Work

Friday, September 27, 2013

A day in the life of Treater

One of the challenging things about entering the world of development was that I felt like I came from a completely different universe. I got a degree in political science and near east studies, always thought I was destined for a job in a government agency and then almost accidentally fell into the Jewish nonprofit world and loved it. For years, my job was about created experiences, building community, taking people to coffee… very different than the day-to-day of development. I saw a little bit more of a developer’s day-to-day in the startup world, but most of the people I work around are the only tech person on their team. One person responsible for all tech is different than how teams function and what a company culture looks like for startups that are just a tad bit larger.

I had the opportunity this past Monday to shadow the dev team at Treater for the day and it was great (Thanks JD for giving me the opportunity!). Treater seems like a great place to work and I learned a TON in just the day I was there (including my first look at someone using vim to code instead of sublime text and finally seeing what hipchat is all about). One thing I wanted to highlight was the idea of a scrum meeting to do sprint planning.

I had heard of scrum meetings and sprints/sprint planning before but had never had the opportunity to see first-hand what happens at these meetings, how development pieces are discussed and how the next few weeks are planned out. Additionally, I’ve run a lot of meetings in my life and have always been a part of a hierarchical structure but have always been curious about larger startups with flatter structures.

The scrum meeting starts with the scrum master (all this, by the way makes me think of rugby which is really not anything like one of these meetings). This meeting had three parts: review the last sprint, retrospective, and go through the next sprint, all utilizing the company’s Trello board. Each part is important and I was impressed by the fact that everything everyone said was acknowledged and considered. The review of the last sprint helped to set additional goals for the current sprint (sprints are two weeks long). After reviewing the last sprint, priorities, deployment dates, and phases were discussed. The retrospective was the most interesting I think. It gave each team member a chance to think about where they were at after the last sprint and address what they themselves or as a team could do better in the upcoming sprint. Finally, the next sprint was reviewed, discussed, and assigned to different people. It was really interesting during the future sprint discussion to see how each part of the team interacted (ie- front-end, back-end, testing, business, etc.). Being a part of the scrum meeting also gave me a really good understanding of what was going on so I could just jump into the code more effectively in the second half of the day.

So, if you’ve never been to a scrum meeting or done sprint planning, that’s what they’re all about (or at least based on my sample size of 1 company). Hopefully I’ll be shadowing at more companies in the future (if your company is metro accessible and willing to let me shadow for the day, please let me know!).

I just want to close by thanking the whole Treater team for being so welcoming and answering all of my questions. I really had a great time and learned a ton!

Wednesday, September 25, 2013

Environment Variable, Bash, and the omniauth-twitter gem, Oh My.

I just started building a new application and decided that I'd like people to sign in via Facebook or Twitter which meant installing the omniauth-twitter gem (and the omniauth-facebook gem but I'm not quite there yet).

My first challenge was to figure out how to keep my secret token a secret. Everyone says you never commit your secret stuff into Github, which makes sense but I didn't know how else to do it. In order to keep the tokens a secret, you need to store them as environment variables on your computer so that they can be called by the application when it is running. I stored my twitter_key; and twitter_secret as environment variable in ~ /.bashrc. Which led to an error of uninitialized omniauth and a timeout. I then learned that environment variables need to be uppercase so I re-saved them as TWITTER_KEY and TWITTER_SECRET (Thanks to Betsy for help on this one). This is what it looks like:

export TWITTER_KEY=your_key_goes_here
export TWITTER_SECRET=your_secret_goes_here

Then I got a different error. When I clicked, "Sign in with Twitter" the /auth/twitter path lead to a 401 oauth::unauthorized. Looking at the trace, the last errors had to do with requesting and receiving the tokens. I tried to see if the key showed up by calling

$ echo $TWITTER_KEY 

in the terminal and at first it did return, but when I ran the rails console and tried


which should have yielded the same result, I got nil. I also tried utilizing the pry gem to check if the variables were being sourced from my initializer like this:

OmniAuth.config.logger = Rails.logger

Rails.application.config.middleware.use OmniAuth::Builder do
puts "key: #{ENV['TWITTER_KEY']}"
puts "secret: #{ENV['TWITTER_SECRET']}"

provider :twitter, ENV['TWITTER_KEY'], ENV['TWITTER_SECRET']

and also got nil, and finally, I went back into the original window where I called $echo TWITTER_KEY tried again, and it wasn't working. So the issue was definitely that the tokens were not being read in the application.

The first solution (which was simple but turned out not to be the actual problem) was that I had been typing source ~/.bashrc into 1 terminal tab and then opening up my server in a different tab (talk about a hand-to-forehead moment but I didn't realize that the environments didn't copy over if you were in the same window but a different tab). When I did that, it worked. Clicking "Sign in with Twitter" lead to the appropriate /auth/twitter path where the user could approve the application. But again, that wasn't the route of the problem. The main issue was that I had to run the source code each time in order for the variable to be loaded into the system.

I tried to put the same export lines (the environment variables) as above into ~/.profile instead of in ~/.bashrc. I also put an echo line into ~/.profile:

echo "leading env, yay"

Putting an echo line will help see if things are set up correctly. If the shell is loading everything properly, when I open the shell or a new tab, I should see "loading env, yay" at the top.

But when I tried ~/.profile, nothing showed up. Then, I put the same echo line into ~/.bash_profile (thanks Chris for this suggestion!) and that worked! So things were working and set up correctly. To understand it a little better, Chris found this link from a great SuperUser answer. Basically, bash will only source ~/.bashrc or ~/.bash_profile. Bash looks, in order, for ~/.bash_profile, ~/.bash_login, or ~/.profile and sources whichever one it finds first. The solution is to alter the configuration.

At the top of ~/.bash_profile put:
Export BASH_CONF=”bash_profile”

At the top of ~/.bashrc put:
Export BASH_CONF=”bashrc”

Then in your terminal window type: $ echo $BASH_CONF and the file that shows up is the one being sourced.

And now my omniauth-twitter gem is working (well, at least the first part of the process is complete).

Sunday, September 22, 2013

The Beginning

Hello inaugural blog post!

Welcome to my new blog. Many people reading this may be familiar with imposter syndrome... and that's what I've had for months, a huge amount of self-doubt. I've been "learning" Ruby on Rails for a year now. I put learning in quotes because I feel like I've only really started understanding in the past 8 weeks.

My journey started last September at the first Rails Girls DC workshop. Well, actually, that's not true. I guess my journey started the previous March at Day of Fosterly. I had just recently started to get involved in startups in DC, determined to change industries from the Jewish non-profit world I had worked in since college. Day of Fosterly was my first big startup event. I knew very few people and spent most of the day trying to silently self-encourage myself to meet as many people as possible. I had heard a bit about coding and learning to code but since I hadn't taken a math class since high school, assumed I would be way out of my league. So, there I was in line for lunch and happened to meet three awesome individuals: Jim Gay, Piotr Steinnger, and Liz Steininger. They were all developers/in tech. When I mentioned wanting to learn how to code I immediately got a huge amount of positive reinforcement. For the next 45 minutes, I learned about meetups, resources, and the Ruby community.

I didn't make any moves until September when I attended the Rails Girls DC workshop (which Liz organized and Piotr was my mentor there). I had just gotten going with my own startup and decided to learn the basics so that I could converse intelligently with my awesome developers. From that September until this July, I learned in bits and pieces, mostly when I was scoping out a new feature or idea with my development team. It was in late July that I decided to spend less time focusing on my startup and more time learning how to code. So, for the last eight week or so I've spent every day, morning till night, coding, learning and getting to know the community.

Throughout this time, I've been thinking of starting a blog but was pretty certain no one would care about anything that I had to say. After much encouragement though, here it is, the blog. I'll be writing a little about my journey and what I've done over the past eight weeks (and somewhat before that) to learn as well as posting issues I come across (and hopefully the way I solved them)!