800円以上で送料50円引き
- 全体的な意図。なにをどうやって実現するのか(What, How)。
- 変更の文脈、位置付け。なぜこの変更が必要なのか(Why)。
- 複数の独立した問題が含まれているか
- 含まれている場合、分割できないか検討する
- 設計の誤りは影響が後を引く可能性があるので、なるべくちゃんと見ておきたい。とくに永続化されるデータ構造のミスは、リリースしてしまうと修正な面倒なので、注意する必要がある。例えば:
- SQLアンチパターンに該当するようなテーブル設計になっている(実データが発生するとめんどう)
- 本来別のAPIを新設すべきところを、既存APIへの追加パラメータで無理矢理処理している(修正される挙動への依存が増えるとめんどう)
- 手続の種類が増えても修正不要なように書ける(一度書けば済む)のに、手続の数だけコード追加が必要な設計になっている(無駄な手数が増える)
- 追加・変更される挙動について、テストケースが追加・変更されているか、テストケースの見出しレベルで簡単に見る
- 特殊な理由のある変更など、コードだけから理解できなさそうな変更は、コメントに経緯が書かれているかを見る
yarn run v1.22.18 | |
$ /Users/tai2/Sync/Code/myapp/node_modules/.bin/appium | |
[Appium] Welcome to Appium v1.22.3 | |
[Appium] Appium REST http interface listener started on 0.0.0.0:4723 | |
[HTTP] --> POST /wd/hub/session | |
[HTTP] {"capabilities":{"alwaysMatch":{"platformName":"ios","platformVersion":"14.4","deviceName":"iPhone 12 Pro","app":"http://localhost:8081/app.zip","newCommandTimeout":1200,"language":"en","orientation":"PORTRAIT","noReset":true,"processArguments":{},"clearSystemFiles":false,"skipLogCapture":false},"firstMatch":[{}]},"desiredCapabilities":{"platformName":"ios","platformVersion":"14.4","deviceName":"iPhone 12 Pro","app":"http://localhost:8081/app.zip","newCommandTimeout":1200,"language":"en","orientation":"PORTRAIT","noReset":true,"processArguments":{},"clearSystemFiles":false,"skipLogCapture":false}} | |
[debug] [W3C] Calling AppiumDriver.createSession() with args: [{"platformName":"ios","platformVersion":"14.4","deviceName":"iPhone 12 Pro","app":"http://localhost:8081/app.zip","newCommandTimeout":1200," |
「事業をエンジニアリングする技術者たち」読んだ。
https://www.lambdanote.com/collections/engineers-in-voyage/products/engineers-in-voyage
いやー、くっそおもしろかった。VOYAGE GROUPは広告やゲーム攻略サイトなどいろいろなプロダクトを持っている。それらを作ってきたエンジニアたちへのインタビュー集。
中でも圧倒的に面白かったのが、第3章のECナビの話。ECナビは、1999年からある20年もののシステム。2015年の時点で誰も全容を把握している人がいなかった1200テーブルを超える巨大レガシーシステムを、5年の歳月をかけて、いかにして把握可能な状態まで持っていったか。はっきりいって、めちゃくちゃかっこいい。痺れる。「お花畑」とか「葬り無双」とかの独特のネーミングセンスも笑える。
他の章ももちろんどれも面白い話ではあった。けど、神ゲー攻略とかデータサイエンスの話は、超絶優秀なエース級の人アサインしたら、その人がうまくハマってくれて、ほぼ1人でなんとかしてくれたっていう話で、へーすごい人なのねという感想は持つけど、言ってみれば、そこらへんにありそうな話でもある。けど、ECナビの話は、一から作り直すこともできないほどの巨大なシステムを、長期間かけて計画的にこつこつ改善していったということの、並大抵でなさに感動する。やり遂げたエンジニアたちに畏敬の念を抱く。あなた達はすごい。
import socket | |
import time | |
import threading | |
RECEIVE = False | |
#RECEIVE = True | |
NUM_THREADS = 300 | |
finish_flags = [False for i in range(NUM_THREADS)] |
function zcd() { | |
cd $(z | tail -r | fzf --layout=reverse --cycle | awk "{print \$2}") | |
} | |
function ge() { | |
FILE=`git grep "$@" | fzf --layout=reverse --cycle | cut -d : -f 1` | |
nvr --remote $FILE | |
} | |
function gt() { |
特に重要なのは、先に数字を言った方が確実に不利になることだ。どのような交渉でも、自分の条件はあとから言うようにしたい。理由はこうだ。たとえば、ある募集に応募して、そのポストの給与は7万ドルだと見込んでいたとする。採用が内定して最初に尋ねられるのは、給与としていくら必要かだ。そこであなたは7万ドルくらいのポストを探していると答える。もっと賢く、7万ドルから8万ドルの範囲で、と言うかもしれない。採用担当マネージャーは、すぐに7万5千ドルではどうかと言ってくるだろう。あなたは首を縦に振り、契約を受け入れ、めでたしめでたしとなる。ただ、この話には大きな問題がひとつあった。その採用担当マネージャーは、8万ドルから10万ドルの予算を立てていたのである。あなたが先に数字を口に出したので、年に2万5千ドルも自分を割り引いてしまったのだ。これは極端な例だと思われるかもしれないが、そんなことはない。他人がどのような額を提示するかは、相手があなたに言うまでわからない。先に自分の数字を言ってしまうと、あなたは確実に不利になる。あなたは自分が言った額より上を要求するわけにはいかなくなるが、交渉でその額よりも引き下げられてしまう可能性はある。先に数字を言ってしまうと、上はなくなり、大きく引き下げられる危険だけが残る。
ジョン・ソンメズ. SOFT SKILLS ソフトウェア開発者の人生マニュアル (Japanese Edition) (Kindle Locations 5399-5408). Kindle Edition.
# base-files version 3.7-1 | |
# To pick up the latest recommended .bash_profile content, | |
# look in /etc/defaults/etc/skel/.bash_profile | |
# Modifying /etc/skel/.bash_profile directly will prevent | |
# setup from updating it. | |
# The copy in your home directory (~/.bash_profile) is yours, please | |
# feel free to customise it to create a shell |
Web mail service comparison https://gist.github.com/tai2/90ec5667f7d8aa07a1d10d669576593e