DEV Community: RPA

Generators are APIs — Designing Better DX in Rails

RPA — Tue, 21 Apr 2026 23:54:36 +0000

This article is based on the talk I gave at Tropical on Rails 2026 in São Paulo. If you were there, this is the written version. If you weren't — welcome. This is the whole thing.

Introduction:
Rails generators are one of the most underrated tools in the framework. Every Rails developer has used them. Few have designed them. And almost nobody treats them as what they actually are: an API. This article makes the case that generators deserve the same design attention we give to REST APIs — and shows what that looks like in practice, using real code from jet_ui, a Rails gem I built at JetRockets and launched at Tropical on Rails 2026.

The Wrong Frame

The typical mental model for generators looks like this:

Input a name → Get some files → Move on with your life

It's a reasonable model. Generators are code generation tools — you give them a name, they give you files, you keep building. Nobody questions this because it works. rails g model User creates a model. rails g controller Posts creates a controller. The generator runs, the files appear, and the developer moves on.

But that frame misses something important. Every time a developer runs a generator in a project, they're not just running a command. They're accepting a decision that someone else made. A decision about folder structure, naming conventions, what gets generated by default, what doesn't, and what happens when something goes wrong.

If that decision was made well, the developer doesn't notice — they just get good results. If it wasn't, they get confusion, inconsistency, and eventually a Slack message that reads: "Hey, how do we do X here?"

That's not automation. That's influence. That's design.

The API Analogy

The reason generators deserve more attention is that they share the same interface contract as an API. Consider the mapping:

API concept	Generator equivalent
Endpoint name	Generator name
Request params	Arguments & flags
Response body	Generated files
Error messages	Failure output

We hold APIs to a high standard because we know developers are going to interact with them repeatedly. We think carefully about naming, document every parameter, return consistent responses, and write error messages that explain what went wrong and how to fix it. If an API has confusing naming, we file a bug. If inputs are unpredictable, we complain. If errors are useless, we write angry posts on X.

And then we ship a custom generator with no --help, no output messages, and a Ruby backtrace on failure — and nobody bats an eye.

The difference isn't that APIs matter more. The difference is that we never thought of generators as something worth designing. This article argues that we should.

What Bad DX Looks Like

To make this concrete, here are three real problems that show up in poorly designed generators. The examples use jet_ui as the reference context — but to be clear, these are illustrative scenarios, not actual issues in the gem. Think of them as "what jet_ui:eject could have looked like if DX hadn't been a priority from the start."

🔴 Problem 1: Ambiguity

When a generator has no documented naming convention, developers are left guessing. Should the component name be capitalized? Abbreviated? Written as a path?

$ rails g jet_ui:eject Button
$ rails g jet_ui:eject button
$ rails g jet_ui:eject btn

All three feel plausible. Without documentation or a clear convention communicated through the generator itself, a new developer has no way to know which form is correct — or whether it even matters. This is a naming contract that was never written. The cost isn't just confusion on day one. It's inconsistency across the entire codebase as different developers pick different forms over time.

🔴 Problem 2: No feedback

A generator that runs silently is a generator that communicates nothing. Here's what an eject_components method looks like without any output calls — just the bare template loop:

def eject_components
  components.map(&:downcase).each do |name|
    MANIFEST[name][:files].each do |entry|
      template entry[:src], entry[:dest]
    end
  end
end

Running this produces:

$ rails g jet_ui:eject btn

      create  app/components/jet_ui/btn/component.rb

One file created. No CSS. No test. No preview. No confirmation that the operation was successful. No mention of what was skipped or why. And critically — no next steps. The developer is left wondering: are there other files I need to create manually? Do I need to restart the server? Do I need to run anything?

Good tools tell you what they did. Great tools tell you what to do next.

🔴 Problem 3: No control by having no options

A generator that always generates everything — regardless of the project's needs — forces developers to either accept files they don't want or manually delete them after every run. The problem isn't the output itself, it's the absence of choice.

class EjectGenerator < Rails::Generators::Base
  argument :components, type: :array,
    banner: "component [component ...]",
    desc: "Component(s) to eject (e.g. btn card)"

  # No class_option :skip_test
  # No class_option :skip_preview
end

With this implementation, generating a component always produces the component file, the CSS file, the test file, and the preview file. Every time. Without exception.

But what if the project uses RSpec instead of Minitest? What if previews aren't part of the workflow? What if the developer only needs the CSS to override a style? None of that matters — the generator decided for them, and gave them no voice in the matter.

Five Principles for Better DX

These three problems have the same root cause: the generator was written, not designed. Writing a generator means producing something that works. Designing one means producing something that communicates, guides, and respects the developer using it. Here's what that looks like across five principles.

🟢 Principle 1: Naming is a contract

The name of a generator, and the names of its arguments, should communicate exactly what it does and how to use it. This isn't about being clever or descriptive — it's about being unambiguous. A developer should be able to read the command and know what they'll get before they run it.

The desc block and the argument definition are the primary tools for this. They're not just documentation — they're what makes --help work, and --help is the first thing a developer reaches for when something isn't obvious.

class EjectGenerator < Rails::Generators::Base
  desc "Ejects JetUi component(s) into your application for local customisation."

  argument :components, type: :array,
    banner: "component [component ...]",
    desc: "Component(s) to eject (e.g. btn card)"
end

With this in place, --help produces something actually useful:

$ rails g jet_ui:eject --help

Usage:
  rails generate jet_ui:eject component [component ...] [options]

Description:
  Ejects JetUi component(s) into your application for local customisation.

Example:
  rails g jet_ui:eject btn card

The naming convention — use the component's short name — is now communicated through the generator itself. No Slack message required.

🟢 Principle 2: Predictable inputs

Every flag a generator accepts is a promise to the developer. It says: this is a choice you can make, here's what it controls, and here's what happens by default. When flags are undocumented or absent, developers either don't know the choice exists or can't make it.

The class_option method is where this happens. Each option should have a desc that explains what it does in plain language:

class_option :skip_test, type: :boolean,
  default: false,
  desc: "Skip test files for each component"

class_option :skip_preview, type: :boolean,
  default: false,
  desc: "Skip preview files for each component"

This solves the "no control" problem immediately. Running rails g jet_ui:eject btn --skip-test skips the test files. Running it with --skip-preview skips the previews. The defaults still generate everything for developers who want the full output. Everyone gets what they need without fighting the tool.

Predictable inputs also make generators easier to automate, script, and integrate into CI pipelines — because the behavior is explicit, not assumed.

🟢 Principle 3: Transparent output

A generator that says nothing is a black box. The developer runs it, files appear, and they have to manually inspect the result to understand what happened. This is fine for simple cases — but it doesn't scale. As generators get more complex, silent execution becomes a liability.

The say and say_status methods exist precisely to address this. They're underused in most custom generators, but they're what separates a tool that communicates from one that doesn't.

def eject_components
  # ... validation + template logic

  say "\nEjecting #{name}...", :cyan
  # ... generate files
  say "  #{name} ejected.", :green
end

def show_summary
  say "\nDone! Ejected: #{components.map(&:downcase).join(", ")}\n", :green
  say "The local files in app/components/jet_ui/ now take precedence over the gem."
  say "Run your tests to confirm everything still works:\n"
  say "  bundle exec rake test\n"
end

This is the real output from jet_ui:eject:

Ejecting btn...
      create  app/components/jet_ui/btn/component.rb
      create  app/assets/stylesheets/jet_ui/btn.css
      create  test/components/jet_ui/btn/component_test.rb
      create  test/components/previews/jet_ui/btn/component_preview.rb
  btn ejected.

Done! Ejected: btn
The local files in app/components/jet_ui/ now take precedence over the gem.
Run your tests to confirm everything still works:
  bundle exec rake test

Every line is a deliberate decision. What to announce before acting. What to confirm after each file. What to summarize at the end. What to tell the developer to do next. That last part — the next steps — is the most commonly missing piece in generator output. It's also the one that most directly reduces the number of questions a new developer has to ask.

🟢 Principle 4: Helpful errors

An error message that doesn't explain the problem isn't a message — it's noise. The worst case is a Ruby backtrace: technically accurate, completely useless to the developer who just mistyped a component name. The better approach is to catch the problem early, name it clearly, and show what's valid.

def eject_components
  unknown = components.map(&:downcase) - MANIFEST.keys

  if unknown.any?
    say "\nUnknown component(s): #{unknown.join(", ")}", :red
    say "Available: #{MANIFEST.keys.join(", ")}\n", :red
    exit 1
  end

  # ... rest of the logic
end

The result is a message that tells the developer exactly what went wrong and what to do about it:

$ rails g jet_ui:eject buton

Unknown component(s): buton
Available: btn, card

This pattern — validate early, fail loudly, show the valid options — applies to any generator that accepts constrained input. It costs very little to implement and dramatically reduces the friction of a first failure.

🟢 Principle 5: Design for extension

A generator that can only be used as-is — with no way to extend or modify its behavior without touching the source — is fragile. It forces developers to choose between using it as prescribed or forking it entirely. Neither option is good.

Rails generators are built on Thor, which means they inherit from Rails::Generators::Base — and that means subclassing is a first-class pattern. A well-designed generator takes advantage of this by organizing its logic into small, focused methods that can be overridden or extended individually.

class EjectWithStorybookGenerator < JetUi::Generators::EjectGenerator
  desc "Like jet_ui:eject, but also generates Storybook stories."

  def generate_stories
    components.map(&:downcase).each do |name|
      template "#{name}/story.js.tt",
        "stories/jet_ui/#{name}/component.stories.js"
    end
  end
end

This subclass gets everything from the parent for free — argument handling, validation, say calls, summary output — and adds exactly one new behavior. The original generator is never modified. The team member who wrote this extension never had to ask how the base generator works internally — they just used it as a foundation.

If a generator can't be extended without modifying it, it's not a tool. It's a script.

The Bigger Picture

These five principles are tactical. But there's a strategic argument behind them that goes beyond individual generators.

Every time a developer runs a generator, they're executing a decision that was made when it was designed. If that decision was made well — with clear naming, predictable inputs, transparent output, useful errors, and extensibility in mind — it scales. It scales to every developer on the team, every feature they build, every project that follows the same conventions. The generator becomes a living encoding of architectural decisions that would otherwise live only in documentation, tribal knowledge, or the memory of whoever wrote the original code.

If the decision wasn't made well, that also scales. It scales the inconsistency, the confusion, and the technical debt — one run at a time.

This is why generators matter beyond code generation. A well-designed generator is:

📋 Onboarding — a new developer who runs rails g jet_ui:eject btn learns the project's conventions by using them, not by asking. The output tells them what was created, what takes precedence, and what to run next. That's an onboarding experience encoded in a command.
📖 Living documentation — the --help output describes exactly what the generator does and how to use it. Unlike a README, it can't go out of date — it's generated from the same code it describes.
🏗 Architecture enforcement — conventions encoded in generators are conventions that get followed. Not because developers are disciplined, but because the path of least resistance points in the right direction.

Three Things to Do Tomorrow

🔎 Audit one generator in your project as if it were a public API. Run it with --help. Is the output useful? Are the flags documented? Are the error messages actionable? Would you ship this to external developers?
⚡ Add a desc block to any custom generator that doesn't have one. One line. Ten minutes. Your generator just got a help page, and every developer on your team can now discover what it does without reading source code.
💡 Next time you write a generator, ask yourself: could a new developer use this without asking me anything? That question alone — applied honestly — captures everything in this article.

Conclusion:
There's a quiet irony in how we build software. We spend hours debating API design, writing documentation, reviewing pull requests — all in the name of quality. And then we ship a custom generator with no --help, no feedback, and no error messages, and nobody bats an eye.

Generators are invisible infrastructure. They run once, they generate files, and then they disappear from the conversation. But the decisions they encode — the folder structures, the naming conventions, the assumptions about what a developer needs — those stay. They get repeated. They get inherited by every new team member, every new feature, every new project that follows the same pattern.

That's why this matters. Not because generators are complex or glamorous, but because they're mundane. The tools we use every day without thinking are exactly the ones that shape how we think. Design them with intention, and that intention scales silently across your entire team.

The next time you write a generator, treat it like a public API. Because for the developers who will use it — it is.

Happy coding! 🚀

About jet_ui

jet_ui is a Rails gem I built at JetRockets to package the UI component library originally created by Aleksei Solilin — a comprehensive collection of ViewComponent, TailwindCSS 4.0, and Stimulus components available at ui.jetrockets.com. The gem makes those components installable and ejectable in any Rails project, new or existing, without copying code manually.

The jet_ui:eject generator shown throughout this article is real, open source, and available for inspection at github.com/jetrockets/jet_ui.

To get started:

# Add to your Gemfile
gem 'jet_ui'

# Install
bundle install

# Run the install generator
rails g jet_ui:install

# Eject a component for local customisation
rails g jet_ui:eject btn

Forging the Future of Blockchain Development (with Ruby)

RPA — Tue, 19 Dec 2023 21:47:57 +0000

It's been a while since I wrote the last article here on DEV (Empowering Ruby in the World of Machine Learning). These have been difficult times, in which unfortunately I haven't been able to invest even a little amount of time in what I like so much. This time, keeping the essence of this series in which I want to emphasize the power of Ruby outside of Rails, I come with a very popular topic outside the Ruby world, but with the idea of integrating it in such a way that we learn how we can combine the best of both worlds and take advantage of it. We all know that Rails is too good, but sometimes we know little about what we can do with Ruby outside of Rails. And, following that essence, I wrote about Ruby+Blockchain. Enjoy!

Introduction: Ruby on Blockchain.

Blockchain technology, the revolutionary force behind decentralized applications and cryptocurrencies, has been predominantly associated with languages like Solidity and JavaScript. Yet, the often overlooked Ruby language emerges as a powerful and elegant solution for blockchain development. This comprehensive article aims to dissect why Ruby stands as the optimal choice for building robust, scalable, and secure blockchain applications. From its expressive syntax to deep integration with web frameworks and an array of libraries, we will explore how Ruby not only facilitates blockchain development but also revolutionizes it.

1. Expressive Syntax and Developer Efficiency:

Ruby's syntax, lauded for its readability and elegance, significantly contributes to developer efficiency. In the domain of blockchain development, where complex smart contracts and algorithms reign, having a language that simplifies expressing intricate ideas is a game-changer.

   # Smart contract in Ruby
   class SimpleTokenContract
     def initialize
       @balances = {}
     end

     def transfer(sender, receiver, amount)
       @balances[sender] -= amount
       @balances[receiver] += amount
     end
   end

2. Robust Ecosystem of Gems and Libraries:

The Ruby community boasts an extensive ecosystem of gems and libraries that offer a plethora of tools for blockchain developers. Gems such as bitcoin-ruby and ethereum provide streamlined methods for interacting with Bitcoin and Ethereum blockchains, offering a seamless entry point into blockchain development.

These are easy examples to know how to introduce yourself (and use) gems regarding Blockchain development.

bitcoin-ruby Gem: The bitcoin-ruby Gem is a standout in the Ruby toolkit, offering comprehensive functionalities for Bitcoin blockchain integration. It simplifies tasks such as generating Bitcoin addresses, creating transactions, and managing wallet functionalities.

   require 'bitcoin'

   # Create a Bitcoin address
   key = Bitcoin::Key.generate
   address = key.addr

ethereum Gem: For Ethereum blockchain integration, the ethereum Gem is a go-to choice. It provides methods to interact with Ethereum smart contracts, execute transactions, and retrieve blockchain data efficiently.

   require 'ethereum'

   # Interact with an Ethereum contract
   contract = Ethereum::Contract.create(file: 'path/to/contract.sol')
   result = contract.call.myFunction(params[:param])

web3-rb Gem: The web3-rb Gem serves as a powerful tool for Ethereum-based development. It offers functionalities to connect with Ethereum nodes, handle transactions, and interact with smart contracts.

   require 'web3'

   # Connect to an Ethereum node
   web3 = Web3::Eth::Rpc.new(host: 'http://localhost:8545')

ripple-client Gem: Those working with Ripple blockchain find the ripple-client Gem invaluable. It facilitates interactions with the Ripple network, enabling users to send payments and manage accounts seamlessly.

   require 'ripple'

   # Send a payment via Ripple
   client = Ripple::Client.new
   client.payment.create(...)

stellar-sdk Gem: The stellar-sdk Gem simplifies Stellar blockchain integration. It allows for the creation of transactions, managing accounts, and accessing the Stellar network's functionalities.

   require 'stellar-sdk'

   # Create a transaction in Stellar
   Stellar::TransactionBuilder.new(...)

These Gems, among many others, empower developers in the blockchain space, offering an extensive array of functionalities to build, manage, and interact with various blockchain networks. Leveraging these Gems, developers can streamline their workflow, expedite development, and create robust blockchain applications efficiently.

3. Web Development Synergy:

Obviously we need to talk a little about Ruby on Rails, the prominent web development framework, that seamlessly integrates with blockchain development. This harmony allows developers to build user-friendly interfaces for decentralized applications, enhancing the overall user experience.

   # Smart contract interaction in a Rails controller
   def show
     @contract = Ethereum::Contract.create(file: 'path/to/contract.sol')
     @result = @contract.call.myFunction(params[:param])
   end

4. Developer-Friendly Environment and Supportive Community:

The Ruby community fosters a welcoming environment for developers venturing into blockchain. Abundant tutorials, forums, and open-source projects create an enabling atmosphere, nurturing both newcomers and experienced developers alike.

5. Flexibility and Dynamic Typing:

Ruby's dynamic typing facilitates flexible development, crucial in adapting to the ever-evolving blockchain landscape. This adaptability empowers developers to respond quickly to changes in blockchain specifications and requirements.

6. Testing and Test-Driven Development (TDD):

Ruby's culture of Test-Driven Development (TDD) aligns seamlessly with the rigorous testing demands of blockchain applications. Testing frameworks like RSpec and Minitest enable developers to create robust and secure blockchain solutions.

Ruby's Internals Strengths in Blockchain Development

Ruby's internal design intricacies align remarkably well with the demands of blockchain development. While often not immediately apparent, Ruby's core features and mechanisms significantly contribute to the creation of efficient and robust blockchain applications.

1. Object-Oriented Nature:

Ruby's object-oriented paradigm perfectly fits the architecture of blockchain systems. The encapsulation of blockchain components as objects enhances readability, maintainability, and re-usability within smart contracts and decentralized applications.

   class SmartContract
     def initialize
       @storage = {}
     end

     def store_data(key, value)
       @storage[key] = value
     end

     def retrieve_data(key)
       @storage[key]
     end
   end

2. Memory Management and Garbage Collection:

Ruby's garbage collection mechanisms and efficient memory management are pivotal in blockchain applications. Optimal memory utilization ensures seamless performance in managing large volumes of transactional data within the blockchain network.

3. Dynamic Dispatch and Flexibility:

Ruby's dynamic dispatch capability aligns seamlessly with the dynamic nature of blockchain transactions. It accommodates flexible execution paths, adapting to changes in transaction types and state updates within the blockchain.

4. Concurrency and Parallelism Support:

Blockchain networks often handle multiple transactions concurrently. Ruby's support for concurrency via features like fibers and threads equips it to manage the parallel processing demands of blockchain networks effectively.

   require 'concurrent'

   # Create concurrent tasks for blockchain processing
   task1 = Concurrent::Future.execute { process_transaction(transaction1) }
   task2 = Concurrent::Future.execute { process_transaction(transaction2) }

5. Flexibility in Protocol Implementations:

Ruby's flexibility in protocol implementations allows developers to seamlessly integrate with diverse blockchain protocols. This adaptability empowers developers to craft blockchain applications tailored to specific network requirements.

These internal strengths of Ruby might not be immediately visible but play a critical role in the efficiency, scalability, and adaptability of blockchain applications developed in Ruby. By leveraging Ruby's internal mechanisms, developers can create robust and efficient blockchain solutions tailored to diverse use cases.

Conclusion: Ruby's potential for Blockchain projects.

In the fast-evolving realm of blockchain development, Ruby stands tall, blending elegance and power to create decentralized, transparent, and secure applications. From its expressive syntax to its robust ecosystem and deeper internal strengths, Ruby emerges as a language that not only simplifies but also elevates blockchain development.

By embracing Ruby for your next blockchain project, you tap into a language that not only enhances developer productivity but also harnesses the underlying strengths of its internal mechanisms. Ruby's object-oriented nature, memory management, dynamic dispatch, and support for concurrency make it a compelling choice for crafting secure, efficient, and scalable blockchain solutions.

Embark on your blockchain journey with Ruby, where elegance meets innovation, and witness the seamless fusion of sophistication and functionality in the blockchain realm.

Empowering Ruby in the World of Machine Learning

RPA — Mon, 14 Aug 2023 10:43:07 +0000

First of all I would like to say thanks for the good reception and support y'all have given to my last article Exploring Genetic Algorithms with Ruby. It really meant the world to me. I know I said I was going to write consistently on a weekly-basis but August started off pretty rough so I needed to push this new article back a bit. Also, I am a "do it well or not at all" guy, and this means that if I'm not satisfied with something I wrote, I'll never publish it; therefore, the wait is worth it, at least for my peace of mind.

About the entry, well, this is a new one in my now called "Ruby is waaaay more than web development" article series, in which I'm trying to raise awareness in the community that the Ruby language covers a lot more ground than just Web Development and its relation to the RubyOnRails framework. In this post we'll talk about Ruby and Machine Learning.

Proper Introduction: A Ruby Revolution in ML.

In the ever-evolving landscape of machine learning, a few programming languages have traditionally held the limelight – Python, R, and Julia, to name a few. Yet, nestled in the shadows, the Ruby programming language has been quietly proving its mettle in this domain. This article embarks on a journey to showcase the potential of Ruby in machine learning, highlighting disruptive gems that defy convention, offering illustrative code snippets, and delving into the depths of Ruby's internals for a comprehensive understanding.

While Ruby might not be the first language that springs to mind when it comes to machine learning, its attributes make a compelling case for its inclusion in the ML toolkit. Ruby's readability, elegant syntax, and developer-friendly environment pave the way for creative problem-solving. As we journey through this article, we will unveil how Ruby can step up as a worthy contender in the realm of machine learning.

Unveiling Disruptive Gems for ML's purposes.

1. Nyaplot: Visualizing Insights:

Nyaplot is a versatile gem for data visualization. It offers a collection of plots and visualization tools that are particularly helpful when exploring datasets and gaining insights. Nyaplot's interactive visualizations provide an intuitive understanding of data patterns and distributions.

require 'nyaplot'

# Generate some sample data
data = {
  feature1: [1, 2, 3, 4, 5],
  feature2: [5, 4, 3, 2, 1]
}

# Create a scatter plot
scatter = Nyaplot::Plot.new
scatter.add(:scatter, data[:feature1], data[:feature2])
scatter.show

2. Numo::GSL: Integration with GNU Scientific Library:

Numo::GSL seamlessly integrates Ruby with the GNU Scientific Library, enabling advanced mathematical and statistical computations. This gem is ideal for researchers who require specialized numerical functions for their machine learning projects.

require 'numo/gsl'

# Compute Bessel function
result = Numo::GSL::Sf.bessel_Jn(2, 3.0)
puts "Bessel function result: #{result}"

3. RubyFann: Neural Networks with FANN:

RubyFann leverages the Fast Artificial Neural Network (FANN) library to implement neural networks. This gem empowers developers to create, train, and utilize neural networks for various tasks, from classification to regression.

require 'ruby-fann'

# Build a simple neural network
fann = RubyFann::Standard.new(num_inputs: 2, hidden_neurons: [3], num_outputs: 1)

Real-life Application: The Sentiment Analysis.

Let's dive into a real-life application where Ruby shines: sentiment analysis of customer reviews. In this scenario, we'll use the Natural Language Toolkit (nltk) gem, Nyaplot for visualization, and Numo::NArray for data manipulation.

require 'nltk'
require 'nyaplot'
require 'numo/narray'

# Sample dataset of customer reviews and their sentiment labels
reviews = [
  "The product is amazing and exceeded my expectations!",
  "Not satisfied with the quality. Will not buy again.",
  "Excellent customer service. Very happy with my purchase.",
  "The packaging was damaged, but the product itself is good."
]

sentiments = [1, 0, 1, 0]  # 1 for positive, 0 for negative

# Tokenize and preprocess the reviews using NLTK
tokenized_reviews = reviews.map { |review| NLTK::Tokenization.word_tokenize(review) }
# ...

# Vectorize the preprocessed text using TF-IDF
tfidf_vectorizer = NLTK::Vectorization::TfIdfVectorizer.new
tfidf_matrix = tfidf_vectorizer.fit_transform(tokenized_reviews)
# ...

# Split the dataset into training and testing sets
train_data, test_data, train_labels, test_labels = train_test_split(tfidf_matrix, sentiments, test_size: 0.2)
# ...

# Build a simple sentiment analysis model using Numo::NArray
input_size = train_data.shape[1]
hidden_size = 128
output_size = 1
learning_rate = 0.01

weights_hidden = Numo::DFloat.new(input_size, hidden_size).rand
bias_hidden = Numo::DFloat.new(hidden_size).rand
weights_output = Numo::DFloat.new(hidden_size, output_size).rand
bias_output = Numo::DFloat.new(output_size).rand

def sigmoid(x)
  1 / (1 + Numo::NMath.exp(-x))
end

def predict(input)
  hidden_output = sigmoid(input.dot(weights_hidden) + bias_hidden)
  output = sigmoid(hidden_output.dot(weights_output) + bias_output)
  output
end

# Train the model using the training data
num_epochs = 1000

num_epochs.times do
  predicted = predict(train_data)
  error = train_labels - predicted
  d_output = error * predicted * (1 - predicted)
  error_hidden = d_output.dot(weights_output.transpose)
  d_hidden = error_hidden * predicted * (1 - predicted)

  weights_output += hidden_output.transpose.dot(d_output) * learning_rate
  bias_output += d_output.sum * learning_rate
  weights_hidden += train_data.transpose.dot(d_hidden) * learning_rate
  bias_hidden += d_hidden.sum * learning_rate
end

# Evaluate the model using the testing data
predictions = test_data.map { |data| predict(data) > 0.5 ? 1 : 0 }
accuracy = (predictions == test_labels).sum / test_labels.size.to_f
puts "Accuracy: #{accuracy}"

# Visualize sentiment distribution using Nyaplot
plot = Nyaplot::Plot.new
plot.add(:histogram, sentiments)
plot.show

Peering into Ruby's Internals for ML.

Delving into Ruby's internals can be enlightening. You know, Ruby is written in C, which means that understanding its internals provides insights into how it can effectively handle machine learning tasks. Although Ruby's primary design isn't tailored exclusively for machine learning, its extensibility allows developers to build libraries and gems that enable ML capabilities.

Memory Management: Ruby's garbage collector, a part of its internal C implementation, manages memory allocation and de-allocation. This efficient memory management is essential for handling large datasets and optimizing neural network operations during machine learning tasks.
C Extensions: Ruby's C API allows developers to write C extensions, bridging the gap between Ruby and lower-level operations. This extensibility enables the integration of optimized numerical libraries like BLAS and LAPACK, which are crucial for performing complex matrix operations common in machine learning algorithms.
Embedding Libraries: Developers can embed external libraries written in C or other languages within Ruby code. For instance, by embedding optimized linear algebra libraries like Intel's MKL or OpenBLAS, developers can significantly accelerate numerical computations within machine learning algorithms.
Interfacing with Gems: Ruby's C API allows gems to be developed with enhanced performance in mind. Disruptive gems like Numo::NArray and Numo::GSL can harness these capabilities to provide optimized numerical computations and integration with specialized scientific libraries.
Multithreading: Ruby's C internals provide mechanisms for multithreading, allowing developers to parallelize tasks such as data preprocessing, optimization, and neural network training, which are common in machine learning workflows.

Example: Matrix Operations.

Let's consider a simple example of how Ruby's internals contribute to efficient matrix operations, a fundamental aspect of machine learning algorithms.

require 'numo/narray'

# Creating Numo::NArray objects
a = Numo::DFloat.new(3, 3).rand
b = Numo::DFloat.new(3, 3).rand

# Matrix multiplication using Numo::NArray
c = a.dot(b)

In the above code, when performing matrix multiplication using dot, Numo::NArray leverages efficient C-level memory management and optimized BLAS operations. These optimizations are a direct result of Ruby's ability to interface with C libraries, showcasing how it can contribute to the language's prowess in handling machine learning tasks.

By utilizing C-level memory management Numo::NArray's dot method can perform matrix multiplications like the above, efficiently. This efficiency is crucial in machine learning, where matrix operations are fundamental to algorithms like neural networks and support vector machines.

Conclusion: Embracing Ruby's ML Potential.

Ruby's versatility and its growing array of gems make it an unexpectedly compelling choice for ML tasks. As we've witnessed, gems like Nyaplot, Numo::GSL, and RubyFann are pushing the boundaries of what's possible. By embracing these gems and even exploring Ruby's internals for extensibility, developers can unlock the language's potential in the world of machine learning. Ruby may not be the conventional choice, but it's proving its prowess in this evolving landscape. So, whether you're a Ruby enthusiast or a machine learning aficionado, Ruby's capabilities are certainly worth exploring further.

Exploring Genetic Algorithms with Ruby

RPA — Tue, 25 Jul 2023 04:15:20 +0000

Introduction:
In the quest to solve complex optimization problems and simulate natural evolution, computer scientists turn to the fascinating world of genetic algorithms. These algorithms mimic the principles of Darwinian evolution, and when combined with the expressive and elegant Ruby language, they become a powerful toolset for tackling a wide range of challenges. In this article, we'll dive into the intriguing realm of genetic algorithms in Ruby and explore real-life applications that showcase their potential.

Understanding Genetic Algorithms:
🧬 Genetic algorithms draw inspiration from biological evolution, imitating the process of natural selection, crossover, and mutation. At their core, these algorithms consist of a population of candidate solutions, evolving over generations to reach an optimal or near-optimal solution to a given problem.
Representation of Solutions:
In a genetic algorithm, each candidate solution is encoded as a chromosome, often represented as an array or data structure in Ruby. The combination of genes within chromosomes determines the characteristics of each solution.

# Example: Chromosome representing a sequence of cities in a Traveling Salesman Problem
class Chromosome
  attr_accessor :genes

  def initialize(genes)
    @genes = genes
  end
end

Evaluation Function: The key to genetic algorithms lies in the evaluation function, also known as the fitness function. This function assesses how well each candidate solution performs, guiding the selection process during evolution.

# Example: Fitness function for the Traveling Salesman Problem
def fitness(chromosome, distance_matrix)
  total_distance = 0

  chromosome.genes.each_with_index do |city, index|
    total_distance += distance_matrix[city][chromosome.genes[index - 1]]
  end

  total_distance
end

Selection Methods: Various selection methods determine which solutions have a higher chance of becoming parents for the next generation. Popular selection techniques include roulette wheel selection, tournament selection, and rank-based selection.

# Example: Roulette wheel selection
def roulette_wheel_selection(population, distance_matrix)
  total_fitness = population.sum { |chromosome| fitness(chromosome, distance_matrix) }
  selected = []

  until selected.size == population.size
    r = rand(0..total_fitness)
    cumulative_fitness = 0

    population.each do |chromosome|
      cumulative_fitness += fitness(chromosome, distance_matrix)
      if cumulative_fitness >= r
        selected << chromosome
        break
      end
    end
  end

  selected
end

Genetic Operators: Genetic algorithms utilize three fundamental genetic operators:
- Crossover: Involves combining genetic material from two parents to create offspring.
- Mutation: Introduces random changes in the offspring to maintain diversity.
- Elitism: Preserves the best solutions from the previous generation to ensure progress.

# Example: Crossover operator for the Traveling Salesman Problem
def crossover(parent1, parent2)
  crossover_point = rand(1..parent1.genes.size - 1)
  child_genes = parent1.genes[0...crossover_point]

  parent2.genes.each do |city|
    child_genes << city unless child_genes.include?(city)
  end

  Chromosome.new(child_genes)
end

# Example: Mutation operator for the Traveling Salesman Problem
def mutate(chromosome, mutation_rate)
  chromosome.genes.each_with_index do |city, index|
    if rand < mutation_rate
      swap_index = rand(0...chromosome.genes.size)
      chromosome.genes[index], chromosome.genes[swap_index] = chromosome.genes[swap_index], chromosome.genes[index]
    end
  end
end

Real-World Applications: Genetic algorithms have found applications in diverse fields, showcasing their versatility and problem-solving capabilities. Their ability to handle combinatorial optimization challenges makes them invaluable in real-life scenarios:
- Traveling Salesman Problem: Optimizing routes for delivery services or travel planning, where the goal is to find the shortest path that visits a set of cities and returns to the starting point.
- Job Scheduling: Efficiently scheduling tasks or jobs to minimize processing time, improve resource utilization, and meet deadlines.
- Network Routing: Optimizing data packet routing in computer networks to reduce congestion and improve efficiency.
- Evolutionary Art: Generating artistic images or designs through evolving populations of visual representations.
- Neural Network Training: Tuning the weights and biases of neural networks to optimize their performance for specific tasks.

Conclusion:
Ruby's expressive syntax and powerful object-oriented features make it an ideal language for implementing genetic algorithms. By harnessing the principles of natural selection, crossover, and mutation, developers can solve complex optimization problems and explore uncharted territories in their respective domains.

As you delve deeper into the world of genetic algorithms, remember to experiment, iterate, and adapt your approach to the unique challenges you encounter. Embrace the evolutionary spirit, and let Ruby be your ally in unleashing the untapped potential of genetic algorithms.

Happy genetic coding! 🤣

Crafting a Ruby Gem: Empowering Developers One Gem at a Time

RPA — Mon, 17 Jul 2023 04:47:36 +0000

Introduction:
Welcome to the world of Ruby gem development, where innovation and creativity intersect to bring new possibilities to fellow developers. In this article, we'll embark on an exciting journey, guiding you through the process of creating and publishing a Ruby gem that addresses a real-world challenge. Together, we'll explore the nuances and practical tips to make your gem shine, impacting the community positively.

Step 1: Finding the Spark: Ideation and Purpose.
Great gems start with a compelling idea. Identify pain points or missing functionalities in existing tools, or brainstorm new concepts that can enhance developer workflows. Focus on simplicity, reusability, and solving a specific problem.
Step 2: Unleashing the Potential: Setting Up Your Gem Project.
Initialize your gem project with the following structure:

my_gem/
├── lib/
│   └── my_gem.rb
├── my_gem.gemspec
├── Gemfile
├── Rakefile
├── LICENSE
├── README.md
└── ...

Use version control (e.g., Git) to track changes and collaborate effectively.

Step 3: Crafting the Gem: Code with Care.
Write the core functionality of your gem in the lib/my_gem.rb file. Employ Ruby's object-oriented principles, adhering to the Single Responsibility Principle (SRP). Leverage existing libraries and APIs when appropriate.
Step 4: Exquisite Craftsmanship: Tests and Documentation.
Create a comprehensive test suite using RSpec or Minitest to ensure reliability and maintainability. Write clear and expressive test cases for every feature.
Craft well-structured documentation using YARD to assist users in understanding your gem's purpose, installation, configuration, and usage.
Step 5: Honing the Gem: Refactoring and Peer Review.
Take time to refactor your code, ensuring it's clean, maintainable, and adheres to Ruby community style guidelines. Seek feedback from peers through code reviews, fostering collaboration and uncovering potential improvements.
Step 6: Embracing Versioning: Semantic Versioning.
Follow semantic versioning to communicate changes effectively. Increment versions thoughtfully to reflect the impact of updates on compatibility.
Step 7: Real-world Testing: Install and Test Locally.
Install your gem locally and test it in real-world scenarios to ensure a smooth user experience. Consider edge cases and collect feedback to iron out any rough edges.
Step 8: Sharing the Brilliance: Publishing on RubyGems.org
Create an account on RubyGems.org and use gem push to publish your gem. Craft a captivating description and include relevant keywords for discoverability.
Step 9: The Magic of Open Source: Engage the Community.
Announce your gem, sharing your journey, motivations, and the problems it solves. Engage with developers, address queries, and consider contributors to build a vibrant community!

Conclusion:
With passion, creativity, and dedication, you've crafted a valuable Ruby gem that empowers developers worldwide. As you embrace feedback, iterate on your gem, and foster an open-source community, your creation will continue to evolve, making a lasting impact.
Embrace the spirit of collaboration, celebrate diverse perspectives, and continue exploring the uncharted territories of Ruby gem development. Together, we'll shape the future of the Ruby ecosystem, one gem at a time! 💎 🚀

Getting Started with Jekyll: A Powerful Ruby-Based Static Site Generator

RPA — Sun, 09 Jul 2023 17:36:37 +0000

Introduction:

Jekyll is a robust and popular static site generator built in Ruby. It offers a simple yet powerful way to create static websites, blogs, and documentation sites. In this article, we will explore the fundamentals of Jekyll and guide you through the process of getting started with this versatile tool.

What is Jekyll?

Jekyll is an open-source static site generator that takes raw text files, written in Markdown, Textile, or HTML, and converts them into static websites. It eliminates the need for databases or server-side processing, making it an excellent choice for simple and efficient websites.

Key Features of Jekyll:

Templating Engine: Jekyll uses the Liquid templating language, allowing you to create reusable templates for consistent page layouts.
Markdown Support: Jekyll supports Markdown, which enables easy content creation without the need for complex HTML.
Front Matter: Jekyll utilizes YAML front matter to add metadata to your content, providing flexibility in organizing and structuring your site.
Built-in Development Server: Jekyll comes with a built-in development server, enabling you to preview your site locally before deploying it.
Plugins: Jekyll offers a vast ecosystem of plugins that extend its functionality, allowing you to add features like SEO optimization, analytics, and more.

Getting Started:

Prerequisites:
- Ruby: Ensure that Ruby is installed on your machine.
- RubyGems: Install RubyGems, the package manager for Ruby.
- Bundler: Install Bundler, a gem dependency manager.
Installation:
- Open your terminal and install Jekyll by running the following command:
```
 $ gem install jekyll
```
Create a New Jekyll Site:
- Create a new Jekyll site using the following command:
```
 $ jekyll new my-site
 $ cd my-site
```
Build and Serve Your Site:
- Use the following command to build your site and start the local development server. After that, you can access your site at http://localhost:4000 in your browser.
```
 $ bundle exec jekyll serve
```
Customize Your Site:
- Explore the directory structure of your Jekyll site and make changes to the configuration file (_config.yml) to personalize your site settings.
- Create new pages and blog posts in the _posts and _pages directories, respectively.
- Leverage Liquid templates to create reusable page layouts.

Conclusion:

Jekyll provides a flexible and efficient way to build static websites. With its simplicity, extensive community support, and vast plugin ecosystem, Jekyll has become a go-to tool for developers looking to create beautiful and performant static sites. By following the steps outlined in this article, you are now equipped to dive into the world of Jekyll and unleash its potential for your next project. If you want to dive more into Jekyll you can visit the official documentation site and look for more extraordinary things you can do with this amazing static-site generator based in our beloved Ruby language.

Give Jekyll a try and unlock the power of static-site generation for your web development needs. Happy coding!!!

Init.

RPA — Sun, 02 Jul 2023 07:28:24 +0000

Hey there!

I'm thrilled to have this platform to share my passion for programming, specifically when it comes to the enchanting world of Ruby. Here, I'll be taking you along on my personal exploration of the Ruby language, the Ruby on Rails framework, and the incredible development ecosystem that surrounds them. But that's not all – I'll also be sharing exciting updates about my side projects and shedding light on the impactful work being done by the RubySantaMarta non-profit organization and its events.

For as long as I can remember, programming has been a captivating journey for me. The elegance and expressiveness of Ruby have always fascinated me, and its ability to bring joy to the coding process is truly remarkable. Through this blog, I hope to share that joy and inspire others to embark on their own Ruby adventures.

Together, we'll delve into the intricacies of the Ruby language, from the fundamentals to advanced concepts. I'll share tips, tricks, and best practices that I've picked up along the way, helping you write clean, efficient, and elegant code. We'll explore the power of Ruby on Rails, uncovering how this transformative framework can be harnessed to build remarkable applications that make a real impact.

I'll also be sharing info about my side projects – those passion-driven endeavors that allow us to explore new ideas and stretch our creative muscles. I hope to inspire you to embark on your own side projects, unleashing your creativity and embracing the joy, outside the constraints of conventional projects.

Lastly, I am proud to announce the foundation of the RubySantaMarta non-profit organization. This is going to be the place to be for Ruby developers in my hometown Santa Marta, Colombia, but everyone around the globe will be invited to attend (personally or virtually) all of our events/meetups. Through this blog, I'll keep you informed about our initiatives and opportunities to get involved. Together, we can make a difference and contribute to the vibrant ecosystem we know only Ruby has to offer.

Make sure to follow me so you never miss a single post. Also, I invite you to connect with me on social media, where we can share our thoughts, exchange ideas, and engage in thought-provoking discussions.

Welcome!