Word 不分行空白與不分行連字號

今年9月時把之前做的一顆電路整理一下，寫成一篇journal投出去，今天接到學長的回信，結果是Major Revision，一看有不少東西需要改的呀Orz。

要求修改的內容，有一條是：

Through the whole paper the numbers and units should be put into one line for better readability.

例如，文中有一些相關的元件單位像是 25 pF，排版時25 跟pF被分到不同行了，這是當時譔寫時沒有注意到的部分；另外負數像 -5 dBm，如果用一般的hyphen 它會被分到不同行去。

當然這是不可能用手動修正的（要也可以，只是這樣很蠢），這時候我們就需要不分行空白和不分行連字號(non-breaking space, non-breaking hyphen)了，兩者在顯示上和一般的空白和連字號是一樣的，但在排版上word 不會在此字元換行，插入的方法分別是：ctrl + shift + space 跟 ctrl + shift + -

或者可以在「插入->符號->特殊符號」裡面找到它們。

之後如果遇到不能換行的地方，就插入這兩個符號吧。

參考資料：
http://savethesemicolon.com/2011/05/16/two_hidden_features_in_microsoft_word/

葉問3 (有電)

2016 的第一天，閒來無事就去電影院看個葉問3，又稱log(葉闆)，人還不少，下面寫一下葉問系列的感想，大概三集葉問電影都有電。

要說評語，我只能說：三集裡面最像傳記電影的葉問電影。

先說傳記電影，首先先釐清的是，傳記電影並不是要拍一部<楚門的世界>，把該位人士從出生到死亡都拍得清清楚楚，而是取導演想要表達的主題，集中描述：比如<林肯>，只取林肯在南北戰爭最後幾年，用盡各種骯髒手段強行推動解放奴隸法案的努力；<社群網戰>只取Mark Zuckerberg 從大學輟學成立Facebook，但Facebook 站穩腳步、與對手和解的故事。

先不論導演取材角度是否偏頗，例如上面社群網戰把Zuckerberg 描述成隨意偷人點子、自我中心的技術怪人，最後只能一個人孤獨的加正妹臉書一直按F5的魯蛇，現實上Zuckerberg 真的是個技術天才，而且有理想、衝勁、太太和小孩，根本是個人生勝利組；總之傳記電影少有長篇大論，而是在約兩小時內把某人一生幾個最鮮明的印象給表現出來；倒也不是沒有鉅細靡遺的電影，我記得我看過一部拿破崙的傳記電影或是電視劇，長度高達數張DVD，連一場演說、一場戰役都要對話個幾分鐘（更有趣的是戰場上子彈飛來飛去，主角還可以這樣神色自若的對話聊天，不愧是主角威能），沉悶至極，這個就算個特例好了。

而傳記電影是否屬實？我想這是必須的，甚至已經接近<傳記>一詞的基本要求了，如上所述，電影受限於長度必須對對象的人生內容進行刪減，一如小時候看過那些被<淨化>過的偉人傳記，僅保留了真實內容，靠著刪減就能讓人有如完人，看那些傳記大概不會知道愛迪生為了攻擊對手Tesla ，使出多少黑暗手段，若連剩下的內容都不是真的，豈不是近乎詐騙？

葉問電影最糟的就是這點：它的片名打著傳記電影的名義，卻不陳述真實故事，而是虛實並陳(也許虛的多很多)，現實上葉問很可能根本沒保護過哪間小學、妻子病逝時也不在她身邊，從這點來看，葉問電影無論1, 2, 3，其實都稱不上合格的傳記電影，如果電影改叫<一拳超人-葉問>、<詠春英雄傳-葉問>可能比較像話。

說了這麼多，葉問3的電影主打葉問保護學校和財團(?)對上，大殺黑道眾多雜魚、泰拳、拳擊高手，然後為了照顧妻子放棄詠春拳正統地位，最後在片尾再次出手證明自己寶刀未老；再怎麼說，比起葉問1, 2刻意設計的<打日本人>、<打英國人>，創造不存在的對決三浦將軍、對決英國拳王，偏重娛樂效果與民族激情，這集至少去除了大部分強加上去的<民族救星>、<中國人民該團結>的概念，回歸到葉問這個人，試著描述一個重社會道義和重視愛人的武者形象，總算是部講人的電影。

但要說葉問3是部傳記電影，我想根本是笑死人，但若把它的片名和內容一比下來，葉問3搞不好還是三部裡面最<正常>，最無雜質的一部；不信的話回想一下葉問2打爆拳王後葉問說的那些話，葉問1結尾那些過場文字<葉問努力不懈，終於喚醒中國人的抵抗意識>，只會讓人感到極深的斧鑿。

至於片中那些詠春大殺各派武功，聽眾不妨一笑置之，請別太嚴肅的看待這部電影，它乘載什麼「詠春最強」、「中國武術最強」的概念只是為了娛樂效果，它連葉問真實的故事都不想顧，需要為這種片吵成一團嗎？真要說的話，真的有人看了<美國隊長>開始吵美國人戰力最強嗎？ 本質上，<葉問>電影之於詠春，可比鋼鐵擂台之於拳擊。

再怎麼說，<葉問>三部曲都只是爽片，聽聽音效創造出來的拳拳到肉，它並沒這麼認真的要好好講述真實的葉問。

至於會不會有葉問4 或稱log(葉閘)，就靜待電影公司要不要玩了。
拍了這麼多部難道不會無聊嗎？當然不會，你看蜘蛛人都出幾部，還可以重開機再來一遍，Uncle Ben 死了幾次了XD

* 相關電影：
林肯：https://en.wikipedia.org/wiki/Lincoln_(2012_film)
社群網戰：https://en.wikipedia.org/wiki/The_Social_Network

雜湊、訊息鑑別碼與簽章

最近剛翻完Understanding Cryptography這本書，內容真的是淺顯易懂，每章的最後也都會附上相關的參考跟深入研究可讀的參考資料，是本適合當入門的好書，看完之後，想通了雜湊、訊息鑑別碼與簽章三者的差別，在這裡筆記一下，這三個對應的英文分別是 Hash, Message Authentication Code (MAC) 和 Signature，都是訊息傳遞時，用來檢查訊息內容有無「問題」的演算法，三者相似但有些許不同，主要是要對付的問題不一樣。

當我們要傳送一大筆資料時，我們必須要驗證傳送的正確性，沒有錯誤或遭人修改，最基本的就是使用Hash 雜湊，概念就是把傳送端的資料攪一攪，吐出一段代表這份資料的值，接收端再把收到的資料攪一攪，看看出來的值是否一樣。

我們要求Hash 至少要有這些特性：
* 任意長度的輸入，固定長度的輸出
* 要快：如果傳資料要花一秒，算Hash 要十秒，有人要用嗎
* 輸入少量——即便是一個bit 的變動——也應該要讓output 完全不一樣
拿果汁機當比喻，好的果汁機要能攪拌任何輸入的食物並給你一杯新鮮可口的果汁，還要很快攪好，最後，當你攪蘋果汁時加了一些些咖哩，它也要把咖哩分子均勻散佈到每一口蘋果汁裡，打成一杯美味的咖哩蘋果汁(X

另外有Hash三個安全性的要求：
* 從輸出推不出輸入(preimage resistance)
* 給定一個輸入和它的輸出，攻擊者無法產生另一個輸入有同樣的輸出(second preimage resistance)
* 攻擊者無法產生兩個輸入有同樣的輸出(conllision resistance)

知名的Hash如md5, SHA-2，在傳檔案不希望有毀損時，用這些雜湊驗一下是不錯的檢查。

要注意的是，hash 的演算法都是公開的，所以如果有心人Oscar偽造一筆資料跟它的Hash值送給接收端，這筆資料會被誤信為真的資料，Hash 無法對付有心的第三方偽造的攻擊，要對付這種狀況就需要MAC。
MAC和hash 一樣，對一組輸入產生代表的輸出，但MAC除了Hash 的特性外，還會要求一把key，在共同擁有這把的key 的雙方，能驗證訊息完整(integrity)，也能確定訊息無法被沒有key的第三方偽造，因此MAC 有時又稱為Keyed Hash Function。
再拿果汁機當例子，共有的key 就像某種獨門配方…像金克拉吧，攪咖哩蘋果汁的時候放點金克拉進去，只有用了金克拉才能吸收土壤兩米下的氮磷鉀攪出金克拉風味咖哩蘋果汁，其他人就無法偽造出這獨特的金克拉風味。

但再進一步，MAC並不提供”不可否認性”，MAC雙方共有這把key，他們都可以產生可被驗證的MAC訊息，這就像有人可以故意打出「有杏仁味的金克拉風味咖哩蘋果汁」然後說是我打的，那我不是冤大頭？這時我們就需要簽章Signature：
簽章跟MAC差異不大，只是我們把hash value 用非對稱演算法的私錀加密過，並公布它的結果，這樣所有有公錀的人都能驗證這份資料是我簽的，卻無法偽造這份簽章；另一方面，我也無法否認這份資料是我簽的，這就是”不可否認性”，這在晶片卡、網路交易上有極大的應用。
就像攪果汁的時候，吐點口水進去，所有人都能驗我的DNA，證實是我攪的果汁；但DNA就只有我有，任何人都無法偽造。

簡而言之，如果你拿訊息過來攪一攪，那是雜湊；攪一攪的同時加上一把通常是對稱性的金錀，這變成MAC；如果產生的過程用上你的私錀，用非對稱加密演算法處理過，就成了簽章。

Star Wars ep 7 Force Awaken原力覺醒(有電)

期待已久的Star Wars ep 7 force awaken 總算上映，又正好趕上放假立馬去看，不用叫子孫燒給我了XDD

整體表現不俗，就跟Star Trek ep 11一樣，是個重開機作品，JJ Abrams 善於利用高速鏡頭，對準一個主體帶出巨大的場景，這在Star Wars上非常適得其所，把戰機間的狗戰拍得相當帥氣。
劇情是全新設計，就算ep 1-6都沒看過應該還是看得懂，也許會對角色口中Luke, Leia, Han這些人物不太熟悉，不過當他們是前輩就好，隨著劇情他們的身分會逐漸揭露，唯一從劇情了「比較」看不出來的，大概就是Darth Vadar，只有一句台詞帶過。

為了連結過去，先看過ep 4-6 還是比較容易上手，也能看出片中一些場景道具是在指什麼，或是向某個東西致敬，像我看到沙漠裡巨大的AT-AT 跟滅星者，想到ep 4-6 它們曾是讓反抗軍聞之變色、如同Borg Cube 一樣恐怖的存在，現今卻淪落在沙漠中腐朽，不禁讓人感慨輝煌一時的帝國，大概也像武器一樣祇剩過往的榮光；而新共和與絕地勢力尚未壯大，電影開頭就跟那片沙漠的拾荒者一樣，給人無限蒼涼的感受。

世界觀的部分，整片的世界觀其實很破碎，沒有太多著墨，究竟新共和跟反抗勢力的關係是啥？反抗勢力經過了這麼多年，竟然還是只有一個前線基地，拿X-wing 機群突入為主力，而沒有可跟滅星者相抗衡的主力艦隊？First Order 又是代表整個舊帝國，還是前線跟反抗勢力作戰的主力？不過這些都算是細節，忽略掉沒關係，一開始就是從邊境星域開始(就如同Tatooine 一樣XD)，可能雙方主力都鞭長莫及，所以不是劇情重點，或許隨主角一步步深入核心，這些內容會在 ep 8-9 補齊。

我覺得這部表現最讓我失望的是它的音樂，可能是被東方系列養慣的關係，現在非常注重電影主題配樂，而不只是聲光效果；以往的星戰影片產製了很多扣人心弦的音樂，開頭畫面的 Star Wars main theme，ep 5的帝國進行曲(Imperial March), ep 1的duel of fate, ep 2 across the star，六集內我評價最低的ep 3 也還有the great duel 這首，雖然混了其他配樂但還有個連音緊湊的基調。
這部我看完卻沒什麼有印象的配樂，好像都是舊配樂拿上來充場面？沒有某人某物「主題曲」的感覺，隔壁棚的star trek 也有類似的問題，ep 11 音樂我非常滿意，像Enterprising Young Men，到了ep 12 Into darkness 卻沒了，頂多是一開始的London calling，大部分場面只剩爆炸音效，少了音樂把整個場面襯出來，希望未來兩集能多加強這部分。

總評來說，這集可算是星戰的全新入門款，不但承先也啟後，幾乎所有的概念都Reset ，舊作的角色出來串場但絲豪不影響主角戲份，很簡單就能從新角色的視角，重新體會這個風靡全球的遙遠銀河。

準備好了嗎？進電影院感受Star Wars Theme 的震憾，享受最新的星戰鉅作吧。

Google App Engine 回應動態內容

文章標題是照翻原來的內文：Dynamic Image，這次試著處理聲音，發現一樣可以使用，就記錄一下，相關內容可見：
https://cloud.google.com/appengine/articles/python/serving_dynamic_images
http://www.renepedersen.com/2010/04/12/how-to-serve-images-dynamically-from-google-engines-datastore/

找一下舊文章發現上一篇類似主題竟然是七月的事：
http://yodalee.blogspot.tw/2015/07/google-app-engine-ajax-request.html
well，畢竟在陰間不好辦事，又遇到base64 decode的問題，弄了很久一直沒進度，這次放假問題解掉了，順利把資料送到後端；問題有兩個

一個是我之前把資料放在url 裡面一起送，結果base64 string 的'+'全變成space，後端python base64 module decode不出來，本來是用一種很蠢的解法，先讓資料經過data.replace(“ “, “+”)，結果deploy 的時候遇到問題二：資料放在url 裡面有長度限制，應該要放在send資料裡才對，連帶這樣也沒'+'被取代的問題，詳情寫在上面那篇文內。

資料送到後端，寫入google app engine 的ndb 資料庫，這部分請參考：
https://cloud.google.com/appengine/docs/python/ndb/
很直覺，先建一個class 把該有的資料庫項目填進去，不管影像或聲音都是ndb 的BlobProperty

class RecordFile(ndb.Model):
  content = ndb.BlobProperty(indexed=False)
  date = ndb.DateTimeProperty(auto_now_add=True)

這是prototype 的關係，只記了兩個欄位。

在upload handler裡面，就可以用put()把資料寫到資料庫裡，用Key的get可以把資料再取出來：

recordFile = RecordFile(content=decoded)
retrieveKey = recordFile.put()

要怎麼把取出來的blob 塞進html 裡面？
這裡首先要寫一個Handler負責取出資料庫裡的BlobProperty，然後把binary 直接寫出來：

class GetAudio(webapp2.RequestHandler):
  def get(self):
    recordFile = retrieveKey.get()
    if recordFile.content:
      self.response.headers['Content-Type'] = 'audio/wav'
      self.response.write(recordFile.content)

再來我們要把跟圖片/聲音的request 都轉給這個handler，這裡我是假定跟/wav有關的url 都轉給它，在handler register加上這行：

app = webapp2.WSGIApplication([
('/wav', GetAudio),
], debug=True)

最後我們就能在圖片/聲音 tag 的src後面，直接寫上/wav, /img之類的網址：

<audio controls>
  <source src="/wav?key=XXX” type="audio/wav">
  Your browser does not support the audio element
</audio>

我這裡當然不是真的寫XXX，實際上的做法是{{ key }}，再用JINJA2的render把資料塞進去，一樣的方法也適用圖片上，寫個/img 的handler 並把image 的blog 寫回去即可。