あれから 10 年。まさーるさん(石井勝さん)を偲ぶ。 - t-wadaのブログ
今日（2015-04-25）は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
Fine Software Writings
最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か？ (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか？ (Nick Bostrom) 厄介な問題を解決したい？ ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W
プログラマだけど異世界の開発会社に転生した - megamouthの葬列
最適化（オプティマイゼイション） ジャムス「どうもページの表示が遅いんだ。多分Javascriptが重すぎるんだよ。どうしたらいいんだろう？」 エイダ「しょうがないわね。ふーん。まずJqueryのappendが多いわ。DocumentFragmentやinnerHTMLをもっと効果的に使わないと」 ジャムス「ふーむ」 と言ってジャムスはTeraPadを開くとjsファイルを編集しはじめた。エイダがすかさず口は挟む。 エイダ「待って。前のファイルをちゃんと残しておかないと。」 ジャムスはうっかりしていたとばかりにエクスプローラーで、main.jsをクリック。CTRL+Cでコピーすると、流れるような動きでCTRL+Vを押す。すぐさま「main.js のコピー」ができあがる。 エイダが呆れて言った。 エイダ「それじゃ、いつの履歴かわからないじゃない！。今日の日付main.1281落葉の月21の日.
流行のIT技術を追うのをやめたらプログラマとして成長した話
私はもともと普通のプログラマとしてキャリアをスタートしましたが、2007年くらいから脱プログラマを目指してソフトウェア起業家として経営に軸足を移してきました。 それから8年くらいが経過して思うのは、経営者として大きな成功をおさめる前に、自分のプログラマとしての実力がめきめきとアップしてしまったということです。 8年前の私は、プログラマとしては基礎力はあるものの全般的には未熟であったように思います。コードも荒削りで、とにかくかろうじて動くものを作ることに四苦八苦していました。が、いまはプログラマとしてずっと良い仕事ができています。 この8年間は、自分でコードも書いていたので、経験が増えたことによって、良いコードを書けるようになったという面も多々あるとは思います。しかし、そのあいだ技術書を読むことはすっかりやめてしまい、流行の技術などは完全無視してきました。 経営層の一員として働くので、プロジ
ドイツでプログラマとして働いて半年がたちました。 - WETな備忘録
と、いうやつを8月末に書こうと思ってたらもう12月がすぐそこまで来ている。 人生設計とか考えるのがしゃらくさくなり、と言えば格好はいいんですが、何か僕の将来に対する唯ぼんやりした不安と向き合うことに疲れて、ビールとソーセージが好きだという理由だけでドイツに行きたい、というか行くことに決めたのが昨年の11月くらい*1で、そのときは前も後ろも何も決まってない状態だったので、いそいで準備とかしたのでいろんな人に迷惑をかけてしまったかなあと思いつつ、深く感謝はせども、反省はしていません。いつも本当にありがとう。 こういう無茶な生き方をするために心技体マッチョなものを身につけたはずなのであって、せっかくなので無茶な生き方しないともったいない。 所詮地球でした ドイツに来て即、ボーフムというサッカーしか無えみたいな田舎街に単身で顧客に常駐して、スイスのクライアントの2次請けみたいなことをしたんですが、
Done（完了）の定義とリリースブランチ - 未来のいつか/hyoshiokの日記
Doneだ。終わったよという宣言をするのは心地よい。しかしながらこの「完了」という言葉ほどソフトウェア開発現場では曖昧に使われているものはない。 わたしも新人の頃、いいかげんに使っていた。 よ「〜の機能の実装完了です」先輩「ビルドした？」よ「コーディングしただけです」先輩「ばかやろ、それは実装完了とは言わねーよ」よ「すいません」、（あれやこれや作業）…、よ「ビルドしました。コンパイルエラー、ビルドエラーとかないっすよ」先輩「で、テストした？」よ「てへ」先輩「お前あほか」、（あれやこれや作業）…、よ「テストしましたーー。ばっちりっす」先輩「あれ、こっちでは確認できないなー。ソースコードをチェックインしたの？」よ「あ、自分のローカルな環境でしか試してません」先輩「おい首締めるぞ。チェックインしてから言えよ」、（あれやこれや作業）…、よ「チェックインもしました」先輩「やっとか。どれどれ。あれー、
「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
ロードマップ指向とエコシステム指向 - アンカテ
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
プログラマの数学を読んで、数学の初心を思い出した - $shibayu36->blog;
プログラマの数学を読んだ。 プログラマの数学 作者:結城 浩ソフトバンククリエイティブAmazon この本ではプログラミングに関わる数学について(例えば論理や再帰的な構造など)、わかりやすく説明がされている。 内容についてはある程度知っていたことが多かったが、それより文章の進め方を見て、高校時代に数学が楽しいと思っていた自分を思い出した。 最近は数学勉強するのすごくだるくて、それは大学時代にわけわからない数式を突然見せられて、全く解けないみたいなのを繰り返してたからだった。でも今思い出すと高校のときは、数学の勉強するのすごく楽しくて、自分で数式作って遊んでたりしてた。 プログラマの数学は、基本的に小さいところから初めて、その規則性を見つけ、それを一般的な数式に変えるというのが、一章ごとで行われていた。例えば、100個の中から20個選ぶ組み合わせの問題を、最初は5個から3個選ぶという小さい問
世界で闘うプログラミング力を鍛える150問 〜トップIT企業のプログラマになるための本〜 - iwiwiの日記
先行発売のお知らせ (11/7 追記) 以下の店舗で先行発売が行われているらしいです． 紀伊國屋書店 新宿本店 (https://twitter.com/KinoShinjuku/status/265658160222724096) 紀伊國屋書店 新宿南店 (https://twitter.com/kino_Minami/status/265405470548844546) ジュンク堂書店 池袋本店 (https://twitter.com/junkudo_ike_pc/status/265677297430978562) 有隣堂 ヨドバシAKIBA店 (https://twitter.com/yurindo_akb/status/265648944745426945) 丸善 丸ノ内店 なお，電子書籍版の発売も予定しているそうですが，調整中とのことで少し後になりそうです． 原著は既に第5版
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
【これが現実か・・・】派遣プログラマーの漫画が悲しい(´；ω；`):もえたす
253 名前：名無しさん必死だな 投稿日：2012/09/30(日) 17:43:41 ID:PNbnTbbs0 続きを読む
普通のプログラマへ良いコードを書く方法を教える！リーダブルコード | Act as Professional
私はすばらしいコードを「エレガントなコード」と呼ぶ@HIROCASTERでございませう。 まず、はじめに。本書はハッカーは読まなくて良い。普通のプログラマに読んで欲しい。 デザインパターンやリファクタリングよりも、本書に書かれていることの方がプログラマは毎日考えて、意識してコードを書くのだ。 よって、普通のプログラマならば本書を読んでおきたい。普通のコードを書く人にオススメの1冊だ。 例えるならば、バク転や月面宙返りをする方法ではなく、日常的におこなわれる「歩く」という行動に着目し、姿勢良く、美しく、シッカリ、確実に歩くための方法が書かれている。 本書の目的は、君のコードをよくすることだ。 「良いコード」の定義とは、コードを読んだときに最短で理解できる様に書かれていることである。そう、本書は伝えている。 では、良いコードを書くための方法を具体的に学んだり、教えられたりしたことはありますか？
リーダブルコード
美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より） コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作
プログラマが解くのに1時間かかるという問題が普通にプログラマな方法で5分で解ける話 - きしだのはてな
こういう問題が流れてきた。 まつひろのガレージライフ: 幼児が数分で解けるのに大人が解けない算数（？）の問題 「幼稚園児が５〜１０分で解けるのに、プログラマなどの頭脳労働職の高学歴の方が解くのに１時間もかかる」とあるけど、これ1時間かかるの、プログラマとしてあまりよくないんじゃないのかなーと思った。 ので、プログラマ的に解いてみる。 改めて書き出すとこう。 8809=6 3333=0 7111=0 5555=0 2172=0 8193=3 6666=4 8096=5 1111=0 1012=1 3213=0 7777=0 7662=2 9999=4 9313=1 7756=1 0000=4 6855=3 2222=0 9881=5 3333=0 5531=0 5555=0 2581=??? 問題は英語だし語呂合わせじゃない。幼稚園児にわかるということでそこまで複雑なルールでもない。なんらか
nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下)
March 10, 201213:50 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) さて、前回からの続き。 社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。 一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金食い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。 基本的に旧ブログチームの役割はデ
「無駄にたくさんゲーム作って生きる」 “RucKyGAMES” という生き方 10の新機軸
1. ゲームを無駄に大量生産する ラッキー君はゲームをたくさん作っている。 僕は普段ゲームをしないのだが、i刺身Liteはダウンロードして持っている。 当時はこれが彼のデビュー作だとは知らなかった。 そして今まで2年半で約90本のiPhoneゲームをリリースし、総ダウンロード数は400万に上るという。 2年半で90本ということは、1ヶ月あたり3本のペースだ。 凄い勢いと言って良いだろう。10日に一本のペースでゲームアプリばかりを出し続けているのだ。 なかにはまったく日の目を見ないものもあるという。 それでも出し続ける。それが彼のやり方なのだという。 2. 遊びたいものを自由に作る 他人の目や結果の失敗を気にして躊躇しない。 自分が「遊んでみたい」と思い付いたら、とにかく作ってみる。 どんなにつまらないと思えるものでも、誰かしらの心に引っ掛かる。 そこからがスタートになる。 作らなければ、た
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
: _
ふつうの受託開発チームのつくりかた
