71 Matching Annotations
  1. Jul 2025
  2. Jun 2025
  3. Apr 2025
  4. Sep 2024
  5. Jan 2024
  6. Nov 2023
    1. ActiveRecord::Base.normalizes declares an attribute normalization. The normalization is applied when the attribute is assigned or updated, and the normalized value will be persisted to the database. The normalization is also applied to the corresponding keyword argument of query methods, allowing records to be queried using unnormalized values.

      Guess I don't need to use mdeering/attribute_normalizer gem anymore...

  7. Jun 2023
    1. I think we have a responsibility not only to ourselves, but also to each other, to our community, not to use Ruby only in the ways that are either implicitly or explicitly promoted to us, but to explore the fringes, and wrestle with new and experimental features and techniques, so that as many different perspectives as possible inform on the question of “is this good or not”.
    2. If you’ll forgive the pun, there are no constants in programming – the opinions that Rails enshrines, even for great benefit, will change, and even the principles of O-O design are only principles, not immutable laws that should be blindly followed for the rest of time. There will be other ways of doing things. Change is inevitable.
  8. Nov 2022
  9. Apr 2022
  10. Mar 2022
  11. Oct 2021
  12. Sep 2021
    1. Update API usage of the view helpers by changing javascript_packs_with_chunks_tag and stylesheet_packs_with_chunks_tag to javascript_pack_tag and stylesheet_pack_tag. Ensure that your layouts and views will only have at most one call to javascript_pack_tag or stylesheet_pack_tag. You can now pass multiple bundles to these view helper methods.

      Good move. Rather than having 2 different methods, and requiring people to "go out of their way" to "opt in" to using chunks by using the longer-named javascript_packs_with_chunks_tag, they changed it to just use chunks by default, out of the box.

      Now they don't need 2 similar but separate methods that do nearly the same, which makes things simpler and easier to understand (no longer have to stop and ask oneself, which one should I use? what's the difference?).

      You can't get it "wrong" now because there's only one option.

      And by switching that method to use the shorter name, it makes it clearer that that is the usual/common/recommended way to go.

    2. Webpacker used to configure Webpack indirectly, which lead to a complicated secondary configuration process. This was done in order to provide default configurations for the most popular frameworks, but ended up creating more complexity than it cured. So now Webpacker delegates all configuration directly to Webpack's default configuration setup.

      more trouble than it's worth

      • creating more complexity than it cured
  13. Aug 2021
  14. Jun 2021
  15. May 2021
  16. Apr 2021
  17. Mar 2021
  18. Feb 2021
    1. The activity gem is an extraction from Trailblazer 2.0, where we only had operations. Operations expose a linear flow which goes into one direction, only. While this was a massive improvement over messily nested code, we soon decided it’s cool being able to model non-linear flows. This is why activities are the major concept since Trailblazer 2.1.
    1. While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
    1. Yes, Trailblazer is adding new abstractions and concepts and they are different to the 90s-Ruby, but now, at the latest, it becomes obvious how this improves the developing process. We’re no longer talking in two-dimensional method stack traces or byebug hoops, the language and conception is changing to the actual higher level code flow, to activities sitting in activities structured into smaller step units.
    1. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website. This became painfully apparent when we noticed other people post OpenTTD on some stores. They are not always updated with new releases, sometimes even slacking behind a few years. And maybe more important to us: we can not guarantee that the uploaded version is unmodified and is the version as we intended. So, instead of fighting it, why not turn around and join them! Why not release our own, verified, builds on those stores! And this is exactly what we have been working on lately. And when I say “we”, a bit ironic to me, I mean the two developers that are around longest (myself and orudge) ;) A while back orudge added OpenTTD to the Microsoft Store. And today, I am happy to announce we will be on SteamE too! Well, we are on Steam, but we haven’t released anything there yet (sorry that I got your hopes up, just to squash them right after :( ). This is partially because of how Steam works, but also because we know we can bring a better experience for Steam with our upcoming release. That brings me to the most exciting news: if everything goes as planned, we will release OpenTTD 1.11 on Steam on the first of April, 2021! And that is not even an April fools’ joke! You can already Wishlist OpenTTD today .. and till we release on Steam, you can find our game via our website ;)
    1. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website.
  19. Dec 2020
  20. Nov 2020
    1. If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
  21. Oct 2020
    1. Note how we have to duplicate the code between these two lifecycle methods in class. This is because in many cases we want to perform the same side effect regardless of whether the component just mounted, or if it has been updated. Conceptually, we want it to happen after every render — but React class components don’t have a method like this. We could extract a separate method but we would still have to call it in two places.
  22. Sep 2020
  23. Aug 2020
  24. Jun 2020
  25. Mar 2020
    1. Q. Why does Rubinius not support frozen and tainted? A. Rubinius has better features; frozen and tainted are considered harmful. To elaborate... Both frozen and tainted depend on strewing checks throughout the source code. As a classic weak-link system, only one of those checks needs to be misplaced for the guarantees offered by either to fail. Since the number of checks is high, and as new code is written new checks need to be considered, the features inherently constitute unbounded complexity and unbounded risk.
  26. Dec 2019