75 Matching Annotations
  1. Jul 2025
    1. Don't rely on an inbox, comprehensive indexes, or backlinks When writing notes for your Zettelkasten, it's natural to feel some anxiety about whether you're just writing into the void, or whether you'll actually stumble across those notes again in the future. To relieve this anxiety, there are at least three tempting solutions that seem to make sense on the surface, but which tend to fall apart in the long term.

      Mis blikis me permiten reencontrar la información fácilmente y los consulto/referencio con frecuencia. En particular para ofrecer información que solicitan una y otra vez, como hojas de vida y portafolios de proyectos.

      Si bien a veces creo índices con otros tiddlers, en general confío y uso los sistemas de etiquetados y de búsqueda que ya vienen incorporados en la herramienta para reencontrar la información y el sistema de filtros y operadores para ofrecer vistas específicas de la misma a terceros, como mi portafolio o mi perfil.

      No reorganizo la información en publicaciones más grandes y lineales como artículos o libros, como lo haría Luhmann, básicamente por dos cosas:

      1. me gusta estar lejos de las mafias de publicación académica clásica y sus circuitos y
      2. quisiera que las publicaciones vivas, tipo wiki, blikis, datasets y repositorios de código tuvieran un estatus epistémico en sí mismo, sin tener que tomar la forma de las publicaciones académicas clásicas que han sido tan gentrificadas.

      Lo anterior requerirá otras métricas, en las cuales vamos trabajando lento.

    1. Take Wikis as an example. Most of them have two different modes: The reading mode. The editing mode. The reading mode is the default. But most of the time you should create, edit and re-edit the content. This default, this separation of reading and editing, is a small but significant barrier on producing content. You will behave differently. This is one reason I don’t like wikis for knowledge work. They are clumsy and work better for different purposes.

      Los blikis (blogs + wikis) son formas de pensar en público y tener modos de lectura y escritura está bien, pues no todos los que se aproximan al wiki lo van a editar y la mayoría de internautas sólo lo va leer.

      Además sistemas tipo TiddlyWiki (y en el futuro Cardumem) alientan en buena medida la reedición de unidades de contenido (wiki refactoring). Lo clave es que las unidades sean pequeñas y se puedan usar para organizar otras unidades (es decir usarlos como etiquetas).

  2. Jun 2025
    1. Before writing component tests, think about whether you actually need to test the component, or if it’s more about the logic inside the component. If so, consider extracting out that logic to test it in isolation, without the overhead of a component
  3. Apr 2025
    1. A lot of it feels like someone who doesn’t like the old code and wants to do it “right.” I can agree that the old code is ugly. But it will take an awful lot of effort to make a new implementation. It’s a lot like what happened to Elvis: A rewrite was going to make it much better, but it took so long, during which Vim added more features, that eventually there are not so many Elvis users. And the rewritten Elvis may have nice code, but users don’t notice that.
  4. Feb 2025
    1. Feature Branching also discourages developers from making changes that aren't seen as part of the feature being built, which undermines the ability of refactoring to steadily improve a code base.
    1. Most companies where I worked have a history of rebuilding their applications every 3 to 5 years, some even 2 years. This has extremely high costs, it has a major impact on how successful the application is, and therefore how successful the company is, besides being extremely frustrating for developers to work with a messy code base, and making them want to leave the company. A serious company, with a long-term vision, cannot afford any of it, not the financial loss, not the time loss, not the reputation loss, not the client loss, not the talent loss.
  5. Aug 2024
  6. Jan 2024
  7. May 2023
    1. ake sure you are mentoring someone, always. Make sure you’re always mentoring others. And I have found that mentoring others gives me new perspectives on things. Because I may be telling them things, but I’m learning a lot while I’m telling them.

      Great

  8. Apr 2023
  9. Jan 2023
    1. ExportProcessControl

      This can (should) be parameterized—not just here, but in the procurement constructor.

  10. Sep 2022
    1. I have refactored the schema to use allOf, oneOf, and unevaluatedProperties, which not only dramatically shrank the file (1500 lines down to 845) but allowed a different approach consisting of a number of "mix-in" schemas grouping commonly used fields, which are then referenced throughout a set of object schemas.
  11. May 2022
    1. By offering to have a real-time technical discussion, you are reframing the code review process away from an 'instructor correcting student' dynamic and into a 'colleagues working together' mindset.
    1. Level 5: Stop the line. The highest level of code review comments. Borrowing the term from Toyota's manufacturing process this is when the code reviewer noticed something in the PR that signals a major defect.

      Stop the line - 5th type of MR comments

    2. Level 4: Infringement. This is where things get more serious, note that infringement means rules were broken. In this context, rules can mean a number of things, from the more obvious feature spec and framework rules to things like style guides and coding principles.

      Infringement - 4th type of MR comments

    3. Level 3: Suggestions. These can also be thought of as recommendations and alternatives.

      Suggestions - 3rd type of MR comments

    4. Level 2: Nitpicks. Usually, comments about grammar errors and minor stylistic issues/typos go there. The solution to the nitpicks is usually very obvious and if the solution is opinionated, the opinion is not strongly held. Naming a method foobarGenerator vs foobarFactory goes in here, and nitpick comments often start with Nitpick:.

      Nitpicks - 2nd type of MR comments

    5. Level 1: Clarifications. I also think of these as sanity checks, I may even start the comment with something like I may be completely off the base here... or Just to sanity check...

      Clarifications - 1st type of MR comments

  12. Jan 2022
    1. and if I think this is too boilerplatey, I can export a handler from some .js file and pass the error to that: <script> import { onError } from 'svelte' import { genericHandler } from '../my-error-handler.js' onError(genericHandler(e => { // code which is called first to try to handle this locally return true // we've handled it here, don't do anything else. }) </script>
  13. Nov 2021
    1. Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.
    1. The consumer component will barely change from our last example. The only difference is the way we'll get a reference to our store (since now the store is exported from the JS module):
    2. In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:
    3. // our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }
    4. Here's how we would rewrite our callback example with a store instead:
  14. Jul 2021
  15. test-prof.evilmartians.io test-prof.evilmartians.io
    1. That's it! Just replace let! with let_it_be. That's equal to the before_all approach but requires less refactoring.
    2. That technique works pretty good but requires us to use instance variables and define everything at once. Thus it's not easy to refactor existing tests which use let/let! instead.
  16. Jun 2021
    1. I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.
    2. Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.
    3. But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.
  17. Apr 2021
  18. Mar 2021
    1. The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.
    1. Refactoring is a means of addressing the problem of software rot. It is described as the process of rewriting existing code to improve its structure without affecting its external behaviour.
    1. Unfortunately, given how widely used concat_javascript_sources is, this required changing a lot of tests. It would be nice if we could remove some of the duplication in these tests (so that similar changes would not require updating this many tests), but that can come in another PR.
  19. Feb 2021
  20. Jan 2021
  21. Dec 2020
  22. Nov 2020
    1. Refactoring at scale is challenging and a significant investment, so communicating the progress is important both from a business perspective but also as a motivational effect to developers. In this case we used a combination of complexity trend visualizations and Code Health Metric as shown in the preceding example.

      [[refactoring at scale]]

    1. I refactored quite a bit of tarball-fetcher now to use actual Promises and asyncawait instead of passing resolve / reject callbacks around. This makes the code quite a bit easier to follow in my opinion, but let me know if anything should be changed there.
    2. I know this is existing code but we can probably use this as an opportunity to "fix" it: it is discouraged to use the async exists method to check for a file and try operating on it.
  23. Oct 2020
    1. Derived data can move between being synchronous and asynchronous without modifying the components that use it.
    2. State can be replaced with derived data without modifying the components that use it.
  24. Sep 2020
    1. This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:
    1. When a component reaches such a size that this becomes a problem, the obvious course of action is to refactor it into multiple components. But the refactoring is complex for the same reason: extracting the styles that relate to a particular piece of markup is an error-prone manual process, where the relevant styles may be interleaved with irrelevant ones.
    1. Primitives are often used to “simulate” types. So instead of a separate data type, you have a set of numbers or strings that form the list of allowable values for some entity. Easy-to-understand names are then given to these specific numbers and strings via constants, which is why they’re spread wide and far.
  25. Jul 2020
    1. It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.
  26. Jun 2020
    1. Prefactoring is the application of experience to the creation of new software systems. Its relationship to its namesake refactoring is that lessons learned from refactoring are part of that experience.
    1. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.

      First sighting: "non-functional attributes".

  27. May 2020
  28. Apr 2020
    1. If you'd just like to see refactorings without Quick Fixes, you can use the Refactor command (Ctrl+Shift+R).

      To easily see all the refactoring options, use the "Refactor" command

  29. Apr 2019
    1. What is code refactoring?Code refactoring means restructuring your existing code, in a way that improves the internal structure but doesn’t change its external behavior. This complex procedure is aimed at modernizing software. It is typically used to increase the system’s maintainability, enhance performance, scalability, security and so on. If performed well, it can help developers discover some hidden bugs or vulnerabilities in the system.Typically, refactoring is done in small steps, called micro-refactorings. Each of these steps is usually a tiny change to a source code that leaves the functionality of the system unchanged, it just makes the code cleaner and simpler. And if you do want to change some functionality of your code, it’s much easier to do with a clean, refactored code.