810 Matching Annotations
  1. Feb 2021
    1. So every program starts in the IO monad. From here you can get any input you need, call into relatively "pure" code with the inputs, and then output the result in some way. The reverse does not work. You cannot call into IO code from pure code like you can call into a Maybe function from pure code.
    1. it is inconvenient to write specific implementations for each datatype contained, especially if the code for each datatype is virtually identical. For example, in C++, this duplication of code can be circumvented by defining a class template
    1. which entails computer programming (process of writing and maintaining the source code), but also encompasses a planned and structured process from the conception of the desired software to its final manifestation
    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. In Trailblazer, models are completely empty. They solely contain associations and finders. No business logic is allowed in models.
    2. The bare bones operation without any Trailblazery is implemented in the trailblazer-operation gem and can be used without our stack.
    3. While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
    4. Only use what you like.
    5. you can pick which layers you want. Trailblazer doesn't impose technical implementations
    1. stolen love from the child and infant and made it the exclusive property of the adolescent and adult

      Love is not exclusive to adults and adolescents as there are many types of love. I do not believe it has been stolen but added to love in general.

    1. Since we're using an interaction, we don't need strong parameters. The interaction will ignore any inputs that weren't defined by filters. So you can forget about params.require and params.permit because interactions handle that for you.
    1. The great thing about working with reinteractive is you get to work directly with the developers, which is a huge plus. As a technical founder, I find proxying through a project manager adds unnecessary layers of complexity and creates opportunity for human error.
    1. By explicitly defining the form layout using ::property there is no more need for protecting from unwanted input. strong_parameter or attr_accessible become obsolete. Reform will simply ignore undefined incoming parameters.
    1. Any attribute in the list will be allowed, and any defined as attr_{accessor,reader,writer} will not be populated when passed in as params. This means we no longer need to use strong_params in the controllers because the form has a clear definition of what it expects and protects us by design.

      strong params not needed since form object handles that responsibility.

      That's the same opinion Nick took in Reform...

    1. We got this email from Parabo, the print shop app, and smiled. Instead of the very standard “Please confirm subscription” header text, we were greeted with a funny, whimsical hello that’s totally in their brand voice. “We really want you to want us” is a clever way to break up the usual mundane greeting, and, guess what? It totally reaffirmed why we thought we wanted to sign up for their emails in the first place.
    1. If you teach your users to trust that URL bar is supposed to not change when they click links (e.g. your site uses a big iframe with all the actual content), then the users will not notice anything in the future either in case of actual security vulnerability.
    2. And if there's a suitable vulnerability, it might be possible to trigger it even without using <iframe>, <img> or <a> element, so it's not worth considering for this issue.
  2. Jan 2021
    1. Slackmojis is made by some random dude in Brooklyn. He doesn't work for Slack, isn't paid by Slack, he just thinks Slack is pretty cool. Super Official Lawyer Talk: Slackmojis is not created by, affiliated with, or supported by Slack Technologies, Inc.
    1. I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.
    2. Systemd problems might not have mattered that much, except that GNOME has a similar attitude; they only care for a small subset of the Linux desktop users, and they have historically abandoned some ways of interacting the Desktop in the interest of supporting touchscreen devices and to try to attract less technically sophisticated users. If you don't fall in the demographic of what GNOME supports, you're sadly out of luck.
    3. 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
    1. The Gmail Android app that comes pre-installed with most new Android phones contains a feature to access non-Google accounts using POP and IMAP. Unfortunately, emails accessed through this setup lack the embedded style (<style>) support as well as the support for background images.
    1. overflow-wrap: break-word; makes sure the long string will wrap and not bust out of the container. You might as well use word-wrap as well because as the spec says, they are literally just alternate names for each other. Some browsers support one and not the other.
    1. I can’t promise I’m explaining this 100% accurately, but the way I understand it, the minimum width of a grid column is auto.
    1. I've already said this, but if you think the average desktop computer user thinks a sentence beginning "I just make a chroot..." makes any kind of sense, you haven't been paying attention to the level of intelligence of the general public.
    2. Well, that user can safely stay with Windows. Hiding these things from me makes wish that.
    3. Linux on the desktop won't take off until it is equally easy. Snap may be dumbed down, restricted and all the rest of it, but for ordinary users it's easier - and more secure - than the alternative.
    4. if it's not broken, fix it until it is.
    1. While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or edited it to ensure you have an error-free learning experience. It's on our list, and we're working on it! You can help us out by using the "report an issue" button at the bottom of the tutorial.
    1. Popper for Svelte with actions, no wrapper components or component bindings required! Other Popper libraries for Svelte (including the official @popperjs/svelte library) use a wrapper component that takes the required DOM elements as props. Not only does this require multiple bind:this, you also have to pollute your script tag with multiple DOM references. We can do better with Svelte actions!
    1. However, one of the drawbacks of this property is that the line intersects descenders of the characters.

      I think it actually looks great/better because it intersects descenders of the characters.

    1. “JSONP is JSON with extra code” would be too easy for the real world. No, you gotta have little discrepancies. What’s the fun in programming if everything just works? Turns out JSON is not a subset of JavaScript. If all you do is take a JSON object and wrap it in a function call, one day you will be bitten by strange syntax errors, like I was today.
    1. On Ubuntu, Chromium is not the default browser, and the package resides in the ‘universe’ section of the archive.
    1. 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.
    2. 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.
    3. While you may have some objections due to your specific setup, please consider you’re not the usual use case. Most people install Ubuntu on a single drive, not separate /home, and not multiple disks. Most are quite happy with automatic updates - in line with how their phone is likely setup - both for debs (with unattended-upgrades) and snaps (via automatic refresh in snapd). Experts such as yourself are capable of managing your own system and are interested in twiddling knobs and adjusting settings everywhere. There are millions of Ubuntu users who are not like that. We should cater for the widest possible use case by default, and have the option to fiddle switches for experts, which is what we have.
    4. 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.
    5. We have consistently said that we cannot forsee the deb-based desktop going away. I still can’t see that happening. Debs are an integral part of the way the desktop is built. It’s just not feasible / desirable to make the desktop be “all snap”.
    6. When there are imperfections, we rely on users and our active community to tell us how the software is not working correctly, so we can fix it. The way we do that, and have done for 15 years now, is via bug reports. Discussion is great, but detailed bug reports are better for letting developers know what’s wrong.
    7. 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
    8. The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.
    9. But now Chromium is no more available as deb, so what to expect ?
    10. What’s the use of ie. snap libreoffice if it can’t access documents on a samba server in my workplace ? Should I really re-organize years of storage and work in my office for being able to use snap ? A too high price to pay, for the moment.
    11. Disk space is an issue. Resource usage is an issue. Those new packages nowadays need huge amount of storage to finally do the exact same thing as their older and lighter deb counterpart. Whatever the price of storage, it’s the opposite of a progress, it’s not optimal at all.
    1. They may skim books for what they’ll “need to know.” They’re less likely to wonder, say, “How can we be sure that’s true?” than to ask “Is this going to be on the test?”

      This is completely true! As a student we honestly do not care about anything, as long as our grade is an A. I hate that it is true, because sometimes as a student, I just want to really learn for a second. Although it is nearly impossible when pressured is applied based on a letter grade that may or may not affect one's life. This class is really helping realize that it is not me, is that pressure kills the beauty of learning.

    1. One lesser-appreciated user-behaviour is when a user would like to choose an alternative download location. On a download link, your user can right-click -> “save link as…” and place the download directly into a folder of their choice. Handy if you want something to go directly to removable media, for example. On a download button, there’s no such option.
  3. Dec 2020
  4. Nov 2020
    1. Notably, LLVM and JVM are by far the most prominent targets in this scenario: they’re both open-source and well-documented targets that provide a ton of firepower, and there frankly aren’t a ton of other options.
    1. If the client JS is disabled, then handleSubmit will never be executed and you have to care that your /api/fakeBackendRoute will handle the data exactly how the client would.
    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. Fallback values aren't used to fix the browser compatibility. If the browser doesn't support CSS custom Properties, the fallback value won't help.
    1. There is no rerender, when you call listen, then all scroll events will warn on chrome. See this entry from svelte: breaking the web

      Even the author of this library forgot this about Svelte?? :) (Or maybe he didn't and this response misunderstood/falsely assumed that he had.)

    1. Many of you will not be able to use this if you depend on custom import types or other fancy loaders. This project is just not for you!
    1. I think what the author intended to do was check if the second argument was a non-empty string (which is not the same thing as checking whether there are more than 1 argument, as the second argument could be passed but be the empty string).
    1. In Rust, we use the "No New Rationale" rule, which says that the decision to merge (or not merge) an RFC is based only on rationale that was presented and debated in public. This avoids accidents where the community feels blindsided by a decision.
    2. I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this: new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging. the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state") the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments. assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented. All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)
    1. All browers handle 302 incorrectly. Chrome 30, IE10. It became the de facto incorrect implementation; that cannot be changed because so many web-sites issue mistakenly issue 302. In fact ASP.net MVC incorrectly issues 302, depending on the fact that browsers handle it incorrectly.
    1. But using internal api's is dangerous as these may change when you update svelte. If you decide to use this, add a line to your project Readme.md mentioning which internal api's you used and why. Try to write it using other methods when you can.
    1. This is Sass based, and therefore doesn't require Svelte components

      Just because we could make Svelte wrapper components for each Material typography [thing], doesn't mean we should.

      Compare:

      • material-ui [react] did make wrapper components for typography.

        • But why did they? Is there a technical reason why they couldn't just do what svelte-material-ui did (as in, something technical that Svelte empowers/allows?), or did they just not consider it?
      • svelte-material-ui did not.

        • And they were probably wise to not do so. Just reuse the existing work from the Material team so that there's less work for you to keep in sync and less chance of divergence.
    2. This is not an MDC Web component. It is an addition that SMUI provides.
    1. Feel free to subscribe to the issue (there's button in the right hand column) but do not comment unless you are adding value to the discussion. "Me too" and "+1" are not valuable, nor are use cases that have already been written in the comments (e.g., we know that you can't put <tr> or <dd> elements with a <div>).
    1. Note that when using sass (Dart Sass), synchronous compilation is twice as fast as asynchronous compilation by default, due to the overhead of asynchronous callbacks.

      If you consider using asynchronous to be an optimization, then this could be surprising.

    1. When you do import '../scss/application.scss', you're telling webpack to include application.scss in the build. This does not mean it's going to be compiled into your javascript, only that webpack now compiles and knows how to load this file.

      Not necessarily the case that importing something into a JS file means the thing being imported is also JS.

    1. Some of the verbs implemented by systemctl are designed to provide a high-level overview in a human readable format. All that information is available over dbus, and/or journalctl, systemctl show. We could provide that information in json format, but there's a second problem. Information and format of information printed by e.g. systemctl status is not stable. Since the output is not suitable for programmatic consumption anyway, there's no need to provide it in a machine readable format.
  5. Oct 2020
    1. In summary TLS uses PKI to secure information over the internet. However, it is important to note that TLS supports other encryption standards which are not part of PKI.
    1. Ok, I have seen that there are lot of built-in and third party validations, but sooner or later I will face a validation rule not covered by this buffet. Can I build a custom one? Of course you can!
    2. Of course you can start implementing your own thing, but you will waste a lot of precious time reinventing the wheel. Why not take advantage of a validation library that takes care of all this complexity for you?
    3. 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?
    1. Especially when rollup is configured with multiple outputs, I find this particular onwarn to be helpful in reducing warning clutter. It just displays each circular reference once and doesn't repeat the warning for each output:
    2. I think my personal preference would be to see them all at once. Or maybe limit it to up to 10 messages and then list the count of how many more messages were not displayed. Pick your reaction
    3. Another thing we could do to limit output would be to only every show the first circular dependency warning. I think we already do this for other types of warnings. Then you would need to tackle the warnings one-by-one, though.
    1. Why will you children insist on giving parties!”

      I doubt the children had much to do with this, consider Laura's apathy for the silly boys she dances with, or Laura's desire to end the party on the account of Scott, or how Jose felt it was too late to call it off, rather than feeling like she would be personally upset to call it off. These parties are the adults ideas, but Sheridan likely has trouble accepting such a vapid pass-time as worth while, her ego is a mess, because its such a pointless endeavor, and that's why she must convince herself that it's the children's idea.

    1. Note that these are not hyperlinks; these URIs are used for identification. This is a machine-readable way to say “this is HTML”. In particular, software does not usually need to fetch these resources, and certainly does not need to fetch the same one over and over!
    1. However, objects are generally easier to work with than maps, because not all JavaScript functions, frameworks, and libraries support maps. For example, the JSON.stringify() function doesn't serialize maps by default.
    1. just saying that if you're going to try to go with a markup approach, at least go all the way, instead of the frankenstein that is JSX
    2. I'm okay with an overall design that allows people to plugin the parts they need in order to be able to generically support a compile-to-javascript language, but to bake in support for one singular solution because its popular is simply bad engineering.
    3. Of all the compile-to-languages, the one that strikes me as having the least merit is JSX. It's basically a ton of added complexity for the sake of what boils down to syntax. There are no real gains in terms of language semantics in JSX.
    4. Yes, you can embed loops in it and compose lots of small repeated JSX snippets, but that almost never happens in practice because mixing the turing complete of javascript with the markup of HTML eliminates the readability of JSX so that it is actually harder to parse than a solution like hyperscript (the syntactical approach taken by virtual-dom).
    5. Without elegant ways of expressing loops/iterators (like angular does with directives), the primary way to keep JSX readable thus becomes copying and pasting.

      I'm not quite sure I understand this (so until I do, I'm not sure I agree)...

      Why does he think copying and pasting is the only way to make it readable? Like he pointed out, you can extract JSX snippets and use loops within JSX. But maybe he means (his previous point), that people often don't do that. Hmm. 

    6. The react community has become a big cargo cult. There are some good ideas in the community and many Bad Ideas™. Paving the bad idea cowpaths lends a sense of legitimacy to these bad technical ideas that is not merited.
    7. I agree that "it feels gross" is a bad reason. "not paving a bad cowpath" is a much better reason.
    8. hyperscript is much simpler to refactor and DRY up your code than with JSX, because, being vanilla javascript, its easier to work with variable assignment, loops and conditionals.
    9. The only "issue" it has is that its unfamiliar. People have been working with HTML for years and are comfortable with it. That's basically the only reason that people find it more readable. If you make an effort to spend sometime with hyperscript, it becomes as familiar and readable as jsx.
    1. Other frameworks, which use a template syntax built atop HTML — Svelte, Vue, Ractive, Glimmer etc — have historically been fragmented, meaning those tools need to be reinvented many times.
    1. Node doesn't have a DOM available. So in order to render HTML we use string concatenation instead. This has the fun benefit of being quite efficient, which in turn means it's great for server rendering!
    1. This is a very dangerous practice as each optimization means making assumptions. If you are compressing an image you make an assumption that some payload can be cut out without seriously affecting the quality, if you are adding a cache to your backend you assume that the API will return same results. A correct assumption allows you to spare resources. A false assumption introduces a bug in your app. That’s why optimizations should be done consciously.
    2. Moreover, React team even removed the “highlight updates” feature from dev tools because people used to obsessively haunt wasted renders with no reasoning behind it
    3. In the vast majority of cases there’s nothing wrong about wasted renders. They take so little resources that it is simply undetectable for a human eye. In fact, comparing each component’s props to its previous props shallowly (I’m not even talking about deeply) can be more resource extensive then simply re-rendering the entire subtree.
  6. Sep 2020
    1. Unfortunately, this only worked because of a feature called import elision. When TypeScript outputs JavaScript files, it sees that Options is only used as a type, and it automatically drops its import. The resulting output looks kind of like this:
    1. The onBlur function can take a SyntheticFocusEvent like it would if you had given it directly to an <input/> component, but you can also just call it: props.input.onBlur() to mark the field as blurred (inactive).
    1. You probably want initialValue! ⚠️ The value of the field upon creation. This value is only needed if you want your field be dirty upon creation (i.e. for its value to be different from its initial value).
    1. The problem I have with this approach to state and prop variables is that the difference between them is very blurry. In React you can clearly see that a prop is an input to component (because of clear function notation), and that state is something internal. In Svelte they are both just variables, with the exception that props use export keyword.

      This is something I've seen before: people noticing that Svelte is missing some kind of naming convention.

      React has use___ convention, for example. Without that, it makes it hard to see the difference between and know just from the name that a function is an (mentioned in the other article I read) action and not a event handler or even component, for example.