Battle Conference U30 ( https://bcu30.jp/ )で話した時の資料です より安心して使っていただくために、これまでどうしても超えられなかった95%の壁を越えるための挑戦についてと今後のテスト方針について
カバレッジ95%以上を実現した テストコードの書き方
Battle Conference U30 ( https://bcu30.jp/ )で話した時の資料です より安心して使っていただくために、これまでどうしても超えられなかった95%の壁を越えるための挑戦についてと今後のテスト方針について
仮想 I/O 高速化手法まとめ - かーねるさんとか
仮想 I/O の高速化手法についてまとめました。特にネットワーク I/O の高速化について調べました。 デバイスの仮想化 仮想マシンが利用するネットワークカードは多くの場合、QEMU のようなエミュレータによってエミュレーションされており、物理的なネットワークカードとのやりとりはホスト上で動作する仮想スイッチを介して行われます。*1以下に構成を図示します。 エミュレートされるデバイスは Intel の 1Gbps NIC 等、実際に存在するネットワークカードと、virtio-net のような、物理的なハードウェアが存在しないインターフェースがあります。 仮想化技術は大きく「完全仮想化」と「準仮想化」に分類されます。*2 完全仮想化によってゲストへ提供される環境は、ゲストからは、現実に存在する物理ハードウェアと全く同じように見えるようエミュレートされます。結果として、ゲスト OS は、仮想化
SiriというKindle読み聞かせお姉さん - 本しゃぶり
Siriはタイマーをセットするだけの存在ではない。 Kindle読み上げこそが、彼女が最も輝く時なのである。 セールのたびに増え続ける積読を消化するための知見を共有しよう。 読み上げ機能 iOSには画面の読み上げ機能がある。この機能をKindleアプリで使うことで、Kindle本が疑似オーディオブックとなる。知っている人も多いだろうが、やり方を簡単に説明しておこう。 まず準備として「設定」→「一般」→「アクセシビリティ」→「スピーチ」へ行き、「画面の読み上げ」をONにする。 そして読みたいKindle本を開いたら、画面の上から下へと2本指でスワイプする。すると画面の読み上げが始まる。 『ルビ付き＋なし版 口語訳（旧約聖書＋新約聖書）＋文語訳（旧約聖書＋新約聖書）＋聖書地図』 Kindleの画面を開きっぱなしであれば、ページ移動も自動で行ってくれる*1。 ここまでのことはKindle+読み上
画面遷移図の作成方法ついてのまとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は、アプリケーション開発におけるUI設計の、画面遷移図について個人的に考察したものです。画面遷移図を作る上で、現状どのような選択肢があるかをまとめています。正直調べ足りないところも多々ありますので、内容が偏っていたり間違ってる可能性があります。参考にする場合はご注意ください。 画面遷移図の役割 画面遷移図とは、画面とその移り変わりを図にしたものです。画面同士を矢印などでつなぎ、矢印の方向に画面が遷移することを表したりします。 最近はUI設計の成果物として、実際に画面遷移の操作をできるモックアップの開発も盛んになっていま
エンジニア採用のための仕組みづくり - hiroppy's site
文章化したかったので記事にしました。 技術寄りの自分が思うことです。 結論 外部から見てもその会社が技術的に何をやっているかというのをわかりやすくするべきです。 自分だったら何も情報がない会社には振り向きもしないかなと思います。 ワクワクする会社がいいなって思う。 前提 入社する前(and 応募する前)のエンジニアはその会社のコードなどを知りません。 つまり、その会社で働いている人から聞くか、外から見たその会社の印象ぐらいしか判断する材料がないわけです。 面接や面談でわかることなんてほんと一握りだと思います。 エンジニアを入れたければ、どういう技術を使ってるか、どのような開発を行っているか、どのようなことに力を入れているか等を積極的に対外的に話した方が入社した後との差が少ないと思います。 どこの会社にも必ずある負債やコードの質は入社するまで見れないわけですからそこを考えてもしょうがないけど
maprobe - Mackerel のホスト情報と連携する外形監視エージェントを作った - 酒日記 はてな支店
監視を Zabbix から Mackerel に移行しています。そこで困ったことを OSS を書いて解決しようシリーズのお時間です。 ホストのダウン検知を早くしたい Mackerel の監視は Push 型と呼ばれるもので、mackerel-agent が Mackerel サーバに対してメトリクスを送信する形態です。そのため、agent を稼働させているホストがダウンしたという事象は、「一定時間サーバに対して情報が送られてこない」ことによって、組み込みのアラート "connectivity" として検知されます。 これによって困ることとしては、以下があります。 ホストが実際にダウンしてから7分程度経過しないとアラートが上がらない あまり短時間で判断してしまうと誤検知が増えるからでしょうか もうちょっと早く検知したいです "connectivity" アラートは Critical レベルし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
