67 Matching Annotations
  1. Aug 2021
  2. Jun 2021
    1. Giving peers permission to engage in dialogue about race and holding a lofty expectation that they will stay engaged in these conversations throughout the semester or year is the first of the four agreements for courageous conversation. While initially, some participants may be eager to enter into these conversations, our experience indicates that the more personal and thus risky these topics get, the more difficult it is for participants to stay committed and engaged." Singleton and Hays

    1. But what's the matter with "raw" instance variables? They are internal to your instance; the only code that will call them by name is code inside pancake.rb which is all yours. The fact that they start with @, which I assume made you say "blech", is what makes them private. Think of @ as shorthand for private if you like.

      I agree / like that: @ is just shorthand for private.

      But OP clarified in a comment that the @ itself is not what they disliked: it was the accessing data directly instead of going through an accessor method.

      The raw variable is the implementation, the accessor is the interface. Should I ignore the interface because I'm internal to the instance?

    1. instance_eval { reduce(:+) / size.to_f }
    2. Or if you're looking for a core extension that adds this to the Array class, I'd recommend the facets gem (require 'facets/array/average'). Then you can just do array.average. And, from looking at the source, it turns out they do the exact same thing as the instance_eval approach above. The only difference is that it's implemented as a method—which of course already has self pointing to itself—instead of a block): def average; return nil if empty?; reduce(:+) / length.to_f; end Main advantage of this is that it's even more concise/readable and it handles the empty? case.
  3. May 2021
  4. Apr 2021
    1. There are several built in classes you can add as formatters. You can use a symbol to reference built in formatters. logger.formatter.add(Hash, :pretty_print) # use the Formatter::PrettyPrintFormatter for all Hashes logger.formatter.add(Hash, Lumberjack::Formatter::PrettyPrintFormatter.new) # alternative using a formatter instance
    1. Bugs The man page is longer than the program.

      I assume "the program" is referring to this file:

      https://core.tcl-lang.org/expect/file?name=example/unbuffer&ci=trunk

      , which compared to the source for man page, is in fact much smaller (about 1/2 the length).

  5. Mar 2021
    1. I like that Svelte doesn't make me use the subscribe API every time I need to read the value.
    1. The absence of a method name here is per design: this object does only one thing, and hence what it does is reflected in the class name.
  6. Feb 2021
    1. To understand this helper, you should understand that every step invocation calls Output() for you behind the scenes. The following DSL use is identical to the one [above]. class Execute < Trailblazer::Activity::Railway step :find_provider, Output(Trailblazer::Activity::Left, :failure) => Track(:failure), Output(Trailblazer::Activity::Right, :success) => Track(:success)
    2. For branching out a separate path in an activity, use the Path() macro. It’s a convenient, simple way to declare alternative routes

      Seems like this would be a very common need: once you switch to a custom failure track, you want it to stay on that track until the end!!!

      The problem is that in a Railway, everything automatically has 2 outputs. But we really only need one (which is exactly what Path gives us). And you end up fighting the defaults when there are the automatic 2 outputs, because you have to remember to explicitly/verbosely redirect all of those outputs or they may end up going somewhere you don't want them to go.

      The default behavior of everything going to the next defined step is not helpful for doing that, and in fact is quite frustrating because you don't want unrelated steps to accidentally end up on one of the tasks in your custom failure track.

      And you can't use fail for custom-track steps becase that breaks magnetic_to for some reason.

      I was finding myself very in need of something like this, and was about to write my own DSL, but then I discovered this. I still think it needs a better DSL than this, but at least they provided a way to do this. Much needed.

      For this example, I might write something like this:

      step :decide_type, Output(Activity::Left, :credit_card) => Track(:with_credit_card)
      
      # Create the track, which would automatically create an implicit End with the same id.
      Track(:with_credit_card) do
          step :authorize
          step :charge
      end
      

      I guess that's not much different than theirs. Main improvement is it avoids ugly need to specify end_id/end_task.

      But that wouldn't actually be enough either in this example, because you would actually want to have a failure track there and a path doesn't have one ... so it sounds like Subprocess and a new self-contained ProcessCreditCard Railway would be the best solution for this particular example... Subprocess is the ultimate in flexibility and gives us all the flexibility we need)


      But what if you had a path that you needed to direct to from 2 different tasks' outputs?

      Example: I came up with this, but it takes a lot of effort to keep my custom path/track hidden/"isolated" and prevent other tasks from automatically/implicitly going into those steps:

      class Example::ValidationErrorTrack < Trailblazer::Activity::Railway
        step :validate_model, Output(:failure) => Track(:validation_error)
        step :save,           Output(:failure) => Track(:validation_error)
      
        # Can't use fail here or the magnetic_to won't work and  Track(:validation_error) won't work
        step :log_validation_error, magnetic_to: :validation_error,
          Output(:success) => End(:validation_error), 
          Output(:failure) => End(:validation_error) 
      end
      
      puts Trailblazer::Developer.render o
      Reloading...
      
      #<Start/:default>
       {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
       {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
       {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Right} => #<End/:success>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Left} => #<End/:validation_error>
       {Trailblazer::Activity::Right} => #<End/:validation_error>
      #<End/:success>
      
      #<End/:validation_error>
      
      #<End/:failure>
      

      Now attempt to do it with Path... Does the Path() have an ID we can reference? Or maybe we just keep a reference to the object and use it directly in 2 different places?

      class Example::ValidationErrorTrack::VPathHelper1 < Trailblazer::Activity::Railway
         validation_error_path = Path(end_id: "End.validation_error", end_task: End(:validation_error)) do
          step :log_validation_error
        end
        step :validate_model, Output(:failure) => validation_error_path
        step :save,           Output(:failure) => validation_error_path
      end
      
      o=Example::ValidationErrorTrack::VPathHelper1; puts Trailblazer::Developer.render o
      Reloading...
      
      #<Start/:default>
       {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model>
       {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Right} => #<End/:validation_error>
      #<Trailblazer::Activity::TaskBuilder::Task user_proc=save>
       {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error>
       {Trailblazer::Activity::Right} => #<End/:success>
      #<End/:success>
      
      #<End/:validation_error>
      
      #<End/:failure>
      

      It's just too bad that:

      • there's not a Railway helper in case you want multiple outputs, though we could probably create one pretty easily using Path as our template
      • we can't "inline" a separate Railway acitivity (Subprocess "nests" it rather than "inlines")
    3. step :direct_debit

      I don't think we would/should really want to make this the "success" (Right) path and :credit_card be the "failure" (Left) track.

      Maybe it's okay to repurpose Left and Right for something other than failure/success ... but only if we can actually change the default semantic of those signals/outputs. Is that possible? Maybe there's a way to override or delete the default outputs?

    4. Patching has no implicit, magical side-effects and is strongly encouraged to customize flows for a specific case in a quick and consise way.
    5. This connects the failure output to the previous task, which might create an infinity loop and waste your computing time - it is solely here for demonstrational purposes.
    1. you can do pairs.each_with_object({}) do |(multiparameter_name, value), attributes|
    2. values_with_empty_parameters.each_value.all?(&:nil?) This comment has been minimized. Show comment Hide comment Copy link Quote reply egilburg on Apr 9, 2015 Contributor you can do values_with_empty_parameters.values.none? [nil, nil].none? => true Pick your reaction egilburg on Apr 9, 2015 Contributor you can do values_with_empty_parameters.values.none? [nil, nil].none? => true
    1. Finally, you can use fields_for in order to create/edit associated fields and the suffix _list (like profile_list below) to choose an existing associated record.
    1. The goal of the header copy is to say just enough to get the user to convert without getting in their way. Appcues says all they need to in one concise and straightforward sentence.
  7. Jan 2021
    1. The behavior of this code is identical, but the implementation is much easier to write and read.
    2. While custom iterators are a useful tool, their creation requires careful programming due to the need to explicitly maintain their internal state. Generator functions provide a powerful alternative: they allow you to define an iterative algorithm by writing a single function whose execution is not continuous. Generator functions are written using the function* syntax.
  8. Dec 2020
    1. json.(

      I don't care what the Rubocop style guide says about this; this is nicer and cleaner than typing json.call(...).

  9. Nov 2020
    1. In Svelte, all reactive statements are memoized. Instead of const var = useMemo(() => expression, dependencies), you can use $: var = expression. Notice with Svelte, you don't need to declare the dependencies. The compiler infers them for you.
    1. When people write COND && COMMAND, typically they mean "if COND succeeds (or is boolean true), then execute COMMAND. Regardless, proceed to the next line of the script." It's a very convenient shorthand for a full "if/then/fi" clause.
  10. Oct 2020
    1. first sighting: use of superscripts like this

      I like it. Nice and concise and understandable.

      • s¹  critical
      • s²  important
      • s³  nice to have
      • s⁴  low
      • s⁵  inconvenient

      But in other cases, the abbreviation is quite unclear and ambiguity:

      Like, what does "pr" mean in these cases?

      priority? Doubt it.

      • pr¹  chore
      • pr²  docs
      • pr³  feature
      • pr⁴  fix
      • pr⁵  performance
      • pr⁶  refactor
      • pr⁷  style

      Pull Request? Doubt it. But maybe?


      For axes that are quantifiable, like severity, using a number makes sense. But what benefit is there in including a number in these (platform?) labels?:

      • p¹ ⋅ browser
      • p² ⋅ linux
      • p³ ⋅ mac
      • p⁴ ⋅ windows

      I think this would have been better and clearer (in that fewer people would be like huh? and wonder what it means):

      • platform: browser
      • platform: linux
      • platform: mac
      • platform: windows
    1. hyperscript is more concise because it's just a function call and doesn't require a closing tag. Using it will greatly simplify your tooling chain.

      I suppose this is also an argument that Python tries to make? That other languages have this con:

      • cons: closing tags make it more verbose / increase duplication and that Python is simpler / more concise because it uses indentation instead of closing delimiters like end or } ?
    1. But this is starting to become rather verbose at what could be a much simpler and more elegant solution if only there were another template helper that could do variable assignment.
  11. Sep 2020
    1. We should also allow passing unrecognised props to the rendered component. eg: tabindex might be required on some instances of a component, and not all. Why should developers have to add tabindex support to their components just that it may potentially be used

      Glad to hear this is solved now: $restProps

    1. With useEffect, you can handle lifecycle events directly inside function components. Namely, three of them: componentDidMount, componentDidUpdate, and componentWillUnmount. All with one function!
  12. Aug 2020
    1. Then when giving answers I'm even less certain. For example I see occasional how-to questions which (IMO) are ridiculously complex in bash, awk, sed, etc. but trivial in python, (<10 lines, no non-standard libraries). On such questions I wait and see if other answers are forthcoming. But if they get no answers, I'm not sure if I should give my 10 lines of python or not.
  13. Jul 2020
    1. preventDefault — calls event.preventDefault() before running the handler. Useful for client-side form handling, for example. stopPropagation — calls event.stopPropagation(), preventing the event reaching the next element passive — improves scrolling performance on touch/wheel events (Svelte will add it automatically where it's safe to do so) capture — fires the handler during the capture phase instead of the bubbling phase (MDN docs) once — remove the handler after the first time it runs self — only trigger handler if event.target is the element itself
    1. Why don't you allow a range without end, like (1..)? There are two advantages. First, we can write ary[1..] instead of ary[1..-1]. The -1 is one of the most I dislike in Ruby. It is very magical, ugly, redundant, and disappointing. I envy Python's ary[1:]. I know that ary.drop(1) is slightly fast, but too long for such a common operation, IMO. Second, we can write (1..).each {|n| ... }.
  14. Jun 2020
    1. I was just expressing that, even thought I like React, I dread having to still manually handle everything, instead of just using a directive, a la Vue.JS. This is what I consider boilerplate. Hence my comment on how I could leave React for Svelte just because of that. Clearly a Svelte side-by-side code comparison shows a much cleaner code for Svelte.
    2. <script> let a = 1; let b = 2; </script> <input type="number" bind:value={a}> <input type="number" bind:value={b}> <p>{a} + {b} = {a + b}</p>
    3. I'm saying I'm ready to switch just because of the clarity of the code.
  15. Apr 2020
    1. Finally, from a practical point of view, we suggest the adoption of "privacy label," food-like notices, that provide the required information in an easily understandable manner, making the privacy policies easier to read.
  16. Nov 2019
  17. Sep 2019
  18. Dec 2017
    1. The IRB helps to make sure that the risks of the proposed research are minimized, the benefits outweigh the risks, the research is carried out in a fair manner, and the informed consent procedure is adequate.

      Clear and concise explanation of exactly what IRBs do.