19 Jul 2017
When new developers are creating an online presence, they are default pointed to work and publish their code on GitHub. It’s very easy to understand why.
GitHub has by far the largest and most active user community of the repository management services available. For a detailed and relatively recent comparison of the biggest services available, this Medium post from flow.ci does a good job of illustrating how they stack up.
I’ve recently made the decision to migrate all of my code repositories from GitHub to GitLab. Here’s why:
-
Security. Specifically security around the Pages feature. GitHub Pages don’t currently support attaching SSL certificates to the sites that they host, while GitLab does.
-
Open-Sourceness. GitLab is the only major repository manager that is entirely open source. While I am by no means dogmatic about my support of open source software, I believe that this is a significant point in GitLab’s favor.
-
Respectability. GitHub has a lot of ground to make up in terms of its company culture. Julie Ann Horvath’s story of persistent and continued harassment (that caused the company’s founder to resign) in 2014 barely registered with me. I was relatively new to the tech world, and it felt like it was a million miles away.
After their internal investigation of that incident, the company made a public commitment to address what appeared to be fundamental issues with the company’s culture. From the outside, it appeared that GitHub had made strides toward being a more inclusive and less abrasive place to work.
Then on July 5th of this year, Coraline Ehmke told a tale of a GitHub that had not changed. Refusing a generous and likely necessary severance package in order to speak openly about her time there was a brave and necessary act. Her words speak for themselves, but her experience has been the primary motivator for me to utilize a different repo management service for my work.
I will continue to use GitHub to contribute to projects I’m interested in. It’s the industry standard, it would be foolhardy to not have an account there. For my projects and Pages going forward, though, I will use GitLab.
18 Jul 2017
Entering the Digital Ocean
As my primary task for today I registered with Digital Ocean and migrated jacobmoore.cool from free Github Pages hosting to a small Ubuntu droplet.
A couple of advantages to this approach:
-
Security. GitHub Pages doesn’t currently support SSL certificates. Moving to my own hosting makes this trivial.
-
Knowledge. Setting up an Ubuntu droplet from scratch was a nice exercise. Using a statically generated site means that the process isn’t too intense, but writing nginx config files and configuring DNS isn’t nothing.
-
Scale. I have a few other web projects planned, specifically one around the Cube League I run. Running an nginx host on my own droplet means that I will be able to host multiple small domains. GitHub Pages is free, but only allows for one site per username or project.
-
Work. Making some daily effort toward a larger goal is the single greatest way to achieve the things that we set out to do. Starting this project today gave me momentum and some fodder for this post.
Check back tomorrow for some extended thoughts about GitHub and why I’ll be moving to GitLab sooner rather than later.
17 Jul 2017
Employment, or: The Gilded Cage
One of the downsides of working for a company with private code repositories is that much of your work is impossible to access once you leave. Even if you’re proactive and keep personal copies of your code or other contributions, a couple of problems present themselves:
-
Context. A single method, class, or function is more or less meaningless without being able to see the surrounding code. The same goes with a technical document. Seeing one page of a help site can provide some insight into a writer’s raw ability, but without a site map or full wiki access, seeing how they work with others or to a style guide simply isn’t possible.
-
Disclosure. Even if you have copies of your work for your previous company, it may be in violation of the terms of your employment to share it. Many employers have strict non-disclosure agreements that cover any work done on their payroll. Perhaps it’s possible to alter the work so that it only remotely resembles the original, but undertake any venture of this nature at your own discretion.
Given these strictures, what’s the most useful course of action? How is it possible to display one’s prowess to potential employers or clients without either violating an NDA or hosting a scattershot repository of contextless code snippets?
The answer is simple, but not easy: a side project.
The Tyranny of Time
I accept and understand that many folks simply don’t have the time, passion or energy to create a side project, much less maintain and add to one.
People have other responsibilities: to their spouses, parents, children, second jobs, what have you. I will say, though, that there isn’t much that’s more attractive to a potential employer than being able to see complete and operational code on a github repository or a personal webpage.
The Reality of Portfolios
Relying on a resume alone is a long row to hoe when looking for work as a developer or creative person. Without a portfolio, an artist or graphic designer has basically no shot at getting paying work. It’s practically a prerequisite for any kind of legitimacy as a professional. The same holds true for developers and writers too.
It’s certainly possible to get paying work as a developer or writer without a lot of experience. My own history is proof of that. However, my case relied upon:
- Being in the right place at the right time
- Having a strong network that allowed me to get an audience with an employer
- Being able to impress that person enough to hire me based on my rhetoric
Needless to say, it took a lot of luck (and undeniably some privilege) to get work where and when I did.
So tell me, what the hell is a fella to do?
There have been reams and reams of virtual ink spilled onto the internet about how to create side projects, so I’ll (mostly) leave it to you to navigate the endless sea of advice on the subject. You’ll stumble upon a piece on Medium or their personal blog that resonates with you, and that advice is the place to begin.
If this is that place, I’ll first give you my thanks, and then a couple of short thoughts on the matter:
-
You likely already have an idea for a side project. If you have a hobby or interest that you pursue, it’s entirely possible that a side project is staring you in the face. Do you knit? Write some code that displays knitting instructions in full sentences, or as code snippets (k5 as a loop, kyok as a function call, etc). Are you into baseball? Convert a box score into an inning-by-inning breakdown of the game, or write an api for a database of a particular player’s statistics. Take a database of names and places from the Game of Thrones universe and generate a literal Fantasy League.
-
Use this opportunity to learn something new. My core idea about how to start a side project stems from James Altucher’s concept of ‘idea sex’. Take a few things you like and jam them together. Want to learn React? Take an interest of yours and find a tiny thing within that interest. Take that tiny thing and make a tiny React app. Something that performs and renders a simple calculation, or makes a call to a public API.
Combining your entertainment interests with your professional interests is an intersection that leads to a great deal of inspiration.
- It’s all additive. I think that a lot of people, myself included, think of a side project like a baby horse. It pops out basically fully formed, can walk almost immediately. There are a few problems with this analogy, but bear with me. Even if you spend four or five hours over a week working on a project and decide to trash it, that in itself is an opportunity!
Write a blogpost, or (if you’re not into practicing publicly) a private journal entry, about how you spent those four hours. What you tried, how you failed and what you intend to do moving forward. This post-mortem analysis is so, so useful. It forces you to collate your thoughts and reflect. Hell, your reflection may uncover a solution to the problem you set out to solve in the first place!
- The best time to start is yesterday. The next best time to start is right now. Exactly like the proverb about planting a tree. Make a commitment to yourself to spend a small amount of time every day thinking about and working on the project. 15 minutes, 30 minutes. Even if that time is spent staring at a blank piece of paper, agonizing about the fact that you have no actionable ideas.
The mere fact that your ass is in a chair with the intent of ‘make a neat thing’ puts you far ahead of everyone rewatching the same show they’ve seen four times already, or playing a game that they only kind of enjoy just as a way to pass the time. I have been this exact person for a lot of my life.
Splinters and Planks
I’ll be the first to admit that I am terrible at following my own advice. My attempts to make side projects or portfolio projects have ended with losing focus or interest, moving onto a new thing or hitting a roadblock and giving up.
In an effort to address this shortcoming, I am making a commitment to myself to update this blog every weekday, starting with today, with this post.