DEV Community: Delon R. Newman

ruby -run, again

Delon R. Newman — Wed, 15 Jan 2025 19:42:32 +0000

Previously we learned about a tool in Ruby's standard library called un. After some consideration it occurred to me some might wonder, "How does this work?"

We learned that we can type something like ruby -run -e httpd . to start a web server that will serve all the files in our current directory over HTTP. But we said the name of the library is "un"
what's with ruby -run?

Well, why don't we try asking ruby? We can do so by making use of its help flag. Just type ruby -h and you should see something like this on your screen:

There are a lot of options here, but if you squint you'll notice just past the middle an option called -rlibrary. It says it's used to "require the library before executing your script". That's what we're using. "un" is the name of the library so when it's paired with -r it spells -run. That's clever!

View Source

Let's not stop there. What else can we learn? Let's checkout the source code. We can find it in this repository on Github: https://github.com/ruby/un. Let's check it out.

When you do you'll notice that there's a lib directory. That's usually were source code goes for Ruby libraries. Let's see what's in there. It's a single file. Interesting.

If you open it and scan through it slowly to the bottom you'll notice that it just contains a few functions. Now scrolling back toward the top the first function is setup. If you scroll down to the next function cp. You'll notice that it uses setup. If you go back up to setup you'll notice that it's parsing the command line flags that we've passed it using a class called OptionParser.

In the final line of setup it uses the Ruby keyword yield to pass the parsed arguments to a block that gets passed to it. Now when we look at each of the other functions cp, ln, mv, etc. they each use setup this way. That's a neat trick!

Come Together

That's interesting and all but we still haven't quite explained how ruby -run -e httpd . works. It seems like the missing piece is -e. Let's ask ruby again.

There it is, toward the top, -e 'command', "one line of script". Hmm. Let's try it out: ruby -e "puts 'Hi'". My console kindly greets me with "Hi". Is that what you see? Cool. So this allows us to execute arbitrary Ruby code....I think I get it! When I load the library "un" with -run I can call any of those functions in lib/un.rb!

Let's test out this theory by doing something crazy.

ruby -run -e 'setup() { puts "Hi" }'

Did your console greet you like mine did? That-is-cool. Now I get how ruby -run -e httpd . works. Now I just need to understand the httpd function. That'll have to wait. I could use a snack about now, but this was fun. Later!

ruby -run

Delon R. Newman — Wed, 15 Jan 2025 19:34:00 +0000

Ruby is well known as a language that is easy to use from the surface but is very deep and complex underneath. That's what we know and love about it. Its standard library has a similar design and contains many hidden gems. One of the gems I've learned about recently is un. It's designed to be a command line utility executed directly from ruby. This is its usage description:

This means that if you type

ruby -run -e help httpd

you'll see a help message that will describe how that command works.

Most of the commands have pretty limited utility. They seem to be portable UNIX utilities for use when Ruby is present but a UNIX environment is not. In fact, the package is described as "Utilities to replace common UNIX commands in Makefiles etc." Perhaps they're useful in embedded systems (I understand that Ruby is commonly
used for embedded systems in Japan).

The two that stand out to me are httpd and colorize. httpd is very useful. It's become my go-to utility when I need to quickly serve files over HTTP.

Just type

ruby -run -e httpd .

press "Enter" and boom you're done! You should see something like this on your screen:

Now you can open localhost:8080 in your browser and see the files you've served.

colorize prints out the Ruby code of any file you give it with syntax highlighting. I've not used it in a practical setting yet. But it might be useful when looking through Ruby files in a terminal as an alternative to cat.

Emacs is More Like a Terminal Than an Editor

Delon R. Newman — Thu, 23 Nov 2023 17:16:48 +0000

I've long been a command-line nerd. It was, after all, my first computer interface starting with Apple II's in school and DOS at home when my mother bought our first computer when I was 10. While I was fascinated by graphical interfaces when I first encountered them, text-based interfaces continued to hold a certain mystique especially as I became familiar with the UNIX shell through my early experiences with Linux based systems when I was in my teens.

As I continued to work at mastering the various skills of the programming trade, I decided to settle on a preferred text-editor¹. At that point I settled on Vim for it's ubiquity and extensibility. Over time I came to embrace the idea of using the UNIX environment as my primary IDE². From that standpoint the UNIX shell and it's various associated tools provide everything that you get from an IDE. I found that I was quite content with this as my default editing and programming environment with the exception of using IDEs for Java & C# when I used them.

When I finally took the Lisp plunge³ I started to wonder if I was missing something by not using Emacs. First, I'd never gotten into writing my own Vim extensions because Vim script—well let's just say Vim script isn't Lisp, and second I was coming to realize that there was something different and at least equally powerful about the Lisp vs. the UNIX mindset⁴. Additionally, I'd gotten bitten by a bug⁵. I wanted to understand the state-of-the-art in tooling for the sake of trying to get a sense of how we could do better, and the world of Lisp and Smalltalk seemed like some of the ripest fruit to pick⁶.

So now I've been exploring Emacs for a few years. Early on I had the "Emacs is a computing environment" or "operating system", but definitely not an "editor" aha. As a result, I've found myself keeping an Emacs window open almost all the time to be ready for use whether I need a text editor, Org Mode, Magit, TRAMP, or a R E P L. But it wasn't until reading You Don't Need a Terminal by Andrey Listopadov that the full impact of this hit me. After trying out his suggestions I hardly find myself opening a terminal at all whether it's iTerm or vterm or the terminals integrated into RubyMine or VS Code.

Emacs is my terminal. Just as when I was primarily a Vim user I always had my terminal open and I would access my various tools from it. Now I always have Emacs an arm reach away. But there is a difference. And I think the difference speaks to the difference between the Lisp and the UNIX mindset. From a UNIX shell each of the tools are different⁷, whereas Emacs provides a uniform interface over lower-level tools⁸. For example, if I want to access a remote server (or docker container) I use the same commands that I use to open files locally, and once I do connect all the commands I normally use now work on the remote server as well. This is a way of taking your configuration with you that Vim simply doesn't provide⁹. And more importantly, it's a way of empowering users through what is ultimately still a thin, but infinitely moldable layer of indirection.

Based on the advice I found in the wonderful book The Pragmatic Programmer. ↩
I even tried my best to replicate this experience on Windows (with mixed success) since I often used Windows machines in my work at the time. ↩
Using Clojure on a few projects in my work and digging into SICP and the Little Schemer series. ↩
For more on that read The Rise of Worse is Better and Worse is Better. ↩
I'm sure I can thank Bret Victor for this. ↩
Having long been an IDE user of the C++, Java, and C# sort I'd always found them helpful, but ultimately disappointing. Though I have recently succumbed to using RubyMine and VS Code for my Ruby and JavaScript work, respectively. Though that is at least in part about gaining an intuition for the state-of-the-art in programmer tooling. ↩
UNIX command line arguments are infamously inconsistent, though we celebrate the openness of the system---that it's disparate parts can be tied together with the very thin, but powerful abstraction that the shell provides. ↩
Some of this uniformity is due to the way Emacs has been configured for me. Since I'm a Emacs newbie, I've resorted to using Doom Emacs, after initially trying to build my own configuration. But in the end, Emacs provides the uniform substrate that enables that experience. ↩
Although VS Code does now provide similar functionality. ↩

How to Generate Unique Names With a Plain Old Ruby Object

Delon R. Newman — Thu, 16 Nov 2023 19:32:26 +0000

I recently came accross something approximating the following in a
client's code base.

# app/model/user.rb
class User < ActiveRecord::Base
  # ...more code
  before_validation :set_username
  # ...more code

  private

  def set_username
    return unless username.blank?

    i = 0
    begin
      if i < 10 && (email.present? || first_name.present?)
        prefix = [first_name, last_name].compact.join.presence || email.split('@')[0]
        self.username = prefix + (i.positive? ? i.to_s : '')
      else
        self.username = "user_#{SecureRandom.hex(3)}"
      end

      i += 1
    end while User.exists?(username: self.username)
  end
end

It's a fairly standard requirement for an application to have some named record that may need an automatically generated name that must be unique. This is a pretty standard (if not pretty) approach for a Rails application to take. I've taken a similar tack in the past myself.

This time¹ it occurred to me that this could be a good opportunity to apply a little bit of Object-Oriented Design and make use of a Value Object. As a starting place I envisioned something like this:

# app/model/user/unique_name.rb
class User::UniqueName
  delgegate :email, :first_name, :last_name, to: :@user

  def initialize(user)
    @user = user
  end

  def to_s
    username = nil

    i = 0
    begin
      if i < 10 && (email.present? || first_name.present?)
        prefix = [first_name, last_name].compact.join.presence || email.split('@')[0]
        username = prefix + (i.positive? ? i.to_s : '')
      else
        username = "user_#{SecureRandom.hex(3)}"
      end

      i += 1
    end while User.exists?(username: self.username)

    username
  end
end

# app/model/user.rb
class User < ActiveRecord::Base
  # ...more code
  before_validation :set_username
  # ...more code

  private

  def set_username
    return unless username.blank?

    self.username = UniqueName.new(self)
  end
end

Although User::UniqueName still isn't terribly pretty, it already has some useful properties. For one, in any testing I do, whether it's in the form of unit tests or experimenting in the REPL, it has the very desirable property that it can be tested on basis of simple input and output. Additionally, this can be done in relative isolation from the other properties I'd like to test about User. This wouldn't stop me from testing the integration with User either, but those tests can be few.

User::UniqueName.new(User.new).to_s # that's it!

All the essential behavior is encapsulated here. As a nice ergonomic bonus ActiveRecord will take care of calling #to_s for us as it coerces our Value Object into a string.

If this is the best we can do this is not a terrible place to be, but as it stands this code can be cleaned up, and it could be made more general. For example, on another project I'm working on there are many models that require unique names to be generated. Some models also need to be unique within a certain scope. In that case the Value Object might take this form instead. Here we've also added logic that will return the name of the record if it's present removing the need for a condition in our callback.

# app/models/unique_name.rb
class UniqueName
  def initialize(record, attribute: :name, scope: nil, root_name: nil)
    @record = record
    @attribute = attribute
    @root_name = root_name || "New #{model.model_name.human}"
    @scope = scope
  end

  def to_s
    name = record_name
    return name if name.present?

    unique_name
  end

  def record_name
    record.public_send(attribute)
  end

  def record_scope_value
    record.public_send(scope)
  end

  def unique_name
    n = auto_named_count
    n.zero? ? root_name : "#{root_name} (#{n})"
  end

  def auto_named_count
    query = model.where(attribute => root_name).or(model.where(attribute => "#{root_name} (%)"))
    return query.count unless scope

    query.or(model.where(scope => record_scope_value)).count
  end

  def model
    record.class
  end

  private

  attr_reader :record, :attribute, :root_name, :scope
end

# app/model/user.rb
class User < ActiveRecord::Base
  # ...more code
  before_validation { self.username = UniqueName.new(self) }
  # ...more code
end

# app/model/survey.rb
class Survey < ActiveRecord::Base
  # ...more code
  validates :name, uniqueness: { scope: :author }
  before_validation { self.name = UniqueName.new(self, scope: :author_id) }
  # ...more code
end


# app/model/saved_report.rb
class SavedReport < ActiveRecord::Base
  # ...more code
  validates :name, uniqueness: { scope: :author }
  before_validation { self.name = UniqueName.new(self, scope: :author_id) }
  # ...more code
end

Now we have a Value Object that is general enough to be used widely throughout a large project, and perhaps is on it's way to being a useful library.

Having long favored functional programming I've been exploring the complementary nature of object-oriented and functional programming (more on that later). ↩

On Venerable Technology--Perl, Part 1

Delon R. Newman — Wed, 08 Nov 2023 02:26:48 +0000

It seems these days that I often find myself in the position of one of the elder programmers in team settings. This is unsettling for a variety of reasons, one of the more obvious being that I’m just over 40, and one of the most troubling being that there’s still so much to learn. However, I do find that there’s some perspective that comes from being involved in the same industry for a while (27 years or so now—time waits for no one), and perspective, I’ve found, is always valuable. I often hear folks waxing nostalgic about PHP or the early days of JavaScript, but I hear very little about the wonder of a language that PHP and JavaScript, warts
and all, could never have come to be without. That language is Perl. To understand its significance we have to do a little time traveling, but before
we do that let’s talk a little about programming.

Programming is a deep and strange art (not to start debates about whether programming is an art, for me there is no debate, programming is an art if for no other reason than because Knuth said so, and if you don’t know who Knuth is please get back to your studies). It’s linguistic, it’s mathematical, for many it’s mechanical. Now that teaching programming is becoming more of a focus there’s starting to be some actual science on the subject and it seems according to at least one study in our brains’ opinion it’s none of the above.

Yet, each programming language, out of necessity, takes a stand on the matter. To C (old venerable C) programming is about helping the human communicate with the machine in a way that is portable (in the late 60’s sense of the word “portable”). To Lisp (my dear old friend) programming is a mathematical art, that is about the the creative artist communicating with themself (and others) then and only then with the machine. For COBOL programming is about getting the job done and in way that looks like English so hopefully, with a silent prayer to the saints, somebody who comes behind this guy will be able to understand his code.

Most other languages take one of these positions or some combination thereof. Perl, however, takes a view of programming that is uniquely its own. Yet, peridoxically, one of it’s most unique features is putting no effort into being unique. Rather all of its effort was thrown entirely in the opposite direction. That is, cannibalizing every good idea from every place else starting first with natural languages.

Please don’t misunderstand, Perl is not linguistic in the sense that COBOL and Basic and SQL are linguistic. These computer languages were linguistic in the shallow sense. Yes thanks to Chomsky, et al. they all have a formal grammar, and that formal grammar “looks” like English, but these languages only steal the appearance of natural languages. They lack deeper features that have a profound effect on the usability (the user interface) of language. Now the programmer (a bit older than myself) that was forced to sling Perl code at her Web 1.0 startup cries foul, “I know this guy didn’t bring up usability while talking about Perl”.

Yes, I said it, usability. Again, now there is actual science behind this and Larry Wall (the father of Perl) was trained in linguistics. Many of those features that make languages like Perl or APL look strange and alien actually make them more usable once you’ve learned them. The key is once you’ve learned them. Many of us who came to love Perl have had the experience of truly thinking in Perl (much the way we do in our native tongue) an experience I don’t think I’ve had in any other language since (it seems APL hackers report similar experiences). And ultimately that seems to have been a part of Perl’s struggle like Lisp and Smalltalk it’s a deep language, like C++ it’s a big language. It’s power was that it was also
easy to learn, that is, the basics were easy to learn, but the deeper parts that were necessary to know in order to understand it’s essential design and see how deeply coherent the language actually is was more like the process of having the code-as-data, “aha” from Lisp or the message passing, “aha” from Smalltalk, it took effort and that effort was only exerted by a relative few.

In a later article I’ll endeavor to illuminate those usability features. So for now, thank you for reading and in the meantime please enjoy these tasty links!