dangra

from scrapy.spider import BaseSpider
from twisted.internet import reactor, defer
from scrapy.http import Request

DELAY = 5 # seconds


class MySpider(BaseSpider):

    name = 'wikipedia'

hellerbarde

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

myusuf3

To remove a submodule you need to:

• Delete the relevant section from the .gitmodules file.
• Stage the .gitmodules changes git add .gitmodules
• Delete the relevant section from .git/config.
• Run git rm --cached path_to_submodule (no trailing slash).
• Run rm -rf .git/modules/path_to_submodule (no trailing slash).
• Commit git commit -m "Removed submodule "
• Delete the now untracked submodule files rm -rf path_to_submodule

AKB428

リーダブルコード読書会及び要約共有会の目的

• 今後コードレビュー時に「これってリーダブルコードの◯◯だよね？、こう直したほうがいいよね」と引用できレビューの時間の短縮化が実現できる。
• リーダブルコードに登場する特殊ワードをチームのコーディングの共通語とする。デザインパターンのカタログ的な考え。
• リーダブルコードを読んでない人も内容を短時間で把握できる。
• チーム全体のコードを読みやすくメンテナンスしやすくし品質をあげる。
• リーダブルコード教になりチーム以外にも広める。コードの品質が悪い人にはリーダブルコードの読書を進めてみる。ひどいコードのままコーディングしてもらうよりその時間を読書の時間に割り当てることも考える(結果的に時間が還元できるなら）。
• リーダブルコードに書いてあることが全てのプロジェクトに適用てきるわけではないけれでもコーディングルールを考える際の指針にすることはできる。

対象者

yossorion

What I Wish I'd Known About Equity Before Joining A Unicorn

Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.

This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would

noto

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

• 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
• 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
• グループ/チームでのミーティングを補完するためのものです。
  • みんなの前では話しづらい、込み入った内容を話します。
  • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
• 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
• ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうｗ)。