この文章は自分のプロジェクトマネジメントとエンジニアリングに対する理解のダンプです。自分はソフトウェアエンジニアなので、ソフトウェア=プロダクトという前提です。なぜエンジニアリングがくっついてくるかと言えば自分はプロダクトマネジャーではないので、プロダクトマネジメントと関わり方としてはプロダクトマネジメントという世界観の中でエンジニアリングをするというスタイルが多いから。 なぜ書いたのだろう。なぜ書いたのでしょうね。多分プロダクトマネジメントが体系化されておらず一人一派な状況なので自分のメンタルモデル持っておきたかったんだと思う。1年後見たときずいぶん考え方変わったなとか実践した結果考えが精緻化されたなとか思えればいいと思ってる。関連: メンタルモデルを作り込むという遊び - 下林明正のブログ プロダクトマネジメントとはなにか プロダクトマネジメントとはなにか？に対する自分の理解は、プロダ

仕事でTLS関連のトラブルがあったが全然基礎知識がなかったので1から学んだ。この記事は特にTLSの仕様を解説したいわけではなくどこを参照してまだかメモっておく。僕が解説するよりそっちを参照したほうが確実。 まずSSLとTLSの違いすらわからないレベルだったのでウィキペディア読んだ。 Transport Layer Security - Wikipedia ウィキペディアがいいのは常に更新されているところで、例えばPOODLE攻撃とか比較的最近のトピックも網羅されている可能性が高い。ウィキペディアで得た知識だけでPOODLE攻撃がわかるかというと微妙だけどインデックスは貼れる。 今回の問題はハンドシェイクに問題があるとわかっていたのでハンドシェイクの詳細が知りたい。ウェブ上の記事だと SSL／TLS（Part.1） (1/3)：不正アクセスを防止するSSL/TLS（2） - ＠IT が一番詳

追記 2019/04/16に以下の記事が公開されました。 employment.en-japan.com gfxさんによる記事です。この記事自体2017年の若干古い記事なので、新しく読む方は最新版である上記の記事を読んだほうがいいでしょう。 このエントリは2017/07/12に行われたHatena Engineer Seminar #8 @ Tokyoの発表内容をブログ向けに書き直したものです。 事前の通知では「CoffeeScript脱出にみるTypeScript2.4時代のベストプラクティス」がタイトルだったのですが、主題を変えたためタイトルも「がんばらないTypeScriptの始め方」に変更させていただきました。CoffeeScript脱出の話は一応出てきます。 社内のTypeScript事情 その後のTypeScript 現在の様子 TypeScriptのがんばらないはじめ方

TypeScriptには似たような型としてObject型とobject型と{}型が存在します。 let o1: Object; let o2: object; let o3: {}; 今回はこの3つの使い分け、あるいはobject型導入の経緯についてです。 JavaScriptのデータ型 JavaScript のデータ型とデータ構造 - JavaScript | MDNを読めば分かるように、 Boolean Null Undefined Number String Symbol の6種のプリミティブ型を持つプリミティブ値とオブジェクトでJavaScriptは成り立っています。 TypeScriptにおけるobject型とはここでいうプリミティブ型以外を表現しています。 object型はいつ使われるのか いつ役に立つかというとObject.create()の定義です。 TypeScript/

VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。 ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。 CHANGELOG の原則 機械的に生成するのではなく人間の手で書く 各セクションへのリンクが容易にできる 1つのバージョンごとに1つのサブセクションを作る リリースは新しいものが上に来るようにする 日付のフォーマットは YYYY-MM-DD

初めて書く時困りそうなトピックごとに TypeScript との関わり方を示していく。導入や書き始めのハードルを下げるのが目的なので意識高いことは言わない。 https://github.com/remojansen/logo.ts 対象読者 ゴール 基本姿勢 何故そんなこといい加減な感じなのか 型の書き方 type annotation シグニチャ 型が合わない時 Structural typing any したい キャスト色々 キャストせざるを得ない時 import できない error TS2307:Cannot find module 'hoge'. error TS1192: Module '"hoge"' has no default export. や error TS2305: Module '"hoge"' has no exported member '_'. など 頑

zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体