I Remember... @yhlin - Tumblr Blog

Posts

永遠不要成為小時候討厭的那種大人

IT界最熱血的技術分享挑戰，第10屆iT邦幫忙鐵人賽即將展開。9月10日報名，10月1日正式開賽。本屆推出主題挑戰、團體挑戰及自我挑戰等3大類型，邀請IT界的朋友們，共同挑戰30天發文不中斷，拿出勇者鬥惡龍般的勇氣，一起超越不可能

希望今年可以順利完賽!

透明永遠可以讓事情變簡單

vagrant provisioning

第一次 vagrant up 創建環境時，provisioning 會運行。如果環境已經創建，並且 up 操作只是恢復或啟動一台機器，provisioning 將不會運行，除非明確提供 --provision 標誌。

在生產環境中使用 vagrant provision 時。調用 vagrant reload --provision 時。 --provision 標誌必須存在才能強制執行 provisioning。

也可以啟動環境時，明確指定 --no-provision 來避免運行 provisioner。

#laravel #homestead

Laravel key生成

記憶變差要乖乖做筆記

在初次安裝時要先安裝相依套件

compopser install

然後使用這個指令為laravel建立key

php artisan key:generate

#每次都忘記

為什麼會想介紹 CSS Reset 與 CSS normalize ？因為在很久很久以前（喂～）。咳！重來。在 W3C 制訂 HTML 與 CSS 規格時，並沒有強制規定各家瀏覽器應該怎樣實作每一...

有些東西用了很久了，卻從來沒有好好釐清來龍去脈

#css

系統安裝階段的風險

這禮拜送的一份「系統安裝報告書」被要求要修改「風險評估及因應措施」。有人吆喝起，不是系統上線後才需要風險評估嗎？不久，全團隊瀰漫著一股「得寫一個不存在的文件」的氣息。於是甲方乙方同仇敵嘅的碎唸著鬼島快逃…沒事要求什麼不存在的文件！

但，真的是這樣嗎？系統上線後才需要風險評估，正確嗎？

「安裝階段的風險」

思路

由於風險是無所不在的，為什麼安裝階段不會有風險？

風險是「威脅」利用「資產」的「脆弱性」造成「衝擊」的「可能性」，如果安裝階段有風險，那上述變數是什麼？

因此，第一步要先找出可能被威脅的「資產」。在軟體安裝階段中，資產可以粗略抓出：

硬體設備

作業系統環境

資料庫系統環境

應用系統

接下來針對各種資產，找出「可能」對「資產」造成「衝擊」的「威脅」。

硬體設備

設備進場安裝程序錯誤造成硬體設備損毀

現場施工人員之竊盜行為

現場施工人員蓄意破壞行為

…

作業系統環境

設定程序錯誤，造成作業系統損毀。

安裝程序錯誤造成檔案資料異常刪除

安裝程序錯誤造成作業系統環境崩潰

…

資料庫系統環境

異常操作對非本案之資料庫造成破壞

過失或蓄意破壞非本案之宿主資料庫系統環境

…

因應措施

硬體設備

本案採用VPS虛擬機，無實體設備進場安裝活動。能有效避免安裝活動對機房硬體環境產生之衝擊。

作業系統環境

本案採用VPS虛擬機，安裝階段產生之作業系統環境衝擊可使用虛擬機鏡像還原。安裝程序對作業系統環境不會產生不可逆的衝擊。

資料庫系統環境

本案使用之資料庫系統為獨立虛擬機架設mariaDB。完全獨立於其他資料庫系統。因此，可有效避免安裝階段之任何資料庫操作，對資料庫系統環境產生衝擊的可能性。

結論

照定義找出資產之後，從正確的角度很快就可以看見各種隱含的風險。直視這些風險，因應措施也就呼之欲出了。

#風險

beego 的 admin 包

https://github.com/beego/admin

功能蠻完整的，但有點醜ＸＤ

beego的cmd工具bee設定

情境

照個官方文檔做了

go get github.com/astaxie/beego

卻發現 bee 怎樣都不出來。從 ./bin/bee/bee 測試發現可以執行。確認是是環境變數問題。

處理

執行

export PATH=$PATH:$GOROOT/bin export GOROOT=$HOME/go

打完收工

其他值紀錄的事

go 的環境檢查指令很好用

go env

#goleng #beego

關於 Drupal 編輯齒輪的權限設定

問題情境

新建的角色找不到對應的權限讓齒輪出現。

解決方式

勾選 context link 權限

佛系專案管理

使用警告：本文談的是混亂專案現場自處的心法，工作當做功德非本台立場

想想你五六七月地獄般的生活，沒有額外的報酬，還要面對我們的不滿，雖說是在負責到底的情況下，沒有任何實質的收益或是慰藉，實在是太不健康

這個問題的確是讓我愣了一下。

地獄？

下一個念頭是，對噎，這幾個月好像真的忙到蠻瘋狂的。然後我發現了一個執得探究的問題，

為什麼我對此沒有怨懟？為什麼布拉克是我兩倍的忙，也沒有怨懟？為什麼大愚是我十倍的忙，也沒有怨懟？

從地獄開始推理好了。

無間有三，時無間，空無間，受苦無間。犯五逆罪者永墮此界，盡受終極之無間

地獄在哪？地獄在心裡，在每個輾轉難眠的夜;在每個心煩意亂難以coding的扭侫，在心煩意亂覺得愧對自己的時候，在心情低落覺得愧對別人的時候，在心思狂亂覺得別人被別人愧對的時候。一心狂亂，就是身處煉獄。

那怎麼消除？

應云何住？云何降伏其心？

三千年前，如來的大弟子就問了他這個問題。怎樣才能定下心來，怎樣才能降伏這狂亂的心？

應無所住，而生其心

如來說，不要想定下來，心就會定下來。 (這個[住]就是停止、維持在目前狀態的意思。) 煉獄之所以無間，是因為我們以為痛苦會過去，我們以為技術債會消失，我們以為奧客戶會消失，我們以為雷隊友會消失，我們以為慣老闆會消失，事實上，痛苦不會過去，所有的狗屁倒灶也都不會消失，唯一能做的事情是接受痛苦不會消失的事實，接受痛苦、與痛苦相處，同時保持最終會戰勝痛苦的信念。

教育的先知先覺者，看透了這些狗屁倒灶不會消失之後搞了翻轉教學。金融的先知先覺者，看透了這些狗屁倒灶不會消失之後搞了比特網路。程式的先知先覺者，看透了這些狗屁倒灶不會消失之後有了敏捷宣言。創業的先知先覺者，看透了這些狗屁倒灶不會消失之後寫了精實創業。

想想你五六七月地獄般的生活，沒有額外的報酬，還要面對我們的不滿，雖說是在負責到底的情況下，沒有任何實質的收益或是慰藉，實在是太不健康

慰藉？

慰藉就是，我依然相信最終我們會消滅這些狗屁倒灶

寫程式簡單做專案難

上禮拜跟布拉克聊到實習生程式進步很快，以驚人的速度就可以投入生產。布拉克淡淡的說，「寫程式簡單，做專案難」。

來談談這個

寫程式簡單，做專案難......Block(2018)

以工程師為職志的我們，在寫程式時專注於更乾淨的代碼、更優雅的語法、更高明的技術、更快的執行速度；我們也自鳴得意於比別人更乾淨的代碼、比別人更優雅的語法、比別人更高明的技術、比別人更快的執行速度。

然而，做專案是有責任的。

做專案的時候，要對客戶業主負責，讓對方每分錢花得值得。要對終端用戶負責，讓用戶有效工作、信任系統，不會突然找不到資料。要對團隊夥伴負責，讓夥伴信賴，讓每一行code都能讓他人幫忙維護。要對上級長官負責。讓長官可以放心交付任務，並適時回報戰況。

所以

做專案的時候，更乾淨的代碼、更優雅的語法、更高明的技術、更快的執行速度。上述的這些，只是完成責任的手段，不是目的。達成責任才是目的，其他都是手段

如果髒代碼、醜語法、爛技術、慢速度，可以完成專案賦予的責任，那就是好方法。

我們還是會檢討髒代碼、醜語法、爛技術、慢速度。但目的是為了責任;是為了把工作做好。若是為乾淨而乾淨、為美而美、為高明而高明、為快而快，還因此而洋洋得意，甚至彼此歧視，是很蠢的一件事。

Eat the dog shit, get the job done. That's it.

系統的價值？團隊的價值？

一個有價值的系統，通常是一個「會成長的系統」。如同阿里巴巴也是從一個默默無名的小網站開始長大，不同階段的網站需要考慮不同的問題。

工程師從系統上線過程中遭遇的問題記取教訓，一次一次的透過創新解決難題，甚至發明新工具。雖然阿里巴巴已經是征服全中國的傳奇電商系統，他們還是持續遭遇到問題和挑戰，持續創新。

這個連結是天貓集團的前端，在過去一年發展出來的各種大規模電商解決方案。https://github.com/tmallfe/tmallfe.github.io/issues

系統固然有價值，但真正能帶來競爭優勢的是發展出這些知識的工程團隊。沒有工程師持續支持的系統，就像白化的珊瑚礁，無法產生健康的營運生態。多少台灣企業買了頂新的ERP之後，不但沒有增加競爭力，反而花冤望錢又讓作業流程變得更加詭譎。

寫一個系統用20年的時代已經過去了。工程師持續創作，持續學習，才能為系統帶來持續的競爭力。而持續學習的成本是昂貴的，也是現代系統開發真正成本的所在。

那如何衡量競爭力是否有提升呢？

我逐漸歸納出一個辨識方法。

競爭力有五個衡量變數，速度、種類、穩定、彈性、除錯。

速度，能在多短的時間內，抓住商業重點，切割適當大小，並完成可上線使用的有價值軟體。

種類，掌握的戰術武器類型廣度，WEB、WEBAPP、行動APP、桌面APP、地圖應用。

穩定，交付系統是否有可期待的品質程度，且每個人預期的品質一致。

彈性，交付的軟體容易擴充，且容易擴充的特性是設計時不被懷疑的中心思想。

除錯，團隊成員是否能辨識地雷、有意識的辨識地雷、且在發現地雷時有紀律的記錄地雷的位置。

關於小玩具

小玩具的特性，除了要快、要有用、還有要專心。

快，就是要清楚知道自己的能力到哪，不做好高騖遠的想像。在自己能掌握的專注範圍裡面，一個晚上，或幾個晚上完成。時程長短端視自己的技能成熟度，越成熟，時程可以越長，在越新手的時候，時程要越短。最好以以個晚上為單位。

有用，就是要讓做出來的東西真的有人用，可以是自己用，可以是親朋好友用，最佳的狀態是在自己不用花新力的狀態下，就一直有人會來用。

最後是專心，是新的體悟，專心只做一個專案，做完才做下一個，專案同時進行的時候，就是原地踏步的時候。

發現很棒的所見即所得編輯器

編輯tumblr的文章時發現，不知道從什麼時候開始，tumblr拿掉了醜醜的編輯窗，改用這種不會干擾創作的所見即所得編輯器。

向google大神祈禱的結果，得到了這個 https://editor.froala.com/。和tumblr的效果非常類似，下個專案來使用看看！

網路經濟的革命翻轉

翻譯並改寫自--Dries 部落格 http://buytaert.net/the-big-reverse-of-the-web

我預期WEB若要完全發揮其潛能，在十年內，會經過大規模的重構(re-architecture)和平台重建(re-platforming)。目前的WEB是「pull-based」，就是我們得透過造訪網站或下載手機APP這樣的動作來獲取資訊。然而未來的網路是「push-based」，WEB會自己找上門。未來十年，我們會經歷一場從「pull-based」到「push-based」的典範轉移。當這個「大翻轉」完成時，WEB將從此如同自來水與電力系統一般隱身於幕後，人們甚至會忘記「WWW」的意思。我知道這是很大膽的末日預言，讓我接著說明為什麼會這樣。

在未來，內容、產品和服務將會自動找上你，而不是你去找他們。在你鞋子穿壞的時候，手機會收到Puma最新的鞋款。想像看看，當你下定決心連續晨跑5天，Nike會主動問你要不要試試他們最新的慢跑鞋，為了鼓勵你的運動習慣，免運費再9折。當你長途旅行中錯過了一班飛機，旅行社將自動幫你重新安排好預約的餐廳與飯店，就等你確認ＯＫ。這一切，都不需要自己打開WEB，自己聯絡客服。未來的網路世界裡，服務會在你感到不舒服之前就擺平一切，就像哈利波特裡面的「家庭小精靈」。這些主動的WEB功能，會自動自發的在環境變化時，讓你知道「發生了什麼事」然後自動自發的「幫你解決」，而不是讓「丟問題讓我們自己去想辦法」。

Facebook和Flipboard算是兩個「push-based」的早期案例，可以讓我們大致感覺一下這種「push-based」服務的感覺。Facebook 透過精心設計的串流資訊，主動「push」周圍親朋好友的狀態給你，讓你可以隨時知道他們發生了什麼事，Facebook讓你不需要用打電話來「pull」親朋好友～「嘿你最近找到工作了嗎」; Flipboard 則是透過自動化的演算法，匯總網路上的資訊源，主動提供經你會感興趣的內容給你，讓你再也不需要去訂閱電子報或操作難懂的RSS訂閱。此外，手機上的「通知中心」也越來越聰明，這些服務會透過「通知中心」來跟你互動，連APP都不用打開，就可以達到主動提供你資訊的目的。人們真正想要的，是可以解決問題的資訊;而不是花力氣去取得資訊。大部份的情況下「幫我重開機」樂勝「讓我自己去搜尋怎麼重開機的方法」。

只要發揮一點想像力就可以看見這些令人興奮服務體驗被實現的畫面。你就會發現全世界的電子商務的互動形式，根本就和實體商店差不了多少。我們都還是需要辛勤去搜尋去比較，才能找到真正要的商品。在「push-based」的世界你，當你坐在沙發上看著旅遊生活頻道，旅行社就會依據你的旅遊偏好、預算、健康狀況...來直接提供你量身打造的完美套裝行程。當這個「大翻轉」來臨時，就是傳統旅行社的世界末日。十年後我們現在我們習以為常的現況--「向Google大神祈禱，然後從大神回應的籤詩裏找到解答」將被打破。現在我們讓用戶去「自己找到答案」或「給我把網址牢牢記住，有問題自己來我」。這種「pull-based」還是有其價值，不會完全消失，但「push-based」將會逐漸主導市場，讓世界更有效率。

可能會有蠻多人覺得「我還是覺得pull-based比較好」，但最終「push-based」還是會成為主流。醫療產業已經在經歷這個從「pull」到「push」的過程。穿戴型智慧型裝置將自動幫你做的健康狀態追蹤，提早發現身體素質的變化，讓你不是等到病倒了才去掛號。教育產業也已經搭上這班「pull」到「push」的列車，已經出現一些服務可以依據你的程度，提供你個人化的課程。想想看，我們所習慣的「上學」概念，可能會被顛覆。

這場世界經濟的典範轉移，我們正站在革命的起點。