タグ

開発に関するohnishiakiraのブックマーク (48)

  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • 私が参考にしたAndroidアプリ開発情報をまとめてみました - もとまか日記

    先日、以下の記事で初めて作ったAndroidアプリを紹介しました。 一週間で初めてのAndroidアプリを作ってみました その後、そのアプリをAndroidマーケットで公開してみました。 はてブ閲覧用Androidアプリ「HTBPocket」を公開しました この一連の作業で参考にした記事やサイトについて、「Androidアプリ開発関連情報まとめ」としてまとめてみました。 開発環境構築まず必要になるのが開発環境です。以下はMacの環境構築です。MacAndroid SDKをインストール (Update 2010.05.25) そして以下がWindowsでの環境構築です。私はやったことないのでよく分かりませんが(^^;;世界を目指せ!Androidアプリ開発入門:第2回 Androidアプリ開発のための環境構築 公式の開発情報公式の開発者向けサイトです。Android Developers

  • エラー処理設計:対処方法をシステム全体で定める

    システムのエラー処理を総合的に設計する どんなシステムでもエラー処理は欠かせず、たいていは大きな割合を占める。システム上のエラーはもちろん、業務上に代表される問題領域のエラーまで対応しなければならないからだ。エラー処理の基は、エラーを検出し、その結果によって適切な処理を実行すること。しかし、システム全体でみれば、異なるタイプのエラーが数多くあるため、エラー処理が分散するし、エラーの種類ごとに対処が違う。完成度の高いシステムを目指すなら、全部のエラーを把握しながら、システムを設計する必要がある。 一部のエラー処理は、システムの基構造と深く関係している。エラー処理を重視すると、システムの基構造に影響を与える。逆に、システムの基構造がエラー処理の一部を制限することもある。仕方がないので、両者の妥協点を見付けるしかない。 この点を考慮し、次のような手順で基構造を設計する。最初は、エラーが

  • エラー処理とログ出力

    ソフトウェアの開発において、エラー処理は、時には来の機能よりも重要です。業務として開発するソフトウェアでは、来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト

  • http://japan.internet.com/busnews/20111013/8.html

  • 誤って理解してほしくない日本的「デバッグ」と欧米の「ユーザーテスト」の違い(下) | 新清士の「デジタルと人が夢見る力」 - コミニー[Cominy] / ブログ

    プロフィール 新清士 ジャーナリスト。立命館大学映像学部非常勤講師。1970年生まれ。慶應義塾大学商学部及び環境情報学部卒。著書に、『ゲーム産業の興亡』(アゴラブックス)。 「デバッグ」と「ユーザーテスト」は違う アメリカのエンジンを使ったゲーム開発のプロセスと日との決定的な違いを上げるならば、この弊害を徹底的にデータ的に調べ上げることによって、迅速に質を上げる方法を作り上げたところだ。各ゲーム会社によって多少の差異はあるが基は同じことだ。 多くのゲームは、それぞれの面ができあがるごとに、1?2週間ごとに、QA(品質保証)チームにまわされ、「ユーザーテスト」を受ける。間違えて理解してはいけない。決して、単なる「デバッグ」ではない。日で言われるデバッグは、ゲーム内のバグを取ることを目的としており、デバッカーが上げてくるゲームバランスの提案や、調整の提案はほとんどの場合、開発現場にフィー

  • 誤って理解してほしくない日本的「デバッグ」と欧米の「ユーザーテスト」の違い(上) | 新清士の「デジタルと人が夢見る力」 - コミニー[Cominy] / ブログ

    プロフィール 新清士 ジャーナリスト。立命館大学映像学部非常勤講師。1970年生まれ。慶應義塾大学商学部及び環境情報学部卒。著書に、『ゲーム産業の興亡』(アゴラブックス)。 誰もが認めざる得ないほどの日米の開発力の差 なぜ、日ゲームはこの10年で急激に海外勢に押されることになったのか、という議論が、やっと日国内で真剣に議論されるようになりつつある。9月6日〜8日に行われたCEDECでも、その点は重要なトピックになっていた。 明らかにトップクラスのAAA(トリプルエー)のゲーム開発は、技術的にも日ゲーム開発会社は追いつくことが難しくなっていると感じるほどの差が開いている。今年の、世界的な年末商戦の目玉タイトルになるだろう「バトルフィールド3」(エレクトロニックアーツ)や「コール オブ デューティ モダン・ウォーフェア3」(アクティビジョン)といったタイトルは、技術的にもゲームの完成

  • マルチプラットホームライブラリを作ってみた。 PowerSmash4 の場合 (CEDEC2011)

    マルチプラットホームライブラリを作ってみた。 PowerSmash4 の場合 (CEDEC2011) 株式会社セガ R&D2 平山 尚 目次 第 1 章 前置き 3 1.1 PowerSmash4 について最低限の紹介 . . . . . . . . . . . . . . . . . . . . . 3 1.2 複数機種対応ライブラリという道具 . . . . . . . . . . . . . . . . . . . . . . 4 1.3 今回開発したライブラリの概要 . . . . . . . . . . . . . . . . . . . . . . . . 4 第 2 章 開発時の状況 6 2.1 何故今更作っているのか . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 使えた資源 . . . . .

  • 最近もらった本: アジャイルサムライ - steps to phantasien(2011-09-13)

    いただきました. ありがとうございます. そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う. 理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる. 二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリン

  • 構成管理 実践入門 第1章 構成管理入門 サンプルの準備

    ■書籍 Subversion実践入門― 達人プログラマに学ぶバージョン管理(第2版) Mike Mason(著)、でびあんぐる(訳)、オーム社(刊) Subversionの基的な使用法をはじめ、実プロジェクトでのバージョン管理の活用という観点で書かれていておすすめです。 パターンによるソフトウェア構成管理 Stephen P. Berczuk/Brad Appleton(著)、宗雅彦(訳)、翔泳社(刊) あんがい知らないうちにやっていることがパターンとして明記されています。Subversionの機能もこの書籍のパターンを実現しているものが多いです。特集の構成管理に関する図はこの書籍の図を参考にしています。 達人プログラマー― ソフトウェア開発に不可欠な基礎知識 David Thomas、Andrew Hunt、Mike Clark(著)/テクノロジックアート(訳)/長瀬嘉秀(監訳)/ア

  • ソースコードの品質向上のための効果的で効率的なコードレビュー

    ちゃんとした C# プログラムを書けるようになる実践的な方法~ Visual Studio を使った 高品質・低コスト・保守性の高い開発

    ソースコードの品質向上のための効果的で効率的なコードレビュー
  • 素人がWebサービスを作ってみて分かった9つのこと:Rails Hub情報局:エンジニアライフ

    こんにちは、@IT編集部の西村賢です。IT系のオンラインメディアで編集・記者をしております。タイトルに「ど素人」と書くと、ちょっと嘘になるので「素人」と書きましたが、素人がWebアプリを作ってみた体験談と感想を書いてみたいと思います。「オレもプログラミングを勉強して何か作ってみたい!」と考えている人や、「自分でサーバを借りて何かやってみようと思っていたんだよね」という人の参考になれば幸いです。 去年の夏、Webアプリケーション開発フレームワークのRuby on Railsのことを調べていて「面白そうだな」と思い、ドキュメントに従ってサンプルアプリをいくつか作ってみました。作ったり壊したりしている間に、こう思いました。 「あれ? これなら自分が欲しかったサービスが作れちゃうんじゃないの?」 で、「Worklista」(ワークリスタ)という名前のWebサービスを作りました。3カ月ほど前から親し

    素人がWebサービスを作ってみて分かった9つのこと:Rails Hub情報局:エンジニアライフ
  • SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して

    ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは? - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。このは、7月に行わ

    SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
  • はじめてのしゅうだんかいはつ あるいはAndroidの暗黙知のこと - mizchi log

    先月ぐらいからバイトでAndroidのプログラムを書いている。 結構、言葉になってない暗黙知がたくさんあったので、その経験として、メモを残す。プログラミングそのものの話も含む。 三人で分担して開発していた。 分担 自分: Android開発初心者。プログラミングはある程度慣れてる。ロジックとネットワークとバックグラウンド処理 A : Android開発初心者。iPhoneアプリ開発経験ありだが、プログラミングは慣れてない。AndroidUIデザイン担当 B : サーバー・データベース担当。PHP結構出来る。 問題。このバイト先ではAndroid開発経験者がいない。スキル的にも自分より上の人が最初はいなかった。途中で入ってきたスキルがある人がいたが、このプロジェクトには関わっていない。というわけで、自分とAがほぼゼロから開発してきたことになる。 かなり時間がかかっていて、あまり開発効率がよ

    はじめてのしゅうだんかいはつ あるいはAndroidの暗黙知のこと - mizchi log
  • 小規模Webサービス向け安上がりシステム構成と開発フロー(怖話.jp) - Fjord, Inc(株式会社フィヨルド)

    こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp(kowabana.jp)のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト(アプリではありません)です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC(合同会社フィヨルド) 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは1ヶ月経ってないまだまだのサイトです。開発期間は約1ヶ月ぐらいです。 サイト情報 (これAnalyticsを直接貼るのはどうやればいいんだろう?) 直近一ヶ

    小規模Webサービス向け安上がりシステム構成と開発フロー(怖話.jp) - Fjord, Inc(株式会社フィヨルド)
  • 継続開発のススメ - Twisted Mind

    概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、

    継続開発のススメ - Twisted Mind
  • Getting Real by 37signals

    Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →

    Getting Real by 37signals
  • ディレクターやエンジニアが運用エンジニアにインフラの相談をする際に持って来て欲しい5つのこと - blog.nomadscafe.jp

    新しいWebサービスを開始する際や、既存サービスに変更を加える際に、サーバを何台確保するか、ストレージやAPIといった共有リソースを使用して良いか、ディレクターやアプリケーションエンジニアの方に訪ねられることがありますが(というかそれが仕事ですね)、その際相談のためにどんな情報を持って来て欲しいか書いてみます。人間同様にサーバやネットワークリソースも有限なので、無駄にならない最適なサーバ台数を割り出したり、増強が必要かどうかを判断して、会社のビジネスを効率よく進めていくことが重要です。 人によっては以下に書いてあることが、非常に緩く感じでしまうこともあるかもしれません。これはWebサービスを早く立ち上げて、柔軟に運用していくことができる環境ならではだと思います。それでも出して欲しいモノはいくつかあります 企画書 どんなサービスであるか説明できる企画書があるといいでしょう。ないわけはないと信

  • 開発中に求めること - ✘╹◡╹✘

    7月1日にCookpadにインターンとして参加してから1週間が経過した。「インターンに参加する」では齟齬があり、「インターンとして参加する」が最もしっくりくる雰囲気。ここでは時間が過ぎていくのが速すぎて恐ろしい。月と太陽まで高速なサイクルを回さなくてもいいのに。 今まではてなで働いた経験しかなかったけど、今回クックパッドで働いた経験が1週間貯まった。これまでは「はてなだからこうしているのかもしれない」という捉え方しか出来なかったけど、この時点で「ああどこも共通してこうなっているのかも」という視点に立って考えることが出来る状態になった。その視点から考えてみて、幾つかの共通する意見が明確になってきた。 学習コスト Cookpadの開発は、途中からJoinしやすい環境が整っていた。Railsを採用しているところは特に、内製フレームワークに対する理解の為の学習コストが発生することなく、開発に取り掛

    開発中に求めること - ✘╹◡╹✘
  • Webアプリケーションエンジニアはノマドであれ(特定のサーバに依存しない方法) - blog.nomadscafe.jp

    弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元/管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技