After graduating from Flatiron School I’ve been going on job interviews and it seems everyone really wants to know how much I know about inheritance. So I told them “I used to work for a living and my grandmother left me nothing.”

After the uncomfortable crickets faded, I told them something like what’s below. I selfishly wrote down some thoughts to solidify my own review of the topic.

StackUp was built by myself and two others at the Flatiron School as part of the ‘project mode’ portion of the curriculum.

StackUp allows you register an email address, and receive daily emails with questions the StackUp team has decided are suitable for newer developers. The questions are selected based on data provided by the Stack Overflow API and attempt to guarantee the following:

• Each question must be appropriate to a new developer’s level of knowledge

• Each question must not have been answered at the time the daily email is sent

• While possible each user must receive a unique question from each other user so that users of StackUp don’t cannibalize their own opportunities to answer questions

• While possible each user must only receive questions they have not previously been sent

According to Pew Research the age group using the internet the least right now are people over age 65. This might be because they prefer to do other things in their spare time than be on the internet, or they prefer to contact their friends without Facebook or they prefer to buy things in a store rather than deal with on line issues etc.

One important thing I noted here is that people over 65 did not get broken out like the decades before them (20-30, 40-50) - everyone over 65 is generally considered to be uniform. This attitude may have been useful up until now, but very soon, the 88% of 50-64 year olds on the internet will move into the 65+ category.

Did earlier life preferences shape this 65+ group’s later life choices? Generally we believe the 65+ group to be less nimble when changing behaviors, so I think it’s likely that this age group set their preferences early on. From speaking to people in this age bracket in my family, I’m convinced that these preferences are set, may stay set for the rest of our lives. My evidence for that is slim, but I have had family members say something like this: “…eventually people get tired of keeping up with the latest thing. Eventually they just want to do it the way they are comfortable doing it.” Proof!

So should anyone care?

When I first started at the Flatiron School I got more than a few stares for using a PC. In fact for a place that otherwise espoused tolerance and a positive attitude, the feelings toward PCs were definitely more downward facing dog than rising eagle. To me this was a shock, the arguments against MACs were obvious - overly expensive, upgrades require a “genius”, used to not even run on x86 processors, have to pay for every single thing that is available as open source, and you can’t play (as many/recent) games!

After watching 40 students handle their Macs as development machines I will admit that there is a sexiness to newer Macbooks, and you definitely get what you pay for in terms of screen resolution, and who can argue that having the OS just work isn’t something that you would want? For simplicity, The Flatiron School insists that you use a Mac. I used a linux and Win 8 dual boot machine for most of my time there because they hadn’t outright said I couldn’t, and becuase I already owned one.

How did it go?

It was a major victory for proving it can be done. It was a minor hassle in terms of having to jump through a few more hoops on a curriculum designed for Macs. Some custom Flatiron gems needed tweaks to work, or Postgres had additional dependencies, or shortcuts in Sublime aren’t the same. All in all it wasn’t game breaking stuff, and I still prefer that I used a laptop I had ($500) over buying a new one ($2000) in an eco-system I had no intention of participating in. As we neared the end of the term I realized however that I was missing out on a third option : virtualization.

At the Flatiron School (FI) we’re required to present at least one technical talk. Not to be outdone by classmates most people go all out with the knowledge they have at the time. My partner and I decided to build a dashboard with the help of DashingIO (http://dashing.io/).

We wanted to build a dashboard that could be accessed by the students individually and on the big screens around the lab area. Dashing IO provided both of these features out of the box.

We wanted to show 1. what new blogs have been posted? 2. is there anything fun to do later? and 3. how am I doing on labs?

The following isn’t strictly programming related, but I learned some things that I make sure to remember while programming so I thought I would share it.

A few apartments ago my wife and I had our first son, Eli. Very quickly I got tired of washing a thousand baby bottles by hand every day and so I looked for and found a dishwasher on Craigslist. I had a very narrow kitchen without the possibility of installing a dishwasher so I needed a mobile one. In fact, the person I bought it from thought their dishwasher was broken, so they were giving it away. It had recently been serviced and the main motor had been replaced. The owners were frustrated that it still didn’t work and were unwilling to spend any more money on it. I was more willing to gamble my time back then, so I went ahead and got a free dishwasher.

The short answer is that it gets slow. I had heard this before but decided to confirm it with some code. I used SQLite for the database, ActiveRecord to ease the SQL work, and Ruby to automate table generation. Tables of sizes from 100 to 1000 columns and rows were created and populated, and then randomly queried 100 times per benchmark. The benchmarks were averaged and compiled to generate the summary chart. To keep things simple, I only tested a single column of 1000 records, or a single row with 1000 attributes (columns).

Ruby has an Enumerable method called inject and it makes summing or getting the product of an array of values a snap. Below are some extended examples of it in use:

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

#'injects' 0 in for sum before we start summing so 
#the result is 1+1+1
[1,1,1].inject(0) {|sum, value| sum+value}
#'injects' a value of 1 in for sum before we start summing so 
#the result is 1+1+1+1=4
[1,1,1].inject(1) {|sum, value| sum+value}
#nothing injected, so the first argument (sum) takes the 
#value of the first item in the array (1). The result here is 1+1+1=3. 
[1,1,1].inject() {|sum, value| sum+value}

#This will give you the product of the injected 0x1x1x1=0
[1,1,1].inject(0) {|product, value| product*value}
#This will give you the product of the injected 1x1x1x1=1
[1,1,1].inject(1) {|product, value| product*value}
#This will give you the product of the first value of the
#arrayx1x1=1
[1,1,1].inject() {|product, value| product*value}

So what does inject do?

1. The first argument of the block takes the value of the variable passed to inject (the injected variable) initially
2. After performing the block’s operation the result is stored in that same variable and at the end that final stored value is returned
3. If you don’t pass in a value to inject, the first argument of the block will initially take on the value of the first index in the array.

Read some more here: http://ruby-doc.org/core-2.1.3/Enumerable.html#method-i-inject

It can be made even shorter

1
2
3
4

#This is equivalent to [1,1,1].inject(0) {|sum, value| sum+value} 
[1,1,1].inject(0,:+)
OR
[1,1,1].inject(:+)

The first argument is the injection, the second is calling on the symbol for the operator +. Symbol references to methods are also acceptable arguments for inject.

Summary

Instead of

1
2

sum=0
array.each do {|value| sum+=value}

You can do this:

1

array.inject(:+)

#inject and #reduce are the same method. I imagine reduce refering the to the collapsing of the array via the given block into one value