How I learned Swift in about 3 weeks

I did not start my journey into Swift 3 weeks ago, but actually started back in June, the same month Swift was announced by Apple. I was very much focused on learning more Rails and had no real desire to learn it extensively, so I only dabbled in some reading. At that time I had already started learning Objective-C and messing around with iOS( which was just opening and closing Xcode). I started working through some of the Bloc iOS curriculum, but mainly read through curriculum and did not finish the alcohol calculator project.

Fast forward 2 months and I declared September as the month Swift for myself. I began reading the ever so dry Swift Language Guide and completed the Treehouse Swift course videos but wouldn't actually write Swift code for another month.

I have begun facilitating LearnWithMe sessions with CodeNewbies where the focus is choosing a subject in programming that you are interested in learning with others. I was approached, Swift came to mind right away, since it has been a milestone I continue to push down the list.

I started my first session with the CodeNewbies and ran through the Swift Tutorial: Quick Start, which I highly recommend due to it's great job in explanation of basic Swift programming and Xcode Playgrounds.  Just last week I started a tutorial I had on my list for months, which I highly recommend, Bloc's Swiftris tutorial. This tutorial was the perfect next step for myself to really understand how Swift works with the iOS framework. I also got actual hands on in Xcode and actually make an app work. I was blown away when I ran the build and heard the Tetris music running in the background, it was a great feeling.

Today was my 3rd Swift session and I ran through another basic tutorial called, Learn Swift. The nice part about this tutorial is the pre-packaged playgrounds you can download and play with.

What's Next?
My immediate goal is to start and complete another tutorial in iOS/Swift, I do not have plans of attempting non iOS tutorials at this point, since I already have a basic understanding of Swift; enough to at least debug errors. I have downloaded the FlappyBird Swift code which I will be reading through and plan on completing the Treehouse Swift Weather app.

If you are interest in joining me in learning Swift, keep an eye on the CodeNewbie forum for the next event.

My goal is to become proficient in mobile development and have the ability to transfer my web development ideas to the iOS platform. Thanks for joining on that journey.

Pairing in node with a Healthy Hacker

I had the opportunity yesterday afternoon to pair with Chris Hunt, host of the new podcast Healthy Hacker. After listening to the "Growing as a Programmer" he made an interesting announcement that I have not yet heard anyone else do at his caliber of programming. He was offering free time to pair with him in 30min increments. I signed up rathe quickly after noticing a number of open spots.

At the time of signing up you have to put in a subject to pair on for the session; With me being really ambitious I chose a subject I had zero experience in, node.js's socket_io plugin. I planned on messing around with it prior, in hopes to add live chat to my Ruby Newbies page, but it didn't happen. I got extremely side tracked with learning Ember and updating my Chuych app.

My overall impression of pairing with an absolute stranger on a subject I had no knowledge on, was great. Not only did we finish the socket_io tutorial, we also got it pushed to heroku and tested it out live. I did the driving in the pairing, while Chris navigated through the documentation, which was extremely valuable in me learning. We did get hung up on pushing a node/express.js project to heroku, since both our experience were in Rails, but he was able to pin point in the docs how to update the server to the heroku environment variable.

I am actually pretty stoked to continue to work on this project on my own and implement it with the RubyNewbies things. Node is a new frontier for me and I hope to continue exploring the various plugins and frameworks associated with it. To view our code check it out here.

If you are interested in pairing with Chris, checkout his calendar and sign up soon, but there seem to be very limited spots available.

My VIM config

This is a copy of my current .vimrc. Do you have any suggestions?

2 weeks and nothing but VIM

I decided that the 2 days prior to my Thanksgiving holiday would be a great time to switch to VIM at work and I admit it was stuff not to pull up Sublime text for specific things. One of the most common reasons I have heard for not learning VIM is the need to not loose time for switching workflows; This concern is understandable, but the only way to learn is by doing.

The past two weeks have been packed with learning how to update my .vimrc and making sure I have the most common plugins installed.

Right away I missed some of the most common shortcuts in sublime text, like quick indenting and commenting. Thanks to the Nerdtree and my custom key mappings I can still use them. I also finally figured out what a <leader> which has greatly assisted in mapping special commands to.  

Some of things I look forward to learning is finally figuring out how to do project wide search properly, at moment the rails-vim commands and accessing the buffer tree have been great additions to my workflow. In addition to all that I hope to learn how to run test directly from vim with a mapped key command, but like all things, I have to pace myself in learning; I am desperately trying not to spend my entire day learning cool tricks - I still work to do.

*update - thanks to @tracehelms I was able to solve my project searching issue.

Copy current file path in VIM

I found a vim shortcut to grab the file current path and copy it to the system clipboard.  I wrote a blog post in the past about key bindings in sublime, and my favorite key binding which has the same path grabbing functionality.

The .vimrc can the host the same type snippets that sublime, but obviously in a different syntax. I am pretty excited to add this to vim with it being one of the two thing I miss from sublime. The last thing I miss is not really a missing functionality but just my lack of knowledge and that is project wide searching, but I believe with a little practice I can figure it out.

If you have any pointers in working with let me know.

Learning Swift with Me

Tonight I had the opportunity to learn Swift with other new developers and I am impressed amount of knowledge I took while slowly going through a tutorial with others. This has definitely been one of the learning experiences.

Swift is a new territory for me, something that is new for me. I like that is also newer for everyone else. For example, one of my goals for 2015 is to actually build an app (not a tutorial) in Swift before March. I am hoping that the app I finally build is my chuych app.

The tutorial we completed was A Quick Start Guide to Swift and I highly recommend for anyone looking to expand their knowledge into Swift. My next tutorial will I am aiming to complete is Bloc's Swiftris.

If you are interested in learning how to write a Tetris Game in Swift and want to learn with me, keep an eye on the Code Newbie discourse page.

What ever happened to Chuych

I spent a good amount of my learning Rails while hacking away at an idea I had to find churches easier. This idea for a church app was actually the reason that got me started in this journey in the first place, but this app been rejected in the past mont

Back in August I rewrote a lot of the Rails code and even added test for the functionality. I then began learning a lot of new front end techniques and frameworks to eventually redesign the app from the ground up, but I got distracted.

I first got distracted just learning and recently realized I was not spending nearly enough time writing code. The fastest I have ever learned code is by writing it and I have made the decision get back into making apps. I have spent nearly 15hours of logged time rebuilding the design using a bootstrap template ( I was avoiding using bootstrap, but gave in).  I now have an app that I am proud of and looking forward to sharing it with actual users.

The irony is that this has been complete for nearly 8 months, but I have been dragging my feet to actually share it and have people use. It's one thing to build an app, but its much nicer to have real people use it, which I have found joy with in RubyNewbies.

I have been putting git flow into practice and focusing one feature at a time, I did not spend my time in TDD as much as I like to since the majority of changes were CSS and not backend. I also set my integration test to pending during that time since I did not have a design in mind, I look forward to going back and rewriting those.

Look out for more post about my rewrite of this app coming soon, specifically the challenges of maintaining an app with legacy code.

Before:

After:

ember CLI install and murdering my node

Never ever ever sudo with npm installs. I did not know this and probably unknowingly did this all the time. In my early days in Rails I never had an issue, only because once you install Rails it's stalled and be upgraded in the Gemfile. With Javascript, I am quickly finding that a lot of things require the node package manager (npm) to install and upgrade. I recently upgraded my ember to use the ember-cli, came across this sudo errors, but thanks to this homebrew issue thread I was eventually able to solve my problem.

My solution included this premade bash script called "murdering your node." From there I could clean install node and ember-cli.

If you are interested in learning Ember I suggest starting with the ember-cli-101 book. It is hands down the best Ember tutorial I have done and has gotten me pass some of the toughest hurdles I have faced in learning a Javascript MVC framework on my own.

*FYI: just to be clear you can sudo your way through npm, but it is not recommended, especially with ember-cli.

I am IZEA (video)

The company does a lot of work web influencers and bloggers in the social media space and has created a number of showcase what IZEA is all about. I was approached as an employee of IZEA to be the focus in one of them and would like to share it with all the readers of my blog.

The posts on this blog is a representation of the hard work I put in to finally get a job as a Ruby on Rails engineer. Thank you for all the support you have given me while I have been on this journey.

git commit -v

Everyday I use vim I get a little better at it, and actually surprised on how fast I have progressed this past week. My hesitation to jump right in was unfortunately the only thing preventing me from really learning it.

The best that help break my timidness in vim was writing my commit messages us the vim IDE. The common way of commit work is using `git commit -m`, but I recently found out about `git commit -v` from an upcase video; Rather than set your message per commit, you are able view the `git diff` and add a commit message while viewing what you changed.

I highly recommend viewing the diff before you create commits, it will help you catch misspellings and prevent debuggers from getting in a pull request.

Setting up Jasmine TestRunner

Shortly after I wrote my previous post I found this awesome video on getting the Jasmines Test Runner set up. Javascript testing is still a mystery to me when it comes to set up and preferred DSL'a, but it seems as if Jasmine is quite popular and where I will be spending most of my time.

I am also interested in Chai, just because it sounds so good with Mocha

I can't recommend Koans enough

I have basically gone through the majority of Eloquent Javascript, working through problems here and there,  and just about done with it. The book has definitely taken more time to get through than expected, mainly because it is new territory for me. I have found that Javascript is language I have to get hands on writing with, actually Ruby was the same way. I can't just read Eloquent Javascript and pick up the concepts.

I have found great success working through Javascript Koans. The basic form of Koans are simple programming test which you make pass by literally inputting the answer given. I did spend time filling in the answers without looking them up but when I got stuck all I need to do is run the test and read the assertion for help. My explanation of Koans does not give it justice, which is why I highly recommend checking it out for yourself.

Prior to moving to Orlando and taking my job at IZEA, I work through the entirety of Ruby Koans, this helped me learn the syntax of Test::Unit. Previously I only had experience with Rspec and the majority of the testing at my new job was Rspec.

Another thing the Koans taught me was how to write more test. The structure of Javascript and Ruby Koans does not require you to write test, but from reading the already made test it help me understand how to write proper and more extensive test.

Like I said in a previous post, it's hard to be inspired when you never look at the way others do things. If you write Javascript or Ruby and are not testing currently or want to expand your knowledge into testing, download the repos for Ruby and Javascript Koans today.

*Please note there are other types of Koans out there but I feel these are the best introductions into them.

My Baby Steps into VIM

I have spent a lot of time attempting to complete the challenging Vim-Adventures, but have found solving the integrated puzzles more challenging actually learning VIM. I am actually still stuck on level 9, I found I needed to learn VIM faster and actually completed vimtutor twice.

Vim-Adventures is definitely one of the best ways to learn muscle memory, as you tend to learn how to move around without even thinking about it. The vimtutor tutorial is definitely one of the best tutorials and covers a lot in a short amount a time. I imagine you can complete the entire tutorial in less than an hour on your first run through.

The entirety of my VIM learning was completed while running the test suite at work, which unfortunately takes about 30mins each time (something we are working on in making better). I decided last week that after spending 2 months learning VIM in small spurts, it was time to actually start using it.

I got a very brief walkthrough after my last TDD  practice session. I got to see tmate.io (actually tmux and not vim, but still a cool tool) working in the wild and even install the JANUS VIM package. Last week I attempted to work on a feature using VIM but quickly found out despite my extensive research and practice, the previous tutorials do not have sections on working through the file system.

I moved on to learning through the free Vimcast and Vim Novice Tutorials which has helped in learning the VIM workflow, like splitting windows and entering and exiting the file system.

I am not yet ready to use VIM at work but I have been working through the Javascript Koans. I am finding that koans is a nice and safe way to learn how much I would rather be using VIM at work. My goal is to switch over when I complete the the entirety of the Koans and become a little more proficient.

If you are at any level interested in try out VIM, either type vimtutor in your terminal or checkout Vim-Adventures. Warning, once you get the initial muscle memory down, you might get addicted.

Invalidating text as html with Nokogiri

I am finding a lot of my issues with writing code at work is due to the specific use case of our industry.

I was given the task to add an input box to a form that will allow HTML snippets; these snippets can be a variety of types but of course exclude script tags. I wrote a line of code that validates HTML but it failed QA testing since plain text was allowed to be added to the form. 

This check_html method validates the HTML provided, but it was still allowing plain text, which is a functionality I had to circumvent. I finally came across a hacky solution which was to parse the content using an XML call. After 90 minutes of deliberation I came to this solution:

*note: I was checking for image tags because the XML call specifically disregards the "<img>" tags and requires "<image>", but this worked because it disallowed plain text to be input. I was later informed by my peer that not all XML was valid html and there would not stand the chance of time, I did say this was a hacky solution.

Not proud of this, I submitted my code for peer review and was quickly informed that my attempt was noted but plain text is valid html... Not taking any formal "HTML" course in college I had not known of this fact; All that work to only eventually find out that I was trying to invalidate something that was technically valid.

I was then provided this solution thanks to code review:

Nokogiri parse the HTML and separates each element tag into children and nodes. This code checks to see if thre are any children that have nodes with plain text and finally invalidates those. Like the intro to Star Trek: Enterprise, "It's been a long road".

I hope sharing this will help anyone else in the trying to validate html in put forms, this have proven to be a great learning experience.

My tour with Javascript

I have spent this weekend learning some more Javascript using the book Eloquent Javascript. I have not put as much dedication in learning Javascript until very recently. I have worked through part III of the Javascript Roadtrip on Code School which has been challenging, but not hard I previously thought.

I am finding having a basic understanding in Programming and Ruby makes learning more advanced Javascript a lot easier. I am about to begin chapter 8 and very much enjoying this book and the ability to solve exercises in the browser. I am however, having a lot of trouble just figuring my way around solving problems outside of book. I spent 3 hours on the exercism problem that I solved easily in Ruby.

Learning the Javascript way of doings things has proven to be the challenge. For example I am currently trying to figure out enumeration in Javascript, which is easy in Ruby because I know the name of the standard library methods. I just need to find better sources for looking up Javascript functions, `forEach()`.

Friday was another "hackday" where I spent the entire time working on an app for work called "Beer Club." I am part of a club where we all chip in to buy a new keg for the office and seem to be getting hung up on the voting of a new keg. The app would allow us to add multiple beers to a list to eaily vote on.

I unfortunately started the app in Ember and spent most of the day learning how to play nice with the framework. It was a similar experience when I tried to first learn Rails. The day eventually ran out I restarted the app in just Rails with a basic bootstrap template. I am looking forward to finishing this app for obvious reasons and plan to shoe horn Ember in it once the Rails portion is complete.

My plan is is to now switch my focus away from iOS and put all my learning efforts into Javascript, since it is a tool I use at work and will benefit from a lot sooner.

2014 was the year of Ruby for me, I am thinking 2015 will be full of JS.

Concentric Circles in Learning

When I was younger one of my least favorite cartoons was the Road Runner.  One of the main reasons that I did not like the cartoon because of Wile E. Coyote. In his effort in catching the Road Runner he never kept at it with the same tools, and always thought he had to try something new.

In the beginning of my learning to program journey, I tried everything. I tried a lot of languages before I finally settled on Ruby. I actually first started with C, but when that got boring I quickly jumped into to Ruby after spending a brief time in HTML/CSS, but years prior I attempted to learn JAVA with much failure.

I also tried a lot of different tools to learn Ruby and built up quite the backlog of things to complete, including books, videos, and course. My thought was to blow through each learning tool quick enough to learn the next, but I very rarely did things twice.

My entire outlook on learning has completely changed now that I work as a web dev, but I feel like it is for the better. I now spend more time on one learning resource at a time and actually find myself revisiting things I have already completed.

I heard of the term, Concentric Circles in Learning from a fellow Odinite, Afshin. The idea comes down to making your learning cyclical by repeating going through learning materials multiple times. My biggest complaint with Code School is that I did not understand the material the first time through. I then avoided learning Rails through the Rails for Zombie course, but when I revisited months later after completing a number of Rails Tutorials, it made much more sense.

One of the biggest recommendations I heard when going through the Rails Tutorial is to go through the same tutorial again. I met an individual at local meetup who loaned me a copy of the The Well-Grounded Rubyist after going through it 3 times. There is a lot of truth to learning more the second time around.

I now actual read books multiple times and repeat chapters as well as complete the problems in the book(Eloquent Javascript). I have been slowly working through Vim Adventures while running my test suite at work and feel VIM has become second nature because of it.

Before I felt like I was cramming for a test before an exam every time I learned something new, I now leisure read through material not worrying about capturing everything in my brain because I can always capture on my second of third time through.



I highly recommend going through resources multiple times and don't give up just take a break.

What are your thoughts on this? Do you re-read and run through videos multiple times or do you try things once?

Change your local host name

Did you know that you can update your host names. For example rather than typing in localhost:3000 to boot up your rails app, you could call up brian:3000.

All you need to do is call up `sudo nano.etc.hosts`and append a new line at the bottom with your the new alias and the reference of 1.27.0.0.1, voila. The only catch is that you need know how move around the NANO editor.

I recommend not replacing localhost but rather just creating an additional alias.

sudo nano /etc/hosts

For more info check out these detailed instructions.

Practicing Code [Global Day of Code]

A year ago I embarked on a journey into learning how to program. I spent 550 hours of hard work across 7 months towards a goal of being proficient in writing code. The word proficient is very subjective and as I think if I am or not, I think of what areas I need practice in.

I have been playing my entire life, began at the age of 9, and as a musician I understand the importance of practice and trying different things. As many children I group listening to fair bit amount of music but never really got into classic rock and crazy guitar solos until I got into college. It was never an area of music I appreciated until college, but once I discovered that genre, I was able to increase my musical ability exponentially.

I have volunteered to facilitate the Global Day of Code, because just as in music I understand the need for practice to strengthen skills. The Global Day of Code is meant for developer who does not have time to try new things or appreciate other languages because of time constraints and deadlines. Due to these constraints we generally stick to the techniques that we have proven and avoid the risk of trying something new.

If you are looking to get into a new programming language or just strengthening your programming skills, the Global Day of Code is for you.

The structure of the day is broken up into 40 min pairing sessions with different developers throughout the day. There is a very good chance you will pair with a developer who has a different idea of how to write code and solve the problem, which open up the door for you to learn.

The problem laid out for the pairs is Conway's Game of Life and is a fairly straight forward but very unlikely to be completed in 40minutes, during each pairing session a new constraint is provided to challenge the pairs, For example one session I was given the constraint where I person writes test and the others write the code to pass the test, without talking. This was rather difficult since I had never tested in Ruby prior and had the luxury of also pairing with someone using VIM, which I also had no experience with.

The entirety of experience at the code retreat was only 1 month into my journey towards learning code and I still took away a ton of information. It actually began my attempt into testing in Ruby and is the main reason why learned it early in my programming journey.

If you are interested in joining a Code Retreat near I highly recommend and if you are in the Orlando area, I highly recommend joining me on November 15th.

One Year Into this.

This happens to be a pretty big milestone week for me. This is actually the week I started learning how to program. I remember waking up in the hospital and having the idea of learning how to program.

A year ago I was only in my first class of my MBA and I wrote my first MBA paper on Google. I had recently got interested in them after reading the book In The Plex. The book got me thinking of starting my own journey into programming and thus began my deep dive, feet first.

I had an idea for an application to search churches based on location. I had previously tried to find a church from google but failed to  find any decent results. I had the idea; I jut had no idea where to begin. I thought about getting into iOS but previously attend Android development years ago but lost interest very quickly after realizing you had to learn JAVA. I decided to start in C programming, since it was the most basic, and I used a free course called Computer Science for Everyone. This course seems to be no longer available on the internet, but I do know it is available in questionable places for torrenting, but I rather not link there.

After 2 weeks of that I blew through the basics of C and Computer Science but stumbled upon a video on youtube about learning Ruby/Rails in only a month. I couldn't jump ship any faster, I love this guys drive to learn so quickly and after a quick read on Ruby, I found it to be significantly easier to read. I signed up for his course and that begin my journey with Ruby.

Learning to code is probably one of the best decisions of my life. It not only gave me a new career but also gave an opportunity to use a multitude of my skills.

I have completed an Apprenticeship, started an online community, and even completed the building of applications. I am definitely excited to see what is store for this next year. 

Capybara page.save_screenshot('screenshot.png')

I spent a lot of time trying to fix integration test at work and have experience using the `save_and_open_page` command to view the actual page. This has been an awesome addition to my test debugging, but recently I discovered a new command `page.save_screenshot('screenshot.png')`.

The screenshot command only works with pages and test that use Javascript, and are great to check to see if the functionality is really happening in a controlled environment.

I spent the past weeks working on a filtered search using Sunspot/SOLR which is all new stuff for me. SOLR is basically a tool to do searching of the database and Sunspot is the gem that connects Rails to SOLR easily.

SOLR has specific methods that query the database and I spent a lot of time checking out a number of them and testing the UI to be sure the correct data shows.

I am sure I could of spent the entire time in the terminal testing functionality but using my integration test and the Capybara screenshot command to view the actual page was a little more rewarding.

If you have integration test I highly recommend using Capybara to debug integration testing. I wrote this post to remind myself of the syntax, since I literally google it every time I need to use it.

*UPDATE: the screenshot call only works if you enable javascript in your test, with something like selenium:

 `def switch_to_javascript
    Capybara.javascript_driver = :selenium if ENV["FF"]
    Capybara.current_driver = Capybara.javascript_driver
  end
'

Thanks Adam Brice for pointing that out.

exercism_io revisited

I recently got back into exercism.io. For whatever reason I only completed the first Ruby exercise and never returned, but now I have turned over  new leaf. I have decided that I need to write more code outside of work. Lately I have only been reading books and solving small problems on treehouse.

exercism is an awesome tool that is obtainable for any novice in programming in a multitude of languages.

I feel as if I am a decent Ruby programmer but could use some help in the "Ruby Way" of doing things and best practices. exercism_io will hopefully get me to the next level; the feedback I have already received from my first submission has already helped.

I have also made my first Swift submission which was ok, the actual code did not compile and I couldn't get the test suite to run in xcode. I have been bootstrapping my learning in Swift with the free Swift books offered by Apple on the iBooks app. I highly recommend picking that up.

If you are looking to join a group on exercism, join us on the Ruby Newbie team and if you need help setting up exercism, feel free to reach out.

Ruby Science

Ruby Science is a book written by the popular Rails shop, Thougtbot. I had the opportunity to try out their upcase program a few months ago but cancelled it because it wasn't what I was looking for.

I however have recently acquired their Ruby Science book and absolutely love it. If you like myself, are newer to programming, Ruby, or just look for better ways to write your code, then I highly suggest this book.

I began reading this book last Friday and accidentally read the whole thing by Sunday, it was that good. I have usually taken the approach of reading books slowly and pondering on the concepts to really get them but this book was just too good. It might be hard to tell but I am pretty excited about this book.

I did not realize at first but the way this book is written is sort of a choose your own adventure style, where the book is broken up in 3 sections., Code Smells, Solutions, and Principles.

The Code Smell section is full of code that looks like what I would write, good code but bad practices, for example a "Long Method." Methods are meant to be short 3-7 lines and if they are larger they can probably be refactored. This chapter was so eye opening I went back to a pull request I created that Friday morning and made tons of changes and got some pretty awesome comments from my coworkers on my abstraction, little did they know it was because me reading this book.

The second section is on Solutions. You hear a lot of talks and know the buzzwords about writing clean code, but this book really breaks it down to the point where you just get it. There is definitely no fluff and extravagant examples but I really enjoyed this approach in the book. To get an idea of what I am talking about, the book is as straight as the front cover, right to the point of everything.

The final section is on Principles in programming. I learned what the Law of Demeter was because of this section, as well some other really big terms. I have heard of so many of the terms but never really knew their meanings. I actually knew of the Law of Demeter Concept but did not realize what it was called. It's the idea keeping your method calls to one and not chaining method onto to method on to method, i.e. `run.forest.run` .

When I first started this programming journey, I watched a fair bit of conference talks, most that went over my head. I recently was re-watching CatchupConf, specifically Ben Orenstein's talk on Refactoring and found that so many of those concepts explained that I didn't understand, I now understand and even have been using these past 3 months working as a developer.

Here is a sample of the book: Ruby Science

Teaching Github to College Kids

I recently had the opportunity to teach a group of UCF Engineering/Computer Science students how to use git. There is an organization called Engineers Without Borders at the University of Central Florida in Orlando; The president of the organization reached out to a coworker of mine to teach them about Github. My coworker was unable to attend and threw it out there to the team and of course I had to accept.

I truly enjoy teaching others and love taking the opportunity when ever I can.

The meeting was on Monday of this week and I spent the weekend preparing a short slide show on the topic. My understanding that the students need to know how to use git and Github in order to collaborate on group code projects.

The group of about 40 kids were mixed with all different types of engineering backgrounds, some with experience in code and some without.

My approach was to share how git works initially and it's basic commands, Unfortunately the school was not equipped with a thunderbolt to VGA adapter, and I failed to put one of two I owned in my backpacked. So I presented from the limited Windows PC showing git via Nitrous.io, which was quick thinking on my part.

Overall the presentation went ok, despite the technical glitches with the internet. I was actually surprised that a handful (maybe 3-4) of students already knew git and had a github. one student really impressed me and already had a Rails project built (only if I got into to Rails in college, I'd be a baller right now).

Teaching git has actually taught me a few new git commands I have begun using, like `git reflog` which gives you the ability to see all commits on the project. I also learned despite deleting a branch or commits they all live there and are retrievable by their unique commit id.

Remember git saves changes, not files.

My 37k dollar mistake: ilikerobot.com

If you listened to my interview on the Code Newbie podcast I mentioned briefly that I had a slight debacle with my AWS key to the tune of 37k dollars. I feel like I should write a public service announcement about it to help others, so here it is:

Coming close to almost a year, I started my journey November of last year. I began a few tutorials and online resources, but the first complete tutorial that I finished was One Month Rails and it was an awesome experience. In only two weekends I followed the instructions step by step to create the site ilikerobot.com. I was so excited about it I even convinced others to use it.

At that time I did not use github at all and barely knew how to use git, but fast forward to the beginning of January and I had mastered the process of pushing to github, so much that I pushed all my projects to public repositories. Little did I remember the warnings from the OMR videos to not publicly posting any files with sensitive information.

You see the sample application is a Pinterest clone which requires users to sign in and post a picture of a robot. In order to save these upload pictures, you need a tool like AWS's S3 service to store these pictures. AWS provides a secret key and bucket names and 1 year free access to this. After the year you will need to pay, but at the rate I was using it, it might of been pennies.

When I pushed the repo to github I neglected to hide all the sensitive information and did not realize until I received a phone call from Amazon out of the blue letting me know my keys were published on github, this was back in May at the time I was interviewing for jobs, so my focus was not this project I created months ago. I had the key inactivated and I deleted the specific file on github (this is not enough) and moved on with my day. Little did I know that there actual charges made to the account from an attackers that scrapes github for all sensitive information, actual clever and I am sure very easy due to the amount of new programmers.

I only found out about the charge because I have been making an effort to update all my old apps and bring them up to speed with Rails 4 in addition to writing previously non-existent test suites. I lost access to the photos on the site and could not log into my AWS dashboard. After getting my login access back I noticed the large bill and had a phone call with Amazon the next day.

I am very pleased with their understanding and effort they put in to having the charges reverse. They also protected my account even with the root of the problem actually being my ignorance. I would highly recommend them to others looking for simple cloud hosting, I do recommend a few things below.

My recommendations to protect your projects:

I am still all for making code public in repos on github but I recommend everyone learn about `.gitignore`. This is something I learned about after OMR but did not put into practice with my first app. You simply create the file in the root folder of your app and place all private file paths there. Git will know to never save these files and you will be responsible for saving your login info outside the repo in a secure location.

I also recommend the figaro gem for Rails projects on heroku. Their github readme is more than enough to get started using it, but it is also helpful in protecting sensitive information like API keys.

*Update: I also suggest this GoRails video on Environment Variables

Code Newbie Podcast

For those interested, I was on a Podcast call CodeNewbie and shared my story of how I got into web developing in Ruby. The podcast itself is on Itunes or via RSS from the site.

Saron is definitely an amazing host and I am glad I had the opportunity to do this.

Why I am using git flow and you should too

I have learned many things in only 3 months real Rails Engineer(not just on tv) and I have been a slacking a bit on sharing those skills due to the increase workload I continue to take on. I did want to take the time and share on `git flow` and why I am using it on my overhaul of my breakable toy app, Chuych.

While attempting to work on my chuych app in the past 3 months I have notice that my commits are a bit all over the place and I lack the focus to complete anyone thing, for example sticking to one design. This is why I have taken it upon my self to use git flow (What is git?).

 My goal has been to give my personal projects more of a focus lately since they have been ignored. I spent a lot of time trying to get up to speed in Ruby, Javascript, and even learn iOS on the side. I can say I really lost focus on maintaining my own code portfolio. I have however been taking work home and spend a couple hours on the weekend working through refactoring and bug tracking in my work code.

I have slowed down on my learning of new skills and languages and restricting myself to only learning things that will increase my productivity at work and make my chuych app more robust (This will not effect my iOS learning). I have spent the past 2 weekends building out my test suite and it is at a point where I can no just add test when I implement new things.

Git flow  is feature of git where you can speed up your workflow, in the command line, by creating structure in your branches/commits with shortcuts. This feature will create a branch, merge a branch, and close a pull request in 2 commands. It is not uncommon for someone to work on their personal app and commit and push everything on their master branch. There is no shame in this if you do so; I was doing this up until last month. I am now using git flow to create separate branches to organize my thoughts and focus on one feature/fix at a time. This really helped me finish the last of my testing and will hopefully help me build out my design stylesheets.

If you learned rails through any tutorial they team you to commit as soon as you are done with a full feature or full programming thought. They sometimes briefly teach you about branches, but from my recollection, it gets abandoned rather quickly in the tutorial, or at least I abandoned it. It really isn't necessary to be so verbose in your branching your commits, but for apps you would like to keep around for awhile, structure is what will keep your sanity.

My recommendation is to try using `git flow` for one feature of your site, if you are not already using a similar method, it will bring sanity back to your app development just as it has mine.

The Process:

To begin you will need at least 2 branches created in your app. I named one master and the other develop, but feel to use any naming convention.

  Master Branch - This branch is standard, especially using github and coming from tutorials. I believe most Rails developers and even possible back-end git users use this branch name. If you are using heroku or another deploying method, it can be deployed from here.

  Develop Branch - This is the branch where all you code will be merged to first and tested.

It is important to keep master separate in case you merge a breaking changes or something goes wrong, the merge history should be primarily merges from develop unless its a hotfix (to be explained later).

You can also create staging, release, and QA branches but I am keeping it simple for now and suggest the same.

Install:

There are complete git flow installation instructions on the web but I will provide the cliff notes.

Start by type `git flow init` in the command line and proceeding with the steps prompted in your terminal. They will ask what branch your feature will be merged to, my recommendation is to use the defaults on the screen and the develop branch to merge to.

Workflow:

Again there are many workflow examples on the web but I will provide the cliff notes.

In my current we follow the current structure.

1. Create a feature branch `git flow feature start <desired_feature_name>` while on the develop branch. What ever branch you are on will create the new feature branch, so make sure you are on the correct one.
2. Push the branch to git `git push origin <new_feature_branch_name>`  this will create the branch on github, be sure your git remote is set or you will be prompted the first time. 
3. Open pull request, on github you can use create a pull request compared to develop for peer code review. Instructions on creating a pull request.
4. After feature is complete `git flow feature finish <chosen_feature_name>` this will merge your branch to develop and delete your feature branch locally only. 
5. Now the final can be of your choosing, but you eventually need to merge to master and then deploy once tested. At work we would now create a release branch using `git flow release <release_number>` and repeat steps 2-4, replacing the final merge to master instead of develop.

*a hotfix is a pressing bug that will actually be merged to the master branch instead of the develop first. You will create these off master and follow the same steps 2-4.

Why:

So why do it this way? My answer is again to stay focused on feature at a time; it will also help when I actually get my app built out, I can work on multiple feature at a time if I get stuck or choose to work with another developer. I also will start using release cycles once my app hits 1.0 (i.e. has some sort of front end design).

If you are reading this and still learning rails in hopes to get a job doing it, I recommend trying this out, if it doesn't work for you, you can always delete the extra branches continue to push changes directly to master. If you do decide to do this, it would help you in the eventual interview since most companies use this or a similar technique in the development.

If you have questions or if something was unclear, please shoot me an email or leave a comment.

Managing Dependencies with POODR

I recently spent some time preparing a talk on Managing Dependendencie, a topic cover in the POODR book by Sandi Metz.

Programming is great:

I came from  a sales position where the only keeping me there was the paycheck. I am person that enjoys perpetual learning and not that sales can't be a perpetual end to learning it can also be a drain. I now have the ability to now make things that matter and be a part of something rather than just sell the idea of it. I now have the privilege of maintaining an application with a lot of legacy code.

In sales I have learned to observe the situation and I have notice that programmers are notorious for knocking the previous developer. Rather than understand the code they choose to curse the code for its brittleness and unending work to update with change.

Dependencies:

A recurring misstep in the code I see is the problem I see in my work code but as well in other is change is hard to work due to the large amount of dependencies in the code. Dependencies are the messages sent between objects. In the example below, there is a message being received in the initializer and an outgoing message in the :gear_inches method.

*Please note that the attributes are incoming messages, chain-rig, cog, rim, and tire.

Problems:

The problem with dependencies is that there are too many. The idea of creating Practical Object Oriented Design is to have the least amount of dependencies.

Solution:

Writing maintainable code is another goal having a practical design. As a programmer you should be able to revisit your code and easily understand what is going and also easily implement a new change. In the above examples, the Gear is too dependent on knowing about the Wheel and how its made and which order the rim and tire should be placed in the argument.

The suggestion is to instead pass in the wheel as an argument; this free up the ability for the gear to depend less on the Wheel but also allow other parts of the bicycle without getting the way of the Gear and Wheel relationship.

I hope this post has been useful and also hope to share more info on the subject in future post. *Examples came from the book Practical Object Oriented Design in Ruby, I highly recommend this book to all new and experienced Rubyist. 

Editing a commit after the fact

Multiple times I have found myself in need of editing my commit messages due to typos or unclear messages. I have that the use of  `git commit --amend` and `git reset -- hard`.

Having a short and concise commits have been useful for myself, especially I have had to start and my feature stories multiple times during the course of the month.

Another practice in reading code to learn is reading each commit(line by line) to get a good understanding on what the code is doing. Reading commit messages on code that you have no association with could feel as an unneeded experience, but my recommendation is to do so to grasp a better understanding of the code in general.

*update* If the terminal is your default way of using git then you will need to know enough VIM to navigate. I recommend vimtutor or vim adventures. Of course you could always use the github GUI but thats doesn't feel like coding :)

How to Install Rspec

*For some reason I thought I wrote a post on this, but it seems I have not.

Gems are wonderful make it easier to add complicated functionally to your add. A large number of gems can be installed and implemented in only a few steps. Installing Rspec can be completed in a few steps and can be even easier if you install in Rails.

1. gem install 'rspec-rails'

If you are working in a Rails application, it is recommended to include the `rspec-rails` gem because of it close association with Rails generators. If you are not using Rails, then the plain `rspec` gem will suffice. Once the gem has been added to your gem file, it may be implemented using `bundle install`

2. Create spec helpers and config files.
This is even easier,the command need to finish the install is `rails generate rspec:install`. This will create all the need fils for add any additional functionality to your testing suite, including auto testers and stuck/mock libraries.

*Please note if you choose to create an application without rails, you will need to install those file manually. I spent 2 hours in a starbucks once trying to figure that out, but that story will be for another post.

3. Place all test in the `/spec` folder and append the `_spec.rb`. This will ensure that the `rspec` command runs all test.

For more clarification on installing Rspec, please see its Github readme. I also recommend a trying it our, since the best way to learn is by doing. Checkout the the examples from the Rspec book.

Also checkout: Ruby for Newbies: Testing with Rspec

Finally building a complete test suite for chuych

Now with 10 weeks of real work experience I have gained more experience than I could have ever imagined.

I am shocked to find that my first commit to github for my chuych wasa whole 3 months later. My previous goal was to gain enough knowledge after beginning work to keep up with my daily workload and I feel I have just reached that point.

My second goal as of August was to start committing to my personal projects once again. I have succeeded by providing my first commit August 10th.  My hope is now to complete my test suite by Sunday, which will include Features and Models (using Rspec).

I am looking forward to writing a complete test suite to ensure my app is free of most bugs. I will be focusing some future blog post to my current work in testing. Once I complete this task I can move on to improving the front-end design, which has been lacking since it's inception.

TDD? More and more people I come encountered with do not use TDD and it's not a mystery that I do not use this form of testing, but the concepts I have learned from thoughbot's upcase TDD workshop has been more than enough to learn the idea of testing in Rspec. Whether you test before or after, testing is still the same, and I highly recommend learning TDD is you are interested in writing better test.

Testing small has made it easier for me to get the ball running and getting an overall idea of what needs to developed next. I currently have tests for 3/4 of my existing models and plan to move on to Integration/Feature test which will tighten up the functionality of my app. I have found that the geo-searching was very buggy and the rendering of the Javascript was also hit or miss, by testing this will help identify the problem and fix it.

For a tip:
My recommendation is to start with validation testing to help get past the awkward part of testing,  I have an example of that below.

Tomorrow I will write a post on setting up your test environment.

How I defeat Impostor Syndrome

What do I do to defeat Impostor Syndrome?

I realized I could of title this blog post differently, 10 ways to defeat Impostor Syndrome, but I feel there are only 2 things I did to defeat Impostor Syndrome.

When I started attending Ruby Meetups last fall I heard of the term Impostor Syndrome briefly but never really took the time to look into it. I quite honestly never heard of the term prior to my journey into web  development but it seems to be an issue that actually all types of people and fields.

I listened to the a recent podcast unrelated to programming where the host explained his suffer through impostor syndrome while attending his first classes in med school.

"Impostor Syndrome, is a psychological phenomenon in which people are unable to internalize their accomplishments."

In my previous career I made a huge effort to obtain a job in sales without any prior sales experience. I spent a good amount of time researching interview and sales techniques to only be turned down for multiple positions because of my lack of experience. I was even turned down for my first sales position, but due to to the first candidate failing their drug test (which I found out later from a co-worker); I was called back a week later and offered the position. I of course accepted the position but couldn't help but spend the next two years thinking that I did not belong there.

The thought that I was never good enough and that I would eventually be figured out as a fraud (hypothetical)  crossed my mind multiple times during my time in sales. Within my first 2 weeks I closed a significantly large deal and didn't make a big deal about because I thought it was not good enough.  My drive became not settling for skating by and doing just enough. This unintentionally caused me to become promoted twice within 4 months.

Accept It

In my own words, Impostor Syndrome is not something that ever goes away, I realized this buries the lead, but if you understand this concept it can be a great way to defeat it daily. Similar to fear, it will never leave you 100% in life and even the fear of failure will always come up in your career. I know I am not the best at software engineering but strive to be a decent great engineer.

It's possible in sales to become insincere due to their lack of confidence and end up presenting a false image of confidence. It is highly possible you have to fake it to make in a career, but it only alienates you from others putting you on a shaky pedestal. By accepting your faults it makes it easier to understand what areas you might need help in and helps you challenge Impostor Syndrome head on.

My suggestion is not elevate yourself into something you are not, but rather learn from your peers and and openly admit that you do not know. Within my first week in sales I was told to never tell a customer that you do not know, but rather tell them you will find out. I sit here writing this post today with problems I have yet to figure out in Ruby and no plan to solve them. I do plan to research my answers, but I also plan to reach out for help and assistance when stuck.

There is no doubt the company I work for today took a chance on me, as an aspiring engineer with no experience, and I feel everyday that I must prove that their decision was worth it. I swallow my pride knowing I made a leap so many strive for and keep my eyes on the next goals of the day. My hard work does not stop because I have gain employment, it only just began.

I am a bit of a listener and love learning from others, not only in programming, but in life generally. I have learned that even the most decorated and influential people in my life deal with Impostor Syndrome. I have also the realized the individuals who have no need to worry about Impostor Syndrome are the individuals who are stagnant in their careers and abilities. Most can grow content in a position where they have expert knowledge in, never challenge or pushed to try something new or hard.

Impostor Syndrome is great way to encourage yourself to strive harder and admit your weakness to eventually strengthen them. Use the fear of not being good enough to work on areas you can improve in.

Do Something(Step outside you comfort zone)

I heard of how a study was conducted on monkeys where they placed 5 monkeys in a room where bananas were placed in the center room, only reached by access of a rope. When a monkey could make it half way up the rope a man in the same room used a firehose to spray the monkey off the rope, cruel but stay tuned for the meaning. Eventually each monkey tried until they realized the futility of trying for the banana.

The second stage of the study involved each monkey being replaced by a new monkey, which was quickly discouraged by the others not to attempt for the bananas without the aide of the water hose. It got the point where monkeys in the room were replaced by individuals that had not experienced the fire hose but knew to discourage any new monkey.

When I started into web development with everyone telling me how hard it was, I even avoided the Hartl tutorial because everyone told me it was very difficult. I smile when I think about that because the tutorial itself it not as difficult as perceived, seeing how all the code is handed to you to type into your IDE, the only impediment is starting.

I started an online study group on the internet because I knew I needed help from others and sought out to associate my self like-minded individuals. I had a local meetup available to me to meet and chat with other local Rubyist but it only occurred once a month. The group I started was RubyNewbies and it propelled my learning immensely. Prior to RubyNewbies I had the fear that I couldn't complete the most basic of applications in Ruby, but once I realized the best way to beat that was to do something about it.

I pushed my self into a role of sharing my knowledge of what I learned literally a week prior in order to identify areas for improvement in myself, if I could explain it to other Newbies, I did not know it well enough. When I first heard of the Odin Project I jumped into the Rails Study group to capture missing knowledge needed to eventually get a programming job. I chose to lead a separate study group in order to propel my weaknesses into strengths.

Every video I recorded I had the fear that I would be asked a questions I could not ask or be given a problem I could not solve, but instead of quitting I accepted the challenge. I chose to record the videos to not only keep myself consistent but also make it available for others. There were multiple times where I stumbled over my own slides and even said I don't know but I chose to continue my journey towards learning Ruby.

I eventually completed the Odin Ruby curriculum, even while accepting a job as a Software engineer and moving 100 miles across the state of Florida. My determination to prove to others that I could make was really a way of proving to myself that Impostor Syndrome could be defeated. When interviewing I flat out said I did not know, but I could find the answer in a Google search. I even said stated that I was barely a decent programmer, but I had a strong desire to learn. Selling my faults with my strengths was something I would never of done in a sales interview. In sales I avoided sharing my weakness in order to sell myself as the Impostor. This is not a practice of all sales professionals, but it's what I thought I needed to do to get by.

Accepting that Impostor Syndrome is real is the first step but actually doing something to challenge it head on is the second step. I am glad I had the opportunity to make this career change and come to realization of how to accept and change my outlook towards Impostor Syndrome.

Summing it up

There are intentionally only two steps to defeat impostor Syndrome to avoid getting lost in a perpetual planning cycle. My goal is to encourage others with a story and 2 step process to create more encouragers.

Impostor Syndrome is unfortunately not something you can defeat once with no need to worry about in the future. If you are like myself with goals, dreams, and aspirations you will deal with this regularly. The key is accepting it and deciding what you are going to do about it and if you feel you are in a position where Impostor Syndrome is not a problem, I have to asked: Are you stagnant in your personal development? Are you helping to grow others by creating an encouraging environment?

I am not an expert in Psychology, I have some life experiences and hope that this post can encourage those that read it. This is a post I have wanted to write for awhile but coincidentally did not feel I could for reasons implied in the above paragraphs. Writing is just one way I defeated Impostor Syndrome today.

Best of luck with your journey and thanks for reading.

{}.tap have you seen or used it?

I have never heard of the tap method but am glad I have made the discovery. I planned to use it in my code at work, but have not had the opportunity yet. I find lately I have tried to force many new concepts in my code, but have yet been able to.

Its probably better not to force them. I love the idea of the <=> operator but have not used it once in a real life experience, even in code quizzes. I will probably used the {}.tap method sooner and actually tried it out for the first time yesterday, but ended up taking it out in a refactor.

Check out this blog on the tap.{} method.

I am finding out that there is a right way to Ruby and wish I read Eloquent Ruby a lot earlier. I spent too much time not reading books and going through basics of Ruby. I highly recommend every new Rubyist to read Eloquent Ruby. It is a great guide into Ruby and explains a lot of questions about when to how to write Ruby with best practices.

Reading Rails Group

My originally idea for the next Ruby Newbie activity was to read different Ruby libraries, but I found it hard to find new and interesting libraries to check out. I chose the Inflector Library because it was a library I started looking into at work but as I read through it I found out it was a Rails library.

I have avoided Rails and it components when doing new things for Ruby Newbies and trying to stay focused on learning the concepts of Ruby, but at the end of the day Rails is Ruby and thats why I plan to hold a new event on the off weeks of the book club, called Reading Rails.

Rails is made up of 7 main components and the first component we will be reading through will be the Active Model. I am excited to finally jump into reading Rails core libraries and hopefully demystifying it. If you are available please join the discussion this Sunday.

There will not be a requirement for joining, just a basic understanding of Ruby.