That. Is the coolest. Shortcut. Ever. 💥 🚀

It's an interesting position and had me rethinking things a bit, but the way I look at it, the actions themselves are negative; it's their boundary conditions which are different. Take for instance embark/disembark. In pseudo-mathematical terms, I would tend to think they increment or decrement one's embarkedness, with an upper boundary of 1 (aboard), and a lower boundary of 0 (ashore). The non-existence of values >1 (super-aboard) or <0 (anti-aboard) shouldn't affect the relative polarity of the actions themselves. I think. Looking through the rest of the list, there's a variety of different boundary conditions. Prove/disprove would range from 1 to -1 (1=proven, 0=asserted but untested, -1=proven false), entangle/disentangle seems to range from 0 to infinity (because you can always be a little more entangled, can't you?), and please/displease is perhaps wholly unbounded (if we imagine that humanity has an infinite capacity for both suffering and joy).

Also unclear why the answer is criticized for providing a "more general case" since the OP said "You are right, this [base64] was just used as an example, though.

The lonesome cat isn’t useless.  UUOCs are typically characterized by having exactly one filename argument; this one has none.  It connects the input to the function (which is the input of the if statement) to the output of the if statement (which is the input to the base64 –decode statement)

The title of the question is what triggered the process of finding this Q/A for material that aided development of the above to solve a real life problem described by the title. The OP declared that base64 decode was not the "real" problem; pedantic constraint of answers to a particular "example" seems less helpful. When this question and its answers were key to helping solve real problems, alternate answers can be gifts to the community in recognition of the fact that many more people will use this Q/A to solve problems. Since the answer is on-topic per the title, I feel it is "game on".

The answer credits others while solving a problem that wasn't optimally solved by other (helpful) answers at the time. I shared to help others. It is up to a reader to select answers and review for appropriateness to their needs. This almost looks like an attack when all that was required was an alternative answer standing on its own merits or demerits.

resolution of a design widget is more like closing an issue than an MR

We didn't add this initially because Google is not the only form of authentication we offer and it could get annoying for users that sign up with GitHub or username and password to see the Google popup all the time.

lib/ is intended to be for non-app specific library code that just happens to live in the app for now (usually pending extraction into open source or whatever).

Stuff like a generic PhoneNumberFormatter is exactly what lib/ is intended for.

The criteria for code in lib is what @dhh said above: non-app specific library code that just happens to live in the app for now (usually pending extraction into open source or whatever)

(BTW, the app/models directory is there to organize the model layer. The model layer is greater than the persisted models.)

Everything has a place so do better and find it. There is a certain belief that everything within app should be organized into functionally-named directories and any files placed in app/lib actually belongs in app/services or app/interactors or app/models or someplace if the developers just tried harder. The implication is that developers are bad developers if they don’t yet know what kind of constant they have and where its forever home should be. I reject this. Over the lifespan of an application, there will be constants that have not yet found their functional kin, if those kin ever come to exist at all; sometimes you simply need some code and a place to put it. app/lib can be the convention for where those constants can live temporarily or as long as necessary. Autoloading is really nice, let’s treat them to it.

The nice point of Kiwi is that it supports Chrome extensions, this is why I am trying it. Browser extensions are something which I believe should be rather more widespread in Android by now.

as a native speaker I'd probably tend to refer to his drug dependency, but his dependence on drugs (maybe because I see one as a problem he has, and the other as something he's doing, I don't know).

I think that "dependency" is usually the thing that you depend on, whereas dependence is the state of depending on it. But there are certainly cases where you could use either interchangeably.

Answers are identical because Questions are identical too !

For me, I don't have an issue, but there was one syntax situation I found awkward: I need to sometimes know whether it is a class or a module that I am modifying. So I may have code: module Foo module Bar class Baz versus: class Foo::Bar::Baz It's not a huge issue, but ruby would yield an error if I specify a class or module incorrectly (which can happen if you spread code out into different .rb files, so I understand why there is an error message shown, to avoid accidents). But I then also wondered why I have to care whether it is a module or class, if my primary goal is to modify something, such as by adding a method. If I want to add a method: def foobar; end then I really should never be required to have to know whether I am modifying a class or a module.

I'm curious: what is the reason for Yahoo discontinuing the "@ymail.com" domain?I'm aware that there's now a 2nd domain option available, "@myyahoo.com", and I recently took advantage of that to create a new address. But "@ymail.com" honestly looks more appealing to me than either of the "yahoo" iterations.

I find the use of the term “session” within integration tests a bit unfortunate (open_session, etc), since there are also these session objects, which are however different. Maybe replace by “user_session” ?

I think we have a responsibility not only to ourselves, but also to each other, to our community, not to use Ruby only in the ways that are either implicitly or explicitly promoted to us, but to explore the fringes, and wrestle with new and experimental features and techniques, so that as many different perspectives as possible inform on the question of “is this good or not”.

Public and/or protected fields are bad because they can be manipulated from outside the declaring class without validation; thus they can be said to break the encapsulation principle of object oriented programming.

If you're already using PostgreSQL anyway, just use citext as the type of the email_address column.

Some day, the de facto standard and the official standard will hopefully be the same. It's too bad we have to deal with this issue at all.

Sorry, I can't agree with you. If someone issues a second code, they should have two potential logins - one for each one they requested. Call me weird, but considering how cheap it is to store data, I'd rather keep around exactly what happened.

deleting user files without being asked for is by far an "unsafe in nonzero scenarios" decision, no program should do it. The sane option is to refuse working and/or display a visible warning explaining why.

Result of lots of searching on net is that pre-checkout hook in git is not implemented yet. The reason can be: There is no practical use. I do have a case It can be achieved by any other means. Please tell me how? Its too difficult to implement. I don't think this is a valid reason

but that before marking the contact as a bounced, Campaign should double check it was really a hard bounce that would affect future deliverability.

I don't see why this is a false positive

I fail to understand how this is such a low priority. Code review is one of the most basic and critical portions of development lifecycle, and prior to discovery of this ticket I literally had to roll an entire other repository manager just to perform that correctly when I discovered entire directories of changes had been omitted from the Gitlab generated MR. We actually found that in order to get the change set fix to apply reliably, that it is required to add "?w=1" to the url even after updating the white space setting.

A better message, clarifying the true purpose of the cop, which I guess is to differentiate empty Hash literals and blocks.

Some people eventually realize that the code quality is important, but they lack of the time to do it. This is the typical situation when you work under pressure or time constrains. It is hard to explain to you boss that you need another week to prepare your code when it is “already working”. So you ship the code anyway because you can not afford to spent one week more.

I don't like the first syntax because then you have weird looking code due to all the leading whitespace, and you lose a lot of real estate.

Aligning everything with however long the method name is makes every indention different. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true Compared to the following, which all align nicely on the left. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true

really begin/end is just a way to pass several expressions where you normally need to pass only one. In this way I think it's much closer to something like conditionals (e.g. if, than to do).

I'm not sure if there's a reason why additionalProperties only looks at the sibling-level when checking allowed properties but IMHO this should be changed.

Good code is its own best documentation. As you’re about to add a comment, ask yourself, "How can I improve the code so that this comment isn’t needed?". Improve the code and then document it to make it even clearer.

Stop autoclosing of PRs While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions. Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.

All that can be forgiven, but not charging $10 USD for this bundle worsener (they dumped it very quick into shovelware game bundles). $10 gets you a lot of great games on Steam like Frostpunk, Metro and Skyrim, so it's impossible to ask anyone considers this against the competition.

Either way, I’m a fan of leaving the math in the authored code.

I found this counterintuitive because usually I try to make all my passwords, etc. different for each environment I have. I thought I would need to create a different master key for my production environment. No, I need to not create a different master key.

I just thought that if there was any time to improve the naming it would be now, before rolling it out to thousands of devs/projects. I don't think of that as bikeshedding, personally.

Ruby should not completely ignore blocks. const_set :Example, Class.new do p "Hello, world" end # Doesn't print anything, generate any warning nor error. To minimize any impact, Ruby should issue a warning, and in future version could even raise an error. Even unused variables provide warnings in verbose mode, and they have their use. I can't think of a case where passing a block to a builtin method that doesn't accept a block is not a programming error though.

FORBIDDEN: Status code (403) indicating the server understood the request but refused to fulfill it. User/agent known by the server but has insufficient credentials. Repeating request will not work, unless credentials changed, which is very unlikely in a short time span.

UNAUTHORIZED: Status code (401) indicating that the request requires authentication, usually this means user needs to be logged-in (session). User/agent unknown by the server. Can repeat with other credentials. NOTE: This is confusing as this should have been named 'unauthenticated' instead of 'unauthorized'.

So, underscores are not quite as good as spaces. They’re a compromise of language, readability, and semantics, but they’re the best we’ve got. Better than dashes, CamelCase, plus+signs, or anything else. So use them.

The “use spaces, or else fall back on quotes” system is just silly.

And this is why I left Ubuntu. If I want a SNAP I will install a SNAP. Otherwise stay out of my crap.

in my opinion it could have been more constructive to move this question to cryptography stack exchange, instead of downvoting and closing it.

t's also why it is so annoying to people who actually know what they are doing, when randomly the browser decides to take over a function provided for decades by the OS network stack, and with no notice start bypassing all the infrastructure they set up to their liking (like your hosts file) and funelling all their browsing habits to some shady company (Cloudflare).

Therefore, Firefox already contains the code to look in the hosts file, but it does things in the wrong order: 1. Look up the URL in the DNS server if not found: 2. Send the URL to the default search engine as a search term if not found: 3. Look in the hosts file

The entries in the hosts file are obviously not on a DNS server. Setting the keyword.enabled option FALSE by itself should only turn off the feature that uses the address field as a search field. It would not give Firefox an additional ability that it did not have before.

I have never seen the @Stale bot or any directly equivalent to it achieve a net positive outcome. Never. It results in disgruntled people, extra expenditure of effort (for reporters and maintainers), real stuff getting lost when people get fed up with poking the bot (I have no intention of poking it further), and more extensive filing of duplicates. You say a simple comment dismisses it, but it doesn’t—it only does this time. Next time, it continues to annoy. This is an issue tracker. Use labels, projects, milestones and the likes for prioritising stuff. Not sweeping stuff under the carpet.

Closing issues doesn’t solve anything. Closing issues in GitHub just sweeps them under the carpet and helps everyone to forget about them, which is just not what you want—the fact that GitHub search excludes closed items by default is a large part of the problem with it. As applied to software projects with general-purpose issue trackers, the @Stale bot is fundamentally phenomenally bad idea, a road paved with good intentions. I presented an actionable alternative: labels. Possibly automatically applied, but it’s certainly better to spend a little bit of time on manual triage. It honestly doesn’t take long to skim through a few hundred issues and bin them into labels. 609 open issues? That’s honestly not a problem. Not at all. There’s nothing wrong with having a large number of issues open, if they do correspond to real things—even things that you may not expect to get to for years, if ever, because that might change or someone might decide they want to deal with one. Closing issues that aren’t dealt with is bad. Please don’t do it.

Indeed yes, but sometimes it is necessary to change one's password, even if one is not 'mucking about with' or 'tweaking' or 'customising' any other system settings.

In the vast majority of cases when I'm using prettier-ignore I'm only really looking to prevent it from breaking my code into new lines, whilst keeping its other transformations such as switching quotes and adding space between brackets. When ignoring single lines, fixing these formatting problems by hand is very manageable. With the ability to have Prettier ignore entire blocks of code I think the ability to specify what you want it to ignore is essential.

When writing about programming, I prefer to use 'annotation' as the general term. Although .NET was first, the word 'attribute' is just too widely used for different things.

As you can see Rails already adds error messages from associated models and doing it wrongly: Merging together errors from different models under same has_many association. :"employments.company"=>["can't be blank"] And this is wrong.

I'm not sure if there's any cost in terms of contributing either, especially when by design git can have any branch as default, and will not hinder your experience when you use something other than master.

Forcing people out of the habit to assume this branch would be called master, is a valuable lesson.

The primary branch in git can have any name by design.

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.

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.

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.

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

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.

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 really want to re-implement all of my api endpoints to make this work. Is there a way to "mask" the thirdparty endpoints to pass through the cookies?

I would argue though that crashing is better than quietly providing unexpected behavior.

The reason fragments should be identifiable by users is because a user, not the content creator or the developer, will ultimately decide whether or not a portion of content is valuable or notable in some way.

The developer or content creator may have a general idea of how a page’s content might be divided up, but ultimately it will be the linking resource that should have full control over what portion of the page they want to highlight.

This means that, regardless of what the developer has done behind the scenes in the HTML, all HTML fragments on that page should be identifiable by external referrers.

That's something that has been bugging me too. I mean, it's fine if not everything is supported, but if everyone could agree on what is or should be supported then that would make a huge difference. But until then, it's going to be a struggle.

I'm of the opinion that there shouldn't be a platformer in today's market that doesn't include native controller support

Game Saves After completion of each level

Been seeing this comment copy/pasted everywhere it's pathetic what people will do for thumbs up/awards on reviews, be original and make your own review. If you guys need proof go and look at NVL reviews, I saw it on another game a few weeks ago too.

Neither question nor answer appears to understand the notion of semantic HTML. Height and width are presentational attributes regardless of where you put them. For semantics we establish what the image means to content in the alt tag. I don't remember why it was so important to width/height in the HTML but I suspect it was in case you hit browsers without CSS rendering. It's not a semantics issue. If anything it thwarts separation of concerns to a degree.

If anything it thwarts separation of concerns to a degree.

It has two very different meanings, that you would have to distinguish by context. One meaning is just expressing that we have limitations. If you don't know something, that's just tough, you don't know it and you have to live with that. You don't have information if you don't have that information. The other meaning is that not only are there gaps in our knowledge, but often we don't even know what the gaps in our knowledge are. I don't know how to speak Finnish. That's a gap in my knowledge that I know about. I know that I don't know how to speak Finnish. But there are gaps in my knowledge that I'm not even aware of. That's where you can say "You don't know what you don't know" meaning that you don't even know what knowledge you are missing.

“Who cares? Let’s just go with the style-guide” — to which my response is that caring about the details is in the heart of much of our doings. Yes, this is not a major issue; def self.method is not even a code smell. Actually, that whole debate is on the verge of being incidental. Yet the learning process and the gained knowledge involved in understanding each choice is alone worth the discussion. Furthermore, I believe that the class << self notation echoes a better, more stable understanding of Ruby and Object Orientation in Ruby. Lastly, remember that style-guides may change or be altered (carefully, though!).

I wish to define methods within the class they belong to. Using class << self demonstrates that approach clearly — we are defining methods within the actual singleton class scope.

When we usedef self.method, though, we are defining a method across scopes: we are present in the regular class scope, but we use Ruby’s ability to define methods upon specific instances from anywhere; self within a class definition is the Class instance we are working on (i.e. the class itself). Therefore, usingdef self.method is a leap to another scope, and this feels wrong to me.

I strongly prefer this over Carcassonne. It plays faster (I don't want a tile laying game to go for more than 30 mins or so) and I happen to like the limited options. Carcassonne just gets on my nerves because I just don't view selecting between so many placement options to be that interesting. Obviously, YMMV. Ditto the previous statement, it's different than Carcassonne. And that's why I like it.

I recently played a prototype of an upcoming game called Bronze. This takes the tile-laying/ territory claiming mechanic and builds on it by adding abilities to each of the tiles. they benefit you in some way if you claim them. The result is a very similar feel to Fjords (competing for a share of the map) but with greater depth.

It is one of the better games to stuff in (y)our luggage when on holidays. (We tried Hive a couple of times, but that is too heavy stuff for the holidays.)

What I dislike from the achievements is the "Dialogue Skipper". I really don't like it because you are encouraging people just to skim or even skip it at all and not get interested with the story. I earned this achievement on a 2nd run but I had a friend who just skipped it all on her 1st try.What devs should encourage is for the gamers to have a lot of playing time on their game so they would recommend it to others and not just do it for the cards and uninstalling it afterwards.

Most of the projects here are the kind that might be fun to make but shortly end up in the trash (like: animals made out of toilet paper tubes, a Paper plate ring toss game, A necklace made of colored plastic straws...)

The label and input were confused with body text, especially in dense compositions.

In my opinion, the W3C definition is unnecessarily confusing and restrictive. The dictionary definition of aside is "a temporary departure from a main theme or topic", and the spec should just stick to that, rather than introducing subtle distinctions.

The movement speed is painfully slow. There's nothing to do on your way.

Fortunately for fans of high quality puzzle games, RUSH is anything but simple.

why do you guys think have_css matcher is named the way it is? I mean, it sure deals with css identifiers, but have_css gives(at least to me) the impression that the page has certain stylesheet loading.

I think the issues/problems specified in the comments are not present with a Hash-only implementation. :) I would be supportive of re-considering this feature just for use with a Hash, where I believe 80% of the real-life use cases would (and do) exist. I have encountered this need before in the wild, but not with Arrays.

I like this approach more because I can scan the code that renders the Box component and easily spot that it takes two children. If the Box took any props, they'd be within the opening <Box> tag, and they would be distinct from any children props.

One gripe I've had with this approach is that you lose the visual cues that you're passing children into the Box component; they now aren't nested within the Box when you render them like we're used to in HTML; it's now up to you to read the props and spot which ones are being used to provide children.

this is so stupid (that there is no sensible way to run a Desktop file from the terminal)

If I do gnome-open foo.desktop it simply opens foo.desktop as a text file. If I make it executable and then run it in bash it simply fails (which is expected, it's clearly not bash script). EDIT: Doing exec /fullpath/foo.desktop gives me a Permission denied message, even if I change ownership to myself. If I make executable and do the same command, the terminal tab I'm using simply closes (I'm guessing it crashes). Finally, if I do sudo exec /fullpath/foo.desktop, I get an error reporting sudo: exec: command not found.

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

if we can fix source maps, unconditionally adding ";\n" would be a better solution

If the bug is still there I think that it is better if it is open so others can find it if they run into the same issue.

Webshim is opinionated, that a developer should always solve a problem the HTML5 way.

Another thing I don’t like is the name of the config file manifest.js. Internally Sprockets has the concept of a manifest already Sprockets::Manifest, but the two aren’t directly coupled. We also already have a “manifest” JSON file that gets generated in public/assets/ and has manifest in the name .Sprockets-manifest-140998229eec5a9a5802b31d0ef6ed25.json. I know one is a JS file and one is a JSON file, but it’s a bit confusing to talk about.

The link name is not very helpful, it doesn’t explain what it does very well.

What this means is: I better refrain from writing a new book and we rather focus on more and better docs.

@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

If you compare the code of Reform and the code of ActiveForm-Rails, I think the last is more simple and clear for a behavior similar (or better).

While there is some precedence in other frameworks for using as, the word doesn't fit well. Since you are adding functionality to elements I like the word add better (and it only has 1 more character).

But what all frameworks have in common is to write JS and this could convince users of React but also newcomers that know JS.