125 Matching Annotations
  1. Jul 2021
  2. Jun 2021
    1. I wouldn't consider it switching behavior. Ultimately it's including a module -- either a manually defined and referenced one from the user, or a RSpec::Core::SharedExampleGroupModule created for the user when they defined the shared example group and referenced via the group name.
    1. “The data does not exist independently in the world, nor is it generated spontaneously. Data is constructed by people, from people,” (source 1).
    1. I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.
    2. 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.
    1. And, if you think about it, only the pointy ones are used un-paired in regex construct's. All the other pairs are balanced. I'd steer clear of that pair <>
    1. We need to be really careful about what's 'same origin' because the server has no idea what host/path the various cookies are associated with. It just has a list of cookies that the browser had determined to be relevant for this SSR'd page, and not for any other subrequests.
  3. May 2021
    1. I like the idea in theory, however it doesn’t feel very robust – you are relying on the layout of the page in question. Many authors regularly revisit articles and add new sections and paragraphs. Now your #h2:3 link points to a previous section. (This is far less likely to happen with IDs.)
    2. Linking directly to someone’s blog comment is very useful. Even if a blog doesn’t have an active link for each comment, it’s pretty easy to use developer tools to find the comment’s id and link to it. I’ve done this many times on Smashing Magazine (they don’t have live links on each comment). If there was no way to link to an individual blog comment, this would be a great hindrance to linking on the web. It would not be enough to link to the “#comments” section and then hope for the best. So CMSs like WordPress do the right thing by dynamically adding a unique identifier to each comment.
    3. 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.
    4. Yes, the content creator should have the ability to decide how a page is generally divided, if they choose to do so. But the end user should not be restricted from linking to content fragments just because a developer couldn’t be bothered to add id attributes to every element on the page. And that’s besides the fact that it would be a waste of time for a developer to do that or to have to build a CMS that does it automatically.
    5. The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

      at the mercy of author

    6. So why is it up to the developer (or content creator) to define whether or not a specific portion of the content can be linked to? When any page of content is created, there is no way of knowing which sections of the page are worthy of being identified.
    1. Making effective use of this mechanism requires either control of the targeted document or generous creators of targeted documents who have liberally applied id attributes throughout a document.

      unlikely for anyone/most people to actually do that

    1. They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.

      forces you to read before deciding

  4. Apr 2021
    1. From a practical point of view it's highly desirable to specify them to prevent page reflows as mentioned above. However those suggesting it should be in the html because of this are missing the fact browsers use css when building the page initially. If they didn't the page would have to be redrawn for floated elements, specified padding, margins etc.
    2. CSS seems like the right place to put visual information. On the other hand, few would argue that image "src" should not be specified as an attribute and the height/width seem as tied to the binary image data as the "src" is.
    1. “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!).
    1. I actually think this is Not Constructive, since there's no absolute rule about which pairings can be joined into a single word or hyhenated, and it's pointless having "votes" here about each specific case. Follow a style guide if you have one, or search Google Books and copy whatever the majority do. Or just make your own decision.
  5. Mar 2021
    1. The hierarchical structure of semantic fields can be mostly seen in hyponymy.

      Good explanation about semantic fields.

      I assume the same or an even stronger statement can be made about semantic classes (which to me are like more clear-cut, distinct semantic fields), then? 

    1. Some types exist as descriptions of objects, but not as tangible physical objects. One can show someone a particular bicycle, but cannot show someone, explicitly, the type "bicycle", as in "the bicycle is popular."
    1. However, if the distinctions between the two concepts appear to be superficial, intentional conflation may be desirable for the sake of conciseness and recall
    1. Dictionary writers list polysemes under the same entry; homonyms are defined separately.

      This describes how you can tell which one it is by looking at the dictionary entry.

    2. Polysemy is thus distinct from homonymy—or homophony—which is an accidental similarity between two words (such as bear the animal, and the verb to bear); while homonymy is often a mere linguistic coincidence, polysemy is not.
    1. vim-athena doesn't depend on or use any version of GTK+. If you use sudo apt-get build-dep vim-athena, it probably will install GTK+ and GNOME related libraries, because the vim-athena binary package is built from the same source package as vim and other vim-providing packages. In any case, you shouldn't need to build from source, as the binaries provided by vim-athena are already built against Athena and not against GTK+ or other graphical toolkits.
    2. If you built vim against Qt rather than GTK+ and python-complete still isn't working, that suggests the problem isn't actually a consequence of trying to link to both GTK+2 and GTK+3.
    1. This issue hasn’t been deemed a high enough priority to be fixed yet. It will be addressed one day, I’m sure. There are many issues in GLib which many people on the internet think are important.
    1. The absence of a method name here is per design: this object does only one thing, and hence what it does is reflected in the class name.
  6. Feb 2021
    1. Do you have collaborators who could have generated keys and sold them on their own? DIG's Steam keys and other stores' Steam keys must have some source, after all. Keys don't generate themselves, and only your accounts should be able to request them.This particular game was in Bunch Keys Indie Wizardry Bundle. I assume you had a proper contract for that. Maybe DIG or an intermediary bought 50-200 copies of it?
    2. It isn't stealing because you or an associate must have generated and given them the keys in some way or another?Ideally you would ask a DIG bundle buyer to show you their key for your game, so you can figure out what key request batch it came from, and then you can scratch your head and wonder who you gave those keys to and what journey they took afterwards.
    1. Regardless of origin, allow/deny are simply clearer terms that does not require tracing the history of black/white as representations of that meaning. We can simply use the meaning directly.
    1. In the telecommunications industry, on a conceptual level, value-added services add value to the standard service offering, spurring subscribers to use their phone more and allowing the operator to drive up their average revenue per user.
    1. note that TRB source code modifications are not proprietary

      In other words, you can build on this software in your proprietary software but can't change the Trailblazer source unless you're willing to contribute it back.

      loophole: I wonder if this will actually just push people to move their code -- which at the core is/would be a direction modification to the source code - out to a separate module. That's so easy to do with Ruby, so this restriction hardly seems like it would have any effect on encouraging contributions.

    1. There are times where it is useful to know whether a value was passed to run or the result of a filter default. In particular, it is useful when nil is an acceptable value.

      Yes! An illustration in ruby:

      main > h = {key_with_nil_value: nil}
      => {:key_with_nil_value=>nil}
      
      main > h[:key_with_nil_value]
      => nil
      
      main > h[:missing_key]  # this would be undefined in JavaScript (a useful distinction) rather than null, but in Ruby it's indistinguishable from the case where a nil value was actually explicitly _supplied_ by the caller/user
      => nil
      
      # so we have to check for "missingness" ("undefinedness"?) differently in Ruby
      
      main > h.key?(:key_with_nil_value)
      => true
      
      main > h.key?(:missing_key)
      => false
      

      This is one unfortunate side effect of Ruby having only nil and no built-in way to distinguish between null and undefined like in JavaScript.

    2. Inside the interaction, we could use #find instead of #find_by_id. That way we wouldn't need the #find_account! helper method in the controller because the error would bubble all the way up. However, you should try to avoid raising errors from interactions. If you do, you'll have to deal with raised exceptions as well as the validity of the outcome.

      What they're referring to:

      Account.find('invalid') will raise an error but Account.find_by(id: 'invalid') will not.

    3. For this one we'll define a helper method to handle raising the correct errors. We have to do this because calling .run! would raise an ActiveInteraction::InvalidInteractionError instead of an ActiveRecord::RecordNotFound. That means Rails would render a 500 instead of a 404.

      True, but why couldn't it handle this for us?

    1. My understanding of "programming to an interface" is different than what the question or the other answers suggest. Which is not to say that my understanding is correct, or that the things in the other answers aren't good ideas, just that they're not what I think of when I hear that term.
    2. If the program was important enough, Microsoft might actually go ahead and add some hack to their implementation so the the program would continue to work, but the cost of that is increased complexity (with all the ensuing problems) of the Windows code. It also makes life extra-hard for the Wine people, because they try to implement the WinAPI as well, but they can only refer to the documentation for how to do this, which leads to many programs not working as they should because they (accidentally or intentionally) rely on some implementation detail.
    1. Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods.
    1. 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.
    2. If we renamed things more often, then it probably wouldn’t be so hard to name them in the first place.
    3. This is funny because it’s unexpected. Cache invalidation sounds like a hard thing, while naming sounds more straightforward. The joke works because it violates our expectation that hard things should be technical. It’s also funny because it’s true.
    1. Now let me ask you, do you write JS for a single page application differently from a "traditional" web application? I sure hope you do! In a "traditional" application, you can get away with being sloppy because every time the user navigates to a new page, their browser destroys the DOM and the JavaScript context. SPAs, though, require a more thoughtful approach.
    1. When people talk about "beginner distros" they mean distros that are no hassle to get started, it doesnt mean they are somewhat inferior or less capable.
  7. Jan 2021
    1. This is a dynamic value because of hybrid devices which can use a mix of mouse and touch input.
    1. if you set text-decoration: underline for all links then you will have to set text-decoration: none for special links which you don't need an underline.
    1. It’s all very well telling Canonical what to do, but someone needs to pay those developers for their time. It’s not free.
    2. Repeatedly posting in this thread that there are problems, won’t actually get anything fixed.
    3. The best place to let the developers know, and track those bugs is in the bug tracker. There are hundreds of forums online, all over the place in many languages. We can’t be expected to read all of them. Anyone with a launchpad ID (thus, anyone who has an account on this discourse instance) has the capability to file a bug. I’d strongly recommend doing so, for each specific issue. Taking just a few minutes to do that will help tremendously.
    4. 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.
    5. 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.
    6. Only folks who help package Chromium get to decide how Chromium gets packaged. This gives anyone two options: You can get involved and help package Chromium so you have a voice in the decision-making, or not.
    1. We can lay blame for this semantic drift squarely at the feet of trend. Designers and developers eager to try the latest and greatest invite ambiguity in with outstretched arms. Leadership chases perceived value to stay relevant.
    2. However, the W3C provides us with an important clue as to who is right: the download attribute.
    3. The debate about whether a button or link should be used to download a file is a bit silly, as the whole purpose of a link has always been to download content. HTML is a file, and like all other files, it needs to be retrieved from a server and downloaded before it can be presented to a user. The difference between a Photoshop file, HTML, and other understood media files, is that a browser automatically displays the latter two. If one were to link to a Photoshop .psd file, the browser would initiate a document change to render the file, likely be all like, “lol wut?” and then just initiate the OS download prompt. The confusion seems to come from developers getting super literal with the “links go places, buttons perform actions.” Yes, that is true, but links don’t actually go anywhere. They retrieve information and download it. Buttons perform actions, but they don’t inherently “get” documents. While they can be used to get data, it’s often to change state of a current document, not to retrieve and render a new one. They can get data, in regards to the functionality of forms, but it continues to be within the context of updating a web document, not downloading an individual file. Long story short, the download attribute is unique to anchor links for a reason. download augments the inherent functionality of the link retrieving data. It side steps the attempt to render the file in the browser and instead says, “You know what? I’m just going to save this for later…”
  8. Dec 2020
    1. 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.

      tag?: what scope of provided features / recommended happy path is needed?

  9. Nov 2020
    1. Svelte by itself is great, but doing a complete PWA (with service workers, etc) that runs and scales on multiple devices with high quality app-like UI controls quickly gets complex. Flutter just provides much better tooling for that out of the box IMO. You are not molding a website into an app, you are just building an app. If I was building a relatively simple web app that is only meant to run on the web, then I might still prefer Svelte in some cases.
    1. 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.
    1. is not required to point to "svelte": "src/main.html" if you're bundling for es, "module": "dist/main.mjs" would suffice. I mean, it's a good thing to provide a single file, not the whole sources again.
    1. Man, for some reason, I really like this answer. I recognize it's a bit more complicated, but it seems so useful. And given that I'm no bash expert, it leads me to believe that my logic is faulty, and there's something wrong with this methodology, otherwise, I feel others would have given it more praise. So, what's the problem with this function? Is there anything I should be looking out for here?

      I think the main thing wrong with it is the eval (which I think can be changed to $("$@") and it's pretty verbose.

      Also, there are more concise ways to do it that would probably appeal more to most bash experts...

      like set -x

      and it does unnecessary things: why save output to a variable? Just let output go to where it would normally go...

      So yeah, I can see why this solution isn't very popular. And I'm rather surprised by all the praise comments it's gotten.

    1. I wondered about that. But as you mention, the control flow makes it tricky, because it's not really a template literal — it's a DSL. I thought perhaps it's better to have something that's explicitly different, than something a bit 'uncanny valley'.
  10. Oct 2020
    1. There are contradicting definitions: "dependence: one that is relied on", "dependency: something that is dependent on something else", "dependent: one that is dependent" which also says "archaic : DEPENDENCY" which is certainly the inverse of what is usually meant in technology... is it more correct to install the "dependences"? (wiktionary gives it as the plural)
    1. I'm afraid there's only so much the docs & tutorials can do about something like this actually. When you first read them, you don't get Svelte well enough (since you're reading a tutorial...) for this to make sense to you. Then you try something, encounter a behaviour, question it, understand better... That's learning.
    1. Could you please explain why it is a vulnerability for an attacker to know the user names on a system? Currently External Identity Providers are wildly popular, meaning that user names are personal emails.My amazon account is my email address, my Azure account is my email address and both sites manage highly valuable information that could take a whole company out of business... and yet, they show no concern on hiding user names...

      Good question: Why do the big players like Azure not seem to worry? Microsoft, Amazon, Google, etc. too probably. In fact, any email provider. So once someone knows your email address, you are (more) vulnerable to someone trying to hack your account. Makes me wonder if the severity of this problem is overrated.

      Irony: He (using his full real name) posts:

      1. Information about which account ("my Azure account is my email address"), and
      2. How high-value of a target he would be ("both sites manage highly valuable information that could take a whole company out of business...")

      thus making himself more of a target. (I hope he does not get targetted though.)

    1. One of Svelte's advantages, for me, is that I can test out ideas with relatively few lines of code. the #with feature could save me from adding a separate component for the content of an #each loop. I get frustrated when I have to create a new file, move the content of the #each clause, import it as a component, and add attributes and create exports for that, and implement events to send messages back, and event handlers, when I just wanted to test a small feature.
    1. JavaScript is, of course, a dynamic language that allows you to add and remove objects and their members at any point in time. For many, this is precisely why they enjoy the language: there are very few constraints imposed by the language.
    1. Just like elements can have children... <div> <p>I'm a child of the div</p> </div>...so can components. Before a component can accept children, though, it needs to know where to put them. We do this with the <slot> element.
    1. 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.
    2. Template literals work well for long embedded DSLs. Unfortunately the syntax noise is substantial when you exit in and out of embedded arbitrary ECMAScript expressions with identifiers in scope.
    1. 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.
    2. This is exactly why I'm in favor of @const. Helpers are fine, except when they're not and turn into boilerplate.
    3. Right, because those are the only 3 instances where new "scopes" are created, which means you're seeing data for (probably) the first time.

      good point: means you're seeing data for (probably) the first time.

    4. I like this, mostly because it allows me to write small components without creating another separate sub-component for holding the value simple computation. I get annoyed every time I need to create a component just to hold a variable, or even move the computation away from the relevant location. It reminds me of the days where variables in C had to be declared at the top of the function.
    1. Putting a browserlist in the project will send a false signal to users. Svelte is only a lib, not an application. The consumer / implementer will have to decide what level of support he wants, according to its constraints/userbase and adjust its build process and polyfills implementation.
  11. Sep 2020
    1. A lot of instructions I read say things like npm install niftycommand and then niftycommand. But this will never work unless you have ./node_modules/.bin in your path, will it?
    1. Yes, they do but none of them allow arbitrary javascript anywhere in the template it is finely controlled. This deviates from that, in fact that is it's defining feature.
    1. We should also allow passing unrecognised props to the rendered component. eg: tabindex might be required on some instances of a component, and not all. Why should developers have to add tabindex support to their components just that it may potentially be used

      Glad to hear this is solved now: $restProps

    2. The language should work for developers, not the other way around.
    1. Adding my 2 cents to the discussion. Adding a class prop to a component doesn't necessarily mean it should apply the style to the root element, but it makes sense that it should apply it the main element visually. Let's take a modal component as an example.
    2. You're not trying to pass a class to a dom element. You're passing a class to a component. It's up to the component to define what that means for the components use case. In most cases it would be passed to a dom element.
    1. I don’t want my source to be human-readable, not for protective reasons, but because I care about web performance more. I want my website to arrive at light speed on a tiny spec of magical network packet dust and blossom into a complete website. Or do whatever computer science deems is the absolute fastest way to send website data between computers. I’m much more worried about the state of web performance than I am about web education. But even if I was very worried about web education, I don’t think it’s the network’s job to deliver teachability
  12. Aug 2020
    1. I think the conjugation is particularly helpful to see why it should be two separate words: "log in" -> "logging in" -> "logged in"
    2. You can also think about each one with the way we stress the different syllables slightly when we're speaking: "log in to host.com" sounds like "log + in + to host.com" (each word is pretty much evenly stressed) "log into host.com" sounds like "log + INto host.com" (the stress is on "in") "login to host.com" sounds like "LOGin + to host.com" (the stress is on "log")

      I wouldn't have thought about using the way we pronounce it to make a point about grammar, but somehow it seems to help slightly to make the point.

  13. Jul 2020
    1. It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.
  14. Jun 2020
  15. May 2020
  16. Apr 2020
    1. I think it's useful to differentiate especially because there are many situations where "hack", and its conjugations, is the only effective term to describe something that has nothing to do with malicious violation of security measures or privacy.
  17. Mar 2020
    1. The whole point of not relying on debt excessively in normal times is precisely to be able to use debt massively and without hesitation in situations like this.