| Phantom | Dear all, |
| Bart | 幕後花絮: 本次能勝出都靠黑馬Heidi做出個穩定的電梯，讓我們這組 能勝出，可惜的是Michael的原子彈沒做出來，可是他也發揮了嚇唬 各組的功能，而我在前半段完全不知道他們兩個做的怎樣，只能想 想TestCase和看看每組做的怎樣，看來我和Michael都剛剛好發揮心 理作用，最後讓Heidi安安靜靜的完成了他的穩定版，而讓我們些微 之差贏，有點僥倖，不過也看到各組努力合作的精神，大家其實都 很拼，下次禁止ＮＰＣ參加賭盤，大家努力才不會白費。 |
| Lex | 以下為心得報告內容: 大家好，我是第四組的Lex。 剛來公司第一個月就參加了程式設計比賽，讓人有點慌了手腳。 不過我還是盡力生了一個能運作的程式出來。 一開始本來打算用C++寫的。但是由於題目充滿了麻煩的條件， 光是要記錄每個電梯的State就花了我不少時間，而且由於自己不熟悉C++ STL，浪費了不少時間走冤枉路。 到了剩下12小時的時候，眼看連一個能動的程式都生不出來，於是心一橫，改用自己拿手的Ruby來寫， 沒幾個小時就完成一個能通過驗證的程式(雖然還是很醜)。Ruby是我最喜歡的一個程式語言之一， 有興趣的人一定要試試看。由於時間不足的緣故，我的程式採用了隨機演算法，在無法下定論的時候程式會隨機採取一個行動。 因此電梯會隨機決定要不要開門，沒人的時候會隨機決定要向上還是向下。跑個幾百遍再選一個最好的結果。 這個策略證明是可行的，只是通常結果不怎麼好看。最後結算的時候，大部分的TestCase我的程式都只能給出非常差的結果， 只有Case 8我的程式給了一個比所有人略好的結果，因此整場比賽我可以說沒幫上什麼忙。不過這也說明在某些極端的狀況下， 隨機搜尋會比固定的策略來的有威力。 這次比賽真的很累也很開心，能和這麼多厲害的高手切磋真的是很難的機會，也期待下次比賽的來臨。謝謝。 |
| Heidi | 這真是個爆肝的比賽！XD |
| Henry | 心得: 慘敗，這次當作學個經驗，明年再來吧。 by Henry |
| Jimmy | 第一次參加程式設計比賽，雖然成績不理想，不過很好玩、很有趣。明年有機會一定要參加!! |
| Jonas |
當聽到公司要舉辦今年的程式設計比賽，心理就一陣興奮… 沒錯！又可以再來一次那種跟隊友一起腦力激盪，分工合作把東西衝出來的感覺啦！ 自從高中畢業之後就很少有這種團隊競賽的感覺了，沒想到到了 Openfind 還可以重溫這種快感… 當然啦依照慣例，程式設計比賽沒有在睡的啦！反正大家都還那麼年輕 (?)，撐一個晚上不睡 OK 的。 看到今年的題目是電梯大王之後，直覺反應是…哇咧電梯系統不是老問題嗎？ 不過想當然爾，Openfind 程式設計比賽不會那麼遜的，依照慣例一樣有一堆參數還一些怪怪的變化條件。 Phantom 賽前一直再重複：『這次的題目那麼簡單， 20 分鐘之內就可以寫完的啦！』，不過大家都知道一定不是那回事。 果然看到題目之後… 20 分鐘要寫出一個結果 OK 的版本好像有點拼咧？ 話說比賽到一半，Phantom 從旁邊經過還在碎碎唸：『靠怎麼那麼難寫…』喂喂喂…不是 20 分鐘寫完嗎？ 在當天中午公佈題目之後，我還想說下午認真工作，下班之後再來衝比賽。 不過下午到了一點半…兩點…兩點半… 哇咧？人怎麼都不見了啊！？ 原來是我太天真了，各隊幾乎都中午就開始衝了 Orz 所以我們這隊就趕快招集起來，開始衝比賽啦！ 賽間不時有人一直放風聲『這次大概跑得出來結果的話應該就有前三名吧！』… 話是這樣說的嗎 XD 剛開始的時候我們思考了一些方式，找了一些相關 Paper 來看，不過看看比賽時間和題目複雜度，還是 Greedy 最直接吧！ 反正先用最笨的 Greedy 跑出結果 (跑得出來就有前三名是吧?)，再慢慢調整一些 Greedy 方式應該就夠了。 搞複雜演算法的話，到時候時間不夠跑不出來半個 OK 的結果的話，豈不就應驗別人說的『跑得出來就有前三名』了 XD 這次真是辛苦 Mike 了，在我們討論出來方法之後，他就負責主要部分的 coding， 但是他似乎平常沒有訓練熬夜，到接近天亮之後已經近乎神智不清了，所以這故事告訴我們…平常偶爾熬點夜還是有點幫助的 :P 而 Tony 不愧是 QA，早早就準備好 test cases：『你們有可以跑的版本可以測了嗎？可以測了嗎？可以測了嗎？』 oh my god，沒想到比賽也會被討債，『抱歉，你先咪一下等我們 de 完 bug 吧 Orz』 好不容易第一個可以跑出結果的版本是天要亮的時候才出來的，用題目的 sample case 下去跑，嗯嗯看起來不錯喔！ 再放其他幾個 test cases 下去跑… 挖勒 checker 怎麼一直跟我說結果錯誤啊 Orz 之後 de 掉幾個 bugs 之後，剩下一個 FIFO 的問題搞不定，最後想到是邏輯上有點缺陷，可能會造成違反 FIFO 原則的問題 Orz 看了看剩下的時間，如果要修好的話時間上有點危險，所以只好祭出大絕招： 拿三個版本，各跑一個電梯，兩個電梯，三個電梯，最後在三個結果內選一個 checker 驗證過且結果最好的來用 XD 其實當初看到這個比賽評審方式的時候就有想過： 我們其實可以寫 100 個版本各用不同的演算法，到時候拿到 input cases 的時候就用 script 下去跑所有的程式， 最後自動把結果正確且最好的選出來交出去就好了。 甚至有些決策點如果想不出好方法，或是判斷太複雜，或是會讓程式跑很久的，那邊乾脆就用來個 random， 只要讓程式跑得快，到時候就跑個 1000 次選個最好的結果就好啦！ 其實這也算是個不錯的方法啦，不過很偷雞就是了，產品這樣寫的話會被砍頭的 XD 總之到了最後評分階段，因為有的 test case 我們只用了一台電梯或兩台電梯， 所以有些 case 所耗費的時間，真是高到自己看了都會不好意思 XD 不過我們這組的電梯整個是『節能減碳型』，雖然時間上輸的蠻多的，但是能源花費部分在每個 test case 都是最優的 :P 不過你要問我為什麼會比較省電我是不知道啦，不過我可以給你一個猜測： 如果公司兩台電梯關掉其中一台，那大樓電費支出可能會少一點 (不過你可能上個四樓要等 20 分鐘電梯) … 基於環保訴求的『節能減碳電梯系統』也因此讓我們拿到了第二名，喔喔喔喔喔…這算是賽到嗎？ 總之，這次的故事告訴我們: (1) Openfind 程式設計比賽很好玩，請大家多多參加不要請假 (2) 平常偶爾訓練熬點小夜，總有一天會派上用場的 (3) 節能減碳還算蠻重要的，請大家多多響應 (4) 沒事不要罵電梯很笨，電梯也是有他的苦衷的 |
| Raul |
這次的程式設計比賽，很遺憾的，本組完成的不夠確實，雖然程式可以正確無誤的執行， 可是跑出來的結果確沒有一個可以確實的拿到分數。之後自己在檢討時，敗因可以歸納成以下兩點：
雖然這次的程式設計比賽結果不盡如人意，可是對於我來說，透過這次的比賽，一方面認識了更多的同事， 一方面也是對程式能力的加溫。而Phantom在之後的電子報對於這次的比賽情形更是分析的鞭辟入裡， 也讓我受益良多。雖然比賽已經結束了，可是我還是會找時間，打敗電梯大王這個大魔王，並且，我也開始期待下一次的程式設計比賽了。 |
| Berit |
一年一度的程式設計比賽終於來了.比賽之前整個公司謠言滿天飛,傳說今年的題目超簡單, 簡單到出題的Phantom只需要花二十分鐘就可以解決,不過大家都不驚訝,因為Phantom似乎每年都說超簡單, 事實卻常常不是這樣... Wallace跟Lex還有我三個人同一組, 我們原本的計畫是先花兩小時各自寫個簡單的版本, 再一起討論較為複雜的作法與不同策略的優缺點.但真正開始實作之後才發現問題比想像中要來的複雜, 於是開始了三人的閉門會議.經過一番討論,將程式流程中較複雜的部份清楚的畫在白板上,並擬定作戰策略, 我們決定多個版本不同策略同時進行.實作之後,Lex的random在實測上似乎都可以得到相當不錯的結果. 原本信心滿滿的我們,卻在最後變的有些手忙腳亂,因為比賽的test cases不太適合在random版本上跑. 好在我們版本多,一個不行還有一堆可以用.最後名次揭曉得到第三名,辛苦總算是有了代價. 今年的程式設計比賽是我第一次參加比賽,感覺相當緊湊且有趣,過程中也學到了很多. |
| Tony |
這次比賽的題目，真如 phantom 所說非常"簡單"啊， 各組的人幾乎都開心的在公司渡過了一晚， 從以往程式設計比賽的經驗，我們認為只要可以動，基本上就會有機會。 不過題目實在太難了，最後準備的幾個複雜的 testcase 都沒派上用場， 因為跑基本的都有問題@@。最後結果是由 jonas 所研發的以一部電梯 進行載運，就可以順利跑完；最後感謝兩個辛苦的隊友 mike, joans， 在這次的比賽中，辛苦的寫程式。 |
| Mike |
Sorry for late......囧 這一次的程式設計比賽，題目滿有趣的。不過似乎大家一開始在phantom的"刻意誘導"下， 都真的覺得一天內似乎可以寫得出來，但是在深入討論後並實作後，才發現這是個大黑洞…囧。 所以所有的組別都在公司待了一夜。比賽結束時，大家的眼袋都比眼睛還大。XD 我們這一組因為擁有上帝的頭腦之稱的Jonas，故最後雖然我這一版本的有bug，還是靠著Jonas一人之力， 硬是奪得榜眼。而 Tony 哥也很辛苦，硬是一整夜未闔眼在寫 test case. 想來想來覺得自己真的是太弱啦，看來要好好的操練一下，免得成為零戰力。 程式設計比賽還真的滿有趣的，不過，如果題目可以"人性化"一點，不要每次都這麼變態，就更好了 |
| Michael |
這次的題目第一直覺就是很麻煩，而且如果真的要最佳化的話也有相當的難度 -- 如果是 online （無法預先知道乘客數量、何時到）的話反而簡單許多。 因為不容易想到好方法，所以決定 Bart 先想幾個 test case，我和 Heidi 則先各自寫一個版本，有餘力再尋求改進， 事後證明這也是個不錯的策略：由於這次比賽要交的是 output，所以分頭寫出多種版本、比賽時挑出最好的結果會是 不錯的方法。（還可以降低風險） 雖然計畫是先做個最簡單、幾近 online 版的，不過真正動手前時還是想太多，為了之後修改演算法預留彈性、 為了可以人工修正……，後來自己訂出了一個中間層--定義出比較抽象的電梯動作（相較於題目輸出用的電梯動作狀態碼） 以及從抽象動作輸出成題目要求的輸出格式的 function。做這件事的目的是希望能讓電梯演算法的輸出簡化 （不需要處理 clock by clock detail），而且有人類易讀/寫的中間格式，必要時可以以人工介入修改結果-- 比起直接修改最終輸出簡單。事後想想，這個動作除了增加不少工作量，也是 online 版演算法難產的原因-- 既然是 online，直接考慮 clock by clock 就好了，為了輸出成抽象動作，反而得做部分的 look-ahead-- 結論就是為了不見得寫得出來的「較佳演算法」搬了塊大石頭砸自己的腳。 最終就只有中間層轉輸出這部分可以用，本來打算如果有小的 input case 就用人工排程硬做，可惜並沒有夠小的 case。 幸好其他兩位隊友沒有發生這種搞笑的狀況，順利完成原訂的初版，還做了改進版本，測試穩定而且還有不錯的結果， 就如 Phantom 所說：關起來做原子彈--只做出彈殼--的情況下靠著隊友得到這次的成績。 |
活動訊息
- 行銷動態
- Solution Day
- 教育訓練
廣告櫥窗
- Mail2000
- MailBase
- MailGates
- OES
- 雲端服務
優惠活動
公益御風計畫
業務合作：sales@openfind.com
產品經理：pm@openfind.com
教育推廣小組：education@openfind.com
人事部：job@openfind.com
聯絡電話：(02)2553-2000 分機 888 業務部
國中小技術客戶專線：(02)2553-2000 分機 666 MIS
法律聲明與使用條款
