[tech] LinkedIn open-sources PalDB, a key-value store for handling 'side data'

cool

一個 high throughput 的 read only database，主要是用來解決一些使用 side data的情境。例如，在做自然語言處理時，你要使用的stop word檔案，或是在做分類或是spam 偵測時，你需要預先讀入的處理過分類資料。而在Linkedin 中，這樣的操作，居然成為他們的瓶頸所在，所以他們開發了PalDB 。


Side data can be defined as the extra read-only data needed by a process to do its job. For instance, a list of stopwords used by a natural language processing algorithm is side data. Machine learning models used in machine translation, content classification or spam detection are also side data. When this side data becomes large it can rapidly be a bottleneck for applications depending on them. PalDB aims to fill this gap.

Performance

效能來說每個新database推出的時候，總會有個令人經驗的對照。
與常見的LevelDB或是RocksDB對比甚至可以高達八倍的throughput。

PalDB is specifically optimized for fast read performance and compact store sizes. Performances can be compared to in-memory data structures such as Java collections (e.g. HashMap, HashSet) or other key-values stores (e.g. LevelDB, RocksDB).

Current benchmark on a 3.1Ghz Macbook Pro with 10M integer keys index shows an average performance of ~2M reads/s for a memory usage 6X less than using a traditional HashSet. That is 8X faster throughput compared to LevelDB (1.8) or RocksDB (3.9.0).

Limitations

• PalDB is optimal in replacing the usage of large in-memory data storage but still use memory (off-heap, yet much less) to do its job. Disabling memory mapping and relying on seeks is possible but is not what PalDB has been optimized for.
• The size of the index is limited to 2GB. There's no limitation in the data size however.
• PalDB is not thread-safe at the moment so synchronization should be done externally if multi-threaded.

LinkedIn open-sources PalDB, a key-value store for handling 'side data' | VentureBeat | Big Data | by Jordan Novet
http://venturebeat.com/2015/10/26/linkedin-open-sources-paldb-a-key-value-store-for-handling-side-data/
linkedin/PalDB
https://github.com/linkedin/PalDB

[elasticsearch] Elasticsearch 2.0.0 GA is Ready for Provisioning

眾所期待的 Elasticsearch 2.0 終於GA了


what’s new?

• Pipeline aggregations - an entirely new class of analytic functions that push more computation into Elasticsearch, making advanced applications simpler and easier to create.
• Query/Filter merging - query execution can now be automatically optimized to run in the most efficient order possible.
• Configurable store compression - a new high-compression option added to each index, which can reduce storage size by up to 30%.
• Performance and resilience - a multitude of smaller changes in Elasticsearch that add up to a more stable, reliable, easy-to-configure system.
• And much, much more!

Marvel 2.0.0 free to use in production

Marvel is now free to use in production for all Elasticsearch users. A license is required, but is available to all users free of charge. If you require multi-cluster monitoring support, that is a commercial feature.

Migration Plugin

from elasticsearch 1.x to 2.0

elastic/elasticsearch-migration https://github.com/elastic/elasticsearch-migration

Links

Elasticsearch 2.0.0 GA released | Elastic

https://www.elastic.co/blog/elasticsearch-2-0-0-released

Elasticsearch 2.0 Overview & Demo - YouTube

https://www.youtube.com/watch?v=KlXG2XLHYc0

[elasticsearch] 配置 heap 在超級服務器上 (purpose-built hardware elasticsearch heap configuration )

如果你有1TB ram 的大機器，你會怎麼配置elasticsearch呢?

30.5G這個數字是非常重要的。所以，你使用大機器的時間，你將會多出很多的記憶體。尤其是現在有很多記憶體高達512G~768G 的超級服務器。

首先，官方的建議是避免使用者樣的大機器。
Hardware
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html

一般來說，在這種大型分散式系統如hadoop ，都推薦使用一般的˙商用硬體(commodity hardware)。

如果你已經擁有這樣的超級服務器，
你可以採取的方案有兩個

若是主要是在使用full-text search ? 可以考慮把Elasticsearch ES_HEAP_SIZE 設成 30.5G，把其他剩下的memory 都留給Lucene 透過系統的緩存來使用這些memory。由於segment都緩存在系統中，所以你會有更好的 full-text search（全文檢索）效能。

若是主要在sorting /aggregations ? 當然會預期，能夠使用越多memory越好。但是取代設定超過30.5G給Elasticsearch 的heap ，可以考慮在一台機器上運行多個elasticsearch節點。
依然依照 50% rule，把剩下的memory給lucene使用。舉例來說，你有128G的RAM 在上面運行兩個節點，各配置給他們30.5G。所以，有61G使用在heap上，67G留給系統與Lucene使用。
使用了，在一台機器上裝上多個節點的方案，可以設定
cluster.routing.allocation.same_shard.host: true

這個選項可以避免 primary shard跟 replica share 放在同一台實體機器上。

[elasticsearch] Elasticsearch heap 最佳配置 best practice

Elasticsearch  預設使用的 heap 大小設定是 1GB 。
對於實際的佈署與使用，1GB的設定是太小了。

這是非常不正確的設定，如果你使用預設的設定值來佈署你的cluster。

在Elasticsearch 中，有兩個方式可以改變 heap size 的大小。最簡單的方式就是使用設定 ES_HEAP_SIZE 的環境變數。當server process 啟動的時候，將會讀取設定的heap參數。

export ES_HEAP_SIZE=30.5g

另一方面，你也可以在啟動程序時，透過command-line 來設定 heap size。

./bin/elasticsearch -Xmx30.5g  -Xms30.5g


這裡有一點值得注意的是，把 heap 的最大(mx)最小(ms) 都設成相同的數字，避免成本很高的heap resizing 。

把一半的memory 留給 Lucene

heap size配置太大是一般常見的問題。如果你有一台64G的機器，你可能想的是把64G的記憶體都配置給 Elasticsearch 使用，希望配置的越多越好。

Heap 的配置在 Elasticsearch中相當的重要。因為眾多的資料結構存放在 momory裡，以提供快速的操作。還有另外一個memory 主要用戶就是Lucene ，使用 off heap 方式。(另外探討使用java 攥寫的大資料軟體們常用的技術 off heap )

Lucene 設計使用底層OS提供的caching 機制，來存放一些 in momory 的資料結構。 Lucene 的 segments file則是存成會被修改的個別檔案。這個設計使得 cache 緩存可以很好的得到應用。 底層OS很擅長的去把熱門的segments 在memory 內，使得這些 segments 可以快速的被讀取。

Lucene 的效能主要是在於與OS層的互動操作。所以，如果把所有可用的momory都配置給elasticsearch ，那們將沒有留下足夠的 momory 給 Lucene 。這將會對嚴重影響全文搜索的性能。

所以，邊準的建議是，配置可用記憶體的一半給 Elasticsearch 的 Heap ，
同時保留系統的一半記憶體。放心，這些記憶體不會被閒置，他們會大量的被Lucene所使用。

勿超過30.5G

還有一個不配置大heap給Elasticsearch的原因。就是，JVM 在30.5G下使用一個compress object pointers 的技巧。

在Java中，所有的object被配置在heap上，透過pointer 來引用。

[演講]Mark Zuckerberg 2015 在清華大學中文演講

Mark Zuckerberg 暨上一年到清華大學，
這次他又使用全中文演講。

關於他的創業

• 想要去做什麼why ，就去做了

• 堅持你的使命
• ex news feed 的功能本來不被看好，但是後來成為，世界上最重要的媒體
• 更多的用心
• 很多人都說新的想法不會成功
• 人們在用是因為連結是重要的

• 必須向前看
• 你要有願景，每做一步，就可以多一點東西

在你做之前，不要先問怎麼做，要先問為什麼做

"Change the world" 改变世界 - Mark Zuckerberg Speech at Tsinghua University 清华大学 in Beijing 20151024 - YouTube
https://www.youtube.com/watch?v=w8MlL2GhhOw

祖克伯成北京清大講師！臉書創辦人用中文為學生授課-國際｜中港澳｜影音-風傳媒

http://www.storm.mg/article/70137

[elasticsearch] elasticsearch bechmarks baseline performance 官方效能基準

elasticsearch 官方有提供一個 nightly indexing performance 可供當做一個效能的 baseline。

https://benchmarks.elastic.co/index.html

關於
Nightly indexing performance on master

2015/10/25 23:37:40:
Defaults: 15.8
Defaults (4G heap): 17.21
Fast: 14.91
FastUpdate: 14.64
Defaults (2 nodes): 7.16
EC2 i2.2xlarge Defaults 4G: 7.45

單位 K Docs /sec

他們所使用的配置與指標非常值得參考


This test indexes 6.9M short documents (log lines, total 14 GB json) using 8 client threads and 500 docs per _bulk request against a single node running on a dual Xeon X5680 (12 real cores, 24 with hyperthreading) and 48 GB RAM.
Defaults, 2 nodes is append-only, using all default settings, but runs 2 nodes on 1 box (5 shards, 1 replica).
Defaults is append-only, using all default settings.
Defaults (4G heap) is the same as Defaults except using a 4 GB heap (ES_HEAP_SIZE), because the ES default (-Xmx1g) sometimes hits OOMEs.
Fast is append-only, using 4 GB heap, and these settings:

  refresh_interval: 30s
  index.store.throttle.type: none
  indices.store.throttle.type: none

  index.number_of_shards: 6
  index.number_of_replicas: 0

  index.translog.flush_threshold_size: 4g
  index.translog.flush_threshold_ops: 500000
  

FastUpdate is the same as fast, except we pass in an ID (worst case random UUID) for each document and 25% of the time the ID already exists in the index.
Defaults (doc values) is the same as Defaults, but also indexes doc values for most fields

[python] 兩個 dict 字典怎麼找出相異的key difference in keys contained in two Python dictionaries

A,B 各是一個dict

diff = set(B) -set(A)


dictionary - Calculate difference in keys contained in two Python dictionaries - Stack Overflow
http://stackoverflow.com/questions/1165352/calculate-difference-in-keys-contained-in-two-python-dictionaries
dictionary - Calculate difference in keys contained in two Python dictionaries - Stack Overflow
http://stackoverflow.com/questions/1165352/calculate-difference-in-keys-contained-in-two-python-dictionaries

[git] 修改已經 git commit 的 提交訊息 / modify git commit message

在還沒 push 到remote 前，
可以使用

git commit --amend -m "New commit message"

要修改已經push到遠端的branch

git push <remote> <branch> --force

# Or 

git push <remote> <branch> -f


要注意的是 force push 會 overwrite 你遠端的branch


ref
Git 版本控制系統 | ihower 的 Git 教室
https://ihower.tw/git/rebase.html
Git - 提交更新到儲存庫
https://git-scm.com/book/zh-tw/v1/Git-%E5%9F%BA%E7%A4%8E-%E6%8F%90%E4%BA%A4%E6%9B%B4%E6%96%B0%E5%88%B0%E5%84%B2%E5%AD%98%E5%BA%AB
Edit an incorrect commit message in Git - Stack Overflow
http://stackoverflow.com/questions/179123/edit-an-incorrect-commit-message-in-git

[elasticsearch] maximum ES_HEAP_SIZE best practice Elasticsearch maximum HEAP SIZE 設定 最佳建議

關於設定 Elasticsearch 的 ES_HEAP_SIZE 上有一些建議， 如果設定超過32G  的 ES_HEAP_SIZE ，可能會遇到 JVM 上的  uncompressed pointers  的問題。

後來文件上修改了這個設定值，建議的maximum ES_HEAP_SIZE 設定在 30.5 G ，

主要是避免不同的JVM上對，uncompressed pointers的不同，設成 30.5 G ，是比較保險的數字。

https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
Recommended Heap - Documentation Error? · Issue #14254 · elastic/elasticsearch
https://github.com/elastic/elasticsearch/issues/14254

[吳式太極拳] 十月習拳心得

這篇習拳雜記是記錄十月初到中的一些心得與歷程

把動作練的更合乎標準，每個動作的用法用意，都要細細的去體會，

不是打一次兩次幾次就會的，要從知到動作，然後精，再來熟悉。

才能慢慢體會一動必有一用，就算知道了，也不是一時半刻，由知道，就能到使用的。

151003(六) 請教老師 關於 高探馬 左右分手腳 野馬分鬃  的用法，才有恍然大悟，原來這幾個動作，細打有如此深意，然後又可以連貫起來使用。

師兄都會在此之後，來指教推手跟結構的力量，一步一步的導引。

週日往往是多練好幾次的機會 ，151003(日) 居然還能打到五次。

151010 (六)

師兄跟我講推手，要把肩放鬆，不能聳肩，也就是接觸力量的時候不要緊張，把他接住，但是還是要維持原本的掤勁。也就是說，把肩放鬆，手保持接牢(小圓肌 大圓肌附近維持著，但是是使用筋骨的力量而非肌肉)，然後氣下沉，身體表持中正，使用腰的力量來帶動，過程中不能把力量放掉，放掉就會危險，對方容易攻入，且要是被破壞了，自己就出不了力了。

151017 (六) 

一貫的在每日打拳中開始，約莫在1015打完拳架子。

師兄再次來講解推手，主要是說，放鬆的階段下，讓結構骨架來撐，途中要保持中正，不能偏掉。

後來，師兄請老師教授 二十四式功法裡面的 大象搖頭，這個功法，很常看到當代的吳家太極掌門 吳光宇 在講解的時候演示。

又跟老師提到，這個動作看起來是跟吳陳比武時，吳公儀常用的訓練嗎？ 老師說，還有一個功法叫做吳剛伐桂，更著重於此。

大象搖頭，在操作的時候轉腰，手鬆沉下來，不要一下快起來，也不要一下停下來。

練習的時候不限次數，50,100,120 按造你的身體狀態來決定。

之前，請教老師 24式功法(也就是 常說的 陰陽二十四段 )的相關故事，老師說，會看你需要加強哪個方面有不同的功法做專門的訓練，有人有需要，有人就不需要。特別有興趣想要傳承的人就會想說把它學齊，如此而已。

換而之其實也沒這麼玄之又玄。

僅以此為記

ps  原始草記 匆匆寫下

151003 1010 打完
高探馬 左右分手腳 野馬分鬃 知 精 熟
151004 日 1058已練三次
101010 1012 打完 1002到
肩放鬆 接牢 氣下沈 中正 用腰帶

151011 1021到

101017 0930 到

101017 1015 打完

放鬆讓結構骨架中正來撐
轉纏絲改變力的方向

大象搖頭

101018 1016 打完 0955到
101018 1130離開
101018 打四次

[武術] 再閱 宮式八卦養生內功 劉雲樵傳 氣血滾滾 養氣還原

作者：郗家駿, 出版社：逸文, 出版日期：2009-10-14
商品條碼：9789866329098, ISBN：9866329097

想不到這本書，在博客來上居然找不到了，已經絕版了。
裡面有提到氣血滾滾跟養氣還原這兩個功法。

確為劉雲樵傳下的宮式八卦內功

養氣還原，居然是在一次酒醉的場合，劉老師帶著郗家駿跟陳國欽做了幾十趟，幾次以後覺得整個人神情氣爽。
劉老有次隨蔣總統移往日月潭行館訓練隨扈，也是看隨扈精疲力盡，遂教他們這套養氣還原。

我對養氣還原最深的一次印象，就是隨著 Lucky Chen 陳瑞祥 教練練習的一段時間，有次真的是有點酸痛，跟的做一次養氣還原，居然整個精神都來了，訓練的酸痛感都不見了。


幸好當年有把劉老練功的照片一式一式對照拍了下來，甚至保存至今。

在最後留下值得探討的問題，到底先練氣血滾滾還是先練養氣還原。
筆者感慨沒有在劉老生前巴著他問。

也提出了兩種解釋，先練氣血滾滾充實血氣，或是養氣還原吐故吶新，都有不一樣的思考。
但是，可以知道的是，持之以恆的鍛鍊這兩個功法，對身體是有很大助益的。

其他資料可參考

• peicheng note: [武術]宮式八卦養生內功 劉雲樵傳 氣血滾滾 養氣還原http://peichengnote.blogspot.tw/2013/12/blog-post.html
• 八卦健身功郭應哲示範 - YouTube
  https://www.youtube.com/watch?v=tF5vd2EF7QA

台灣武藝文化研究協會 - 秋天到了，所謂運動之秋，大家一起來動動身體吧！ 由郭應哲老師示範的八卦健身功，大家可以跟著做唷...

https://www.facebook.com/permalink.php?story_fbid=1110408438987933&id=208352992526820

秋天到了，所謂運動之秋，大家一起來動動身體吧！
由郭應哲老師示範的八卦健身功，大家可以跟著做唷

特別提示：
1.有關呼吸
(1)呼吸自然，練此功，先不要繫緣於呼吸。將注意力綁在肢體上，繫緣在身體運轉的自然狀態，這叫「走大路子」，不執一專修。
(2)如老子說：「綿綿若存」。若有若無，細慢勻長，為諸家共同的準則。特別何敬一博士說，呼的慢些可降低體溫並活化細胞機能，使脈搏跳動次數降低，在吐氣時間拉長下，達到情緒穩定、安定的境界。
2.有關覺知
身體有所覺受的一些徵兆，不要太過執著。須知一切都只是因緣變幻無常之下，暫時的感覺，勿驚勿喜，勿悲勿樂，因循自然。總之，切勿執著於身體的覺受上。
3.此功法之「氣血滾滾」(小周天)及「養氣還原」(大周天)部分，由劉雲樵宗師所傳；另有許秋德師兄所授者。最後由筆者體會闡述。「反經歸正」部分，則為陳威伸老師所啟發。
4.參考書目
(1)郗家駿，《宮式八卦內功：氣血滾滾、養氣還原》，台北，逸文武術文化，民98年10月初版。
(2)劉雲樵，《養氣還原》，台北，武壇國術推廣中心，民91年二月再版。

[python][flask] jinja2 如何把 time string 轉成 datetime object / how to convert time string to datetime object on Jinja2

有個需求是在是想把 date string 在  jinja2 中 ，轉換成 datetime object。
主要是因為使用 flask-moment 需要傳入的是   datetime object。


在 Jinja2 中可以使用 Custom Filters 來做這件事情。

API — Jinja2 Documentation (2.8-dev) http://jinja.pocoo.org/docs/dev/api/#writing-filters

 def getdatetime(string,format='%Y-%m-%dT%H:%M:%S.%fZ'):  
   '''  
   datetime.datetime.strptime(timestamp, "%Y-%m-%dT%H:%M:%S.%fZ")  
   2015-10-19T08:11:21.556Z  
   '''  
   return datetime.datetime.strptime(string, "%Y-%m-%dT%H:%M:%S.%fZ")  
 app.jinja_env.filters['getdatetime'] = getdatetime  

在 template 中就可以使用

{{ post.dt | getdatetime }}

[tech_note]如何取得facebook profile 圖示

<img src="http://graph.facebook.com/<UID>/picture?type=square" />

square 可換成  square ,large ,small 取一

php - getting facebook thumbnail profile picture - Stack Overflow
http://stackoverflow.com/questions/5771929/getting-facebook-thumbnail-profile-picture

[食記][日本] 日本三大丼飯 松屋 吉野家(Yoshinoya) すき家(Sukiya)

[食記][日本] 日本三大丼飯 松屋 吉野家(Yoshinoya) すき家(Sukiya)

這次的旅程意外的完成三大連鎖常見的丼飯之旅
服用時間排列

吉野家(Yoshinoya)

2015.09.06(日)

東京淺草駅前店

松屋

 すき家(Sukiya)

[食記] すき家 Sukiya 古亭 店 Taiwan

すき家 Sukiya 古亭 店

在日本品嚐過 すき家 Sukiya 後念念不忘，這次造訪 すき家 Sukiya Taiwan 古亭店。
目前在台灣已經開了三家分店，
第一家是古亭店，在古亭捷運七號出口處，目前已經 24hr營運。
現在，內用在正餐時間還是屬於要排隊的狀態。

對照日本 すき家 來說，大部分的食材都會採取當地的素材。
所以，日本米入境隨俗的可能變成台灣米...etc..

至於口味就見仁見智，但是，還屬於中上口味。








溫蔥玉可樂餅 149

溫蔥玉青菜套餐 129

すき家 Sukiya 菜單

選好餐點可按服務鈴，服務人員會儘速來為您點餐。

[健康] 中里巴人 求醫不如求己 講腎經 筆記

中里巴人是為實證中醫，

常常推廣自我保健為先的觀念。

擁有深厚關於中醫經絡的背景基礎，使用簡單的言語，講授深入的概念。

這篇是講腎經。

中里巴人 求人不如求己 肾经 - YouTube

 https://www.youtube.com/watch?v=hGSjNooPB_4

[elasticon] elasticon 15 Elasticsearch User Conference Sponsors

elasticon 15 Elasticsearch User Conference 官網上，似乎沒有 15 年的 Sponsors 資訊了

這裡整理了一份，可以去對照這些 sponsors 怎麼去使用 elasticsearch 。

Sponsors

Strategic sponsor

• Microsoft

Blue Diamond

• The fastest way from idea to digital experience - Enonic https://enonic.com/
• Home - Avalon Consulting, LLC http://www.avalonconsult.com/

Avalon Welcomes elastic{ON}15 as Blue Diamond Sponsors http://news.avalonconsult.com/2015/03/03/avalon-welcomes-elasticon15-as-blue-diamond-sponsors/

Platinum Paragon

• Enterprise Search and Big Data Experts http://www.searchtechnologies.com/

Golden Guardian

• WordPress › Blog Tool, Publishing Platform, and CMS https://wordpress.org/
• codecentric Blog - Expertenwissen rund um agile Softwareentwicklung, Java und Performance Solutions. : codecentric Blog https://blog.codecentric.de/en/
• ShadowSoftNews The Open Source System Integration Experts. http://shadow-soft.com
• ExtraHop Networks: IT Operations & Wire Data Analytics Platform | ExtraHop https://www.extrahop.com/
• Intellectyx – Big Data Science Analytics Company http://www.intellectyx.com/
• Cloud Monitoring as a Service | Datadog https://www.datadoghq.com/
• Cisco: IoE - Using Elasticsearch to Unlock an Analytical Goldmine | Elastic https://www.elastic.co/elasticon/2015/sf/ioe-using-elasticsearch-to-unlock-an-analytical-goldmine

Cosmic Community

• Tryolabs | Python Django development with Artificial Intelligence components http://www.tryolabs.com/
• nginx news http://nginx.org/ NGINX & Elasticsearch: Better Together - NGINX

https://www.nginx.com/blog/nginx-elasticsearch-better-together/

• Ansible is Simple IT Automation http://www.ansible.com/

[gcin] Cannot open /usr/share/gcin/table/X@.kbm

會一直發生
 Cannot open /usr/share/gcin/table/X@.kbm

根據作者的建議可能是不能原因導致檔案損毀

rm ~/.gcin/config/phonetic-keyboard*

Ubuntu 14.04 gcin 安裝啟動後竟抓不到注音符號表??---->X@.kbm
http://hyperrate.com/thread.php?tid=30341

[blog] 2015 截至十月前的 blog 發表數量與 2014, 2013 對比

分析一下十月以前的本年度發表量

2015年度十月六號前發表了 89篇
2014年度共發表了 180 篇
2013年度共發表了 203 篇

表示本年度剩下三個月，如果要最少達到往年的量，
(200-89) / 3 = 37 每月產出至少 37 篇阿

看來最多只能打平去年了...
(180-89) / 3 = 30.3333333 但是也是每月最少三十篇，每天至少一篇阿。



  

[tech_note] 再次使用 delicious

再次使用 delicious ，從被 AVOS 收購以後許久沒在用，
https://delicious.com/

目前 中文的搜尋還是一樣不OK，或者是貫徹 delicious 的精神，使用tag 來做組織的工作。

讓人不禁聯想到，Evernote 回歸產品本質，專注在「筆記、同步、搜尋」（notes, sync, and search）上 。

[tech_note] hackpad 的 unique padid 產生方式 / etherpad 與 appjet

之前一直沉迷在研究不同網站的 unique id generation 的方法，

Hackpad 是從被 Google 收購並且開源 etherpad  為基礎的一個網站，目前被 DropBox收購並且也開源了。
dropbox/hackpad
https://github.com/dropbox/hackpad


自從他們成立網站後，他們有許多改進，關於他們之前的roadmap有一篇有趣的文章，他們提到幾個Task。


hackpad looking for a some hitmen (scala, java, mysql, tdd) - hackpad.com
https://hackpad.com/hackpad-looking-for-a-some-hitmen-scala-java-mysql-tdd-LzsmytZqo1A

Task 1: Kill Scala

Etherpad is built on a thin Scala request dispatching layer. It’s about 4K lines all together, including a bunch of utility functions. This layer is hard to maintain and largely useless now that many maintained frameworks exist for Jetty with support for streaming, longpolling, websockets, etc. The goal here is to replace all this code with well-supported libraries or the most succinct, idomatic Java (or Javascript!) you can write.

Start here: https://github.com/ether/pad/tree/master/infrastructure/net.appjet.oui

Task 2: Kill Rhino

Synchronous Javascript on the server is awesome. Trivially using any Java library from Javascript is awesome. 150ms response time overhead is less awesome. Oracle has written a fast replacement for Rhino called Nashorn which will ship in Java8. It interfaces entirely through the javax.scripting API. Replace the Rhino engine in Etherpad with Nashorn.

Start here: 

http://docs.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/

https://github.com/ether/pad/blob/master/infrastructure/net.appjet.bodylock/bodylock.scala

Task 3: Kill Bad DB decisions

The DB schema we chose to inherit is, erm, bad. It does a decent job using mysql as a blob store, but everything else is a mess. Inconsistent primary keys, outdated assumptions, etc. You know the drill. The idea here is to swoop in and fix things, come up with a rollout plan that won’t break people’s data.

Get started by mailing alex@hackpad.com to ask for the DB schema. Brag about the awesomest Mysql install you’ve designed/maintained.

Task 4: Kill Our Naive Ideas about Testing

Being somewhat old-school, I opt for the Linus-style of testing and debugging. e.g. `printk("This should be 1: %d\n", reallyImportantVariable);`

This is silly in context of a modern website. The device targets too numerous, the APIs too fluid. The idea here is to bootstrap us onto the path of testing sanity: set up CI, a decent Java unit testing harness, get some basic coverage we can build on.

Get started by mailing alex@hackpad.com explaining which testing framework you prefer, and the largest website on which you’ve tested it.

-----



這篇文章可以窺探他們在沒有開源的那段時間的想法。
Hackpad 主要是就是以 appjet 把 javascript server side的一個方案。
他們的 unique id generation 方式很直觀，就是重複產生直到不重複的global pad id 出現為止。
hackpad/utils.js at master · dropbox/hackpad
https://github.com/dropbox/hackpad/blob/master/etherpad/src/etherpad/utils.js

 // returns globally-unique padId  
 var SECURE_PAD_ID_LENGTH = 11;  
 function randomUniquePadId(optDomain) {  
  var id = stringutils.randomString(SECURE_PAD_ID_LENGTH);  
  while (model.accessPadGlobal(padutils.getGlobalPadId(id, optDomain), function(p) { return p.exists(); }, "r")) {  
   id = stringutils.randomString(SECURE_PAD_ID_LENGTH);  
  }  
  return id;  
 }  

[mac] OS X El Capitan 怎麼使用 split view

在 Mac OS X El Capitan 怎麼使用 split view ?

首先要打開 Mission Control (可以在spotlight 打上去 搜尋 ，也可以四指滑上) ，

2. 先把某個應用程式 放在最大 (按左上角綠色)

3. 才可以在misson control  把另外一個應用程式拖到上面的縮圖內的最大化程式旁邊去。

結論

本來以為這個split view 出來後就可以不用divvy ，使用後才發現，方便度甚至不如win7 可以直接把程式拉到左右邊撞邊緣視窗就幫你放大。

Split view 會不會是個雞肋的功能呢?

[startup_note] 原來 旅遊酒吧 travel98 是 東京裸奔 轉變來的

今天看到linshibi 講 Tabelog 就看到他之前一篇文章在講一個叫做 東京裸奔 的網站，
剛開始與邀請很多部落客當做網站的達人，並且有他們自己整理的旅遊資訊。
希望可以提供長久的update跟更新某些店家資訊。

目前已經轉型成 旅行酒吧 ，現在應該是做起來了。

東京裸奔（已改名為旅行酒吧），中文的Tabelog旅館美食資料庫，東京的愛評網 | 林氏璧和美狐團三狐的小天地
http://linshibi.com/?p=1576

[mac] OS X El Capitan 登上酋長石

9/30 開放可以下載更新的 OS X El Capitan 你更新了嗎？
Mac OS 更新完，都會一如往常的比上一版有新的改進跟亮點。

 El Capitan 短期之內，不會在搜尋到優勝美地的 El Capitan 這是個美麗的地方。


Apple — OS X El Capitan
https://www.apple.com/tw/osx/elcapitan-preview/

[elasticsearch] Amazon Elasticsearch Service

Today, Amazon are launching the new Amazon Elasticsearch Service (Amazon ES for short). !!!!!~~~~

New – Amazon Elasticsearch Service | AWS Official Blog

https://aws.amazon.com/tw/blogs/aws/new-amazon-elasticsearch-service/

Amazon Elasticsearch Service | Product Details

https://aws.amazon.com/tw/elasticsearch-service/details/

Amazon Elasticsearch Service | Pricing

https://aws.amazon.com/tw/elasticsearch-service/pricing/

Key Features

Set-up & Configuration from AWS Management Console or API

With a few clicks, you can create Amazon Elasticsearch domains using the domain creation wizard in the console. Each domain is an Elasticsearch cluster in the cloud with the compute and storage resources you specify. You can also create your domains by a making a single Amazon Elasticsearch Service API call through the AWS Command Line Interface (CLI) or the AWS SDK. While creating a new domain you can specify the number of instances, instance types, and storage options. You can also modify or delete existing domains at any time.

Flexible Storage Options

You can choose between local on-instance storage or Amazon EBS volumes to store your Elasticsearch indices. You can specify the size of the Amazon EBS volume to be allocated to the domain and the volume type - Magnetic, General Purpose, or Provisioned IOPS. You can also modify the storage options after domain creation as needed.

Security and Auditing

Amazon Elasticsearch Service lets you configure access policies for the domain end points using AWS Identity and Access Management (IAM). IAM policies allow your applications running on AWS or outside AWS to access your domain securely. IAM policies can be set up to provide fine-grained access control to the control plane API for operations like creating and scaling domains and data plane API for operations like uploading documents and executing queries. In addition, you can monitor and audit your domain with AWS CloudTrail, a web service that records AWS API calls for your account and delivers log files to you. The AWS API call history produced by AWS CloudTrail enables security analysis, resource change tracking, and compliance auditing.

Support for Logstash and Kibana

Amazon Elasticsearch Service supports integration with Logstash, an open-source data pipeline that helps you process logs and other event data. You can set up your Amazon Elasticsearch domain as the backend store for all logs coming through your Logstash implementation to easily ingest structured and unstructured data from a variety of sources. Amazon Elasticsearch Service also includes built-in support for Kibana, an open-source analytics and visualization platform that helps you get a better understanding of your data. Kibana version 3 and version 4 are automatically deployed with your Amazon Elasticsearch domain.

Direct Access to Elasticsearch API

Amazon Elasticsearch Service gives you direct access to the Elasticsearch APIs to load, query and analyze data, and manage indices.

Scaling Options

You can add or remove instances, and easily modify Amazon EBS volumes to accommodate data growth. You can write a few lines of code that will monitor the state of your domain through Amazon CloudWatch metrics and call the Amazon Elasticsearch Service API to scale your domain up or down based on thresholds you set. The service will execute the scaling without any downtime.

Set-up for High Availability

You can configure your Amazon Elasticsearch domains for high availability by enabling the Zone Awareness option either at domain creation time or by modifying a live domain. When Zone Awareness is enabled, Amazon Elasticsearch Service will distribute the instances supporting the domain across two different availability zones. Then, if you enable replicas in Elasticsearch, the instances are automatically distributed in such a way as to deliver cross-zone replication.

Plug-in Support

Amazon Elasticsearch Service comes prepackaged with a several plugins available from the Elasticsearch community including, Kibana 3, Kibana 4, jetty, cloud-aws, kuromoji, and icu. Plug-ins are automatically deployed and managed for you.

Data Durability

You can build data durability for your Amazon Elasticsearch domain through automated and manual snapshots. You can use snapshots to recover your domain with preloaded data or to create a new domain with preloaded data. Snapshots are stored in Amazon S3, which is a secure, durable, highly-scalable object storage. By default, Amazon Elasticsearch Service will automatically create daily snapshots of each domain. There is no additional charge for the automated daily snapshots. In addition, you can use the Elasticsearch snapshot APIs to create additional manual snapshots. The manual snapshots are stored in Amazon S3 and will incur normal Amazon S3 usage charges.

Monitor Domain Performance

Amazon Elasticsearch Service exposes several performance metrics through Amazon CloudWatch including number of instances, domain health, searchable documents, Amazon EBS metrics (if applicable), CPU, memory and disk utilization for data and master nodes. You can use these metrics to monitor the health of your domain and take any necessary actions such as scaling.

Pay-as-you-go Pricing

With Amazon Elasticsearch Service, you pay only for the compute and storage resources you use. There are no minimum fees or upfront commitments. You don’t need a team of Elasticsearch experts dedicated to provisioning, monitoring, and managing the infrastructure. As a result, your total costs of operating Elasticsearch goes down even at large scale.