Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
「第3のIT」へと変革する時代に考えておきたい「品質」との付き合い方
「第3のIT」へと変革する時代に考えておきたい「品質」との付き合い方：「ソフトウエア品質向上の"変" 2015 江戸～今、変革の時～」リポート 2015年2月4日に行われた＠IT主催セミナーより、JJUG会長鈴木氏による基調講演の模様や、弥生とYahoo!ショッピングの品質向上事例、各品質向上ツールの概要をお届けする。 2015年2月4日、＠IT主催セミナー「ソフトウエア品質向上の"変" 2015 江戸～今、変革の時～」が開催された。開発のスピードと品質を底上げするには、開発からテスト、リリースまで、プロセスごとではなく全体としての効率を向上させることが重要となる。本セミナーで登壇したエキスパートたちの講演から、同課題に取り組むためのヒントを探る。 基調講演～アプリ開発からサービス開発へ移行するには？ 基調講演『提供すべきは「成果物」ではなく「サービス」今あらためて疑うべき、「スピードと品
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
Androidアプリ開発で素早くフィードバックをえるためのライブラリを作りました - クックパッド開発者ブログ
モバイルファースト室の山下(@tomorrowkey)です。 Androidアプリを開発していて、ふとした時に不具合を見つけたりしませんか。 クラッシュであればDeploygateやCrashlyticsなどでクラッシュレポートを送ることができますが、表示崩れを報告をするにはスクリーンキャプチャを撮ってメールアプリを開き、画像を添付して、送信する、といった手順が必要でなかなか面倒です 。 アプリを開発する側は不具合のあったスクリーンショットがほしい、不具合を報告する人は報告する手順がめんどうといったギャップを解決するためのライブラリを作りましたので、紹介します。 不具合報告する機能を作りました 冒頭のアニメーションgifで一通りの挙動を見ることができます。 このライブラリを使っているアプリを開くと通知領域に「不具合を報告する」という項目が増えます。 不具合を見つけた時にこの通知を選択すると
memcachedの活用と運用 実践編 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第25回 MongoDB最前線！ 効果的なシャーディングとバックアップ | gihyo.jp
「MongoDB」は、スキーマレスであることやスケールアウトが容易なこと、さらにレプリケーションのしくみが用意されているといった特徴から急速に人気を集めている、オープンソースのドキュメント指向データベースです。第21回で、MongoDBの基本的なしくみや開発時における注意点などをサイバーエージェントの技術者に解説していただきました。今回は後編ということで、運用時におけるポイントについて伺っていきます。 Ameba PicoやピグライフでMongoDBを実運用 サイバーエージェントにおいて、MongoDBはすでにいくつかのプロジェクトで活用されていますが、その1つにアメリカ向けのアメーバピグであるAmeba Picoが挙げられます。松下雅和氏は2011年1月に入社し、このAmeba Picoの運用にアサインされたことでMongoDBを使うことになったと話します。 「前職ではMongoDBを使
Pinterestをスケールさせる中で学んだこと - ワザノバ | wazanova
https://www.youtube.com/watch?v=jQNCuD_hxdQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 PinterestのMarty Weinerによる goto; conference 2014の講演。 「webサイトどうやってつくるの？」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。 現在のPinterestのシステムアーキテクチャの全貌。 個別のテクノロジーの選択理由。 などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード（初日の10:20のコマです。）できるので、そちらを見ていただいてもわかりやすいかと。 「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。
米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10％にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
チーム開発実践入門──共同作業を円滑に行うツール・メソッド
この書籍に関連する記事があります！ はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが，チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章 チーム開発とは 1.1 1人だけでも開発はできる 1.2 チーム開発で直面する課題 1.3 どのように課題に立ち向かうか 1.4 本書の構成 第2章：ケーススタディ 第3～5章：基礎的なプラクティス 第6～7章：継続的デリバリーとリグレッションテスト 1.5 本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章 チーム開発で起きる問題 2.1 ケーススタディの前提 プロジェクトの前提条件 2.2 ケーススタディ（1日目） 問題1：重要なメールが多
「メンテナンス大変なのでサービス閉じたいです」 - tototoshi の日記
Web サービスの会社にはイケイケなサービスの陰に隠れて、かつてイケイケだったけど今はイケテナイサービス、とか、ぶっちゃけ最初っからあんまりやる気なかった☆サービス、これどこで拾ってきちゃったのサービス、などなど、惰性で続いちゃってるようなサービスがごろごろあったりします。 そういうイケテナイサービス群はメンテナンスの手間を取らせる物なので、エンジニアとしては閉じてしまいたい。でも非エンジニアとしては閉じたくない。いや、本当は閉じたい！でもちょっとは儲かってるし、閉じるとわずかながら存在するユーザーからクレームくるし、連携先の企業とやりとりするのめんどいし、まあいろいろめんどうそう。 そこで、「イケテナイサービスにはできる限りメンテナンスの手間を払うな」という話がエンジニアのとこにきて「お前なーっ！そのメンテナンスの手間がなーっ！」となり、話がループを始めます。なぜこういう噛み合わない話に
『約10年、最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう！』というイベントで発表してきました - よかろうもん！
6月末頃、Rails/Rubyのバージョンアップ作業を開始したときに、Railsアプリケーションを長い間運用しているサービスってなかなか聞かないよな〜と思って、Facebookで下記のような投稿をしてみました。 すると、「AWSを活用してる現場リーダーやCIOをお招きしたトークイベント」でパネルディスカッションをさせていただきました のイベントでお世話になった小山田さんがすぐさまトークイベントを持ちかけてくださり、今回、 約10年最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう！ - Web系な人のキャリアカフェ | Doorkeeper というイベントでお話させて頂くこととなりました。 当日は、社内SNS『SKIP』のサービス開発／運用でやっている取り組みを例に、Rails,RubyなどのバージョンアップからOSのアップデートを実施する際の取り組みについてご紹介させ
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜
#ssmjp ～腹を割って話そうスペシャル～ でのパネルディスカッション発表資料です。 http://ssmjp.connpass.com/event/8615/ ゆるりとした会場の雰囲気にあわせた資料となっております。ご理解いただければ幸いです:-) 2014-12-03: 当日発表では使わなかった「なぜ、セキュリティインシデントは発生するか」を追記したものを再アップしました。
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
VOYAGE GROUP エンジニアブログ : 運用しやすい管理画面とは
2014年04月21日19:45 カテゴリ 運用しやすい管理画面とは こんにちは！ (株)Zucks で Zucks Ad Network というアドネットワークシステムを開発・運用している @brtriver です。 先週末に Symfonyユーザー会 主催 の Symfony 勉強会 #9 が フォトクリエイトさんのご協力のもと開催され、"管理画面Webアプリケーションのアクセスコントロール" というお題で話をしてきました。スライドは既に公開していますが、内容について補足しつつ "運用しやすい管理画面" について書いてみたいと思います。 管理画面のアクセスコントロール from Masao Maeda 運用しやすい管理画面とは 今回いいたかったことをまとめると以下の2点になります。 URLに必要な情報が含まれていること アクセスコントロール (ACL) がシンプルなことPermane
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE): John Allspaw (編集), Jesse Robbins (編集), 角征典 (翻訳): 本
すこやかRails
TechCrunch | Startup and Technology News
