2013年12月29日 星期日

環境安裝


開始練習rails 安裝的環境

0. zsh
curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh
1. homebrew
    os x上的套件管理工作
 http://brew.sh/index_zh-tw.html
 $ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)
2. tmux
  http://blog.chh.tw/posts/tmux-terminal-multiplexer/
$ brew install tmux
3.git
 $ brew install git

4.rbenv

\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enable




gem

每次安裝時,加上以下參數:不要安裝相關文件

 加在/.gemrc      gem: --no-ri --no-rdoc

參考這幾篇的安裝
http://vinn.logdown.com/posts/2014/01/19/note-2-ruby-on-rails-environment-mav

https://github.com/rocodev/guides/wiki/setup-mac-development




2013年12月27日 星期五

重構-向範式前進 Refacttoring to Patterns(10)- 簡化Replace Conditional Logic with Strategy

   7.2 Replace Conditional Logic with Strategy
         當函式內有太多條件邏輯控制某一工作的各種變異中的哪一個被執行
         可以把每個變異建立起一個Strategy ,然後將函式的計算工作委託給strategy
          
         + 透過減少或移除條件邏輯的方式來淨化演算法
         + 把演算法的變異移給一個繼承體系,用以簡化class 
         + 讓一個演算法德已在執行期換為另一個演算法
         - 會讓設計變得複雜 - 當以繼承為基礎的解法 或來自Simplifying Conditional Expression 的重構手法較為簡單時 
         - 會讓 演換法從其context class中取資料 的方式變得複雜

2013年12月26日 星期四

learning git(1)

I stated learning ruby on rails .

Reference book (Rails 101)

First of all , I started to learn the basic operation of github (https://github.com/)

I learned from the website(http://try.github.io/levels/1/challenges/1)

Got 15 minutes and want to learn Git?



1.git init 
To initialize a Git repository

2.git status
see what the current state of our project is

3.git add filename
 add file to the staging area by using git add

4.git commit -m "註解"
To store our staged changes we run the commit command with a message describing what we've changed.

5.git add "*.txt" 
adding all changes

6.git log
look history

7.git remote add origin repository URL,
setting remote repository url(GitHub url by your account)

8.git push -u origin master
The name of our remote is origin and the default local branch name is master

The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.

9.git pull origin master
pull file from origin

10.git diff HEAD
look at what is different from our last commit by using the git diff command
HEAD :want the diff of our most recent commit

11.git diff --staged
run git diff with the --staged option to see the changes you just staged

12.git reset filename
You can unstage files by using the git reset command

13.git checkout -- <target>
Files can be changed back to how they were at the last commit by using the command
Restore the deleted files

14.git branch branchname

When developers are working on a feature or bug they'll often create a copy (aka. branch) of their code they can make separate commits to. Then when they're done they can merge this branch back into their main master branch.

15.git branch
you can see a main branch named master and your others branch named

16.git checkout branchname
You can switch branches using the git checkout <branch> command

17.git remove
remove all the things

18.git merge branchname
We're already on the master branch, so we just need to tell Git to merge the branchname branch into it:

19.git branch -d branchname
delete a branch.

重構-向範式前進 Refacttoring to Patterns(9)- 簡化Compose Method

 7.1 Compose Method

         + 有效表達函式所做的是以及如何做這些事
         + 將函式分解為多個名稱正確且細目等級相同的行為 以簡化函式
         - 導致過多的小型函式
         - 除錯變得困難

重構-向範式前進 Refacttoring to Patterns(8)-創建 Inline Singleton

 6.6 Inline Singleton
        程式碼需要存取物件 但不需要一個用來存該物件的class(singleton)時
        將其相關函式取出,並移除此singleton
         +.讓物件間的合作更明確
         +.不需要特別程式碼來保護單一實體
         - through many layers 來傳遞物件實體 很困難時,設計會變得複雜

重構-向範式前進 Refacttoring to Patterns(7)-創建Encapsulate Composite with Builder

   6.5 Encapsulate Composite with Builder


         1.因為Composite的建構工作經常很複雜,因此改由builder代替[能夠減少錯誤並最小化及簡化建構的步驟]
         2.builder封裝Composite也可以解除client端Composite程式碼的耦合關係
         
         進階xml建置等 可用schema-based建置器




         +simplified client code for construct Composite 
         +減少Composite創建過程中重複而且易出錯的特性
         +讓客戶碼和Composite維持鬆耦合關係
         +允許被封裝的Composite或複雜物件有不同的表述
         -無法提供意向清晰的介面

重構-向範式前進 Refacttoring to Patterns(6)-創建Introduce Polymorphic Creation with Factory Method

   6.4 Introduce Polymorphic Creation with Factory Method
         當sibling subclasses以類似的手法實作某函式時
         當superclass和subclass以類似的手法實作某函式時
         將其類似的函式移到其superclass去做(若無法修改其superclass,則創建一新的superclass)
        

         +減少訂製型物件創建手段所引發的重複
         +有效表達 創建行為發生於何處 以及 可以怎樣複寫他
         +強迫class必須實作 Factory Method用到的型別
         - 可能會要求你傳遞非必要參數給某些Factory method實作者  

2013年12月25日 星期三

重構-向範式前進 Refacttoring to Patterns(5)-創建Encapsulate Classes with Factory

  6.4 Introduce Polymorphic Creation with Factory Method


  當sibling subclasses以類似的手法實作某函式時
  當superclass和subclass以類似的手法實作某函式時
         

將其類似的函式移到其superclass去做(若無法修改其superclass,則創建一新的superclass)
         +減少訂製型物件創建手段所引發的重複
         +有效表達 創建行為發生於何處 以及 可以怎樣複寫他
         +強迫class必須實作 Factory Method用到的型別
         - 可能會要求你傳遞非必要參數給某些Factory method實作者  

重構-向範式前進 Refacttoring to Patterns(4)-創建Encapsulate Classes with Factory

   6.4 Introduce Polymorphic Creation with Factory Method 

共用同一個public interface , 共用同一個superclass ,且位於同一個package時
 又想要隱藏一些不公開的clasee , 所以以factory將其封裝起來
 將原本呼叫class的建構式改為Creation method並移到factory 


        實現program to interface ,not an implementation
        以Factory封裝眾多classes
        +透過 目的清晰的函示產生各種實體,簡化Creation
        +隱藏不公開的Classes,減輕package的概念重量
        +program to interface ,not an implementation
        - if need to creat new kinds instance , need new Creation Methods
        1.找出 呼叫class建構式以創建某種實體的客戶碼, 對建構式呼叫動作實施Extract Method,建立public static函式,其就為Creation Method
           實施Move Method,把creation method 移至被喚起的建構式的所屬class的superclass
        2.找出上述建構式的每一個呼叫者,讓其轉為呼叫Creation Method




2013年12月19日 星期四

重構-向範式前進 Refacttoring to Patterns(3)-創建Move Creation Knowledge to Factory


  6.2 Move Creation Knowledge to Factory

有Creation sprawl 發生時,把所有需要的資訊集中在Factory中
讓Factory來處理

解決參數有時候沒有用到  卻一直傳遞下去的問題
直接一次到位
ex: client呼叫 class A傳 c參數給class B ,B又傳給class C 
但其實c只有在class C才有用到


        +.可統合創建邏輯(creation logic)和instantiaion/configuration
        +.將客戶端和creation logic解除爾合(decouple)
        -.比直接具現(direct instantiation)更複雜
         1.instantiator是一個 與其他classes合作具現出某個product的class,如果instantiator未使用Creation Method來具現product
           ,修改他 讓他以creation method發生
         2.產生一個即將成為Factory的新class, 其該如何命名,視其創建出的什麼實體而定
         3.Move Method.把creation method 移到Factory
         4.令instantiator改而具現Factory,然後呼叫Factory獲得一個實體
         5.若扔有其他classes的資料和函式在具現任務中使用,只要合理 進可能搬到Factory,讓Factory盡可能處理創建任務的一切
範例可參考
http://www.allenkuo.com/GenericArticle/view358.aspx

重構-向範式前進 Refacttoring to Patterns(2)-創建Replace Constructors with Creation Methods

6. 創建(Creation)
   6.1 Replace Constructors with Creation Methods

      當有很多Constructors時,把它改成很多個createXXX()
      反正就是要把各個建構子換成Creation Method的樣式

      


         +.比建構式更能有效表達可獲得哪一種的實體物件
         +.突破建構式的限制,像是不能同時擁有兩個 引數個數和引數型別均相同的 建構式
         +.更容易找出未使用的創見瑪(creation code)
         -. Creation方式變得不標準,有些classes 使用new來instantiated ,有些使用Creation Method

         1.找出一個 為創建某種性質的實體而呼叫class的建構式(假設為Ctor1),對其Extract Method, 建立 public static函式
            此新函式為Creation Method,再實施Move Method將Creation Method移到內含建構式Ctor1的那個class
         2.找出Ctor1的所有呼叫者 將其改為呼叫Creation Method
         3.如果Ctor1呼叫了Ctor2 就讓Creation Method呼叫Ctor2 , 可透過Inline Method進行
         4.任何想轉換回Creation Method的建構式 重複步驟1~3
         5.如果這些class建構式沒有class之外的呼叫者,設為nonpublic
   

重構-向範式前進 Refacttoring to Patterns (1)

1. 為什麼寫這本書
    1.1 過度設計
    1.2 The Patterns Panacea
    1.3 Under-Engineering
    1.4 Test-Driven Development
    1.5 Refactoring Patterns
    1.6 Evolutionary Design
2. 重構(Refactoring)
    2.1 Human readable
    2.2 Small Steps
    2.3 Design Debt
    2.4 Evolving a New Architecture
3. 範式(Patterns)
    3.1 Up-Front Design
4. 程式碼壞味道(Code Smells)
    4.1 duplicated unclear complicated
5. 一份Refactorings to Patterns名錄

約耳趣談軟體 PART3 如果你是約耳:既定主題的隨機思考

CH29 Rick Chapman在尋找愚蠢 
            1.技術與商業
CH30 這個國家的狗做什麼工作? 
            1.用自己的方法
CH31 小員工也能做大事
            1.從自己做起 
CH32 兩則故事 
            1.管理階層的重要性
CH33 大麥克對上原味主廚
            1.天才與標準流程方法論
            2.需要的是什麼 
            3.維持高標準 vs 快速擴展
CH34 沒有事情像表面看起來那麼簡單 
            1.先做設計在實作
CH35 為非我發明症辯護
            1.核心事業的功能 要自己做  
CH36 策略書之一: Ben and Jerry模式與Amazon模式 
            1.兩種模式都能成功 挑一種堅持下去 
CH37 策略書之二:雞生蛋蛋生雞問題 
            1.互利的策略
CH38 策略書之三:讓我換回去! 
            1.消除進入障礙
CH39 策略書之四:腫脹軟體與80/20迷思 
            不適用軟體了
CH40 策略書之五:開放源碼的經濟學 
            雞生蛋 蛋生雞
CH41 墨菲定律發威的一週 
CH42 微軟如何輸掉API戰爭

約耳趣談軟體 PART2 程式人員管理

CH20 面試人員教戰守則 
            1.簡介
            2.最近專案的問題
               a.尋找熱情
               b.好的人選會仔細把事情由各個層面解釋清楚
               c.如果專案是由多個人負責  尋找能擔任領導者的腳色
            3.不可能的問題
            4.程式問題
            5.你滿意嗎
            6.你有什麼問題

CH21 激勵是有害的 
            1.為了報酬而工作的人 表現不如完全不期望報酬的人
CH22 不用測試人員的五大(錯誤)藉口 
            1.問題是懶惰的程式設計人員弄出來的
            2.軟體放在網路上 即使有問題也能馬上修好  因為分發容易  但會有壞印象
            3.客戶會替我測試軟體
            4.有資格可勝利的人都不想做測試人員
            5.我請不起測試人員
CH23 人的工作切換有害無益 
CH24 你絕對不應該做的事之一 
            1.把程式從頭寫過
CH25 揭露冰山的秘密 
            1.客戶不知道他們要什麼  別期望客戶知道他們要什麼
            2.外觀很重要  如果外觀好  很容易讓不懂程式的人 以為專案已經完成了  
               因此時程規劃時 若功能還沒好  外觀也先不要太完整
CH26 抽象滲漏法則 
            1.了解基礎
CH27 程式設計領域的帕麥爾斯頓勳爵 
            2.知道各個領域的差別 各有長處
CH28 測量
            1.評價標準很難,也會花去太多時間->激勵是有害的 

約耳趣談軟體 PART1 程式設計實務

最近開始捷運通勤上下班
每天等於多了大概一小時看書的時間
紀錄一下看過的書 及一些看完還記得的重點


CH01  選擇一種語言
CH02  回歸原點
                   1.了解程式底層原理
CH03  約耳測試-高品質程式碼的12個步驟 
        1. 你有使用原始碼控制系統嗎?
        2. 你能用一個步驟建出所有結果嗎?
        3. 你有沒有每天都重新編譯建立(daily builds)嗎?
        4. 你有沒有問題追蹤資料庫(bug database)?
        5. 你會先把問題都修好之後才寫新的程式嗎?
        6. 你有一份最新的時程表嗎?
        7. 你有規格嗎?
        8. 程式人員有沒有安靜的工作環境?
        9. 你有沒有用市面上最好的工具?
        10. 你有沒有測試人員?
        11. 有沒有在面試時要求面試對象寫程式?
        12. 有沒有做走廊使用性(hallway usability)測試?
CH04   每位開發人員至少且絕對要會的Unicode及字元集必備知識 
CH05 無痛的功能規格1:何必麻煩? 
            1.有規格文件和沒有規格文件的差異
            2.寫程式前先寫規格
CH06 無痛的功能規格2:規格是什麼? 
            1.一段聲明
            2.一位作者 
            3.情境
            4.非目標
            5.概要
            6.細節很重要
            7.未定義項目
            8.旁注:測試註解 行銷註解 技術註解 文件編寫註解
            9.規格必須是活的
CH07 無痛的功能規格3:但是…該怎麼做?
            1.誰寫規格
            2.產品經理: 別讓程式人員對產品經理報告 
CH08 無痛的功能規格4:提示 
            1.要有趣
            2.寫規格就像在寫用腦執行的程式
            3.寫得越簡單越好
            4.審閱多次 並重讀幾遍
            5.使用樣板是不好的
CH09 無痛的軟體時程 
            1.用excel
            2.簡單就好
            3.每個功能包含多項任務
            4.實際寫該程式的人 排自己的時程
            5.把任務分得很細
            6.紀錄最初和目前的估計
            7.每天更新耗時欄
            8.加上假日等項目
            9.除錯時間排入時程
           10.整合時間排入時程
           11.時程中加入緩衝時間
           12.絕不讓經理叫程式人員縮減時間
           13.時程就像積木
CH10 每日編譯是你的好朋友
             1.每日編譯確保程式能正常運作
CH11 絕不妥協的抓蟲行動 
             1.確定知道問題的狀況
             2.確定會得到經濟上的回饋
             3.找出那些問題值得修好
CH12 五個世界 
             1.知道各種不同的軟體開發方式
             2.並明白自己處於哪一種  適用於哪一種方式
CH13 紙上原型製作 
             1.用紙筆先畫出介面架構
CH14 別讓架構太空人嚇到你 
             1.重點是解決問題
CH15 邊開火邊移動 
             1.持續release 持續開發
CH16 工匠技藝 
             1.做到最好
CH17 電腦科學中三個錯誤的想法 
             1.不同文化 不同觀點
             2.沒有對錯 重點是了解這樣設計 是為了哪種需求
CH18 雙元文化主義 
CH19 由用戶端自動取得當機回報,一切全自動!
             1.識別重複的當機
             2.選擇分類

2013年11月27日 星期三

bash script runs manually , but fails on crontab

今天碰到一個問題是
寫的shell script 手動run的時候  是正常可以執行的

這個script 主要是呼叫mysql 執行一些資料庫的動作

查了一下發現是一些環境變數的問題
在crontab不認得一些變數--> path裡面所設定的mysql變數

因此先在環境下

下  echo $PATH   

可以知道PATH的變數設定

之後再script增加 

export PATH="上面得到的設定"

如此就可正常執行


參考
http://stackoverflow.com/questions/14612444/bash-script-runs-manually-but-fails-on-crontab

2013年11月25日 星期一

sql exist vs in

這邊比較一下sql exist 和in的差別


Select * from T1 where x in ( select y from T2 )

LIKE:

select *

from t1, ( select distinct y from t2 ) t2 >

where t1.x = t2.y;

如果使用EXISTS,如同上述的查詢結果
select * from t1 where exists ( select null from t2 where y = x ) 

LIKE: 

for x in ( select * from t1 ) 
loop 
if ( exists ( select null from t2 where y = x.x ) 
then 
OUTPUT THE RECORD 
end if 
end loop 


因此當子查詢比主查詢小的時候使用in  ,反之則使用exist
外大內小=IN,外小內大=EXISTS








參考了http://tw.knowledge.yahoo.com/question/question?qid=1306041509015

2013年8月26日 星期一

ajax post get


ajax post 遇到url長度太長的問題

把url和參數分開帶  不要加在一起

用data存參數  和url分開

Instead of putting the data on the URL you should be putting it in the body of a POST request. You need to add a data value to the object you're passing to the ajax function call. Like this:

$.ajax({
        url: url, type:"POST", data:{pcontent: $(pcontent).serialize()
}

2013年8月25日 星期日

裝飾網頁的 CSS3 小技巧

來源  http://www.icoding.co/2013/08/css3-tricks-to-embellish-web

裝飾網頁的 CSS3 小技巧

24 八月 2013 NO COMMENT
CSS3 已經發展到讓前端開發者可以很容易的在頁面上加入許多複雜的視覺效果,這篇文章整理了十個 CSS3 小技巧來讓頁面看起來稍微專業一點 :)

使用 CSS3 將圖片變成黑白圖片

CSS3 定義了 filter 這個功能,所以其實可以很容易的對影片作出各種基本的影像濾鏡。這邊使用的是 grayscale 這個 filter 來讓圖片變黑白,其它還有許多包含 sepia,intert,saturate .. 等。詳細請參考這個範例

另外其實 filter 不只可以用在 img 上,其實可以用在任何 element 上,比如這個測試就對 iframe 來作出黑白的效果 :) 當然也可以用在 video element 上。
iframe 黑與白: http://jsbin.com/eZinOMI/1/

使用 CSS3 做頁面頂端陰影

很簡單的效果,但專業感加分 :) 但陰影效果不要用太重,太重就 low 了。
http://codepen.io/kswlee/pen/CgvuK

CSS3 偵測 double clicks

你相信真的可以只用 CSS3 就可以偵測 double click 嗎?不信請看 :)
http://codepen.io/kswlee/pen/amdtw

CSS3 畫三角形

使用 Pure CSS 來作畫這件事情,之前流行過一陣的 Pure CSS Mnion 已經讓大家見證到透過 CSS3 做任意形狀的可能性。但回歸基本我們還是看一下如何做出透過 CSS 做出非矩形的 element 外觀吧。 http://cdpn.io/zbGBp

使用 CSS calc() 函氏

有時候我們只想做針對 CSS value 做一些基本的計算,這時候並不需要為了這件事情寫 JavaScript,一個簡單的 calc() 就可以搞定了。
http://codepen.io/kswlee/pen/FmDHs

使用 CSS3  做文字漸層

CSS3 本身並無直接的 text gradient 可以套用,但可以轉個彎使用 image-mask 搭配 gradient 來達成。 http://codepen.io/kswlee/pen/wctnx

使用 CSS3 關閉 pointer events (包含滑鼠與 touch)

要讓 element 不去收 user input 可以很容易透過一個簡單的 CSS 屬性設定就可以達成。
http://codepen.io/kswlee/pen/HzqAE

使用 CSS3 做縫線樣式邊框

輕鬆做出專業區塊邊框。 http://codepen.io/kswlee/pen/fviJr

使用 CSS3 客製化捲軸 (WebKit only)

多年前只有 IE 提供客製化捲軸,現在 Webkit-based 的也可以。
http://codepen.io/kswlee/pen/ChygD

使用 CSS3 做模糊文字效果

你一定曾經想找出屬性要做出這個效果,但就只是需要一個小技巧把文字顏色設透明 :)http://codepen.io/kswlee/pen/BchxD

使用 CSS3 做邊角緞帶效果

就是 GitHub 樣式的邊角緞帶
http://codepen.io/kswlee/pen/qIrdv

參考資料:http://www.catswhocode.com/blog/modern-css3-techniques-to-embellish-your-website