一行でも書け、倒れるときは前のめり（または書かないで済ませる話） - uzullaがブログ
先週金曜日にPerlCasual #5(http://atnd.org/events/37158)が開催されました。 どう考えても発表者の中で俺だけレベルが浮いて（沈んで）いますが、まあ発表してきました（LT軍は、半数が「なんで俺がPerlの会で発表してるの？」と言っていたことを付け加えておきます）。 感想として、とてもたのしかったので、詳細は他の人のブログとか見ましょう。 スライドはこちら Perlcasual #5 発表資料 from Junichi Ishida ※1，2ページ目は当日のネタなのですが、素材を活かす為に削除しないでおきます（めんどくさい） すみませんでした 今は @uzulla による、からみ酒トーク #perlcasual— nipotan (谷口公一) (@nipotan) 2013年3月29日 ものすごい酔いどれ発表だったと思います。テンパっていたというわけでは
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る会に行った - seikoudoku2000のブログ
27日(金)にこのイベントに行ってきたので、内容のメモ。 http://atnd.org/events/16029 スライドがあって云々ではなく、ほぼ伊藤さんのフリートークで、時々、Ianが回答するという形式だったので箇条書き形式にて。 アジャイル全般 スクラムなど、日本から出てきたコンセプトも幾つかあり、海外のエンジニアには、日本がアジャイル先進国だと思っている(勘違いしている？)人も多い。 外注方式ではアジャイルを実践することは不可。ビジネスオーナーと作成者が同じ組織にいなければならない。 基本的な方向性は決まっているけど、最終的なアウトプットは決まっていない状態で実装が進められていく。このため、プロジェクトマネージャーという役割は存在しない。 １〜２週間に１回、ピボットと呼ばれるタイミングを設け、これまでのアウトプットや各フィードバック(数字の話、他社の新機能の話など)を元に次の進め
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
開発中に求めること - ✘╹◡╹✘
7月1日にCookpadにインターンとして参加してから1週間が経過した。「インターンに参加する」では齟齬があり、「インターンとして参加する」が最もしっくりくる雰囲気。ここでは時間が過ぎていくのが速すぎて恐ろしい。月と太陽まで高速なサイクルを回さなくてもいいのに。 今まではてなで働いた経験しかなかったけど、今回クックパッドで働いた経験が1週間貯まった。これまでは「はてなだからこうしているのかもしれない」という捉え方しか出来なかったけど、この時点で「ああどこも共通してこうなっているのかも」という視点に立って考えることが出来る状態になった。その視点から考えてみて、幾つかの共通する意見が明確になってきた。 学習コスト Cookpadの開発は、途中からJoinしやすい環境が整っていた。Railsを採用しているところは特に、内製フレームワークに対する理解の為の学習コストが発生することなく、開発に取り掛
連載：アジャイル開発者の習慣―acts_as_agile｜gihyo.jp … 技術評論社
第4回特別コラム 「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」 角谷信太郎 2008-04-22
1年間の技術的負債を返すために読んだ3冊の本
[この記事を読む前に] タイトルに騙されて来た方はごめんなさい。 恐らく、知っていることばかりが書いてあると思います。 “3冊の本”もベストセレクションではありません。 “たまたま”選んだ3冊の本です。 それでも読んでくれる心優しい方はどうぞ、先にお進みください。 技術的負債は日々、返済していますか。 技術的負債って何？という方はこちらへ。 技術的負債 – Wikipedia えー、正直、私は技術的負債が溜まっています。 お知らせメールを本格的に初めて1年が経とうとしています。 何も無い状態から、手探りで始めて今の状態までなんとか持って行きました。 この計画が立ち上がった当時(2年ぐらい前かな)、自分ができたのは、 PHPが書ける(書けるだけ) サーバが少しわかる(cdとlsが打てるだけ) これぐらいです。 ちょっと大げさですが、あながち嘘じゃない。 そんなこんなで、試行
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
複数人(2-3人)でウェブサービスを開発するコツ - リート開発者ブログ
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
Googleエンジニアから学ぶ、ハッカーになるための勉強法 - 久保清隆のブログ
Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
サイボウズで学んだこと - IT戦記
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
ロケタッチのつくりかた 第4回 プログラマー編 : LINE Corporation ディレクターブログ
ごあいさつ こんにちは吉川です。今回は「ロケタッチができるまで」プログラマ編を書かせていただきます。 ロケタッチではスキーマ定義などのシステムの設計から、ロケタッチのWebアプリ周りのコードの実装を担当させていただきました。 プロトタイプの作成 プログラマとはいっても、今までの連載でも何度か触れられたとおり、今回のプロジェクトではキックオフからの2ヶ月あまりはサービスのコンセプトを決めるためのブレスト等を行っていて実際に設計やコーディングにとりかかることができませんでした。 今までの弊社の開発スタイルではプログラマがアサインされた時点でサイトの概要はほぼ決まっており、作れるところからどんどんコードを書いていくという進め方が多かったため、2ヶ月間作らないというのは本当に初めてのことでした。 とはいえプログラマとしてはコードを書かないでいると不安になるので、この期間にいくつかのプロトタイプを作
ソフトウェア開発を成功に導く法則 - 久保清隆のブログ
デッドライン 作者: トムデマルコ,Tom DeMarco,伊豆原弓出版社/メーカー: 日経BP社発売日: 1999/03/19メディア: 単行本購入: 14人 クリック: 111回この商品を含むブログ (161件) を見るソフトウェア開発の小説。 テーマはプロジェクト管理。 示唆に富む内容が多く、ソフトウェア開発に従事している技術者やマネジャーが読めば、考える良い材料になると思った。 以下、参考になった部分、具体的にどう実践するか考えていきたい部分を中心にまとめ。 【目次】 チャンスとの出会い 管理ごっこ シリコン・バレジット 管理者の最初の仕事 支配者 世界最強のプロジェクト管理者 管理者の採用 リスク管理と生産性 人材管理の智将 モデルとシミュレーション デッドライン：理想と現実 プロジェクトの数量化 プロセスの改良と変更 設計とデバッグの関係 残業の効果 あいまいな仕様書 対立解決
モダンな Perl の開発環境の構築方法 - tokuhirom's blog
一般的な OSX 環境および Linux 環境における、モダンな Perl 開発環境の構築方法についてまとめてみたよ。 perlbrew のインストールperlbrew をつかうことにより、簡単に最新版の Perl5 を利用することができるようになる。 perlbrew をいれる。% curl -L http://xrl.us/perlbrew | perl - install % ~/perl5/perlbrew/bin/perlbrew init ~/.bashrc (または ~/.zshrc)に source ~/perl5/perlbrew/etc/bashrc を追記。あたらしいシェルをたちあげる。最新版の perl をインストールする。% perlbrew install perl-5.12.1 % perlbrew switch perl-5.12.1 ここまできたら、she
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
400万行のコードを15分で見える化！ プログラム解析ツール『Understand』で開発効率アップ
システムの多機能化により、プログラムの内容が複雑化している。テクマトリックスの『Understand』は、プログラムの構造を可視化することで、ソースコードの解析時間を大幅に削減できる開発支援ツール。今回は同社の福永一寛氏に、Understandの機能や特徴について聞いた。 システムの多機能化により、プログラムの内容は複雑化している。既存コードの改修や多人数での開発における情報共有のためには、プログラム構造の理解が必須だが、ドキュメントと実装内容とが乖離している場合も多く、解析自体に工数がかかることもある。テクマトリックスの『Understand』は、プログラムの構造を可視化することで効率的なソフトウェア開発をサポートするソフトウェア開発環境。「組込みシステム開発技術展（ESEC）」にて、同社の福永一寛氏にその特徴を聞いた。 ソースコードの解析作業時間を大幅に削減する『Understand』
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
