質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
PHPカンファレンス2014でHHVM/Hackの話を聞いて感動した - As a Futurist...
使える言語の幅を広げたいと思ってPHP カンファレンス 2014に参加してきました。徳丸さんの「安全な PHP アプリケーションの作り方 2014」は改めて自分のセキュリティの知識を確かめるのに大変有意義だったのですが、何より感動したのが Facebook の Paul Tarjan による「HHVM + Hack == PHP++」のセッションでした。 すごく簡単に僕が理解した限りで HHVM/Hack を紹介すると、HHVM とは PHP の処理系の一つの実装です。その特徴は JIT コンパイルにより超高速になっていることに加え、圧倒的な魅力は PHP の Extension(C 拡張ライブラリ)の多くが実装されていて PHP のメジャーなフレームワークが問題なく動作するということです。つまりもう実践で戦えるということ。そして、Hack というのは HHVM が処理できるもう一つの言語
遅延評価勉強法だと得られなかったもの - As a Futurist...
ハッカーは遅延評価勉強法をするものだそうです。確かに僕の知ってるすごい人達は、皆必要になった時の吸収力が半端無くて、それを紹介した時には自分の方が詳しかったはずなのに、あっという間に追い抜かれてしまいます。 僕はハッカーになりたいけどハッカーじゃない人間ですが、やはり大上段から入って時間をかけて勉強していくのは嫌いなので、基本的には遅延評価勉強法をしてきました。でも言葉どおりに「必要になるまで」勉強しなかったら、得られないものが多すぎるなと最近感じてます。それは「普遍的な知識」です。 自分の仕事や興味だけに従っていると、訪れる機会は必然的に偏ります。たとえば web アプリの開発ばかりやっていれば、LL や HTTP や通信の知識は幅広く身につくかもしれませんが、スマホ開発や仮想環境やハードウェアなどはなかなか身につきません。必要にならないんだから勉強しなくていいんじゃない？というのはもち
最近のサーバの抽象化について - As a Futurist...
学者でもなんでもない現場のいちエンジニアの感想です。しかも、どれもちゃんと使ったことないので、聞きかじりをまとめたメモ書きなので嘘が入ってますが、興味ある方がいればどうぞ。 はじめに かつては「OS=物理サーバ」であって、その物理サーバの資源(CPU,RAM,DISK,etc.)をどのように使うかは OS がプロセスに割り振る形で決定されていました。しかし、それでは例えば以下の様な問題があります。 ファイルシステム資源をプロセスが自由にコントロールできない ProcA と ProcB で使いたい libfoo のバージョンが異なる場合面倒 CPU, RAM 資源もコントロールしにくい 同居してるプロセスがメモリ食い尽くして、みんな死亡、みたいな そもそも異なる OS を同居して使うことができない CentOS ばかり使ってるのに、使いたいライブラリが Debian でしか動かないとか 解決
「リーダブルコード」が良書すぎて胃が痛い - As a Futurist...
インフラ系のエンジニアは、あまりリファクタリングとかクラス構造といった視点でコードを読む機会が少なくて、勢い作ったスクリプトやツールはそれはそれはひどいものになりがちです(体験談)。 僕もエンジニアになって以来、まともなコードなんか書いたことなくて、従ってる原則といえば、「グローバル変数は悪」とか「短いことはいいことだ」とか「コメントは書かない方がいい」とか、なんか学生の時にたまたま目にしたよくわからない何かに従ってる程度。 少し大きい規模を書き始めると、昨日の自分と今日の自分で命名規則が全然一貫性なくて、「getHoge()」と「makeFuga()」がおんなじようなことをやってたりしていつも嫌悪感に駆られてました。 ちょうど 1000 行くらいのアプリ書いてたところだったので毎日吐き気をこらえながら「まずは動くものをつくるんだ。全てはそれからだ」と言い聞かせて汚いコードをゲロゲロしてた
「ソフトウェア開発者採用ガイド」は採用される側も読んだ方がいい - As a Futurist...
会社でふと教えてもらった本だったのですが、読み始めたらすごいおもしろかったのですぐ読みきってしまった。2008 年なので僕はまだこういうことに興味なかったから全然網にかかってなかったけど、ググったりすると結構書評でてきますが、総じておもしろいって感じです。今更感ただよう書評ですいません。。。 高音域 社内外のスーパーエンジニアを見るに、本当に「できる人」と「できない人」には絶対に超えられない壁があると僕も感じる。 凡庸な歌唱は最高の歌手がいつでも出している高音域を決して出すことができない。 p. 011 会社が高音域を求めるなら、優秀なエンジニアを獲得するしかないわけですし、優秀なエンジニアとはそういうものですね、実際。高音域を求めないところなら、確かに人月の神話で凡庸なエンジニアを並べればできあがるのでしょう。 才能 とはいえ誰だって最初は「できない人」であって、それが「できる人」になる
DNS勉強会＠ゼロスタに行ってきた - As a Futurist...
恒例の行ってきたエントリです。そういえば qpstudy 書き忘れてたけど、あれは勉強会じゃないからいいよね(；・∀・) というわけで、今日は万難を排してゼロスタートコミュニケーションズで開催された「DNS 勉強会」に行ってきました。つぶやきまとめはこちらをご覧ください。途中の@sugyan さんがよくわかりません。 Togetter – 「インフラエンジニア( zaki )による、エンジニアのための「初心者向け DNS 勉強会」 #zsstudy」 DNS ってなんじゃい！ BIND があまりにもよく使われるせいで、「DNS=BIND」的な感じで BIND の設定のはなしとかばっかりが世の中にはびこってるけど、そもそも DNS ってどういう仕組みでどういう登場人物がいるのかという話を、@zaki 社長自ら解説するという豪華な勉強会。最初かなりグダグダな感じ(始まってから「ハッシュタグ今決
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
