an important historical datum

Once a card has been played, any player can say “Mischief!” and call you on your potential lie

However instead of using array.length for latter items; e.g. array[array.length-1] for the last item, you can call array.at(-1)

You can add event modifiers with the on:click$preventDefault$capture={handler} syntax. If you use Svelte's native on:click|preventDefault={handler} syntax, it will not compile. You have to use "$" instead of "|". (The extra S inside the | stands for SMUI.)

hover and resize window support #965 Closed Sorry, something went wrong. Collaborator jnicklas commented on Feb 25, 2013 Go, go @twalpole!

I have a rule that I won't allow Capybara to be monkey-patched in Poltergeist. This gives some indication to users about whether something is non-standard. So basically all non-standard stuff must be on page.driver rather than page (or a node).

What seems more problematic is divergence between drivers. For example, capybara-webkit and poltergeist support several of the same things. Let's take resizing the window as an example. In capybara-webkit this is page.driver.resize_window(x, y) and in poltergeist it's page.driver.resize(x, y). This means that if a user wants to switch from one to the other they have to change their code. Now I don't know if selenium does or doesn't support resizing the window, but supposing it doesn't I think there's still a lot of value in the capybara project deciding what the blessed API is, because then all the drivers that support that feature can implement it using the same API, increasing portability.

Provides empty Module#ruby2_keywords method, for the forward source-level compatibility against ruby2.7 and ruby3.

Here is one of the most confusing cases: def foo(x, **kwargs) p [x, kwargs] end def bar(x=1, **kwargs) p [x, kwargs] end foo({}) #=> [{}, {}] bar({}) #=> [1, {}] bar({}, **{}) #=> expected: [{}, {}], actual: [1, {}]

The automatic conversion not only confuses people but also makes the method less extensible. See [Feature #14183] for more details about the reasons for the change in behavior, and why certain implementation choices were made.

3. The no-keyword-arguments syntax (**nil) is introduced You can use **nil in a method definition to explicitly mark the method accepts no keyword arguments. Calling such methods with keyword arguments will result in an ArgumentError. (This is actually a new feature, not an incompatibility)

This is useful to make it explicit that the method does not accept keyword arguments. Otherwise, the keywords are absorbed in the rest argument in the above example.

If you extend a method to accept keyword arguments, the method may have incompatibility as follows: # If a method accepts rest argument and no `**nil` def foo(*args) p args end # Passing keywords are converted to a Hash object (even in Ruby 3.0) foo(k: 1) #=> [{:k=>1}] # If the method is extended to accept a keyword def foo(*args, mode: false) p args end # The existing call may break foo(k: 1) #=> ArgumentError: unknown keyword k

There are three minor changes about keyword arguments in Ruby 2.7.

If your code doesn’t have to run on Ruby 2.6 or older, you may try the new style in Ruby 2.7. In almost all cases, it works. Note that, however, there are unfortunate corner cases as follows:

Ruby 2.6 or before themselves have tons of corner cases in keyword arguments.

You need to explicitly delegate keyword arguments. def foo(*args, **kwargs, &block) target(*args, **kwargs, &block) end

ruby2_keywords might be removed in the future after Ruby 2.6 reaches end-of-life. At that point, we recommend to explicitly delegate keyword arguments

foo({}, **{}) #=> Ruby 2.7: [{}] (You can pass {} by explicitly passing "no" keywords)

you can use the new delegation syntax (...) that is introduced in Ruby 2.7. def foo(...) target(...) end

ruby2_keywords allows you to run the old style even in Ruby 2.7 and 3.0.

In Ruby 2, you can write a delegation method by accepting a *rest argument and a &block argument, and passing the two to the target method. In this behavior, the keyword arguments are also implicitly handled by the automatic conversion between positional and keyword arguments.

Will my code break on Ruby 2.7? A short answer is “maybe not”. The changes in Ruby 2.7 are designed as a migration path towards 3.0. While in principle, Ruby 2.7 only warns against behaviors that will change in Ruby 3, it includes some incompatible changes we consider to be minor. See the “Other minor changes” section for details. Except for the warnings and minor changes, Ruby 2.7 attempts to keep the compatibility with Ruby 2.6. So, your code will probably work on Ruby 2.7, though it may emit warnings. And by running it on Ruby 2.7, you can check if your code is ready for Ruby 3.0.

If you want to disable the deprecation warnings, please use a command-line argument -W:no-deprecated or add Warning[:deprecated] = false to your code.

However, this style is not recommended in new code, unless you are often passing a Hash as a positional argument, and are also using keyword arguments

In line with dishonest asset flippers, this has a number of fake positive reviews from compromised accounts, all in the same broken English.

Dungless is another GameMaker Studio asset flip from serial copy+paste infringers, Imperium Game. All these guys do is rip off game templates and projects from the Yoyogames/GameMaker Studio store and try to scam people into paying for someone else's work on Steam.This time they've ripped off a basic template for a 2D retro pixel platformer/brawler. In line with this asset flipping behaviour, the game was dumped immediately at launch into DailyIndieGame shovelware bundles.In line with dishonest asset flippers, this has a number of fake positive reviews from compromised accounts, all in the same broken English. Even if this wasn't just an asset flip, it would be garbage. Impossible to recommend.

Developers leave in glaring issues that should have been resolved in the base game. For example, the original development had fuel, then scrapped it, then 3 or 4 years later they realize that logistics is actually important.The monetization scheme is inherently predatory. Charge your customers for a game that without DLC is without a backbone.

it shows history well, along with a good display of alternate history!

This is somehow the only game where you can play as an anti-fascist faction in Nazi Germany, drive the Nazis into the ocean, kill Hitler and reclaim Germany as a democracy, and that's somehow the most boring possible outcome.

Before you go like “Wow!!!”, understand that the packages highlighted above take a lot into consideration when detecting timezones. This makes them slightly more accurate than Intl API alone.

Intl.DateTimeFormat().resolvedOptions().timeZone

Don’t hate me, but let’s face it, if I showed you this, you may have ignored the rest of this article lol.

Some applications mentioned here are not open source. They are listed here because they are available on Linux and the article’s focus is on Linux. Such applications are duly marked non-FOSS so that you can make a decision yourself.

function omit(obj, ...props) { const result = { ...obj }; props.forEach(function(prop) { delete result[prop]; }); return result; }

You can use computed properties along with the omit keyword in this case like so. const varName = 'name'; const { [varName]:omit, ...updatedUser } = user;

function omit(key, obj) { const { [key]: omitted, ...rest } = obj; return rest; }

"modern environments" meaning if you're shipping un-transpiled code, this will work on 93% of browsers. See full compatibility at caniuse.com/…

"balance".en.synset( :verb )

If you prefer monkeypatching (around 70) linguistics methods directly onto core classes, you can do that by adding a 'monkeypatch' option to ::use:

that's why I bolded "same column" with the or query. I can delete the comment altogether, but thought it would be helpful for people perusing "or" query SO questions.

Arel is a public API, or more precisely, it exposes one. Active Record just provides convenience methods that use it under the hood, It's completely valid to use it on it's own. It follows semantic versioning, so unless you are changing major versions (3.x.x => 4.x.x), there is no need to worry about breaking changes.

A semantic command dispatch intended for loading external dependencies into the environment.

direnv is not loading the .envrc into the current shell. It’s creating a new bash sub-process to load the stdlib, direnvrc and .envrc, and only exports the environment diff back to the original shell. This allows direnv to record the environment changes accurately and also work with all sorts of shells. It also means that aliases and functions are not exportable right now.

To cache the result of calling use guix

Normally use guix can be frustratingly slow to use.

and friends

direnv would have to do too many releases to keep up with all the other project changes

Add this to ~/.direnvrc:

watch_file .nvmrc local NVM_PATH="$HOME/.nvm/nvm.sh" if ! [ -f "$NVM_PATH" ]; then echo "Installing NVM" >&2 curl -o- https://raw.githubusercontent.com/creationix/nvm/master/install.sh | bash fi . "${NVM_PATH}" # `nvm use` will set up the environment to use some version matching what we have # in .nvmrc without talking to the network, assuming that there is any matching # version already downloaded. If there isn't (eg, you're just getting started, or # we just did a major version upgrade) then it will fail and `nvm install` will # download a matching version. nvm use || nvm install # Let you run npm-installed binaries without npx. layout node

Auto-Detect & install BigCommerce's stencil-cli Auto-Detect & install Meteor Auto-Detect & install Shopify's themekit

curl -o ~/.config/direnv/helpers.sh

# This is a configuration file for direnv (https://direnv.net/), a tool that # allows you to automatically set up environment variables based on the current # directory. If you install and enable direnv, then this file will ensure that # `nvm` is installed in your home directory and that the version of Node in # .nvmrc is selected.

Normative

There is currently no standard for transporting instances of JSON text within a stream protocol

apart from [Websockets], which is unnecessarily complex for non-browser applications

Relationship to TCP and HTTP _This section is non-normative._ The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. By default, the WebSocket Protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over Transport Layer Security (TLS) [RFC2818].

It is similarly intended to fail to establish a connection when data from other protocols, especially HTTP, is sent to a WebSocket server, for example, as might happen if an HTML "form" were submitted to a WebSocket server. This is primarily achieved by requiring that the server prove that it read the handshake, which it can only do if the handshake contains the appropriate parts, which can only be sent by a WebSocket client. In particular, at the time of writing of this specification, fields starting with |Sec-| cannot be set by an attacker from a web browser using only HTML and JavaScript APIs such as XMLHttpRequest [XMLHttpRequest].

The protocol is intended to be extensible; future versions will likely introduce additional concepts such as multiplexing.

The WebSocket Protocol is designed on the principle that there should be minimal framing (the only framing that exists is to make the protocol frame-based instead of stream-based and to support a distinction between Unicode text and binary frames). It is expected that metadata would be layered on top of WebSocket by the application Fette & Melnikov Standards Track [Page 9] RFC 6455 The WebSocket Protocol December 2011 layer, in the same way that metadata is layered on top of TCP by the application layer (e.g., HTTP). Conceptually, WebSocket is really just a layer on top of TCP that does the following: o adds a web origin-based security model for browsers o adds an addressing and protocol naming mechanism to support multiple services on one port and multiple host names on one IP address o layers a framing mechanism on top of TCP to get back to the IP packet mechanism that TCP is built on, but without length limits o includes an additional closing handshake in-band that is designed to work in the presence of proxies and other intermediaries Other than that, WebSocket adds nothing. Basically it is intended to be as close to just exposing raw TCP to script as possible given the constraints of the Web. It's also designed in such a way that its servers can share a port with HTTP servers, by having its handshake be a valid HTTP Upgrade request. One could conceptually use other protocols to establish client-server messaging, but the intent of WebSockets is to provide a relatively simple protocol that can coexist with HTTP and deployed HTTP infrastructure (such as proxies) and that is as close to TCP as is safe for use with such infrastructure given security considerations, with targeted additions to simplify usage and keep simple things simple (such as the addition of message semantics).

When an endpoint is to interpret a byte stream as UTF-8 but finds that the byte stream is not, in fact, a valid UTF-8 stream, that endpoint MUST _Fail the WebSocket Connection_. This rule applies both during the opening handshake and during subsequent data exchange.

The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).

Our members are technically self-pay; however, 100 percent of our members pay their bills. All we—and they—ask is that healthcare providers not penalize them for this technical designation. Please give our members the same consideration in terms of discounts that insurance companies receive for negotiated contracts.

SvelteKit gives you complete freedom with respect to all its features. There’s always a way to exclude a feature if you prefer to.

SvelteKit offers a very elegant solution for this — the load function. The load function can run both on the client and on the server side and in both cases will be executed before the component renders.

There are two ways SvelteKit does this: prerendering and server-side rendering

The fetch is re-executed on the client, but fetch is overloaded and never hits the network - a cached HTTP blob is shipped in the HTML and the load function uses it on the client as a kind of simple cache.

If so I think this is a very sad omittance and makes SvelteKit much harder to work with than it has to, since it's very common for many components to not want to hydrate data on the frontend after it's been loaded.This is not React. There is no hydration problem.

If the API call fails due to a stale token, the endpoint can get a new token and send it to the browser via Set-Cookie in the response headers. Note for this to work, you must ensure the endpoint is being called by the browser (not the server.) SvelteKit templates are executed first on the server, then again in the browser. If the endpoint is called from the server, the browser cookie will not be set.

Although not well-documented, fetch is available from all of these hooks. Simply add node-fetch as a dependency in package.json (not a devDependency!).

getSession() is probably not a good choice. The main purpose of this hook is create a sanitized version of the server context for the browser (like remove sensitive information like passwords/API keys.) It is called after the handle() hook, so it would be too late for setting any headers in the response.

That's because in CSS, any value at all -- even 'disabled="false"' or whatever -- is exactly the same as 'disabled' or 'disabled="disabled"'. The opposite of 'disabled="anything"' is to not have a disabled keyword in there at all.

Guiding Principles¶ Some guiding principles Nokogiri tries to follow: be secure-by-default by treating all documents as untrusted by default be a thin-as-reasonable layer on top of the underlying parsers, and don't attempt to fix behavioral differences between the parsers

HTTP CachingWe run a website called UNPKG. It serves over 70 billion requests per month without making a dent on our credit card bill. It's possible because of HTTP caching and CDNs

e.preventDefault(); // because we're progressively enhancing the 'add to cart' <form>

Do you prefer a different email validation gem? If so, open an issue with a brief explanation of how it differs from this gem. I'll add a link to it in this README.

It's now possible to move terminals between windows by detaching via Terminal: Detach Session in one window and attaching to another with Terminal: Attach to Session. In the future, this should help enable cross-window drag and drop!

Please note that the strategy: :build option must be passed to an explicit call to association, and cannot be used with implicit associations:

Are you more comfortable with multiple inheritances that modules provide, or do you prefer composition?

I guess it is more of a feeling whether to use them or not.

But having an experienced team that knows the codebase well as an argument for using them is weird and not strong.

the interesting thing here is that there are comments that say which concern depends on which.

Putting comments like these can be helpful, but it’s still set up for doing something sketchy, especially if you are new to the codebase. Being new and not being aware of all the “gotchas” a code has can certainly send you down the concern downward spiral.

By looking at the code screenshot, you are either opening your mouth in awe or in appall. I feel there is no in-between here.

What is risky here is that the concern (mixin) knows a lot about the model it gets included in. It is what is called a circular dependency. Song and Album depend on Trashable for trashing, Trashable depends on both of them for featured_authors definition. The same can be said for the fact that a trashed field needs to exist in both models in order to have the Trashable concern working.

This works nicely wherever we show authors, but after we deploy to production, the folks from other parts of the world won’t get notified anymore about their songs. Mistakes like these are easy to make when using concerns.

was due to a form that was submitted (ALWAYS SET THAT TYPE-PROPERTY ON YOUR BUTTONS!) after my onclick-event fired, but before my request had any chance to be completed.

in my case having the browser clearing it's network-tab and the reason for the next request beeing due to "Initiator: document" should have been a clue. (meaning: it's not done by some JS, but by some html functionality)

Following "NetworkError when attempting to fetch resource." only on Firefox I found the problem. It seems that Firefox' onclick event propagation interferes here with the fetch() call. As soon as I added event.preventDefault() in the onclick-handler before doing the actual fetch(), everything started to work again.

Copyright © 2007-2018

Rails' inability to automatically route my link_to and form_for in STI subclasses to the superclass is a constant source of frustration to me. +1 for fixing this bug.

You can do this elegantly with throw/catch, like this:

In most languages, there is no clean equivalent for breaking out of a recursive algorithm that uses a recursive function. In Ruby, though, there is!

it's much faster—the stack frame does not have to be carried along the "thrown symbol", and no object is created. Lightweight nonlinear flow control.

Throw it's a more elegant way to use an exception-like system as a control flow.

The most important part of this query is the with block. It's a powerful resource, but for this example, you can think of it as a "way to store a variable" that is the path of the contact you need to update, which will be dynamic depending on the record.

It just builds the path as '{1, value}', but we need to convert to text[] because that’s the type expected on the jsonb_path function.

For user-contributed data that's freeform and unstructured, use jsonb. It should perform as well as hstore, but it's more flexible and easier to work with.

SET object = object - 'b' || '{"a":1,"d":4}';

these functions above works like a so-called UPSERT (updates a field if it exists, inserts if it does not exist)

(The null result should not be confused with a SQL NULL; see the examples.)

The shell is responsible for expanding variables.

The title doesn't fit the question: it should be Show lines between two patterns. Whoever wants lines from the first line on, doesn't get his answer here

+1 to counter the drive-by downvote. I'd still use sed for this, unless you need the power of Perl regular expressions to select the delimiting lines

sed appears to be able to do this much more efficiently if a large number of files are involved. awk may be easier to remember, but sed seems to be worth a sticky note in my brain.

Any tips on how to make it exclusive (for any generic situation, not just OP's)?

This is one of the more-satisfying ruby expressions I've seen in a long time. I can't say that it also has prosaic transparency, but I think seeing it teaches important things.

x = -3 "++-"[x <=> 0] # => "-" x = 0 "++-"[x <=> 0] # => "+" x = 3 "++-"[x <=> 0] # => "+"

I think that it's nonsense not to have a method that just gives -1 or +1. Even BASIC has such a function SGN(n). Why should we have to deal with Strings when it's numbers we want to work with. But's that's just MHO.

As for why - a GET can be cached and in a browser, refreshed. Over and over and over. This means that if you make the same GET again, you will insert into your database again. Consider what this may mean if the GET becomes a link and it gets crawled by a search engine. You will have your database full of duplicate data.

This is not advice. A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

has the same effect (that is no side effect)

The difference between PUT and POST is that PUT is idempotent: calling it once or several times successively has the same effect (that is no side effect), whereas successive identical POST requests may have additional effects, akin to placing an order several times.

Why is there a reservation fee?The main reason for reservations is to ensure an orderly and fair ordering process for customers when Steam Deck inventory becomes available. The additional fee gives us a clearer signal of intent to purchase, which gives us better data to balance supply chain, inventory, and regional distribution leading up to launch.

Steam Deck is a PC so you can install third party software and operating systems.

Induction does not pander, but gives you the satisfaction of mastering an imaginary yet honest set of physical laws.

Across more than 50 meticulously designed puzzles

you must explore the counter-intuitive possibilities time travel permits. You will learn to choreograph your actions across multiple timelines, and to construct seemingly impossible solutions, such as paradoxical time loops, where the future depends on the past and the past depends on the future.

> I should have used "side-effect-free" instead of "idempotent" in my tweetsThe HTTP term is "safe method".

whereas now, they know that user@domain.com was subscribed to xyz.net at some point and is unsubscribing. Information is gold. Replace user@domain with abcd@senate and xyz.net with warezxxx.net and you've got tabloid gold.

While Microsoft is entirely in the right by reminding people of the terms they agreed to, many users are taking issue with the fact that they hadn’t been warned about the limit in the eight years it’s been in place, and many people are now being told they are over the limit after years of being over.

password reset on another account which goes into Hotmail and is then read and stolen by the hackers who gain control of that other account.

Sending body/payload in a GET request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in GET requests.

Requests using GET should only be used to request data (they shouldn't include data).

So long as the filters are only using GET requests to pull down links, there’s nothing fundamentally wrong with them. It’s a basic (though oft-ignored) tenet of web development that GET requests should be idempotent; that is, they shouldn’t somehow change anything important on the server. That’s what POST is for. A lot of people ignore this for convenience’s sake, but this is just one way that you can get bitten. Anyone remember the Google Web Accelerator that came out a while ago, then promptly disappeared? It’d pre-fetch links on a page to speed up things if you clicked them later on. And if one of those links happened to delete something from a blog, or log you out… well, then you begin to see why GET shouldn’t change things. So yes, the perfect solution to this is a 2-step unsubscribe link: the first step takes to you a page with a form on it, and that form then POSTs something back that finalizes the unsubscribe request.

Two step unsubscribe, where the link in the email goes to a webpage with a prominent “click here to unsubscribe” button is often a good thing for unsubscription. It also gives people an option to not unsubscribe, when they click on the wrong link, or hit “return” with the wrong link focused, in a mail inadvertently, which isn’t that unusual in link-laden emails.

Idempotent just means that following a link twice has exactly the same effect on persistent state as clicking it once. It does not mean that following the link must not change state, just that after following it once, following it again must not change state further. There are good reasons to avoid GET requests for changing state, but that’s not what idempotent means.

Arguably any link that performs such an action via GET is fundamentally broken. A proper unsubscribe should direct to a page with a form that requires a POST submission. (Of course, in the real world, few things are proper.)

Assuming that people trust your site, abusing redirections like this can help avoid spam filters or other automated filtering on forums/comment forms/etc. by appearing to link to pages on your site. Very few people will click on a link to https://evilphishingsite.example.com, but they might click on https://catphotos.example.com?redirect=https://evilphishingsite.example.com, especially if it was formatted as https://catphotos.example.com to hide the redirection from casual inspection - even if you look in the status bar while hovering over that, it starts with a reasonable looking string.

An HTTP method is safe if it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation.

All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe.

Each of them implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be safe, idempotent, or cacheable.

request method can be safe, idempotent, or cacheable.

I don't like that I can't really use head? to know it's a HEAD request, but I (think I) understand the reasoning

Testing at GitLab is a first class citizen, not an afterthought. It’s important we consider the design of our tests as we do the design of our features.

That's it! Just replace let! with let_it_be. That's equal to the before_all approach but requires less refactoring.

That technique works pretty good but requires us to use instance variables and define everything at once. Thus it's not easy to refactor existing tests which use let/let! instead.

(Not a Boolean attribute!)

A big gotcha needs to be mentioned: When testing transaction, you need to turn off transactional_fixtures. This is because the test framework (e.g Rspec) wraps the test case in transaction block. The after_commit is never called because nothing is really committed. Expecting rollback inside transaction doesn't work either even if you use :requires_new => true. Instead, transaction gets rolled back after the test runs.

urql stays true to server data and doesn’t provide functions to manage local state like Apollo Client does. In my opinion, this is perfectly fine as full-on libraries to manage local state in React are becoming less needed. Mixing server-side state and local state seems ideal at first (one place for all states) but can lead to problems when you need to figure out which data is fresh versus which is stale and when to update it.

Looking deeper, you can see a large amount of issues open, bugs taking months to fix, and pull requests never seem to be merged from outside contributors. Apollo seems unfocused on building the great client package the community wants.

This sort of behaviour indicates to me that Apollo is using open-source merely for marketing and not to make their product better. The company wants you to get familiar with Apollo Client and then buy into their products, not truly open-source software in my opinion. This is one of the negatives of the open-core business model.

This “bloat,” along with recently seeing how mismanaged the open-source community is, finally broke the camel’s back for me. I realized that I needed to look elsewhere for a GraphQL client library.