RSS Feed for Short Ruby Email Courses

RSS Feed for Short Ruby Email Courses Short Ruby Email Courses - follow my journey while building the email courses https://learn.shortruby.com/blog/feed Micro benchmarking value objects in Ruby As I was working on another email part of my <a href="https://learn.shortruby.com/courses/modern-ruby">Modern Ruby course via email</a> I wanted to make some micro benchmarks on <code>Data.define</code> vs <code>Struct</code> vs <code>OpenStruct</code> They are not a production-level benchmark, so take them with a grain of salt. I added all code and results in a repo at <a href="https://github.com/lucianghinda/value-object-in-ruby-benchmarks">https://github.com/lucianghinda/value-object-in-ruby-benchmarks</a> <h2>Creating new objects</h2> When creating a new object, <code>Struct</code> (with <code>keyword_init: true</code>)and <code>Data.define</code> behave almost the same (the differences are with error margin or so small that they are probably due to my setup), while <code>OpenStruct</code> seems to be the slowest. Having defines the following keys and values: <pre class="ruby">keys = 1000.times.map { |i| "key#{i}".to_sym } values = 1000.times.map { |i| "value#{i}" } keys_and_values = Hash[keys.zip(values)] </pre> The creation benchmarks are testing the following code: <pre class="ruby">DataStruct = Struct.new(*keys, keyword_init: true) DataStruct.new(**keys_and_values) # vs DataDefine = Data.define(*keys) DataDefine.new(**keys_and_values) # vs OpenStruct.new(**keys_and_values) </pre> Here is a <code>`bmbm`</code> benchmark result: <pre class="bash">Creating a new object - Benchmark with bmbm Rehearsal -------------------------------------------------- Struct.new 0.000023 0.000003 0.000026 ( 0.000024) Data.define 0.000020 0.000001 0.000021 ( 0.000022) OpenStruct.new 0.001705 0.000075 0.001780 ( 0.001780) ----------------------------------------- total: 0.001827sec user system total real Struct.new 0.000020 0.000000 0.000020 ( 0.000020) Data.define 0.000022 0.000000 0.000022 ( 0.000022) OpenStruct.new 0.001069 0.000044 0.001113 ( 0.001132) </pre> Here is the <code>ibs</code> benchmark result: <pre class="bash">Creating a new object - Benchmark with ips ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] Warming up -------------------------------------- Struct.new 5.169k i/100ms Data.define 5.361k i/100ms OpenStruct.new 62.000 i/100ms Calculating ------------------------------------- Struct.new 50.086k (± 1.7%) i/s - 253.281k in 5.058450s Data.define 51.646k (± 1.1%) i/s - 262.689k in 5.086990s OpenStruct.new 607.447 (± 0.8%) i/s - 3.038k in 5.001584s Comparison: Data.define: 51646.3 i/s Struct.new: 50085.7 i/s - 1.03x slower OpenStruct.new: 607.4 i/s - 85.02x slower </pre> Here is the <code>memory</code> benchmark result. <pre class="bash">Creating a new object - Benchmark with ips Calculating ------------------------------------- Struct.new 36.792k memsize ( 0.000 retained) 2.000 objects ( 0.000 retained) 0.000 strings ( 0.000 retained) Data.define 36.792k memsize ( 0.000 retained) 2.000 objects ( 0.000 retained) 0.000 strings ( 0.000 retained) OpenStruct.new 848.728k memsize ( 0.000 retained) 8.005k objects ( 0.000 retained) 50.000 strings ( 0.000 retained) Comparison: Struct.new: 36792 allocated Data.define: 36792 allocated - same OpenStruct.new: 848728 allocated - 23.07x more </pre> <h2>Accessing attributes</h2> Again <code>Data.define</code> and <code>Struct</code> with keyword arguments are the same. On the other side <code>OpenStruct</code> is almost twice as slow. Having the following data defined: <pre class="ruby">keys = 1000.times.map { |i| "key#{i}".to_sym } values = 1000.times.map { |i| "value#{i}" } keys_and_values = Hash[keys.zip(values)] </pre> And then defining the following structures: <pre class="ruby">BigDataS = Struct.new(*keys, keyword_init: true) BigDataD = Data.define(*keys) </pre> The benchmarks are comparing: <pre class="ruby">keys.each { struct_object.send(_1) } keys.each { data_object.send(_1) } keys.each { opens_struct_object.send(_1) } </pre> Here is the <code>bmbm</code> benchmark result: <pre class="bash">Accessing attributes - bmbm test Rehearsal ----------------------------------------------- Struct 0.000069 0.000002 0.000071 ( 0.000071) Data.define 0.000069 0.000003 0.000072 ( 0.000071) OpenStruct 0.000110 0.000003 0.000113 ( 0.000116) -------------------------------------- total: 0.000256sec user system total real Struct 0.000049 0.000001 0.000050 ( 0.000046) Data.define 0.000046 0.000001 0.000047 ( 0.000046) OpenStruct 0.000091 0.000001 0.000092 ( 0.000094) </pre> Here is the <code>ibs</code> benchmark result: <pre class="bash">Accessing attributes - ips test ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] Warming up -------------------------------------- Struct 2.857k i/100ms Data.define 2.828k i/100ms OpenStruct 1.384k i/100ms Calculating ------------------------------------- Struct 28.420k (± 0.9%) i/s - 142.850k in 5.026906s Data.define 28.691k (± 0.5%) i/s - 144.228k in 5.027131s OpenStruct 13.475k (± 0.9%) i/s - 67.816k in 5.033315s Comparison: Data.define: 28690.8 i/s Struct: 28419.6 i/s - same-ish: difference falls within error OpenStruct: 13474.6 i/s - 2.13x slower </pre> <h2>Context for understanding why Data.define and Struct are similar</h2> <a href="https://ruby.social/@ufuk">Ufuk Kayserilioglu</a> <a href="https://ruby.social/@ufuk/112141972493634321">explains</a> why <code>Data.define</code> and <code>Struct</code> with keyword arguments have the same behavior: <img alt="Ufuk explaining: "Data is (basically) just Struct with no writer methods defined (and a freeze, I believe). The CRuby codepaths are exactly the same for both, except zverok decided that Data#initialize should always accept kw arguments, so Data.new has to convert positional args to kw args before passing them to initialize."" src="https://images.learn.shortruby.com/data-define-similar-with-struct.webp" /> <h2>A note about <code>OpenStruct</code></h2> <a href="https://github.com/byroot">Jean Boussier</a> <a href="https://twitter.com/_byroot/status/1771221003051422101">answered</a> a question about why OpenStruct is so slow: <img alt="Jean Boussier explaining "It's not because it's written in Ruby but because of it's semantic. For every single instance it has to create a metaclass and define methods on it. It's terribly wasteful and doing the same in C wouldn't be much faster. OpenStruct should be considered deprecated really."" src="https://images.learn.shortruby.com/open-struct-deprecated.webp" /> 2024-03-29 https://learn.shortruby.com/blog/micro-benchmarking-data-define-vs-struct-vs-openstruct https://learn.shortruby.com/blog/micro-benchmarking-data-define-vs-struct-vs-openstruct History of the endless method syntax When I learn about a new language feature, I like to read and discuss the proposal. How and why it was accepted. What was the requester trying to accomplish, and what problem did they try to solve? Here, I will review how the endless method was introduced in the Ruby language. <h2>What is the definition of the endless method?</h2> In a few words, it is an alternative syntax for defining a method that consists of a single expression. Here is the definition from <a href="https://docs.ruby-lang.org/en/master/syntax/methods_rdoc.html">Ruby documentation</a>: <img alt="Definition of endless method in Ruby" src="https://images.learn.shortruby.com/definition-from-ruby-docs.webp" /> Here are two simple examples: <pre class="ruby">def exists? = User.where(organisation: organisation).exists? </pre> or with parameters: <pre class="ruby">def format_date(date) = date.strftime(DEFAULT_DATE_FORMAT) </pre> <h2>History of trying to remove one or more <code>end</code>s</h2> <h3>2011 - the first proposal is made mainly as a joke, but it tries to solve a real problem with idiomatic code</h3> In 2011, Yasushi Ando <a href="https://bugs.ruby-lang.org/issues/5054">proposed</a> (as a joke) an <code>en(n+)d</code> to solve the following issue: having too many ends: <pre class="ruby"># Source: https://bugs.ruby-lang.org/issues/5054 # Replace this code: module MyModule class MyClass def my_method 10.times do if rand < 0.5 p :small end end end end end # With: module MyModule class MyClass def my_method 10.times do if rand < 0.5 p :small ennnnnd </pre> While the proposal was a joke, the idea is that sometimes the number of <code>end</code>s we have to write is high (sometimes it takes more chars than the actual business logic). Another <a href="https://bugs.ruby-lang.org/issues/5065">proposal</a> (this time a serious one) was made by Lazaridis Ilias later the same year, 2011. This time the proposal was to allow <code>}</code> instead of <code>end</code>: <pre class="ruby"># Source: https://bugs.ruby-lang.org/issues/5065 module MyModule class MyClass def my_method 10.times { # "10.times do" would work, too if rand < 0.5 p :small } } } } } </pre> This one was rejected. Among other proposed ideas was to have an <code>endall</code> as a keyword that will add all necessary ends if I might say so: <pre class="ruby"># Source: https://bugs.ruby-lang.org/issues/5065 module MyModule class MyClass def my_method 10.times do if rand < 0.5 p :small endall </pre> <h3>2016 - another proposal was made, this time a serious one</h3> Then, in 2016, Nobuyoshi Nakada <a href="https://bugs.ruby-lang.org/issues/12241">proposed</a> another idea, building upon the previous one: to introduce the <code>end!</code> keyword like a <code>super end</code> concept that will end all blocks not ended until its level: <pre class="ruby"># Source: https://bugs.ruby-lang.org/issues/12241 module MyModule class MyClass def my_method 10.times do if rand < 0.5 p :small !end </pre> There were few replies to it, so there was no final decision. <h3>2020 - a new proposal with more arguments and a simple approach is suggested</h3> The <a href="https://bugs.ruby-lang.org/issues/16746">feature request</a> for the current format was submitted in 2020 by Yusuke Endoh on the Ruby issue tracker: <img alt="Endless method definition - proposal from Yusuke in Ruby tracker" src="https://images.learn.shortruby.com/endless-method-yusuke-proposal.webp" /> The initial proposal wanted to use <code>:</code> instead of <code>=</code> when defining the method body, but Matz <a href="https://bugs.ruby-lang.org/issues/16746#note-7">proposed</a> using <code>=</code>. Still, the go-ahead for running an experiment like this was given at the end of 2020. Later in that thread, Yusuke <a href="https://bugs.ruby-lang.org/issues/16746#note-8">presented</a> some arguments: <blockquote> Surprisingly, according to the following rough estimate of ruby/ruby code base, this kind of simple method definitions account for 24% of the entire method definitions. </blockquote> Victor Shepelev <a href="https://bugs.ruby-lang.org/issues/16746#note-25">added</a> some excellent arguments in favor of this proposal: <blockquote> The most precious Ruby’s quality for me is “expressiveness at the level of the single ‘phrase’ (expression)”, and it is not “code golf”-expressiveness, but rather structuring language’s consistency around the idea of building phrases with all related senses packed, while staying lucid about the intention I believe that the difference of “how you write it when there is one statement” vs “…more than one statement” is intentional, and fruitful: “just add one more line to 10-line method” typically small addition, but “just add one more line to 1-line method” frequently makes one think: may be that’s not what you really need to do, maybe data flow becomes unclear </blockquote> <h3>2021 - a new proposal is made for a super-end keyword</h3> While the status of the Yusuke proposal kept having multiple arguments, and Matz already proposed a syntax there that he would like but said might be conflicting, a new proposal was submitted trying to solve the same issue but focusing on nested ends. This <a href="https://bugs.ruby-lang.org/issues/17786">proposal</a> added by Jabari Zakiya is about the same idea of how to reduce the number of <code>end</code> keywords, and in this case, the proposal was to use <code>ends</code>: <pre class="ruby"># Source: https://bugs.ruby-lang.org/issues/17786 def render(scene, image, screenWidth, screenHeight) screenHeight.times do |y| screenWidth.times do |x| color = self.traceRay(....) r, g, b = Color.toDrawingColor(color) image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b)) end end end # To be replaced by def render(scene, image, screenWidth, screenHeight) screenHeight.times do |y| screenWidth.times do |x| color = self.traceRay(....) r, g, b = Color.toDrawingColor(color) image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b)) ends </pre> This, too, not approved yet. Notice this is a bit of a tangent to the endless method, but it is worth considering that the idea that the number of <code>end</code> keywords written should be limited is present. <h3>Ruby 3.0 - release on 25 December 2020 included endless method definition</h3> Ruby version 3.0 included the endless method definition or shorthand method syntax with the following format: <pre class="ruby">def <name>(<params>) = <body> # or def <name>(<params>) = <an expression that can be on multiple lines> # or def <name> = <body> # or def <name> = <an expression that can be on multiple lines> </pre> Of course, having arguments is optional, but if you decide to specify them, then parentheses are mandatory. <h2>More about the endless method</h2> One of the best resources to read about this in a format that does an excellent assessment of this feature is the article written by Victor Shepelev called <a href="https://zverok.space/blog/2023-12-01-syntax-sugar5-endless-methods.html">“Useless Ruby sugar”: Endless (one-line) methods</a> <h2>Curious to learn more about this?</h2> If you want to learn more about this feature, its gotchas, when and how to use it, and real code examples, I am creating a course called <a href="https://learn.shortruby.com/courses/modern-ruby">“Modern Ruby Syntax”</a>, where I explore the endless method along with other Ruby features. 2024-03-19 https://learn.shortruby.com/blog/history-of-endless-method https://learn.shortruby.com/blog/history-of-endless-method Modern Ruby Syntax - update 1 Here’s a quick update on my progress with the email course for <a href="https://learn.shortruby.com/courses/modern-ruby">Modern Ruby Syntax</a>: <ul> <li>I finished the numbered block params chapter (the first email in course)</li> <li>I am close to finishing the draft for the endless method syntax email (the second one in the same course).</li> </ul> In the last two or three weeks, the progress has been slower than I expected because I worked to write some proposals for a couple of Ruby conferences in Europe, where I hope to speak about the Modern Ruby Syntax. Fingers crossed! <h2>Numbered Block Params</h2> The first round of feedback on the numbered block params email has been received, and I’m actively working on updates. It should be ready in an alpha state by next week. The PDF version of the document, which is the most detailed version, is nearly 20 pages long. It covers everything from explaining numbered block parameters to providing examples of how to use them in your daily coding life. Additionally, it includes some style guidelines that I believe will help you write more readable code when working with numbered block parameters. No worries, there email will be shorter as you always have the PDF attached for a deep dive. Your feedback is invaluable! If you’re interested in proofreading or just feedback on the numbered block params email, please email me at lucian@shortruby.com. I’ll send you the PDF and eagerly await your insights. <h2>Endless Method Syntax</h2> I worked this week on writing the email for the endless method syntax. It is 80% done. I will also work on this one next week, try to finish it, and prepare it for feedback. <h2>A video overview</h2> In case you want to see a sneak peek at the content, I made a short video with the current status and talk about what each chapter contains: <iframe width="560" height="315" src="https://www.youtube.com/embed/xIjdatejD2M?si=Q0xQI7e3M99T22-W" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen class="mx-auto"></iframe> 2024-02-09 https://learn.shortruby.com/blog/update-1-modern-ruby-syntax-finished-first-chapter https://learn.shortruby.com/blog/update-1-modern-ruby-syntax-finished-first-chapter The tech stack I choose to build email courses Here are my choices about the tech stack I plan to use for this project. <h2>Criteria</h2> When I think about the tech stack I want to use for this project, I have to consider the following: Time The most important part is time. This is a side project; thus, it receives a small part of my effort. This is a fixed allocation that I can put among spending time with family, having a full-time job, and taking time for myself. I think about time in two ways: <ul> <li>The time I have to build the project</li> <li>The time I will have to maintain the project</li> </ul> Speed of change The second most important thing is being able to change. That includes releasing new features or reacting to users’ needs or wants. What’s important here is the speed of change: How fast can I release something to production? Costs On the third place are costs: hosting, emailing, and additional services used to build the project. I have not yet allocated a budget for this project but will do so over the next weeks. Having a budget will help to validate if the idea is feasible and sustainable over the long run. <h2>Choices</h2> <h3>Programming language: Ruby</h3> I am using <a href="https://www.ruby-lang.org/en/">Ruby</a>. It is the language the I know best and it is also a language that allows me enough flexibility to write code that is easy to change and quick to adapt. <h3>Web framework: Ruby on Rails</h3> I am using <a href="https://rubyonrails.org">Ruby on Rails</a>. I briefly considered Hanami 2 as it is fresh, and I wanted to pick it up, but considering the time and speed of change, there is not much room to learn a new framework. At the same time, Ruby on Rails comes with a lot of battery included, and that is what I need in this project where I plan to focus on the product and content. <h3>Persistence: SQLite</h3> I am using SQLite. Ruby on Rails now has good support for SQLite in production, and <a href="https://fractaledmind.github.io">Stephen Margheim</a> has a lot of easy-to-follow and to-the-point articles for configuring it. Choosing SQLite reduces the time allocated to maintenance, so it is an easy win. I am not concerned with scalability as I don’t see this project needing more than a server. I also added the <a href="https://github.com/fractaledmind/activerecord-enhancedsqlite3-adapter"><code>Activerecord-enhancedsqlite3-adapter</code></a> that adds support for generated columns, deferred foreign keys, PRAGMA tunning, and extensions loading. For backup I am using <a href="https://github.com/fractaledmind/litestream-ruby"><code>litestream</code></a> gem that makes working with the <a href="https://litestream.io"><code>litestream.io</code></a> easier. <h3>Backround running jobs</h3> I use <a href="https://github.com/oldmoe/litestack">litestack</a> gem that comes with everything, including Jobs, Caching, Search, and Metrics. I am considering for jobs to move to <a href="https://github.com/basecamp/solid_queue">SolidQueue</a> at some point. <h3>Admin: Avo</h3> I am using <a href="https://avohq.io">Avo</a> to build the Admin UI that I will use to manage the content. Avo looks excellent; it is modern and fast, and I don’t want to spend time building a UI for myself to manage the content. It is already built, it has a feel of Railsy while configuring it, and it is flexible enough so that if I need more custom things, I can do them. The best benefit is that I get time back to invest in the content instead of the development of an admin. <h3>CSS: Tailwind and TailwindUI</h3> I am using <a href="https://tailwindcss.com">Tailwind</a> because I used it professionally, so I know it a bit, and also because I bought <a href="https://tailwindui.com">TailwindUI</a> where I can find ready-made components that I can copy/paste into my project if needed. Rails 7 also comes with an already integrated Tailwind, and it works with import maps. <h3>Import maps</h3> I like <a href="https://github.com/rails/importmap-rails">Rails import maps</a>, and I am picking other UI-related gems only if it works with import maps. That is because I don’t want to run <code>nodejs</code> or have any <code>node_modules</code> installed. It adds to maintenance, and I like to minimize maintenance tasks. <h3>Views: ERBs and Phlex</h3> First, I will create the general views as HTML ERB files. This is because it is close to HTML, will have low maintenance, and can be changed quickly. It also helps with copying/pasting elements from TailwindUI without making too many changes. I will organize (or extract) standard components by using <a href="https://www.phlex.fun">phlex</a>. Phlex is closer to my backend background, so I can keep writing Ruby while building UI elements. <a href="https://rubygems.org/gems/phlex-rails"><code>phlex-rails</code></a> has also a good integration with <a href="https://lookbook.build/guide/components/phlex"><code>Lookbook</code></a> and so I can easily preview my components. How I use this mix is like this: the general structure of the page is done with HTML ERB, but the elements inside are mostly done with Phlex. <h3>Testing</h3> I use <a href="https://guides.rubyonrails.org/testing.html#rails-meets-minitest">Minitest</a>, the default testing framework for Rails. I like Minitest in my side projects for two main reasons: <ul> <li>It comes default with Rails and runs fast</li> <li>It is not a DSL, but it is just Ruby code. So it will be easy to return to it and not spend time remembering a DSL. </li> </ul> There is one gem that I usually install for tests and that is <a href="https://github.com/adammck/minitest-stub-const"><code>minitest-stub-const</code></a>. Stubbing constanta can also be done without this gem, but I kept using this gem. <h3>Static pages: Sitepress</h3> For static pages, like <a href="https://learn.shortruby.com">homepage</a>, or <a href="https://learn.shortruby.com/blog">the blog section</a> I am using <a href="https://sitepress.cc">sitepress</a>. It has an easy integration with Rails and helps move from static files to dynamic options easily. I also like that it has Frontmatter support and comes with a way to work with each page’s meta-data. It is a maintenance and low configuration solution: Install it, write things in <code>.html.md</code> files, and all will work. <h3>Debugging: Debug gem</h3> <a href="https://github.com/ruby/debug">Debug</a> gem is now the default debugger gem for Rails, and I like it a lot. A lot of development is happening, and new features are always added. I started moving away from <code>puts</code> debugging to real debugging, and I even use the debugger to inspect object states while I do code design. As the <code>debug</code> gem is part of Ruby, I think it can be a safe bet for the future with little maintenance or overhead required. I am using it in all my projects. <h3>Asset pipeline: Propshaft</h3> On multiple occasions, <a href="https://github.com/rails/propshaft"><code>propshaft</code></a> mentioned that it would become the default in Rails, so I chose it because I think it will make upgrading Rails easier. I also like that <code>propshaft</code> is simple and does one thing well. <h3>Beautiful web UX: Hotwire</h3> Of course, <a href="https://hotwired.dev">Hotwire</a> is my choice for building web UX. It comes with Rails by default, and it has a lot of good integrations. It allows me to build promising web UX without the mental overhead of learning more JS or a new JS library. When I need to write some JS, I like to use Stimulus because it gives me a place and a way to organize JS code. This is important for a project you don’t open daily to know exactly where to find each piece of code. <h3>Environment variables: direnv</h3> I started using <a href="https://direnv.net"><code>direnv</code></a> a while back, mostly because I needed to share some environment variables between projects. So I can put a <code>.envrc</code> file in the top folder for a group of projects and have those environment vars available in all subfolders. It removes the need to use the <code>dotenv</code> gem and also decreases the chances of accidentally committing your <code>.env</code> file if you put the <code>.envrc</code> in the parent folder and not the code folder. I mostly organize my projects like this: <pre class="bash">projects/ project/shortruby/ project/shortruby/apps project/shortruby/apps/shortruby.com project/shortruby/apps/lean.shortruby.com project/shortruby/apps/newsletter.shortruby.com project/shortruby/images project/shortruby/docs project/shortruby/scripts </pre> I can add the <code>.envrc</code> file under <code>projects/shortruby/apps</code> and have the common development environment variables shared between multiple projects. <h3>Code Quality: Rubocop + Rubycritic</h3> I use Rubocop to enforce <a href="https://github.com/lucianghinda/personal-ruby-style">a coding style</a> that I like and made for myself. It is well-supported by any editor and allows me to configure it as I see fit. In my case, I lean toward using new Ruby syntax so the cops are configured to allow that. I added to it the following gems: <ul> <li><a href="https://rubygems.org/gems/rubocop-rails">rubocop-rails</a> - “Automatic Rails code style checking tool”</li> <li><a href="https://rubygems.org/gems/rubocop-performance">rubocop-performance</a> - “A collection of RuboCop cops to check for performance optimizations in Ruby code”</li> <li><a href="https://rubygems.org/gems/rubocop-minitest">rubocop-minitest</a> - “Automatic Minitest code style checking tool”</li> <li><a href="https://rubygems.org/gems/rubocop-capybara">rubocop-capybara</a> - “Code style checking for Capybara test files (RSpec, Cucumber, Minitest)”</li> <li><a href="https://rubygems.org/gems/rubocop-rubycw">rubocop-rubycw</a> - “Integrate RuboCop and ruby -cw. You can get Ruby’s warning as a RuboCop offense by rubocop-rubycw”</li> </ul> I also use <a href="https://github.com/whitesmith/rubycritic">Rubycritic</a> to keep complexity low. I don’t refactor for every code smell, but it is good to have an excellent overview of what complexity each change might add to the existing codebase. You can see how I configured all these tools in my article about <a href="https://learn.shortruby.com/blog/first-commits">First commits</a>. <h3>Code editor: RubyMine</h3> I am using <a href="https://www.jetbrains.com/ruby/"><code>RubyMine</code></a> as my primary code editor with <code>IdeaVim</code> plugin enabled. I worked with it quite a lot in the last few years and am fast when using it. Helps with debugging and go to definition. <h3>Versioning: Github</h3> I have some experience with both <a href="https://github.com">Github</a> and <a href="https://gitlab.com">Gitlab</a>. But I think GitHub is a good choice here due to its UI simplicity. I don’t want to spend time in configuration and the UI/UX choices are great. The PR flow is quick and easy to set up, and for my needs, I only use GitHub actions to run simple tasks. I think Gitlab has a more powerful CI but I don’t think I need it right now. <h3>Sending emails: Postmark</h3> For sending emails, I choose <a href="https://postmarkapp.com">Postmark</a>. It is easy to set up and offers API-sending email and SMTP services. I don’t know if Postmark will be used to send the course content. But it will be used to send all transactional emails related to the project. I am considering <a href="https://convertkit.com">ConverKit</a> to write and send the actual email content. This will depend on their API support for the features I plan to build for my users: restart an email course, choose periodicity, and more. <h3>Hosting: Hetzner and Hatchbox</h3> I am using VPS <a href="https://www.hetzner.com">Hetzner</a> as they have a good price and being in EU it helps me with registering the invoice to my accounting. I am using deployment <a href="https://hatchbox.io">Hatchbox</a> for ease of use. I enabled automatic deployments to make a deploy with <code>git push</code> - simple and effective. <h3>Analytics: Plausible</h3> I discovered <a href="https://plausible.io">Plausible</a> while learning Elixir and Phoenix and started using it for all my side projects. I like the simplicity, and it is also a good price for what it is offering. <h3>Image storage: Cloudflare R2</h3> I started looking for an AWS S3 alternative primarily due to the time spent configuring IAM and other stuff that always needed to be done when setting up a new account. I discovered Cloudflare R2 last year (https://www.cloudflare.com/developer-platform/r2/), and I started using it. Again, I like the simplicity (it can be configured in minutes) and can be used for ActiveStorage. What I plan to build, where I will mostly upload and display images, worked perfectly and for an excellent price. AWS S3 could be better for more complex tasks, but if the only need is to upload images and display them publicly while being a solo developer, the R2 is a good choice. <h2>Conclusion</h2> These are the tools I use and why I chose them to build <a href="https://learn.shortruby.com">the email courses project</a> I don’t think there exists a thing called “the best tech stack,” but depending on my knowledge and purpose, I can create an excellent tech stack to help me deliver fast and with good code quality. 2024-01-24 https://learn.shortruby.com/blog/tech-stack https://learn.shortruby.com/blog/tech-stack End of Cycle 1 - Retrospective I can conclude that Cycle 1 is finished. The main focus of <a href="cycle1-building-an-welcoming-place">Cycle 1</a> was “Building a welcoming place,” and I think I managed to achieve it. The bar was not that high anyway. Here is what I managed to implement: <ul> <li>Added RSS feed for blog</li> <li>Added meta-tags with OG images</li> <li>Transformed all images to WEBP format where possible (it seems that OG images do not support WEBP)</li> <li>Fixed accessibility page speed report</li> <li>Added feature to subscribe when launch with ConvertKit</li> <li>Add automatic Sitemap generation</li> </ul> <h2>Learnings</h2> This time passed very quickly. That might be because the total amount of time I invested was around 4 hours for programming and 3-4 hours of writing. I spent most of the programming time trying to implement integration tests for an article on the blog and ensure that the OG properties are correctly displayed. The chunk spent there was trying to make Rails load Sitepress from a path under <code>test/data/sitepress</code> and then get a blog article from there instead of testing against a real article. Learning: Speed of development should be considered in a side project, and sometimes it is ok not to stub a resource and instead assert against the actual resource. Learning Limited time allocation helps with decisions about when to stop working on a solution and go back to rethink the approach. <h2>What’s next?</h2> There are two directions where I could spend my time: <ol> <li>Expand the currently proposed courses and write the proposed list of emails/chapters I plan to tackle for each of them. </li> <li>Implement a prototype for writing and sending an email to users. </li> </ol> I am confident I can find a solution for 2, so maybe I should focus on the content part because people might be buying the course because of the content and not the platform. Thus, I want to do a cycle focusing on the content and trying to expand it a bit more. 2024-01-23 https://learn.shortruby.com/blog/end-of-cycle1-retrospective https://learn.shortruby.com/blog/end-of-cycle1-retrospective First commits <img alt="Image header with article title and screenshot of Github commits" src="https://images.learn.shortruby.com/first-commits-in-my-rails-repository.webp" /> I had the idea for this project over three months ago and created the Ruby on Rails repo around that time. I was unsure what form the product would have, so I focused first on setting up coding styles, static analysis checks, and some other defaults that I consider essential when starting a project. In this article, I will explore what I added and why I chose that specific tool, talking specifically from the perspective of a single-person side project. <h2>What I wanted to achieve with my first commits</h2> There is a kind of inertia to the code design: new code tends to be similar to existing code. Here is a better quote from Edmond Lau book called “The Effective Engineer” that shows the positive side of this inertia: <blockquote> The code quality also self-propagates; new engineers model their own code based on the excellent code that they see, creating a positive feedback loop. </blockquote> When working alone on your project, you can replace “new engineer” with “you in the future,” the quote will still be relevant. My initial commits aimed to set up automated checks for code quality and security. I want to help my future self be fast and write quality code. Side projects developed while having a full-time job have a unique characteristic worth noting. The time dedicated to working on the side project is not continuous. For instance, you may work on it for 1-2 hours on Saturday, and the next opportunity to work on it may only arise a week later. It is then essential to make the code quality built-in and use as much automation as possible. <h2>First commits</h2> My first commits were about: <ul> <li>adding Rubocop to correct and enforce coding styles automatically </li> <li>check code quality with Rubycritic</li> <li>security audits with brakeman, bundler-audit and importmap audit</li> <li>enable Rails strict loading</li> <li>make Rails console run on sandbox mode in production</li> </ul> <h3>Add Rubocop</h3> I have a <a href="https://github.com/lucianghinda/personal-ruby-style">Rubocop configuration</a> that I like to use in my side projects. The first commit sets up Rubocop and adds my configuration to the <code>.rubocop.yml</code> file. <h4>Why add Rubocop</h4> I have a lot of thoughts about what cop I want enabled and what cop disabled, and sometimes I change my mind about some of them, but for this project, consistency is more important than a specific cop. It is essential to have a consistent style while coding. I also like to have the editor auto-format my code, so I chose Rubocop because I want to use the new Ruby syntax, and thus, I can switch on/off rules that will impede this. <h4>What I added to the commit</h4> 1. Rubocop gems I am using the following Rubocop gems: <ul> <li><a href="https://rubygems.org/gems/rubocop-rails">rubocop-rails</a> - “Automatic Rails code style checking tool”</li> <li><a href="https://rubygems.org/gems/rubocop-performance">rubocop-performance</a> - “A collection of RuboCop cops to check for performance optimizations in Ruby code”</li> <li><a href="https://rubygems.org/gems/rubocop-minitest">rubocop-minitest</a> - “Automatic Minitest code style checking tool”</li> <li><a href="https://rubygems.org/gems/rubocop-capybara">rubocop-capybara</a> - “Code style checking for Capybara test files (RSpec, Cucumber, Minitest)”</li> <li><a href="https://rubygems.org/gems/rubocop-rubycw">rubocop-rubycw</a> - “Integrate RuboCop and ruby -cw. You can get Ruby’s warning as a RuboCop offense by rubocop-rubycw”</li> </ul> 2. Apply Rubocop autocorrection to files generated by <code>Rails generate</code> I want to automatically run Rubocop with autocorrect on any <code>.rb</code> file generated by the Rails generate command. This will ensure that any gem that generates Ruby files or any I generate will have the style automatically corrected. I added the following code to the <code>config/application.rb</code> to do this: <pre class="ruby">config.generators.after_generate do |files| parsable_files = files.filter { |file| file.end_with?(".rb") } unless parsable_files.empty? system("bundle exec rubocop -A --fail-level=E #{parsable_files.shelljoin}", exception: true) end end </pre> I took this code from <a href="https://docs.rubocop.org/rubocop-rails/usage.html#rails-configuration-tip">Rubocop Rails Configuration tip</a> and you can see it added to <a href="https://github.com/rails/rails/blob/main/railties/lib/rails/configuration.rb#L134">the current Rails master</a> And I made Rubocop run on Github CI with by adding the following content to the file under <code>.github/workflows/rubocop.yml</code>: <pre class="yml">name: Rubocop Linter on: push: branches: - main pull_request: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Set up Ruby uses: ruby/setup-ruby@v1 with: ruby-version: 3.3 bundler-cache: true - name: Install dependencies run: bundle install - name: Checking Rubocop Styles run: bundle exec rubocop </pre> This will run Rubocop on the following two cases: - When code is pushed to the main branch. - When a pull request is made to the main branch. <h3>Code Quality with Rubycritic</h3> The third commit adds <a href="https://github.com/whitesmith/rubycritic">Rubycritic</a> as a code quality static analysis. <h4>Why add Rubycritic</h4> I added this because I want to ensure I create simple code. And while Rubycritic does not guarantee the code will be simple, it can help maintainability. I see maintainability as an essential metric in the context of a side project. <h4>The commit</h4> I don’t want to run Rubycritic in CI mostly because I think about having little time and trying to be fast with feature releases, and sometimes refactoring to remove a code smell can take quite some time. But I do want to run this locally, so I just created a file under <code>bin/quality_check</code> with the following content: <pre class="bash">#!/bin/bash -e bundle exec rubycritic </pre> Why a file and not run directly <code>rubycritic</code>? I’d like to add more tools like this here or configure Rubycritic in a specific way and having a bash script allows me this flexibility. Rubycritic uses <a href="https://github.com/troessner/reek">reek</a> under the hood so I added a reek config files at <code>.reek.yml</code> with the following content: <pre class="yml">--- detectors: IrresponsibleModule: enabled: false LongParameterList: enabled: true exclude: [] max_params: 4 overrides: initialize: max_params: 5 DataClump: max_copies: 3 min_clump_size: 3 ### Excluding directories exclude_paths: - test/ - config/ </pre> I mostly disabled <code>IrresponsibleModule</code> because I don’t want to add a description to all classes/modules I create. I also allowed a maximum of 4 parameters for methods and 5 for the initializers. I also allowed a maximum of 3 methods in an object to have the same parameters, and the check happens only from 3 parameters up. I can rationalize this decision, but it is mainly based on my experience with extracting objects from a long list of parameters and finding a balance when to make this effort. <h3>Security checks on CI</h3> The fourth commit is concerned with adding security checks to the CI. <h4>Why add security checks</h4> I want to run on CI a couple of security audits that I grouped under the name of <code>Static Analysis</code>: <ul> <li><a href="https://rubygems.org/gems/brakeman">Brakeman</a> - “Brakeman detects security vulnerabilities in Ruby on Rails applications via static analysis”</li> <li><a href="https://rubygems.org/gems/bundle-audit">Bundle audit</a> - “Patch-level verification for Bundler”</li> <li><a href="https://github.com/rails/importmap-rails">Importmap audit</a> - “checks the NPM registry for known security issues”</li> </ul> <h4>The commit</h4> Here is the CI config for Github to run all these tools in <code>.github/workflows/static_analysis.yml</code>: <pre class="yml">name: Static Analysis on: push: branches: - main pull_request: branches: - main jobs: static_analysis: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Setup Ruby uses: ruby/setup-ruby@v1 with: ruby-version: 3.3 bundler-cache: true - name: Install Bundler run: gem install bundler - name: Install dependencies run: | bundle config path vendor/bundle bundle install --jobs 4 --retry 3 - name: Run bundler-integrity check run: bundle exec bundler-integrity - name: Run Brakeman run: bundle exec brakeman - name: Run Bundle Audit run: bundle exec bundle-audit check --update - name: Run Importmap audit run: bundle exec bin/importmap audit </pre> <h3>Enable Rails strict loading</h3> Here is what <code>strict_loading</code> does (<a href="https://github.com/rails/rails/pull/37400">source</a>): <blockquote> Add #strict to any record to prevent lazy loading of associations. strict will cascade down from the parent record to all the associations to help you catch any places where you may want to use preload instead of lazy loading. </blockquote> <h4>Why enable strict loading</h4> This is an excellent way to prevent N+1 and ensure that any needed association is included or preloaded. <h4>The commit</h4> I enabled <code>strict_loading</code> in all environments: <pre class="ruby"># config/environments/development.rb config.active_record.strict_loading_by_default = true </pre><pre class="ruby"># config/environments/test.rb config.active_record.strict_loading_by_default = true </pre><pre class="ruby"># config/environments/production.rb config.active_record.strict_loading_by_default = true </pre> <h3>Make Rails console run on sandbox mode in production</h3> <h4>Why make console run in sandbox mode</h4> It is a good practice to run the rails console in production in the sandbox box to ensure any change is intentional. I use <code>rails console</code> quite often in production, but I want to make sure that if I want to make any changes, that should be intentional and not accidental. <h4>The commit</h4> This is a <a href="https://github.com/rails/rails/pull/48984">simple switch</a> that I can toggle in the Rails config for production: <pre class="ruby"># config/environments/production.rb config.sandbox_by_default = true </pre> If this is enabled, then to make changes, you have to run <code>rails console --no-sandbox</code> <h2>Conclusion</h2> I made the first commits in this repository intentional about code quality and automatic checks. It helps with moving fast while keeping a good code quality. A lot can be done in this area, but I tried to add the minimum that would help me. <hr> <h3>A note about eager loading code</h3> A previous version of this article included a section about configuring CI to run <code>bin/rails zeitwerk:check</code> to check if the code loads correctly. <a href="https://hashref.com">Xavier Noria</a> correctly pointed out that running this in CI is unnecessary. First, there is a config setting called <a href="https://guides.rubyonrails.org/v7.0/configuring.html#config-eager-load"><code>config.eager_load</code></a>, and if you put that on <code>true</code> in your test environment and run any test that will eagerly load your entire application. This setting exists already in Rails 6.0 (and even before 6.0). Since Rails 7.0 the generated <code>config/environment/test.rb</code> includes the following line: <pre class="ruby">config.eager_load = ENV["CI"].present? </pre> That means if you run your tests in Github CI (or similar CIs) that sets the <code>CI</code> environment variable, it will eagerly load your application. So there is no need to execute <code>rails zeitwerk:check</code> separately. Either set the <code>config.eager_load</code> to true on CI, or you already have that if you generated your app with Rails >= 7.0 and run your tests on CI. 2024-01-16 https://learn.shortruby.com/blog/first-commits https://learn.shortruby.com/blog/first-commits Early Launch When is an excellent time to launch a project? Some people advise launching as early as possible. Just have a domain (or not), create a simple page where you explain the project, publish, and start talking about it. Others advise waiting until you have some prototype or MVP or a tiny utility or value you can offer. I think context also matters: <ul> <li>What kind of product or content do you have?</li> <li>Is this part of an established brand, or are you launching a new brand?</li> <li>Is this a side project or part of an existing company?</li> <li>The audience that you are trying to reach?</li> </ul> <h2>Why launch early?</h2> <h3>Write about the journey while building the project</h3> In my case, this project is a side project, and my idea is to launch it as early as possible because I plan to write about my journey while building it. To be part of the <a href="https://buildinpublic.com">#buildinpublic</a> movement. I liked following some people sharing their stories as they built their side projects. Writing about technical or product problems as I encountered them is valuable, and this is what I plan to do. First, it helps me clear my thinking and simplify, adjust, and find solutions; second, it might inspire others who may have problems or explore similar paths. <h3>Early feedback</h3> Launching early helps me get early feedback. That is a very valuable input to have when building a product. Also, the launch of a project can alleviate the pressure of having a perfectly polished release. This allows me to concentrate on small iterations and, when paired with writing and early feedback, enables me to release early and iterate instead of waiting for a significant feature to be completed and guess what possible users might want. <h3>Current project status</h3> The current status of the project: Building the platform and the Thus, today is a good day to launch this. As good as any other day! Wish me luck! 2024-01-10 https://learn.shortruby.com/blog/early-launch https://learn.shortruby.com/blog/early-launch Cycle 1 - Building a welcoming place <h2>Context</h2> I have limited time to invest in building the app and making the content. Probably a couple of hours per week. Thus, it is essential to be very strict with what I build and where to put my effort. So I am going to maintain a list of things that I work on for this project and I will group them under a theme or cycle. <h2>Cycle 1: Building a welcoming place</h2> <h3>The theme</h3> The central theme of this first cycle is to make the website <a href="https://learn.shortruby.com">learn.shortruby.com</a> a welcoming place for visitors. There will be two metrics that I will watch for this: <ol> <li>PageSpeed insights (looking at performance, accessibility and SEO)</li> <li>Number of visitors</li> </ol> The focus of this cycle will be on improving PageSpeed Insights. Here is the current report: <a href="https://pagespeed.web.dev/analysis/https-learn-shortruby-com/9kxackelgp">link</a> <img alt="Image showing mobile pagespeed report" src="https://images.learn.shortruby.com/mobile-pagespeed-insights.webp" /> <img alt="Image showing desktop pagespeed report" src="https://images.learn.shortruby.com/desktop-pagespeed-insights.webp" /> <h3>Small projects</h3> Here is a list of small projects to achieve the goal of this cycle. <ol> <li>Add RSS feed for the blog</li> <li>SEO: Add <a href="https://github.com/kpumuk/meta-tags">meta-tags</a> gem to the app - see as the source of inspiration <a href="https://github.com/marcoroth/hotwire.io">Hotwire.io source code</a></li> <li>SEO: Transform images to webp format</li> <li>SEO: Fix issues from PageSpeed report</li> <li>Accessibility: Fix issues from PageSpeed report</li> <li>Feature: Add subscribe to get course updates - when they launch, pricing …</li> <li>Remove the empty state buttons: Buy Now and See More. Replace them with CTA to subscribe when the course is launched.</li> <li>Add automatic Sitemap generation</li> </ol> <h3>Decisions to make</h3> I have to decide the following: <ol> <li>How do I manage the list of people that want to know when I launch? Is this a good time to list more general subscribers so that I can share what I work on and not be specific to a product?</li> <li>What analytics to add to the website? So far, I have used Plausible for all my websites. I like it and there is no reason to change. I still ask myself the question: Is there something else to add? Should I spend time to look around?</li> </ol> That’s it for now. Let’s build and share! 2024-01-04 https://learn.shortruby.com/blog/cycle1-building-an-welcoming-place https://learn.shortruby.com/blog/cycle1-building-an-welcoming-place The initial pitch for an email course Here is why I decided to build this platform and some high-level plans of what I am trying to do with it. <h2>The problem</h2> Staying up to date with the evolution of technology is among the core tasks of a software developer. There are multiple ways to achieve this: reading social media, subscribing to a newsletter, watching videos, reading articles, or reading books. <img alt="Graph showing current learning platforms" src="https://images.learn.shortruby.com/email-courses-fit.png" /> There is a missing product that should fit into the mix of deep dive with less effort than reading a book. <h2>The solution</h2> For lack of a better word, I will call this solution an email course. A series of emails are sent periodically. Usually, they are sent every week, but the user can choose to receive them more often. There can be other media to share the knowledge this way - split in chunks and consumed over time. My proposal is email because it is a means of communication that works well but leaves the reader’s attention and decision. It does not need to be read now; the reader can choose when and how to read it. The same can, of course, be said about a series of articles or YouTube videos. They all have their purpose and fit well within a diverse group. I like email because it is a two-way communication: it can be read, but I can reply quickly. It creates a communication channel. But I also like it because it is text, and text is an amazing way to express ideas and to discover new concepts. Any email course should be able to be restarted as many times as possible. <h3>Novelty</h3> This idea is not new. This idea has various forms - some more similar and some a bit different. I plan to focus on making it the best learning experience and, in the case of the content, to focus on Ruby and Ruby on Rails content. I will explore this as I build the platform and write the content. <h3>An example of an email course</h3> Here is one example of how I would split an email course into topics: <img alt="Example of email course about new features in Ruby" src="https://images.learn.shortruby.com/new-features-in-ruby.png" /> Of course, the actual content of each week might change based on the feedback and what I discovered while creating each week’s email. <h3>The interface</h3> As the primary medium is email, the interface should allow passwordless login via email. The user should be able to see the running and finished courses and restart any of them at any point. At the end of a course, there will be the option to download a PDF version containing the same content as the course. <img alt="Example of how the welcome screen might looks like" src="https://images.learn.shortruby.com/welcome-screen.png" /> <h3>Composing emails</h3> For composing emails, I will either use the default editor from Rails and send emails as they are formatted by Trix or compose the emails in any other email delivery service and then, from the app, trigger the end of that email from there. I will these two solutions and pick one that first best the initial workflow. <h2>No Gos</h2> I will not build my email editor/composer. I will use an email delivery service - probably Postmark - and will only try implementing some email delivery-related tasks myself. The focus will be on the content and providing a simple way to configure when the emails will be sent. <h2>Conclusion</h2> This is the initial pitch about what I want to create and why I want to create it. I will try to post as often as possible about how I think about building this product. 2024-01-03 https://learn.shortruby.com/blog/the-initial-pitch-for-an-email-course https://learn.shortruby.com/blog/the-initial-pitch-for-an-email-course What I plan to write Hello world! I noticed over the years that writing things down helps me gain clarity and focus. So, I am launching the blog section of this product, even if the product still needs to be built, as an exercise for me to write down my thoughts as I build this learning product. The content that you will discover here will be a mix of: <ul> <li>product decisions and explorations</li> <li>technical assessments</li> <li>technical decisions</li> <li>retrospectives</li> <li>sharing the progress</li> </ul> I plan to be as open as possible and share my thoughts as I create this product in the spirit of #buildinpublic. That’s it for now! 2024-01-02 https://learn.shortruby.com/blog/what-i-plan-to-write https://learn.shortruby.com/blog/what-i-plan-to-write