3/16課堂心得 ragic

基本上好像程式碼都可以用記事本來寫，不過檢核、排版都太麻煩，多一隔空格少一行空格都不是很順眼，也常常打完一長串，下一次重新看起又要從頭一行一行看，而且只能打字，甚麼附加的功能都沒有。

我覺得ragic真的很方便，因為現在html使用者佔很大比例，所以!!如果能減少編輯html的成本，我想這會是一大亮點，尤其他是以不會寫程式碼的角度來設計這個平台，只要略懂排版，其實他是一個很容易入手的好編輯系統!!

但上完課做了一些練習之後，我跟同學好像都發現了不少問題，像是他們的網頁承載能力似乎有點不堪一擊，班上人數幾乎不到一百個人(的一半)，跟著老師練習的時候竟然就這樣硬生生掛掉了，不知道是不是我們是使用免費版本，他們為了降低成本(嗎?)，導致我們大家如果同時使用就會使得網頁不穩定，這是一個很大的問題，如果資料因此消失或是必須重新製作，那麼效率大幅降低又怎麼會拉攏更多人去投靠他們呢(我認為這真的是一大缺失，但除此之外，他們介面真的很好看)甚至還發現了一些資料上的建置錯誤，像是如果我們沒有按照他們平台上給的流程指示去跑的話，遽然發生了資料做不出來或是出錯的問題，不知道這是甚麼bug導致，希望以後如果更深入去了解RAGIC，我可以發現問題點，然後能有自己的想法去給他們建議或者跟他們一起討論該如何改善，雖然有點異想天開，但是如果不做又怎麼知道自己是不是錯了呢??!!

另外，我有思考到一點就是他的資料庫，我們大二的時候就有在課堂上學習資料庫，然而我們使用phpMyAdmin這個，如果公司以前是使用這個資料庫或是其他的軟體，就算他想轉移過來使用Ragic，他原本的sql語法跟Ragic好像並不通用，這很有可能造成一大阻礙，因為總不可能要整間公司的資料庫重新用Ragic建立，從頭來過光是想像就可以知道成本有多大，何況是之前公司原先聘請的資料庫維護人員該何去何從。若Ragic只能適用於一間剛起步的公司的話，這會不會又大大縮小了Ragic的經濟效益，以及擴展範圍，我認為如果不能承接現在主流的資料庫語法，那真的想要改變消費者的選擇，甚至是會讓他先預付出如此龐大的成本，或許跳槽Ragic這個選項就會默默地被剔除了。

http://www-01.ibm.com/software/tw/data/db2/lowerdatabasecosts/index.html

這是我找到相關資料---資料庫移民的大趨勢，看來有這個多層面必須考慮，我想移民又是一大難題了。

首先我們要評估的東西一大堆，像是轉換架構，一個系統的架構是需要多少次改良才能漸漸地成為一個人性化且功能性強，要有邏輯然後慢慢去編譯他，重新編譯程式又是多難的一個課題啊!!

兩個不同團隊(使用不同的資料庫建置)若要進行資料庫移轉，必須同心協力合作，深入討論並去相互了解目前公司營運的環境以及未來開發所要的需求方向。

當然首先要擬定好一份合適的資料庫移轉程序，然後透過專業員工的測試，以及移轉過後的測試，反正就是不停的測試，試到這個系統如原先一般流暢，這樣轉移才沒有損失，如果發生問題，要找出錯誤，並且修正原有的移轉程序，讓他能夠更符合轉移過後的系統，我們務必要將影響到移轉程序的影響因素降到最低(也就是降低損失)。移轉實施過程當中，當然我們必須持續地監控，查看每個可能出錯的問題點，並且確保過程順利。