顯示具有 software 標籤的文章。 顯示所有文章
顯示具有 software 標籤的文章。 顯示所有文章

2017-03-09

[砸七砸八] 遷移自建Docker私有庫 & 客製化公有庫Docker並納入私有庫

最近用了一些Dockerfile與docker的東西,快速筆記一下避免忘記:

[遷移自建docker registry]

  • 想自建docker registry(也就是docker image repository倉庫)自有庫,很簡單,直接到官方docker build一下就可以自建倉庫,略述。
  • 當自有庫運行一段時間,你在上面已經有了大量自建的docker image後,如果想要遷移,這時候你可以把整個registry做docker打包,然後tar起來並且壓縮,略述。
  • 接著把壓縮的registry tar用一般檔案搬移的方式mv/cp/scp/rsync到任何新的宿主機HOST上,把他解壓縮並docker run就可以繼續執行。
    • 參考指令(以下僅為範例指令,請依當下環境自行修改)。
    • #docker run -d -p 4000:5000 --restart=always --name registry-name -v 'pwd'/your-data:/var/lib/registry registry:version

  • 無網路問題,因為container共享HOST網路。

[客製化公有庫的Dockerfile & 納入私有庫]
  • 網路上很多公有庫的docker很好用,但總是需要客製化,無所謂,反正就是拿他的Dockerfile來修改。

  • 修改後重建指令
    • #docker build -t "sean/docker-image:v030901" .
  • 貼上自有庫registry認得的tag
    • #docker tag -f sean/docker-image:v030901 ${registry_ip:registry:port}/${project}/${docker-image-name}:${tag_version}
  • 上傳到自有庫方便自己使用,可以跟自己的CI/CD流程自動化串整
    • #docker push ${registry_ip:registry:port}/${project}/${docker-image-name}:${tag_version}

2016-11-04

[Selenium] How to solve org.openqa.selenium.remote.ProtocolHandshake createSession problem

    近期用 Selenium 在沒有更新任何源碼的情況,再次執行後遇到以下錯誤:


Starting ChromeDriver 2.23.409699 (49b0fa931cda1caad0ae15b7d1b68004acd05129) on port 21975
Only local connections are allowed.
十一月 04, 2016 1:55:08 下午 org.openqa.selenium.remote.ProtocolHandshake createSession
資訊: Attempting bi-dialect session, assuming Postel's Law holds true on the remote end
十一月 04, 2016 1:55:10 下午 org.openqa.selenium.remote.ProtocolHandshake createSession
資訊: Detected dialect: OSS
Exception in thread "main" org.openqa.selenium.NoSuchSessionException: no such session
  (Driver info: chromedriver=2.23.409699 (49b0fa931cda1caad0ae15b7d1b68004acd05129),platform=Windows NT 6.1.7601 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 4 milliseconds
Build info: version: '3.0.0-beta4', revision: '3169782', time: '2016-09-29 10:30:04 -0700'


    解法是要將 ChromeDriver 2.23 更新到 2.25 即可,不過這點還滿弔詭的,因為我個人並沒有更動到任何既有源碼或更新 Selenium 套件,代表 ChromeDriver 本身一定有做一些檢查,這點有空再來研究。

[額外資訊]

2016-11-03

Ubuntu安裝Java JDK 7或JDK 8

介紹於 Ubuntu 14.04 / 16.04 上安裝 Java JDK 7 / 8 的方法。

[說明]
當網路環境處於離線,或不一定直接能存取到internet仰賴proxy時,使用ppa的安裝基本會失效,乾脆到官網上下載 jdk 檔案然後直接進行設定反而是最快的做法。

[步驟]
  1. 請至官網下載JDK,我們這裡用 jdk1.8.0_111 這個版本作為示範,請自行替換版號。
  2. 建立 Ubuntu 的 jvm 目錄,指令:
    • #sudo mkdir /usr/lib/jvm
  3. 將下載的 jdk 檔案解壓縮到 jvm 目錄,指令:
    • #sudo tar -zxvf jdk-8u111-linux-x64.tar.gz -C /usr/lib/jvm
  4. 再來要將 java 預設路徑告知系統,請:
    • #sudo vim ~/.bashrc
    • 添加以下內容
    •        
      export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_111
      export JRE_HOME=${JAVA_HOME}/jre
      export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib
      export PATH=${JAVA_HOME}/bin:$PATH
      
      
    • 使環境變數生效
    • #source ~/.bashrc
  5. 然後執行以下步驟,讓 Ubuntu 認得這個版本的 JDK
    • #sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8.0_111/bin/java 300
    • #sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.8.0_111/bin/javac 300  

2016-10-29

[自動化網頁測試] 於Ubuntu使用Selenium整合Headless Firefox

這裡介紹Geb(瀏覽器自動化browser automation)的解決方案Selenium + Headless Firefox。

[環境與工具]

  • Ubuntu Server 14.04 LTS
  • JDK 1.8.0_91(注意!! jdk 1.7 Selenium 會有問題)
  • Ubuntu沒有GUI,需要使用xvfb(x window virtual framebuffer)作為headless browsergraphic render
  • Web Driver
    • firefox webdrivergeckodriver-v0.10.0
    • google chrome webdriverchromedriver_win32 / linux64
    • 請自行下載並注意執行環境平台
[xvfb & firefox]
  • 安裝指令
    • #sudo apt-get install firefox xvfb
  • 安裝過程如果缺少字型
    • #sudo apt-get update
    • #sudo apt-get install -y xorg xvfb dbus-x11 xfonts-100dpi xfonts-75dpi xfonts-cyrillic
  • 啟動xvfbgraphic render,頻道0~99任選,1280x960x16為模擬視窗大小,目前使用此值運作正常
    • #Xvfb :99 -ac -screen 0 1280x960x16
  • 擷取xvfb畫面

2016-09-10

使用Visual Studio 2015製作Cordova的Android APK(可上架至Google Play)


前些日子的文章提到,Microsoft Visual Studio 2015 針對 Mobile APP 開發相當友善,近日用其 Cordova 套件來開發,推薦大家使用;今天跟大家介紹如何使用Visual Studio 2015製作Android APP的android-release.apk,以便發佈到Google Play。

[製作keystore]

  • Cordova建置Android APP分為兩個階段,分別為Debug、Release,上架至Google Play上的APP需要開發者的金鑰簽署,以下是簽署指令
  • 使用jdk的keytool製作金鑰,一般而言放置路徑會在C:\Program Files\Java\jre1.8.0_91\bin
  •        
    #keytool -genkey -alias your-key-name.keystore -keyalg RSA -validity 20000 -keystore you-key-name.keystore
    
    

[設定keystore資訊於Cordova專案]
  • 有兩個檔案需要設定,其一是[專案] -> [res] -> [native] -> [android] -> ant.properties,請自行填入方才製作的keystore資訊

  • 其二為[專案] -> [www] -> build.json,編輯後會像是

2016-04-20

安裝與備份Gitlab教學

GitHub幾乎是所有(除了China)資訊工程師置放源碼的首選,但缺點是免費使用你必須開源自己的專案,否則必須額外付費,這時候你可以考慮安裝Gitlab作為repository。

[作業環境]
  • Ubuntu 12.04 LTS
  • Gitlab version:gitlab-ce_7.10.4
[網路環境]
  • 請注意自己的網路有通,不然記得設定proxy
  • export http_proxy=http://${ip}:${port}
  • export https_proxy=http://${ip}:${port}
[安裝步驟]
  • sudo apt-get install curl openssh-server ca-certificates postfix
  • curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
  • sudo apt-get install gitlab-ce=7.10.4~omnibus-1
  • sudo gitlab-ctl reconfigure
[Gitlab網頁設定]
  • 把自己的IP替換這兩個檔案
    • sudo vim /etc/gitlab/gitlab.rb
    • sudo vim /var/opt/gitlab/nginx/conf/gitlab-http.conf
  • 重啟Gitlab
    • sudo gitlab-ctl reconfigure
    • sudo gitlab-ctl restart
[備份]

2016-03-11

如何設定Gerrit的Hook機制

Gerrit是一套Google工程師撰寫的開源code review系統,底下可以銜接多種類的版本控制工具,最近因為Android Studio的開發導入Gerrit作為code review的系統開始竄紅;以下介紹Gerrit如何設定其Hook機制。

[安裝環境]
  • 作業系統:Ubuntu 14.04 
  • Gerrit版本:2.11
  • 版本控制:Git

[設定步驟]
Step 1. 請正確安裝Gerrit系統(略)

Step 2. 修改gerrit的設定檔,把hook的設定補進去,目錄在${your gerrit home}/etc/gerrit.config;請根據自己的需求設定gerrit支援的hook階段

[hooks]
    path = /etc/gerrit/hooks
    patchsetCreatedHook = patchset-created
    # ...you can add more hooks

Step 3. 將script設定為可執行

sudo chmod +x /etc/gerrit/hooks/patchset-created

Step 4. 重啟Gerrit

sudo /etc/init.d/gerrit restart

Step 5. patchset-created是你要執行hook的script,可以換成任何您熟悉的script語言,置放在/etc/gerrit/hooks目錄底下,注意檔名要正確才能對應;先用bash來測試是否正常執行。

#!/bin/sh
echo 'hook setting test.' > hook-gen.txt;
注意:hook-gen.txt會產生到你git到的repo的project目錄,原則上應該是/etc/gerrit/git/${project}。

Step 5. 從本地端執行git commit push,將code送到Gerrit,然後當patchset被產生的時候就會執行patchset-created這支script。

2015-07-11

只要十招,讓您經營高效的軟體研發團隊



1. 縱向思維分工,打破既有分工模式
    引言提到,我們團隊基本上就是一個人要做十個人的事情,所以如何分工就是一件最重要的事情,因為我知道如果以原本的工作型態進行分工,肯定無法承接;所以我自己在腦中沙盤推演很久,並將要接手的系統範圍做了領域的縱向切割,然後再分工出去。
    換言之,我讓每個團隊成員都具備full stack的研發任務與能力,雖然都是剛進公司的新人,不要緊,可以培養,我全力協助建立他們所需要的domain knowhow與技術能力。怎麼培養,後面文章會慢慢提到。

2. 信賴團隊,訂立明確任務
    充分信賴團隊,這句話會說的人很多,但真的做得到的主管很少;另外最重要的是,你要讓整個團隊清楚目標,但往往連主管自己也搞不清楚。
    再者,我真心認為公司的高階主管挑人進來的眼光都很厲害,某些因緣際會我接觸過許多公司的工程師,能進敝公司的人比較起來素質都相當優秀、上進心十足,都是佼佼者。
    既然我有一群佼佼者團隊,更應該善用大家的力量。

3. 個別成員,一次只給單一目標,絕不多頭馬車
    這招讓團隊成功突破許多限制跟細節
    身為一個主管在執行專案,最怕的就是進度不如預期,很抱歉,個人剛好承受壓力的極限異於常人,我把團隊中高手放在一個最無法預期進度(因為難度極高)的功能研發中,但我不給他任何的進度壓力,我這麼跟他說:"這個功能很重要、我也知道困難度很高,但我要的就是一個general solution,我不要你為了求快、求進度而做半吊子的成果就放到系統裡,你放手去做,有任何需要幫忙的盡管提出來我可以跟你一起解問題,剩下的責任我來扛"
    執行過程,當然會遇到不少問題,不管是技術上或是方向要怎麼走,我會仔細從頭到尾把問題、過程、可能解法都聽過一次才發表自己的想法,並且要求成員能有自己的意見跟想法,充分相信你的好手!
    用了好幾次,屢試不爽!成員暨獲得成就感,系統也有了大突破。 

4. 何其幸運,我自己也擁有一個能力超強、當責的好主管
    十年寒窗無人問其實很辛苦,剛好自己也相當幸運,碰到一群好主管(不然也不可能這麼快就讓我當責帶團隊),我們的溝通很頻繁、也很順暢,下情能上達,而且他完全能觀察到我帶團隊用的方法以及建立的文化氛圍,幾乎不用任何解釋他就能理解我的想法

2015-05-19

SCRUM的迷思



    軟件工程一直是個很有趣的領域,相關工程論從早期的CMMI、到近年流行(其實也不是近幾年,在台灣已經有聽到2005年就開始執行的專案)的敏捷(AGILE)開發,由於CMMI繁瑣的文件要求、瀑布式開發都讓人直覺認為執行一個專案最起碼要數月、半年、好幾年的時間,所以應運而生敏捷開發這個名詞,相關最著名的方法論為SCRUM,不小心這個方法個人帶的團隊有執行過;以下來探討一下人們對敏捷開發的迷思
 
    再次強調,敏捷式開發不是軟工方法,敏捷只是一種心理狀態的描述、一種工作環境的意念,如果公司文化沒有敏捷的意圖或是想法存在,導入任何方法都沒有用。

    那SCRUM又是什麼,假如敏捷開發是個數學的應用問題,那SCRUM就是一套或許可以解決問題的公式,SCRUM只是一套方法、一種作業方式、一種運作模式、一種流程,SCRUM不是萬靈丹、SCRUM不是萬靈丹、SCRUM不是萬靈丹,因為很重要,所以要講三次。

迷思一:有了SCRUM就不用寫文件
    一言以蔽之:SCRUM是利用大量的溝通、許多的定期會議取代文件撰寫,所以在時程上並不會大量減少耗費人時,因為這是一種挖東牆補西牆的概念。但好處是因為溝通頻率高,各角色間的思考誤解會有效減少,避免各說各話。
    CMMI最令人詬病的就是那一拖拉庫的文件,從肥滋滋的客戶拿著需求來找你開始,一直到開發完成、測試完成,全部都是一連串的交付文件,包含每個月研發團隊開的會也要記錄,所以CMMI常常被罵到臭頭的都是這件事情。但用了SCRUM之後,難道就真的可以避開這些阿雜的事情嗎?
    CMMI設定的SA、SD、PG、Tester便缺少了文字依循,所以SCRUM放入了幾項元素:會議(快速、經常性的)、User Story。
    因應軟體開發這種腦力高度集中的產業,資訊需要快速交流、有效溝通,SCRUM的模型裡面針對溝通部分導入大量的會議,包含Daily standing meeting、Sprint retrospective meeting、DEMO meeting...
    所有的SCRUM教科書都說Daily standing meeting是一種每天要所有團隊成員以站立的方式開一個10 - 15分鐘的會,那這個會要幹什麼,一言以蔽之就是要資訊通透,會議中要求每個人只要說明前一天做了什麼、今天要做什麼、遇到什麼問題需要協助...

你真的以為會議都會在15分鐘內就結束嗎?

    除非你真是個非常有經驗Scrum Master相當會掌握會議僅度 or 技術能力很強可以理解每個成員想要表達的事情,一個理想的Daily standing meeting執行上其實不簡單,提供個人經驗分享
    此外Retrospective meeting一定要把會議討論的重點跟調整方向記錄下來,口說無憑、時過境遷,很多事情不寫下來或是當下沒有決議,進度檢討流於空談。這種會議文件也不需要長篇大論,基本上就是一張A4就綽綽有餘,紀載會議時間、與會人員、決議事項、待辦事項(包含人、事、時)即可。

迷思二:SCRUM可以節省開發時程

2014-12-04

神註解 - 思考 Code Review 的重要性

無意間翻到一個放著發霉的js檔,傳說中是一間世界知名的硬體品牌廠對外網站產物,分享一下神註解(網路一夕爆紅,然後馬上就被撤)。

不要再跟我說code review不重要,你沒有時間做code review~

2014-06-24

當Mac OS遇上VMware Workstation


謎之聲:"個人喜歡Apple Inc.,也有iPhone、Mac Air...這篇純粹是秉著程序員求新的態度孕育而生~"

Apple Inc.在WWDC 2014橫空出世發表了新的programming language: Swift,以下是Apple自己給Swift的簡介:Swift is Apple's brand-new programming language for writing great iOS and OS X apps. Learn the basics of the language. See how to declare variables, use the fundamental data types, declare functions, and implement classes. Explore some of the great features that make Swift a safe, modern, and extremely powerful language. 簡單來說,Apple要將為人詬病已久不易上手的Object-C換到新語言Swift上,其支援近年流行的Lambda語法Script隨寫隨編隨跑等特性,直教人想趕快玩一玩;但要用Swift可真是讓小弟費煞了一番苦心,沒有Mac怎麼辦?沒關係,Virtualization的第一名VMware真的很厲害~以下介紹如何在Windows上用VMware Workstation安裝Mac OS

個人測試環境需求:

  1. VMware Workstaion 10 (以上),才能支援最新版的Mac OS
  2. VMware unlock tool (v120 以上),得以解鎖Workstaion原本對Mac系列OS的屏蔽
  3. Mac OS X Mountain Lion 10.8.3.iso or Mac OS X Mountain Lion 10.8.3.dmg
  4. xcode6 beta.dmg
[VMWare Workstaion安裝Mac OS X步驟]

2014-03-12

OSGi簡易實作於Eclipse



某些因緣際會,最近稍微研究一下OSGi Framework,但對於這個技術,網路上較多的都是一些框架概念,實作分享不多,就連Eclipse本身直接拿內建的Plug-in建立專案也沒辦法跑(奇怪...Eclipse不是基於OSGi去開發的嗎?) 以下是個人簡易實作分享。

什麼是OSGi:
網路上很多介紹,這裡僅做簡介:OSGi是一個Framework(框架)、是一個概念,框架往往就是好幾個Design pattern構成,用來幫助開發者統一建構系統的標準架構;面臨一個大型系統建置,絕對不會把所有程式碼都放在同一個Project(專案),因為這樣不好維護、分包撰寫,所以OSGi提供一個切割子Project的方法,每一個子專案在OSGi之上視為一個Bundle,每個Bundle可以擁有自我獨立的生命週期,如果撇開Dependency(相依性)不管,每個Bundle可以自由地透過OSGi統一的Command line進行管理(啟動/關閉/重啟...等等),而不影響其他Bundle的運作。
    換句話說,假設,假設今天你開了一台基於OSGi框架製造出來的車子上路,你開到路上車子還在跑,但是你卻突然發現路旁有家新開的輪胎行,德國H牌輪胎之類的,看起來很厲害,然後你臨時想換個輪胎但又不想停下來,只要今天你的輪子也是基於OSGi製造,轉動輪子的軸承也是,那你就可以在車子還在跑的情況之下把輪胎換成心愛的H牌輪胎(什麼爛比喻?!)

先來提提Eclipse內建的OSGi專案:(這個實作並沒有完全成功,網路上找到的bug shooting也沒什麼用)
  1. 下載並安裝Eclipse,https://www.eclipse.org/downloads/
  2. 建立workspace,點選File -> New -> Other -> Plug-in Project
  3. 進入對話框Plug-in Project,記得把下面的Target Plateform換成an OSGi framework,點選Next
  4. 進入對話框Content,Execution Environment不要動,記得還是選JavaSE即可,不要換成OSGi/Minimum,否則等專案跑起來會沒有osgi.jar檔,然後Next
  5. 進入對話框Templates,點選Hello OSGi Bundle,然後Finish. 專案應該就建立完成了。(Eclipse好棒啊)
  6. 執行專案,沒有問題可以執行,Console很開心的跟你說Hello World! 
  7. 悲劇來了,接著馬上噴出一堆錯誤訊息...一句話,別花時間去解了,聽說是專案自己initial其他沒用的jar,然後那一拖拉庫的jar也不知道要關掉哪些才有用,因為關了一些,又噴出其他的錯誤訊息...
那我們該怎麼辦

2014-01-27

不嘴砲!敏捷式(Agile)開發玩真的


敏捷式開發的流程圖大致上會長成這樣,很簡單,但問題是該如何執行?

繼日前介紹的每日站立會議執行心得,時光飛逝,一晃眼2014來了,中國新年也要到了(請不要問版主今年貴庚...),也是再給個交代的時候了。

實際執行過的軟工方法 What we did ?
  • 每日站立會議 Daily Standing Meeting
  • WBS(Work Breakdown Structure)
  • 持續性整合 Continuous Integration(CI)
  • 自動化測試 Auto Testing
  • 視覺化工作進程追蹤 Kanban
  • 使用議題追蹤系統 Using issue tracking system with Microsoft Team Foundation Server(TFS)

敏捷式(Agile)開發到底是什麼鬼 What the hell is AGILE ?
以下完全是個人對敏捷式開發下的定義,不代表任何一個出處。
  • 敏捷式開發不是軟工方法,敏捷只是一種心理狀態的描述、一種工作環境的意念,如果公司文化沒有敏捷的意圖或是想法存在,導入任何方法都沒有用。但軟體開發總是需要方法來協助執行,下一節會針對上述個人所使用過的軟體工程方法來成果分析。
  • 敏捷注重的是大量的重複迭代(Iterator),簡單的說,就是你的任何工作不要做完了才拿出來,千萬不要做完了才拿出來,而是時間到了就要拿出來檢視、拿出來討論、拿出來DEMO。老師在講你有沒有在聽?老師在講有沒有在聽?這可不是跳針,是強調!
  • 所以敏捷團隊執行狀態比較會像是:在專案開發初期,所有成員一起制定目標,這個系統要呈現使用者什麼樣的功能、什麼樣的感覺,不一定要馬上有既定的結論,但必須把工作項目(backlog)內容及時程制定下來,然後由成員各自認養。
  • 不是認養回去就算了,還得繼續把目標切割(item)透過不斷的執行、驗證、根據驗證後的感覺進行討論然後修改、再執行,這樣每次的執行、驗證、再修改、再執行就是一個 iteration。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋,沒有實際執行過真的永遠只會理解教條上那套。
那這樣一直反覆迭代,難道你心中沒有一個疑問?事情一直重複做、重複修改,哪來這樣的美國時間?這樣真的有敏捷到嗎?恭喜你,你開始要有點懂敏捷式開發了。

2014-01-11

軟體主管的喃喃自語:領導原則


圖片來源:www.nipic.com

大方向:

不是很喜歡主管這個詞彙,主管感覺只是在管人、管事,但其實在管理階層要做的事情不能只是管理,要能找出團隊未來的方向,雖然對台灣人來說會很反感,個人倒是覺得用"領導"才是比較洽當的詞彙。


領導(主管)認知:(個人立場)
  1. 謀定而後定,避免朝令夕改:要認知主管的一舉一動、下達指令都是成員們的圭臬,要是今天主管請你研發A,後天跟你說改成研發B,再過幾天又跟你說要研發C,想必大家都會無所適從,專案進度永遠都在歸零。所以個人在下每個命令或指導棋之前,絕對不會脫口而出,都是在腦海中沙盤推演這個命令下去後會讓多少人投入資源,投入資源後會獲得哪些產出,再藉由這些產出能不能達到目的才會下這道決策。要知道主管的話語對下屬來說就是指南針,今天你自己都抓不準方向,又要如何讓事情獲得成功?
  2. 必須有扛責任的覺悟:團隊成敗與否絕對是在主管身上,別想怪罪到下屬上;要是主管老是以"員工不認真"、"員工能力不足"來搪塞失敗,那上級長官又何必賦與你主管職,一個主管存在價值就是在於領導團隊的成功
  3. 不是只為上司負責,更要為成員的未來負責:設想一個情形 - "如果今天你所在這間公司突然倒閉了,你的成員都有辦法、有能力找到別的工作嗎?"主管的任務不僅是要完成上面長官交代的事情,同時間你應該要為下屬的能力培養盡到責任(除非你的下屬就是沒有心思學習,另當別論),今天你交辦給他的任務應該是要有技能性、學習可能、有競爭力的

2013-09-16

Note of daily stand-up review 每日站立會議執行心得


圖片來源:http://martinfowler.com/articles

滾石不生苔的法則,適用於惡劣不斷學習的職場、男女之間的感情維持、朋友的交際應酬,當然軟體工程也不例外。

問題在於,要怎麼讓石頭滾起來呢?又要怎麼判斷有沒有滾起來呢?所以某人堅持要執行每日站立會議(Daily stand-up review)

目前團隊跑了剛好一個多月,執行方式:
  • 每日早上九點初準時開始,全員參與,因為開得很快,在其他團隊要用會議室前就結束了,連會議室都不用借。
  • 站著開會,因為乳酸會在站立的姿勢下快速積累於雙腳,能有效加快會議速率。
  • 用google doc進行條列式追蹤,追蹤項目只寫三件事情:昨天我做了什麼今天我要做什麼我需要什麼幫助
  • 在大家報告完後,再行同步其他資訊(某些情況這件事情可以當作熱場用)。

在這裡先澄清一件事情,並不是所有的開發團隊都適用於每日站立會議,首先有幾個條件要滿足:
  • 人不能太少,四人以下團隊基本上就免了吧,因為整天就是這幾個人在你看我、我看你,幹嘛還花時間開會。
  • 人不能太多,雖然目前個人團隊還沒超過十個人,但依現在的負荷量來說,超過十人來開每日會議就會浪費太多時間,每個人報告個3分鐘,全部人報告完就要半小時,還沒有加上其他議題的討論時間。
  • 主席(可能是PM或SA)要有一定的技術能力,否則開了也沒意思,直接用功能完成度來追進度就好了。最好是能當場就決定某些技術環節要如何解決、來解決、何時解決,否則議而不決真的沒意義。

所謂的每日站立會議有幾項原則:
  • 時間不能太長,因為腳會痠。
  • 主席減少發言,最好是

2013-09-10

[Weinberg - Quality Software Management][Book 4][Ch 12] 流程原則


個人看書喜歡跳來跳去,這次直接跳到第四冊啦!

軟體工程大師溫伯格在談軟體管理學的前三本書,內容主要都是在導引如何建置優良的軟體開發,直到第四本書他開始談要如何在一個發展規模龐大組織及舊環境的體制下,我們該如何進行變革

第十二章講述的是流程原則,目的在於用方法論來克服人的惰性,關鍵在於任何環節都需要被掌握,然後怎樣的情況算是有所掌握,以下是摘要:

Note:
  • 專案中的每樣東西必須是顯而易見的,包含程式碼、計畫、需求、設計、測試計劃、測試結果、進展、所有的書面資料...
  • 當你發現任何一件成果看不到,或"無法接受檢驗",一定要停掉那件事情,並開始進行矯正。要避免"吉米是唯一知道那裏面有什麼東西的人"這類情況,先派人協助吉米,然後請吉米把事情記載於文中,如果吉米拒絕,就拿掉他。看不見的事情絕對不會安頓下來。
  • 通過獨立審查前,沒有一樣東西是真實的。
  • 你不做評量的東西,絕對會不受你控制。

2013-05-01

[Weinberg - Quality Software Management][Book 1][Ch 7]

書名:溫柏格的軟體管理學,第一卷,第七章
Title:把穩軟體的方向

概要
軟工發展多年,已有許多方法論可協助軟體開發,例如waterfull process model,或是近年很流行的WBS、agile,無論如何,這些都只是方法,最重要是執行專案的是人,而不是方法;所以首先我們要了解純然規律性的方法不能完全適用這個道理,更糟糕的是方法論往往為扼殺創意,當然,保守的作法也往往比較安全。

方法論講了好幾頁,都不作者要表達的重點,最後他點出人為決定才是對專案造成關鍵干預且會脫離方法論造成多種不可見狀態。所謂不可見狀態,舉例說明如下:
  • 寫出來的程式有大量難以修正的錯誤
  • 專案成員對不該有自信的事情卻充滿了自信

2013-02-05

當全世界都在用Win/Mac, 你如何用Linux獲利




當世界已經被 Windows 或 Mac 占領,你還有辦法用賣免錢開放原始碼的 Linux 獲利嗎?

最重要的是找到商業模式

- 蘋果模式 Apple Pattern:Mac OS 底層用的是 BSD Linux,但他做了相當多的加值,除了從核心把原生致命的記憶體管理改善,最廣為人知的莫過於 Steve Jobs 畢生都在推行的一體化軟硬整合,瞧瞧2008年七月就上市 iPhone3,他那指尖翻閱頁面滑溜無比的順暢度,到了2013年的今日也沒有幾隻手機能超越。喔~對了,他還有個叫做 AppStore 的應用程式平台,不僅提供 Dev 一夕致富的機會,也讓 user 有十輩子也玩不完的 content。

2013-02-04

下一座台灣新資訊城:台中野孩子


十五年前,如果當時你還只是個名校高中生,你有想到自己全班將有超過六成的同學最低學歷是碩士嗎?

五年前,你有想過周遭有越來越多有出國(或將)工作的朋友嗎?或聽到超過九成五的台灣人想"登陸"發展嗎?

不過是趨勢,因為三個字:不得不

斗膽猜下一個趨勢:"台中是一個很好的資訊產業部落"

最愛用發問來引領思考:
1. 你想靠自己買好房子嗎?台灣薪資水準低落,科技新貴早已是過去名詞,日前某內湖科技公司,開出19k網羅硬/韌/軟體身手的RD,能在台北這樣高房價、高物價獨立置產的年輕人早已是鳳毛麟角。

2012-10-26

軟體債


任何的軟體工程師一定有碰過類似的狀況:「Dead line就在明天,不管了,隨便寫寫交差再說」、「上午老闆跟你說:這個功能你下午就要給我!!」 面對這樣的杯具,保有技術潔癖的工程師絕對還是不會隨便敷衍了事,仍舊保持那優雅的程式撰寫風格,先行做好規劃架構、元件可再利用設計、語法宣告嚴謹的 Write the GREAT CODE 態度,即使犧牲加班時間也要把工作完成(其實如果一直保持這樣撰寫態度的工程師,一點也不會害怕這樣的事情發生,因為所有的架構早就準備好接納各種需求變更的設計)。
但現實生活這樣的工程師往往只能用 hard code、全域變數代替區域變數來應付了事,更糟糕的是連測試都省略。短時間能敷衍了事,但維護的時候就是惡夢連連,這在軟工上稱為技術債

軟體債:廠商為了求快、求眼前看的到的利益大肆任用開放原始碼做一些很簡單的加值功能,但卻不願投注研發核心讓自己擁有獨一無二的難以突破性關鍵技術