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

作者: r567tw

是一名住台北的一位台東developer,最喜歡"忠心"這個形容詞。這一生希望完成三件事:寫一本書、站在TED演講、寫一支 ios app 上架。想要成為橋梁,做福音的行者,期許自己能夠不斷學習、不斷練習、不斷地傾聽、接納、尊重、回應。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *