Forem: Nick Schwaderer

Matz talks mRuby at Barcelona Ruby Conf 2014

Nick Schwaderer — Wed, 30 Sep 2020 11:21:54 +0000

Past Rubies is a tiny weekly newsletter that shares curated historical content from the Ruby community. Consider it Ruby's version of 'on this day in history'. New issues every Wednesday. Subscribe to get this to your inbox

Yukihiro Matsumoto - mruby: AltRuby

Ruby is in satellites. Ruby is being used in hardware. A lot of this work is built off of mruby (embedded ruby) and affiliated projects. Here's a great talk Matz gave six years ago this week about a fair few things including mruby. :)

Using Rust with Ruby, pair programming with Yehuda Katz in 2015

Book out some time to sit down and watch this. We get to see *two hours* of pair programming with Yehuda Katz this week five years ago using Rust with Ruby

Ruby with BetaBrite in 2007 with Aaron Patterson

This week THIRTEEN YEARS AGO Ruby hero tenderlove released a new version of the ruby BetaBrite sign library, allowing you to compose ruby to control betabrite signs. This was ruby in the IoT space many years before the phrase IoT existed! Write in if you get the code up and running. :)

Making Javascript more Ruby-esque with JsClass in 2008

Twelve years ago this week people were turning their heads towards JsClass; which takes a lot of elements we love about ruby and implements them in Javascript. Note here in the screenshot that yes, that includes an Enumerable implementation! I would love to see if we could get this running on today's javascript.

Using AWS with Ruby - in 2007

Nick Schwaderer — Wed, 08 Jul 2020 14:16:47 +0000

This one is a bit of a treat. Normally I capture blog posts, articles, releases or talks. But this week I've found an AWS-with-Ruby tutorial archived from the AWS site this week in 2007! Check it out here: http://www.pastrubies.com/

Ruby Conf 2005 Agenda Released

Nick Schwaderer — Wed, 01 Jul 2020 17:56:40 +0000

Enjoying PastRubies? Know a friend who would be into this type of content? Let em know! :)

Past Rubies is a tiny weekly newsletter that shares curated historical content from the Ruby community. Consider it Ruby's version of 'on this day in history'. New issues every Wednesday. Subscribe

RubyConf 2005 Agenda Released

This week in 2005 saw the release of that year's RubyConf agenda. I always find these as a gold mine for really interesting information about what was going on in the Ruby Community at the time! I was tempted to make this week just highlighting the talks of the time but think you'll enjoy parsing the agenda as much as I did. Familiar faces included DHH and Matz, and other legends such as the late Jim Weirich and Ryan Davis. Would have loved to have been there!

Converting Ruby to Javascript (fourteen years ago!)

In 2006 this week London's Paul Battley had written a Ruby-to-JS converter in under 200 lines of Ruby code. It's hairy, and I didn't even try to run it nowadays. However it's a real treat to see folks looking at these issues when even JavaScript still feels so young sometimes. If you play around with the code let us know! (But I'm unsure how much use you'd get out of 2006-JS these days...)

Let's collect some garbage

Now if you want to dig into the real, REAL nitty gritty of Ruby history, it can be a lot to parse but the ruby-talk community is great. It's something I'm going to try to feature more. Today's ruby-forum only goes back to 2008, but you can still get back into the 2000's with some gumption. (Which we all have, right?) This week in 2005 we say an interesting post that piqued the Ruby community, having a dig into the GC and finding weird failing edge cases. I think sometimes it's too easy to just think of the Garbage Collector as a there be dragons area of Ruby and never play around with it. This thread and following discussion is a *great* example of that.

Web spidering back in the day

If _why is the Herodotus of Ruby circa 2003-2009, then Peter Cooper is the Tacitus of Ruby 2006-present. We are so grateful for all of his work the last decade to effectively chronicle the goings on of Ruby. Here he shares a neat tool of the time, Anemone, to manage your own spiders and configure your own web crawling. Neat!

How to use horizontal sharding in Rails 6.1

Nick Schwaderer — Tue, 03 Mar 2020 16:28:15 +0000

NOTE: As of writing Rails 6.1 has not been released, and to follow along you'll need to pointing to Rails Master, which is a handy thing to know how to do.

We saw some big news this week, as Rails continues to get better and better when it comes to supporting multiple databases.

Eileen Uchitelle and John Crepezzi shipped a commit to Rails master that allows full, out-of-the-box support for horizontal sharding.

Wait, shard what?

It is very possible you've gone your entire dev career without needing to shard, or even know vaguely what it is. That's okay. Rails has intentionally been constructed in such a way that you don't need to be a DB expert to use it.

However, here are a few links giving background on what sharding is, and maybe why you'd want to use it.

Forget it, I have no idea what I'm doing, but I want to shard NOW

Sweet! Me too.

First off, this is a Rails 6.1 feature (heh, which doesn't exist yet), so you'll need to spin up a Rails application off of the master branch.

You can do that by first generating a new rails app off of the latest stable branch:

rails new myapp --edge

Then, to point to the master branch, change the rails line to the below:

gem 'rails', github: "rails/rails", branch: "master"

Rebundle and voilá!

Let's make a bunch of databases

Update your database.yml like so (much of what comes being taken from the commit's docs):

development:
  primary:
    <<: *default
    database: my_primary_database
  primary_replica:
    database: my_primary_database
    replica: true
  primary_shard_one:
    <<: *default
    database: my_primary_shard_one
  primary_shard_one_replica:
    <<: *default
    database: my_primary_shard_one
    replica: true

You can use whatever database or adapter you want. I normally hook up Postgres, today playing around with SQLite3. For more advanced systems, these could all be pointing to different databases, local or remote, in vastly different locations. Pretty cool, huh?

In this setup from the docs, we have a primary and primary_shard, and each has a replica. Nifty!

Then run:

rails db:create; rails db:migrate

Created database 'my_primary_database'
Created database 'my_primary_shard_one'
Created database 'db/test.sqlite3'

Time to fill the database

Let's generate a model:

rails g model Person name:string
rails db:migrate

#=>
== 20200303155421 CreatePeople: migrating ====================================
-- create_table(:animals)
   -> 0.0026s
== 20200303155421 CreatePeople: migrated (0.0028s) ===========================

== 20200303155421 CreatePeople: migrating ====================================
-- create_table(:animals)
   -> 0.0040s
== 20200303155421 CreatePeople: migrated (0.0041s) ===========================

And either in a seeds file or our console, run:

Person.create!(
  name: 'Frieda'
)

Person.create!(
  name: 'Bill'
)

Person.create!(
  name: 'Penelope'
)

Playing with the databases

Now, let's update our application_record.rb like so:

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to shards: {
    default: { writing: :primary, reading: :primary_replica },
    shard_one: { writing: :primary_shard_one, reading: :primary_shard_one_replica }
  }
end

We will now reload our console and see what we can do, using ActiveRecord::Base.connected_to:

ActiveRecord::Base.connected_to(role: :reading, shard: :shard_one) do
  Person.first
end
#=> nil


# Now let's write to :shard_one,
ActiveRecord::Base.connected_to(role: :writing, shard: :shard_one) do
   Person.create!(
     name: 'John'
     )
    Person.create!(
      name: 'Georgina'
    )
 end

#=> #<Person id: 2, name: "Georgina", created_at: "2020-03-03 16:10:14", updated_at: "2020-03-03 16:10:14">

# And we'll read from :shard_one's replica:
ActiveRecord::Base.connected_to(role: :reading, shard: :shard_one) do
  Person.count
end
#=> 2

# And finally confirm that shard one's data has not been written to primary:

ActiveRecord::Base.connected_to(role: :reading, shard: :default) do
  Person.count
end
#=> 3

# This is correct, remember the three people we created earlier who default to the primary database.

Not too tricky

That was.... not as involved as one would inspect. Cheers to the Rails core team for once again making things as straightforward and developer friendly as possible! 💖

You can use this code however you like, and write and read from databases in whatever architecture is justified by your business logic.

Once again, for all the full details on using this feature in the wild, see the full PR here.

Ruby Science Saturday: use Mixin Modules or Reopen Classes? 👩‍🔬🔬🧬🧪

Nick Schwaderer — Sat, 22 Feb 2020 14:11:39 +0000

Ruby legend Xavier Noria recently penned a tweet that got me thinking about how we organize and package up our native Ruby code:

How often do we just dump our code into mix-in modules (that never get reused) when our classes get too large? What if we continued to organize our code into separate files, but reopened classes?

This is something we can debate all day in the comments, but that sparked my Ruby Science question:

What if one of these approaches was faster?

Well, thanks to benchmark-ips, (which I have also bundled into my own performance logging gem) we don't have to wonder.

I fired up three example cases (Reopen, Include mixin module, Extend mixin module) and ran them against each other in a simple test case. Code below:

module MixinDependency
  def open_door
    puts 'Door is open!'
  end
end

class DoorOpenerMixin
  include MixinDependency

  def close_door
    puts 'Door is closed!'
  end
end

class DoorOpenerMixinExtend
  extend MixinDependency
end

class DoorOpenerReopen
  def close_door
    puts 'Door is closed!'
  end
end

class DoorOpenerReopen
  def open_door
    puts 'Door is open!'
  end
end

And we tested it with:

require 'benchmark/ips'

Benchmark.ips do |x|

  x.report('Include') { DoorOpenerMixin.new.open_door }
  x.report('Extend') { DoorOpenerMixinExtend.open_door }
  x.report('Reopen') { DoorOpenerReopen.new.open_door }

  x.compare!
end

Results? Nothing exciting.

Comparison:
              Extend:   214816.5 i/s
              Reopen:   197784.3 i/s - same-ish: difference falls within error
             Include:   182298.2 i/s - same-ish: difference falls within error

Even inconclusive findings are still findings, and I hope you enjoyed seeing how I picked through this hypothesis to give a clear answer. If you're unfamiliar with benchmark-ips, copy this code and try it out yourself! It really is one of my favorite tools in my toolbox.

One small but fun finding, I tried running this on different Ruby versions, you can see a clear speed bump since Ruby 2.1! Here's the results on the old version:

Comparison:
              Extend:   178840.8 i/s
             Include:   167210.7 i/s - same-ish: difference falls within error
              Reopen:   166005.2 i/s - same-ish: difference falls within error

If you have any 'experiments', feel free to share your results and thoughts below! 🥼 🤔

Dev.to is one of the best open-source Rails apps you can contribute to

Nick Schwaderer — Thu, 02 Jan 2020 13:25:58 +0000

This week the Ruby on Rails podcast released episode 301, which I was very lucky to be a part of.

On the episode Brittany Martin and I talked about several topics, including ParisRB and combating imposter syndrome with chess and bodyPUMP.

Also, I went on at length about the dev.to source code on Github. For those who don't know, this application is primarily a Ruby on Rails backend.

As a bonus, it handles millions in monthly traffic and is a very mature, elegant application. It hooks into tooling such as Algolia and Pusher, and other very interesting technologies. The most beautiful part is it's open source.

That means if you've been working on Rails webapps for anywhere from 1-10 years, it's a fantastic and evolving codebase to explore and learn.

Never written a publicly accessible API before? Just have a look at how it's been architected for dev.to!

Unsure about notification handling on a large scale for the first time? Fear not- there's a great example to be had here!

Very often people look to Discourse (another fantastic open source Rails app)- but if you're really looking to upskill from Junior to Middleweight or Middleweight to Senior as a Rails developer, working through this codebase could be the boost you need!

Check out the episode:

http://5by5.tv/rubyonrails/301

_why interviews DHH

Nick Schwaderer — Wed, 18 Dec 2019 13:20:35 +0000

_why interviews DHH

Christmas Eve 2004 (!) saw our favorite why the lucky stiff interviewing DHH. They cover Instiki, the future of Rails, music and skyscrapers.

Peter Cooper's RubyInside releases the ultimate Ruby advent calendar

_What a treat for our readers to peruse over the Christmas Holiday break. As hinted last week, here is Peter Cooper's amazing Ruby advent calendar released back in 2006. You have interesting Ruby snippets, cool links, and even shnazzy wallpaper. If you're a Ruby history buff like me, this is a gold mine _

Why Rubinius matters to Ruby's future

This post released 11 years ago this week by Reg Braithwaite goes into the importance of Rubinius. At that time Engine Yard had five full time staffers working on Rubinius. Pretty interesting discussion in the comments below.

What makes Rails a framework worth learning in 2017

Once in a while I'm allowed to treat myself to a link *not* on this week in history, right? We are likely to take a break during the festive season so it feels appropriate to wrap things up with this post from DHH. Enjoy!

Rails 1.0 turns 14

Nick Schwaderer — Thu, 12 Dec 2019 16:28:44 +0000

10 more features in Ruby 2.5

It's Christmas which means new Ruby time! But I think it's all too easy to forget the new features of recent versions so we can utilize the latest Ruby goodness! Here's a great writeup published this week in 2017 on those features in Ruby 2.5

A pagination helper for Rails in 2004

Well would you look at that! A little cheeky banter between Ruby legends _why and DHH this week fifteen years ago. This is a neat little peek into Rails pagination in 2004, a year before 1.0 was released! (Yes, it's that old of a problem space)

What are events, why you might care, and how EventMachine can help

This is a great little writeup on the EngineYard blog by Kirk Haines on events and event machine (published this week in 2011)

The 2005 Ruby Advent Calendar

Who remembers reading the Tucows blog back in the day? It was a massive source of info for Rubyists in the early coding days. Here's a glimpse into the Ruby Advent Calendar they were hosting in 2005 (note: the famous PeterC also had a few that may yet get featured this month!)

Neat Ruby snippets 2004

Gosh, I haven't hustled through the RubyTalk archives yet... That changes this week! Here's a pleasant fifteen year old (this week) thread on interesting Ruby snippets that accomplish cool things. (We're talking servers in six lines)

The Ruby on Rails Whitepaper [Past Rubies]

Nick Schwaderer — Wed, 04 Dec 2019 15:37:51 +0000

The Ruby on Rails White Paper, 10 years later

This was actually released in the autumn of 2009, but was making the rounds on blogs a decade ago this week as more people discovered it. InfoEther and Mark Gardner released a very comprehensive Ruby on Rails whitepaper which covered everything from the current state of the framework, estimated developer population, to the community and ecosystem. For those of us who have been around a while or even fancy ourselves a bit of a "Ruby Historian", this is an unrivaled snapshot into the "State of Rails" in 2009.

It's time for... SCIENCE!

This week five years ago we got to see Jesse Toth give a talk about their work on Github's Scientist. This allows developers to compare, via the lens of 'science experiments', old code and refactored code. Enjoy the talk and the code!

Snakes and Rubies Conf

A whopping fourteen years ago saw Snakes and Rubies Conf, a collaborative conference between the Ruby and Python programming communities. You can check out a wrapup here, and plenty from DHH and crew at the link above. Since I run everything through the wayback machine, most of the old links SHOULD work.

In memory of Ezra Zygmuntowicz

In a massive loss for the Ruby community, we found out about the passing of Ezra five years ago this last week. To honor his memory, we have this very kind tribute from Mike Perham back in 2014. There is also this magnificent talk from Ezra himself where he goes through a lot of his journey.

Using Rubyfmt with Atom

Nick Schwaderer — Mon, 02 Dec 2019 16:16:17 +0000

Rubyfmt, the exciting project from @penelope_zone continues to grow by the day. After being a fan of this work for quite a while, I set out to hack together a way to get it running slick on Atom. I'm writing today to share those few steps so that you, too, can enjoy the magic of Rubyfmt on Atom!

What is Rubyfmt?

I reckon 90% of people reading this article will already be intimately familiar with this project. If not, here's the quick hits.

Rubyfmt is inspired by gofmt. It formats existing Ruby code, and you can set this up as you like (today we will do it after save). It is mature enough to be able to run against all of rspec-core without breaking. You can read more details on the Github README.

I first heard about this when Penelope discussed it with @sgrif on the Yak Shave podcast. The subject came up in multiple episodes, and if I'm honest the technical details of creating this awesome tool likely went over my head. I still recommend taking a listen!

Okay, let's get this running on Atom

1. Follow initial README instructions

At time of writing these are:

git init
git clone https://github.com/penelopezone/rubyfmt.git
make
make install

2. Set up Atom 'after-save' listener.

Install Atom package save-commands
add the following to your save-commands.json in your directory:
"**/*.rb": "ruby --disable=gems path/to/bin/rubyfmt.rb -i {absPath}{filename}"

Full example:

# save-commands.json
{
    "commands": [
        "**/*.rb : ruby --disable=gems /path/to/bin/rubyfmt.rb -i {absPath}{filename}"
  ]
}

And voila! You should be in business. As a test you can add something unRuby-ish to a Ruby file (or just excess whitespace), save, and it should autoformat!

3. Gotchas:

Atom didn't like the recommended command on RubyFmt of ruby --disable=gems ~/bin/rubyfmt.rb -i ${file}
To get around this I manually passed in the actual path, obtained with realpath rubyfmt.rb
Happy to improve this if a reader has a more elegant solution

4. Moving forward:

I will try to keep this post updated, but following @penelope_zone on Twitter and checking out the README are the current best sources of truth
It would be nice to wrap this up automatically in an atom package in future, so these steps aren't necessary. I've started looking into this but it may be more straightforward with someone more familiar with writing Atom package plugin code
If you have any "this doesn't format correctly" feedback, hold fire for the moment as there's a lot of work happening on this right now

Thanks, Penelope! ❤️

Never miss one of my posts by signing up for my newsletter here