https://github.com/wangchucheng/hugo-eureka/pull/38
https://github.com/wangchucheng/hugo-eureka/discussions/50#discussioncomment-498640
搜到原repo的几个相关讨论,看起来是这个主题的CSS并没有按套路出牌,改动起来有点麻烦。
最容易的方法应该是按第一个链接里的去head-custom.html里改了,值得试试。
https://github.com/wangchucheng/hugo-eureka/pull/38
https://github.com/wangchucheng/hugo-eureka/discussions/50#discussioncomment-498640
搜到原repo的几个相关讨论,看起来是这个主题的CSS并没有按套路出牌,改动起来有点麻烦。
最容易的方法应该是按第一个链接里的去head-custom.html里改了,值得试试。
如 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 作底层支持。
2)在 *.md文件里用什么syntax?
用 GitHub Flavored Markdown 的语法。
1)下载的图片要放在哪个文件夹?有讲究吗?
放到 static
文件夹或者用图床,参看:Including image using blogdown · Issue #45 · rstudio/blogdown
来个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 个人愚见:
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
使用 Forms 接收数据 再利用 Functions 触发一次 build 即可
https://www.netlify.com/blog/2018/09/14/forms-and-functions/
感觉这里面涉及的身份太多了:工作的话,发足够的钱就好,哪家公司没有斗争。语言的话,最好跳出具体的条条框框,站在更高的维度去看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。实在让我费解。