106 Matching Annotations
  1. Nov 2023
  2. Oct 2023
    1. Any recommendations on Analog way of doing it? Not the Antinet shit

      reply to u/IamOkei at https://www.reddit.com/r/Zettelkasten/comments/17beucn/comment/k5s6aek/?utm_source=reddit&utm_medium=web2x&context=3

      u/IamOkei, I know you've got a significant enough practice that not much of what I might suggest may be helpful beyond your own extension of what you've got and how it is or isn't working for you. Perhaps chatting with a zettelkasten therapist may be helpful? Does anyone have "Zettelkasten Whisperer" on a business card yet?! More seriously, I occasionally dump some of my problems and issues into a notebook, unpublished on my blog, or even into a section of my own zettelkasten, which I never index or reconsult, as a helpful practice. Others like Henry David Thoreau have done something like this and there's a common related practice of writing "Morning Pages" that you can explore. My own version is somewhat similar to the idea of rubber duck debugging but focuses on my own work. You might try doing something like this in one of Bob Doto's cohorts or by way of private consulting sessions. Another free version of this could be found by participating in Will's regular weekly posts/threads "Share with us what is happening in your ZK this week" at https://forum.zettelkasten.de/. It's always a welcoming and constructive space. There are also some public and private (I won't out them) Discords where some of the practiced hands chat and commiserate with each other. Even the Obsidian PKM/Zettelkasten Discord channels aren't very Obsidian/digital-focused that you couldn't participate as an analog practitioner. I've even found that participating in book clubs related to some of my interests can be quite helpful in talking out ideas before writing them down. There are certainly options for working out and extending your own practice.

      Beyond this, and without knowing more of your specific issues, I can only offer some broad thoughts which expand on some of the earlier discussion above.

      I recommend stripping away Scheper's religious fervor, some of which he seems to have thrown over lately along with the idea of a permanent note or "main card" (something I think is a grave mistake), and trying something closer to Luhmann's idea of ZKII.

      An alternate method, especially if you like a nice notebook or a particular fountain pen, might be to take all of your basic literature/fleeting notes along with the bibliographic data in a notebook and then just use your analog index cards/slips to make your permanent notes and your index.

      Ultimately it's all a lot of the same process, though it may come down to what you want to call it and your broad philosophy. If you're anti-antinet, definitely quit using the verbiage for the framing there and lean toward the words used by Ahrens, Dan Allosso, Gerald Weinberg, Mark Bernstein, Umberto Eco, Beatrice Webb, Jacques Barzun & Henry Graff, or any of the dozens of others or even make up your own. Goodness knows we need a lot more names and categories for types of notes—just like we all need another one page blog post about how the Zettelkasten method works by someone who's been at it for a week. Maybe someone will bring all these authors to terms one day?

      Generally once you know what sorts of ideas you're most interested in, you take fewer big notes on administrivia and focus more of your note taking towards your own personal goals and desires. (Taking notes to learn a subject are certainly game, but often they serve little purpose after-the-fact.) You can also focus less on note taking within your entertainment reading (usually a waste) and focusing more heavily on richer material (books and journal articles) that is "above you" in Adler's framing. You might make hundreds of highlights and annotations in a particular book, but only get two or three serious ideas and notes out of it ultimately. Focus on this and leave the rest. If you're aware of the Pareto principle or the 80/20 rule, then spend the majority of your time on the grander permanent notes (10-20%), and a lot less time worrying about the all the rest (the 80-90%).

      In the example above relating to Marx, you can breeze through some low level introductory material for context, but nothing is going to beat reading Marx himself a few times. The notes you make on his text will have tremendously more value than the ones you took on the low level context. A corollary to this is that you're highly unlikely to earn a Ph.D. or discover massive insight by reading and taking note posts on Twitter, Medium, or Substack (except possibly unless your work is on the cultural anthropology of those platforms).

      A lot of the zettelkasten spaces focus heavily on the note taking part of the process and not enough on the quality of what you're reading and how you're reading it. This portion is possibly more valuable than the note taking piece, but the two should be hand-in-glove and work toward something.

      I suspect that most people who have 1000 notes know which five or ten are the most important to where they're going and how they're growing. Focus on those and your "conversations with texts" relating to those. The rest is either low level context for where you're headed or either pure noise/digital exhaust.

      If you think of ideas as incunables, which notes will be worth of putting on your tombstone? In other words: What are your "tombstone notes"? (See what I did there? I came up with another name for a type of note, a sin for which I'm certainly going to spend a lot of time in zettelkasten purgatory.)

  3. Sep 2023
    1. Start with the default gemfile: gem "rails", "~>x.x.x" Replace the xes with the actual version of rails that you need. It'll be in config/environment.rb, unless it's a Rails 3 app, in which case you can just put 3.0.0. Start your app, and watch for errors. When there's an error about not being able to load something, add that gem to the gemfile. Eventually, you'll have the whole list. :)
  4. Aug 2023
  5. Jul 2023
    1. recommend disabling optimizations when building the code being debugged

      debugging should be done with compiler optimizations disabled

  6. Jun 2023
    1. Another point is that properties are good in that you can place breakpoints in them to capture getting/setting events and find out where they come from.
  7. Apr 2023
  8. Mar 2023
  9. Feb 2023
    1. “[It's] an amazing tool for brainstorming or rubber-ducking. Its conversational quality is perfect to talk about plot, characters and worldbuilding.”- Nelly Garcia

      Presumably the use of rubber-ducking here is an indicator of Nelly Garcia's background with programming and prior AI tool use?

      The rubber duck as a writing partner?

    2. We've also integrated a chatbot feature into the app to enable unstructured conversation about the story being written.

      Presumably being used for rubber ducking?

      Was it also used as research feedback for the program itself?

  10. Jan 2023
    1. Among other things, I have traditionally used my Journal to think out loud to myself about my work in hand: the progress I’m making, the problems I’m encountering, and so on. Many of my best ideas have arisen by writing to myself like this.

      Richard Carter uses his writing journal practice to "think out loud" to himself. Often, laying out extended arguments helps people to refine and reshape their thinking as they're better able to see potential holes or missing pieces of arguments. It's the same sort of mechanism which is at work in rubber duck debugging of computer code: by explaining a process one is more easily able to see the missing pieces, errors, or problems with the process at hand.

      Carter's separate note taking and writing journal practice being used as a thought space or writing workshop of sorts is very similar to the process seen in my preliminary studies of Henry David Thoreau's work in which he kept commonplace books and separate (writing) journals which show evidence of his trying ideas on for size and working them before committing them to his published works.

  11. Nov 2022
    1. Set the endpoint to Mailgun's Postbin. A Postbin is a web service that allows you to post data, which is then displayed through a browser. This allows you to quickly determine what is actually being transmitted to Mailgun's API.
    1. Nobody ever says rubber ducky debugging involves writing memos to your preferred duck, after all.

      Seemingly both rubber duck debugging and casual conversations with acquaintances would seem to be soft forms of diffuse thinking which may help one come to a heuristic-based decision or realization.

      These may be useful, but should also be used in combination with more logical, system two forms of decision making. (At least not in the quick, notice the problem sort of issues in which one may be debugging.)

  12. Oct 2022
  13. Sep 2022
    1. Moreover, because the entire language and development system are available, unrestricted, in the repl, you can define the missing function bar, resume foo, and get a sensible result.

      This seems like one of the key points. The ability to edit computations while running. Type holes with resuming gets you most of the way there but there's probably also modifications. I wonder how you can keep it from getting confusing. Something similar to FRP?

  14. Aug 2022
  15. Jul 2022
    1. I may had to turn it off and on again a few times as debugging technique when I had no other ideas on what to do.
    1. Debugging is the process of finding and removing errors (bugs) from a software program. Bugs occur in programs when a line of code or a statement conflicts with other elements of the code. We also call errors or defects in hardware bugs.

      Debugging and debugging software

      Debugging is the process of finding and removing errors (bugs) from a software program. Bugs occur in programs when a line of code or a statement conflicts with other elements of the code. We also call errors or defects in hardware bugs.

  16. Jun 2022
    1. Or else, imagine the need to instruct someone in a piece of learningyou possess.

      Barzun suggests using a rubber duck debugging approach to writing as motivation for getting started.

    Tags

    Annotators

    1. No one had to read or respond to what these peoplewrote down—the benefits came just from the act of writing

      Benefit of writing things down

      link this to - rubber duck debugging - https://hypothes.is/a/beiGPOFOEeySP3__4Mj_0w - benefits of talking to a therapist - others? - morning pages

    Tags

    Annotators

  17. May 2022
    1. a constellation already described in 1805 by Heinrich von Kleist in his fascinat-ing analysis of the “Midwifery of Thought”: “If you want to know something and cannotfind it through meditation, I advise you, my dear, clever friend, to speak about it withthe next acquaintance who bumps into you.” 43 The positive tension that such a conversa-tion immediately elicits through the expectations of the Other obliges one to producenew thought in the conversation. The idea develops during speech. There, the sheeravailability of such a counterpart, who must do nothing further (i.e., offer additionalstimulus through keen contradiction of the speaker) is already enough; “There is a specialsource of excitement, for him who speaks, in the human face across from him; and agaze which already announces a half-expressed thought to be understood often givesexpression to the entire other half.”44
      1. Heinrich von Kleist, “Ü ber die allm ä hliche Verfertigung der Gedanken beim Reden,” in Sämtliche Werke und Briefe. Zweiter Band, ed. Helmut Sembdner (M ü nchen: dtv, 1805/2001), 319 – 324, at 319.
      2. Ibid., 320.

      in 1805 Heinrich von Kleist noted that one can use conversation with another person, even when that person is silent, to come up with solutions or ideas they may not have done on their own.

      This phenomena is borne out in modern practices like the so-called "rubber duck debugging", where a programmer can talk to any imagined listener, often framed as a rubber duck sitting on their desk, and talk through the problem in their code. Invariably, talking through all the steps of the problem will often result in the person realizing what the problem is and allow them to fix it.

      This method of verbal "conversation" obviously was a tool which indigenous oral cultures frequently used despite the fact that they didn't have literacy as a tool to fall back on.

  18. Apr 2022
    1. ```js function useTraceUpdate(props) { const prev = useRef(props); useEffect(() => { const changedProps = Object.entries(props) .reduce((ps, [k, v]) => { if (prev.current[k] !== v) { ps[k] = [prev.current[k], v]; } return ps; }, {}); if (Object.keys(changedProps).length > 0) { console.log('Changed props:', changedProps); } prev.current = props; }); }

      // Usage function MyComponent(props) { useTraceUpdate(props); return <div>{props.children}</div>; } ```

    1. I feel like better code visualization would solve a lot of my problems. Or at least highlight them.

      The other commenter talks about a typical sw.eng. approach to visualization (flame graphs), but I want programs visualized as a manufacturing/packing/assembly line on a factory floor. Almost like node editors like Unreal's Blueprints, but in three dimensions, and shit visibly moving around between tools on the line in a way that you can actually perceive. Run the testcase on a loop, so you have a constant stream of "shit visibly moving around", and it runs at fractional speed so the whole process takes, say 10 seconds from front-to-back instead of near instantaneously like it normally would (and allow the person who's debugging to control the time scaling, of course). You find bugs by walking the line and seeing, "oh, man, this purple shit is supposed to be a flanged green gewgaw at this point in the line", so you walk over and fix it.

      (This is what I want VR to really be used for, instead of what's capturing people's attention today—games and lame substitutes for real world interaction like Zuckerberg is advocating for.)

  19. Mar 2022
    1. Add a rule to /lib/udev/rules.d/69-libmtp.rules just after LABEL="libmtp_usb_rules": ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0f91", RUN+="/bin/sh -c 'env >> /home/username/udev-phone-mtp_%E{SEQNUM}.log'"
  20. Feb 2022
  21. Jan 2022
  22. Nov 2021
  23. Sep 2021
    1. Some studies Paul cites show that the other students don’t even necessarily need to exist: if we have a sense of an audience and can imagine teaching them, that imagined teaching itself has benefits for learning.

      Any relationship to the idea of rubberduck debugging?

    1. Another effective technique is to start your notetaking by writing a short summary of each chapter and transcribing any meaningful passages or phrases. If you are unsure how to simplify your thoughts, imagine that someone has tapped you on the shoulder and asked you to explain the chapter you just finished reading. They have never read this book and lack any idea of the subject matter. How would you explain it to them?

      The so-called Richard Feynman technique, n'cest pas?

      From whom did he crib it? Did he credit them, or was it just distilled into part of the culture?

      This is also similar to the rubber duck method of debugging a program in some sense.

  24. Jul 2021
    1. in my case having the browser clearing it's network-tab and the reason for the next request beeing due to "Initiator: document" should have been a clue. (meaning: it's not done by some JS, but by some html functionality)
  25. Jun 2021
  26. May 2021
    1. In his “On the gradual fabrication of thoughts while speaking,” Kleist was in turn musing on Immanuel Kant’s metaphor of the teacher as the midwife at the birth of the student’s thought. When stuck in developing a thought, Kleist recommends, find an acquaintance to talk at. No responses are required. The mere presence of the silent interlocutor, and even more so the imminent threat of losing their attention during lengthy stretches of boredom or incoherence will trigger, or so Kleist claims, the “fabrication of my idea in reason’s workshop.”

      This sounds a lot like a broader case than rubber duck debugging, which is obviously not a "new" thing.

  27. Mar 2021
    1. If you built vim against Qt rather than GTK+ and python-complete still isn't working, that suggests the problem isn't actually a consequence of trying to link to both GTK+2 and GTK+3.
    1. If still doesn't work. Make desktop file runnable in terminal by changing Terminal=true, and put it inside a bash script. Run the script to catch the error output. Change back when errors are corrected.
    1. I used this in the console to find the file and the line of the error (took it from this answer): JS_PATH = "app/assets/javascripts/**/*.js"; Dir[JS_PATH].each do |file_name| puts "\n#{file_name}" puts Uglifier.compile(File.read(file_name)) end

      Didn't work for me because it was actually a .coffee file.

      So I tried something similar with this:

      main > Dir["*/assets/javascripts/**/*.coffee"].each { |file_name| puts "\n#{file_name}"; Sprockets::CoffeeScriptProcessor.(filename: file_name, data: File.read(file_name), cache: {}); }
      
      app/assets/javascripts/bootstrapped.js.coffee
      NoMethodError: undefined method `config' for nil:NilClass
      from /home/tyler/.gem/ruby/2.7.1/gems/sprockets-4.0.2/lib/sprockets/source_map_utils.rb:40:in `format_source_map'
      

      but it wasn't as trivial to provide the necessary environment that Sprockets wants.

      But that's okay, when better_errors paused on the exception, I just jumped to the

      block in Sprockets::CoffeeScriptProcessor.call
      sprockets (4.0.2) lib/sprockets/coffee_script_processor.rb, line 24
      

      frame and evaluated

      input[:filename]
      

      to figure out which file had failed.

      Obviously this information should be part of the error message itself though!!

    1. Having an understanding of higher level abstractions, such as tasks, activities and the historical code path taken, its debugging trace is much closer to how you, as an engineer, think about your code.
    2. This is my absolute favorite feature ever and the official reason for (re-)writing Trailblazer 2.1. It makes me happy every time I use it.
  28. Feb 2021
    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. To tell you the truth, the new tracing feature was the original reason why I decided to write 2.1 and make you sit and wait in agony for years. Nevertheless, tracing is simply blowing my mind. I can’t count how many hours and angering rushs of adrenaline I’ve saved since the introduction of the wtf? method and its helpful higher-level stack trace.
    1. There's a bash debugger, bashdb, which is an installable package on many distros. It uses bash's built-in extended debugging mode (shopt -s extdebug).
  29. Jan 2021
  30. atomiks.github.io atomiks.github.io
    1. It's highly recommended you inspect a tippy element via your browser's DevTools. An easy way to do this is to give it hideOnClick: false and trigger: 'click' props so that it stays visible when focus is switched to the DevTools window.
    1. LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store. In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.
  31. Nov 2020
  32. Oct 2020
    1. I’ll give you a more concrete example. I was writing a technical post yesterday. During the writing process, I found a way to make my code more efficient. When I write, I tend to analyze more than I do at any other time. I analyzed my code with a more critical eye because I wanted to offer you, the reader, the best experience. This is an experience I have had many times throughout writing on this blog.

      This also sounds very closely related to the idea of rubber duck debugging.

  33. Sep 2020
    1. But because that final CSS file is probably minified (all whitespace removed), DevTools is likely to tell us that we’ll find the declaration we’re looking for on line 1! Unfortunate, and not helpful for development.
  34. Jun 2020
    1. in Python - setting up basic logger is very simple

      Apart from printing the result, it is better to debug with logging.

      Sample logger:

      import logging
      logging.basicConfig(
          filename='application.log',
          level=logging.WARNING,
          format= '[%(asctime)s] {%(pathname)s:%(lineno)d} %(levelname)s - %(message)s',
          datefmt='%H:%M:%S'
      )
      
      logging.error("Some serious error occurred.")
      logging.warning('Function you are using is deprecated.')
      

      the sample result:

      [12:52:35] {<stdin>:1} ERROR - Some serious error occurred.
      [12:52:35] {<stdin>:1} WARNING - Function you are using is deprecated.
      

      to find its location, type:

      logging.getLoggerClass().root.handlers[0].baseFilename
      
  35. May 2020
    1. Before enabling this, you should ensure jobs are visible to team members only. You should also erase all generated job logs before making them visible again.
  36. Apr 2020
    1. Note: When you create a new virtual environment, you should be prompted by VS Code to set it as the default for your workspace folder. If selected, the environment will automatically be activated when you open a new terminal.

      After creating a new project related environment, it shall be specified as a default for this specific project

    2. Tip: Use Logpoints instead of print statements: Developers often litter source code with print statements to quickly inspect variables without necessarily stepping through each line of code in a debugger. In VS Code, you can instead use Logpoints. A Logpoint is like a breakpoint except that it logs a message to the console and doesn't stop the program. For more information, see Logpoints in the main VS Code debugging article.

      Try to use logpoints instead of print statements.

      More info: https://code.visualstudio.com/docs/editor/debugging#_logpoints

  37. Mar 2020
  38. Jan 2020
    1. If you enable the -v switch to ssh you can see what's going on: 1st command: debug1: Sending command: /bin/sh -c "cd /boot && ls -l"
    1. git -c core.sshCommand="ssh -vvv" pull

      This seems like the most reliable and direct way to enable debugging of the ssh connection (authentication, etc.) used by a git command.

  39. Dec 2019
    1. If none of these commands identified the duplication, try analyzing your bundle for multiple instances of @material-ui/styles. You can just check your bundle source, or use a tool like source-map-explorer or webpack-bundle-analyzer.
    2. server-side rendering is strict about configuration, and the best way to find out what's wrong is to compare your project to an already working setup. Check out the reference implementations, bit by bit.
  40. Nov 2019
  41. Oct 2019
  42. Aug 2019
  43. Nov 2018
    1. One quick trick for making it easier for debugging/understanding your threading macros is to put print statements in between some of the steps. The important thing to remember is that all the print functions in clojure return nil so you need to make a little helper function (I like to call mine ?) that prints and then returns the original input, like this: (defn ? [x] (prn x) x)

      debugging trick

  44. Oct 2018
  45. Apr 2018
  46. Jan 2018
    1. Default Value

      Please note that the values listed below are the default ones. An Option can represent a Boolean toggle flag (i.e. HeapDumpOnOutOfMemoryError, PrintConcurrentLocks). For such Options, '+' and '-' flags deal with Boolean toggling. In short:

      • '+' means Enable (or set to '1');
      • '-' means Disable (or set to '0').

      For example, in the table pertaining to Debugging Options, by default the -XX:-HeapDumpOnOutOfMemoryError is Disabled, because it has the - prepended to it. To actually Enable it, change that with +, yielding the variant -XX:+HeapDumpOnOutOfMemoryError.

  47. Nov 2016
    1. Vorlon.JS is a tool for remotely debugging JavaScript on any device. Use involves running a Vorlon debugging server on the machine hosting the web service and adding a script tag containing the client runtime to the page that you want to debug.

  48. Jan 2016