Oh boy, where do I even start with this...?
Someone posted yesterday to Hacker News their new project:
Meoweler, a cat-themed travel website that's almost entirely auto-generated.
I have written here before about
the realistic dangers of AI, predicting that we would see "garbage in any
medium that offers even the slightest of rewards, financial or not". And boy
was I right...
Here's a short, non-exhaustive list of problems I found with this website:
- Offensive stereotypes. About half the Argentinean cities I've checked
are based on stereotypes about the country, regardless of whether
they are even remotely applicable.
- Offensive pictures. I grew up in not-so-popular cities across the country
and I can tell you: I wasn't born in a war-torn city, I didn't go to school
in Tatooine, I didn't study in a
mirror-like desert, and I didn't go to University on a mountain city.
I just lived in perfectly normal, standard, slightly boring cities.
But you wouldn't know any of that by looking at the Midjourney-generated
illustrations for each one of them.
- Bad information. I don't care that much that the AI suggests that Potsdam's
is a "mini version" of the one with the same name in
Berlin (which AFAIK is
not true), nor that it talks about getting lost "in the maze-like streets
of the Old Town" for the squarest blocks you'll find outside of Manhattan.
But when your list of attractions includes sightseeing points in cities
more than 200km away... and in a different Province... I hope you remember
to bring your good walking shoes.
- Dangerous information. The site includes an "LGBTQ safety" rating which is
auto-generated and not checked against any official source. The guide will
also gladly include locations "off the beaten path" that are plain unsafe
for a tourist. One such advice suggests "lounging in sunbathed plazas" in
a city that Travel Safe - Abroad
rates as having a high risk of pickpockets and medium risk for muggings.
And while I'm not here to tell you how to live your life, I think "don't"
is a solid advice for this situation.
The source code for the website is open, and the license seems to be
"do whatever you want with it, no restrictions". And you know what?
People will do whatever they want with it: they will spin God-knows how many
clones (dog themed, child themed, circus themed, ...), slap ads on it, and
the internet will drown a little more in auto-generated, unchecked, ad-ridden
But hey, at least the website has the tiny footer "Beware, most of the content
was generated by AI". So if you end up being robbed at gunpoint because you
went "off the beaten path" it will actually be your fault.
One final digression: I decided to check some of the cities listed as "Do not
in the US State website and I landed on Kabul, Afghanistan, which the US warns you against visiting due to armed conflict,
civil unrest, crime, terrorism, and kidnapping.
The AI description reads "Kabul is a friendly city: despite the violence,
Kabul residents are extremely hospitable and friendly towards visitors", which
to me as a (computational) linguist is fascinating: if the locals are hospitable
and friendly, then who is perpetrating "the violence"? Is this sentence blaming
foreigners for the situation in Kabul? Can someone kidnap you and be
hospitable at the same time? And since we know that a guest who kills their
hosts in their own house loses privileged status, does robbing,
kidnapping, and maybe murdering your visitors mean that you lose your status
as a friendly city?
I would say that I'm maybe overthinking it, but let's be honest: given that no
human thought of any kind went into this entire website, literally any attempt
at understanding it is, by definition, overthinking.
(I have changed the title of this article to add a "(I)" at the end. I get the
feeling this is far from the last entry in this series...)
Looks like I wrote this article and forgot to publish it for a whole month.
I hope the extra length will make up for it.
Now that the 61st annual meeting of the ACL is over,
and based on my experience as a member of the Virtual Infrastructure Committee,
I would like to share some thoughts on what my ideal virtual conference
infrastructure would look like.
A conference, for our purposes, is an event that takes place in some random
venue around the world. Researchers submit papers with their latest research
results and, if accepted, present those results in sessions where related
papers are bundled together. Conference attendees typically hear a short talk
about the paper (or read a poster) and then ask questions to the authors.
Given that we live in a post-pandemic world we are going to prepare for a
hybrid conference. This is cheaper (less mouths to feed means lower fees)
more accessible (researchers in countries with less
resources will thank you for the plane ticket and hotel costs they'll save),
greener (less people flying around), easier to archive, and a good idea overall.
It is traditional in conferences to offer a handbook containing all information
about the conference - schedule, paper abstracts, venue maps, social events,
tourist info, sponsors, and so on. But given that this year's booklet reached an
impressive 462 pages it may be time to think about a website or app to replace
I do not believe that the conference website and the handbook can be unified,
for reasons I'll explain later. So let's assume we want to develop a website
or app exclusively for the handbook. Let's call it AppBook.
The main use cases for AppBook are:
- Checking the schedule to figure out either what's going on at some time
(exploration) or to find out when is a specific event taking place
- Adding reminder for events you would like to visit, from entire events down
to specific talks. It is not unusual to be there for Paper 1 in Room A,
then go to Room B next door for Papers 2 and 3, and so on.
- Get details about a specific paper: if the title catches your attention then
you may want to read its abstract, and/or you may want to see what else
the authors are presenting.
- General information about the venue: maps, tourist info, vouchers, etc.
The schedule is, I believe, the hardest part. Sure, there are plenty of
scheduling apps around that do the information retrieval part quite well,
but how about the exploration part? Taking the EACL 2023 handbook as an example (because I have it here on
my desk): I can see that Session 6 on Day 2 has two Tracks I'd like to visit,
namely, "Information Extraction" and "Generation". With the paper booklet I
can put one finger in the Schedule page, flip back and forth through the pages
for each Track, decide which one is more interesting at which time, and plan
my visit accordingly.
Compare that to a regular website calendar: clicking on a Track takes you to
the abstracts, but clicking "back" takes you to the general calendar. In
the specific case of the talk I heard today that means scrolling back down
to the correct time slot, clicking on "+", finding the right Track (there are 13
parallel workshops), open this Track and, since the interface doesn't
allow for right click, remember somehow what the previous one had to offer.
Repeat this for all 3-4 Tracks that one could consider, and this quickly turns
into a mess.
This leads me to the first three requirements:
- AppBook has to be lightning fast, which in this case means offline.
Sure, you can periodically download updates to the database, but there is
no way to implement "lightning fast" when you have 2k+ attendees checking
the website at the exact same time with shoddy WiFi. I can tell you that
a full conference fits in ca. 10Mb of JSON.
- The interface has to trivially allow back-and-forth between all events
taking place in parallel. Swiping left/right to switch Tracks could work,
but I'd have to play with a prototype first to ensure it's not confusing.
- It has to be mobile first. If you want to get rid of the handbook you need
to ensure that even the humblest of devices can provide an equal or better
experience than the paper version. When in doubt, remember that computer
interfaces could already do this type of stuff in real time 20 years ago.
Even though I insisted on AppBook being offline first, it would be foolish to
ignore all it could do if we judiciously let it go online.
At its most basic, you should be able to download the actual papers directly
from the interface. The next step is allowing access to both pre-recorded
and live videos, which is a lot of work on the backend but relatively
straightforward on the frontend. And if your internet is down you'd still have
the handbook information.
Chat, on the other hand, is where I think the app could shine. Having a
dedicated chat for every paper is a great way to ensure that all attendees can
contact you, which helps in-person attendees to talk to you even outside your
presentation window and empowers virtual attendees to talk to authors they
would otherwise miss. And even better: once you allow attendees to create their
own channels you can sit back, relax, and watch communities of like-minded
people come together, plan events, and have fun.
If you choose to go this way then you could consider adding a feature to
AppBook: "log me in as author". If you register as the author of a specific
paper then you would get some extra functionality such as administrator rights
over channels for your papers, notifications whenever someone posts in there,
and reminders of where and when you are supposed to go.
And finally, if you use something like Zoom then you may want to disable the
chat function in videos. Sure, people may be used to it, but if you leave them
on then now you have two sources of questions and you've fragmented your
userbase (see the first paragraph of "Supporting Infrastructure").
If you are a virtual attendee, spending a week looking at your phone would
probably be torture. More so when there's almost certainly a big screen
somewhere around that you could be using instead. So we need a website too.
Could AppBook and this website be merged together? I don't want to say "no",
but I will however say "well... errmmm..." while making face gestures. See,
the website and AppBook have different audiences and different use cases, to
the point that unifying them might just be impossible:
- AppBook: lightning fast.
- Website: regular website speed.
- Data source:
- AppBook: offline first.
- Website: online first.
- AppBook: designed for your mobile phone.
- Website: designed for your laptop and/or desktop computer.
- AppBook: one window at the time. Interaction is everything. You may need
to go native, but maybe a web app would do.
- Website: multiple windows at the time. Most interaction issues can be
solved opening a second tab.
- What would you use it for:
- AppBook: figure out what's going on and/or where to go.
- Website: stream live events, read papers.
Posters are tricky. The current best solution I've seen
is Gather.Town, but now you are depending on an
external platform. I imagine you could get rid of poster sessions altogether
with a combination of pre-recorded videos and chat, which is coincidentally
what the ACL Conference offers every other year. Then again, they also offer
Gather.Town, so it's hard to say which one is better.
Organizing a conference is a lot of work, but luckily we've done it for long
enough that there isn't much new that I could say. I should however point out
some details to keep in mind:
- All talks should be live-streamed and questions should be accepted both
in-person and via chat.
- Every room needs the proper equipment for remote presenters. That means
being prepared for presenters joining via teleconference and, conversely,
having a mic at hand for attendees to pose their questions.
In my ideal conference platform, there is exactly one source of truth and
one way to get information. There are no two schedules needing coordination,
nor two chat platforms, nor two video platforms. There is one way and one
In other words, the infrastructure would be built as such:
- A central "source of truth" database with all information about the
conference. You change it there and it is reflected everywhere (which in
the case of AppBook means "eventually").
- A file hosting platform with every paper and poster.
- Some kind of video platform for live-streaming events.
- The website, which is your main portal to all those things above.
- AppBook, which presents a subset of the above information but in an
- A chat app: bundling this inside AppBook would probably be a bad idea, and
a dedicated app may be better. AppBook could query the chat backend once in
a while, but only as long as it doesn't make the app slower in any way.
Bundling it with the website, on the other hand, would make perfect sense.
And failing that, an "open in app" link should also work fine.
Should AppBook allow you to synchronize your reminders with the website (and
vice-versa) to get notifications across devices? I get the feeling that "yes"
would be the best solution (and again, as long as it doesn't make AppBook any
slower), but this would significantly impact the complexity of the whole
operation. So this remains an open question.
I don't know of any platform offering all of this at once. Most platforms I know
offer one feature or the other with varying degrees of success but I haven't yet
seen a good implementation of AppBook.
And please, I beg you: few things are as annoying as an app that abuses its
dominant position. If you use my login information for crawling my LinkedIn
information and "connect me" to other people in my (wrongly scraped!) company,
I may not have a recourse right there and then (there's rarely an alternative
conference app) but I will make it my goal to ensure that no one uses your
I am currently considering whether to run a 10k and decided to take a look at
the available training plans. This being the internet I found a whole lot of
reasonably good training calendars but, this being the internet, they are all
detailing the distances in
freedom units miles.
Seeing as I now spent an unreasonably long time translating one of those
calendars, I have decided to put it here simply because I can. The original
plan with much more detailed information can be found in
||4.0k (race pace)
||30 min EZ
||4.8k (race pace)
||35-40 min EZ
||5.6k (race pace)
||35-40 min EZ
||5.6k (race pace)
||40-45 min EZ
||4.8k (race pace)
||40-45 min EZ
||5.6k (race pace)
||40-45 min EZ
||4.8k (race pace)
||40-45 min EZ
||CT or Rest
||4.8k (race pace)
- CT: Cross training. Swimming, biking, strength training, or even rest if
you're feeling down. Anything but running.
- EZ: Easy, comfortable pace. Walking is fine. Cross training is fine too.
- Race pace: you are free to run at a comfortable pace the rest of the week,
but on those days you should stick to your intended race speed (roughly
10km/h for the average runner).
As someone who's constantly fidgeting, I tend to play some Solitaire during
online meetings. Note that I didn't say "boring online meetings" because, let's
be honest, the meeting can be the most interesting thing ever and yet I still
need something to keep my hands busy.
In Linux I use Aisleriot, and I'm
really happy with it. The only (frankly, very minor) point I have to object
is that I don't like the default card look. This being Linux, this is an issue
that can be solved with a single click or two: Click in
View, go to
Card Style, and then choose a different style. And since I also installed
gnome-cards-data, I have 30+ card styles to choose from.
One of those card styles is called "Slavic Costumes", a set based on
this beautiful card deck from
1911 that was
added to Gnome
on May 1, 2022 and removed on August 16, 2022 for being on shaky ground
regarding copyright. Lucky for me the change has not made it into
Devuan yet, and therefore I get to use it without
having to go to this commit and downloading the file myself.
But the problem (well, "problem") is that I'm not familiar with Cyrillic, and
having cards with "В, Д, К, Т" instead of "J, Q, K, A" is breaking my brain.
So I changed the design using a couple commands and Inkscape:
- Find the source deck file, which in my case is stored in the
- Copy the card file
slavic_costumes.svgz to another directory and
rename it to
slavic_costumes_2.svg.gz. This is because, while Inkscape
can open .svgz files without any issues, I want to edit the file as
plain text in step 5.
- Decompress the file with gzip:
gzip -d slavic_costumes_2.svg.gz.
- Edit the file with Inkscape. This is detailed a couple paragraphs down.
- Edit the file with a text editor and change the
property to match the new file name. I'm not sure whether this step is
- Re-compress and re-rename the file:
gzip slavic_costumes_2.svg and
mv slavic_costumes_2.svg.gz slavic_costumes_2.svgz
- Moved the new file to the directory
As for the edition with Inkscape, you need to do the following:
- Select the card you want to edit and double-click on the element you want
to change - in my case, that would be (say) the letter "Д" of one of the
cards. In modern Inkscape this will allow you to edit a group of objects
(which all cards are) without destroying the group itself.
- Work on the card until it looks fine. In my case this meant replacing the
two card letters with a boring "Q".
- Click on another card, then right-click back on your original card and
select "Object properties". Make sure that the "ID" and "Label" properties
of the finished card have retained their original readable name, which is
club_queen. Otherwise your card set may not work.
- Repeat for all cards until you are happy.
And with that I have tweaked my own card set. I didn't find these steps detailed
anywhere, so I thought it would be a good topic for a blog post. I can't promise
that I'll look around for different deck designs to contribute
(Heraclio Fournier, anyone?),
but if you want to do it for your own entertainment, well, now you know how.