Python Paramiko 筆記

在以前公司工作的時候,有點忘了是遇到什麼情境,總之我就看到python 有這樣的一個套件庫:Paramiko

話不多說,我們就給大家來看文件吧:http://www.paramiko.org/

然後就結束這一回合(阿不是!

他是一個和SSH 有關的套件庫,是可以使用python 直接在遠端給他執行程式起來… 啊寫文章的同時我就想到了!之前我們好像是要做那個資料庫備份什麼的, 然後有發現說有時server 會不夠空間backup , 所以後來我就用這個套件透過本機去連結遠端執行 df -h 的指令,以方便告訴我到底有沒有足夠的空間這樣…. 不然每次連線打指令實在很麻煩…

然後 , 我最喜歡的是: show you the code !

import paramiko

paramiko.util.log_to_file('paramilo.log')
key = paramiko.RSAKey.from_private_key_file("pem path...")

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(hostname='......',username='user',pkey=key)

stdin, stdout, stderr = ssh.exec_command('df -h')

result = open('log.txt','wb')
result.write(stdout.read())
result.close()

ssh.close()
小君曰:我到底寫了什麼...?

原來可以這麼寫(10):同步與非同步

來到第十篇原來這麼寫啦,看來這個系列真的常駐我這個部落格真的很久呢!

要冷靜啊!

然後這次真的是史上我接過任務最難的一波,有一天還差點情緒崩潰在工作現場爆哭… 真的覺得自己很丟臉很誇張……

不過事後想想,那是因為我自己對自己的要求也實在太高了,也一直過度自責、苛責自己的規劃上有很大的問題….. 真的很辛苦各位我的同事。總之,這次的經驗告訴我:要努力試著讓情緒歸情緒、工作歸工作哭完,問題還是在那裡,我們一定要努力地解決問題。工程師的存在正是為此啊。

我自己最喜歡得形容詞就是忠心!忠心於工作、忠心於自己的技術能力、也忠心於自己的信仰。我想藉著上面的事件也再度應證與難怪自己為什麼會有那種過度反應了吧

結論是:calm down ! 挽起袖子來解決問題

小說的匯入任務

這個任務為什麼對我來說蠻困難的,我覺得技術問題是一回事,其次我自己也檢討是不是太晚將問題丟出來了?我的個性常常是獨立做事,說真的還蠻就事論事得、原生工程師性格。而我通常認為我自己不是那個第一個遇到同樣問題的人,所以總是自己想辦法處理、想辦法解決…. 像是Laravel 的開發與專案、API維護上,我其實就非常游刃有餘、自由自在。(當然溝通上面的gap 與問題是需要慢慢的與團隊磨合與自己努力調整的),DevOps 的精神就是逐步改善麻!

但我卻忽略有時候其實是有時間上的問題,在過年前要匯入這麼多的小說,一共12000多章節,剛好我台東人在過年期間卻要請長長的年假,我才驚訝發現:我hold 不住了。看來,下次也要注意時間,好讓PM與SA 能夠發覺與注意到我的狀況,能hold 住專案

自動匯入方案的產生

不過還好啦,謝謝同事、夥伴們的體諒與幫助。在禮拜五怒給他加班到十一點的時候把這個自動化方案寫出來(但當然啦,這個我覺得也需要事先給PM測試,所以同時我也預備自己的手動匯入程式方案…但等等分享我遇到的問題與啟發)

手動匯入的些許失敗經驗與啟發

但說真的,小說匯入其實這次第二波了。上一次真的我自己沒有準備好… 可是這次我吸取第一次的失敗經驗,重新調整流程、設計。於是這次在匯入資料上面就非常的順利,還記得第一次營運單位有兩天的時間都無法到後台修改資料…但這次一個下午就搞定了。

事實上,我只是把匯入分成兩個階段進行,第一階段是把資料放進去資料庫(就是這個步驟才會不建議營運單位修改資料,以免我們的id 亂跳…),而第二階段是去別人小說的網站把音擋下載下來上傳到我們server上的指定位置,驅動我們同事寫好的自建音檔模組。於是完成了這整個匯入流程。

而第二階段的處理原本我用python 寫 request.get(url) 這樣去下載,寫檔案後上傳的“同步方案”,一支處理就要10秒多…. 然後12000多就… 超級慢的啦!

中間還遇到工作電腦爆掉的問題… 真的是很衰… 第一次遇到…. 但所幸謝謝我們家的MIS幫我工作電腦換好一個power 這樣,於是只有一點點時間是不知道怎麼辦而已。

隔天早上,發現我那支居然跑到一半不跑了… 還好我之前在設計上有納入可中斷性,就算中斷了重新執行也可以從還沒處理的部分繼續接著處理… 但就像剛剛說的一個一個上傳真的很慢啊…. 於是開始研究 python 的 非同步方案版本…

import aiohttp
import aiofiles
import asyncio
import time
import os


#定義協程(coroutine)
async def main(links):

    async with aiohttp.ClientSession() as session:
        tasks = [
            asyncio.create_task(fetch(data['url'], data['episodeId'], session)) for data in links
        ]  # 建立任務清單
        await asyncio.gather(*tasks)  # 打包任務清單及執行


#定義協程(coroutine)
async def fetch(link, id, session):
    async with session.get(link) as response:  #非同步發送請求
        if response.status == 200:
            f = await aiofiles.open('/tmp/file.mp3', mode='wb')
            await f.write(await resp.read())
            await f.close()
        try:
            # s3 upload
            print("{} upload success")
        except Exception as e:
            print("{} upload error")

        os.remove('tmp/file.mp3')



start_time = time.time()  #開始執行時間
loop = asyncio.get_event_loop()  #建立事件迴圈(Event Loop)

#  episodes = ...

loop.run_until_complete(main(episodes))  #執行協程(coroutine)
print("花費:" + str(time.time() - start_time) + "秒")

於是,我在家中研究寫了這樣一個模擬出來的程式碼… 然後執行下卻發現… 靠 檔案因為非同步的關係所以就產生Permission error 的錯誤,在修正後變成以下這個版本…(但不是全部程式碼,僅是示意)

import aiohttp
import aiofiles
import asyncio
import time
import os


#定義協程(coroutine)
async def main(links):

    async with aiohttp.ClientSession() as session:
        tasks = [
            asyncio.create_task(fetch(data['url'], data['episodeId'], session)) for data in links
        ]  # 建立任務清單
        await asyncio.gather(*tasks)  # 打包任務清單及執行


#定義協程(coroutine)
async def fetch(link, id, session):
    await asyncio.sleep(10+int(random.random()*10))
    try:
        async with session.get(link) as response:
            if response.status == 200:
                FileHelper.upload_s3_audio_files(id, await response.read())
                print("{} upload success".format(id))
            else:
                print('status not 200')
                print("{} upload error".format(id))
    except Exception as e:
        print(e)
        print("{} upload error".format(id))



start_time = time.time()  #開始執行時間
loop = asyncio.get_event_loop()  #建立事件迴圈(Event Loop)

#  episodes = ...
loop.run_until_complete(main(episodes))  #執行協程(coroutine)

print("花費:" + str(time.time() - start_time) + "秒")

但還是無法解決所有的問題,有時還是會噴一堆錯誤,或者是Response payload is not completed , 因此… 還在想一想怎麼樣可以更好…

但比較好的是:因為這是第一次匯入,當然資料爆多。之後的更新就不會有那麼多了… 而確實使用非同步的寫法與方案在第二階段處理上快了很多…

此事件帶來我的啟發是:這麼大量的上傳下載處理還是要搞非同步啊

小君曰:看來,我需要好好理解非同步程式設計啊....

原來可以這麼寫(9):結果我變成python 工程師?

祝大家新年快樂。原來可以這麼寫這個系列終於來到第九篇!

說聲好消息,最近工作獲得肯定(撒花~)。只是不知道年終到底有多少…搞不好…其實很少…. 這個就題外話啦,在這個公開網路場合還是不宜多說XD

從資料庫匯出資料

最近接到一個需求,是要從資料庫匯出資料。其實這個東西並不是很難,寫寫SQL 語法就能搞定…但因為安全的因素我們的資料庫通常要透過SSH 跳板才能進去。可是他們匯出資料的需求是要by 一個顧客(客戶),你媽咧我難道一個一個SQL 撈出來然後再丟進Excel 嗎?

不!這絕對不是工程師的思維… 後來想想我在我第一份工作的時候開啟了一個side project : office: https://github.com/r567tw/office

那時候為什麼我要開啟這個專案呢?原因是,我當時負責重構一個網站系統,是用Laravel 重構原本native php 改寫的報名網站…. (這大概可以說是我工程師生涯其中一個直得常常拿出來說嘴的一個成就…但當然啦我之後在想覺得那時候我初出茅廬才維護一年多就改寫實在有點冒險…只怪我當時太年輕太衝動太不懂事了…. 裡面還是有一些遺珠之憾等級的小後悔~)

啊話說開了,總之那時候有要驗證台灣的身分證字號,還有生成台灣的身分證字號…這當然網路上可以有工具可以用啦,但你不覺得開瀏覽器->搜尋-> 點進網址 -> 可能還有點一些按鈕bla 的才能搞定自己的需求很麻煩嗎?

於是你看到office 裡面就有一個資料夾應運而生:id_card_number

隨著時間推移,裡面的工具也越來越多XD

這次我就用到使用ssh 連接到database 來幫我完成需求的工具:connectDBthoughSSH

import pymysql
import sshtunnel 
import dotenv
import os

dotenv.load_dotenv()

server = sshtunnel.SSHTunnelForwarder(
    ssh_address_or_host=(os.getenv('SSH_HOST'), 22), # 指定ssh登入的跳轉機的address
    ssh_username=os.getenv('SSH_USER'), # 跳轉機的使用者
    ssh_pkey=os.getenv('SSH_PEM_PATH'), # 跳轉機的密碼
    remote_bind_address=(os.getenv('DB_HOST'), 3306)
)

server.start()

db = pymysql.connect(
    host='127.0.0.1',
    port=server.local_bind_port,
    user=os.getenv('DB_USER'),
    passwd=os.getenv('DB_PASSWORD'),
    db=os.getenv('DB_DATABASE')
)

cur = db.cursor(pymysql.cursors.DictCursor)

cur.execute('select id,name from clients')

clients = cur.fetchall()

db.close()
server.close()

接下來,拿到sql 的資料之後就是python 和 excel 的問題了,撒花!

匯入第二波小說資料

因為目前時程與安排的緣故,目前匯入資料暫時由工程師處理,前面的應用到step function 就是其中一環的應用,但說真的,前面這一環的資料匯入,我開發幾個 laravel 的 api , 實在規劃的! 很!爛! 我愧對我作為工程師的身份啊…

經過漫長快一個禮拜的規劃… 我想到他馬的我為什麼要繼續用PHP完成我這個需求?用Python 呢?

再經過兩~三天的研究與開發, python 的版本終於應運而生!不過裡面資料先暫時用在sqlite 上面, 之後我想把它放在mysql 資料庫上面… 然後寫好專案裡面的readme和說明,不用我只要大家用這個程式就可以做使用,多自動化多方便啊… 這是我這個的最終目標啊!

嘗試做一些改變

目前,我是一名後端工程師,我的專案其實就只有一個。這一個專案負責官網、後台、ios/android app 的API, 同時也需要與交易的 Lambda 溝通,去年我甚至也主導單集銷售模式的Lambda 開發,而我在接手此專案的過程中曾發下宏願:

  1. 完整文件化
  2. 導入TDD,甚或是DDD , 強化程式碼品質、程式碼架構彈性

目前我自認自己將文件化的目標至少有70-80%,我很努力的研究swagger 怎麼寫,創造一個較為優良的swagger文件的環境,整理目前就我角度上專案的開發現況,導入代碼表的文件在每個需要代碼的swagger 文件。也在多次與app team/PM/官網/後台 有多次的溝通摩擦、gap , 雖然是有點加重了我個人的loading , 但至少在開發前做一次好好地確認、流程、導入mock api 的機制先在開發前作討論。

我不知道,我這樣的做法,是否對於各方角度team 有好的成效、好的溝通效率?甚願可以。希望可以。畢竟API 的 DX 很差,那我這個後端工程師真的不用在繼續幹下去了!

接下來,希望完成資料庫的文件化,也希望程式的TDD, 測試能一一地補上。這是我接下來要努力的目標之一。

每次改變一點點,這也是DevOps 文化的其中一環麻。

小君曰:原來這次我是python工程師?

aws step function 筆記

最近工作用到一些工具,使用到AWS step function , 因此在這裡也筆記一下…

也在公司後端組例會分享了一下(以下就是我分享的PPT ):

其實我覺得我用的情境很簡單,只是用Map 的方式啟動lambda . 這個 lambda 就是我用來處理下載與上傳到s3指定位置… 說真的應用的情境真的很不多… 還有更多著墨的空間。

另外,自己同時也針對此寫了兩個版本,用SAM 和 用 CDK 的版本…

一、CDK 的版本

import * as cdk from '@aws-cdk/core';
import * as lambda from "@aws-cdk/aws-lambda"
import * as stepfunctions from "@aws-cdk/aws-stepfunctions"
import * as tasks from "@aws-cdk/aws-stepfunctions-tasks"
import * as logs from "@aws-cdk/aws-logs"
import * as s3 from "@aws-cdk/aws-s3"
import * as ec2 from "@aws-cdk/aws-ec2"
import * as dotenv from 'dotenv';

export class CdkLambdaStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 將裡面比較敏感的資訊用env 包起來, 注意後面的path 要正確
    dotenv.config({path:__dirname+'/../.env'})
    
    // 我要上傳音檔的S3 目標 arn:aws:s3:::test 為虛構(我忘了把這個也包env了哈哈)
    const bucket = s3.Bucket.fromBucketArn(this,"test","arn:aws:s3:::test")

    // 負責前面呼叫step function 的 lambda
    const downloadAudioLambda = new lambda.Function(this, "downloadAudioLambda", {
      runtime: lambda.Runtime.NODEJS_12_X,
      timeout: cdk.Duration.seconds(25),
      handler: "index.handler",
      code: lambda.Code.fromAsset("lambda/downloadAudioLambda")
    });

    bucket.grantPut(downloadAudioLambda)

    const downloadAudioJob = new tasks.LambdaInvoke(this,'Calllambda',{
      lambdaFunction: downloadAudioLambda,
      outputPath: "$.Payload"
    })

    const map = new stepfunctions.Map(this, 'ExampleMapState');
    map.iterator(downloadAudioJob);

    const logGroup = new logs.LogGroup(this, 'StepFunctionLogs')

    const stateMachine = new stepfunctions.StateMachine(this, 'StateMachine', {
        definition: map,
        logs: {
          destination: logGroup,
          level: stepfunctions.LogLevel.ERROR
        }
    });

    const testVpc = ec2.Vpc.fromLookup(this,"vpc-dev",{
      vpcId: process.env.VPCID
    });

    const processorLambda = new lambda.Function(this, "processorLambda", {
      runtime: lambda.Runtime.NODEJS_12_X,
      handler: "index.handler",
      timeout: cdk.Duration.seconds(25),
      code: lambda.Code.fromAsset("lambda/processor"),
      vpc: testVpc,
      environment: {
        ENDPOINT: process.env.ENDPOINT ?? 'localhost',
        DATABASE: process.env.DATABASE ?? 'db',
        DBUSERNAME: process.env.DBUSERNAME ?? 'root',
        PASSWORD: process.env.PASSWORD ?? 'password',
        NODE_ENV: process.env.NODE_ENV ?? 'test',
        statemachine_arn: stateMachine.stateMachineArn
      }
    });

    stateMachine.grantStartExecution(transferLambda)
  }
}

總之,上面我就是用CDK先創建我的lambda , 然後把那個要放到state machine 的建立”task”, 給予我另外一個lambda 有 startExecution 的權限…. 簡單完成!

二、SAM 的版本

總之,有些原因,我另外又學習怎麼用SAM製作 state machine XDD

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description:
  download audio file from huaxi to trigger audio transcoder
Resources:
  ProcessAudioFileStateMachine:
    Type: AWS::Serverless::StateMachine # More info about State Machine Resource: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-statemachine.html
    Properties:
      DefinitionUri: statemachine/audioFile_processer.json
      DefinitionSubstitutions:
        DownloadAudioFunctionArn: !GetAtt DownloadAudioFunction.Arn
      Policies: # Find out more about SAM policy templates: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-policy-templates.html
        - LambdaInvokePolicy:
            FunctionName: !Ref DownloadAudioFunction

  DownloadAudioFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html
    Properties:
      FunctionName: downloadaudio
      CodeUri: functions/downloadaudio/
      Handler: index.handler
      Runtime: nodejs12.x
      Timeout: 20
      Policies:
        - S3ReadPolicy:
            BucketName: 'test'
        - S3WritePolicy:
            BucketName: 'test'

  ProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: processor
      Timeout: 20
      CodeUri: functions/processor/
      Handler: index.handler
      Runtime: nodejs12.x
      Environment:
        Variables:
          ENDPOINT: db_url
          DATABASE: dbname
          DBUSERNAME: dbusername
          PASSWORD:dbpassword
          NODE_ENV: test
          statemachine_arn: !Ref ProcessAudioFileStateMachine
      Policies:
        - StepFunctionsExecutionPolicy:
            StateMachineName: !GetAtt ProcessAudioFileStateMachine.Name

其實說真的CDK 和 SAM 沒有多大差別,只是CDK你可以用比較程式化的去做那個state machine language (就是sam 裡面要包的那個json 啦!),像我,實在懶得去構想那個json 怎麼寫(啊我就不是JSON工程師啊~),所以先用CDK 產生state machine , 然後上AWS控制台上面把那一串json 抓下來,放到我的sam 這裏… 整理一下,CDK detroy 一下,sam 的template.yaml 調整一下,一個下午搞定啦!(不過我好像忘了在sam 裡面宣吿log 去接state machine 啦 XDDD 之後再研究吧!)

小君曰:還有很多成長的空間

今年的回顧與未來規劃-2020

終於又準備來到新的一年,這一年過得真的很快,又到了回顧&立未來Flag的時候。讓我回顧去年寫的版本:今年的回顧與未來規劃

有哪些完成了?有哪些沒完成?又有哪些放棄了呢?

關於工作

在今年大約三月初的時候,找到了一份在聯合報系行動發展部擔任後端工程師的工作,很幸運的得到一個自己蠻滿意的offer ,真心感謝長官們的賞識。而在這份工作當中,我終於體會與經歷做產品的酸甜苦辣,商業模式的各種錯綜複雜與討論,學習上真的蠻多的。感謝我的同事、夥伴、組長總是不厭其煩的幫忙與指導,真心希望未來2021年,還希望你們繼續指教我啊! (媽的我好官腔喔好想揍飛自己…)

而在約莫11月底的時候,長官更是幫我申請到一筆獎金給我,人生第一次收到這間公司的獎金。說真的,可以在工作上得到肯定,就是棒啦!♥將榮耀歸給上帝 ♥

關於去年的目標

其實啊,今年有一項相當失敗,就是 ios 上面的學習,遲遲都沒有進度。。。。 看來只能展望明年了 嗚嗚嗚 😭

另外,明明今年計劃想學好golang 的計畫也只是簡單上一門簡單的線上課程:GetGoing: Introduction to Golang,而且,目前還正在上課中,還沒融會貫通啊!

最後,上架了之前在鐵人賽的文章到部落格上,也果斷放棄搬到siteground的想法,因為… $$

今年完成了什麼

  • 關於部落格
    • 後來研究了一下費用與成本的部分,甚至一度想要改放到AWS上,但後來想一想,覺得放在siteground 真的太貴了,想到之前網路上問過的問題:想請問從目前的虛擬主機搬到AWS的成本,裡面有個回答寫道:「若是計較成本優先的人, 不應該選擇公有雲….」,就決定果斷放棄搬主機的計畫啦,現在固定一年兩千多塊多省啊XDDD
    • 有沒有發現,我的部落格文章變多了,很順利的,我用python撰寫一些工具把鐵人賽的文章搬過來了啦ㄎㄎ
  • 技術學習
    • 對 Laravel 有更深入的了解:在撰寫上有試著更多的在操作與學習 Collection,同時也試著將強型別的概念導入我寫的程式碼當中、繼承前人寫的測試繼續擴大寫測試、同時也在努力學習、讓自己的程式碼可以更乾淨、更好看!同時在這份工作上也學習用到Job的東西,好興奮啊!!!同時閒暇之餘玩轉了一下GraphQL ,恩 有更多的認識了,大概只剩下看看有沒有機會將這個技術應用到正式專案了…
    • API : 我們的產品其實是ios/Android 的 APP,我負責這後面的API 以及管理後台的API , 我發現,API 其實真的是一門學問,於是在許多次進坑後(被前端App team 譙) ,我去天瓏買了一本 Web API 建構與設計,App 的環境比較特殊、不能用以過去我那種以Web角度設計的API,能盡量少給API就少給API ,另外剛剛我買的那本書也提到要重視DX (Developer Experience) ,看來我還是要想辦法讓App/官網/前端 team 開心一點啊….. 之後看這本書如果有什麼心得感想會記錄在這個部落格裡面啦!如果想要知道更多資訊可以參考此網址:https://tw.alphacamp.co/blog/2015-04-22-api-dx
    • 對Mysql 的深入:如果你看過我今年的原來可以這麼寫系列,你會發現後面很多篇幅都在談Mysql 的技巧,不得不說,這算是今年很大的收穫之一了!
    • Docker 能力 level up : 藉著線上Hahow的課程、以及工作上也在使用,對Docker的操作與學習又更深入了一些,甚至覺得可以基礎的放進履歷的那種程度了
    • More AWS/CDK : 公司用了很多AWS 服務,像是Fargate , ECR/ECS 等等,對AWS可以說更熟了!這間公司玩AWS根本到了出神入化了啊,和我前一間公司只是開開EC2 差好多喔,另外也認識到了CDK….
    • NodeJS :  這次在公司也接到了一個NodeJS的專案,是金流交易的系統Lambda ,我們的產品APP 會打Lambda 扣點數交換課程,在這上面學習到很多、同時更是我第一個正式上線的NodeJS專案啊!同時我自己也有在Udemy 上有關於NodeJS的課程:NodeJS – The Complete Guide (MVC, REST APIs, GraphQL, Deno) ,對 NodeJS 掌握度也更深更多了呢 讚讚讚

未來目標

這裡就是嘴砲的地方了,不過既然如此還是希望自己要付諸實踐!寫下來就知道要怎麼實踐了~

  • 關於部落格
    • 一週一文章的計畫,以及希望可以寫更多Laravel deeper的文章~
  • PHP/Python/JavaScript 深化
    • 不知道明年可不可以挑戰寫一個自製 PHP framework ? 學習Swoole ? 同時自己也在Hiskio 買了一包 Laravel 組合包課程 (不過事後想想有點後悔。。。)
    • 買了一本 Python非同步設計:使用Asyncio, 明年要拿出來好好給他看看!
    • 結合今年上的Nodejs課程,當然要寫個NodeJS的部落格當練手看看啦!
  •  新語言學習:2021年,我想要開始認真擴展自己的技能樹,挑了兩門語言學習
    • Golang : 其實2020年就打算學Golang ,但就沒什麼系統,也沒有很認真,這次想要用一本書的時間,購買了深入淺出Go,用專門一個月的時間,好好學習Golang
    • TypeScript : 第一,我想要讓自己習慣強型別,第二,AWS CDK 比較支援的就是這門語言, 當然啦, 在前陣子心情不好也買了本相關書籍,所以當然要給他看完😅
    • ios 學習:不行,我還記得我的人生清單中有一項是上架一個自己的ios app 😂 明年不可以在落掉這項目標了啦!年初就給他行動起來啦!
    • Kubernetes : 覺得自己應該要好好認識這到底是三小東西……
  • 被年底 AWS Dev Day 演講煞到(參加心得):想給它真的很認真參與技術社群
    • DDD TW (想藉此好好學習DDD)
    • PHP也有Day or Taipei.py
    • 希望可以找一個G0v的專案好好給他埋下去
小君曰:明年的目標與想做的事情也太多,到底能不能一一完成呢?讓我們繼續看下去!

網站可靠性工程工作手冊導讀會一遊

最近工作上沒什麼事,可能是快要尾牙了吧?雖然一樣很多新需求、新功能追著我跑,不過每天都還算充實快樂,只是要努力的試著學習怎麼克服溝通這門學問…

於是乎,最近就常常十二月排了一些活動,像是這次天瓏書局協辦由江少傑(之前Yahoo 的工程師)帶了一場「網站可靠性工程工作手冊」的導讀會兼簽書會(笑,技術書籍也搞這個簽名會啊><)

基礎、基礎、還是基礎

原本從我們公司到天瓏書局很遠,光是六點準時下班都還是預計會遲到。中間我稍微跑了一下,發現還真的遲到了幾分鐘….不過還好,工程師們也都是忙碌的,因此活動還沒開始!

作者前面一直講很多翻譯的甘苦談、出版社的困境、現在技術學習的方式與以前不太一樣甚至談到教育與人生….哈哈,阿還有在Yahoo的工作等等,但我心裡想:我來不是想聽這些的啊><

不過講者也在過程中其實也算導讀一些東西啦,有點發散,大概我比較有印象的關鍵如下:

  • Agile , CI/CD , Scrum , Test 其實這幾個都互相關聯與奠基著,穩定與速度也互相關聯著。為什麼我們的軟體專案會失敗,其實就是不知道這中間許多的細節與關聯、盲目的導入只是帶來更多的坑
  • 一次只上一點點的改變,而不是一大包放上去,這才是CICD的做法、也是為什麼要自動上版的原因(想到我們公司CICD顯然就與這樣的想法背道而馳,而且還沒有測試,希望在我任內能將其補齊!)
  • 團隊之間必須要有「信任」,「信任」很重要,然後也讓我想到我在看這本書剛開頭也講到所謂的「不究責」的文化,這帶給我蠻大的提醒,我們不是要來抓戰犯、而是要共同一起解決問題、處理問題啊!
  • 這本書是一種案例研究,如果你企圖將書上講的方法都硬套在你的公司上,那只會帶來失敗,你應該要認真好好的認識與理解你們公司的domain , 學習到本書各案例背後的精神與概念,帶去case by case 解決你們公司的問題

我問的問題

在會後,我問了幾個很笨的問題

譯者回答,基本上應該是不會的,甚至可以直接看這一本也無所謂,就當成是案例研究,他也建議可以看第一本的內容互相對照,網路上也有免費的英文版可以看呢!

  • 做Developer不是SRE的角色,能看懂這本書嗎?

譯者說,不會,而且開發者也應該也要試著看看這本書,學習與他人「溝通」…這是蠻重要的等等,旁邊也有一個工程師也說到看得懂(看起來也是他的好朋友或社群夥伴吧?!)

剛開始讀這本書

我目前才剛看一點點而已,不過就有幾個概念對我蠻有所突破的。例如我們不該追求什麼「百分百可靠度」、也了解DevOps & SRE的不同、上面說到不究責的文化等等…

如果對這本書有更進一步的資訊可以參加FB的社團,在FB搜尋書名就可以看得到~

小君曰:DevOps也是一門學問呢但也是一種文化!!我也正在努力的學習中

2020AWSDevDay 一日遊

最近請了一天公假,和很多後端組的同事一起參加今年2020 AWS Dev Day, 這是人生的第一次啊!能夠與很多AWS 的開發者聚再一起,實在是件令人興奮的事,以下就簡短、簡單的分享一下吧!

早上的議程

早上其實是共同的議程,有Pahud 大大分享的「與開發者同行」以及Kim 分享的「技術人的社群影響力」,另外也有趨勢科技分享比較硬技術的「如何在 AWS 上建立大規模實時數據管道」,老實說,第三場有點聽不太懂,感覺與現實我遇到的情境真的相差甚遠,所以很難真正理解與明白他所談的一些概念,大概知道要有所「監測」才能有所證明,如果要證明自己做好,就可以用監測/Dashboard 的方式呈現給非技術性的團隊看,這種技巧可以記一下,至於其他技術關鍵字的部分,像是 AWS kinesis , Apache Flink 等等,可能只是稍微查查 wiki 了,看看以後有沒有機會遇到這樣。

至於其他比較軟的部分,大多都是談談「人生」,但我覺得可以記下的是「技術人的社群影響力」這一場,他讓我也重新再思熱情的重要,回想起當初讀資管、寫程式的小初衷。或許明年,可以選擇某個社群認真參加一下、投入一下,一個人可以走的快、但一群人可以走得更遠啊!

而另外我也很想在明年找一個G0V某個專案,好好給他投入一下,貢獻作為技術者的社會影響力!但說真的,還是要給他認真的付諸實踐才是真的!

謝謝在外面擺攤的DDD TW 的社群義工,當我很認真地問起DDD, 甚至問了很多很基礎很初學的問題都還是很不厭其煩地為我解答!說真的之前就大概聽過DDD,就我的理解上是一種軟體開發方法論,可以將業務知識對應到我們的程式的方法,我覺得真的很適合拿來放在我在做產品的工作場域!希望藉由之後認真地給他投入DDD社群的過程中,真正學習、認識、應用與實踐DDD。畢竟,作為工程師,還是希望自己寫一手漂亮、好維護、可傳承的程式碼與產品啊!Be a better Coder ! Also be a better Architect !

在下午的議程中,我先選擇了Track C 的第一場,之後就都待在Track A了…

CDK家族介紹:CDK, CDKTF 及 CDK8S

這場還蠻基礎的,因為先前參加過Pahud 的serverless php 工作坊,稍微認識過了CDK ,而在之後也有時候會看Pahud的Youtube影片學習,最近鐵人賽也有熱心人士分享CDK的學習(目前正在學習中) ,所以這場的知識量對我來說真的有點偏少,但也很不錯了,因為我直接跳過一些基礎或歷史直接學CDK難免還是會有點卡卡的,藉這此議程補足之前沒有補上的歷史與基礎也很不錯,當然啦,我覺得我不太認識Kubernetes也是一個小小的致命問題之一,學好Docker 卻沒有學好 Kubernetes真的有點傷啊! 看來以後要補足這一塊的知識!

運用 AWS Fargate 與 Amazon ECS 的 CI/CD 最佳實踐

這一場談到CICD的最佳實踐,說真的也是有點偏基礎,日常我工作就有在用到了….不過他談到一個Blue/Green 部署的概念可以放在心上,就是讓舊的版本先飛一陣子,只有一部分的人用新的版本,等到新的版本穩定了,再將原本舊的版本拿掉。這樣的好處是如果到時候要從新版本還原很方便(大概我是記得這樣啦XD)。

技術選型,今天要選 ECS Fargate 還是 ECS EC2 launch types

老實說,他其實沒有講什麼,最後也沒有真的大概指名什麼狀況要選Fargate,什麼時候要選Ec2 (之後可能還有ECS anywhere ??) ,大概整場就在講「燒烤店」吧(笑~ 。大過大概知道Fargate就是不太管、而 EC2就是要管理這兩種大差別吧,以及一些你可以選擇的場景XD

數數發 DevOps 的轉型旅程與 AWS CDK 實作案例

其實要導入DevOps 真的不太容易,他是一種「文化」、需要「溝通」、擁抱「改變」,我很佩服國泰金控居然有這這樣的一個中心願意為此而努力、跳下去做!而這場比較有點硬技術且讓我印象深刻的是CDK的撰寫要for function(合) 還是 for resource (分),其實沒有標準答案,帶他們團隊是採取for resource 的方式,另外,template的改變能越少越好,他們是有用一個叫做config.py的方式去載入一些真正會需要調整改變的地方,這帶給我寫code有不錯的技巧與工具啟發!

結論

這場AWS Dev Day , 可能我選的議程都比較基礎比較簡單吧?所以感覺寫起來沒什麼技術點,但我覺得基礎是很重要的!這是我最近進入職場寫程式一直以來所擁有的體會,有時候我們忽略的基礎,剛開始可能會真的沒什麼太大用,但你寫久之後,其實這些正是事後需要補足的地方!無論是本科系或非本科系的都是一樣!

小君曰:結果最後的airpod 沒抽到、然後報到禮和問卷禮都沒拿到,難道我這天只是來吃便當的嗎?

原來可以這麼寫(8): SAM 真的好好玩~

這篇文章有點廢,沒什麼技術點… 純粹是拿部落格當筆記的概念。

玩 AWS SAM

最近在玩AWS SAM CLI 部署 lambda ,真的好好玩喔,最近拿來部署好關於一些資料庫、SQS、KMS 等等的東西… 以下是我花了一點時間研究好怎麼寫template.yaml … 都要變成yaml 工程師拉!


 

更多的Mysql 研究

另外因為某個原因,讓我最近一直在研究database lock 的問題… 原來,加一個[for update]就可以達成了,真的好好玩~


select points from customers for update

資料來源:https://oldmo860617.medium.com/transaction-%E4%BD%B5%E7%99%BC%E9%8C%AF%E8%AA%A4%E8%88%87%E9%9A%94%E9%9B%A2%E5%B1%A4%E7%B4%9A-51b8af6178ae

https://blog.xuite.net/vexed/tech/22289223-%E7%94%A8+SELECT+…+FOR+UPDATE+%E9%81%BF%E5%85%8D+Race+condition

徹底解決Composer 記憶體不夠的問題

再裝某些Composer package 時常常遇到記憶體不足的問題,後來查到一個超棒的指令

COMPOSER_MEMORY_LIMIT=-1 composer update

資料來源:https://medium.com/@kycd.dark/%E5%9F%B7%E8%A1%8C-composer-update-%E6%99%82%E9%81%87%E5%88%B0-composer-memory-limit-aee4f2df56ee

小君曰:「真廢」

原來可以這麼寫(7): 資料庫筆記第一彈

在工作上被賦予資料庫Schema的設計責任

像是因應贈課功能、訂閱功能、關鍵字功能等等。也因此發現資料庫的學問真的博大精深
看來我還需要多多的磨練。

1. unsigned & zerofill

在資料庫常常看到unsigned這個字,最近想一想覺得要好好研究他,查了一下資料,就我個人的理解是:
unsigned: 將數字「無符號化」,意表這個欄位就是0 和正整數
zerofill: 在查資料也發現zerofill , 原來它是資料庫中,拿來前面補零的語法與功能。
文章來源:https://twgreatdaily.com/RbGjcW4BMH2_cNUgvI0q.html

2. 資料庫怎麼設計

在查資料發現一個很棒的github repo , 告訴我們怎麼設計schema 或怎麼最佳化實踐,目前有空會再看看,好好消化一下。分享一下:https://github.com/alextanhongpin/database-design

原來可以這麼寫(6): 換了一個佈景主題

我換了一個佈景主題,你知道的,後端工程師美感幾乎都不怎麼樣。我覺得我開發的佈景主題好像還是不是很好用、很美… 所以找了一個新的佈景主題,好看多了……

參加 AWS 工作坊

最近有機會上課,課程名稱是:PHP 開發者工作坊 -深入淺出 AWS 無伺服器 LAMP 架構(https://awsphpday.splashthat.com/),引用了外國人寫的一系列文章:https://aws.amazon.com/tw/blogs/compute/introducing-the-new-serverless-lamp-stack/

從這一系列文章,這個人定義出新的LAMP定義: L- Lambda , A- API gateway , M-Mysql , P-PHP。並且介紹如何實作以及實現。

之後滿心期待報名,甚至還報名了三次,兩次用私人信箱、一次用公司信箱。AWS真的有夠現實的,只有公司信箱報名的那個有成功XD 另外也發現原來我們公司的公假這麼好請XD 只要主管有同意就好 哈哈

有機會認識到Pahud 大大,他真的是一個很熱情的人,在會後請教他問題都很熱情地回答哈哈,同時也深入到Bref 這個套件、以及 Pahud 大大開發的套件可以如何方便的部署serverless laravel 在 AWS 上,我真的很期待這門課程也很開心得到很多不錯的收穫,同時也認識到AWS CDK,目前也正以緩慢的速度慢慢理解學習他(畢竟我又不是DevOps 哈哈)……

啊主要這門課程他就是在介紹他開發的這個套件:https://github.com/aws-samples/cdk-serverless-lamp

這個套件主要是依據AWS CDK為基底,做出符合serverless laravel 的contruct lib ,可以很方便的讓開發者使用開箱

AWS SAM CLI & Lambda

同時我的第一個 Lambda 專案終於開發到一個階段了,甚至也經過前輩的Code Review 完!真的很期待他上架的時候,除了是我第一個Nodejs 架上專案也是第一個 Lambda 專案,而且很認真的畫流程圖、一步一步開發規劃。就是可惜目前開發順序&上架就是有點混亂、這也是讓我有點不爽的地方,一直被「中間插件」… 然後等到上架可能又有更多東西要調…那開發者到底為什麼當初要規劃那麼多?幫使用者想那麼多?(不過軟體工程不就是需求常常會改來改去嗎? 真的很好奇更標準更專業的IT他們怎麼處理這一塊?)

同時,這個專案也要慢慢學習與習慣用SAM CLI ,之前我們公司的Lambda 管理與開發比較亂、現在有了SAM之後會比較好整理及有次序,能夠成為公司內導入這部分的其中一份子真的蠻令人興奮的!也希望我的 第一個 Lambda 專案可以趕快上去! 這樣我就又有一個成績可以炫耀(誤

小君曰:最近都在搞AWS呢