易栈网-膘叔

請不要介意我用的是繁體字。。。

好久沒有參加過聚會了，這次架構師大會怎麼著也得參加，於是我買了門票希望能夠聽到一些不同的東西。雖然最後由於時間由於各種安排，我有一些期望的沒有聽到，但還是聽到了一些比較有興趣的東西。
一、贊助商
為什麼要提這個？畢竟現在各種社區為什麼舉辦不起來？原因有很多，其中有一部分就是因為沒有錢，你想啊，租場地要錢、租設備要錢、錄像要錢，什麼東西都是 靠錢來支撐。如果人來得少了，大家出的份子錢還不夠付付場地費啥的，這時候你也不能讓人加錢吧？如果人來得多了，原先準備的小場地可能就不夠用，或許就會 有人感到不滿意，甚至以後就可能不願來參加。
如果有錢，再加上一群有激情的人，這樣的社區就能夠延續下去，也只有這樣，社區才能延續下去。當然理想情況下，社區應該是自己能夠造血，而不是靠別人來輸血，只有自己能夠造血了，對於外在的壓力才會減輕。
所以，感謝這次的贊助商，也正因為他們，我們才有機會聽到這些知名人士或者說有才華的人給我們的技術分享

二、技術點
大概是因為thinkinlamp舉辦的緣故，所以大家基本上都是講的php相關的技術點。也正因此，更容易被大家所接受和理解。當然今天的技術點並不是 完全與PHP相關，畢竟這是架構師大會。可是誰又能真正的描述什麼是架構師呢？軟件架構師、系統架構師等都能稱為架構師，而今天的分享就幾乎都包含了這些 內容。
1、張爾寧：安居客的架構變遷。張爾寧講的幾點正好是我關注的，搜索和圖片存儲，後期又補充了一些代碼部署和數據統計、數據監控、系統監控等
    搜索用的是solr，以前沒有關注過，以後會稍微看看。但圖片存儲這一塊確實是我關心的，雖然我的量肯定沒有安居客大，但我每天也會產品將近2G左右的圖片，嗯，這幾乎是指原圖。如果再算上縮略圖等，那至少也是3G左右，雖然增長幅度不高，但畢竟也在緩慢增加。100天下來，也有300G左右的數據了，雖然磁盤不值錢，但流量值錢啊。再說了就算不值錢，多少塊硬盤也經不起這樣折騰啊。於是它的圖片的存儲方式我就相對比較關注了（我這裏不介紹，事後應該有PPT，大家可以圍觀，否則我這裏就會有太多話想說了）。
     然後對安居客的一些小產品和小功能有一些想法。我不知道現在有多少公司會向安居客這樣，因為使用了solr，所以又額外做了一些solr的管理程序；因為要部署代碼，甚至實現了一些簡單的github的界面；為了要管理xxxx，最後又實現了一引起xxx的管理軟件；其實我挺羨慕安居客的，至少他們的頭願意看到他們折騰也願意讓他們折騰。有一些boss就無法理解，為什麼不把本職工作做做好，做一些一個星期只能使用一兩次的WEB管理程序。這其實是很多公司的通病。不講了，再講就變成發牢騷了。不過，這些小工具的實現確實簡化了很多工作，所以我也只能是羨慕：人多啊，人多了想做什麼事情的時候都有人做。 人少的時候，事情都做不完，怎麼有空做這些東西？

2、周愛民：架构表达方法中的界面及其原则。周愛民是一個名人，我一直有訂閱他的博客，只是這兩年更新的少了。他的書除了delphi那本沒有看過外，其他的都算是看過了。今天是第一次看到真人，有點失望，長的不太象大師（開個玩笑）。不過他講的東西就是一個軟件架構師在做的事情了。怎麼樣讓架構能夠適合更多的變化。用aimingoo的話來說，架構橫切、豎切、外包圍 都是一種方法，每種方法都各有優劣，只是現在橫切用的比較多一點。（橫切：假設架構是一個正方型，橫切就橫過來一刀，一些基礎構架，一些是應用核心，希望沒有理解錯）。
   周愛民還提出了一些觀點：
    1.框架和库的区别：框架有明确的系统原则和模块原则
    2.服务和层次化理论：服务是一种“库”、需要解除一些逻辑依赖
   當然在提出這些觀點的時候，他是拿Erlang中的一些編程規範來說的，我記得最清楚的就是：盡量少用防禦性編程。
    不可否認，很多時候爛代碼都是從防禦性編程裏產出的。

3、程輝：LAMP in Cloud --- 新浪SAE架构与设计。這個確實是我今天比較感興趣的話題之一。因為在沒有用SAE之前，自己也嘗試對PHP做過簡單的封裝，讓他僅用來跑一個小項目，而可以忽略其他的平臺因素。在今天看來，這種做法其實並不是特別可取，因為它犧牲了可擴展性。不過在5.4的時候，PHP也能夠自己就能夠實現成一個小型 Webserver，所以以前的想法又可以付諸實施了。
    當然新浪SAE不可能這麼簡單，否則它今天就不可能做在這裏講解了。SAE的早期版本只是實現了一個php的runtime，只是為了這個runtime的安全，他們在上面又加上了zend sandbox和http sandbox，各種各樣的沙盒，使得runtime被攻擊的概率減少了很多。說白了，又有點象java的JVM吧，只是JVM又沒有phprumtime靈活。為了避免因為沙盒帶來的影響，sae又模擬實現了很多東西，比如curl庫（這個在早期的版本中是絕對不支持的，經歷了好多版本後才有這個支持），SAE也提供了一些基本的類庫：圖片處理、LBS、郵件發送、memcache、RDC、Counter、KVDB等等，這些小功能的實現使得用戶在遷移的時候能夠將問題最小化。
嗯，我就將yii做了一些簡單的二次開發，使得它支持SAE，我擴展的yiiforsae與另一位朋友的yii4sae不太一樣。將程序遷移到SAE平臺上最大的問題是兩個：1、上傳2、存儲3、緩存，其他的使用都差不多。因為SAE基於SVN，所以在它的項目裏就不支持通過程序生成文件，生成在項目目錄下。只能使用STorageWrapper將文件寫入到存儲中去。就這個比較繁。
SAE還對.htaccess進行了重封裝，只支持一些基礎功能，這些也足夠了。
SAE對我最大的啟發提10個版本庫。這個在SAE第一次推出的時候就有了，非常實用，因為你可以在兩個版本庫之間隨意切換，即，你在v2.xxx.com上進行開發，當測試完成後，將代碼的默認庫設置為v2即可，只要操作一下鼠標就完成了。如果發現有重大問題，繼續點一下鼠標 。一切就是這樣的簡單。
SAE宣傳的就是穩定、安全、保密。陳輝說了，如果你不放心，你可以上傳ZG處理過的代碼。

4、陈思儒 ：《AMOEBA（变形虫）的架构以及使用》。說實話這個話題我的興趣不是很大，我並非說陳恩儒的東西不好，而且這個玩意大家現在都在玩一個思想。如果真要說，那SAE的RDC已經有它的類似效果了，當然可能性能不如它。不過在目前變形蟲 還不穩定的基礎上，相信沒有多少人願意當小白鼠。
    不過它的一些策略、處理流程都是可以值得借鑒的。話說，我也沒有覺得lua都很難學吧？
    amoeba的一個缺點在於，因為他支持了多庫多表的即時查詢，所以，對於聚合類的函數，就無法支持了。
   當然，尺有所短，寸有所長，思想是可以用來借鑒的

5、潘曉良：百姓网的“非典型”架构之路。這個分享也是我感興趣的。自從第一次知道客齊集後，後面對於它們的關注就相對比較多，只是後來突然消失了不少時間。百姓綱介紹中說他們的代碼是越來越少越來越少，現在只有7萬行不到了。而在之前的分享中張爾寧說他們的代碼有數十萬行代碼了。百姓網的代碼卻還在精簡（這不正是持續重構嗎？）潘曉良說了一點我非常受用：讓用戶盡可以快的打開網站。這點非常重要，現在很多公司為了好看，大量的CSS加上大量的圖片，使得在訪問的時候光這些圖片和CSS的加載就消耗了好多時間，他們怎麼就沒從用戶角度 想？
    潘曉良介紹百姓網的架構變遷時用了四個詞做代表：遷移、減少、增加、平衡。當然前面兩個是百姓網的特殊歷史原因所造成的就不做多提了。增加，怎麼增加，對我們來說就很關鍵了，要知道程序不是說你加一臺服務器就自動將性能提升1倍了，要改很多東西。雖然潘曉良沒有提，但，因為他們從最多開始就是40臺左右的服務器，相信這些問題在初期就已經被處理或者已經遇到過了。後期這些都不是問題了。
順便說一下，百姓網才18個工程師。糾結啊，18個人做了這麼多的事情。
潘曉良還提了一下，說是百姓網並沒有用了一些多麼高深的架構，相反他們的WEB只有10臺，DB6、7臺，搜索好幾臺。並沒有多麼複雜的架構，他只是很得意說，他們的負載均衡是硬件的，用的很爽。
最後他還是總結了一下：架构是对目标的极致的最求。確實，架構不是越複雜越好，而在對極致的追求中所掌握好的平衡。

三、嘉賓致辭
幾個嘉賓的致辭也很有意思，時間都比較短，除了安居客的倪军是以講故事的方式介紹了某個架構師的成長歷程，其餘的幾位都是在介紹自己的產品。比如 海丁網、比如愛可生，嗯，我想了想，是啊，人家都贊助了，怎麼也得讓人家介紹一下自己的產品吧。再加上時間也不長，也能夠接受。我在這裏就不多談了。

四、隨想
嗯，我還是不太喜歡互動，雖然在周愛民的提問上有想過要回答那個為什麼傳入對象而不是ID，帶來的後果。其實從當時的PPT上可以很簡單的看出，那個函數大致是這樣：checkXxxxFromCompany，但結果，傳遞進去的是一個pueOrder對象。雖然在函數中是取得了這個pueOrder.getCompanyId()，但這本身就與設計不符。
不過，不喜歡互動好象是程序員的通病。很多人都不太喜歡交流，不知道自己想要說些什麼，也不知道如何將自己的想法傳達給別人，這確實是需要鍛煉的。
在結束的時候套用一句很早的臺詞：相聲（演講）是一門語言藝術。要想掌握好還是很有難度啊。

什麼是hprose?這個我不想多說了，只想說它之前的版本叫phprpc，這是它的更新版，功能更強大。
官方地址是http://www.hprose.com。
以前用用都還行，結果就昨天在使用的時候發現，調用同樣的接口時，服務器返回502錯誤。但有時候確實是正常的。
仔細查看了一下，好象是返回的數據過大，於是我使用serialize將數組序列化後，用strlen查看了一下長度，發現長度在99999左右（這個數字當然是不對的，但大小差不多），最多也就99K嘍。但正因為這樣會出錯。於是我一點一點試
我在遠程的函數裏str_repeat("0",1111),一直嘗試，發現當數字在7000多時，就返回502了。因為是采用了php-fpm方式，所以我在本地的apache服務器上做了個測試，發現大約是在9000多字節。鬱悶。
問了一下andot，他說可能是服務器的設置也問題，也可能正好是一個BUG。但短時間內沒有時間測試了。

鬱悶

-----

时隔多日，这个BUG已经在一年前就解决了。只是我没有更新。andot居然来回复了一下，我想，我还是更新掉本文吧。

這篇文章是我以前寫的，所以還是簡體。。。。

    1、指阅的内容源，这个我不想多提，毕竟你只要看到指阅中的媒体名称，一般还是能够找到其來源的，所以这一块并不想多说，畢竟RSS源這一塊大家都能找得到
    2、分类，IPAD版上的指阅分类分的相对较细，而且是属于那种细的过份的那种，但指阅手机版因为只有4个APP，针对4个品类进行细分（娱乐、体育、科技、时尚），每一个分类下的内容看起来都不是特别多，但内容确实是不错，象科技类的，针对其频道就相对较少，但每个频道下面的分类都相对较细，比如，指阅·科技，中的“社交网络”频道，其中的分类就是：微博、Facebook、twitter、SNS游戏、腾讯微博、新浪微博、微博营销、Google+、Zynga，涵盖了几乎这个行业中的一些有特色的品牌，比较适合对某一类有兴趣的用户。
    3、Pintrest，现在流行这个玩意，而指阅也有类似功能，如果你按图片浏览，它的列表就是pintrest风格，如果你看到有兴趣的图片就可以点进去（这一点，比较适用于时尚、娱乐、体育，相对来说科技反而是不太合适的）
    4、热门关注、最近更新，因为我们的产品中没有按收藏数和点击数来排序，也就是说其实我们没有将我们最特色的媒体推荐给用户。

其實很難說什麼，但我還是想多說兩句。

閱讀有幾種？瀏覽、快讀、精讀、學習，粗一看，大約有这么几种（我這個是指IPAD、iphone上面）。

浏览：我指的浏览是快读，就是传说中的一句话新闻，例如：皇马1：0战胜xxx，这句话其实就是新闻，我不需要看内容也知道了。看这类新闻的人不会少
快读：也是指新闻类或者娱乐类的，一扫而过，没有内涵，纯粹就是打发时间随便看看（时装秀、图片类文章都是这样，大致了解一下情况就OK了，没有必要钻在里面）
精读：看小说是精读，看一篇有意义的文章也会精读，甚至，那种做菜类的文章也会让人精读，因为他需要让人将精力放在这里面。
學習：一般用閱讀軟件來學習的，真的很少，大多數時候不是當成參考書就是。。。。因此kindle这类专业用来看PDF、EPUB类的工具更适合他们。

其實本來還有一些話，但不清楚是不是目前可以講，所以就先不講了。

原文的內容是這樣講的：
如果你常看 HTC 发布的手机的话，不晓得你有没有发现，在 HTC 公布的手机官方图片中，时钟都是指在 10 点 8 分，是巧合吗？还是有原因？关于这个疑问，有不少人提出自己的解释，像是有可能是 HTC 发布第一款 Android 手机 G1 的日期、可能是设计者随便弄上一个时间之后再也没去改它、或者是根本没有原因等等。
-------------
OK，我想這應該算是產品設計的一種，那麼10：08究竟是什麼意思呢？
-------------
前一阵子 HTC 在官方博客里给出了答案。在 12 小时制的数字时钟里（就像下图那个时钟一样），10:08 是在合理的时间范围下，让最多液晶单位亮起来的时间，让时钟制造商可以确定时钟正确显示；大家可能会说如果要让最多的液晶亮起来的话，怎么不用 18:88 呢？因为事实上没有这样的时间。
另外，在传统指针时钟上，10:08 分时，时针与分针刚好会呈现一个 V 字形的「微笑」角度，有「胜利」的意思，这样看起来最对称，所以大家看一些手表的 DM，图片也都会刻意调到 10:08 来拍摄。总之，HTC 采用 10:08 时间的原因就是这么简单，没什么更深层的意义。

▲ 一般的指针时钟，常常会把时间调到 10:08 拍摄照片，指针看起来对称，也不会挡到品牌 logo。
原文來自：http://www.cnbeta.com/articles/191609.htm