タグ

ブックマーク / higayasuo.hatenablog.com (15)

  • ムービープロトタイピング - ひがやすを技術ブログ

    pixtuneというアプリをリリースしました。 pixtuneをひとことで説明すると、「Play the moment」。 自分の撮った写真と、写真を撮った当時にはやっていた曲を一緒に楽しむアプリです。どういうアプリなのかは、動画を見た方が早いと思うので、まずはこちらをどうぞ。 無料なので、興味がある方は、ぜひダウンロードしてください。 https://itunes.apple.com/jp/app/pixtune/id722162353?mt=8 今回は、このアプリの開発に使ったムービープロトタイピングという開発手法を紹介したいと思います。 ムービープロトタイピングは、私が勝手につけた名前(大目に見てください)で、アプリのプロトタイプをムービーで高速に行う手法です。プロトタイピングの手法としては、ペーパープロトタイピングが、手軽かつ効果的で、このプロジェクトでも、最初、ペーパープロトタイ

    ムービープロトタイピング - ひがやすを技術ブログ
    atsuizo
    atsuizo 2014/02/12
    アプリよりもムービープロトタイピングに関心が行ってしまう件。そして、そっちの作業を支援するプリが公開されたらなおさら嬉しい。
  • Google App EngineでGlobal Transaction - ひがやすを技術ブログ

    Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi

    Google App EngineでGlobal Transaction - ひがやすを技術ブログ
    atsuizo
    atsuizo 2010/02/10
    送金処理を意識したトランザクション管理とか、ベタ基幹・業務システム目線で考えてくれる方がフレームワーク作ってくれるというのはほんとにすばらしいことだと思う。
  • 男児たるものGoogle App Engine実践クラウドシステム構築を買うべきだ - ひがやすを技術ブログ

    なぜなら、Google App Engineを学ぶために一番必要なのは、「何ができないかを知ること」だからだ。そして、このにはそれが書いてある。それしか書いていないといってもいい。 App Engineは、Googleのインフラを最も効率よく使うことにフォーカスしている。Genericなアプローチではなく、Specializedなアプローチだ。 何かを得ようとするならば、それと等価の何かを支払わなければいけない。App Engineは、Googleのインフラを最も効率よく使うために、「いくつかのAPIが使えない」という対価を支払った。 だからこそ、App Engineを知るためには、最初に何ができないのかを知らなければいけないのだ。 あなたは、その制限という対価と引き換えに、Googleから安価なスケールするプラットフォームを手に入れることができる。 EC2はGenericなアプローチだ

    男児たるものGoogle App Engine実践クラウドシステム構築を買うべきだ - ひがやすを技術ブログ
    atsuizo
    atsuizo 2009/09/30
    男児なのでもう買って読んでます。キリッ
  • DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ

    Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/

    DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
    atsuizo
    atsuizo 2009/07/30
    あとで買う、と思う。厨とは言えない程度のDOA好き。OOA弱いだけっていうのは大きな声では(ry
  • そろそろSeasar2のガラパゴス戦略について語っておくか - ひがやすを技術ブログ

    Slim3のファーストリリース(今月中)の前に、Seasar2の開発で、どのような戦略をとったのか話しておきます。 2005/11/8、Seasar2.3のバージョンをリリースしました。このバージョンから搭載されたのが、コンポーネントの自動登録機能です。設定ファイル無しで開発できるようにする機能ですね。Springだと2.5から搭載されたcomponent-scan。 Spring2.5のリリースは、2007/11/19なので、実に2年以上差があります。オープンソースの世界では、みんなが手の内を見せ合っているので、誰かが新しい機能を実装した場合、それが良いものであれば、ライバルも直ぐにそれを取り入れ、それほど機能差がつくことはありません。 なぜ、従来のXML地獄を解消する「コンポーネントの自動登録機能」を実装するまでの期間にこれほど差が出たのか、それはガラパゴス戦略のせいなのです。 Sea

    そろそろSeasar2のガラパゴス戦略について語っておくか - ひがやすを技術ブログ
  • S2DAOやXen,OpenOfficeなどが大手ベンダーの定番に - ひがやすを技術ブログ

    iBatis, Seaser(S2DAO)などのO/Rマッピング・ツール, TortoiseSVN, Tracなどのソフトウエア管理ツール,バグ管理ツールのBugzilla, pgAdminやMYSQLAdministratorなどのデータベース用管理ツール, テストツールのSelenium, Eclipse WTPやFirebug, 軽量データベースのFirebird, Sqliteも複数の大手ベンダーで実績がある。 意外な調査結果ですねー。 Seasar類(ガートナー用語、Seasar2を中心としたプロダクト群をさすらしい)は、開発の現場で使われているとは思っているけど、ほとんどの大手ベンダーで実績があるとは正直意外です。もちろん、ここに出てくる大手ベンダーの中には、Seasar2の商用サポートを利用されている方々もいるので、使っていることは知ってましたが、極一部の話だと思っていたから

    S2DAOやXen,OpenOfficeなどが大手ベンダーの定番に - ひがやすを技術ブログ
    atsuizo
    atsuizo 2009/05/08
    喜ばしいことだし、ますます推進してほしい。でも「実績がある」の基準って何だろう?大手でも現場の裁量で決められる範囲があるので、1案件だけでも「実績あり」なのかな。推奨製品入り、ならかなり良い結果。
  • DRYについてのよくある誤解 - ひがやすを技術ブログ

    WEB+DB PRESS vol.49で、「現場で役立つDRYの基礎知識」が特集されています。とても、良い記事だと思うので、ぜひみなさん、読んでください。 ただ、ちょっと補足をしておきます。 記事の中で、DRYは、「達人プログラマー」の中で、とりあげられ、Railsによって広まったとされています。確かに、Rubyの世界ではそうかもしれないけど、DRY原則というのは、ERモデリング(DOA)の世界では、ずっと「One Fact In One Place」という言葉で知られてきました。 ERモデリングにおける正規化は、「One Fact In One Place」を具体的に実現するための手段です。 DRYという言葉そのものを広めたのは、間違いなくRailsです。しかし、DRYの考え方そのものは、昔からあったし、「One Fact In One Place」という言葉も、昔から有名だったというこ

    DRYについてのよくある誤解 - ひがやすを技術ブログ
  • 一からやり直すより今あるものを改良する - ひがやすを技術ブログ

    純粋にフレームワークとして考えると、少なくとも今のSAStrutsを見る限りStrutsに縛られずに作ったほうが使いやすいものができそうな気がするのですが、ひがさんの次回作(Slim3 Struts)もStrutsベースのようなので、なんだか残念な感じです。それともSlim3 Strutsでは今までSAStrutsで不満に感じていたことが解消されているのかも…。 SAStrutsはStrutsが足かせって言うのは、まぁそうです。自分で、最初から再設計したほうが、いいものができると思っているんだけど、知識の積み重ねは無視できないんですよ。 単に、Strutsは、人が集めやすいというだけじゃなくて、みんなが知っているところに意味がある。 知識はそう簡単に蓄積しないもの。 おいらが選んだのは、今あるものをすべて捨てて、一から作り直すより、今あるものの弱点を地道につぶしていくこと。竹添さんが、不満

    一からやり直すより今あるものを改良する - ひがやすを技術ブログ
    atsuizo
    atsuizo 2009/01/05
    「1からやり直したほうがマシ」は、誰もが陥りがちな、魅惑的な罠。自戒。
  • ラインが消える日 - ひがやすを技術ブログ

    掲示板のIBMの転職スレを見てると、40以上で給与の高いラインマネージャこそ、リストラすべきだという意見を良く見かけます。 給与が安くてたくさん働く若者を残して、給与が高くてあまり働けないラインをリストラしたほうがいいというのは、理にかなっている気はします。 ただ、今バリバリ働ける「あなた」、いろんなことを吸収できる「あなた」、いつまでも同じように続けていけると思います? 例えば、今最先端の開発ができる人でも、いつまでも最先端でいるのはつらいなぁと思っている人って意外と多いんじゃないかなぁ。 最先端でいるのがつらくなったら、これまでの経験を生かして、ラインになりたいと思っている人も多いでしょう。 そうすると最初に戻って、不況のときには、そんなラインが切られていくわけですよ。若いときは安い給料で一生懸命働いてきて、ようやくラインになって、給与もそこそこもらえるようになったら、リストラの対象

    ラインが消える日 - ひがやすを技術ブログ
    atsuizo
    atsuizo 2008/12/09
    サービスラインでしょ、サービスとかソリューション単位の部門の。自分がいたファームにはあった。ラインマネージャになると現場からは一歩下がるけど、とても重要なポジション。「わかっていて管理する」のは大変。
  • 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ

    自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか? 自社と外注先との間の契約がどのようになっているのかご存じですか? それを目の当たりにしても同じことを言い続けられる自信はありますか? そういうことはスーツ仕事とレッテルを貼って見て見ぬ振りをしてませんか? それでいて業界を変えたいなどといいますか? 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同

    「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
    atsuizo
    atsuizo 2008/10/17
    ひがさん、見事に釣られてる。
  • Seasar2本書き終わった - ひがやすを技術ブログ

    SAStrutsとS2JDBCを使ったWebアプリケーション開発のを書いていたんだけど、ようやく書き終わりました。Dolteng、SAStruts Plugin、DbLauncherの使い方や、設定ファイルの解説もつけたので、結構充実した感じになったと思います。 店頭に並ぶのは、12月前後かな。 これで、Slim3の開発に専念できるようになったよ。

    Seasar2本書き終わった - ひがやすを技術ブログ
    atsuizo
    atsuizo 2008/10/13
    ほしい
  • RailsとSeasar2で同じアプリを作って比較する - ひがやすを技術ブログ

    この間から、コードなにがしに「SAStrutsによるWebアプリケーションスーパーサンプル」を投稿し始めましたが、さらに同じ仕様のものをRuby on Railsで作成してみようと思いまして「Ruby on Railsあれこれ」に「Ruby on RailsによるWebアプリケーションスーパーサンプル」も始めちゃいました。。。 RailsとSeasar2で同じアプリを作っている方がいました。 nanigac.com Loading... Seasar2の方は、とても情報が充実しているので、SAStrutsとS2JDBCで開発されている方は一度目を通しておくといいんじゃないかと思います。 生産性の違いはというと コーディング量は、 「Ruby on Rails」<「SAStruts」 ですね。Railsの方が、生産量は少なくすみます。 ただ、情報の充実度は、 「Ruby on Rails」<

    RailsとSeasar2で同じアプリを作って比較する - ひがやすを技術ブログ
  • このままだとSIerの給与水準は下がっていく - ひがやすを技術ブログ

    今後のビジネスの方向性として、たいていのSIerは、上流を強化するだとか、上流にシフトするだとか、上流に専念するなんて答える。 下流には、付加価値がつけられないから、自分たちの付加価値をつけるためには、上流を強化するしかないと思っているSIerの人も多い。 でも、みんなが同じ方向を向いたら、最後は価格競争になる。 日の市場が厳しくなっているので、ブランド力よりも価格が重要視される割合が増えてきているのです。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 ひがやすを氏の会社がプログラミング・ファースト開発を標榜

    このままだとSIerの給与水準は下がっていく - ひがやすを技術ブログ
    atsuizo
    atsuizo 2008/09/02
    ITゼネコンのヒエラルキーから離れたいなとなんとなく思っていたが、その核心となる原因をキレイにまとめられた気がする。
  • 深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ

    SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大

    深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
  • プログラミングファースト開発の必要性 - ひがやすを技術ブログ

    ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

    プログラミングファースト開発の必要性 - ひがやすを技術ブログ
    atsuizo
    atsuizo 2008/07/22
    ひが氏の意見にここまで同意できたの初かも。これでもまだ日本のビジネスでは実現難しいかもしれないけど。ただ、設計書が後ろになると、「何を保証するのか」の定義の明文化はどこへ行くのか。そこで準委任か。
  • 1