last year, masp's new annex opened to the public. i had the opportunity to visit at opening week. a few weeks before that, i bought a tiny thermal camera that prints on receipt paper.

path

using the tiny camera is lots of fun. i get to print and see the image as soon as they are taken.

the paper is also cheap (a lot cheaper than instax). i could even reuse regular print paper, which is something i do actually want to try out in the future.

some little chairs i found on the way.

anexo

the annex is out of place and discrete at the same time.

it does not draw much attention to itself.

while contrasting the original building by bobardi.

the annex was actually built on top of a pre-existing building. they reused some of the foundations and original structure.

i was trying to use pandoc with arch, but was getting an error when trying to convert a markdown to pdf.

conversion snippet:

pandoc document.md -o document.pdf

resulted in:

Error producing PDF.
! LaTeX Error: File `xcolor.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name: 
! Emergency stop.
<read *> 

l.7 \usepackage

to use pandoc you first need a tex engine, like texlive:

sudo pacman -S texlive

i installed only the ones that seemed relevant, as all packages amount to over 1 GB (??).

turns out, i was missing something. this reddit comment helped me out:

If you want to figure out which one you need to install to get a certain LaTeX package, use for example pacman -F bbm.sty. You will need to run pacman -Fy once if you have never used pacman -F at all.

very good to know. running it:

sudo pacman -F soul.sty

gave me:

extra/texlive-plaingeneric 2025.2-3 (texlive)
    usr/share/texmf-dist/tex/generic/soul/soul.sty

which i just had to install with pacman.

microsoft's documentation for between doesn't mention inclusivity at all until section b, which suggests that between is inclusive. the information is only really explicitly stated all the way down in section d, where it states that (for datetime values, at least), between is inclusive.

however, as i have come to find out (not before a whole hour of debugging): it ... depends?

context

lets create a table with two columns. date_vc is a varchar that follows the formatting '%d/%m/%Y' (as per the usual cron formatting¹). date_dt is a datetime column.

this was an issue i ran into at work, involving real data. here, i'll demonstrate it with a sample table.

here is a sample sql script to create the tables and insert some values into them.

create table tsql_testing(
    [date_vc] varchar(20) not null,
    [date_dt] datetime not null
)
insert into tsql_testing (date_vc, date_dt)
values ('15/12/2025', '2025-12-15 23:48:13.000')
insert into tsql_testing (date_vc, date_dt)
values ('09/12/2025', '2025-12-09 23:48:13.000')

now, notice that, as previously mentioned, date_vc has string values with style 103 ('%d/%m/%Y'), the British/French standard as per microsoft's own documentation.

between is (not?) inclusive

if we try to select the following using between, what should be the expected behavior?

select date_vc, date_dt from tsql_testing
where convert(datetime,date_vc,103) between '2025-12-09' and '2025-12-15';

we convert the varchar column date_vc to datetime, and select between those two dates.

as alluded to in microsoft's own documentation, we do get that this between select is indeed inclusive, as we fetch the following from the select:

date_vc	date_dt
09/12/2025	2025-12-09 23:48:13.000
15/12/2025	2025-12-15 23:48:13.000

note that, even if we were to use the 103 standard with between '12/09/2025' and '12/15/2025', we'd still get the same response.

now, if we do the exact same select for the datetime column date_dt (again, it doesn't matter which standard and formatting you pick):

select date_vc, date_dt from tsql_testing
where date_dt between '12/09/2025' and '12/15/2025'

we get a response non-inclusive of the second value:

date_vc	date_dt
09/12/2025	2025-12-09 23:48:13.000

is this a quirk of tsql? or is this also in other sql dialects?

a rant

it is a tremendously unpleasant experience to find out that a bug derives not from a mistake i have made, bet from an undocumented issue from the tool i am using. all the more aggravating when this is not someone's foss passion project, but a prod tool by a massive tech company (which we pay good money to deploy on their azure servers). well, at least this is not as bad as powerbi.

The finest qualities of our nature, like the bloom on fruits, can be preserved only by the most delicate handling. Yet we do not treat ourselves nor one another thus tenderly.

i tried using the auto builder, but either i did something wrong, or there is a bug with it. nikola depends on the python package watchdog for the continuous auto-build. i might try it again some other time.

for now, this blog is built with the following sequence of commands:

nikola check --clean-files
nikola build

and served locally with:

nikola serve -b

in one line:

nikola check --clean-files && nikola build && nikola serve

the first line cleans up any files that no longer exist from the output directory (docs, because github pages is unloved).

new "tabs" can be added with through the NAVIGATION_LINKS variable in conf.py ¹. here is what that variable looks like attow:

NAVIGATION_LINKS = {
    DEFAULT_LANG: (
        ("/archive.html", "archive"),
        ("/categories/", "tags"),
        ("/rss.xml", "rss feed"),
        ("/pages/about/index.html", "about")
    ),
}

checking if a task has failed in airflow is simple enough, and may be done with:

from airflow.operators.python import get_current_context

@task
def check_task_failed(task_id: str) -> bool:
      context = get_current_context()
      return (
          context["dag_run"].get_task_instance(task_id=task_id).state
          == State.FAILED
      )

however, if the task is nested within a task_group, referencing the task with task_id doesn't work. in theory, tasks inside a task_group should be indexed with group_id.task_id¹, but trying get_task_instance with this ID structure will return a NoneType.

the one way i have found to actually make it work, is with the following:

from airflow.operators.python import get_current_context

@task
def check_task_failed(group_id: str, task_id: str) -> bool:
      context = get_current_context()
      failed_tasks = context["dag_run"].get_task_instances(state=State.FAILED)
      return f"{group_id}.{task_id}" in {
          ft.task_id for ft in failed_tasks
      }

which i was able to implement based an answer on stackoverflow².

before finding that answer, i struggled with missing docs, llm hallucinations. and what i am fairly sure were people posting llm bullshit as if it were real.

looking at the commit history for the repository containing the source for this blog, you may notice that this was originally my personal website/cv.

my initial intention was to setup the present blog on a separate branch, but i forgot to switch branches before deleting everything.

in any case, i suppose i'll have to commit to this now. so here is a test post.

testing out

originally, i attempted to use jekyll for this blog, as it is already integrated into github pages. however, after some frustration (as had happened years ago when i first tried it), i decided to look for a different blog building tool.

one of my main points of contention with jekyll is that it uses ruby, which i don't have anything against, but am also entirelly unfamiliar with. therefore, i went searching for a tool that allowed me to stay within what i alredy know (namely, python), and that had built-in markdown support.

i also want it to be doing most of the work. i am not too interested in messing with templates and such at the moment. all i want is to get started on throwing stuff out there.

so i landed on nikola{:target="blank"} for static site generation. it even has built'in support for _extended markdown, seeing that the footnotes are working nicely.

it does have support for images in markdown, but...

here is what the markdown for the previous photo looks like:

![a photo i took while biking in chicago](../../images/2025-03-30_16-37_chicago-skyline-biking.png)

which seems fine, except that this is what the folder structure of this repo looks like (with some omissions for readability):

.
├── images
│   ├── 2025-03-30_16-37_chicago-skyline-biking.png
│   ├── frontispiece.jpg
│   └── illus_001.jpg
├── output
│   ├── images
│   │   ├── 2025-03-30_16-37_chicago-skyline-biking.png
│   │   ├── 2025-03-30_16-37_chicago-skyline-biking.thumbnail.png
│   ├── index.html
│   └── posts
│       ├── setting-up
│       ├── index.html
│       └── index.md
├── posts
│   └── 1.md
└── README.txt

i am writing from ./posts/1.md, and i am placing my image in ./images/. after the build, my post is in ./output/posts/setting-up, and the image is in ./output/images/. meaning that while in this markdown i can use intellisense to access the image with:

../images/2025-03-30_16-37_chicago-skyline-biking.png

however, because the image in the output build is in a different directory, i need to add an additional ../ to the beginning of the image reference¹.

anyway, this is more of a minor pet peeve, so it is fine i guess.

addendum 1

ok, i have another pet peev, this time with github pages. for whatever reason, github pages only allows deployement from root or from /docs²?

so i had to change the output folder of this repo to docs, with the following addition to nikola's conf.py:

OUTPUT_FOLDER = 'docs'

addemdum 2

one last thing for this test post.

nikola came with a number of files in its demo. i deleted them manually, and then followed the instructions from the getting started page:

nikola check --clean-files