The Eternal Whitebelt

This is an annoying error, which I experienced while trying to set up a project in the beta Rails 5 (api mode). If you experience it, try seeing what bundler version you have:

1
2

$ bundle --version
#=> outputs something like 1.7.7

It could be that you need to update your version.

1

gem update bundler

That fixed it for me.

Introduction

So on a semantic level, everyone knows what the internet is, and it’s definitely a thing that has dramatically changed the world. The speed of information transfer is doing incredible things, both by making it faster and cheaper to get information, which has democratizing effects, and also by enabling people to stay in touch, it’s incredible really. And in the following series of blog posts, I am going to try and cover the main big ideas about what makes the internet what it is, and how it works.

First, a little history

So it doesn’t seem like Al Gore actually invented the internet. It seems to have started as early as the 1950’s, when the idea of networking and packet switching, which is the method by which computers send chunks of data to each other and can talk to many of each other at the same time, was the method these networks were using. Development continued for several decades, and in 1981, the National Science Foundation funded the Computer Science Network, and the Internet protocol suite (TCP/IP) became the standard networking protocol. In the late 1980’s, commercial internet service providers started coming onto the scene. TCP/IP, which is also known as the Internet Protocol suite, became the standard method of exchanging information on the internet in March 1982, when the Department of Defense declared it so, and became open source in 1989. Officially commercial entities started using the internet around 1990, and by 1995 the world wide web was pretty much in full force. So this stuff has actually been around for a long time, but it’s really exploded in the last 20 years or so.

And now, TCP/IP!!

So what the hell is TCP/IP? TCP stands for Transmission Control Protocol, and IP stands for Internet Protocol. It is the basic communication language for the world wide web, as well as private networks (both extranet and intranet networks). Obviously, there are 2 main parts – 1. TCP and 2. the IP.

1. TCP (Transmission Control Protocol) – This is the higher layer. TCP manages the chunking of data of whatever is trying to be sent, breaking the file or files into small packets of data, and then reassembling the chunks once they’ve been transmitted.
2. IP (Internet Protocol) – This is the lower layer. The IP handles the addresses for each packet, and makes sure that they get to the right place.

One term that is often mentioned in the same sentence is the concept of being “stateless.” Broadly, this just means that the network doesn’t remember anything about the last time it sent packets; it’s like it has complete and utter lack of memory. There are no connections between packets; just discrete and separate requests. This really frees things up, so that multiple computers can use servers at once and no one has a lock or can delay these transactions.

Ok, seems good so far. Now let’s get into the guts of the thing.

The easiest way to understand the structure of the protocol is by looking at its anatomy. There are 4 different layers of abstraction, starting with closer to the user, and then getting more nitty gritty into the actual transmission. Abstraction is great because it frees things up for the top user; they don’t need to focus on the implementation of the very lowest level stuff. Similarly, the lowest level doesn’t need to care about what it’s being sent, it just kinda blindly stupidly does what it’s supposed to do. It’s beautiful. The 4 layers are: 1) The Application Layer – where you create actual data and communicate it to people on different or the same host. 2) Transport Layer – the channel that you communicate on, and handling flow-control, connection establishment, and reliable transmission of data. 3) Internet Layer – defines the addressing and routing structures used, Its function in routing is to transport datagrams to the next IP router that has the connectivity to a network closer to the final data destination 4) Link Layer – defines the networking methods within the scope of the local network link on which hosts communicate without intervening routers.

Let’s take a look at each in turn, starting low level.

The Link Layer

The Link Layer (also known as the Data-Link layer) deals with local networks. ensures that an initial connection has been set up, divides output data into data frames, and handles the acknowledgements from a receiver that the data arrived successfully. It also ensures that incoming data has been received successfully by analyzing bit patterns at special places in the frames.

Internet Layer

The Internet layer handles routing between networks. It’s responsible for transferring data between the source and destination computers. The Internet layer accepts data from the Transport layer and passes the data to the Network Interface layer. One function is routing the data to the correct destination. This layer takes care of sending the data through the shortest route if more than one route is available. In addition, if a route through which a datagram is to be sent has problems, the datagram is sent through an alternate route.

Transport Layer

The transport layer, in contrast, is sufficiently conceptual that it no longer concerns itself with these “nuts and bolts” matters. It relies on the lower layers to handle the process of moving data between devices.The transport layer is charged with providing a means by which these applications can all send and receive data using the same lower-layer protocol implementation. Thus, the transport layer is sometimes said to be responsible for end-to-end or host-to-host transport.

The Application Layer

At the very top of the OSI Reference Model stack of layers, we find layer 7, the application layer. Continuing the trend that we saw in layers 5 and 6, this one too is named very appropriately: the application layer is the one that is used by network applications. These programs are what actually implement the functions performed by users to accomplish various tasks over the network. Most people, when connected to the internet, are using higher level protocols, like the HTTP protocol, but it’s all built on and based off of TCP/IP and this is the layer HTTP is in.

Conclusion

Well there you have it, that’s part one. It’s a fascinating and important thing for networking, and while we sit much higher in abstraction now, we all still depend on it. There are trillions of data packets exchanged daily, and it’s all built on this model. Next time, I’ll delve a little more into both TCP and IP individually.

Ruby Bits 1 was the first of the CodeSchool challenges that I tackled. This course is geared to take someone with decent experience in Ruby teach them how to do certain things “the Ruby way.”

Part 1: Expressions This part went over the best practices for writing expressions in Ruby. It was mostly review, but there were a few bits of syntactic sugar that were good to review. It was interesting that at Flatiron School people were encouraged to use if !_condition_ instead of the more Rubyist unless.

Of the patterns described, Memoization was probably the most useful. As a reminder, this refers to assignment of a variable if assignment has not already taken place.

1
2
3
4

x ||= 1
x ||= 2
x
#=> 1 

Part 2: Methods and Classes This section covered optional arguments, raising exceptions, using begin/rescue/end, and attr_accessor vs. attr_writer vs. attr_reader. It was definitely good to review. Ben Orenstein had a fantastic talk about refactoring at the Aloha Ruby Conf 2012, which you can see here. In this talk, he describes how IN GENERAL, methods that require no parameters are probably a little better than methods that take one argument, and that methods that take 1 argument are probably a little better than methods that take 2 arguments, etc. Keeping the number of argument keeps ‘coupling’ lower, something we definitely want, as it often leads to higher cohesion (for more information on coupling in computer science, check out the Wikipedia page.

So how do we combat coupling? Let’s say that you had an imaginary application where you had a band called the Ruby Rockers. And maybe there was a method called schedule_concert that took a few arguments, including the venue, show fee, time, and maybe longitude and latitude, which don’t seem as mission critical.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#Meh:
def schedule_concert(venue, fee, time, longitude, latitude)
  #...
end
#to call the method, you need to have the order memorized among other things and it's definitely annoying. Let's say you didn't remember the longitude and latitude and didn't really care about it either:
play_concert('The Fillmore', 1.00, 2100, nil, nil)
#=> Ok, your concert is scheduled.

#Better kinda:
def schedule_concert(venue, fee, time, longitude = nil, latitude = nil)
  #...
end
play_concert('The Fillmore', 1.00, 2100)
#=> Ok, your concert is scheduled, and in a slightly less coupled way!

#Solid
def schedule_concert(venue, fee, time, options = {})
  #...
end
play_concert('The Fillmore', 1.00, 2100)
#=> Sweet
play_concert('The Fillmore', 1.00, 2100, latitude: 28.55, longitude: -81.33)
#=> Cool

Part 3: Classes This was almost all review, but it did touch on something that is important – not being shy about private methods. It discusses the pros and cons of inheritance, the fact that Ruby has single inheritance, and how it’s useful to make many smaller classes – for more information on classes check out Practical Object-Oriented Design in Ruby.

Part 4: Active Support I hadn’t really used ActiveSupport before this Code School class, and I’m kind of glad I didn’t because it taught me the harder ways to do things. However, there are some really awesome extensions here that I didn’t know about and that could probably make developing with Ruby [even] more of a joy! The RailsGuides do an incredible job with this.

Part 5: Modules This is a very useful section and I would definitely recommend it highly to others. I didn’t even know about the ancestors method, which for everyone who doesn’t already know, is a method for any object that will return the object ancestor chain in an array. If anything it’s a useful inspection device. Another useful one is the included_modules method, which returns the modules that are being included in your class. Both included_modules and ancestors can be useful.

In general, it seems that modules are a better way of extending functionality into other classes unless there is a compelling logical case for inheritance; inheritance implies specialization, and because a class can only have one superclass, it must be pretty perfect to justify doing. One of the coolest patterns that I came across was the self.included(base) hook. To see it in action, take a look here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#module Badassify
module Badassify
  def self.included(base)
    base.extend(ClassMethods)
    base.make_everyone_more_badass #wow, we can hook into the moment of extension and then do stuff
  end
  module ClassMethods
    def make_everyone_more_badass
      #...
    end
  end
end

#class AverageJoe
class AverageJoe
  include Badassify
  #extend Badassify::ClassMethods (this no longer necessary!)
end

And you can do even cooler and prettier stuff with the ActiveSupport::Concern element of ActiveSupport, which can be found again at this url.

Part 6: Blocks This is actually very useful knowledge. It goes over everything from the way our favorite iterators work in Ruby (such as ‘each’, ‘map’, etc. that all take blocks), to the proper way to yield to a block. Also it describes how you can also yield objects to blocks just like regular arguments. This can allow for some pretty good refactorings, leading to DRYer code. Additionally, it talks about the Enumerator module (not to be confused with the Enumerable type), which allows access to many things (including those high level iterators!). Here’s an example of a nice refactoring with a block:

Let’s say you have two methods, both which require you to do a lot of the same logic around signing in, logging errors, and signing out, like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def update_status(user, status)
  begin
    sign_in(user)
    post(status)
  rescue ConnectionError => e
    logger.error(e)
  ensure
    sign_out(user)
  end
end

def upload_photo(user, photo)
  begin
    sign_in(user)
    upload(photo)
  rescue ConnectionError => e
    logger.error(e)
  ensure
    sign_out(user)
  end
end

Given these two methods, it’s easy to see that there is a lot of duplication. Why don’t we just refactor so that we don’t have to duplicate ANY OF IT!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

def sign_in_action_for(user)
  sign_in(user)
  yield
  rescue ConnectionError => e
    logger.error(e)
  ensure
    sign_out(user)
end

#Now, we can call the single method with blocks instead.
sign_in_action_for("Will") do
  post(status)
end
#of course we could do both within one block, but this allows for one at a time as well.
sign_in_action_for("Will") do
  upload(photo)
end

Cool beans. Well the first part of Ruby Bits was quite interesting and I’m getting really hungry, so we’ll see ‘bout the advanced sequel, Ruby Bits 2.

The title says it all. I’m going to try and get through all of the Ruby, Rails, and Javascript code school tutorials in the next month. Why? Because it was “free” along with the Flatiron School tuition (definitely not free either) and I might as well get the most of it before it’s taken away.

Let’s see how it goes – I think it can be done.

Javascript is often made fun of for its idiosynchrasies (if you haven’t seen Gary Bernhardt’s “Wat” talk, stop right now and watch it: http://vimeo.com/94881698). Today I want to focus on one issue that can cause problems in Javascript – hoisting.

Recently, I’ve been learning a lot more about Python. I’m a Rubyist by background but I’m interested in learning Python because of all it’s amazing libraries, especially those related to data science. This post is about a few differences that are useful to think about coming from a Ruby background. This is also largely a reaction to material I’ve gathered from the web, including this thread on Stack Overflow.

Method Access Rules

While the end user of your program is never going to be using the methods you define in a class directly, it is still helpful to control access to your methods. Envision a team situation in which multiple developers use instances of the same class; it is useful to control which methods can be used.

A simple way to think about the difference is to imagine our class is an airplane (I’m writing this aboard one, in fact.)

This post is centered around linked lists using Ruby.

A linked list is a data structure that consists of a collection of nodes that represent a sequence. Each element in a linked list will contain a datum and a reference to the next element in the linked list (a pointer).

In Ruby it makes most sense to use arrays due to built-in methods such as shift, unshift, enq, deq, push and pop, but it is helpful to know why linked lists can be beneficial.

Anyone with a background in Ruby has seen a hash before. And anyone with a background in Javascript has seen a Javascript Object before. I encountered an interesting problem on CodeWars.com and wanted to share. The problem deals with accessing data in Ruby hashes the way you can in Javascript objects – by using the dot notation.

The process of logging in with Oauth may seem complex the first time you do it, but it becomes easier the second time around. This article assumes some familiarity with Ruby and the structure of a Rails application (but not too much :)