Tell Don't Ask concept

So I finally attended the Orlando Ruby User's Group for the first time since October and blown away from how much I learned from two topics I was already familiar with. One was on creating an MVP and the other was on authentication with the devise gem.

The first was given by Code School's Carlos Souza and he gave us a sneak peak into a video series coming out shortly called, Feature Focus. The repo is available on Github for the Base Camp clone if you are looking to read some code, which is a great way to see what an MVP is. There are no slide available but the course will go over the details of building the Base Camp app.

Something I am looking forward is the interview with DHH and his critque on the code and his recommendations for Carlos. For example there was a method offered called "Tell Don't Ask." The idea is basically to stop writing if statements and begging the language for info, but getting what you need.

For example this is from the Code Schoolrepo. The | | is literally checking the if the result is this or that, this an alternative to writing out an entire if/else statement.

Translation to if/else:

def find_by_target

  if result = User.name
     then this
  elsif result = Product.title
    then that
  else
    nil

end



Let me know if this makes sense or can be better clarified, this a subject I will be doing some research on, for sure posting on more. Really happy I discover this. I am sure there are also better examples of this, please share those too.

subl shortcut to pull up Sublime text from the command line

I always forget how to do this so I am writing a quick blog post on how to set up your Sublime short for "subl ."

The subl command is nifty tool I originally learned from the One Month Rails videos (the originals), but when you go through the updated Rails course they do not share how to do that. Its also something you only do once and never have to worry about again, unless you are me and on their 3rd computer since starting their progamming journey.

1. Macbook from college. 2008 White Macbook 13''
2. 2012 Macbook Pro 13'' I bought used off ebay (thanks Kosh Kemps recommendation from his book.) because my first mac had too many quirks and a battery issue.
3. Brand new work computer. 2013? Macbook Pro 15''

All 3 computer I used within 9 months of each other and I install Ruby on each. I also install this shortcut and had to search through stackoverflows to find it again, which wasn't easy this last time, so here it is. Just in case I get another computer, I will know where to go.

For Sublime Text 3 just enter the below in the cli and voila.

`sudo ln -s /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl /usr/bin/subl`

Here is the stackoverflow is more detail is needed or you are using Sublime Text 2.

There are other cool commands I might share in the future for Sublime, but for now here is a video on multiple select, which I relearned to do yesterday for something.

Ember and VIM tutorial

Staying true to my goals I have started the Ember tutorial. I am only half and can't really report on it at the moment, but I do have to say its nice to go through a tutorial on a framework and understand everything that is going on. Ember is a MVC framework, which operates very similar to Rails and with my background in that framework has made it super easy to breeze through this tutorial.

On another note, I typed `vimtutor` in my terminal and got a pretty cool initiation to VIM. I didn't even know it was there but as many recommend, I think you should give it a try. There will be a day when you will have to interact with VIM, just make sure you know that `j` will move the cursor down.

!!Bryan - I am taking another look at my goals for 2014

I actually used the double bang (!!example) in actual production code at work. But first, I was taught what it actually does. There are some hang ups with using it, but just keep it use in the back of your mind in case its ever needed. Basically forces a Boolean.

Orlando.js

8 months later after I attended my first meetup, which happened to be at Envy/Code School,  I attended my second meetup there tonight. I told myself I would make it out there again but never did. For one reason its over 2 hours to drive from Tampa with Orlando 9rush hour/disney) traffic, but luckily I now live in Orlando and 2 miles from the Envy office.

I attended the second ever Orlando.js meetup, which make me surprised that there was not one before, since there are 3 Javascript in Tampa alone. Tonights meeting was in detail on OOP in JS. It kind of got me excited to learn more vanilla JS and check out some books, but for the moment I am focusing on getting through these Objective-C and Ember tutorials, but its tempting to jump into more with all these meetups.

There is without exaggeration a meetup happening every week that is programming related and I plan on being at most. I might as well take advantage of the opportunity while I am so close to them.

Goals for 2014

As mentioned before in a post, I wrote some goals out for the year and I had the opportunity to check them out again. I have every intention to complete all by the end of the year, but realize I am behind. However, I did complete the goal of getting a job.

In short I still need to create a tutorial, which I might change to give a talk (since there are so many meetups). I also need to deploy and publish a functional app, which will be Chuych eventually, and finally based on the mention by Daniel during the Ruby Newbie chat; I will be trying to hit a goal of 75 stack overflow questions answered by the end of this year(not necessarily correctly). I needed to start this yesterday.

Well if you have a question for me put it in s/o, I guess...

Working in a Ruby Dojo helps my TDD: I also learned how to view a PR locally for work.

Viewing a PR locally

Some tools you will learn and never have to use. I want to share a quick link on how to view a pull request locally. I found the following gist on how to view a pull request locally. There might be a better way to do this, but I found this to be pretty easy to do.

Starting off you have to make sure you are in the develop/master branch of the project locally(after you have cloned the repo) and run `git fetch.` Fetching will not only pull in the latest commits on the branch but all other branches in the project.

From the command line you will be able to access all pull request using `git checkout pr/<pr #>` and voila, you have access to that pr. Technically you are able to pull the branch the pull request came from also, but I find this easier, since you are looking view those specific changes.

My most recent use for this tool was to review a pull request done by a contractor, there were multiple changes to implement a feature, but it also had multiple errors. I found it nice and east to merge the pull request into my branch and check it out locally. There were multiple conflicts, but it helped me understand what they did as I fixed the changes. If you do not work in a team, I highly recommend joining up with the Odin group and picking up some small task they need done; it a great way to practice some of these concepts.

I am now going to attempt to write test to check their's and my functionality implemented, I do realize I should of wrote test after the merge to check if any of the code actually worked. I came to this realization duding last night's Ruby Dojo, where I was able to practice and view TDD in action. I hope begin writing test first today and help steer myself into writing better Ruby code.

At work TDD is not a requirement, as long as test are written they are cool with it. I also just finished the last chapter of POODR and highly recommend the book for that chapter alone. Its all about testing and testing for the right reasons. I spent 7 minutes in the Dojo testing if an argument returned that argument, which sounds confusing now, because it was and unnecessary. When testing, it should be in small increments and towards the goal of actually solving the problem, not just for the sake of testing (I will walk through this concept in a longer post tomorrow...promise).

Once again, thanks for reading and if you are in the Orlando area, check out the Dojo. Also if you want to read some inspiring post on awesome Ruby concepts check out Ramon's blog. Right now he is going through the book Refactoring Ruby, which has convinced me to put it on my list of books to read.

*If you wan to try the coding exercise yourself, check it out here and let me know how you do. Limit yourself to less than 30minutes and use TDD.

Stop torturing yourself and look it up already.

I spend everyday at work in README's and scrolling documentation.

I was surprised to find out that the Computer Science degree today sets graduates up to learn the Philosophies of Programming and walks them through Algorithmic Learning. But despite the 4 years of hard work it does not make them any closer to actually building real projects.

I went through Bloc which is an awesome program, only a fraction of what a CS degree cost, and learn the fundamentals of Ruby in 2 weeks. I was in no place to start building any large scale applications, but I had a mentor to push me through the tough parts and also got recommendations of code samples to follow.

At work I am in the very same situation, I can build a small MVP in Rails on my own but in no position to produce the amazing code needed to create an application on my own in a timely manner.

I enjoy the fact that I am surrounded by individuals from very different backgrounds, some with degrees and some without. I enjoy that I am able research programming concepts while at work and discover new tools to make my job easier, which brings me to my main point.

While learning, I found myself doing one of two things when learning or going through code exercises. I seemed to always push myself so hard to learn that I would not look anything up or even think to look at the code of others. If it wasn't my code, I felt as if it was cheating; I know now that it indeed is not cheating, but actually part of the learning process.

My initial thought process was definitely silly now that I look back and now I compare a programmer to an athlete, lets take a Tennis player. There is no doubt that Roger Federer has watch other tennis players and even absorb a bit of their style.

To think that I could be a decent programmer without ever reading the code of others and I believe its not too far off from what others are thinking. I am still working to change that thought process with myself, but thought to write on it as encouragement to myself and others.

My recommendation is to compare code to others and do not be afraid to read the code of others, even if it is for a "code challenge" or an interview. one thing I found while completing the Conways Game of Life for an interview with another company, is that they do not mind if you viewed someone else's code to complete a problem, as long as you can explain what is going on in the code.

Understanding and learning from code is not cheating, but be sure to reference to where you learned so they can get credit and maybe one day people will be sharing your code to learn from.

Now go read some code!

Rails Panel and Better Errors

I was told of another pretty nice tool to help in working with the legacy code at work. I find that trying to figure out where I am at in the app while debugging errors to be difficult. The main reason is due to the templates being named very similarly from page to page.

Chrome comes with an element inspector which works similar to rails panel to debug front end issues and discover the actual names of items in the asset pipeline. I am still very much a novice when it comes to working with assets and templates, and find it very helpful to be able to see the page interaction and found it very useful to write integration tests.

Another great tool is the Better Errors (you can debug in the browser!) that is used at work and both are explained in this short Railscast.
I am extremely blessed to be able to learn and use these new tools everyday and looking forward to sharing new tools as I learn them.

`git checkout --`
Another quick tips I wanted to add was the use of `git checkout`.  Most people might know that `git checkout . ` can be used to clear all changes to your code to your last git commit. I have found it very useful to practice writing code without any fear of breaking something, I can also revert back to the original state of the code if I mess things bad, but sometime I find I inadvertently make changes to files that I do not commit.

For example I sometime change the spacing of a file of play in a file while doing testing that does not need to be merged to the project. Instead of reverting to the original state of the code using the `period`. This week I started using `git checkout -- <filename>`, which only reverts that file.

I am sure I saw/used this tool before or maybe used it in a Code School video, but I have yet to use it till now and felt like I could share. so if you find yourself going through the Hartl tutorial and stuck on error, rather than starting completely over, just `checkout` the files.

Thanks for reading