時區換算 - 重新思考 Rails 架構
在整個系統的開發過程中,因為客戶的服務是世界性的,因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜,而是在時區的呈現上並不像我們平常理解的那樣。
在整個系統的開發過程中,因為客戶的服務是世界性的,因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜,而是在時區的呈現上並不像我們平常理解的那樣。
現代大部分的軟體都會考慮到使用者體驗(User Experience)因此都會盡量設計成簡單易懂的操作,然而仍有一些例外的狀況,像是有高度專業需求的系統,或者一些傳統產業長久以來的習慣,當時客戶就屬於這一類型。
當時收到新客戶的需求時,表示是一套很老舊的系統無法維護,急需開發一套新系統來維持業務的運作。客戶自己的工程師已經忙不過來,因此找到我當時任職的公司協助開發這套新系統,並且表示他們已經分析完畢,只需要依照 ERD(Entity-Relationship Diagram)實作即可。
約 2010 年左右,我開始接觸到許多程式語言的社群、研討會,因此大量吸收許多軟體開發的知識。當時,在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後,才意識到「架構」的意義。
最近剛好在跟以前一起工作過的朋友聊到薪資的問題,提到產品設計師的薪資水準比軟體工程師的最高薪資,大概差了一倍左右,這讓我覺得非常疑惑。
以一間做產品為主的公司來說,產品的設計會嚴重的影響公司收入,但拿到的待遇卻沒有比工程師還高,是不是哪裡出了問題?
參加完新一代就差不多是要等畢業了(茶
文章開始之前,一定要先靠北一下新一代,呼籲大家在該死的投票時不要因為去參加新一代很方便就不選自己辦校外展,辦校外展雖然比較累但是至少還可以學個策展的經驗,也不會被人規劃超小的場地繳根本沒有減半一樣的場地費,還不用把門票錢送給人家,也不用因為贊助商獎項很多變成當人家充場面的工具人,傻傻等那只有 8% 比例的獎項頒完。
不過你們沒被陰過,不懂這感覺。沒關係,參加一次就懂了!反正是最後一次麻⋯⋯ 是說評審的評分標準,最好還是送個不會入圍的 DEMO 去,自己另外曝光還比較賺喔~~
看到這行就是我要開始寫了拉 XD
這周都在忙 SITCON 的網站,結果就錯過週二寫 PaaS 入門指南的時間了(剛剛看 GA 還發現大家都已經習慣週二來晃~) 這篇文章其實是順便當寒假作業(雖然老師沒強制,不過剛好可以複習跟檢視我對 RWD 的熟悉度)
其實我一直對 W3C 標準跟歷史不太熟,所以沒辦法像許多高手根據標準跟歷史來討論這些網頁技術上的問題。 不過還好,我多少算是有經驗跟實作,以下就從我所「知道」的 Responsive Web Design 來談談吧!
這邊文章大致上會從這些方向去討論:
我想又會是篇很長的文章,大家就泡個茶慢慢讀吧 XD