ブックマーク / blog.a-know.me (30)

  • 個人開発してるWebサービスの API のシナリオテストに runn を使ってみたけど、とてもよかった - えいのうにっき

    個人開発してるWebサービス」というのは Pixela のことで、runn とは @k1loW さんが開発しているオペレーション自動化ツール/パッケージです。 pixe.la github.com Pixela は、そのユーザーインターフェースとして基的に Web API のみを提供しているサービスで(サービスを利用するための各種操作は基的にすべて Web API に対する HTTP リクエストによって行う必要がある)、現在そのローンチから6年目を迎えるサービスです。 blog.a-know.me ありがたいことに、世界中のユーザー(特に、プログラミング初学者の方によくご利用いただいているようです)に継続的に使っていただけているサービスになっており、登録ユーザー数はもうすぐ7万人に到達しようとしているところです。開発・メンテナンスに係る私の人件費を除けば、黒字運営を続けることもできて

    個人開発してるWebサービスの API のシナリオテストに runn を使ってみたけど、とてもよかった - えいのうにっき
  • 「カオスエンジニアリング」を読んだけど、とてもよかった - えいのうにっき

    今の会社の同僚、というかチームメイトが訳を手掛けた「カオスエンジニアリング」、これを頂戴してから実に4ヶ月弱、先日ようやく読み終わりました...。。遅読にも程がある。 こちら来ました、ご恵贈いただきました!!ありがとうございます、ちょっとスピードは遅めかもなんですが読みます!!! pic.twitter.com/GBxvw9gVjV— a-know | Daisuke Inoue (@a_know) June 10, 2022 このを読むまでは、「カオスエンジニアリング」という言葉だけは知っていて、......と思っていたけど、実際に読んでみて、「自分は何も知らなかったんや...」ということに気が付きました。当によかった。 カオスエンジニアリング、僕が盛大に勘違いしていたこととして「”カオス” をいかにもたらすかというエンジニアリング」かと思ってたのだけど、そうじゃ(それだけじゃ)なく

    「カオスエンジニアリング」を読んだけど、とてもよかった - えいのうにっき
  • 僕は CREing:ソフトウェアエンジニアにカスタマーサクセスを任せたときに起こるもの、を Autify で実現したいと思っている - えいのうにっき

    この文章で出てくる用語たち: SRE Site Reliability Engineering / Engineer 。 前者のことを指して SREing, 後者のことを指して SREs, と表記することもある サイトリライアビリティエンジニアリング - Wikipedia CRE Customer Reliability Engineering / Engineer 。 「CRE」という言葉が使われるときはだいたい後者な気がする。前者を指してこの言葉が使われてるのはあんまり見ないな、という印象がある 僕自身、前職でサーバーモニタリングSaaSに携わっていたこともあって「SRE」については最低限の知識というか、その概念の理解はあるつもり。でも最近目にしたこちらの記事を読んで、ああそうだった、と認識を新たにした表現があった。以下は、この記事の中の「そもそもSREとは何なのか」という問を受けて

    僕は CREing:ソフトウェアエンジニアにカスタマーサクセスを任せたときに起こるもの、を Autify で実現したいと思っている - えいのうにっき
  • 中身が不定のJSONオブジェクトをGo言語で扱うのに mattn/go-jsonpointer が便利だった - えいのうにっき

    今日書くのは、先日Go言語の個人プロジェクトである Pixela に手を加えた際に実感したことについて。 先日手を加えたものの一部に、以下のようなものがあった。 > 以下のようなコマンドを実行してみましょう。 > > curl -X GET https://pixe.la/v1/users/a-know/graphs/stopwatch-test/20200504 -H 'X-USER-TOKEN:thisissecret' > > Pixela では、各日付ごとのデータを pixel と呼んでいるのですが、その詳細を取得できるコマンドです。`20200504` のところは詳細を確認したい日付を指定します。このコマンドの実行がうまくいけば、以下のような結果が表示されると思います。 > > {"quantity":"0.50","optionalData":"{\"stopwatchUsag

    中身が不定のJSONオブジェクトをGo言語で扱うのに mattn/go-jsonpointer が便利だった - えいのうにっき
  • はてな の CRE の今 - えいのうにっき

    ウオオオオオオ!!! はてなCREが新たなステージに突入するぞ!! https://t.co/itwjrAu9ae— a-know | Daisuke Inoue (@a_know) 2020年2月5日 上記の引用リツイート元のツイート主である id:syou6162 は、社(はてな)の同僚なのですが、この2月から、僕と同じ職種・CRE(Customer Reliability Engineer)になってくれることになりました。 元のツイートにある通り、彼はこれまで、はてなのアプリケーションエンジニアとして、Mackerelのサービス開発、特にロール内異常検知に代表されるような機械学習アルゴリズムを活用した機能開発を担当していました。そんな彼が、CREという職種に魅力や可能性を感じてそこにベットしてくれたこと、大変うれしく思うと同時に、はてなでのCREという職種の立ち上げに携わった者とし

    はてな の CRE の今 - えいのうにっき
  • AWSとGCPをいくつかの観点で比較してみたメモ - えいのうにっき

    Google Cloud の認定資格、Professional Cloud Architect が最近気になっている。 cloud.google.com なぜ気になっているかというと、業務上プラスになることがありそう、ということはさることながら、以下の記事を読み「合格すると認定グッズがもらえる」「リュック(デイバッグ)良さそう!」と思ったこと、というのが実は大きい。物欲。 medium.com この気分がどこまで続くかはさておき、ゆるゆると勉強しはじめたのは事実。勉強も、手元でいろいろと整理しながらやっており、その整理したものについてこのブログにもメモしておきたい。もしかしたら資格取得以外の目的でも誰かの役に立つかもしれない。。ということで書いてる。 今回は、AWSGCPをいくつかの観点で比較・整理してみたもののメモ。 AWSGCPの比較 リージョン・ゾーン AWSでは、あるリージョン

    AWSとGCPをいくつかの観点で比較してみたメモ - えいのうにっき
  • サイボウズさんのイベント #CybozuMeetup で「リモートスクラム」について話を聞いてきた - えいのうにっき

    昨日・7/26、【東京開催】Cybozu Meetup 西日でのリモート開発事情 - connpass というイベントがあり、そこに参加してきた。 cybozu.connpass.com 僕は出身が岡山県で、「いつとは言わずともいつかは地元に帰りたいなぁ」という気持ちはずっと持っているので、そういう意味では「西日」というワードに惹かれたのもウソではないのだけど、今回参加してみようと思った理由はもうひとつあって、それが「リモートスクラム」というキーワードがconnpassページ内に見られたこと。僕は前職でスクラムマスターをやっていた経験があり、現職でも(スクラムチームには入っていないものの、)スクラムのプラクティスが活用されている・しかもリモート拠点でやっている、ということもあり、「スクラム開発」はいまだに僕の興味トピックのうちのひとつであり続けている。 connpassページにもあると

    サイボウズさんのイベント #CybozuMeetup で「リモートスクラム」について話を聞いてきた - えいのうにっき
  • インフラエンジニア・SREなどの職種関係なく同じグラフを見ると楽しい - えいのうにっき

    このエントリは、サーバー監視サービス・Mackerel の中の人であり、Mackerel 大好き人間でもある私・ id:a-know がお届けしています。 Evernote や Dropbox paper など、世の中には様々なメモのためのアプリケーションがあるけれど、僕は個人用のメモをつけるための道具として、 kibela と esa の両方をユースケースに応じて使い分けている。いずれも所属ユーザーは僕一人しかいない、ひとりチームとしての利用なのだけど。 kibela https://kibe.la/ja 日々の生活におけるメモ。日記とか。 日記は2017年3月から毎日書き続けている......。。 esa https://esa.io/ プライベート開発用。 開発関連作業においての副産物として生まれるもののメモやコード片など。 僕の使い方としてはこんなかんじ。どちらも、企業内で情報共有

    インフラエンジニア・SREなどの職種関係なく同じグラフを見ると楽しい - えいのうにっき
  • 安価なGKE(k8s)クラスタを作って趣味開発に活用する - えいのうにっき

    tl;dr GKEでk8s(kubernetes)クラスタを作成すると、各ノードはGCEインスタンスとして起動する GCEインスタンスには preemptible モードが指定でき、これはGKEクラスタとして起動するノードに対しても指定可能 GCEのf1-micro無料枠の適用と合わせて、この運用費用は約 $7.68/month 動機 GKEクラスタを維持する最安料金ていくらだろー— a-know | Daisuke Inoue (@a_know) 2018年6月11日 趣味開発用途として手軽にあれこれ試すことができて、それでいてできるだけ安くあがるコンテナオーケストレーション環境(k8s環境)がほしい。 k8sそのものを運用したい・そのノウハウを学びたいというわけではないのでマネージドサービスがいい 「k8s上でアプリケーション・サービスを運用する経験」がしたい その上で、できるだけ安く

    安価なGKE(k8s)クラスタを作って趣味開発に活用する - えいのうにっき
  • サーバーが高負荷状態になったときのプロセス一覧を自動で出力させておく - えいのうにっき

    趣味でお世話をしているサーバーインスタンスのうちのひとつが、最近以下のような事象を時折起こしておりまして。 深夜に一時的に高負荷状態に陥る 朝起きてみたらそれに気づく(終息している) さすがに趣味の範疇なので、深夜に飛び起きて対応できるようなアラート通知設定はしておらず、とはいえ起きてからその理由を探ろうとするのだけど、終息したあとに見られるものといったらせいぜい以下のようなことくらい? モニタリングツール(Mackerel)のその当時のグラフの様子 アプリケーションログを見る /var/log とかに出力されてるログを見る 今回の場合だとCPU使用率とLA(ロードアベレージ)が高騰していたことくらいしかわからずで、そのときにどういうプロセスがリソースをってたんだろう、みたいなことは把握することができなかった。 こんなかんじ。diskはちょっとハネてるかな...。。 対象のサーバーには

    サーバーが高負荷状態になったときのプロセス一覧を自動で出力させておく - えいのうにっき
  • nginx で EU からのアクセスを拒否する - えいのうにっき

    「あ、EUからのアクセスを拒否したいな......」と思うこと、ありますよね。私も今日、そう思いました。 私は趣味と実益を兼ねて(いるつもり)、いくつかのしょうもないWebサービスを個人で運用してるのですが、そこに対するEUからのアクセスを遮断したいと思い、それを nginx で対応してみたので、そのメモです。 手順 基的にはこちら↓の知見の固まりを参考文献としています。 inaba-serverdesign.jp EU加盟国は、外務省のページ(EU加盟国と地図 第5次拡大|外務省)によると以下の28カ国。 アイルランド イタリア 英国 エストニア オーストリア オランダ キプロス ギリシャ クロアチア スウェーデン スペイン スロバキア スロベニア チェコ デンマーク ドイツ(加盟時西ドイツ) ハンガリー フィンランド フランス ブルガリア ベルギー ポーランド ポルトガル マルタ ラ

    nginx で EU からのアクセスを拒否する - えいのうにっき
  • ふりかえり や KPT などのファシリテーターをやるときに意識していること - えいのうにっき

    前職ではスクラムマスター的な立ち回りをしていたり、今でもたまにファシリテーターを頼まれることがあったりするので、そのときに気をつけてることをちょっとメモしてみる。どちらかというと経験則に近いかんじ。 その場にいる、できるだけ多くの人に話をしてもらえるようにする ある事象について、「それを知ってそうな・知らなそうな人」「その場にいた人・いなかった人」に意識をフォーカスして掘り下げる 「なぜ・どうして」や「どのようにして」、そして「どうあるべきか」にフォーカスする (そもそもの話)できるだけ当事者じゃない人がファシリテートするのがよい なんかもっとある気がするので思い出したら追記します。 その場にいる、できるだけ多くの人に話をしてもらえるようにする チームの大小あると思うけど、できるだけ多くの人に話をしてもらえるようにする。理想的にはその場にいる全員に一度は発言の機会はあって欲しいし、それがで

    ふりかえり や KPT などのファシリテーターをやるときに意識していること - えいのうにっき
  • Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき

    もともと数ヶ月前から、Go言語によるWebアプリケーション開発 を読みながら Go での Webアプリケーション開発の勉強をしていた。 Go言語によるWebアプリケーション開発 作者: Mat Ryer,鵜飼文敏,牧野聡出版社/メーカー: オライリージャパン発売日: 2016/01/22メディア: 大型この商品を含むブログ (3件) を見る 「実際に動くもの」を、「手を動かして作りながら学ぶ」のが僕は好きで、今回も同様、それを楽しんでやっていたのだけど、思いの外それっぽいものができあがってしまって。これをそのままローカルで動かすだけじゃおもしろくないな、もったいないな、と思ったので、それをサービス化して公開するところまでやってみた。 かんじんのアプリケーションは↓これ。Yukizuri と書いて「ゆきずり」と読む。 https://yukizuri.moshimo.worksyukizu

    Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき
  • 前株/後株判定コマンド・kabu を Go でつくった - えいのうにっき

    どうしようもないコマンド・ツールなんだけど、日頃地味に困ることが多いので、表題のツールを作った。 $ kabu はてな 前株マッチ数:9 後株マッチ数:0 前株です! 株式会社はてな どうしようもない...。。 仕様 日頃の業務などで「この会社、前株だっけな、後株だっけな...。。」というとき、ありますよね。みなさんはどうしてるんでしょう。 ぼくはどうしてるかというと、「会社名 株式会社」といったワードでぐぐって、その結果をざっと眺めて「あぁ、前株/後株だったな...。。」というかんじでやってます。これをもう、100万回ぐらいやってる。さすがに嫌気が差したので、その作業をそのままやってくれるコマンドを書きました。その名も kabu 。 つかいかた リポジトリ の README にも書いてるのだけど、kabu は、Google Custom Search API を使用してるので、予め Go

    前株/後株判定コマンド・kabu を Go でつくった - えいのうにっき
  • 読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき

    「詳解システムパフォーマンス」の読書メモシリーズ・第3弾。 詳解システムパフォーマンスを読んでいる話・2章/メソドロジ 読書メモ - えいのうにっき 読書メモ・詳解システムパフォーマンス 第3章/オペレーティングシステム - えいのうにっき 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る この回はなんだっかの理由で輪読会に参加できなかったので、前回のような「輪読会の場での話題」みたいなのはなし。スミマセン。 感想 僕自身が システムエンジニア -> PaaS(GAE)エンジニア -> Web アプリケーションエンジニア -> セールスエンジニア(イマココ) 、というキャリアを踏んできたこともあってか、「システムが

    読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき
  • Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき

    Mackerel について考えない日はないというくらいに Mackerel・Love な僕なわけですが(考えない日はあります)、Mackerel の Web 画面で日頃なにげなく見ている「システムメトリック」、みなさんはどのような意識を持って観察していますでしょうか。 ↑ https://home.a-know.me をホストしているサーバのシステムメトリックのようす。 ここでひとつおさらいをしておくと、「システムメトリック」とは、監視対象のサーバにインストールされた mackerel-agent が、それ単体で収集・投稿するメトリックのことです。一般的な Linux系OS に mackerel-agent をインストールした場合、以下のような項目がシステムメトリックとして Mackerel に投稿されます。 loadavg5 cpu memory disk interface files

    Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき
  • 「みんなのGo言語」が良かったので、自分のためだけのCLIツールを作ってみた - えいのうにっき

    言わずと知れた書籍「みんなのGo言語」。発売直後くらいに購入してはいたんだけど、目次あたりをパラパラ見て「あ、これは2,3日集中してガッとやりたくなるやつだ」と思って。で、タイミングを見計らっているうちに年末年始休暇に突入してしまったのだけど、そのタイミングでちゃんと「ガッ」とできたので、今日はそのお話をば。 みんなのGo言語[現場で使える実践テクニック] 作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太出版社/メーカー: 技術評論社発売日: 2016/09/09メディア: Kindle版この商品を含むブログを見る 僕と Go 言語 僕の Go 言語遍歴について少しだけ触れておく。 以前、個人的にちょっと作ってみたいツールがあった時期があって。そのとき既に Go がそこそこもてはやされていたこともあって、そのツールは Go で書いてみていた。↓がリポジトリなんだけど(コ

    「みんなのGo言語」が良かったので、自分のためだけのCLIツールを作ってみた - えいのうにっき
  • はてなに入って良かったと思っていること - えいのうにっき

    こういうのって、「はてなに入って良かったと思っている○つのこと」みたいな感じでまとめて書くことができたらそれが一番なんだろうなということは薄々わかっていて、そして入社してから今日までの間に「良かったな」と感じたこと全てをまとめればきっとそれもできなくはないとは思うんだけど、そういう実感って得てして儚いもので、すぐに自分にとって「当たり前」なものになってしまう。儚い。 今日ふと噛み締めた(そしてこのエントリで書こうと思っている)「よかったという実感」もその点ではきっと一緒なんだけど、そうやって全てを「当たり前」にしてしまうことに、と急にもったいないような感情に襲われたので、「はてなに入って良かったと思っていること」というタイトルで、これから書くひとつのこと以外にももちろんたくさんあるんだけど、今日のところはこれ一つで勘弁してくださいという感じで、長い前置きは終わり。 で、その今日ふと噛み締め

    はてなに入って良かったと思っていること - えいのうにっき
  • Unixプロセスとリソースの基礎を再確認した - えいのうにっき

    前置き 最近、「なるほどUnixプロセス ― Rubyで学ぶUnixの基礎」というを読んでいる。 tatsu-zine.com 僕の所属している会社・はてなでは「メンター制度」というものがある。はてなに所属する全てのエンジニアに、誰かしら(グレード的に自分より上となるエンジニア)をメンターとしてつける、という制度。メンターとメンティーは月に一度、1on1を実施する。 自分はセールスエンジニアという特殊な職種ではあるが、メンターとしてシスプラ(インフラ)部門のエンジニアの方に付いて頂くことになった。このことは僕にとって、とても有り難く、心強い。 というのも、入社から2ヶ月ちょっと、実際にセールスエンジニアとして業務を進めてみて、インフラ周りの基礎知識・ローレイヤーに関しての基礎知識が強く求められるなぁと...、、というか、それを知っているといないとでは、問題や課題についての理解の仕方も違っ

    Unixプロセスとリソースの基礎を再確認した - えいのうにっき
  • Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき

    前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身(親プロセス)の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実

    Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき