開発者にやさしい環境
ikeike443と申します。このブログの言いだしっぺです。 シャノンに転職してきてちょうど1年になります。前職は業務パッケージソフトの会社に所属していました。 転職してきた経緯などについては、下記のインタビュー記事で話したので、よかったら読んでください。 SaaSの可能性を信じて、新たな道を踏み出したエンジニアの「視点」 で、今回はとりあえず、シャノンに入社してこれは”いいね”と思ったポイントをつらつらと挙げてみます！ アジャイル開発やってるよ 開発方法論としてはアジャイル開発手法の一つ、Scrumを採用しています。 約一ヶ月をひとつのスプリントとみなして、毎月頭にスプリントの計画と見積りをして開発／テストに入ります。 毎朝のミーティングでバーンダウンチャートを確認し、文字通りみんなでスクラムを組んで開発しています。 バーンダウンチャートの作成、プロダクトバックログの管理には、ヌーラボさ
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W. Reeves 氏に，
これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
「ひとりぼっちのプログラマ」に読んで欲しい、『 プログラマが知るべき97のこと』 - ただのにっき(2011-01-08)
■ 「ひとりぼっちのプログラマ」に読んで欲しい、『 プログラマが知るべき97のこと』 オライリーの高さんから献本いただいた。いつもありがとうございます。 この本はねぇ、「ひとりぼっちのプログラマ」にぜひ読んで欲しいなぁ。 ここでいう「ひとりぼっち」にはふたつの意味があって、ひとつは「ひとりでがんばっているプログラマ」。 Twitterやブログを読んでいると、仕事でいろんなことにチャレンジしたり、業務を改善したりしたいと思っているのに、職場の文化が壁になったり、上司の理解が得られなくて歯がゆい思いをしている若いプログラマの叫びが、それはもう、かなり頻繁に聞こえてくる。10年前ならいざしらず、今ならさっさと転職してしまうのが正しい道だろうけど、そうもいかない事情を抱えている、でも現状をなんとかしたい……そう感じているひとりぼっちのプログラマにとって、本書はいい味方になってくれると思う。というか
Don't Tell, Ask - 求めよ、命じるな - @katzchang.contexts
えーと、どんな因果か、レビューされる側よりもする側になることが多くなってしまった。 対象となる生産物の欠点を指摘することは、レビューの大事な役割の一つであるとされている。だが、レビュアーとして一番怖いのは、間違った指摘や無意味な指摘をしてしまうことだったりする。そう、レビュアーもまた間違いを犯すんだよ。恐ろしいことに。 そこで有効なのが、"Don't Tell, Ask."「求めよ、命じるな」の原則。 レビュー対象物の「至らなさそうな点」に対して、なぜそこはそうなっているのかについて答えるよう求める。自分がより良いアイデアを持っていれば、それを伝え、どちらが優れているか判断を求める。「ここは、こうしてよ」のような命令（出す側は「アドバイス」と呼ぶ）は出さない。だって、レビュアーの意見の方が優れている保証なんて、何もないんだからね。 そもそもレビューをするのは、そのアドバイスに黙って従う初級
Sooey - なぜ日本のネットベンチャーはエントランスばかりが小奇麗で、執...
なぜ日本のネットベンチャーはエントランスばかりが小奇麗で、執務スペースは養鶏場のような有様なのでしょうね。執務スペースだけはクリエイティビティが感じられない。転職準備金200万円よりも、もっとゆったりしたデスクを用意したほうがよっぽど効果あると思うのだけど。 ディー・エヌ・エーさん、執務スペースは広いけどデスクが縦横にずらり。 blog::941:株式会社ディー・エヌ・エーに行ってきた！ Googleワナビーなオフィス造りがちょっと気になるグリーさん（初代サーバーの展示とか）、執務スペースだけはいかにも日本のオフィスという感じで残念。 blog::941:グリー株式会社 に行ってきた！ エントランスなどがアーティスティックでシャレオツなスタートトゥデイさん、執務スペースは広いけどデスクはギッチリ詰まって並んでて残念。 blog::941:ZOZOTOWNで有名な 株式会社スタートトゥデイ
ブルックスの法則、再び - 書評 - 人月の神話/デザインのためのデザイン : 404 Blog Not Found
2010年12月19日11:45 カテゴリ書評/画評/品評Art ブルックスの法則、再び - 書評 - 人月の神話/デザインのためのデザイン ピアソン桐原の畑中様より献本御礼。 デザインのためのデザイン Frederick P. Brooks / 松田晃一・ 小沼千絵訳 [原著:The Design of Design] 人月の神話 Frederick P. Brooks / 滝沢徹・ 牧野祐子・ 富澤昇訳 [原著:The Mythical Man-Month] あのブルックスの法則から35年。銀の弾丸が幻に過ぎないことを知った我々は、それからどれほど進歩をとげたのか。 本人にたずねてみようではないか。 「人月の神話」("The Mythical Man-Month")は、それを知らずに協調作業が何たるかを語ることが許されない一冊。作業をするだけの人であればとにかく、作業を命ずる立場の人で
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
なぜ前日できなかったプログラミングが次の日になるとできるようになっているのか « モノづくりブログ 株式会社8bitのスタッフブログです
こんにちは。 プログラミングと企画の狭間で右往左往している高本です。 現在次のサービスを作るために、割とプログラミング作業がメインになっているここ最近ですが、自分がやったことがないことを実現しようとした時に、大抵うまく動かずに躓きます。 ですが、 前日できなかったことが次の日になって改めてやってみると結構あっさりできるようになったことはないでしょうか？ 私個人は帰宅したあと調査したわけでもないのに、次の日には整理できて実現できることが結構あります。 どうしてなんだろう。。とここ最近考えていました。 新しいことや、やったことのないことをやってみるのは技術者としては一番面白いところでもあり、期限があれば一番辛いところだと思います。 初めてやる技術はネットサーフィンをしたり、技術書を読んだりして、いろんな方が書いたサンプルコードを引っ張ってきて検証して、自分の作ろうとしているものに徐々に形を変え
エンジニアでないファウンダーは最大一人まででお願いします
インターネット系ベンチャーがアメリカでエンジェル投資を受けるために重要なものの一つが「ファウンダーの中に技術者がいる」ということ。一番セクシーなのが、「３人全員MITのコンピュータサイエンス」みたいに、わらわらと優秀そうなエンジニアが始めたベンチャー。 一方、コードがかけない人はマックス一人、つまり、ゼロか１、というのが理想型でございます。 なぜか。 理由１：変更につぐ変更を重ねられるようにする 最近 lean startup なる考え方がはやってますが、これはどういうことかというと、 トライする回数 × 成功率 ＝ 成功 という式で、成功率の方をあげることは不可能なので、トライする回数を圧倒的に増やすのが成功の鍵だ、という発想なり。 サービスを作って、世に出して、使ってもらって、ユーザのフィードバックをもとに改善、改善などという生易しいものではだめそうだったら一度アイデアをスクラップして
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
グリー株式会社 に行ってきた！ - 941::blog
ハラショー！！！！ くしいです。 インターネット業界をもっと多くの皆さんに知っていただきたい！ という熱い熱意を持ってやらせていただいております、この「行ってきた！」 シリーズもなんと33エントリ目。ゾロめ！あ、そういやワンピース再開ですね。 まぁそんなこんなでいつも暖かく見守ってくれている私の会社の上司の皆さんには 感謝しておるわけなんですけども。ライブドア万歳！ね。そういうカンジです。 はい、というわけで。六本木ヒルズというところにグリーさんが お引っ越しされたとのことでお呼ばれされちゃったのでご紹介したい。 最近はTVコマーシャルでもよく見かけるグリーさん、その名前の由来もユニークで 詳しくはこちらの会社情報のページなどをご覧いただけるとよいかも知れない。 ほい！やって来ました受付！無人！ ==== ちょいと進むと ※公開から3ヶ月以上経過した特定の記事は有料となっている場合がありま
Googleエンジニアから学ぶ、ハッカーになるための勉強法 - 久保清隆のブログ
Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版)
こんにちは murahashi です。 アジャイルな開発をチームでやってみている(2010年)のですが、いざやってみると結構ハマリどころがありました。やってみたことを共有しておこうと思います。 かたちから入ろう 朝会 アジャイルな開発と言えば朝会なので、朝会から始めました。 開始時刻をメンバーで決めて、それぞれが昨日やったこと、今日やること、おしらせ、困っていること、を共有しました。 さらに、朝会前に社内wikiにメモ書き程度の項目を書いておきます。これにあらかじめ目を通すことで、一番の課題に時間を集中することができました。 アンチパターン・決めた時刻を守らない 11時から朝会始めようと決めたのに、11時過ぎに汗だくで飛び込んできて「遅れてすみません」「wiki書いてません」「wiki読んでません」というのは、チームの空気を悪くするだけでなく、単純に全員の時間を無駄にしてしまいま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オーム社eStore
Loading...
プログラミングに関するあまり知られていない７つの真実
エンジニアが求める職場環境まとめ（暫定）
