Re: [閒聊] 好奇板上的朋友們都是讀甚麼科系阿?

看板Web_Design作者gpmm (銀色)時間14年前 (2011/02/06 16:43)推噓9(9推 0噓 104→)

留言113則, 14人參與討論串6/8 (看更多)

: → tkdmaf:信徒？我只知道沒有經過實證的技術就只是講講而已。 02/06 08:57 : → tkdmaf:簡單來說。我講過的東西如果不是我做過或用過。 02/06 08:58 : → tkdmaf:我不會拿出來講。 02/06 08:58 這就是關鍵所在了，很多東西有所謂絕對，像基礎的程式概念，但有更多事情是相對的，尤其是觀念或手法部份，自己做過或用過的東西當作經驗而言很好，但一旦升格為狂熱性的框架，那只會限制住自己往後的視野罷了。 : → tkdmaf:至於說「某」書籍。原來我看的書都是「同一本」？ 02/06 08:58 : → tkdmaf:重構、設計範式、物件導向設計模式、極致軟體編程 02/06 08:59 : → tkdmaf:敏捷開發、C++物件導向程式設計，原來這些書是「某書籍」.. 02/06 08:59 : → tkdmaf:我公司買的C++ PRIMER, java編程語言，還有其他雜其雜八的 02/06 09:01 : → tkdmaf:軟體設計技術書籍都叫「某書籍」...... 02/06 09:01 : → tkdmaf:基本上你想在這和我論人品就不必了。 02/06 09:05 : → tkdmaf:有辦法的程式碼拿出來電一電比較實在。 02/06 09:05 某只是泛指，不知道您為什麼一定要自己拉椅子坐下來，把某設定成同一本 XD 至於什麼拿程式碼電一電…真的是不必了，我給出來您還不一定看得懂… 別把自己教義外的人都給小覷了。的確對別人評論不是很恰當，在這邊跟您說聲抱歉，小弟以後會更注意的。 : → s25g5d4:從PHP版戰到這裡來... 02/06 11:11 : → mdfh:技術至上的討論串真無趣 02/06 11:15 : → tkdmaf:所以說，當程式設計師是無趣的。耐不住就不要踏進來。 02/06 11:21 : → tkdmaf:當網頁設計師倒是很有趣就是了。可惜我設計力薄弱。 02/06 11:22 : → tkdmaf:程式設計師只能面對一堆程式碼，努力在效率及功能上加強。 02/06 11:23 : → tkdmaf:網頁設計師則是設計出給人讚嘆的前端介面。 02/06 11:24 所以說到底是如何的所以說？不太懂這句話的前題在哪，不過小弟倒從未覺得寫程式無趣，coding 是我生命裡非常快樂的時光啊，有多快樂呢？大概可以跟閱讀和玩遊戲並列在差不多的位置吧，那可是在構築一個世界呢。常常覺得如果能在程式中找到熱誠，找到什麼是「美」，會是程式人員向上邁進的大助力啊。 : → TonyQ:所謂的前端也是需要有組織跟架構的...-_-;; 02/06 11:29 : → rocairforce:原來已經開戰了 02/06 11:34 : 推 pm2001:設計前端介面就不用管邏輯跟功能嗎? 02/06 11:45 從名詞來講起總會有太多定義上的出入，試試看按內容來分好了，網站實做分工大概會有這些項目：．主視覺設計（網頁設計）．各網頁視覺設計（網頁設計）．網頁動線、介面設計（網頁設計 + 前端工程）．繪製 Flash、撰寫 AS （動畫設計 or Flash 設計/工程）．將設計好的畫面解成網頁，處理 html 骨架、css 貼皮、基礎的 SEO （前端工程）．撰寫瀏覽端的介面控制、相容性、與後端來回拋接的資料和回饋（前端工程 + 後端工程）．準備主機環境（系統工程 or 後端工程）．開 DB （後端工程）．處理後端程式控制（後端工程）上面有標示起來的差不多都是需要撰寫程式的地方，老實說我不知道拿這些內容項目去歸類「是不是一個程式設計師」有什麼意義，更遑論網頁設計師和程式設計師到底怎麼分？那就是看你的CODE是寫CLIENT端執行還是SERVER端執行或啊就網頁設計師啊！不需要莫名的提昇他們的「工程師」地位這種言論（嘆）小弟寫程式這點年歲，後端從簡單的直白寫法到建立起一套完整的 Framework，甚至因為 TemplatePower 在搭配 MMC 上無法真正省效能，所以自己寫了效能差不多但結構迥異的 Template class，前端則是從基本的 alert 到 prototype 到自己手刻 drag/resize/scroll 模組，可以說即使今天沒有 jQ ，95% 以上的控制和介面小弟還是可以分毫不差的達成。重點是，即使前後端的程式都寫了好些時間，但兩邊所追求的道卻截然不同，後端程式輸出 1 就是 1，就算不用瀏覽器只在 shell 底下跑它還是 1，但是前端程式就不是這麼一回事了，控制元素、顯示的行為往往因地而異，即便是現在，往往都還是會寫到一半膠著在某個點上跨不過去。小弟私以為撰寫介面程式要比後端程式要艱辛多了… 如果要追求所謂效率效能，那更是兩者都不簡單啊。 -- 口水到這邊，小弟也來拋磚討論一下好了（雖然我論噗通沉沒的可能性… orz）不知道大家在可排序的資料的資料庫都是怎麼設計呢？例如一本相簿內，相片的排序，普通的建立方式應該就是 id / order 吧，例如： id title order ------------------- 33 相片一 1 34 相片二 2 35 相片三 3 以此類推，而一般針對資料常見的排序操作不外乎是：「向前移動一筆」、「向後移動一筆」、「移到第一筆」、「移到最後一筆」、「自由排序」（拖曳模式，暫不討論）但是在一個高負荷的系統底下，這些操作其實會給資料庫帶來不小的負擔，稍微羅列一下對資料庫而言的相關操作：「向前/後移動一筆」： 1.取得自己的順位（讀取） 2.將前/後一筆的資料排序 +1/-1 （寫入 1） 3.將自己的排序 -1/+1 （寫入 1）而「移到第一筆/最後一筆」就有點可怕了： 1.取得自己的順位（讀取） 2.從第一筆/最後一筆到自己目前位置的資料排序都 +1/-1 （寫入 n） 3.將自己的排序更改為 1/n （寫入 1）這樣算起來，在一個多資料（假設 1000 筆好了）的狀態下，移動資料排序就相對變得有點壓力。其實有另一種不太愉快的變形演算，就是透過夾擊來實做：首先我們先來放大排序的數字，把每個自己的序列 x 1000 好了資料庫： id title rank ------------------ 33 相片一 1000 （第一筆） 34 相片二 2000 （第二筆） 35 相片三 3000 （第三筆）在這種演算下，相關操作對於資料庫的影響會變為：「向前/後移動一筆」： 1.取得前/後兩筆的權重（讀取） 2.檢查夾擊，更改自己的權重（寫入 1）舉個實際的例子，如果要把相片三移動到相片二之前，我們要做的是：．取得相片三前兩筆資料的 rank：1000、2000 ．將前兩筆 rank 相加除以 2 得到 1500，異動自己結果就是： id title rank ------------------ 33 相片一 1000 （第一筆） 34 相片三 1500 （第二筆） 35 相片二 2000 （第三筆）而「移到第一筆/最後一筆」則會變成： 1.取得第一筆/最後一筆的權重（讀取） 2.檢查夾擊，更改自己的權重（寫入 1）以實際例子來說，如果我們要繼續將相片二移動到第一筆：．取得第一筆（相片一）的 rank：1000 ．將第一筆的 rank + 0 除以 2 得到 500，異動自己結果就是： id title rank ------------------ 33 相片二 500 （第一筆） 34 相片一 1000 （第二筆） 35 相片三 1500 （第三筆）由以上可以看到夾擊排序對於資料庫的壓力相對來說小很多，這在追求效能最佳化的高覆載網站上是會有一定程度效果的… 但是夾擊排序最麻煩的地方在於夾擊空間的處理，也就是當某兩筆資料之間的權重只相差一，再也沒有空間可供別筆資料擠進來時，要以什麼樣的演算法做 rank 的重整，這就是另一個故事了 XD 不知道有沒有人有更好的排序資料處理方式啊… orz -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.45.230.126

→