DEV Community: Thomas Sarmis

How I automated typing for coding tutorials with C# (introducing ChoreoTyper)

Thomas Sarmis — Wed, 20 Aug 2025 08:04:26 +0000

When recording coding tutorials, I found myself spending more time editing out typing errors than teaching.

So I built ChoreoTyper, a free utility that automates keystrokes from a text file into the active window.

✨ Use cases:

Coding tutorials (no typos, repeatable scripts)
Live demos (type pre-written commands/code)
Reducing editing work for creators

🛠 Built in C#, works with .NET 10 preview.

📹 Short demo video
📖 Project Page
💻 Source code

Would love feedback from other tutorial creators!

Observability: Metrics in the .NET Ecosystem

Thomas Sarmis — Thu, 14 Aug 2025 00:00:00 +0000

Monitoring .NET Web API Metrics with Prometheus and Grafana on Windows

In this post, we learn how to instrument a .NET Web API with OpenTelemetry Metrics, how to collect them using Prometheus, and how to visualize them in Grafana.

References: Code Repository |YouTube video

Introduction

Solution Layout

The solution we will build has three major components:

A C# application instrumented with OpenTelemetry Metrics.
Prometheus, which scrapes (collects) and stores the metrics exposed by the application.
Grafana, which retrieves, transforms, and visualizes the metrics stored in Prometheus.

Before we start implementing the solution, we should understand what a metric is and how it works.

What Are Metrics?

In the context of observability, a metric is a named, labeled, timestamped, numerical measurement that captures some property of system behavior. Let’s break that down:

Named : All measurements of the same logical thing share the same metric name. For example, http_server_request_count represents the number of HTTP requests the server handled.
Labeled : We differentiate series with the same name using label key/value pairs (dimensions). For example, http_server_request_count might include http_route and response_code labels so we can slice by endpoint and status.
Timestamped : Each measurement corresponds to a point in time (explicitly or implicitly when scraped).

The Prometheus exposition format (text-based and most common) expresses each sample as:

metric_name{label1="value1",label2="value2"} value [optional_timestamp]

If the timestamp is missing, Prometheus uses the scrape time.

Example output:

http_server_request_count{http_route="/weatherforecast",response_code="200"} 15
http_server_request_count{http_route="/health/ready",response_code="200"} 200

This tells us /weatherforecast has been called 15 times and /health/ready 200 times since the process started.

Our application only exposes the current cumulative totals. Prometheus stores the time series history across scrapes. From that history we can derive rates by diffing successive samples. Because we record cumulative counts, values should monotonically increase—except when the process restarts (the counter resets).

Measuring Durations

Measuring durations is trickier than counting invocations. A naive approach would record only the total cumulative duration and divide by total calls to get an average. That hides latency spikes and distribution shape: we can’t tell whether all calls are uniformly slow or a few outliers skew the mean.

OpenTelemetry (and Prometheus histograms) address this by tracking counts of observations falling into pre-defined latency buckets. With bucketed counts plus the total count and sum, we can approximate latency distributions and compute quantiles (e.g., 50th / 95th percentile) with reasonable accuracy.

Implementation

DotNet WebAPI application

Now that we have some background, let’s build the solution. We’ll start by creating a new .NET Web API project:

\> dotnet new webapi --name weatherapp

Now let’s add the required package references:

\> cd weatherapp
\> dotnet add package OpenTelemetry.Extensions.Hosting
\> dotnet add package OpenTelemetry.Instrumentation.AspNetCore
\> dotnet add package OpenTelemetry.Exporter.Prometheus.AspNetCore --prerelease

Next we add code to Program.cs. We need three blocks:

The using statements at the top.
The builder.Services.AddOpenTelemetry() configuration for metrics (resource, meters, instrumentation, exporter).
The app.MapPrometheusScrapingEndpoint(); to expose the /metrics endpoint.

+using System.Diagnostics.Metrics;
+using OpenTelemetry.Metrics;
+using OpenTelemetry.Resources;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

+builder.Services.AddOpenTelemetry()
+ .ConfigureResource(resourceBuilder => resourceBuilder
+ .AddService("weatherapp", "1.0.0"))
+ .WithMetrics(metricsProviderBuilder => metricsProviderBuilder
+ .AddMeter("weatherapp").AddAspNetCoreInstrumentation()
+ .AddPrometheusExporter());                

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

+ app.MapPrometheusScrapingEndpoint();

var summaries = new[]
...

As a good practice, let’s also edit appsettings.json to pin the server’s port:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
+ "urls":"http://localhost:7070"
}

Our application is now ready. It exposes metrics at http://localhost:7070/metrics; we can confirm this by opening the endpoint in a browser.

Prometheus: Setup & Run

Prometheus scrapes (reads) the /metrics endpoint and stores the time series. We set it up as follows:

Download the latest binary (version 3.5 at the time of writing) from the Prometheus Releases page.
Extract the contents to a folder.
Edit prometheus.yml and append our scrape job (watch the indentation):

...
scrape_configs:
  # The job name is added as a label `job=<job_name>` t...
  - job_name: "prometheus"

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ["localhost:9090"]
       # The label name is added as a label `label_name=<label_value>` to ...
        labels:
          app: "prometheus"

+ - job_name: "weatherapp"
+ static_configs:
+ - targets: ["localhost:7070"]
+ labels:
+ app: "weatherapp"

Run Prometheus (prometheus.exe) and visit http://localhost:9090/targets to verify it’s running and scraping our app.

Grafana: Setup & Run

Grafana lets us explore and visualize the collected metrics:

Download the latest OSS standalone binaries (version 12.11 at the time of writing) from the Grafana downloads.
Extract the contents to a folder.
(Optional) Remove authentication: create conf/custom.ini and add:

[security]
allow_embedding = true
cookie_samesite = none
cookie_secure = false

[auth.anonymous]
enabled = true
org_role = Admin

Run Grafana (bin/grafana-server.exe) and visit http://localhost:3000 to verify it’s running.

Grafana: Add Prometheus Data Source

Before we can query metrics we add Prometheus as a data source:

Open Grafana's New Datasource UI
Find and Select Prometheus
Set the "Prometheus server URL" to http://localhost:9090
Click Save & Test

Grafana: Create a Dashboard

Open the Dashboards UI.
Create a new dashboard: New → Dashboard.
Add a panel: Add → Visualization.
Switch the query editor to “Code” mode using the builder/code toggle.
Enter a PromQL query (e.g., rate(http_server_request_duration_seconds_count[1m])).
Save the dashboard.

We can add additional panels using more queries. Here are a few starting points:

// HTTP Request Rate (Requests/Second)
rate (http_server_request_duration_seconds_count[1m])

// HTTP Request Duration (Seconds, 95th Percentile) 
histogram_quantile(
    0.95, 
    sum(rate(http_server_request_duration_seconds_bucket[1m])) by (le)`

// HTTP Request Duration (Seconds, 50th Percentile) 
histogram_quantile(
    0.50, 
    sum(rate(http_server_request_duration_seconds_bucket[1m])) by (le))

// HTTP Request Duration (Seconds, 75th Percentile, by route) 
histogram_quantile(
    0.75, 
    sum(rate(http_server_request_duration_seconds_bucket[1m])) by (le, http_route))

We now know how to add metrics to our .NET Web API, collect them with Prometheus, and visualize them in Grafana. Next steps could include adding traces, correlating metrics with logs, or exporting metrics to a long-term storage backend.

AutoInvoke (Runtime method resolving and invoking)

Thomas Sarmis — Sun, 29 Dec 2019 09:25:33 +0000

During my years of programming I often run into the issue of dynamically (during runtime) deciding which function to call.

This may happen while developing a CLI tool where you need to call a different method based on some command line parameter or when building a command processing/routing module for some backend system.

Typically I would just solve this issue per case, but I decided to build a library for that.

I present to you AutoInvoke it is a static class and its usage is as simple as:

    var list = new List<int>();
    AutoInvoke.Invoke(list, "add", 10);

or for resolving overloaded methods

public class PayloadHandler
{
    public int AHandledCount { get; set; } = 0;
    public int BHandledCount { get; set; } = 0;
    public void Handle(APayload payload) { AHandledCount++; }
    public void Handle(BPayload payload) { BHandledCount++; }
}

public void Invoke_WithSpecificType()
{
    var _handler = new PayloadHandler();

    AutoInvoke.Invoke(_handler, "Handle", new APayload());
    Assert.Equal(1, _handler.AHandledCount);

    AutoInvoke.Invoke(_handler, "Handle", new BPayload());
    AutoInvoke.Invoke(_handler, "Handle", new BPayload());
    Assert.Equal(1, _handler.AHandledCount);
    Assert.Equal(2, _handler.BHandledCount);
}

It is in alpha stage but the basic functionality is there.

The main open issues are

Cannot handle extension methods
Cannot await async methods (will return Task)

nuget
repository

What if Business Requirments where semi-structured files in project's repo

Thomas Sarmis — Sun, 22 Sep 2019 15:21:39 +0000

During my dev career, I have many times witness the case that business requirements (and thus, consequently, functional specifications) were not treated with the same scrutiny as the source code. The source code usually passes at-least from one human reviewer that actively tries to improve the quality of it, there are standards defined regarding the quality of the code, and formal tools (usually git) are used to track the changes and the reason behind them.

Business Requirements are ofter described in issues on a separate issue management system and are usually incomplete and separated from source code. Thus it is easier for the code and requirements to fall out of sync (ie a new issue is created for an updated Business Requirement, but the old commits still point to the old issue that holds an outdated business requirement).

To handle both the issue of sub-par business requirements and their "distance" from the codebase I'm thinking of defining a "standard" that would require the business requirements to be stored in markdown files inside the source code repository.

My current approach is:

Possibly split business requirements from functional requirements (functional requirements are written based on business requirements but are more technical)
Allow hierarchical structures to be defined by referencing parent requirements.
Provide meta-data (like front-matter in static site generators)
Link acceptance criteria to test cases

A command-line utility will be built that will:

enforce Definition of Ready by presenting requirements without acceptance criteria as not ready
provide the current status of the project based on the state of each business requirement (not ready, no tests are written, tests are written but fail, tests are written and passing)
be able to run on pre-commit or pre-merge to either indicate issues or fail the commit/merge
be able to run on ci/cd to generate and publish the current state of the project

So, what are your opinions about this? Do you see any value on this approach? What would you require to use this approach instead of what you are already using?

Modern WebApps - Style: Vuetify

Thomas Sarmis — Wed, 08 May 2019 19:45:35 +0000

In (PWA Infrastructure: Vue, Parcel & Workbox) we build a template for single-page, progressive web applications using Vue.js and Workbox. The result was funtional, but not good-looking, in this article we will work on that.

There are many options for making a webapp good-looking, from hand-writting your css, using a css framework, or since we already use Vue.js, using a vue components library, which has the added benefit of adding functionality. There are various vue component libraries, one of the most promising is Vuetify.js which implements google's material design and, thus, looks almost native in android phones.

Resources

The code for this tutorial can be found in project's github repo in the vuetify branch

Integrating vuetify

Integrating vuetify is actually very simple.

Install vuetify and material design icons by running the following commands:

\>npm i -s vuetify
\>npm i -s material-design-icons-iconfont

Import the scripts and add them to Vue by adding the following in src\web\index.js (just after import Vue from 'vue')

import Vuetify from 'vuetify';
import 'vuetify/dist/vuetify.min.css' // Ensure you are using css-loader
import 'material-design-icons-iconfont'
Vue.use(Vuetify);

Using vuetify

There is a lot of documentation and examples in Vuetify.js site but let's build a very simple web app layout.

We will only touch the .vue files

In src\web\app.vue we will add a permanent toolbat at the top and a navigation drawer at the left side of the page. We will configure the toolbar to be always visible, and the navigation drawer open by default in pages wider that 640 pixels.

<template lang="pug">
    v-app
        v-toolbar(app)
            v-toolbar-side-icon(@click="drawer=!drawer")
            v-toolbar-title Home
            v-spacer
            v-toolbar-items
                v-btn(flat to="/") home
                v-btn(flat to="/profile") profile
                v-btn(flat to="/about") about    

        v-navigation-drawer(v-model="drawer" app fixed mobile-break-point=640)
            v-list()               
                v-list-tile( to="/profile")
                    v-list-tile-action
                        v-icon account_circle
                    v-list-tile-title Profile

                v-divider

                v-list-tile(to="/" exact)
                    v-list-tile-action
                        v-icon home
                    v-list-tile-title Home

                v-list-tile(to="/about" exact)
                    v-list-tile-action
                        v-icon notes
                    v-list-tile-title about 

        v-content           
            router-view

</template>


<script>
    import Vue from "vue";
    import {router} from './_router.js';
    import {store} from './_store.js'

    export default Vue.extend({ 
        data: () => ( { 
            drawer: null 
        } ),

        store: store,
        router: router    
    });    
</script>

In src\web\vues\profile.vue we add a (dummy) login form using a v-card component

<template lang="pug">
    v-container(fluid fill-height)
        v-layout(justify-center)
            v-flex(xs12 sm8 md4)

                v-card(class="elevation-12")

                    v-toolbar( dark color="primary")
                        v-toolbar-title Login

                    v-card-text
                        v-form
                            v-text-field(prepend-icon="person" name="login" label="Username" type="text")
                            v-text-field(id="password" prepend-icon="lock" name="password" label="Password" type="password")

                    v-card-actions
                        v-spacer
                        v-btn(color="primary") Login

</template>

<script>
    export default {

    }
</script>

We make some minor alterations in

src\web\vues\home.vue

<template lang="pug">
    v-container(fluid) 
        h1 Home
        p Welcome: {{$store.state.name}}

</template>


<script>
    export default {
    }
</script>

Finally we modify src\web\vues\about.vue

<template lang="pug">
    v-container(fluid fill-height)
        v-layout(justify-center)
            v-flex(xs12 sm8 md4)

                v-card(class="elevation-12")

                    v-toolbar( dark color="primary")
                        v-toolbar-title About

                    v-card-text
                        p Let's Vuetify the template!                       

                    v-card-actions
                        v-spacer                        

</template>

<script>
    export default {

    }
</script>

Pug ?

We opted to use pug instead of html as our markup language, it's a personal preference mainly due to being more compact ( a well structured page in pug should have about half the lines versus the html version - due to not having closing tags).

The result

Time to see the end-result, in desktop browser:

and in mobile (with the navigation drawer closed, and with navigation drawer open):

Next steps

In the next post we will add some real functionality in our web app.

Original post at greek developer

Modern WebApps - Infrastructure: Vue, Parcel & Workbox

Thomas Sarmis — Wed, 17 Apr 2019 06:46:54 +0000

Single Page Applications (SPA) are web applications that are contained in a single web page, providing a seamless navigation experience due to not having to download and parse the html for each page. Progressive Web Applications (PWA) are web applications that, using a service worker "proxy" and a manifest file, provide the necessary infrastructure to allow cashing of the application by the browser in order to be usable in poor, or no-network conditions. All modern browsers and OSes allow PWAs to be "installed" locally and, thus, provide for a native-like user experience.

A PWA is often a viable alternative to building a native application, especially for small teams, since most app stores now accept PWAs and all major OSes (Windows, Android, iOS) allow PWAs to be installed and appear on the desktop. PWAs open instantly and the browser can be directed to hide it's controls providing a native-like look and feel.

Modern tooling can simplify development but setting it up can be a time-consuming task. Let's see how to setup a SPA & PWA project. The scope of this tutorial is to describe the setup and not each framework/tools specifically - Each of these tools has extended documentation that explains how each works.

Framework & Tools

Vue.js

We will use the Vue ecosystem for the heavylifting:

Vue.js will handle our views by providing a declarative approach in defining them and seperating the code in single-file-components,
VueX will be used for state management
Vue Router will be used to handle the SPA routes

Node.js

node.js will provide support for the bundling utilities and all other utilities that might be required

Parcel.js

Parcel bundler will be used to build and bundle the application

Workbox

Workbox will handle the service-worker details.

Files layout

./src will contain all source code for this project.
- ./src/web will contain the source code for the web application (the html client).
- ./src/db (optional) will contain any database initialization scripts
- ./src/server (optional) will contain any server-side projects
./dist will contain all generated artifacts and should be ignored in git
- ./dist/web will contain the builded and bundled web application.
- ./dist/db (optional) will contain any artifacts generated by the database scrits
- ./dist/server(optional) will contain any server-side projects (compiled)
./.cache will be generated by parcel and should be ignored in git
./node_modules will be generated by npm or parcel and should be ingored in git

The code

The code can be found in project's github repo

Javascript dependencies

Entry point (index.html)

./src/web/index.html is our entry point and just links everything together

<link rel="manifest" href="./manifest.webmanifest"> links the .webmanifest file
<div id="vueapp"></div> defines vue mounting point
<script src="./index.js"></script> loads the script that contains the vue application
navigator.serviceWorker.register('/service-worker.js'); registers the service worker script

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <meta http-equiv="X-UA-Compatible" content="ie=edge">
        <link rel="manifest" href="./manifest.webmanifest">

        <title>Vue.js Single Page Application Template</title>       
    </head>

    <body>
        <div id="vueapp"></div>          

        <script src="./index.js"></script>
        <script>
            if ('serviceWorker' in navigator) {
                window.addEventListener('load', () => {
                    navigator.serviceWorker.register('/service-worker.js');
                });
            }            
        </script>
    </body>
</html>

Manifest

./src/web/manifest.webmanifest describes the application and is required for the application to be considered a PWA.
It's important to maintain the .webmanifest extension for parcel compatibility.

{
    "name": "My application name",  
    "short_name": "app",

    "start_url": "/",
    "background_color": "#3367D6",
    "display": "standalone",
    "scope": "/",
    "theme_color": "#3367D6",

    "icons": [
        {
            "src": "/res/app-256.png",
            "type": "image/png",
            "sizes": "256x256"
        }
    ]
}

Service Worker (Workbox)

./src/web/service-worker.js implements the service worker that is requred for considering the application to be a PWA. Google's workbox is used. Workbox defines multiple stategies (network-first, cache-first, and Stale-while-revalidate). In this example all resources are served using the network-first strategy since this is the most responsice approach and maintains the capability to work offline.

console.log("service-worker.js")
// import service worker script
importScripts('https://storage.googleapis.com/workbox-cdn/releases/4.2.0/workbox-sw.js');

// Network First
[ 
    '/$',  // Index 
    '/*',  // Anything in the same host
    '.+/*' // Anything in any host 
]
.forEach(mask => {
    workbox.routing.registerRoute(
        new RegExp(mask),
        new workbox.strategies.NetworkFirst( { cacheName: 'dynamic' } ) 
    );
});

Vue binding

./src/web/index.js is used to bind the vue application and our css (in scss). It imports the Vue framework, our vue application code (app.vue) and our styles (styles.scss) - All these files are located in ./src/web/ but we are using relative paths in the imports. Finally we mount our vue application to the corresponding div element.

import Vue from 'vue';

import App from './app.vue';
import './style.scss'

new Vue(App).$mount('#vueapp')

Vue Application

./src/web/app.vue contains our vue application as a single file component.

In the <template> we construct a simple navigational menu and the router-view which is the host for our single page application, all other pages are mounted in the router-view element. In this template we are using pug insteand of html.

In the <script> we import the vue framework and two custom modules, the _router.js and the _store.js and we create our vue application by extending the default vue application with the store and router modules we just loaded.

In the <style> we providing some local (scoped) styling for the menu using scss (which out bundler will convert to css)

<template lang="pug">
    div
        nav.navbar
            router-link(to="/") home
            router-link(to="/profile") profile
            router-link(to="/about") about
        router-view
</template>


<script>
    import Vue from "vue";
    import {router} from './_router.js';
    import {store} from './_store.js'

    export default Vue.extend({ 
        store: store,
        router: router    
    });    
</script>


<style lang="scss" scoped>

    .navbar {
        text-align: center;

        * + * {
            margin-left: 8px;
        }
    }
</style>

Router

./src/web/_router.js configures and initializes vue-router by loading all pages and declaring their routes.

import Vue from "vue";

import VueRouter from 'vue-router';

Vue.use(VueRouter)

// 1. Import Components
import home    from './vues/home.vue'
import about   from './vues/about.vue'
import profile from './vues/profile.vue'

// 2. Define some routes
const routes = [
    { path: '/'       , component: home    },   
    { path: '/profile', component: profile },
    { path: '/about'  , component: about   }
]

// 3. Create & Export the router 
export const router = new VueRouter({
    routes: routes
})

Store

./src/web/_store.js configures and initializes the vuex store module. It declares the global state and the available mutations. The vuex allows for global state to be modified by all view components (through the mutations) while mainting the reactivity of the framework. (ie commiting a mutation will update all components that are affected by the state change).

import Vue from 'vue'
import Vuex from 'vuex';

Vue.use(Vuex);

export const store = new Vuex.Store({
    state: {
        name: 'Unknown'
    },

    // Usege: $store.commit('mutationan', parameter)
    mutations: {
        setName(state, name) {
            Vue.set(state, 'name', name);
        }
    }
});

Pages

We have three pages in our example, home and about are almost identical, both are rendering the name property of the store.

profile provides an input box where the user an type his name and instantly updates the global state when the value of the input changes.

./src/web/vues/about.vue

<template lang="pug">
    div 
        h1 About
        p  Welcome: {{$store.state.name}}
</template>

<script>
    export default {

    }
</script>

./src/web/vues/home.vue

<template>
    <div> 
        <h1>Home</h1> 
        <p> Welcome: {{$store.state.name}}</p>

    </div>   
</template>


<script>
    export default {
    }
</script>

./src/web/profile.vue

<template lang="pug">
  div 
    h1 Profile
    p  Welcome: {{$store.state.name}}
    div.form 
      table
        tr
          td Name
          td
            input(:value="$store.state.name" @input="$store.commit('setName',$event.target.value)")
</template>

<script>
    export default {

    }
</script>
<style lang="scss" scoped>
    .form {
        display: flex;
        justify-content: center;
    }
</style>

Developing

The following steps are required in order to develop on this template

Download or clone the code
Install parcel npm i -g parcel-bundler
Install project dependencies npm install (in project root)
Run the dev script npm run dev

Original post at greek developer

Webapp Templates - What would you like to see?

Thomas Sarmis — Sat, 06 Apr 2019 09:19:24 +0000

I am setting up some web app templates - Will use Vue for the client and would have three implementations for the server:

.net core
node.js
firebase firestore

I'm not sure if i should build just a template or include some sample funtionality
What's your opinion on this?

This is the repo of the first sample (contains only client-side currently)
https://github.com/sarmis/greekdev-template-vue-spa

Hugo 102: Setting Up

Thomas Sarmis — Fri, 15 Mar 2019 00:00:00 +0000

Hugo is a static site generator that converts markdown files (.md) to html pages. Let’s discover how we can build a blog using it, and discuss some configuration options that will make the experience better.

Step 1 - "Install" Hugo

Download the latest extended version for your OS from Hugo Releases
Extract Hugo in a folder of your choice
(Optional) Add Hugo folder to path - if not, then replace the hugo command with the full path to Hugo, ie "c:\program files\hugo\hugo"

Step 2 - Create a new blog

Launch a new command prompt and navigate to the folder which will contain the new site.
Create a new hugo using hugo new site my-blog. A folder named "my-blog" will be created.
Download a new theme, preferably beatiful hugo.
Extract and copy the new theme inside my-blog/themes/
Rename theme folder from beautifulhugo-master to beautifulhugo
Open the config file (my-blog/config.toml) and edit the theme line theme = "beatifulhugo" to select the new theme
Create a new post hugo new post/first-post.md
Run the deveopment server (hugo serve -D -w)
Preview the new site on http://localhost:1313 - unless port 1313 is already used, in which case the new port will be listed in the development server's output

Step 3 - Content Management

Although there are a lot of ways to organize content in hugo, I prefer to place each post in a separate folder named yyyy-mm-dd title, also I like to group these folders by year. Finally since each post lies in each own folder it should be named as index.md.

So the full path for each post is my-blog/content/post/yyyy/yyyy-mm-dd title/index.md

my-blog
│
├── cv
│   └── index.md
│
├── content
│   ├── post
│   │   ├── 2018
│   │   │   ├── 2018-03-15 Hugo Gallery Shortcode
│   │   │   │   ├── index.md
│   │   │   │   └── feature.png  
│   │   │   │   
│   │   │   └── 2018-09-11 Hugo 101 Static Site Generators
│   │   │       ├── index.md
│   │   │       └── feature.png

That approach both keeps all post files together in a folder and isolates them from the rest posts allowing for easier editing as each time we have to handle only one folder containing exactly what we need.

By default hugo will use the post title to create the url of each posts but this approach might create issues if we decide to change the title of the post or if we don't necessarily like to match the url with the post's title. Also since post images will be under the same url, changing post title will require changing all image urls. A better approach is to use "slugs" a slug is a custom url part that we assign to each post.

First we need to instruct hugo to use the slugs so we edit my-blog\confg.toml and add the following lines

[permalinks]
  post = "/:year/:slug/"

This instructs hugo to create a url that consists of the year and the slug for each post.

Now in order to set the slug for each post we need to understand what these index.md files contain.
Each post file (index.md in our case) contains the text of the post and some meta-data, called frontmatter. The frontmatter must appear in the beggining of each file between --- and consists of name: value pairs. For example the frontmatter of this page is

---
title: "Hugo 102: Setting Up"
date: 2019-03-15
tags: ["hugo"]
slug: "hugo-setup"
image: "2019/hugo-setup/featured.png"
---

the year of the date and the slug are used to construct the url of each post.
Note that the image field here will be used in the home page of the post and, thus, it's value must be relative to the root of blog.

Step 4 - Content

The actual content of each post starts after the front matter. Everything we write bellow the frontmatter will appear in the post's body. The content should be formatted in markdown but also regular html will work.

As a very short intro to markdown:

prefixing any line with #, ##, ###, ####, #####, ###### will create headers
enclosing any text in * or ** will render it using italic or bold
prexiing any lines with - will create lists

Step 5 - Generating

By defaut hugo marks all new posts as drafts, before generating check that no post has a
draft: true field in it's frontmatter

To generate the site use the hugo command. It will create a folder named public with all the content of the site. You can publish your site by uploading the contents of the public to any host.

Original post at greek developer

Hugo #1 - Intro to Static Site Generators

Thomas Sarmis — Tue, 11 Sep 2018 15:59:42 +0000

A static site generator (SSG) is an application that converts simple text files (with minimal markup) to static sites using predifend templates (Themes). They provide a middle ground between fully fledged Content Managment Systems (like wordpress or drupal) and statically build sites.

Pros

No server-side infrastructure except a simple http server (no database, no server-side application).
Simple deployment procedure (just copy the generated files).
Every deployment is a full deployment (no differences between local and remote site)
Easily to track content and theme via source code versioning system
Content consistency (every page looks the same due to template usage)

Cons

The application is required in order to alter content (ie. cannot publish frpm mobile)
No advanced content management or authorization model
There is a learning curve for doing more complex tasks (but this is true for every other option)

Use case

SSGs are a fitting option for personal or small teams, blog-style sites where any commenting is either disabled or off-loaded to another tool (ie facebook comments) - If the team member are familiar with text editing, markdown and git (like developers are) even better.

Operation & Setup

The typical steps to setup an SSG are:

Download SSG binaries or script
Create a new folder (project)
Download a theme
Configure site parametes (title, url, theme, etc)
Create content (simple ascii files, using markdown)
Build static files
Deploy static files

Which one?

There are multiple SSGs to select from, but the 3 most used are:

Jekyll is the most used (partailly due to being used by github pages), but setting up RoR on a windows machine could be intimidating..
Hugo is build in "Go" but ships as a single executable and is a nice option
Hexo is build in node.

My personal preference is Hugo

Origin post at greek developer

Building a folder-based gallery for Hugo

Thomas Sarmis — Thu, 30 Aug 2018 05:58:22 +0000

A custom hugo shortcode that builds an image gallery from images inside a folder

Source Code

Image Discovery & Gallery Layout


    <!-- "site root"\layouts\shortcodes\foldergallery.html -->

    <style>
        div.gallery {
            display: flex;
            flex-wrap: wrap;
        }
        div.gallery a {
            flex-grow: 1;
            object-fit: cover;
            margin: 2px;
            display: flex;
        }

        div.gallery a img {            
            height: 200px;
            object-fit: cover;
            flex-grow: 1;
        }

    </style>

    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/fancybox/3.4.0/jquery.fancybox.min.css" />

    <div class="gallery">
        {{ $path := print "content\\" .Page.Dir (.Get "src") }}
        {{ $url  := print .Page.URL (.Get "src") }}
        {{ range (readDir $path)  }}            
            {{ $src := print $url "/" .Name }}                
            <a data-fancybox="gallery" href="{{ $src }}">
                <img src="{{ $src }}">  <br/>            
            </a>
        {{ end }}
    </div>

Fancy Box


<!--
1. Replace theme's jquery with 3.3.1 version
2. Add the fancybox3 script
-->
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/fancybox/3.4.0/jquery.fancybox.min.js"></script>

Usage

  { {< foldergallery src="imgs" >} }

Will create an image gallery with the images in the imgs folder

Sample

Originally posted at greek developer

Hidden Boards - "copy/paste via http" for non-sensitive text

Thomas Sarmis — Thu, 23 Nov 2017 11:31:20 +0000

Hi everyone, I just build http://hiddenboards.com It's intent is to enable transferring private (but not too sensitive) text from one pc to another, without installing anything or going through lengthy registration processes. (ie copy/paste a serial number to a new machine)

You can create a board and the contents of the board are only available to those who have the (random) board ID (and me as the administrator).

I will add a layer of (simple) encryption before posting the data to the firebase.

I would appreciate any comments.

The stack is firebase, vue.js & bulma.io (currently runs on the free tier so it should have a limit on about 100 simultaneous connections)

My "RAD" stack for small projects

Thomas Sarmis — Mon, 21 Aug 2017 11:29:56 +0000

The last 10 years I work with Delphi & MS-SQL Server for building desktop apps and back-end systems in Windows. The last years I have considered some web-based projects but the distance from the tools I 'm familiar with to a decent stack for web apps is huge - sure I can build the back-end in Delphi but then deployment get's complicated, especially for small projects that do not worth setting app a complicated CI/CD tool chain.

So I was in search for a more suitable stack, my requirements were more or less the following:

Small set of new languages
Easy setup of the development environment
Deployment options.

After some consideration I decided to go with the following stack:

MS SQL Server
Node.js
HTML & Javascript

HTML & Javascript is a no-brainer, a website can target most of the devices that are used today.

Node.js was also an easy choice, it uses javascript so I can leverage what ever I learn for the front-end, and is popular enough to be deployable in almost all cloud platforms as well as both in Apache & IIS and both under Windows and Linux. Also as it is a new, hot technology there are a lot of guides and has a very active community. Setting up the developing environment is also very simple.

MS SQL Server is a rather strange choice but in my case it has some advantages, first of all it's a tool that I'm familiar with, I have it already available in my dev machines and I can re-use a lot of tooling that I have available. There also many options for deploying MS SQL Server (Managed in Azure, unmanaged in Google Cloud, Local installation in windows & linux)

This stack allows me to develop and deploy either to my dev-machine or completely managed in azure.

Sure some tools of this stack may not be optimal for large-scale web projects but the issue of this post is to describe a stack for small projects which may or may-not move forward to become large-scale enough...