I came, I saw, and it was awesome.
All of my fellow Rails classmates did amazing. It was so much fun watching everyone go up and present their final projects. Not a single person lacked passion and love for their project. I have a lot of pride in my project, Pricimate.

The idea for my project came from my wife. She’s in touch with the artistic community and knew that there was a void for new artists.
They don’t know how to price their works of art for sell.
So I made that my mission. Help Artists Price Their Work I proceeded to scrum out what my wife/client believed to be important, calculated my story points for each, and found my priority list.
For MVP, I got all of my basic features working in Rails. But that wasn’t good enough, I needed more dynamic features, so I proceeded to work in AngularJS. In the end, my app worked exactly how I wanted it to.

I practiced my presentation many, many, many times. Being 100% prepared was essential for me. Stumbling, forgetting where I was, or skipping a few sentences were not things I was going to do.
And I nailed it.
We had 6 minutes alloted for presentations; Mine was 5:57 (we had a timer on our podium). I felt like I had complete confidence in my app because I prepared as much as I did. People had engaging questions after my presenations, like what I had to offer was very interesting to them. More importantly, in intermission I had three people come up and directly compliment my app, offer their direct feedback(which was great) and wanted to know my current employment status.
I was floating.

I had so much fun at The Iron Yard.
Would definitely recommend it to anyone who wanted to learn an insane amount of content in a short amount of time. It requires dedication. You will get out what you put into it. Being satisfied by getting the work done isn’t enough. You have to push yourself and take what is given and throw it up a couple of levels.
Don’t like the page having refresh over and over? Use Ajax, or something like AngularJS.
The beginning Ruby assignments seem easy to you? Write tests for them, or throw up your work on sinatra.
There are countless things to do to push learning to the absolute maximum, and it all falls on your dedication. I loved every bit of being there, I don’t regret a day I spent at The Iron Yard. I feel 100% confident I can solve many complex problems I don’t have the answer to, and that is because of my training. Now the job hunt begins, and I don’t feel like it’ll be too stressful because of how much weight the name “The Iron Yard” holds.
Life is pretty great when you push yourself.

I woke up surprisingly energetic this morning.
I think it is because I feel prepared and excited to give my demo. The amount of work that has gone into my final project at The Iron Yard has been intense. The last two weeks I’ve worked mostly 10+ hours a day sorting out everything I wanted. Starting by building an app from scratch, to a finished/polished product that is in working condition. That was one thing that I wanted from my final project. Not an app that had hard coded information, or tweaked just for our presentation. But a real, live, working application that can be used with minimal difficulty.

I have had a ridiculous amount of fun these last couple of weeks. Digging into code, building something that was entirely based on my skill, and being able to show it off to others. I feel like I’m on cloud 9. It’s really a great thing that I scrum’d out my workflow as to set specific goals in a timely manner. I would be freaking out if I still had to work on code today. It has been stressful, meeting personal deadlines, not knowing how the end product will turn out. I feel confident now. My work is great and it is an uplifting feeling to create something by yourself that is a presentable product.

My next post will detail the application that I built. I’ll go over why I built it and for who. Also I’ll post the link for the app and my github.

Many thanks to the folks at The Iron Yard. It’s been a blast.

It is my last week at The Iron Yard.
It feels like the last 11 weeks have flown by, mainly because I have been having a ridiculous amount of fun. I have been stressed, anxious, and nervous. Learning how to cope with all is part of being a developer. To take the negative feelings and look beyond them.
“Why am I feeling stressed? I guess it’s because I’m having a hard time getting this to work.”
Understanding yourself and the root of your feelings can be a driving force. After understanding the stress, I can redirect it into a thirst for knowledge.

I’ll be happy and sad after my demo day is done. Happy that I had completed the course to the best of my abilities, learning so many different things. Sad that the environment that I have been in, everyone giving 100% to learn, will be over. But alas! A new chapter will start, with great people with great purposes. Life is pretty cool if you give it a chance.

That was intense.
I had a really fun time this weekend. It’s amazing how much can be accomplished in such a short amount of time. I went into the hackathon with the mindset of building something that would work when it was over. I was successful.

Our app was a pseudo dropbox that would be used by businesses and allow clients to download/upload files without making an account. I took the task of scrumming together a work flow for my team for the weekend, gathering input from a couple of the pitchers. Because of this, we never had a situation where we asked what was next. At the end, I was told that I looked and acted like a project manager. Also, our app looked like an enterprise worthy application, and was planned and built accordingly. That was a pretty nice ego boost, to get feedback from strangers that my techniques in building and managing and application are very effective.

Working with a front end developer and an IOS developer was very fun. Being able to cultivate my data to tailor their needs was different. Our front end developer was very fresh to The Iron Yard (2 weeks in) and was a stellar developer. I took the time Saturday to teach him Haml and he took to it quickly(major props to you Dean). Being on a team like that was worth the whole weekend to me. To be around minds who also had a thirst for knowldge and had a different perspective on everything. I look at things very logically, they had a much better perspective on design and user expereience. I had a great team and more importantly had an absolute blast.

So in about 20 minutes the internal hackathon at The Iron Yard Atlanta is going to begin.
I’m pretty pumped.
Not really knowing what I’m going to be building.
Who I’m going to be working with.
If I’ll be able to do everything I want to in the time frame (probably not).
All of these variables seem like it’s going to bring an epic weekend.

The teams are going to be preselected. Each team will get at least one Rails Engineer, IOS Developer, and Front End Developer. Most teams will be groups of 3, some groups of 4. I’m hoping to think that my team is going to be extraordinarily bad ass. Well to be perfectly honest, everyone at The Iron Yard has talent. Everyone will be able to contribute something. I know going into it that I want my team to scrum our project. I already have a nice spreadsheet laid out and ready to go. Now it’s only a matter of time before we start.

I’m excited.

It’s about to get crazy at The Iron Yard.
We have a week and a half of lecture and practice until we begin final projects. Honestly, I have no idea what I’m going to do. I know that I would love to build a site combining the strengths of Rails backend with Angular JS’s front end. I suck at ideas though. If I have an idea of what to build, the general idea, then I can run with it and do something fun. Getting that initial idea is hard as hell for me. I plan on asking various people to get their advise for what kind of project would be memorable and useable. From October 3-5 The Iron Yard is doing an internal hackathon (Combination of the Front End, IOS, and Rails classes) and I hope that I get an idea from there that I can run with for my final project. I would love to work with other classes and form a Scrum centric idea process and work flow to knock down a project.

The last couple of weeks have been group projects for us. Last week I was the project leader of our group and it was very different experience for me. I didn’t do pure scrum with the group. I didn’t get client input, or make a board. I kind of winged the inputs in my head to develop a MVP. This week the leader of our group was a former project manager, Robert Groller, and knows how to use scrum. Actual scrum implementation is much different than “winging it”. I like the workflow process much better with full scrum. The timeboxing, workflow, and everything. I want this process in my final project. My intention is to have James, my teacher, act as the client and give me feedback on what he thinks a user experience should find important in whatever I do.

Now I just need to figure out what I’m going to do. I’m sure I’ll figure it out soon.

In this article I’ll detail the process of logging into google via the Omniauth Gem.
I set up my code almost the same as how my teacher, James Dabbs at The Iron yard. Also keep in mind that devise is needed to be setup before omniauth will work.

Getting Set Up

The first thing we will do is add of the gems and gem dependencies we’re going to need for logging into google. There are two gems that are going to be needed. The first is the actual Omniauth Gem and the second can be found on the list of provider gems that are supported with Omniauth. I decided to use the google-oath-2 gem.

1
2
3

gem 'omniauth'
gem "omniauth-google-oauth2"
gem 'hashie'

Note: Always run bundle after changing your gemfile
Note: I’ll go into the purpose of Hashie in the identifier section

It is becoming a trend for websites to enable logging into that website via another.
We’ve all seen it. The buttons that say “Sign in with Facebook”, or various other providers. For some reason unknown to me (really unknown to me because I don’t use social media), seeing these logins provide some kind of weird validity to a website. It’s like “Oh, they are connected with facebook, they must be credible”. When I know perfectly well that its just a little bit of code hooking into the facebook api. Regardless, implementing these login features for a user is a great strategy from a user experience (UX) standpoint.

Over the next few blog posts I’m going to go over step by step using provider authentication, and being able to use multiple providers for the same user. I feel logging into various providers is a valuable skill for every Rails developer, and a great tool to be able to use.
In the upcoming posts, I’ll use Amazon and Google as my examples. I’ll also detail what is needed to add another provider, and some quirks about certain ones (Twitter).

There is so much I don’t know about security.
Yet it is so fascinating. Yesterday I attended a workshop hosted by Nvisium, with the premise of discussing vulnerabilities in Rails and how to avoid them. It amazes me how much security professionals know. In order to understand security, you need to know everything about the framework you’re using, as well as exactly how the web works.

The workshop was led by Ken Johnson, the CTO of Nvisium. I won’t go into the details of exactly what we did and what we covered. Instead I’ll focus on mainly what I gained from the workshop. For me, Security has three faces.

The first face is owned by the designers and those who develop the front end. For them, the only care for security is that it is there, but doesn’t change how they want to order and design the page.

The second face is owned by the developers who want to get code to work. I am guilty of this. I generally attack code trying to get a feature to work, not really thinking about how the parameter I have listed could be sql injected or could give away a person’s id to allow to try to narrow down who is admin and try to attack that specific person.

The last side lies on the ones who want to protect security. For them, trying to convince the first two to use best security practices must be an absolute headache. To take a feature that looks the way the design team wants, and functions the way the developers want, and tell them that they are vulnerable to attacks. It seems to me that they would always be the “bad” guy in that situation. People care about security, as long as it doesn’t effect their daily lives.

I took a lot of notes and got a ton of resources from the workshop. My plan is to try to do the best I can do make sure that I plug the big holes of security in my apps. I know that at my current state of being a junior developer that it would be impossible to try and do everything, but I will take all the necessary steps to prevent my app from being completely vulnerable.

We go through material so fast at The Iron Yard.
It isn’t like we go through things too fast, but just fast enough to understand everything. I personally have a tendency to forget basic syntax when blazing through new material.
Do I put a semi-colon here or wrap it in quotation marks?
Do I need curly brackets here?
Little details like that come up often in my brain. I find it helpful to try to not remember the exact syntax, but where I wrote code similar to that to reference. That way I’m not trying to rush and memorize specific syntax, but over time as I continuously refer to my own work it will become more normal.

Personally, I enjoy looking at code that I have wrote before. Especially code that I don’t remember. I can see my progress and have the “what was I thinking when I wrote this?” moments. To be able to mock my previous self is crucial in self evolution. See what I did, and make it better. Then I’m not just referencing some article online, but take something that I put time into and make a new reference by upgrading it. There is always something to do. Code can always be smaller, faster, and more efficient. It’s my job to find a perfect balance between those and the time it takes to write the code.