buchanae

> I think we all can agree that these lines are repetitive and even error-prone to some degree.

I don't agree. I'll take if-statements over a validation library 99% of the time.

This is how we validation a message coming into our REST+JSON API: https://github.com/ohsu-comp-bio/funnel/blob/master/tes/vali...

Here's one I find tricky: https://bioconductor.org/packages/release/bioc/html/viper.ht...

That's the tool, and that page cites the paper.

> I don't think you should cast aspersions of laziness

You're right. I use laziness out of frustration, but in reality I know it's hard for me to make my own work fully documented and reproducible.

A large part of the situation is cultural. Software engineers are born into a world of version control, unit tests, documentation, managing complexity, reproducibility, debugability, etc (and we still struggle with it). That sort of culture and associated tools are missing from data science.

I don't think I could write an editor with regular expressions from scratch in a week. Especially if you took away the internet and 99% of my CPU and RAM. Fail.

And another thing! Why should a project be done when it gets published?! What kind of software project would make one release and call it good forever? Nonsense.

I have been working on reproducing computational biology papers from the cancer field lately. I am very frustrated. When the inputs and outputs are machine-readable data, there's no excuse for not making your work reproducible, in my opinion. Often the problem is plain laziness and disorganization.

One major problem is that there's not much real incentive to make your work reproducible. Money granting organizations favor researchers breaking new and exciting ground, not those rehashing an already published method. Publishers don't require reproducible methods, and reviewers don't have the time, desire, nor expertise to do an in-depth methods review.

Wet lab experiments are 1-2 orders of magnitude more expensive and difficult to reproduce, that's true, but we're not even getting the basics right!

> although pointless and impractical

I disagree. Consider computational biology papers – you should be able to show me code that takes the raw data and turns it into your results. Peer review is a sort of global, public code review in this case. There is a lot of value (education, validation, propagation, sharing, etc), and it's completely practical. Sadly, we (as a field) are nowhere near that, IMO.

I love how often phrases start with "yeah..."

I'm the same way! I have to train myself not to think when people give a casual "hey, how are you?".

The book "Quiet: The Power of Introverts" has an interesting message about how introverts struggle to fit into an image of society where one must be a quick-witted extrovert in order to be successful and powerful. I think it's the same for fast vs slow thinkers. It's important to know your a slow thinker, and accept it as a strength.

I made an offline version by opening it in Firefox and printing to PDF. Seems to look fine.

I think my render in Chrome is pretty broken. Here's a screenshot of the top of the page: https://drive.google.com/open?id=1YVtcV-J0JrDyW2pJ6vwgEDsgjO...

Oh, I actually didn't realize how much of the page I was missing until I opened this in Firefox. My page is very broken in Chrome 67.0

Wow. It's so hard to find expert-level documentation like this all in one page these days. I'm usually stuck piecing together information from a couple dozen (often poorly presented) websites. The topic is fantastic, but the presentation deserves some applause too!

I remember being giddy about the potential of Ubiquity to bring the CLI to a wider audience, and bring more power to existing CLI users. Too bad it never played out.

https://wiki.mozilla.org/Labs/Ubiquity

That's not nice, nor helpful. I did read the article, a couple times actually.

Care to paste the line which give a list of specific cars?

Which cars use Chinese 5G modems?

Yes! That's a good one.

I'd also say, probably minimize the use of javascript and dynamic content.

Amen!

And this article doesn't even touch on the bullshit content – I don't want 10 websites that all say generally the same thing with different layouts (and 10 times more total bullshit consumed). I can't stand the internet today. The experience on mobile is even more unbearable.

I want simplicity.

Can we all just band together right here and now and create a subnet with a better set of principles?

- minimize page weight - minimize duplicate content - minimize UI variation - what else?

My entire life, I've seen ad campaigns (TV, radio, web, etc) from American politicians; ads which are projected to a wide audience, and which are neither shy nor subtle about bashing their opponents.

I'm curious, how would others describe the line between acceptable influence (American political ads) and unacceptable influence (Russian political ads).

To be clear, I'm not saying there is no line, I'm just curious to read peoples' description of the difference.

I wrote github-release-notes to help me stop being lazy about releases. It generates a log based on github PRs. It's not a perfect solution, but it's a place to start, and helps track down the work done and the comments made so I can start writing better notes. A lot of times, the first comment of a PR is a great source of information about a change made (what, why, caveats, etc).

[1] https://github.com/buchanae/github-release-notes

> NIH highlights situations where engineers side with reinventing the wheel due to a belief that building technology in-house will be better, quicker and cheaper than using an existing solution

In my experience, it's more like "due to an uncontrollable urge that building technology in-house will be more fun, more interesting, more pleasing than using an existing solution" :)

...not that I'm completely innocent in this respect.

Could you write the core in Go, compile cross-platform, bundle the core binary, and then remove the reliance on the host's Python?

> Eventually I’ll write a post about the wrong, but for now, the right: in some sense, WebAssembly is a different way of accomplishing what the JVM set out to do

I agree, it's exciting, but this is half (or less than) an article. These hyped-up technologies make me grumpy neck beard.

> The calls for research to be transparent and reproducible have never been louder. But today's tools for reproducible research can be intimidating - especially if you're not a coder.

As someone (a software engineer) who has been trying (struggling) to reproduce biology research lately, I say amen. Hallelujah.

But. It's time to accept coding as a core skill. Science has more to learn from software engineering than it realizes. Software engineering (aka coding) eats reproducibility for breakfast, even when hundreds or thousands of "collaborators" are involved. These days, it's rare for a single biology researcher to produce (publish) code that is easily reproducible by an external researcher.

I have (and have had for many years) the same trouble. I can't tell you what to do, but I can tell you what I think I've learned (so far):

1. I am incredibly curious, by nature. I want to learn everything. I accept that it is NOT possible to learn everything I want to.

2. I can be more disciplined. I can say no to projects. I can't be good at everything. Saying no can be (surprisingly) fulfilling. I can be more dedicated than comes naturally, but it takes extra willpower. The payoff is worth it.

3. Projects involving other people are more fun, and therefore more successful and more engrossing.

4. What I really want is to accomplish something meaningful.

5. There are patterns in my projects, in my interests. They feed on each other.

6. It's ok to treat a project as a learning experience, and then move on.

7. A project that I'm serious about will take at least 5 years.

Great article, ruined by Gizmodo's disrespect for its readers by including animated junk on the page.