It is a grep for YAML and (incidentally) JSON files. It allows you to search for a key and get the value and the line number where it is located. It is handy when you have a big YAML with several nested levels, for example, on the typical I18n Rails files.

You can find it on Github and install it with gem install flatito. It is a very simple tool, but I hope it can be helpful for someone else.

How it looks like

$ flatito

Usage:    flatito PATH [options]
Example:  flatito . -k hello

    -h, --help                       Prints this help
    -V, --version                    Show version
    -k, --search-key=SEARCH          Search string
        --no-color                   Disable color output
    -e, --extensions=EXTENSIONS      File extensions to search, separated by comma, default: (json,yaml,yaml)
        --no-skipping                Do not skip hidden files

Let’s see an example of a search over the Rails repository:

$ flatito rails/ -k dev_server

rails/railties/test/isolation/assets/config/webpacker.yml
24:  development.dev_server.https => false
25:  development.dev_server.host => localhost
26:  development.dev_server.port => 3035
27:  development.dev_server.public => localhost:3035
29:  development.dev_server.hmr => false
31:  development.dev_server.overlay => true
33:  development.dev_server.compress => true
35:  development.dev_server.disable_host_check => true
37:  development.dev_server.use_local_ip => false
40:  development.dev_server.quiet => false
41:  development.dev_server.pretty => true
43:  development.dev_server.headers.Access-Control-Allow-Origin => *
45:  development.dev_server.watch_options.ignored => **/node_modules/**

rails/actiontext/test/dummy/config/webpacker.yml
60:  development.dev_server.https => false
61:  development.dev_server.host => localhost
62:  development.dev_server.port => 3035
63:  development.dev_server.public => localhost:3035
64:  development.dev_server.hmr => false
66:  development.dev_server.inline => true
67:  development.dev_server.overlay => true
68:  development.dev_server.compress => true
69:  development.dev_server.disable_host_check => true
70:  development.dev_server.use_local_ip => false
71:  development.dev_server.quiet => false
73:  development.dev_server.headers.Access-Control-Allow-Origin => *
75:  development.dev_server.watch_options.ignored => **/node_modules/**

rails/activestorage/test/dummy/config/webpacker.yml
40:  development.dev_server.https => false
41:  development.dev_server.host => localhost
42:  development.dev_server.port => 3035
43:  development.dev_server.public => localhost:3035
44:  development.dev_server.hmr => false
46:  development.dev_server.inline => true
47:  development.dev_server.overlay => true
48:  development.dev_server.compress => true
49:  development.dev_server.disable_host_check => true
50:  development.dev_server.use_local_ip => false
51:  development.dev_server.quiet => false
53:  development.dev_server.headers.Access-Control-Allow-Origin => *
55:  development.dev_server.watch_options.ignored => /node_modules/

rails/actionmailbox/test/dummy/config/webpacker.yml
33:  development.dev_server.https => false
34:  development.dev_server.host => localhost
35:  development.dev_server.port => 3035
36:  development.dev_server.public => localhost:3035
37:  development.dev_server.hmr => false
39:  development.dev_server.inline => true
40:  development.dev_server.overlay => true
41:  development.dev_server.compress => true
42:  development.dev_server.disable_host_check => true
43:  development.dev_server.use_local_ip => false
44:  development.dev_server.quiet => false
46:  development.dev_server.headers.Access-Control-Allow-Origin => *
48:  development.dev_server.watch_options.ignored => /node_modules/

How it works

Flatito is written in Ruby and uses the psych gem to parse YAML files. Initially, it was only for YAML files, but then I realized that it also works for JSON files, so I added support for them.

The big challenge was to get the keys with the line number where they are located. Psych does most of the work, but the documentation could be more explicit about how can I use it to get a different output. Luckily, there is a StackOverflow thread about a similar issue. This specific answer from John Carney was very helpful, and I used it as a base to build the tool with a few modifications to get exactly what I needed.

I was looking for something that would let me run a full-text query over the content of the sites, create snapshots (image and HTML) and let me integrate it with my browser (Firefox), so instead of spending some minutes looking for existing services, I started my own…

Ultimately, it is a great excuse to work with technologies I like and experiment with several things.

At the moment, the main features are:

• Full-text search, based on Postgres. I want to write something about pg_search and beyond.
• Import Firefox bookmarks
• Quick post with a Bookmarklet, made with my bookmarklet generator
• Display mentions in HackerNews

And pretty soon, I would like to release the following:

• Firefox (and maybe Chrome) addon with several functionalities, but it has yet to be ready.
• A system to allow users to export (and import) their data in an SQLite file.

There are other features I would like to implement in the future:

• Fetch transcriptions from YouTube, and maybe download the video
• Enqueue captures on the Wayback machine, but the rate limits are unclear to me…
• Inject results on leading search motors via the web extension
• Something with LLM; everything has a LLM integration now, but it would be expensive: summarizing, auto-tagging…

One of the key features of this tool is that it stores state information in the URL, making it easy to share and bookmark different configurations without depending of a backend.

If you don’t know, young post-millennial bookmarklets are small JavaScript applications that can be saved as bookmarks in web browsers, like a web extension, but simpler.

You can use it on bookmarklet.jose.gr and the code is available at Github.

The maze generator could be more impressive. It only supports the typical rectangular maze and a few algorithms.

I made it when I started reading the book Mazes for programmers. The book is excellent and teaches you how to generate a bunch of different mazes with different shapes, how to find the complex or most straightforward path, etc.

The code is in Ruby (my primary programming language), but I wanted to play more with Svelte and Typescript; hence I decided to make a small web app.

I want to continue reading the book and implement more features, but there is no time for everything.

Apart from Svelte I want to mention a few more libraries that I used:

• konva: To generate the maze on a canvas, I could do it without it, but it will allow me to add some interactivity in the future. I also tried implementing it on SVG, but the browser gets unresponsive for giant mazes (200x200)

• PDFMake: To generate PDF on the client side.
• unique-names-generator: To generate random human friend seeds.
• seedrandom: To generate random numbers for a given seed. It allows rendering always the same maze when providing the same seed.

There are many other alternatives on the internet, but MarkdownTable includes in the generated Markdown code a link to edit it self.

The app stores the state in the URL. It allows generating a link to the own table without storing anything on the server.

There is no official max length for the URL, but some maximums depend on the client and server combination. More about maximum URL length.

MarkdownTable relies on lz-string to squeeze the data. It allows more data storage and shorter links without server-side intervention.

The app allows copying and pasting directly from a spreadsheet or CSV, importing an existing markdown table and create a new table from scratch.

The spreadsheet UI is based on Jspreadsheet v4.

I did the app as an excuse to play around with Svelte. The experience was charming. Probably because the Svelte documentation is excellent.

There are thousands of examples of the Svelte Repl. The Svelte web doesn’t list them, but you can find them through Google (site:https://svelte.dev/repl).

The code is available on Github and open for issues and merge requests.

Example:

☝️edit me

Some technologies require high specialization; sometimes, it is not apparent until things start going wrong.

SPA (Single Page Applications)

Leaving aside that I consider that the SPA approach is wrong most of the time, a Ruby on Rails team that decides to implement the frontend as a SPA will require some specialization on Node and frontend frameworks ecosystem.

Deployment

A small company with one or two services would be enough to deploy using Capistrano or pay for some PaaS like Heroku instead of managing a complex Kubernetes or similar setup. In any case, I would not expect that the same group of people can develop backend, frontend and also be up to date in all the knowledge required to manage a proper Kubernetes infrastructure.

(Micro)-Services

Before deciding to extract or implement a new feature as a service, the same company should consider the deployment and maintenance of the new service. If they are using Capistrano, it will mean a new set of servers to manage. If they use a PaaS, it will mean spending much more money.

Event Sourcing

It is another trend in software development. There are valid use cases for this approach. Still, it entails high specialization for managing specific services like AMQP or Kafka, understanding the new technologies, researching the ecosystem for your base language, and sometimes introducing a new language.

New languages, frameworks, databases, and so on

The introduction of microservices and platforms like Kubernetes will allow experimenting on production with more languages, frameworks, and databases. All these new technologies require expertise for a good and reliable service.

If you are willing to switch to something different because you have many troubles with your current stack, consider that the new one will bring new issues and drag the ones that belong to other components of your stack.

Final thoughts

A high specialized stack requires specialized teams and makes sharing the knowledge and responsibilities harder.

I agree that a heterogeneous code simplifies the reading but recognizes that some things are personal taste. It’s not useful to apply your preferences only in a few lines if the rest of the code is not coherent.

So please, rely on a linter,  Rubocop is a good option for Ruby, but there are other alternatives.

You can discuss defining the rules as long as you want, but not on every pull request. I prefer not to invest too much time defining the rules. In the case of Rubocop, I usually start with the default config, maybe even add some extensions, like the Rails or Performance one. Then, I can modify the rules on demand, depending on the team’s taste and the project’s requirements.

It’s important to define a strategy to maintain Rubocop’s warnings. I like to auto-fix all the warnings with -a and sometimes -A.  If something else is still raising warnings then I generate a .todo_rubocop.yml with --auto-gen-config. Then I can run rubocop as part of my continuous integration and mark it as a failure if it raises a warning.

Always open the lightbox

This is what I see most often. It prevents sharing the URL or reloading the page without losing the form.

Open the lightbox on click and implement a specific view

It allows open the lightbox on click, but it allows open the link in a new tab with the browser options (CMD/ctrl+click).

If the user opens the lightbox, will lose the information in case of reloading the page, but it allows “advanced” users to open the link on a new page.

Keep the list state and append the item

/posts?page=2&order_by=title&edit=33

This approach can make the implementation a bit complex. There is no guarantee that the row we are editing will be on the same page forever. So it would cause other interaction problems. For example, the user doesn’t see in the list the item after editing it.

Replace the URL

/posts/33/edit

With this approach, when the user reloads the URL, will see only the “EDIT”, the user can always go back using the browser history.

Conclusion

There is no perfect solution as far as I know. There are other options for sure, and we can combine them. In my opinion, it is important to be aware of the problems that the lightbox presents and how to mitigate them.

In this case, I am talking about the lightbox, but It would apply to other UI solutions that try to avoid the navigation to new URLs.

Related

• Save the URL, Save the web
• Implementation of a paginated list filterable and sortable with different approaches on rails.

• Passing session tokens
• Mixing GET and POST on submitting forms without taking care of security, idempotency, or usability.
• Misconceptions about WWW (no-www and yes-www).
• Sites based on FLASH or Java applets ignore the URL completely.

AJAX replaced FLASH and Java applets bringing us reactive websites following web standards. But again, we were able to ignore or missuse the URL.

The same is happening with sites developed with SPA-oriented frameworks like React, Angular, Vu or backend powered technologies like StimimulusReflex, Hotwire, and Liveview… because the problem is not the technology. The problem is ignoring the URL.

As you can see, the problem is not inherent to SPA frameworks but can be exacerbated due to multiple reasons:

• Most of these frameworks are virtual dom-based, maintaining an internal state and updating the real dom on demand. Therefore, it is easier for the developer to ignore other sources of information like the URL.
• At least with React, “Hot reloading” allows us to update the page we are developing without losing the internal state, so you don’t feel the need to reflect the state in the URL.
• Some frontend developers with up to 10 years of experience have only worked with those frameworks, so they consider it normal behavior.
• There is a trend to design websites as web apps. Unfortunately, with that, we lose some of the features and advantages of the web.

I think it is worth remembering, however obvious, the benefits of respecting and treating URLs with affection may be.

Benefits

The URL not only allows us to find a resource (website in this case). It also lets us define the initial state, so a user will be able to:

• Save the URL for later.
• Open multiple instances of the same page in the same or different state.
• Share a page in a specific state (like a list with some filters applied).
• We can link from a page with a specific state from different apps. It allows collaboration between websites.

What do I mean when I say “status”?  Imagine a paginated list of items that can be filtered and sorted like the next one:

The status would be which page and element we are sorting, for example, using query params. We could also include filters (/posts?page=2&order_by=title).

What should we reflect in the URL?

To know if we need to reflect something in the URL, we can ask ourselves if a user, when reloading, saving, or sharing a web, would want to keep its status.

If you think it would be useful but very difficult or impossible, maybe we should check if the design is suitable for the web.

Some examples:

Probably necessary

• Pagination
• Sort of a list
• Element of a list that we are viewing
• Search filters
• Date time filters

Probably unnecessary

• Dropdown state
• Menu state, like hovering
• Scroll

Good examples

• Github search: the URL includes the query terms, pagination, and filters.
• Github code links: It allows us to link the highlighted parts of the code.
• Google search: similar to GitHub search, but the result can differ depending on other variables not part of the URL, like user preferences, geolocation, black magic, etc.
• Google Maps: It reflects in the URL zoom, position, kind of view, details of a picture, and details of a place. It updates the URL by clicking on an element or just navigating on the map.

Related

• Implementation of a paginated list, filterable and sortable with different approaches on Rails.
• Save the URL, The lightbox