64 Matching Annotations
  1. Mar 2025
  2. Sep 2024
    1. In practice when people use ||, they do mean ?? (whatever its spelling). It just so happens that most of the time, it does what you want, because you happen to not be dealing with Booleans. But the semantics you mean to express is not about "truthness", but about "nilness". And occasionally you get bitten because false does exist, and behaves differently.
  3. Jul 2024
  4. Feb 2024
    1. Its a bit tricky because of the ambiguity of how the args get presented. You can see through the little demo the args are presented the same way whether its a straight kwargs or a hash, but the assignment of the args to parameters is different. def foo(*args) puts args.inspect end def bar(x=1, a:2) puts "x:#{x} a:#{a}" end foo(:a => 1) # [{:a=>1}] foo({:a => 1}) # [{:a=>1}] bar(:a => 1). # x:1 a:1 bar({:a => 1}). # x:{:a => 1} a:2
  5. Dec 2023
    1. && nil

      first sighting: I don't think I've seen someone write exactly && nil before.

      Apparently to avoid having the return value from errors.add — which should be done solely for its side effect, not to get a return value -- inadvertently being used as a return value for user. It wouldn't make sense to return from user. That should only return a User or nil. And more statically typed languages would allow that to be expressed/enforced from type annotations alone, which would have caught the mistake of returning errors.add if someone had accidentally attempted to return that.

      Having user (and therefore call) return nil is key to the unless @current_user working.

  6. Nov 2023
    1. BTW to improve the reliability of that test I believe you would need a sleep (smaller, e.g. of 0.1) between the Thread.new and assert M.works?, otherwise it's likely the M.works? runs first and then the other thread will see the constant is autoloading and wait, and anyway that thread does not check what is defined on M. For the test to fail it needs to be the Thread.new running first and defining the constant but not yet the method, before the main thread keeps running and call the method.
  7. May 2023
    1. An AI model taught to view racist language as normal is obviously bad. The researchers, though, point out a couple of more subtle problems. One is that shifts in language play an important role in social change; the MeToo and Black Lives Matter movements, for example, have tried to establish a new anti-sexist and anti-racist vocabulary. An AI model trained on vast swaths of the internet won’t be attuned to the nuances of this vocabulary and won’t produce or interpret language in line with these new cultural norms. It will also fail to capture the language and the norms of countries and peoples that have less access to the internet and thus a smaller linguistic footprint online. The result is that AI-generated language will be homogenized, reflecting the practices of the richest countries and communities.

      [21] AI Nuances

  8. Dec 2022
    1. Because I am as interested in the attitudes and assumptions which are implicit in the evidence as in those which were explicitly articulated at the time, I have got into the habit of reading against the grain. Whether it is a play or a sermon or a legal treatise, I read it not so much for what the author meant to say as for what the text incidentally or unintentionally reveals.

      Historians, sociologists, anthropologists, and surely other researchers must often "read against the grain" which historian Keith Thomas defines as reading a text, not so much for what the author was explicitly trying to directly communicate to the reader, but for the small tidbits that the author through the text "incidentally or unintentionally reveals."

    1. Mailgun, with its permanent failure webhook, is sending a message about a permanent failure of that specific message - it is Campaign that is then making a decision to translate this message, about just that one message, into a permanently bounced (suppressed) contact, and blocking all future emails to that contact - based on, what is clearly quite possibly just a temporary failure. It's really the distinction between a single message level (temporary) problem and a (permanent) contact level problem that is being lost with Campaign's current approach.
  9. Nov 2022
  10. Oct 2022
  11. May 2022
  12. Apr 2022
    1. Caution: + continues the statement but not the string. puts "foo"+"bar".upcase gives you fooBAR, whereas puts ("foo"+"bar").upcase gives you FOOBAR. (Whether or not there's a newline after the +.) But: if you use a backslash instead of the plus sign, it will always give you FOOBAR, because combining lines into one statement, and then combining successive strings into one string, happen before the string method gets called.
    1. These callbacks are focused on the transactions, instead of specific model actions.

      At least I think this is talking about this as limitation/problem.

      The limitation/problem being that it's not good/useful for performing after-transaction code only for specific actions.

      But the next sentence "This is beneficial..." seems contradictory, so I'm a bit confused/unclear of what the intention is...

      Looking at this project more, it doesn't appear to solve the "after-transaction code only for specific actions" problem like I initially thought it did (and like https://github.com/grosser/ar_after_transaction does), so I believe I was mistaken. Still not sure what is meant by "instead of specific model actions". Are they claiming that "before_commit_on_create" for example is a "specific model action"? (hardly!) That seems almost identical to the (not specific enough) callbacks provided natively by Rails. Oh yeah, I guess they do point out that Rails 3 adds this functionality, so this gem is only needed for Rails 2.

    1. If I create a model ActiveRecord sends NULL values for every field that is not defined. Postgres dutifully writes the NULL value into the field instead of the default value. Activerecord should either send nothing (preferable) or send DEFAULT.
  13. Mar 2022
    1. Use apt as a first choice, but if you're scripting use apt-get. Apt-get has more stable output (meaning that the output format is left alone as much as possible so as not to break scripts which parse that output automatically). Apt-get also has some low-level commands not available in apt.
  14. Feb 2022
    1. "Context" manipulation is one of big topic and there are many related terminologies (academic, language/implementation specific, promotion terminologies). In fact, there is confusing. In few minutes I remember the following related words and it is good CS exam to describe each :p Thread (Ruby) Green thread (CS terminology) Native thread (CS terminology) Non-preemptive thread (CS terminology) Preemptive thread (CS terminology) Fiber (Ruby/using resume/yield) Fiber (Ruby/using transfer) Fiber (Win32API) Generator (Python/JavaScript) Generator (Ruby) Continuation (CS terminology/Ruby, Scheme, ...) Partial continuation (CS terminology/ functional lang.) Exception handling (many languages) Coroutine (CS terminology/ALGOL) Semi-coroutine (CS terminology) Process (Unix/Ruby) Process (Erlang/Elixir) setjmp/longjmp (C) makecontext/swapcontext (POSIX) Task (...)
  15. Jan 2022
    1. const rejectedP = Promise.reject('-'); const finallyP = rejectedP.finally(); const result1 = rejectedP; const result2 = new Promise(resolve => { const rejectedP = Promise.reject('-'); const finallyP = rejectedP.finally(); resolve(rejectedP); }); we can see that the first snippet creates two promises (result1 and rejectedP being the same) while the second snippet creates three promises. All of these promises are rejected, but the rejectedP rejection is handled by the callbacks attached to it, both through ….finally() and resolve(…) (which internally does ….then(resolve, reject)). finallyP is the promise whose rejection is not handled in the both examples. In the second example, result2 is a promise distinct from rejectedP that is also not handled, causing the second event.
    1. You basically did var a = promise.then(…); var b = promise.catch(…); creating a branch in the chain. If promise is getting rejected now, the catch callback will be called and b will be a fulfilled promise just fine, but the a promise is getting rejected too and nobody handles that. Instead, you should use both arguments of then and write Requirement.create({id: id, data: req.body.data, deleted: false}) .then(requirement => { res.json(requirement); }, reason => { let err = {'error': reason}; res.json(err); });
  16. Sep 2021
  17. Apr 2021
    1. They cause completely different behavior for auto margins. If you have a fixed element for example with top/bottom/left/right set to zero and you stick an image in it you want to center wrapped in a div, then in order to center that div with auto margins, you MUST specify a CSS width/height, because specifying an HTML attribute width/height has no effect and the margins remain zero. I have no idea why the difference exists.
    1. Some humor is just funny on a surface level, or incorporates words that sound funny. What makes dry humor unique is that it isn't always obviously funny, especially with a deadpan delivery; you often need to think about it. The humor is entirely within the meaning of the words.
    1. Few real decisions to make....Not in my experience, either in tile placement or in disk placement. Of possible interest is the thread:Informal experiment: how easy to find "the optimal disk placement" in various positions?wherein we see that even in the second phase, which people often complain is "automatic" or "obvious", the decisions are not necessarily obvious.
    1. Requirement #2 contains an unwarranted assumption. The body needs to flow not around the sidebar, but around the sidebar's position. That may seem like splitting hairs, but it isn't -- because what if there were something floated where we want to put the sidebar? The body would flow around that space. If we could put the sidebar in that same location, we'd have a solution.
  18. Mar 2021
  19. Feb 2021
  20. Dec 2020
  21. Nov 2020
  22. Oct 2020
  23. Sep 2020
    1. I’ve seen some version of this conversation happen more times than I can remember. And someone will always say ‘it’s because you’re too used to thinking in the old way, you just need to start thinking in hooks’.

      But after seeing a lot of really bad hooks code, I’m starting to think it’s not that simple — that there’s something deeper going on.

  24. Jul 2020
    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.
  25. Apr 2017
    1. Borgia-like

      The House of Borgia was an Italo-Spanish family who rose to power underhandedly during the Renaissance. Although they influence two popes being elected, they were suspected of many murders by poisoning, as this painting by John Collier "A glass of wine with Ceasar Borgia" shows the hesitancy in the young man about to have his wine glass filled with possibly poisonous wine. Sara Willis here relates to Thoreau's disdain for those who seek to destroy their opponents and obtain a majority who makes all of the important decisions.