これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしている エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
システム開発の入門者から中級者にステップアップするための10のティップス - builder by ZDNet Japan
ある読者との電子メールのやり取りの中で出てきた話である。彼は、開発者向けのブログや記事、雑誌の内容が2種類に分類できるということを述べていた。その2種類とは入門者向けのもの（"Hello World"に代表されるもの）とエキスパート向けのもの（MSDN Magazineのようなもの）である。 これはなかなか鋭いポイントを突いている。開発者が入門レベルから中級レベルにステップアップするうえで役立てることのできる情報がほとんどないのだ。以下は、こういったステップアップを実現するための10のティップスである。 ＃1：新たなプログラミング言語を学習する 新たなプログラミング言語を学習することは、それがどのような言語であったとしても、より優れた開発者になるための近道となるのである（このことは、あなたが既に多くのプログラミング言語を修得していたとしても成立することである）。言語を選択する際には、あなた
バーベキュー優先度問題、あるいは人生における優先度の問題 : 小野和俊のブログ
忘れられない思い出というのは意外とちょっとしたところから生まれるものだが、 私にとってのそんな思い出の一つに、大学生の頃の「バーベキュー優先度問題」というものがある。 簡単に言えば、バーベキューのために買ってきた肉が多すぎたのである。 この多すぎる肉をどのように食べ進めるかについて、私は二つの方法を考えた。 (2) まず安い肉から食べ始める。途中でお腹一杯になってしまっても、デザート別腹理論的に 美味しい肉であれば食べようという気が起きて完食できるだろう。 当時の私は、食べ物を粗末にしてはいけないと殊勝(自己評価)なことを考え、 (2)を選んだ。しかし、肉が別腹に入るはずなど無く、結果として残ったのは 食べきれずに残された大量の上質な肉だった。 買ってきた肉を食べきれず、しかも良い肉の方を残してしまったのである。 「ちくしょう！」、私は自分の判断の誤りを悔やんだ。そして敗北感に打ちひしがれ
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary
まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日本は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ！全
Ruby on Railsの作者より：高まった生産性を仕事を余計にこなすためではなく自分の将来に向けて使おう - himazu blog
IT ConversationsでRuby on Railsの作者デービッド・ハンソンが2008年5月にRailsConfでおこなった講演が配信されている。そして、以下でも聞ける。 RoRの思想についての言及が冒頭にあるが、大部分は開発者の身の処し方についての講演である。その部分の概要は以下の通りである。 RoRは他のフレームワークや開発手法に比べて生産性について依然として優位性があり、RoRを使って開発していると「余剰開発力」を享受できる。しかし、その状態は永遠には続かない。遅かれ早かれ以下のどれかが起こるから。 他の言語／フレームワークがRoRを凌駕する RoRを凌駕する新たなフレームワークが登場する RoRがメインストリームになる 幸い、どれもすぐには起こりそうになく、RoRでの開発はまだしばらく生産性の点で有利である。その優位性によって生ずる余剰開発力をいかに活用すべきだろうか。も
パラサイト・プログラミング steps to phantasien t(2007-04-16)
2007-04-16 近況 最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い. コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記