DEV Community: Adrian Marin ⛵️

[Boost]

Adrian Marin ⛵️ — Wed, 13 Aug 2025 09:17:54 +0000

Lucian Ghinda

Aug 13 '25

More Than Code: The Friendships You’ll Build at FriendlyRB

Comments 1

1 min read

Delegated Types and and building the ultimate Kanban Board in Rails

Adrian Marin ⛵️ — Tue, 09 Jul 2024 08:44:38 +0000

We're getting ready to work on our Kanban Board feature. It's exciting as we haven't started a "big" feature in a while.

As we embark on this, we began to think about how to model the database around it. We have a couple of constraints within Avo's context, which makes it a bit more challenging.

1. We don't own the records/models that sit on the board

This is the ethos of Avo; the user can have Users, Products, ToDos, and any other kind of models added to the board. We don't own those models and can't dictate the design decisions around them.

2. We don't want to enforce database restrictions (or have as few as possible)

Another big feature of Avo is that you configure it with code and not by database rows. This is powerful because all your configuration is very portable across all environments. This means we don't ship any migrations with Avo and, again, don't impose database restrictions on you.

So how do we keep track of which item is on which board/column?

3. We want multi-item-type boards

We'd love to support boards that handle multiple item types, meaning you could have a User, a Product, and a To-Do on the same board and work with all of them as if they were the same item.

4. Make it as configurable as possible

We want this to be the ultimate Kanban board feature out there. Maybe not from the initial iteration, but still be able to easily add features as we progress.

How Do We Do It?

It's an interesting challenge, I think.

Initial Iteration

We first thought about the simplest use case. We would require the user to add a column to each record type in the database to indicate which column that record is placed in.

That quickly becomes problematic if you want that record in multiple columns.

User
- id
- name
- kanban_column # add this to hold the board it is on

This starts to look like Single Table Inheritance.

You also need to hold the position on the board. Adding another database column? What if you need to add another property? It starts getting messy really quickly.

Second Iteration

Then, we thought about holding the position and board information in a different table. This is great as it doesn't impact the user's database modeling. We can "do what we want there" and not bother the user.

User
- id
- name

KanbanItem
- record_type ("User")
- record_id (55)
- column ("In progress") # which column
- position (2) # position in the column

This is already better. But what does it look like? That's right! It looks like Delegated Types.

Delegated Types are a great abstraction for holding common data for multiple types of models. They have great heuristics and are proven and tested.

It checks all the boxes:

We don't need to apply any updates to the user's model database structure.
We can have the same record sit on multiple boards.
This future-proofs this feature so we can customize it as we want.

We still have a few things to look into and test out, but the "meat" of the feature is there!

How would you build this feature?

Originally posted on avohq.io

How to bundle assets in a Rails engine

Adrian Marin ⛵️ — Tue, 10 Jan 2023 18:29:35 +0000

During Rails' lifetime, we had a lot of ways to load, parse, and process assets. The "recommended" way is to hook into the asset pipeline (whichever that is) and, on deployment, let the assets:precompile task to take over and... compile them so they can be used in your app.

But, if you built an engine that you want to distribute to others, there might be a few things that might get in the way.

Asset pipeline cons

Let's say you're using jsbundling-rails and/or tailwindcss-rails with your distributable engine. To you, it's common to have all you need to compile those assets.
You'll have Node.js and all other external dependencies installed and ready to compile everything together, but the parent app that's using your gem might not. They might use importmaps, and they might not have all that Node.js infrastructure.

When the user pushes the Rails app with your gem installed, they might get the gem without any assets (because they haven't been built yet), or they might even get a crash that sprockets (or propshaft) can't find those assets.

But there's a better way!

Compile assets on publish-time

One approach we had with avo-hq/avo was to precompile the assets before we publish a new version and serve them as static assets to the parent app.

How do we do that?

The overview is this:

Set up build commands
Provide a way for the parent app to reach those assets
Run all the compilation commands
Package the gem up with those static assets

1. Set up build commands

You first install your asset handlers as you need them for your project. They can be anything from rails/jsbundling-rails and rails/tailwindcss-rails to webpacker or something custom.

Add some commands to build up those assets.
We have the following scripts inside the package.json file:

  "scripts": {
    "prod:build:js": "esbuild app/javascript/*.js --bundle --sourcemap --minify --outdir=public/avo-assets",
    "prod:build:css": "tailwindcss -i ./app/assets/stylesheets/avo.base.css -o ./public/avo-assets/avo.base.css --postcss",
  }

They take the source JS and CSS files, compile them, and move them to a public/assets directory.

2. Provide a way for the parent app to reach those assets

When you ship your gem, that public directory will not be public at all. It will be hosted somewhere hidden on that machine, so the browser will not have a way to reach them.

Let's use a Rack::Static middleware to the engine.rb file.

module Avo
  class Engine < ::Rails::Engine
    config.app_middleware.use(
      Rack::Static,
      urls: ["/avo-assets"],
      root: Avo::Engine.root.join("public")
    )
  end
end

Now, the parent app will re-route all the traffic from /avo-assets to that "hidden" directory where our compiled assets are.

3. Run all the compilation commands

When we're ready to ship our gem to RubyGems (or any other gems server), we should run the compilation commands to ensure all the JS and CSS files are compiled, minified, and packaged up how we need them to be in production.

$ yarn prod:build:js
$ yarn prod:build:css

4. Package the gem up with those static assets

We need to instruct the gem utility to add the compiled files to the packaged gem.

Gem::Specification.new do |spec|
  spec.name = "avo"
  spec.version = Avo::VERSION
  # more spec properties

  spec.files = Dir["{bin,app,config,db,lib,public}/**/*", "MIT-LICENSE", "Rakefile", "README.md", "avo.gemspec", "Gemfile", "Gemfile.lock"]

  spec.add_dependency "activerecord", ">= 6.0"
  # other dependencies here
end

The spec.files property knows which files should be bundled up. Finally, you'll see the Dir["{public}/**/*"] will add the whole public directory to the gem, including the avo-assets one.

Run bundle exec rails build to package everything up and profit 🙌

All you need to know about Rails engines

This post is part of a series I'm writing to share some of my learnings while building my own distributed engine, Avo.

All you need to know about Rails Engines

Why Successful Startups Use MVPs

Adrian Marin ⛵️ — Sun, 31 Jul 2022 14:15:48 +0000

Website building platforms like WordPress or Wix undeniably revolutionized the internet.

Why? For the same reason, a band like Green Day draws a festival-sized crowd in comparison to a jazz ensemble formed of professional musicians who studied music theory their entire lives. It is more easily accessible to the masses.

As long as the majority of people can understand the inner workings of a certain process - spanning from relating to the 3 chords an artist plays in front of them to build their own minimalistic website - they will be drawn to what they can achieve on their own. Relying on an expert in any field of work implies a bigger budget and a schedule you don't always call the shots for.

In the world of companies, a startup is the equivalent of an individual that starts something from scratch. They will need a lot of resources to evolve and they should seek any support they can get. The biggest support always comes in the form of cost- and time-efficient solutions for a business. This is the category an MVP falls under.

What are MVPs?

Dating back not too long ago - 2001 - the acronym has been coined, which stands for Minimum Viable Product. Before a product starts generating profit, its developers need to understand its market extremely well. They need to detect the most significant problems clients face and solve them. Determining what makes the problem significant is also what defines the product.

By using an MVP, developers can concentrate directly on the said problem, without pouring too many resources into a more advanced form of the product. It is more important to see if the product solves the customer's problem first. Then comes the consolidation.

For a business, efficiency is key. It is much more efficient for product development to take its course in tandem with customer research. This way, both issues, and solutions can be handled in real-time.

More precisely, an MVP is the skeleton of a human body, the outline of an essay, and the stage setup of a concert. It is the bare frame that bears the least number of features, focusing on only solving the most important one it was designed to solve. Since solving that issue is the focal point of an MVP, it needs to function perfectly in order to not create additional problems along the way while the infrastructure is still in its fetal stage.

Eric Ries - author of the book "The Lean Startup" - defines an MVP as the stage of a product in which as much client data collection is permitted, by undergoing the least amount of effort. It is the stage that helps a team understand how their product can start making money from that point on.
Some common MVP practices
To thoroughly understand what minimum and viable means when it comes to a product, it is helpful to look at some common practices that led MVPs to become successful. Six such practices come to mind:

Landing page
Media (video or animation)
Email
Piecemeal
Illusion
Concierge

Any product, regardless of its level of functionality, requires a brief description of what it does. Ideally, this information should fit on a landing page. Its main focus is to shine some visibility on the product. A customer's curiosity brings value to the product, which is what a founder should be initially seeking and feeding off of, to know where to go next. In this case, value is measured by emotional responses, meaning customers found some solace, thus making the problem more easily identifiable.

People have different learning methods. They are stimulated either visually, sonically, or creatively. If reading about a product still does not help them make the connections they need to understand a product, a video or an animation would be more useful. Brief as it might be, the essence of a product's function can be extracted and transformed - or edited - in moving images. After the emotional responses have been triggered, slap a call to action at the end of the video, and boom - you got yourself what is known as an opportunity in the corporate world.

It may seem old-fashioned but email campaigns are still effective. Granted, you need to build an initial contact list, but it only takes sending one email to test the waters and analyze the recipients' responses.
It would be nice to have some sort of demo version for everything we buy but are initially unsure of. Like testing a melon at a market, or taking a new car for a ride from a dealership lot. In terms of using this piecemeal approach for an MVP, a founder can extract what they believe to be the most important and useful features of a product that still make it viable on its own, limited as it is.

With a little pizzazz to collect user responses and create intent to buy, the development team doesn't have to go out of their way to make a functioning product that seems as easy to use as a demo version, but is really all there is to get the job done. In the beginning, this method requires a more "hand-made" tactic before the team can fully automate its functionality. Just to get the pulse and explore the potential buying power. Just until it gets too difficult to operate "manually".

If you have an e-commerce platform on your hands, the illusion (sometimes called Wizard of Oz) approach is ideal. While your company does not physically carry the products on the page, customers still need to be drawn to purchase them from vendors. Your platform is the one that draws them in, and that ultimately generates traffic to your page.

Your illusion game needs to be top notch…meaning you have to make the customers' buying experience one that they cannot find anywhere else. This can only be achieved by trial and error, constantly changing the way the platform looks and taking notes on when there's an interest growth spike.

Similar to the piecemeal approach, the concierge approach relies on manually operating a process before turning the operation into a product. In this case, manual operation refers to personal interaction with customers. Building trust the old fashioned way! After customers develop "feelings" for the way your company treated them, they will most likely stay on board after you automate the services as well.

How Can Startups Benefit from MVPs?

Does a customer really need your product? An MVP can provide the best answer.

There is no need to waste resources, effort, and budget before finding the answer out. A low-code version of the product's main functionality is all the customer needs to decide if they need it, and for you to decide whether you found your niche. This version can actually demonstrate your product's ability to the customer which generates the most important criteria for a business owner: validation.

The customer will explore the product thoroughly in order to test its validity. Although an MVP is a very basic version of the final result, it needs to work in all of the iterations that the customer is able to explore. This puts more pressure on the development team, but will take an insurmountable weight off their shoulders in the long run.

Customer feedback is crucial but not immeasurably important. Development team and management should not cling on to every single critique or feedback, but instead draw a conclusion in regards to what direction to take. After all, the big aim is to head towards product-market fit.

If your product is so innovative that it is unprecedented on the market, you may have struck gold! But as any pirate or miner will tell you, gold must be kept well-protected. Having first entry to market, your product may be so revolutionary that the market is not yet educated or prepared for the benefits it can generate. By using an MVP you can also gradually infiltrate the concept on the market before competitors find a better way to display the value of the product to potential customers.

An MVP allows a startup to reduce the risk of failure by spending less resources such as time and money. After all, this is the very definition of effective investment management. A smaller budget helps a team to focus on where the money is necessary and where it actually ends up helping. This implies simplifying demands, cutting out unnecessary tasks and expenses, and most importantly, being vigilant in getting an accurate pulse of the market.

As difficult as it may be to fathom, there are solutions on the market that tick all the boxes above. Languages and frameworks that support an MVP for as long as needed before the application takes off. One such useful programming language is Ruby on Rails.

Ruby on Rails: Doing the Heavy-Lifting For You

Two words that should titillate your interest: programmer productivity.

When it comes to syntax, language, and afferent suite of tools, programmers sigh with relief knowing that they can build faster and worry less about basic code and database structures. Numerous Silicon Valley startups such as Airbnb, Shopify, Github, Twitter, Hulu, Dribble, Kickstarter, and even Tesla have used RoR to expand within the market.

Instead of wasting your budget and your programming team's time for basic - but necessary - coding, by using Ruby on Rails they can get right to building the essence of your product, while you and your clients can observe the results much quicker and solve any issues on the fly.

Similar to frameworks like Java, Python, and PHP, RoR uses a model-view-controller (MVC) architectural pattern. The model refers to the logic of the application, the view represents the template files that result in the data's visual representation, and the controller is the connecting piece between the latter two. With the help of an MVC arch, the application logic is kept clean and applications become flexible.

Aside from MVC, RoR also relies on convention-over-configuration (CoC) and the Don't Repeat Yourself (DRY) principle.

CoC refers to frameworks setting "sensible defaults" so that programmers don't have to make every little decision, instead they get to focus more on building the actual application.

DRY prevents programmers from using repetition in their codebase, which makes files and functions easier to maintain, debug, and most important of all…understand.

Pros

It is important to note that an MVP is not a Beta version of a product. While Beta versions aid in finding bugs, user experience, stability, and reliability issues, they are meant for a group of tech savvy people known as Beta testers.

An MVP relies on the viable aspect by being able to function well for normal customers. The aim is for the customers to appreciate the value and understand how the product can solve their problems. It is necessary for the product to work well and impress potential customers by solving their outstanding problem.

So let's go over the pros of using Ruby on Rails one more time:

Takes little time to develop
Easy to read and understand
Free to use
Highly scalable
Secure framework
Helpful community

Sounds perfect, but there has to be a dealbreaker, right?

Cons

For startup CEOs, the cost might be the main con. While RoR is free to use, the few programmers who can develop a solid base will charge 100K + per year.

Even if you dispose of that kind of money, it is difficult to find RoR programmers on every corner. Since it is not the most commonly used language and framework, there is quite a niche of programmers that can even take on RoR-based projects.

Since these two aspects might be discouraging enough for a startup team to go through with using RoR, they may eventually slow down progress. Paying copious amounts of money and wasting precious time on fixing bugs and not understanding the needs of the market entirely are not efficient uses of resources. During this time the competition might prosper, rendering your product inferior or even outdated by the time it is finished.

Solution

Overseeing and successfully managing all the activities a startup implies is harrowing enough. And although they are paid for their efforts, even programmers would much rather concentrate on programming the main function of a product, rather than waste time in the "pre-production" phase.

Ideally, there should be a platform that is as easy to use as Wordpress or Wix. A platform that makes the process easy to understand and use for anyone. A platform from which you can choose RoR templates, features, resources, common actions (such as deleting a page or duplicating a page), an area where you can edit results, all the while the activity is transparent, easy to access for programmers, and works quickly and efficiently.

Such a platform is Avo.

Avo essentially takes care of building everything else that is not the absolute core functionality of the product. By using Avo, you don't have to allocate big budgets to developers to build the boilerplate.

You are better off using the fortune you save on basic infrastructure developing on other marketing practices to get your product in the hands of those that actually need it.

While your programming team concentrates on the core functionality, here are the ways you will be ahead of schedule on:

scouting the market
generating demand
creating supply
securing your place on the market (even making it indispensable)

All the while your competitors will barely be at step one.

In comparing the subscription-based Avo to a platform like Wordpress but for Ruby on Rails, it is also implied that it makes your production time at least 10 times more efficient.

No additional costs, no scouting for the ideal RoR programmer, just an app developed by programmers who have faced the same problems and developed a solution. A solution that will save you money, time, stress, and a lot of extra hassle to just turn your product into reality as quickly and effortlessly as possible.

Requirements for implementing an MVP

While some products are less likely to have an obvious and compact explanation for their value and functionality, others can be summed up in a basic elevator pitch. Regardless, there are some factors to take into consideration before deciding on implementing an MVP approach.

Aligned Ideology Within the Team

A team's first real test is coming up with the Proof of Concept (PoC). This usually resembles the final product, except it is just an early model. This is where hypotheses and outcomes are discussed and explored. Demonstrating the functionality of the product will ascertain the theory that lies behind it.

This means the team has to be on the same wavelength. It should be strong enough to not crumble during the brainstorming, documentation, and Lean Canvas phases. After weak assumptions are expelled and timing and presentation types are decided upon, the team will already have gone through enough consolidation phases to have a clearer purpose and work ethic.

After all, a healthy and unified team is the strongest type, as the results always show. An MVP is guaranteed to benefit from this type of collective attitude.

Additional Staffing

After the PoC phase, the team needs to start taking each following step of the product very seriously in terms of execution. A strong and effective MVP requires sophistication.

A team should look into adding to their staff as a necessary investment to their operation. Specifically, developers with knowledge of back-end technology, as well as front-end technologies.

Prototype Evolution

If a product works, it needs to be scaled up to satisfy mass demand. This means the architecture of information is crucial in setting the product's stability and scalability. The natural progression of a product should be:

Proof of Concept
Prototype
MVP

Without having to give up on quality, scalability should be kept in mind with each step forward. Every factor that plays a positive role in reliability should be kept from one stage to another, and improved upon.

MVP Construction

Finally, the actual building of the MVP. Based on initial interest and first experiences reported by users, the experimentation stage should be very advanced by now and the business model is on the verge of confirming or infirming initial theories. Namely, as a startup owner, you should have by now been able to tick the following boxes:

Market and customer segment targeting
Finding problems within customer segments and trying to find viable solutions
Offering your solution as having unique value on the market
Setting up communication and distribution channels
Setting up revenue streams and possible future collaborations
Assessing the costs - how much goes in and out to sustain the operation until it takes off

If your experimentation stage has undergone all of these (and afferent) bullet points, the team's path should be clear and ready to start integrating the MVP process.

Is an MVP a viable solution for your startup?

Since knowledge is the driving force behind the startup, it is also its kerosene until it takes off. An MVP is a gap. It helps a company turn knowledge into business.

By collecting customer data, a Minimum Viable Product aims to validate initial assumptions and hypotheses a team has when embarking on this startup trip, and turn them into a viable business model.

Before looking for external funding, startup companies have to be unified in the faith they have in their product. This can only happen by receiving customer validation: if one customer finds value in the product, they won't be alone. Thus the value will increase, and the faith will drive the team to gradually go "all in". A functioning product built with a minimum budget is exactly what fills that gap and what fuels the next exciting stages.

As a bonus - which can turn out to work in their favor - a team can also explore if there is any competition for what their product has to offer, and take notes on why customers are looking elsewhere after not being satisfied with those solutions. You could even be the first that presents this solution!

But in order not to jump ahead too much or even pose a threat to the existing market, an MVP also helps in maintaining balance and somewhat of a low-profile in its initial stages. Does your product relate to the potential an MVP serves? It depends on how far you are willing to take it, how quickly, and how much you believe in its success. The ball is in your court now.

Dynamically re-use & lazy-load page using Hotwire

Adrian Marin ⛵️ — Tue, 01 Mar 2022 15:31:11 +0000

This article was originally published on avo.cool

Hotwire is a fantastic technology that helps you build dynamic websites without thinking about JavaScript.

When we re-wrote Avo from VueJS to Hotwire, when it first came out, we had to think about how we could leverage it to our advantage.

One of the first things we did was to add dynamic turbo-frames around common pages.

For example, the ResourceIndex page is the page that usually displays the table with the requested resources (it shows the users on /users).
We knew that we could use that exact partial when we wanted to display the has_many association on the ResourceShow page but didn't know how at first. We could have extracted it to a partial and rendered it in the ResourceShow page underneath the record details, but the ResourceShow page would take a long time to load when you have many associations to one record.

We then came up with the idea to use a turbo-frame for that but still didn't want to use a partial.

Let's say we have User and Team models like so:

class Team < ApplicationRecord
  has_many :users
end

class User < ApplicationRecord
  belongs_to :team
end

The routes and controllers look like this:

resources :posts

get "/:resource_name/:id/:related_name/", to: "associations#index"

class BaseController < ApplicationController
  def index
    # if there's a query set up, use it, if not, set one up
    unless defined? @query
      @query = @resource.class.query_scope
    end
  end
end

class AssociationsController < BaseController
  def index
    # find the parent record and set the query
    @query = @parent_model.public_send(params[:related_name])
  end
end

So what happens there? When a user goes to /users, they will see the list of users, and if they go to /teams/TEAM_ID/users, they should see the same list of users but scoped to the respective team.

In order to achieve this using turbo-frames we'll add a lazy-loaded turbo frame on the RecordShow page with the src attribute set to the association path with the ?turbo_frame="has_many_users" param added to the path /teams/TEAM_ID/users?turbo_frame="has_many_users" url.

<!-- views/base/show.html.erb -->

<!-- record details here -->

<!-- association details below -->
<turbo-frame id="has_many_users" src="/teams/#{@team.id}/users?turbo_frame=has_many_users" target="_top">
  <!-- Loading state -->
</turbo-frame>

Next, we should add a dynamic wrap around the index.html.erb partial like so.

<!-- views/base/index.html.erb -->

<% if params[:turbo_frame].present? %>
  <turbo-frame id="<%= params[:turbo_frame] %>">
<% end %>

  <!-- The list of records -->

<% if params[:turbo_frame].present? %>
  </turbo-frame>
<% end %>

What happens is that when the user loads a teams Show page /teams/1, that page will display with the lazy-loaded frame (so no impact on the performance of that page on load), which in turn, loads the association Index page with the turbo_frame param. That will add the <turbo-frame id="has_many_users"> tag around the template allowing Turbo to replace the content dynamically on the page.

We're re-using the actual index.html.erb template and the BaseController#index action.

Of course, this can be improved using some helpers and a partial.

# app/helpers/application_helper.rb

def turbo_frame_wrap(name, &block)
  render layout: "partials/turbo_frame_wrap", locals: {name: name} do
    capture(&block)
  end
end

<!-- app/views/partials/turbo_frame_wrap.html.erb -->

<% if name.present? %><turbo-frame id="<%= name %>"><% end %>
  <%= yield %>
<% if name.present? %></turbo-frame><% end %>

<!-- views/base/show.html.erb -->

<!-- record details here -->

<!-- association details below -->
<turbo-frame id="<%= turbo_frame %>" src="<%= frame_url %>" target="_top">
  <!-- Loading state -->
</turbo-frame>

<!-- views/base/index.html.erb -->

<%= turbo_frame_wrap(params[:turbo_frame]) do %>
  <!-- The list of records -->
<% end %>

You can do the same thing for Show pages too. We did with Avo.

You can find a more detailed example on Avo's GitHub repo.

Stay cool and improve performance 💪

avo.cool/
avo.cool/repo
avo.cool/feedback
avo.cool/try