87 Matching Annotations
  1. Jan 2024
    1. A reviewer wants to view all comments on an MR in a condensed list, and - for each one - see the context of that comment. Problem: Notes (on the MR) and Discussions (on the Diff) are treated differently, and Discussions necessarily come with Diff context. Diff context with Discussions is difficult to match with actual diffs because rendering diffs isn't designed for non-Changes-tab contexts
    1. I feel that the current design area should be a key part of the workflow on any work item, not just type of designs. As a PM I don't schedule designs independently. It's odd to open and close a design issue when it doesn't deliver value to the customer.
    2. Discussions tied to the design itself is solved today with design manager, which allows those design discussions to occur within the context of a bigger issue. Bringing design manager into other work item types, like epics, would help, as would surfacing discussions from designs into the main discussion space. That behavior should be consistent for any work item type with design management enabled, rather than just for a design type.

      don't want: isolation

  2. Nov 2023
  3. Aug 2023
  4. May 2023
    1. ISO 8601 specifies the use of uppercase letter T to separate the date and time. PostgreSQL accepts that format on input, but on output it uses a space rather than T, as shown above. This is for readability and for consistency with RFC 3339 as well as some other database systems.
  5. Mar 2023
    1. What type of note did Niklas Luhmann average 6 times a day? .t3_11z08fq._2FCtq-QzlfuN-SwVMUZMM3 { --postTitle-VisitedLinkColor: #9b9b9b; --postTitleLink-VisitedLinkColor: #9b9b9b; --postBodyLink-VisitedLinkColor: #989898; }

      reply to u/dotphrasealpha at https://www.reddit.com/r/Zettelkasten/comments/11z08fq/what_type_of_note_did_niklas_luhmann_average_6/

      The true insight you're looking for here is: Forget the numbers and just aim for quality followed very closely by consistency!

      Of course most will ignore my insight and experience and be more interested in the numbers, so let's query a the 30+ notes I've got on this topic in my own zettelkasten to answer the distal question.

      Over the 45 years from 1952 to 1997 Luhmann produced approximately 90,000 slips which averages out to:

      • 45 years * 365 days/year = 16,425 days
      • 90,000 slips / 16,425 days = 5.47 slips per day

      In a video, Ahrens indicates that Luhmann didn't make notes on weekends, and if true, this would revise the count to 7.69 slips per day.

      260 working days a year (on average, not accounting for leap years or potential governmental holidays)

      • 45 years x 260 work days/year = 11,700 days
      • 90,000 slips / 11,700 days = 7.69 slips per day

      Compare these closer numbers to Ahrens' stated and often quoted 6 notes per day in How to Take Smart Notes.

      I've counted from the start of '52 through all of '97 to get 45 years, but the true amount of time was a bit shorter than this in reality, so the number of days should be slightly smaller.

      Keep in mind that Luhmann worked at this roughly full time for decades, so don't try to measure yourself against him. (He also published in a different era and broadly without the hurdle of peer review.) Again: Aim for quality over quantity! If it helps, S.D. Goitein created a zettelkasten of 27,000 notes which he used to publish almost a third more papers and books than Luhmann. Wittgenstein left far fewer notes and only published one book during his lifetime, but published a lot posthumously and was massively influential. Similarly Roland Barthes had only about 12,500 slips and loads of influential work.

      I keep notes on various historical practitioners' notes/day output over several decades using these sorts of practices. Most are in the 1-2 notes per day range. A sampling of them can be found here: https://boffosocko.com/2023/01/14/s-d-goiteins-card-index-or-zettelkasten/#Notes%20per%20day.

      Anecdotally, I've found that most of the more serious people here and on the zettelkasten.de forum are in the 4-10 slips per week range.

      <whisper>quality...</whisper>

    1. How do you store and classify index cards? I usually have boxes that fit my index cards, and add a plastic tab with the reference in Author (Date) format. Other people use different classification systems (by keyword, by topic, by author). I just recommend that the process be consistent across.

      Pacheco-Vega stores his card with plastic tabs labeled by the references rather than by keyword or topic.

      He does recommend consistency in filing though.

  6. Jan 2023
    1. These words are redundant and inconsistent with the style of boolean methods in the Ruby core library, such as empty? and include?.
  7. Dec 2022
    1. We will also run into some issues when we consider adding new channels to Service Desk like an API. We should have a streamlined process of rendering notes (messages) etc. Having a base64 image (or even attachment) in mail but not in the API might be inconsistent and also adds a lot of code that needs to be maintained.
  8. Oct 2022
    1. I'm afraid you missed the joke ;-) While you believe spaces are required on both sides of an em dash, there is no consensus on this point. For example, most (but not all) American authorities say /no/ spaces should be used. That's the joke. In writing a line about "only one way to do it", I used a device (em dash) for which at least two ways to do it (with spaces, without spaces) are commonly used, neither of which is obvious -- and deliberately picked a third way just to rub it in. This will never change ;-)
    1. For the second time Goutor mentions using different size cards for different note types, but doesn't specifically advise for it or provide a reason. Perhaps his advice for consistency and card size applies only to cards of particular types? (p28)

      link to: https://hypothes.is/a/XPphjkNZEe2s3i9VV4qt1g


      Incidentally he also specifically mentions 7x9" cards here too. How frequently used were these as a standard?

    2. Unlike many note taking manuals, Goutor advises for consistency in method and use as a means of improving efficiency. He extends this specifically to choosing card sizes (though this only goes as far as particular note types: i.e. bibliographic notes versus content notes), card colors, layout of cards, and card classification. (p28)

      It's frequent in practice, however, that many people make small incremental changes in their workflows and systems over time. In some cases, people have been known to make dramatic changes, like changes in platforms, or start over from scratch (example: that of Luhmann who started ZKII after many years of building ZKI).

  9. Sep 2022
    1. in my personal opinion, there shouldn't be a special treatment of do-end blocks in general. I believe that anything that starts a "block", i.e. something that is terminated by and end, should have the same indentation logic
  10. Aug 2022
    1. for example, having occasion to make thousandsof brief records of such small matters as the spelling or pronunciation of a word, might well prefera slip no larger than 2x4. On the other hand, anyperson writing a coarse or heavy hand wouldprobably not care for a very small slip, whateverhis interests.

      I haven't seen 2 x 4" slips suggested before!

      Dow suggests the possibility of various small sizes based on the individual researchers' needs. Linguists might have very little and benefit from a 2 x 4" slip. Though once chosen, he does caution consistency of that size for easy manipulation.

    Tags

    Annotators

    1. oh I'm fine with defective verbs. I'm not fine with inconsistency, though. Make it "Signup and login", and make it that on every SE page everywhere ever, and you can countin me.
  11. Jul 2022
    1. I'm partial to the solution originally proposed. It follows a pattern already established in Rails. For example, using an application-specific ApplicationStorageController which inherits from ActiveStorage::BaseController is very similar to the ApplicationRecord which inherits from ActiveRecord::Base or ApplicationJob which inherits from ActiveJob::Base.
    1. I guess my hesitation in answering your question is that I hate essentialism. It’s the same way that I hate it when people say women are better leaders because we are more empathetic. The problem with essentialism is, the moment you pay yourself a compliment based on gender, caste, religion, color of your skin — whatever — country of your origin — if you’re going to accept one generalization is true, then you’re going to have to suck up the generalizations and the caricatures that aren’t so flattering.
  12. May 2022
    1. I think RSpec should provide around(:context)/around(:all). Not because of any particular use case, but simply for API consistency. It's much simpler to tell users "there are 3 kinds of hooks (before, after and around) and each can be used with any of 3 scopes (example, context and suite)". Having some kinds of hooks work with only some kinds of scopes makes the API inconsistent and forces us to add special case code to emit warnings and also write extra documentation for this fact.
    2. I've been thinking of looking into implementing this in rspec-core, primarily to make the API more consistent (e.g. so that you can combine any scope -- example/context/suite -- with any hook type before/after/around).
  13. Apr 2022
    1. I'm concerned that supporting certain parts of the svelte javascript semantics in module scripts—that have so far been restricted to the instance script—could lead users to believe that everything is supported. Supporting store shorthand syntax but not reactive assignments and declarations could be confusing.

      could lead users to believe ... - could lead users to believe that everything is supported.

  14. Mar 2022
    1. In 13.10, Shift+Insert pastes from the selection buffer (the thing that selecting text writes to). In Libre Office, Chrome, and Firefox, Shift+Insert pastes from the clipboard. I would thus like to configure gnome-terminal to do the same.
  15. Feb 2022
    1. ReconfigBehSci. (2022, January 14). man who contracted potentially disease and then violated public health orders tries to cross borders by providing incorrect info on key docs = just fine is not something I foresaw from this corner... Once consistency is thrown out as a standard, rational debate is impossible... [Tweet]. @SciBeh. https://twitter.com/SciBeh/status/1481929150042619908

  16. Jan 2022
    1. What happens when a regular error occurs and is not caught by try..catch? The script dies with a message in the console. A similar thing happens with unhandled promise rejections.
  17. Dec 2021
  18. Sep 2021
    1. You can help make Node.js and browsers more unified. For example, Node.js has util.promisify, which is commonly used. I don’t understand why such an essential method is not also available in browsers. In turn, browsers have APIs that Node.js should have. For example, fetch, Web Streams (The Node.js stream module is awful), Web Crypto (I’ve heard rumors this one is coming), Websockets, etc.
  19. Aug 2021
    1. Luhmann also described his system as his secondary memory (Zweitgedächtnis), alter ego, or his reading memory or (Lesegedächtnis).

      Stumbled back upon this article almost a year and change later. Great to see that I'm at least consistent in what I would highlight. ;)

  20. Jun 2021
    1. Prettier intentionally doesn’t support any kind of global configuration. This is to make sure that when a project is copied to another computer, Prettier’s behavior stays the same. Otherwise, Prettier wouldn’t be able to guarantee that everybody in a team gets the same consistent results.
  21. Mar 2021
  22. afarkas.github.io afarkas.github.io
    1. If set to true the UI of all input widgets (number, time, month, date, range) are replaced in all browsers (also in browser, which have implemented these types). This is useful, if you want to style the UI in all browsers.
  23. Jan 2021
  24. Nov 2020
  25. Oct 2020
    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. it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.
    1. We get a boilerplate-free API where shared state has the same simple get/set interface as React local state (yet can be encapsulated with reducers etc. if needed).
  26. Sep 2020
    1. For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.
    1. We don't want to treat it specially in certain contexts, and we don't want to silently convert a reactive variable into a store.
    1. The above doesn't work for another unfortunate reason, it's not possible to write export let class = ''; instead CustomComponent because class is a reserved keyword and isn't allowed to be used as a variable name. The workaround would have to be to use some other prop name like maybe cssClass but then there's no "standard" by which all Svelte components can follow and every library will choose a different name which is cumbersome for users, because it creates scenarios like:
    1. The primary motivation for this change is to have the same behavior between dom elements and wrapper components. Class directives are extremely convenient but that convenience is lost when a section of code needs to be converted to a component.
  27. Aug 2020
    1. “I came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me is that there is a greater difference between high-performance code and idiomatic ‘clean’ code in Haskell than in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can become unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.”
  28. Jul 2020
    1. It also resolves the problems with private operator methods (self + bar) and compound assignments with private writers and/or private operators (self += bar, self.foo += bar, where either + or foo= or both are private). It removes pretty much all edge cases in one blow.
    2. It does change it, but it makes it much simpler in my opinion. It is basically "the receiver is statically the explicit literal special variable self or implicit." This gets rid of the current exception for private writer methods (self.foo = bar).
    1. I decided to use the same name to keep the consistence with the Set class and because it was also written like that in the Array code.
    1. Set#intersection already exists and is an alias for Set#&, so there's precedent for such a method to exist.
    2. one other thing I wanted to ask was about whether we should allow multiple arrays to be passed as arguments. Array#difference and Array#union both allow this, so it might make sense to have Array#intersection also take multiple arguments.
    1. Arrays are not sets. Trying to treat them as if they are is an error, and will create subtle problems. What should be the result of the following operations? [1, 1] | [1] [1] | [1, 1] Of course, there are more interesting examples. These two are to get you started. I don't care what the results currently are. I don't care what you think they should be. I can present extremely strong arguments for various answers. For this reason, I believe that #| is an ill-defined concept. Generalizing an ill-defined concept is a world of pain. If you insist on treating objects of one class as if they were members of a different class, there should be bumps in the road to at least warn you that maybe this is a bad idea. I'm not going to argue that we should remove or deprecate #|. I don't think of myself as a fanatic. But encouraging this sort of abuse of the type system just creates problems.
    2. What about introducing concat! with the same behaviour as concat and deprecating concat. Then we could in the feature give concat the behaviour it deserves. It is confusing as well that this method modify the object and I think we should fix this.
  29. Jun 2020
  30. Apr 2020
    1. Finally, from a practical point of view, we suggest the adoption of "privacy label," food-like notices, that provide the required information in an easily understandable manner, making the privacy policies easier to read.
  31. Mar 2020
    1. Why would a company want to have one system for people in France, Germany, and Italy and a separate one for people everywhere else?
    2. “It’s strange to say, ‘Yeah, we’re going to respect the privacy of Europeans more than all other human beings all over the world,’”
  32. Jan 2020
  33. Nov 2019
    1. I always prefer strictness, bad behavior should be uncovered as soon as possible or you are effectively encouraging it, which means they'll soon be back asking why it doesn't work for X and Y. Fix the problem at the source. I don't really care, but IMHO doing this seems like a charitable thing but it's actually the opposite.
    2. In a sense, the current behavior is the best behavior, because it never works, you will never get the impression that it does in React.
  34. Sep 2019
    1. The theory says that in distributed systems everything is eventually consistent but the pragmatic view of the real world says that we need to be real careful on what we choose to make eventually consistent.
  35. Jan 2019
  36. getincredibles-fe.herokuapp.com getincredibles-fe.herokuapp.com
    1. What's the stage your project is currently at?

      This is a required field (add * at the end) Please remove the first option 'stage at which my project is currently at' from the dropdown as it's not an option one can choose.

      Please also match the look and feel of this to the other drop downs..e.g. this one is grey, fonts seem different and it also animates/appears on the screen in a different way

  37. Nov 2018
    1. “The role of the hospitalist often is to take recommendations from a lot of different specialties and come up with the best plan for the patient,” says Tejal Gandhi, MD, MPH, CPPS, president and CEO of the National Patient Safety Foundation. “They’re the true patient advocate who is getting the cardiologist’s opinion, the rheumatologist’s opinion, and the surgeon’s opinion, and they come up with the best plan for the patient.”
  38. Jun 2017
    1. no data loss will occur as long as producers and consumers handle this possibility and retry appropriately.

      Retries should be built into the consumer and producer code. If leader for the partition fails, you will see a LeaderNotAvailable Exception.

    2. By electing a new leader as soon as possible messages may be dropped but we will minimized downtime as any new machine can be leader.

      two scenarios to get the leader back: 1.) Wait to bring the master back online. 2.) Or elect the first node that comes back up. But in this scenario if that replica partition was a bit behind the master then the time from when this replica went down to when the master went down. All that data is Lost.

      SO there is a trade off between availability and consistency. (Durability)

    3. keep in mind that these guarantees hold as long as you are producing to one partition and consuming from one partition.

      This is very important a 1-to-1 mapping between writer and reader with partition. If you have more producers per partition or more consumers per partition your consistency is going to go haywire

    1. Kafka consumer offset management protocol to keep track of what’s been uploaded to S3

      consumers keep track of what's written and where it left off by looking at kafka consumer offsets rather than checking S3 since S3 is an eventually consistent system.

  39. Nov 2016
  40. Nov 2013
  41. Sep 2013