Imma publish my SRC 2014 notes here

00_planned_schedule.md

Scottish Ruby Conference 2014 Notes

Sessions I'm planning to attend

Monday

• 9:00 Keynote by Evan Phoenix [notes]
• 10:15 I have no idea what I'm doing, Tom Stuart. Melville. [notes]
• 11:15 Not Invented There... Caleb Thompson. Ferntower. [notes]
• 13:15 Getting started with Open Source Contributions, Matt Wynne and André Arko. Drummond [notes]
• 15:30 Web Applications from Scratch, Tom Stuart. Drummond [notes]
• 17:30 Keynote by Breanna Wu. [notes]

Tuesday

• 10:00 Extreme Isolation: free your app to grow. Chris Parsons. Drummond. [notes]
• 13:00 Lightning talks! [notes]
• 14:15 Can't decide!
• 15:30 Writing a game in Ruby, Mike Moore [notes]

Other Sessions

What with three tracks, there isn't time to go to all the talks. Here are some notes on talks I've found that match the descriptions of talks on confreaks. They might not actually be the same, or they might be out of date.

Monday

• Thread Safety First, Emily Stolfo. video notes
• Office Politics for the Thin-Skinned. Justin Searls. video [notes]
• Introduction to CRuby source code, Andy Pliska. notes video, la ruby conf video, mwrc

Tuesday

• Jim Weirich passed away in February. Jim's talks never failed to be both fascinating and inspiring. They are all well worth watching. confreaks vimeo search
• The Dark Side of Ruby, Gautam Rege. notes video

ep_keynote.md

Monday Keynote: Reading Code

by Evan Phoenix

This is a talk about reading code. The goal of the talk is to convince us that we're not professional typists, but problem solvers. Ending up writing 1 line of code in a day does not mean you've been unproductive.

As developers, what we do a lot more is:

• understand problems
• do research
• and read code

Evan strives to write the uncleverest code possible, so that future developers have an easy a time as possible to understand what the code does.

Evan has some guidelines to help achieve this:

• Minimal metaprogramming, it can obfuscate code and quickly become impenetrable.
• Favour repetition over abstraction - you pay a lot for the wrong abstraction (see Sandi Metz)
• Premature or overcomplicated abstractions include deep or unnecessary inheritance.
• Abstractions should come when you can feel that the abstraction is necessary and maybe you have a set of common classes that you can see would benefit from an abstraction.

Other reasons to read code:

• learn skills
• code is source of documentation

Evan has a bunch of recommended reading, including Beautiful Code and Beautiful Architecture.

Example

Rail 1.2.4 has 73,623 lines of code. 4.1 has 169,844! We can use 1.2.4 as an example.

Other recommended types of code : hard things, 'read outside you level'

How should you go about reading it.

Do you have a goal in mind? Use that as a starting point. Otherwise, sort by interest: Let the developers guide you - do a ''' git log -p ''' To get an idea of what the developers are focused on.

Read old bug fixes. Look for an 'in' something to focus on

So, Evan walks through an investigation of 1.2.4. He knows it used fastcgi and WEBrick. He does git log -s WEBrick and finds an interesting commit, and digs up some interesting info on the earliest versions of rails.

Another investigation technique is the 'skim map' Its a bit like trying to see the whole code at once, focusing on the structure, not the details. Get an idea for the shape of the code, the high level 'feel' for the code. look for the modules, constants, method names, etc.

With code you;ve never seen before, reading it line by line is usually slow, and difficult to do without first getting some context, and a general feeling for the code structure.

Summary

Reading code is important for lots of reasons!

We covered what to read and how to read it§!

Evan then does a live demo of 'how does the rails asset pipeline work?'

My thoughts

I'm very please to here a keynote that talks about how important code readability is. Neat 'tricks' can be cool and educational, but also obfuscate design and intent. Design patterns, idiomatic ruby (read Russ Olson's book!) and making use of common libraries can make a massive difference.

When talking about skimming the code, there wasn't much mention of reading the tests, which is what I like to do. Someone asked a question that addressed that, but Evan finds them misleading, full of mocks, and not useful for a first pass.

Another method raised by a audience member is to look at the collaborators of the class you are looking at.

intro_to_cruby.md

Introduction to CRuby source code

by Andy Pliszka (Mountain West Ruby Conf)

Introduction

Andy says his motivation for looking at the C source code is to understand ruby better. It will help you understand garbage collection, write faster code and help you write C ruby extensions.

You can check out the C ruby source code from github. There are several steps to configure it correctly. It's pretty straightforward. You can then compile, build, and run the unit tests.

Once its made, you can install it to a local directory, and set up your $PATH to use it, and maybe set it up in RubyMine, etc.

Another important thing to check is your gem environment. Check 'gem env'

Andy installs rails to check that the ruby installation is kosher.

The debugger

There are a couple of debuggers available. Andy goes into lldb.

The source code

Andy shows a couple of C implementations of familiar ruby code.

Each C file that implements a ruby class has an init function. This is called when the class is loaded.

The C code is fairly straightforward to follow, especially if you know ruby. A couple of differences: Instantiations in C take two method calls - one to allocation memory.

Andy talks about method and class definitions in a bit more detail.

Andy points out that C needs memory management, whereas ruby is working with heaps, etc. You need to consider this, and things like type conversions between ruby primatives and C's.

Hacking CRuby

Andy describes hacking a fibonacci method onto CRuby's Fixnum object. The C version runs 30 times faster! You can do this all over the place, and investigate the ruby language, and add or speed up ruby implementations. A few more detailed examples are described.

There were a bunch of other slides that Andy skipped. Looks this there are more details in the slides, available online.

My thoughts

An interesting point is the idea of adding your own extensions to ruby, or changing implementations. That seems a great way of adding features or speed, and not something I've ever considered before. Andy points out that its not a great idea to do this in production, buts its a good way of exploring changes for extracting something into a gem.

I'm impressed by people that delve this deep into the language, and this seems a great way to get a richer understanding of ruby. Andy make it seem easy to play around with CRuby, and you could probably have a good play around with it, after having seen this talk.

Related things to investigate:

• Rubinius.

no_idea.md

I have No Idea What I'm Doing

by Tom Stuart

Tom Stuart has no idea what he's doing. I already feel like we are kindred spirits.

Some examples:

• Writing this talk. haha
• Writing a book. (involved a lot of hoovering and washing up)
• Writing a scheme interpreter (in ruby)

The Impostor Syndrome

Tom talks about the impostor syndrome.

The impostor syndrome, sometimes called impostor phenomenon or fraud syndrome, is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be.

Some interesting references:

• Invisible Monsters in Tech
• Time Chevalier's blog post and ruby rogues talk.

The Dunning Kruger Effect. (A) Incompetent people tend to overestimate their competence; (B) competent people underestimate thier competence.

Tom describes an experiment that demonstrates this behaviour. Furthermore, when given other people's papers to mark, competent people - once they'd seen how others had done - changed their opinion.

Interestingly, this suggests that (A) stems from mistakes about self's abilities; (B) stems from mistakes about everyone else's abilities.

Tom have other examples of people and things that don't know what they are doing:

• Douglas Adams - making up the Hitchhiker's script as he went along.
• Animals - with incredible camouflage, or particular adaptations that give them benefits, without any 'knowledge' of this. Not just physical attributes, though - beavers have dam-building instincts that provide an ecosystem and beaver habitat. Beaver are idiots. They don't know anything about hydrodynamics, they just do.

What to do? Shoshin - a Zen Bhuddist concept: think about a problem as though an absolute novice. Don't pre-judge too much, it can work against you.

Judo - if you have a problem, use the problem to solve itself. In judo, use your opponents advantages (size, weight) against themselves. Douglas Adams used this to solve a cliffhanger.

Rolling up - the Katamari Damacy example - build on previous steps, and grow. Also, an analogy with evolutionary theories. So, for animals with camouflage, it's the brains of their preditors that have encoded information about their environment into their genes.

Material Exploration Exploring wood grain helps make better things out of wood; exploring radio wave patterns helps build better RFID systems like oyster cards. Similarly, exploration is an important aspect of thinking about code designs.

Tom points out that TDD can give many of these things. Its all about working iteratively, rolling up and incremental improvements. It also allows you to separate the thinking about the requirements and solutions as difference contexts (writing the tests, then writing the code)

Incidentally, this is why there is such risk with re-writes, there is a lot of inherent, hidden knowledge rolled up in old code that might not be apparent.

Another thing that helps is 'play' and experimentation.

Take away thoughts

Nobody knows what they are doing. Embrace it, its an opportunity. Ignorance fuels creativity (c.f. that excellent 'Future of Pragramming' talk by Bret Victor) Exploration, play and lack of preconceived ideas leads to innovation Complex systems are built iteratively and incrementally - software, stick insects, radio shows.

not_invented.md

Not Invented Here

by Caleb Thompson

A talk about things that rails didn't innovate. Caleb says "You can be more effective by not innovating" and will now explain why...

A brief history of wheels: Wheels were invented in 5000BC, but initially, their use was limited. Wheels needed flat enough roads before widespread use, and road, track and vehicle technolgies co-evolved.

But during this process of innovation, they where re-inventing the wheel, they were building on existing technologies.

So, here are some things that rails has made good use of, but didn't invent:

• MVC, defined in 1978.
• Active Record, Martin Fowler, date??
• REST (to replace SOAP and rpc). 2002.
• Rails didn't invent REST, but help made it very popular.
• Convention over configuration. - prior examples include javabeans, spring, maven, many other places.
• ERB.
• Merb brought in strong parameters, asset pipeline and ORM/javascript agnosticism

So, what made Rails popular? The combination of all these things together to make it easy for rapid protoyping.

What can we learn?

• Build on the shoulders of giants
• Keep things simple
• Use defaults and familiar conventions

Buy for parity, build for competitive advantage. Concentrate your efforts on building new & differentiating features.

My thoughts

I think as developers, we are often tempted to shave yaks, because the process of developing the solution is one of investigation and understanding the problem. But its a great point that the most value is in using proven technologies that fit your domain and then innovating around the edges, and product differentiation.

Lori Olson tomorrow that might touch on a related topic. I'd be interest to find out her position.

ruby_dark_side.md

The Dark Side of Ruby

by Gautum Rege, Garden City RubyConf, 2014

Introduction

This is a talk about ruby's weirdness and gotchas.

There are a bunch of them, and I can't type that quickly. The examples highlight some unknown or interesting features about some ruby syntax and design.

Here are a couple of examples:

1/0               # raises a ZeroDivisionError
1.0/0             # returns Float::Infinity

12345.to(8)       # returns an octal "30071"
12345.to_s(36)    # returns a base 36 "9ix"
12345.to_s(64)    # returns an ArgumentError because there aren't enough
                  # alphanumerics to encode it.

• Splat expansion has several quirks.
• Arrays, and different operations on arrays.
• Case equality operator and basically all the different equality operators.
• "Proc#curry - woah!" is all I had time to type during the talk.
• A discussion about private and protected, and its different implementation in ruby.
• Ruby 'keywords'
• Cool tricks with cherry picking from Modules

So, if you read the Proc#curry rubydocs, you get a pretty dry description of the method, buts it's not obvious what you can really do with it.

Proc#curry(n) actually does currying or partial function application, so will return call the original proc if it has the right number of arguments, otherwise, it will return a proc that takes n arguments, binds them, and calls a second curried proc, and so on

I'm not sure I've explained that at all well, but here: ''' proc {|x, y, z| x + y + z }.curry '''' is a shortcut to ''' proc {|x| proc {|y| proc {|z| x + y + z } } } '''

Now, you can do all sorts of Haskell-type stuff with this!

My thoughts

An interesting look at quirks.

Some of the examples of neat things you could do look like things I'd recommend never actually using because its just not going to make your code clear - but they're pretty neat! e.g. [1,2,3] * "%"

Its interesting to see the 'edges' of ruby. The more you understand and use the language, the more you'll learn these quirks. Taking the time to investigate and understand why they are they way they are can provide more insight into the ruby language.

Other related things worth checking out:

• Here and here are a couple of great posts that give more details about currying.
• RubyGolf
• Gary Bernhardt's 'Wat' talk.

thread_safety_first.md

Thread Safety First

by Emily Stolfor, at GoGaRuCo 2013

Intro

Emily starts off by showing an example of 200 threads, half of which access a shared resource in a non-threadsafe way. Running tests on this can work fine, but running on jruby multiple times, it eventually blow up - indicating the difficult nature of the threading problem. Emily says that this is because there is no such thing as threadsafe ruby code. Gosh!

I'm skeptical about this assertion, so my interest is piqued!

The concurrency issue in ruby is complicated by the different threading models in the different ruby implementations. This might hide threading problems on some implementations.

e.g. MRI has a Global Interpreter Lock; jruby has green threads.

The GIL means that only one thread is running on the CPU at one time. JRuby has no GIL and can execute multiple threads, scheduled by the OS, at the same time.

Example

Emily shows a code example from a MongoDB driver, which has a similar code to the failed example. Therefore, this is also not threadsafe. Hashes are also not threadsafe.

Some possible solutions and issues:

• Avoid shared data across data. If unavoidable, use immutable variables. If you can't, use concurrency primitives.

1. Mutexes. An object that is used to synchronise across threads. Mutexes have problems: Don't block on IO! The thundering heard: Many threads waiting for a lock. Only one can continue, but all the threads will awaken when the lock is released.
2. The Condition Variable. A communication mechanism between threads. I didn't quite follow what the issues were with this.

Testing

Test with a ton of threads, with multiple implementations. Test with precision: Check out the rendezvous / barrier pattern.

Take-away message

• Know your implementations,
• Know your concurrency primitives,
• Know your code / design

There is no such thing as thread-safe ruby code, but there is 'jruby 1.7.4 thread-safe code' - Aaah, I see.

My thoughts

I was skeptical about the idea that there is no such thing as thread-safe ruby code, but I get what Emily is saying. Concurrency is certainly hard, and sometimes you have to wonder ifs its worth the trouble. Ruby's record with concurrency and parallelism is pretty poor, but there has been some good progress in concurrency at least in recent years.

I've heard that the GIL will be removed from MRI at some point, but I think thats been on the cards for a while, so I'm not holding my breath. JRuby has pretty good threading and no GIL, and so too, apparently, does rubinius and macruby. I've had conversations before at SRC about how CPUs are tending to grow more powerful through multiple cores, and therefore taking advantage of parallelism is going to be ever more important. But, I dunno, maybe this sort of thing just isn't ruby's strong-point. Other languages might be more suited to highly parallel problems.

Related things to investigate:

• This is an excellent 2-part blog post by Jesse Storimer going into detail about how MRIs implementation of the GIL enables thread-safe concurrency, and why you will get different results with different implementations.
• Celluloid
• Elixir
• Rob Pike's talk on parallelism vs concurrency, and while your at it, this post by Engine Yard looks helpful.
• EventMachine & the Reactor pattern.