質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
DBA的な視点から見たgit - As a Futurist...
git は現在分散バージョン管理システムの中では最も使われているものだと思いますが、サーバ管理やネットワークだけやってるエンジニアからすると、git は開発者が使うもので、なんか難しそう、と思って敬遠しがちです。実際僕も昔は git なんてコマンド打ちたくありませんでした。しかし、分散バージョン管理システムというのは、複数人でシステムを運用(not 開発)する際にもとても役に立ちます。このエントリでは、いわゆる一般的な git の解説とは違った視点から、git の良さを書いてみたいと思います。 ちなみに、git の基本的なアイデアについてはこちらのエントリが分かりやすいと思います。 イラストでわかる！git 入門の入門 : アシアルブログ 複数人でファイルを編集するなら 別にバージョン管理すべきものはソースコードだけではなく、例えばサーバの設定ファイルなんかも管理すべきものです。etcke
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
