ocowchun
AWS Lambda 設定
之前一直困擾的 AWS Lambda 關於 環境變數設定的問題 ，今天突然想到 AWS Lambda 會需要搭配一個 IAM role ,所以其實如果是使用 aws sdk的話，當我沒有另外指定 access key的時候 預設的角色會是該 IAM role 我只需要設定IAM role有對應的權限，就可以了。
如果需要設定其他變數的話，應該可以把變數放在dynamodb，再透過 IAM role去讀取，這樣就可以避免掉之前使用 consul 來存取環境變數時，因為有設定VPC 所以 AWS Lambda 無法連外的問題。
Henry
關於 AWS 架構的反思
最近迷上 AWS 那 用多少，收多少 (一個月十美金撐著四個 php 網站 + 一個 Dokku 建立的 Heroku-like 平台，根本物超所值) 又極為彈性的架構，一股衝動上來想要把所有的現有架構全部搬到 AWS 上，卻落入了 過度設計 的陷阱。
上週曾試著使用 AWS Lambda 寫一個模擬 web cron 的小 app。在使用 AWS Lambda 之前，我是透過一個簡單的 Rails app 去達成一樣的目的。
為什麼你不使用 Linux cron 就好了呢？
這是我跳脫 Linux cron 架構之後最常被問到的問題。原先想要從 Linux cron 搬出來的原因是 *Linux cron 太依賴主機*，在這個 主機是畜牲，不是寵物 的虛擬化平台年代，每一台主機都應該具備 immutable 的特性， 就算主機消滅了，只要透過系統化的步驟，就可以讓服務在可控制的時間內重新上線。
搬出來之後，我研究了 Rails app 的 scheduler，研究了 Rails 如何與 Slack 串接然後發送通知。實際串接一個已上線的 Drupal 網站測試兩個月之後，我觀察到以下情形：
- 我根本不 care Slack 送來的通知，因為我內心深處知道一定又是一個成功的 cron。這讓 Slack 通知變得非常雞肋。
- 如果 cron 執行失敗了，會另外發送電子郵件提醒，而 Drupal cron 失敗的機率又非常低。
於是，三個月之後，歷經 Linux cron、SetCronJob、AWS Lambda 之後，我又回到 Linux cron，配合 Uptime Robot 接收網站下線警告。這是我最初的架構，也是最穩定、最簡單的架構。
工程師應該要想辦法降低自己的工作負載，而不是讓自己一直過勞。 — 佚名 實際上是我忘記誰說的了 XD
其實 AWS Lambda 讓我想起 Parse 之前推出的 Cloud code，兩者簡直是一模一樣的服務。只是隨著 Parse 被 Facebook 死刑定讞，那些過往雲煙就讓它隨風飄逝吧。
Kalan
回顧前端發展
首先，讓我們回顧一下去年和今年前端的大事件，2015 2016 幾乎可以稱為前端的大工業革命了。
- react 發布並且在 2015 爆紅
- react native 的出現讓前端後端及 app 整合，有了跨平台的功能，雖然目前仍然有許多問題，但未來發展性還很高。
- angular2 的發布。angular 看見 react 的爆紅，也重整的架構，朝向所謂的組件化邁進
- 在 react 爆紅同時，出現了 vue.js 與之抗衡。
- graphQL 的概念出現，並且由 facebook 所推出的 relay 推動。
- es6 es7 標準逐漸定案。js 有了更簡潔的語法
- 許多的自動化工具開始產生，如 webpack babel gulp 等等。
- web assembly 出現，希望能夠讓網頁的執行速度有更大幅的提升webassembly
- web component 的概念產生web component
大概念
可以發現的是，從以前的 web page 開發，使用者在網站上只是想要取得資訊，或者執行某個特定動作（訂購、下單等），到現在變成的複雜的行為交互（聊天、互動、即時等）。逐漸取代了以前的桌面應用程式。
React 等框架的出現
react angular vue 等框架的出現，可以發現前端正逐漸走上工程化的路。慢慢地所謂 component 的概念也會盛行在前端（其實現在就算盛行了吧！）。
同時，google 也悄悄推出 webcomponent 的概念。大家最近如果頻繁使用觀察元素的話，可以發現 input 的 tag 底下會出現 shadow-dom 的標記，主要目的是將 input 裡的內容用一個 DOM tree 做取代，讓你可以操作 input 裡面的內容與樣式。
不過，瀏覽器的實作總是跟不上時代的演進，目前這些 spec 都還在 working draft 裡面，更何況現下已經有各種框架冒出頭了。不過這些標準的優點是，他們是原生的，相對的抽象化滲透就會比較少一點。或許還是個值得關注的發展吧！
真的要組件化嗎？
有時候過度的組件化，反而會造成在 debug 的不易，在狀態並沒有太多的情況下，過度的組件化反而會陷入死胡同裡。
functional programming 的興起
最近這個概念逐漸竄紅，immutable 與 functional programming 逐漸也在 js 界聞名，知名的框架有 immutable 與 Rxjs。
主要是因為 functional 的固定輸出以及映射，讓 debug 變得較為容易。加上時代的變遷，人們開始思考是否有更好的開發方式。
Postcss
postcss 讓我們可以使用未來的 css 語法，並且搭配各種套件做開發，讓 css 的管理更方便、簡潔，同時增加了使用上的彈性。
結論
其實對於前端的生態發展，目前影響最大的應該就是框架的選擇了，太多的框架讓人眼花撩亂，我們似乎也難以找到能夠適應所有開發場景的框架，而且歷久彌新的框架。看看在幾年前，如果在 js 寫 html 寫 css 會被批評為爛 code，但現在呢？很可能我們長久認為的 anti-pattern 被別人拿來當作 best practice 也說不定。
在這個百花齊開的時代，我們更應該回頭思考，我們想要解決的問題到底是什麼。再來是，我們可以去學習框架，學習裡頭的想法、哲學。但，唯一不變的是程式技巧本身。了解基本的演算法、寫出有彈性的架構、深入去了解 js API 等等，或許在這個日新月異的前端領域，才是生存下去的不二法門吧！畢竟要選擇怎樣的框架、是否真的能夠改善開發效率，也端看我們的知識深度是否到位，才能做出最好的判斷吧！
可以確定的是，關於前端，我還有很多路要走。
同場加映，日本 IT 產業
恩，實在是很好奇日本的 IT 產業下的環境是怎樣耶！每次看到他們的作業員就是穿著整齊的制服，早上還要一起跳早操喊精神口令，一絲不苟地完成自己的工作。雖然真的很屌，但…壓力真的很大吧
於是想起了以前找到的文章，在日本的IT 公司工作是怎樣一番體驗？。基本上可以看到他們的工作是被高度細分的，所以今天儘管你是文科畢業的學生，只要經過一番訓練就可以馬上 on board。然後大部分的公司都是在做外包，然後再外包再外包這樣的形式。
看來當個旅行者，跟實際在日本生活，所想像的樣子還是有差啊！不過每次看到日本的房子、日本的風景、日本的服務業，就會儼然覺得「恩，這個社會還是有希望的」（笑）。
