DEV Community: Ajay Karwal

Add spaces to the Dock in macOS

Ajay Karwal — Tue, 04 Jun 2019 13:14:57 +0000

If you want to take greater control of how apps are organised on your macOS Dock, a great way is to add spaces between groups of apps.

Run this one-liner in your Terminal to create a new blank space in your Dock

defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="spacer-tile";}' && killall Dock

What this does is add a new ‘spacer-tile’ item to the Dock’s ‘persistent apps’ array — the list of apps which are permanently in the Dock — and then reloads the Dock.

The new space will be added to the end of the Dock. Of course it’s invisible so the best way to confirm it’s there is to open any other app which isn’t currently in your Dock. You should now see a space which you can drag into the desired position.

To create more spaces, just run the command again.

Here is what my Dock looks like. I like to group my apps by function.

Deploying a Jekyll website using Travis CI

Ajay Karwal — Fri, 02 Jun 2017 08:36:39 +0000

Following on from my post about moving from a CMS to Jekyll, the next pain point to tackle is the build and deployment of your site.

Jekyll does a great job of compiling your website into a neat _site folder which you can then FTP to your server, however this does mean that you need to have the convenience of an FTP client at hand. A better solution would be to automate this process and seeing our source code is already being stored on GitHub, we're already half way there.

Meet Travis

Travis CI is a free Continuous Integration service for testing and deploying your open source GitHub projects (a paid option is available for private Github projects).

Add a config file to your project, point Travis CI to your GitHub repo and when you push your code or merge a pull request, Travis CI builds your Jekyll site in a VM and deploys your code as per the settings in the config.

So, let's get started.

Creating a Travis CI config file

Create a new file in the root of your Jekyll project and name it .travis.yml. As this is a 'Dotfile' it may be hidden in Finder but should appear in your text editor. The contents of this file will tell Travis CI how to build and deploy your site. This is the contents of my file.

language: ruby
rvm:
  - 2.3.1

install:
  - bundle install
  - gem install jekyll
  - gem install jekyll-sitemap
  - gem install emoji_for_jekyll

branches:
  only:
    - master

env:
  global:
    - JEKYLL_ENV=production

notifications:
  email:
    recipients:
      - ajaykarwal@gmail.com
    on_success: always
    on_failure: always

script:
  - chmod +x _scripts/build.sh
  - _scripts/build.sh

after_success:
  - chmod +x _scripts/deploy.sh
  - _scripts/deploy.sh

sudo: false
addons:
  apt:
    packages:
      - ncftp

Let's break this down step-by-step

Define the build environment and dependencies

language: ruby
rvm:
  - 2.3.1

install:
  - bundle install
  - gem install jekyll
  - gem install jekyll-sitemap
  - gem install emoji_for_jekyll

branches:
  only:
    - master

env:
  global:
    - JEKYLL_ENV=production

This section tells Travis CI that the build requires Ruby and sets the version to 2.3.1. It also lists any Gem dependencies. 'jekyll-sitemap' and 'emoji_for_jekyll' are specific to my project.

The branches section allows you to control which branch in your repository you want to build. In my case I am just building the master branch but this section can be used to set up a staging environment too.

Setting JEKYLL_ENV to production means we can test for this environment variable while doing local testing to ignore things like Google Analytics.

Building and Deploying the site

script:
  - chmod +x _scripts/build.sh
  - _scripts/build.sh

after_success:
  - chmod +x _scripts/deploy.sh
  - _scripts/deploy.sh

sudo: false
addons:
  apt:
    packages:
      - ncftp

This section is telling Travis CI to find and execute the file located at _scripts/build.sh and on success execute the file at _scripts/deploy.sh.

The addons section tells Travis CI to also install an FTP client called ncftp. This will be used to deploy your site.

Create a folder in the root called _scripts and inside create a build and deploy shell script.

build.sh

#!/bin/bash

bundle exec jekyll build --config _config.yml

The build script is essentially the same as the command you run in Terminal while building your site locally with the addition of defining the _config.yml file as the site's configuration file.

deploy.sh

#!/bin/bash

if  [[ $TRAVIS_PULL_REQUEST = "false" ]]
then
    ncftp -u "$USERNAME" -p "$PASSWORD" "$HOST"<<EOF
    rm -rf site/wwwroot
    mkdir site/wwwroot
    quit
EOF

    cd _site || exit
    ncftpput -R -v -u "$USERNAME" -p "$PASSWORD" "$HOST" /site/wwwroot .
fi

The deploy script performs 3 main tasks

Logs into your FTP account using the $USERNAME, $PASSWORD and $HOST variables which you set in Travis CI settings.
Deletes the site/wwwroot directory and recreates an empty one
Copies the contents of the _site folder to /site/wwwroot

This script was written by Jamie Magee who provided some very helpful guidance during the whole process.

Setting up Travis CI

For the deploy script to work you need to configure the environment variables for your GitHub repository in Travis CI.

Go your your Travis profile
Find your Jekyll repository, switch Travis CI on and click the gear icon
Set the Environment Variables for your FTP host.

Note: Build logs for open source projects are publicly visible so remember to keep the 'Display value in build log' option off.

Automate all the things

Now that everything is set up and configured, its simply a case of pushing your code to your GitHub master branch. Travis CI will watch your repository for changes and automatically trigger a build. If, and only when, the build is successful, Travis CI will deploy your site to your FTP host.

With a Pull Request workflow, Travis CI will run a build on the PR and only when it is successful will it allow the branch to be merged into master.

The notifications section in .travis.yml file can be used to manage who receives build status email notifications.

notifications:
  email:
    recipients:
      - ajaykarwal@gmail.com
    on_success: always
    on_failure: always

Final thoughts

Deploying your Jekyll website using Travis CI is simple, fast and secure. The Pull Request workflow is perfect for collaborating on open source projects or simply scheduling your own content by merging branches when you're ready.

All of the build process is handled by Travis CI which means you can commit changes to your repository from anywhere, have your code tested and validated and then merge to push your content live. I use this method for making site updates from my phone via the GitHub website.

For more ways to use Travis CI to suit your needs check out the documentation.

Switching from a CMS to Jekyll

Ajay Karwal — Tue, 11 Apr 2017 08:29:14 +0000

Back in February, I shipped a new version of my website. Only a very slight update to the design but a complete overhaul on how it was built.

// Detect dark theme var iframe = document.getElementById('tweet-829825398385082368-890'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=829825398385082368&theme=dark" }

Everything was originally built using Umbraco – a CMS powered by .NET – and hosted on Microsoft Azure. This setup of course was reliant on Windows for developement.

I'm a Mac user so in order for me to update my website I needed to run Windows in VMmare Fusion, fire up the project in Visual Studio, setup my localhost and IIS Express, log into the Umbraco dashboard and then make my updates.

When it came to deploying my changes, I would then have to FTP my Views, DocumentTypes (Templates), DataTypes, DLLs and static assets.

Just kill me now. 😭

Up steps Jekyll

I first heard about Jekyll and other SSGs on the Toolsday podcast (exactly one year before I launched my site update) and it had been on my 'things-I-want-to-try-one-day' list ever since.

I started by creating a blank Jekyll site.

jekyll new myblog --blank

If you follow the quick-start guide you end up with a simple blog theme which I didn't want as I was going to be importing my existing design.

The problem with this process is that the command bundle exec jekyll serve won't work as the installation doesn't have a Gemfile or a _config.yml file. More on this later.

Once installed, Jekyll creates the basic folder structure required to organise your site.

├── _drafts
├── _layouts
├── _posts
└── index.html

Notice how the folders begin with an underscore. Any folders named this way are not outputted to the compiled _site folder.

Migrating my content

I started by coping over all my Views from my Umbraco project into my Jekyll _layouts folder. Luckily both systems use similar concepts of layout templates, page templates and partial views (_includes in Jekyll), so it was relatively painless to get my file structure right.

Next I converted my View logic from C#/Razor into Liquid, the templating engine that Jekyll uses (which was developed by Shopify). All of the logic has a like-for-like replacement as my site wasn't doing anything too complex.

Jekyll has Sass pre-processing built in so it was just a case of copying over my sass folder and adding an underscore to have it ignored from the build. I continued to add the remainder of my assets, includes and templates. You can see the full site structure on my GitHub repository.

Where the magic happens

The most important files you will need to create are a Gemfile and a _config.yml file in your project root.

The Gemfile lists any Ruby Gems which are needed to build your project. At the very least this file should contain,

source 'https://rubygems.org'
gem 'jekyll'

The _config.yml file is where the magic happens. It contains all the site settings and you can add any custom settings which are then available to your liquid templates using {% raw %}{{ site.SETTING_NAME }}{%endraw%}. You can use my config file as a template for your own project or follow the Jekyll documentation.

Building your static site

Now that the basic file and folder structure is in place, simply run,

bundle exec jekyll serve --watch

This will bundle any Ruby Gems defined in your Gemfile, generate your static files to a _site folder, serve up your site on localhost:4000 and watch for any changes you make from now on.

That's it, you're done.

Congratulations on converting your CMS driven website to a static website powered by Jekyll. 🎉

Conclusion

Overall the process of moving from Umbraco to Jekyll was relatively simple. The documentation is very clear and there is plenty of support available on Stack Overflow for scenarios where custom logic is required in your Liquid templates.

Every use case is going to be different so take this with a pinch of salt, but the over-arching pros and cons which I feel would apply to all are:

Pros

The output is just static HTML, CSS and JavaScript so the resulting site loads extemely fast. It can also take advantage of browser caching to make return visits even more rapid.
No complex hosting package or server-side processing is required which could dramatically reduce the cost of running your website. You can even host it for free via GitHub Pages.
Writing your content in Markdown results in clean, semantic markup and encourages a more structured approach to your content.

Cons

There is a dependency of using the command-line to generate your site each time you make an edit, so some development expertise is needed. This means Jekyll is probably not a great solution for a client project where content is being managed by the client themselves.
Not really suited for sites which are updated very frequently.

Final thoughts

I would highly recommend that you try out Jekyll. Set up a test project and get a feel for how the content is structured. The Liquid templating engine is a joy to work with and has a very low barrier to entry.

If you're using Jekyll for your website, I'd love to hear about your experiences.