タグ

developmentに関するkokepiのブックマーク (37)

  • keepalived講習会 | feedforce Engineers' blog

    ゴール VRRPによる仮想IP持ち回りの仕組みを理解する keepalivedを利用したHAクラスタが構築できる LVS周りはナシで。 基礎知識編 基的な資料 keepalived 家 こんなに簡単! Linuxでロードバランサ (2) - DSAS開発者の部屋 あとは昔まとめた社外秘の資料 keepalivedって何スか LinuxにおけるVRRPの実装のひとつ。HAクラスタを実現するデーモン。 HAクラスタのマスタ機とバックアップ機の両方で動作させることで簡単にHAクラスタができる。 またLVSを利用した負荷分散クラスタの稼動をサポートする機能もある。 VRRP 仮想IPを複数機器で共有し、一番プライオリティの高い機器がそのIPを持つ仕組み。 来はルータ冗長化のためのプロトコルだが、サーバの冗長化にも使用できる。 つまりHAクラスタが作成可能。 参考 : Virtual Rout

    keepalived講習会 | feedforce Engineers' blog
  • masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針

    初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ

    masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、

  • 小野和俊のブログ:そして、ペア・プログラミングが始まる

    ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 1セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

    小野和俊のブログ:そして、ペア・プログラミングが始まる
  • http://blogs.sun.com/tkudo/entry/google_and_internal_control

  • ある事業立ち上げの風景2:経営計画と開発計画のギャップ調整:渡辺聡・情報化社会の航海図 - CNET Japan

    ある事業立ち上げの風景2:経営計画と開発計画のギャップ調整 公開日時: 2006/11/08 22:05 著者: 渡辺聡 前回の続きとして、シードからアーリーにかけての立ち上げ時点でも拡大期でも、更には上場してからも何度と無く問題化する事業計画と開発プロセスでとの速度とサイクル調整の件を。 各所で問題化しているのを実際見ていることもあり、NILSの担当パネルでもディスカッションテーマとして採り上げられないか調整している。一部SaaSやサービス化などに時間を割くかもしれないが、パネルの皆様から良いお話を頂けるというのが確認取れれば、限られた時間内ではあるものの整理を試みてみたい。次のトレンドは何か!というのも大事であるが、足腰を固めるのも同じくらい大事なために。 問題が置きつつある現場での症状としては概ね以下のような形で出てくる。 1)経営陣からみるといつまで経ってもモノが仕

  • 要求2.0開発 (arclamp.jp アークランプ)

    要求開発アライアンスの10月定例にて「要求2.0開発」というテーマで話をしてきました。題名は理事の細川さんから依頼をいただいたときにノリでつけた名前です。かなり勢いに任せた内容はなっていますが、まぁまぁ(w。 要求開発2.0ではなくて、要求2.0の開発。これからの時代は要求その物が2.0化してきます。手法うんぬんではないのです。言い換えれば「ビジネスのシステム化2.0」ではなくて「ビジネス2.0のシステム化」をテーマにしていかないといけないと考えまています。 資料はアライアンスのページにあがると思いますがサマリを書いておきたいと思います。 今、何が起きているのか 次のスクリーンショットを見てください。なんだと思いますか? 実はこれ、日全国1万ヶ所のホテルに●を置き、最低価格が高いほど赤くしたものなのです。長野から伊豆とか、京都奈良ならあたりが赤くて、東京、大阪は件数が多いものの価格が高

  • Apache Rewriteモジュール - 転送量分散型 Webクラスタ・サーバーシステムの構築

    3.Rewriteモジュール 前ページのような形で画像等をミラーするサーバーを複数用意出来たら、あとはクライアントから動画や画像ファイルに対してリクエストがあったときに、それを適切な方法でいずれかのミラーに振り分ければ良いことになる。PerlなどCGIを用いて何らかの条件で毎回振り分け先を決める方法もあるが、リクエストがある度にCGIを呼び出していたのでは、少なからぬオーバーヘッドが生じて効率が悪く、アクセス数が多いと転送量よりも、サーバー負荷が問題となってしまう恐れがある。 そこでApacheの便利なモジュール、Rewriteモジュール(mod_rewrite)の登場である。これはクラインアントからリクエストされたURLのパス部分を内部的に書き換えたり、条件に応じて他へリダイレクトしたりすることを、柔軟におこなうことが出来る非常に強力で便利なモジュールであり、使用のオーバーヘッドも少ない

  • 負荷対策概論 - Y-110's Wiki

    最新文章 2018-12-26 17:10▪ 致敬英雄,致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发!上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞:"吃出卫生巾"系人为当事顾客

  • わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊

    この記事のまとめ。また長文エントリごめん。“ITコンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP&提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容 

    わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
  • 登録日を指定したメモ一覧取得API

  • http://d.hatena.ne.jp/akahigeg/20060627

  • ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ネットワーク編)

    尾藤正人です。 前回のエントリ ベンチャー流サーバ構築のススメ(ハードウェア編) では多くのコメント、トラックバック、ブックマークをしていただきました。ありがとうございます。僕自身多くのことで勉強になりましたし、新たな発見もありました。 技術は公開、共有して発展するものだと思っていますので、自分の無知をさらけ出すのを恐れずにいろいろ公開して、自分自身も成長していければと思っています。 今回はサーバ構築するときのトピックとして、どのようにネットワークを構築したかを書いてみます。 サーバ構築に限ったことではありませんが、重要なのは質を下げずにコストを下げることです。ネットワーク部分でお金がかかるのは回線ぐらいですから、ネットワーク周りで重要なのは人的コストを下げること、つまり管理コストを下げることです。 ・回線は2回線以上用意する 2回線以上用意するのは高可用性を確保するためです。通常は全ての

  • 複雑さに金が落ちる時代は本当に終わるのか? - アンカテ

    RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース

    複雑さに金が落ちる時代は本当に終わるのか? - アンカテ
  • 検索:関連検索ワードAPI - Yahoo!デベロッパーネットワーク

    指定されたURLは存在しません。 URLが正しく入力されていないか、このページが削除された可能性があります。

    検索:関連検索ワードAPI - Yahoo!デベロッパーネットワーク
  • Flickr開発者が語るネットサービスの高速化方法

    Web2.0としてくくられるタイプの各種ネットサービス、いわゆるウェブアプリは以前とは比較にならないほど動的生成されるものが多く、結果としてものすごい負荷をシステムにかけるわけです。 というわけで、海外におけるデジカメ画像共有サービスの代表的なものである「Flickr」の開発者がJavaScriptを高速化する手法について解説しています。 Vitamin Features >> Serving JavaScript Fast 手順を分割して簡単にしてみたり、キャッシュを使ったり、転送量を圧縮して帯域を節約したりいろいろあるようです。なお、GIGAZINEはキャッシュシステムを採用して有効活用することで負荷を現在、当初の12分の1に抑えています。 また、こっちはリバースプロキシによる高速化手法。 ViSolve.com - Squid Support Service Apacheのモジュール

    Flickr開発者が語るネットサービスの高速化方法
  • 読みたくなるような仕様書を書けと - F.Ko-Jiの「一秒後は未来」

    ジョエル・オン・ソフトウェアはジョエルさんの個人的意見で書かれているらしいけど、内容が豊富でかなりタメになることが多いです。多分全部読んでからブログに感想書いてては最初のほうに読んだ内容をきっと忘れてしまうと思うので、まだ前半25%くらいしか読んでませんがちょっとメモしておこうと思います。「バグは最初のうちに潰しておけ」というのと同じですね。 このの最初のほうで重点的に語られているのが「仕様書を書け」ということなのですが、ただフォーマットに沿ったつまらない仕様書を書くのは無駄であると述べています。まさにごもっともな話。大学時代の最初のほうでプログラミングの演習があって、課題のプログラムを作るときに「一緒に仕様書を書け」というのがあったのを思い出しました。このプログラムはどんなもので、使われている関数はどんなで引数と返り値はどんなで・・・といった内容を書くものでした。当時「こんなのわざわざ

    読みたくなるような仕様書を書けと - F.Ko-Jiの「一秒後は未来」
  • The Agile Modeling (AM) Method: Effective Strategies for Modeling and Documentation

    The Agile Modeling (AM) Method Effective Strategies for Modeling and Documentation The Agile Modeling Mission To share proven and effective strategies for modeling/mapping and documentation. What is Agile Modeling? Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation. Some important concepts: Model. A model is an abstraction that expresses important aspects

  • つまらないものですがヨコナビです - livedoor ReaderのAPI一覧

    livedoor Readerのソースをもの凄くざっくり読んで、もの凄くざっくりとAPI一覧を作ってみた。長いので初めての続きを読む記法。 オートディスカバリーAPI /api/feed/discover param: url オートディスカバリーするURLを渡す method: get/post 与えられたURLからオートディスカバリーする Feed登録API /api/feed/subscribe param: feedlink FeedのURLを渡す method: post Feedを登録する Feed削除API /api/feed/unsubscribe param: subscribe_id subscribe_idを渡す method: post Feedを削除する Feed一覧取得API /api/subs param: unread 0:全部 1:未読のみ method:

    つまらないものですがヨコナビです - livedoor ReaderのAPI一覧
  • ひげろぐ@はてな グーグル技術講演会まとめ