Martin Fowler's Bliki in Japanese - 対話的ストーリー
http://martinfowler.com/bliki/ConversationalStories.html 2010/2/4 アジャイル方法論に対するよくある誤解の話をしよう。 アジャイル方法論は、開発のなかでユーザーストーリーを作り、変化させていくことに重点を置いている。 よくある誤解とは、プロダクトオーナー（あるいはビジネスアナリスト）がユーザーストーリーを作り、それを開発者に差し出して実装してもらうというものだ。 この考えでは、流れはプロダクトオーナーから開発者に向かっている。 プロダクトオーナーの責任は何が必要かを決めることであり、開発者の責任はどうやって実現するかを決めることだというのだ。 この考えは、能力に沿った責任の分割をその理由としてる。 プロダクトオーナーはソフトウェアの目的であるビジネスを知っており、何を行うべきかを知っている。 一方、開発者は技術とその方法を知っ
DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組
このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 （元請け会社の2人、当時同じ会社だった先輩、僕の4人） そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201
規模の大きい本番システムをGo言語で書き直した感想 - ワザノバ | wazanova.jp
http://matt-welsh.blogspot.com.au/2013/08/rewriting-large-production-system-in-go.html Go言語の４周年をテーマにしたgolang.orgのブログで紹介されていた、GoogleのMobile Web Performanceチームに所属するMatt Welshのブログです。大規模な本番システムの作り直しにGo言語を採用した経験を語っています。 1) 背景 C++のオリジナルのコードベースは問題なく作動していたが、何年も複数の目的の違うプロジェクトで共有されていたため、スピーディーに改修するのが難しくなっていた。（何のシステムなのか具体的に書いてないのは残念。。） イメージフォーマットをトランスコードするライブラリはC++で完璧に動作していたので、そのまま残し、それ以外を全てGo言語で書き直した。 元のコード
スキル差の存在を前提としたJava開発の私の理想 - Kengo's blog
スキルの低い人が生産性における問題ならその人を何とかするのが根本解決だよねと話したら、人に強要することなんてできないじゃないですかーという反応をいただいた。 これはすごく的を射たもので、チームを引っ張ってモノづくりをするうえで・チームを引っ張らせてモノづくりをするうえで重要な着眼点になると思っている。 個人の尊厳や主体性は最大限尊重すべきだし、様々な発想を持ち込めること（多様性）こそがチーム結成の価値の1つでもある。もしも開発プロセスやそのツールをガチガチに固めてしまうことで自由なチャレンジができなくなるのだとしたら、それは価値ある生産物を主体的・継続的に提供する能力の低下につながるだろう。そもそも変わりゆく環境の中で、1つのプロセスがずっと最適である保証も無いのだ。 では、どうするべきなのか。基本的には以下の原則を守ることだと思っている。 チーム全員が同じ方向を向こうとすること 気づきの
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
いまどきのPHP開発ノウハウを詰め込んだ『PHPエンジニア養成読本』が出るので、見所をまとめてみるよ
いまどきのPHP開発ノウハウを詰め込んだ『PHPエンジニア養成読本』が出るので、見所をまとめてみるよ 2013年08月27日 13:02PHP この本に記事を書きました。9月13日発売予定です。 Amazon.co.jp PHPエンジニア養成読本 こんな内容 以下の項目のどれかにピンと来る人と、 いまいちピンと来ないという人のための本です。 PHP最前線 PHPの最新動向 いまどきPHP開発技法入門 [最新]ライブラリ&フレームワーク活用の基礎知識 [新定番]Composerの基礎と活用 フレームワークを本当に使いこなすための考え方 Symfony活用のポイント FuelPHP活用のポイント CakePHP活用のポイント 注目フレームワーク総ざらい 現場で役立つ PHPエンジニアの開発術 PHPUnitではじめる自動テスト Gitでばっちりソースコード管理 いまさら聞けない「公開鍵認証」
テンプレートを追加するプラグインの作成 — Eclipse Plugin 開発チュートリアル v1.1 documentation
テンプレートを追加するプラグインの作成¶ それではプラグインの作成に入りましょう。これから作成するプラグインはエディタ上でコンテントアシストを行うと、テンプレートのテキストを追加するプラグインです。妥当な名前でテンプレートを追加していけば行くほど開発を楽に進める事ができるでしょう。そういったちょっとしたプラグインの追加方法を学びます。 このチュートリアルではEclipseの機能、ショートカットを活用しながらプラグイン開発を行います。ショートカットは(Ctrl+Shift+L)を押すと一覧が表示されます。もしよく分からなくなった場合はこの一覧を参照されるとよいでしょう。 (MacOSX上の表示なので、キーの記号が違っています。WindowsであればCtrlやAlt、Shiftの一覧が表示されるでしょう。) この章で作成するプラグイン¶ JavaDoc上でmemoと入力し、コンテント・アシスト
Eclipseプラグイン開発自分FAQ
ここでは、 Bulletnoteを開発した際に分かったことを中心に、 Eclipseのプラグインを 開発する際のFAQを勝手に設定して勝手に答えている。 Eclipseは、デザインパターンを活用した、 ポストモダンでデカダンでレーゾン・デートル なアーキテクチャになっているので、 そのプラグインを開発する際、非常に簡単なことを実現するにも 非常な困難にぶちあたることがままある。 いま目の前にあるテキストを取り出すにも、 耳の穴から指を突っ込んで奥歯をがたがたいわせながら舌をひっぱるような、 手の込んだメソッド呼び出しが必要になったりする。 パズルとして考えれば楽しくないこともなくもなくもないが、 プログラミングでいちいちこんなことをやらされるとなかなかつらいものがある。 加えて、ドキュメントが圧倒的に不足している。 一応Helpおよびいくつかの記事があるが、基本を網羅しているとは 言いがた
第1回 Node.jsとは | gihyo.jp
はじめに 本連載では、注目を集めるNode.jsを使って、Webアプリケーションを様々なクラウド環境で動かすことを最終目的にしています。Node.jsに触れたことがないJavaやPHPなど普段サーバサイドで開発されている方を主な対象として、まずNode.jsの概要から紹介していきます。 Node.jsとは Node.jsとは、ブラウザGoogle Chrome用に開発されたJavaScriptエンジンV8がサーバ上でプログラムを実行できるように、ファイルやネットワークI/Oなど多くの機能を追加したものです。軽量で効率よく多くのリクエストを処理するネットワークアプリケーションの構築ができるプラットフォームになっています。いわゆるサーバサイドJavaScriptの代名詞として注目を集めています。 Node.jsでは“軽量で効率良く”というのを実現するために次の2つのモデルを採用しています。
「はてな教科書」をgithub上に公開しました - Hatena Developer Blog
こんにちは、id:shiba_yu36です。 はてなのエンジニア陣によって執筆されたウェブアプリケーション作成の基本を学ぶための「はてな教科書」をgithub上に公開しましたのでお知らせします。 はてな教科書は、はてなサマーインターンでも利用されている、約1週間でウェブアプリケーションの基本を身に付けるためのものです。はてなでは日々のウェブ開発で得られたノウハウをこの教科書を継続的に盛り込みながら、インターンシップやエンジニアの新人教育などに利用しています。今回、はてな教科書をgithub上で公開することで、広くPerlを使ったウェブアプリケーション開発に興味を持ってもらえれば、と思います。 いまのところ公開されている資料は、以下の4つになります。 Perl によるオブジェクト指向プログラミング ORM によるデータベース操作 (DBIx::MoCo を使った開発) MVC によるウェブア
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance
403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした＆ありがとうございましたー！ SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問
新しい何かに取り組むプログラマさんたちへ | y_matsuwitter's
桜の季節が近くなってきましたね。 春といえば出会いと別れの季節です。 我々プログラマも、ともすると４月から就職して新しいプログラミング言語やプロジェクトに出会うのではないでしょうか。 僕は１月に戦場を移動した関係で、１月から初めてRubyに取り組みました。 またObjective-cも書き始めています。 何かの参考になればと思い、今回の経験から僕なりの新しいプログラムへの取り組み方の定石みたいなものを偉そうに書いてみようと思います。 Kiai Driven Development 新しい言語やプロジェクトに出会ったとき、KDD（気合駆動開発）信奉者の僕が気を付けている点が３つ有ります。 それを一から紹介します。 Githubをとにかく巡れ！ 新しい言語に取り組むとき、僕はまずGithubのその言語に関するwatchやfolkのランキングを見てます。 ランキングは、Github上部のExpl
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
7462
Clean Coder Blog
BLOGOS サービス終了のお知らせ
