2014年11月22日 星期六

JavaScript 基本資料型態

資料型態決定了以什麼方式呈現這個資料,大致上有字元(文字)、數字與邏輯值三種型式。

JavaScript屬於弱型別,也就是在宣告變數時不必特定指定資料型態,變數具體的資料型態會根據變數的具體內容推算出來,並且能隨著內容改變更改型態。


資料匿名化

資料匿名化是什麼?


簡單來說,就是對一份資料做匿名處理,使別人猜不透裡頭誰是誰。常看到公布名單時,上頭的名字是王**、alie*******等等,這類都是已經匿名化的資料。

那為什麼需要匿名資料

如何引入JavaScript程式碼

要將Javascript套用到HTML文件中,我們可以使用2種方法:
  • 利用<script>標籤
  • 使用HTML的事件屬性 
 

 

利用HTML中的Script標籤

  • <script>的屬性:
  • language:指定程式語言的版本,預設值為JavaScript
  • type:標示插入的腳本程式碼型別
  • src:用於將外部的.js 檔引入至當前文檔中,如果與HTML文檔在不同目錄,要另外指定位置
透過script標籤,我們能達成兩個方法:
在HTML文檔中利用<script></script>來封裝JavaScript: 
<script>...JavaScript Code...</script>
利用<script>的src屬性,將.js檔嵌入:
<script type="text/javascript" src="檔案名稱.js"></script>

利用HTML中的事件屬性


HTML文檔中可以設置事件處理器,我們能透過HTML元素中的某些屬性來啟動一個腳本,這些屬性稱為事件屬性。比如說有這麼一段程式碼被包裝在<script>中:
function Click()
{
    alert("Clicked");
}
我們能透過設置HTML的事件屬性反應使用者的操作,就像這樣
<input type="button" value="Click" onclick="Click()">
當這個按鈕被按下時,onclick便會調用JavaScrpit函式Click,跳出訊息Clicked!  
而在將程式碼插入至文檔前,我們還需要面對兩個問題:
  • 1.<script>該在哪裡插入?  
可以放在<head></head>之間或<body></body>之間,混著放也是可行的,差別在於:
<head>中的程式碼,在頁面載入時就會執行完畢。
<body>中的程式碼,只有對應的函式被調用時才開始執行。 


  • 2.處理不支援JavaScript的情況:
可以將程式碼包裝在<!-- -->當中,如果瀏覽器不支援JS便會自動跳過,比如
<script>
<!--
     Code
-->
</script>
或是利用<noscript>標籤,當腳本程式碼不被支援時,會在HTML頁面顯示提示資訊。


2014年11月21日 星期五

Ezgo project Meeting 1

這次是針對字音字形學習網的排版,除了打算用Html5改寫,也希望達成響應式網頁設計。

響應式網頁設計Responsive web design - RWD

能讓網頁隨著啟動裝置自動調整版面,換句話說,電腦有電腦的版面,手機有手機的版面,平板也有平板的版面,不用再針對裝置分別設計網站囉,RWD的思維在於響應解析度,隨著解析度的不同,網站的元件會流動至合適的位置,比如原本一行兩列的大按鈕,隨著解析度提高,按鈕會越變越大,當提高到目前的顯示裝置一行容不下兩個按鈕時,第二個按鈕會流動到下一行,變成兩行一列的按鈕。

這方面決定採用12欄的網格佈局達成,引入了bootstrap協助操作,目前預計完成四個頁面,配合AJAX後大略的規劃長得像這樣:




2014年11月20日 星期四

OpenStreetMap

講者:李昕迪 mcdlee


  • 想像自己是一個地圖廠商老闆
    • 收集一個城市或國家的資料,應當耗費多少資源?
    • 自己又要花費多少的比例,在收集這些資料
      • 多久更新一份資料?
      • 多久能處理一份Bug?
  • OpenStreeMap (中譯為開放街圖)
2004年由Steve Coast成立,具備Open Source與Wikipedia的精神,屬於開放授權(ODbl)且開放格式(對外交換為xml),只要有標註來源,就可以自由的複製、散布、傳輸與修改。

OpenStreetMap包含了森羅萬象的地理資料庫,如路網、地名、設施、速限、甚至連路燈、涼亭、店家開門時間等等都有標註,也可挑選其中幾個屬性作為其他地圖的底圖使用,比如素食地圖、WheelmapFOURSQUAREOpenHistoricalMap(歷史地圖數位化)等等。
  • Mapper(圖客)
開放街圖的貢獻者,帶著GPS的tracker,或透過Field Papers印製地圖,實地走訪在圖上描點,紀錄完資訊後上傳至開放街圖。
  • WikiStyle
    • 可能發生悲劇(惡意修改),但紀錄有跡可循
    • 半成品是可接受的,因為每個人都可以編輯


2014年11月15日 星期六

訊息鑑別技術

Message Authentication



每說到文件識別技術,我們通常關心三件事:
  • 送出的訊息是否完整且正確 (protect integrity)
    • 你不會希望在匯款時多送了幾個 0
  • 發訊人的身分是不是正確的 (validate identity)
    • 防止有人假冒你幹些雞鳴狗盜的勾當
  • 發訊人不可否認曾做過的事 (Non-repudiation)
    • 沒辦法切割幹過的壞事
要實踐訊息鑑別,有兩個簡單的方法:
  • CBC - residue , CMAC(Cipher-based MAC):在區塊加密時進行鑑別
  • HMAC :另外用個雜湊函式(Hash) 進行鑑別

什麼是MAC

是Message Authentication code的縮寫,它是文件經過某些演算法(MAC algorith)產生的,能夠擷取出文件訊息,從加解密的而言,我們可以把它當成一個Checksum,用其進行完整性或身分檢查。


要使用MAC,傳送方跟接受方需要共享一把鑰匙,這可以視為MAC演算法的一個參數。每當傳送方發送文件時,會經由演算法送出MAC,並附在文件中,接收方在收到文件後,會對收到的文件再做一次演算,如果兩方得出的MAC是相同的,可以假定這份文件沒被修改過。

CBC - Residue 

使用了2把Key,一把用於進行CBC模式,一把用於產生MAC(Residue)。CBC - Residue在加密過程幾乎沒有改變,唯一的不同是在最後的明文Pn的加密,他分成兩個部份,我們把Pn和密文Cn-1做XOR產生的東東叫做Xn好了,一是Xn用Key1加密產生最後一份密文Cn,二是Xn用Key2加密產生一個渣渣,這個渣渣跟密文一點關係都沒有,我們把他當做一個校正碼。因為CBC特有的雪崩效應,使得先前的加密有ㄧ些小改變就會造成後續一連串的錯誤,所以我們才能把這個渣渣用做比對。

HMAC

1.什麼是 Hash ?

Hash是一個單向函式,假設有一個Hash函式H,H(X) = A, 你無法透過A得到X,從加解密而言,Hash做到的只有加密,而沒辦法解密,因此Hash只會用來做驗證及比較。

2.HMAC

道理很簡單,我們有相同鑰匙,相同算法,那麼對相同明文,Hash出來的東西就該相同。

Authenticated Encryption

加密做的是:保證資料的安全
驗證做的是:保證資料的完整

而雙管齊下就是Authenticated encryption,直觀來看有這幾種型式:

但是他們都有一個缺點,就是對於N個區塊而言,他們往往要進行2N次的處理。為了解決這個問題,出現了IAPM與OCB這兩種新模式。

IAPM


S0~SM是用做擾亂資料,因為這是個近似ECB的模式。Sigma P 是由P1XorP2...XorPm-1得出的,Cm即為產生的校正碼。

OCB (Offset codebook Mode)


OCB參考資料
Checksum = M1 ⊕…⊕ Mn

你不可不知的JavaScript

原文:You don't know JavaScript but you should



這是我參與Kyle Simpson會談時記錄的部分抄本,他是名來自奧斯丁的開放網路提倡者,同時也身兼作家、講師、工作指導、開源軟體的贊助者等多種身份,最重要的是,他熱衷於與Javascript相關的一切。

感謝各位這次的邀請,我是凱爾·辛普森,暱稱getify,目前活躍於TwitterGithub、及這些地方。就在上週末,我受邀於Thought@Work在羅切斯特主持了場研討會,並在討論New Media Interactive Development這個專案時,發現自己陷於JavaScript和Node的類別囹圄中,所以再次感謝各位邀請我來,讓我有重新審視JS的機會。

我曾寫過幾本關於JavaScript的系列書You Don't Know JS,全冊都開放在GitHub 供免費閱讀。它們也有經歐萊禮正式出版,但目前市面上只有兩冊,第三冊正在進行最後的修訂,第四冊已近乎完成,而第五冊將在不久後著手編修。

  1. Scope & Closures:主要在探討閉包,它是Javascript中最重要的基本議題,每個JS的程式都涉及閉包,但是大部分的開發者都不曉得它們正在使用它,或不了解什麼機制呼叫了閉包及其運作原理。
  2.  this & Object Prototypes:將探討 this 這個奧妙的關鍵字,並且解決JS中的一個錯誤的迷思一一JS有類別。事實上,JS有的只是原型的指派,我們應當正視它,而非去嘗試不切實際的類別導向。
  3. Types & Grammar:我們將專注在變數的強制轉型,儘管多數開發者把它當成糟糕的機制,但我鼓勵各位深入鑽研它。因為強制轉型並不如你所聽到的那麼詭異,而且如果你運用得當,它能大幅改善你的編碼。
  4. Async & Performance (編寫中) :我們首先會解釋為何回呼函式不適用於非同步程式,並深入於改善非同步模式下的promise與generators,當然也囊括了優化與評估JavaScript效能的部分。
  5. ES6 & Beyond (預定編寫): 涵蓋了JS在ES6的所有改變,以及ES6後即將迎來的各種革新
如果想洞悉這系列的精神,不妨和道格拉斯·克羅克福特JavaScript: The Good Parts做個比較。這本書對我們社群有好有壞,他就像名領航人,近乎獨力地把開發者帶至(或拉回)JS,並使JS獲得了高度的重視,在這方面,我們欠他一份大恩。但是他也灌輸了開發者一些錯誤的思想,那就是「在JS中,你真正當學的只有極小的一部分」,這使得大多數的開發者,甚至是有5~10年經歷的程式設計師,所理解的仍只有JavaScript的冰山一角。

而談到我寫的這系列,若與JavaScript: The Good Parts做對比,它們所論及的是「非優良部分」,要注意,這不代表他們是壞的部分,而是涵蓋了JavaScirpt完整的面向。我認為開發者不該試圖迴避困難,我鼓勵各位挑戰它並瓦解它,當各位碰上了JS中令你困惑費解的語法,比起埋怨語言本身,更當去思索自己究竟遺漏了什麼,並進一步徹底鑽研。

我想這種思維對JS開發者顯得有些微妙,因為在他們的認知中,JS應該是一個既簡單又直覺,甚至是能夠一望而知的程式語言,如果JS達不到這些要求,那一定是語言本身出了什麼問題。其實,期望任何一種語言(如C++、Java)在規則上不言而喻,本身就是不合理的要求。所以當你碰著了不懂的程式碼,別去苛責語言設計者或寫這段程式碼的人,而是要趕緊補足自己缺失的部分。許多時候,開發者討厭JS的一些功能,只由於不理解,而在我向他們解釋運作原理後,他們漸漸從厭惡轉為接受,補充一下,接受可不一定等於喜歡,只意味他們肯正視這些功能而已。

在我看來,欲確實駕馭JS,精神與時間的投資必不可少,除了瞭解怎麼去寫,更該瞭解JS做了什麼?乃至JS為什麼要這麼做?我之所以鼓勵各位在學時就該精熟JS,是因我身為一名JS的教員,曾和一群用錯誤方式學習JS的工程師共事過,為了重新起步,他們無不投入了莫大心力,如果各位在學期間就真正理解了JS,進入產業後,除了不重蹈覆轍,更能明白JS的規範在當今網路平台何其重要。

在未來,JS將是鞏固網路平台的堅實地基,為此,我們更當熟悉它,並且掌握它。

最後,我想傳達給各位一件事‧我堅信,各位在課程上必定能學到不少好東西,但是更重要的是,要趁現在掌握學習的方法,以及享受學習的過程。在你這輩子裡,不可能只需精通一件事。科技日新月異,業界主流一代換過一代。如果沒別人出頭的話,我想現在是蘋果當道。無論你的興趣何在,唯有永不止歇的學習,才是成功的不二法門。

Q&A

Q:這五本書有特定的閱讀順序嗎?
A:Scope and Closures應該算是必修,按照出版順序閱讀是OK的。前三冊鎖定在JS的核心,雖然四五冊是建立在前三冊之上,但它們主要是探討ES6上的改變。

Q:免費的開源軟體對你的工作有多重要?
A:我工作上的一切都來自開源軟體,我堅信它的影響力,在不久的將來,開源軟體將使我的事業更上層樓。如果你對科技的發展史有些研究,會發現雖然技術總起於私有,但幾經調適後,最終都會走向開放,而且我認為,起於開放將漸漸成為一種趨勢。或許不少人會說:「我不想把我的程式碼公開,我怕別人會取笑我蹩腳的技術。」不過我先前嘗試時,別人是這麼說的:「你該更有自信些,因為你的程式寫的真好。」但你若看看那份程式碼,會發現裡頭充斥著不少糟糕的設計。You Don't Know JS的You其實是個集合名詞,就連我也不敢說我了解他。

我寫的每份專案都是起源於空白文件,我會把他們公開在GitHub,並盡全力持續更新它。這麼做並非要行銷理念或設計,我假定我寫的每行程式碼都是最糟糕的,而唯一能改進的方法就是借助他人。開源軟體超越了任何獨力開發,因為它是集眾人之力協做而成。

各位應當投身於開源文化中,我堅信開放是一切技術的起源,也是我們事業能延續10年的首要原因。

Q:像我這種怕把自己程式碼公開的人,應該從哪裏參與起?
A:這有很多答案,就我而言,加入別人的專案是個不錯的選擇。許多自由及開放原始軟體(FOSS)上的貢獻不是來自編程,而是來專案文件的編修與更新,如果你能夠在文件上添加一些註釋、細節或測試結果,乃至回傳一份錯誤訊息給開發團隊,這都是對社群的巨大貢獻。而要揪出這些小bug,已經有不少廣為人知的方法,並不需要透過編程去處理他們。其實,不少FOSS界的巨星都是從寫文件起頭的,一個專案要成功,實際上就只是比別人多做一點點,編程是很重要,但留下文件能傳承這份專案,而且你透過親身參與,也能更了解一份專案到底是怎麼運作的,所以我建議新手由此入門。

Q:那有什麼參與的管道嗎?
A:通常是選擇Github,當然,其他社群也不錯。然後,我不會叫你去選某個專案,因為你該選的是你「自己感興趣」的專案,比如你想做資料可視化,那就試試D3。找出你的熱情所在,這不但助於快速建立自信,同時也是優化程式的良性循環。

Q:你曾說JS將是我們這輩子唯一會用的網路語言,先聲明一下,我並不是Dart或類似語言的支持者,但你怎麼不覺得他們會成功?
A:真是個有內涵的好問題, 不過Dart無法取代JS,並不是Dart設計的不好,而是在Google的態度。先看看Google在網站上怎麼說,他們把Dart定位成JS的死對頭,期望有朝一日能取代JS,而非僅只實驗性的影響JS發展。不過從Dart外洩的紀錄得知了一件事:「Dart無法修正JS的根本性瑕疵。」,無論是在Chrome中與JS分庭抗禮的虛擬機Dartium,或是在語言轉議器Dart2JS裡,Dart都做不到。這訊息相當耐人尋味,Google似乎不是想做的比JS更好,而是認為在開發者生來就選Dart的前提下,JS將逐步衰退。但我能肯定一件事,Mozilla絕對不會在Firefox中實做Dart。如果Dart真要取代JS,那得等到Firefox消失,不過我想像不出這種情形。

宏觀來看,有數以百計的語言能編譯為JS,如果你想在網頁上執行你的程式碼,可以把它轉譯為JS。 雖然我個人不怎麼喜歡那些語言,但它們確實很重要!源碼不是給電腦看的,而是給開發者看的,處理與演算的手段如恆河沙數,開發者要在這些手段中,找出一個最符合自己思考模式的。為此,我們還需JS的轉譯上做更多試驗,就像CoffeeScript,他使ES6如虎添翼。我想未來CoffeeScript能做的已經很有限了,但不要緊,它已是JS革新的重要推手。至於Typescript,雖然我不怎麼喜歡類別,但Eich在報告中提到,它未來將改為近似JS的宣告方式。

先學好JS,儘管你仍將接觸其他語言,並發現在某些情形它們做的比JS好,或對你的團隊更有利。很多人就因為這樣而不學JS,但我認為不該這麼做,學會JS不僅對自己有利,也能將你喜歡的語言轉譯為JS。這促成了網路平台的美好未來。


2014年11月13日 星期四

軟體的國際化與在地化

自由軟體開發與社群發展

講者:FrankLin


INDEX Topic 1.自由軟體的國際化與在地化
Topic 2.Ezgo打包的技術初窺探

講者介紹:
Franklin,在社群中被稱為馬哥,大一開始玩Linux,但真正栽入Linux與OOS是在念研究所時。出社會後都在做RD,現在則是以OSS為業的浪人。
2006年起,擔任KDE中文化團隊的協調人。

Topic 1.自由軟體的國際化與在地化


 Ezgo是推廣自由軟體用的一個系統,既然要推廣,中文化就是個相當重要的部分。
  • 國際化與在地化
過去的軟體,光是要能顯示中文,就要處理很多事情,如訊息的顯示、字型(px上的設定,同時涉及了自行的解析度)、編碼問題,使得在過去中文版的推出,即是一件大事。

而除了訊息,還可能會涉及當地的觀念,像是:
  • 數字表示法
例如在歐洲大多數的國家,1.000是一千,1,000才代表1,假設今天有一個德國的會計軟體,台灣中文化就得做內部的修改。
  • 年份的表示法
  • 日期的表示法
  • 金錢的表示法
  • 度量衡系統
這些都是在軟體在地化時要做的處理。

而現在,為了在同款軟體賣給不同國家時不大量修改,軟體公司提出簡單多國語言化概念。

原始程式→將訊息抽取出來編索引,存成一個檔案→將該檔的內容翻成不同語言
(原始程式在設計時就該有能檢視索引的機制)
因為訊息已經抽出來了,所以只要針對訊息獨立處理,不必修改原始程式。

Linux 上的中文化始祖 - CLE


Chinese Linux Extension - Linux 中文延伸套件
延伸:修改程式內容,重新編譯打包,以加入中文支援

CLE團隊也知道,光是修改打包只治標而不治本,因此積極與原始Linux團隊合作,期望加入國際化軟體的架構。
包刮 Linux ,  glibc , QT, KDE ,Gnome......都從收過CLE團隊的修改。

所謂國際化,即是將軟體與特定地區及語言脫鉤的過程,當移植時,不必做內部工程上的大量改變或修正。而在地化便是延續國際化的架構,建立某個地區文化的資料庫,填入該地區文化的資料,供程式在執行期呈現。

Gettext


關於自由軟體的國際化,主要是靠著Gettext這套軟體進行,Gettext只是套工具,他利用對訊息的包裝,可以將訊息抽取出來集中在一個 .pot 檔,翻譯者只需要拿pot翻譯成不同語言,並各別存成po檔即可,而開發者會將po檔編索引成為mo檔。

po檔分為檔頭與條目:

  • 檔頭存放的是po檔與其相對的pot檔的相關資訊,包括產生時間、最後翻譯者,還有複數型的定義 (plural - form)。
  • 條目則分為旗標與註解(區別相同訊息但不同意義,e.g: left : leave過去式? 左? )

翻譯工具簡介


  • 翻譯資料庫
  • Launchpad、pootle、transifex、tryneeds等線上共筆的翻譯平台

Ezgo打包技術初窺探


  • What is ezgo
    • 能夠讓從未接觸過OSS的人,接觸OSS並使用它 → 推廣
  • 推廣
    • 目標客群:從未用過OSS的人
    • Ezgo該有哪些特色?
      • 選單
      • 操作設計上貼近Windows思維
  • 從技術面而言
    • 屬於客製化的distribution
      • 有自己的品牌,卻不是一個獨立的distribution
    • Dirty hack產生的問題
      • 沒有組織,東西太零散
      • 版本一多不易管理
      • 不符合Debian規範,無法上傳
    • 目前的做法
      • 儘可能遵循標準機制,並自動化
      • 儘可能採用外加設定檔的方式,不覆蓋現有檔案
  • Debian - ezgo
    • Debian:套件的老祖宗
    • 遵循Debian規範,將常用重複的檔案與設定等等包裝成deb檔

古典密碼學

索引 #1.加密工具
  • 密碼棒
  • 卡爾達諾漏格板
  • 旋轉機
  • 一次性密碼本
#2.加密算法
  • 凱撒密碼
  • 希爾密碼
  • 路由加密
  • 單字母替換密碼
  • 維吉尼雅密碼
#3.攻擊類型 
  • 僅知密文攻擊
  • 已知明文攻擊
  • 選擇明文攻擊

加密工具 #1.密碼棒
取布條將其纏繞於木棒上,橫向寫下明文後取下布條。解密時,必須取得相同直徑的木棒。

#2.卡爾達諾漏格板


依照漏格書寫明文以及觀看明文。

#3.旋轉機(Rotar machine)


#4.一次性密碼本

藉由亂數產生的一本加密用密碼本,可以把它想成一組金鑰,每當要產生明文時,將明文與密碼本的內容相加,如明文中的字母C (3)與密碼本的字母 X (25),3+25=28,因為28超過了26個英文字母,而對28取餘數得2,即得加密完成的密文字母B。
一次性密碼本有三個限制:
  • 確定密碼本是由隨機產生的
  • 密碼本必須只能使用一次
  • 因為要與明文相加,密碼本至少要與明文一樣長

加密算法 #1.凱撒密碼

已知明文字母P,引入一個參數K,得出密文 C = (P + K)mod 26
例如 ABCDEFGHIJK,在K=3時,得出密文DEFGHIJKLMN。(K=3是最初的凱撒密碼)
解密時 P = (C - K)mod 26。

因其架構簡單,現今已能用暴力法輕易破解,故只用於字謎類遊戲(ROT-13)。

#2.希爾密碼

使用矩陣進行加密,由密文構成的密文矩陣C = KP,其中P為明文構成的明文矩陣,K為密鑰矩陣,密鑰矩陣須為可逆才可供解密。


 
希爾加密避開了頻率分析攻擊,然而在已知明文的情況下,可透過逆運算求得金鑰,無法保證安全性。

#3.路由加密

近似於密碼棒,採用直書橫寫進行加密。

#4.單字母替換密碼

與凱撒密碼同為單字母取代的概念。將26個英文字母分別做對應,比如A對應C,B對應F,替換不受限於特定規則,也不要求有跡可循,純粹是做出26個字母的明文密文對應表,以供加密與解密時使用。儘管其複雜度遠遠高於凱撒密碼,但明文字母與密文字母仍屬一對一對應,同樣易受頻率分析(分析字母出現的頻率)攻擊破解。

#5.維吉尼雅密碼


上圖其實是由26個凱薩密碼構成的。
維吉尼雅密碼引入了金鑰的概念,假設要加密ABCDEFG,使用密鑰CIP。首先,先將密鑰長度補至和明文一樣長:

ABCDEFG
CIPCIPC

接下來,取第A行第C列得A,取第B行第I列得J...取第G行第C列得I,如此完成加密。在配合一次性密碼本的情況下,維吉尼亞密碼是足夠安全的。
攻擊類型#1.僅知密文攻擊:攻擊者在只知道密文的情況下試圖求得明文或金鑰。

#2.已知明文攻擊:攻擊者在知道部分明文與密文配對的情況下試圖破解。

#3.選擇明文攻擊:公開加密器,攻擊者可以自由輸入明文及得到該明文的密文,藉此試圖破解算法。

儘管選擇明文攻擊於設計角度上看似不合理,但在近代密碼學中,十分強調在公開演算法的情況下,還能保證安全的才是優秀的演算法,這是為了避免開發者本身預先對算法預先留下了暗門,卻因為算法黑箱而無法得知,使得維護者或開發者成為最危險的攻擊者,因此必須公開算法接受檢視。

2014年11月10日 星期一

在地社群使Firefox行動版登陸印度

Firefox for mobile,開發代號Fennec,是Firefox建構於行動裝置(平板電腦,智慧型手機)上的網頁瀏覽器。Fennec內建了多種語系,而就在數月前,Fennec新增了 Assamese, Bengali (India), Gujarati, Kannada, Maithili, Malayalam, Marathi, Oriya, Punjabi, Tamil, and Telugu 十二種印地文。

在最新釋出的版本中,這12種印地語占了新植入語言的大多數,為此,印度社群舉辦了一個小型的聚會,慶祝與宣傳這引盼已久的成就。約莫30名志工與自由軟體的愛好者參與了Moilzia在浦那的活動。Mahesh Kulkarni,是語言技術的權威,同時也身為C-DAC GIST group的首長與 W3C India駐印經理,由他負責切下Fennec蛋糕的第一刀,為這起盛事揭開序幕。

Mahesh Kulkarni在會席上分享了他的經驗,他認為社群中端與端間的在地化經驗是必要的,而不僅只於裝飾性質。於在地化的領域,只有第一等的工作仍持續至今,而現在這是著手於第二等工作的時刻。與會的社群有些來自Mozilla Hindi Team,涉及Mozilla的在地化工程,有些則是Pune Linux User Group (PLUG)的成員,還有不少活躍於Mozilla各領域的社群,他們一同研討了當前翻譯上的討戰,以及籌畫實質策略以改善現狀。

這些來自世界各地的志願團體,都是被一份初衷所吸引:可以為講者提供配有當地語言的軟體,並幫助他們用自己的語言瞭解網路與瀏覽器。這份在地化的熱情及同行評審制往往產了比付費業者還優質的翻譯軟體。這些在地化的細節都紀錄在 the Mozilla Wiki上。

有許多用戶只理解當地語言,所以不論是網站的內容或是界面都須在地化,以讓更多用戶受益,Mozilla將持續促進網頁上的語言革新,以迎合這些使用者們

Mozilla的在地化工程首重民主的原則 ── 民有、民治、民享,搭配上熱情與優良的作業流程。舉例來說,Mozilla的德國化起於一個簡單而微小的點 ── 一個大學生打算完成Firefox的德國版本做為給他父親的禮物,由於Firefo的原碼開放,他有能力完成這份願望。同樣的,在十幾年前我加入Red Hat印度語團隊,並開始投身在各個開源專案,現在我以相當熟悉Mozilla的在地化工作,並參與了Mozilla印度語翻譯團隊。

時至今日,大多Mozilla的產品都完成了翻譯,在地化工程於Pootle platform上平穩的進行著。Fennec的印度版也藉由協做完成了翻譯及測試,儘管如此,我們仍歡迎更多的志工朋友們加入。


2014年11月9日 星期日

Network Security issues

  • Network Security Basis
    • Confidentiality
      • 維持資料的完整性
    • Integrity
      • 確認資料是否有被修改
    • Authentication
      • 建立使用者身份的認證
    • Non - repudiation
      • 防止使用者否認其曾做過的行為
    • Access Control
      • 管制使用資料的使用權限
    • Availability
      • 隨時保持資料的可用性
  • Protocol
    • 網路傳輸的協定:HTTP/FTP......
    • 資訊安全的協定:SSL,IPSec,Kerberos......
  • Ideal Security Protocol
    • 滿足安全需求
    • 效率高
      • 運算量少、延遲短
    • 健壯性
    • 容易使用與實作且應用彈性高
  • Secure Entry to NSA
    • Insert badge into reader
    • Enter Pin
    • Correct Pin?
      • Yes : Enter
      • No : get shot by security guard

Authentication Protocol

  • mutual authentication
    • 假設現在有兩個使用者Alice和Bob (可以為人或電腦)
      • Alice必須要向Bob證明她的身份是Alice
      • 同樣的,Bob需要向Alice證明他的身份是Bob
      • 因為雙方都要驗證自己的身份,而稱為mutual authentication
    • 過程可能需要建立對稱金鑰,作為辨別的基準
    • 雙向認證的必要性
      • 以往都只有系統認證人
      • 但人遇上假的系統 → 資料外流
  •  Challenge-Response mode
    • 為了避免重放攻擊,使用challenge-Responce
    • 當認證時,使用只有Alice本人才能進行的認證
    • e.g.
      • Bob為了確認Alice的身份,Bob送出一個Nonce給Alice,Nonce就是個Challenge
      • Alice對 Alice's password跟Nonce進行一次雜湊
        • 因為只有Alice跟Bob知道Alice's password,所以可避免重放攻擊
      • 若Bob進行雜湊的結果與Alice一樣,就能確認Alice的身份
  • Authentication : Symmetric Key
    • Alice和Bob共享一把對稱金鑰
    • 只有Alice和Bob知道這把金鑰
      • 為了認證Alice的身份,Bob會傳送一個Nonce,給Alice
      • Alice對Nonce進行加密 E= (Nonce,key),傳送E給Bob
      • 上述只完成了Bob對Alice的認證
    • 那麼如何完成雙向認證呢?
      • Alice先送Ra給Bob
      • Bob送回Rb跟E(Ra,key)給Alice
        • Alice可透過解密知道是否為Ra
      • Alice送出E(Rb,k)給Bob
        • Bob可透過解密知道是否為Rb
    • 然而,這會產生一個問題
      • 分成兩次的嘗試
      • 第一次,攻擊者可以透過送出Ra得到Rb跟E(Ra,k)
      • 第二次,攻擊者送出Rb,得到E(Rb,k)
      • 那麼就可以在第一次嘗試中送回E(Rb,k) 
  •  

2014年11月6日 星期四

Ezgo

Ezgo

Speaker : Eric


Ezgo開源教材分享
  • Stellarium
    • 可以描繪星體的軌跡
  • MuseScore
    • 可繪製五線譜,快速調整譜面
    • 可隨音符演奏音樂
    • 配有音樂社群,分享音樂創作
  • Hydrogen
    • 節奏編曲軟體
    • 配有各種音源,操作容易
  • Fritzing
    • 備有虛擬麵包板與圖像化電路,可以用於電路設計上的教學

2014年11月4日 星期二

C4 Labs Course 4

#1. Makefile


  • makefile REF
    • Makefile學習筆記
  • 平常的編譯方式
    • gcc file.c -o file
    • make file.o -> make file
  • makefile :很多個檔案要做編譯,彼此之間有相依性,所以寫一個腳本來完成所有的編譯動作
PROJECT = test
OBJS = a.o b.o c.o //物件檔當成三個字串

all: $(PROJECT)
$(PROJECT): $(OBJS)
...編譯指令...
  • 檢查include的標頭檔是否有被改過
    • 知道誰被改過,又有誰用到它
  • 建立一個描述相依性的檔案,然後將其include到makefile中
    • command line指令:-MF
      •  產生出一個.d檔,說明完成這個.o檔需要哪些.h檔
  • 引入一個目錄內所有檔案:wildcard
    • wildcard會展開目錄內的檔案

#2.Arch Linux


2014年11月1日 星期六

MOPCON 2014 會後會

 

MOPCON 2014 議程紀錄


這次是MOPCON會後會,主要在分享ㄧ些參加心得和揭露祕辛,所以不會跟議程直接相關唷。

第一次摸去IRSlab,空間比想像中的要大些,席間有提供飲料跟小點心,是個蠻愜意社群環境。分享人是MOPCON贊助組的成員,提及了一些MOPCON內部的分工,研討會的初衷與贊助者的立場等等。

對於贊助商而言,贊助的目的無非是推銷自身的產品,不過今年有些小悲劇,因為會眾有約40%是學生,所以有些產品不怎麼迎合需求,為了拯救贊助商,只好把MOPCON的店面移到贊助商旁邊,希望幫忙挽回一點人氣~算是會議的小插曲吧。

不光是產品推銷,這次的MOPCON也成為獵人頭的手段。分享人提到,這類大型開發者聚會往往是找人才的管道,因為會來參加聚會的,通常也都是對這領域略有了解的人,不妨藉此管道找尋真正適合的人才,比起104的模糊篩選好太多了。

但是這也引發了一個問題,一個堅持在濁水溪以南舉辦的研討會,來的贊助商卻多是北部的,講者也是北下而來,而會眾族群又多是學生,這會不會把南部的資訊人才又往北拉?反而是違背了研討會的初衷。這個問題討論了整整一個小時,直到蘇教授出來Demo自製咖啡機,工作人員是認為,能把北部的資源拿來南部用,這對研討會而言是件好事,而人才流失的問題,這並不是一時半刻就能解決的,MOPCON 至今也才辦了三屆,還不算個成熟的研討會,就先放眼當下,想辦法促進南部的素質吧。