10,000 Matching Annotations
  1. Feb 2021
    1. The IO monad wraps computations in the following context: "This computation can read information from or write information to the terminal, file system, operating system, and/or network". If you want to get user input, print a message to the user, read information from a file, or make a network call, you'll need to do so within the IO Monad. These are "side effects". We cannot perform them from "pure" Haskell code.
    1. provide interfaces so you don’t have to think about them

      Question to myself: Is not having to think about it actually a good goal to have? Is it at odds with making intentional/well-considered decisions?  Obviously there are still many of interesting decisions to make even when using a framework that provides conventions and standardization and makes some decisions for you...

    1. Trailblazer goes further and provides an approach to model entire life-cycles of business objects, such as "a song" or "the root user" using workflow (pro feature). Also, you don't have to use the DSL but can use the editor instead (cool for more complex, long-running flows).
    2. Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.
    3. 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. 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. TRAILBLAZER-TEST The official stable release is only weeks away bringing you a bunch of new assertions that drastically reduce coding effort for tests! Of course, Minitest and RSpec will both be supported. TRAILBLAZER-STORY will follow as it turned out to be inevitable for setting up application state for tests. Instead of fumbling around with factories and traits in your tests, you “tell a story” about what to create in which order, easily customizable, and all written using activities. Currently, I’m working on designing the interfaces and it’s real fun!
    2. In the past 1 ½ years something weird happened: a real core team formed around the Trailblazer gems. I say “real” because in the past 15 years of OSS, I’ve had people come and go, being of great help but never staying and taking over long-term responsibilities - which I found to be the pivotal element of a core team. Eventually, those kids convinced me to start the Trailblazer organization on Github and move over all “apotonick gems”. Over the course of time, I saw myself giving away that aforementioned responsibility with a smile on my face, adding owners and collaborators to gems, yes, even giving away entire gems, letting people work on documentation and just trusting someone and their skills. I have no words to describe how good that feels!
    3. What this means is: I better refrain from writing a new book and we rather focus on more and better docs.

      I'm glad. I didn't like that the book (which is essentially a form of documentation/tutorial) was proprietary.

      I think it's better to make documentation and tutorials be community-driven free content

    4. Using a terminus to indicate a certain outcome - in turn - allows for much stronger interfaces across nested activities and less guessing! For example, in the new endpoint gem, the not_found terminus is then wired to a special “404 track” that handles the case of “model not found”. The beautiful thing here is: there is no guessing by inspecting ctx[:model] or the like - the not_found end has only one meaning!
    5. 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.
    6. The new 2.1 version comes with a few necessary but reasonable changes in method signatures. As painful as that might sound to your Rails-spoiled ears, we preferred to fix design mistakes now before dragging them on forever.
    7. We try to keep the “information architecture” - a word I wouldn’t have learned without the inspiring Alex Coles - as simple as possible: so far, we got a handful of pages accessible through the top navigation, and then the documentation behind the DOCS link. Here, the right sidebar helps you to navigate within the chapter.
    8. I feel how needed those new abstractions are. Yes, you can write everything with your own code, you don’t need abstractions for flow control and automatic error handling, which makes me wonder why you’re not programming in assembler since Ruby is also an “unnecessary abstraction” on top of a processor. We need abstractions, unless you want to program like we did 30 years ago.
    9. ather, data is passed around from operation to operation, from step to step. We use OOP and inheritance solely for compile-time configuration. You define classes, steps, tracks and flows, inherit those, customize them using Ruby’s built-in mechanics, but this all happens at compile-time. At runtime, no structures are changed anymore, your code is executed dynamically but only the ctx (formerly options) and its objects are mutated. This massively improves the code quality and with it, the runtime stability
    10. The work put into Trailblazer 2.1 has been tremendous, it could easily have been TRB 3.0, or even TRB III, since Roman version numbering turns out to be quite a fancy thing to do. However, as much as the internals have been improved, as little has changed on the public APIs of Trailblazer, so we decided to go with a minor release.

    Tags

    Annotators

    URL

    1. There are two definitions of ‘Enterprise’ 1 - Enterprise as a business. In fact, in French, ‘enterprise’ literally means ‘business’ 2- Enterprise as a large business. This is the most common use of the term in business, differentiating between small, medium, and large businesses. In this context, there is no official rule, however it is generally accepted for enterprise to mean companies with over 1,000 employees and/or $1B in revenue
    1. Our company reinvests our funds straight back into developing all Trailblazer gems, better documentation and support, plus building up a nice team of fantastic people to help you with Trailblazer.
    1. The endpoint gem is the missing link between your routing framework and your business code. It acts like a mix of before_filters and “responder” that handles authentication and authorization, invoking your actual logic, and rendering a response.
    1. Any "rising above" is meta. When works do it about themselves, that of course is meta as well: the specific kind of meta which is self-referential (what Hostadter calls a Strange Loop. BTW, do you know what Hofstadter's motto is? "I'm So Meta, Even This Acronym")
    1. One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
    1. What is the opposite of free content?

      The opposite of free/open-source software is proprietary software or non-free software (https://en.wikipedia.org/wiki/Proprietary_software).

      So should we call the opposite of free content "non-free content"? Or "proprietary content"?

      Seems likes either would be fine.

      Looks like https://en.wikipedia.org/wiki/Wikipedia:Non-free_content prefers the term "non-free content".

      Couldn't find anyone contrasting these 2 terms (like I could no doubt find for software):

      Not to be confused with:

      • paid content ... just like:
      • free content should not be confused with gratis content (?)
      • free software should not be confused with freeware
    2. A free cultural work (free content) is, according to the definition of Free Cultural Works, one that has no significant legal restriction on people's freedom to: use the content and benefit from using it, study the content and apply what is learned, make and distribute copies of the content, change and improve the content and distribute these derivative works.
    1. note that TRB source code modifications are not proprietary

      In other words, you can build on this software in your proprietary software but can't change the Trailblazer source unless you're willing to contribute it back.

      loophole: I wonder if this will actually just push people to move their code -- which at the core is/would be a direction modification to the source code - out to a separate module. That's so easy to do with Ruby, so this restriction hardly seems like it would have any effect on encouraging contributions.

    2. The LGPL allows users to use and integrate LGPL software components into their own software without being required to release the source code of their own software components. However, if users modify LGPL software components (“derivative work”), they are required to make the modified software component available under the same LGPL license. To avoid the latter with TRB, users have to comply with para. 5 LGPLv2.1: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. In other words: if you use the TRB libraries in your commercial applications or Open-Source projects, you’re not creating a derivative work of Trailblazer. Your software can be distributed under any terms.
    1. People who buy this buy for a reason, bonsai and some gaming experience. I'm disappointed from what I saw. I'd love to turn back and give another chance after it's completed. For now what I can say is it really amazes me how people here tend to glorify things easily while writing reviews.
    1. Note: This question has been edited since it was asked. The original title was "Test whether a glob has any matches in bash". The specific shell, 'bash', was dropped from the question after I published my answer. The editing of the question's title makes my answer appear to be in error. I hope someone can amend or at least address this change.