Note: new cv online for learning RWD skill

最近開始學了一下RWD/Web front-end 的內容, 剛好開始找工作, 想說拿之前用別人的版做的resume , 用Google 新的Material Components Web 自己手動復刻了一個版本, 陸陸續續做了一陣子, 目前有一個雛型了 Jekyll-mdc

做這個練習大概會學到一些基本的 CSS3/Sass/HTML5/npm/Webpack/Travis-CI/Github Pages/Jekyll  等相關技術棧與framework的技巧

也遇到了Web 標準這幾年持續演化, 有很多相容性的問題, 發現做Web要養人來堆不是沒道理的

如果是工作的話, 除非變成很熟捻各種技術相容性問題, 不然選成熟一點的方案會好一點, 省點力氣, 當然如果公司有特定目標可以選一些新的發展, 畢竟新技術都是為了解決舊有問題, 只是因為Web標準跟Broswer 支援程度落差不少, 尤其這個現在Browser還是各種新舊版本與相容問題, 問題跟Android 碎片化的情況不遑多讓

廣告

隨想: 找工作整理2018

最近休息近半年後開始找工作,越來越體會年老色衰的就職市場劣勢,然後台灣薪資狀況看起來已經無解,當然自己不是大牛也是有關係,自己知道有些缺點,不過自我評估優點應該是蓋過缺點。但是這個要持續工作後才能展現,面試很難單憑口說證明,除非是熟人介紹。

目前手上只有兩個選擇,一個是某工控廠商,一個是某BIOS IBV,不過面試的部門是BMC部門。

兩個目前開出的薪資相近,IBV的月薪是工控+5K,但是工控保證的年薪數字略高,但是估計兩邊我最後獲得的年薪應該差異不大。所以想分析一下選擇哪邊對自己有利。

公司未來前景:

工控廠商看起來產品毛利率有下滑的趨勢, 不過這應該不算大缺點,目前台灣系統廠商普遍有這方面的問題,看了一些相關報導,高層有意識到工控業界會愈來愈零碎化,因為競爭者眾,不再如我10多年前,做標案時沒選擇性,必須要自己從工控的標準品去客製化,現在的局面走向高度面向行業領域,因為競爭者眾大家都想從工控市場分一杯羹,變成工控廠商如果不殺價錢就要面對應用領域去推出應對產品,所以相對會越來越零碎化,簡單講已經到了必須如同IC vendor 的Turnkey services;再付出越來越多的客製化能量,這有賴於市場與業務的手腕去爭取客戶付費在這客製化,不然毛利率只會一降再降,目前看到的是市場還願意付費在這個區塊,因為能提供好的客製化服務的廠商還不太多,還沒到完全紅海的競爭局面。 不過市場上目前充斥很多只願意付國產車價格但嘴裡卻要超跑性能的客戶, 但是不能分辨客戶剛需的業務與PM,往往會用這個理由替業績不佳開脫。該公司目前也是效仿其他公司開始展開策略聯盟或是購併來擴大市場規模避免邊緣化並補齊產品線。

至於IBV 目前看起來公司整體來說市占率還是最大,從投資面看起來算是有市場護城河,不可能大起大落,算是不用擔心公司前景。

個人技術發展前景:

工控廠商–目前想找的是一個做遠端管理方面軟體的人,目前目標是Windows 10 IoT Core,但是也要維護舊有的 Windows Embedded Compact 產品跟舊的配合iAMT的軟體。按照說法應該是想改版上UWP, 不過這個我估計要再2年左右才會真的進入市場或是根本不在市場上,為啥這樣說是因為,UWP Mode 的App 實際上,開始支援跟硬體相關資訊的存取要到Windows 10 1803 開始才有,當然實際上應有其他Work around的方式,應該可以透過操作界面是UWP,但是實際Control 透過Services 之類的方法。對我來說可能可以獲得的成長性是,Windows Driver/BIOS與互動的可能性,這大概10年前就有投入相關學習,不過礙於公司狀況,一直不適合推動,因為有部門職責問題,還有企業文化等相關問題。人的問題往往比技術問題更難解決。
唯一問題是Windows 10 IoT Core 會不會被Microsoft 之後放棄,目前趨勢看來不無可能,估計再經過2, 3年,如果相關市場上無法取得一定成果,被放棄的機率大於70%,畢竟Microsoft 已經採取新的戰略方式 Azure Sphere 都推了。如果發生就是等於把時間投入一個將死的技術堆棧,不過如果拉長來看,這世界技術堆棧死的不計其數,但是領域知識總是大同小異的。而且本身不是只會Windows 相關技能,對於我來說切換技能樹相對簡單。

IBV–目前提供的是Team leader,要負部份管理職責,做的是基於Debian 的BMC BSP Porting相關工作,還有支援某些未來功能需求,目前看來這部份的工作因為職責與公司的知名度關係,會對個人履歷有點加分作用。不過技術堆疊應該就是持續再BMC相關開發上面,估計可以做個3~5年。

工時與通勤距離長短:

目前看起來兩家公司都是正常工時,不太會有超時工作的需求。如果考量通勤,工控廠商位於我步行可達範圍算是加分,IBV要搭捷運30~40min.,但上班時間更彈性點。

目前最大問題是之後還想不想在求職人手市場上打滾,拿別人飯碗的問題。目前看來如果還要再換公司應該選IBV會好一點。但是這個不是我的剛需,畢竟年紀真的到一個程度,市場很現實。

個人成長方面

個人目前有開始學習Full stack 相關知識方面,如果要應用相關內容,則工控廠商的機會大於IBV,不過這會回到公司文化跟人的問題。這在未入職的階段無法確認,目前只有透過朋友去打探一下該公司該部門狀況,得到的答案是該部門還算正常,台灣工控內部搶人搶資源的內鬥情況蠻嚴重,生為一個技術宅,很容易被影響。

Note: IOTA with Industry 4.0 的一些想法

最近在看IOTA 的一些東西,今天早上突然有個想法是應用IOTA 的帳本紀錄在工業4.0上面,假設有個工廠想要導入IOTA相關技術到生產管理上面,實際上需要建立一個或多個Full Node 目前IOTA提供的參考實作 IRI 是透過JAVA EE 寫的,個人覺的他有一個缺點是JAVA EE 本身需要比較大的計算資源,可能的話我個人覺的是在工廠的生產場線場景,透過各種IoT Gateway 執行這個Full Node 功能,這時選擇比較輕量架構應該是一個降低整各應用場景成本的,例如用Python/Go/NodeJS/Rust 等等語言去實現這個FullNode

而考慮應用場景的後續管理維護問題Full Node 與IOTA Devices(Wallet)也需要應用上 Neighbour Discovery Protocol,這樣才有可能達到快速佈建與減低後續維護管理的成本。

再來IOTA Deivce需要自動產生 Seed 並且隔離在應用層,這個應該可以應用目前 Trust/App OS 分離的設計,透過MPU/Hypervisor/TrustZone … 等等技術去隔離

當然以上是考量用比較小的成本去執行,昨天還看到對岸某各機器人公司用ROS做的設備那些東西的成本可以忽略執行IRI成本,但是考量後續管理維護成本其他東西還是需要補齊,考量初始裝設成本跟後續維護成本的比例實際上這裡初始裝設只佔比較小的部份

 

Note: 痛點/爽點/癢點–梁寧–產品思維

“梁寧–產品思維" “得到"上的一門課 目前售價 RMB 99
其中的一篇試讀 10 痛点、痒点、爽点都是产品机会

今天看到有人推薦, 試讀了一下感覺還不錯 但是不知道為啥在我的電腦上無法直接撥
只好看一下他的網頁 找到是mp3 檔案  (另外一篇試讀課)可以透過瀏覽器直接播放
這堂課談的是面對客戶的產品需求定義要如何透過一些方式找出來,文內定義了三個面向,分別是

  • 痛點 — 對應解決客戶心中恐懼害怕的問題
  • 爽點 — 對應客戶當下產生怎樣的需求,就能立刻處理短時間內解決,滿足客戶
  • 癢點 — 對應客戶心中的理想投射,客戶期望的各種事物,提供一個滿足想像的方式

Note: ledisdb to operation rocksdb

just for testing rocksdb basic operation

package main
// build tips
//    go build -tags "rocksdb" t1.go
//    go run -tags "rocksdb" t1.go

import (
  "log"

  lediscfg "github.com/siddontang/ledisdb/config"
  "github.com/siddontang/ledisdb/ledis"
)

func main() {
  cfg := lediscfg.NewConfigDefault()
  cfg.DBName = "rocksdb"

  l, _ := ledis.Open(cfg)
  db, _ := l.Select(0)
  key := []byte("test")
  // with new DB
  //value := []byte("AB123254235")
  //db.Set(key, value)
  nv, _ := db.Get(key)
  log.Println(string(nv))
}

 

Note: work experience ref.

 

Note: Test build Legato Platform of Sierra on Ubuntu 14.04

只需要在Sierra Wireless 上註冊帳號就可以下載他的 Source code
它現在採主流 Embedded Linux 的開發環境 Yocto Project,解開後很簡單只需下 make 就可以完成 喔對了網頁上會寫要裝哪些套件成功 build code

但是如果按照這樣的步驟會發現有兩個 package 會出現問題 原因是他在bb 的function 中呼叫了 bash 的內建函式 而bb是呼叫/bin/sh 在 Ubuntu 上預設的 sh 是dash 所以會不能正確執行, 需要做一個work around 當然你也可以手動砍掉symolically 在重新建立連到 bash 的link 也是可行的

 

  • Check that /bin/sh (ls -l /bin/sh) is not symbolically linked to dash. “dash" is a POSIX compliant shell that is much smaller than “bash" — however some broken shell scripts still make use of bash extensions while calling into /bin/sh. To work around this issue call “sudo dpkg-reconfigure dash" and select No when it asks you to install dash as /bin/sh.