Basic Commands

The ls command list the contents of the current directory. A more detailed form would be ls -la which lists the contents along with their file permissions.

The cd command lets you move back and forth from folders by adding the folder name afterwards. cd .. lets you move back by one folder and cd - lets you jump back and forth between the last changed spots.

The mkdir command makes a folder while rmdir removes an empty folder.

cp can copy files where the the first group is the target and the second group is the destination.

mv moves files and works similarly to cp except the first group is deleted afterwards.

The rm command deletes a file and passing in additional flags like rm -rf would delete a whole folder along with its contents.

Useful Commands

man followed by another command would show the complete help section on how to use that command. Whenever I’m lost or forgot how to use a particular command, I would use this to figure out how it works.

sudo can be prepended to other commands that need super user permission to execute.

chmod can change the file permissions of a file enabling you to edit or use thE FIle.

grep lets you search through the file’s or output’s contents using a regular expression. There are other commands that other people use to perform the same function but this is the most common one.

head and tail - Shows the first of last ten lines for a file or output. They’re useful for logs and when piping a string of commands.

rails has their own set of commands along with rake commands for migrations. I end up using rails console the most when debugging a problem or exploring an application.

Optional Commands

vagrant up and vagrant ssh - I had a lot of trouble with setting up a development environment since I had a Windows 8 laptop. I learned that Vagrant was the easiest way to start using a virtual machine at the time and I started with the rails dev box.

rvm was how I managed my environments and it helped me separate incompatible gems. A Gemfile should manage most of these but I had trouble figuring out where errors were coming from when installing gems and this was an easier solution at the time.

vim - I started with vim because I couldn’t figure out how to share folders between the virtual machine and the local machine but I ended up enjoying being able to quickly switch between the editor and shell so much that I stuck with it.

tmux - I began learning this on an Upcase trail and using it finally convinced me to install a Linux distribution. It became more evident that developing in a virtual machine was the bottleneck for me when I became comfortable enough in a tmux session, especially when running tests.

When I was getting deeper into reading The Rspec Book a few weeks ago, I found that I had difficulties when it came to information that wasn’t included in the rails guides. I picked up The Rails 4 Way to rectify that. The book felt more like documentation while I was reading it and that’s very intentional. The breadth and depth was impressive and I wanted to get a book that I could carry with me as a physical documentation of the framework. I knew before reading it that I couldn’t memorize everything the book had to offer so I read it like I would when I read Google Map directions, finding the general routes I needed and making a mental note for things that I didn’t need to know now but would definitely look into once I reached that landmark.

The first chapter dealt with a rails environment and configuration. Most of it dealt with things I learned from other sources but I was introduced into the specifics of bundler and other configuration details. This is the section I learned to add gems into the vendor directory which I wanted to do because I recently learned about ctags from Upcase’s vim trail. This enabled me to jump around my app figuring out how methods are called throughout the application. The next three chapters after that were also refreshers on routes, REST in Rails, and controllers.

There were five full chapters that dealt with active record split into general active record uses, migrations, associations, validations and advance active record uses. Active record deals with so many parts of Rails that I remember looking at the source code before and not getting where to begin. The book delved into the database adapters for the most common relational databases and how Rails interprets the types of data they use. During the rest of the chapters, what stood out to me the most where how callback were used in the model, how associations are made particularly polymorphic associations, and using indexes.

The tenth chapter dealt with the action view part of Rails and introduced the decent exposure gem. Most of it was a refresher dealing with methods available in the view diretory, using partials, and rendering objects or collections. The most useful part I learned was the assigns instance variable which shows what is being communicated between the controller and view.

I’ve been working through the testing trails in upcase for test doubles and testing fundamentals. The most difficult part for me was understanding mocks and spies along with how to structure them to make sure the right behavior is being tested. I’ve written unit tests and a few acceptance tests in the past but I’ve never used test doubles before the upcase trail. I had to research the differences between fakes, dummies, stubs, spies and mocks. Upcase provided an aricle by Martin Fowler as an introduction to those ideas. From my understanding, the advantages of using test doubles are clarity and speed. The unit tests should already tests that the proper answers are being given in the model or controller level which makes stubs a good way to improve them. Mocks ensure that specific method calls are being used and spies take that a step further by recording how the method calls are used. For example, spies could say that a method call was used twice instead of the expected once.

I’ve learned the definitions for different kinds of testing; unit, integration, feature, and functional tests. Unit tests are for a small subset of the application and I closely associate it with tests for a specific controller or model. Integration tests go from end to end and I’ve used it to test that logging in to an application or using the user interface. Functional tests are integration tests that actually run the application from end to end similar to making sure that an email is sent when a person is trying to recover a forgotten password. Feature tests are for things that change the functionality of the application like changing a status update from text only to including image attachments.

I’m also still getting used to rspec and capybara. The most prevalent comments I would receive from the exercises were the different shortcuts people use in their tests and other improvements on readability to make sure that the reader can better understand the intent behind the tests. Most of my tests in the past was using Minitest because it was included by default and it was the framework most of the tutorials I followed use; it’s the testing framework included with the exercism exercises and the Treehouse tutorials for the Treebook application. I’ve never really thought of tests outside unit testing but I’m appreciating what testing adds to the application. I’m starting to see why tests can function as documentation instead of comments and how bugs can be recreated to better understand where edge cases are coming from.

I spent most of January working on exercism challenges and refamiliarizing myself with Rails. I haven’t been able to pair program with other people yet and online exercises have been the only way I’ve gotten feedback for the programs I’ve written. It’s been a good way to learn more about design patterns and subtleties in the Ruby language. Out of all the exercises there, I enjoyed the one about Binary Search Trees the most. Another user on the site turned me towards using the Null Object Pattern and my research into the topic led me to an article that illustrated how it could be used in Ruby. In the end, I ended up with code that looked like this:

class Bst
  attr_accessor :left, :right, :data

  def initialize(data)
    @data = data
    @left = NullObject.new
    @right = NullObject.new
  end

  def insert(number)
    if number > @data
      in_right(number)
    elsif number <= @data
      in_left(number)
    end
  end

  def each(&block)
    left.each(&block)
    block.call(data)
    right.each(&block)
  end

  private

  def in_right(number)
    right.insert(number) or @right = Bst.new(number)
  end

  def in_left(number)
    left.insert(number) or @left = Bst.new(number)
  end
end
class NullObject
  def data
    nil
  end

  def insert(*)
    false
  end

  def each(*)
    self
  end
end

The exercism website also had challenges that involved other data structures like linked lists and matrices. I’ve been reading more and more about how to become job ready as a programmer and there have been a lot of advice on being familiar with common data structures and how to implement them as well as recognizing the Big-O complexities of different algorithms. I’ve mostly been teaching myself and I know that I need to spend time on subjects that other programmers would have been exposed to in school. I want to do my best to expose my ignorance now.

I’ve also started a membership at upcase so that I could become more familiar with the tools that Ruby on Rails developers use. I’ve learned more about how to use vim and testing use rspec/capybara. I’m amazed by how efficient I could be using while vim and how easy it could be to learn when I’m pointed in the right direction. I’ve neglected how to write my own tests in the past and I’m trying to remedy that by learning how to use the tools other developers employ. Currently, I’m also trying to learn how to use tmux in one of upcase’s new trails.

When I started learning more and more about Rails, I became very aware that my programming skills in Ruby was lacking. I would read the code examples and I would find many methods and concepts that I repeatedly had to look up online in order to understand. I started to panic a little bit then because I was afraid that what I was doing wasn’t working and that I wasn’t internalizing what I was learning. A lot of times I feel like I’m fumbling around trying to find a way to reach out and find something to hold on to and effectively learn. The main way I’ve been doing this is through code challenges and tutorials but I’ve been finding that there is a huge gap between the code that I was writing and the code that I would read on open source projects.

Because of that gap, I’ve been reading as many Ruby Books as I can. This past month, I’ve gone through Learn to Program, Well-Grounded Rubyist, Metaprogramming Ruby 2: Program Like the Ruby Pros and I’m also halfway through Eloquent Ruby. These four books had a lot of intersections and they were a great starting point for the techniques that I was coming across while trying to read open source code. Along with those books, I’ve also read Secrets of the Javascript Ninja so that I could learn more about the Web API/DOM and how Javascript fits into that picture. A lot of the tutorials I’ve been finding uses Javascript extensively and my lack of understanding in that subject was becoming a bigger problem.

Because of these issues, I decided that December was the month that I would hunker down and challenge these glaring holes in my understanding. I dove deeper into Ruby and Javascript than I have before and ensured that I knew as much as I could before I buried myself even more into the various frameworks I was running across. Most of this renewed enthusiasm towards the language instead of the framework was because I was hearing over and over again about people learning frameworks without knowing what problems those frameworks were trying to solve.

In my head, I have a clearer picture of Ruby’s object model and order for it’s method lookup. I have a clearer idea of how an object inherits it’s methods and how monkeypatching works. I’ve learned more about the techniques Rubyist use in their code including method_missing and the eval family to create scopes or get around them. I’ve gone through them too quickly to fully understand their importance but I’m going to use what I’ve learned to understand the open source projects that I’m using.

There are a lot of resources I need to go through and many things I need to learn. I’m aiming to go through a big chunk of them this month and start better habits before the new year.

Continuous Todo List

• Code everyday inspired by Jennifer Dewalt.
• Better git commit messages
• Contribute to open source tools that I’ve been using, possibly using 24pullrequests.

General Todo List

• Learn more about Rspec and fixtures/factories.
• Learn about functional programming through JavaScript and see how it can be applied with Ruby’s procs and lambdas.
• Learn how to use Linux commands like tar and grep effectively.

Books to read

• Pragmatic Programmer
• Mythical Man Month
• Learn to Program
• Secrets of the Javascript Ninja
• Well Grounded Rubyist
• Metaprogramming Ruby: Program Like the Ruby Pros
• Practical Object-Oriented Design in Ruby: An Agile Primer
• Ruby Science
• The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends

Even more questions

• What is NGINX?
• What is Mongrel’s parser?
• What is Event Machine network I/O library and how does it work?
• How does Rack middleware and Rack in general work with Ruby web applications?
• What is the difference between multi-threaded servers and multi-process servers?
• What is the difference between eager loading and lazy loading?
• How could I use capistrano, chef or puppet ?
• What is the difference between authentication and authorization in a Rails app?
• What is and how does garbage collection work in Ruby?
• How does the Rails asset pipeline differ from other pipelines in frameworks like Middleman ?