強制每個 Git Repository 都要設定使用者資訊

看到「Setting Up Git Identities」這篇,裡面提到的方法可以解決 Git 裡有多個身份時常見的用錯身份的問題...

個人的 Git repository 會希望用自己的 email address,而公司的 Git repository 則是希望用公司的 email address,但 Git 預設會使用 username 與 hostname 組一個出來,所以常常是推到公司的機器上後才發現 Git repository 沒設定公司的 email address...

上面提到的文章就是關掉 Git 預設會組合的行為,於是就會記得要設定了:

git config --global user.useConfigOnly true

然後記得要把全域設定裡的 nameemail 拔掉,另外有些人可能會掛上 signingkey 也一起拔掉:

git config --global --unset user.name
git config --global --unset user.email
git config --global --unset user.signingkey

這樣當沒設定時想要 git commit,就會被擋下來要求你提供,就能避免把自己的 email address 混在公司的 Git repository 裡面了...

用 PoW 當作防機器人的方式

看到「wehatecaptchas」這個服務試著用 PoW (Proof of work) 擋機器人...

這個方式不需要像 GooglereCAPTCHA 那樣蒐集大量行為 (對隱私不利),也不需要解一堆奇怪的圖片問題。

CAPTCHA 最常用的領域,也就是擋 spam 這件事情來說,PoW 這樣的單一方式應該是不夠,但可以當作綜合方法裡面的一種...

對每個月一次的「Ask HN: Who is Hiring?」分析

timqian/hacker-job-trends 這個用 Node.js 開發的專案是針對 Hacker News 上的「Ask HN: Who is Hiring?」分析 (每個月一篇,拿來提供各家人馬留 comment 徵才的),把關鍵字丟進程式,程式就會分析每個月的出現數量,在 terminal 上產生趨勢圖表。而且支援加法或是減法計算,可以用在去掉重複的字 (像是 javajavascript)。

遠端工作的量慢慢增加:

而區塊練的量也在增加:

裝起來後看 php 的量好慘啊 XDDD

2011 年的研究,開放辦公室與病假的關聯性

忘記從哪邊冒出來的連結,反正是個 2011 年的研究:「Sickness absence associated with shared and open-plan offices--a national cross sectional questionnaire survey.」。2011 年在丹麥的研究:

METHODS: The analysis was based on a national survey of Danish inhabitants between 18-59 years of age (response rate 62%), and the study population consisted of the 2403 employees that reported working in offices. The different types of offices were characterized according to self-reported number of occupants in the space. The log-linear Poisson model was used to model the number of self-reported sickness absence days depending on the type of office; the analysis was adjusted for age, gender, socioeconomic status, body mass index, alcohol consumption, smoking habits, and physical activity during leisure time.

都是與 cellular office 比較,可以看出大於六個人的開放辦公室病假的量高出許多:

RESULTS: Sickness absence was significantly related to having a greater number of occupants in the office (P<0.001) when adjusting for confounders. Compared to cellular offices, occupants in 2-person offices had 50% more days of sickness absence [rate ratio (RR) 1.50, 95% confidence interval (95% CI) 1.13-1.98], occupants in 3-6-person offices had 36% more days of sickness absence (RR 1.36, 95% CI 1.08-1.73), and occupants in open-plan offices (>6 persons) had 62% more days of sickness absence (RR 1.62, 95% CI 1.30-2.02).

CONCLUSION: Occupants sharing an office and occupants in open-plan offices (>6 occupants) had significantly more days of sickness absence than occupants in cellular offices.

看起來只是拉數字出來分析... 另外信心區間的洞好大 XD

兩個都用 Slack 的公司可以直接在 Slack 上合作了

Slack 推出的新功能 Shared Channels:「Introducing Shared Channels: Where you can work with anyone in Slack」。

Shared Channels are a new kind of channel that connects two separate organizations, creating a common space for both sides to make use of Slack’s communication features and platform integrations when working together.

在截圖可以看到界面上,左半部會以 Shared Channels 顯示:

這邊也有提到 Shared Channels 需要透過管理員核准:

Accept the request: The other organization’s admin will receive a direct message from Slackbot, from which they can accept your request and add the channel to their workspace.

這樣就不用另外再開 guest 了...

創業的點子

在「Startup idea generator: find spreadsheet tasks and build something better」這邊看到很有趣的想法 XDDD 原討論區出於 Hacker News 上的 id=14631031 這則。

找到還在用 spreadsheet (或者說,Excel?) 的用途,然後設計新的產品 XDDD

1) Pick an industry
2) Ask someone in that industry what they use spreadsheets for
3) Build something better

算是一種很有趣但是也還蠻實際的想法 XDDD

在程式競賽得獎負面相關於工作的品質

2015 的文章以及演講,最近冒出來看到的。GooglePeter Norvig 提到了用 ML 的方式分析,發現程式競賽的成績與工作品質的負面相關性:「Being good at programming competitions correlates negatively with being good on the job」。

換句話說,程式競賽的成績反而是是個負面指標 (對於 Google 內的情況分析出來的,所以是基於 Google hiring process 的前提過濾過的)。

In this talk, Peter talked about how Google did machine learning and at one point he mentioned that at Google they also applied machine learning to hiring. He said that one thing that was surprising to him was that being a winner at programming contests was a negative factor for performing well on the job.

給了一些對原因的猜測:

Peter added that programming contest winners are used to cranking solutions out fast and that you performed better at the job if you were more reflective and went slowly and made sure things were right.

YouTube 的留言處也有一些猜測,像是:

What he's talking about is the fact that several extremely important parts of software engineering are not included in these contests, for example code reusability, maintainability, decomposition of the problem using the OO paradigm, etc. All of these make a good engineer, but are not necessarily needed in competitive programming contests.

「把工作自動化」的討論

最近在 The Workplace Stack Exchange 上還蠻火紅的一篇文章:「Is it unethical for me to not tell my employer I’ve automated my job?」。

作者的全職工作是從系統上抓資料出來,貼到 spreadsheet 上 (也許是 Excel?),這份工作的薪資還不錯,然後作者寫程式自動化掉後發現他每禮拜只需要做一兩個小時了:

There might be amendments to the spec and corresponding though email etc, but overall, I spend probably 1-2 hours per week on my job for which I am getting a full time wage.

然後在糾結要不要跟雇主講,跑上來發文 XDDD 有興趣的人可以去圍觀看一看下面的回應...