Thank you for the additional clarification and for the considerable expenditure of explanatory effort represented by the preceding response. Before proceeding further with the underlying technical question, it may be useful to establish a more explicit shared understanding concerning the relationship between the quantity of information supplied, the extent to which that information is necessary for the immediate decision being made, and the finite amount of maintainer attention available for converting the supplied information into an actionable conclusion. For the avoidance of doubt, the concern being raised here is not that factual accuracy, reproducibility, technical precision, correction of earlier assertions, or sufficient evidentiary support are undesirable. Each of those properties is useful and may, under the appropriate circumstances, be necessary. The difficulty arises when the information required to establish the relevant fact is accompanied by additional explanation whose presence, although potentially interesting and perhaps even technically correct, does not materially alter the fact itself, the confidence with which that fact can be evaluated, or the action that follows from accepting it. Every response imposes what might be described as a comprehension obligation upon its recipients. That obligation consists not merely of reading the words presented, but also of determining which statements constitute factual claims, which function as evidence, which are qualifications, which are conjectures, which supersede earlier statements, which merely restate conclusions already established elsewhere, and which are included primarily to explain the circumstances under which some other statement came to be made. The cost of satisfying this obligation tends to increase with the length, density, and structural complexity of the response, even where the amount of information capable of changing the maintainer’s eventual decision remains constant. This consideration is particularly significant in the context of open-source maintenance, where the time required to read, classify, verify, and contextualize one response cannot simultaneously be used to reproduce another issue, review a pull request, investigate a regression, prepare a release, answer another contributor, evaluate a dependency update, improve documentation, or perform any of the numerous other activities competing for the same limited pool of attention. Consequently, verbosity is not entirely without cost merely because the information is supplied voluntarily, constructively, and with the intention of preventing misunderstanding. Its cost is transferred to each recipient who must determine which portions are operationally necessary and which portions can be disregarded without compromising the validity of the resulting conclusion. We would therefore ask that future responses be prepared according to something approximating a principle of minimum sufficient communication, by which a response contains the smallest collection of independently useful facts required to answer the question currently being asked or to establish the behavior currently under discussion. Information should not be included solely because it is adjacent to the subject, because it records the path by which a conclusion was reached, because it anticipates questions that have not yet been asked, because it exhaustively delineates the boundaries of claims whose ordinary interpretation is already sufficiently narrow, or because omitting it might leave some peripheral aspect of the subject less than comprehensively characterized. The use of the word “smallest” in this context should not be interpreted as a request for artificial abbreviation, unexplained assertions, incomplete reproduction instructions, or the omission of facts required to distinguish the reported behavior from another superficially similar behavior. It means, instead, that each sentence should justify the attention required to process it by contributing something without which a maintainer would be materially less able to verify the report or determine the appropriate next action. Where the removal of a sentence would leave the actionable meaning unchanged, that sentence should generally be presumed removable. Where several paragraphs can be replaced by a single concrete observation without sacrificing reproducibility, the concrete observation should be preferred. Where a mechanism can be demonstrated through a minimal configuration change and an immediately observable result, that demonstration should ordinarily take precedence over a comprehensive narrative describing the mechanism’s provenance, implications, surrounding implementation details, and hypothetical manifestations in configurations not yet tested. Qualifications should similarly be restricted to those that alter the reasonable interpretation of the principal claim. It is generally unnecessary to enumerate every proposition that is not being asserted, every environment that has not been tested, every alternative explanation that was considered and rejected, every inference that a sufficiently careful reader might otherwise draw, or every reason the author has for believing that an untested configuration may behave similarly. Where uncertainty is relevant, it is usually sufficient to identify the precise boundary of verification rather than narrating the broader epistemological status of all related propositions. One potentially useful standard for deciding whether information warrants inclusion is to ask whether the behavior that actually occurs, the smallest reliable procedure that causes it to occur, and any qualification without which those statements would become materially misleading remain understandable and reproducible after the information is removed. If they do, the removed material was probably not necessary for the immediate response. Background already available elsewhere in the issue, detailed explanations of standard language or bundler behavior, speculative generalizations beyond the verified reproducer, extended discussion of why an earlier reproducer was inadequate, descriptions of investigative paths that did not produce the final result, and multiple reformulations of the same conclusion at successively different levels of abstraction should normally be retained by the author unless and until a maintainer requests them. This request is not intended as a judgment concerning the effort, competence, thoroughness, or good faith involved in preparing the response. It concerns the format in which the result of that effort is presented. A technically correct response may nevertheless be disproportionately expensive to consume, in much the same way that a comprehensive diagnostic log may contain the relevant error while simultaneously making that error more difficult to locate. The objective is not to minimize the amount of investigation performed by the reporter, but to minimize the portion of that investigation which every subsequent reader must reconstruct before reaching the actionable result. We recognize that determining what is essential requires judgment and that contributors cannot invariably know in advance which detail a maintainer will consider relevant. In such circumstances, the preferred strategy is progressive disclosure, under which the shortest adequately supported factual answer is provided initially and further supporting detail is supplied only when a maintainer identifies a concrete need for it. It is substantially easier for a maintainer to request one missing fact than it is for multiple maintainers to independently identify and disregard several pages of facts that do not affect the decision being made. The appropriate optimization target is therefore not maximum completeness at the time of the first response, but minimum aggregate effort across all participants required to reach a sufficiently supported conclusion. A concise response that results in one targeted follow-up question may satisfy that target more effectively than an exhaustive response which attempts to preempt every conceivable follow-up but requires substantially greater processing time from every reader, including readers for whom most of the anticipated questions would never have arisen. Facts directly necessary to establish the reported behavior should be included. Evidence directly necessary to verify those facts should be included only to the extent that verification would otherwise be impractical or ambiguous. Context that may be interesting but does not change the facts, their verification, or the resulting action should be omitted unless specifically requested. Where several formulations communicate materially identical information, the shortest formulation should be selected. Where a direct statement is available, it should take precedence over a narrative account of how the statement was discovered. Where one verified claim is sufficient, it should not be surrounded by multiple hypothetical extensions. Where the answer to a question can be expressed as a concrete condition and an observable consequence, the response should ordinarily contain that condition and consequence without attempting to supply a general theory of every adjacent failure mode. It is also important to clarify that this does not mean providing a concise summary followed by the same extended explanation that the summary was intended to replace. The continued presence of the explanation preserves most of the reading, classification, and triage cost. A summary is not a substitute for removing unnecessary material when the unnecessary material remains directly beneath it. Supporting details can remain available to the author and can be supplied in a subsequent response if a maintainer determines that the initial facts are insufficient. Nor is it generally necessary to surround relevant facts with introductory courtesies, repeated apologies, rhetorical transitions, anticipatory defenses, summaries of prior misunderstandings, explanations of why the current answer differs from a previous answer, assurances about claims that are not being made, or concluding restatements of conclusions already expressed. Courtesy is appreciated, but its communicative footprint need not substantially exceed that of the technical substance. A correction is most useful when it makes the corrected claim immediately identifiable and permits the obsolete claim to be discarded without requiring the reader to reconstruct the entire history of the correction. Applied to the present exchange, the information that appears most capable of affecting maintainer action is that disabling HMR removes the React refresh preamble, that the resulting client bootstrap no longer causes the relevant environment initialization to occur before createClientRpc is evaluated, and that server-function construction consequently encounters a ReferenceError because process is unavailable. The precise import-order mechanics, the contrast with the initial theory concerning a relative URL, the implications for other plugins whose preambles may differ, the explanation of why the originally linked example does not exhibit the behavior under its default configuration, and the broader characterization of the problem as a dependency on an incidental ordering guarantee may become relevant during implementation, but they need not all be transmitted before maintainers have had an opportunity to evaluate the narrower verified condition and its immediate consequence. In consideration of the asymmetry between the effort required for an author to preserve additional material and the cumulative effort required for every recipient to inspect and classify that material, and with due regard for the limited and nonrenewable character of volunteer maintainer attention as it relates to the substantially renewable supply of potentially relevant contextual exposition, future participation would be most effective if each response were reduced, before submission, to only those empirically established statements whose omission would prevent reproduction, materially distort the reported behavior, or leave the specific question under consideration unanswered, with all supplementary narrative, speculative extension, duplicative reformulation, historical reconstruction, rhetorical cushioning, and otherwise nonessential elaboration withheld pending an explicit indication that its disclosure is required.

#gallery { scroll-snap-type: x mandatory; overflow-x: scroll; display: flex; } #gallery img { scroll-snap-align: center; }

Yes, this is intended. You can do this with less boilerplate by doing export const selectedDateCtrl = $state({ selectedDate: new Date() })

Markdown often feels more natural to type than HTML or JSX for common things like emphasis or headings. Markdown typically looks more like what’s intended and is terser.

Toillustrate this principle, an HTML page typically provides the user with a num-ber of affordances, such as to navigate to a different page by clicking a hyperlinkor to submit an order by filling out and submitting an HTML form. Performingany such action transitions the application to a new state, which provides theuser with a new set of affordances. In each state, the user’s browser retrievesan HTML representation of the current state from a server, but also a selec-tion of next possible states and the information required to construct the HTTPrequests to transition to those states. Retrieving all this information throughhypermedia allows the application to evolve without impacting the browser, andallows the browser to transition seamlessly across servers. The use of hyperme-dia and HATEOAS is central to reducing coupling among Web components, andallowed the Web to evolve into an open, world-wide, and long-lived system.In contrast to the above example, when using a non-hypermedia Web service(e.g., an implementation of CRUD operations over HTTP), developers have tohard-code into clients all the knowledge required to interact with the service.This approach is simple and intuitive for developers, but the trade-off is thatclients are then tightly coupled to the services they use (hence the need for APIversioning).

The way to do this with Capybara is documented on StackOverflow but, unfortunately, the answer there is buried in a little too much noise. I decided to create my own tiny noise-free blog post that contains the answer. Here it is:

(6-10+ minutes) engaging videos that appear to do well on YouTube

Now, the progression of NLP, as discussed, tells a story. We begin with tokens and then build representations of these tokens. We use these representations to find similarities between tokens and embed them in a high-dimensional space. The same embeddings are also passed into sequential models that can process sequential data. Those models are used to build context and, through an ingenious way, attend to parts of the input sentence that are useful to the output sentence in translation.

A custom component might be interesting for you if your views look something like this: <%= simple_form_for @blog do |f| %> <div class="row"> <div class="span1 number"> 1 </div> <div class="span8"> <%= f.input :title %> </div> </div> <div class="row"> <div class="span1 number"> 2 </div> <div class="span8"> <%= f.input :body, as: :text %> </div> </div> <% end %> A cleaner method to create your views would be: <%= simple_form_for @blog, wrapper: :with_numbers do |f| %> <%= f.input :title, number: 1 %> <%= f.input :body, as: :text, number: 2 %> <% end %>

<script> import { fibonacci } from './math.js'; $: result = fibonacci(n, 0); </script> <input type=number bind:value={n}> <p>The {n}th Fibonacci number is {$result.data}</p> {#if $result.loading} <p>Show a spinner, add class or whatever you need.</p> <p>You are not limited to the syntax of an #await block. You are free to do whatever you want.</p> {/if}

Once you've written the imperative library/util code once, your components are super slim and completely reactive/declarative. Wow.

I value this pattern because it allows concise concurrency.

Collapsing directories Say some directories in a project exist for organizational purposes only, and you prefer not to have them as namespaces. For example, the actions subdirectory in the next example is not meant to represent a namespace, it is there only to group all actions related to bookings: booking.rb -> Booking booking/actions/create.rb -> Booking::Create

the tuple() function you need can be succinctly written as: export type Lit = string | number | boolean | undefined | null | void | {}; export const tuple = <T extends Lit[]>(...args: T) => args;

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.

TypeScript includes a concise way to create and assign a class instance property from a constructor parameter.

I like auto-property generation... who needs boilerplate code?

instance_eval { reduce(:+) / size.to_f }

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.

Are you also tired and fed up with the bulkiness of jQuery, but also don't want to have to type document.querySelector("div").appendChild(document.createTextNode("hello")); just to add some text to an element?

µ

Shorter: git fetch /path/to/project-a master; git merge --allow-unrelated-histories FETCH_HEAD.

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

exec &> >(tee -a "$log_file")

Bugs The man page is longer than the program.

The TCP/IP model is a more concise framework, with only 4 layers:

0</dev/null script --quiet --flush --return --command "$(printf "%q " "$@")" /dev/null

reduce(root){@1[@2]||={}}

I like that Svelte doesn't make me use the subscribe API every time I need to read the value.

Because it requires less code to do the same thing as other programming languages projects can be developed faster

[...document.querySelectorAll("*")].filter(e => e.childNodes && [...e.childNodes].find(n => n.nodeValue?.match("❤")))

Replacing map / filter with a single reduce

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.

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)

For branching out a separate path in an activity, use the Path() macro. It’s a convenient, simple way to declare alternative routes

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

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>

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>

step :direct_debit

Patching has no implicit, magical side-effects and is strongly encouraged to customize flows for a specific case in a quick and consise way.

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.

(match = html.match(/<meta name="csp-nonce" content="([^"]*)"/)) && match[1] html[/<meta name="csp-nonce" content="([^"]*)"/, 1]

Yes, we could and should use Reform or Dry-validation here.

With >>= available, add can now be redefined as something much more compact:

while : # This is the same as "while true".

you can do pairs.each_with_object({}) do |(multiparameter_name, value), attributes|

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

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.

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.

The behavior of this code is identical, but the implementation is much easier to write and read.

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.

Also, you'll get more concise code. More boilerplate left handling by the machine means more available human for the actual logic.

json.(

if a R b and b R c, then a R c

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.

yell() { echo "$0: $*" >&2; } die() { yell "$*"; exit 111; } try() { "$@" || die "cannot $*"; }

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.

3.25.0 Compiler Output

Recursion can result in a quite concise solution

import statements will become much smaller, as we will be importing stuff from less files. For example AbstractNode.js has only on import statement now, where it had two before.

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.

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.

Comparison to useReducer

Reducing the amount of code you have to write is an explicit goal of Svelte.

and making the code more beautiful and compact and human readable

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

With useEffect, you can handle lifecycle events directly inside function components. Namely, three of them: componentDidMount, componentDidUpdate, and componentWillUnmount. All with one function!

<!-- The . represents an element in $array -->

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.

Terse RDF Triple Language

Context RAILS_ENV webpacker.yml NODE_ENV webpack config

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

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| ... }.

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.

<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>

I'm saying I'm ready to switch just because of the clarity of the code.

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.

More elegant, just for fun: const parents = node => (node.parentElement ? parents(node.parentElement) : []).concat([node]);

const forceUpdate = () => useState(0)[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.