Normally you should not register a named module, but instead register as an anonymous module: define(function () {}); This allows users of your code to rename your library to a name suitable for their project layout. It also allows them to map your module to a dependency name that is used by other libraries.

The non-minified default bundle is no longer mangled, making it more readable and preserving inline comments.

D3 now passes events directly to listeners, replacing the d3.event global and bringing D3 inline with vanilla JavaScript and most other frameworks.

This thread is more than 5 months old. It is very likely that it does not need any further discussion and thus bumping it serves no purpose. If you feel it is necessary to make a new reply, you can still do so though. I am aware that this thread is rather old but I still want to make a reply.

I don't understand why this isn't being considered a bigger deal by maintainrs/the community. Don't most Rails developers use SCSS? It's included by default in a new Rails app. Along with sprockets 4. I am mystified how anyone is managing to debug CSS in Rails at all these days, that this issue is being ignored makes sprockets seem like abandonware to me, or makes me wonder if nobody else is using sprockets 4, or what!

I don't even know how to tell if they're working 100%, I'm getting mixed signals ..

Should it only contain link* calls?

When should I use link, vs dir, vs. tree?

but I still have no idea if I'm writing this new file correctly.

For the $$$ question, nothing comes to mind. These problems i'm hitting up against are larger than a contractor could solve in a few hours of work (which would be hundreds/thousands of dollars).

we used `backticks` to jump into native Javascript to use moment.js

The HTML5 form validation techniques in this post only work on the front end. Someone could turn off JavaScript and still submit jank data to a form with the tightest JS form validation.To be clear, you should still do validation on the server.

Therefore client side validation should always be treated as a progressive enhancement to the user experience; all forms should be usable even if client side validation is not present.

It's important to remember that even with these new APIs client side validation does not remove the need for server side validation. Malicious users can easily workaround any client side constraints, and, HTTP requests don't have to originate from a browser.

Since you have to have server side validation anyways, if you simply have your server side code return reasonable error messages and display them to the end user you have a built in fallback for browsers that don't support any form of client side validation.

You really don't need underscore/lodash for this ... nowadays anyways

I went by the reviews and now i am seeing a pattern on STEAM where even good reviews are bought and paid for and not really player revews and that actuallly watching game play from google will be my best option in the future. AGAIN don;t trust bought and paid for reviews from STEAM....I just learned and realised this now

Keep in mind that third party code with references to other files also processed by the asset Pipeline (images, stylesheets, etc.), will need to be rewritten to use helpers like asset_path.

In both filters, you’re able to rename and coerce variables. This gives you a bit more control than the simpler DSL.

Not all cases can be covered and easily restored. And sometimes when we will reuse this function for different use-cases we will find out that it requires different restore logic.

But why do we return 0? Why not 1? Why not None? And while None in most cases is as bad (or even worse) than the exceptions, turns out we should heavily rely on business logic and use-cases of this function.

So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context. There’s no silver bullet to resolve all ZeroDivisionErrors once and for all. And again, I am not even covering complex IO flows with retry policies and expotential timeouts.

However, you don’t need to have an extensive knowledge of monads to use ROP in your code.

Though rarer in computer science, one can use category theory directly, which defines a monad as a functor with two additional natural transformations. So to begin, a structure requires a higher-order function (or "functional") named map to qualify as a functor:

It's hard to say why people think so because you certainly don't need to know category theory for using them, just like you don't need it for, say, using functions.

This stuff is intoxicating once you get into it.

note that TRB source code modifications are not proprietary

I'm sure there will be a few other people out there who eventually want something like this, since Interactions are actually a great fit for enforcing consistency in data structures when working with a schemaless NoSQL store, but obviously it's still a bit of a niche audience.

Rather than implement features you might need, you implement only the features you definitely need, but in a way that accommodates change. If you don't have this flexibility, parallel development simply isn't possible.

I'd like to know specifically what you were aiming to achieve with this Gem as opposed to simply using https://github.com/apotonick/reform? I am happy to help contribute, but equally if there is a gem out there that already does the job well, I'd like to know why we shouldn't just use that.

The reason Reform does updating attributes and validation in the same step is because I wanna reduce public methods. This is to save users from having to remember state.

I will continue to use form objects and push changes into the repo when I feel they are universally relevant and valuable.

Writing the uniqueness validations yourself is easy so I felt it was better to leave this up to the developer

There's no such a thing, more like beautiful interface trying to hide that there's no actual gameplay.

The filthy casuals write positive reviews on steam and it's clear that true gamers won't even try to review such a shallow game.

Space: Suppose we had infinite memory, then cache all the data; but we don't so we have to decide what to cache that is meaningful to have the cache implemented (is a ??K cache size enough for your use case? Should you add more?) - It's the balance with the resources available.

Time: Suppose all your data was immutable, then cache all the data indefinitely. But this isn't always to case so you have to figure out what works for the given scenario (A person's mailing address doesn't change often, but their GPS position does).

So the hard and unsolvable problem becomes: how up-to-date do you really need to be?

After considering the value we place, and the tradeoffs we make, when it comes to knowing anything of significance, I think it becomes much easier to understand why cache invalidation is one of the hard problems in computer science

The syntax itself provides a visualization of the structure of the grid.

Please don't thank me! ;-) If this answer did help, just click the little grey ☑ at the left of this text right now turning it into beautiful green. If you do not like the answer, click on the little grey down-arrow below the number, and if you really like the answer, click on the little grey ☑ and the little up-arrow... If you have any further questions, just ask another one! ;-)

We believe good tools lead to excellent creations.

There is a dimension of personal preference to it. I don't like to expose more than strictly necessary to external consumers, because it makes it harder to track usages. If you find a bind:prop in a consumer, you know prop is used (which you already kind of knew since the prop is part of the "public" API of the component). Done. If you find a bind:this, you now need to track all usages of this this.

We usually only see people launching projects once they're already done. I'm sure there are countless more unfinished and unlaunched side projects that the world will never know about. Don't let your side project become one of them.

They say that perfect is the enemy of good, and I'm coming to realise that something like a video course can never be perfect anyway. I can only do my best with the time and energy I have available. I'd rather finish this course and share my experience and insights on using Svelte with the world, than to plan it forever and never launch.

In fact, even <svelte:slot /> feels a bit confusing because it introduces a new kind of slot, where the concept is already a bit crowded (there the <slot /> in the parent component, and the target slot="name" for the slot content).

Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management. Others like Angular and Vue provide a more all-in-one solution with official routers, opinionated state management, CLIs, and more. Sapper is Svelte’s official app framework that adds routing, server-side rendering, code splitting, and some other essential app features, but it has no opinions about state management and beyond. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

With the caveat that hero worship can be gross, distorting, and unhelpful to everyone involved, Svelte author Rich Harris (@rich_harris on Twitter) is one of my favorite open source developers. In the JS community he’s well-known among tool authors for spreading interesting ideas. He’s the creator of many open source projects including Rollup, the bundler of choice for many libraries including React and Vue.

Svelte is its own language, not plain HTML+CSS+JS

The compiler architecture moves complexity from the runtime and source code to buildtime and tools. Behind Svelte’s simple APIs sits a beefy compiler. Frontend web development has become very tool heavy in the webapp era, so in practice this adds little cost beyond what developers like myself already pay, but increased build complexity is important to acknowledge.

There's a huge area of seemingly obvious user-centric products that don't exist simply because there isn't a working business model to support it.

I also find that a lot of the complexity of Flutter can be avoided, and I mostly use it to define the UI as a more app-centric alternative to HTML/CSS.

(15x) ENJOYMENT: Forgettable Outstanding(10x) DEPTH (IN RELATION TO COMPLEXITY): Lacking Meaty (5x) LUCK FACTOR: All Luck All Skill (3x) REPLAYABILITY: Nil Limitless(10x) MECHANICS: Boring Interesting (4x) PLAYER INTERACTION: Low High (4x) PLAYER COUNT PERFORMANCE: Not Balanced Balanced (2x) GAME LENGTH: Too Short/Long Just Right (2x) CLARITY OF RULES: Mud Crystal (5x) COMPONENT QUALITY: Cheap World ClassINITIAL RATING (sum(Criteria Rating x Criteria Weight)/Total Weight) = 7.7

If everyone did this, the repair shops would be out of business.

It is important to notice that if you are planning on making your application a PWA, you don’t have to rewrite all the logic.

If the document is uncontroversial and agreement is reached quickly it might be committed directly with the "accepted" status. Likewise, if the proposal is rejected the status shall be "rejected". When a document is rejected a member of the core team should append a section describing the reasons for rejection.

Did you look at it and decide not, or not look at it?

This isn't written to hype a battle in the holy war.

It looks like you just deleted our lovely crafted issue template. It was there for good reasons. Please help us solving your issue by answering the questions asked in this template. I'm closing this. Please either update the issue with the template and reopen, or open a new issue.

In principle, this information is already available through other means, but it is actually a fair amount of work to gather it in this form, and I think it could be useful to open it up to programmatic consumption.

http://jonudell.info/h/tag-rename-02.mp4

I came up with this solution by piecing together man pages and random google result. I was surprised at how many incomplete and inaccurate answers were out there. What may have been more surprising was the complete lack of a full intact solution.

We could broadcast a warning if we find the variable to be set in the environment, but that is more likely than not to annoy people who intentionally set it.

It took a lot of searching around to find that variable.

If you have a better/simpler/"more official" solution, I'd still love to see it!

Focus on your application: forget about forms details like I'm dirty, field touched...

You can try to build a solution to tackle these issues on your own, but it will cost you time and money... why not use a battle-tested solution to handle all this complexity?

If you want to implement a form with a superb User Experience, you have to take care of many variables:

Form validation can get complex (synchronous validations, asynchronous validations, record validations, field validations, internationalization, schemas definitions...). To cope with these challenges we will leverage this into Fonk and Fonk Final Form adaptor for a React Final Form seamless integration.

Managing Form State (holding field information, check if a control has been touched, if the user has clicked the submit button, who owns the current focus...) can be tedious and prone to errors. We can get help from React Final Form to handle these challenges for us.

But it sounds like the library could use some way to setTouched()

Paths are traversed in the order they occur in the search path. By default, this means the files in app/assets take precedence, and will mask corresponding paths in lib and vendor.

Replace the card, reinstall Sophos and restart the system.

Hardware connectivity in Separate Kitting

Installing the Wi-Fi Communication Terminal MK-755 (optional)

Doing so also means adding empty import statements to guarantee correct order of evaluation of modules (in ES modules, evaluation order is determined statically by the order of import declarations, whereas in CommonJS – and environments that simulate CommonJS by shipping a module loader, i.e. Browserify and Webpack – evaluation order is determined at runtime by the order in which require statements are encountered).

Don’t fetch stuff unless you actually need it Judging from the response to our 503 errors, much of the software requesting DTDs and schemata from our site doesn’t even need them in the first place, so requesting them just wastes bandwidth and slows down the application. If you don’t need it, don’t fetch it!

Informative data about objects that are considered prototypes for the role. Base concept is similar to type, but without inheritance of limitations and properties. Base concepts are designed as a substitute for inheritance for external concepts. A base concept is like a related concept except that the base concept is almost identical to the role definition.

Wondering how to get field state from multiple fields at once? People coming from Redux-Form might be wondering where the equivalent of Redux Form's Fields component is, as a way to get state from several fields at once. The answer is that it's not included in the library because it's so easy to write one recursively composing Field components together.

It is important to note here that the flow does not need to begin with a user interaction. With the rise of asynchronous middleware like redux-saga and redux-observable, the ability to trigger any code on a component anywhere is very useful.

The primary motivation behind virtual-dom is to allow us to write code independent of previous state. So when our application state changes we will generate a new VTree. The diff function creates a set of DOM patches that, based on the difference between the previous VTree and the current VTree, will update the previous DOM tree to match the new VTree.

However, in function components there really isn't much need for this pattern since you can just use JS default arguments

This proposal simplifies how React.createElement works and ultimately lets us remove the need for forwardRef.

This is valid javascript! Or harmony or es6 or whatever, but importantly, it's not happening outside the js environment. This also allows us to use our standard tooling: the traceur compiler knows how to turn jsx`<div>Hello</div>`; into the equivalent browser compatible es3, and hence we can use anything the traceur compile accepts!

If you're targeting these platforms, there's no need to use a transpiler!

But the vast majority of things that our apps are doing are just conditional and list rendering.

Every new variation to the view requires updating both the view model and the template. This holds true even for simple variations.

It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.

Disclaimer: I’m new to Svelte so this isn’t so much a recommendation as it is a “I guess this is a way to do it 🤷‍♂️”

People constantly suggest that I should have just worked with a different library instead of writing another one.

helped me carve a niche for what would become SolidJS. I still see that space today, so I'm glad that I did.

Do we need another JS UI Library?

Are there any rehearsal or set up dates on campus? Yes No Please enter any rehearsal or set up dates here

There are work arounds, but nothing clean. I just feel like this should be functionality that should be part of the slot feature.

Lets not extend the framework with yet another syntax

I'm just pushing on the "is this really a good idea" front

You must: reference each element you are extending using refs or an id add code in your oncreate and ondestroy for each element you are extending, which could become quite a lot if you have a lot of elements needing extension (anchors, form inputs, etc.)

The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)

I really have no idea how you came up with this solution but that reflects a major problem with many npm packages, i.e. 90 percent of the library documentation should be pulled from the Git issues or SO answers.

The hype is something common in our industry. Remember NoSQL? Or when everyone went crazy over microservices? Or the AI / Machine learning burst? The list goes on and on. People get excited about new and breakthrough technologies and ideas.

The idea of having to learn something new is good, and I agree with that, but how often should you do that? Looking at the world of JavaScript, a new idea, blog post, library, framework, and whatnot pops up very often. Things become trending, and people quickly try to adopt that. I’m not saying you should not adopt new things and consider different approaches to a solution, not at all! I am trying to propose the idea of doing that less often.

"AOO is not, and isn't designed to be, the 'super coolest open source office suite with all the latest bells and whistles,'" Jagielski continued. "Our research shows that a 'basic,' functional office suite, which is streamlined with a 'simple' and uncluttered, uncomplicated UI, serves an incredible under-represented community.

If you're having to look at GitHub, it seems like you didn't find a situation yourself where the requested feature would make you happier. I would advice you not to attempt to find use cases beforehand, just let them find you.

Matz, alas, I cannot offer one. You see, Ruby--coding generally--is just a hobby for me. I spend a fair bit of time answering Ruby questions on SO and would have reached for this method on many occasions had it been available. Perhaps readers with development experience (everybody but me?) could reflect on whether this method would have been useful in projects they've worked on.

I'll freely admit I was surprised by this behavior myself since I needed to obtain an Array with only one instance of each item in the argument array removed.

As an engineer, it’s important to explore different technologies. It’s important to identify the tools available to tackle problems. And it’s important to expand your horizons because then you can look cool on your CV.

If anyone else wonders How to just get data type of a varible (not column) you can use the pg_typeof(any) function.

I have used this bash one-liner before set -- "${@:1:$(($#-1))}" It sets the argument list to the current argument list, less the last argument.