如何提升不同程式語言的技能

在Hacker Daily News上看到的一篇文章,作者提到了,當他發了一個PR到某個專案上時,專業的維護者的一些review 評論對他來說非常受用,也讓他了解到一些程式語言上 的特性與knowhow。

透過這個經驗,作者也發現了,當他去翻一些開源專案上的merged/closed PRs時,也可以發現類似的撰寫建議;所以他歸納這可以是一個通用法則,並且可以用在各個程式領域上:

I learned so much from reading the comments and concerns on my PRs. But it doesn’t have to be my PR. It can be anybody’s.

How To Rapidly Improve At Any Programming Language (cbui.dev)

簡而言之,在一個成熟且大型的開源專案上,開發與維護者通常都會是非常聰明且有知識的開發者,所以透過學習這些PRs 的建議與評論可以挖掘到許多無價的經驗。

因此作者也給了一些如何開始的建議:

1. Every morning, take your favorite open source library or one from a language you’re learning, go to the closed PRs on Github and start reading them from the beginning. Just a few a morning for warmup while you drink your morning coffee and catch up on email.

2. When you want to level up, start reading the diff, and review the code and changes yourself before reading the comments.

3. Finally, when you start feeling more confident, start leaving those comments on new PRs so that the maintainer doesn’t have to. You’re starting to contribute to open source!

How To Rapidly Improve At Any Programming Language (cbui.dev)

原文可以參考這裡:

How To Rapidly Improve At Any Programming Language (cbui.dev)

如何有效的學習

在Hacker Daily News 上看到的一篇文章,在分享如何才會有效的學習。

作者分享了一些他的經歷以及相關的結論,但由於文章內容蠻長的,大概快速的掃過一遍以後,大概就節錄一些作者最後的列出的Key points。

Key Points

You can’t rely on intuition about how well your studying practices are working for you. Intuitive judgments of learning are often inaccurate and tend to produce an inflated perception of progress.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

不要用直覺來去評斷自己的學習成果,這通常會導致不正確的評估,最後可能高估自己的學習成果。

Avoid defaulting to habitual, passive approaches to studying such as rereading and highlighting sources. These do not take advantage of the reconstructive nature of memory, and make it more tedious and less effective.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

不要用一些習以為常的被動學習方式去學習,重複的閱讀重複的內容,或標註重點字句並不會讓學習變的有效。 (當你標註某個重點時,試著去理解為何它是重要的。)

Systematic engagement with the meaning of your source material is the key to successful studying.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

系統性的學習手頭上的資源會是非常重要的 !

Rather than cramming your studying into an extended session before the exam, it’s much more effective to distribute the time you have available for studying over a larger number of shorter sessions.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

在考試前的臨時抱彿腳對學習是沒有幫助的,試著有效的分配自己的時間,並且做好時間管理來學習才會真正有效學習。

When you are studying similar topics that might be easily confused, it’s a good idea to interleave your studying – to alternate between the topics during your study sessions. This can help you identify the differences between the topics and reduce the chances of them being conflated.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

對於類似的主題,如果有理解上有感到困惑的話,試著去交錯的去閱讀相關的主題,如此一來,會有助於理解不同主題的相似與相異之處。

You should view self-testing as an integral part of your studying. One way to do this is the read, recite and review (3R) method: read a section of text, set it aside as you try to recall its content in your own words, and then check your recall, repeating as necessary.

https://psyche.co/guides/how-research-from-psychology-can-help-you-study-effectively

自我評量也是非常重要的,有效的學習通常伴隨著有效的衡量方式;作著提出了3R (Read, Recite, Review) 來幫助自己評斷學習成果。

想法

通常對於這種類似文章,我都會稍微掃過就好;不過這篇文章整理出了一些重點,而且這些節錄的重點又都是以前曾勿略的地方,剛好趁這個機會作點記錄讓自己以後可以有些回顧。

Reference:

How to study effectively | Psyche Guides

CTO與VP of engineering的差別

一直以來,我對於這兩個職位的想象都是…

“這應該只是公司不同,所以對同一個role有不同的職稱而已;基本上它們就是 Dev/IT 的最高執行角色,並且直接向CEO報告!?”

但在某一次 1 on 1 與DK 剛好聊到以後,才發現原來這兩個角色是完全不同的,它們有各自需要關注的方向,並且同時report給CEO。

CTO, Chief Technology Officer

CTO 這個角色主要工作範籌在於公司未來的技術發展,他必須評估公司長期的技術需求,帶領團隊開發相關的技術,並確保當業務發展到某個時間點時,其相關的技術都已經ready了。

像是Amazon的CTO的工作就是在帶領團隊專注在Amazon 未來5-10年技術開發,比較有名的例子是:Amazon DynamoDB 這篇paper就是由CTO帶領團隊來發的…

VP of Engineering

這個角色主要是關注公司目前的技術發展,而他所帶領的團隊會需要開發各種技術來應付目前的業務需求。 (但大多數的公司的CTO其實在做 VP of Engineering的相關職務)

評估技術導入的一些方向 – message queues

前言

這星期與DK剛好有討論到,我們在新專案上可能需要一個scalable distributed message queue,由於預期單一個queue的qps 可能會很高,所以效能也會是一個重要的考量點之一;在這個前提下,我們開始去找了一些可能的選項…

我自己的Survey過程

在整個survey的過程中,我主要考量的點會是:
(1) 效能,因為我們的需求就會是需要高效能的queue。
(2) 社群成熟度,畢境若社群不成熟的話,可能遇到很多的坑必需自己想辦法處理。
(3) 相關的生態,對目前團隊的使用上來說,是不是有完整的支援。
(4) 目前有在production上使用的公司,我會去看說目前這套服務是否有知名的公司取用了!?

想當然,上述的考量基礎其實還是很薄弱的;而DK 在這次的討論中分享了他的一些觀點,我覺得蠻適合再記錄一下。

DK提出的一些觀點

首先,他認為可以朝兩個大向來找我們會需要解缺方案:

市場上的成熟方案

成熟的方案通常設計上已經經過驗證,有完整的一套生態系統,相對而言,可能會有很重的dependency。
而Kafka 算是這種方案中的一個選項,除了資源吃了多一點外,其他都很完美 (尤其是 scalability);不過相對而言,因為Kafka在最初設計時就不是以message queues的出發點來設計,所以一定會需要做些額外的工作才能使用它…

市場上還不夠成熟,還未經過大量使用的方案

這時候會偏向降低依賴性,也就是盡可能讓 dependency 可以抽換,也就是說,我們不希望導入以後這個服務要換成另一個方案時是困難的…

而從我們專案的需求上,他列了下面的考量點:

  • Scalability
    由於我們原本的需求就是需要可以scale的queue,所以這也會是首要考量之一。
  • Data Integrity
    當有機器 crash 時是否可以確保資料不掉,保護能力夠強,對於開發者來說用起來會簡單。
    (這點我還真的一開始沒想到queue會有可能掉資料這件事,這真的是經驗太少了,又學到一課。)
  • High Availability
    HA主要在維運上也的是個重要的考量點,如果HA不好做的話,就會大大影響到實際上維運的困難。
  • Documentation completeness
    文件完整度對使用者來說是非常重要的,這才有辦法知道使用上的一些資訊。
  • Community support
    如果社群不成熟的話,很有可能會再使用一陣子過後沒有人再維護了;而且,也有可能會遇到問題時,找不到前人的經驗,只能自己解決。
  • Commercial support
    這也是蠻重要的,對商業使用上的支援度。畢境,若一個好用的方案伴隨著不友善的商業授權的話,我們也無法使用在現有的環境。

如何找尋一個技術方案的相關資訊

這邊我也是覺得蠻值得記下來的地方,DK有提到說可以從 hackernews,slideshare, speakerdeck 上找某一個方案的相關資訊。

像是從hackernews上,可以找到關於某個方案的相關新聞;舉例來說,這個討論串就有提到Apache Pulsar被splunk買走以後的一些資訊。

另外像是slideshare, speakerdeck上,我們可以找到某個技術的一些分享簡報,而從那些簡報的多寡與其中的內容,我們就可以挖到更多趣的資訊;比如說,使用上的一些抱怨…等等。

最後

最後我們重新review了一些我們的架構,發現我們所需要的scalable message queue可能實際上是不需要的,是我之前設計的架構上的缺失,才會衍生出這一個問題;所以回到源頭去重新修正整個專案架構可能才會是一個解決根本的方式…

不過這個討論讓我感覺得受益不少,自己架構方面與技術選型這一塊還是非常的不足!
原本,我覺得Apache Pulsar是蠻符合我的期待,但DK分享了一些對Pulsar的想法,像是:

  • 定位上是”Better Kafka”,但可能會影響之後對於Message Queue這功能的發展。
  • ZooKeeper + BooKeeper 的架構相對於Kafka目前想要去掉ZooKeeper的方向還是有差,Kafka若沒有ZooKeeper以後又會更為簡潔。所以Pulsar在維運上會需要花更多的心力…

這些點都讓我覺得,有太多面向需要去額外考量一個服務的導入了…

References