I occasionally update my web log, however updates are rare because writing ends up taking a lot of time. You have to identify an interesting topic, research it to fill the gaps needed to describe it, create a writeup with associated figures/pictures, edit it, and then commit to publishing it. Yes, it's entirely possible to create lower effort content, but it's substantially less satisfying to me.
Find a small project that you're interested in and check out the developmental discussion channels to see if there's any way you can lend a hand. Starting with trying to find complex coding tasks in large bureaucratic projects is setting yourself up for failure IMO.
For example, https://zynaddsubfx.sourceforge.io/contribute.html shows a few different levels of involvement in one project I maintain. That's not me saying you should work on this project specifically though; you'll want to find projects that you're enthusiastic to learn about.
Usually it takes a few days for the thread to completely populate, so unless you're looking at the rate that it fills up I think it's too early to decide.
No, I would not work on any personal projects during work hours as I don't want to risk any IP clauses getting applied to my own personal/side projects. Generally down time is a good opportunity to learn more about tools which could be applied in the future, but are not immediately required.
You're not (likely) going to be working casually on VLSI design, but for basic circuitry and embedded design you can work on hobby projects. I wouldn't compare that to having a fulltime job working on complex systems where you're going to be exposed to more elaborate challenges, but you can at least avoid letting hardware skills atrophy over time by using them for comparatively simple tasks.
If you want to have ragged starting information displaying pricing information for the various symbols in the range they're defined, I'd assume it's much more common that there's different start dates, but they're all defined for today. So, you could have a single checkbox to normalize based upon equal value at today's value and I'd default to having that on. As your baguette argument about the absolute values not having huge significance still applies it seems like it would work with no other modifications (i.e. it doesn't matter that it could require fractional shares and the like).
If the goal is to demonstrate relative performance over time, wouldn't it be useful to use a normalization such that all lines either start at the same point (e.g. simulating investing X amount) or ending at the same point (showing requirement to get to X final amount)?
Taking a quick look at the source it doesn't look too bad all things considered. First off, assume that there's going to be some sort of 32bit->64bit issues (likely casting pointers into 32bit words). So, start off on a 32bit setup, get things to cleanly build on -std=gnu99 (no need to cause yourself extra pain if it's optional). Then tidy things up with warnings (-Wall -Wextra on clang&gcc) such that the compiler can help you spot any existing bugs. Next up is the transition to 64bit. You're likely going to have to spot any pointer manipulation and where possible change 'int', 'long', etc into types which specify their length to make reading the code easier (subjective, but that's my opinion) e.g. uint32_t, uint64_t, etc. Then you ought to be pretty close to having all system tests pass on 32bit and the 64bit port.
I'd be worried if the code was old enough you were seeing K&R C notation or if it was a huge codebase, but it doesn't look like either case has occurred.
Of course if you're very much not a C programmer, learn some C. It's a comparatively small language overall (IMO) even if it's a low level one. Newer versions of the K&R book should get you up to speed pretty quick.
Certainly not as much as I used to, but yes I contribute to open source projects. It's a combination of making things I'm interested in, drive by patches for tools that almost do what I want or have a bug that I've managed to trigger, and chatting with others building things they're interested in. Being a maintainer is a different ballgame than contributing to a project without the long term responsibility, though both can scratch an itch and help develop new skillsets while helping to create new pieces of software.
> his dataset is pretty worthless and the claims around it have been largely unsubstantiated.
The really sad part of it is that with fairly minor changes it could have been a landmark dataset IMO. Having better recording equipment, a lower noise floor environment for data collection (e.g. don't run fluorescent lights while recording), having precise timestamps integrated into the recording, better temporal separation between recording of various phrases, adding simultaneous EMG/EEG, etc would have resolved quite a few data related issues. It's a unique situation (for good reason), but bad data...
From seeing the data, I suspect the electrode placement was in a good enough location that novel things could have been done with a cleaner data source. I guess the major limiting factor is that absolutely no one would want to be involved with the project at that stage. What sort of IRB would approve any of this? Better data would answer some key questions that could generalize to lock-in patients (theoretically) and worst case it would provide a strong indicator that no significant BCI can be made for the task given the electrode placement.
My personal big disappointment was seeing objectively false claims being made at the society for neuroscience conference. It made it clear to me that the work was not being done in good faith.
Certainly a unique experiment, however behind the scenes things were let down by poor experimental procedures, minimal experiment designs, outrageously inaccurate data analysis, and poor recording equipment.