This is part 2 of my – sometimes rambling – review of building the latest iteration of pddds. In part 1 I reviewed the tech, tools and features I used.
This time I’m going to cover workflow I used to rapidly develop the site.
I built the site in what scraps of spare time I could find, so I wanted to maximise the time I spent actually building the site. The first thing I did was streamline the dev process.
My first goal is to make editing and previewing as fast as possible.
Previewing the work-in-progress site using Jekyll is easy out of the box:
That builds starts the built the site and starts a simple webserver hosting the
http://localhost:4000. The two additional flags make it possible to
quickly edit the site;
--watch tells jekyll to rebuild the website when files
are edited so you don’t need to restart the server, and
unfinished posts in the
Jekyll now recommends you also use Bundler when building the site. This ensures you have all the required ruby packages. With bundler, it then looks like:
With that running, I’m able to preview the website in my browser, next to my text editor, as I change it. The only downside with this setup is I have to refresh the page to see my changes. That’s where the next step comes in.
Now, this isn’t the sort of script I want to run on the live site, so we need to
only include it when previewing the site locally. We can use the variable
jekyll.environment to detect if we’re in the live production site or just in
the preview development site. Later, when I talk about deployment, I’ll show how
to set the environment when building the live site.
In the base layout this code looks something like:
Now – with the text editor on my left, and the webbrowser on the right – as I save changes to pages, layouts, css, or any other file, and jekyll automatically rebuilds them, the web browser automatically refreshes to reflect the changes!
It’s not perfect, (I can’t easily save tweaks made in the browsers dev tools, back to the original css/scss files) but it’s relative simplicity and complete isolation from the specific tools is a major advantage. It will work with any text editor, and browser, and on any OS.
(It should even work mobiles/tablets previewing the development site, but you’d have to work out how to connect to the jekyll server across your network)
Now I never needed to leave the text editor, another major sticking point was getting up-and-running. When you’ve just got just half an hour spare, I needed to be able to sit down and start work immediately.
First though, a disclaimer: I “work” inside bash and vim, but I work on Windows because I want to get work done. This leads to some odd environment-specific scripts and tools. So, sorry, the sample below probably won’t work for you, but maybe they’ll help?
I have a script checked in that I run before I do anything else. It’s very simple; it launches the sever and opens the web browser on the correct address. Work starts as so:
Open vim, off I go.
This is what
run_server.sh looks like:
One of the surprising revelations I had at the end of 2016 was how useful time tracking would be at keeping on-task. I use Toggl, initially to keep track of how many non-development things I was having to do at work. As I started using it I found it had the additional benefit of giving my time focus. I decide what I’m going to do, hit Go and start work. I feel guilty if the timers running, but I’m not doing that thing, so I stay on-task and have a better idea how long I’ve been working on a thing. For that reason I started using it at home.
Anyway, back to the website.
A nice side effect is I know exactly how much time I spend building the site.
- Total work done: 35 hours, 56 minutes.
- Over a period of: 2 months 5 days
I think, considering I was re-learning many aspects, completing the site in roughly a work-week (i.e. 40 hr week) seems respectable.
Next time, deployment.