加湿空気清浄機 - 週末備忘録買ったけど水の入れ替えが面倒でただの空気清浄機になってる バカ
QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
YAGNI - Wikipedia
英: You ain't gonna need it[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 理由[編集] YAGNI原則を提唱する人々は、その理由として以下を挙げている。 後で使うだろうという予測の元に作ったものは、実際には10%程度しか使われない。したがって、それに費やした時間の90%は無駄になる[2]。 余計な機能があると、仕事が遅くなり、リソースを浪費する[2]。 予期しない変更に対しては、設計を単純にすることが備えとなる。そして、必要以上の機能を追加すると、設計が複雑になってしまう[2]。 人生の時間は、貴重である。したがって、人間の能力は、ただコードを書くためではなく、現実の問題に集中するために使うべきである[3]。 結局は、その機能は必要ないかもしれない。もしそうなったら、あなた
エンジニア勉強会（コミュニティ）運営について思うこと- 適度な内輪感と公共性の両立 - tkm2261's blog
こんにちは、tkmです。 このブログではポエムはあまり書かないことにしてたのですが、最近エンジニア勉強会（特にML系）が募集後すぐに埋まるツイートを目にしたので、 エンジニア勉強会全盛期（TokyoR, TokyoWebMiningなどの時）に学生で参加してから、kaggle meetupとかで運営するようになったので色々思うことを垂れ流して見ます 持続的な勉強会（コミュニティ）に必要なこと 適度な内輪感と公共性の両立 質の高い発表者の確保は最優先 運営から一言声を掛けるのがとても大事 発表することが目的の発表を排除 参加者の質も最低限確保したい 勉強会おじさんは絶対排除。慈悲はない それでも新規参入者の敷居は低く 内輪盛り上がりは予想以上に外部から醜悪に映る コアになる常連メンバーは必要 運営は出しゃばらない どこまで公共性を追求するか いま思っていること 優しい終身の独裁者は必要なのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
golang.org/x/tools/go/analysisで静的解析ツールを自作する #gounco / how to create the static analysis tool for go