「人々が強烈なあこがれを持つような、ダンスを作るハード作ってよ」と会社にいわれたら、あなたならどうする? 自信も経験もないから断る? 僕は、自身も経験もなかったけど、これは面白そうだと直感的に思った。 そして、DJ&トラックメイカーに転身。この仕事をやり切ることを決意した。 これからは、DJ HIGACHANとして生きていきます。よろしくお願いします。 さて、DJ HIGACHANとしての最初のエントリは、「SmartNewsとBacklogの作り方」。 Seasar Conferenceの目玉セッションの一つです。浜本階生さんと橋本正徳さんに登壇してもらい、私がモデレータをつとめます。 SmartNewsといえば、全世界で1300万ダウンロードを突破し、アメリカでもMAUが100万を超えるなど、世界レベルで快進撃中のアプリで、その代表取締役の浜本さんは、世界レベルでモテモテです。 セッシ
ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 35才(2004年)でプログラマとしてオープンソースを始め、今年で42才になる俺が通りますよ。 35才までは、SIerの中でSEをやってたので、そんなにプログラムは書いたことがないです。 上記のエントリには、いろんな戦略が書いていますが、ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは、常に自分の価値を高めるために努力し続けることです。 努力や挑戦をやめたら、自分の価値はどんどん陳腐化して下がっていくのは当たり前なのです。 自分がどんなことに挑戦してきたのかちょっと書いてみますね。 2004年1月、プログラマとして何か新しいこ
Google App Engineに最適化したJavaフレームワーク「Slim3」登場。作者のひがやすをさんにインタビュー Slim3は、Google App Engineで複数行のトランザクション操作を可能にし、標準で用意されているAPIよりも高速な動作を実現するなどの特徴があります。Slim3を開発したのは、オープンソースのJavaフレームワークとして知られるSeasarなどを開発してきたひがやすを氏です。 正式リリースにあたり、Slim3の特徴、開発に苦労した点、今後の展開などについて、ひが氏自身に説明してもらうべくインタビューをしました（インタビューはメールで質問し、返答いただくという方法で行いました）。 Slim3の設計哲学は、“Less is more”を実現すること ―― Slim3とは何でしょうか？ Javaにそれほど詳しくないというプログラマにも説明するとしたらどう説明す
「クラウド」や「内製化」で変わりつつあるIT業界。その中で従来型のSIerはどうなるのか。そこで働くITエンジニアはどうするべきか。講演やブログを通じてSIerやエンジニアについて提言を行ってきたひがやすを氏へのインタビューから、2010年の「自分戦略」を立案するためのヒントを探ろう。 第4回｜1 2｜次のページ 1週間にわたってお送りしてきた特集「SIerの未来、エンジニアの未来」。最終回は、システムインテグレータ（SIer）に勤めながら従来型のSIerに数々の提言を行ってきた、Seasarフレームワークの開発者ひがやすを氏に、SIerが今後どうなっていくのか、ITエンジニアはどうあるべきかを聞いた。 2010年のあなた自身の「自分戦略」を考えるうえで、参考になれば幸いである。 ■ 従来型SIerは崩壊する ―― 今年はSIerにとって苦しい年となりましたが、今後SIerはどうなっていく
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
タイトルは釣りです。 ただ、kawangoさんが、だめな受験勉強をしている人を例にあげて、だから受験勉強はだめなんだと結論付けているので、本当の受験勉強とはどんなものか説明しましょう。本当っていっても、自分の経験と周りを観察した範囲のことですが。 個人でやらないとお金が足らなくなるからといって、個人でやれば成功するという理由にはならない。けれども成功する道は必ずあるはずだからとドラマの熱血主人公のように思い込んだとき、それは個人でやるという道の中に隠されているはずだという結論がでてしまうんだと思う。 でも、それって、解答が必ずある試験問題の解き方なんだよね。 受験では、「正解を出すことが重要だ」という思考パターンで動いていると思われているようですが、実際は「正解を出すよりも点数を取ることのほうが重要」です。説明不足で答えだけあってる答案よりも、最後の結論は間違っていても、答えを導き出す仮定
例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働
今は友人までの公開になっているので、リンクをクリックしても発言を読めません。このエントリを書いたときは誰でも読めたんだけどね。 勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃねーの？ 仕事は、一人ではできないので、いろんな人に支えられてやっています。そういう意味で、支えてくれる人なしには何もできないのは事実です。 で、だ。 自分はどうかといえば、おれは、ほとんど、一人で仕事をしているから、下請けとか関係ないです。うちの会社でどうかといえば、下請けに仕事を押し付けている人なんていないですよ。みんな仕事大変だからね。忙しいし。 で、だ。 誰に言っていてもいいんだけど、上記の言葉の裏には、コミュニティ活動は、暇だからできるみたいなニュアンスが感じられるんだけど(間違っていたらごめん)、コミュニティ活動ってかなり大変だよ。 例えば、この前、「ひがやすを飲み会」なんて
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
私がSlimというプロジェクトをはじめるということは、Seasarカンファレンスで発表しました。 http://itpro.nikkeibp.co.jp/article/NEWS/20080524/303949/ もともとSlimのコンテナ部分は、Seasar2からもってくるつもりでしたが、最近、NTTデータやCTCのフレームワークをやってる部隊がSpringベースのフレームワークにいろいろ悩んでいることを聞いて、Slimのコンテナは、Springベースにしたほうが、世の中のためになるんじゃないかと思い直しました。 NTTデータと真昼の対決 CTCと夜の決闘 もちろん、SpringベースでHOT deployを提供します。エイプリルフールネタを現実にやるということですね。 Super Agile Spring HOT deploy可能なSpringの上に、SAStrutsとS2JDBCを移
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して
リリースノートはこちら Bug [SASTRUTS-18] - ArrayWrapperでListを実装するようにしました [SASTRUTS-20] - ActionからActionへ遷移できない問題を修正しました Improvement [SASTRUTS-19] - ActionのプロパティがMapの場合も扱えるようにしました ダウンロードはこちら http://sastruts.seasar.org/download.html このバージョンから、チュートリアルに、ResourceSynchronizerプラグインを使ったリッチなエラーページをつけました。ResourceSynchronizerを超ざっくり説明すると、ブラウザからEclipseを操作するプラグインです。 チュートリアルのリッチなエラーページをクリックすると、Ext.jsで作ったリッチなエラーページが表示されます。ス
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
