DEV Community: Jan Peterka

Using Phlex helps me be a better programmer

Jan Peterka — Sat, 26 Jul 2025 12:33:09 +0000

What is Phlex?

If you are in the Ruby on Rails land, you might have noticed Phlex.

A little Ruby gem for building HTML and SVG view components.

, as it says on the website.

It was concieved by Joel Drapper as a new approach to view layer in Rails (and other web app frameworks, but I don't have any experience in that department).

Managing view layer in Rails app.

I'm pretty much new kid in Rails department (started with it ~5 years ago), so I don't feel like talking about the whole history of view stack in this framework. But even my experience with it (mostly in my ~15yr old $WORK project, and some new projects I started from scratch using Rails 7-8 ) is bit cumbersome:

there's the "golden standard" - erb templating.
- I don't like erb. It's just a lot of writing, and the code us just ugly in my view.
at $WORK, we use slim instead, and I prefer that, so I mostly use that!
- but for example when I was creating Rails generator I intend to publish, it makes sense to write it in erb, as much more people use that.
we also use ViewComponents, which I then used (mostly copy-pasted) in my other projects to save time.
- they are probably super powerful, but I have trouble understanding them. Also, I don't like having two files (rb + html.*) for one thing.
and of course you have partials and helper
- I 'm currently very suspicous of helpers. They are great until you shove logic into them (which can happen easily).

Also, for a long time, there were no component libraries for Rails! That's currently changing, as I'll soon mention.

As you see, I was not super happy about the stuff I used for view layer, but there wasn't much to do about that.
So, when Phlex came by, I was curious - would this be better for me?

Different, in a good way?

I wasn't sure.
One of the big things that Phlex does differently is that you only write Ruby. No HTML. No erb or slim or other templating. It's all ruby code.
Don't get me wrong, I absolutely love Ruby, but at the same time, I'm bit sceptical about approaches that try to "get rid" of some language - I don't for example think you should write Ruby/Python/.. instead of javascript.

With this mix of scepticism and curiosity, when I started new project, I wanted to play with Phlex a bit.
What did help was that I found RubyUI, nice library of components made with Phlex, which did speed up the initial prototype development by a lot.

It took me a bit to get a grasp, and I stumbled multiple time, as I don't fully understand how it all works. Also, I still had basic layouts and used simple_form (I wanted to use superform, which looks amazing, but it didn't support Phlex 2.x at the time I started the project. It should now, so maybe I'll give it a try now!), so there's some mixing of old code with new, which is all doable, just slows one down at first.

But then?
I found out I love it.
I'll show an example of a page I got to rewrite to Phlex on a different project, where I now use classic approach + ViewComponents, and try to describe why Phlex makes sense to me now:

Here's original controller:

# app/controllers/dashboards_controller.rb

class DashboardsController < ApplicationController
  def show
    @current_events = Current.member.events.current
    dashboard = Dashboard.new

    @future_events = selected_future_events

    @sboodles = []

    @unread_announcements = Current.member.unread_announcements[..2]
    @pinned_announcements = Current.member.pinned_announcements[..2]

    @tasks = Current.member.assigned_tasks.incomplete[..2]
    render Views::Dashboard::Show.new dashboard
  end

  private

    def selected_future_events
      nearest_performance = Current.member.events.future.includes(:type).find(&:performance?)
      nearest_events = Current.member.events.future.limit(3)

      if nearest_performance.present? && nearest_events.exclude?(nearest_performance)
        (nearest_events[..1] << nearest_performance).compact
      else
        nearest_events.compact
      end
    end
end

# app/views/dashboards/show.html.slim

- content_for :title, "nástěnka"

- if @current_events.any?
  = heading("právě probíhá")
  = render "events/card", event: @current_events.first

- if @future_events.any?
  = heading("nejbližší události")
  .grid.md:grid-cols-3.gap-4
    - @future_events.each do |event|
      = render "events/card", event:

- if @sboodles.any?
  = heading("aktivní sboodly")

- if @unread_announcements.any?
  = heading("nové příspěvky")
  .grid.md:grid-cols-3.gap-4
    - @unread_announcements.each do |announcement|
      = render "announcements/card", announcement:

- if @pinned_announcements.any?
  = heading("připnuté příspěvky")
  .grid.md:grid-cols-3.gap-4
    - @pinned_announcements.each do |announcement|
      = render "announcements/card", announcement:

- if @tasks.any?
  = heading("nejbližší úkoly")
  .grid.md:grid-cols-3.gap-4
    - @tasks.each do |task|
      = render "tasks/card", task:, editable: false

And here's a new, Phlex, one:

# app/controllers/dashboards_controller.rb

class DashboardsController < ApplicationController
  def show
    dashboard = Dashboard.new

    render Views::Dashboard::Show.new dashboard
  end
end

# app/views/dashboard/show.rb

class Views::Dashboard::Show < Views::Base
  prop :dashboard, Dashboard, :positional, reader: :private

  def view_template
    content_for :title, "dashboard"

    current_event

    future_events

    active_sboodles

    unread_announcements

    pinned_announcements

    tasks
  end

  private

    def future_events
      return if dashboard.future_events.empty?

      Heading "future events"

      grid do
        dashboard.future_events.each do |event|
          EventCard event
        end
      end
    end

    ...
    # there are of course all the methods, I just don't want to list them all
end

Ok, so multiple interesting things are happening here, not all Phlex specific, but Phlex (+ Literal) did definitely push me it the right direction:

Controller got much smaller

I love small controllers. I have a strong belief that the controller method should only do one thing (not counting loading and rendering/redirecting), preferrably on one line of code.
In here, I didn't previously follow this directive. I got lazy. I just kept adding instance variables, because the template will just pick them up. It doesn't cost me anything.

Sidenote: I like how this interface is made explicit in partials using strict locals. But for the "main" view, there's nothing.

Well, with Phlex it does. Because I'm explicitely passing values to method:
1️⃣ on the controller side I have to edit render Views::Dashboard::Show.new dashboard
2️⃣ on the view side I have to specify incoming attributes
If you are confused about what's prop :dashboard, Dashboard, :positional, reader: :private about, it's from different gem (Literal) by Joel Drapper, which works great with Phlex. I could do the same with

def initialize(dashboard)
  @dashboard = dashboard
end

private

attr_reader :dashboard

but Literal Properties makes this much simpler, and I get type checking "for free".

So it made sense to finally make a "presenter" object Dashboard to pass around, which is what I wanted to do anyway, just didn't have that much reason to.

View can have layers of abstraction

I'm a bit fan of having only one (and the same) layer of abstraction in one place. So I like that my view_template now describes basic structure of my dashboard. You can look at the code and just know what to expect. Then, if you need to dig deeper, you do, very easily!

All in one place

Very easily indeed, as you have all the code in same place! Using traditional templates, I did have show.html.slim, and then all the partials.
Now the "partials" are in same place.

These last points show why I did get to like having all in Ruby - you can use all the Ruby tricks and patters and it also leads me to keeping my code clean, much cleaner then I do in templates (where I'm just like "fuck it" and do anything necessary half the time). This is only my personal failing, not any objective problem with templates! But if there's a way to nudge me into writing better code? Yes please!

You can notice multiple more ways this did force me to make the code bit nicer:

grid is just a very simple shared method:

def grid(cols: 3, &)
  div(class: "grid md:grid-cols-#{cols} gap-2 mb-3", &)
end

as I 1️⃣ didn't like to repeat the code, and 2️⃣ also I don't like the look of long list of classes in my code (maybe I shouldn't use Tailwind than I hear you cry? Well, I like it for fast prototyping and changing, and when contained in components and helpers, it doesn't bother me!)

Then I also created component EventCard, but I already wrote a lot of code, so maybe let's not get into that (it's just - again, in my view - more elegant than using ViewComponent, but not that different).

Ok, let's wrap this up.

I wanted to share my exploration of Phlex as a different way of managing both components and views themselves. You can also choose to use Phlex only for components (which I originally planned to), but I got very much convinced that using it for views makes my code better and myself happier.

Here's a summary of whys:
1️⃣ I enjoy having one Ruby file instead of Ruby + HTML for components
2️⃣ I love how Phlex makes it soo easy to work with "components", and bit cumbersome to work with anything else, that it basically forces me to write everything that way - which gives me reusable and consistent elements and layouts!
3️⃣ I love using private methods for parts of the page (all in one file) instead of partials (that you have to search through).
4️⃣ Literal Properties are super convenient with both components and views
5️⃣ And using them nudges me into very clean and simple interfaces, following patterns that I believe in, but sometimes don't follow fully.

Do you have experience with Phlex? Do you like it? I'd love to hear from you!

Concerning God objects in Rails legacy app

Jan Peterka — Mon, 17 Mar 2025 15:06:00 +0000

I have a lot of fun lately with diving into old and new parts of our ~15yo app at $DAYJOB, and trying to improve it bits by bits.

One of the issues, as many older apps may have, are "god objects" - objects with so much logic inside them, they are mostly impossible to understand and maintain.

It can happen to any object - you start with something small and concrete, possibly adhering to Single responsibility principle even. But then, you need to add just one more method to the object, and one more after that, some scopes, validations, callbacks.

And when new developer joins the project, they see that this object has so many to do, and so many lines, it won't hurt to just add another.

And then you see their pull request, think "oh, we should someday clean this, it's terrible", but that's not the juniors responsibility, so you just sigh and approve this new addition, solidifying this monstrosity.

I was once the junior, having no worries about the code design, just doing what I saw the more experienced devs doing. So I contributed my share to this mess.
Now, I'm bit more experienced, bit more aware of consequences, and bit less careless about this kind of code.
Now I feel it's my responsibility to visit this Augean Stables, and emerge, if not victorious, than at least proud of some improvements I'm able to do.

Luckily, I also really enjoy it (well, most of the time).

So how do I start?

Finding topics

I try to find out bundles of behavior and data that belong together - our object surely contains more than one responsibility (or topic) now, lets see what is there.
For example, we have object Job in our app. It does a lot of things (and have more then one role, which complicates things a bit), but let's say that it mostly describes demands users create in our application.

Demand has and does a lot of things - it can be commented and bided upon, can be reviewed, rated, priced, approved, verified, categorized, located, and many more things.

Let's say we have something like this:

# app/models/job.rb

class Job < ApplicationRecord
  # ...a lot of code
  scope :not_rated, -> { where(rating: nil) }

  # ...different code

  def add_rating(rating)
    # does some logic
    send_notification_about_updated_rating
  end

  # ...more code

  def send_notification_about_updated_rating
    # does some notifying 
  end

  # ...it never ends...
end

If you have any experience with Rails, you probably see where I'm heading.

Yes, I will heavily lean on Concerns (and ruby modules in general).

Note on cautiosness: Now, there are people who don't like Concerns, as they can lead you to the same god object as I described, just hidden in multiple files. And I understand their concerns, and yes - that can happen and is not great. See Jason Swett's article in resources at the end of this article to read more.

However, whether you like them or not, and whether you want them in your app, they can be a great tool for what I'm trying to achieve here. Bear with me.

Extracting topics to Concerns

Once I found some topics in my object, I will create a new concern for them, and carefully find anything related to move there:

# app/models/concerns/job/rateable.rb
module Job::Rateable
  extend ActiveSupport::Concern

  included do
    scope :not_rated, -> { where(rating: nil) }
  end

  def add_rating(rating)
    # does some logic
    send_notification_about_updated_rating
  end

  def send_notification_about_updated_rating
    # does some notifying 
  end
end

# app/models/job.rb

class Job < ApplicationRecord
  include Job::Rateable # I can also omit the `Job::` part, but I like it. 

  # ...a lot of code
  # ...different code  
  # ...more code
  # ...it never ends...
end

Note on testing: Even though moving things to concern seems pretty safe, I got failing tests after this many times (and sometimes errors in production, when tests were missing or incomplete). So, first step should be to check for tests, and have a general idea about what is tested. Also, if there are no tests, it is useful to add some.

If successful, I now have one file with all related code to this topic (e.g. Job can be reviewed).
This has immense benefit in itself - hopefully now I can get proper idea about what's used, what behavior is expected. I don't need to understand all logic, just overall feel.

Improving code

Now I can start to restructure this a bit. Possibly there are some methods that can be marked as private, making it clearer what is the public interface of our Job in the topic of reviewing.

Note on private methods in Ruby: There's some discussion on how to use private in ruby. Marking method private doesn't really stop you from using it - you can call it using send, for example.
I do use it mostly to make it clear that it's just internal details, not public interface. It makes it clearer to me what I'm dealing with.

In our example, notifying about rating is probably only done on methods in our concern, so we can mark it private:

# app/models/concerns/job/rateable.rb
module Job::Rateable
  extend ActiveSupport::Concern

  included do
    scope :not_rated, -> { where(rating: nil) }
  end

  def add_rating(rating)
    # does some logic
    send_notification_about_updated_rating
  end

  private

  def send_notification_about_updated_rating
    # does some notifying 
  end
end

Note on testing: Now I'm doing real changes to my code, and I'm very happy to have tests.

Great, my idea about this area of code is getting better and better - I have everything in one place, I know what is public interface and what are internals, maybe I even found some old code that is no longer used in our app (git log -p -S is my good friend here), which is a nice bonus.

But, we still have a model with a lot of code, lot of responsibility on them.

Luckily, we have all we need to move one step further, and create truly well designed code.

Once again, it's just PORO

As we have all the logic in one place, we might be able to extract it to one or more POROs (plain old ruby objects):

# app/models/job_rating.rb
class JobRating
  attr_reader :job

  def initialize(job)
    @job = job
  end

  def add_rating(rating)
    # does some logic
    send_notification_about_updated_rating
  end

  private

  def send_notification_about_updated_rating
    # does some notifying 
  end
end

We now have self-contained class, with one responsibility - adding rating (in real world, it probably also includes updating rating, deleting rating and so on. but still.). Now, finally, job has no bussiness in managing its ratings - that's job of this object!

But wait! Do we have to find all places where we call job.add_rating and rewrite it to JobRating.new(job).add_rating? No!
First, that would be ugly as hell.
Second, that's a lot of work I'm not willing to do.
Third, now all these places would need to know that there's JobRating class, ugh.

Note on preferences: Maybe you are happy to stop here, and get rid of the Concern that helped us get here. That's okay too! Using concern the way I do in next part has its drawbacks - it's less clear where the logic resides and you have to follow the trail of delegation, also it makes it cosy to just stick more and more to the concern, getting the same issues we had before. I like structuring my code this way, but you don't have to!

Delegating responsibilities

No, there's better way - we leverage Concerns again:

# app/models/concerns/job/rateable.rb
module Job::Rateable
  extend ActiveSupport::Concern

  delegate :add_rating, to: :rating

  included do
    scope :not_rated, -> { where(rating: nil) }
  end

  def rating
    @rating ||= JobRating.new(self)
  end
end

Now, we don't have to change anything anywhere! Rest of our codebase doesn't care - it just wants to add rating to job! Now job accepts this request, and delegates it to rating object.

Note on inspiration: This pattern is not my discovery, but I'm now unable to find the article I read introducing it. If you know where it came from, let me know and I will add it to resources.

Here I showed how using Concern as a stepping stone helps me to make messy code cleaner and better separated.
What do you think? Do you also use this approach, or do you have other tricks to clean this sort of code?
And what are your opinions on (over)using Concerns? Let me know!

Resources and more reading

Here's some reading about Concerns, if you want a bit more context:

Concerns in Rails: Everything You Need to Know (Akshay Khot @ Write Software Well)
When used intelligently, Rails concerns are great (Jason Swett)
Vanilla Rails is plenty (Jorge Manrubia)
ActiveRecord AssociatedObject gem (gem by Kasper Timm Hansen, making this pattern more hidden and ergonomic)

Managing current user in Rails, our way - part 3

Jan Peterka — Thu, 06 Mar 2025 13:12:19 +0000

Finding the right representation

Note: If you haven't read first part of this series, start there. It explains the basics of how and whys behind this one.

As I said before, we used current_user == :false to indicate that we checked whether we can log in user for this request, and found out we cannot - meaning it's "anonymous user", or "guest".

We tried to think and code different approaches - for some time we played with having AnonymousUser class, or NilUser (borrowing from nil object pattern - read more here or here), to finally find an approach we liked - using decorated object.

What that means? The idea is simple - what if current_user was not three different types of objects (User, AnonymousUser, nil), but just one - let's call it CurrentUser. Here is some (incomplete) code:

# app/models/current_user.rb
class CurrentUser
  attr_reader :user

  delegate_missing_to :user, allow_nil: true

  def initialize(user)
    @user = user
  end

  def authenticated? = user.present?
  # Or equivalent, if you are not fan of Ruby endless methods:
  # def authenticated?
  #   user.present?
  # end
end

First thing you might notice is that this is PORO (plain old ruby object) - no inheritance, no composition.
Its usage is very simple:

def log_in(user)
  @current_user = CurrentUser.new(user)
end

So - we will try to always have some instance of CurrentUser in our current_user attribute, which will answer if user is authenticated?.

This is great improvement in that we can lean much more on duck-typing - our older code often looked like this:

if current_user && current_user != false
# or sometimes just
if current_user == :false
# or some variations

We would much prefer to be confident that our current_user can always tell us - is the user authenticated?

So, that's improvement.

Also, as we used delegate_missing_to :user, in cases when we are interested in other user information (name, email or any other user attributes/methods), we can interact with current_user without having a clue what it really is - if it walks like a user, and quacks like a user, you know the rest. The allow_nil: true part helps us even when there is no user - it will just respond with nil, which is legitimate value in cases like name or email (we would probably want to specify some false values on some attributes, but more on that later).

Summary:
We used Decorator pattern to achieve duck-typed interface when interacting with current_user object.

I was happy with this approach, changed places where current_user was assigned to use CurrentUser, and ran test suite.

Of course, it was massively failing. Why? Now we get to some bit more interesting and/or confusing parts of Rails.

Using our PORO in associations

It's pretty common to want use the current_user in association.
Example:

Log.create(kind:, initiator: current_user)

This failed on ActiveRecord::AssociationTypeMismatch error. What does that mean?
Rails/ActiveRecord knows, that initiator should be a user, as we probably defined something like this:

# app/models/log.rb
class Log < ApplicationRecord
  belongs_to :initiator, class_name: "User"
end

or, more likely, we even have just

# app/models/some_object.rb
class SomeObject < ApplicationRecord
  belongs_to :user
end

, where the class is implicit.

So, when we try to use instance of different class, ActiveRecord is trying to save us from our obvious mistake, and doesn't allow that.

There was one way to sidestep it, which is ugly, but I will mention it nonetheless:

If we wrote it like this:

Log.create(kind:, initiator_id: current_user.id)

, it will work.

But don't that, and try to fool ActiveRecord instead!

This was probably most difficult part of all this where I was properly frustrated and claimed defeat multiple times.
In the end (as it often is), it was not so difficult when I (with help with my team leader and many people on the internet) realized two things I was missing:
1) delegation
I had delegation set by delegate_missing_to, but I didn't realize this only does instance methods delegation, and I also wanted to delegate Class methods, to behave like the User in all ways. So many class methods
Once I understood, solution was very simple:

class CurrentUser
  ...

  class << self
    delegate_missing_to :User
  end

  ...
end

2) pretense
This solved most problems but one - I still needed to convince ActiveRecord that yes, this really is a User object, wink wink just trust me.
For this I had to do something bit nasty:

class CurrentUser
  ...

  delegate :is_a?, to: :user, allow_nil: true # This prevents ActiveRecord::AssociationTypeMismatch

  ...
end

This didn't happen automatically with delegate_missing_to, as it was not missing - it was defined by inheriting from Object class.
When we do this, CurrentUser is really not easily recognizable from User. It has some drawbacks - we cannot use is_a?, as it will not tell the truth (but there are not many valid uses of that anyway).
Now we can use CurrentUser object instead of a User object all around the place, and ActiveRecord won't be any wiser.

Summary:
I learned a bit more about ActiveRecord magic, and how to bend it to my will.

comparing to other objects

Another thing that we often do with our current_user is to compare it with other objects, like this:

current_user == post.creator

Well, even though current_user behaves as a user in many ways, this will not be true:
<CurrentUser...> is not equal to <User...>

To solve this, we will again delegate:

class CurrentUser
  delegate :==, to: :user # This allows us to compare to proper User objects

  ...
end

And voila, they are equal.
What happens when we change the order - post.creator == current_user?
You guessed it, again we get false. I made it work this way, but I'm not super happy about it:

class User < ApplicationRecord
  ...

  def ==(other)
    if other.is_a?(User) && other.respond_to?(:user)
      # This is here to be able to compare to CurrentUser decorator
      super(other.user)
    else
      super
    end
  end
  ...
end

Yeah, not great. First thing, it will make every comparison to user bit slower.
Another is, User now knows too much - it expect there to be some object or objects that pretend to be of User class, and respond to user method.
This might bring us grief later, so I'm still looking for better way. If you have any ideas, let me know please!

This solved some other failing tests, and showed another problem, and another way Rails use objects.

using with ActiveJob

Next error I got from my tests was Serialization Error for ActiveJob.
What is that? Well, when I want to create ActiveJob, using current_user as an argument, Rails needs to send identifier of the object to ActiveJob, which is then able to pick the object up correctly.

For that, I had to add custom ActiveJob serializer:

# app/serializers/current_user_serializer.rb

class CurrentUserSerializer < ActiveJob::Serializers::ObjectSerializer
  def serialize?(argument)
    argument.respond_to?(:current_user_decorator?) && argument.current_user_decorator?
  end

  def serialize(current_user)
    super("user" => current_user.user)
  end

  def deserialize(hash)
    CurrentUser.new(hash["user"])
  end
end

Now this is one case when we really need to recognize if the object is CurrentUser (and, as you remember from previous part, we lost the ability to use is_a?), so we added current_user_decorator? method to it. It's a bit suspicious code, having to check it this way, but I didn't yet find any better.

After loading this into app (as explained in Rails guide), ActiveJob knows how to work with CurrentUser.

4 - url helpers

Last problem I encountered with decorator was with url helpers.
When you pass ActiveRecord objects to url_helpers, it is able to make urls from them:
user_path(user) => /user/123
But when I pass random object, it goes terribly wrong:
user_path(current_user) => /user/<CurrentUser...>.
We could once again go around this problem with explicitly using id (user_path(current_user.id) generates correct url), but we don't want to lose this flexibility Rails provides us with.

Luckily, solutions is extremely simple here - url helpers use to_param method to do this neat trick with converting object to id.
So we just need to define or delegate to_param on our CurrentUser object:

# either
def to_param = id.to_s
# or
delegate :to_param, to: :user, allow_nil: true

With this, I got to passing test suite, which was a nice sight (as I started with hundreds of failing tests). Maybe we will find some other troubles (I'm thinking about ActionMail).

So, we can be almost happy with what our current CurrentUser does.
Almost.

stacking dolls situation

There are multiple places where we can change the current_user with code like current_user = Current.user(user). But, as we started to pass CurrentUser as a User all around our app, we are not sure (and we did a lot of work not to care about it) whether user is User or CurrentUser.
So, what happens when we create new CurrentUser, but pass another CurrentUser as a user?
We get a stacking doll situation - we can have current_user, which has CurrentUser as a user, which again has CurrentUser as a user, which...
Maybe it's not that much of a problem with delegation, but it sure is not great, so let's get rid of that.

Let's look at our CurrentUser initiation:

# app/models/current_user.rb, simplified
class CurrentUser
  attr_reader :user

  def initialize(user)
    @user = user
  end

  def current_user_decorator? = true
end

and think for a moment what we can expect to get:

nil, when user is anonymous
instance of User, when user is known
instance of CurrentUser, when passing current_user around

With this understanding, we can change our code to something like this:

def initialize(user = nil)
  @user = if user.nil?
            nil
          elsif user.respond_to?(:current_user_decorator?)
            user.user # This prevents stacked CurrentUser objects
          elsif user.is_a?(User)
            user
          else
            raise ArgumentError, "Only nil, or instance of User or CurrentUser can be passed"
          end
end

We solved two things here - we "unstack" current_user, and we validate the input (so we cannot pass other objects to it by mistake).
Again we used our current_user_decorator? method to recognize instances of CurrentUser.

All right, that's enough for now. This was really long (maybe I should split this to two posts), and we did a lot of work.

There are still some changes and improvements in our pipeline, but those will wait.

Managing current user in Rails, our way - part 2

Jan Peterka — Thu, 06 Mar 2025 13:07:37 +0000

let's be current with Current attributes

In the first post of this series, I tried to show state of our code, and why we weren't happy with it.

In this part, I will start with the easiest change - introduction CurrentAttributes to our app.

After getting utterly confused and lost in the code I tried to outline for you, the first, mostly simple part, was getting rid of Thread.current and using modern Current (attributes API)[https://api.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html].
If you have never heard of it, this explains it:

Current Attributes

Abstract super class that provides a thread-isolated attributes singleton, which resets automatically before and after each request. This allows you to keep all the per-request attributes easily available to the whole system.

So, I looked for our usage of Thread (and our CurrentThread "wrapper"), and mostly just replaced it with the same using Current.

Easy.

Sidenote: I will use current_user in remaining code, as we do in our app now. However, if your app uses Current.user instead (as pure Rails 8+ apps might), it is approximately the same (not really, in that Current is global).

This was easy and short. Not so much for our next part!

Managing current user in Rails, our way - part 1

Jan Peterka — Thu, 06 Mar 2025 13:02:58 +0000

I'm working on ~15 years old Rails application at my $DAYJOB and sometimes (loads of times, actually) there is some quirky code that we are not really happy with these days.

One example which I stumbled across years ago and tried to make sense of (and clean a bit) multiple times, mostly unsuccessfully, was how we manage current user.

You see, in modern Rails apps, this is usually either managed by gems like devise, or using Current attributes, possibly with code from authentication generator introduced in Rails 8.

Not us. We have our custom code that contains some of the oldest code in our project, and which (considering it's authentication) I am pretty afraid to touch.

However, we are slightly getting to somewhat better version of our code, and in this post, I will try to describe our original code, why we wanted to change it and how we did it (or failed to do).

Let's begin.

Part 0 - let's paint a scene

Core of our current user logic are two methods, defined on ApplicationController - current_user and current_user=.
That's not that crazy - if you have experience with devise or similar, that's pretty common thing. Yes, maybe you have log_in instead of current_user=, but well, it's pretty ok.

current_user can have multiple different types:
On the beginning of request (or before first calling current_user or current_user=), it was nil.
Then, it could be set to two values:
1) instance of User
2) value :false

Wait, what? :false? Yeah, weird.
It was the way how to say "we know it's anonymous user", in opposite of nil representing "we just have no idea yet.
So even though te implementation was weird, the general approach of three possible values ("we don't know", "we know they are unknown", "we can link them to our users") made sense and was a starting point for the following changes.

Last thing was that we used was Thread.current (and around it our PORO CurrentThread) to be able to access current user not only from controllers and templates, but also, sparingly, from models or background job.

We had some suspicion it leaks and it brought us some overall doubt about this part of code.

So, after a lot of tinkering, thinking, head scratching and writing and deleting of code, we were able to make some improvements, discover interesting patterns and look into many things Rails does "magically" for us, until it doesn't.

Deploying Rails app with Kamal - why is my image so big?

Jan Peterka — Thu, 14 Mar 2024 11:56:25 +0000

I'm currently in process of rewriting app from Python/Flask to Ruby/Rails, and one of changes is in deployment process.

I decided to use containers and Kamal, as it's upcoming default for Rails.
Mind you, I have no prior experience with neither Docker nor deployment tools like Capistrano.

There are many things that I got stuck on (and I plan to write about them maybe later), but today I was trying to solve one problem - images Kamal generated were about 3GB.
Whoa, that's a lot! It takes a long time to build, to upload to registry, to download to server. It's huge waste of resources!

I had to dig into it, and here's what I learned:

To find out how big my images really are (and compare before/after some changes), there's docker images. It lists all my images and their sizes.

But whats inside?
I found out about this handy command to show me what's contained inside the image:
docker history registry.example/example-all:latest
which shows me something like this:

IMAGE          CREATED              CREATED BY                                      SIZE      COMMENT
211b6b39d381   About a minute ago   CMD ["./bin/rails" "server"]                    0B        buildkit.dockerfile.v0
<missing>      About a minute ago   EXPOSE map[3000/tcp:{}]                         0B        buildkit.dockerfile.v0
<missing>      About a minute ago   ENTRYPOINT ["/rails/bin/docker-entrypoint"]     0B        buildkit.dockerfile.v0
<missing>      About a minute ago   USER rails:rails                                0B        buildkit.dockerfile.v0
<missing>      About a minute ago   RUN /bin/sh -c useradd rails --create-home -…   74.9MB    buildkit.dockerfile.v0
<missing>      About a minute ago   COPY /rails /rails # buildkit                   2.7GB     buildkit.dockerfile.v0
<missing>      17 minutes ago       COPY /usr/local/bundle /usr/local/bundle # b…   148MB     buildkit.dockerfile.v0
<missing>      18 minutes ago       RUN /bin/sh -c apt-get update -qq &&     apt…   148MB     buildkit.dockerfile.v0
<missing>      18 minutes ago       ENV RAILS_ENV=production BUNDLE_DEPLOYMENT=1…   0B        buildkit.dockerfile.v0
<missing>      19 minutes ago       WORKDIR /rails                                  0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          CMD ["irb"]                                     0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          RUN /bin/sh -c mkdir -p "$GEM_HOME" && chmod…   0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV PATH=/usr/local/bundle/bin:/usr/local/sb…   0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP…   0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV GEM_HOME=/usr/local/bundle                  0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          RUN /bin/sh -c set -eux;   savedAptMark="$(a…   58.1MB    buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV RUBY_DOWNLOAD_SHA256=cfb231954b8c241043a…   0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV RUBY_DOWNLOAD_URL=https://cache.ruby-lan…   0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV RUBY_VERSION=3.2.3                          0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          ENV LANG=C.UTF-8                                0B        buildkit.dockerfile.v0
<missing>      8 weeks ago          RUN /bin/sh -c set -eux;  mkdir -p /usr/loca…   45B       buildkit.dockerfile.v0
<missing>      8 weeks ago          RUN /bin/sh -c set -eux;  apt-get update;  a…   46.5MB    buildkit.dockerfile.v0
<missing>      8 weeks ago          /bin/sh -c #(nop)  CMD ["bash"]                 0B        
<missing>      8 weeks ago          /bin/sh -c #(nop) ADD file:b86ae1c7ca3586d8f…   74.8MB

Here I saw that my problem lies in COPY rails/ rails/, meaning my app directory is huge.

Why's that? Here's another handy command to see that:
du --max-depth 1

This shows me size of directories inside my project:

8   ./.bundle
108 ./test
824388  ./.ruby-lsp
176 ./config
554380  ./vendor
56  ./lib
108 ./db
125260  ./tmp
28  ./bin
3034272 ./old
24  ./.kamal
39508   ./.git
8   ./.vscode
2300452 ./storage
232 ./spec
8216    ./app
20  ./public
427176  ./log
4614096 .

The thing is, I started deploying from my laptop, so I have all this files that are not present when deploying from CI/CD (as would be optimal way).

So, we have /storage (with all files), /.ruby-lsp (from editor), /old (thats just some migration data), and /vendor.

I don't want these in my image!
Let's not include them:

# .dockerignore

old/
*.log

vendor/
tmp/
.ruby-lsp/

After another build, I check my image again, and I got to much nicer ~600MB image.

There might be still some room for improvement, but I'm quite happy with this - my build time is down significantly, my self-hosted registry is not full of useless data, and I learned something new.

How I migrated from Flask-Security(-Too) to Devise

Jan Peterka — Thu, 07 Dec 2023 11:07:49 +0000

Recently I started a rewrite of one of my smallish projects (in terms of complexity, but with ~200 users, so I must handle that with care) from Flask to Ruby on Rails.
Why? I'm planning on writing another article about that, so I don't want to go into details here, but in short, I believe it will enable me to write the app both faster and better. But there are some hurdles to overcome to get there.

For some time, I ignored the authentication part of the app. So today, I made my first attempt at making that work.

In Flask, I used the Flask-Security-Too package from the start. I never tried to implement any authentication logic myself (as you probably never should for, you know, security reasons).
I knew that in Rails, I could use the devise gem.
But it means jumping from one black box into another. I knew that it might bring some difficulties.

Warning: I'm no expert on security by any means! I understand really little about this, just enough to make it work. There might be some security concerns I'm not aware of. Read this just as a story, not a tutorial!

There was some little work involved in correctly adding columns to the database to support devise (as some column names are the same in both libraries and some are not), but not that much. The most annoying is that I had a password column, and that caused some problems with Rails/devise. But after some tries with migrations, I got sorted that out.

The main problem, as expected, was being able to validate the same hashes in Rails that Flask-Security created automatically for me.

The Problem - Password hashes

Short aside if this is new for you: what are password hashes?
It would be very unwise to save passwords to the database as-is. I certainly don't want to have that responsibility on me.
So instead password hashes are usually stored in the database, and on login attempt hash is calculated from the provided password and compared to the saved one.
So the app knows the same password was provided as when the user registered, but is none the wiser about the actual value.

When I looked into my database, I had hashes like $2a$12$etyAllfaDgIDC61ZUS9UB.peoAIYpZborbU4T/6c8SejvrIhbIL46 there.

Ok, back on track. The trouble is that there are many different ways to hash passwords.
You can use different algorithms (sha256, bcrypt, argon,..), they can have different configurations, there may be some salt or pepper involved,..

There's basically NO CHANCE that a different library (devise in my case) will hash, and therefore validate, passwords the same way as some other (flask-security for me).

So it was no surprise that after adding devise to my project, logging in with my credentials wasn't working.

The easy way out for me would be the following - just toss out all passwords and send mail to my users that they need to use the Forgotten password feature. Well, not gonna happen, thank you very much.

So I needed to find out way to migrate successfully.

There were two parts to the solution:
1) Slightly changing mechanism for Devise-provided password-validation to validate using its built-in mechanism first, and if that fails, try our own validator, simulating how Flask-Security does validation.
2) Writing the validator

Allowing both Devise and Flask-Security-like validation

The first part is quite straightforward:

# app/models/user.rb
class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable

  (...)

  def valid_password?(password)
    if Devise::Encryptor.compare(self.class, encrypted_password, password)
      true
    elsif flask_security_compare(password)
      true
    else
      false
    end
  end

  (...)
end

It's probably pretty self-explanatory, I'm just overriding the default valid_password? method Devise is providing, adding another way to validate the password. Nice, let's move into the second part - how will flask_security_compare work?

Simulating Flask-Security hashing

Now this was a bit more difficult (took me a few hours to solve).

First, I needed to understand what Flask-Security is doing when hashing passwords.

Luckily, I was already using bcrypt as my hashing algorithm (as it's the default for Flask-Security), the same as Devise uses.
I needed to check that it is configured the same way, mainly the number of stretches (technique making hashing slower, thus making brute-force attacks more difficult).

Sidenote:
Remember the hash I showed you before? Here it is again $2a$12$etyAllfaDgIDC61ZUS9UB.peoAIYpZborbU4T/6c8SejvrIhbIL46._
$2a tells us it's bcrypt using 2a variation
$12 is the number of stretches

Now for a tricky part.

When the password is hashed using bcrypt, there's salt provided. That's a way to make pre-calculating hashes nearly impossible (preventing usage of the infamous rainbow tables).

Where does this salt come from?

It's generated randomly.

For a moment I was afraid that it meant I would be unable to simulate this - how can I recreate something random? Of course, that's not the case - bcrypt needs to keep this value around. And it does so directly in the hash string:

in $2a$12$etyAllfaDgIDC61ZUS9UB.peoAIYpZborbU4T/6c8SejvrIhbIL46, etyAllfaDgIDC61ZUS9UB. is the salt (22 characters after the initial part).
Only the rest (peoAIYpZborbU4T/6c8SejvrIhbIL46) is the actual hash!

Nice! And even nicer - I don't need to parse the value manually, I can use the library for that (as suggested by Copilot):

legacy_password_hash = "$2a$12$etyAllfaDgIDC61ZUS9UB.peoAIYpZborbU4T/6c8SejvrIhbIL46"
bcrypt_password_hash = BCrypt::Password.new(legacy_password_hash)
puts bcrypt_password_hash.salt
# $2a$12$etyAllfaDgIDC61ZUS9UB.

Ok, we have a salt, let's hash some passwords!

hashed_password = ::BCrypt::Engine.hash_secret(password, bcrypt_password_hash.salt)

Well, I did get a result, but it was different than what I had in the database...

The reason is that Flask-Security uses one more security enhancement.

It doesn't use the password directly for hashing but encodes it to HMAC using a server-wide secret key (set as SECURITY_PASSWORD_SALT env variable).

I had to look into Flask-Security source code to find how exactly it's done:

def get_hmac(password: SB) -> bytes:
    """Returns a Base64 encoded HMAC+SHA512 of the password signed with
    the salt specified by *SECURITY_PASSWORD_SALT*.

    :param password: The password to sign
    """
    salt = config_value("PASSWORD_SALT")

    if salt is None:
        raise RuntimeError(
            "The configuration value `SECURITY_PASSWORD_SALT` must "
            "not be None when the value of `SECURITY_PASSWORD_HASH` is "
            'set to "%s"' % config_value("PASSWORD_HASH")
        )

    h = hmac.new(encode_string(salt), encode_string(password), hashlib.sha512)
    return base64.b64encode(h.digest())

and then recreated the algorithm in ruby:

def get_hmac(password)
    require 'openssl'
    require 'base64'

    salt = ENV['LEGACY_SECURITY_SALT']

    if salt.nil?
      raise "The configuration value `LEGACY_SECURITY_SALT` must not be None when the value of `SECURITY_PASSWORD_HASH` is set to #{ENV['SECURITY_PASSWORD_HASH']}"
    end

    digest = OpenSSL::Digest.new('sha512')
    hmac = OpenSSL::HMAC.digest(digest, salt, password)
    Base64.encode64(hmac)
  end

and used that to write the flask_security_compare function I need:

def flask_security_compare(password)
    bcrypt_password = BCrypt::Password.new(legacy_password_hash)

    hmaced_password = User.get_hmac(password)
    hashed_password = ::BCrypt::Engine.hash_secret(hmaced_password, bcrypt_password.salt)

    Devise.secure_compare(hashed_password, encrypted_password)
end

And it still didn't work.
I was a little desperate by then, but after some debugging and comparing of strings I found out small problem:
The ruby implementation sometimes added \n symbols into the hmaced_password.
Fast fix is this: Base64.encode64(hmac).chomp.gsub(/\n/, '').

Now I'm just curious if this works with every password there is in my database. Let's hope.
And maybe show a banner to users warning them that it might happen.

Oh, I forgot one more improvement - if the user logs in using the "old mechanism", it can rehash the password to update the hash. This way, I can remove the flask branch later (like in a year or so). I already did something similar when I was migrating from SHA256 to the bcrypt algorithm in my older project.

Now I'm done.

So, I learned a bit about how password hashing works in Flask-Security, which was interesting. And I'm really happy that I can continue with my rewrite to Rails, knowing that users will be able to log in using their old passwords.

Again, this is not a tutorial. Please, if you do some authentication stuff, be careful. And if you find any mistakes here, let me know in the comments!

Update:
I realized I didn't address properly one potential downside to this. As password validation tries two way of hashing, it makes guessing password easier, as there are potentially two strings that produce the desired hash. That's not great, as it's lowering security of our authentication, but as we use otherwise safe way, it shouldn't do much damage (half the time for brute-forcing will still be a lot). We could migitage this by having flask_password_hash and password_hash as different fields, and only allowing one of them to be present.

Writing Jinja as a proper Python developer

Jan Peterka — Tue, 04 Oct 2022 09:08:02 +0000

⚠️ disclaimer

I have no idea what is the correct way to do things. I probably do some things really wrong, and I will be glad to learn that. Here I'm just sharing my experience and where I'm now in using Flask for multiple small-to-medium projects (all basically CRUD apps). Your experience may be different, and I will gladly hear it.

✍️ writing Jinja as a proper Python developer

You probably heard about the DRY principle. I'm not going into the heated discussion if that's something you should code by. Actually, let's forget there's the DRY principle at all.
Let's just say that I'm a lazy person.
So, the idea of writing code I don't have to multiple times is, well, not appealing to me.

But it happens. Especially when the project is young and dynamic and you have no idea what code you will need, or how you will structure things.
One place I extremely hate writing code over and over again is HTML. There are so many <s and >s and other things. And soo much that's obvious and shouldn't be written.
you know - if you are writing the <a> tag of course you will use href argument. Why is it even kwarg? I would never be kwarg if I was writing it in Python!
And as I'm programming Flask CRUD app, most of the time <a> is pointing to some object show/edit page. Should I write
<a href="{{ url_for('UserView:show', id=user.id) }}> {{ user.name }} </a>" every time? Absolutely not!
As I'm exposed to Ruby on Rails in my work, I've seen link_to in templates a lot. And I thought: that's really nice! That's what I should be doing, right? Just write {{ link_to(user) }} in my template, when I want a really simple link. Why can't I do that?

Let's look into what did I discover on my journey into great developer experience with Jinja templates.

The question was - how can I create some "helpers" like this in Jinja?
And the answer is...
There are many ways depending on context. Sigh.
Well, let's look into them.

partials

By partial, I mean a separate template that I include in my "main" template. They are useful when there's some big part of a page (like a table of all users) that I use on multiple pages (index, show).
I can give them some variables using {% with users=... %}, but if I try adding some complex logic, it's not really great.

macros

When you were reading this article, you probably thought "he's talking about macros, right?". Well, of course, macros are THE suggested way to handle a bit more generalized, repeated pieces of HTML.
It's mostly the only advice you get on StackOverflow (here and here just two examples). And macros are great! I used them happily for some time - having macro for rendering form fields, icons, and other repeated elements. I had macros that use other macros! But...
Jinja logic is somewhat.. ..more verbose than I'm used to from Python. Not a great code. And getting some more complex logic in, it's not really what you want.
Another thing with macros is that you have to import them into your templates. Normally it's just a matter of adding everything to base.html.j2 template, but as I use Turbo (another article on that), sometimes I render just a partial, so I need to import explicitly there too. I know that Zen of Python says "Explicit is better than implicit.", but in this case, I don't know. Having link_to accessible globally seems like a sensible thing to me (and another zen says "Although practicality beats purity.").

So, how do we do that?
We will have to come back from the dark, messy realms of HTML to the sweet embrace of Python.

helper functions

I did know that I can register custom Jinja filters and test (you know, because I read Jinja API documentation more times than I would like to).
But for a long time one great method was hiding from me: application.add_template_global().
What is it? Simple, just a method to register custom functions to use in Jinja. They are used in code like macro, but they are your normal Python functions.
Nice, let's use that!

I created a new directory: app/components and there created this file:

# app/components/links.py
from flask import Markup

def link_to(obj):
 # (do some logic)
 return Markup(some_html_code)

and then, to make things nice, I added:

# app/components/__init__.py

from .links import link_to


def register_all_components(application):
 application.add_template_global(link_to)

and finally, in my app/__init__.py (simplified):

# app/__init__.py

def create_app():
 application = Flask()
 (...)
 from app.components import register_all_components
 register_all_components(application)
 (...)

Now I can use {{ link_to(something) }} anywhere in my templates. Smooth!

You can probably guess what some logic in link_to does, and I don't want to include full code here as it's but sprawled, but basic functionality goes like this:

I can pass either object or string to link_to
if it's a string
- it either includes :, so it's recognized as Flask-Classfull reference to route (eg. "UserView:index"), so it's converted to url_for(something)
- or it's just pure URL, then I just pass it as it is
or it is object
- then I get generated route - so, from user object I can expect UserView, add :show and id=user.id. This logic is handled by UserPresenter which gives us user.path_to_show

I was happy with this. But I wasn't happy for long. Because soon I got repeating code again, and it was just not beautiful enough. So my journey to perfect developer experience continued and I found...

kittens!

No, sadly kittens are of no direct help with HTML. They are way too cute for that.

We need to continue our search...

TemplateComponents

Have you never heard of TemplateComponents? That's understandable, they don't exist.
Inspiration for this pattern comes from Ruby on Rails, and specifically, gem(package) created and used by Github - ViewComponent.
As views in Rails and Django are templates in Flask (I don't know why I would be happy with MVC instead of MTV), let's call it TemplateComponents!

The idea is to move the core of these reusable pieces of HTML into Python objects, getting all the benefits of OOP.

How would that look?

Here's an example:

1️⃣ Components are classes, in my case located in app/components/.
2️⃣ Component itself does some logic and then renders jinja template (with minimum logic from app/templates/components/
3️⃣ They are used by helper functions (defined in the same place), these helpers are registered by flask to be globally accessible, eg.(application.add_template_global(icon))

Here's an example how it can be set up:

# app/__init__.py


def create_app():
 (...)
 from app.components import register_all_components

 register_all_components(application)
 (...)

Nothing new here...

# app/components/__init__.py

from .links import link_to, link_to_edit


def register_all_components(application):
 application.add_template_global(link_to)
 application.add_template_global(link_to_edit)

Yeah, we know this part.

# app/components/links.py
from app.components import Component


# core
class Link(Component):
 def __init__(self, path, value, **kwargs):
 super(Link, self).__init__(**kwargs)
 self.path = path
 self.value = value


# helpers
def link_to(obj, **kwargs):
 path = obj.path_to_show()
 value = kwargs.pop("value", obj.default_value_link)

 return Link(path=path, value=value, **kwargs).render()


def link_to_edit(obj, **kwargs):
 from app.components import icon
 path = obj.path_to_edit()
 value = kwargs.pop("value", icon("edit"))

 return Link(path=path, value=value, **kwargs).render()

Ok, here's something new. But Link itself doesn't have a lot of logic, so how..

# app/components/base.py

from flask import render_template as render
from flask import Markup


class Component:
 def __init__(self, **kwargs):
 self.kwargs = kwargs
 self.kwargs["data"] = self.kwargs.pop("data", {})

 def render(self):
 return Markup(render(self.template, **self.attributes))

 @property
 def template(self):
 folder = getattr(self, "folder", f"{self.__class__.__name__.lower()}s")
 file = getattr(self, "file", f"{self.__class__.__name__.lower()}")

 return f"components/{folder}/{file}.html.j2"

 @property
 def attributes(self):
 # All public variables of the view are passed to the template
 class_attributes = self.__class__.__dict__
 view_attributes = self.__dict__
 all_attributes = class_attributes | view_attributes
 public_attributes = {
 k: all_attributes[k] for k in all_attributes if not k.startswith("_")
 }

 # kwargs has higher priority, therefore rewrites public attributes
 merged_values = {**public_attributes, **self.kwargs}
 return merged_values

Oh, right! Because some logic will probably be used in any component, so let's move that to Component class!

And here's a template it renders:

# app/templates/components/links/link.html.j2

<a
 href="{{ path }}"
 {% if class %} class="{{ class }}" {% endif %}
>{{ value }}</a>

Mind you, this is the first version of my Component system. I haven't even moved all my macros there, so there will be probably some changes and improvements. But the basic idea is here.

For now, I'm not pushing component classes to jinja context - so I cannot do {{ Link(something) }}.
It would be possible, but for now, it makes sense to me to use them through helper functions such as link_to and link_to_edit.

Why am I happy (for now) with this approach?

I can handle complex logic easily (as I'm using Python, not Jinja)
there's a clear way to split logic for
- components in general (handled by Component class) - getting template name, rendering it
- kinds of components (handled by Link class for example) - possibly setting some defaults - style,...
- and specific helpers (link_to, link_to_edit) - setting specific values - path and defaults.
it's easily testable!
- I can test class or helper. not doing it now as I only have simple use cases, but in the future, it will make sense - so I can check parts of my HTML in a fast unit test instead of a complicated slow FE test.

As always, I'm not saying this is the best approach. I was trying to show all the styles I used for this part of creating a web app. All may be useful, it depends on what you need.

Question for this post:

how do you handle your templates?
how important is "Explicit is better than implicit" zen important to you?

Hope to hear your ideas, experiences, and critique!

Beyond Flask tutorials

Jan Peterka — Tue, 04 Oct 2022 08:57:10 +0000

disclaimer

I have no idea what is the correct way to do things. I probably do some things really wrong, and I will be glad to learn that. Here I'm just sharing my experience and where I'm now in using Flask for multiple small projects (all basically CRUD apps). Your experience may be different, and I will gladly hear it.

what's this about

As many (I guess), I started to learn Flask with Flask Megatutorial by Miguel Grinberg (who's for me a Flask guru). You can learn a lot from tutorials, but at some point you get to situations where you don't find a reference for how to do this a clean way, "Flask way". So, there are many things I tried and changed and changed again. It's not that the code is not working, but when you are thinking about how to keep your code sustainable, you are just trying to find a good way all the time.
I want to show how I use Flask. How I think about structure, what tools and packages I use for my app.

I will randomly add some articles as I'm handling different parts of my application/s. If I will see something to be worth sharing, I will try to do so.

I hope for this to become place for me to structure my thoughts and experiences, for you to be inspired, and for all of us to exchange thoughts, discuss and learn.

Let's start!

Questions for this post:

Do you use Flask? And have you comparison with other web frameworks?
Is there something you are stuck on, something that doesn't just "feel right" in you Flask project?

Gratitude journal - dev edition (29.3. - git)

Jan Peterka — Sun, 29 Mar 2020 07:39:25 +0000

So, how are you holding up?

In pursuit of happiness in these difficult times, I will continue my gratitude journal.
Last week I wrote about Stimulus.js and why am I grateful for it.

This week I will focus on something fundamental for most of us - git.
I am probably not only one who cannot imagine working without git these days, but it wasn't always that way.

When I started learning to code, I had no idea there is anything like version control systems. I just made new and new files with names like code_2_0_new and so. You may know what I am talking about.

I learned to use git after that - or to be more precise, I mostly learned how to operate GitHub (which was the same for me at a time).

So, I was very surprised when I was supposed to use TortoiseSVN in my first job. It was really weird, ugly and complicated. Soon, I happily returned to git.

Since then, I am using git almost daily - at work (learning how to use it for collaboration) or in my hobby projects (adding things like pre-commit, integrating with deploys and so).
I am no expert in git, I have a lot to learn, but even now, it helps me with my programming tremendously.

So for today, I am grateful for git (and in extension, for all git software I used so far - GitHub desktop, GitKraken and my current Sublime Merge).

What are you grateful for? :)

Gratitude journal - dev edition (23.3 - Stimulus)

Jan Peterka — Mon, 23 Mar 2020 13:30:15 +0000

I started gratitude journaling a few months ago, and it feels nice.
It feels good to stop for a moment, find something you are grateful for or makes you happy, especially in these precarious times.

So, I decided to start another gratitude journal publically here, this one focused on technology, software and generally things I am grateful as a developer.

I will try to make a post at least once a week.
And for now...

..this week I am grateful for Stimulus

I guess many of you know about this little js framework from Basecamp.
I have personally seen it first about six months ago thanks to my work at NejŘemeslníci.cz, where our front-end developers started using it some time ago.

As I am not front-end developer myself (I prefer backend, mostly in Python and recently in Ruby on Rails), I only have some little knowledge in js, and when I needed to use some (e.g. for my web app ketocalc), I just wrote some terrible code, which "just worked" (but was terribly unreadable, unmaintainable and added terrible class-naming scheme to my html).

Well, at work I learned some basics of stimulus and it seemed nice.
So this weekend I decided to finally improve code in my project, so I stopped being ashamed of it whenever I worked on that project.

I didn't manage to crack how to use neither npm nor webpack, luckily I can use stimulus without it (I know, I know, it's not optimal and I promise, I will get there someday).
I simplified my code (both js and HTML) immensely, replaced AJAX with fetch, DRYed my code, and got rid of most of jQuery.
I am so happy now.

I know that most of it is not because of stimulus. But it helped me with the process of writing nice, reusable code, and I love how it connects to HTML. I think it's really great js framework, especially for someone not very fond or skilled in frontend.

So, that's for this weeks gratitude.
Thanks for reading this, and let me know in comments what are you grateful for :)

Cookies and GDPR

Jan Peterka — Fri, 14 Feb 2020 15:56:48 +0000

Recapitulation

In first article I defined some base information and plans.

In this article we will try to understand first part of legal requirements for publishing app - cookies and personal data.

I'm not a lawyer, this article is my own grasp of which is needed. If you find any factical (or other) mistakes, please let me know in comments.

Cookies

General rules (EU applicable)

You can find info on many sites (such as here or here), but in general, these are the rules:

For most cookies uses, you need your users to opt-in - meaning give their consent to using cookies. It might be a checkbox in register form, or pop-up window they need to accept.

You also have to list what kinds of cookies you use, and enable users to disable those not critical for using the app (necessary and functional cookies).

Also, users need to have the option to revoke their consent later, and it should be obvious to them how to do that.

My app

I use Flask-Sessions for session management, which is server-site. I only use cookies to save session and remember-token (as I checked in my browser). So, this cookie is by no means personal info.

My usage of cookies qualifies them as necessary cookies.

I don’t use any third-site services and cookies (such as Google Analytics).

That means the following:

My cookies are exemption from the consent requirement. I have to inform users about using cookies, but I don’t need their consent.

My solutions

As I only need a simple banner informing users about using cookies, I can make some myself, or use some generator. I used this one.

Personal data and GDPR

General definitions

General Data Protection Regulation (GDPR) is an EU-wide set of rules for managing personal data.

Here are some of the definitions we will need:

According to the Regulation of 679/2016n:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;

App overview

What personal data do I collect?

I collect data which identify person, like:

name (first and last)
email address (which classifies as online identifier)
Google ID (if logged in via Google OAuth)

However, the definition of personal data from above says that any information relating to an identifiable person is personal data. Which means that any data that is connected to persons info (through foreign key etc) is personal data. For my app, it means everything user creates (e.g. recipes) or I collect about them (e.g. last login time)

How do I process them?

I collect this data when users create them (account, recipes,..).

I collect some data about app usage (last login, login count, recipe page show count).

I don’t give the data to any other person or business.

General rules

So I will try to just pinpoint some main rules needed in my app:

I need users active, informed consent before collecting data

I will solve this by adding checkbox to registration form which confirms that the user is informed about what personal data I collect and how I process them, with a link to Privacy Policy (further describing what I do with data - more on that later).

Users have the right to access their data and to information about their data (article 15)

Well, as users can see all their data in the app at the moment, it shouldn’t be a problem. However there are some information I keep that isn't shown on the user profile. For example - last login date, number of logins, how many times a certain page was seen,.. Those are information I use for improving usage of my app (having info about the number of active users) and for features like suggested recipes (based on most looked at).

If user requests this information, I am able to get them from database manually (GDPR states I have a month to fulfill this request, so it’s entirely possible), but in the case of more request I would probably add some automated way for users to get their data.

As of informing about purposes of processing data, these will be added to Privacy Policy. I also need to include info about how they can get their data - in my case they can contact me via apps mail.

Users have the right to restrict my use of their data (article 18)

What does that mean?

According to article 18, I have to stop processing their data if they request it based on claim that:

data is inaccurate || processing is unlawful || app doesn’t need the data

I don’t see that happening in my app, but still I need to give them info about how to request this.

Also according to how ‘processing restriction’ is defined, I need to be able to mark these data. I don’t do that now automatically, but if I receive such a request, I can implement this (by adding parameter or flag to user).

Right to change inaccurate or incomplete data (article 16)

Ok, so I allow my users to change their name and email. That’s a good idea anyway, and also already implemented in my app. I just need to let them know about this option in Privacy Policy as well.

Right to know who’s collecting their data and what for (recital 58)

Important thing here is that any information I give users or publicly about data collection and processing must be easily accessible and easy to understand. Therefore it should be in languages my app is available in - currently only Czech, possibly in English in the future. That would mean adding all law documents in English as well.

Right to be forgotten

Also important role - users can request deletion of their data if their personal data is no longer needed for the purpose for which it was originally collected.

In case of my app, it means mainly option to delete their account and all personal data associated with it.

One possible way is to implement this to user profile editing (as seen in many big apps). However, as my app is small and with little users, I am okay with just adding info that they can contact me with this request, as with the others.

Data security (article 32)

According to this article I must ensure integrity and availability of data processing system. This is a bit hard to understand, but we will look more into this in section about security. One important part of this rule is that I have a responsibility to test and evaluate security of my app. It might mean doing a security audit, but it’s probably okay to just do my best to secure data and built secure app.