Frankly speaking ...

Building a specialised tool such as a word-puzzle solver needs more than automated builds. The real value is letting users run the solver from their browser—enter letters, press a button, and get results without a command line. For example, given letters like "mitncao", users should find every valid word without leaving the UI. That requires a simple run method: press a button, type the letters, and receive results quickly. By implementing this on both GitHub and GitLab I learned how each platform compares in setup effort, input sanitisation, and user experience. Takeaway 1: GitHub is Fast and Simple An Easy Start: GitHub's Straightforward Setup For those who want to move from an idea to a working tool in minutes, GitHub is a strong choice. Setting up a manual start button for the solver was straightforward, largely due to the integration between the platform and AI tools like GitHub Copilot. Instead of digging through manuals, I could describe the required inputs (...

For the modern developer, the desire to share technical insights is often hindered by the "toil" of the publishing process. We live in our code editors and terminal sessions, yet sharing those insights on platforms like  Blogger  often means reverting to manual labour: copy-pasting HTML, wrestling with web-based WYSIWYG editors, and manually managing assets. This discourages regular contribution, often resulting in stale repositories and abandoned drafts. By adopting a "Blogging as Code" approach, you can replace manual copy-pasting with an automated CI/CD pipeline. By leveraging the  Blogger REST API v3  and  GitHub Actions , you can treat your blog with the same engineering rigour as your production software. 1. The API as Your Deployment Interface The core shift in this methodology is viewing Blogger not as a website, but as a deployment target. The Blogger REST API allows developers to bypass the browser entirely, enabling programmatic creation and updates o...

In our earlier article on Git pipelines , we mentioned that GitHub had released a beta of Actions , their latest CI/CD workflow automation tool. Let's take a quick look at some of its features. For simplicity, we'll use the same example as in the previous article - that of rendering this article into HTML - which is more than enough to demonstrate the basic features. To recap, the workflow for Git pipelines was: Get the latest commit in the repository Install GNU Make Install pandoc which is used to render Markdown into HTML Render the HTML document from Markdown Archive HTML document The Actions based workflow is similar, but quite a bit simpler. It performs the following tasks: Get latest commit in the repository Render the HTML document from Markdown Publish the rendered HTML document to GitHub pages It's simpler, because we don't need to install the dependent software - we can use pre-prepared Docker Hub images instead. What are GitHub Actions? ...

Git has become the de facto standard for version control, but until recently you needed external tools such as  Jenkins  or  GoCD  to manage Continuous Integration / Continuous Delivery (CI/CD) pipelines. Now, though, we're seeing vendors like  GitLab  and others providing pipeline features with extensible suites of tools to build, test and deploy code. These integrated CI/CD features greatly streamline solution delivery and have given rise to whole new ways of doing things like  GitOps . In this article we examine and compare some of the current pipeline features from three popular Git hosting sites:  GitLab ,  Bitbucket  and  GitHub , and ask the question: "Is it time to switch from your current CI/CD toolset?" Example Pipeline Let's use pipelines to render the  Git Markdown  version of this article into an HTML document. The pipeline features we are using: using Docker images to execute build tasks customisin...