Web系の新卒の人ははじめにエンジニアになってみると良い

Engineer

なぜこのエントリを書こうと思ったかというと、
「プログラムを書いたことが無いけどいつかWebサービスを世に出したいんですよ！」
と、技術のことは知らないけど熱意がある若い学生の人たちと話をしたから。
「じゃあエンジニアになればいいよ」というのが僕の答え。
ちなみに何年か社会人やってから「エンジニアになりたいです！」
って言っても多くの会社で職種転向というのはなかなか認められない狭き門なんじゃないかな思う。
だから新卒のうちにエンジニアになっておくほうが良い。

エンジニアになってエンジニアリングを知っていると（今思いつく範囲で）3つの利点があるなと思ってる。

利点1：自分で作ることができる

これはとても気楽なこと。何やったっていい。なんだって出来る。
スケジュール調整とかリソースの調整なんて考えなくていい。作りたいときに作る。
エンジニアリングを知っている分だけヒト・モノ・カネのうち、
モノにおいてはコントロールできる範囲は広く持てる。

とはいえエンジニアとして会社に属して働くのであれば明示された
納期は守らないとダメだけど。

利点2：エンジニアに対して的確に指示が出せる

これは昇進とか昇格したときに下にエンジニアの人を付けてもらった時の利点。
エンジニアリングを知らない人はエンジニアに的確に指示が出せない。
例えば拡張性を考慮した設計にして欲しくても「将来サービスの規模が拡大しても容易に
拡張出来る設計にしてください！」と伝えることしかできない。
正直これではエンジニアには伝わらない。

エンジニアリングを理解していればサービスの背景を深く理解して、
何を抽象化して、どのようにパーツ化して、どのレベルでコンポーネントに分けて、
コンポーネント間のインタフェースの仕様を定めて、など設計をまとめて
エンジニアに共有するという事がしやすい。
なんて簡単に書いてしまったが設計というのはかなりのスキルを要求されたり、
チームで設計したりするものなのでそんなに楽ではないけど。

利点3：プロジェクトを推進しやすい

これは上に書いた利点と同じようなものなんだけど、
例えば自分が既にエンジニアでなくなっている場合を想定。
プロジェクトを推進するときに「エンジニアがどのように考えてどのように実装するか」
を理解しているマネージャーは経営者にとってもエンジニアにとっても貴重な存在。

まとめ

何年か社会人やっていて色々なキャリアを見てきたけどWeb系であれば
エンジニアリング知っている人のほうが、知らない人よりは結果を出して
いるように見える。もちろんエンジニアリングを知らない人も
大きな結果を出している人を見て来たけど数は少なかった。

繰り返しだけど「Webのサービスを世に出したい！」と強く思う人ほど、
エンジニアリングを知っておくほうが吉だと思う。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

#97prog_ja 91 良いプログラマになるには

programming 仕事 プログラマが知るべき97のこと書評

プログラマが知るべき97のこと
このエントリを読んで昔よりはまともなソースコードが書けるようになったかな、と振り返った。
昔は良いプログラムを書こうとしても書けなかった。経験も努力も足りなかった。
多分達人プログラマになりたいのであればこのエントリにある通りに努力して実践することが一番の近道なのかもしれない。

良いコードは何の根拠もなく勝手に生まれたりはしません。今週はたまたま星回りが良いから良いコードができた、などということはないのです。コードを良くするには、そうすべく相当な努力をしなくてはなりません。良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書けるのです。
（中略）
ソフトウェア会社で長年働いた経験から、1つわかったことがあります。それは、良いプログラマとそうでないプログラマの違いです。両者の最大の違いは「取り組む姿勢」にあります。良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいものです。常に、最大限の力を尽くして良いコードを書こうとします。リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでも出来る限り良いコードを書こうと努力をするのです。
（中略）
良いプログラマになるためには、単なる善意だけでは不十分です。
（中略）
真に優れたコードは、知識も経験もあるプログラマが最大限心を配って書いたときに生まれるものです。

#97prog_ja 90 コードを見る人のためにテストを書く

programming 仕事 プログラマが知るべき97のこと書評

プログラマが知るべき97のこと
このエントリはタイトルが秀逸すぎる。
一体誰のためにテストを書くのか？それはコードを見る人のためだ。
コードを見る人は未来の自分かもしれない。もしくは自分以外の誰か。
そのためには良いテストを書かなければならない。

良いテストとは何か？コードがどのように働くのかを教えてくれるテストが
良いテストだ。

良いテストの条件を簡単にまとめると次のようになるでしょう。
●コンテキスト、出発点、満たすべき事前条件がわかる。
●ソフトウェアがどのように起動されるかがわかる。
●期待される結果と、確認すべき事後条件がわかる。

中学時代の同窓会に参加した

Life

同期の人たちとは12年ぶりの再会。

3つぐらいにまとめる。

意外とエンジニアが多い（※ただしコンピュータに限らない）

仲の良かった友人たちの多くがエンジニアになっていて驚いた。
エンジニアって人気なのかな？
話をしてみると多くの人が今の仕事に不満を抱えているように見えた。
でもそれってすごく普通のことなんだろうなと思ったけど。
みんな何かしらで満たされていて何かしらで満たされていないもんだ。

旧友に出会えて良かった

長時間TVゲームしたり、すこしアウトドアな活動をしたり、ごくたまに勉強もしてみたり。
一緒に3年間を過ごせた友人たちとまた会えたのは良かった。
「見た目は少し変わったけど振る舞いはあの時のままだなお前はｗ」
なんて言われたときは僕自身の持ち味を潰さず、変えることなく年を取ったことを
評価されたような気がして嬉しかった。

昔話に花を咲かせた

クラスが違ったから名前と顔が一致しない人もいたけど
学校という共通項があったから話題には困らなかった。

良い同窓会だった。

チケットに対して詳細に解説を書くのが面倒くさすぎた

日報

チケットに対して詳細に日本語を書くのが面倒すぎた。
日本語で文章を解説するという行為があまりにもクリエイティブすぎて挫折した。

代わりにチケットにはコメント付きのソースコードを書いた。
大体10分ぐらいで表現したい内容を詳細に書けた。

プログラマに伝えるべき表現に関して迷ったらニュアンスをプログラミングしてしまうのも一手段。

Mac OS X Lion のApacheの設定

mac

メモ。

# umaskの設定を.bash_profileに記述
umask 0002

# phpのコメントアウトを外す
sudo vi /etc/apache2/httpd.conf

# 権限の調整(なぜか自分がstaffグループだったのでDocumentsをstaffに)
cd /Library/WebServer/
sudo chown root:staff Documents/
sudo chmod 775 Documents/

# CLI版のphp.iniの設定を施す
sudo ln -s /etc/php.ini /opt/local/etc/php5
php -i | grep php.ini

最後にシステム環境設定→共有→Web共有のチェックボックスON