FPs

Pelican插件:CDN Support

之前用WordPress 做博客的時候,用過一個WP Super Cache 的插件,
這個插件可以把WordPress 的頁面靜態化,然後用內存或者磁盤等做緩存,提升性能。

其中有個選項是開啓CDN 支持,開啓這種功能之後,插件會把所有指向本站的靜態資源(CSS,JS,各類圖片)的URL 替換爲CDN 的URL,當然填入的CDN 域名需要配置好回源。

wp-super-cache 圖片來源:keycdn.com

最近幫妹子做了一個網站(s.fangpeishi.com),想着各種優化,又想起這事。這個網站是用Pelican 生成的,所有就有了這個插件。

Continue ->

ip.fangpeishi.com

server {
    listen 80;
    server_name ip.fangpeishi.com;
    location / {
        default_type text/plain;
        return 200 "$remote_addr\n";
    }
}

获取外网IP,给自己在某些脚本里面用,没有查询地址、运营商的需求。


圖片優化筆記

這裏說的圖片優化,目標是想儘可能降低圖片大小,但又要保證質量不錯,非常矛盾。不過降低圖片大小,可以剩一大筆流量錢,降低負載,還能提升用戶體驗,值得花點功夫。

前端方面有一些關於圖片加載速度的優化,例如CSS 畫圖,CSS 合併素材,甚至用CSS 把圖片Base64 編碼(不推薦),和這份筆記關係不大。

格式選擇

不同的需求選擇不同的格式, JPEG 能夠滿足的需求沒必要選擇PNG。

format-tree

Continue ->

基於IRC 的同站聊天

circ

整理筆記發現一個大學時候的idea,那會玩IRC 的時候試用過circ這個Chrome 插件,冒出來一個想法:

基於CIRC 實現同站聊天,即在irc 上自動創建一個網站域名的頻道,瀏覽者在瀏覽網站時可以右鍵快速打開加入。

不過由於當時不熟悉JavaScipt 以及其他原因就擱置了。現在翻出來,想着把它給實現了。先找到circ 的源代碼(作者開源了),看了下有點頭大,又找了《Chrome 擴展及應用開發》這本書,看了幾章,到第六章的時候才發現circ 是一個chrome 應用,不是一個擴展,所以很多權限會受限制。我想在右鍵添加的contextMenus好像只能用於擴展,另外要獲取當前瀏覽頁面的URL,也只有擴展能拿到?

頓時信心大失,放棄了,寫一篇文章記錄下,希望有一天哪個高手看到能把這個idea 實現了。XD


htop 解釋

"Explanation of everything you can see in htop/top on Linux"

“解釋你在Linux 上htop/top 中看到的所有內容”

很長一段時間我都不清楚htop 中所有內容的意思。
我曾經以爲我的雙核機器上1.0的平均負載意味着CPU 利用率是50%。這並不完全正確。而且,爲什麼是1.0呢?

我決定查清楚,並記錄成這份文檔。

大家也都說,學習事物的最好方式是通過教別人。

Ubuntu Server 16.04 x64 上的htop

這是一張我要解釋的htop 截圖。
canyoukillit-before

Continue ->

《極客與團隊》讀書筆記

team_geek_cover

《极客与团队》這本書是在看《技术管理猪鸡-1 开篇》注意到的:

Google 的芝加哥 office 有两个技术领导:Brian Fitzpatrick 和 Ben Collins-Sussman。他们合写了一本书,叫做 Team Geek。

這本書的副標題是“软件工程师的团队生存秘笈”,畢業一年認識到和同事合作、如何更高效的推進工作也十分重要,正如作者在書一開始提到了書的宗旨:

本書旨在幫助程序員改進理解他人、與人溝通,以及與人合作的能力,進而使其在編寫軟件的過程中變的更有效率。

這本書的核心是“HRT”,即“謙虛”,“尊重”,“信任”,不算是什麼祕訣,但卻非常難做到,一遍讀,一遍想着工作中的一幕幕,感慨良多,希望能在閱讀完這本書之後,在下一份工作中有更好的表現吧。
把書中的內容要點,以及一些隨想簡單的記錄如下,方便日後查閱。
Continue ->


2016年总结

离开北京前,和妹子一起去了次故宫,妹子拍的天安门

tiaanmen

2015年3月初来到北京,2017年1月底离开,在第一家公司,从实习到入职转正,再到离职。
16年,五一有九天假,去了长沙岳麓书院,回了学校,再去了佛山。最重大的变化都发生在下半年,六一时和妹子在一起,八月份一起出游去了泰国。
Continue ->


Salt Minion ID 變爲FQDN 記錄的問題

最近在一臺外網機器上起了salt minion ,但是同事發現/etc/salt/minion_id 不對,之前自動生成的minion_id 都是機器的/etc/hostname,這回變成了一個奇怪的域名:cncXXXX.XXX.ln.cn,並且這個域名和使用 hostname --all-fqdns 返回的結果相同。先查下minion_id 是怎麼生成的。

Github:saltstack/salt/doc/topics/tutorials/walkthrough.rst:

When the minion is started, it will generate an id value, unless it has been generated on a previous run and cached (in /etc/salt/minion_id by default). This is the name by which the minion will attempt to authenticate to the master. The following steps are attempted, in order to try to find a value that is not localhost:

  1. The Python function socket.getfqdn() is run
  2. /etc/hostname is checked (non-Windows only)
  3. /etc/hosts (%WINDIR%\system32\drivers\etc\hosts on Windows hosts) is checked for hostnames that map to anything within 127.0.0.0/8.

If none of the above are able to produce an id which is not localhost, then a sorted list of IP addresses on the minion (excluding any within 127.0.0.0/8) is inspected. The first publicly-routable IP address is used, if there is one. Otherwise, the first privately-routable IP address is used.

If all else fails, then localhost is used as a fallback.

應該是第一點,通過socket.getfqdn 拿到的結果,也驗證了和上文提到的hostname --all-fqdns 拿到的結果一樣。

FQDN是什麼?

Continue ->

HAProxy 最佳實踐筆記

haproxy_best_practice

這篇筆記內容主要來自Haproxy官方團隊分享的一個幻燈片:《Haproxy best practice》,介紹了一些常規的配置方式和優化手段。

不要盲目使用文中出現的所有技巧。

Haproxy 是如何工作的

關於Haproxy 團隊介紹,以及一些特性介紹直接看前面幾張幻燈片即可。 Haproxy 的主要用作代理請求,工作流程如下:
haproxy_proxy_mode

client 和Haproxy 建立連接,Haproxy 再和對應的後端server 建立連接,然後作爲中間人,轉發請求。 在Haproxy 配置中,對一個代理,會劃分爲2層,frontend(前端) 和backend(後端),這和上文說的Haproxy 的工作流程也是對應的。
Continue ->