[{"content":"Git with Github is probably the most widely used version control systems across enterprises, all throughtout the world. As a developer, I have had my far share of working with Git throughout my career. In this post, I will be listing some practices and configurations that have helped me improve my productivity with Git.\nBranch Protection Rules As a person who has prefers Trunk Based Development, my concern when setting up a multi-user code repository will usually be how I could prevent accidental force pushes, deletions, how other teams should make changes to my code and how it should be accepted, etc.\nTo address this, Github has the provision to setup branch protection rules. This setting allows you to specify who can force push, disable branch deletion, mandate commit signing, setup status checks for merges etc, based on a branch name or a branch name pattern. We can set this up by going to the Settings tab on the Github repository.\nCheck out the how to setup branch protection and the various rules you can add to your repository on Github.\nAuto Stash When working with Git, I used to have some difficulty getting my branch up to date, if my working directory was dirty with some changes. I would end up stashing those changes, pulling from remote to bring my working directory up-to-date, and then popping the stashed changes again.\nI longed for this to be automated, and that\u0026rsquo;s when I discovered the autostash option with git.\nTo enable autostashing on pulls, we can run\ngit config rebase.autoStash true # If your default pull behavior is to rebase git config merge.autoStash true # If your default pull behavior is to merge All though there could be some conflicts between the pulled and stashed changes, we should easily be able to resolve them.\nCommand Line Aliases I usually use the command line to work with Git in my projects. Since I usually use a Macbook for development with a ZSH kernel, I found it easy to setup oh-my-zsh with the git plugin. The plugin powers my command line with a comprehensive list of aliases for git commands.\nNow instead of typing in\ngit checkout -b new-branch git push --set-upstream origin new-branch I can just do\ngco -b new-branch gpsup Git Hooks A usual practice with git is to use git hooks to perform some custom operations like linting, running tests before push, detecting and installing dependencies etc. This can help us set up some code quality assurance and provides confidence on the standard of code we push.\nSince I work mostly on JavaScript based projects, I found Husky to be very useful and easy to set up git hooks on these projects.\nThese were some practices that improved my development flow with Git\n","permalink":"https://noggin.vedant-ships.in/posts/git-best-practices/","summary":"\u003cp\u003eGit with Github is probably the most widely used version control systems across enterprises, all throughtout the world.\nAs a developer, I have had my far share of working with Git throughout my career. In this post, I will be listing some\npractices and configurations that have helped me improve my productivity with Git.\u003c/p\u003e\n\u003ch2 id=\"branch-protection-rules\"\u003eBranch Protection Rules\u003c/h2\u003e\n\u003cp\u003eAs a person who has prefers \u003ca href=\"https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development\"\u003eTrunk Based Development\u003c/a\u003e, my concern when setting up a multi-user code repository will usually be\nhow I could prevent accidental force pushes, deletions, how other teams should make changes to my code and how it should\nbe accepted, etc.\u003c/p\u003e","title":"Streamlining Development with Git and Github"},{"content":"As a software developer, I had vaguely heard of the term \u0026ldquo;Domain Driven Design\u0026rdquo; thrown around in my office circle, but I never completely understood what exactly it is. In my quest to figure out what it was, I uncovered a video on YouTube by Eric Evans, who also basically came up with this concept in one of his books. This post is my attempt to list my takeaways from this video and my opinions on Domain Driven Design in general.\nThe Pitch In the beginning stages of my career as a developer, I had a narrow vision when developing software. I saw the whole process as a version of \u0026ldquo;passing the buck\u0026rdquo; - the business folks would make some decisions and hand it over to the experience designers, they would design a user experience and hand it over to us devs, and we would mindlessly write code and pass it over to the QA peeps, all this done with no cohesion.\nDue to this, our team would often run into problems. We would develop a whole feature only to end up with a disappointed client, because our development process was based on misunderstandings.\nThat\u0026rsquo;s where DDD could possibly have helped\nThe Approach DDD aims to unify the language between development and business. The language of the domain should be the basis of modelling the software, since we aim to address the problems of the domain.\n\u0026ldquo;Domain: A sphere of knowledge / activity\u0026rdquo;\n\u0026ldquo;Model: System of abstractions representing selected aspects of the domain\u0026rdquo;\nUnderstanding the domain is the most complex part of a software projects. So, it makes sense to have the domain as the core for the project, and build everything else on top of it, since \u0026ldquo;Architecture is the stuff that’s hard to change later.\u0026rdquo;\nOne of the main emphasis of DDD is the use of a Ubiquitous Language, which is to be used by all team members to connect all activities of the team with the software, within a bounded context. The idea is that if everything is structured around the language, there would be a lesser scope for misunderstandings\nMy DDD Encounters After going through the video and looking up some articles, I realized that some tasks that I had worked on recently, could potentially have been us implementing DDD approaches. I had been using DDD to a certain extent, even without my knowledge!\nOne of the tasks was some refactoring we did. We moved around some files and folders and structured them based on their domains, since our team had subteams, each who owned a domain.\nAnother task was around the UI Design components we used. We had a UI library on Figma which consisted of multiple input/presentation elements like Text Box, Select Box etc. These would translate in to JSX Elements for us since we were using React, but the names we had for our React components were not connected to the names of the UI Elements, which would cause some confusion when we talked with our UI Designers. So the dev team took up the task of reorganizing the JSX Elements to name and organize them to what the domain dictated, so that it was in sync with the UI Elements.\nDDD for the win From what I\u0026rsquo;ve learnt and experienced, DDD definitely seems to be a powerful approach to software development. By placing the domain at the center of the design process, DDD enables developers to create software that is better aligned with the needs of the stakeholders.\nReferences https://www.youtube.com/watch?v=pMuiVlnGqjk\n","permalink":"https://noggin.vedant-ships.in/posts/ddd-encounter/","summary":"\u003cp\u003eAs a software developer, I had vaguely heard of the term \u0026ldquo;Domain Driven Design\u0026rdquo; thrown around in my office circle, but I never completely understood what exactly it is.\nIn my quest to figure out what it was, I uncovered a \u003ca href=\"https://youtu.be/pMuiVlnGqjk\"\u003evideo\u003c/a\u003e on YouTube by Eric Evans, who also basically came up with this concept in \u003ca href=\"https://www.amazon.in/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215\"\u003eone of his books\u003c/a\u003e.\nThis post is my attempt to list my takeaways from this video and my opinions on Domain Driven Design in general.\u003c/p\u003e","title":"A dummy's encounter with Domain Driven Design"}]