here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.

Software that is not currently being used gradually becomes unusable as the remainder of the application changes.

Infrequently used portions of code, such as document filters or interfaces designed to be used by other programs, may contain bugs that go unnoticed. With changes in user requirements and other external factors, this code may be executed later, thereby exposing the bugs and making the software appear less functional.

Microlibraries are easier to understand, develop and test. They make it easier for new people to get involved and contribute. They reduce the distinction between a “core module” and a “plugin”, and increase the pace of development in D3 features.

If you don't mind putting the sourcemap url in the minified JS

While I understand orgs wanting not to expose their unminified source, it's security through obscurity (meaning it's not adding any real security).

The only place I can find it is in the sprockets-rails gem. javascript_include_tag calls this: def find_debug_asset(path) if asset = find_asset(path, pipeline: :debug) raise_unless_precompiled_asset asset.logical_path.sub('.debug', '') asset end end

Les élèves accompagnés dans le cadre de ces dispositifs sont comptabilisés dans les effectifs scolarisés.

In production, you will never trigger one specific callback or a particular validation, only. Your application will run all code required to create a Song object, for instance. In Trailblazer, this means running the Song::Create operation, and testing that very operation with all its side-effects.

There’s no need to test controllers, models, service objects, etc. in isolation

Instead of one big code pile, activities will gently enforce a clean, standardized way for organizing code.

Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.

traditional tracking devices such as radio frequency identification (RFID) and bar codes remain relevant

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)

Non-blocking suggestion: This is a little more elegant, if you prefer this syntax:

Another thing I don’t like: our asset behavior is decoupled from the assets. If you’re mucking around in your app/assets folder, then you have to first know that such a config exists, and then hunt it down in a totally different config folder. It would be nice if, while we’re working in asset land, we didn’t have to mentally jump around.

While you could program this little piece of logic and flow yourself using a bunch of Ruby methods along with a considerable amount of ifs and elses, and maybe elsif, if you’re feeling fancy, a Trailblazer activity provides you a simple API for creating such flow without having to write and maintain any control code. It is an abstraction.

An activity is a high-level concept to structure code flow

Whether this is the life-cycle of a <user> entity or just a sign-up function, it has to be defined and coded somewhere.

Trailblazer strikes when it comes to organizing business code.

The DSL has a weaker control over the program’s flow — we can’t have conditions unless we add a special step

In functional programming, a monad is an abstraction that allows structuring programs generically

note that TRB source code modifications are not proprietary

Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.

Check yourself some shell-sources.

If interested, you can check the plain old /bin/sh signal handling in the source code here.

time run_with_timeout 3 sleep_and_exit 1 7; echo $?

it propagates (Option -p) the returnlevel ($?) so you may use it for your purpose.

ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.

Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.

I like the clarity of this approach instead of stuffing it in initialize.

Code of Ethics

I do think it's a common pattern that should be solved, and I am probably going to try and solve it as a Gem as opposed to simply writing code that we use in our code base

First of all, we want names to exhibit truth and beauty: to be the right names, and to make our code clean and beautiful. At least, this is what we want to think about our code, but naming’s importance is far more practical.

‘Programs are meant to be read by humans and only incidentally for computers to execute.’

2.L’article 40 du code de procédure pénaleL’article 40 du code de procédure pénale, déjà évoqué, dispose que «toute autorité constituée, tout officier public ou fonctionnaire qui, dans l’exercice de ses fonctions, acquiert la connaissance d’un crime ou d’un délit est tenu d’en donner avis sans délai au procureur de la République et de transmettre à ce magistrat tous les renseignements, procès-verbaux et actes qui y sont relatifs». Cet article a donc pour effet de délier du secret professionnel les officiers publics ou les fonctionnaires en leur imposant de dénoncer au procureur de la République les crimes ou délits dont ils ont acquis la connaissance dans l’exercice de leurs fonctions. Cetteobligation de dénonciation s’impose à tous les fonctionnaires et concerne toutes les infractions. Un médecin de PMI, un médecin scolaire ou un médecin hospitalier peut donc être concerné par cette obligation. Cependant, le non-respect de cette obligation de dénonciation n’est pas pénalement sanctionné, ce qui en limite considérablement la portée.

This is a store we can’t audit, which contains software nobody can patch. If we can’t fix or modify software, open-source or not, it provides the same limitations as proprietary software.

The code is far simpler and easier to understand/verify

’article 434-3 du code pénal prévoit que « toute personne ayant eu connaissance de privations, de mauvais traitements ou d’atteintes sexuelles infligés à un mineur de 15 ans s’expose à des sanctions pénales s’il n’en informe pas les autorités judiciaires ou administratives »

reviewing code takes energy!

the lighting is suitable

Maybe $$slots like $$props? My use case is that I'd like to wrap a slot's content in an element that applies styling that I'd like absent without the slotted content. Something like this: {#if $$slots.description} <div class="description"> <slot name="description"></slot> </div> {/if}

It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

Monaco is what VScode, and CodeSandBox, use for code editing. It's obviously one of the best code editors in the world. It's always been on my want-to-try-list and this is the perfect proejct.

A Svelte component that monitors an element enters or leaves the viewport/parent element. Performant and efficient thanks to using Intersection Observer under the hood. Can be used in multiple projects including lazy loading images, infinite scrolling, playing/pausing the video when in the viewport, tracking user behaviour firing link pre-fetching and animations and many many more.

It's a generic abstraction for the logic and styling of elements that pop out from the flow of the document and float next to a reference element, overlaid on top of the UI.

By abstracting the cleanup process in the cleanUp function, the three callbacks — timeout, success, and error listener — look exactly the same. The only difference is whether they resolve or reject the promise.

Keep your patches colocated with the code that depends on them.

Treating the web as a compile target has a lot of implications, many negative. For example “view source” is a beloved feature of the web that’s an important part of its history and especially useful for learning, but Svelte’s compiled output is much harder to follow than its source. Source maps, which Svelte uses to map its web language outputs back to its source language, have limitations.

For example, an event handler callback that can be used to handle both fullscreenchange and fullscreenerror might look like this:

// DO NOT INLINE this variable. For backward compatibility, foundations take a Partial<MDCFooAdapter>. // To ensure we don't accidentally omit any methods, we need a separate, strongly typed adapter variable.

in which business logic (JavaScript) is collocated with styles (CSS) and markup (HTML-like templating syntax).

Refactoring at scale is challenging and a significant investment, so communicating the progress is important both from a business perspective but also as a motivational effect to developers. In this case we used a combination of complexity trend visualizations and Code Health Metric as shown in the preceding example.

also, should RFCs include working code (basics for the IETF work)?

In my opinion, deleting a user is not a function executed by an item on itself but is a function done by the holder of the array. So in your case you would be better of moving the deleteUser up to App.

A resource route maps a number of related requests to actions in a single controller.

they're in the svelte compiler: https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Element.ts#L668 (search for the warning text)

Note that you can also use dynamic partials, that conditionally select the partial to render based on the value in the JSON.

When you’re implementing a bad plan yourself, instead of having a mentor bail you out by fixing it, a few really useful things happen:You learn many more details about why it was a bad idea. If someone else tells you your plan is bad, they’ll probably list the top two or three reasons. By actually following through, you’ll also get to learn reasons 4–1,217.You spend about 100x more time thinking about how you’ll avoid ever making that type of mistake again, i.e., digesting what you’ve learned and integrating it into your overall decision-making.By watching my mistakes and successes play out well or badly over the course of months, I was able to build much more detailed, precise models about what does and doesn’t matter for long-term codebase health. Eventually, that let me make architectural decisions with much more conviction.

Decode of jq command:

If you don't like to create an extra function and remove the items 'inline'

we update the validation schema on the fly (we had a similar case with a validation that needs to be included whenever some fetch operation was completed)

What would happen if we get the list from a rest api when the form component is mounted? That's an interesting topic, you can add a rule once a component has been mounted and update the associated validation schema.

Ok, I have seen that there are lot of built-in and third party validations, but sooner or later I will face a validation rule not covered by this buffet. Can I build a custom one? Of course you can!

exec(params) do load path end

This simplifies maintenance and keeps things clean by allowing related code to be grouped before inclusion elsewhere.

withindex.js, we have a single source of truth, giving fine grained control on what we expose to the outside world.

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.

The reason that this solves our problem is: we now have full control over the module loading order. Whatever the import order in internal.js is, will be our module loading order.

Here are few, real-life commits of refactorings that make use of this solution:

The crux of this pattern is to introduce an index.js and internal.js file.

Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.

Replaced nested `require` statements with `import` declarations for the sake of a leaner bundle. This entails adding empty imports to three files to guarantee correct ordering – see https://github.com/styled-components/styled-components/pull/100

In some cases, I could also create a component without any <script> tag at all. So in that way, I could actually bulk up the logic in one place if I could get some help from the #with block.

Separately, I wondered about having a central registry of warnings, since they're a bit scattered around at the moment. That way, we could check that someone wasn't trying to ignore a non-existent warning.

The false promise of your source code repository is that everything it contains is “good.” To complete your task, just find something that does something similar, copy, modify, and you’re done. Looking inside the same repository seems like a safety mechanism for quality but, in fact, there is no such guarantee.

What makes it good or bad is the quality of the code being multiplied.

For years, I’ve shared with friends and clients what I call the bunny theory of code. The theory is that code multiplies when you’re not looking, not unlike bunnies that tend to multiply when you’re not looking.

Anyone who’s ever worked with me knows that I place a very high value on what ends up checked-in to a source code repository.

nzaka's theory of bunny code is relevant here

Yes, you can embed loops in it and compose lots of small repeated JSX snippets, but that almost never happens in practice because mixing the turing complete of javascript with the markup of HTML eliminates the readability of JSX so that it is actually harder to parse than a solution like hyperscript (the syntactical approach taken by virtual-dom).

The problem is that not all tooling supports adding new dependencies from a transform. The first step is figuring out how this can be done idiomatically in the current ecosystem.

the actual upgrade path should be very simple for most people since the deprecated things are mostly edge cases and any common ones can be codemodded

Why not just use that instead of inventing a syntax that's not part of ECMAScript?

code is read much more often than it is written.

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable.

The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines.

For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters

Yes, you cannot fully express a modern app through templates without sacrificing flexibility and code reusability.

Source Code is a UX to interface with the raw machine.

I'm also persuaded by the arguments that it will be easier to track stuff down by co-location.

About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.

I also think this would be great in terms of colocation. If I need some intermediate result I no longer have to jump between script and markup.

I'm persuaded that co-locating just this one type of logic will be useful.

I like this, mostly because it allows me to write small components without creating another separate sub-component for holding the value simple computation. I get annoyed every time I need to create a component just to hold a variable, or even move the computation away from the relevant location. It reminds me of the days where variables in C had to be declared at the top of the function.

it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.

When I say that my experience is that it means it's time to split up your components, I guess I mean that there tends to be a logical grouping between all the things that care about (for example) sqr_n, and in Svelte, logical groupings are expressed as components.

Keep the local state isolated.Think about which state is local to a particular UI representation — and don’t hoist that state higher than necessary.