CMU F20/S21 紀錄

19 min readJun 30, 2021

這篇想記錄一下這幾兩個學期以來上過的 tech 課程，回顧一下每個禮拜消失的 60 70小時都跑到哪去了。短期內的職涯規劃以 SWE 為主，把一些細節準備起來在面試時，也能更系統性地回顧起每個 Project 的重點內容。

Cloud Computing (15619/15319) — S21

Introduction

坦白說，我在這堂課學到很多東西，非常非常多，多到我覺得有點太過頭了。如果讓我再選一次我要不要再上這個課，如果我一樣 carry 54 units 的話，我絕對會說 NO。至於是否要推薦給別人的話，我會採保守態度，取決於對方背景，時間以及對想要怎麼度過這邊人生。目前實習進入第二週，我還感受不到這堂課的用處，畢竟 intern project 本身也尚未開始。

這堂課不僅僅只上名目上的教你使用這些檯面上的 PaaS/IaaS，而是他希望你能夠將所有的酷炫的服務都用雲服務架構完成。整個課都是線上課程，不論你人在 Pittsburgh campus or CMU SV 在每週的第一天，你會拿到大量的 writeup & reading. 這堂的引以為傲的是它將你看作是一個實際開始工作的工程師，你在某週都有新的 feature 要 deploy，都有趕上線的壓力，沒有所謂的 grace days，你擁有的只有 google 跟自行網路上找解答，還有 documents。這堂課本身希望你做的事情就是發現問題，解決問題，發現新問題，新解決方式，直到你完成 task。每個禮拜踩過的坑實在是太多了，後面看起來看起來很蠢，怎麼沒想到是這個原因。但你真的遇到的時候，尋常時候可能花了四個小時才解決得了。You knew it when you met it.

這堂課是完全 project-based 的課，你要完成的是 10 各自不相關的 individual projects 還有 3 個 group projects. 除此之外還有 12 個 cloud 學理上的 quiz。除此之外，還有一些排定的 programming training (spark/multi-threading programming)。除此之外，大概 30 個 primer sessions 提供給學生，讓沒有該週基本概念的學生可以有再更清楚的了解。

基本上 15 週的課程，13 個 projects，12 個 quiz。每週的五六日，我就是念 writeup/reading，做 project，唸書寫小考。這堂課真的非常的花時間，一畝三分地會說，你獲得的跟你付出得不成正比，因為這堂課不是要教你的東西，他是要你踩坑，然後才學東西。以我來說，我每週光在這堂課，就會花上 40 ~ 50 個小時，更不用說還有其他的課。當你要在極快的時間吸收新東西時，這真的能體現能力上的差異，我相信一定有同學能 20 小時做完。

Project1-Big Data Analysis
Project1.1 Sequential analysis
1. 學習撰寫 Junit，使用 code coverage tool 並熟悉 TDD 運作方式以及 Maven build lifecycle 去建構 Wikipedia data processing pipeline.
2. 熟悉 AWS configuration 還有 terraform 來 provision cloud instance.
3. 使用 grep/awk 等 linux tool 撰寫 bash script 來做簡單的分析

Project1.2 Big Data Analytics
1. 在小型機器上嘗試並學習 MapReduce 運作原理，並實作 MapReduce，建立 MRUnit test。
2. 使用 AWS EMR 來達到平行化執行 MapReduce
3. 使用 Pandas 分析跑完 MapReduce 後的 data table

這兩個 project 相對是平易近人，學習文件做的相對容易懂的。我個人認爲前兩週的難易度是最適合學習，接下來的都很崩潰….

Project2-Automating and autoscaling distributed services
Project2.1 Horizontal Scaling and Advanced Resource Scaling
1. 學習使用 AWS API(boto3) 自動化 horizontal scale instance.
2. 了解 ALB/ELB 特性，去 handle load generator 產生的 requests，並用cloudwatch 的 metrics，來設定不同的 scaling policies
3. 在給定的預算內要能 handle maximum RPS，維持一定 RPS，而且要避免 cpu overloaded 造成 instances crash。

這個 project 花超多時間真的是惡夢，要先去了解整體 request 在 AWS 內送進 instance 時的流程，從 load generator，security group，load balancer，lauch configuration，最後在到 auto-scaling group。目標是要做出一個能夠自動 auto-scaling 的 cloud backend。要針對 aws 架構去 configure security group，了解安全性問題，哪些 port 要關閉/打開。點到點的串接，然後看文件一步一步試錯，然候要怎麼 configure。這個幾個 project 都認知到，不能一昧的硬幹。不了解系統架構，硬幹只是決然地浪費時間。每 run 一次 test 就要花個 30 分鐘，到頭來，你也真的也沒多少次機會嘗試。最後是搞清楚 design 後照著文件一步一步做。

Project2.2 Containers: Docker and Kubernetes
1.學習使用 GSR 來 push docker & GKE 來 deploy Kubernetes 進而開發 microservice
2. 使用 helm chart 來管理 Kubernetes application

這週的目標是要架設chat service 是要建立三個獨立的服務，包含 profile service/chat service/login service，每個服務各有自有自己的 docker container 把 Restful Java Spring 包起來，接著 deploy 到 vm 上彼此之間使用簡單的 http request 做溝通。接著學習如何使用 Kubernetes 的特性建構出可以平行 scaling 的服務，並使用 helm chart 來管理 k8s application。這個禮拜的範圍非常大近乎無法理解一半以上的內容，基本上就是把 write-up 掃過，一步一步照著做，starting code 都已經提供了，只是要花大把時間去了解 configuration 以及了解整個大服務架構。大概 8 成的時間都在看沒有寫任何一行 code 然後幾十個小時又過了。不過說實在這是個蠻有趣的主題，可以一步一步看出比較進階的架構是怎麼被建構出來，是一個值得花時間的主題。

Project2.3 Functions as a Service
1. 學習使用 AWS lambda/Azure functions/Google cloud functions 來建立 serverless applications
2. 了解 serverless 服務的架構，如何建立，application 間如何溝通，以及怎麼被 trigger

這週目標是要製作一個服務，當有人上傳影片時，自動將內容儲存在 azure blob storage ，然後製作影片的縮圖，並根據縮圖使用 azure API 做搜尋 & image recogintion 這週的目標明確，並沒有太多令人糾結的部分是，我記得我卡住最久的部分是，製作影片縮圖這件事情，因為當時不了解 trigger 以及怎個 application 要怎麼建構，然後最重要的還有 cloud 上的 test，有鑒於你完全不知道你傳進去的跟 serverless 拿到的 request 是什麼，format 長什麼樣子，你只能使用 azure 的 debug 服務去 debug，但一個 deploy 就要花上 5 ~ 10 分鐘，你會花大把的時間再等待跟測試，畢竟你沒有 CLI 來做 print 啊QQ。我印象中花了20個小時在寫這個建立縮圖的 application，後面就比較快速了。

Project3-Storage and DB on the cloud
Project3.1 Files v/s Databases
1. 使用 awk/grep 去做 flat file 的 query
2. 學習使用 JDBC 去與 SQL 建立連線，接著使用 SQL 的 Java API 去做 query，並瞭解的 bottleneck and MySQL indexing 方式
3. 練習 Redis 的 key-value store 實作 Put/Get/Delete 等 function
4. 練習建構 Hbase database 這包含如何 customize MapReduce 來 load data 並了解怎麼使用 row key/Scan/Get 來加速 query。

這週也是塞得滿滿的，hbase 的 Java API 我已經看得蠻痛苦的了，跟 relational databse 有些不同，預期的操作，不一定適用 Hbase 上，就要多啃文件跟查資料看要怎麼使用這個工具。不過 hbase and SQL 的概念很重要，貫穿整個學期。

Project3.2 Multi-threading Programming and Consistency
1. 了解在 database 中不同 level 的 consistency 會呈現怎樣不同的結果
2. 使用 java 實作 strong consistency and eventually consistency。
3. 了解使用 multi-threading 什麼時候需要 lock 什麼時候需要 release。

Parallel processing of large dataset
Project4.1 Interactive Processing with Spark
1. 用 Spark 打造出類似 page rank 的演算法來分析 Twitter social graph.

這個 project 的時候我剛好在面對期中考，根據我對這個主題的理解(0)與時間安排。我權衡認為直接放掉 project 應該是最好的結果。所以我基本上完全沒有碰這個功課，只有了解一下 spark 怎麽寫，跟 spark 的RDD 概念。但 Spark 是個蠻有用的工具，希望會找個時間熟悉一下。

Project4.2 Machine Learning on the Cloud
1.使用雲端工具進行資料探索以及作適當的 data engineering
2. 練習 config Goole AI Platform 進行 XGB 的超參數 tuning 並 deploy 到 GAE 3. 使用 google API 打造完整的 ML 服務，包含圖像辨識，語音轉文字，Google MAP API
這個 project 是我原本就比較熟悉的領域，做起來也相對快速，而且這個 project 真的算是有趣且明確。目標是做出一個車資計算的應用程式，基於 GCP 的各種服務串接其 API 做出一個可以輸入語音/文字/圖像，之後輸出地點進 google map API 去計算出距離跟路線，再將相對應參數丟入訓練的 model，最終算出車資。整個的 pipeline 龐大但明確，你可以一個一個拆開來去 GCP 找相對應的文件來查看。這個 project 的困難點應該就是你有很多的文件要看，然後要怎麼使用 API，不過由於 write-up 寫目標明確，不模糊，我覺得是相對好做且有趣的應用 project。

Project4.3 Stream Processing with Kafka and Samza
1. 熟悉 kafka & Samza 來處理 real-time stream data (IOT data)
2. 使用 AWS EMR 使用 YARN 來管理 & debug Kafka and Samza

這週的 project 目標是要做出利用 message queue 來打造類似於 uber 這樣的即時配對應用程式。這種 streaming data processing 是之前沒有接觸過的新概念，看 API deploy 直接搞也是困難。實在要非常理解整個概念後，開始coding 會比較容易些。這個 steam data 跟 database 的概念不一樣，stream data 會不斷主動的瘋狂傳輸資料，而不是等待被 query。在這個 project ，producer 會不斷的餵入即時的乘客資料 logfile，我們需要使用 samza 來 consume stream data，根據司機在即時資訊，以及乘客的需求，匯出乘客/司機的配對，吐回去給乘客。我們需要包含其中的配對演算法還有 samza & kafka code。這個 project 我也沒做完 lol，這個 project 本身我比較不熟悉，但不熟悉就算了，我大概卡了 15 個小時在 debug，我原以為是我哪裡寫錯了，但最後發現這個 bug 是因為作業的 server 會隨機生成 logfile，不同時間生成的乘客司機資料會配對不起來。所以我的結果跟答案一直對不起來，重新 load 資料就會對了，但太晚發現，後面沒時間做完QQ。這個 project 的概念十分有趣，我覺得這種處理 active data 會在許多 IOT device 實際起作用，distributed stream process system 或許在未來的場域會十分常見。下學期希望會想要針對這個題材作深度摸索 or 修相關的課程

Team Project — Twitter analytics on the cloud

Team project 分成三個小 project
- Project part1 (web tier)
目標：架設一個能至少 handle 32000 rps 的 backend，無工具限制。
web tier 要架設一個能夠 handle 夠高 request 的 web tier。每個 request 要處理的是一個 twitter JSON 然後要進行一個類似於 blockchain hash 的加密，然後 response 回去確認正確程度。做 hash 本身需要一些算力，parsing json file 也根據你使用的 package(GSON/org.json) 會有差異(要找 benchmark! 很酷)，然後你的寫法也會有差異。但最大的差異是 framework 語言的選擇，可以看 https://www.techempower.com/benchmarks/，了解到你如果使用的是 flask/django，基本上你是不可能達標的，你必須使用更輕量化，更快速的語言。C++/Rust/GO 都是好的選擇。但我們是選用 java 最快速的那個，因為我覺得我時間不夠學新語言。

- Project part2 (storage tier)
目標: 基於 part1，完成 ETL pipeline 在額外新增 Hbase & MySQL 的 database 並至少達成 10000 RPS。並新增 range query 方式，需要針對兩種 database 的 search 進行優化，加速 query。比如說 MySQL 加上 InnoDB cache buffer pool/ Hbase row-key design。
這之中其實踩了很多雷，因為整個裡面的架構都是自己設計的，有時候發現這個設計太慢，就要砍掉重新寫。比如說 design query 的時候，寫完才發現目前的架構太慢，不可能達標。那就要重新更改 ETL(使用 MapReduce or Spark)產出的 data schema，data 塞進資料庫的時候就會是 Hbase 好 query 的格式。並且做 profiling 把 server loading 降下來，把 computation 都歸於 ETL 的部分。但這塊真的是一步一腳印地去嘗試。

- Project part3
目標: 將 group project 的 web tier 改成 AWS ECS/EKS 原生服務以及 storage tier 改成 AWS 原生資料庫。

除了第三階段以外(隊友 carry -.-)，每個 team project 也是 50 hrs 起跳的時間。

reflection

我甚至有卡 12 小時在做同一個 bug，完全無生產力，就是無頭蒼蠅的再找問題點在哪。這才發現瘋狂 coding 基本上是一件非常無效率的事情。如果能先把架構架出來，我會覺得是一個更好的解題循環。
這堂課對我來說我認為真的學到了很多的東西，碰了很多酷炫的工具，然後快速學習新工具，新架構，新框架。我相信這在軟體業的確常見。其中裡面的 project 也幫助我很早就找到實習(面試直接拿出來講 lol)。
但對於菜雞我來說，學習的熱忱很早就被磨掉，後面只有無止盡的熬夜跟交作業地獄。

說到來我覺得這堂課就是真的能力的差異，包含技術力與閱讀能力。因為 write up 跟 reading 就大概 100 頁。就我而言 write-up 就是一個要看 3 遍才能真的理解內容與架構，還有藏在裡面的細節。完全就被壓在地上磨蹭，但歸咎於能力也於事無補，希望在有限時間內能盡量地把所謂的技術能力 & 閱讀能力都有效的提升，讓痛苦指數能盡量下降。

95702-Distributed Systems for ISM — S21

這堂課是 heinz 開的 distributed system，這堂課的 loading 就是一個我認為正常可以接受的程度，我個人花費每週約 12–15小時，但由於很多時間都被 CC 壓縮掉了，如果可以的話，我會認得再花多花上個半天在閱讀還有探索，找資料上面。這堂課顧名思義就是在上 distrbuted system，但這個主題也是很廣，所以老師上課的東西比較淺，多數要由閱讀 or 作業來獲得。上課來說每週有課前考試，課後考試，Lab 還有期末考 & 6 個 project。每個 project 20 小時內一定可以結束，大概是 CC project 的 2/3 loading。

使用 java servelt and JSP 來做出具備 MVC 架構的網頁來呈現爬蟲的結果，需要理解 MVC 概念，並了解常用 HTTP request methods 之中的差異
使用 UDP/TCP 作為 server and client 溝通的管道，並理解智能合約的原理。利用 RSA 來創建 public key/private key 並達到簽署合約這個行為。
根據課程上提供的 Java Doc 實作出 SSI blockchain，並達到新增 node，驗證 blockchain，毀壞 blockchain，新增 blockChain。
使用 docker 來建立 RESTful web server 來與其他四個服務溝通。1. server side 可以 host 任意服務，我做的是會 call 一個虛擬貨幣平台的三方 API 2. Android client-side app，建立一個簡單的 android app 可以當作 client 來發送 request 給 server。3. Mongo Atlas 的 NoSQL backend 串接，在這裡面你需要自己定義要儲存的資料，client request 的參數或者 3rd party API 回傳的資料都行 4. 在 web 建立 dashboard，而 dashboard 顯示的資料是從 mongo atlas 裡撈出來的。
使用 MapReduce Java API 來進行平行化加速運算。並練習使用 Spark 做一樣的運算。
基於 JMS Message Queues 以及 Chandy-Lamport Snapshot Algorithm 做出一個模擬壟斷交易桌遊的 project，architecture 都已經被建立了，只要完成兩個核心概念的部分。 Chandy-Lamport Snapshot Algorithm 是一個用來檢視非同步的 distributed systems，該系統的 global state 演算法。

Reflection:
這堂課東西蠻廣蠻雜的，有不少的功課量都跟 CC 有重疊，寫的算是愉快，因為 CC 都先寫過了zzzz。因為是必修，你也沒得選，沒啥推薦不推薦 XD

95–706 Object Oriented Analysis and Design — S21

這堂我感覺比較像是 software engineering 的大概念，老師想上的東西太多了，但時間有限。整體上起來變成有點囫圇吞棗(但我所有課上起來都這樣，應該是我的問題 XD) 有 group project presentation，考試，case study，上課，但一週就兩堂課，全部塞進去覺得實在非常趕。每週花費時數約 12 吧，但真的要花我覺得可以到 20 lol。

前面的課程在教的是軟體業界的協作跟 work flow。探討最常見的 Scrum and Agile。這些方法由於自己有了一些工作經驗，會知道這些管理工具，開發流程怎麼控制，也知道工作方式影響效率，而軟體工程師每個小時都很貴，因此好的管理方式來的非常重要，但到時實際工作是要怎麼樣真正使用上，又是另一回事了。但當談論到我自身經驗較缺乏的部分，其實這塊就變得玄虛，感覺聽過就忘了，希望隨著實習慢慢有更多的了解（但我們不是 Agile)。再來是探討 user story 跟 use case。分組報告要做的就是 design 營養 app，我們要假設使用者的需求，來製作相對應的功能，並要使用前面談到的 scrum 去分配功能在哪個 sprint，哪些又應該在 backlogs 裡。

再來就是 Object oriented design 與 design pattern 的部分，首先要先了解怎麼樣做出一個恰當的 oo program。在這上面花了很多時間去從 use case 來了解要怎麼去切分每個 class 的內部應該要有什麼 method，跟創建最基礎的物件。這些概念本身我認為就十分 tricky，要去定義物件之中的關係。就我做的 project 來說，User 可以瀏覽所有的菜單，而瀏覽這件事情應該是 user 可以主動發起的，Browse 這個 method 應該在 User object 裡頭。菜餚裡頭包含著營養成分，這些營養成分應該獨立為自己一個 object，來表示會更好。菜餚之中又可以分成很多種類，這些種類可以分成根據各自的特性，implement inheritence，主餐，小點等等。因此在規劃的時候，其實就會花很多時間在最初始的 design，而這些是我認為更需要經驗以及練習的部分，這也是我認為 design 更困難的原因。再加上提到的 design pattern 如 GOF/GRASP 後，配合上 case study 可以知道在怎麼樣情況下，可以使用怎麼樣的 design pattern 來優化 OO program。

Reflection:

我覺得要做出好的 design 比 coding 難上好幾倍。要 design 要溝通要思考，要想這個物件這個 method 放在這個 object 比那個好。雖然隨著 scale 永遠會有更好的 design，但在開始就能將程式有條理地寫出來，總比後面在大改來的好。