原來可以這麼寫(13): 其實我會一點點Ruby

都在 SQL啦,哪次不SQL

最近工作主要的部分是幫忙營運單位做資料匯出相關需求,沒有同事在說我還以為去年我應徵的是「資料工程師」呢!

不過說真的,其實我很喜歡「資料庫」,喜歡SQL語言,所以其實我覺得做這些東西是在挑戰自己、很好玩…. 更期望之後可以碰碰其他的SQL 像是PostgreSQL 啊、Oracle 之類的。

總之我覺得藉此經驗能挑戰自己寫SQL 也很不錯,雖然有夥伴說其實你就匯出Row data 給他們就好啊,叫他們自己拉Excel 做就好…. 但我就是想要幫忙他們解決問題麻😅

真不知道如果要應徵DBA ,我這種粗粗淺淺的菜鳥經驗能不能試試?

沒梗了,來講Ruby

簡單交代一下最近工作狀況,也紀錄自己的歷程。本來這個系列就是要來記錄的啊~

每個月我們都有小組例會,每個月大概一個人會有這麼一回吧…. 總之,我發現我有點沒梗了,所以來分享一下自己以前自學的語言:Ruby

然後沒有想到,AWS Lambda 竟然有支援Ruby , cool ! so fun !

雖然我有在這裏寫一篇文章Ruby 筆記,不過那都沒什麼排版,我也懶得改XD

以下就是我之後將在例會報告的PPT啦

小君曰:其實我會一點點的Ruby啦,不知道這樣能不能應徵Ruby Engineer ? 哈

原來可以這麼寫(12): 我❤️Golang

最近處理兩個大功能,一個是要建立websocket server 讓交易流程去串(開發官網購買)(但說真的交易流程用websocket 真的有點怪怪的?就我的認知 websocket 的部分應該是在一個很即時的情境,但用在這種只是為了獲得通知的目的確實有點怪怪的… 但說真的我也沒有辦法提出更好更優的方案,作為一位只能聽命行事的超基層也只能照做QAQ)

另外是要做有關於批次匯入的功能…. 呵呵以前就有做過類似Excel 匯入的功能,我深知道那是一個巨大無比的坑,坑是在一開始的規劃,你既然開放前面使用者可以用Excel 檔匯入,那你就得面對使用者的Excel檔可能有千起百怪的樣式、無法驗證或無法預期的輸入…套句我之前有位主管說的話:你要防使用者想防賊一樣啊!

總之,這個功能其實去年有做一下下,但後來被靠北中止了….現在又復活,當然給他們凹一下,仔細把流程討論清楚先,然後再做…. (其實正確的流程及我想表達的意思是:PM/SA 你們給我生出流程圖和規格書啊!

然而,在這兩大功能夾擊下,我算是很平安的度過及學習、開發,並沒有像之前趣聽小說匯入被搞得人仰馬翻、混亂不已….在這個過程中,修修幾個bug、調整幾段程式碼…. 其中一項是調整拆帳報表的功能

原本,我是用Laravel 匯出拆帳報表,並用上 Laravel-excel 這個套件,殊不知測試環境都弄好好的,但到了正式就完蛋(匯不出來)

因此,我發現當前端送 request 直接製作檔案的這個版本實在有點….糟糕。

後來規劃出了第二套版本:就是當前端送出request 後丟到queue後再慢慢做… 也是一樣用到剛剛說的那個套件,那個套件可以很輕易的用queue的方式製作excel 檔。

測試環境一樣好好的,但正式環境還是爆掉…. 後來發現只要調大我們機器的CPU 就可以匯出了….,不然就是我真的功力不精無法好好使用這個套件囧!

但是!每次調大機器CPU 實在不是什麼好方法…. 而同事告訴我:不應該堅持用laravel/php處理這種CPU bound的事項…. 於是….我採用的AWS Lambda 方案,而Lambda 用Go 開發….

結果是:原本用Laravel Queue要跑兩三十分鐘的報表居然奇蹟的在5~15秒內搞定

然後再寫的過程當中也越來越喜歡Go這門語言。不過我知道我要學習的還太多,這在我使用Go上面只是剛開始而已。

謝謝後端團隊的大家讓我可以任性的使用看看這門語言,並且在我有問題的時候願意幫助我^^

於是乎,這個月的技術分享會就分享我使用Golang的心得了……

額外加碼:

最近docker 使用上常常有那個build 失敗的image 和container bla bla 的,最近看到一個很好用的清除指令紀錄一下:docker system prune

小君曰:想要轉職成Golang 工程師。。。

原來可以這麼寫(11): 每個人的心中都要有DevOps

最近工作比較沒有什麼新鮮事,所以開始在將手上專案有比較完整的文件化之後,開始逐步導入TDD ,寫一些Unit Test 以確保程式碼的品質。

但老實說:我還是不是太懂Laravel Feature 和 Unit 這兩個資料夾的區別?我知道Unit 是要做單元測試,是測試那個類別的行為,但我目前大多都在寫Feature Test… 如果有大大知道Unit 該在何時寫、什麼情境下要寫,歡迎不吝賜教!

研究Socket/API Gateway

因為要導入官網購物車購買,討論一連串的流程與討論,最後希望我Laravel 要開一個socket server,但研究的結果其實發現 因為我們專案的版本比較低,所以沒辦法使用Laravel-Websocket 套件,也就是在Laravel 裡面自己開socket server 那種,變成我們要另外用Node 的套件去建立… 然後… 又衍伸第二種方案,在AWS Api-gateway 架起websocket api ,然後他可以指定動作去call API…

這個方案很好玩… 不過在研究初期卡關在怎麼用Laravel 取出 connectid , 因為AWS example 是用Node 的Lambda 去串的,很簡單就取出connectid… 。我Laravel 怎麼print request 的body 還是 header ,顯然就是找不太到那個connectid …

後來實在有點卡太久了(大概一天),被同事叫我去寫AWS Support XD

人生第一次寫AWS Support 耶,然後AWS 團隊真的很用心很貼心,告訴我很詳細的步驟及方法、解決方案,原來,如果要讓Laravel 的 後端讀得到 connectid ,是要透過CLI 去設定啊… (目前API gateway 控制台還沒有支援這個),不然就是需要把integration type 改成 HTTP ,去寫 request template 這樣。

總之,這次經驗讓我更認識 API gateway 和 socket 啦!預計之後想要開一系列深入研究Laravel 的系列,想要寫broadcast 的部分,希望今年可以完成這個寫作計畫 ^^

網站可靠性工程工作導讀

我們每個禮拜都會有小組的例會,小組的成員都需要報告一下我們各自的狀況與專案進度,然而在今年我們組長要求大家輪流每個禮拜都要分享一下技術議題,不管他是前端還是後端皆可。

我個人覺得這是很好的一個文化,但最近也常常聽到同事在講對他們有一點小小的loading…。有點不知道耶,明明是很棒的事情為什麼反而有點造成不太好的效果?我們的專案真的有點多而且每個人負責很多啊,不太平均……

話說回來,大概這樣輪流每個人平均一個月講一次,所以這個月就帶來我讀網站可靠性工作工程的心得與收穫~

之前,也曾經參加這本書的導讀會,大家可以參考:網站可靠性工程工作手冊導讀會一遊

然後值得一講的是後面補充文章有一則:技術債觀念及實務
因為在查一些SRE 和 DevOps 相關文章時就不小心逛到,在這篇文章讀到:

另一方面,著有《Domain-Driven Design》一書的 Eric Evans ,對於處理舊有程式碼(legacy code),也曾提出過一個叫做「戰略設計(Strategic Design)」的觀念。Eric Evans 認為,在一個系統中,根本不可能所有的程式碼都維持夠高的品質,而且,有些情況下,有些程式碼也沒有必要一定非得是高品質。這是個相當務實的觀念,如果我們很現實的來計較在開發過程中每一份生產力的 C/P 值,那麼,維持一些程式碼的完美,需要付出的代價太高,但這些程式碼即使完美對整個系統的效用卻不大時,是否應該讓它們也被一視同仁地被維持高品質?

By 技術債觀念及實務

這帶給我寫程式上面莫大省思與體悟,原來,寫程式也像DevOps 一樣「不應該」去要求百分百可靠度(完美)

以前我都覺得自己要每一行寫得很棒很好,這是一種工程師對自我的要求… 反而導致每一次我寫功能之後就會每次檢討自己、總是花很多時間在想下一次怎麼可以寫更好,但有時候下一次也不一定像這一次可以要求寫得很好…

而DevOps 和剛剛讀到的技術債觀念及實務帶給我在寫程式上面的一個心態轉變,應該要對於不同的程式碼有不同的權重分配,有些可以選擇粗略地寫,只要功能有夠、排版讓人覺得算ok,這樣就好;而有些需要好好每次的重構每次的改善,讓程式碼可以越來越易讀!

總之,這是我當天報告用的ppt ,希望能幫助到大家~

小君曰:每個工程師的心中都應該要有DevOps !

原來可以這麼寫(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工程師?

原來可以這麼寫(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呢

原來可以這麼寫(5): 原來MySQL 博大精深

最近工作接下交易與金流的部分,開始將自己最近火燙燙學習的 Nodejs 來拿去試試水溫。不過,被callback 弄的昏頭轉向的…. 所幸,最後藉著文件與冷靜,慢慢的下斷點、看結果,參考之前前人寫的code , 才慢慢走出來,甚至處理到進度似乎發展還不錯。

MySQL 的 insert 新寫法

因為專案需求,我雖然接下這個舊專案,但是要開發新功能,於是,我覺得可以趁此改善專案架構與程式碼品質,原本程式碼的SQL 是用那種字串方式連結的,但我知道這樣會有SQL injection 的問題,所以在新功能&參考舊程式碼的過程當中,也慢慢的將字串方式改成可以防止SQL injection 的方式。同時也意外發現Mysql insert 有新的寫法:


INSERT INTO table SET a=1, b=2, c=3

比起原本冗長INSERT INTO table (a, b, c) VALUES (1,2,3), 我覺得這種set 的方法真的很不錯,這樣在對照上及程式碼易讀性也更勝一籌,所以覺得可以評估是否要引入的可能性…..

參考資料:https://stackoverflow.com/questions/861722/mysql-insert-into-table-values-vs-insert-into-table-set

參加LaravelConf 2020

其實本週還真的沒啥事情,除了就是討論、開發、維護、就是這些不斷的循環…. 工程師的人生就是這麼平凡無奇,但週末參加了 LaravelConf 2020 , 這次我買的是線上回放票,整體下來感覺很不錯,聽Ant 大大的對PHP&Laravel 之未來的一席話,真的有所感受與領悟啊!然後我覺得比起之前參與過的2017、2019,我發現我又更加聽懂了很多內容,覺得感受到自己的成長真的蠻棒的,不過整體的心得文與筆記我想之後會再好好整理起來。現在還有安可場,可以再去買票去聽啊

小君曰:工程師的生活就是這麼平凡無奇,且有趣

原來可以這麼寫(4) : 終於接新專案

近況

最近工作終於接到新的任務,雖然還是在同一個專案…..

事情是這樣的,我們那個專案的後台分成兩個部分的人負責,一個是後台、另外一個則是交易…..而我進來公司後,一直都是處理後台,對於交易都是一知半解,只知道要打Lambda 而已。而這次,在專案時程終於沒這麼趕的情況下,以統一後端接口(俗語說:天下大勢,合久必分、分久必合),我被授命要接下這交易功能的後續維護&開發新功能…. 這對我是一種挑戰,因為我終於可以有段時間不用繼續和PHP掛勾拉XD (交易lambda 是使用NodeJS)

況且,最近也剛學習了一點 NodeJS, 前陣子上完六角學院的 NodeJS 課程,很期待可以將自己新學習到語言運用到實務專案,不過之後還是要多多進修將nodeJS 補齊基礎拉,而且這個又是金流與交易,其實我自己說實在有點抖抖的&很興奮能接到此挑戰!

總之,為自己加油拉!而且其實也沒用到太高的技巧,那些 nodejs  其實還算好懂的

Mysql: COALESCE

因為在 trace 與理解交易商業邏輯的 code 當中,我看到我們用到COALESCE 在SQL語法中…原來,他是一個好方便的參數啊,可以回傳在列表裡的第一個非null的值。

例如

SELECT COALESCE(NULL, NULL, NULL, 'W3Schools.com', NULL, 'Example.com');
這行sql 語法就會回傳 ‘W3Schools.com’

相關可以參考的資料:https://www.w3schools.com/sql/func_mysql_coalesce.asp

沒用過還真的不知道可以這樣用啊!

強化與習得Docker技能

在今年初,看到Hahow 上面有個關於Docker 的新課程,在最近終於把那門課程上完了,雖然,自己本身工作就已經在使用Docker了,而且為了讓自己可以弄個舒服的開發環境,以符合自己早期的開發習慣,還自己簡單刻了 docker-compose.yml , 好讓自己資料庫可以用自己本機。(我們專案資料庫是用AWS RDS),所以早在上課之前對Docker 就有略知一二。不過,經過有系統的整理後確實能對Docker有更多的理解。像是中間會多了一個虛擬Linux container層,而每一個命令都是新的Container層而互不干擾,他的教學其實還蠻淺顯易懂的,我這裡可以推薦一下:Docker 部署入門完全指南-圖片速學攻略(https://hahow.in/courses/5df27f1fa5ee510022a08500/main)

不過之後還是會想研究一下,會有點想要像我們公司專案一樣,把 Laravel 部署到 Fargate 的部分……

小君曰:接到新專案囉,雖然還是在一刻(我們公司產品簡稱) XD