Kaoru Kohashigwa

Schedule is everything

I have been really religious about working out. So much so that I've lost weight yay! Now I gotta apply the same habits to writing a blog post every week. It has been a **month** since I decided to start writing again. Welp that didn't happen as planed and I think it's because I didn't plan it. I have to block an hour maybe even more to just sit down and write what I've learn. A brain dump for sure. If you want to start something you have to make time for it for sure. So here I go...again.

growth journey

Starting over...again!

I said to myself, let's redo my blog cause I can't read things because everything is too big and it's difficult to navigate and because I have nothing to work on and blah blah blah. So I started and then promptly stopped. I stopped because I got distracted with Starcraft 2 and the exciting release of the next expansion. I had to blow off some steam and now that that's done with I want to work on something that will improve myself as a coder. Blog came to mind because I absolutely suck at keeping track of my accomplishments and so I thought OH this is a perfect opportunity to keep track of my accomplishments and works done at Inside, but alas my blog looks ugly etc etc etc. Welp, I'm not about to recreate something I don't use. So instead of restarting another portfolio site, especially since I don't post things, I've decided to publish more blog posts rather than do a redesign because come on let's face it. A blog post's goal is simply to be a platform for content. If I haz no content I haz no blog. Simply put. So hopefully this will be the start of something different.

journey growth

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