lennylin

  • 2023年5月15日
  • 注册于 2021年3月4日
  • chuxinyuan 所说,是为了一桶浆糊。RStudio、R Markdown 都带着 R 的胎记,哪怕它们也支持别的语言;就像若干年前 IPython 重新命名 Jupyter 一样,换汤不换药,主要还是为了去掉 Python 的胎记、便于宣传这是个缝合多种语言的大一统工具,但就算换了名字,这 Python 胎记也根深蒂固了(从多语言角度来说,窃以为 Jupyter 对 R 的支持力度是不如 R Markdown 对 Python 的支持力度的)。

    Quarto 的字面意思是四开本,取其印刷意。它主要基于 TypeScript 开发。如 yufree 所说,它是想一统科研用户江湖的,基本上会囊括所有 R Markdown 的功能(报告、幻灯片、网站、论文、书籍等);blogdown 可能是唯一的例外,不会被重新发明,因为用 TypeScript 重写 Hugo 不值当,但 Quarto 会有类似 distill 的网站功能。

    美工方面也是花了大力气的。比如幻灯片选了 reveal.js 作为底层框架,但对默认主题做了很大的调整,让它不要那么花哨。网页格式的输出都是基于 Bootstrap 定制的。

    以 Q 开头只是个巧合。最早是 S 语言,然后是 R 语言,再往前进一个字母就是 Q 了。

    简单说来,就当是结合过去八年的经验全盘重写 R Markdown 吧,底层不变,仍然是 Pandoc 和 knitr(以支持 R),但也收入了 Jupyter(以支持 Python)以及 Observable 作底层支持。

    • 来个base版:

      dat <- expand.grid(year = 2015:2021, month = 1:5, day = 10:19)
      dat$value <- seq_len(nrow(dat))
      
      do.call(rbind, with(dat, by(
         dat[order(year, month, day), ],  interaction(year, month),
         function(i) with(i, c(year = year[1], month = month[1], value_mean = mean(tail(value, 5))))
      )))
      • barnett874 个人愚见:

        • 没有考虑跨年的情况,因此还需要增加 Year 变量,但是 Day 变量感觉没有必要。
        • 谨慎起见有必要对数据按照日期升序排列,然后按照 Year、Month分组。
        • 既然走 tidyverse 风格,可以考虑将do(tail(., 5))换成slice_tail(n = 5)
      • 一年份的数据做几张interactive自然会导致文档过大(数据是以字符串的形式插入到html页面中去了)。并且个人感觉那几张热图其实也没必要做成可交互式的,因为即使交互了也没有提供很多额外的便利和信息。

        看了下html的源码,发现只要把数值小数位缩短、日期时间只截取到小时即可减少一半以上文档的大小。

        • lovebluesky 以你这个情怀为主题,我想了四个多小时,初步计划给这书加个书签,手写题诗一首:

          一图千言十四载,人事代谢古成今。
          快意少年重展卷,江山胜迹复登临。

          ——献给曾经等待《现代统计图形》的少年

          但说实话我对我的一手字并没什么信心。冲着你们的情怀,我就献丑了。

          • Netlify 只能托管静态网站,所以用 Shiny 的方案首先就被排除。

            界面:flexdashboard
            绘图:echarts4r(推荐), plotly, ggplot2
            表格:DT、reactable等
            获取数据:如果需要爬取网页就 rvest,如果直接能访问地址获取csv或者json的话就不用了,直接拉数据即可
            自动化:使用GitHub Action编写流程,每日运行获取数据的脚本更新数据,然后重新渲染flexdashboard的Rmd文件,更新结果自动commit到仓库里,然后设定好GitHub仓库自动deploy到Netlify的流程就可以了。

            flexdashboard的示例:https://rpubs.com/rubenfbc/coronavirus

          • lennylin
            可以自己写个 css 啊。我一般点右键,查看一下页面的代码结构。然后针对适当的模块,自己写一段 css 放入到 head 块儿里就好了。

          • 话说年中的时候,看到“用 R 语言的 blogdown+hugo+netlify+github 建博客”,于是乎开始照着搭建个人博客。但是人在国内不能科学上网,netlify登不了,就中途搁置了。前几天无意中戳到一篇文章,才知道除了netlify还有很多别的方式。
            自建博客的萌新们加油,条条大路通罗马。

          • 感觉这里面涉及的身份太多了:工作的话,发足够的钱就好,哪家公司没有斗争。语言的话,最好跳出具体的条条框框,站在更高的维度去看R这门语言,没有不扯淡的语言。对99%的用户,base R里的内容就够用了。装X追潮流被牵鼻子真没啥好处,毕竟冷暖自知。

          • 我准备继续说点什么的时候,问题被关闭了。继续用我的blogdown,静观其变吧!一切遵循市场的游戏规则,当然主观和客观上我都绝对挺你@yihui,感谢你带给我们这么多姿多彩的娱乐工具。游戏,请继续……

          • 从用户角度看如果两个包应用场景一致或能覆盖自己需求,选择上只会感到糊涂,用户不会管技术层差异只会管能不能快速做个网站出来。R作为高级语言,用某个包就是实现某个功能,多数都不愿去理解底层依赖与调用关系,目的性很强,即使这两个包底层有差异,但如果实现结果甚至过程都差不多,就很容易造成用户分化。R这个用户基数,一个功能两个包都能实现且都持续更新,长时间累积差异很容易让看重稳定性与可重复性的用户一个都不用,然后转去另一种解决方案。

            举个有点类似的例子,最近尝试重新运行一些 tidyverse 的代码,结果发现很多函数生命周期都终结了,很多包功能相似但用法又不一样,我理解这属于技术框架限制需要重新定义一些东西,但我不认为那些拿到代码的人同样理解,他们只会说 “哎呀,有提醒,有红字,是不是错了?你这换来换去不靠谱”,所以我就把 tidyverse 代码全都转成 base 版的了,然后又踩了个 4.0 把因子变量默认不转换的坑,然后加急把之前所有的读入函数里都加了对 stringsAsFactors的控制。

            • tctcab 这事情连我都不是第一时间知道的,而是过了好些天了别人告诉我的,这让我感到很难堪。我最近在加紧改书稿,还没顾得上跟哈大神谈、弄清楚这到底是怎么一回事。我当时知道这个包的时候,感觉像是被友军从背后放了一枪。从包的描述来看,他就是做了一个 blogdown 的子集,他要的那些功能在 blogdown 框架下并不难实现(而且那个功能对比表格中的 blogdown 的欠缺功能也不准确),我非常不明白为什么他不先跟我谈一下。最让我感到不舒服的是他已经在社交媒体上提这个包了,而且是在别人抱怨 blogdown 的缺点之后跳出来说 hugodown 解决了这些问题。我一直认为哈神应该在社交媒体上更加谨慎发言,因为他几乎已经是大主教的地位了,他要是吼一嗓子说 blogdown 不行、hugodown 是新的希望,那大家都很容易信的。那接下来我该怎么办?扛起枪来跟 hugodown 拼功能吗?我感觉技术上这并不是什么难事,问题是对用户来说,为啥同一个公司出了两个竞争性产品、以及应该如何选择。他要是做其它静态网站生成器如 jekylldown 或 hexodown 我也就不说什么了,因为这些我早已承认 blogdown 的支持力度不够;偏偏他要挑 hugo。实在让我费解。