One such feature is parameterized tests. This feature enables us to execute a single test method multiple times with different parameters.

using RSpec::Parameterized::TableSyntax where(:a, :b, :answer) do 1 | 2 | 3 5 | 8 | 13 0 | 0 | 0 end

In Jest we are currently running all tests in JSDOM and not in a browser. This implies that certain scenarios cannot be tested or behave differently than in the real application.

Move it to Jest. This potentially requires extending our jsdom mocked browser environment. Move it to RSpec. This will probably require us changing our perspective to a use-case oriented one. We just want to make sure we have the same value coverage.

We should test for events emitted in response to an action in our component. This is used to verify the correct events are being fired with the correct arguments.

Do not test the internal implementation of the child components:

Test we react correctly to any events emitted from child components:

Test any directive that defines if/how child component is rendered (for example, v-if and v-for).

Adding Object Oriented Principles (OOP) to a functional codebase adds yet another way of writing code, reducing consistency and clarity.

A class adds a layer of abstraction, which makes the component API and its inner workings less clear.

Do add business logic to helpers or utilities, so you can test them separately from your component.

A rule of thumb is that data should just be data - it is not recommended to observe objects with their own stateful behavior.

Although each method of a Vue component can be tested individually, our goal is to test the output of the render function, which represents the state at all times.

When creating a new fixture, it often makes sense to take a look at the corresponding tests for the endpoint

You can find code to generate test fixtures

When mocking is deemed profitable:

Global mocks introduce magic and technically can reduce test coverage.

Manual mocks are used to mock modules across the entire Jest environment. This is a very powerful testing tool that helps simplify unit testing by mocking out modules which cannot be easily consumed in our test environment.

Jest provides useful matchers like toHaveLength or toBeUndefined to make your tests more readable and to produce more understandable error messages.

semantically target the element

targeting what the user actually sees

hen selecting by text it is best to use the byRole query as it helps enforce accessibility best practices.

The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible

Another common gotcha is that the specs end up verifying the mock is working. If you are using mocks, the mock should support the test, but not be the target of the test.

Don’t test the library

Testing the hasMetricTypes computed prop would seem like a given here. But to test if the computed property is returning the length of metricTypes, is testing the Vue library itself. There is no value in this, besides it adding to the test suite.

It’s better to test a component in the way the user interacts with it: checking the rendered template.

Running yarn jest-debug runs Jest in debug mode, allowing you to debug/inspect

Differences to Karma

Karma is a test runner which uses Jasmine as its test framework. Jest also uses Jasmine as foundation, that’s why it’s looking quite similar.

I love what this project has done, thank you for taking your time to make it happen.

If you don't need to support IE9 or lower, you can use flexbox freely, and don't need to use floated layouts.

Same feature in TypeScript¶ It's worth mentioning that other languages have a shortcut for assignment var assignment directly from constructor parameters. So it seems especially painful that Ruby, despite being so beautifully elegant and succinct in other areas, still has no such shortcut for this. One of those other languages (CoffeeScript) is dead now, but TypeScript remains very much alive and allows you to write this (REPL): class Foo { constructor(public a:number, public b:number, private c:number) { } } instead of this boilerplate: class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } (The public/private access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at compile time rather than at run time.) Further reading: https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-properties https://basarat.gitbook.io/typescript/future-javascript/classes#define-using-constructor https://kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/ I actually wouldn't mind being able to use public/private modifiers on instance var parameters in Ruby, too, but if we did, I would suggest making that be an additional optional shortcut (for defining accessor methods for those instance vars) that builds on top of the instance var assignment parameter syntax described here. (See more detailed proposal in #__.) Accessors are more of a secondary concern to me: we can already define accessors pretty succinctly with attr_accessor and friends. The bigger pain point that I'm much more interested in having a succinct shortcut for is instance var assignment in constructors. initialize(@a, @b, @c) syntax¶ jsc (Justin Collins) wrote in #note-12: jjyr (Jinyang Jiang) wrote: I am surprised this syntax has been repeatedly requested and rejected since 7 years ago. ... As someone who has been writing Ruby for over 10 years, this syntax is exactly that I would like. I grow really tired of writing def initialize(a, b, c) @a = a @b = b @c = c end This would be perfect: def initialize(@a, @b, @c) end I'm a little bit sad Matz is against this syntax, as it seems so natural to me. Me too!! I've been writing Ruby for over 15 years, and this syntax seems like the most obvious, simple, natural, clear, unsurprising, and Ruby-like. I believe it would be readily understood by any Rubyist without any explanation required. Even if you saw it for the first time, I can't think of any way you could miss or misinterpret its meaning: since @a is in the same position as a local variable a would normally be, it seems abundantly clear that instead of assigning to a local variable, we're just assigning to the variable @a instead and of course you can reference the @a variable in the constructor body, too, exactly the same as you could with a local variable a passed as an argument. A workaround pattern¶ In the meantime, I've taken to defining my constructor and list of public accessors (if any) like this: attr_reader \ :a, :b def new( a, b) @a, @b = a, b end ... which is still horrendously boilerplatey and ugly, and probably most of you will hate — but by lining up the duplicated symbols into a table of columns, I like that I can at least more easily see the ugly duplication and cross-check that I've spelled them all correctly and handled them all consistently. :shrug: Please??¶ Almost every time I write a new class in Ruby, I wish for this feature and wonder if we'll ever get it. Can we please?

I am not sure if this is an improvement. To me it does not seem very pretty. Of course I am biased since I also prefer () in method definitions if they have arguments; although I think it is fine that ruby does not mind omitting the (). For my brain, I like the () for visual separation.

For attributes, methods and constructors, you can use the one of the following:

Introduce behaviour that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.

Emit clean, idiomatic, recognizable JavaScript code.

The encapsulation is enforced by the language. It is a syntax error to refer to # names from out of scope.

When defining accessors in Ruby, there can be a tension between brevity (which we all love) and best practice.

I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.

a principle I use is: If you have an accessor, use the accessor rather than the raw variable or mechanism it's hiding. The raw variable is the implementation, the accessor is the interface. Should I ignore the interface because I'm internal to the instance? I wouldn't if it was an attr_accessor.

I have been wrapping instance variables in accessor methods whenever I can though.

Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.

Yeah, "virtual attribute" seems like dated terminology to me, so conceptually just a method.

I see a 'virtual attribute' as something we're forced to implement when using frameworks, ORMs and the like. Something that lets us inject our code into the path of whatever metaprogramming has been put in place for us. In a simple PORO like this, I don't see how it has meaning; it's just a method. :)

If you're just throwing the toppings away, your class is less of a Pancake and more of a PancakeToppingDetector ;)

has_sauce is a "virtual attribute", a characteristic of the model that's dependent on the underlying toppings attribute.

But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.

in languages (like JavaScript and Java) where external objects do have direct access to instance vars

Which gets the job done, but that's a chunk of boilerplate for a simple accessor

But suddenly I'm using a raw instance variable, which makes me twitch. I mean, if I needed to process has_sauce before setting at a future date, I'd potentially need to do a lot more refactoring than just overriding the accessor.

I'm liking your use of private though - a fair compromise between ugly code and updating the Object class.

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.

One of the consequences (although arguably not the primary motivation) of DRY is that you tend to end up with chunks of complex code expressed once, with simpler code referencing it throughout the codebase. I can't speak for anyone else, but I consider it a win if I can reduce repetition and tuck it away in some framework or initialisation code. Having a single accessor definition for a commonly used accessor makes me happy - and the new Object class code can be tested to hell and back. The upshot is more beautiful, readable code.

class << Object def private_accessor(*names) names.each do |name| attr_accessor name private "#{name}=" end end end

(I think you need a better name than private_accessor though)

Setting an instance variable by going through a setter is good practice, and using two access modifiers is the way to accomplish that for a read-only instance variable

Note that this proposal provides private fields and methods only as declared up-front in a field declaration; private fields cannot be created later, ad-hoc, through assigning to them, the way that normal properties can. You also can't declare private fields or methods in object literals; for example, if you implement your class based on object literals, or adding individual methods to the prototype, or using a class framework, you cannot use private methods, fields or accessors.

Activity welcome in this repository

Ask questions about the proposal, how the syntax works, what the semantics mean, etc.

Note: there’s no way to define private methods, getters and setters. but a proposal is there https://github.com/tc39/proposal-private-methods

Having a member in a class and initializing it like below:class Foo { x: number; constructor(x:number) { this.x = x; }}is such a common pattern that TypeScript provides a shorthand where you can prefix the member with an access modifier and it is automatically declared on the class and copied from the constructor. So the previous example can be re-written as (notice public x:number):class Foo { constructor(public x:number) { }}

If an access modifier is not specified it is implicitly public as that matches the convenient nature of JavaScript 🌹.

Private instance accessors (getters and setters)

class Person { #firstname = "Babel"; #lastname = "JS"; get #name() { return this.#firstname + " " + this.#lastname; } sayHi() { alert(`Hi, ${this.#name}!`); } }

we now support let x: typeof import('./x');, added in TypeScript 2.9

Babel implements multiple variants of this proposal to help TC39 test and gather feedback from the community. As with all proposals, expect changes in the future.

The answer is no, we use a pattern where we do this, and have a `static` method for manufacturing the constructor.e.g.static from({prop1, prop2}) => new this(public prop1, public prop2)

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

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

Then, people from programming communities (mainly front-end) realized that CoffeeScript is out of date and is starting to lag behind the ever-evolving Javascript environment. As of today, January 2020, CoffeeScript is completely dead on the market (though the GitHub repository is still kind of alive).

It was the first to present the concept of creating a function without a superfluous keyword function, replacing it with something that in 2015 was to become the function arrow (=> in ES6, -> in CoffeeScript). He also got rid of the curly braces (like Python), replacing them with indentations. Often in CoffeeScript, you can omit (once required) parentheses, that often unnecessarily decrement the readability of the code.

I don't think this warrants adding to the Array class, since it's not generalizable to all the types that Arrays can contain.

That's not exactly Symbol#to_proc conversion — it's part of the inject interface, mentioned in the documentation. The to_proc operator is &

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

Programmers should be encouraged to understand what is correct, why it is correct, and then propagate.

I don't think it is too clever. I think it solves the problem idiomatically. I.e., it uses reduce, which is exactly correct. Programmers should be encouraged to understand what is correct, why it is correct, and then propagate. For a trivial operation like average, true, one doesn't need to be "clever". But by understanding what "reduce" is for a trivial case, one can then start applying it to much more complex problems. upvote.

Thanks, this was just what I was looking for! This is a perfect appropriate use of instance_eval. I do not understand the nay-sayers. If you already have your array in a variable, then sure, a.reduce(:+) / a.size.to_f is pretty reasonable. But if you want to "in line" find the mean of an array literal or an array that is returned from a function/expression — without duplicating the entire expression ([0,4,8].reduce(:+) / [0,4,8].length.to_f, for example, is abhorrent) or being required to assign to a local, then instance_eval option is a beautiful, elegant, idiomatic solution!!

instance_eval is analogous to using tap, yield_self, … when you are dealing with a chain of method calls: do use it whenever it's appropriate and helpful! And in this case, I absolutely believe that it is.

instance_eval lets you run the code while only specifying a once, so it can be chained with other commands. I.e. random_average = Array.new(10) { rand(10) }.instance_eval { reduce(:+) / size.to_f } instead of random = Array.new(10) { rand(10) }; random_average = random.reduce(:+) / random.size

I don't know, using instance_eval this way just seems weird, and it has a lot of gotchas associated with it that make this approach a bad idea, IMO. (For example, if you tried to access and instance variable or a method on self inside that block, you'd run into problems.) instance_eval is more for metaprogramming or DSL.

I agree, don't use this in your application code.

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.

Wooow! Have you passed this level with or without tools?

graphics are not really important in the grand scheme of things, even less so in puzzlers, but the diorama-like presentation of forests and cute animals immediately won me over, and I found small things like moving animals in the backround hours into the game. gotta admire the attention to detail.

add some quality of life stuff like volume sliders, windowed mode, unlimited undo, etc.

when it first came out, cubicity: slide puzzle was full of mobile shenanigans, but based on feedback the developers quickly 'de-mobilized' it during launch week

all are basically standard SQL, but no RDBMS supports the standard completely.

I suggest to make it UNIQUE because it seems like the column should be unique

A LATERAL item can appear at top level in the FROM list, or within a JOIN tree. In the latter case it can also refer to any items that are on the left-hand side of a JOIN that it is on the right-hand side of.

SELECT base.nr, multiples.multiple FROM (SELECT generate_series(1,10) AS nr) base, LATERAL ( SELECT multiples.multiple FROM ( SELECT generate_series(1,10) AS b_nr, base.nr * 2 AS multiple ) multiples WHERE multiples.b_nr = base.nr ) multiples;

SELECT s.id, s1.percent_water , s1.percent_water * 100 AS percent_water_100 FROM samples s , LATERAL (SELECT s.wet_weight / NULLIF(s.dry_weight - 1, 0) AS percent_water) s1;

I added NULLIF() to defend against division-by-zero errors.

This answer is pretty old but today SPA works most of the time on static server-less env, so doing this with Javascript is more than legit.

ISO 639-3 extends the ISO 639-2 alpha-3 codes with an aim to cover all known natural languages.

The terms autonym and xenonym also had different applications,[3] thus leaving endonym and exonym as the preferred forms.

語 is the suffix which means 'language'. Unlike English which needs two different nouns for a country and its language, in Japanese, you can simply add 語 after the name of a country to mean the language spoken in that country. (e.g. ドイツ = Germany, ドイツ語 = German, フランス = France, フランス語 = French)

(This term, にほんご, is an alternative spelling of the above term.)

The US Library of Congress has been designated the official registration authority by the ISO and they publish the entire, official, up-to-date list as a trivial to parse text file for free.

Through a linkpin called "Property Value Alias", Unicode has made a 1:1 connection between a script defined, and its ISO 15924 standard.

The following standards are referred to as indispensable by ISO 15924.

Critical to the acceptance of the position of the script subtag was the inclusion of information in the registry to make clear the need to avoid script subtags except where they add useful distinguishing information. Thus, the registry entry for the language subtag "en" (English) has a field called "Suppress-Script" indicating that the script subtag "Latn" should be avoided with that language, since virtually all English documents use the Latin script.

Another problem was the ambiguity of RFC 3066 regarding the generative syntax. The idea of "language-dash-region" language tags was easy enough to grasp; most users didn't read RFC 3066 directly or consider the unstated-but-realized implication that other subtags might sometimes occur in the second position.

Language Range ... matches ... does not match de de, de-CH, de-AT, de-DE, de-1901, de-AT-1901 en, fr-CH

Because ISO code lists were not always free and because they change over time, a key idea was to create a permanent, stable registry for all of the subtags valid in a language tag.

excepting a few grandfathered registrations, all tags are now generative

grandfathered = tags listed in the old registry that are not otherwise redundant (a closed list)

This article is only of historical interest, since the proposed new approach it refers to was published as RFC 4646 and RFC 4647 (collectively known as BCP 47) in September 2006, and have since been revised. The article is now out of date.

BCP stands for Best Current Practice

I'm not sure why MSFT decided to change these codes in the first place. While it might have been a noble goal to follow the IETF standard (though I'm not really familiar with this), the old codes were already out there, and most developers don't benefit by the new codes, nor care about what these codes are called (a code is a code). Just the opposite occurs in fact, since now everyone including MSFT itself has to deal with two codes that represent the same language (and the resulting problems). My own program needs to be fixed to handle this (after a customer contacted me with an issue), others have cited problems on the web (and far more probably haven't publicised theirs), and MSFT itself had to deal with this in their own code. This includes adding both codes to .NET even though they're actually the same language (in 4.0 they distinguished between the two by adding the name "legacy" to the full language name of the older codes), adding special documentation to highlight this situation in MSDN, making "zh-Hans" the parent culture of "zh-CHS" (not sure if it was always this way but it's a highly questionable relationship), and even adding special automated code to newly created "add-in" projects in Visual Studio 2008 (only to later remove this code in Visual Studio 2010, without explanation and therefore causing confusion for developers - long story). In any case, this is not your doing of course, but I don't see how anyone benefits from this change in practice. Only those developers who really care about following the IETF standard would be impacted, and that number is likely very low. For all others, the new codes are just an expensive headache. Again, not blaming you of cours

I feel the pain. It is a normal thing that standards do evolve over time, though, and our software needs to cope with it.

I'm not sure why MSFT decided to change these codes in the first place. While it might have been a noble goal to follow the IETF standard (though I'm not really familiar with this), the old codes were already out there, and most developers don't benefit by the new codes, nor care about what these codes are called (a code is a code).

HAVING avg(score) < 0.75 * (SELECT avg(score) FROM performance_reviews)

When you are dealing with an aggregate of aggregates, it needs to be accomplished in two steps. This can be done using a subquery as the FROM clause, essentially giving us a temporary table to then select from, allowing us to find the average of those averages.

Is there a way to select from multiple custom tables using ActiveRecord QueryMethods? I'm trying to replicate this SQL query using Ruby's ActiveRecord Query Methods. select employee.emplid, address.location from (....) employee, (....) address where employee.emplid = address.emplid

over (order by effdt desc) prev

You can use jsonb_agg and jsonb_array_elements_text to flatten or unnest an array of arrays in PostgreSQL: SELECT jsonb_array_elements_text(jsonb_agg(array_of_arrays)) FROM x;

jsonb_pretty

That's going to be extremely ugly. Nothing about this makes sense. Your JSON schema should just have one object that has {"is_enabled":true}, or something like this {"name":"change","is_enable":true}.

ActiveRecord::Relation::QueryAttribute.new(nil, value, ActiveRecord::Type::Value.new)

DISTINCT ON (1)

SELECT DISTINCT ON (1) t.id, t.name, d.last FROM tbl t LEFT JOIN LATERAL json_array_elements_text(data) WITH ORDINALITY d(last, rn) ON d.last <> t.name ORDER BY d.rn DESC;

There is a (hack-ish, i know, but) more reliable way to do the "cast" in 9.3: ('[' || d::text || ']')::json ->> 0

Unnest in a LEFT JOIN LATERAL (clean and standard-conforming)

unnest ( anyarray ) → setof anyelement Expands an array into a set of rows. The array's elements are read out in storage order.

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

And this has some immediate benefits: more efficiency, significantly faster to process, supports indexing (which can be a significant advantage, as we'll see later), simpler schema designs (replacing entity-attribute-value (EAV) tables with jsonb columns, which can be queried, indexed and joined, allowing for performance improvements up until 1000X!)

Besides efficiency, there are extra ways in which you can benefit from storing JSON in binary form. One such enhancement is the GIN (Generalized Inverted Index) indexes and a new brand of operators that come with them.

SELECT jsonb_array_elements_text(data->'genres') AS genre FROM books WHERE book_id = 1; That will expand the JSON array into a column:

This is an important one, as it will enable us to use the aggregate functions that we are familiar when dealing with relational databases, but in the otherwise counter-intuitive environment of JSON data.

As stated in the title, I am in a situation where I need to return a count of occurrences within an array, that is within a jsonb column.

jsonb_each_text

To find the problematic rows you can use a query like SELECT id FROM t WHERE jsonb_typeof(data_col) <> 'object';

Your attempt should work. There is a mismatch in column name in your query though. The query uses col2 but the table is defined with col1.

select t.* from my_table t, jsonb_each(my_col) as value1(key1, value1), jsonb_each(value1) as value2(key2, value2) where jsonb_typeof(my_col) = 'object' and jsonb_typeof(value1) = 'object' and value2->>'Param3' = '6';

This means that you have a json structure different from that described in your question. You cannot use generic jsonb functions when the json structures differ in each row.

json_array_elements_text ( json ) → setof text jsonb_array_elements_text ( jsonb ) → setof text Expands the top-level JSON array into a set of text values. select * from json_array_elements_text('["foo", "bar"]') → value ----------- foo bar

Writing json_populate_record in the FROM clause is good practice, since all of the extracted columns are available for use without duplicate function calls.

Use the -> operator instead of ->> in the reference to children. The way you have it, you'd first cast json / jsonb to text and then back to json.

The clean way to call a set-returning function is LEFT [OUTER] JOIN LATERAL. This includes rows without children. To exclude those, change to a [INNER] JOIN LATERAL

FROM test x1 LEFT JOIN test x2 ON x1.id = (x2.data->>'parent')::INT;

JOIN LATERAL

a leap of faith?

The age_in_years is calculated for every record of the blog table. So, it works like a correlated subquery, but the subquery records are joined with the primary table and, for this reason, we can reference the columns produced by the subquery.

Mitch Hedberg - "I play the guitar. I taught myself how to play the guitar, which was a bad decision... because I didn't know how to play it, so I was a shitty teacher. I would never have went to me."

You can watch videos, but videos can't watch you.

No article or video can replace qualified instruction and experience

jsonb_array_elements('{"test": ["a1", ["b1", "b2"]]}'::jsonb->'test') as json

jsonb_typeof(json)

For a «zoom out» view of my current data, here is a table-free working test :

Careful, Instead of != you may need to IS DISTINCT FROM operator which also compares NULL value

INSERT INTO accounts (id, token, affiliate_code) VALUES (value1, value2, value3) ON CONFLICT (id) DO UPDATE SET token = value2,

import { knex } from 'knex' // this is a function that you call to instantiate knex import { Knex } from 'knex' // this is a namespace, and a type of a knex object

TypeScript type exports changed significantly. While `import Knex from 'knex';` used to import the knex instantiation function, the namespace and the interface for the knex instantiation function/object, there is now a clear distinction between them:

You can use the pg_typeof() function, which also works well for arbitrary values. SELECT pg_typeof("stu_id"), pg_typeof(100)

@7alhashmi: Yes, e.g. the 100 comes from the feature_values table

SELECT * FROM departments AS d, LATERAL (SELECT * FROM employees AS e WHERE e.department_ID = d.department_ID)

In a FROM clause, the LATERAL keyword allows an inline view to reference columns from a table expression that precedes that inline view.