定期的にサッと出したい資料だったので記録がてら
対象のスライド
みどころ
- ミスやトラブルに関することに関して、どういう考え方であたり、またどういう切り口で対策を講じるべきかの話が書かれている
- 短くまとめられているので、他人にも紹介しやすく、意識としても話を広げやすい
- 一般論的な部分もあるが、明文化されていないものはあまりなかったので時折振り返るものとしても有用そう
定期的にサッと出したい資料だったので記録がてら
意外とバリエーションがあり、意味が少しずつ異なるのでまとめる
日立製作所の川村氏が広めた言葉、川村氏との対談の記事の説明から引用すると以下の通り
ラストマンとは組織の中で最終的な意思決定をしてその実行に責任を持つ者であり、いずれそうなるかもしれないという覚悟を持って仕事をするように言われたと。アメリカの第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つで紹介したラストマンとは若干趣が変わり、「他の頼る人が居ない最後の一人」という意図で使われる。
個人の活動ログです。とりあえず必要最低限。
今回は kitty を導入してみました。特に吟味して選定したわけではなく標準出ないものを使ってみようというチャレンジです。
kovidgoyal/kitty: Cross-platform, fast, feature-rich, GPU based terminal
M1の場合アーキテクチャがarm64です。直近M1登場前までのIntelのアーキテクチャのMacのため作りが違います。念の為ターミナルで確かめると以下の通り。
% uname -m
arm64
homebrewの場合この状態においてどんな問題があるかというと
上記の問題があるが、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
AppleSiliconでの安定版がリリースされている
Apple silicon 上での Docker Desktop for Mac が正規安定版(GA release)として利用できるようになりました。 開発者によるローカル開発環境の選択肢が広がったことになります。 また ARM ベースアプリケーション開発に拡張することができます。 - Docker Desktop for Apple silicon | Docker ドキュメント
そのためこちらはひねったことをせずに素直にインストールをする。
だいたいはdocker上で動かすが、困ったときには手元でも環境を作りたくなるのでanyenvを入れておく
anyenv/anyenv: All in one for **env
homebrewが入ってるので、以下でセットアップ
brew install anyenv
あとはパスの設定や、初期セットアップを求められるので順当にやる
JetBrains製のものを永らく使っているので入れる。最近はToolboxのアプリから入れるのが一番ラクなのでToolboxを入れる
JetBrains Toolbox App:ツールを簡単に管理
実態と合わせてザッとまとめる
hoge@example.com
も HoGe@example.com
も同じアドレスとみなす場合がほとんど。仕様としては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
コードレビューに関して考え方をまとめている記事はいくつかあるのですが、この記事は参考文献を交えながらの説明となっているあたりがとても良かったです。
個人的には「メンテナンスのしやすさ」という軸をはっきり示している内容はこれ以外にみたことがなかったので大変参考になりました。
社内勉強会のLT資料が出しても問題ない感じだったのでちょっとブラッシュアップしてUPしました。
内容としては過去このブログで扱ってきたRubyやRailsで気になった書き方シリーズを「複雑にしない」という視点でまとめた内容になります。
なお、ベースとなった記事は以下です。
また、下記の書籍の話もエッセンスとして混ぜています。
スライド内にもありますが、基本的には「複雑さを減らす」というところにおいて寄与しない書き方があるので、「本当にその書き方が必要か?」と思いとどまるタイミングを増やしてほしいなと思ってまとめました。
Cookieの有効期限設定、ドキュメントからわからない罠が多すぎるので雑にまとめる
MDNを転載すると以下の通り
Cookie の持続時間は 2 通りの方法で定義することができます。
・セッション Cookie は現在のセッションが終了すると削除されます。ブラウザーはいつ「現在のセッション」が終わったと見なすかを定義し、ブラウザーによっては再起動時にセッションの復元を使用することができます。そのため、結果的にセッション Cookie が無期限に持続することがあります。
・持続的 Cookie は、 Expires 属性で指定された時刻、または Max-Age で指定された期間が経過した後に削除されます。 - HTTP Cookie の使用 - HTTP | MDN
上記のようにExpires属性、あるいはMax−Age属性の設定した期間までは維持されるというのがベースの仕様となっている。
俗に言う2038年問題の一種で、2038年の1月18日の一定時間よりあとを指定すると、それ以降の時間を保持するビット数が足りず意図違いの値がセットされる。そのため無期限にしたいからと言って2038年以降を指定してはいけない。
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ではSecure属性あるいてはhttp-only属性が付与されていないと、ITPの制約を受けるため短い期間の保持しかされない。詳しくは下記WebKitのブログを参照のこと。(2023年2月時点では24時間以内で消える)
Full Third-Party Cookie Blocking and More | WebKit