Coding: Creating My Developer Portfolio (Part 4)
This is the fourth part of developer portfolio journey so if you somehow came across this article I would suggest that you read part 1.
After weeks of designing, I have finally started to work on coding my portfolio. The months of August and September found me slaving away furiously, creating designs for a portfolio that I wasn’t even sure I would be able to create. Yet, here I am now looking at the sparse cover page that will soon introduce future employers to my work.
While it seems like this article will just be about the process of coding the site, there were actually some other things that I did before I even wrote a line of code. Never having worked for a company or gone to school in order to develop my skills, I had to create my own roadmap for developing this site. It is both frustrating and liberating at the same time, and Medium has been a way for me to reflect upon this.
Feel free to look at my progress on this page (custom url coming soon).
What?
Before even creating a Github repository it was important that I went back and reevaluated what tools I planned on using to create the site. My original thought was to use Vuejs in order to handle the DOM of the site, but I hadn’t gotten much farther than that.
There were a couple of options for creating the site. I could:
- Use vanilla HTML, CSS, and Javascript
- Use HTML, Javascript and a CSS Framework
- Use HTML, CSS and a Javascript Library
- Use HTML, CSS Framework and a Javascript Library
While all of these would be fine options for creating a static portfolio, I choose ultimately to go with the last and objectively most complicated option to build a very simple website. There were a couple of reasons for this, the first being that I wanted this to be a project. Even though the portfolio could be seen as a means to a job, I wanted to use it as an opportunity to learn more about web development in general. This was the reason that I spent the past two months creating drawing and prototypes; this was clearly a slow way to do it, but I learned a lot in the process. The second reason was simple and related to the first; I had used Vuejs before and that made this an easy way to get better with it.
Now, the reason that I chose to go with a CSS framework is simply that I knew that it wasn’t worth my time trying to code a bunch of CSS when I could just import ‘src/assets/css/bulma.css’ and be done with it.
And speaking of bulma.css the framework that I decided to use was Bulma. It’s lightweight nature combined with the fact that I had also worked with it before made it an easy choice.
Where?
At this point, I already knew that I was going to use Netlify to host my site, as the internet seemed to hail it as a great free option for hosting static websites. All I had to do was now set it up which proved a bit more difficult that I thought, but way easier than anything else I had ever done before.
To start I did the thing any normal developer would do and created a basic Github page for my portfolio.
Simple enough.
I then used the vue-cli to create a basic demo page which I then pushed to the repo.
Simple enough.
I then connected my Github account to Netlify and created a page on the dashboard for it.
Simple enough.
Then I tried to build out the site, which as you can guess, was not simple. I had to go and read the documentation to learn that you need to add a build command to the site so that way if anything more dynamic such as Vue or React is being used it can be created. I tried a couple of different commands on the internet before finding one that worked, which was npm run serve which I later learned I could have found by looking in the JSON.
What?
At this point, I had a site up and running but I needed to add content. After some quick Google searching, I found the commands to import Bulma and I was off to the races. I began by creating a basic landing page that would welcome people to the site, informing them of its obvious lack of content. I then created an “other” page that I used to get the Vue router working.
While I wanted to continue I had to stop. Looking at my Github page, I realized that I had no way of managing the new branches that I kept creating and I soon understood that I needed a way to organize it. Not having used something like this before, the internet suggested Git Flow, and while it seemed good, it was to complicated for me to use for such a simple project. As such I created, Portfolio-flow, something that at the time I thought was very clever.
Guidelines
- The main branch must always be deployable because it is always pushed directly to Netlify.
- The master branch should be tagged using semantic versioning
- Feature increments by 0.1.0
- Page increments by 0.1.0
- Fix increments by 0.0.1
- Branches should be named using the branch_type.what_is_being_changed
Branches
- Three different types of branches, features, pages, and fixes
- Features are used to describe changes that add new functionality to a portion of the site that is significant.
- Examples of this would be adding a new animation, a Navbar, or a Footers.
- Pages are used to describe the process whenever a new page is added to the site.
- Examples of this would be creating a Welcome page or adding a Project Page
- Fixes are used to describe changes that are made for the purpose of fixing bugs on the site
- Example of this would be fixing an animation issue or making sure that links work across the site.
Finishing with my very clever pun, I then created a simple navbar and footer, using the branches feature.navbar and feature.footer, to finish off the basic framework of the site. Compared to the mockup, I think that I got it almost spot on. While I changed some of the sizes of elements, I can’t really tell the difference between the two. Sometimes while creating the site I even got confused between the mockup and actual site, which I consider a win.
Next Up…
Now I need to create the actual content on the pages, something that while seeming easy, I know will be very difficult.
