The diagram raises an interesting question which you may not have thought about before. How does all the information from the internet get to the right device inside the network? If you visit howtogeek.com on your laptop how does it end up on your laptop and not your son’s desktop if the public-facing IP address is the same for all devices? Advertisement pagespeed.lazyLoadImages.overrideAttributeFunctions();tmntag.cmd.push(function(){tmntag.adTag('purch_Y_C_0_1', false);}); This is thanks to a wonderful bit of routing magic known as a Network Address Translation (NAT).

the whole language is a shame, but it's so useful :)

If you're using bash, you don't need to use sed to do string replacements (and it's much cleaner to use the replace feature built into bash).

We tag and release gems according to the Semantic Versioning principle. As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision.

Nested contexts tags are overwritten not merged: TestProf::LetItBe.configure do |config| config.default_modifiers[:freeze] = false end context "with reload", let_it_be_modifiers: {reload: true} do # uses freeze: false, reload: true here context "with freeze", let_it_be_modifiers: {freeze: true} do # uses only freeze: true (reload: true is overwritten by new metadata) end end

config.define_derived_metadata(let_it_be_frost: true) do |metadata| metadata[:let_it_be_modifiers] ||= {freeze: true} end

Thus it's not easy to refactor existing tests which use let/let! instead.

It's well-suited for dev/test since it doesn't need an external infrastructure, but it's a poor fit for production since it drops pending jobs on restart.

declaration accepts: | null | [] | [null] | [{foo: 'BAR'}] ------------------------------------------------------------------------ [Vote!]! | no | yes | no | yes [Vote]! | no | yes | yes | yes [Vote!] | yes | yes | no | yes [Vote] | yes | yes | yes | yes

[Vote!]! means that the field (in this case votes) cannot return null and that it must resolve to an array and that none of the individuals items inside that array can be null. So [] and [{}] and [{foo: 'BAR'}] would all be valid (assuming foo is non-null). However, the following would throw: [{foo: 'BAR'}, null] [Vote]! means that the field cannot return null, but any individual item in the returned list can be null. [Vote!] means that the entire field can be null, but if it does return a value, it needs to an array and each item in that array cannot be null. [Vote] means that the entire field can be null, but if it does return a value, it needs to an array. However, any member of the array may also be null.

I could look into this more to understand where things are going wrong, if you can suggest to me which part of the way this is working might be off.

Besides that configuration, SvelteKit is just a normal Vite project that does rendering on both SSR and client-side.

Two wrongs don't make a right We should fix it in popper core. I sent a PR there: floating-ui/floating-ui#1342

Just import it the normal way. Then Vite can use the CJS version on the server-side and ESM version on the client-side. Forcing it to always be ESM breaks SSR with the latest SvelteKit.

The code isn't going back to the way it was So otherwise you'll be stuck on an old version forever...

Deeply importing Svelte components is not supported. Either import all components from one entrypoint, or always stick to deep imports, otherwise it could cause multiple instance of the Svelte library running.

So, underscores are not quite as good as spaces. They’re a compromise of language, readability, and semantics, but they’re the best we’ve got. Better than dashes, CamelCase, plus+signs, or anything else. So use them.

The “use spaces, or else fall back on quotes” system is just silly.

This post is like a year old... Does not matter ,

It allows you to access common components and utility modules without ../../../../ nonsense.

The difficulty is that the square brackets accessor doesn't allow a straightforward way to access items from the end of the array, and also doesn't accept a negative index.

function intersperse<T>(this: T[], mkT: (ix: number) => T): T[] { return this.reduce((acc: T[], d, ix) => [...acc, mkT(ix), d], []).slice(1); }

you might consider using Object.defineProperty to ensure the property is not enumerable:

A Map of root-level context key-value pairs to supply to the component

Tip for those who run into the same error message and find this bug report by Google: Your cause for this error message might be a different cause entirely. To find your cause, set a breakpoint, and look at the call stack.

We couldn't see the cause due to the horrific error message from Sapper. grr at Sapper.

Moving to devDependency worked, but why?

This means that underscores allow humans to be able to space out the words used, but computers lack the ability to do so.

This is because using hyphens instead of underscores makes it easier for Google’s web crawler to compute the information that your website has and create consistent results.

The product may not be compatible with routers or gateways with firmware that has been altered, is based on open source programs, or is non-standard or outdated

Just FYI, there is a nice way to "expect a change" in RSpec. You don't have to use it, what you have is fine, just thought I'd share. expect { widget.paper_trail.update_columns(name: "Bugle") }.to(change { widget.versions.length }).from(1).to(2)

I'd prefer a "guard clause" here. return unless enabled?

TylerRick commented

Wait, I'm still interested in a solution to this problem/need! (no activity doesn't necessarily = no interest. I totally understand if the maintainers just aren't interested in implementing this and would rather someone submit a PR... but would it have been any different if I'd pinged this thread every 5 months to show continued interest? )

To be more clear, it violates this particular rule.

For what it's worth, accessing attributes with [] is not the same as using send. The latter will call the accessor method, which is what you want 99/100.

The decision to use a "keep it clean" design for the user interface sometimes takes it a step too far.

The props used for each slot inside the Tooltip. Note that componentsProps.popper prop values win over PopperProps and componentsProps.transition prop values win over TransitionProps if both are applied.

If you want to restore the old behavior (thus not reaching level AA), you can apply the following diff: -<Tooltip> +<Tooltip disableInteractive> # Interactive tooltips no longer need the `interactive` prop. -<Tooltip interactive> +<Tooltip>

In order to work with Safari, you need at least one display block or flex item below the tooltip wrapper.

A co-operative card game about assembling flat-pack furniture with your partner, and definitely not about your collapsing relationship.

make you more prepared for spontaneous things in life, like when you get asked a question in the middle of nowhere, your brain usually freezes up and can't think of an answer. This game captures that entirely.

trying to counter the antivaccine movement predicted that antivaxxers would publicize and weaponize reports of death and adverse events after COVID-19 vaccines to give the impression that the vaccines are dangerous

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

Its good to know how to implement it. I would prefer to use a gem myself.

Fixing with containIf we give each article the contain property with a value of content, when new elements are inserted the browser understands it only needs to recalculate the containing element's subtree, and not anything outside it:

I’m talking about the adults flocking to school board meetings to protect children from the manufactured crisis of “critical race theory.”

There is so much good stuff going on here.

What a time to be alive!

The complex typewriting effect is abstracted away in a neat function, out of site and out of mind.

this action is re-usable. Anytime you want a typewriter effect added to an element, you just import the function and apply it. So elegant.

All that is left is use:typeWriter. You instantly understand what it does and so will probably any future colleagues.

Some call them the lifecycle methods of elements which I think is an apt description.

Actions are deceptively simple yet incredibly powerful.

Yep, we experimented with this, but what we found is that you loose most of Svelte's niceness like slots, and instead you'll pass around deeply nested objects.

Now this is getting too complex for discussing this here and these type of architectural decisions require more in depth understanding than what I can provide here.

My UIs are data/store driven. The UI is just a way to visualize the data. Your data could flow through all of of the extensions and the extensions can make decisions (e.g. setting visible to false). Like middlewares in a Connect/Express/Polka app. And the UI doesn't even know about all this, it just updates with the current state and makes sure it's consistent.

(you can get pretty far with <svelte:component> and passing component constructors around and spicing up props along the way)

Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.

You sure packed lot of good lessons and important concept explanations/illustrations into this little answer/tutorial. Well done.

The consumer component will barely change from our last example. The only difference is the way we'll get a reference to our store (since now the store is exported from the JS module):

In effect, the $ syntax we've seen above will actually setup a subscription to the store. And the subscription will be cancelled when the component is destroyed. If the store is subscribed by multiple components, the store will be disposed only when the last component unsubscribes (it will be reinitialized, if a new subscription is made). This is very handy to manage the lifecycle of disposable things in your code.

<!-- you can use the $ prefixed value directly in the template --> <!-- (so we actually don't need the reactive expression above, in this example)

lifecycle is also managed automatically by Svelte

(And we've covered 75% of the store topic... They're efficient, to the point... And simple!)

Now your whole WS logic can be encapsulated in your JS module. That makes for good separation of concern.

In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:

In your Svelte component, you can then use your store with the special $ prefix syntax, to access the value of the store ('cause the temperature variable is a reference to the store itself, it's just a mean to our end, the result we need is the value):

// our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }

Here's how we would rewrite our callback example with a store instead:

Same as our callback example, except they offer a handful of other very useful tool (like computing derived values from other stores), and also a slick syntax in the Svelte component.

Stores are essentially some kind of simplified streams (or Observable as they're called in ES), that is they represent a value over time.

Stores are the idiomatic Svelte way when you need to import "reactivity" from your normal JS sources.

If you need to pass multiple arguments to an action, combine them into a single object, as in use:longpress={{duration, spiciness}}

Personally, I prefer an event-based communication, but I don't think it's actually better. The only problem with props is that it can cause problems if badly managed, but normally, both of them are ok. In real life, I would opt for storage.

Interim summary

Finally, I think Actions are great for animations, because you will definitely need to apply the same logic to many different elements. One of my favorite examples are FLIP animations, where a change in DOM position can be animated. For example shuffling a list of items. I will not dive deep into the topic in this article: I've written about some techniques in this article about FLIP animations in React and in this article about how to create spring animations with Web Animation API. Although they are not about Svelte, at the end of the day it all boils down to manipulating the HTML element directly. And Svelte Actions are a great place to do it.

We also need at least something in our CSS that can be set from outside. CSS custom properties are a great fit for this!

But you can get quite close to directly updating CSS with Actions!

export function autofocus(node) { node.focus(); } That's it. This is a legitimate Svelte Action!

To match against an ID or selectors that do not follow standard CSS syntax (by using a colon or space inappropriately, for example), you must escape the character with a backslash ("\"). As the backslash is also an escape character in JavaScript, if you are entering a literal string, you must escape it twice (once for the JavaScript string, and another time for querySelector()):

export interface TasksListSpecifics { 0: ('parallel' | 'sequential'); } export type TasksList = (string[] & TasksListSpecifics); Or more compact: export type TasksList = (string[] & { 0: ('parallel' | 'sequential'); }); The trick is to add your more specific properties on top of array of string type (Array<string>).

add ! to the end of the var that is being spread. E.g. [{}, ...payload!]

This also happens with an interface that fakes a tuple: interface Foo { 0: string; 1: number; 2?: boolean; // can't have an optional member in a real tuple }

Notice that in the else branch, we don’t need to do anything special - if x wasn’t a string[], then it must have been a string.

It might be confusing that a union of types appears to have the intersection of those types’ properties.

the name union comes from type theory. The union number | string is composed by taking the union of the values from each type. Notice that given two sets with corresponding facts about each set, only the intersection of those facts applies to the union of the sets themselves.

For example, if we had a room of tall people wearing hats, and another room of Spanish speakers wearing hats, after combining those rooms, the only thing we know about every person is that they must be wearing a hat.

Animal & { honey: boolean }

Extending a type via intersections

Type aliases and interfaces are very similar, and in many cases you can choose between them freely. Almost all features of an interface are available in type, the key distinction is that a type cannot be re-opened to add new properties vs an interface which is always extendable.

Inside each first-level directory of a MAFF archive, the second-level directory named ^metadata^ (case-sensitive) is reserved and should not contain actual content. A file or folder named ^metadata^ (case-insensitive) should not exist inside any first-level directory.

Support for reading and writing MAFF archives was provided in the Mozilla Application Suite, Firefox, and SeaMonkey thanks to the Mozilla Archive Format add-on from 2004 to 2018. While the original add-on is no longer maintained, the file format specification is still available and can be referenced by third-party software to provide better interoperability.

MAFF files are standard ZIP files containing one or more web pages, images, or other downloadable content. Additional metadata, like the original page address, is saved along with the content.

Unlike the related MHTML format, MAFF is compressed and particularly suited for large media files.

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.It requires a paid subscription (Pro, Team or Business), starting at $5 per user per month, for professional use in larger businesses. You may directly purchase here, or share this post and our solution brief with your manager.While the effective date of these terms is August 31, 2021, there is a grace period until January 31, 2022 for those that require a paid subscription to use Docker Desktop.

Thanks to the positive support we received on the subscription updates, we’ve started working on Docker Desktop for Linux which is the second-most popular feature request in our public roadmap.

I received an Appraisal Award letter for a claim to have my roof replaced for a total amount of $16000. The insurance paid the first half of 9100 for the Actual Cash Value and stated that the difference which is the depreciation amount was going to get paid after the work gets completed. It was completed and now the insurance is stating that because the amount on the roofers bill was less than the total awarded amount that they won't pay the rest. I can either have the roofer send an itemized final bill to show the depreciation cost in addition to the first bill that didn't show the breakdown or additional costs... OR I shouldn't have to go through this because the awarded amount is due regardless because the job was completed as requested. I need help to recover my depreciation amount owed.

America's Frontline Doctors - a group she founded last year to speak out against the government's efforts to contain the coronavirus.

As a solo dev I find this review totally unfair and rude! This game has been made by one person and hundreds of hours have gone into it... To say 5 hours max has been put into this project is just a ignorant negative response.

Modern browsers that support the File System Access API (Edge and Chrome today) allow web pages to access the local file system (with your permission).

Like a lot of people who buy a .dev domain, we had no idea what we were going to do with it. And we certainly didn't anticipate that it would end up being the fulfillment of a mission over a decade in the making.

con: doesn't let you define after_transaction callbacks anywhere like ar_after_transaction does (outside of the after_commit, etc. callbacks which only happen at certain points in the model's life cycle)

.. isn't just a shell shortcut; it's a very real entry in the file system for the parent of the directory it is contained in.

So it actually replaces the file, not update? If that file is hard-linked, the the other link is unaffected?

It's all too complex for our little brains to handle. And like any situation of excess complexity, we collapse dimensions until we have a structure we can comprehend. The problem, in this case, is that our simplifications create tunnels large enough for the trucks of hacker to drive through—with ease.

As many have observed, login is a broken system. Until we can be identified by factors that are unique to our personhood (biometrics, etc.) that we don't have to remember or store somewhere, these problems will persist. People have too many passwords for too many accounts.

What consumers are now storing in cloud services encompasses the whole of their digital lives.

If you're looking for a slightly higher level API built on the same technology, you may want to check out watir or capybara.

I don't see how making the attribute selectively present (and unlike anything else) achieves that goal.

Content in the wild can easily come to rely on this: var underAutomation = ("webdriver" in navigator) ? navigator.webdriver : false; v, without this behaviour: var underAutomation = navigator.webdriver;

to be always exposed with value true|false since there was no real benefit (privacy, implementation ease, performance, or otherwise) to making its existence conditional.

to be always exposed with value true|false since there was no real benefit (privacy, implementation ease, performance, or otherwise) to making its existence conditional.

With firefox 88 it won't work anymore, now navigator.webdriver is always true when maionette is enabled.

profile = webdriver.FirefoxProfile() profile.set_preference("dom.webdriver.enabled", False) profile.set_preference('useAutomationExtension', False) profile.update_preferences()

Honestly, I don't know. Strictly speaking it's different to a window being opened at a specific size (I can see the difference). I don't know whether that difference is material. Seeing as these are tests, I'd like to remove as many unknowns as possible. If someone can tell me that it makes no difference then I'd be happy.

Worst practices

Info for maintainers Triage this issue by using labels. If information is missing, add a helpful comment and then I-issue-template label. If the issue is a question, add the I-question label. If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label. After troubleshooting the issue, please add the R-awaiting answer label. Thank you!

But it is kind of verbose, and it’s also a lot slower, so I can understand why the model test might be preferred.

If and when you need some kind of behaviour that waits for things, wait_until is a giant big sledgehammer. There are more fine grained, sophisticated tools built into Capybara, and I want you to learn about them, because those are some of the best features of the library. And when the built in tools aren’t enough, there are more sophisticated tools available than that clunky hammer. So hopefully the removal of wait_until encourages you to write better tests.

I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.

Even if #foo is originally on the page and then removed and replaced with a #foo which contains baz after a short wait, Capybara will still figure this out.

The release of Capybara 2.0.0 removed the wait_until method from the API. This seems to have frustrated a few people,

so let me explain why this decision was reached and what your options are for the future.

wait_until was removed for several reasons:

As long as you stick to the Capybara API, and have a basic grasp of how its waiting behaviour works, you should never have to use wait_until explicitly.

Let’s make that really clear, Capybara is ridiculously good at waiting for content.

apybara could have easily figured out how to wait for this content, without you muddying up your specs with tons of explicit calls to wait_until. Our developer could simply have done this: page.find("#foo").should have_content("login failed")

Now after a long debugging session, our developer has found the timing issue. They now realize that there is a wait_until method in the API, and immediately think that, "hey, this sounds like what I need!"

Its existence confuses people into thinking that it is necessary, when in fact it isn’t.

TylerRick

I can't blame you. This problem seems anything but a newbie question! I was surprised when I noticed that this post (which was the only post I could find about trying to use chromedriver with flatpak chromium) in the linux4noobs forum. I've been using Linux as my primary desktop for ~15 years and this problem has stumped me too.

Actually, I ended up uninstalling Chrome and installing a chromium deb. Since no chromium deb exists in Ubuntu or Pop OS repositories anymore, I followed the instructions from https://askubuntu.com/questions/1204571/how-to-install-chromium-without-snap to add the Debian stable repo and install Chromium from there instead.