上級プログラマってどんな本読んでるの？中堅プログラマがマウンティング取られないための名著8選 - 世界が幸せで在ります様に
この記事を読もうと思ったということは，あなたはそこそこできるプログラマ，あるいは社内でも自他ともに優秀と認められるほどの実力者かもしれません． ただし，そんな状況でも業界で名が知られる優秀な人や社内の上級プログラマと対峙した時身構えてしまい相手の不思議な理論に屈服してしまう経験はありませんか？本気でプログラミングをすれば互角，あるいは言語によっては自分の方が明らかに上だと自負できる状況にもかかわらず． そんな中，そこまで優秀そうに見えないのにうまくマウンティングを回避しているプレーヤーを見たことはないでしょうか？ 彼らと自分は何が違うのか？ 簡単に言えば，知ってるコンピュータ科学の量と，何らかの物事に対して同調するのではなく先駆者的にそれを宣言することです．それを少しでも発揮できる名著をこれからご紹介します． ※安心してください，日本語の書籍だけ紹介します． Coders at Work
マルチスレッドプログラミングにおける重要な４要件: 柴田 芳樹 (Yoshiki Shibata)
JaSST Tokyo 2018の招待講演で話した資料（こちら）に書いてあることですが、今までの人生で私自身は、デジタル複合機コントローラソフトウェア開発を4回もアーキテクチャを変えて行いました。デジタル複合機の難しさは、ハードウェアからの非同期なさまざまなイベントとユーザからの様々なイベントを両方を上手く処理しなければならず、かなり複雑なソフトウェアとなります。 ソフトウェアエンジニアとして合計すると10年以上をデジタル複合機コントローラソフトウェアの開発に従事し、マルチスレッドプログラミングを行ったことになります。公開資料に詳細情報は含まれていませんが、資料にある「Take 3」と「Take 4」は、デジタル複合機コントローラソフトウェアを完全にテスト駆動開発で行うというものでした。 4回ともマルチスレッドプログラミング（厳密には、Take 4はマルチゴルーチン（goroutine）プ
命に関わるコードを書く時の10個のルール
ミス一つで命に関わったり数年の努力が失われたりするような重大なコードを書く場合、どのような点に気を使うべきなのかを、NASAで働くコンピューター技術者のGerard J. Holzmannさんが「The Power of 10」としてまとめています。 The Power of 10: Rules for Developing Safety-Critical Code - Wikipedia https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code 1. Gotoや再帰など複雑なフローは避ける By atsunori kohsaki 2. 暴走を阻止するため、全てのループに回数上限を設定する By Woplu 3. ヒープ領域のメモリを割り当てない これは、使用済みメモリが
コメントと名前付けの難しさ それに対して僕らができる防衛術 - See the Elephant
TL;DR 命名はプログラミングの中で重要かつ難しいタスクである コメントが出てきた時点で一考しよう. リファクタリングのチャンス 抽象化は慎重に 仕事を小さくすることで命名は比較的簡単にできる コードに残らない事情はコメントで表明する あるslackの雑談から始まった 僕が属しているコミュニティであった雑談から. ういろう [11:26 AM] 結構、コメント書くって難しいよね・・・ コメントと変数名は、プログラム書くより難しいんじゃないかって思ってる。 抽象メソッドにどんなコメントを書くかーみたいなことも今考え中。 okashoi [11:41 AM] 抽象メソッドなら入出力だけわかればいいんじゃないのかな > コメントと変数名は、プログラム書くより難しいんじゃないかって思ってる。 わかる。プログラミングするときに最も脳のリソースを消費するのは命名かなっておもってる（やや大げさ） うい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
数式を綺麗にプログラミングするコツ #spro2013