2018年8月3日のブックマーク (7件)

  • クラシル、不屈のキャッシュ戦略 - Kurashiru Tech Blog

    こんにちは! プロダクトマネージャーをしている奥原 (@okutaku0507) です。前までサーバーサイドのリードエンジニアをしていました。 delyの開発ブログが長らく更新されておらず、不甲斐ないです。これからは活発にdelyが取り入れている最新技術や実際にあった事例、取り入れているアーキテクチャなどを中心に発信していきたいと思っています。 久しぶりの今回は、delyが運営/開発しているレシピ動画サービスであるkurashiruの涙あり、笑いありのキャッシュ戦略について歴史と実際の事例を元に書いていきたいと考えています。最後には、僕が作成したクラシルに用いられているキャッシュ戦略をgemにしたライブラリを紹介いたします。 はじめに サーバーサイドチームはクラシルの開発から1年半程度まで、主に僕一人しかいませんでした。TVCMによる急激なユーザー数増加や新機能開発、社員100人を支える管

    クラシル、不屈のキャッシュ戦略 - Kurashiru Tech Blog
    issyurn
    issyurn 2018/08/03
  • eスポーツに新機軸? 「サイバー剣術」を開発した孤高の武術家:DANRO

    朝日新聞社が展開する様々なデジタルメディアを網羅した総合広告ガイド。媒体資料はこちらからダウンロードいただけます。各メディアのメディアガイド/広告ガイド/広告事例もご紹介します。

    eスポーツに新機軸? 「サイバー剣術」を開発した孤高の武術家:DANRO
    issyurn
    issyurn 2018/08/03
  • 第4回:レプリケーションの比較 (1/4) | Think IT(シンクイット)

    Linuxカーネルにローカル権限昇格脆弱性「Dirty Frag」 ─ PoC公開、各ディストリビューションが対応進める 5月9日 22:51

    issyurn
    issyurn 2018/08/03
  • Redmineをしっかり活用してチーム運用改善したら、チーム力がグンと上がった話 | Wedding Park CREATORS Blog

    こんにちは、SREチーム エンジニアの西脇(@yasuhiro1711)です。今日は、チーム運用改善の話をしたいと思います。これからチーム運用をしていく方々に少しでも響けばいいな、参考事例になればいいな、と思って書いておきます。ちなみに、テーマを変えて続編も書く予定ですので楽しみにしてもらえればと思います。 チームに課題が出て来た 私のSREチームはこれまでは2人と少数精鋭でした。そこに昨年全く違う背景を持つメンバーが入って来ました。(ちなみにSREチームに改名した件も近々どこかで書こうと思います。)最初は仕事のやり方を変えずにやっていたものの、仕事が増えて連携する場面が増えると、2人のときの阿吽の呼吸だけではどうしても回らなくなることが増えてきました。他にも思考のすれ違いなど幾つか課題が出始めました。項目にするとこんな感じです。 少数メンバーのため、人に依存したタスクが多かった。 チーム

    Redmineをしっかり活用してチーム運用改善したら、チーム力がグンと上がった話 | Wedding Park CREATORS Blog
    issyurn
    issyurn 2018/08/03
  • ベロシティに対する誤解 | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 【警告】スクラムチームにおいて「もっと正確に見積りたい」とか、スクラムチーム外から「正確な見積りが欲しい」と言われるような場合、見積り以外のところに問題があります。 チームの現状や、ステークホルダーのアジャイルスクラムに対する理解や期待をいまいちど検査することを強くお勧めします。 ストーリーポイントとは?まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』(Mike Cohn 著、安井力、

    ベロシティに対する誤解 | Ryuzee.com
    issyurn
    issyurn 2018/08/03
  • 開発残酷物語 - @IT

    「開発残酷物語」は、システム開発会社比較検索サービス「発注ナビ」ユーザーのシステム開発会社の方々に、自慢(?)の失敗事例を披露いただき、契約で押さえるべきポイントやプロジェクト運営の勘所、トラブル防止法などのノウハウを共有し、読者諸氏がこれから経験するトラブルを未然に防ぐことを目的としている。聞き手は、豊富なデスマーチ経験を持つ山一郎氏。

    開発残酷物語 - @IT
    issyurn
    issyurn 2018/08/03
  • 単一障害点 - Wikipedia

    単一障害点の1例。コンピュータ間の通信ネットワークでは、ルーター等が冗長化されていなければ単一障害点となりうる。 単一障害点(たんいつしょうがいてん。英: single point of failure、SPOF)とは、その単一箇所が働かないと、システム全体が障害となるような箇所を指す。情報システム工学や通信、サプライチェーン・マネジメントなどの分野で使われる概念である。単一故障点と訳されることもある。 高い可用性が必要なシステムでは、そのシステムを構成する各構成要素の1箇所の障害で全体が停止しないように、各構成要素を冗長化(2重化、3重化など)するが、その際に単一障害点が残らないように設計すべきである。 一般的なコンピュータシステムの例では以下が挙げられる。 ハードディスクをRAIDで冗長化しても、そのRAIDアダプターが1枚ではRAIDアダプター障害時には全体が障害となる RAIDコン

    単一障害点 - Wikipedia
    issyurn
    issyurn 2018/08/03