定期的にサッと出したい資料だったので記録がてら
対象のスライド
みどころ
- ミスやトラブルに関することに関して、どういう考え方であたり、またどういう切り口で対策を講じるべきかの話が書かれている
- 短くまとめられているので、他人にも紹介しやすく、意識としても話を広げやすい
- 一般論的な部分もあるが、明文化されていないものはあまりなかったので時折振り返るものとしても有用そう
ラストマンとつく言葉の意味をいくつかまとめる
意外とバリエーションがあり、意味が少しずつ異なるのでまとめる
ラストマン
日立製作所の川村氏が広めた言葉、川村氏との対談の記事の説明から引用すると以下の通り
ラストマンとは組織の中で最終的な意思決定をしてその実行に責任を持つ者であり、いずれそうなるかもしれないという覚悟を持って仕事をするように言われたと。アメリカの第33代大統領トルーマンは「The buck stops here」というデスクサインを執務机の上に置いていたことで知られています。全責任はここにある。他の人は責任を転嫁（pass the buck）できるけれど、それは最後に大統領のところで止まる。すなわち私がすべての責任を取るのだという覚悟を示す言葉だと言われています。 - リーダーに求められる「情」と「理」 経営改革を支えた、本からの学び その2 ラストマンの覚悟とリーダーシップ - Executive Foresight Online：日立
上記の言葉を端的に表すと「ラストマン、すなわち自分の後には意思決定を譲れる人がいないかもしれない意識を持て」というような用途で使われる
ラストマンシップ
前述のラストマンとオーナーシップを足したような言葉、言葉の出典としては以下の通り
ラストマンシップを持つ人は「自分が仕事全体の最終防衛線であり自分が崩れたら仕事全体がダメになる」という発想をする。 - ラストマンシップ｜トーキョーハーバー｜note
このようにラストマンの「最後の意思決定者である」という言葉と、当事者意識を持ってものごとにあたる「オーナーシップ」を合わせて、「自分が最後の一人、この後ろには誰も居ないかもしれないという意識を持て」というような用途で使われる
おそらく出典のnoteが明言化された初のブログかもしれないとのこと
ところで「ラストマンシップ」という単語をたまにTLで見かけるが、実は私が2019年5月27日に旧ブログをツイートしたのが最も古く、それ以前は少なくともツイッターの検索上は見つからない。もしかしたら概念をちょっと広めることに貢献できたのか？？
— TokyoSwing (@TokyoSwing) 2021年3月18日
ラストマン戦略
「ラストマン戦略」は少し言葉の意味が変わる、出典は以下
ラストマン戦略とは、組織の中で自分が一番詳しくなれそうな領域を決め、「あの人が分からないなら、他の誰も分からないよね」と言われるような、最後の砦とも言うべきスペシャリストを目指す成長戦略だ。 - 『その仕事、全部やめてみよう』クレディセゾンCTO小野和俊が語る、成長したい20代エンジニアのための“最後の砦”戦略 - エンジニアtype | 転職type
こちらは上記2つで紹介したラストマンとは若干趣が変わり、「他の頼る人が居ない最後の一人」という意図で使われる。
参考リンク
Apple M1 MaxのMacbook Proの初期環境構築をする 2023/3
個人の活動ログです。とりあえず必要最低限。
購入したMac
やったこと
Terminalの導入
今回は kitty を導入してみました。特に吟味して選定したわけではなく標準出ないものを使ってみようというチャレンジです。
kovidgoyal/kitty: Cross-platform, fast, feature-rich, GPU based terminal
homebrew
現時点の背景整理と対応方針
M1の場合アーキテクチャがarm64です。直近M1登場前までのIntelのアーキテクチャのMacのため作りが違います。念の為ターミナルで確かめると以下の通り。
% uname -m
arm64
homebrewの場合この状態においてどんな問題があるかというと
- すべてのパッケージがarm64対応しているわけではないので、Intel向けのパッケージしか用意されていない可能性がある
- Intel版のパッケージを使いたくなった場合に互換エミュレータをON(Rosetta 2を有効)にした状態にしないといけない
上記の問題があるが、2023年時点ではネットを見回したがだいぶ浸透したというのもあるのか、そこまで苦しむポイントがなさそうなので素直にインストールをしてみる。参考サイトは以下。
絶対にRosetta 2を入れたくない人によるM1 Mac環境構築 2021 10月末編
インストール
Homebrew — The Missing Package Manager for macOS (or Linux) の冒頭のコマンドを実行する
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ## 中略 ## HEAD is now at 82a36d24f Merge pull request #14693 from timvisher/fix-posix-mode-test-for-bash-3 Warning: /opt/homebrew/bin is not in your PATH. Instructions on how to configure your shell for Homebrew can be found in the 'Next steps' section below. ==> Installation successful! ==> Homebrew has enabled anonymous aggregate formulae and cask analytics. Read the analytics documentation (and how to opt-out) here: https://docs.brew.sh/Analytics No analytics data has been sent yet (nor will any be during this install run). ==> Homebrew is run entirely by unpaid volunteers. Please consider donating: https://github.com/Homebrew/brew#donations ==> Next steps: - Run these two commands in your terminal to add Homebrew to your PATH: (echo; echo 'eval "$(/opt/homebrew/bin/brew shellenv)"') >> /Users/*********/.zprofile eval "$(/opt/homebrew/bin/brew shellenv)" - Run brew help to get started - Further documentation: https://docs.brew.sh
pathが読めないとのことなので、zshのプロファイルに書き足す
% cd ~
% vi .zprofile
# self custom export PATH=/opt/homebrew/bin:$PATH
新しくターミナルを開いて、以下が出たのでOK
% brew -v Homebrew 4.0.1 Homebrew/homebrew-core N/A
Docker Desktop
AppleSiliconでの安定版がリリースされている
Apple silicon 上での Docker Desktop for Mac が正規安定版（GA release）として利用できるようになりました。 開発者によるローカル開発環境の選択肢が広がったことになります。 また ARM ベースアプリケーション開発に拡張することができます。 - Docker Desktop for Apple silicon | Docker ドキュメント
そのためこちらはひねったことをせずに素直にインストールをする。
anyenv
だいたいはdocker上で動かすが、困ったときには手元でも環境を作りたくなるのでanyenvを入れておく
anyenv/anyenv: All in one for **env
homebrewが入ってるので、以下でセットアップ
brew install anyenv
あとはパスの設定や、初期セットアップを求められるので順当にやる
IDE
JetBrains製のものを永らく使っているので入れる。最近はToolboxのアプリから入れるのが一番ラクなのでToolboxを入れる
JetBrains Toolbox App：ツールを簡単に管理
参考サイト
- [M1 Mac の環境構築メモ \| 株式会社エムケイシステム TECH BLOG](https://blog.mksc.jp/contents/apple-silicon/)
- M1 Apple Silicon 移行記
2023年3月時点ではメールアドレスのローカル部の文字は大文字小文字を区別しないのが多数派
実態と合わせてザッとまとめる
先にまとめ
- メールアドレスのローカル部（アットマークより前）は大文字小文字を区別しないことが多い。そのため
hoge@example.comもHoGe@example.comも同じアドレスとみなす場合がほとんど。 - 「区別しないこと多い」という表現をしているのは区別しないという仕様ではないため。
- 一部のWebサービスではメールアドレスのローカル部は小文字で保存しているケースもある
仕様から考える
仕様としてはRFC5321を参照すると以下の通り
The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive. - RFC 5321: Simple Mail Transfer Protocol - 2.4
日本語訳verだと以下の通り
つまり、コマンド動詞、メールボックスのローカル部分以外の引数値、および自由形式のテキストは、大文字、小文字、または大文字と小文字の任意の組み合わせでエンコードされても、その意味には影響しません。メールボックスのローカル部分は、大文字と小文字を区別する必要があります。したがって、SMTP実装は、メールボックスのローカル部分の大文字と小文字を維持するように注意する必要があります。特に、一部のホストでは、ユーザー「smith」はユーザー「Smith」とは異なります。ただし、メールボックスのローカル部分の大文字と小文字の区別を悪用すると、相互運用性が妨げられるため、お勧めしません。メールボックスドメインは通常のDNSルールに従うため、大文字と小文字は区別されません。 - RFC 5321 - Simple Mail Transfer Protocol 日本語訳
わかりにくい部分ではありますが、「区別する必要がある」と書かれており、最後の最後で「大文字と小文字を区別して運用することはオススメされておらず、区別しないほうがよい」とされている。
実際のメール送信において
実際のメール送受信の挙動としては、RFCの挙動の「メールボックスドメインは通常のDNSルールに従うため、大文字と小文字は区別されません。」の部分に準じて動く。そのため大文字と小文字を区別しないため HoGe@example.com も hoGE@examole.com も同じメールアドレス扱いになり、正しく届く。
サービスによってはメールアドレスは小文字で保存されることがある
一部のWebサービスではメールのローカル部が大文字だった場合は小文字で保存するなどの処理をとっている。例えばSalesforceでは以下のように記載がある
Salesforce ではメールアドレスは小文字で保存されます。 - メールアドレスの検証
関連リンク
コードレビューの考え方に迷ったときに読み直したい記事『コードレビューの目的と考え方』
記事のメモです
対象の記事
コードレビューの目的と考え方 - osa_k’s diary
みどころ
コードレビューに関して考え方をまとめている記事はいくつかあるのですが、この記事は参考文献を交えながらの説明となっているあたりがとても良かったです。
個人的には「メンテナンスのしやすさ」という軸をはっきり示している内容はこれ以外にみたことがなかったので大変参考になりました。
関連リンク
社内勉強会で「書くときにひと呼吸おいて考えてから書いてほしいRailsコードの書き方」という話をしました
社内勉強会のLT資料が出しても問題ない感じだったのでちょっとブラッシュアップしてUPしました。
資料
内容
内容としては過去このブログで扱ってきたRubyやRailsで気になった書き方シリーズを「複雑にしない」という視点でまとめた内容になります。
なお、ベースとなった記事は以下です。
- RailsのViewPartialにて引数確認にdefine?を使うようなケースは本当にそこまでやるか立ち止まって考えて欲しい - コード日進月歩
- Railsで with_indifferent_access を使うときは一呼吸おいて考えて欲しい - コード日進月歩
- Rubyの引数の情報の渡り方(共有渡し)をざっくりまとめる - コード日進月歩
- Rubyにてハッシュを用いたキーワード引数(**引数)を使いたくなった場合は本当のそれが必要かを一息おいて考えてほしい - コード日進月歩
また、下記の書籍の話もエッセンスとして混ぜています。
伝えたいこと
スライド内にもありますが、基本的には「複雑さを減らす」というところにおいて寄与しない書き方があるので、「本当にその書き方が必要か？」と思いとどまるタイミングを増やしてほしいなと思ってまとめました。
関連リンク
2023年2月現在、Cookieの有効期限設定は未来すぎると意図違いの状態になるので気をつける
Cookieの有効期限設定、ドキュメントからわからない罠が多すぎるので雑にまとめる
前提としてCookieの維持に関して
MDNを転載すると以下の通り
Cookie の持続時間は 2 通りの方法で定義することができます。
・セッション Cookie は現在のセッションが終了すると削除されます。ブラウザーはいつ「現在のセッション」が終わったと見なすかを定義し、ブラウザーによっては再起動時にセッションの復元を使用することができます。そのため、結果的にセッション Cookie が無期限に持続することがあります。
・持続的 Cookie は、 Expires 属性で指定された時刻、または Max-Age で指定された期間が経過した後に削除されます。 - HTTP Cookie の使用 - HTTP | MDN
上記のようにExpires属性、あるいはMax−Age属性の設定した期間までは維持されるというのがベースの仕様となっている。
未来時刻を設定する際に気をつけないといけないこと
2038年1月18日以降を設定するとオーバーフローする
俗に言う2038年問題の一種で、2038年の1月18日の一定時間よりあとを指定すると、それ以降の時間を保持するビット数が足りず意図違いの値がセットされる。そのため無期限にしたいからと言って2038年以降を指定してはいけない。
Chrome104以降は400日以内に丸められる
When cookies are set with an explicit Expires or Max-Age attribute, the value will now be capped to no more than 400 days. - New in Chrome 104 - Chrome Developers
上記にある通り、Chromeは400日以内になるようになっている。
また、この仕様はHTTPワーキンググループでの以下の記述が元になっているのでブラウザ各社が追従する可能性がある。
The user agent MUST limit the maximum value of the Expires attribute. The limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future. The RECOMMENDED limit is 400 days in the future, but the user agent MAY adjust the limit (see Section 7.2). Expires attributes that are greater than the limit MUST be reduced to the limit. - Cookies: HTTP State Management Mechanism - 4.1.2.1. The Expires Attribute
なお、この400日(約13ヶ月)が設定された背景はChrome Platform Statusの投稿いわく1年に1回だけ訪れるサイトなどもあるので、その点を配慮しての数値設定とのこと。
補足. SafariではITPの取り組みがあるので、設定次第ではかなり早く消える
SafariではSecure属性あるいてはhttp-only属性が付与されていないと、ITPの制約を受けるため短い期間の保持しかされない。詳しくは下記WebKitのブログを参照のこと。（2023年2月時点では24時間以内で消える）
Full Third-Party Cookie Blocking and More | WebKit