DEV Community: Emmanuel Nkrumah-Sarpong

Separate GitHub Accounts for Work and Personal Projects: A Step-by-Step Guide

Emmanuel Nkrumah-Sarpong — Wed, 05 Jun 2024 08:48:05 +0000

Intro

We will configure Git to use your work GitHub account and work SSH key for all repositories in your work directory, while using your personal account and SSH key for repositories in other directories.

With this guide you won't have to use weird Github urls or edit your ssh config.

Requirements

Make sure you have generated ssh keys for your work account and your personal account.

Let's call them id_rsa_work and id_rsa_personal respectively.

These instructions are for Mac and Linux. Windows users will have to adapt it.

Steps

1 Create a config file in your home directory called `.gitconfig-work` and put this in it.

[user]
    name = Your Name
    email = workemail@company.com
[core]
    sshCommand = "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_work -F /dev/null"

change Your Name to your name
change workemail@company.com to your work email
change ~/.ssh/id_rsa_work to the location of the ssh private key used for your work github account.

2 Open your git config at `~/.gitconfig` and put this in it

[user]
    name = Your Name
    email = personalemail@gmail.com

[core]
    sshCommand = "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_personal -F /dev/null"

[includeIf "gitdir:~/work/"]
  path = .gitconfig-work

change Your Name to your name
change personalemail@gmail.com to your personal email
change ~/.ssh/id_rsa_personal to the location of the ssh private key used for your personal github account.
make sure that .gitconfig-work is the name of the file you created in the previous step.

Conclusion

We have set up Git to use your personal GitHub account and personal SSH key as the default for all repositories on your computer, except for those in your work directory, which should use your work account and work SSH key.

Stress Driven Development

Emmanuel Nkrumah-Sarpong — Fri, 01 Sep 2023 08:46:45 +0000

You have heard of TDD, BDD, DDD and DDD (I know I said DDD twice. One is Document Driven Development (never heard of that before 5 minutes ago) and Domain Driven Development).

I present to you, Stress Driven Development (SDD), how software is written in a successful tech company near you.

Introduction

In the chaotic realm of software development, where deadlines morph into nightmares and stakeholders summon results like wizards casting spells, developers are often thrown into a whirlwind of tasks and issues. But let's set aside the predictable ways of task prioritisation for a moment and journey into the realm of absurdity: Stress Driven Development (SDD).

What is Stress Driven Development?

Picture this: developers hurrying through the office, phone lines buzzing, and the coffee machine working overtime. This, my friend, is the theatre of Stress Driven Development (SDD). Unlike the typical approaches to task prioritisation, SDD thrives on the sheer panic and frenzy expressed by the ones reporting the issues. It’s like the emergency room, but with code.

And don't forget, for the ultimate SDD experience, remote won't work. It must be served on-site, in-office, and preferably accompanied by a passionate monologue delivered right in your face. At the very least via phone call.

The Rules of SDD

Volume of Complaints Matters: In the realm of SDD, the louder the complaints, the higher the task jumps up the priority ladder. Because clearly, if someone's yelling or crying about it, it must be super critical and important to the health of the entire business.

Job Titles Influence Priority: In the wild world of SDD, your job title is your sword. If a higher-up waltzes in and utters the sacred words, "This needs fixing!", the developers bow in reverence, and the issue rockets to the top of the crisis list. After all, titles make for great emergency sirens.

Advantages of SDD

Where There's Panic, There's Progress.

Immediate Attention to Urgent Issues: Thanks to SDD, the office becomes a bustling ER room, and the most melodramatic emergencies take centre stage. Heartbeats rise and developers spring into action like a squad of black belt ninjas.

Aligning with High-Level Priorities: Prioritising tasks based on the urgency expressed by higher-ranking individuals can help align development efforts with broader business goals and objectives.

Optimal Use of Resources: Slow days become gold mines. While there's a lull in the emergency sirens, developers are free to tackle the minor glitches and quirks. Like

The Peril of Aged Dependency Packages
Eternally slow Database Response Times
The Fiasco of Failing Sandbox Environments
The Legend of Broken Git Branches
The Haunting Tale of Unreliable Third-Party APIs
The Enigma of Never-Ending Legacy Code
The Curse of Mystical Production Bugs
The Siren Song of Documentation Neglect

You know, inconsequential things like these.

Disadvantages of SDD

Bias in Prioritisation: SDD may inadvertently bias the development process towards those who are more vocal or have higher job titles, potentially overlooking valid concerns from quieter team members.

Lack of Strategic Planning: SDD’s approach to prioritisation can be likened to a game of "Whack-a-Mole" with tasks. While you’re focused on the ones popping up like popcorn, the long-term strategy might just turn into confetti.

Inconsistent Development Pace: The constantly shifting priorities under SDD might lead to an inconsistent development pace, making it difficult to maintain a stable workflow. Making it impossible to set realistic deadlines and meet them.

Conclusion

This approach isn’t as far-fetched as you might think. In the land of endless deadlines and perpetually panicking stakeholders, SDD has a seat at the table.

While we may laugh at the idea of prioritising tasks based on stress levels and job titles, let’s not forget that even in its absurdity, SDD has its moments. It might be chaotic and a tad nonsensical, but hey, it keeps some wheels turning and projects afloat.

So, as we navigate the treacherous waters of software development, it's safe to say that a more balanced and strategic approach is likely to yield more consistent and sustainable results in the world of software development.
But come on. Which business owner, marketer, customer service person (etc) wants that? We all just want our problem solved already.

Price's Law: My Path to Becoming an Overperforming Wizard

Emmanuel Nkrumah-Sarpong — Fri, 28 Apr 2023 18:14:28 +0000

If you're a software developer, chances are you've heard of Price's Law. But what does it really mean, and why does it matter? Simply put, Price's Law states that in any given field, the square root of the number of people in that field will produce half of the output.

So for example, for a company of 16 people, 50% of the work is done by 4 engineers.
For a team of 100 people, 10 engineers do half the work.
For a project of 10,000 people, 100 do half the work.

A small number of top performers are responsible for the majority of the work.

Looking at popular open source projects we see just how true Price's Law is. A study of the top 1000 contributors to the Linux kernel found that just 10% of them were responsible for over 80% of the code contributions. Similarly, a study of the top 1000 contributors to the Apache Hadoop project found that just 11% of them were responsible for over 90% of the code contributions.

As a software developer, I really fancy being one of these overperforming wizards. You know, the guys who seem to effortlessly crank out code that is miles ahead of everyone else's. The ones who push the boundaries of what is possible and leave their mark on the industry.

These numbers are staggering, and they show just how important it is to strive to be one of the top performers in our field. The question is, can anyone become an overperforming wizard, or are they just born that way?

While there is no clear-cut answer, for me, I am constantly pushing myself to learn new skills and take on challenging projects. It means seeking out mentorship and guidance, and being willing to put in the extra time and effort to produce high-quality work.

But it's not just about hard work. It's also about having a passion for software development and a DEEP understanding of the underlying technologies. Take George Hotz, for example. He became famous in the early 2000s for jailbreaking the iPhone and developing a self-driving car. His success was due in part to his incredible coding skills, but also to his deep understanding of the inner workings of technology.

Or take Michael Carmichael, another top performer in the field of software development. Carmichael is the founder of the popular open source project, the SaltStack configuration management system. His success is due to his deep knowledge of software development and his ability to build a community of contributors around his project.

The bottom line is, becoming an overperforming wizard in software development is possible, but it takes a lot of hard work, dedication, and passion. Anime has taught me that while not everyone may be born with the natural ability to excel in this field, anyone can improve their skills with practice and dedication.

I really wonder if I will ever be one of the greats. At least by my own standards.

All Articles Are Wrong, Some Are Useful

Emmanuel Nkrumah-Sarpong — Thu, 27 Apr 2023 15:35:03 +0000

As software developers, we are always foraging the internet for articles, tutorials, StackOverflow answers and blog posts hoping that they have the latest and greatest solution for our coding problems. But how many times have we found ourselves frustrated with code that doesn't work, despite following the instructions from an article or tutorial to the letter? Or worse yet, how many times have we been misled by articles that are simply incorrect?

The truth is, all articles are wrong. Every single one. No matter how well-researched, well-written, or well-intentioned an article is, there is always the possibility that it is wrong in some way. Maybe the code won't work in a certain environment, or maybe it relies on assumptions that aren't true in every case. Even articles that are factually correct can be wrong in their applicability to your specific situation.

However, just because all articles are wrong doesn't mean that they are useless. In fact, some articles can be incredibly helpful in our daily work. But how do we distinguish the useful articles from the ones that will lead us astray?

One way is to approach articles with a healthy dose of skepticism. Don't blindly follow the instructions or advice given in an article without first testing it thoroughly in your own environment. Ask yourself if the article makes sense for your specific situation, or if there are any assumptions that the article is making that don't apply to your code. And don't be afraid to question the author or reach out to the community for clarification.

Another way to determine the usefulness of an article is to consider the source. Is the author an expert in the field, or are they simply regurgitating information they found elsewhere? Is the article backed up by data or research, or is it purely anecdotal? Taking the time to evaluate the credibility of the source can help you determine if the article is worth your time and attention.

Finally, it's important to remember that no single article or source can provide all the answers. As software developers, we are constantly learning and growing, and the best way to do so is by exposing ourselves to a wide variety of opinions, ideas, and techniques. So don't be afraid to read articles that challenge your assumptions or offer a different perspective, even if you ultimately decide that they aren't useful for your specific situation.

In conclusion, all articles are wrong, but some can be incredibly useful. As software developers, it's our job to approach articles with a critical eye, test them thoroughly, and evaluate the credibility of the source. By doing so, we can continue to learn and grow in our careers, even in the face of conflicting information and opinions.

Slow is smooth, smooth is fast

Emmanuel Nkrumah-Sarpong — Wed, 05 Apr 2023 11:02:26 +0000

As a software engineer, it's easy to get caught up in the rat race of churning out code and delivering projects at warp speed. But in our pursuit of velocity, we often forget the timeless wisdom of "slow is smooth and smooth is fast."

Yes, it sounds like something a drill sergeant would say during boot camp, but the principle holds true in software engineering as well. Rushing through a project often leads to mistakes, bugs, technical debt, and delays, which can slow you down in the long run.

Instead, take the time to plan, execute, and test your code methodically. Don't be afraid to break down complex tasks into manageable pieces, and involve your colleagues and stakeholders in the development process. By prioritising quality over quantity, you can avoid the need for time-consuming fixes and rewrites down the road.

Plus, taking a slower and more deliberate approach can help you build stronger relationships with your team and stakeholders. After all, communication is key to effective software engineering, and rushing through a project often leads to misunderstandings and miscommunications.

So, next time you're tempted to hit the gas pedal and rush through a project, remember: slow and steady wins the race. By taking your time and focusing on quality, you can achieve faster, more efficient development, build stronger relationships, and maybe even impress your colleagues with your newfound wisdom.

How to install php-sqlite3 for php 8.1 on Ubuntu 21.10

Emmanuel Nkrumah-Sarpong — Fri, 17 Feb 2023 23:18:40 +0000

Installing the sqlite driver for php 8.1 on Ubuntu 21.10 should be as simple as running:

sudo apt install php-sqlite3

However if you got the error:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 php8.1-sqlite3 : Depends: php8.1-common (= 8.1.2-1ubuntu2.10) but 8.1.5-1+ubuntu21.10.1+deb.sury.org+1 is to be installed
E: Unable to correct problems, you have held broken packages.

Then you are in good company. This is how I solved. it.

Solution

NB: You should already have php 8.1 installed. Running php --version should give a result of php 8.1 and above.

1. Update your System Dependencies

sudo apt update
sudo apt upgrade

2. Add PHP PPA

sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update

3. Install php-sqlite3

sudo apt install php8.1-sqlite3

This should work now.

Acknowledgement

This article is just a copy of https://medium.com/@laraveltuts/how-to-install-and-run-php-8-x-on-ubuntu-20-04-8f18e7565c41 shamelessly specialized for fixing the unmet dependencies problem.

DEV Community: Emmanuel Nkrumah-Sarpong

Separate GitHub Accounts for Work and Personal Projects: A Step-by-Step Guide

Intro

Requirements

Steps

1 Create a config file in your home directory called .gitconfig-work and put this in it.

2 Open your git config at ~/.gitconfig and put this in it

Conclusion

Stress Driven Development

Introduction

What is Stress Driven Development?

The Rules of SDD

Advantages of SDD

Disadvantages of SDD

Conclusion

Price's Law: My Path to Becoming an Overperforming Wizard

All Articles Are Wrong, Some Are Useful

Slow is smooth, smooth is fast

How to install php-sqlite3 for php 8.1 on Ubuntu 21.10

Solution

1. Update your System Dependencies

2. Add PHP PPA

3. Install php-sqlite3

Acknowledgement

1 Create a config file in your home directory called `.gitconfig-work` and put this in it.

2 Open your git config at `~/.gitconfig` and put this in it