https://www.arctarus.com/ Recent content on Gabriel Ortuño Hugo -- gohugo.io en © Gabriel Ortuño Sun, 03 May 2020 23:22:09 +0200 https://www.arctarus.com/notes/2020/05/the-best-code-you-can-write/ Sun, 03 May 2020 23:22:09 +0200 https://www.arctarus.com/notes/2020/05/the-best-code-you-can-write/ Code is read many more times than it is written, and its ultimate cost is often very high and paid by someone else. While it’s difficult to get exact figures for value and cost, asking the following questions will give you insight into the potential expense of a bit of code: How difficult was it to write? How hard is it to understand? How expensive will it be to change? https://www.arctarus.com/notes/2020/04/dry/ Thu, 23 Apr 2020 14:27:24 +0200 https://www.arctarus.com/notes/2020/04/dry/ Don’t repeat yourself is a principle of software development aimed at reducing repetition of code and replace it with abstractions. DRY principle says: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. If you’ve duplicated a bit of code in many places, the DRY principle tells you to extract the duplication into a single common method and then invoke this new method in place of the old code. https://www.arctarus.com/notes/2020/04/how-to-refactor/ Tue, 14 Apr 2020 23:01:39 +0200 https://www.arctarus.com/notes/2020/04/how-to-refactor/ When you have to add a new requirement to an existing code, first you should check if the code is open to the new change. Open means that the code is following the SOLID principle open for extension and closed for modification. If the code isn’t open yet, you should first refactor it to make it open, and once done you can add the new code. To refactor to make it open, you should be guided by the code smells. https://www.arctarus.com/notes/2020/04/when-to-refactor/ Sun, 12 Apr 2020 17:27:40 +0200 https://www.arctarus.com/notes/2020/04/when-to-refactor/ Refactoring is not an activity you should set time aside to do. You refactor because you want to do something else and refactoring helps you with that other thing. So, when should you refactor: The rule of three The third time you do something similar, you should refactor it. When you add a function You want to add a feature to an existing code you have written or have been written by someone else. https://www.arctarus.com/notes/2020/04/refactoring/ Sat, 11 Apr 2020 23:27:48 +0200 https://www.arctarus.com/notes/2020/04/refactoring/ Refactoring is a technique for restructuring code in a way that you improve the design, but don’t change the its external behaviour. It is done applying a serie of small transformations to the code (called a “refactor”), and using test to ensure the external behaviour never changes. Thanks that each refactor is small, if something goes wrong and a test fails, is easy go back, undo the changes, minimizing the probability that a bug can be introduced. https://www.arctarus.com/notes/2020/04/zero-bug-software-development/ Tue, 07 Apr 2020 23:31:00 +0200 https://www.arctarus.com/notes/2020/04/zero-bug-software-development/ Zero Bug Software Development is a policy to archive an state of zero known bugs. The first step to reach this state is label the issues using a very strict classification: Critical issues: The user is not receiving the value that is supposed to receive. You should stop what you are doing and fix it inmediatelly. Bugs: The app is not working as expected but the users can receive the value that is supposed to. https://www.arctarus.com/notes/2020/04/flocking-rules/ Sun, 05 Apr 2020 23:16:08 +0200 https://www.arctarus.com/notes/2020/04/flocking-rules/ The flocking rules are an small set of rules for refactoring code. The idea is make small incremental changes that allows you obtein precise error messages when something goes wrong, so if you find and error, you can revert it and make a smaller one. The steps are the following: Select the things that are most alike. Find the smallest difference between them. Make the simplest change that will remove that difference. https://www.arctarus.com/about/ Sat, 04 Apr 2020 23:21:10 +0200 https://www.arctarus.com/about/ Hello! I’m Gabriel Ortuño and this is my personal website. I’m software engineer and currently work on Cabify. Here you can find some notes I take about things I want to remember. Hope you enjoy them! https://www.arctarus.com/notes/2011/06/build-less/ Fri, 03 Jun 2011 16:34:50 +0200 https://www.arctarus.com/notes/2011/06/build-less/ So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing. Less features Less options/preferences Less people and corporate structure Less meetings and abstractions Less promises External links 37 Signals - Getting Real: Build Less Related notes What is refactoring.