星期四, 11月 15, 2018

AdExchange 廣告交易中心的疑似詐騙行為

image from commons.wikimedia.org


最近聽到很有趣的疑似廣告流量詐騙議題。

某網站流量跟 CTR 都很固定,約在每日十萬, CTR約在 1% 左右。算是很不錯的流量來源。

然後忽然此網站某幾個版位某天 CTR 開始逐步成長到 3.x%,以廣告交換中心會覺得這些版位成效不錯,並且逐漸拉高廣告出價(bid floor)。

忽然某個小時灌入近 10 倍的流量,由於廣告交換中心 bid floor 計算還來不急反應下修,變等於是使用 3.x% CTR 的出價去購買這些 10倍的流量,進而造成發佈商營收大量增加。

類似股市坑殺散戶的概念,這種情況如何偵測是個好議題。

星期日, 11月 11, 2018

數位廣告筆記 - third party tracking, GDPR issue.

1. webkit 對於 3rd  party cookie 的限制 (Intelligent Tracking Prevention) 以 make expired 做範例。

情境:有可能一個 我今天在 example-product.com 種了一個使用者 cookie id 在 example-tracker.com 網域下想說之後如果以點擊/購買我可以認列在我們的轉換。

結果使用者三天之後才買, example-tracker.com 就會存取不到第三方 cookie 的使用者資訊,就沒辦法認列。

Webkit Intelligent Tracking Prevention


2. 因應上述限制 facebook 提供 first party cookie option 跟 連外頁面連結帶 fbclid 做連結。

廣告技術者需要知道的 Facebook Pixel 重大更新

Facebook to release first-party cookie option for ads, pull web analytics from Safari

3. GDPR 廣告科技/數位媒體/電子商務 等的影響。
Google Blogger 的 GDPR 宣告

我們公司有對這個議題作分析,我自己是覺得,重點是要告知使用者,並且讓使用者有被遺忘,不被追蹤的權力,而非只是單純的阻止廣告科技/數位產業追蹤使用者

而 GDPR 的 opt-in/opt-out
(Opt in - 先不納入使用者使用,由使用者決定確認後要使用後才啓用。
Opt out - 先提供該服務給使用者, 再由使用者決定是否要繼續使用。)

其實是偏向 opt-in,但是實際上對 數位廣告/電商/數位媒體 真的很難做到使用者同意再給廣告跟追蹤。

我自己個人也是支持 GDPR 的,但是技術上我覺得還有很多尚待討論的實做問題。

所以重點還是回到有沒有提示使用者/跟給予使用者刪除被遺忘的選項。

以數位廣告做流量/素材管理,所以提供給使用者跟廠商的是資料被遺忘權。

對電商/數位媒體則需要提供資訊呈現給使用者,而且不能用落落長的 term of use 法律條文來呼籠。

給網站主的 GDPR 因應建議


星期四, 5月 03, 2018

Immutable In JavaScript

FunP 集團的技術分享
筆記一下

數位廣告業界洞察 - UnMuted/Muted 事件

最近 mobile device 對於影片要能自動播放,大多都會要預設靜音 (muted)。
也因此當使用者有沒有播放聲音這個行為就相對變的重要,而且值得觀察了。
影音廣告的規範文件 在VAST 1.0 就定義了 TrackingEvents-> mute/unmute 也逐漸被重視。

星期一, 4月 02, 2018

babelrc preset stage 0,1,2 差異


最近有人在問 .babelrc 裡面 preset 的資訊 跟 stage 0,1,2 的差異
這篇寫很清楚




babel配置-各阶段的stage的区别

如何用 babelrc 把 src 下面的資料夾一次 resolve 路徑解決 import 問題

babel-plugin-module-resolver 模块解析插件

星期日, 2月 11, 2018

被問到要怎樣思考一個登入系統介面

這問題真的太大哉問了...
先假設 後端 API 是 RESTfull 而非 GraphQL 好了

# 後端

建立好 user table
就帳號跟密碼兩個欄位好了


  • 密碼使用什麼加密方法(PBKDF2, scrypt, bcrypt) 鹽巴的長度
  • 登入後系統產生 token , 然後 CSRF 也是要關注的事情。
  • Token expiration 的機制。
  • 後端跟前端不同主機的 CORS 設定
  • 防機器人暴力測試的機制。

現在大部分後端框架跟工具都可以協助處理這些議題就是。

# 基礎建設


  • 主機也別忘記設置 HTTPS,credentials 如何保管。
  • 在 API Server 前面是否要有 HTTP Server (nginx) 來做控管。
  • 主機機密資料是否要建立 vault 來隔離。
  • 備原機制為何?
  • 誰可以存取主機登入權限。


# 前端

  • 前端跟後端 API 的 CORS 設定
  • 前端如何 persist 登入 token (cookie...)
  • 前端的 Deploy 流程(是否能跟後端分開 Deploy )
  • Remember me 跟後端的搭配的實做
  • 忘記密碼的流程
  • 沒有權限存取的頁面控管...


想到慢慢補,還有很多就是..XD

星期二, 9月 19, 2017

Middlware Arrow Function And Destructuring


const createMiddleware = (extraArgument) => ({dispatch, getState}) => (next) =>(action) => {//some code};

const createMiddleware = (extraArgument) => {
  return ({dispatch, getState}) => {
    return (next) => {
      return (action) => {//some code};
    }
  }
}



星期三, 8月 30, 2017

[CSS] All property 筆記

All 是 CSS 的用來重設樣式的屬性的簡化方法(shorthand), 重設範圍不包括 direction 跟 unicode-bidi。
瀏覽器支援度http://caniuse.com/#search=css%20all
All Value
  • initial: 重設樣式到 CSS spec 的初始值
  • inherit: 樣式會從parent element 的樣式繼承下來,包括一些 Non-inherited 的屬性,例如 border
  • unset: 一些可繼承的樣式會從 parent element, Non-inherited 的樣式將會回到 CSS spec 的初始值。




Ref.1: https://developer.mozilla.org/en-US/docs/Web/CSS/inheritance

星期三, 8月 16, 2017

[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 下 讀書會筆記

上一篇[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 上整理了讀書會的速記,這一篇來記錄一下心得跟團隊的回顧。

自從 TenMax 公司副總 Richard 在 Daily Scrum 說到他今年的目標是要讓團隊進化成一個自主、學習的研發團隊,其實團隊就可以感受到一直在朝這方向前進。

自主,就是成年人自己找方法,在面對廣告科技這複雜的生態圈,遇到問題騰學在台北新竹的開發同仁第一件想的事情,通常是我能提供什麼能力協助團隊去解決這個問題 ,不針對人去究責,而是思考著怎樣解決問題。

學習,因為這個生態圈演化相當快速,不斷的增加自己的技能樹的廣度跟深度也是重要的。我們其實固定都有讀書會,從一開始的廣告科技的基礎理論書-計算廣告,接著是如何思考產業的正向成長的平台經濟學,後來接了一本硬技術底子的 Clean Code。以及在下來跟產品設計相關的 Product Design for the Web

不得不說大家在讀書會的選書都很有連貫性,環環緊扣著怎樣充實自己,怎樣規劃開發出有價值的產品,怎樣把平台滾大。

這次讀書會 Clean Code 對我而言最大的收穫,就是在 Plan Meeting、開發的時候大家會不斷問,這段程式碼有沒有 Clean Code 阿?另外大家是分小組的方式進行,其中在 Unit Testing 的團隊更是用心的準備了許多線上範例教材給大家一起練習,非常用心。



上圖是我們讀書會後的檢討( Retro ),當然有優點,也有值得改善的地方,團隊跑敏捷開發跑了一段時間了,這次讀書會也以敏捷的精神來跑,不免俗的就是最後會檢討一下。

但是這邊檢討不是那種針鋒相對的說誰做的不好,這種指責性的檢討。大家都有一個觀念就是誠實的面對問題,並且思考下一次要如何改善問題。

其實之前讀書會計算廣告大家覺得後面的章節太多數學公式,大家再討論流於形式,這次 Clean Code 讀書會就把後面一些章節捨去,但是其實很可惜的,後面有蠻多值得大家討論的實做。


[Angular] Directive Isolate Scope Note


enter image description here


@ – one way binding
In directive:
   scope : { name : "@name" }
In view:
   name="{{nameFromParentScope}}">
= – two way binding
In directive:
   scope : { name : "=name" },
   link : function(scope) {
     scope.name = "Changing the value here will get reflected in parent scope value";
   }
In view:
    name="{{nameFromParentScope}}"> 
& – Function call
In directive :
   scope : { nameChange : "&" }
   link : function(scope) {
     scope.nameChange({newName:"NameFromIsolaltedScope"});
   }
In view:
    nameChange="onNameChange(newName)">



星期六, 8月 12, 2017

2017 走吧!尋找最棒的自己 觀看事件紀錄

今天2017/08.12下午兩點半帶小朋友去中山堂由風潮音樂主辦的 2017 走吧!尋找最棒的自己,感覺非常之差。

因為我們買了3000元的票,卻因為小朋友場地怕黑大哭而被請出去外面看螢幕。首先我要說,我們對這個親子音樂會努力很久,包括對小朋友做心理建設,讓他網路上先聽了謝欣芷老師的youtube影片。

只要小朋友一哭我們立刻都是安撫他,我老婆一開始他哭了就帶他出去,但是上半場我們出去劇場我們沒有被告知就不能再進來了,所以上半場只好在外面看螢幕。

下半場前我們不斷給孩子心理建設,但是中間還是被告知因為小朋友哭鬧希望我們離開,實際上中間有表演的時候小朋友都是安靜地在看的,只有過場燈光熄掉會大哭,但是我們絕對立刻安撫,但是大約下半場第二首歌我們就被請出去了。

小朋友在外面心情平復了之後,他看著電視指著跟我們說他還想進去看,但是工作人員說已經是最後一首了,等結束才能再進去了。

聽著場上表演者不斷表演,小朋友要做你自己,最棒的就是你,不要哭泣。但是或許他們不能容許一個兩歲的孩童在一個短暫的黑暗時間的哭泣。我們身為家長也不知道是做錯了什麼,但是我們會在他害怕的時候永遠守護著他。


星期四, 8月 10, 2017

[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 上


最近公司 TenMax 的研發團隊完成了 Clean Code 這本書的讀書會,我自己覺得這本書很有趣,尤其在一個成熟的研發團隊正在開發或維護大型軟體,裡面有很多好的準則常常會在Plan Meeting 或是隊友在討論開發細節的時候常常聽到,「這個寫法有沒有 Clean Code 阿?」。

趁熱筆記一下個章節的速記

第1章 無瑕的程式碼 - Clean Code
  • 簡介一些大師眼中何謂 Clean Code。
第2章 有意義的命名 - Meaningful Names
  • 命名是程式中最難的事情,提供了一些避免跟建議的命名方法。
第3章 函式 - Functions
  • 簡短,只做一件事情原則,才能算是好函示。
  • 降層原則,讓閱讀函示像是閱讀文件。
  • 函示的參數小於等於2最理想。
第4章 註解 - Comments
  • 註解的目的
    • 快速回憶上下文
    • 瞭解開發者意圖
    • 最好的註解就是程式本身
第5章 編排 - Formatting
  • 編排是團隊的一個共同溝通方式
  • 每一段程式碼都代表一個完整的思緒,可用編排( ex :空白行)來分隔思緒。
  • space or tab?
  • function { } carriage return ? 
第6章 物件及資料結構  - Objects and Data Structures
  • 資料的抽象化
  • 結構化的程式碼難以添加新的資料結構,因為必須改變所有的函。
  • 物件導向程式碼難以添加新的函示,因為必須改變所有的的類別。
  • 物件還是資料結構
    • 物件(Object): 暴露行為並隱藏內部資料
    • 資料結構(Data Object): 暴露資料但不會有行為
  • 德摩特爾法則 (The Law of Demeter)

假設下面的程式碼
Result result = myObject.myMethod(ctxt)

myMethod應該只能用到
  1. 自己: myobject
  2. 傳進來的參數: ctxt
  3. 回傳的結果: result
  4. 自己所持有的物件: myobject.ooo
第7章 錯誤處理 - Error Handling
  • 讓錯誤的意圖變的明顯
  • Checked Exception vs Unchecked Exception
  • 在不正確的地方寫錯誤處理,導致邏輯混亂,例如該正確運行的地方還加上處理
  • 錯誤處理,依照撰寫者意圖應該要有兩種形式
    • 嚴重錯誤
    • 應該要被完整處理的情況

第8章 邊界 - Boundaries
  • 探索與學習邊界: 常見案例,整合第三方軟體
  • 學習性測試:
  • 不要在產品程式實驗新的東西,而是額外撰寫程式程式來探索第三方軟體

第9章 單元測試 - Unit Tests
內容很多,尚待補充

第10章 類別 - Classes
  • 類別就是一種封裝的方式
  • 類別要夠簡短,命名是一個判斷的方式,如果無法取一個簡明的名稱,他負責的東西可能太大了。
  • 是否能用簡短的方式敘述一個類別的目的。
  • 單一職責原則(Single Responsibility Principle SRP), 主張一個類別或一個模組應該有一個,而且只能有一個修改的理由。
  • 保持類別的凝聚性,可能會得到許多小型的類別。
  • Open To Change
  • 利用抽象化隔離修改