Code

  • estimation in sprints are ludicrous
    Code,  Tech

    Estimations in sprints are ludicrous ?

    Estimations in sprints are ludicrous ? We switched from fibonacci complexity to just plain man day. Estimating work in sprints has become a cornerstone of Agile | Scrum methodologies More and more evidence suggests it often creates more problems than it solves. On the other hand it is a nice „form” You can wrap Your work into. It is a nice template. Teams routinely face mismatches between predicted complexity and actual time investment. Exacerbated by meetings that should be an email, administrative overhead and tasks like code reviews. The Fallacy of Sprint Estimation is why complexity metrics miss but do we have anything better ? The complexity is time disconnected…

    Możliwość komentowania Estimations in sprints are ludicrous ? została wyłączona
  • How to shutdown windows without updating
    Mini essays,  Code,  Tech

    How to shutdown windows without updating – cdm – shutdown /s /t 0

    Windows often prompts users to install pending updates during shutdown or restart. Fortunately, using the Command Prompt (cmd), you can bypass updates and shut down your system immediately. This article explains how to use the „shutdown /s /t 0” command effectively. Understanding the command The „shutdown /s /t 0” command is a simple Windows cmd instruction that forces the computer to shut down instantly without processing updates. Here’s what each parameter means: Command Description shutdown /s Shuts down the computer after a default 30-second delay (can be modified with /t). shutdown /s /t 0 Shuts down the computer immediately (similar to /p). shutdown /f Forces running applications to close without…

    Możliwość komentowania How to shutdown windows without updating – cdm – shutdown /s /t 0 została wyłączona
  • Chestertone`s Fence in coding
    Code,  Books,  Mini essays

    Chestertone`s Fence in coding and not only

    The Chestertone`s Fence in coding is the principle named after the writer G.K. Chesterton. Serves as a critical reminder in programming and software development: before removing or altering existing code, one must understand why it was implemented in the first place. This principle is universal for life. Emphasizes the importance of historical context and the potential consequences of change, especially a quick and fast one. Urging developers to approach modifications with caution and respect for prior decisions. Even if they are unknown or seem meaningless. Understanding the Chesterton`s Fence Chesterton`s Fence principle, at its core, suggests that every piece of code, no matter how outdated or unnecessary it may seem,…

    Możliwość komentowania Chestertone`s Fence in coding and not only została wyłączona
  • A Philosophy of Software Design by John Ousterhout
    Books,  Code

    A Philosophy of Software Design by John Ousterhout – review

    A Philosophy of Software Design by John Ousterhout is a great book. Period. I would say that it is a great additional to reading Clean Code. Clean code in my opinion is dry and very… strict ? Not much room to fiddle around with rules set by Uncle Bob the Guardian of the Clean Code. John Ousterhout provides us with a more kind and flexible approach without strict, dry rules to follow. Since the book was wrote by a professor at Stanford that had classes it might get a bit technical when John goes through the different code sets but it does print a better picture of the whole problem.…

    Możliwość komentowania A Philosophy of Software Design by John Ousterhout – review została wyłączona
  • How to write code part 1
    Code

    How to write code – part 1

    How to write code ? Writing Code for Future Comprehension. How to write code In the „fast-paced” world of software development is a very tricky question… The ability to „write code so in one year you or anyone else will be able to easily understand what it is about” can be a crucial skill. This practice not only enhances the longevity of your projects but also significantly improves team collaboration and code maintenance. Gives a lot less headaches also. Let’s explore why this approach is essential and how you can implement it in your coding practices. As always.. take a grain of salt with a dose of common sense… The…

    Możliwość komentowania How to write code – part 1 została wyłączona
  • How to judge code
    Code,  Mini essays

    How to judge code – part I

    How to judge code is a tricky question. With all the clean code rules, KISS, DRY, YAGNI, SOLDI and so on and so forth one can go crazy and question ones sanity in the end. What i wanted to throw out there is to judge the code be a very simple rule the encompasses multiple different one, is not straightforward and is very flexible. How to judge code ? Judge the code by how easy it is to debug We all know that one person at a company that knows all the quirks and secret sauce of a language, pipes, default interfaces and so on…. that person also knows the…

    Możliwość komentowania How to judge code – part I została wyłączona
  • Literate programming by Donald Knuth
    Code,  Mini essays,  Uncategorized

    Literate programming by Donald Knuth

    Literate programming is a programming style introduced by Donald Knuth in 1984. The focus is on explaining the logic and reasoning behind a computer program (comments) to human readers, rather than just providing instructions for the computer ( plain source code ). The key ideas are: Definition Literate programming is a programming paradigm where a computer program is explained in natural language interspersed with snippets of macros and traditional source code. Purpose Used for reproducible research and open access in scientific computing and data science. Approach Literate programming by Donald Knuth Gives programmers templates to develop programs in the order demanded by the logic and flow of their thoughts. Moving…

    Możliwość komentowania Literate programming by Donald Knuth została wyłączona
  • Computed vs ref properties in Vue
    Code

    Computed vs ref properties in Vue

    Computed vs ref properties in Vue are used to manage reactive data. There are very similar but they serve different purposes and have distinct characteristics. Here’s a detailed comparison of computed and ref. Ref To obtain a reference using Composition API, You need to provide a ref attribute with a name that matches the template ref attribute’s value: <template> <input ref=”input” /> </template>. You will be able to use the methods of the component directly in the script part of the code. Computed In-template expressions / references are very convenient, but they are meant for simple operations. Front should usually READ data, backend should do computing. Too much logic in…

  • Vitest not rendering vue component
    Code

    Vitest not rendering vue component

    Vitest not rendering vue component might be many, hugely depends on the config but what i discovered is that…. You have to UNMOUNT the component at the end of the test. Otherwise mounting it again in the next test will just not render it, like it uses some old obsolete version of the object. Best part is that the pinia store is changing as it should. The component is not rendering the html. Code example First test will always pass, second one will pass when running it alone, solo. When running both the second one will fail due to bad managment of components. I would imagine that mounting will always…

  • Typescript default parameters
    Code

    Typescript default parameters in constructor for GA

    Typescript default parameters are the same as in scala. While working on multple google analytics projects it is good to now we can hardcode part of the object and then just use the simple, single object in a constructor, without having to pass the default values. However !! Typescript default parameters should be the last on the parameter list in constructor That said the not optional, required and demanded parameters need to be first. Otherwise intellij or what ever other ide You use might complain and will NOT TELL YOU THAT. I love that small little things You assume would be obvious but then You spend a lot of time…

Piotr Kowalski