144 Matching Annotations
  1. Jun 2021
    1. GitLab is transitioning from controller specs to request specs.
    2. These tests should be isolated as much as possible. For example, model methods that don’t do anything with the database shouldn’t need a DB record. Classes that don’t need database records should use stubs/doubles as much as possible.
    1. A common cause of a large number of created factories is factory cascades, which result when factories create and recreate associations.
    2. :js is particularly important to avoid. This must only be used if the feature test requires JavaScript reactivity in the browser. Using a headless browser is much slower than parsing the HTML response from the app.
    3. Use Factory Doctor to find cases where database persistence is not needed in a given test.
  2. May 2021
    1. They have to ask you the dumb questions, either because their employer demands they do, or sometimes because their computer system doesn't let them get to the next part of the script unless they play ball.
    2. Another will employ smart people who apologise to you profusely for having to go through all the pointless steps, but that's just what they have to do!
    1. CommonJS has served us well for many years, but ESM comes with many benefits, like language-level syntax, browser support, defaults to strict mode, async loading, top-level await, improved static analysis & tree-shaking, and more.
  3. Apr 2021
    1. Lumberjack 1.0 had a concept of a unit of work id that could be used to tie log messages together. This has been replaced by tags. There is still an implementation of Lumberjack.unit_of_work, but it is just a wrapper on the tag implementation.
    1. What you want is not to detect if stdin is a pipe, but if stdin/stdout is a terminal.

      The OP wasn't wrong in exactly the way this comment implies: he didn't just ask how to detect whether stdin is a pipe. The OP actaully asked how to detect whether it is a terminal or a pipe. The only mistake he made, then, was in assuming those were the only two possible alternatives, when in fact there is (apparently) a 3rd one: that stdin is redirected from a file (not sure why the OS would need to treat that any differently from a pipe/stream but apparently it does).

      This omission is answered/corrected more clearly here:

      stdin can be a pipe or redirected from a file. Better to check if it is interactive than to check if it is not.

    2. stdin can be a pipe or redirected from a file. Better to check if it is interactive than to check if it is not.
    1. Factory FunNER is the sequel and a very solid improvement to Factory Fun. It uses hexes instead of squares to allow more creative building, and some subtle improvements to scoring, length, and machine placement rules really improve things.
    1. Now that we’ve gotten newer layout features — again, like grid and flexbox — floats, too, have sort of fallen by the wayside, perhaps either because there are better ways to accomplish what they do
  4. Mar 2021
    1. My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

      first sighting: That <template>/<slot> is part of HTML standard and the reason Svelte uses similar/same syntax is probably because it was trying to make it match / based on that syntax (as they did with other areas of the syntax, some of it even JS/JSX-like, but more leaning towards HTML-like) so that it's familiar and consistent across platforms.

    2. Svelte is different in that by default most of your code is only going to run once; a console.log('foo') line in a component will only run when that component is first rendered.
    1. One thing that would be useful to this debate an analysis of a language ecosystem where there are only "macropackages" and see if the same function shows up over and over again across packages.
  5. Feb 2021
    1. That’s it. If you have a previous “precompile” array, in your app config, it will continue to work. For continuity sake I recommend moving over those declarations to your manifest.js file so that it will be consistent.
    2. Instead of having this confusing maze of lambdas, regexes, and strings, we could, in theory, introduce a single entry point of configuration for Sprockets to use, and in that file declare all assets we wanted to compile. Well, that’s exactly what the manifest.js file is.
    1. You’re allowed to blame us for a terrible developer experience in Trailblazer 2.0. It’s been quite painful to find out which step caused an exception. However, don’t look back in anger! We’ve spent a lot of time on working out a beautiful way for both tracing and debugging Trailblazer activities in 2.1.
    1. The activity gem is an extraction from Trailblazer 2.0, where we only had operations. Operations expose a linear flow which goes into one direction, only. While this was a massive improvement over messily nested code, we soon decided it’s cool being able to model non-linear flows. This is why activities are the major concept since Trailblazer 2.1.
    1. 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.
    1. Yes, Trailblazer is adding new abstractions and concepts and they are different to the 90s-Ruby, but now, at the latest, it becomes obvious how this improves the developing process. We’re no longer talking in two-dimensional method stack traces or byebug hoops, the language and conception is changing to the actual higher level code flow, to activities sitting in activities structured into smaller step units.
    2. We removed the trailblazer-loader gem just like Apple removed the headphone jack from the iPhone 6. This brings you faster startup and consistency with Rails autoloading.
    1. ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.
    2. 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. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website. This became painfully apparent when we noticed other people post OpenTTD on some stores. They are not always updated with new releases, sometimes even slacking behind a few years. And maybe more important to us: we can not guarantee that the uploaded version is unmodified and is the version as we intended. So, instead of fighting it, why not turn around and join them! Why not release our own, verified, builds on those stores! And this is exactly what we have been working on lately. And when I say “we”, a bit ironic to me, I mean the two developers that are around longest (myself and orudge) ;) A while back orudge added OpenTTD to the Microsoft Store. And today, I am happy to announce we will be on SteamE too! Well, we are on Steam, but we haven’t released anything there yet (sorry that I got your hopes up, just to squash them right after :( ). This is partially because of how Steam works, but also because we know we can bring a better experience for Steam with our upcoming release. That brings me to the most exciting news: if everything goes as planned, we will release OpenTTD 1.11 on Steam on the first of April, 2021! And that is not even an April fools’ joke! You can already Wishlist OpenTTD today .. and till we release on Steam, you can find our game via our website ;)
    1. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website.
    1. Well, I'm glad they did, because Turbolinks is a much better piece of software than jquery-pjax ever was. It's actively maintained and doesn't require jQuery at all! So we're one step closer to our dream of ditching $.
    2. 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.
  6. Dec 2020
    1. People really don't stress enough the importance of enjoying what you're programming. It aids creativity, makes you a better teammate, and makes it significantly easier to enter a state of flow. It should be considered an important factor in choosing a web development framework (or lack thereof). Kudos!
  7. Nov 2020
    1. There was a major refactoring in the resolver (https://github.com/webpack/enhanced-resolve). This means the resolving option were changed too. Mostly simplification and changes that make it more unlikely to configure it incorrectly.
    1. {#key} was introduced in Svelte v3.28, before that you needed to use a keyed {#each} block with only one item When the key changes, svelte removes the component and adds a new one, therefor triggering the transition.
    1. Svelte's advantage here is that it indicates the need for an update at the place where the associated data is updated, instead of at each place the data is used. Then each template expression of reactive statement is able to check very quickly if it needs to rerender or not.
    2. Svelte slots are much easier to use and reason about than Angular transclude, especially in cases where you don't want an extra wrapper element around the slot content.
    1. If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
  8. Oct 2020
    1. Instead of this, you can use a File type variable.
    2. Previously, a common pattern was to read the value of a CI variable, save it in a file, and then use that file in your script:
    1. 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.
    2. Svelte doesn't re-render, so you need to respond to component mount/dismount and prop changes separately as they are distinct concepts and never tied together, unlike in React.
    3. While react hooks were one of the catalysts for v3 we don't agree with with the APIs or the model and won't be emulating it.
    1. Note how we have to duplicate the code between these two lifecycle methods in class. This is because in many cases we want to perform the same side effect regardless of whether the component just mounted, or if it has been updated. Conceptually, we want it to happen after every render — but React class components don’t have a method like this. We could extract a separate method but we would still have to call it in two places.
  9. Sep 2020
    1. Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
    2. The main rationale for this PR is that, in my hones opinion, Svelte needs a way to support style overrides in an intuitive and close to plain HTML/CSS way. What I regard as intuitive is: Looking at how customizing of styles is being done when applying a typical CSS component framework, and making that possible with Svelte.
    1. The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)
    2. I'll work on a preliminary PR (which I expect will need some love from maintainers, sorry!)
  10. Aug 2020
    1. For example, to search for text occurrences, I used ack-grep. Later on, I found that there is a faster approach using ag. Then, there is an even faster alternative called ripgrep.
    1. If you are a senior, try talking to a junior or someone less experienced than you. Many companies are running what is called ”reverse mentoring” programs where juniors coach senior members of a company. Senior’s experience is traded for a fresh perspective from a junior. You’d be amazed at how much you could learn and share.
  11. Jul 2020
    1. Creating and calling a default proc is a waste of time, and Cramming everything into one line using tortured constructs doesn't make the code more efficient--it just makes the code harder to understand.

      The nature of this "answer" is a comment in response to another answer. But because of the limitations SO puts on comments (very short length, no multi-line code snippets), comment feature could not actually be used, so this user resorted to "abusing" answer feature to post their comment instead.


  12. Jun 2020
  13. May 2020
    1. “Make it work” means shipping something that doesn’t break. The code might be ugly and difficult to understand, but we’re delivering value to the customer and we have tests that give us confidence. Without tests, it’s hard to answer “Does this work?”
    1. The administration and its allies fear that the more people gravitate toward the successful, free-market self-insurance approach, the worse their government-engineered health “reform” will look. We’re already seeing the beginning of this trend.
    1. This is it. I'm done with Page Translator, but you don't have to be. Fork the repo. Distribute the code yourself. This is now a cat-and-mouse game with Mozilla. Users will have to jump from one extension to another until language translation is a standard feature or the extension policy changes.
    2. Mozilla will never publicly ask users to circumvent their own blocklist. But it's their actions that are forcing people to do so.
    3. So to me, it seems like they want to keep their users safer by... making them use Google Chrome or... exposing themselves to even greater danger by disabling the whole blocklist.
  14. Mar 2020
    1. Q. Why does Rubinius not support frozen and tainted? A. Rubinius has better features; frozen and tainted are considered harmful. To elaborate... Both frozen and tainted depend on strewing checks throughout the source code. As a classic weak-link system, only one of those checks needs to be misplaced for the guarantees offered by either to fail. Since the number of checks is high, and as new code is written new checks need to be considered, the features inherently constitute unbounded complexity and unbounded risk.
    1. For several reasons the Simple backend shipped with Active Support only does the "simplest thing that could possibly work" for Ruby on Rails3 ... which means that it is only guaranteed to work for English and, as a side effect, languages that are very similar to English. Also, the simple backend is only capable of reading translations but cannot dynamically store them to any format.That does not mean you're stuck with these limitations, though. The Ruby I18n gem makes it very easy to exchange the Simple backend implementation with something else that fits better for your needs, by passing a backend instance to the I18n.backend= setter.
  15. Jan 2020
    1. Your idea should stem from solving someone’s problem. Ideally, your own problem. It’s important that you choose an idea which interests you. Interest is key to fuelling motivation which is crucial when making a web app. It takes effort building web apps and it’s important you have fun during the process.
  16. Dec 2019
    1. Confusingly, all the distributions I use (Ubuntu, RHEL and Cygwin) had some type of check (testing $- or $PS1) to ensure the current shell is interactive. I don’t like cargo cult programming so I set about understanding the purpose of this code in my .bashrc.
    1. No, clumsily working around the root account in situations where it is absolutely appropriate to use it is not for good reasons. This is just another form of cargo cult programming - you don't really understand the concept behind sudo vs root, you just blindly apply the belief "root is bad, sudo is good" because you've read that somewhere.
    1. Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose.