I know about elixir since 2017 or so when I first saw Chris McCord vid on YouTube about Phoenix. Always wanted to try but never had a chance. Last year I decided to build a product for my own needs and thought what if I use Elixir/Phoenix for that.

To start - I decided to use boilerplate. I won't be sharing the name, but overall I wasn't really happy about it. I had to rewrite about 70% of code because it simply didnt work for my needs, even though my app isnt that special and doesnt have anything non standard. Its simply code wasn't really extendable or reusable, so for my next product I will probably just start with empty PHX app.

It took a bit of time to get used to Elixir functional approach. I could not understand Quote/Unqoute concept until very recently, but that didnt stop me from implementing most of my app with out it. Ecto concept was always not the most pleasant. While I understand why it was made that way, I had cheatsheets always with me simply because I could not memorize function names and arguments, esp when you can use macro syntax for things like select, etc.

LiveView is miles ahead of Rails's turbo. At some point I was even overusing it for simple UI interactions such as opening dropdown, etc. Later I refactored code to use Alpine.js for everything UI related and I'm happy about that. Hooks are really nice addition too, but I only used it once in my case. Just LV and Alpine.js was enough for me. I live in Europe, but I host app on DO in NYC region and have no latency issues with LV. I even tested it through few VPN connections to add some latency and it was working better than most modern react based apps. And overall I was happy with ease of use. I don't really understand complexity made with layouts(root, live, app) so took a bit to get used to it.

ObanJob was nice surprise for me. Finally I didnt need to run another instance of app for background jobs(hello sidekiq) and it required 0 extra infra or maintenance. Maybe for big queues it would made sense, but I have few jobs running every few mins, so it works well.

I had issues with deployment. There are few ways to deploy apps and I went with dockerizing compilation. Dockerfile was pretty simple multistage build, but when running I had OOM errors on my 4gb instance. After hours of googling and debugging I found this ERL_MAX_PORTS=1024 which solved all my memory issues. It was just a message on elixir forum without much explanation.

Testing tools are a big rough. Rails has many useful gems to help with it like factory bot, etc. ElIxir/Phoenix seem like a bit behind in this terms(but I might just didnt find good tools or good approach).

What I really like - elixir's case statement. Handling different call results not much easier because of pattern match. So things like {:ok, result} -> ... {:error, message} -> helps to handle errors much easier. And overall pattern matching feature is super useful and helped me to write really good code comparing to same in ruby. It's also nice Phoenix has generated authentication code. Unlike from devise - it has minimal implementation, but it's really quick to add anything you need. In my case I added google/github authentication in just few hours.

Some of recent updates made regular controller/template/views a bit weird for me. For some reason now templates, views and controllers under same controller folder making it really hard to manage it, would be nice to have separate folder for templates/views outside of controllers.

The app I build - updatify.io is a release notes tool where you can embed widget to your web app. I also used LV to power the widget. I have some JS code to create modal, but then it just creates iframe inside with LV powered app. One of the features - blog which you can host on subdomain - took a bit of time to get sorted with subdomains. I came up with few plugs that helped me to serve requested blog on subdomain, and it was one of first things I covered with tests because I still feel like it could be done better. For some 3rd party services there isnt a package, so I had to write my own harness, but its not that hard and mostly can be done in matter of hour.

I also had few back and forth with image uploads. Originally I stored them in app, but eventually decided to move to CDN, because it was simply cheaper($5 for DO Spaces). Took a bit to understand ho presign_ function works and thats first time I used hooks. I still don't really like how its implemented and I feel like it could be done easier

Overall I'm really happy with my elixir/phoenix experience. I already pitched this tool for another paid project I'm about to start. The biggest complexity was to convince client there's enough developers on market to support it. For my own projects I plan to use it more. I'm not sure how well it will work just of API type of projects, since LV is a big part of framework and one of reasons people like it.

Added: I tried LiveViewNative few months ago. Saw Dockyard CEO post on twitter and gave it a try. Its in very early stages of development, but it can definitely has its own audience and niche. Its not be used for apps where you might be offline, but I feel like e-commerce type of apps could benefit from it

Today I want to show you how can you implement really advanced form(and not just) input components. By advanced I mean something like custom drop-downs, toggles, or anything other that you can't create/style with regular inputs

The idea is to use Alpine.js together with hidden inputs which would hold your input state and then wrap it into ViewComponent, so it could be reused in any of your forms

Implementation

As an example I use dropdown from screenshot above. This is tailwind styled component, but it is a good example of more advanced component.

This is how it would look like in simplest implementation

# custom_dropdown_component.rb
class CustomDropdownComponent < ViewComponent::Base
  def initialize(options:, selected_option: nil, form:, field_name:)
    @options = options
    @selected_option = selected_option
    @form = form
    @field_name = field_name
  end

  private

  attr_reader :options, :selected_option, :form, :field_name
end

# custom_dropdown_component.html.erb

<div x-data="{ open: false, selectedOption: '<%= selected_option %>' }" class="relative pointer-events-auto w-[28.125rem] text-[0.8125rem] leading-5 text-slate-700">
  <div class="font-semibold text-slate-900">Assigned to</div>
  <div class="relative mt-1">
  <button @click="open = !open" type="button" class="w-full bg-white border border-gray-300 rounded-md shadow-sm px-4 py-2 text-left cursor-default focus:outline-none focus:ring-1 focus:ring-indigo-500 focus:border-indigo-500 sm:text-sm">
    <span x-text="selectedOption || 'Select an option'"></span>
    <span class="ml-3 absolute inset-y-0 right-0 flex items-center pr-2 pointer-events-none">
      <!-- Heroicon name: solid/selector -->
      <svg class="h-5 w-5 text-gray-400" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" fill="currentColor" aria-hidden="true">
        <path fill-rule="evenodd" d="M10 3a1 1 0 01.707.293l3 3a1 1 0 01-1.414 1.414L10 5.414 7.707 7.707a1 1 0 01-1.414-1.414l3-3A1 1 0 0110 3zm-3.707 9.293a1 1 0 011.414 0L10 14.586l2.293-2.293a1 1 0 011.414 1.414l-3 3a1 1 0 01-1.414 0l-3-3a1 1 0 010-1.414z" clip-rule="evenodd" />
      </svg>
    </span>
  </button>
  </div>

  <div x-show="open" @click.away="open = false" class="absolute z-10 mt-1 w-full bg-white shadow-lg max-h-60 rounded-md py-1 text-base ring-1 ring-black ring-opacity-5 overflow-auto focus:outline-none sm:text-sm">
    <% options.each do |option| %>
      <div @click="selectedOption = '<%= option[:value] %>'; open = false" class="cursor-pointer select-none relative py-2 pl-3 pr-9 hover:bg-indigo-600 hover:text-white">
        <%= option[:value] %>
      </div>
    <% end %>
  </div>
  <%= form.hidden_field field_name, 'x-model': "selectedOption" %>

  <div class="mt-2 text-slate-900">Current selected value inside hidden_field: <span x-text="selectedOption"></span></div>
</div>

# Your template

<%= form_with do |f| %> # There can be your form for your model
  <%= render(CustomDropdownComponent.new(form: f, field_name: :test, options: [{id: 1, value: 'John Doe'}, {id: 2, value: 'Jane Doe'}, { id: 3, value: 'Tobias Luetke'}]))%>
<% end %>

And final result would look like below

All the magic happens thanks to this:

<%= form.hidden_field field_name, 'x-model': "selectedOption" %>

where x-model is responsible to setting proper value to hidden_field upon any action from page. So when you click on any of dropdown elements

<div @click="selectedOption = '<%= option[:value] %>'; open = false"><%= option[:value]</div> we have @click handler which sets `selectedOption` to interpolated value of our option.

You can have any interface you prefer, either hash or specific DropdownItem class which has needed methods for your case.

Conclusion

With this approach you can have any form inputs you can come up with or find online. For example for tailwind there are few really cool UI kits which you can use right away. This can save time on your UI, especially if you work on MVP and you'd prefer to work on core features rather than UI

By using ViewComponent you also make your UI more reusable, since all form inputs can be used across all your forms not just one

For more interesting content follow me on X where I post daily

Recently, I’ve been working on an app core intended for distribution as a white-label solution. For those unfamiliar, a white-label solution involves creating code that can be customized into different apps for various clients. So basically it's the same app but can be with different design, backend endpoint, images/logos, sounds, etc.

Many restaurants run on same platform with just different color scheme, name and icon. There are many other industries where this approach is normal, as you don't need to develop app from scratch, but can use existing solutions.

In this article I want to show my approach to building white-label solutions with Flutter and Fastlane.

Why Fastlane you might ask? When you have fewer than five apps, manual deployment is manageable and doesn't take long. When you have few dozens of apps - you don't want to deploy it manually as it will take hours and hours of monotonous work.

Flutter

Before automating the build, we need to prepare our app for white-labeling. There are few general approaches. Some folks prefer to go with Flavors/BuildSchemes. I prefer to go with ENV variables.

In my case, the build process looks like this:

flutter build ipa --dart-define=MY_VAR1=value --dart-define=MY_VAR2=value

You can also use --dart-define-from-json and pass a path to json, but you'll see why I went this way

And then inside my flutter app I extract all ENV vars as constants to use later in my app

static const primaryColorHex = String.fromEnvironment('MAIN_COLOR');

Fastlane & CI builds

Now to more complex part. Building with CI is a regular thing. Most of apps are built in CI as part of CI CD pipelines. Either for testing purposes or for App Store deployment.

Since we already had few dozens on clients willing to have their white-labelled versions I had to come up with solution when I didn't have to spend days adding new clients. The solution is very simple - use Fastlane to build all apps at once with Github Actions(or any other CI provider). Fastlane is basically a set of Ruby lang methods that does something. There are existing lanes or you can create your own for your specific needs. Its best to have someone familiar with Ruby while creating your own custom lanes/steps

I started with json config file which looked like following. Where FIREBASE_PROJECT_ID is uniq value per each client(yes we use firebase for auth and some other things).

{ "FIREBASE_PROJECT_ID": {
    "APPSTORE_BUNDLE_ID": "com.myapp.client",
    "DEV_API_URL": "https://dev.endpoint.com",
    "PROD_API_URL": "https://prod.client.endpoint.com",
    "DISPLAY_NAME": "App Name",
    "COMPANY_NAME": "Company Name",
    "MAIN_COLOR": "#000000",
    "COUNTRY_CODE": "US",
    "LOGO_DATA": "..ommited BASE64 encoded image"
   }
}

To add a new client, I simply need to add a new section to this JSON file. Eventually this JSON file was moved to server and it takes few clicks to add new client via web form, but for ease of understanding lets stick to local JSON config.

Before actually deploying even test build we need manually create app bundle and app itself on appstoreconnect. We can automate this as well, but I haven't get there. Overall it takes 10-15 minutes to create new bundle ID and new app on appstoreconnect, fill in all information(it needs to be done only once per app). Same time applies to Google Play.

To save dev time I recorded few videos explaining how to do this, so even non tech staff can also do the job.

Now it's the most complicated step - building. Here's my Fastfile with comments on each step

default_platform(:ios)

GIT_AUTHORIZATION = ENV["GIT_AUTHORIZATION"]
TEMP_KEYCHAIN_USER = 'temp_keychain'
TEMP_KEYCHAIN_PASSWORD = 'temp_keychain_password'


# methods below are service methods that helps me to setup build config
def create_temp_keychain(name, password)
  create_keychain(
    name: name,
    password: password,
    unlock: false,
    timeout: 0
  )
end

def ensure_temp_keychain(name, password)
  create_temp_keychain(name, password)
end
# This method provides me specific PROJECT configuration based on
# provided ENV variable PROJECT ID.
# This is done in order to build single app per fastlane launch
def build_configuration
  raise 'PROJECT_ID is not set' unless ENV['PROJECT_ID']

  config = build_configurations[ENV['PROJECT_ID']]

  raise 'Configuration not found' unless config

  config
end

# This just parses json file and provides me a ruby JSON object with
# all configurations
def build_configurations
  @configs ||= JSON.parse(File.read('config.json'))
end

# This method creates me string with all my dart defines ENV vars
def build_args
  args = {
    'PROJECT_ID': build_configuration['PROJECT_ID'],
    ...other env vars
  }
  raise 'Build args is not set. Make sure you have following ' if args.values.any?(&:nil?)
  args.map { |k, v| "--dart-define=#{k}=\"#{v}\"" }.join(' ')
end


platform :ios do
  desc "Push a new beta build to TestFlight"

  # This lane launches github action that triggers 
  # new actions to build each app separately
  # In case 1 app crashes - you dont want to have all following apps
  # to be skipped.
  # This also allows you to restart failed job later
  lane :beta_all do
    api_endpoint = "https://api.github.com/repos/myrepo/myapp/actions/workflows/deploy_ios_project.yml/dispatches"
    auth_token = ENV["GIT_AUTHORIZATION"]

    build_configurations.each do |project_id, config|
      payload = { "ref" => "main", "inputs" => { "project-id" => project_id } }.to_json
      uri = URI.parse(api_endpoint)
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true
      request = Net::HTTP::Post.new(uri.request_uri, 'Content-Type' => 'application/json', 'Authorization' => "Bearer #{auth_token}")
      request.body = payload
      response = http.request(request)

      unless response.code == "204"
        UI.error("Failed to trigger GitHub Action: #{response.code} - #{response.body}")
      end
    end


  end

  lane :beta do
    ENV["APP_IDENTIFIER"] = build_configuration['APPSTORE_BUNDLE_ID']
    ENV['APP_IDENTIFIERS'] = build_configurations.values.map{ |e| e['APPSTORE_BUNDLE_ID'] }.join(',')
    keychain_name = TEMP_KEYCHAIN_USER
    keychain_password = TEMP_KEYCHAIN_PASSWORD
    setup_ci if ENV['CI']
    ensure_temp_keychain(keychain_name, keychain_password)

    # IF BUILD_NUMBER is missing - we do not proceed
    # BUILD_NUMBER corresponds to CI build number
    raise 'BUILD_NUMBER is not set' unless ENV['BUILD_NUMBER']

    increment_build_number(xcodeproj: "Runner.xcodeproj", build_number: ENV['BUILD_NUMBER'])

    update_info_plist( # update app identifier string
      plist_path: "Runner/Info.plist",
      app_identifier: build_configuration['APPSTORE_BUNDLE_ID'],
      display_name: build_configuration['COMPANY_NAME']
    )

    match(type: 'appstore', readonly: false, git_basic_authorization: Base64.strict_encode64("name:#{GIT_AUTHORIZATION}"), app_identifier: build_configuration['APPSTORE_BUNDLE_ID'])

    update_project_provisioning(
      xcodeproj: "Runner.xcodeproj",
      build_configuration: "Release",
      target_filter: "Runner",
      profile: ENV["sigh_#{build_configuration['APPSTORE_BUNDLE_ID']}_appstore_profile-path"]
    )

    # In order to have own set of App Icons we need to generate IconSet for every client
    filename = "#{Time.now.to_i}_logo.png"
    # Decode the base64 string and write it to a file
    raise 'LOGO_DATA is missing. Please encode your 1024*1024 logo to base64 and add to LOGO_DATA key' unless build_configuration['LOGO_DATA']
    File.open(filename, "wb") do |file|
      file.write(Base64.decode64(build_configuration['LOGO_DATA']))
    end

    # Create appicon for ios
    base_dir = File.expand_path File.dirname(__FILE__)
    appicon_image_file = "#{base_dir}/#{filename}"
    appicon(appicon_image_file: appicon_image_file,
            appicon_path: "Runner/Assets.xcassets",
            appicon_devices: [:ipad, :iphone, :ios_marketing])

    # Create main_logo.png file which used as logo in app
    Dir.chdir("../../assets/images") do
      File.open('main_logo.png', "wb") do |file|
        file.write(Base64.decode64(build_configuration['LOGO_DATA']))
      end
    end

    # We need to run manual build since at the time of creating this lane there was no way to pass dart-define to xcode build
    sh("flutter pub get")
    sh("dart pub global activate flutterfire_cli")
    begin
      Dir.chdir "../.." do
        sh("flutterfire configure --yes --project=#{build_configuration['PROJECT_ID']} --web-app-id=#{build_configuration['APPSTORE_BUNDLE_ID']} --macos-bundle-id=#{build_configuration['APPSTORE_BUNDLE_ID']} --platforms=ios,android --ios-bundle-id=#{build_configuration['APPSTORE_BUNDLE_ID']} --windows-app-id=#{build_configuration['APPSTORE_BUNDLE_ID']} --ios-build-config=Release --ios-out=ios/Runner/GoogleService-Info.plist --android-package-name=#{build_configuration['APPSTORE_BUNDLE_ID']} --token #{ENV['AUTH_TOKEN']}")
      end
    end


    ### Set reversed client id to Info.plist. This needed for google sign in to work on ios platform
    reversed_client_id = nil
    Dir.chdir "../" do
      google_service_info_path = "Runner/GoogleService-Info.plist"
      google_service_info = Plist.parse_xml(google_service_info_path)

      reversed_client_id = google_service_info["REVERSED_CLIENT_ID"]
    end

    update_info_plist( #update CFBundleURLTypes
      xcodeproj: "Runner.xcodeproj",
      plist_path: "Runner/Info.plist",
      block: proc do |plist|
        url_types = plist["CFBundleURLTypes"]
        if url_types && !url_types.empty?
          url_type = url_types[0]
          url_type["CFBundleURLName"] = build_configuration['APPSTORE_BUNDLE_ID']
          if url_type["CFBundleURLSchemes"] && !url_type["CFBundleURLSchemes"].empty?
            url_type["CFBundleURLSchemes"][0] = reversed_client_id
          end
        end
      end
    )

    sh 'pod install'
    # Run flutter build ios to generate proper flutter_export_environment.sh. No need to sign app yet
    sh "flutter build ipa #{build_args} --no-codesign"

    build_app(workspace: "Runner.xcworkspace", scheme: "Runner")
    upload_to_testflight(skip_waiting_for_build_processing: true)
    delete_temp_keychain(keychain_name)
    puts "Build #{lane_context[SharedValues::BUILD_NUMBER]} was uploaded to Test Flight"
  end
end

While this flow might look complex - it wasn't done all at once. I was doing step by step to get a build in the end. In your case you might not have firebase, or you might need an extra step to add something specific to your app.

Running in CI

In my Fastfile above you noticed I have 2 lanes, one to deploy app apps and 1 to deploy single app. That was done on purpose. It's simple - when I have new app version I want to deploy them all at once. But I also want to restart build if it fails for some reason(timeout, etc).

Note - GitHub actions uses 4x minutes to build iOS apps, so run debug your Fastfile locally until it completely succeeds.

Conclusion

I skipped part with App Store release, since it's just 2 lines of code calling according Lane. I also skipped google play, since its the same steps(just different on build.gradle configuration)

Setting up this pipeline helped me to offload all routine work to be done by CI and support team. When support team wants to add new client - they add it via web form and create according apps in appstore/google play. Whole process takes less than 30 minutes and has to be done only once. All next deploys are fully automatic.

With this flow we save hundreds of hours every month and the more clients we have more time we save.

Follow me on Twitter for more interesting content.

Yes. I, as indie hacker with no budget to promote my app updatify.io, use all available tools. OG protocol is one of them. It takes literally few minutes to add, but it greatly improves your visual visibility on social networks. Here's few screenshots with/without and how it differs when you post links to your SaaS on social networks

What is the Open Graph Protocol?

The Open Graph protocol is a set of meta tags that allows web developers to control how their web pages are represented when shared on social media platforms and other websites. Developed by Facebook in 2010, it has since become a widely adopted standard across the web.

Why is it Useful for Web Apps?

1. Improved Social Sharing: When users share your web app's pages on social media, Open Graph tags ensure that the content appears in an attractive and informative way, increasing the likelihood of engagement.

2. Better Brand Control: You can specify exactly which images, titles, and descriptions appear when your content is shared, maintaining consistent branding across platforms.

3. Increased Click-through Rates: Well-crafted Open Graph tags can make your shared links more appealing, potentially increasing click-through rates from social media platforms.

4. Enhanced SEO: While not a direct ranking factor, properly implemented Open Graph tags can indirectly benefit your SEO by improving social signals and increasing engagement.

5. Cross-platform Compatibility: Many platforms beyond Facebook, including Twitter, LinkedIn, and Pinterest, recognize Open Graph tags, ensuring consistent presentation across various social networks.

How to Add Open Graph Tags to Your Website

To implement Open Graph tags on your website, you need to add specific <meta> tags within the <head> section of your HTML. Here are the basic Open Graph tags you should consider:

1. og:title: The title of your page.

2. og:type: The type of your content (e.g., website, article, product).

3. og:image: The URL of the image you want to appear when your content is shared.

4. og:url: The canonical URL of your page.

5. og:description: A brief description of your content.

Here's an example of how to implement these tags:

<head>
    <meta property="og:title" content="Updatify | Instant product updates"/>
    <meta property="og:type" content="https://updatify.io"/>
    <meta property="og:image" content="https://link_to_image"/>
    <meta property="og:url" content="https://example.com/page"/>
    <meta property="og:description" content="A brief description of your page content."/>
</head>

You can also customize these values for each page separately. For ex if its blog - you might want to have different title or image or description.

Twitter specific tags

Besides regular "og:" tags twitter has few extra tags you can use to improve visibility on twitter platform.

<meta name="twitter:card" content="summary_large_image" /> 
<meta name="twitter:image" content="URL TO Image"
<meta name="twitter:site" content="@handle for site in case you use separate account for your app on twitter" />
<meta name="twitter:creator" content="@handle of the author, usually yours" />

For "twitter:card" you can have either "summary" or "summary_large_image. Here on screenshot below you can see difference between "summary" and "summary_large_image" types of content

Verification

The easiest way to verify how your link looks on various platforms - simply post it. Some platforms provides preview even before its posted. Also if you even posted before - platform might have your link cached, so you might see old preview. To overcome this - simply add / to end of your link, so it would look like https://updatify.io/ or even extra query param. It takes time for cache to expire.

Summary

By implementing Open Graph tags, you're taking a significant step towards improving your web app's visibility and engagement on social media platforms. As you saw on screenshots above - it changes how users see your links and you can provide more value to them even without making them click. It's also very important what kind of content provided. There are services which allows you to dynamically generate OG links based on your current page UI.

Follow me on Twitter where I provide more interesting content and my journey building updatify.io

The Rails Way Meets Modern JavaScript

Ruby on Rails has always been about developer productivity and happiness. Alpine.js shares this philosophy by providing a minimal yet powerful set of tools to create dynamic interfaces. Here's why it's a great fit for Rails developers:

1. Minimal Learning Curve: Alpine.js uses simple directives that feel familiar to anyone who has worked with Rails' ERB templates. You can start using it productively within minutes.

2. Progressive Enhancement: Like Rails' Turbolinks, Alpine.js allows you to enhance your server-rendered HTML progressively. This aligns perfectly with the Rails approach to web development.

3. No Build Step Required: Unlike many modern JavaScript frameworks, Alpine.js doesn't require a complex build process. You can include it with a single <script> tag, making it easy to integrate into your Rails asset pipeline.

4. Plays Well with Turbolinks: Alpine.js works seamlessly with Turbolinks, maintaining state and event listeners even after page changes.

5. Keeps Your Rails Views Clean: With Alpine.js, you can add interactivity directly in your HTML, keeping your JavaScript separate and your Rails views clean and readable.

Why You Might Not Need a Separate UI Framework

When using Alpine.js with Rails, you may find that you don't need a separate UI framework at all. Here's why:

1. Rails Has Great Helpers: Rails comes with a rich set of view helpers that can generate most of the HTML structure you need. Alpine.js can then add the necessary interactivity.

2. CSS Frameworks Are Enough: Most UI needs can be met with a good CSS framework like Bootstrap or Tailwind CSS. Alpine.js can handle the interactive parts, eliminating the need for JavaScript-heavy UI frameworks.

3. Easier Maintenance: With fewer moving parts and external dependencies, your application becomes easier to maintain and upgrade over time.

Getting Started with Alpine.js in Your Rails Project

Adding Alpine.js to your Rails project is straightforward. Here's a quick guide:

1. Add the Alpine.js script to your application layout:

    <%= javascript_include_tag 'https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js', defer: true %>
   

2. Start using Alpine.js directives in your views. For example, to create a simple dropdown:

    <div x-data="{ open: false }">
      <button @click="open = !open">Toggle Dropdown</button>
      <ul x-show="open" @click.away="open = false">
        <li><%= link_to 'Option 1', '#' %></li>
        <li><%= link_to 'Option 2', '#' %></li>
        <li><%= link_to 'Option 3', '#' %></li>
      </ul>
    </div>
   

Conclusion

Alpine.js offers Ruby on Rails developers a pragmatic approach to adding interactivity to their applications. It aligns well with the Rails philosophy, integrates easily into existing projects, and often eliminates the need for heavier UI frameworks. By leveraging the power of Rails helpers, and Alpine.js for lightweight interactivity, you can create modern, responsive web applications without straying far from the Rails ecosystem you know and love. For more complex cases you can use Turbo frames to replace parts of UI and use alpine for interactivity, it works well together

Give Alpine.js a try in your next Rails project – you might be surprised at how much you can accomplish with so little.

Follow me on Twitter for more interesting content

That's where https://viewcomponent.org comes to stage. Essentially it's plain ruby object which contains some logic and html file which uses objects and logic from ruby class. Here's dropdown component I created some time ago.

# app/components/dropdown_component.rb
class DropdownComponent < ViewComponent::Base
  def initialize(form:, field_name:, options:, label: nil, placeholder: "Select an option")
    @form = form
    @field_name = field_name
    @options = options
    @label = label || field_name.to_s.humanize
    @placeholder = placeholder
  end

  private

  attr_reader :form, :field_name, :options, :label, :placeholder
end

followed by same name html file

<!-- app/components/dropdown_component.html.erb -->
<div x-data="{ open: false, selected: '' }" class="relative">
  <%= form.label field_name, label, class: "block text-sm font-medium text-gray-700 mb-1" %>
  <div @click.away="open = false" class="relative">
    <button @click="open = !open" type="button" 
            class="relative w-full bg-white border border-gray-300 rounded-md shadow-sm pl-3 pr-10 py-2 text-left cursor-default focus:outline-none focus:ring-1 focus:ring-indigo-500 focus:border-indigo-500 sm:text-sm">
      <span x-text="selected || '<%= placeholder %>'" class="block truncate"></span>
      <span class="absolute inset-y-0 right-0 flex items-center pr-2 pointer-events-none">
        <svg class="h-5 w-5 text-gray-400" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" fill="currentColor" aria-hidden="true">
          <path fill-rule="evenodd" d="M10 3a1 1 0 01.707.293l3 3a1 1 0 01-1.414 1.414L10 5.414 7.707 7.707a1 1 0 01-1.414-1.414l3-3A1 1 0 0110 3zm-3.707 9.293a1 1 0 011.414 0L10 14.586l2.293-2.293a1 1 0 011.414 1.414l-3 3a1 1 0 01-1.414 0l-3-3a1 1 0 010-1.414z" clip-rule="evenodd" />
        </svg>
      </span>
    </button>
    <div x-show="open" 
         x-transition:enter="transition ease-out duration-100" 
         x-transition:enter-start="transform opacity-0 scale-95" 
         x-transition:enter-end="transform opacity-100 scale-100" 
         x-transition:leave="transition ease-in duration-75" 
         x-transition:leave-start="transform opacity-100 scale-100" 
         x-transition:leave-end="transform opacity-0 scale-95" 
         class="absolute z-10 mt-1 w-full bg-white shadow-lg max-h-60 rounded-md py-1 text-base ring-1 ring-black ring-opacity-5 overflow-auto focus:outline-none sm:text-sm">
      <% options.each do |option| %>
        <div @click="selected = '<%= option[:label] %>'; open = false" 
             class="cursor-default select-none relative py-2 pl-3 pr-9 hover:bg-indigo-600 hover:text-white">
          <%= option[:label] %>
        </div>
      <% end %>
    </div>
  </div>
  <%= form.hidden_field field_name, 'x-model': 'selected' %>
</div>

and then, in order to use it simply call following anywhere in your html.

<%= render(DropdownComponent.new(
  form: form,
  field_name: :category,
  options: Category.all.map { |c| { value: c.id, label: c.name } }
  label: 'Select a category',
  placeholder: 'Choose a category'
)) %>

Having just 1 component won't make much difference, but when you create/migrate majority of your components - it will start to save you time when start reusing components. Another benefit - is when you decide to restyle your app, you'll have to do it only once - in your components.

You are not limited to just classes. You can also add JS code or anything else that handles your UI. I usually work with Alpine.JS and have components such as Dropdown, etc, where everything UI handled inside and the code above is a great example to show how its used.

Once you have many components you can add https://github.com/lookbook-hq/lookbook which is as name states - lookbook for your components. Instead of going to component sources, you can predefine a set of variants and just copy paste them when you need, just like for any UI kit.

Conclusion

While both partials and ViewComponents serve the purpose of creating reusable UI elements, ViewComponents offer significant advantages in terms of organization, testability, and performance. By using ViewComponents, you can create more maintainable and scalable view layers in your Rails applications and using Lookbook you can save yourself time by copy pasting instead of writing from scratch.

Follow me on Twitter for more interesting stuff!

With flutter and you can build really performance apps thanks to the way flutter renders contents. Recently I’ve created a cross platform app and open sourced it - [http://github.com/avdept/JellyBoxPlayer] The app runs on iOS/android but also on macOS. Windows and linux version still in works as it miss 1 feature that macOS has. And now a bit of my experience using flutter to create both mobile and desktop app.

Originally idea was to have just mobile app, but having iPad design I decided to add desktop support. I only had few minor changes to do and this is the result -

Tools and packages Turned out there’s only one 3rd party package I used - https://pub.dev/packages/responsive_builder which provides you a tools to check what kind of device you run it on, screen breakpoints, etc. So my code started to look like following

ScrollablePageScaffold(
      useGradientBackground: true,
      navigationBar: PreferredSize(
        preferredSize: Size.fromHeight(_isMobile ? 60 : 100),
        child: Padding(
          padding: EdgeInsets.symmetric(horizontal: _isMobile ? 16 : 30),
          child: Row(
            mainAxisAlignment: MainAxisAlignment.spaceBetween,
            children: [
              _pageViewToggle(),
              _filterButton(),
            ],
          ),
        ),
      ),
      loadMoreData: loadMore,
      contentPadding: EdgeInsets.only(
        left: _isMobile ? 16 : 30,
        right: _isMobile ? 16 : 30,
        bottom: 30,
      ),
)

Depending on if it’s mobile or desktop I was able to use different paddings. Another case - hide/show element completely depending on platform

Visibility(
  visible: _isDesktop,
  child: CustomNavigationRail()
 )

One of the issues I had - flutter doesn’t allow setting min size for window when on desktop platforms. To fix this I found a window manager package and came up with this solution:

if (Platform.isMacOS || Platform.isLinux || Platform.isWindows) {
    await windowManager.ensureInitialized();

    const windowOptions = WindowOptions(
      size: Size(1440, 1000),
      minimumSize: Size(1280, 800),
      center: true,
      backgroundColor: Colors.transparent,
      skipTaskbar: false,
      titleBarStyle: TitleBarStyle.hidden,
    );

    await windowManager.waitUntilReadyToShow(
      windowOptions,
      () async {
        await windowManager.show();
        await windowManager.focus();
      },
    );
  }

The idea here to set size and also min size, but also prevent flickering when app starts, for this you got to wait until window is ready and then you can show and focus it.

The missing tools

Unfortunately flutter doesn’t know how to work with global keybindings. In my case it was media keys. There aren’t many available packages so I created my own. Since my main platform is macOS I started with it. I found MediaKeyTap swift package and based on that build flutter plugin. Main functions looks like below.

public static func register(with registrar: FlutterPluginRegistrar) {
    let channel = FlutterMethodChannel(name: "mediakeys_proxy", binaryMessenger: registrar.messenger)
    let instance = MediakeysProxyPlugin(channel: channel)
    registrar.addMethodCallDelegate(instance, channel: channel)
    instance.startMonitoring()
    let options: NSDictionary = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String : true]
    AXIsProcessTrustedWithOptions(options)
  }

  public func handle(mediaKey: MediaKey, event: KeyEvent) {

    switch mediaKey {
    case .playPause:
        self.sendEventToFlutter(eventName: "playPause")
    case .previous, .rewind:
        self.sendEventToFlutter(eventName: "prev")
    case .next, .fastForward:
        self.sendEventToFlutter(eventName: "next")
    }
  }

Conclusion

Over last few years flutter became really mature framework. Out of box it covers 90% possible use cases and it’s possible to use it without any 3rd party packages, but they surely make some things easier. Desktop platform still missing few features, but because of how flutter plugins works its really easy to come up with custom plugin solution to solve your problem.

Follow me on X(Twitter)

What is Self-Hosting and How Does It Work?

When people hear "self-hosting," they often imagine server racks filled with expensive equipment that offer little to no real benefits. But that’s not the case.

Self-hosting means you host cloud applications yourself on your own (or rented) hardware. This can be as affordable as a DigitalOcean droplet or another VPS provider. Only you and the people you grant access to can use the software. With cloud providers, everything is straightforward—you pay a monthly subscription of $5-10 and get the hardware. True self-hosting, however, means you manage everything on your own hardware.

To get started, you don't need anything beyond your own computer. If you want more stability, consider a Raspberry Pi. This inexpensive microcomputer can run Linux distributions (like Raspbian) and has enough computing power to run multiple apps with no problems. It’s energy-efficient and portable, perfect for taking your self-hosted software wherever you go.

There are plenty of different software you can self-host. To start, check out this awesome GitHub curated list of apps.

My Self-Hosting Journey

When I started, I went with Pi-hole, an app that blocks ads across your entire network. Later, I added several Servarr apps to help manage my music collection, which I’ve been building since the mid-2000s. To play my music, I also installed Jellyfin. Nowadays, I’ve developed a client app for Jellyfin called JellyBox, which is also open source.

As of now I run about 20 different apps, which handles content playing and managing, backups, content creation and various networking tools. I managed to get myself used HP DL 380G9 Server which has enough bays for storage and enough computing power to run everything I have with no issues, but be careful - this route can be a rabbit hole, and you end up with 32U rack cabinet with a bunch of hardware.

Why Should You, as a Software Engineer, Care?

1. Hands-on Docker Experience: Most self-hosted apps have Docker images, so you can install them quickly without needing additional OS packages.

2. Command Line Proficiency: You’ll get more comfortable with the command line, reading logs, and troubleshooting.

3. Networking Knowledge: Learn about networking, reverse proxies (like Traefik, which I discovered through self-hosting), and security by securing your services.

4. Problem-Solving Skills: Discover various solutions for different problems, potentially saving you money.

5. Open Source Contributions: Many self-hosted apps are open source. Contributing to these projects can enhance your CV and help you land better job opportunities.

The Business Benefits

Self-hosting isn’t just for personal use. At my company, ProdigyTech, I’ve installed several apps that save us significant money:

• Mattermost: A Slack alternative that’s been working perfectly for almost 1.5 years.

• Plausible: A website analytics service.

• Gitea: For git repository management and CI runners.

• Plane: A Jira-like project management tool.

These tools run on a $20 DigitalOcean droplet and save us about $700 monthly in subscription fees.

While working as a Ruby on Rails engineer on the StatusGator app, I also engaged in several side projects using Flutter. For those unfamiliar, Flutter is a powerful framework that allows you to build a mobile app once and deploy it on both iOS and Android platforms. This means you save on costs by not needing separate engineers for each platform. Changes made on one platform are reflected on the other, eliminating the need to duplicate efforts. I even built an open-source desktop client for Jellyfin called Jellybox Player using Flutter, demonstrating its versatility.

Drawing from this experience, I recognized that the features we were developing for StatusGator could also be effectively utilized via a mobile app, particularly for delivering push notifications. I took the initiative to propose this idea during one of our weekly meetings. It wasn't a detailed plan, just a simple suggestion on how our clients could benefit from a mobile app.

Due to my full-time job, I worked on this project during weekends, gradually building a Minimum Viable Product (MVP). Without a dedicated designer, I leveraged Flutter’s Material UI to replicate our web interface, making necessary adjustments for a mobile-friendly experience. The result was a functional MVP.

Once the MVP was ready, we distributed it via TestFlight within our team for internal testing and feedback. During this period, we also began mentioning the upcoming app in our sales calls, which generated significant interest from potential clients. The promise of a mobile app became a strong selling point, helping us secure additional deals even before the app was officially released.

What lessons did I learn from this experience? As a contractor, you are fully responsible for the impressions your client gets when working with you. One way to build long-term relationships is by offering additional value without extra cost. This approach pays off in the long run.

As a product owner, never underestimate the value of mobile apps. Regardless of the industry, everyone uses smartphones. Mobile apps often offer a quicker, more efficient way to perform tasks compared to websites, sometimes significantly boosting productivity.

For outsourcing companies, it's crucial to encourage engineers to be proactive. When engineers take initiative, everyone benefits.

In conclusion, any working business can benefit from a mobile app, and it's never too late to create one. Plus, building an MVP doesn't have to be expensive—it can cost as little as $2,000 to $3,000. With the right tools and approach, you can create something valuable without breaking the bank.

Going financial....

About a year ago I've joined a new startup called Cashews. I really liked the idea of providing users easy way to know how many can still they spend today without going broke by next salary, however I had 0 idea how should it work, since I dont have any financial education(and well, I've been broke by end of month many times) that seemed challenging to me and so I said - "Challenge accepted!"

Because it was a startup - we didn't have big budgets, team of managers, researchers, and all decisions were done by a team of 3(Hi Jonathan and Romano) and it resulted in really successful outcome, we were awarded with #1 Product of the day on PH badge.

What did #1 give us? First and most important - ProductHunt is a community of early adopters and people who wants to try new products before they reach wide audience or people who looking for better tools that currently exists on market. That means it's easy to get real feedback from users, without actually blaming you for doing something incorrectly or just showing wrong results. That also helped us to fix some bugs we weren't aware of, change UX to be even more user-friendly and generally it helped us to understand how awesome the Cashews is.

I was really anxious on how will it go, because the math behind calculations really complicated and the numbers not always obvious due to many variables involved. Surely, before releasing on ProductHunt we had long beta with lots of changes to our calculations, polishing the UI and UX(the UI/UX on most financial apps kinda complicated and usually flooded by features you most likely won't be using since the beginning). One of our beta users even reported that we helped him to find subscription which he wasn't using, but somehow it wasn't cancelled(that was a big win for us at that period)

How did we make it?

I had no ideas how to calculate user's spendable per period. First iteration was straightforward - take all user's income, take all expenses, subtract and divide by amount of days till end of month. But then - you understand that some people gets paid twice a month, or once in few months. Some people gets paid weekly. Some people gets paid in mid of month. First part of solution was - find proper, realistic spendings dataset. There are few publicly available online with depersonalised transactions. We tuned formula - however there still were edge cases when it didn't work. Another set of discussions, tuning and we end up with few different formulas for different user spending profiles. Looks good(more or less), but then we launch our closed beta, get some real user's and find out how differently people use their money and even how do they store them on their accounts or even having different banks for different purposes, such as - Bank1 for mortgage, Bank2 for leisure, Bank3 for savings, etc.

All previous work was discarded. We started over. Google spreadsheet was our best friend for couple weeks of trials and errors. That resulted in some very promising values that seemed to be correct according to our hand calculations. What also helped us a lot - visual debuggers. While working with list of database rows - its really hard to see whole picture of calculations. Our debuggers were simple SPAs which would actually breakdown calculations into smaller chunks, so we could understand where does the error comes from without need to export rows into spreadsheet and spending hours trying to understand why is it $1 instead of $25.

After months of work we finally got what we wanted. But it's not finished yet. With every new user we get more data. While 90% users have predictable spending patterns, rest 10% are different. And we constantly work to improve our calculations to cover as many spending patterns as possible. I won't go into details, but current calculations consists of more than 20 steps, and its growing up as we find new patterns and trying to make calculations more correct according to user's spending approach and their lifestyle.

Few technical and not so lessons I've learned working on Cashews

• Always use objects for api responses instead of arrays, even for most basic api endpoints, such as:

  {
  'items': ['A', 'B', 'C']
  }
  

  You never know when your client app will demand more data or just different format. Having object helps you to return even different responses depending on client app version.

• Always process requests in user's timezone. Make sure every request has user timezone, or you end up having many complaints that data shows incorrectly(most databases works in UTC timezone).

• Do not spend time on database query optimisations. Most likely database schema will change multiple times before you get final result. Save your time.

• I don't like to be Cpt. Obvious, but - write tests, cover api responses format, make sure that client will always get same response format as before.

• Do not be afraid to checkout your 2 days of work in favour of better solution. While working on cashews we discarded at least 2 different formulas which costed us literally weeks or even months in development time.

• Ruby on Rails still good choice for startups. Fast iterations to verify your ideas. Most likely you won't face any performance issues till you get your first 1M users.

• Google spreadsheet usually can save a lot of time when prototyping calculations.

• Do not overcomplicate your infrastructure until you get final result. Heroku will work well for most startups.

Summary

Am I happy with the final result? Yes, definitely. I've learned a lot not just about math and finances, but also how to plan your work when you not always know how to achieve best result. There's still lots of work to be done to cover as much users as possible, but the foundation we created makes it easy to introduce new variables into final calculation, add new integrations and basically just grow app but be bigger than just spendings predicting.

Now, when I pulled your attention, let me introduce myself. I'm engineer with over 10 years production experience in building different products, starting from small e-commerce and up to enterprise grade CRMs. I do not call myself engineer because I tend to use "most appropriate" technology that solves client's current problem in most efficient way. I know, that sounds like in those $5 online courses, but reality is - if you want to get paid more - be ready to adapt to client's needs, his team, his requests and even how exactly he approaches to his business.

For past 6 years I've been working as freelancer or leading small teams in cases where there are more work that I have time to work on it. During this time I did a lot of mistakes, learned tons of knowledge that you won't find anywhere online nor any courses will teach you.

The intention of this blog - to share my experience, not just coding, but also how do I approach to work, how do I do preproduction work and why it's necessary to do it, especially if you work alone or in small team. How to properly communicate with your client and get more work in future and many other things we all encounter in our everyday work

First blog post cannot go without list of daily technologies I use, so I'll share just so you could know, there will be some interesting stuff.

• Go
• Elixir
• Ruby(rails)
• Ember, Vue, Angular, React
• Flutter
• A bit of embedded development with STM32, NXP, NRF

Follow my blog to get some really interesting insights and useful knowledge which you can use in your everyday work!