83 Matching Annotations
  1. Jul 2024
    1. When publicly distributed, the open-source code is hidden behind layers of indirection bypassing any packaging/integration effort, relying instead on virtualisation and downloading dependencies on the fly. Thanks to those strategies, corporations could benefit from open source code without any consequence. The open source code is, anyway, mostly hosted and developed on proprietary platforms.
  2. Jun 2024
    1. How can I wait for container X before starting Y? This is a common problem and in earlier versions of docker-compose requires the use of additional tools and scripts such as wait-for-it and dockerize. Using the healthcheck parameter the use of these additional tools and scripts is often no longer necessary.
  3. Oct 2023
  4. Sep 2023
  5. Feb 2023
    1. As a general practice, it seems like gems should remain compatible with current/recent versions of their dependencies. Otherwise, if you have 2 gems in your project that depend on faraday, and one of those is locked to faraday 0.17.6, and the other requires at least 2.x, then you have a problem...
  6. Dec 2022
    1. A container packages code and all its dependencies into a single unit, thus letting an application run quickly and reliably from one computing environment to another
    1. Compose V2 has been re-written in Go, which improves integration with other Docker command-line features, and allows it to run natively on macOS on Apple silicon, Windows, and Linux, without dependencies such as Python.
  7. Nov 2022
    1. For example, if using apt to install the main program for the image, be sure to pin it to a specific version (ex: ... apt-get install -y my-package=0.1.0 ...)
    2. Rebuilding the same Dockerfile should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a Dockerfile tagged as 0.1.0 doesn't end up containing 0.2.3.
    1. Unless you are the maintainer of lvh.me, you can not be sure it will not disappear or change its RRs for lvh.me. You can use localhost.localdomain instead of localhost, by adding the following lines in your hosts file: 127.0.0.1 localhost localhost.localdomain ::1 localhost localhost.localdomain This is better than using lvh.me because: you may not always have access to a DNS resolver, when developing
  8. Sep 2022
  9. Aug 2022
  10. Jan 2022
  11. Jul 2021
  12. Jun 2021
  13. May 2021
    1. The implicit dependencies between different versions of different services were not expressed anywhere, which led to various problems in building, continuous integration, and, notably, repeatable builds.
  14. Mar 2021
    1. this only applies to end products which are actually deployed. For my modules, I try to keep dependency version ranges at defaults, and recommend others do the same. All this pinning and packing is really the responsibility of the last user in the chain, and from experience, you will make their life significantly more difficult if you pin your own module dependencies.
    2. here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
    1. The elimination of what is arguably the biggest monoculture in the history of software development would mean that we, the community, could finally take charge of both languages and run-times, and start to iterate and grow these independently of browser/server platforms, vendors, and organizations, all pulling in different directions, struggling for control of standards, and (perhaps most importantly) freeing the entire community of developers from the group pressure of One Language To Rule Them All.
  15. Feb 2021
    1. Your Rails app Gemfile may have a line requiring sass-rails 5.0: gem 'sass-rails', '~> 5.0' # or gem 'sass-rails', '~> 5' These will prevent upgrade to sprockets 4, if you'd like to upgrade to sprockets 4 change to: gem 'sass-rails', '>= 5'
  16. Jan 2021
  17. Dec 2020
  18. Nov 2020
    1. If you rely on any external dependencies (files required in a preprocessor for example) you might want to watch these files for changes and re-run svelte compile. Webpack allows loader dependencies to trigger a recompile. svelte-loader exposes this API via options.externalDependencies.
    1. But then, I still want to upgrade my dependencies from time to time, in a painless way. I recommend checking Renovate which handles JavaScript and Ruby dependencies auto updating. Use it.
  19. Oct 2020
    1. A makefile works upon the principle that files only need recreating if their dependencies are newer than the file being created/recreated.
    1. In the context of software engineering, I've always used "dependent" and "dependee".
    2. 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)
    3. In the software industry we use "dependency" to refer to the relationship between two objects. We say "looking for dependents" for relationships to dependent things and "looking for dependencies" for relationships to prerequisite things, so it gets that connotation, but the literal meaning is the relationship itself, not the object. Finding a better word is exactly the point of the question
    4. I think it is still problematic since many people in the software industry use and understand "dependency" to mean the thing on which something depends (as indicated by this and other answers). So saying "being a dependency" indicates to those people the thing on which something depends, which is the opposite of the way I think of it (and what it means according to the dictionary).
    5. If you really mean "the thing depended upon", then Mr Disappointment's answer (dependency) is correct. If you mean the thing that depends on the dependency, then "dependent" ("dependant
    1. A simple Vue project can be run directly from a browser with no need of transpilation. This allows Vue to be easily dropped into a project the way jQuery is.While this is also technically possible with React, typical React code leans more heavily on JSX and on ES6 features like classes and non-mutating array methods.
  20. Sep 2020
    1. dependencies are the packages your project depends on. devDependencies are the packages that are needed during the development phase. Say a testing framework like Jest or other utilities like Babel or ESLint.
    1. Why include that six-line helper function when you can do a one-line `require`? Never mind that the required module has its own dependencies, with their own dependencies, until your users suddenly find that `npm install` involves downloading 70Mb of gubbins split into 15,000 files. I exaggerate, but barely.
    1. The other possible route would depend on #640 (dynamic components), plus the ability to pass around element names as strings in place of components, plus #195 (spread).
  21. Aug 2020
    1. The straightforward solution to integrate WPML with third party translation services was to do it via dedicated plugins. A separate plugin for each company offering translation services could do the trick. However, this approach had a few drawbacks. For example, WPML developers would need to update and test all these plugins whenever the WPML core plugins received an update, and vice versa; when the API used by the external service changed, you needed to incorporate the change to WPML and test it as well.
  22. Jul 2020
    1. While Rails supports numbering of initializer file names for load ordering purposes, a better technique is to place any code that need to load in a specific order within the same file. This reduces file name churn, makes dependencies more explicit, and can help surface new concepts within your application.
  23. May 2020
    1. In the examples below, we are using Docker images tags to specify a specific version, such as docker:19.03.8. If tags like docker:stable are used, you have no control over what version is going to be used and this can lead to unpredictable behavior, especially when new versions are released.
    1. Using the Git SHA in your image tag makes this less necessary since each job will be unique and you shouldn't ever have a stale image. However, it's still possible to have a stale image if you re-build a given commit after a dependency has changed.
    1. Internal platform groups (those focused on a non-user facing part of our product, like a set of internal APIs) tend to create heavy coordination costs on other groups which depend on platform improvements to deliver valuable features to users. In order to stay efficient, it is important to ensure each group is non-blocking and is able to deliver value to users directly. This is why we avoid internal platform groups.
  24. Apr 2020
    1. What wretched managers miss in their confusion is that all the work you do (and everything your co-workers do) is entangled and interdependent with everything else. When your manager says "Forget your old priorities, and focus on my new crisis" s/he's betraying an ignorance of the laws of physics.
  25. Mar 2020
    1. the performance of a contract may not be made dependent upon the consent to process further personal data, which is not needed for the performance of that contract
  26. Jan 2020
  27. Dec 2019
    1. don't mix application dependencies with those of the build system
    2. by putting dependencies like React behind our dependency, users couldn't update React without also updating our CLI tool.

      I think this means:

      yourApp dependsOn thisTool@1.0.0 thisTool@1.0.0 dependsOn react@16

      So you can't upgrade the react dependency directly: yourApp dependsOn react@17

  28. Apr 2019
  29. Nov 2018
    1. Dependency cycles are most dangerous when they involve the mechanisms used to access and modify a service. The operator knows what steps to take to repair the broken service, but it's impossible to take those steps without the service.