DEV Community: anes

WCAG: Making the internet more accessible

anes — Mon, 20 Apr 2026 20:31:13 +0000

We at Centro Labs recently finished making LocalMate WCAG 2.2 Level AA Compliant.
It's not something that shows up on a demo reel or has any flashy consequences, but it's one of the more meaningful things we have shipped. Here's how we did it and what we found out while doing it.

What WCAG actually is

The Web Content Accessibility Guidelines (or just WCAG) are international standards developed by the W3C Web Accessibility Initiative (WAI) to ensure digital contents are accessible to anyone, including people with disabilities.
It applies to both web applications and mobile applications.

POUR Principles

It's centered around the four core POUR principles:

Perceivable

Information must be presentable to users in ways they can sense. This can be: Alt-Texts on images, aria labels, captions, etc.

Operable

UI components and navigation must be operable. This means: being able to tab through the content of the website, having enough time to read the contents on it, etc.

Understandable

Information and operation must be understandable, meaning: Readable text, predictable functionalities, etc.

Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

Conformance Levels

The standard is split up into three levels of compliance:

A: Minimum level of accessibility
AA: Medium level of accessibility. This is often required for applications in the public sector, which is sadly not met by lots of applications.
AAA: Maximum level of accessibility

Why it matters beyond compliance

Usually when people pitch WCAG-Compliance they talk about government guidelines, legal requirements, etc. All of that is true, but its importance runs deeper than that: Roughly 15%-20% of the population has some disability, affecting how they navigate and experience the web.
A much larger group than that has situational impairments: Navigating a website on a dark screen, using a service with a sprained wrist, using a service in a second or third language.
Accessibility is not only for the permanently impaired, but also for temporary constraints in how they use those digital services.

For LocalMate specifically the reasoning is clear: It's a service that makes information and services accessible to anyone. Not complying with the WCAG AA guidelines is a contradiction to our mission.

What most websites get wrong

Designers and developers often work on their applications in a controlled environment: On a desktop with bright screens, familiarity with the language and with a deep understanding on how the UX was designed, I mean they were present when the application was written.
Below are a few key requirements that are often neglected.

1. Contrast ratios

The rule: Body text needs a contrast ratio of at least 4.5:1 against its background. For larger text (18pt+ or 14pt+ on bold text) this is eased to 3:1. This is success criterion 1.4.3.
Before we were compliant our AI disclaimer in the footer was a secondary light text on a grey background:

This is a contrast ratio of 1.75:1, making it not compliant. We swapped this for darker text, achieving compliance.

2. 400% zoom without horizontal scroll

The success criterion 1.4.10 says, that on a viewport of at least 1280px in width the website must be usable at a 400% zoom.
Most desktop-first designs don't comply: Sidebars, overflowing content, etc.
We were also not compliant before, having the input overflow and making the application unusable:

Fixing this took a bit of UX-Engineering: We turned off the minimum width on the input box and moved the "Open a new chat" button to the top of the page, disconnected from the input itself:

The easiest way to tell if your website is compliant: Try using it after zooming in to 400%.
This is what the cover image of the blog article is. The "ugly" input conserves both width and height, by getting rid of most padding on very small screens.

3. Missing or lying ARIA labels

ARIA stands for Accessible Rich Internet Applications. They are the aria-label tags that inputs and buttons often have.
They add semantic annotations for assistive technologies.

Things that are frequently missed are:

Icon-only buttons have no accessible names. They should all get an aria-label, which describes the action.
Inputs with placeholders as labels. Those should also get an accompanying label.

4. Missing focus states and keyboard traps

If you can't see where the keyboard focus is, you can't use the app with a keyboard, making it non-compliant with guideline 2.4.7.
The browser default is often removed by designers (using outline: none, because it's ugly).
For compliance reasons we show an outline and, if applicable, show the hover-labels:

Keyboard traps

A keyboard trap is when a tab-cycle gets stuck in a loop, like tabbing in the footer and never getting out.
This is a no-go. For people that cannot use a mouse something like this means: Refreshing the page every time they get trapped.
This can be corrected by introducing a tabbing order on a website, even though most of the time, this should be handled by the browser.

The point

I could go on for days about other things that are frequently non-compliant, but the core message is: Don't just expect that your work is accessible, make sure it is.

Tools that helped us

Doing this manually and finding all the weak spots is annoying and takes tons of time. Luckily, there are tools to help.

Lighthouse reports

Google has a website called PageSpeed Insights. While it also covers SEO and first contentful paint, it offers a section called Accessibility, where some issues get caught.

axe DevTools

axe DevTools is a browser plugin, that allows running a diagnostic on your localhost page, catching issues before they ever reach production.
It doesn't catch all issues, but quickly points out quick-wins and obvious problems, like missing contrast.

AI Agents

Let's be honest: Most of the heavy lifting can be done by AI Agents. They can quickly scan through the entire codebase, use playwright MCPs to figure out the tabbing order, etc.
Running Claude Code in plan mode to find, explain and correct all mistakes gets you about 90% of the way there.

The uncomfortable takeaway

Most web apps aren't WCAG AA compliant because accessibility is hard to see and easy to defer. There are no actionable bug reports from the users that get left behind, because they got frustrated and left. There is almost no marketing upside, because it hardly translates into a nice pitch deck and it slows down features.
The way I have come to think about it: WCAG is a proxy, for whether a team takes non-ideal users seriously. They don't think about the person who forgot their glasses, uses the app on a phone while on the bus or someone whose first language isn't the one in the UI. If the response to any of those is: "Well I don't know, it kind of works", the product is shipping a product that divides.

Making LocalMate WCAG AA compliant took real engineering and UX time. It also surfaced lots of small quality issues that improved the product for everyone, not just users with disabilities.

This article was originally published on the Centro Labs Blog, check it out there!

Building LocalMate at Hack Winterthur

anes — Mon, 16 Mar 2026 11:08:50 +0000

A few weeks back me and @meritonaliu walked into Hack Winterthur 2026 as two CS students from ZHAW.
We walked out the winners, being able to provide actual results: Winterthurs LocalMate: A digital assistant that builds the bridge between information and the people that need it.
In this blog I want to outline the story of how it happened, why it matters to us personally, and whats under the hood.

The Challenge

The City of Winterthur proposed a straight forward problem: They want to strengthen the communication between their local government and the people they govern.

A simple problem in theory, but in practice something that is hard to implement: People get lost in the infinite amount of documents, regulations and the complex German.

This problem isn't abstract to us. We know what it's like.

Why this is personal

We both grew up in Zürich as the children of migrants. We watched everyone around us struggle with letters they couldn't fully understand, systems that assume familiarity with the system and other barriers that make integrating into this society harder than it should be.

We often built this bridge: Translating, explaining and navigating where we could. That experience shaped how we think about the accessibility of information.
And seriously: It shouldn't require a native speaker, a law degree or a teenager at your diner table to figure out how things work.

When we saw the challenge, we didn't need to brainstorm: Winterthur faces a challenge we faced our entire lives.

48 Hours of Building

Hack Winterthur wasn't just about hacking: We started with a simple prototype to start gathering insights as fast as we could.
The schedule was intense:

Building a prototype during a 2 hour train ride home from 11PM to 1AM.
Deploying everything on a personal Proxmox server.
Getting user feedback as quickly as possible by using every time between document indexing as an opportunity to walk around and let people try it.

The atmosphere was electric. Entrepreneus from all sorts of fields (IT, Business, Fintech, etc.) all building under the same roof.
The perfect opportunity for cross-pollination of ideas.

What LocalMate actually is

LocalMate is a conversational AI assistant that answers questions about the City of Winterthur, accurately, simply and in any language.
Additionally it's an agent that retrieves dynamic information on the fly: Ask him about the trash schedule and he goes retrieving on his own.

You can try it right now: LocalMate MVP

The Architecture

Under the hood, LocalMate is built on a RAG Pipeline (Retrieval Augmented generation) with agentic workflows built in.

Data Ingestion

We scrape data from stadt.winterthur.ch, the official website of the City of Winterthur. This ensures that no information is wrong or hallucinated.

Vectorization

Everything is vectorized in memory, enabling extremely fast semantic search.

Retrieval

Before every request the users question was enriched using a small model and translated into german to guarantee retrieval quality.
For retrieval we used SBERT, a semantics aware transformer that allows for incredibly quick lookups that know what the user wants.

Multilingual by default

The system can retrieve and respond in whatever language the user wants: Ask in Albanian, get an answer in Albanian.

What makes it different

While most websites have an FAQ section or a simple chatbot, we offer something more.

Verified Sources only: Every answer traces back to a document or page the city provides. No hallucinations.
Language-agnostic: It doesn't just translate, it understands the semantics and reformulates in the users language
Plain language: Administrative jargon gets simplified without losing accuracy.
Agentic: Beyong simple Q&A, LocalMate can autonomously fetch dynamic data like schedules.

What's next

Winning Hack Winterthur was the starting line, not the finish.

WinLab

We have submitted LocalMate to the WinLab co-creating platform, seeking collaboration with the city to pilot the tool on a larger scale.

Launch Control Incubator

We're participating in the Home of Innoviation's incubator program to develop our understanding for business and creating.

Beyond Winterthur

The architecture is instance-agnostic. Any municipality, canton, public- or private-sector organization that has tons of public or private knowledge could get their own LocalMate instance.
We're actively looking for early adpoters.

The takeaway

The best hackathon projects solve a problem the builders actually have. For us, LocalMate is something we wished existed growing up.
We're building it so the next family doesn't have to figure it out alone

Me (Anes Hodza) and Meriton Aliu are students at ZHAW.
We publish our side projects under the name Centro Labs.

Originally featured on the ZHAW News Blog.

Ruby function design and other stuff I like ranting about

anes — Tue, 04 Jun 2024 22:09:31 +0000

Why?

If the posts title looks weird: it is. This is a small rant about code-functionality that makes little to no sense (in my eyes).
This whole article can be summed up like this:

How?

I was talking to a coworker about getting the numerical value of a character, like you can in Java, because a char stores the number behind that character.
As an example of that behavior is this function, that counts the occurrence of every character:

public static int[] countCharacters(String input) {
  int[] summand = new int[256];

  for (char c : input.toCharArray()) {
    summand[c]++;
  }
  return summand;
}

My naive suggestion was that you could just run number.to_i to convert it to its (what I think is) ASCII number.
The problem with that are cases like converting "49".to_i, where ruby, as a non-typed language, has to convert that to the number the string represents:

irb(main):017> "12".to_i
=> 12
irb(main):018> "12".sum
=> 99

On the one hand there is the "12".to_i, which translates to 12. Fair enough, that makes sense. The other case, where the String doesn't represent a number, it just translates to 0:

irb(main):012> "a".to_i
=> 0
irb(main):013> "fdsgsdf".to_i
=> 0

That leads to some weird (but expected) behaviour:

irb(main):003> summand = []
=> []
irb(main):006> summand["a".to_i] = 'test'
=> "test"
irb(main):008> summand["4".to_i] = 'test'
=> "test"
irb(main):009> summand
=> ["test", nil, nil, nil, "test"]

Now look closely at that first codeblock. You might realize that there are two operations used:

irb(main):017> "12".to_i
=> 12
irb(main):018> "12".sum
=> 99

The weird part is the "12".sum - as ruby loves translating strings to the numbers they represent, you would expect that to translate to something like this:

irb(main):018> "12".sum
=> 12
irb(main):018> "12".sum
=> 3 # Because 1 + 2 = 3

But you get something completely different:

irb(main):018> "12".sum
=> 99

And now why does this happen you might as?
Because of this:

irb(main):027> "2".sum
=> 50
irb(main):028> "1".sum
=> 49

Because it takes their ASCII representation, the same as java does!

Okay, so shouldn't this work for accessing arrays?

This (obviously) doesn't work out of the box, as you need to convert the string to a number:

irb(main):004> summand["1"] = 'test'
(irb):4:in `[]=': no implicit conversion of String into Integer (TypeError)

summand["1"] = 'test'
        ^^^^^^^^^^^^^
    from (irb):4:in `<main>'
irb(main):005> summand["a"] = 'test'
(irb):5:in `[]=': no implicit conversion of String into Integer (TypeError)

summand["a"] = 'test'
        ^^^^^^^^^^^^^
    from (irb):5:in `<main>'

What about scientific notation?

"What about scientific notation?" you might ask. That's also what I was wondering:

irb(main):022> 2e10
=> 20000000000.0
irb(main):024> "2e10".to_i
=> 2

?!

Yes, you are seeing this right: It converts the "2e10" to a 2, as it's all the numbers until the first non-number. This behavior is seen in longer strings too:

irb(main):036> "21f10".to_i
=> 21

Here it cuts the to_i operation after reaching the f.

Actually converting scientific notation to a number

Now, how can we make this work? This is how:

irb(main):037> "2e10".to_f.to_i
=> 20000000000

And this only works, as numbers of scientific notation have the class Float per default:

irb(main):038> 2e10.class
=> Float

For a dynamically-typed language it still seems to be unable to do a lot of casting for you!

Where is this leading?

Nowhere. Everything I mentioned before is really obscure and won't be important 99% of the time. This article is just for those 1% of cases.

Publishing your first npm library

anes — Wed, 24 Apr 2024 23:49:22 +0000

Introduction

I recently published my first npm library called pushdown-automaton which allows users to create Pushdown Automata. And while it is a very niche use-case I am still proud of my achievement.
This article's purpose is highlighting anything important I ran into to help everyone reading this.

Librarification of your code

Personally, I started off with something like this:

/
  PushdownAutomaton.js
  Stack.js
  State.js
  TerminationMessage.js
  TransitionFunction.js
  package.json
  .gitignore
  .tool-versions

And while this is fine to hand in for a school project, there is still a lot missing to turn it into a library.

Using typescript (optional)

First, the project should be converted to TypeScript. That makes using the library as an end-user much easier, as there are type-errors in case someone uses it wrong:

Coverting your files

Firstly you should change all *.js files to *.ts.
Then you need to add types everywhere:

let automaton: PushdownAutomaton;
automaton = new PushdownAutomaton("test");

let oneState: State;
oneState = new State("q0");
let otherState: State;
otherState = new State("q1");

While I did it manually, you can probably just feed all your files into ChatGPT and make it do the manual labor. Just use at your own discretion.

Changing folder structure

To make everything more readable and easier to understand you might want to move the source *.ts files into their own folder:

/
  src/
    PushdownAutomaton.ts
    Stack.ts
    State.ts
    TerminationMessage.ts
    TransitionFunction.ts
  package.json
  .gitignore
  .tool-versions

Later we will set up an out/ folder that holds our end-user code.

Setting up the ts compiler

As we still want to make the library usable for non-ts users we have to add the tscompiler that turns our code into JavaScript.
As we only need it when developing and not when sending our package to the user, make sure to only install it in development:

npm install --save-dev typescript

And now we define a few commands in our package.json that make compilation easier:

"scripts": {
  "build": "tsc --outDir out/",
},

This allows us to just run npm run ... and have it compile directly into the correct directory. Now running any of those commands doesn't work as of now:

➜ npm run build

> pushdown-automaton@1.1.3 build
> tsc --outDir out/

Version 5.4.5
tsc: The TypeScript Compiler - Version 5.4.5

COMMON COMMANDS
...

TypeScript config

This happens, as we don't yet have a typescript config set up.
Luckily, we can generate one by running:

➜ npx tsc --init

Created a new tsconfig.json with:
                                                                                                                 TS
  target: es2016
  module: commonjs
  strict: true
  esModuleInterop: true
  skipLibCheck: true
  forceConsistentCasingInFileNames: true

And the generated tsconfig.json might look like this:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

And while this works, it's not quite what we want. After changing it around a bit, this one looked pretty good for me:

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es6",
    "module": "ESNext",
    "lib": ["es6", "dom"],
    "declaration": true,
    "sourceMap": true,
    "outDir": "./out",

    /* Strict Type-Checking Options */
    "strict": true,

    /* Module Resolution Options */
    "moduleResolution": "node",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,

    /* Advanced Options */
    "skipLibCheck": true
  },
  "exclude": ["node_modules", "test", "examples"],
  "include": ["src/**/*.ts"]
}

Important settings are:

target: This is the JS Version our files will be transpiled to
module: This defines the module system our code will use. ESNext allows for keywords like import and export
lib: This defines what will be included in our compilation environment
declaration: This option tells the compiler to create declaration files (explained better under the chapter *.d.ts)
sourceMap: This option tells the compiler to create sourcemap files (explained better under the chapter *.js.map)
outDir: Where our files are sent to (if nothing is specified in the command)
include: What glob pattern to use when searching for files to be compiled

Now we can re-run our commands sucessfully:

➜ npm run build

> pushdown-automaton@1.1.3 build
> tsc --outDir out/

Inside of the out/ folder you should now see a bunch of files, having following endings:

`*.js`

These are JavaScript files. They contain the actual code.

`.d.ts`

These are Type declarations: These files tell any TypeScript compilers about types, etc. giving them the ability to catch type errors before runtime.
The content looks like a Java interface:

declare class PushdownAutomaton {
    //...
    run(): TerminationMessage;

    step(): TerminationMessage;

    setStartSate(state: State): void;
    //...
}

`.js.map`

These files are used by the browser to allow users to see the original files instead of the compiled ones. Reading them doesn't make much sense, as they are just garbage.

ESNext issues when using TypeScript

If you already tried using your library you might have realized that nothing works. That is for one simple reason: TypeScript imports don't get .js added after filenames with tsc:

// This import in ts:
export { default as PushdownAutomaton } from './PushdownAutomaton';

// Gets turned into this in js:
export { default as PushdownAutomaton } from './PushdownAutomaton';

// While this is needed:
export { default as PushdownAutomaton } from './PushdownAutomaton.js';

To fix that, I used some random npm package I found, called fix-esm-import-path.
Automating the process of using this needs us to add more scripts in our package.json:

"scripts": {
  "build": "npm run build:compile && npm run build:fix",
  "build:fix": "fix-esm-import-path out/*.js",
  "build:compile": "tsc"
}

Reflecting the changes in our `package.json`

We made many structural changes to our project, we need to change the package.json by adding an indicator for the type of project we have and where our files are:

{
  "files": ["out/**/*"],
  "type": "module"
}

Adding JSDocs

JavaScript supports something called "JSDocs". They are those helpful messages you sometimes see when using a function:

Adding these docs to every method and class will increase the usability by a lot, so I would suggest you do that.

Creating the "entry point"

When someone uses our package now, that person would expect to import our libraries code like this:

import { PushdownAutomaton, State, TransitionFunction } from 'pushdown-automaton';

But as of now that isn't possible. They would have to do this:

import PushdownAutomaton from 'pushdown-automaton/out/PushdownAutomaton'

To enable this first type of imports we will create something called an entry point. That file is located under src/index.ts and looks like this:

export { default as PushdownAutomaton } from './PushdownAutomaton';
export { default as Stack } from './Stack';
export { default as State } from './State';
export { default as TransitionFunction } from './TransitionFunction';

All this does is just bundle up everything the user needs. Configuring it like this increases ease of use.

Setting that in our `package.json`

Now we need to define the entry point in our package.json file:

{
  "main": "out/index.js",
  "types": "out/index.d.ts",
}

All this does is tell the end-user where to find the "entry point" and its types.

Clean code and testing (optional)

Most libraries make use of things like linters and tests to guarantee maintainability and expand-ability.
While this is not needed, I always advocate for it. It makes the development experience for you and any potential future maintainers much better.

Clean code check

First, we want to set up eslint, which is a JavaScript library that allows us to check for certain clean-code standards and if we are following them.

Installing packages

We will start by installing a few packages:

npm install --save-dev eslint @eslint/js typescript-eslint

Configuring eslint

Next, we will create a file called eslint.config.mjs. It will be pretty empty, only having following content:

// @ts-check

import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.recommended,
);

This just takes what clean-code rules are popular at the moment and enforces them.

Testing

Next, we will set up jest in combination with istanbul to check coverage.

Installing

With following command you can install jest, which also contains istanbul:

npm install --save-dev jest ts-jest @types/jest

Configuring

To configure jest you can add following content to your jest.config.mjs:

// jest.config.mjs
export default {
  preset: "ts-jest",
  testEnvironment: "node",
  roots: ["<rootDir>/tests"],
  testRegex: "(/__tests__/.*|(\\.|/)(test|spec))\\.tsx?$",
  moduleFileExtensions: ["ts", "tsx", "js", "jsx", "json", "node"],
  collectCoverage: true,
  coverageDirectory: "coverage",
  coverageReporters: ["text", "lcov"],
  coverageThreshold: {
    global: {
      branches: 100,
      functions: 100,
      lines: 100,
      statements: 100,
    },
  },
};

Now we can run our tests and see the coverage listed of every mentioned file:

The config a few interesting options, which you can look up yourself. Important are following options:

roots

This defines where the tests are. In this case they are under /tests/.

testRegex

This defines the syntax filenames of tests have to follow. This regex enforces the format something.test.ts but also allows similar names like something.spec.tsx.

coverageTheshold

This defines what percentage of lines have to be touched by our tests. In this case all options are set to 100%, which enforces complete test coverage.

Adding scripts

After adding and configuring both a linter and tests, we need to have a standard way of running them.
That can be achieved by adding following options to our package.json:

{
  "scripts": {
    "test": "jest --coverage",
    "lint": "eslint 'src/**/*.ts'",
    "fix-lint": "eslint 'src/**/*.ts' --fix",
  }
}

Automated testing and git hooks (optional)

To make enforcing of code-quality easier we will add git-hooks and GitHub actions to run our linter and tests.

git hooks

To help us with adding git hooks, we will use husky:

npm install --save-dev husky

Luckily husky has tools to help us with setting up the hook:

npx husky init

This adds following things:

A pre-commit script under .husky
Adds prepare in package.json

Finally, we can add our linter under .husky/pre-commit:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "Running pre-commit hooks..."


# Run ESLint
echo "Linting..."
npm run lint
if [ $? -ne 0 ]; then
  echo "ESLint found issues. Aborting commit."
  exit 1
fi

echo "Pre-commit checks passed."

Now it runs the linter before every commit and forbids us from finishing the commit if there are any complaints by eslint. That might look like this:

Setting up GitHub actions

Now we want to set up GitHub actions so it runs our tests and lints on every push.
For that, we will create .github/workflows/tests.yml. In there we define the workflow:

name: Tests on push

on:
  push:
    branches:
      - '**'

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x, 18.x]
        os: [ubuntu-latest, windows-latest, macos-latest]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        registry-url: 'https://registry.npmjs.org'

    - name: Cache node modules
      uses: actions/cache@v2
      with:
        path: ~/.npm
        key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.os }}-node-

    - name: Install dependencies
      run: npm ci

    - name: Lint Code
      run: npm run lint

    - name: Run Tests
      run: npm test

This runs our tests on ubuntu, windows and macos on versions 16 and 18 of node.
Feel free to change the matrix!

Publishing a package

Finally, we can publish our package. For that we need to create an account under npmjs.com.

Final settings

Some final things we will want to configure before uploading are in our package.json:

{
  "name": "Some name",
  "version": "1.0.0",
  "description": "Some description",
  "repository": {
    "type": "git",
    "url": "git+ssh://git@github.com/user/repo"
  },
  "keywords": [
    "some",
    "keywords"
  ],
  "author": "you, of course :)",
  "license": "MIT I hope",
  "bugs": {
    "url": "https://github.com/user/repo/issues"
  },
  "homepage": "https://github.com/user/repo#readme"
}

Also, we will want to create a file called CHANGELOG.md and reference it in our README. The file looks as follows for now:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [1.0.0] - yyyy-mm-dd
- Initial release

Check out how to keep a changelog and Semantic Versioning to always keep your library understandable.

Manual publish

To publish the package manually, we can do that in our console.
First we log in by running:

npm adduser

That will open the browser window and ask us to log in.
After doing that you can run:

npm run build; npm publish

Automating that work

If you want to automate this work we can configure a GitHub action to automatically publish on npm when pushing a new tag.

YAML config to publish

With following file under .github/workflows/publish.yml a new release gets triggered on every new tag.
Special about this file is also, that it makes sure our package.json has the same version for our package as the pushed tag.

name: Publish to npm registry

on:
  push:
    tags:
      - '**'

jobs:
  check-tag-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check if tag matches version in package.json
        run: |
          TAG_NAME=${GITHUB_REF#refs/tags/}
          PACKAGE_VERSION=$(jq -r '.version' package.json)
          if [ "$TAG_NAME" != "$PACKAGE_VERSION" ]; then
            echo "::error::Tag version ($TAG_NAME) does not match version in package.json ($PACKAGE_VERSION)"
            exit 1
          fi

  check-code:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18.x'
          registry-url: 'https://registry.npmjs.org'

      - name: Cache node modules
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci

      - name: Lint Code
        run: npm run lint

      - name: Run Tests
        run: npm test

  publish:
    needs: [check-tag-version, check-code]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18.x'
          registry-url: 'https://registry.npmjs.org'

      - name: Cache node modules
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci

      - name: Build the project
        run: npm run build

      - name: Publish to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Generating an access token

After adding this, you will need to add an npm auth token to your GitHub Actions environment variables.
Get that key under "Access Tokens" after clicking on your profile picture. Generate a "Classic Token".
On that page, add a name and choose "Automation" to allow managing the package in our CI

Adding that token

To now add that token to GitHub Actions secrets.
You can find that setting under (Project) Settings > Secrets and variables > Actions.
Then click on "New repository secret" and add NPM_TOKEN:

Testing our automated publish

If we did everything correctly a new tag should trigger the "publish" action, which automatically publishes:

Conclusion

Now you can finally check out your own npm package on the official website. Good job!

Accessing local services with SSRF attacks

anes — Mon, 11 Mar 2024 16:06:45 +0000

Introduction

So you thought about a great new business idea for your company: Making an URL-Preview service, that stores the URL for a user and then displays it along with an icon inside a list.
That service should then run locally and get forwarded into the internet by a service like ngrok.
So you start coding and come up with a service that looks as follows: A node.js backend (using express.js) that exposes a few API endpoints so the user can interact with the storage:

app.get('/', (req, res) => {
  res.sendFile('index.html', { root: `${__dirname}/public` });
});

app.get('/api/v1/urls', (req, res) => {
  res.send(userUrls);
});

app.post('/api/v1/add-url', async (req, res) => {
  const url = req.body.url;
  console.log(url);
  console.log(req.body);
  if (!url) {
    return res.status(400).send('URL is required');
  }
  userUrls.push(url);
  res.send('URL added successfully');
});


app.post('/api/v1/fetch', async (req, res) => {
  const url = req.body.url;
  if (!url) {
    return res.status(400).send('URL is required');
  }

  try {
    const response = await axios.get(url);
    console.log(response.data);
    res.send(response.data);
  } catch (error) {
    res.status(500).send('Failed to fetch the URL');
  }
});

And some simple HTML and JavaScript to display everything, and allow the user to add new URLs:

The company architecture

Unbeknownst to you, the company has a few other (security critical) services running:

Both other express.js services aren't meant to be connected to the public internet, but rather to an internal network.

Abusing the vulnerability

Because we don't sanitize the URLs given by the user, we can easily abuse security flaws in the code, which we will be doing in this chapter.

Running the architecture

For testing purposes, I have created this repository, which contains whole server architecture. The README.md contains how to run the project and forward the port trough ngrok.
If you did everything correctly, you should be able to go on your ngrok URL and see something like:

Welcome to your URL storage tool!

Understanding the security flaw

One potential security flaw is that the URL storage app runs on the same network as all the other architecture and also allows us to pass in localhost URLs, without sanitizing them.
To verify that, we first have to see how exactly this storage tool works. For that we add some random domain and submit it. After that we refresh the page:

Now we should check the network tab, to see how much we actually get:

Here we can see following things: The server does the request for us, and we get the whole response back.

Trying to exploit it

Our instinct should be to check what other domains we can get, starting from the more used ports:

localhost:80 <- http
localhost:3306 <- mysql
localhost:3000 <- rails/node
localhost:300x <- additional rails/node apps

By adding both localhost:3000 and localhost:3001 we can see, that those have things running:

What we are now essentially doing is creating this red bridge, to access more than we should:

Inside the HTML we can see that this page calls a route called:

/api/v1/customer-data

If we try to request that one we get what we came for:

Causing more damage

Let's get back to port 3000 now, where we saw that something is running:

Following what we know from the first request we made, maybe we can deduce that this service also follows the aforementioned pattern of API URLs:

/api/v1/...

Now we just try known endpoints there, until we arrive at this one:

http://localhost:3000/api/v1/docs

Adding that URL and refreshing, nets us this in the network tab:

Which is everything we need. We can see that this is some sort of database proxy, used internally to more easily query the database.
As we now may have complete SQL-Access we can try to see what tables the database has, by sending it show%20tables as the parameter:

If we wanted to get crazy, we could try to query a user and all the pills he is prescribed using this query:

SELECT c.firstname, c.lastname, p.name, p.description, p.price
FROM customers c
JOIN customer_pills cp ON c.id = cp.customer_id
JOIN pills p ON cp.pill_id = p.id
WHERE c.id = (SELECT MIN(id) FROM customers);

Converting this query to a URL that we can pass:

http://localhost:3000/api/v1/db-proxy?query=SELECT%20c.firstname,%20c.lastname,%20p.name,%20p.description,%20p.price%20FROM%20customers%20c%20JOIN%20customer_pills%20cp%20ON%20c.id%20=%20cp.customer_id%20JOIN%20pills%20p%20ON%20cp.pill_id%20=%20p.id%20WHERE%20c.id%20=%20(SELECT%20MIN(id)%20FROM%20customers);

Adding this URL and refreshing we can see:

And, as they would say in the movies: WE'RE IN!

The consequences of this breach

Getting root access to a database is bad enough. It gets even worse when that database contains sensitive medical information.
There are lots of ways to abuse this security flaw. One of them being a "double-extortion", which we could do as follows:
First, we dump everything from this database that we can dump. And by that I mean query every table we can see and then store everything we got locally.
Then, we can use our privileges to delete the customer data, and hope that they don't have a backup.
Finally we inform the victim that we want money for two separate things: Returning the deleted data AND not leaking this confidential customer data.

Preventing the exploit

One simple way to prevent this security flaw is by sanitizing the given URLs, by for example returning a 400 every time localhost is mentioned:

app.post('/api/v1/add-url', async (req, res) => {
  const url = req.body.url;
  if (url.includes('localhost')) {
    return res.status(400).send('Invalid URL');
  }
  //...
}

Keep in mind: This isn't enough, as URLs that replace the localhost with 127.0.0.1 are valid and still locally. Please sanitize further in this case!

A safer fix

A safer way to fix this, is to have the URL app running on a different network and separate it by a firewall

The OWASP definition

Luckily OWASP has a good article about this exploit, how often it happens and how well it is covered.
Please read that one for further information.

Conclusion

While exploiting vulnerabilities is highly illegal it is still important to understand how they work.
This example showed a very real thread of exposing anything on a local network, especially if (unsanitized) user input is run.
Code Responsibly!

Randomizing pages titles (and having good SEO)

anes — Tue, 20 Feb 2024 18:47:37 +0000

I recently implemented a new feature on my portfolio website where the website randomizes its title every time its refreshed.
An example of that:

This article is about how I implemented this (with code examples in NextJS) and how I fixed my SEO.

Why would you need to fix your SEO?

The issue with the changing page titles is simple: Every time the google crawler goes onto your website he sees a different title that gets indexed, changing it in the search results.
That can mess with your SEO, as something like "[Your Name]'s personal website" is much better for finding the website than "Ran on my machine".

Implementing the titles

This tutorial on how to implement it will be in NextJS, but you can follow along in every language, as it shouldn't change depending on the language.

Setting the title for the Google crawler

First you want to go on your _document.jsx, or inside of any layout page that you have, like application.html.erb if you're implementing this in Rails. There you want to set the boring title, or the one that should get indexed. In addition to that you want to set the meta description and your favicon:

// NextJS code example
<Head>
  <meta
    name="description"
    content="I need to make the computer overlord happy, so: Anes Hodza made this! This is Anes Hodzas' digital property!"
  />
  <link rel="icon" href="/favicon.ico" />
  <title>Anes Hodzas' personal website</title>
</Head>

Creating the custom titles

Then you want to go to your index page (the one that gets shown on /).
There you want to create a const array with all your titles as strings:

const titles = [
  'Ran on my machine',
  'Web developer? I think?',
  'Engineer is an overstatement',
  'I\'m testing this in prod',
  'Does anyone read these?',
  'I\'m not a robot',
  'http://localhost:3000',
  'I don\'t use arch, btw'
]

In the case of something like Rails, where the backend logic is somewhat separated from the html code, you would probably put this in the controller.

Sending the user your custom titles

It's very important that the changing page titles are handled in the backend, as otherwise Google starts indexing your webpage weirdly.
In the case of NextJS you would want to create a getServerSideProps function:

export async function getServerSideProps(context) {
  // ...
}

Now in there we want to pick the title randomly and return it as a prop:

export async function getServerSideProps(context) {
  const index = Math.floor(Math.random() * titles.length);
  let title = titles[index];

  return {
    props: {
      index,
      title
    }
  }
}

Now if you start refreshing your page you should see that the title changes.

Fixing Google SEO again, because it's better to be safe than sorry

The Google crawler for some reason sometimes still indexes a random title, so we will also have to change that in the server-side function. What we do first is define a function that checks if the useragent is any google crawler. That we can do as follows:

const isGooglebot = (userAgent) => {
  return /(googlebot|google-inspectiontool\/1\.0)/i.test(userAgent);
};

Why not just match any occurrence of Google you might ask. It's just a precaution in case Chrome decides to adapt the word Google into its user agent string.

And now you also have to call the function and return your wanted title in case its the crawler:

export async function getServerSideProps(context) {
  const index = Math.floor(Math.random() * titles.length);
  let title = titles[index];

  let userAgent = context.req.headers['user-agent'] || '';

  if (isGooglebot(userAgent)) {
    title = "Anes Hodzas' personal website"
  }

  return {
    props: {
      index,
      title
    }
  }
}

And after waiting for Google to index your website again, you should be good to go!

Won't this get marked as cloaking?

I had this feature on for two weeks by now and there wasn't any indication of it being marked as cloaking:

In case anything happens, I'll keep you updated!

Getting out of tutorial hell

anes — Tue, 29 Aug 2023 22:53:50 +0000

Introduction

We have all been there; You are watching the next hours long tutorial on language X or on framework Y, but for some odd reason you feel like you don't know anything in the end.
That's what I call "tutorial hell" and with this article I hope I can teach you how I was able to leave tutorial hell and productively learn new languages.

Why don't tutorials work?

The reasons can be vastly different from person to person, as everyone has their own style/pace of learning. Nonetheless here are some reasons I found that cause tutorials to be ineffective:

Pace

Due to the tutorials needing to be made for a broad audience the pace will be off for most people: It either starts at the wrong skill-level or is overall just too fast/slow.
That can be very frustrating, as having to skip around the video all the time costs a lot of time and feels like you did nothing in the end.

Lack of interactivity

The biggest problem for me personally was, how little you have to think on your own when following the videos.
You simply just type whatever the person in the video is typing while their voice attempts to explain what exactly is happening, in vain.
The lack of solving the coding problems yourself causes you to not learn how you would approach a new problem. That in turn renders you unable to make products on your own.

Over-simplification

Something I always tried to fight with my articles like Frameworks hurt junior devs (and why math is important) is the neglect for properly understanding a topic.
Being able to create 100 different Web-Apps in Rails using Devise (the authentication gem) doesn't mean that you actually understand what is happening and what you're doing.
This shallow knowledge might be fine for a while, but it won't be long until you hit a, for you, unfixable problem because you actually have no idea what you are making. You only know how you are making it.

The "Question Framework" as your savior

In a YouTube video about exactly this topic I heard the YouTuber use the name "Question Framework" to something I have been doing for a while now. I liked the name a lot, so I decided to adopt it.

What is the "Question Framework" and how does it work?

The Question Framework attempts to teach you, the user, something in a more interactive way by letting you figure out and solve problems on your own by asking the right questions.
There are a few easy steps which you strictly have to follow:

Set an end goal
Ask yourself "What do I need to do next?"
Google how to do that specific task
Repeat step 2 And it's as easy as that! An example is how I taught myself rust:
Build a command line tool that reminds you about peoples birthdays
I asked myself "How do I create a new rust app?"
I googled it and found out I can simply run the command rust new appname
I asked myself "How do I read a text file and save it to a variable?"
I googled and found out that read_to_string(&dir).expect("Unable to read file"); does the job
Next I asked myself "How do I parse the file to users?"
I googled...

Well, you get the idea. By following this principle you will probably need a lot longer to create your first product, but creating the 2nd one will be much easier, as you already had to face problems and think about solutions on your own.
For anyone interested, the rust project is here

Conclusion

Next time you want to learn a new skill, try to challenge yourself with the Question Framework. This approach to learning new languages enables you to get a much deeper and more useful understanding of concepts and languages.

An opinionated article about vim

anes — Fri, 30 Jun 2023 09:10:29 +0000

Introduction

I have now been using vim and neovim for almost a year. In that time I built a lot of experience with the IDE, which I wanted to share with people thinking about making the switch.
This article will mostly just go over why I like vim, but I'll also be talking about some disadvantages.
When showing code to use as an example of editing, I'll be taking code from my own Redmine plugin: gnosis.

Super fast code navigation

The most obvious and most talked about point is how fast you can navigate code with vim. There are a lot of keybindings used for jumping around code. One example would be following:

protect_from_forgery except: %i[github_webhook_catcher semaphore_webhook_catcher]

Now if I want to remove the github_webhook_catcher from the protect_from_forgery statement, I would go following steps (assuming my cursor is somewhere completely random): :4 WWW db does the job. Here is a video of how that might look:

There are a lot more keybindings and tricks that improve your speed. If you have trouble memorizing them all, this cheat sheet was A-tier.

Extreme configuration

A personal favorite is how much you can personalize vim. Everything is customizable, from your background color to very specific keybindings. One example of that would be my own .vimrc.
As someone who gets irritated as soon as something tiny is wrong with their code editor, the ability to customize everything was a very big bonus.
Currently I am using nvchad with my own nvchad config, which makes for a beautiful code editor:

Very good plugin system

(Neo)vim supports plugins, which make your code editor much better. You need a faster way to comment stuff? Sure, here is nvim-comment. Now you need a better tool to surround text by certain characters? Alright, we also have nvim-surround. And this goes on for almost everything you ever needed.
And in the rare case that you can't find a plugin for what you need: Write it yourself! It's very easy to write plugins, as vim and neovim both have a lot of functions that help with writing those.

The steep learning curve

The biggest problem to vim is its steep learning curve. If you're someone who is already in a commercial setting and need to produce at a certain speed, learning vim will be pretty hard. As someone who is still in education I had the option of killing my coding speed for a few months, just so I could learn vim.

Alright, I'm convinced. Should I use vim or neovim?

That choice everybody should make for himself, but I use neovim.

What's the difference between vim and neovim?

The major difference is that neovim uses lua for its plugins, which vim is still on vimscript.
Most people prefer lua, as it's more intuitive to write and has loads of uses outside of writing neovim plugins, making lua a much more useful language than vimscript.

Which one has better plugins?

From personal experience, neovim has much better plugins, while not more.
The fact that they're written in lua makes them more performant than vimscript, which already is a big benefit. On top of that: The fact that learning lua is much more useful than vimscript means that more people are willing to spend time learning it, making neovim plugins feel much more refined.

Example comparison: fzf-vim vs. telescope

As someone that has been using fzf for most of the time, changing to telescope opened up so much more options. Telescope has integrated git diffs, commit histories, language server settings, and much more.
This is an example of how the commit history check looks like

Conclusion

I think learning vim is something everyone that is still in education should do, independent of if you actually stick with it or not.
The great amount of configuration and useful keybindings makes using vim a great experience.

Memory in Rust

anes — Wed, 14 Jun 2023 16:01:46 +0000

Introduction

I recently started getting more and more into Rust, as I wanted to adopt a fast programming language into my tech-stack. Coming from Java and Ruby I had various mountains to climb, one of them being Rust and its relation with memory. This article aims to explain it in an way that is easy to grasp for beginners.

Memory allocation

To understand ownership and borrowing we first need to understand how the memory is allocated. Rust allocates memory based on if the data size is fixed or dynamic.

Static Allocation

On data types like i32 that have a fixed memory size, rust opts for static allocation on the stack.

Dynamic allocation

Dynamic memory allocation happens on the heap. In this case, the needed memory to store a value can change over time, like with the String type:

let mut string = String::from("abcd");
s.push_str("efgh");

In this case (assuming the String is UTF-8 encoded) the variable first needs 4 bytes and then 8 bytes:

Memory management

Rust manages the memory at compile time, which means it doesn't have a garbage collector to find dead memory. That allows the code to run faster, but can also be the cause for memory leaks. To circumvent leaking memory and causing the code to slow down or crash after a while, the compiler enforces a strict set of rules. Those can primarily be split up into: ownership and borrowing.

Ownership

Every value in Rust has a variable that owns it. So for example:

let x = 5;

Would make x the owner of our 5. When x goes out of scope the value will be dropped, as there isn't any owner left. That would look as follows:

{
    let x = 5;
    println!("{}", x); // This prints: "5"
} // Here the memory is dropped
println!("{}", x); // This gives a compiler error

And when we check what the compiler says we see exactly what we predicted:

Now when we assign x to another variable, like y normally we change the owner. That means, that after we do let y = x accessing the variable x will render an error. Following code example is used:

let x = String::from("5"); // Initialize x as "5"
println!("{}", x); // This prints: "5"
let y = x; // This moves the value "5" from x to y
println!("{}", x); // This throws an error

Here, the second println! statement will error, as we try to borrow (explanation in next chapter) x, after it has been moved to y:

It's quite visible what happened: x does not hold the value anymore.
If you're wondering why rust doesn't allow two variables to reference the same value, consider this scenario:

{
    let x = String::from("5")
    let y = x
} // <- Here the value goes out of scope

On line four the value references by x and y goes out of scope, which makes rust call the drop function (in the case of dynamically allocated values) to free the memory. Now because both variables go out of scope it runs drop(x) and drop(y), which causes a "double free condition", which means that both try to free the same memory. This won't happen with languages that have a garbage collector, because the collector properly clears.

The copy trait

While that's the default behavior, certain types like integers, floats, etc. implement the Copy trait, which changes how the move operation behaves.
Let's take the move code again, but with i32 as its data type instead of String:

let x = 5; // Initialize x as an i32
println!("{}", x); // This prints: 5
let y = x; // This copies the value instead of moving it
println!("{}", x); // Now this works fine

When can we copy and when not?

If we think back on how memory is allocated, it should be pretty obvious: If a variable is statically allocated the Copy trait is included.
The issue with having the String type implement Copy is, that Copy creates a bit for bit copy. A simple example of why that is an issue would be as follows: As the String is stored on the Heap, it needs to have a Drop function, which clears the heap memory. The Drop works, by taking the pointer, that every String has to a memory address and clearing the memory there. The issue with using Copy is, that it's a bit by bit copy, which would mean that the pointer is the same in both Strings. When the scope ends, Drop is called on both Strings, which would cause a "double-free", which causes the program to error.
As a replacement for Copy, those data types tend to implement Clone, which, depending on the data type, can have very complex logic to properly copy the values and give it a new

Borrowing

The issue with rusts ownership system is, that with a few function calls we can quickly have a lot of variables. That can look as follows:

fn main() {
    let s1 = String::from("hello");
    let (s2, len) = calculate_length(s1);
}

fn calculate_length(s: String) -> (String, usize) {
    let length = s.len();
    (s, length)
}

A better approach would be to using "borrowing". A borrow is signalized with the & symbol. That gives the variable temporary access to the variable.
A simple example would be this:

let mut x = String::from("Hello");
let y = &mut x;
y.push_str(", world");
x.push_str("!");
println!("{}", x);

Here we are able to push to x by accessing both x and y. The difference to just doing let y = x is, that the type of y is different now:

fn main() {
    let mut x = String::from("Hello");
    let y = &x;
    print_type_of(&y); \\ &alloc::string::String

    let z = x;
    print_type_of(&z); \\ alloc::string::String
}

fn print_type_of<T>(_: &T) {
    println!("{}", std::any::type_name::<T>())
}

We can also improve our function from before by using borrowing:

fn main() {
    let s1 = String::from("hello");
    let len = calculate_length(&s1);

    println!("The length of '{}' is {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

Already looks much cleaner, doesn't it?

De-referencing

Let's say we want to create a function that takes in a i32 x and mutates that value. The first thing that comes to mind would be as follows:

fn main() {
    let mut x: i32 = 10;
    double_number(&mut x);
    println!("the value doubled is {}", x);
}

fn double_number(x: &mut i32) -> () {
    x *= 2;
}

But this will throw an exception, as x (inside the function scope) is only a reference to the value, instead of the value itself:

It is only the reference, because the parameter x has been borrowed by using & when passing it. Now if we want to access and manipulate the value we "de-reference" it by using a *. Here is the same function, but corrected:

fn main() {
    let mut x: i32 = 10;
    // double_number(&mut x);
    println!("the value doubled is {}", x);
}

fn double_number(x: &mut i32) -> () {
    // x *= 2; // This would mutate the pointer position x
    *x *= 2; // This will mutate the value at the pointer position x
}

An example that is easier to understand:

let mut x: i32 = 10;
let y: &mut i32 = &mut x;
*y += 1;

Here we are making y a mutable borrow of x, i.e. a reference to x. To then be able to manipulate the value x trough y, we "de-reference" it.
We can visualize it like this:

Conclusion

Rust trades off efficiency for simplicity, which can make it hard for developers to understand how memory is managed. I hope you were able to learn something from this article.
Thanks to Low Level Learning for a very comprehensible explanation of almost every topic talked about in this article.

Is learning LaTeX worth it?

anes — Wed, 07 Jun 2023 18:38:27 +0000

Introduction

So I just finished my final project to get the "Swiss Certificate of Competence" in software development. That project consists of two major parts: Writing software and documenting it.
The software part was a Redmine plugin, which you can find here. The more important part, the documentation, you can find here. After small deliberation I decided to write it in LaTeX, based on a template. This articles goal is to share my experience with LaTeX.

What is LaTeX?

LaTeX is another way to write documents, like MS Word or Google Docs. But instead of the "What you see is what you get" approach taken by those editors, it takes a completely different one: You "code" the text. That leads to very fast (and mouse-less) writing, which has highly specialized results. For example, my documentation for the finals, had a chapter about the tools I was using. The source code for it looked like this:

\newpage
\section{Entwicklungsumgebung}
\subsection{Versionierung}
Für die Versionierung wird Git verwendet. Dabei wird GitHub als Remote-Repository verwendet. Das Repository mit
dem Source-Code kann unter \url{https://github.com/aneshodza/gnosis} gefunden werden. Für eine genauere Beschreibung
der Versionierung siehe Kapitel \ref{sec:versioning}.
\subsection{IDE}
Als IDE wird vim mit verschiedenen Plugins verwendet. Bestimmte Sachen wurden in der \bgmintinline{bash}{.vimrc} Datei
konfiguriert, damit die Arbeit möglichst effizient ist. \newline
Diese Konfigurationen sind unter \newline
\url{https://github.com/aneshodza/.dotfiles/blob/ad87ee9ecc5588a59d66e211797792099569ca95/.vimrc} zu finden.
\subsection{CI/CD}
Für die CI/CD Pipeline wird SemaphoreCI verwendet. Das ist passend, da auch die PA sehr eng mit SemaphoreCI verbunden
ist.

Which turned into this:

You can see: automatic page enumeration, showing the current date, numerated titles, professional font and a lot more.
To be fair, that was achieved by using a template, but that's how LaTeX is supposed to be operated: You pick a nice template and write your documentation based on that.

The advantages of LaTeX

LaTeX has a wide variety of advantages to software developers, especially which are in education.

Uniform and professional designs

Every documentation written in LaTeX can look the same, have the same formatting and the same feel, as long as the same template is always used.
Something that helped me a lot in my finals: There were a lot of points given by simply conforming to formatting rules (like having a header with the title, page enumeration, the current date in the footer) etc. All things that were done for me, simply by using a template.

Git versioning

Having a safe versioning of your documentation may not be a bad idea. While you can also do the same with docx files, versioning LaTeX files is seamless due to the text being written and stored as actual text. Diffs just show that a binary file has been changed, but you can't really retrace your steps:

While in LaTeX, that looks a lot better:

Work speed

The speed at which you can write documentation is a lot faster in LaTeX that most WYSIWYG editors. You can write it completely on the keyboard and even use your fancy code editors (like the most supreme: vim). Language servers make things like cross referencing very easy and other things like a table of contents or a bibliography are generated (and in the case of the bibliography even alphabetically sorted).
After getting a grip on LaTeX you will feel the speed at which you write documentation going up.

Conclusion

My personal experience with LaTeX is overall very positive and I would definitely suggest every student to learn it. My finals look very professional and conform to every formatting standard expected from it.

Looking for ruby open source contributions? Find them here.

anes — Fri, 19 May 2023 12:40:44 +0000

I just wanted to start a small prompt, where open source projects that need contributions in ruby find contributors skilled in ruby.
Happy hacking :)

Creating multiple accounts with one E-Mail address

anes — Wed, 12 Apr 2023 15:03:19 +0000

The problem

When I was coding my first twitter bot, I ran into a major issue: I needed to register a new account for the bot, which required me to provide a unique email address.
There was one big issue with that: I had the intention of making multiple bots, just to test the capabilities of the twitter API.
I quickly realized that creating a new email for everyone of those would be really cumbersome and unmanageable after a while.

Making use of "Address Aliasing"

I quickly found out about a neat little trick called "address aliasing". What it does is, allow you to add a "tag" to your email address, without actually changing it.
For Gmail and many other services you simply add a plus sign (+) right before the at (@) and add some text between the plus and at.
That could look as follows:
some.example@gmail.com --> some.example+devto@gmail.com
And that's also what I did for my bot account.

Important things to keep in mind

If you are using a different provider than Gmail, there may be a different syntax for doing this.
It won't work for all services, as some built tag checks into their uniqueness check. For me it has worked everywhere I used it.

DEV Community: anes

WCAG: Making the internet more accessible

What WCAG actually is

POUR Principles

Perceivable

Operable

Understandable

Robust

Conformance Levels

Why it matters beyond compliance

What most websites get wrong

1. Contrast ratios

2. 400% zoom without horizontal scroll

3. Missing or lying ARIA labels

4. Missing focus states and keyboard traps

Keyboard traps

The point

Tools that helped us

Lighthouse reports

axe DevTools

AI Agents

The uncomfortable takeaway

Building LocalMate at Hack Winterthur

The Challenge

Why this is personal

48 Hours of Building

What LocalMate actually is

The Architecture

Data Ingestion

Vectorization

Retrieval

Multilingual by default

What makes it different

What's next

WinLab

Launch Control Incubator

Beyond Winterthur

The takeaway

Ruby function design and other stuff I like ranting about

Why?

How?

Okay, so shouldn't this work for accessing arrays?

What about scientific notation?

?!

Actually converting scientific notation to a number

Where is this leading?

Publishing your first npm library

Introduction

Librarification of your code

Using typescript (optional)

Coverting your files

Changing folder structure

Setting up the ts compiler

TypeScript config

*.js

.d.ts

.js.map

ESNext issues when using TypeScript

Reflecting the changes in our package.json

Adding JSDocs

Creating the "entry point"

Setting that in our package.json

Clean code and testing (optional)

Clean code check

Installing packages

Configuring eslint

Testing

Installing

Configuring

roots

testRegex

coverageTheshold

Adding scripts

Automated testing and git hooks (optional)

git hooks

Setting up GitHub actions

Publishing a package

Final settings

Manual publish

Automating that work

`*.js`

`.d.ts`

`.js.map`

Reflecting the changes in our `package.json`

Setting that in our `package.json`