On 2024, I went to fosdem for the first time.
This post and next post will be an objective recount (or as much as possible), of the sessions I visited, and my take aways from each of the sessions. I also intend to make a "after thought" post, discussing the meta issues.
Entries are arranged in chronological order.
Open Research: Bridging Research and Open Source: the genesis of Gephi Lite #
I had initially hoped this session would discuss or push for open standards for plotting/graphing. I was disappointed to find that this was more for porting graphing functionality of Gephi (desktop application) to the web.
Javascript: Your web app is taking up too much RAM. Let's fix it! #
I had moderate expectation to learn something from this session, to learn something new about profiling web applications. It did not disappoint.
I was already aware of the memory profiler in chrome dev tool, which allow snapshot of heap to be captured and profiled. I was not aware that the memory profiler can be used to profile on a temporal axis (i.e., start recording, do action, stop recording, see all calls to allocate memory).
I also learnt about facebook/memlab and clinicjs. They may be for nodejs applications only, but since chrome devtool allow exporting of the profile result, they can potentially be used to visualize and debug frontend.
Javascript: Recycle, Reuse, Rebuild: Transformative Tactics for Turning your Brownfields Green #
Frankly, I stayed because I wanted to see the next session. I had zero expectation.
Convert strongly coupled to loosely coupled. But otherwise, I ... don't know if I learnt anything else?
Javascript: Unraveling JavaScript's Heart: Mastering the Event Loop for Peak Performance #
I thought I had learnt a lot from Jake Archibald's talk on event loop, and was curious as to what else I can learn. I was pleasant surprised to find that, there is always more to learn.
The talk focused mainly on async operations (e.g. Promise, async-await, callback), and how they could still block the main thread, if you are not careful. Since I exclusively used async ops for io-bound task (file read/write, network, etc), I was ready to believe that async tasks would not block the main thread. The speaker used bcrypt to illustrate that CPU bound tasks, even if they are delegated to async operation, could still block the main thread.
Takeaway: For CPU-bound tasks, use workers.
(extra: I wonder how/if this also affects EventLoop implementation in python)
Open Research: The French Open Science Monitor: steering the science based on open bibliographic databases #
I wanted to join the next session, and I had some time to kill, so I decided to join this session, too. I did not expect to learn anything. But of course, there is always something to be learnt.
- https://unpaywall.org
- Grobid github rtd: use ML (?) to generate metadata from PDF
- https://open.coki.ac Curtin Open Knowledge Initiative
- https://openalex.org/
- https://hal.science/
Open Research: Infra Finder: Increasing visibility of open technologies for open science #
I guess a similar initiative to https://helmholtz.software/, but for infrastructure? I am not sure. There was nothing I could test etc.
One of the takeaways from this talk, is that, people who makes the decision regarding infrastructure has different concern/technical know how. It might be necessary to have a different set of criteria when speak to such steakholders
Open Research: Best practices for research in open source ecosystems #
Open Research: PHAIDRA - A Repository Where Research Data Goes to Live (Not to Die). #
I have some interest in RDM. We learnt a little about the history of PHAIDRA, but little to no technical detail. The presenter also mentioned that large data (multi GB/TB) is not currently covered.
Open Research: Updating open data standards #
The main reason why I was in open research dev room to begin with. I wanted to learn about open data standards. This talk gave me some idea on in jobby job.
- Previous: k8s secret shinanigans
- Next: FOSDEM2024 day 2