400+ Rubyists got together and shared ideas and visions. They exchanged opinions and presented the past, present, and future of Ruby.

I went to very few talks (lately, the hallway track is the one that's getting most of my attention) but was impressed (no surprise there) by Vova's talk "Rails X". He did such a good job going through the current state of Ruby tooling, highlighting some areas where we need to pay a bit more attention to detail. I love the whole vision and how he showcased our community members and their work.

Avo was there too. Paul and I prepared a cool booth where quite a few guests came to learn more about Avo, see demos, and talk through issues or problems they'd encountered along the way. We brought Romanian chocolate biscuits and chocolate, and showed off the new design which we have ready for the next release.

The venue was pretty eclectic too. Fort Mason is a former military fort now administered by the National Park Service (we even shot an impromptu podcast interview). The event had some cool surprises like a space where you could get your t-shirt screen-printed live in front of you, a secret room where you could play games using Ruby, and the Ruby Embassy with its event stamp. After collecting that one, you could visit the sponsor booths to get extra stamps.

After the event, there were several activities set up. AngelList held a hackathon at their HQ, some went for a swim to Alcatraz in the morning, and some (like myself) rented e-bikes and took a ride around the waterfront, across the Golden Gate Bridge, and into Sausalito. It's a tour I won't forget anytime soon.

But the most important thing that happened at SF Ruby was the statement it made.

If you've crossed paths with me and we've gotten deep into conversations about Ruby, Rails, and the current state of affairs, you've probably heard me talk about the "One Thousand People Framework". Don't get me wrong, I love the "One Person Framework" approach. It enables small teams to be incredibly nimble and ship value at an unprecedented level. There are so few frameworks and ecosystems out there that can do that.

While this tagline helps a lot with adoption at the bottom of the funnel (single developers and small teams), I don't think it does justice to larger teams (100 people or more). Those companies where tech stack decisions are taken with much larger considerations in mind. Where they ask questions about what support exists at that scale.

I know what you're thinking: "Why should I give a damn about that?", but I'd say it's more important than ever nowadays.

It's important because these huge companies have the manpower and resources to actually push the language and framework forward. They're the ones that can fund 40-person teams to improve Ruby and Rails like Shopify does. Without Shopify, Ruby and Rails would be worse off.

Another big idea I stand behind is that optics matter.

It matters what we put out there into the world. It matters what we say and how we frame things. It matters that Ruby looks like a viable solution going forward for new developers and brings them opportunities. Same for companies who haven't made their bets on their tech stack yet.

And I think this is what happened at SF Ruby last week.

SF Ruby made a statement: that Ruby and Rails is still alive and kicking, powering big and upcoming companies. The new generation of Shopify-level companies. Companies like Chime, Bolt.new, Intercom, Gusto, PlanetScale, and others. SF Ruby showed that Ruby and Rails is still powerful in the Bay Area and around the world.

And that's one of the most important things that could have come out of this event.

Irina, Amanda, Anton, Steven, Ken, Cameron, Garry, and the rest of the Evil Martians and organizing team did an incredible job putting on a swanky event with small-conference vibes but big implications. Thanks everyone for the fantastic job you did

I hope to see it organized again and again for a long, long time.

We're taking a break with Friendly.rb. We had three beautiful editions, incredible fun, and learned so much in the process. This happening changed us, the hosts in ways we could not imagine. We're taking a break because things have happened in our lives that require our focus.

A thought sprouted

Let me paint you a picture.

It's late 2022. I went to Wroclove.rb, and was mesmerized by the community and the event. I learned about RubyConferences.org and was checking it out to see which was the next event I could go to. Sadly, there were almost none in Europe. Rails World wasn't a thing. Euruko and Brighton just came back after a break. Immediately my mind started working. "What if I put on an event like that?" "Would I be able to do it?"

A conference was born

I started contacting conference organizers. Andy was the one of the first. I can't tell how much that call changed the course of Friendly. Andy taught me about the diversity problem in events.

He taught me that being the biggest event by number of attendees may not be the most important metric of a successful event. But most importantly, he opened my eyes that I could make any kind of event. I could make the event that I wanted to attend. That made it so much more appealing to me than anything else 🙌

Assembling the team

By then I had a group of friends with who I had weekly calls with for about a year now. People nowadays call it a mastermind group, but we were not masterminding anything, relly 😅 It was a support and accountability group with a big focus on the Ruby community.

I had Avo and Lucian was just starting Short Ruby Newsletter. We've had conversations before about putting on an event in Romania, but had no real catalyst to get started

I pitched the idea and everyone was pretty much on board with it from the get go. So we started brainstorming.

The first thing we needed is a name. "What should we call it?" "Bucharest.rb? Romania.rb?" We probably had weird proposals like Carpathians.rb and others. We did check Balkan.rb but that was taken 🫣 Balkan.rb was on a sabatical at the moment too.

So I proposed the idea "How about we call it Friendly.rb? It would just set the tone of the whole thing 🙌 We call it Friendly, we will be friendly, and hopefully friendly people will come.", I said not knowing exactly how important that would become. That day we were set on the name. We got in touch with a designer and went with our Romanian folkloric motifs and quickly spinned up a website and released ticket sales.

Speakers

Remember the diversity talk I had with Andy? I took a big mental note of that. We wanted to have a very balanced mix of speakers form all facts of life, all genders, some well-knownk and some just starting out.

I was always afraid that we wouldn’t be able to have a great line-up every year. But I think we managed to do that.

We were very lucky to have had so many fine folks speak at Friendly. Thank you Xavier, Elena, Jeremy, Jason, Naijeria, Nick, Rosa, Tom, Greg, Irina, André and the rest of the speakers for coming all this way to speak. I know for a fact that many people came to see you, not us.

Why we're taking a break

Many are asking "Why?". The reason is pretty simple: Life changed for us.

Jakob moved to Germany. During the time I know him he moved to different cities three times. He just loves trying out new things.

Stefan moved up the career ladder and is increasingly more busy and has less time to focus on Friendly stuff.

Lucian is busy as well with Short Ruby. His work requires more of his time and the slice of free time he has is split between family and other things (Friendly is in the "other things" slice).

I now have two wonderful kids. One of which is a boy toddler who doesn't care about anything and anyone in this world. His latest passion is to be naked all day and pee in the grass "like a dog". I have the business I want to further focus on and doing Friendly takes away much of that focus.

So our priorities changed.

It takes a lot of focus

During these past three years I stopped speaking about how much time Friendly takes from us to happen and started talking about focus, because focus is much more precious than time.

Speaking about time, I estimate that in the first year it took at least one and a half months of my productive, work-related time to make Friendly happen. You read that right. One and a half months. Maybe more, I don't count my hours.

The second year a little bit less, and probably the last year, less.

In '25 I left my kids and wife at my in-laws (where we spend some part of the summer) for about three weeks before Friendly to come to Bucharest to finish up Friendly. That proved out to be more difficult, emotionally, than I anticipated.

But anyway... Focus is the thing that I lost. Because I wanted to make a more-than-nice conference and wanted to offer our guests an very welcoming experience I knew that I wanted things in a certain way.

I wanted the swanky venue. There was no way I would compromise in a boring hotel lobby or corporate building.
I wanted a great video crew. I wanted to capture the talks that were happening on stage but also the vibe off-stage too, and I wasn't going to leave something that important to chance or to an un-experienced crew.
I wanted our guests to experience much of that Bucharest has to offer. We started organizing guided walking tours after the next day.
I wanted a great after-party. I wanted everyone to eat and drink.
I wanted the off-conference time to be spent nicely in the city so we prepared a list of attractions, food, drinks, and coffee places for folks to go to, meet and hang out.
I wanted to have quirky talks so we had talks about where the Roma people came from, Mental health, and plenty of SaaS.
I wanted to have special activities like Jakob's game show (all props go to Jakob for that), Lucian's Coffee demo, and Julian's Music and game building with Ruby talks.
I wanted to show folks our mountains, so every year, on day three we got on a train in the morning, went to the mountains, visited a castle, had some local food, and got back in the evening.
I wanted everyone to leave with a smile, (at least) a new friend, and them believing they've been seen, heard, and appreciated.

All of that takes time and focus. Someone has to make sure every second that those things will happen. Every event organizer know most of the time you have multiple touch points with every vendor. You need to check up on them. You need to ask for details. You have to ensure things are happening in a certain way.

We don't have managers at Friendly. No hierarchy. If you have an idea and want to have something happen, you go out and do it. You might have a review (in the form of me and my opinion 😅), but if you have an idea, you have to implement it yourself.

To cut it short... it takes a lot of time and focus to ensure things go properly and people feel welcomed.

What about passing the baton?

We thought about "giving" it to someone else, but that's not the profile of the conference. We wanted to make it our way. I'm not sure that anyone else could do it in that way.

Don't get me wrong... someone else might do it better than us, and that's fine, but just not in our way. I would very much prefer having three editions that rocked and it's done rather than have two era's with different types of polish and different vibe. We didn't want Friendly to be that rock band which didn't age ok and still tries to "rock on" when they should just retire gracefully. I'd rather us remember Friendly for the incredible happening that it was.

The event where everyone hugs when they meet.
The event where smiling is not mandatory but happening.
The event where people come to create connections.
The event where folks feel like at home.

Sponsors

I want to take a moment to thank the sponsors.

And I want to urge you to go out and say thank you yourself to them. Seriously, when you meet anyone from a company that you see sponsoring events, go to them and say "Thank you for sponsoring our community!" That's it! It's going to make their day better and make them do it more. Only with their help we will be able to continue to put on these events and make the community better.

Without them we would not have had the funds to add this level of polish to our event or be able to create that warm environment for everyone to connect.

So thank you Andy Croll, Flagrant, Nick Sutterer, Softia, Evil Martians, 2Performant, Prowly, RoR vs Wild, Sibiu IT cluster, Wolfpack, ClickFunnels, Typesense, Stripe, Buzzsprout, Bitzesty, Trmnl, Agile Freaks for all your work and investment.

Ruby Triathlon

This is something that happened naturally, and not planned. I hope some other event comes and fills the Friendly slot in September. I hope it will carry the torch and be the island of friendlyness and small-conference-vibes between the giants like Euruko and Rails World.

The Ruby Passport

We got something very powerful out of all this conference planning and attending. We have the Ruby Passport. An in-real-life way of keeping track of the events we visit and connecting with our community. For now it's a physical mock Passport which you can stamp at each conference and claim digitally on rubyevents.org

There's plenty of work to be done there and it's an open-source project so let's meet on the repo and make this community even better.

Future plans

Many ask me if we want to pitch for Euruko. My answer is "No!" We ran a great 120-140 people event. I'm not sure we want or are ready to run a 500-600 people event. So no "Friendly Euruko" anytime soon.

We're going to take a break. Personally, I want to see if I get the itch to do it again.
More importantly, I want to wait until I have the time to do it.
I want to feel "bored" again, and think to myself "I have some spare time. What should I do next?"

We will meet at future events for sure!
Please come and day "Hi!"
I'm genuinely happy when new folks approach me to do that.

Outro

Friendly has been a transformational event for me. I learned a lot about Ruby, our community, sales and marketing, about what matters to people and how to approach them, but most importantly it helped me create this connection with our community like I could have not be able to do differently.

Thank you Lucian, Jakob, Stefan and Alex for bringing this vision to life.

Thank you sponsors for making this possible.

But most importantly I want to thank our guests for coming and being so warm and friendly.
Without you, Friendly wouldn't have happened like it did.

I hope we inspired others to go out there and do something outlandish. I hope others will want to organize the conference they would like to visit. I hope we will get other islands like Friendly.

Friendly is going to be heavily imprinted in my memory and caracter forever.

Thank you 🥹

Balkan Ruby is one of those events where I feel like at home. It might be the proximity to my country and all of that but I have a feeling that the people have something to do with it.

The theme this year was "For the long term" so the talks were about that.

Andrey started the conference with a very great conversation-starter talk about coding with privacy in mind where he outlined how our personal data can be so easily linked together from different sources, so the easiest way to protect the data is to not record it.

Pawel who started building apps "since the last century" showed us that even an "old dog" (sorry Pawel) can learn new tricks.

He openly admitted in front of a bunch of developers that he vibe codes from time to time and he enjoys it. Them proceeded to demo a voice-operated dog that listens to commands. What's that all about?

Bohzidar, after about 10 minutes of jokes and puns spoke about the beginnings of Ruby and how it influenced the whole programming community from Homebrew and Markdown all the way to how modern package managers work. It was quite a crazy story.

Yaro’s talk was about how AI is influencing our developer lives, about how it can help in the day to day work and most importantly why each one of us should pick it up so we are not left behind.

Julia had a very nice talk about how they do things at Harvest. She talked about the Rails pre-1 version codebase, the Delta Force team but also about a few "this is the last things, I promise..." 🤨 other ways she improves the codebase and why we leave the codebase better than we found it.

Jeremy gave an incredible overview about how he escaped limbo and refactored two of his projects with the utmost precision. Almost made me feel bad about my coding techniques 🫣

There were other great talks that covered mental health, coping, improving and just having a better outlook on the work-life balance.

I really can't recommend it enough that you go and watch the videos when they'll come out.

The theme was "For the long term" but the hallway conversations were around AI.

"Why, why now, why me, should we, will we, will it" and so much more questions around that.

I loved that the conversations went in both directions ranging from "I'm not using it", or "I don't like it", to "I use Cursor" or "Windsurf is better", all the way to "I really tried vibe coding and I think there's something there."

I gained a lot of perspective on where things stand and where they are going so if you want my take on AI and coding... definitely use it! It's a whole spectrum between "vibe code all the things" to not using it. First use a smart IDE like Cursor and then try a bit of vibe coding to build boring stuff like bash scripts, tedious tasks or even prototypes to get a feel for how the project could look like.

We didn't just attend Balkan Ruby, but we made a whole thing about it.

Me and Paul did a few days of in-person retreat, where we spoke about the future of Avo and did a bit of coding alongside that.

We also were in the position to sponsor the drinks 🍻 for the entire conference which was so rewarding.

Balkan quickly became that event where we could go, hang out, make plans, execute, but also connect with the community, make new friends and learn in the process.

Genadi and the team did a great job this year too. I hope they continue that for many more years to come so if you're looking for a cool event in the spring, definitely think about visiting Balkan Ruby.

Tropical.rb was a surprise to me. The Brazil Ruby community was surprise too! They are more than welcoming; they go out of their way to make you feel at home.

So many friendly people came together to celebrate Rails at LATAM's largest Rails conference, and what a celebration it was!

The talks

The best speakers you can think of came together to share their experiences with the audience.
The talks were about all that's trendy and relevant now and probably some things that we'll hear about in the future. We've had talks that eloquently taught and reminded folks about how to write clean code and refactor technical debt, talks about how to give back to the community and keep Rails going for 100 years from now, but also about internationalization, semantic search, async Rails, and red-black trees (whatever those are). Hotwire and Turbo Native had their spotlight on the stage, as did WASM, Kamal, Thruster, and Propshaft.
I felt a bit out of place with my "How to build a business on Rails and Open-Source" talk, but the reactions and conversations I had afterward confirmed my suspicion that more and more Rails developers want to break out of the nine-to-five job and try something new.

We also had a great AMA session hosted by Robbie Russel with Amanda and Bruno Miranda. So many valuable ideas came out of that conversation that I would suggest everyone watch when it comes out.

Organization

The organizers did a splendid job of ensuring everyone had a good time. You could see the smiles on everyone's faces. They had surprises for the attendees, one after another.
Even if we didn't stick to the schedule, no part of it felt rushed. We all wanted to be in it and enjoyed the experience.

I made friends

On a personal note, I made friends. So many new and close friends. Close to my heart but far geographically.
But it's okay; I have a hunch that we'll see each other again and relive all that we felt in São Paulo.

I also met many online friends from Twitter and Discord in person, many of whom were with me on my journey with Avo.

Thank you!

Thank you, Cirdes, Débora, Juliana, and Rafael, for hosting this incredible celebration of Rails. I know it was scary and risky to bring back Tropical. rb after all these years, but it was all worth it!
Good job!

But I want to thank the wonderful Ruby community in Brazil and LATAM, which made me feel like I was home when I was so far away.

This community rocks!

PS: You can follow my "live-tweet" session here.

This is just a testament to how vibrant and healthy the Ruby community really is.

The conferences

Wroclove.rb started the season on September 15th in the beautiful city of Wroclaw, Poland.

Euruko 2023 happened between 21-23 September in Vilnius, Lithuania.

Friendly.rb was next on the 27th and 28th of September in Bucharest, Romania.

Rails World happened on October 5-6 in Amsterdam.

Rocky Mountain Ruby happened at the same time on October 5-6 in Boulder, Colorado.

Ruby Conf Thailand quickly followed on October 6-7 in Bangkok, Thailand.

The Triathlon

I was able to attend Euruko, Friendly.rb, and Rails World, alongside 8 other cool folks. We jokingly named ourselves "The Triathlon Nine". It's silly, I know, but we did it anyway.

Euruko

I was in contact with Ali and Sergy for most of the past year and I know how many hurdles they had to overcome to make this event a reality.

Euruko is a traveling event organized annually, every year in a different European city chosen by the participants. It has a legacy from 2003 and it has to be just right.
I think they did it right.

The venue was pretty cool, the Technical University of Vilnius. It was mainly one large track with a secondary stage for sponsors, and others that wanted to present their work.

This year's edition also introduced an unconf format where participants submitted talks and then voted on who they wanted to see on stage. I was super happy to get the chance to talk a little bit about internal tools, and Avo.

The talks were pretty varied with guests from all over the globe.

Another cool surprise was a talk from Matz delivered through video and a live discussion panel, live from Japan.

After the first day, we had a train waiting for us at the train station to take us to a nice brewery where we partied, courtesy of Appsignal. You heard that right. A train full of Ruby developers (on rails)... pun intended.

I met many cool folks and put some faces to those Twitter profiles.

Friendly.rb

This is very dear to my heart because I am one of the hosts. I and my co-hosts worked for the better part of the last year to ensure this first edition is going to be memorable.
We knew that all eyes were on us.

The venue was incredible. Apollo 111 is an independent theatre with an adjacent bar. Just perfect for what we needed. Located in the heart of the city close to many food places and the Old Town.

The photo and video crew are professionals. I chose them because they do events much bigger than Friendly.rb. I wanted to ensure that the quality of the deliverables was top-notch.
The photos are available on Flickr, and the videos are coming soon.

The line-up was sublime! We managed to do what we wanted and have famous speakers and bring newcomers to the stage. Xavier Noria, Elena Tanasoiu, Jeremy Smith, Jason Swett, Nick Sutterer, Tom de Bruijn, and Ayush Newatia were gracious enough to accept the invitation to speak.

The talks were various from Ruby, to general tech, to non-tech, mental health, and even a cool talk from Julian Cheal where he did a live-coding session producing music on stage.

The attendees had plenty of break time to talk and create connections which is the most important thing we wanted to achieve.

Rails World

Rails World was more of a festival than a conference. Amanda and the organizers went all out. The venue was stunning! The swag was great, the sponsor booths were nicely designed, but most importantly the attendees were very passionate about Rails.

If there were such a thing as "The Oscars" for Rails, then Rails World would have been it.

There were many famous folks from the Rails community and most of the Rails core team was there.

The conference started with DHH's keynote where he spoke a little bit about the past and the future. He showed a sneak peek of Turbo 8, Strada, Kamal, and a few other things.

Next came a good round of talks going a little more in-depth with all of the new goodies coming soon. I personally can't wait for the new morphing feature coming to Turbo 8.

My buddies Yaro and Marco also took the stage to speak about the future of Hotwire, show off some tools, and a few cool techniques.

There weren't many after-party activities planned by the organizers but Amsterdam has plenty to offer. Somehow... most of us ended up at the Beer Temple. If you were there, you know what I'm talking about.

Next up

I'm still looking forward to Helvetic.rb on November 24th to properly close off the Ruby Conference season.

This has been an amazing year with many travels on my part. I met wonderful folks and made new friends which I will miss until next year.

One thing is for sure. The Ruby and Rails community is not dying, but witnessing a renaissance with new tooling, new events, and new talent.

But let’s rewind for a sec. It’s June 3rd, and I just returned from Rails Saas in Athens. We had three amazing days of talks, tavernas, and island hopping, all with meeting new folks. I’m saying meeting new folks, but what I really mean is putting a face on people that I already knew from Twitter or GitHub. Folks like Marco Roth, Julian Rubisch, Kasper and more. I’m not going to go too much into how that conference was and will leave Peter’s article, which sums it up really cool.

So it’s still June 3rd; I’m at home, decompressing, and remembering the good times, and the thought that pops into my head is, “I want to do this more”. Friendly.rb and Rails World are pretty far away in the fall, so the next best thing is Brighton Ruby. I didn’t know too much about Brighton Ruby other than it’s organized by Andy, which is all the branding you need. I feel that everything he does, he does it with style and showmanship. So I got into some negotiation with my wife, which is the real superhero in this story, for taking care of our 8-month-old while I’m off; but she’s amazing, said, “of course, go for it!” and I got the tickets and made arrangements.

Brighton Ruby

Going to a conference alone might be daunting if you’re an introvert, but I knew I wasn’t alone. I knew Andy, and I was sure he would shake my hand if I bumped into him, so yeah… I know one person there.

I started the day by walking to the Brighton Dome, which is an incredible venue for a conference. The city is as British as you can imagine, with beautiful low buildings and delightful tiny streets.

I got in, registered, and quickly saw many familiar faces. Some I knew in person, and some just from online. Of course, I bumped into Andy, but he didn’t shake my hand but gave me a very heartwarming hug which really uplifted my spirit and confidence.

The talks

The day started with the classic Andy welcoming, introduction and the history of the conference, and pointing out that this is a space where all should feel safe and welcomed. I can't express how important it is that the organizer mentions that and sets the tone of it.

Eileen started the day with her incredible talk about the Magic of Rails. I’m saying incredible because she touched on a few key aspects, like why the Rails internals are sometimes complex just so we can benefit from the best public APIs we can have, how all Rails’ gems fit together, how they are initialized, and how we should hook in and extend it, and about how the core team is organized and how they work on it. I truly feel that this talk should be seen by all Rails developers at some point of their careers. It explains so many things.

Schwad was next with his Brighten Ruby ”Scarpe diem” talk, where he so delightfully demoed Scarpe, built a fake virus for grandmas, and made all of us talk about it on the breaks.

Kaitlyn Tierney gave one of my favorite talks of the day on a subject that is very close to me. The librarian’s guide to documentation. So many good tips there about writing, maintaining, and pushing your team to create documentation for public or private products. If you ever see her in a lineup at a conference, go see her.

Noah Gibbs was next with his incredibly cool hand-drawn slides about “When not to use Rails”. This talk also hit hard with me because I am also in the “right tool for the right job” camp. This wasn’t just a theoretical talk but had actionable bullet points about when to use it or not, and what to worry and not worry about.

After a quick break, the lighting talks started with a cool presentation about how Ruby evolved in 20 years which will put things into perspective, a quick lesson into what "Job Smearing" is, Five things Hana loves about Ruby, The front-end and UX, and a quick demo into how to write a Rubocop rule.

One of the most impressive and courageous talks was displayed by Tim Riley, with singing, dancing, and presenting the history of Ricky Martin and his song “Livin’ la vida Hanami Loca”. This wasn’t just a “Here’s Hanami, and here’s how to use it” talk, but a very lean and organized introduction into why, and how other frameworks do it and that it’s not a competition. We’re seeing that pattern again of using the right tool for the job. Nice one, Tim! I heard many folks speaking about how they just wanted to go back to their hotel and write Hanami for an hour or two.

We had a quick Ice cream break, and Nadia Odunayo came to the stage to tell us about her Ruby mystery story, “The case of the vanished variable”. This wasn’t a presentation, but a funny modern tale that we all needed at that point in the day.

The day was wrapped up by Joe Hart, who told us about how he likes to spend his time going to conferences and creating Massive Local Multiplayer Games that he can play with the entire audience. We played Super Ruby Bros using our cheers, debugged some code live, and a cool game of Pac-Man together which ended up in a crackle of laughs when someone in the audience exploited the game live. No code was harmed during that talk.

You can see more of the talks in my attempt at live-tweeting from the event.

It’s worth mentioning that Brighton Ruby is a conference full of showmanship. If you’ve ever seen Andy, you know what I’m talking about. All speakers really put on a show, not just come there with some slides and start talking. It’s something that all conferences need.

The socializing

We had a quick socializing session at the venue that turned into breaking out into groups and taking to the streets of Brighton to find a place to have dinner and a drink.

That’s the time at the conference when you should find the folks that are by themselves, take them into your group, and go have fun.

This is when friendships are made. I spent most of the evening having good times with Julian, Mario, Alessandro, Marco, and Alex, and ended up closing our last bar for the night with Benoit and Stan Lo.

On the second day, Jonathan was very kind to invite us to a SaaS founders meetup at the Skiff, the coolest co-working space in Brighton. I got plenty of good advice from him and the other founders there.

We then went to have lunch, went antique hunting, checked out the pier, and just lost ourselves in the wonderful city of Brighton.

Of course that after our Tonkotsu ramen dinner, we ended up in a bar where we talked about indie businesses, open-source, and product development, and did a bit of bikeshedding; developers being developers.

Closing thoughts

Overall, a fantastic event, with great people, in a very beautiful city. Brighton Ruby is an inspiration and should be on every person's list at least once. See you there next year!

—

If you enjoy conferences and can’t wait until next year, we're hosting Friendly.rb, a cozy, boutique, Ruby conference in Bucharest, Romania, in September.

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:

1. Set up build commands

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

3. Run all the compilation commands

4. 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

If you didn't launch it, you made it fail! You never gave it a chance!

Give yourself an hour to put it online, post it in a few relevant communities, and get some quick feedback.

That's it! One hour, not the whole glorious vision of the perfect product that you have in your mind.

Depending on the product, here are a few places where you can post it:

➡️reddit
➡️Twitter
➡️Twitter communities
➡️GitHub awesome lists
➡️LinkedIn
➡️Schedule a quick product hunt
➡️Discord servers
➡️maybe Quora
➡️think about adjacent industries and where those users hang out
➡️retweet this article with your product launch

In the following weeks, monitor those posts, and the feedback coming in and draw some conclusions. You'll probably get a lot of "this is not useful" feedback. Try to get in touch with those people and ask why they gave that feedback. You'll learn a lot about the industry/niche you're trying to enter and whether it's worthwhile to keep working on the project.

Two things can happen:

1. You end up with good feedback to continue the work and turn it from a project to a product

2. You'll shut it down and still feel good about making, launching, and showing it to the world

These are both successful outcomes. Keeping it in the bottom drawer is not.

Go and put your product out there 🚀

If you like indie dev content, follow me on Twitter at [@adrianthedev](https://twitter.com/adrianthedev)

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:

1. Proof of Concept
2. Prototype
3. 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.

We've had a crazy marketing week 🎉 The biggest public launches yet.

A week before, I planned a Product Hunt but didn't launch it because… I was lazy.

On Tuesday, I finished the work on the Product Hunt campaign and set it to launch on Thursday. I prepped a discount code, told my friends and the community I would launch the campaign, and left it there.

Hacker News

At about 5:00 PM, I started fiddling with Hacker News. I opened the new section and wrote Show HN: Build Ruby on Rails apps 10x faster – Avo in the title and added a link to the homepage. I posted on HN before about Avo, but I think the messaging was wrong. The product wasn't mature enough, and I didn't communicate well about it.

But I said, f*ck it! Let's submit this! I wrote the first comment addressing many of the issues and questions users brought up in the past. I watched the post a bit and got 5-7 votes. I had a call and went into a meeting. I started getting newsletter subscription notifications and a few trials during the meeting. That was weird. When I came out of the meeting, we were on the front page 🎉.

People started commenting; the points began growing.

A good part of the comments from HN were very pertinent questions about how "does it integrate with current apps?", "is it easy to get started?", "will it work in a large app?", and so on. Some weren't. The main ideas were:

• "how to get started"
• "who is it suited for?"
• "can it be used in a medium-sized/large app?"
• "how does it support this/that package?"
• "how does it compare with the (wrong or right) alternatives?", "Make a comparison."
• "does it do this or that?"
• "Rails is dead"
• "Rails is alive"
• "I'm sorry I don't work with Rails with such a wonderful ecosystem"
• "I'm excited for these kinds of tools popping up"
• "this is a paid product 😠 (mad face)" (although I mentioned that before)
• "why is it so expensive? why is it a subscription? can I have it for free? pricing is misleading/unclear."
• "do people make money with these kinds of projects?"
• "why is it called that?"
• "you lie! you can't build something that fast?" (yes you can 😎)
• "the demo site is slow" (my bad there. it's hosted on heroku hobby plan)
• "Adrian provides the best support. Adrian releases every week. Adrian is awesome 😎!" (I may have distorted that a bit)
• "looks amazing. what a breath of fresh air"
• "why won't you build this for JS/python?"
• "this delivers value!"
• "this is useless. I can build it myself"

I loved every comment. Good and bad! This shouldn't come as a surprise to you, but you should want to hear the bad feedback about your product. If someone says only good things, there might be a problem there. Ask them follow-up questions about the things you know are missing. They will start telling you that "oh yes. that is missing from your product too. I had a hard time without it". But that's a post for another time.

One not-so-good thing that happened was that the Product Hunt campaign that was set to go public on Thursday, was triggered by mistake (still not sure how) during the HN launch. So more than half a day of campaigning seemed wasted.

I had a link on the homepage previewing the Product Hunt launch. I spoke with PH support, and they reset it for Thursday. Crysis averted 😮‍💨

The stats for the HN launch look like this:

• 8K site visitors and 24K pageviews 🚀
• about 100-120 users at a time on the site. the VPS with dokku (fantastic tool!) held on very nicely. I even made a few deploys during the peak hours.
• ~300 points. ~160 comments (almost half were mine responding)
• 2-3K youtube views (I have a walkthrough video on the homepage)
• 8 newsletter subscriptions
• maybe 10 new Twitter followers
• 3-4 new Discord users
• 5 trials started
• Usage increased by 20% (people trying it out)

You can find the post here.

I must say I loved every moment of being on the front page. It was a milestone for the indie hacker geek inside of me.

Product Hunt

Let me set the stage for how Product Hunt works. Every day there's a 24-hour window when people launch products. It starts at 00:01 AM PDT and should end in 24 hours. Products get upvoted and at the end of the day you get a badge (1st, 2nd, 3rd product of the day) or if you got featured (top 8-12 products). The unfeatured ones fall somewhere below a "more" button on the homepage (instant death on PH). You also get comments on the product. There are a few more things involved (weekly rank, yearly golden kitty award, reviews, etc), but that's the gist. You'd like to rank as high as possible. The ranking is a secret algorithm that considers votes, comments, how people end up on PH, what they do before voting, and more.

Back to our launch. I live in Romania (EEST time), so the launch starts at 10:00 AM. Perfect to start campaigning. When I say campaigning, I mean going on groups of like-minded people and posting about the product and the launch. For us, those people were, or had these interests:

• indie developers
• founders
• growth hacking
• low-code/no-code
• start-ups
• marketing
• tech leads
• agencies

These people gave us the most encouragement and feedback about the product.

They were the new people that gave their support. The established ones were Avo users and customers.

I believe they made the difference with their comments. You can always spot the actual customer of the product in the comments. You'll see people go out of their way to let the world know their opinion on it:

• Avo is legit!
• Avo is the first well documented admin gem
• Thank you for this wonderful product
• Avo has been a game changer for our team
• Avo is hands-down the best solution we've found
• Avo inspires me to quickly try new ideas
• This is a must-use by engineering teams worldwide
• I've built this in-house and watched it decay and become useless so many times
• That's what Avo is to me! It's Rails on Rails!
• It saved us hundreds of hours of development work and we could focus on our main business

I'd add all the reviews, but I'm going to stop there 😎

The third and equally important category was the Rails community. I posted from my and Avo's Twitter account about our launch. There is a wonderful Twitter community called Ruby on Rails where I never post about Avo. People tend to get a bit "aggressive" toward paid products. Although Avo has quite a robust free option, everyone focuses on the fact that it's PrOMoTiOn. Plenty of paid products are advertised in communities (not only that community), but somehow, people pick on mine. Or at least that's my impression, but that's a rant for another day.

Back to posting on the Ruby on Rails Twitter community; I made the post as honest as possible. "There's a Ruby on Rails package #2 on Product Hunt. Let's show our support." And the folks there were very cool about it (there's another "closed circle" community where the meanness and spiteness are through the roof, IMHO). I didn't hear any mean comments, and some liked the post.

The PH day went by. Somewhere in the first 4-5 hours, we reached the top three and second place quite quickly afterward. We were behind the #1 by about 10-30 votes during the day. The number one product was "A Chrome extension for beautiful screenshots". So it's more of a consumer-facing product than ours. I suspect they had to do a little less work to campaign 🤔. I still think we were lucky that a big company like Stripe, Shopify, Apple, or another big start-up didn't announce a significant product. Thursday is considered a high-traffic day on PH (Tuesday and Wednesday are the other two).

Sometime after 16 hours of the PH day, something happened on PH; I suspect a bug. We had more votes and kind of the same number of comments as the #1 and we were still #2. We also started to see "2nd product of the day" badge on our page (and "1st product" for #1). That threw us off a bit. Even the private launch dashboard did not show the countdown anymore. We thought "the fight was over". It was 3 AM on our end, and we were beat. It's quite draining psychologically to "hunt" for that feedback, grow on the podium, be so close to the top and not get there. So I spoke with David, my brother, and went to sleep. It was still a good result and a good launch.

During the night, David sent me a message that we dropped on to 3rd, then again on 2nd. PH definitely does some cleanup with the votes. We lost about 20-30 votes after the 24h window closed. Some products lost 100 votes. Not sure what happened there, but we're still happy we haven't lost our position.

You'll find Avo's PH launch here.

Ruby Weekly

One of the biggest newsletters in the Ruby community is Ruby Weekly, and it comes out on a Thursday. I knew that. I could have anticipated they would pick up on the Hacker News article, feature us, and hold off the Product Hunt, but I didn't.

So we got featured on Ruby Weekly. That's usually a good thing (this time too 🙏), but I wanted to measure each campaign's results, not all together. I'm grateful for the featuring (please don't stop doing that 😊), and we got some traffic from there too. I guess it helped in a way because it drove traffic to our website, where we had the Product Hunt badge visible.

The stats for Thursday look like so:

• 1.6K site visitors and 7K pageviews
• one newsletter subscriber
• one trial
• 2nd Product of the Day badge on our homepage 😎

Conclusions

For such a niche and technical product like Avo, I'd say we got much more ROI for the HN post than for PH. We worked our asses off to bring in traffic, and there were just a few conversions. There might be wins in the long run from SEO and the 2nd product of the day PH badge. For HN, we did considerably less. Primarily respond to questions.

What next?

David and I are excited about things to come. The community definitely noticed Avo and is curious about it. We have to work more on how we communicate about the product.

There is a ton of work we still have to do on the development side to make this the dream platform we'd like it to become.

Keep up with the updates

You can keep up with updates by subscribing to our newsletter, following us on Twitter, joining our Discord server, and by starring the GitHub repo ⭐️.

I fixed a shitty situation I created for myself two years back a few days back. What a fantastic feeling that was. I'm still in awe when everything just works.

When I first started to work on Avo, I didn't know much about Rails' inner workings and file-reloading. So as some might not know, Avo helps developers ship apps quickly. Using a few declarative configuration files that the developer is generating in their own app, it does that. Those files are inherited from a few base files UserResource from BaseResource, ToggleAdminAction from BaseAction, TextField from BaseField, and so on.

The issue arose in Avo's development process. When you were making an update to the BaseResource, the changes were not showing up in the Dummy app. The server was not picking them up and wasn't reloading those inherited classes. You had to restart the server for those changes to come into effect.

Over the years, I got pretty clever on how to work around this because there are more pressing issues that I can fix with my time. But I was still thinking about it and coming back to it to try to fix it from time to time.

How did others fix it?

I checked all the guides on autoreloading, literally read the whole docs page and some of the source code of zeitwerk, checked out a lot of purpose made tutorials about code reloading in development and nothing really worked as advertised. I couldn't wrap my head around why it was not working.

Until Friday; I asked myself, "what have others done to fix this?". Then, I remembered that DHH posted an early demo video of importmaps where he stated something along the lines of "we need to restart the server for the importmaps file to register changes. This is something that we'll fix before release...". So, it's released now, so they've fixed it; time to see what they did.

They built this Reloader class that holds all the configuration and the reload! method.

# lib/importmap/reloader.rb
class Importmap::Reloader
  delegate :execute_if_updated, :execute, :updated?, to: :updater

  def reload!
    import_map_paths.each { |path| Rails.application.importmap.draw(path) }
  end

  private
    def updater
      @updater ||= config.file_watcher.new(import_map_paths) { reload! }
    end

    def import_map_paths
      config.importmap.paths
    end

    def config
      Rails.application.config
    end
end

# engine
initializer "importmap.reloader" do |app|
  Importmap::Reloader.new.tap do |reloader|
    reloader.execute
    app.reloaders << reloader
    app.reloader.to_run { reloader.execute }
  end
end

So what are they doing here? First, the reload! method tells Rails what to do when it needs to run. In their case, it takes the importmap files config.importmap.paths and runs Rails.application.importmap.draw for each one. So basically, re-registering the importmaps. Next, they create a file watcher that watches over the files they need.

In the initializer, they add the reloader to the app's reloaders and instruct the app what to do when changes have been detected.

Translate that to watching and reloading the initializer

How does that translate to watching and reloading the initializer and our base classes? We'll tweak a few methods in the reloader.

First, define the paths that we want to watch. For example, we'd like to watch for changes in the initializer (a file) and the whole lib directory. So we're going to remove paths and add two methods, files and directories.

def files
  # we want to watch some files no matter what
  paths = [
    Rails.root.join("config", "initializers", "avo.rb"),
  ]

  paths
end

def directories
  dirs = {}

  # watch the lib directory in Avo development
  if reload_lib?
    dirs[Avo::Engine.root.join("lib", "avo").to_s] = ["rb"]
  end

  dirs
end

You might have noticed the reload_lib? method. That's there to instruct Rails to reload the lib directory only when we tell it to or doing development on Avo, not the parent app.

def reload_lib?
  Avo::IN_DEVELOPMENT || ENV['AVO_RELOAD_LIB_DIR']
end

Next, we will change what the reload! method does. We're going to reload all the files in files and all the files in the directories we specified.

def reload!
  # reload all files declared in paths
  files.each { |file| load file }

  # reload all files declared in each directory
  directories.keys.each do |dir|
    Dir.glob("#{dir}/**/*.rb".to_s).each { |file| load file }
  end
end

Put it all together

class Avo::Reloader
  delegate :execute_if_updated, :execute, :updated?, to: :updater

  def reload!
    # reload all files declared in paths
    files.each { |file| load file }

    # reload all files declared in each directory
    directories.keys.each do |dir|
      Dir.glob("#{dir}/**/*.rb".to_s).each { |file| load file }
    end
  end

  private
    def updater
      @updater ||= config.file_watcher.new(files, directories) { reload! }
    end

    def files
      # we want to watch some files no matter what
      paths = [
        Rails.root.join("config", "initializers", "avo.rb"),
      ]

      # we want to watch some files only in Avo development
      if reload_lib?
        paths += []
      end

      paths
    end

    def directories
      dirs = {}

      # watch the lib directory in Avo development
      if reload_lib?
        dirs[Avo::Engine.root.join("lib", "avo").to_s] = ["rb"]
      end

      dirs
    end

    def config
      Rails.application.config
    end

    def reload_lib?
      Avo::IN_DEVELOPMENT || ENV['AVO_RELOAD_LIB_DIR']
    end
end

The Rails app now knows what to do when something has changed in the parent app. It also knows to watch over the paths that we specified. So now, when you make a change in the initializer or any file in the lib directory, Rails will pick up those changes without you needing to reload the whole server.

I hope this helps you create better apps faster.

PS: If you want to create apps even faster, try out Avo. We sweat on the little details, so you don't have to.

https://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.

• index.html.erb
• turbo_frame_wrap
• turbo_frame_wrapper_component.html.erb

Stay cool and improve performance 💪

avo.cool/

avo.cool/repo

avo.cool/feedback

avo.cool/try