Login  |  Sign up  |  繁體中文
News

News

今天來到臺灣科技大學採訪鄧惟中老師。他們團隊的專案是研究時脈偏移,「時脈偏移」(clock skew),也有人稱為時鐘偏斜。理想上,電路系統中的各部位的時鐘訊號應該保持同步,以確保整個系統的工作可以同步,但實際上訊號在傳遞的過程中會有些許的誤差,有可能是因為硬體設備的材料、連線長度、或是溫度…等等原因所造成,這樣的誤差就稱為時脈偏移。他們利用這樣的偏移發展出新的應用,現在就來看看他們是如何應用的吧!

人的一天幾乎有三分之一的時間在睡覺,但現代人時常卻時常因為睡眠問題而困擾!回想一下自己最近的睡眠狀況,你是否遇過無法入睡、睡到一半忽然驚醒、或是醒得太早?偶一為之對身體影響不大,但是若長期處在睡眠不足或睡眠品質低落的狀態,則可能對身心造成影響。這時候也許該求助醫師檢查自己是否有睡眠障礙,但專業的睡眠檢測與治療資源有限,在醫師的檢查之外,如果能輔以居家追蹤,不但能讓個人對自己的睡眠狀況更為了解,也可以協助專業醫療更有效的觀察與診斷。輔仁大學的團隊針對這個需求開發了「基於 HTML5 的跨行動平台響應式睡眠節律服務」,針對三大問題提出解決方案:(1) 睡眠紀錄裝置眾多,但是不一定有睡眠專業的認證,且呈現出來的結果對使用者來說不一定容易理解;(2) 睡眠服務在網路連線或離線狀態變更時,不能與雲端順利銜接,產生資料一致性的問題;(3) 無線行動裝置繁多,針對所有不同裝置設計開發睡眠專用 APP 工程浩大。

在進行開發的時候,遇到什麼樣的問題,又有什麼心得?我們現在就立刻來請梅興老師分享吧!
 

在資訊科學領域中,電腦字型是相當重要的一環,因為許多軟體的功能都必須依靠著電腦字型的呈現,才可以被一般使用者順暢地了解與利用,缺少了使用者可以了解的字型,這些軟體的應用範圍將大為受限。但是由於字型的特性與應用方式跟軟體程式並不相同,是自成一格的專業領域,因此相對於軟體程式碼來說,字型的授權內容較少被討論,適合用來授權字型的自由開源條款也非常稀少,也因此我們會看到有些字型是直接適用 GPL、Apache-2.0 等授權條款來釋出。不過 GPL、Apache-2.0 這些授權條款原本是以程式碼為客體所制定出來的,其中的內容並無法完全直接套用到字型的應用情況,常常必須透過專業人士的額外解釋,才能夠釐清使用者如何做才是遵守授權規則。為此,開始有組織制定出專門適用於字型的授權條款,以避免這種將程式碼授權條款應用到字型上的水土不服症狀。本文所要介紹的 SIL Open Font License(OFL,註一)就是一份專門適用於電腦字型的授權條款,OFL 承襲了自由開源的自由精神,並且針對字型的特有的應用情況來加以規範,並且提供了詳細的說明文件,因此是一份從內容本身到週邊資訊都非常完整翔實的字型授權條款。
程式源碼 (Source Code) 與目的碼(Object Code,註一)是軟體程式存在的兩種基本型態,前者指的是電腦程式可供後續增編修改的格式,有時可被直接執行,但多半時候必須經編譯或界定程序之後才能被執行,後者則是能夠直接供電腦機器判讀的執行檔格式,但因已經過編譯程序,故除非經過反組譯或是還原工程,否則一般人無法直接觀察目的碼,來了解該電腦程式的演算過程及運算邏輯 (algorithm)。一般來說,軟體程式可以擇一或是同時透過這兩種型態來被散布,就法律論理上,其在著作權法上是被視為是同一作品不同形態的表現,故其表現形式雖不同,但法律定位完全相同。過去電腦程式目的碼是不是能受到著作權法保障是有疑慮的,畢竟這樣的著作格式並不如同一般受著作權保護的客體:詩、詞、書、畫、文章、音樂、電影般,能被直接閱讀、聆聽、感受,和了解,不過美國於 1983 年 Apple Computer, Inc. v. Franklin Computer Corp. 一案中,承審法官在反覆的論理之後,判定目的碼亦為美國著作權法保護的客體之一,同時,因其無法為人類直接了解之故,更進一步認定其與程式源碼具有同一性關係(註二)。此一判決也影響其他各國就此議題的認識,此後多數法律見解皆偏向於將程式源碼與目的碼,視為電腦程式的一體兩面,故表現的方式雖有差異,但被著作權法保護的本質與地位相同。這樣的解讀態度適用在一般私有軟體 (proprietary software) 上,固然不會有太大的問題,畢竟私有軟體在授權使用上的基本規則為「權利人保留所有權利 (all rights reserved)」,故使用他人電腦程式時,未經授權方同意的方式,基本上都是不被法律所允許的,然而,許多的自由開源軟體 (Free and Open Source Software) 專案及其授權條款,蘊含著一種盡量將程式源碼提出來讓後手使用者增刪修改並便利應用的態度,故在其授權條款中,可以看到許多的內容是明確地針對程式源碼或目的碼所作的,略有差異的義務性要求,此項特點多為一般使用者所不知或忽略,而這方面的資訊,也正是本文希望透過特定條款的例示與說明,所要傳達給大家的。

進到捷運車廂,抬頭一望可以發現幾乎「人手一機」,有的人拿著智慧型手機使用即時通訊軟體、有的人拿著平板看電視,「低頭族」的名詞也應運時代而生。當行動裝置成為最普遍的雲端服務存取裝置之一,除了便利之外,其實也悄悄地帶來一些資安風險,因此,如何提昇行動裝置的安全性便成為當前許多開發者的關注焦點。中央大學的「支援行動裝置使用者與虛擬實驗平台之雲端技術研究」計畫便是利用雲端環境進行資訊安全的研究,並將研究內容分成三個子計畫,今天 OSSF 特派員四貓很榮幸訪問到這些計畫的主持人,中央大學的梁德容、陳奕明和王尉任老師,現在就立刻帶大家一起來看看這些計畫在做些什麼有趣的事情吧!

(本文寫作於 2014 年 7 月,所有相關論述均以此時間點為準)

Mercurial 是一款分散式的版本管理軟體。

所謂版本管理軟體,是一種可在程式開發過程中,有規律地保留程式碼的歷史訊息、讓人能放心地做各種開發實驗,並在開發不幸走進死胡同時,將程式碼回復到舊有版本的系統……

細節很複雜,一言以蔽之,就是一種程式碼管理器。詳細說明網路上可以找到很多,我就不在此囉唆贅述了。

Mercurial 經常被拿來和另一款同類軟體 Git 比較,然而不知是故意貶低或缺乏了解,大部份能在網路上讀到的中文文章,都傾向於認為 Mercurial 比 Git 弱小、彈性差、功能低落,甚至只是個「教學用軟體」。但隨著我同時跨足使用這兩套系統後,我發現實況卻非如此--甚至大部份時候都是反過來的。

作者簡介:陸聲忠,國立成功大學土木工程研究所,現任職於國家高速網路與計算中心。

Linux 的特性與優點:

相較於「某知名廠商」的作業系統,Linux 具有以下的特性與優點:

1.系統比較穩定:Linux 是以 Unix 系統為根本所發展出來的作業系統,因此與其不但有相似的程式介面跟操作方式,同時也承襲其穩定與有效率的特點。有時一台 Linux 主機可連續運作一年以上都 不曾當機、也不需要關機,都是常有的事。

利用自由開源軟體元件來開發自己專案的好處在於,使用者只要能了解所取用元件的授權方式,便可以毋須重新撰寫,而逕予取用這些元件,作為新專案的基石,並在既成的成果上,據以更深入的開發自己所需要的功能!然而,由於許多自由開源軟體的授權元件,開始時多是由網路志工和社群成員自發性的投入撰寫,所以雖然開發者本身,非常願意透過某一個選定的自由開源軟體授權方式來傳遞和分享這些程式碼,但卻極可能在編撰的過程中,未能明確地標示相關程式碼的授權資訊,也或者標示的方式,隨著專案與開發者的不同而有所改變,對於不少使用者來說,找到正確的授權資訊並據以安心的利用,並不是一件容易的事情。但是在這些看似雜亂的標示中,其實仍然有一些基本規則可以依循。本文會就辨識授權資訊的基本規則加以闡釋,並針對常見的問題與標示不清的狀況加以說明,讓讀者可以大要了解,如何在茫茫的軟體程式碼與各項說明資訊中,找到特定自由開源軟體元件正確的授權資訊!

網頁開發者 (Web Developer) 一天會在瀏覽器 (browser) 裡重新整理 (refresh) 個千百次是常有的事,但這樣不只會造成開發上的中斷,也會加重雙手的負擔。

這裡凍仁將介紹 LiveReload 給大家,它是個可以在儲存檔案後自動重新整理 browser 的解決方案,LiveReload 雖然不能即時呈現,但可以讓開發環境變得友善點,是值得投資的好工具,若能搭配雙螢幕使用其效果更佳。

(註:本文的撰寫環境是以 Ubuntu 12.04 為主,若版本不同可能會有些許的不同。)

上週,中國開源軟件推進聯盟(China OSS Promotion Union, COPU,註一)發布了「COPU 開源通用許可協議 V.1.0(以下簡稱「COPU-1.0」,註二)」的草稿,整份授權條款由簡體中文撰寫而成,為全球第一份中文的自由開源授權條款,因此本期的法律專欄將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同,為了避免辭彙轉換過程無法精確表達原簡體中文的詞意,因此本文在涉及說明 COPU-1.0 草稿內容時,將優先採用草稿中的用語,還請讀者自行參照本文末所附的辭彙對照表,來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞(註三)。

在 JSConf.Asia 2013 , Lea Verou 介紹了 CSS in the 4th dimension (影片) ,引發了整個 Web 界對 CSS 動畫的期盼;在 CSS動畫簡介一文也已經把重點整理好了。

以下我們將會介紹主要兩個 CSS3 在動畫的屬性: Transition 與 Animation ,並配合實例來練習這些技術,後面我也會介紹一些不錯的相關開發工具。

為什麼需要 Code Review

要瞭解為什麼需要 code review 之前,先透過下面這張圖解釋,隨著軟體開發週期越後面的階段或經歷的時間越長,軟體修復 bug 的成本越高。

01

▲圖 1 軟體修復成本與時間關係(資料來源:https://buildsecurityin.us-cert.gov/articles/best-practices/security-testing/risk-based-and-functional-security-testing

Subscribe Newsletter

SubscribeUnsubscribe