bloc referral

If you are interested in learning to code with a mentor, try bloc and get $100 off.
Showing posts with label tip. Show all posts
Showing posts with label tip. Show all posts

Friday, January 9, 2015

VIM indent all the way to Oz

I am have been using VIM since Thanksgiving and definitely not looking back to Sublime. I really do believe that the myth that VIM is this big mystery/archaic of programming is not real. It's similar to the Wizard of Oz, where everyone thinks Oz is this great and powerful being and when it is all said and done, its turns Oz is a short white dude behind a curtain, but that short white dude is you just installing plugins into your dotfiles.

One thing I did miss with common IDE's like Sublime, is the ability to hit `command + [`for quick line indentation. Well it turn out getting that back was easy, all I had to do was add the following to the bottom of my .vimrc, voila.

Remember, If you can dream it, you can do it in VIM.

nmap <D-[> <<
nmap <D-]> >>
vmap <D-[> <gv
vmap <D-]> >gv
Take the plunge and try vim today but typing "vimtutor" in your unix terminal.


Thursday, December 4, 2014

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.


Tuesday, December 2, 2014

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.

Monday, November 24, 2014

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.


Wednesday, November 12, 2014

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.


Wednesday, November 5, 2014

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.


Wednesday, October 15, 2014

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.

Thursday, October 2, 2014

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.


Thursday, September 25, 2014

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


Sunday, July 13, 2014

learn.thoughtbot.com, I tried it out.

I tried thoughtbot's learnprime, online training material months ago. I never signed up for the paid version but viewed the sample portions of the videos, but always had it on the back burner for things to do. I recently got a marketing email form Ben Orenstein stating I could start the learnprime program at 50% off.

The course is at steep price in my mind, $49 at the mid-tier. I chose to go ahead an try out the program for a month. thoughtbot is a well respected organization and I have always been pleased with their blogpost and podcast. I also have enjoyed the teaching Ben, mainly from viewed conferences talks on Youtube.

I was surprised to find out that the course did not meet my expectations initially. I actually did not even complete workshop before casting judgment, which was unfair. I only ran through the first portion of the iOS workshop and viewed the first half of the Intermediate Rails.

I admit I initially did not give the courses a chance and only skimmed through, but after just about finishing the Intermediate Rails videos. I find that they are worth the amount I paid (which was 50% off). The Rails tutorial was out of date using Rails 3.12.2 and I had issues getting it up and running with the recommend version. I finally just bundled the latest of everything, including Rails 4.1 and did not have a problem.

I eventually completed viewing all videos in the Intermediate Rails group and plan to rewrite the app a little each day. I also started the TDD app/workshop which I will probably complete this week, since it is smaller. Thanks to VLC and the ability to download the video, I have been watching all the videos 2x speed.

My final conclusion after viewing the videos is the content phenomenal and worth the money paid, I however would not recommend it to beginner or anyone just dabbling. I believe the content is great for someone with quite a bit of Rails personal experience in multiple apps/tutorials. I actually review some things I learned at work from others devs including, Single Table Inheritance and Object Oriented Design. I even saw areas of improvement I could bring into my work app, by limiting the dependencies within the controllers.

What I liked about the content is they take time to explain the best practices of Rails and concepts from Sandi Metz's POODR. I couldn't find it better timing since I have been binging on her past Rails talks, now that I have finished her book. I highly recommend her teaching and recommend watching the follow talk at Rails Conf 2013. It is basically a tease of whats in her book.

The TDD workshop is definitely a must for anyone looking to be hired as a Rails dev. Not every company practices TDD, but it is the best walkthrough of Unit and Integration testing I have seen. Even if you write your test last, the way test lines up right with the recommendations of chapter 9 in the POODR book. This workshop is $15 on it's own and definitely worth money.

 This brings to my observation, the cost of learnprime is high but they offer some high level content, which I never took into consideration. The weekly iteration is awesome videos delivered every week, and some info hot topics in the industry to stay cutting edge. Again this is all info for established devs and ones close to becoming established.

I am still on the fence to keep my membership for the iterations alone, as I feel I can finish both workshops before the end of the month. I am definitely appreciative for the content they have provided in the course; but I have no plans in completing any others but very interested in viewing all the iterations.


Wednesday, June 25, 2014

Git Cherry-Pick

Cherry-picking since day 1 at the new job. I learned this cool tool which has been a life saver while navigating my way through the new code base. I never had had the opportunity to use it previously, actually a lot of the cool git functionality I didn't use previously. Working on your own projects is completely different on collaborating on a project together with others. For example, when I was working on Chuych, I committed everything to master and rarely made branches unless I planned to break something.

git cherry-pick is a tool to copy specific commits from different branches with ease. I completed a fix to the app at work last work but realized I referenced the wrong ticket number within my commits and branch. The workflow is to use Jira to keep track of User Stories and Fix Tickets. Jira helps track how well the team is doing in the most current Sprint.

My error was discovered by a colleague reviewing my pull request. My initial though was to close the pull request and start over, but was given the opportunity to cherry-pick. If you look in github at a project, each commit has a unique id which can be called within the same project. The fix involved me creating a new branch and calling 'git cherry-pick <unique commit id> (its important to know you must cherry-pick from top to bottom, since each commit succession may be dependent on each other)










It as as simple as that and all my code transferred over without the need to start completely over. I am told cherry picking is not used as often but its great to know of this feature if needed. If you have been working on your own projects for awhile and have not contributed an open sourced project, I recommend the Odin Project. You will have the opportunity to use tools like 'git fetch' 'git pull' and even 'git cherry-pick' if necessary. Get out there and work with a team on something.

As I learn new tools I will be sharing them on the blog, so please subscribe or follow me on Twitter for updates.