Skip to content

Latest commit

 

History

History
212 lines (150 loc) · 10.5 KB

202012W5.md

File metadata and controls

212 lines (150 loc) · 10.5 KB
Raw

@Author : Lewis Tian ([email protected])

@Link : github.com/taseikyo

@Range : 2020-12-27 - 2021-01-02

Weekly #9

readme | previous | next

总字数：3083 个（汉字：1984，英文单词：401，数字：57，中文标点：244，英文标点：397），阅读时长约：6 分 8 秒。

*Photo by Florian Glawogger on Unsplash

Table of Contents

  • algorithm
    • 替换空格
  • review
    • 保护你的 .env 文件（英文）
  • tip
    • Linux 下防止文件被删（中文）
    • 用 pandoc 制作带弹出式注释的 EPUB 和 MOBI 电子书（中文）
    • 在 GitHub 风格的 Markdown 中添加脚注（StackOverflow）
  • share
    • 选择合适的尺度（英文）

algorithm ⬆

1. 替换空格

很简单的一题，就是将一个字符串中的每个空格替换成 "%20"，用 Python 的话直接一行 replace 解决。

查了下 go 也有 strings.Replace 函数，其函数为：func Replace(s, old, new string, n int) string，功能是返回将 s 中前 n 个 old 子串都替换为 new 的新字符串，如果 n<0 会替换所有 old 子串。所以差不多就是 return strings.Replace(s, " ", "%20", -1); 就 OK 了？

试了下果然成功了，辣鸡牛客包还得自己导。

import "strings"

func ReplaceSpace(s string) string {
	return strings.Replace(s, " ", "%20", -1);
}

常规解法也不难，边遍历边填空就行。

我发现用 C++ 来做的话给出的函数为 void replaceSpace(char *str,int length);，意思是在原字符串上修改，那么需要两次遍历，第一次确定新字符串长度（空格数），第二遍需要从后往前填空，其中还有边界条件，如给出的字符串能否容下新字符串等等。

果然 C++ 刷题还是稍显麻烦，不过能锻炼自己的思维，因为需要考虑很多边界条件，毕竟没有那么方便的库给你调。

review ⬆

1. 保护你的 .env 文件（英文）

作者上线了一个小网站，10 个小时内就收到了许多可疑请求：

  • /config/getuser?index=0
  • /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
  • /api/jsonws/invoke
  • /solr/admin/info/system?wt=json
  • /index.php?s=/Index/\x5Cthink\x5Capp/invokefunction &function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21
  • /console/
  • /wp-content/plugins/wp-file-manager/readme.txt
  • /Autodiscover/Autodiscover.xml
  • /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
  • /.env

最后一个请求尝试读取环境变量 .env 文件，.env 文件通常包含密码、密钥等敏感信息，所以作者提醒保护好该文件。

关键作者并不是一个名人（I'm a nobody on the internet），这样都收到了很多机器人请求（或者说是攻击也不为过），想象一下知名网站得收到多少奇奇怪怪的请求，网络安全确实是一个值得注意的大问题。

tip ⬆

1. Linux 下防止文件被删（中文）

有时我们的一些重要的文件或目录，不希望被误删除或者修改，我们可以对其加上特殊的属性使其不可修改。

如果在 root 权限下，删除文件也被提示无权限 “Operation not permitted”，那么你可以查看一下文件是否被设置为不可修改的属性。

chattr（Change Attribute 的缩写）命令就是 Linux 改变文件属性的命令。对应地，lsattr 命令可以列出文件的属性。

taseikyo@ubuntu ~> touch a.txt
taseikyo@ubuntu ~> sudo chattr +i a.txt
taseikyo@ubuntu ~> rm -rf a.txt
rm: cannot remove 'a.txt': Operation not permitted
taseikyo@ubuntu ~> sudo rm -rf a.txt
rm: cannot remove 'a.txt': Operation not permitted
taseikyo@ubuntu ~> lsattr a.txt
----i---------e--- a.txt
# 可以看到这里有一个 i 属性
taseikyo@ubuntu ~> sudo chattr -i a.txt
taseikyo@ubuntu ~> lsattr a.txt
--------------e---- a.txt
taseikyo@ubuntu ~> rm -rf a.txt

chattr 提供不同的属性，也就是 aAcCdDeijsStTu，每个字符代表一个特定文件属性，具体如下：

  • a：只能向文件中添加数据
  • A：不更新文件或目录的最后访问时间
  • c：将文件或目录压缩后存放
  • C：不适用写入时复制机制（CoW）
  • d：设定文件不能成为 dump 程序的备份目标
  • D：同步目录更新
  • e：extend 格式存储
  • i：文件或目录不可改变
  • j：设定此参数使得当通过 mount 参数：data=ordered 或者 data=writeback 挂载的文件系统，文件在写入时会先被记录在日志中
  • P：project 层次结构
  • s：安全删除文件或目录
  • S：即时更新文件或目录
  • t：不进行尾部合并
  • T：顶层目录层次结构
  • u：不可删除

2. 用 pandoc 制作带弹出式注释的 EPUB 和 MOBI 电子书（中文）

寒假的时候（二月份）基本看完了《史记》，后面本来想着看《世说新语》，结果下载的电子书格式没有前面《史记》那么友好（没记错的话《世纪》好像是一段一翻译，还有注释，《世说新语》是一篇一翻译，好多年不学文言文，有些字、词可能还有印象，但是大部分谁还记得），于是放弃了。

偶然看到这个感觉还不错，主要是用到了 a 标签，因为实际上 epub 就是 html 页面打包成的 zip 压缩包，然后加了一些格式，下面为主要过程：

  1. 利用 Markdown 源文件生成原始的 EPUB 文件

shiji.md

# 十二本纪 五帝本纪第一
bla bla bla
# 十二本纪 夏本纪第二
bla bla bla

title.txt

---
title: 史记注译
author: 司马迁
language: zh-CN
...
pandoc shiji.md title.txt -o shiji.epub

这样就生成了带有目录的 EPUB 文件。EPUB 文件实质上是一个 zip 的压缩包，可以利用 unzip 命令来解压。解压之后，我们可以看到，使用pandoc生成的 EPUB 文件每一章实际都是一个 XHTML 文件。

  1. 制作弹出式注释
用户可以通过单击文内脚注的图标，弹出显示脚注内容的窗口。文内注可以支持复杂的内容描述，
比如多段落，带有样式的文本等等，具体描述如下：
在需要插入注的位置插入如下代码：
<a class="duokan-footnote"href="#df-1"><img src="../Images/note.png"/></a>
在文章的末尾插入如下代码：
<ol class="duokan-footnote-content">
   <li class="duokan-footnote-item"id="df-1"><p>这是一个注释文本。</p></li>
</ol>
注和内容之间使用id链接，通过这样的扩展方式，可以将整个章节的所有文内注内容集中在一个有序列表中，
这部分内容不会直接在页面上渲染出来，而是通过应用层的交互来呈现。

对于 Kindle，我没有直接去看规范，而是参考现有的带弹出式的 MOBI 文件，利用 Calibre 转为 EPUB 文件之后参考其组织方式总结的。一个示例如下所示：

悲夫士生之不辰<a id="fnref1" href="#fn1"><span><sup>[1]</sup></span></a>，愧顾影而独存。
<p><span><a id="fn1" href="#fnref1"><span>[1]</span></a>生之不辰：出生没遇到好时辰。
一般以此表示所生之世未遇明主贤君或未逢盛世，
所谓“士不遇”主要就是这个含意。语出《诗经·大雅·桑柔》。</span></p>

利用搜索替换操作，将相应的注和内容修正之后，把所有的文件压缩为一个 zip 压缩文件，在把压缩文件的文件名后缀改为 shiji.epub 即可。对于 Kindle 原生系统，由于不支持 EPUB，还需要我们利用 Calibre 将 EPUB 文件转化为 MOBI 文件。

作者还用此方法制作了一本 带注释的《史记》 详情可以去 GitHub 主页查看。

3. 在 GitHub 风格的 Markdown 中添加脚注（StackOverflow）

之前记得蛤蛤分享过，当时没做记录，去群里搜记录没找到，今天又找一次，果然啊，好记性不如烂笔头，多做笔记总是好的。

正文，引用脚注：
Bla bla <sup id="a1">[1](#f1)</sup>

脚注，并且能返回正文的引用处
<b id="f1">1</b> Footnote content here. [↩](#a1)

share ⬆

1. 选择合适的尺度（英文）

everything should be done in small easy to understand units, which can easily be combined to form larger more complex systems.

从我们学编程语言以来，老师都会教我们模块化，将一个功能切分成若干个相互独立的单元，既可以重用代码，也便于代码调试。很多概念也是如此：函数、包、微内核以及目前比较流行的微服务。

另外做内核的也知道，虽然有很多关于微内核系统的研究，但是通用的微内核系统却很少，我们可以看到几乎主流的内核基本都是单一的（Monolithic），如 Linux、 FreeBSD、 OpenBSD，或者混合的，如 macOS、 Windows。

将所有内容分割成小包是一件非常痛苦的事情，管理依赖是一个难题。这一点我深有体会，曾经自己手动在 Ubuntu 环境下安装软件，然后一堆依赖包，然后依赖包还有依赖包，就各种套娃，由于 apt 这种包管理器帮你依赖管理，所以不需要亲自体验了。

其实我看到这篇博客的时候，我首先想到的并不是关于计算机领域的尺度（原标题为 On being the right size，彩云小译翻译为 关于正确的尺寸，我改了一下，然后将其作为了本周的 Share 主题），我首先想到的是那句 近之则不逊，远之则怨，也即关于做人的尺度。这是一个值得深挖的话题，可以聊很多，每个人都有自己的看法和标准（尺度的把握），作为群居动物，我觉得这个东西还是有高下之分的，有人就很会 social，跟周围人关系都很好，有些人就不行（比如我），这其实也可以引出另一个词：情商。

如何选择一个合适的尺度？如何去衡量这个合适？我也不知道，毕竟我只是个社恐罢了。

;3

readme | previous | next