radus

UniProt is not niche. It contains curated information about all proteins across numerous domains.

Edit: Also, to comment more on my own experience, I was lucky to be working in a well-established lab with a PI whose name carried a lot of weight and who had a lot of experience getting papers through the review process. We also had the resources to address requests that might've been too much for a less well-funded lab. I'm aware that this colours my views and didn't mean to suggest that peer review, or the publication process, are perfect. The main reason I wanted to provide my perspective is that I feel that on HN there's often an undercurrent of criticism that is levied against the state of scientific research that isn't entirely fair in ways that may not be obvious to readers that haven't experienced it first-hand.

- question whether or not the conclusions you are making are supported by the data you are presenting

- ask for additional experiments

- evaluate whether or not your research is sufficiently novel and properly contextualized

- spotting obvious red flags - you seem to discount this, but it's quite valuable

In my experience, the process of peer review has been onerous, sometimes taking years of work and many experiments, and has by and large led to a better end-product. There are not so great aspects of peer review, but it's definitely not a joke as you characterize it.

I'll add that in biology and adjacent fields, it makes no sense to discount peer review because the reviewers do not repeat your experiment - doing so is simply not practical, and you don't have to stretch your imagination very far to understand why.

  sed 's/doctor/programmer/g'

I described my workflow in a different comment on this post, and this seems like something I could port to with minimal changes in code since every step is already a Python function and even decorated by @task.

To answer your broader question about the general need for some structured pipeline or workflow orchestration.. That comes down to volume of data (we do screens as well as one-off studies) and a desire to reduce human involvement as much as possible. So the goal is to have raw files be immediately picked up, processed, and loaded into on internal application where it can be queried and interesting data can be highlighted. During my PhD, this was also a goal of mine (and I have at least two github repos where I got close) but it was definitely less of a priority since actually doing experiments and downstream analysis was the limiting factor.

PS: if you want to talk off-HN, I should be your latest stargazer

At work, I develop a proteomics pipeline that is composed of huey¹ tasks (Python library; simple alternative to Celery) which either use subprocess to call out to some external tool, or are just pure python. It runs in a worker container which is managed by Docker swarm, and all containers pull jobs from redis. For our scale, it works great. However, I don't have control over the resource utilization of individual steps, and in the past I've had issues with the pipeline blocking as a result of how I was chaining tasks together. I think something like Nextflow would remove these limitations, but one thing I think I would miss is the ability to debug individual pipeline steps locally with an interactive debugger. As far as I can tell, Nextflow has logging/tracing facilities but nothing quite like an interactive debugger. I'd be happy to be told I'm wrong, or even that I'm doing it wrong.

Other reasons I'd like to start using Nextflow:

- my homebrew pipeline would be easier to setup/share

- there are some efforts in the proteomics community to develop Nextflow pipelines (eg. QuantMS²). I think it would to have a shared language to express pipelines, and it would make benchmarking simpler.

___

¹ https://github.com/coleifer/huey/

² https://docs.quantms.org/en/latest/

In short: The "stories" here are frontend components that are being rendered in isolation, with the ability to play with their params. It's also a nice way to document custom components in a project (this would be the "book" I guess). Storybook¹ is the mature project in this area.

As for Vite it's an alternative to Webpack which has gained rapid popularity - I've enjoyed using for its relatively light configuration and very fast live reloading support.

⸺

¹https://storybook.js.org/ (much better landing page)

I realize that in your scenario we're talking about millions of people no longer paying utility bills, but surely that could not and would not happen overnight, and I cannot imagine that these companies could not find some wiggle room in their billion dollar profit margins to adapt to a change that might for once lower monthly bills.

I am extra circumspect when driving around Teslas as a result of this seemingly common and extremely disconcerting flaw.