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

jqはとても便利なコマンドです。 JSONを返すAPIを実装するときや、SaaSのAPIから特定の情報を抜き出してシェル変数に代入するときなど、web開発や運用には欠かせないツールとなっています。 しかし、私にとってjqのクエリを一発で書くのは容易ではなく、思い通りの出力が得られないことがよくありました。 難しいエラーメッセージに悩まされて、jqで書くのを諦めて別の言語で書き直すこともありました。 jqの十八番と思える場面で使いこなせないのは、なかなか悔しいものがあります。 ツールを使うのが難しいなら、同じものを作ってしまえばよいのです。 jqの全ての機能を実装する jqを言語としてきちんと書けるようになる jqを完全に理解する jqの全ての機能を自分で実装してしまえば、jqがどういうものか、クエリがどのように処理されるのか、詳しくなれるはずです。 jqを得意な言語と言えるようになって、ク

ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ

これは僕が育てるべき何人かの「経営者の卵」たちに充てたエントリーだ。 直接メールするよりも、公開エントリーにしたほうが、ブクマのコメントなどで多面的に物事を見られて良いと思う。 さて、僕はいくつかの会社の経営者を育てるという仕事もしている。 そんなことをするなんておこがましい気もするが、なんとかかんとか、自分自身でも10年くらいは会社を経営して来た。 そのなかで心がけていることは、仕事をしないようにしよう、ということだ。 経営者の最大の目標は引退である。 労働者から出発し、経営者となり、最後は引退して資本家になる。 引退する、とは、後継者を育てるということだ。 自分自身がそこにいなくても自分が居るのと同じかそれ以上の効率で仕事がまわるのが理想であり、そういう仕組みを作ったらその仕事から引退する。 もちろん経営者になるような人間はただ引退して余生を暮らすようなことはしない。 また別の仕事を見

はじめに 今回は、JIRA課題のサマリー（要約）を外部エディタ上で編集してJIRAに書き戻す機能を、JIRAのREST APIとElectron上に構築したテキストエディタを連携させ、実現していきます。 通常、JIRAのテキストフィールドで一括置換を行いたい場合、CSV Export/Importを使って外部ツール経由で行うなど一手間が必要です。そこで、テキストエディタとREST APIを用いて直接連携すると、便利なテキスト編集機能を使いながら手軽に要約の一括置換ができるようになります。 実装はJavaScriptとjQueryを組み合わせて行います。 サマリーエディタのイメージ 必要な環境 Electron稼働環境（本記事ではv1.6.2を利用しました） macOS 10.9以降, Windows 7以降 JIRA6.4以降（サーバ版のみ） サマリーエディタを動作させてみる はじめに、必

以下に移行しました。 kenzo0107.github.io

こんにちは。xyz_iです。 弊社ではチャットツールとしてSlackを使用しています。 メンバー同士のやりとりはもちろん、いろいろなイベントの通知先としてもとても重宝しています。 例えば、WebAPIを使い、Capistranoによるデプロイの実行時にSlack通知する方法のように使ったりもしています。 この記事は、Slack WebAPIでメッセージを投稿するとき、Message Attachmentsを使うといいことがありますよというお話です。 WebAPIにおけるメッセージ Slackにメッセージを投稿する際、メッセージのフォーマットとして以下のような選択肢があります。 プレーンテキスト Markdownテキスト Message Attachments おそらく人間がSlackを使う場合は、1または2の書き方をすると思いますが、 githubなどの通知BOT（下の画像参照）を見てみる

この記事は Slack Advent Calendar 2016 - Qiita の3日目の記事です。 昨日は Kinoppyd さんの「今そこにあるSlack」でした。 さて、今回、この記事では golang で Slack bot を実装する方法を紹介しようと思います。 世に蔓延る Slack bot これから bot を世に放とうとしている人は、是非、１日目と２日目の記事を読み、事前知識を頭に叩き込んでおくと良いと思います。 Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話 - Qiita 今そこにあるSlack 基本的に、自身で作成した bot はもちろん好きになると思いますが、人によっては理解不能な bot や、意味不明な場面で反応したりと、「邪魔だな」と思われてしまうことがあります。そのため、bot を開発する人は「謙虚・尊敬・信頼」（T

仕事好きのみなさん！　デスクでの長時間作業に体の疲れや倦怠感などを感じていませんか？ そんなあなたに必須になるかもしれないチェアを教えてくれるショップがあるんです。それは、高機能なオフィスチェアをメインに扱うWORKAHOLIC（ワーカホリック）。ワークチェアに精通したチェアコンシェルジュが常駐し、その人の体にフィットした最適な一脚を教えてくれます。まさに“あなただけのイス”が手に入るのです。そんなワークチェアのプロ、チェアコンシェルジュの教えを受けに行ってきました。 場所は、東京メトロ銀座線「虎ノ門」駅から数分、交差点角にあるカフェインチャージバー「CAFFEINEHOLIC」の2～4Fです。入り口は外側にありますが、バーを通り抜けても行くこともできます。 入口は外堀通りに面しています 鉄骨がむき出しにされた無機質な空間にチェアが見える 階段を上がりドアをのぞくと、カウンターの中の男性が

テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

日本で買えるHomeKit対応製品まとめと簡単な解説 個人的なメモも兼ねてるので、日本で対応製品が発売するたび逐次更新していく予定です。 最終更新日:2019/11/12 Homekitとは Appleが提唱する家電の管理システムです。 iOS機器(iPhoneやiPad)をハブとして、部屋中の家電を管理することができます。 特長としてHomekit対応製品はSiriから操作することができ、Siriの音声認識を利用して家電を管理することができるようになります。 また、各種スイッチをまとめて操作したり、センサ、時間、位置情報をトリガーとして家電を操作することもできます。 ただし、Homekitは基本的には家のネットワークやBluetoothを利用しているので、家の中でしか操作は出来ません。 もし、外で家電を操作したり、部屋の温度を知りたいというときはApple TVやiPadが必須となります

2016年5月にはてなブログをはじめてすでに3年半超。このブログは開設から半年経過したくらいで月10万の収益を超え、それ以降も順調に増収が続き、今もコンスタントにブログから収入を得ている。 下のグラフは1年目のブログ売上推移。（※正確な数字を出すと色々面倒なのでボカします…） 正直、自分自身もここまでになるとは思っていなかったけれど、「"ちゃんとやれば"誰にでもチャンスはある」ということを実感できた。 4年経過したので、改めてこちらに収益付きでまとめました。 関連ページ【はてなブログ5年目へ】アフィエイト収益とASPについて ●　●　● この記事では、僕が4年間ブログ運営をしていく中で収益化に役立った手法やツールを紹介してみたい。基本的には初心者向けに書いている。 前半は、収益化のステップと「ブログで稼ぐための必須ツール」に関して。誰もが収益化のために使っている必須のツールを紹介している。

一般に、「努力することはいいことだ」と思われている。 もちろん、努力をしないよりはしたほうがいい。仕事でも学びでもトレーニングでも、一定の努力は必要不可欠だ。それでも、「努力をすればいい」と思った瞬間、大事な点を見失ってしまう。問題は、労力やかけた時間ではなく、努力の質にある。 （「Introduction その努力は『いい努力』か『悪い努力』か」より） 『マッキンゼーで25年にわたって膨大な仕事をしてわかった いい努力』（山梨広一著、ダイヤモンド社）の著者は、このように主張します。同じ時間をかけるなら、すべて「いい努力」に転換したほうがいいという考え方。しかし、そもそも「いい努力」とはなんなのでしょうか？ このことについて著者は、次の7つのポイントを挙げています。 1. 「成果」につながるもの 2. 「目的」が明確なもの 3. 「時間軸」を的確に意識しているもの 4. 「生産性」が高いも

10年ぐらい前に筆者が会社員だったころ、日常業務の中で非常に苦手としていたのが、打ち合わせの議事録作成である。 社内の会議ぐらいならノートパソコンを持ち込んで、その都度カタカタと話の内容を入力すればいいのだが、社外の方とマンツーマンで打ち合わせをする時にそれだとちょっと感じが悪い。仕方ないので相手に断りを入れてからボイスレコーダーで録音しつつメモを取りつつ、打ち合わせをこなすことになる。で、帰社してから録音とメモを照らし合わせて議事録を作るわけだが、これがちょっと再生しては止めて、ちょっと戻ってまた聞き直して……と時間ばかりかかって非常にうんざりする作業なのだ。 では、フリーのライターになったらそんな手間から解放されたか、というと、そうはいかない。逆に「インタビュー取材」という議事録作成と同種類の作業で、かつ、まとめるのにさらに時間のかかる仕事をいただく機会が増えてきた。仕事をいただけるの

CentOS のローカル環境内に yum のリポジトリを作成する手順を紹介します。 RHEL(RedHat Enterprise Linux) や CentOS を使っている人には「何を今さら」な情報だと思いますが、アプリケーションやモジュールのインストールには rpm や yum を利用することが多いと思います。 特に yum を利用することで、目的のモジュールを導入するために必要となる前提ライブラリが既にインストールされているかどうかをチェックし、更にその前提ライブラリの前提となるライブラリのインストール状況も調べて・・・で、現在の環境に足りないライブラリやモジュールを順次インストールした上で最終的には目的のモジュールまでインストールしてくれます。非常に便利なツールです。 ただ RHEL にせよ CentOS にせよ、その利用の条件として「yum リポジトリ」と呼ばれる一連のファイル環

独自yumリポジトリを利用するよう設定を行う 作成した独自yumリポジトリにアクセスするには、リポジトリを利用する側（クライアント側）でyumの設定を行う必要がある。yumが利用するリポジトリの情報は、/etc/yum.repos.dディレクトリに格納されている。このファイルはいわゆる「ini形式」で記述されており、最小限下記のものを指定すれば良い。 [＜リポジトリ名＞] name=＜リポジトリの説明文＞ baseurl=＜リポジトリのURL＞ 「リポジトリ名」には、リポジトリの名前を、「name」にはそのリポジトリを説明する文字列を、「baseurl」にはrepodataディレクトリが存在するディレクトリをURLで指定する。 たとえば「hylompkgs」という名称で独自のリポジトリを登録する場合、以下のような内容となる。これを適当な名前（たとえば「hylmpkgs.repo」など）で/

こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ