タグ

2018年9月27日のブックマーク (7件)

  • さようなら ImageMagick - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。 一般的な Web アプリケーションがそうであるように、サイボウズのグループウェアにも画像をサムネイルで表示する機能があります。サイボウズでは日々数万件やそれ以上のサムネイルを生成しており、それらは全て ImageMagick によって生成されていました。 そこで得た知見はこちらの記事で公開されています。 blog.cybozu.io しかし現在、サイボウズから ImageMagick は消え去りました。その理由と、我々が取った代替手段について紹介します。 ImageMagick を外した理由 言うまでもなく ImageMagick は優秀なツールで、画像変換に関する何らかのサービスやツールを作る場合には採用の第一候補になることでしょう。あらゆる画像フォーマットに対応し、出力画像をきめ細かに制御できる膨大なオプシ

    さようなら ImageMagick - Cybozu Inside Out | サイボウズエンジニアのブログ
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた!ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
  • 障害報告書を書くときに気を付けるポイント - orangeitems’s diary

    はじめに 最近は、システム障害ウォッチャーとしていろんな種類の障害報告書を読んでいます。個人的に様々気が付くことがあるのですが、ある基準をもってコメントを入れています。これをまとめておきたいと思います。 ポイント 以下、ポイントが5つあります。 1. 現象と影響 まずは客観的に、ユーザー目線でどういう不具合が起こったかをわかりやすく記載することが大切です。技術者目線で書き始めるとこの時点で読み手から「意味がわからない」と言われてしまいます。システムを使うのは技術者ではないことが多いので、あくまでも平易な言葉で現象を明確に記載しましょう。また、この時点で経緯は不要です。結論から先に話す、という意図を持って現象を記載します。 また、この現象が発生したことによるユーザー側への影響も、現象の次に記載すべきです。そのシステムが使えなかったこと(現象)により、何がユーザーに不利益が起きたのか(影響)と

    障害報告書を書くときに気を付けるポイント - orangeitems’s diary
  • 失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 - エンジニアHub|Webエンジニアのキャリアを考える!

    失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 人間は失敗するものです。エンジニアもまたしかり。Retty株式会社の樽石CTOが考える、失敗を学びに変える考え方とノウハウを紹介します。 はじめまして。Retty株式会社でCTOを務める樽石将人( @taru0216)です。Rettyにおける技術の責任者として不確実性の高いシステム開発を成功に導くよう牽引したり、メンバーが働きやすくなるような仕組みづくりを行ったりしています。 子供の頃からパソコンに親しみ、新卒一期生でレッドハットに就職して、Rettyに入社するまでGoogle楽天を経てきました。エンジニアとして活動して約30年。日々失敗し続けていますし、過去には大規模サービスを止めてしまったこともあります。 人間である以上、バグやエラーは必ず起こるもの。エンジニアは失敗を繰り返

    失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 - エンジニアHub|Webエンジニアのキャリアを考える!
  • 障害報告書の書き方TIPS(テンプレート) - Reactioブログ | 障害対応の救世主Reactio(リアクティオ)

    みなさん障害報告書はどのように書いていますか? 弊社では社内情報システムやサーバインフラ、サービス基盤システムを運用してきた中で、良くも悪くも数多くの障害に立ち向かい報告書を書いてきました。障害やトラブルの報告は、対象システムの利用者や関係者または組織内の管理者や役員など、デリケートな内容なだけ非常に気を使うものです。 そこで、障害報告書を作成する上での注意点とテンプレートを共有したいと思います。 障害報告書の注意点 障害報告書というのは、対象システムのトラブルや障害によって、ステークホルダーに価値が提供できない状況が発生した内容について説明するためのモノです。 ステークホルダーが、社内宛なのか、社外宛なのか、エンジニアなのか、非エンジニアなのかなど、様々な要因によって内容が異なります。なので、まず初めに最大限の情報量をまとめて、提示先に応じて報告書として精査していきましょう。 尚、システ

    障害報告書の書き方TIPS(テンプレート) - Reactioブログ | 障害対応の救世主Reactio(リアクティオ)
  • Make a README

    What is it?A README is a text file that introduces and explains a project. It contains information that is commonly required to understand what the project is about. Why should I make it?It's an easy way to answer questions that your audience will likely have regarding how to install and use your project and also how to collaborate with you. Who should make it?Anyone who is working on a programmin

    Make a README
  • :: グーグル日本語入力に導入したい辞書データ集 ::

    オリジナルの文章を作成するのはとても労力のいる仕事です。神経をすり減らして頭をフルに回転させなければ、自分の納得いく文章というものはなかなか書けないものです。通常は、いちいち辞書を調べて数多くの言葉の中からしっくりいく言葉を見つけ、文章の中に組み込んでいきます。また、どこかでちょっとでもニュアンスが違ってきたりすると、また最初から考えなおさなければいけません。 このページでは文章作成をより簡単に、かつ効率的にできるよう、google辞書・グーグル日本語入力に辞書データを導入することをおすすめしています。 表現力のある方はこういった辞書的なツールは必要のないことかもしれませんが、通常であれば限られた自分の記憶の中から言葉を選んで文章にしたりしています。特に、ブログやホームページなどを作成している人、また、仕事で文章をよく書く人にとっては、文章を書く「時間と労力」の壁に一度や二度ぶつかっていら