Search for a command to run...
I am an iOS Developer from Egypt, Cairo who likes Apple Products and UX studies
I enjoy reading about Entreprenuership and Scrum.
When no one is looking, I like to play around with Figma and build tools/ideas to help me during get things done quickly.
And I keep repeating epic gaming moments over and over again in my head and repeat narratives out loud in my room to regain a glimpse of how it felt when I first saw it (without altering the script)
No comments yet. Be the first to comment.
Navigating the Complexities of Domain-Driven Design: Bridging Tech and Business with Clarity and Bounded Contexts
And the start of a Journey with another DDD Book
How Command Pattern can be easily translated to Siri features
Breaking the Chains of Massive View Controllers: Lessons for SwiftUI and Beyond
A New day... a new productive day where my tiny blog gains a new post! https://tenor.com/view/terrific-tuesday-gif-25021333 Today is a bit of a quick one, its about a productivity tip you can imply if you work a lot with terminals, so without furth...
Today was my first session in Lint-School, we talked about Git and why it is so important in the life of developers.
We talked about how important Gitflow is and why it could save you countless hours of solving merge conflicts, as well as making your Pull Requests short
if you want to know more about GitFlow, I'd recommend this tutorial.
we also learned that PRs (pull requests) are not just for show, they help maintain trust between team members, another eye for catching bugs, forcing discussions and set coding guidelines.
But that's not enough. when a PR is long, people tend to skim it over and give you an "over-the-surface" review
So a golden rule of thumb is to make sure your PR is a work of a day or less if it takes more than a day, u should break it down to a couple of PRs.
This starts from the way you start working on a certain feature, you need to read the feature, make sure you understand it correctly and start breaking it down to smaller features, each feature with their own branch and their respective PR
this way we get better code reviews, and less "looks fine."
We also talked about the importance of CI/CD workflow in your work with Git CI/CD is a productivity beast that takes too little time to deploy and its gains are tremendous
Coming from an iOS background, when deploying builds to testers and to the store, we go through a process called archiving, it's a long process and usually produces a big file which you have to upload, with a bad internet, this process becomes tedious, also the fact that you have to constantly produce a build to testers so they can test is a pain.
By setting up CI/CD you solve such problems by setting configurations to each pipeline, for example in Git-flow we have 5 pipelines, Master-Develop-Feature-Release-Hotfix
each pipeline should do something when an event happens from the perspective of CI/CD an event is on push, merge, pull request
for example, when a pull request is opened to the develop from a feature branch, build the project and make sure tests run, if not, deny merge if a merge occurs on the release, push a build to testers
Git is an essential tool that any developer has to learn, but learning it alone is not enough for big teams, Git-Flow helps in enhancing the process of version control, even better is applying the CI/CD to your workflow, those are the three levels of any git user
