Kaoru Kohashigwa

new goal: settings goals

![Mountains][1] by [James Pritchett][2] <br> Every weekend I sit down in front of the internet and am in awe of the ocean of information. When I say awe I mean distracted. One link leads to another link which leads to another link and by the end of the weekend I feel like I have done nothing. I get distracted easily, probably because I have no goal. I started Saturday morning on a good flow. I read about [ES6 generators](http://davidwalsh.name/es6-generators) and dug in deep. The blog lead me to Clojure and Go which apparently use the same sort of syntax. Seeing that both languages are natively concurrent it made me wonder how I can learn from it. I have no experience with Clojure and Go which forced me to learn some syntax and oh look I haven't played SimCity in a while... <br> Saturday night I'm drained and feeling unaccomplished. As if I didn't do anything. But that isn't true. I just have no grasp on what I did today. Sigh... <br> I have been learning [kanban](http://en.wikipedia.org/wiki/Kanban) recently and have been playing with the idea in my mind a bit. I would love to see how productive I am over a timeframe and a task. How much can I comfortably get done. That will give me an idea of my progress and be able to estimate how long it will take me to read a book, or learn a new technique or new technology. I love having a plan and executing on it, reflecting on what sucks and changing it to make it better. I'm an Agile Hipster I suppose. <br> Baby steps. First I need to start logging what I got done. Like [how I learned Vim](http://www.kaoruk.com/posts/02-27-2015-err-day-i-be-vimming) I have to do it on a consistent basis. Let's start primal. I'll open up a Google drive spreadsheet and start logging what I have done today. That's it! I don't want to make any more assumptions beyond this. I haven't tried it and I honestly don't know how much it will suck until I do. Timeline: 2 weeks. If I can't deal I'll have to figure out why and adapt. <br> If you want to learn anything I believe having a goal is key. But if the "something" is huge breaking it down to smaller goals is key. Climbing a mountain is daunting. Climbing over this 3 foot rock, yeah I can do that. <br> Check out this list of resources if you want to learn more about **kanban** and the benefits of metrics in software engineering. 1. [Phoenix Project](http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509/ref=sr_1_1?ie=UTF8&qid=1426432331&sr=8-1&keywords=phoenix+project) 2. [Greg Wilson talk](https://vimeo.com/9270320) 3. [Ruby Rogues Podcast](http://devchat.tv/ruby-rogues/184-rr-what-we-actually-know-about-software-development-and-why-we-believe-it-s-true-with-greg-wilson-and-andreas-stefik) 4. [5 easy steps to Kanban by Sam McAfee](http://neo.com/2014/10/01/kanban-in-5-easy-steps) [1]: https://kaoru-portfolio-images.s3.amazonaws.com/image/8/2015-03-15-Mountains.jpeg [2]: https://unsplash.com/thehungryjpeg

kanban process goals self-imporvement

Learning how to Vim

![Sunset after surfing.][1] [by Joschko Hammermann][2] <br> Have you ever wondered how to deploy Rails without using Heroku? I have. I found this [awesome tutorial on how to deploy Rails on Ubuntu.][3] I was chugging along just fine until I had configure ngnix via Vim. Ack I don't know how to Vim! Whatever, off I go deleting the entire nginx.conf file and being stuck on it for a ridiculous amount of time all because I refused to learn how to use Vim. Ever find a rabbit hole that leads to another? Exactly. <br> Time I learn Vim head on! I set up a few rules to ~~force~~ encourage my learning. 1) Use it all the time. Unless there is an emergency, i.e. important bug fixes. Vim is the only way I code. 2) If I absolutely hated it after a week I quit. 3) Ask questions! Luckily sitting close to me is a Vimming co-worker! <br> What was really interesting is that not only was I thinking about how to write code, but I was also trying to remember how to type and navigate through Vim! The experience is close to solving a sudoku puzzle while learning how to use a pen. Frustrating non the less, but I kept saying to myself, only a week, only a week! When a week came around I feeling more curiosity than pain. <br> Some Pros about Vim and what I miss about Sublime: <br> **Pros** <ul> <li>I absolutely love that I do not have to take my hands of my keyboard! Ask anyone who uses a computer on a daily, hot keys are the way to go!</li> <li>I don't need a Mac to code now! I can literally ssh into Ubuntu or Linux and use VI and start editing files!</li> <li> I feel more like a hacker now, which is absolutely ridiculous </li> </ul> <br> **What I miss about Sublime** <ul> <li>Multi-cursor editing. There is a Vim plugin that tries to do this but it's meh.</li> <li>Better find all. Maybe this is because I have yet to find a good Vim plugin. I specifically miss how much context sublime offers when searching. I use the silver searcher to find text but it is so awkward going between a open file and the list of search hits.</li> <li>shift+tab: open a recently closed tab</li> <li>Configuration via JSON, but only because I don't know vim scripts yet</li> </ul> <br> I'm going to keep running with Vim for a while until I absolutely cannot stand it. I figure I'm probably not going to forget how to Sublime anytime soon. Vim is another tool I can add to my belt (an editor in non mac-os environment). It really forced me to practice my learning skills. Overall I think it was a good choice. I encourage you to try it out, if only for a week! <br> [1]: https://kaoru-portfolio-images.s3.amazonaws.com/image/7/photo-1414490929659-9a12b7e31907.jpeg [2]: https://unsplash.com/hmmrmnn [3]: https://gorails.com/deploy/ubuntu/14.04

vim learning

Breaking Out

![enter image description here][1] by Jeremi Cai, courtesy of [Unsplash][2] <br> Pyramids are a sum of bricks. Cars are a sum of parts. I like to think of code in the same way. I hear engineers make the best programmers. There is [a lot we can learn from other engineering disciplines][3]. One of those lessons is breaking problems into smaller pieces and in our case, bigger methods into smaller methods. Continuing from [my previous blog post][4], we were building a wrapper around a car API. We first make a request to the api, then translate the response from `JSON` to collect a list of car models. Our big method would look something like: ```ruby def fetch_car_models response = Typhoeus.get("api/url/car/models/#{@year}", {api_key: "c1740b8a598008ac10d2d528156bc4df38f40e947360aaf3"} ) api_info = MultiJson.load(response) api_info["models"].map do |car_info| { text: car_info["name"], id: car_info["name"], vehicle_year: @year, manufacture: car_info["manufacture"], model: model["name"] } end end ``` Everything works and it's fantastic! Ship it! Then your manager stops by and says hey, the api calls are costing us too much money, let's cache it. Can do! ```ruby def fetch_car_models redis = Redis.new(:url => "redis://:p4ssw0rd@") car_model_key = "car:models:#{@year}" model_list = redis.get(car_model_key) return model_list if model_list response = Typhoeus.get("api/url/car/models/#{@year}", {api_key: "c1740b8a598008ac10d2d528156bc4df38f40e947360aaf3"} ) api_info = MultiJson.load(response) model_list = api_info["models"].map do |car_info| { text: car_info["name"], id: car_info["name"], vehicle_year: @year, manufacture: car_info["manufacture"], model: model["name"] } end redis.set(car_model_key, model_list) model_list end ``` I'm pretty sure this method has bugs. Where you ask? I have no clue. I manually have to type everything in the console to figure out where to start. Gross right? Which is why I like having methods broken out into steps. ```ruby def fetch_car_models get_data_from_store || get_data_from_external_source end private def get_data_from_store redis.get(my_key) end def get_data_from_extenal_source raw_data = external_source.fetch_car_models_for(@year) model_list = translate(raw_data) cache_result(model_list) model_list end def translate(raw_data) raw_data["models"].map do |car_info| build_car_hash(car_info) end end def build_car_hash(car_info) { text: car_info["name"], id: car_info["name"], vehicle_year: @year, manufacture: car_info["manufacture"], model: model["name"] } end def external_source ExternalSource end def my_key "car:models:#{@year}" end def redis @redis = Redis.new(:url => "redis://:p4ssw0rd@") if @redis.nil? @redis end def cache_result(model_list) redis.set(my_key, model_list) end ``` *this isn't perfect but I'm hoping you get the idea* <br> Now that the steps are broken down to smaller methods it's easier for me to open up a console and run the steps individually. The private flag is a pain because I would have to type `send` before every method, so I typically comment it out until I'm done testing and debugging. Let's say Redis is returning something I'm not expecting, I can spin up a console and type: ```ruby list = CarModels.new("2014") list.get_data_from_store ``` verses ```ruby redis = Redis.new(:url => "redis://:p4ssw0rd@") car_model_key = "car:models:#{@year}" redis.get(car_model_key) ``` That's a win for me. The bigger picture is that it's easier for the next person to come in and add features or debug steps rather than a big o method. Of course as [I have recently learned][3], I have no data to back this claim, so my previous statement is just an assumption! <br> Relevant blog posts (specifically the modular section): https://medium.com/@karan/the-7-rules-for-writing-software-that-wont-die-when-you-do-38ef0a925650 [1]: https://kaoru-portfolio-images.s3.amazonaws.com/image/6/pebble-beach-stock.jpeg [2]: https://unsplash.com/ [3]: http://devchat.tv/ruby-rogues/184-rr-what-we-actually-know-about-software-development-and-why-we-believe-it-s-true-with-greg-wilson-and-andreas-stefik [4]: http://www.kaoruk.com/posts/when-to-use-private-1421723153

ruby tdd

a SOLID hurdle

![enter image description here][1] I first heard of the [SOLID priciples][2] from Gilbert, my MakerSquare teacher. A brilliant idea emerged of how to pull domain logic outside of dependencies ( i.e. Rails ). The idea is to treat Rails as a mechanism to delivery content. All domain logic can live outside of Rails as a PORO ( Plain Old Ruby Object). There is always one hurdle I keep bumping into. > How do you query the database without using Active Record? I've read several approaches on how to make an in memory repository ( a wrapper around a hash ). ```ruby class Domain::InMemory class << self def persist(data) @store[increment_id] = data end def increment_id @id += 1 end end end ``` Which works awesome if your app only consists of one model. More often than not domain logic will have multiple models working together to paint a bigger picture. To build in memory objects that mimic this behavior sounds awful close to rebuilding an ORM over ruby hashes. I honestly think that's overkill. The main benefits of the SOLID principles are to speed up tests and reduce coupling. Which I'm all in favor for. It's like asking who's a fan of being happier!? I have been bouncing around a couple ideas of how to separate the power of AR querying provides into a PORO. But they're really rough drafts. So instead I rather share with you what works. <br> At Spredfast we have a big o Rails app. Big o Rails means slow tests. I recently had to build an endpoint to validate some json and create models from it. The steps were 1) validate json 2 ) create models. Don't need Rails in one of the two steps. So what do I do? I make a class to validate what I am expecting in the json and throw errors if the json has missing properties. The class looks something like this: ```ruby class Validator def initialize(raw_json) @raw_json end def validate! convert_json_into_hash! ensure_valid_spec_fields! @spec end def convert_json_into_hash! @spec = MultiJson.parse(@raw_json) rescue MultiJson::ParseError => e raise_error("You have passed in invalid JSON: #{e.message}") end def ensure_valid_spec_fields! raise_error("Spec must have a templates property") unless @spec["templates"] end end ``` Yes I am forcing Ruby to behave like Java. There is one dependency in this class. `MultiJson` which is perfectly fine. In my test suite, I can require the gem by itself. I don't have to load up a Rails environment or any other gem we used in our monorail, believe me we have tons. This is how I use it in Rails: ```ruby class SomeController < ApplicationController def create spec = Validator.new(params[:spec]).validate! template = Template.create_from_spec(spec) render :json => { template: template }, :status => 200 rescue Validator::Error => e render :json => { error: e.message}, :status => 406 end end ``` I'm beginning to explore where this technique is applicable and where it isn't. Right now it is unclear to me how far one can go with this. Trust me that I'll keep pushing the boundaries to see where it will go. [1]: https://kaoru-portfolio-images.s3.amazonaws.com/image/5/photo-brandon-kendall-n-72.jpeg [2]: https://www.youtube.com/watch?v=WpkDN78P884

solid ruby rails fast tests

When to use Private

![Blurred out freeway][1] *Photo by: https://unsplash.com/kappuru* Private methods in ruby were explained to me as methods you don't need / want to test. This was super unclear to me. It became more clear as I started writing more tests. I shall dispense of my experience in the following...ready set go! Say we're working on a class retrieves car models from Edmund's API. Our class API would work something like: ```ruby CarModels.new({year: "2015", manufacture: "Subaru"}).get_list ``` There are a few steps we have to do to get this list. First we have to make a request with the proper params to a url, translate the response from a string to JSON, and then we have to iterate through the data to collect the models. The client ( person / object ) who is using this class **doesn't care** how the class gets the information. The only things the client cares about is the list. In fact I don't even care where the class gets the information I just want to see an array of models Subaru has available in 2015. >The client ( person / object ) who is using this class **doesn't care** how the class gets the information. Inside the CarModels class we'll have to define `#get_list` and have it do all the steps I previously babbled about. It might look something like: ```ruby def get_list get_raw_info_from_api translate_raw_response collect_car_models end ``` In TDD we would now write tests to make sure every one of these "step methods" work the way we want them to. `#get_raw_info_from_api` makes a request with the correct parameters and hits the correct endpoint and assigns `@response` to the response it received and yaddity ya ya. At the end of the cycle you will have a whole bunch of tests and a class you cannot refactor without breaking things. For example if I wanted to rename `#get_raw_info_from_api` to `#get_info_from_store` my test would break because my method got renamed. Or lets say the endpoint of the method changed, or we decided to check for a cached version first before making the api call. Or instead we use pixie dust. Or we face the fact that software always changes and we give up on TDD!!! > Don't give up on TDD!!! Instead delete all the tests for the step methods and leave the test for `#get_list`. Don't allow your tests to be so nosey that it prevents you from easily refactoring your class. This is where private comes in. The only method the client cares about is `#get_list` all other methods should be private because a client will never use `#collect_car_models` on it's own. The client would need to call `#translate_raw_response` which will then need to call etc etc. A client will never care about the steps you take to get the list. But WHY?!?! break up all those steps into private methods if they are never used by the client!?!?! Well guess you'll have to wait for the next post. =) [1]: https://kaoru-portfolio-images.s3.amazonaws.com/image/4/freeway.jpeg

ruby testing tdd