20,173 Matching Annotations
  1. Last 7 days
    1. “Discipling” someone is, to use a more recognizable term, mentoring someone in how to follow Christ and share the good news that people can have a relationship with God.
    1. The affinity to using meta-programming in Ruby is going to vary a lot between different development teams and it’s a very important factor in deciding whether to adopt gradual typing as the two work against each other.
    2. On most real life projects, the speed of development is easily worth an occasional corner case bug with an unexpected nil value … except when it isn’t.

      speed of development vs. safety

    3. If I decide to add it, which solution should I pick, battle tested Sorbet or core team endorsed RBS?
    4. Will gradual typing be supported long term or is it a fad? Will this be an abandoned investment?

      annotation meta: may need new tag: - Is it worth the investment? - Is it just a passing fad?

  2. Nov 2024
    1. confabulation
    2. But that label has grown controversial as the topic becomes mainstream because some people feel it anthropomorphizes AI models (suggesting they have human-like features) or gives them agency (suggesting they can make their own choices) in situations where that should not be implied.
    1. “There are a lot of people who mistakenly think intelligibility is the standard. ‘Oh, you knew what I was saying.’ Well, that’s not the standard. That’s a really bottom-of-the-barrel standard,” he says. “People who are concerned with English usage usually want to have their words taken seriously, either as writers or as speakers. And if you don’t use the language very well, then it hard to have people take your ideas seriously. That’s just the reality.”
    2. Some linguists would argue that there’s no point fighting against slips like that—that language is forever unfixed and deviations should simply be observed and even appreciated—or that it’s silliness to tell people to follow rules that are as arbitrary as the meaning assigned to a certain jumble of letters. But Garner is not one of them.
    3. Then again that makes little sense when trying to account for why people use the less-standard preventative instead of preventive or irregardless instead of regardless, he notes.
    4. These days someone might even try to correct you if, in an attempt to note someone was being (overly) humble, you said they were self-depreciating.
    5. But the corruption has become so common that using the original today might not only stop a conversation in its tracks but cause unpleasant face-scrunching. Per Garner, spitting image is now 23 times more commonly used than its precursor.
    6. Have you ever said you felt nauseous? In the traditional sense that would mean you felt like you were capable of causing others to woof cookies, not that you were feeling sick to your own stomach—much along the lines of how poisonous and poisoned work.
    7. Young people today, he says, are now dropping the “from” and simply saying they “graduated college,”
  3. Oct 2024
    1. At the same time, computer scientists and engineers need to deliver the technological burden of proof that decentralized personal data networks can scale globally, and that they can provide people with a better experience than centralized platforms.
    2. This unprecedented openness has inspired large-scale permissionless innovation and unbounded creativity
    3. Fortunately, we do not have to agree on everything. Linked Data enables layered agreements, in which a few rules need to be adopted by many, and sets of additional rules are agreed upon by smaller groups as required.
      • we do not have to agree on everything
      • sets of additional rules are agreed upon by smaller groups as required.
    4. Freedom of course always comes at a cost: what constitutes a victory for personal rights and freedom of speech also facilitates the spread of illegal messages, since decentralized networks make it harder to control what information is exchanged. Legality is of course a tricky matter, as some countries instate laws that prevent their citizens from voicing opinions that would be legal elsewhere.
    1. Usernames will need to be unique and have two numbers appended to the end of them, which Signal states was done in order to help keep usernames "egalitarian and to minimize spoofing."
    1. I am just surprised that there is no clear official name for such a popular and well known convention.  Internet searching seems to indicate that the common term used is "Red Squiggly Line", but it seems like a term quickly made-up just to describe something for which we know no name.  There's a technical name for the dot on an "i" for goodness sake (tittle).
    1. The seeming luxury of having multiple words to choose from is not sufficient to offset the lingering fear that no matter which word you pick it will be the wrong one, causing people to silently laugh at you and judge both you and your grammar school teachers
    2. The word people is best not used with words of number, in place of persons. If of ‘six people’ five went away, how many ‘people’ would be left? Answer: one people.
    1. Enhances ActionMailer to support the :cache delivery method, which behaves like :test, except that the deliveries are marshalled to a temporary cache file, thus making them available to other processes.
    1. I control my emails. I can grep them, migrate them, back them up however I want, I can choose who gets through the spam filter. And this is my most sensitive data - password resets, personal emails, personal info - honestly I'm surprised more selfhosters don't do it.
    1. This tools bridges the gap of having feature files found in your source code and true documentation that your team, product owners and stakeholders can use.
    1. As you all noticed I haven't given too much attention to this project in recent years, which I regret, but realistically I probably won't be the best maintainer given I haven't been using Ruby for years now, lost the contact with the ecosystem whatsoever.
    1. The fact that many here are maintainers of Ruby implementations also has a biased effect on new features, as they might represent a burden on them. I'm not saying this is a bad thing, I love the diversity of points of view that this brings! OTOH, it's fair that people that do take time to discuss things here have a bigger influence on the direction that Ruby follows.
    2. I frequently call for name compromises (let's stop on one name and move forward instead of five more years of discussion).
    1. "astronaut" beautifully translates to "star sailor."
    2. true roots of "helicopter" are "helix" (meaning spiral, as in double helix) and "pteron" (meaning wing, as in pterodactyl, wing finger). So, "helicopter" literally means "spiral wing" – how perfect!
    1. Built in the open Concourse's RFC process and governance model invite anyone to become a contributor, developing the project roadmap by collaborating in the open.
    1. This is a bit awkward since TypeScript already defines its own thing called Iterator purely for type-checking. So due to this unfortunate name clash, TypeScript needs to introduce a separate type to describe these native/built-in iterable iterators.
    1. The extension runs a command using your shell’s interactive mode, so that version managers configured in files such as ~/.zshrc are picked up automatically. The command then exports the environment information into JSON, so that we can inject it into the NodeJS process and appropriately set the Ruby version and gem installation paths.

      Makes sense, but some of these solutions sure seem like roundabout/unideal solutions

  4. Sep 2024
    1. Daily Wire held screenings at universities across the US, but some of those efforts were hindered when Eventbrite took down listings for screenings due to violations of its community guidelines. Article continues after ad “We do not permit events, content, or creators that promote or encourage hate, violence, or harassment towards others and/or oneself,” the company said.
    1. This method allows individuals to manage and interlink their information more effectively by creating interconnected nodes, known as knowledge graphs.
    1. GPL "infects" other parts of a system to combat a work-around which was used to violate the software freedom of the user, by firewalling sections of GPL'ed code from the rest of the system.
    2. The point of GPL licenses is to protect the user of the software, not the developer. If you want "protection" as a developer, use MIT (disclaimer of warranty). GPL "infects" other parts of a system to combat a work-around which was used to violate the software freedom of the user, by firewalling sections of GPL'ed code from the rest of the system. If you don't care about your users' software freedom in the first place, then (L)GPL is the wrong choice.
      • goal: protect user rights/freedoms
      • non-goal: protect developer rights/freedoms
    1. In practice, tracking all authors in all copyright notices is quite cumbersome. Instead, often only the original author is credited here even when copyright is shared with additional contributors. A more reasonable approach is to credit all authors collectively, e.g. as “the FooProject contributors” or “Original Author and others”. However, I am not sure whether that results in a valid copyright notice as the copyright holders must be clearly recognizable.
    2. The other reason to update these notices is if there are new authors. Typically, this is done by adding a new copyright line for each set of authors, with the most recent on top. For example: Copyright 2016–2018 George Copyright 1999, 2007–2016 Fred Adding a new line is sensible since many open-source licenses require that existing copyright notices are kept intact – so you must not update them in any way. And in the above example, adding George to Fred's copyright notice would be misleading since George did not publish any of their work in 1999 and Fred didn't publish in 2018.
    1. freedom to make and distribute copies of your modified versions
    2. A free program allows you to tinker with it to make it do what you want (or cease to do something you dislike). Tinkering with software may sound ridiculous if you are accustomed to proprietary software as a sealed box, but in the Free World it's a common thing to do, and a good way to learn programming. Even the traditional American pastime of tinkering with cars is obstructed because cars now contain nonfree software.
    3. If the users don't control the program, the program controls the users.
    4. Other kinds of works are also used for practical activities, including recipes for cooking, educational works such as textbooks, reference works such as dictionaries and encyclopedias, fonts for displaying paragraphs of text, circuit diagrams for hardware for people to build, and patterns for making useful (not merely decorative) objects with a 3D printer. Since these are not software, the free software movement strictly speaking doesn't cover them; but the same reasoning applies and leads to the same conclusion: these works should carry the four freedoms.
    5. If any of them is missing or inadequate, the program is proprietary (nonfree)

      non-free software = proprietary software

      missing any of these = non-conformant license (relative to a free software license)

    6. With all four freedoms, the users fully control the program.
    7. With the other two freedoms, any group of users can together exercise collective control over the program.
    8. The freedom to make and distribute exact copies when you wish.

      .

    9. Users' control over the program requires four essential freedoms.
    10. freedom to study the program's “source code,” and change it, so the program does your computing as you wish
    11. freedom to run the program as you wish, for whatever purpose.
    12. The first two freedoms mean each user can exercise individual control over the program
    13. Either way, they give the program's developer power over the users, power that no one should have.
    14. When a program respects users' freedom and community, we call it “free software.”
    15. computer users' freedom—for users to control the software they use, rather than vice versa
    1. The computer will run, without prejudice, whatever software you install in it, and let that software do whatever its code says to do.
    2. This means that computer does not impose one particular service rather than another, or one protocol rather than another. It does not require the user to get anyone else's permission to communicate via a certain protocol.
    3. The computer will communicate, without prejudice, through whatever protocol your installed software implements, with whatever users and whatever other networked computers you direct it to communicate with.
    4. Any software that can be replaced by someone else, the user must be empowered to replace.
    5. However, the presence of nonfree software in the computer is an obstacle to verifying that the computer is loyal, or making sure it remains so.
    6. For instance, the AMT functionality in recent Intel processors runs nonfree software that can talk to Intel remotely. Unless disabled, this makes the system disloyal.
    7. The computer always permits you to analyze the operation of a program that is running.
    8. This entails that the computer rejects remote attestation, that is, that it does not permit other computers to determine over the network whether your computer is running one particular software load. Remote attestation gives web sites the power to compel you to connect to them only through an application with DRM that you can't break, denying you effective control over the software you use to communicate with them.
    9. When the computer communicates using any given protocol, it will support doing so, without prejudice, via whatever code you choose (assuming the code implements the intended protocol), and it will do nothing to help any other part of the Internet to distinguish which code you are using or what changes you may have made in it, or to discriminate based on your choice.
    1. Creative Commons NonCommercial licenses (by-nc-*) do not support the OD 1.1#8., “No Discrimination Against Fields of Endeavor”, as they exclude usage in commercial activities.
    1. Broadly speaking, an open license is one which grants permission to access, re-use and redistribute a work with few or no restrictions.
    1. Opponents often state that this technology will be used primarily to enforce digital rights management policies (imposed restrictions to the owner) and not to increase computer security.
    2. TC is controversial as the hardware is not only secured for its owner, but also against its owner, leading opponents of the technology like free software activist Richard Stallman to deride it as "treacherous computing"
    3. The law in many countries allows users certain rights over data whose copyright they do not own (including text, images, and other media), often under headings such as fair use or public interest. Depending on jurisdiction, these may cover issues such as whistleblowing, production of evidence in court, quoting or other small-scale usage, backups of owned media, and making a copy of owned material for personal use on other owned devices or systems. The steps implicit in trusted computing have the practical effect of preventing users exercising these legal rights.
    1. "please" and "thanks"
    2. Provide a complete description of the issue. If it works on A but not on B and others have to ask you: "so what is different between A and B" you are wasting everyone's time.
    3. Introduction of a lockfile: true/filename mechanism to prevent multiple schedulers from executing
    4. So you need help. People can help you, but first help them help you, and don't waste their time.
    5. I avoid running -d in development mode and bother about daemonizing only for production deployment.
    6. There is the handy rails server -d that starts a development Rails as a daemon. The annoying thing is that the scheduler as seen above is started in the main process that then gets forked and daemonized. The rufus-scheduler thread (and any other thread) gets lost, no scheduling happens.
    7. Using rufus-scheduler with Passenger or Unicorn requires a bit more knowledge and tuning, gently provided by a bit of googling and reading
    8. I don't know what this Ruby thing is, where are my Rails? I'll drive you right to the tracks.
    9. Go read how to report bugs effectively, twice. Update: help_help.md might help help you.

      .

    10. similar gems
    11. Rufus-scheduler (out of the box) is an in-process, in-memory scheduler. It uses threads. It does not persist your schedules. When the process is gone and the scheduler instance with it, the schedules are gone.
    1. Log to stdout. Shut down on TERM/INT. Reload config on HUP. Provide the necessary config file for your favorite init system to control your daemon.
    2. Your application code should not be dealing with PID files, log redirection or other low-level concerns.
    3. Let your operating system handle daemons, respawning and logging while you focus on your application features and users.
    4. This makes developing a modern daemon much easier. The init config file is what you use to configure logging, run as a user, and many other things you previous did in code. You tweak a few init config settings; your code focuses less on housekeeping and more on functionality.
    5. For years developers have followed the same arcane dozen steps to create a long-lived daemon process on Unix-based systems. These steps were state of the art in 2000 but they are no longer best practice today.
    6. Less system administration, easier debugging, simpler code, all because you leveraged the init system to do the work for you!
    1. The beauty of runit is its brevity and simplicity
    2. Unfortunately newer init systems like systemd have become increasingly complex to handle more desktop-focused requirements. Here’s a list of systemd APIs: does having 100s of public API functions and commands inspire confidence in its reliability?
    3. I can firmly recommend runit if you want a server-focused, reliable init system based on the traditional Unix philosophy.
    4. Reliability of the init system is paramount so simplicity is a key attribute.
    1. But fork does not copy the parent process's threads. Thus locks (in memory) that in the parent process were held by other threads are stuck in the child without owning threads to unlock them, ready to cause a deadlock when code tries to acquire any of them. Also any native library with forked threads will be in a broken state.
    2. So fork is fast, unsafe, and maybe bloated.
    3. spawn starts a Python child process from scratch without the parent process's memory, file descriptors, threads, etc. Technically, spawn forks a duplicate of the current process, then the child immediately calls exec to replace itself with a fresh Python, then asks Python to load the target module and run the target callable.
    1. Did you actually fix a known issue? Let the author know about it.
    2. Want to really annoy an open-source maintainer? Then ignore any communication channels they have setup for support.
    3. I don't expect everyone to read every single line of the code for a project they are trying to use, that isn't very reasonable. What I do see though, is that a lot developers have a mental barrier to actually opening up the source code for the project they are trying to use. They will read the documentation, run the tests, use the example code, but when they are faced with a problem that could be solved through a one or two line change in the source code, they shut down completely. The point is that you shouldn't be afraid to jump into the source code. Even if you don't fully understand the source code, in many cases you should be able to isolate your issue to a specific block. If you can reference this block ( or line numbers ) when opening up your support request, it will help the author better understand your problem.
    4. Developers want to improve their project. If you find an issue, bring it up. If it's a valid concern, the author will probably want to have it fixed. In many cases, the author will consider it a valid issue, but simply not have the personal time or need to address it immediately. This is where open-source is great. Just fork the project and fix it
    5. Does something about a project really bother you? Does the author not care as much about it as you do?

      .

    6. On many occasions, I've opened up requests for support in the form of a Github pull request. This way, I am telling the author: I have found a potential problem with your library, here is how I fixed it for my circumstance, here is the code I used for reference. You get extra internet points if you open the pull request with: "I don't expect this pull request to get merged, but I wanted to you show you what I did".
    7. Not everyone has time to adhere to the specific coding styles for a project, so if you can't do a full blown pull-request, there is NOTHING wrong with opening a pull-request that only has the intention of showing the author how you solved the problem.
    8. There are no refunds for open-source. If you go in with the attitude that you are owed something, you will be thoroughly disappointed.
    9. On behalf of all open-source developers and project maintainers, I ask you try and be polite the next time you ask for support. Try to remember that there is a real human being on the other side of the screen, and they actually want to help you.
    10. Don't assume that because you opened up a pull request, that the author will accept it. There are many reasons that a maintainer might choose to not merge in your specific patch, many of which have nothing to do with you. If your patch isn't accepted, try to assume it's for a valid technical reason and not because the author hates you.
    11. If you feel there has been an oversight, it's okay to not give up. As long as you are being logical and open to other people's views, you will find that you might learn something new, or even teach something to the maintainer.
    12. Don't get upset, rejection is normal
    13. If the author has taken the time to write unit tests for the project, you REALLY need to confirm the unit tests work before trying to get support.
    14. If the information you need isn't covered in the documentation, let the author know. They probably will want to add this information so other people don't ask the same question.
    15. The point is, take the time to actually research if the maintainer has setup a specific channel for support.
    16. You need to understand that the person you are reaching out to has probably spent 100s of hours working on this project, for free. They do not owe you anything. The maintainers are extending a courtesy by giving away their work for free and then making themselves available to support it. The point is, you should try and be nice when filing for support. The maintainer of the project has literally no obligation to help you.
    1. input
    2. So tell them exactly what you did. If it's a graphical program, tell them which buttons you pressed and what order you pressed them in. If it's a program you run by typing a command, show them precisely what command you typed.
    3. Providing your own diagnosis might be helpful sometimes, but always state the symptoms. The diagnosis is an optional extra, and not an alternative to giving the symptoms.
    4. If you give the programmer a long list of inputs and actions, and they fire up their own copy of the program and nothing goes wrong, then you haven't given them enough information.
    1. In particular, one thing that fork() doesn’t copy is threads. Any threads running in the parent process do not exist in the child process.
    2. it’s time for a deep-dive into Python brokenness and the pain that is POSIX system programming, using exciting and not very convincing shark-themed metaphors!
    3. A conundrum wherein fork() copying everything is a problem, and fork() not copying everything is also a problem.

      may not actually be a dilemma, if there is a 3rd option...

    1. Disable all observers in your test suite by default. They should not be complicating your model tests because they should have separate concerns anyway. You don't need to unit test that observers actually fire, because ActiveRecord's test suite does that, and your integration tests will cover it.
    2. I emphatically disagree with BlueFish about observers being difficult to properly unit test. This is precisely the biggest point that distinguishes them from lifecycle callbacks: you can test observers in isolation, and doing so discourages you from falling into many of the state- and order-heavy design pitfalls BlueFish refers to (which again I think is more often true of lifecycle callbacks).
    3. Rails' observers were partly inspired by aspect-oriented programming -- they're about cross-cutting concerns. If you're putting business logic in observers that is tightly coupled to the models they're observing, you're doing it wrong IMO.
    1. I've been a UK resident for over 70 years, have two degrees from a very well known university, and find both zeros and zeroes quite acceptable as the plural form. So our perceptions are different. Do we toss a coin, or see who can shout the louder? ... Dictionaries are less open to subjective bias than individuals because of the averaging effect of carefully controlled large surveys (and acceptability is usage driven). It's good to realise that personal preferences may not be the best basis for judging correctness.
    2. Note that dictionaries document the (current, at the time of going to press) usage of language, they aren't authoritative. 'Correct' is what is in common usage and largely understood to be correct, even if that contradicts a dictionary (in which case the dictionary is probably out-of-date).