@adisos if reform-rails will not match, I suggest to use: https://github.com/orgsync/active_interaction I've switched to it after reform-rails as it was not fully detached from the activerecord, code is a bit hacky and complex to modify, and in overall reform not so flexible as active_interaction. It has multiple params as well: https://github.com/orgsync/active_interaction/blob/master/spec/active_interaction/modules/input_processor_spec.rb#L41

We could quite easily create a model class that isn’t based on ActiveRecord and have it work as Rails is quite decoupled from ActiveRecord, but there are advantages to keeping our model class inheriting from ActiveRecord.

Take 3, Previously attempted in 2012 (#8189) and 2015 (#19709). This new version uses ActiveModel Attributes API.

Another recent attempt: #35246

By the same token, marketing or political incentives often push design idioms

Programming to interfaces is at the core of flexible structure.

The more important point comes from a program design perspective. Here, "programming to an interface" means focusing your design on what the code is doing, not how it does it. This is a vital distinction that pushes your design towards correctness and flexibility.

The problem with this is that it creates a strong coupling between your code and the implementation, exactly what the interface was supposed to prevent.

With the introduction of CPUs which ran faster than the original 4.77 MHz Intel 8088 used in the IBM Personal Computer, programs which relied on the CPU's frequency for timing were executing faster than intended. Games in particular were often rendered unplayable. To provide some compatibility, the "turbo" button was added. Engaging turbo mode slows the system down to a state compatible with original 8086/8088 chips.

The blog that's almost nothing

Top level architecture

Great thanks to Blake Education for giving us the freedom and time to develop this project in 2013 while working on their project.

I made this gem because I tried reform and I found some bugs. I started to contribute but there is some things I don't like in reform.

Offshore Software Development

NO support whatsoever will be given for the moment unless I gave you the program personally. This is because all of this is work in progress and I can't code while constantly writing documentation and answering questions.

DEV actively answers questions in the community.

As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website.

As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website. This became painfully apparent when we noticed other people post OpenTTD on some stores. They are not always updated with new releases, sometimes even slacking behind a few years. And maybe more important to us: we can not guarantee that the uploaded version is unmodified and is the version as we intended. So, instead of fighting it, why not turn around and join them! Why not release our own, verified, builds on those stores! And this is exactly what we have been working on lately. And when I say “we”, a bit ironic to me, I mean the two developers that are around longest (myself and orudge) ;) A while back orudge added OpenTTD to the Microsoft Store. And today, I am happy to announce we will be on SteamE too! Well, we are on Steam, but we haven’t released anything there yet (sorry that I got your hopes up, just to squash them right after :( ). This is partially because of how Steam works, but also because we know we can bring a better experience for Steam with our upcoming release. That brings me to the most exciting news: if everything goes as planned, we will release OpenTTD 1.11 on Steam on the first of April, 2021! And that is not even an April fools’ joke! You can already Wishlist OpenTTD today .. and till we release on Steam, you can find our game via our website ;)

Unlike naming children, coding involves naming things on a daily basis. When you write code, naming things isn’t just hard, it’s a relentless demand for creativity. Fortunately, programmers are creative people.

There’s only one hard thing in Computer Science: human communication. The most complex part of cache invalidation is figuring out what the heck people mean with the word cache. Once you get that sorted out, the rest is not that complicated; the tools are out there, and they’re pretty good.

“Functional programming language” is not a clearly defined term. From the various properties that are typically associated with functional programming I only want to focus on one: “Immutability” and referential transparency.

This gives them a slight edge but that’s nothing substantial because those fixes eventually reach Ubuntu.

But all of these attempts misunderstand why the Open Source ecosystem is successful as a whole. The ecosystem of fairly standard licenses provides a level playing field that allows collaboration with low friction, and produces massive value for everyone involved – both to those that contribute and to those that don't. It is not without problems (there are many essential but unsexy projects that are struggling with funding), but introducing more friction won't improve the success of this ecosystem – it will just lead to some parts of the ecosystem to break off.

Part of me thinks that open source can be more rewarding to the creators/contributors. But maybe the real contribution is the permanent addition to the tools available to humanity, and if you have the wits, you can make a decent business out of it without tainting open source.

Selling proprietary software is difficult when there is so much gratis Open Source software around.

For a sufficiently successful and industry-relevant open source project, it's possible for the main developers to earn a living e.g. by selling related consulting services.

It turns out that creating and using Free Software is not just good to individuals, but for businesses as well, for example by building upon publicly available components and by collaborating shared software. The term Open Source is a business-friendly rebranding of the Free Software concept. This line of thought was also widely successful, e.g. Firefox/Mozilla was an open sourcing of Netscape software.

Systemd flies in the face of the Unix philosophy: 'do one thing and do it well,' representing a complex collection of dozens of tightly coupled binaries

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.

Although it is open-source, Snap on the other hand, only works with the Ubuntu Store. Nobody knows how to make a Snap Store and nobody can. The Snap client is designed to work with only one source, following a protocol which isn’t open, and using only one authentication system. Snapd is nothing on its own, it can only work with the Ubuntu Store.

We took a stance on an issue. We informed and documented. We made it easy for you to understand the problem and also to take action if you disagreed.

At work, I cannot maintain this project. At home, I'd rather spend time with my children and on projects that I'm currently passionate about.

Maintaining open source software requires energy and a "want"/"passion". I've not been using this project myself for years, and I mainly work in other things than Rails at this point. That means I'm far removed from this project and see no personal gain in maintaining the energy to keep this going.

How should this be manually tested?

Augmented Steam is an open source project. You can verify the code for yourself, help us improve it or create your very own version.

I'm very (VERY!) tempted to use that ppa, but without offense to it's maintainers... it's just some random ppa. If it had more "traction" I'd use it. Right now it has only 3 maintainers.

It is pretty much what Ubuntu 20.04 could have been, but isn't.

Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all

It appears that Canonical is continuing it's vice grip of unliateral, maybe dictatorial control on the development of Snap to the benefit of Ubuntu, but to the detriment of groups like Linuxmint, and all other non-Ubuntu based Linux distributions - like CentOS/Redhat, Suse/openSuSe, Solus, Arch/Manjaro, PCLinuxOS, etc, that are pushing Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all. .

If upstream code presumes things will work that dont in snap (e.g. accesses /tmp or /etc) the snap maintainer has to rewrite that code and maintain a fork. Pointless work. Packaging for .deb is a no-brainer.

>Linux needs an app delivery format Yeah, it's incredible that it has managed to survive for so long without one.

It's Snap that drove me to Arch, so it did me a huge favour. Seeing things like GNOME as a snap and other 'core' products wasn't something I was comfortable with. Personally, I prefer flatpaks as a packaging format when compared to snap and appimage. I agree that Linux needs an app delivery format, but snap's current implementation isn't it.

I run a fairly ancient RedHat Enterprise 6 on my 32-bit test machine and if I need something requiring Gtk3 (such as a latest Firefox or Chrome), I just make a chroot and use debootstrap (from EPEL) to get me a Debian 9 userland for that program. Easy. No bizarre "app stores", no conflicting packages. Do people use Snap app-stores because they don't know how to use the chroot command? Or are they just lazy? If it is because they want the added security of a container, substitute chroot with lxc... Shouldn't be necessary though; if you avoid non-ethical software (i.e App-stores), you are very unlikely to need the added security.

Well, that user can safely stay with Windows. Hiding these things from me makes wish that.

Volkswagen, the world’s largest car maker, has outspent all rivals in a global bid by auto incumbents to beat Tesla. For years, industry leaders and analysts pointed to the German company as evidence that, once unleashed, the old guard’s raw financial power paired with decades of engineering excellence would make short work of Elon Musk’s scrappy startup. What they didn’t consider: Electric vehicles are more about software than hardware. And producing exquisitely engineered gas-powered cars doesn’t translate into coding savvy.

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).

answered

If anyone needs this functionality, I've made a primitive approach to forward all standard UI events, plus any others you specify: https://github.com/hperrin/svelte-material-ui/blob/273ded17c978ece3dd87f32a58dd9839e5c61325/components/forwardEvents.js

Would you work for free? It is a simple but loaded question that requires additional context. Is it working to help a friend do something? Is it work that you would enjoy? Does the act of working for free give you some level of satisfaction? Your gut reaction to the question may have been a hearty, “No,” but many people volunteer for a variety of things all the time, so people will work for free when there is something in it they enjoy.

Open source is fundamentally good with the transparency and flexibility it brings; however, as our reliance on it goes up, the overall investment back into the ecosystem has not. It can be easy to take for granted the time and effort many developers put into open source projects. Yet it is with their time and effort that we often save our own.

These developers are not greedy or selfish for wanting funding for their projects. To the contrary, they want funding to keep the project alive. A person has to eat, after all. Funding the project is a means of changing the maintainer’s timeshare—allowing themselves to put time into the project that otherwise would be used for other employment. There is only so much time in a day that a person can otherwise give.

Funding should not be a struggle for open source projects. We embrace open source into our codebases frequently but have yet to fully embrace the idea that funding it actually helps us too. The bug fixes and feature requests need to be implemented, tested, and reviewed by someone who themselves can only put so much time into the project.

While the code may live online somewhere forever, an open source project only truly survives if someone maintains it.

answered

Chromium is a very popular web browser, the fully open source counterpart to Google Chrome.

All right, whoever, who wanted to get the latest Chromium work without worrying about snaps, get it from here 15, unzip it and make a executable link to executive file “chrome” in it. It opens instantaneously (in a snap). This Chromium web browser is NOT installed, but lives in a folder called chrome-linux.

Look at it from another distro point of view, like Fedora or Arch. On the whole packages for popular software are not made for those distros - by the manufacturers of the software. As a result many flatpaks and some AUR packages are built by ripping apart debs and re-packing them as other package formats. This benefits Arch and Fedora (and other distros) because they now have access to software they might not have.

While the very same software might be in a PPA and a snap, the fact that the snap is shown in Ubuntu Software is the point I’m making. Many people use that to install software. So making software appear there is beneficial for developers - their software is found, and beneficial for users - they discover new software.

Most users frankly don’t care how software is packaged. They don’t understand the difference between deb / rpm / flatpak / snap. They just want a button that installs Spotify so they can listen to their music.

In addition, PPAs are awful for software discovery. Average users have no idea what a PPA is, nor how to configure or install software from it. Part of the point of snap is to make software discovery easier. We can put new software in the “Editor’s Picks” in Ubuntu Software then people will discover and install it. Having software in a random PPA somewhere online is only usable by experts. Normal users have no visibility to it.

Frankly, if the Ubuntu Desktop team “switch” from making a deb of Chromium to making a snap, I doubt they’d switch back. It’s a tremendous amount of work for developer(s) to maintain numerous debs across all supported releases. Maintaining a single snap is just practically and financially more sensible.

Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.

Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.

but that doesn’t mean that confining applications is not a benefit also to FOSS applications, security is an issue that needs to be addressed with many layers of measures no mater what licensing approach you use to license the software

However there’s more benefit of confining proprietary closed source applications, because they are to audit to the same level

I don’t think he implies that, he didn’t mentioned FOSS or non-FOSS. Third party doesn’t refer to licensing, only to who provides it.

I don’t find the software slow, I find the startup time for snap packages when the start for the first time on a session slow, but that has been improved, and it’s public that the snapcraft team has been working hard to improve that.

The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.

wouldn’t that « lesser » the FOSS effort towards desktop app’s ?

Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.

If you’re not a huge fan of Snap packages, but love using Ubuntu, this guide is for you. In it, we’ll go over how you can remove Snap from your Ubuntu system and make it so that your system will no longer have access to the Snap store or anything like that.

Snap packages are quickly becoming the primary way that Ubuntu users consume software. Despite Snaps dominating Ubuntu, many users still opt to avoid Snap packages in favor of Apt packages that have long been available in Ubuntu.

If it is powerful and reliable, that means it serves them better.

That practice went from being standard practice to being a faux pas (not abstracting JavaScript functionality away from HTML) to, eh, you need it when you need it.

Font Awesome is fully open source and is GPL friendly. You can use it for commercial projects, open source projects, or really just about whatever you want.

artificial intelligence seems to be the future of software

Therefore, it could be argued that belief regarding the usefulness of technologies could lead to change and ultimately the actual use of digital technologies in teaching and learning.

You’re in good companyTrusted by leaders at some of the world’s most inspired organizations

You can also purchase a Nextcould hosting service, which on one hand may not seem any different from giving your photos over to Google or Apple, but there's a significant difference: Nextcloud storage is demonstrably encrypted, with source code to prove it.

We are unapologetic tinkerers who neither invent the wheel, nor are satisfied with the wheels already at our disposal. The best scholarship and the best pedagogy take the best of what already exists and make it better, at least better for the task at hand. We need to embrace this identity as hackers, acknowledge our indebtedness to those who have gone before us, forsake the illusion that we are creating (can create, should create) something wholly original, but also refuse to take for granted the things that have been passed down to us.

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.

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.

The template language's restrictions compared to JavaScript/JSX-built views are part of Svelte's performance story. It's able to optimize things ahead of time that are impossible with dynamic code because of the constraints. Here's a couple tweets from the author about that

Keep in mind that as a software developer, of any degree, learning is continuous. New technologies, new ways to write code, not so new approaches, persisting patterns. Read books, watch online courses, follow tutorials, keep learning!

Because Jamstack projects don’t rely on server-side code, they can be distributed instead of living on a single server. Serving directly from a CDN unlocks speeds and performance that can’t be beat. The more of your app you can push to the edge, the better the user experience.

Better PerformanceWhy wait for pages to build on the fly when you can generate them at deploy time? When it comes to minimizing the time to first byte, nothing beats pre-built files served over a CDN.

Better contribution workflow: We will be using GitHub’s contribution tools and features, essentially moving MDN from a Wiki model to a pull request (PR) model. This is so much better for contribution, allowing for intelligent linting, mass edits, and inclusion of MDN docs in whatever workflows you want to add it to (you can edit MDN source files directly in your favorite code editor).

I don't think this is what really matters at the end, since whatever is the implementation the goal should be to provide a library that people actually like to use.

Micro is a platform for cloud native development. It addresses the key requirements for building services in the cloud. Micro leverages the microservices architecture pattern and provides a set of services which act as the building blocks of a platform. Micro deals with the complexity of distributed systems and provides simpler programmable abstractions to build on.

A Comprehensive Guide on the Dedicated Team Model: Explaining the Concept, Advantages, and Pitfalls

No program is an island. Every program has to hook into the operating system at some point, if nothing else.

As was mentioned in the comments above, the material design spec for buttons specifies that the text should be uppercase, but you can easily override its CSS property: paper-button { text-transform: none; }

enables passive event listeners by default for some events (see list below). It basically will set { passive: true } automatically every time you declare a new event listener.

There are actually 3 other libraries that implements material in svelte, i hope this to become the community favorite because using MDC underneath it implements correctly Material guidelines.

I'm still deeply working on it every day, i'm around 1/2 month away for a first preview release.

from my point of view, it is (by far) the best way, to build a layer on top https://github.com/material-components/material-components-web . This is also the path that the Angular Material team has taken, although they have already made a huge effort to create the components themselves.

@monkeythedev can your work be used already? I would suggest not yet, i'm still doing core changes every day

@use "@material/theme" with (  $primary: #FEDBD0,  $on-primary: #442C2E);

You could totally just write your own name and not use the name in package.json, this template is made so the users wouldn't need to think about the UMD build.

Who’s Using Snowpack?

Portable... your .name address works with any email or web service. With our automatic forwarding service on third level domains, you can change email accounts, your ISP, or your job without changing your email address. Any mail sent to your .name address arrives in any email box you choose.

If you are a developer and would like to fork, modify and/or contribute to this extesion, then this section is for you.

Used by folks at

Prior work This project uses work done in the awesome-typescript-loader.

The project organization is a bit weird because we have a mono-repository that contains projects and libraries. The projects are grouped by company and by browser / server / universal.

It is impossible to rebuild the base from the Dockerfile as the 3rd party dependencies have changed significantly since 8 months ago when the base was last built. The tags for my base image have been overwritten and I can only restore them from a descendant image. With Docker 1.8 I simply pulled the descendant image, tagged the base layer and I was done. With Docker 1.10+ I'd need to save, then manually construct the base image descriptor and reload it. Doable but sad that it's far more complex.

Allowing parent layer metadata to be saved for a layer, regardless if the parent layer is in the save command, would be a huge win for those of us working on CI/remote systems. Reusing parent layers used to be ridiculously easy. It would be good if we could get some comparably easy way to do it now.

It used to be great that I was able to select a layer from any image and use it as a starting point. Currently, I am given an image that has 4 layers to be stripped off to get to the original base image. The original image is not reconstructable in any other way.

Since yarn already has retries on metadata operations, my perspective is that this PR is about filling in an (inadvertent I assume) gap.

Test plan You need a large NPM package in a private org on the npmjs.org registry. 10MB download size is ideal.

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.