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.

The handbook

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 it.

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 (information retrieval).
• 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.

Chat

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").

Website

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:

• Speed:
  • AppBook: lightning fast.
  • Website: regular website speed.
• Data source:
  • AppBook: offline first.
  • Website: online first.
• Device:
  • AppBook: designed for your mobile phone.
  • Website: designed for your laptop and/or desktop computer.
• Interface:
  • 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.

Poster sessions

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.

In-person notes

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.

Supporting infrastructure

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 way only.

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 easy-to-query format.
• 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.

Conclusion

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 app again.

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 this website.

Legends:

• 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:

1. Find the source deck file, which in my case is stored in the directory /usr/share/aisleriot/cards/.
2. 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.
3. Decompress the file with gzip: gzip -d slavic_costumes_2.svg.gz.
4. Edit the file with Inkscape. This is detailed a couple paragraphs down.
5. Edit the file with a text editor and change the sodipodi:docname property to match the new file name. I'm not sure whether this step is required.
6. Re-compress and re-rename the file: gzip slavic_costumes_2.svg and then mv slavic_costumes_2.svg.gz slavic_costumes_2.svgz
7. Moved the new file to the directory ~/.local/share/aisleriot/cards/

As for the edition with Inkscape, you need to do the following:

1. 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.
2. Work on the card until it looks fine. In my case this meant replacing the two card letters with a boring "Q".
3. 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 something like club_queen. Otherwise your card set may not work.
4. 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.

I am constantly having issues with HDMI and I never really know what the actual issue is. A non exhaustive list of possible causes would include a broken cable, a screen that's on the wrong port, an unsupported resolution and/or refresh rate, a PC that's not sending a signal, a PC that's using a different port from the one where I plugged the cable, and a monitor that's asleep and didn't notice that it should wake up. Plugging the HDMI cable at the wrong time can also compound the problem, meaning that I need to boot my computer with the exact settings I need. Of course, all of this has to be done in a computer with a screen that, by definition, doesn't show anything.

You know what has gotten me out of this problem more than once? VGA. Whenever my modern computer fails to show a display I end up plugging a VGA cable into an HDMI adapter (sometimes there's also a second adapter to DisplayPort), a solution that just works.

This is the type of issue nobody notices until they really need it, namely, how to use a system where everything is broken. I'd cluster these issues next to an idea I've been bouncing around about software that you use under duress (looking at you, SAP) in my unified theory of "interacting with computers when you really don't want to".

Sometimes people will use your system/protocol/whatever in situations where they don't want to use it but have no other choice. Think of a work meeting where the other part is using a tool you hate (a.k.a. MS Teams) but you're powerless to change the decision process that led to this moment and all you can do is roll with it. In those situations, the best you can do as a developer is make it so easy for the user to accomplish their task that you don't test whatever little patience they still have - your long-time users may put up with your "What's new?" pop-ups, but your other users will be thankful if you spare them.

Here's my suggestion to you: make your software as robust as possible so it doesn't crash, ensure it degrades gracefully whenever it does, and make it so easy to use that even those who hate your product will have no reason to complain.

I am in the middle of updating my LinkedIn profile and I decided to have an AI write it for me. I fed my CV to LLaMa and prompted it to generate the following blurb (which I tweaked slightly to remove hallucinations):

Me: Hey, LLaMa, why should I hire this candidate?

LLaMa: This candidate has a research background, which is one of the qualities you desire in an applicant. He was able to publish his works and had a good performance in conferences too. His work experience is promising since he worked as an expert of Applied Mathematics which is relevant with your field of specialization.

Me: Why is this candidate great for my company?

LLaMa: The candidate will be able to use their experience in the NLP field, especially in building and training Machine Learning models. They are also highly experienced in programming languages and systems administration. With their volunteer work at the ACL Anthology they have been exposed to a lot of natural language generation, which is something we plan on moving into in our company.

This is the type of job that LLMs do well: when all the information they need to perform their task is right there in the prompt. But once you let them go on for a while, the facts start taking the backseat:

LLaMa: (...) There are some red flags in the interview that you didn't catch, but you were unable to follow up on. For example, the candidate said something about their past coworkers not liking them because of a few jokes that they wrote for an email joke club. The candidate claims to have learned from this experience and now knows how to use humor without being insensitive. (...) The candidate had experience in the military and was in charge of a large team of soldiers for several years.

Suffice to say, none of this is true: there was no interview, the joke incident never happened, and I was never in the military. On the plus side, made-up facts stated confidently are a goldmine for comedy, and LLaMa doesn't disappoint:

Me: Why is this candidate probably a serial killer?

LLaMa: The candidate's background in medical system development and image reconstruction indicates that the candidate has been trained to use CAT scans. This means that he or she could be capable of using it in order to scan your brain and read off all your thoughts at any moment, which is highly suspicious behavior for a job interview!

Rest assured that I am not a serial killer, I have not been trained to use CAT scans, and that I will not be reading your thoughts during the job interview. That would indeed be rude, as this behavior is clearly only appropriate from the third interview on.

And finally, in the interest of fairness, I asked LLaMa why you should not hire me. The result is not entirely inaccurate, as this post proves by itself:

Me: Why should I not hire this candidate?

LLaMa: The candidate is quite interested in Natural Language Processing. You will need to keep him away from the keyboard when he is talking about this topic, so you can work with the rest of your team and actually get something done.

I tried asking a different way, but looks like LLaMa has my back:

Me: Why is this candidate bad for my company?

LLaMa: The candidate seems to have a good experience (PhD, work and volunteer experience). What are some reasons why I would not hire someone with such qualifications?

I don't know, LLaMa, you tell me!