翻我自己的blog,发现在三年前就搞了Jekyll,后面也有几次断续提到. 既然总是涉及到还是好好学学了.
Jekyll基于ruby/markdown/Liquid. 官网在这儿

安装

  • Ruby官网下载安装ruby
  • 安装后, 包管理工具gem应该可以运行. 先替换gem源:
    $ gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/
    $ gem sources -l
    https://gems.ruby-china.com
    # 确保只有 gems.ruby-china.com
  • 敲入下面命令做jekyll入门安装:
    gem install bundler jekyll
    jekyll new my-awesome-site
    cd my-awesome-site
    bundle exec jekyll serve
  • jekyll serve命令将打开127.0.0.1:4000端口.不过这个端口很多程序都喜欢占用. 除了将占用程序杀掉, 还可以更换端口,如换到8080:
    jekyll serve -P 8080

    上面使用Jekyll的new命令建立了整套blog, 使用了一个默认的theme. 然而jekyll最本质应用是转换Markdown+Liquid到Html, 所以是几乎可以应用到任何静态html的编写的. 当然其强项还是写blog. 后面教程就说这个.

    标准项目结构

    .
    ├── _config.yml
    ├── _data #放yml数据文件, 可以在其他html/md中通过liquid语法引用其中的数据{% site.data.ymlfilename  %}
    │   └── members.yml
    ├── _drafts #未发布的posts,不会显示。
    │   ├── begin-with-the-crazy-ideas.md
    │   └── on-simplicity-in-technology.md
    ├── _includes # 放html、md文件, 其中的文件可以在layouts、posts的html和md文件中通过liquid include语法引用并插入{% include 文件名.后缀 %}
    │   ├── footer.html
    │   └── header.html
    ├── _layouts # 放html文件, 可以在posts和其他md/html文件中通过liquid语法设置 layout: xxfilename
    │   ├── default.html
    │   └── post.html
    ├── _posts # 放md文件. 文件名格式需要是下面这种. 内容可使用liquid语法.
    │   ├── 2007-10-29-why-every-programmer-should-play-nethack.md
    │   └── 2009-04-26-barcamp-boston-4-roundup.md
    ├── _sass # 放scss文件. 其中的样式在html中通过link引用, 注意文件目录编译后是/assets/css/, 后缀是编译后的.css <link rel="stylesheet" href="/assets/css/filename.css">
    │   ├── _base.scss
    │   └── _layout.scss
    ├── _site
    ├── .jekyll-metadata
    └── index.html # can also be an 'index.md' with valid front matter

    关于theme

    theme解压缩后,要运行一次bundle install, 然后运行服务bundle exec jekyll serve就可以了。

关于自定义数据

最好放在_data/somefile.yml中,而不是放在_config.yml中。因为前者不需要重启服务,而后者需要重启服务才生效。
如在_data\info.yml中:

root_path: \pd\

在md文件中可以用{{site.data.info.root_path}}引用。
在当前页面的前导部分定义的变量如var1,可以用{{page.var1}}访问。最妙的是,{{page.var1}}可以写在_includes里面如public.md,这样, {{page.var1}}就像本地定义的局部变量, 插入的{% include public.md %}中可以使用这些局部变量,就像是传递了实参一样. 而_data/中的数据就像是全局变量/常量一样.
jekyll可以尽可能的共用内容, 而不是像普通写文档一样大段的复制粘贴, 并且实时刷新,写起来非常有愉悦感.

Liquid

Liquid官方文档
表达式 {{ }}
语句 {% %}

逻辑运算

大多数和js一样,比较符号:

== != < > <= >= true false

逻辑运算不太一样,分别是andor

字符串运算

不是通过函数,而是通过语句:
包含:

{% if product.tags contains "Hello" %}
  This product has been tagged with "Hello".
{% endif %}

赋值

注意字符串用双引号

{% assign my_variable = false %}

{% assign my_variable = "foo" %}

{% capture my_variable %}I am being captured.{% endcapture %}

条件转向

{% if customer.name == "kevin" %}
  Hey Kevin!
{% elsif customer.name == "anonymous" %}
  Hey Anonymous!
{% else %}
  Hi Stranger!
{% endif %}


{% unless product.title == "Awesome Shoes" %}
  These shoes are not awesome.
{% endunless %}

{% assign handle = "cake" %}
{% case handle %}
  {% when "cake" %}
     This is a cake
  {% when "cookie" %}
     This is a cookie
  {% else %}
     This is not a cake nor a cookie
{% endcase %}

循环

{% for i in (1..5) %}
  {% if i == 4 %}
    {% break %}
  {% else %}
    {{ i }}
  {% endif %}
{% endfor %}

更复杂一些的,包括可以使用continue、limit、看官网对iteration的说明

import的天坑,先读读
我在stackoverflow上问了个问题,最终发现必须要在test目录和项目根目录放__init__.py,src里面可以不放。

包和模块(Package/module)

简单理解,模块就是.py文件,包就是模块所在的目录。
再python3.3之前,目录中还需要有__init__.py才能称之为包。在这其中定义模块。在3.3之后提出了隐式命名空间包的概念,可以不定义__init__.py

用法

连引号和目录斜杠都省了

导入下级目录之一的包

me.py中:
from sonFolderName import sonPackageFileName
在me.py的目录中运行python me.py

导入上级

from .. import parentPackge
需要在上上级的grandpaFolder按模块-m运行:
python -m parentFolder.myFolder.me
如果不按这种方式运行,会报错ImportError: attempted relative import with no known parent package

再看Jekyll的过程中,忽然发现简化简化再简化才是王道,也是程序员们孜孜不倦追求的王道。
先举两个远一点的例子。
第一个例子是文档编辑格式,在寻找什么才是更好的文档编辑格式的时候,就会发现有DITA(xml格式承载)、reStructText(.rst格式承载)、Markdown(.md格式承载)。上面三种都可以转成html,所以另外还可以再加上html本身。可以看到,在这篇老外写的对比里面,markdown确实是极受欢迎的。 markdown+jekyll也是其推荐首选之一。而DITA的复杂性令人望而却步。
第二个例子是宇宙第一js框架之争。候选是react和vue。vue无数人说其胜在简单。除了使用标准的html、css、js以外,没有引入更多的新语法。而react虽然很强大,但是它引入了jsx这个奇怪的产物。然后就开始在js里面写html……让我想起了在html写php……虽然react极其优秀,然而更多的人们仍然更喜欢更简单的vue。
再说到对文件内容的简化。能列出来好多例子了。
markdown其实就是对html的简化。考虑到markdown里面还可以加入html标签以达成更高的兼容性,就更让大家喜欢了。html长长的标签及其影响阅读体验,才有了markdown用武之地。当然,HTML更强大不是吗,但这无法阻止更简单的markdown对它应用范围的蚕食。
scss是对css的简化和强化。去掉了{}和分号,改用了缩进,加入了变量和语句。其实,像if、for这种语句就是为了怕麻烦。另外,看来相当多的程序员都不喜欢花括号和分号啊!scss前身sass并不流行,看来简化的时候保持兼容性还是很重要的。
python之所以能有这么大的占有率,可以说他也是去掉了C系语言(C/C++/Java/Javascript)里面的花括号和分号。去掉了变量类型。javascript虽然没有去掉花括号(不知道有没有改型语言去掉它的花括号的),但可以省略分号。当然花括号和分号有一大好处就是可以把代码压缩在一行里面,这个python就不行了。JavaScript开始甚至都没有class,所有都是object,并且给object一系列默认的隐藏的function,让其实现复杂的功能已经class的功能,而表现上及其简单。
yaml是json的简化。虽然其名称更像是html。当然,json是xml的简化,用花括号替代了冗长的标签。yaml又用缩进替代了花括号,用-替代了方括号。
简化之路无止尽!每一种简化虽然可能损失了很多功能,然而却带来了更多的使用者、更高的效率!这才是发展的方向,而不是做一个大而全晦涩难懂的东西。
大而全的东西必然走向晦涩难懂,因为它要考虑的太多了。比如excel使用率极低的vba,它要考虑自动化,那么必然vba有很高的学习门槛。另外csv是excel不太成功的简化。损失了太多,但也有其生存之地。

liquid
说实话这玩意儿长得有点像php和Vue用的mustache混合.

Objects

{{ page.title }}

tags

判断语句, 想起来vue的v-if之类. fuhe

{% if page.show_sidebar %}
  <div class="sidebar">
    sidebar content
  </div>
{% endif %}

filter过滤器

vue中也有类似东西

{{ "hi" | capitalize }}

jekyll serve启动报错 error:permission denied -bind(2) for 127.0.0.1:4000

4000端口被占用

D:\r\jekyllproj\try\my-awesome-site                                              
λ netstat -aon | findstr "4000"                                                  
  TCP    127.0.0.1:4000         0.0.0.0:0              LISTENING       3112      
  TCP    127.0.0.1:4000         127.0.0.1:52772        ESTABLISHED     3112      
  TCP    127.0.0.1:52772        127.0.0.1:4000         ESTABLISHED     32940     

最后是PID.在任务管理器的服务中找到PID, 我这儿发现是foxit的一个服务占用的. 停掉它.再次运行就好了.

jekyll可以转换的语言

包括markdown和liquid

jekyll如何使用liquid

在html最前面加上

---
---

即可

替换源

据说淘宝源已经停止维护,现在只有https://gems.ruby-china.com

$ gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/
$ gem sources -l
https://gems.ruby-china.com
# 确保只有 gems.ruby-china.com

显示安装进度

gem默认不显示安装进度,下载比较大的gem文件的时候就搞不清楚是不是断了,添加--verbose或者-V显示详情.


gem install xxx -V
```

自己的核心产品是应该做的。可以扩大一点产品的的概念:产品除了我们常见的产生价值的有形物品外,把销售能力/服务能力等其他产生价值的虚拟能力也称之为产品。核心产品是公司依靠赚钱生活的产品,或者是在未来想象中依靠赚钱生活的产品。公司的客户建立在核心产品之上的印象凝聚成品牌印象。
一个产品背后都是一串供应链,那么自己的产品中,哪些又是应该自己做,哪些是供应链来做?
那么要看产品的竞争力和供应链的竞争力了。这两个有什么不同?产品竞争力是公司的客户、也就是我们的下游评估的,供应链的竞争力是供应链的客户(包括自己公司在内)评估的。

产品的竞争力

至少包括产品门槛和产品差异化优势。门槛决定能不能卖,差异化决定好不好卖。
在我来看,产品差异化优势是必须自己做的,不自己做也就没有所谓“差异化”可言。
而产品门槛是否自己做,其实可以看供应链的竞争力。

供应链竞争力

供应链的竞争力其实是供应链提供的产品的竞争力。就是看我们能不能从市场上(潜在供应商)那里选购到合适的产品作为我们产品的原料。原料可选择性多、很容易选购到,我们说供应链很成熟;很难选购到,我们说供应链不成熟。
那么怎么算成熟?

  • 是否存在符合要求的原料。如果自己的要求很高,那就有可能找不到。反之有可能遍地都是。这时要评估自己的要求是否合理。
  • 这样的原料是否大量存在。大量存在则容易选择,不容易导致供应链中断。
  • 生产这样原料的公司是否大量存在。大量存在则容易替换,原因是一样的。
  • 这个原料是不是在我们产品中占有比较低的成本比例。产品最终要考虑成本,如果成本高,也许是要重新考虑是否自己做了。
  • 这个原料采购周期是否足够短。漫长的等待导致对市场需求反应慢,要么库存积压要么库存缺货。
  • 这个原料供应链的上游供应链(上上游)是否成熟。上上游不成熟同样会有潜在隐患,供应链始终是一个链条,一环断则环环断。但上上游的影响总之还是相对间接一点。

    常见原料对比

  • 公版原料与需要设计的原料。前者当然要比后者更成熟。需要设计的原料就是不存在的原料。
  • 设计本身。同样因要求不同而不同。高要求使可选择的设计人员变少,价格变高。低要求可选择的多,价格低,结果也可能比公版好不了多少。我认为,如果设计被评估为一种差异化的话,那还是应该尽量自己做。

举例

华为终端

我对华为终端还算比较熟悉。华为很早之前尝试做过终端,一直不成功。包括电话、Modem、小灵通、手机。但终端一直没法成为像运营商产品那样的核心产品。更像是因为有了运营商渠道而搭配着卖的。也不重视品牌,很多都是运营商定制。所以,华为这个时期有很多终端都是外包做的。然而终端中的手机成为未来核心产品的时候,就必须找出差异化来亲力亲为了。
首先是外观。其次是系统。最早的智能手机可能只有外观是差异化,系统都是公版Android。然而自从小米等自制系统越来越受到欢迎后,系统也变成了差异化竞争力之一。再次是主板。这是由外观差异化决定的。
在后期的差异化方面又发生了变化,首先是CPU。高通、联发科CPU虽然符合要求、大量存在,然而供应商就这俩,然后提高下要求到高端的话,就只剩下高通了,CPU成本也不低,所以不能说是太成熟的,值得自己做。并且其中有可以差异化的点,如低功耗之类。虽然这个门槛很高,但作为华为仍然是有实力、或者有魄力去做的。
其次是拍摄效果。这完全是新定义的一个差异化点。摄像头没有能力做,好在供应商还有几个,算法还可以优化,数量还可以自定义。当然,最重要的摄像头不能做的话,导致其实差异化拉不开太大差异,小米努努力,也可以超越。
最后是

.s是汇编编写的.
从开头注释来看是Winner Micro原厂编写, 使用的汇编应该是ARM了.

; Vector Table Mapped to Address 0 at Reset

向量表里面IMPORT的是需要启用的功能.
配合后面的DCD也要打开, 这个功能才能启用.
可以看到大多是中断回调.这个就是很神奇的地方了. 中断回调函数名称实际上是在这儿定义的.这大概意味着你不能随便改名字啦.
但是, 按键中断却不在这儿定义,而是通过wm_gpio.c中的函数tls_gpio_isr_register()定义.