タグ

開発に関するhiro360のブックマーク (242)

  • 【コラム】シリコンバレー101 (185) 思いつきだけでも発明長者に - クラウドソーシングによるソフト開発 | ネット | マイコミジャーナル

    マウンテンビューにあるコンピュータ歴史博物館で7月12日と13日に「Mashup Camp 2」が開催された。マッシュアップの仕掛人がアイディアを持ち寄り、オープンな議論を通じてアイディアに磨きをかける。企業側からの注目度も高く、Adobe、AOL、Google、Intel、Microsoft、Sunなどがスポンサーに名を連ねている。1回目からの変更点としては「Mashup University」というトレーニングセッションの追加だ。講師はスポンサー企業(APIの提供者という立場から……)や著名な開発者である。Mashup全体で見れば、開発者のアイディア交換会の場であるCampに、Universityが追加されたことで、ビジネス側からのアプローチとのバランスが図られた形になる。言い換えれば、アイディアだけではなく、いかにビジネスとして成立させるかがMashupの議論のポイントになっている

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • Rails的世界の「安心」と「信頼」の力学 - アンカテ

    hotsumaのURLメモ。 - 信頼対不信。 に対する、sociologicさんのコメント。 「劣化」っても昔と比べないと判断できない気も。むしろ「安心社会から信頼社会へ―日型システムの行方」じゃないですが、もともとそういう国民性なのでは。 これは、日人の国民性という点では、全くその通りだと思う。 「安心」ベースの社会(知っている人への信頼をベースに構築された社会)と「信頼」ベースの社会(知らない人への信頼をベースに構築された社会)には、それぞれ得失があるけど、その力学がオープンソースの世界では全く違い、Rails的世界では、さらに大きく違って来る。 naoyaさんが、こういう感覚は何も Rails が始まりではないと思うけどなと言うのはよくわかる。よくわかると言うか、Railsを実際に使う前には同じように考えていた。「Railsという現象の質について、私はすでにわかっている。ちょ

    Rails的世界の「安心」と「信頼」の力学 - アンカテ
  • RailsとYouTubeは「自転車創業」だ - アンカテ

    Ruby on Rails(以下Rails)は、Linux、Apache、Firefox等に続く、最も成功したオープンソースソフトウエアになりそうである。そして、それは同時に、これまでのオープンソースに無い、全く新しい質を持つ新しい現象の芽生えでもある。オープンソースという現象が、WikipediaやDiggの成功を通して、プログラマのコミュニティの外にインパクトを与えているように、Railsの中に芽生えつつある新しい「質」も集団知や新しい社会システムのデザインについて、ひとつの大きな参照点を構築するだろう。 その新しい「質」とはひとことで言って「スピード感」である。 成功したオープンソースソフトウエアは、全て、モジュールあるいはプラグインシステムを持っている。つまり、多様なニーズとシーズを持つ多数のプログラマがエコシステムを築くことが可能になっていて、それが特定の有力なニッチに最適化する

    RailsとYouTubeは「自転車創業」だ - アンカテ
  • 階層化するサービス (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOA自体、特に難しい概念ではありません。しかし、どうしてもややこしくなるのがサービスという概念です。栗原さんの書かれた「当は単純な「SOA」という考え方」では、 実際には、SOAの考え方は極めて単純である。ソフトウェアを「サービス」という部品の集まりとして構築しようというだけのことなのだ。 サービスとは「複数のアプリケーションをまたがって共用され得るソフトウェア部品である」と言える。 サービスはビジネスプロセスの一部(サブプロセス)を表現していることが多い。 このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス(を実装するソフトウェア)を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システ

  • Efficient data transfer through zero copy

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Efficient data transfer through zero copy
  • http://www.seshop.com/event/dev/2006/data/download/10-D/10-D-7_HI.pdf

  • - eXtreme Programmingの魅力を探る

    (株) 永和システムマネジメント 平鍋 健児   Kenji HIRANABE 作成日:第4版 2001,8/10 第3版 2001,1/16 第2版 2000,10/21 初版 2000,10/10 エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)である. 正式にはエクストリームプログラミング(eXtreme Programming), 略してエックスピー(XP)と呼ばれる.この記事でも,以下 XP と呼ぶことにする. Kent Beck は,'99年に "Extream Programming Explained - Embrace Change" という書籍を著した.これは "EC " とも呼ばれ,XP のバイブルともなる. この記事では,この "E

  • Movable Type ブログ検索や tag 検索の結果を素敵な URL で - 2xup.org

    2006-07-07T14:05:53+09:00 もうちょっと UI が解りやすくなるともっと良いのだけれど Flickr にアクセスしていつも良いなあと思うのは、直感的な URL だと思います。例えば /photos/kaminogoya/ にアクセスすれば僕の写真がみれます (最近のアカウントは不思議な文字列になっていますけれど…。設定できるのかな?)。そのあとに sets/ とつければいくつか用意された Photo Set の一覧ページに移動します。また、/こんな風にわかりやすいと、一度アクセスしたあとであればなんとなく解るようになってきますよね。こういった URL もデザインのひとつだと思います。 おなじように解りやすく気付いてからとても重宝しているのが microformats 関係でもおなじみ Technorati のウェブサイトです (.com の方)。Technorati

  • OOエンジニアの輪! 〜 第 34 回 比嘉 康雄 さんの巻 〜

    特になし。 私は人を丸ごと尊敬することはありません。それぞれ好きなところもあれば、嫌いなところもある。できるだけいろんな人の素敵な点を見つけて、その素敵な点を 認識したいです。 現在のお仕事について -- まず最初に、現在の業務についてお話していただけますか? 弊社でこの 4 月より「Seasar2 技術推進グループ」が新しくできました。そこで主に、弊社の中での Seasar2 を使ったプロジェクトへの支援や、商用サポートなどをやっています。 あるいは、ちょっと会社の仕事には関係ないんですけど、Seasar プロダクトの強化もやっています。 -- 基的には技術的なリーダーをされているのでしょうか?それともマネジメントが中心ですか? 時と場合によりけりで、会社ではマネジメントとして判断することがほとんどです。 Seasar ファウンデーションではチーフコミッターとしての役割がありますので、

  • - 講演・セッション内容

    ソフトウェアは柔らかいのに固い、だけどやっぱり柔軟だ エンジニアは一見暗いけど実は明るい、というより自由だ パターンは便利だけどワンパターン、というか原則があればより自由だ 日の現在は2極化しているけど未来に品格はある?ようわからんから見える化! というようなことを皆さんとダイアローグしてみたいと思います。守・破・離ってなんだ?わからん。シュハリ?しばり?!シュワッチ! お題を頂いて以上のような妄言がうずまく脳内宇宙であります。できればMVCプラス新たなパターンダンスもお披露目します。 合掌、臥床、合唱。 以上、異常、委譲。 ■プロフィール 株式会社豆蔵取締役会長。技術士(情報工学部門)。 オブジェクト指向やソフトウェア工学の実践適用に関するコンサルティング、セミナー講師に従事し、後進の育成にあたる。 現在、アジャイルプロセス協議会会長、IPA/SEC設計技術部会委員、情報処理学会ソフト

  • 第4回 デザイナーがプログラミングについて誤解していること

    「無知の知」では済まされないこと 顧客あるいはプロジェクト・リーダーからの相談内容が,筆者の相方(プログラマ)の耳に届くことがある。筆者は,技術無視の相談にも気長に耳を傾けられるが,相方は,そのような質問が生じること自体が,不思議でならないといった様子だ。 たしかに,拡張子の存在を知らなかったリ,存在を知っていてもWindowsマシンでの表示方法を知らなかったり,さらにJavaJavaScriptを混同していたり…というのは困る。また,顧客の希望がローカル・アプリケーションなのかWebアプリケーションなのかを確認しないまま相談を持ちかけられても答えようがない。 筆者は,.NETをプラットフォームとする開発が多いが,その場合ならせめて下記の表のアプリケーションの種類については,確認しておいたほうがよい。 だが,デザイナーが知らなくてもやむをえない情報は,山ほどある。 筆者の経験からいえば,

    第4回 デザイナーがプログラミングについて誤解していること
  • プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント

    ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16%。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16%だったという。 日においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」(社団法人 日情報システム・ユーザー協会)に調査によれば、システムの仕上がりに満足と回答したユーザーは10%前後に

    プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント
  • 要求仕様戦争(その3)

    ■仕様書をどうこうする――「要求」の見える化 「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。 著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1~n を実装すれば要求Aが実現する、という仕掛けだ。 ┌───┐ │要求A │ └┬──┘ ├─仕様1(スペック1-1,1-2,1-3...) ├─仕様2(スペック2-1,2-2,2-3...) ├─ … └─仕様n(スペックn-1,n-2,n-3...) まぁ、こんなにキレイにならないだろうが、「このスペック(群)で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う(実際に目配りするかどうかは別として)。

    要求仕様戦争(その3)
  • 要求仕様戦争(その2)

    ■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか(書いた人も)分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる

    要求仕様戦争(その2)
  • 要求仕様戦争(その1)

    ■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100%はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ(しかも部分的だ)。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体

    要求仕様戦争(その1)
  • JavaScript統合開発環境 JSide 1.0 登場 | エンタープライズ | マイコミジャーナル

    The JSide teamは26日(米国時間)、JSideの最新版であるJSide 1.0を公開した。JSide (JavaScript Integrated Development Environment)はJavaで開発されたJavaScript統合開発環境。主な特徴は次のとおり。 シンタックス色付け ブレース対応明示 JavaScript関数アウトライン 文法チェック アンドゥ/リドゥ ソースコードの印刷機能 JSide 1.0はGNU LESSER GENERAL PUBLIC LICENSE Version 2.1のもとで公開されているオープンソースソフトウェア。統合開発環境に要求される必要最低限の機能が実現された段階。動作の安定性向上やこなれた操作が実現されるのは、まだ先のリリースになるだろう。 JSide 1.0動作例 同チームは既存の機能の改善と新しい機能の実装に継続的に

  • GREE Engineering

    404 お探しのページは見つかりません GREE Engineering トップへ戻る

    GREE Engineering
  • プログラマの心の健康

    目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードをべながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。

  • 最上の日々 - 数学を表現するのに最適な媒体はコンピュータである

    数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 (これだけ書くのも大変だろうなあ。いつもお世話になってます。) 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな: 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると