In the meantime, people do seem to appreciate a developer spending 2 minutes to reply to comments on old issues, just so they’re not ignored and to manage expectations.

When one is searching for it on the internet, there are many many people wondering how one can open .desktop files. It seems trivial, since one usually just has to click an item on the launcher so one thinks there must be some way.

I have to agree with Raphael here that this should probably be handled in gnome-open, its a pain to have to implement .desktop parsing code in every beagle front end when I can't really think of an instance where the expected behavior wouldn't be to execute the associated command.

I don't know what nautilus does, but i think when you double click a .desktop file it launches the associated program, i guess they don't use gnome-open then..

deskbar should probably detect their extension and execute the relevant command as opposed to opening the file for editing.

If you really want this, I suggest you write a little function that extracts the executable name from the .desktop file and runs it. Add these lines to your shell's initialization file (e.g. ~/.bashrc): runDesktop () { eval "$(awk -F= '$1=="Exec"{$1=""; print}' "$1")" } Then, you can run your .desktop file with runDesktop ~/Desktop/slack.desktop

Is somehow possible to run a "Desktop Entry" from another "Desktop Entry"?

For one, anyone using this module would automatically benefit from any future performance improvements without having to do anything themselves.

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.

I agree about lack of maintenance. It's probably because people use more and more Webpack.

This appears to be an undocumented breaking change. For example, the word "debug" does not appear in the sprockets 4 changelog.

OpenFaaS is hosted by OpenFaaS Ltd (registration: 11076587), a company which also offers commercial services, homepage sponsorships, and support.

Degg naa ko muy tari Alxuraan.

Ci taatu guy googu la jigéeni Ajoor yi di jaaye sanqal.

despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones

The new 2.1 version comes with a few necessary but reasonable changes in method signatures. As painful as that might sound to your Rails-spoiled ears, we preferred to fix design mistakes now before dragging them on forever.

The assert method is used by all the other assertions. It pushes the second parameter to the list of errors if the first parameter evaluates to false or nil.

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

They are a nice idea, but in practice

Now if you think about it, PJAX sounds a lot like Turbolinks. They both use JS to fetch server-rendered HTML and put it into the DOM. They both do caching and manage the forward and back buttons. It's almost as if the Rails team took a technique developed elsewhere and just rebranded it.

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.

the bloody mount points. I couldn't believe that when I realised what was going on. I got the wire brush and dettol out and scraped it off my drive. Never, ever again.

There's a lot of advice online showing how to get rid of snap. (e.g.: https://cialu.net/how-to-disable-and-remove-completely-snaps-in-ubuntu-linux/ worked for me) so the only result (so far, a few months later) is that Chromium has lost a user, and having upgraded Ubuntu since the original Warty, if snap becomes obligatory I'll have to take a look at Mint, or Devuan.

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

You should default to the most permissive option imo and there really is no reason to check anything until you really need to If it were left to me I'd just use optional chaining, as it also eliminates the need for no-ops

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

be conservative in what you do, be liberal in what you accept from others

But now Chromium is no more available as deb, so what to expect ?

And Unity ditching for something that’s still not on par with it, had already broken a bit my trust in Ubuntu as a stable option at work. Now snap is coming closer and broader…

Much like civil engineering and chemical engineering in decades past, this new discipline aims to corral the power of a few key ideas, bringing new resources and capabilities to people, and doing so safely. Whereas civil engineering and chemical engineering were built on physics and chemistry, this new engineering discipline will be built on ideas that the preceding century gave substance to — ideas such as “information,” “algorithm,” “data,” “uncertainty,” “computing,” “inference,” and “optimization.” Moreover, since much of the focus of the new discipline will be on data from and about humans, its development will require perspectives from the social sciences and humanities.

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.

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; }

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

obviously it's too late, but it's a good practice to keep the 3rd party dependencies mirrored in your own infrastructure :) There is NO GUARANTEE that even a huge site (like launchpad for downloading DEBs) won't go down over a period of time.

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.

I also like that the folksonomic approach (as in, there are no “pre-established groups”) allows for a great deal of expression, of negotiation (I imagine that #barcamp will be a common tag between events, but that’s fine, since if there is a collision, say between two separate BarCamps on the same day, they’ll just have to socially engineer a solution and probably pick a new tag, like #barcampblock) and of decay (that is, over time, as tags are used less frequently, other people can reuse them — no domain squatting!).

Furthermore, how come there's a PR open since 3 months, at what seems to be the authoritative repo for Svelte?

There are a few intentional behavioral differences between Dart Sass and Ruby Sass. These are generally places where Ruby Sass has an undesired behavior, and it's substantially easier to implement the correct behavior than it would be to implement compatible behavior. These should all have tracking bugs against Ruby Sass to update the reference behavior.

When you use a function like color(). it’s impossible to know exactly where it was defined. Which @import does it come from?

In Angular CLI 6 this command has been removed, and it will not come back. Instead there is a new concept called Builders.With the new Angular CLI you can customize the build process by defining your own builders as well as using one of the builders provided by the community.

Gracious, father! What a fright you gave me! Have you just come home? Why isn’t Charles here to help you off with your coat?

Things that I miss most from Vue:

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.

OMGWTFSSL - Self Signed SSL Certificate Generator Self Signed SSL Certificate Generator

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.

Library author here. I'm always fascinated by new ways people can invalidate my assumptions. I mean that in a sincerely positive way, as it results in learning.

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

Subgroups of the computer underground with different attitudes and motives use different terms to demarcate themselves from each other. These classifications are also used to exclude specific groups with whom they do not agree.

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.

If you define a variable outside of your form, you can then set the value of that variable to the handleSubmit function that 🏁 React Final Form gives you, and then you can call that function from outside of the form.

This module is similar to JSX, but provided as a standards-compliant ES6 tagged template string function.

However, this would lead to further divergence. Tooling that is built around the assumptions imposed by template literals wouldn't work. It would undermine the meaning of template literals. It would be necessary to define how JSX behaves within the rest of the ECMAScript grammar within the template literal anyway.

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!

Doesn't require the use of transpiler or modifications to all JS tooling ever invented.

And as an aside, I’m definitely in favor of more debates than sessions in future conferences, since we actually learn more by hearing multiple viewpoints.

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.

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.

To fix our Svelte version you might think we could use beforeUpdate or afterUpdate, but these lifecycle functions are related to the DOM being updated, not to prop updates. We only want to rerun our fetching when the album prop is changed.

I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.

If Svelte came up with some kind of hooks like API maybe it could solve both these issues at once.

I think Svelte has some things to learn from React hooks.

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

Why struggle with custom Syntax DSLs when you can use one so widely supported?

It was only pragmatic to use a tool that basically gives you that all for free.

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

Because Svelte is a compiler, we're not bound to the peculiarities of JavaScript: we can design a component authoring experience, rather than having to fit it around the semantics of the language.

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

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

yet when I thought of my beloved Elizabeth, of her tears and endless sorrow, when she should find her lover so barbarously snatched from her, tears, the first I had shed for many months, streamed from my eyes,

Migrating the stores to TypeScript

“You are free to eat from any tree in the garden;(W) 17 but you must not eat from the tree of the knowledge of good and evil,(X) for when you eat from it you will certainly die.”

One key advantage of 'HTML-plus' languages is that you don't actually need tooling in order to be productive — most editors give you out-of-the-box support for things like syntax highlighting (though imperfect, as JavaScript expressions are treated as strings) and auto-closing tags. Tools like Emmet work with no additional setup. HTMLx should retain that benefit.

benefited from a shared set of tools for syntax highlighting, autocomplete, linting and so on.

Secure-by-default is a great approach, but this is not that. It's not even, we know what's best. It's clean up your act or you're out. You really should provide an opt-in to running with scissors. Maybe like config.opt_in_to_dynamic_routes_you_dumbass = true. 1 Pick your reaction

I too would like to know more about the security concerns that are the motivation to remove these useful dynamic routing components. The only thing I can think off is someone who accidentally exposes a private method public, is there more? The dynamic routes are a great way to keep the routing.rb DRY and avoid unneeded dependencies between the routing and the controller files, it has been quintessential Rails magic since version 1.0, surely there must be more serious security concerns to give up such important benefits? What are they? Do we really need to completely remove this from the code base, when removing it from the default routes.rb already would get you most of the security benefit?

I'm sure the security overlords have our best interest in mind and I'd be happy to change my opinion if someone can explain this tradeoff better. I know I can recreate the functionality for myself but I also like to keep in mind what's best for Rails. Just a hand wavy "we've had this for almost 10 years, but it might become an issue in the future so let's preventively eliminate it" does not seem a good enough reason to cut a feature that can make code much more DRY and elegant.

Sounds like Mixins are on their way out