会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
GitHubに400行以下で構成されたオペレーティングシステムが登録された。オペレーティングシステムは「resume_operating_system」と呼ばれている。開発の動機や仕組みなどに関する説明は「My resume in an Operating system」にまとまっている。オペレーティングシステムの基本構造を理解する際に役に立つ。 このオペレーティングシステムはMathieu Passenaud氏が学生時代に作成したオペレーティングシステムの基礎実装をまとめたもの。開発者の経歴を表示するだけという目的で作られた趣味的な取り組みの成果物であるため、明確に名称がついていない。GitHubに登録した名前が「resume_operating_system(経歴オペレーティングシステム)」であるため、この名称で呼ばれている。 resume_operating_systemではテキスト
はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定しています。 Qiitaの投稿やブログの記事といったものでも共通する部分は多いのですが、これらには他にも重要な要素があると思うので、ここでは扱いません。 わかりにくいドキュメント=全体像が掴めないものが多い 先ず、わかりにくいドキュメントとはどんなものでしょ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く