2015年3月28日 星期六
3/23課堂心得 Ragic
現在有許多雲端關聯式資料庫公司，他們提供類似Ragic，甚至是更好的服務，像是IBM，Amazon Web Services (AWS) Aurora，CrystalDB.....等等，可以提高資料完整性以及程式的獨立性，使得我們的資料更容易流通分享，甚至制定一套完善的標準化程序。
像是今天所學的訂購單，就是一個很基礎的功能，但是卻是很常使用的一套模式。每間公司都會有訂購單，應該是不太可能一家公司能夠做到自給自足，我有想到類似於訂購單的系統，像是最近很流行的訂便當系統:
(https://dinbendon.net/do/login;jsessionid=46C9ECD5146FAAF52D7D2AAF4E3262AC)
除了有相似Ragic菜單的功能，給予使用者更完善、漂亮的介面去做訂購便當的這個動作，
像是今天所學的訂購單，就是一個很基礎的功能，但是卻是很常使用的一套模式。每間公司都會有訂購單，應該是不太可能一家公司能夠做到自給自足，我有想到類似於訂購單的系統，像是最近很流行的訂便當系統:
(https://dinbendon.net/do/login;jsessionid=46C9ECD5146FAAF52D7D2AAF4E3262AC)
除了有相似Ragic菜單的功能，給予使用者更完善、漂亮的介面去做訂購便當的這個動作，
我們可以列出名稱、圖片、價格、便當種類、數量、送達地址、姓名及電話，或是其他內容介紹等等的資訊。
他們的訂購系統還可以有類似計算機功能，非常好上手，介面也很親人，不會有困難度，甚至還可以邀請親朋好友大家一起來團購，如此人性化的功能才能夠吸引到大量的使用者。
然而Ragic，很方便的一點是可以做出出貨單功能，我在另外介紹的這個訂便當系統似乎沒看到，這方面功能的缺失可能會造成管理人員文書上面的困難，何況今天我們使用網頁程式來幫助我們訂購，就是要減少人力造成的缺失，以及額外再做文書的處理成本，我想Ragic在這方面做得非常人性化，我可以不用擔心我會不會忘記我送貨了沒，或者是誰誰誰取貨了沒，不過沒關係，這些表單都會有紀錄，我們後端人員可以透過報表的管理，監控送貨人何時送出了便當，甚至是送出了多少便當，收了多少錢，甚至哪些便當賣得比較暢銷，都可以透過後端的資料處理過後的表單看出端倪，而且十分清楚喔。
不過，我有一些些不同的想法，像是我認為他的資料表格處理得有點不夠細節，資料儀表板這個功能，不知道是不是我沒注意到，或許Ragic可以提供我們選擇表格模式，像是點狀圖，長條圖...等等，又或者是可以讓我們設定某些欄位內容可以做超連結，讓我們可以更輕鬆地去做交叉比對。
舉例來說，我這周的作業就有些許碰上困難，我上課都有認真聽老師一步一步帶著我們做，這次回家我還從頭做了一遍，但是我的資料儀表板做出來就和老師的不一樣，甚至我的訂購資料總彙整那份表格就無法顯示出訂購編號，不像老師那樣還可以把移標移過去就有單筆訂購資訊跑出來，這點Ragic就有點美中不足的是，他們關於功能使用的介紹真的是太簡潔了，常常一個細節萬一忽略了後面的表格做出來就不是很好看，或許他們可以為一些不太能無師自通的使用者設身處地思考一下，這就是我在課堂學習之後一點點的小想法。
2015年3月17日 星期二
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
這是我找到相關資料---資料庫移民的大趨勢，看來有這個多層面必須考慮，我想移民又是一大難題了。
我覺得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
這是我找到相關資料---資料庫移民的大趨勢，看來有這個多層面必須考慮，我想移民又是一大難題了。
首先我們要評估的東西一大堆，像是轉換架構，一個系統的架構是需要多少次改良才能漸漸地成為一個人性化且功能性強，要有邏輯然後慢慢去編譯他，重新編譯程式又是多難的一個課題啊!!
兩個不同團隊(使用不同的資料庫建置)若要進行資料庫移轉，必須同心協力合作，深入討論並去相互了解目前公司營運的環境以及未來開發所要的需求方向。
當然首先要擬定好一份合適的資料庫移轉程序，然後透過專業員工的測試，以及移轉過後的測試，反正就是不停的測試，試到這個系統如原先一般流暢，這樣轉移才沒有損失，如果發生問題，要找出錯誤，並且修正原有的移轉程序，讓他能夠更符合轉移過後的系統，我們務必要將影響到移轉程序的影響因素降到最低(也就是降低損失)。移轉實施過程當中，當然我們必須持續地監控，查看每個可能出錯的問題點，並且確保過程順利。
當然首先要擬定好一份合適的資料庫移轉程序，然後透過專業員工的測試，以及移轉過後的測試，反正就是不停的測試，試到這個系統如原先一般流暢，這樣轉移才沒有損失，如果發生問題，要找出錯誤，並且修正原有的移轉程序，讓他能夠更符合轉移過後的系統，我們務必要將影響到移轉程序的影響因素降到最低(也就是降低損失)。移轉實施過程當中，當然我們必須持續地監控，查看每個可能出錯的問題點，並且確保過程順利。
2015年3月16日 星期一
訂閱：
文章 (Atom)