サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
masutaka.net
本日 2023 年 8 月 3 日をもって、PayPay株式会社を退職しました。 [2023-01-31-1] に書いたとおり、今年の 2 月 1 日が入社日だったので、在籍期間はわずか 6 ヶ月と 3 日です。先月から有休消化に入っていたので、実働はなんと 5 ヶ月という短期間でした。 今までの会社は 10 年程度は在籍していたので、なによりも自分がびっくりしています。😳 なぜ辞めたのか# ここで一方的に書くことはフェアではないですし、何よりも自分の価値を下げると思うので、理由は書かないことにします。 今回改めて分かったことは、HRT に基づく心理的安全性がある環境でこそ、自分は伸び伸びとパフォーマンスを発揮できることでした。 前職フィードフォースではフリーライドはしていないつもりでしたが、実際は多くの方々の尽力の上に成り立っていたのだと改めて感じます。 Looker との関わり方#
本日 2023 年 1 月 31 日をもって、株式会社フィードフォース を退職しました。退職は人生 3 回目で [2014-03-09-1] に書いたラングリッチ以来です。 入社が 2014 年 3 月 1 日なので、8 年 11 ヶ月在籍していたことになります。新卒で入社したメタテクノの 11 年に続く長さです。 こんなに長く在籍するとは思ってもおらず、配属されたチームで目の前の課題に向き合っていたら、結果的にこれだけの期間在籍することとなりました。 いろいろ足りないところはあったと思いますが、フィードフォースならびに仕事で関わった皆様、これまでありがとうございました。楽しかったです。これからは一株主として応援しますし、将来また仕事で関わることもあるかもしれません。 これまでのロールを振り返る# About 新卒で入社したメタテクノでは、2000 年 4 月から 2011 年 初めまで、
最近は人間からのメールは減り、機械からのメールが多くを占めるようになりました。その中にはメールを停止できなかったり、メール購読を義務付けられた酷いサービスもあります。 私は仕事もプライベートもインボックス・ゼロを実践しています。それもあって今まで Gmail の検索演算子 をチマチマと調べて、チマチマと設定していましたが、以前から全てを自分の管理下に起きたい欲求がありました。この度ついに強い衝動にかられたので、ゴリッと管理し始めました。 gmailctl を使うことにした# こちらの記事にも影響されて、私的には gmailctl が良いという結論に達しました。 Gmail filters as a code. Using gmailctl to create filters and…|by Hans Jakob Emmel|The Startup|Medium 最初は gmailfilte
職場の同僚が勧めていたので遅ればせながら読みました。私が 20 年近くかけてたどり着いた技術(未だに不完全です)を、この本で習得出来る人が羨ましいです。 仕事で少しでも文章を書く人全てにオススメします。ブログを書く人にもオススメできます。反対に、物語を書くための技術ではありません。 欧米では論理的な文章はパラグラフを使って書くそうです。パラグラフで書けば各パラグラフの先頭文をつまみ食いする、流し読みが出来ます。副次効果として、速読出来る文章になります。もちろんじっくり読むことも出来ます。論理的な文章は物語などと違って、関係者以外は流し読みしたいことが多いですからね。 特筆すべきことは、この本自体がパラグラフで書かれていることです。流し読みできます。しました。 パラグラフを適切に使っていれば、文字どおり見た目が良くなると感じてきました。良いメールやブログを書けた時は、見た目に惚れ惚れして何度
最近この Issue が活発になってきました。 Terraform 0.15 support · Issue #1176 · dependabot/dependabot-core 実はプロバイダーバージョンのアップデートだけならもう使えます。 ・プロバイダーバージョンのアップデートはもう動く ・↑の後に必要な .terraform.lock.hcl の更新は実装中とのこと。現在は手動で “$ terraform init -upgrade” が必要 ・terraform バージョンのアップデートはロードマップに含まれていない ↓プライベートリポジトリで動いている様子。 dependabot.yml のドキュメントはここにある ので、試してみるのも良いかもしれません。 ↓このブログが置いてあるリポジトリの .github/dependabot.yml です。daily はやり過ぎなのであとで
今まではこんなんでした。3 本のケーブルを洗濯バサミ()でまとめて、Anker の USB 急速充電器に引っかけています。かろうじて落ちません。すみません嘘つきました。たまに落ちます。 Anker のマグネットケーブルホルダーを使えばアラすっきり!少し様子がおかしいのは気にしない。 付属のクリップでケーブルを挟み込んで、台座に磁石で付く仕組みなのですが、直径 3.5mm 以下という制約がなかなかキツイ。今どき珍しい Mini DisplayPort ケーブルは無理だったので、別のクリップで凌ぎました。 Anker Magnetic Cable Holder マグネット式 ケーブルホルダー ライトニングケーブル USB-C ケーブル Micro USB ケーブル 他対応 (ブルー) amazon.co.jp
[2020-12-03-1] では優先度は優先順位の下位レイヤーであり、優先順位を決めることが大事という話をしました。では優先順位はどう決めると良いでしょうか? 私はここ 10 年くらいの試行錯誤の末に「やるかもしれないリスト」という方法にたどり着きました。 現在はこのような esa 上の 1 記事として存在しています。 私が「やるかもしれないリスト」でやっていることはだいたい 3 つです。 頭の中を 1 つのテキストファイルにリストとして書き出し続ける 優先順位を並べ替え続ける 敢えて時間を置くことで、思考を寝かせ、よく練られた考えにし続ける 2020-06-09 に作ってから 203 回更新しています。1 日 1 回以上更新している計算になります。 アイディアを思いつくたびに追加したり順番を入れ替えたりしているので、このような更新回数になりました。こういうことはだいたい、仕事以外の時間
この記事は Feedforce Advent Calendar 2020 の 3 日目の記事です。 昨日は kysnrm の「さよなら湯島 」でした。私も今のところに住んで来年で 6 年になるので、8 回目の引っ越しを少し考えてますが、まだ状況が流動的なので悩ましい…。 (ここから歌詞) 優先度を付けると、高高高高高高とかになることあるよね。みんな優先度が高い。 でも人間は一度に複数のタスクを処理することは出来ないよ。 それに実際終わってみたら、終わった順番が付いているはずだよ。 じゃあ 1, 2, 3… とタスクに順番を付けてみようか。つまりは優先順位ね。 優先度より優先順位のほうが偉い。ダンダン 優先度は優先順位を決める1つの要素でしかないよ。区別しようか。 例えば他にもこんなのを考慮する必要があるよ。 ・期日 ・かかる時間 ・かかるお金 ・サービスへのインパクト(顧客増加、顧客満足度
8/11 に Emacs 27.1 がリリースされました。 全然追ってなかったのですが、タブ機能がようやくネイティブでサポートされたそうなので、elscreen.el から移行してみました。 https://github.com/masutaka/dotfiles-public/commit/14710b91d5342c4aec6666c0bd38dec7808d9927 tab-bar.el のコード(※)を見て、出来るだけ独自の設定はせずに、elscreen.el の挙動と合わせてみました。 ※ M-x find-library [Enter] tab-bar [Enter] で開けます。 真のデフォルト厨なら C-x t ? で確認できるキーを使うべきなのでしょうが、ヘタレなので elscreen.el と同じ C-z を Prefix key にしました。 タブ数の制限がなくなった
2 月からほぼフルリモートで仕事してます。 会社の勤怠管理システムはジョブカン が導入されています。物理出社していた時は、物理 Suica カードを NFC リーダーにタッチして打刻していました。 リモートワークでは物理タッチはできないため、Slack の任意のチャンネルで /jobcan_touch と POST して打刻しています。他の社員への共有も兼ねています。 ただ、毎日の /jobcan_touch が面倒になってきました。私は Slack status もゆるふわでセットしているため、追い打ちで面倒です。 いくつか試して今は iOS のショートカットに落ち着いたので、記事に残しておきます。 使い方# ホーム画面を右にスワイプすると現れるウィジェットに iOS ショートカットを登録し、直接使う3つのショートカットを表示させています。 使用感はこんな感じです。 誤タップして打刻して
[2019-05-07-1] に紹介した『Pragmatic Terraform on AWS 』に沿って設計すると、terraform のディレクトリは複数出来ると思います。 依存を分けることと、まとめて実行することはやや矛盾します。とは言え terraform や terraform provider がアップデートした時の terraform init/plan/apply はまとめてやりたいものです。 少し前に作って使っていますが、なかなか良い感じです。 使っている Makefile たち# この辺りを工夫しました。 ・terraform init/plan/apply に失敗すると、即座に停止する ・make の -C オプションを使って、cd せずに make を実行できている。つまり cd .. とかで戻る必要がない。そういう理由で下位ディレクトリに Makefile 置いて
週刊Railsウォッチ(20200225前編)RubyのShellwordsライブラリは知っておくべき、VCRはやはり有能、copを自作、Hix on Rails記事ほか|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社 RuboCopでコードレビュー支援: Net::HTTPを使わせないcop(Hacklines より) そういえば以前業務で似たことをやったので、メモがてら置いておきます。 Dir.chdir はスレッドセーフではない# Sidekiq で Dir.chdir を使ったら、他のジョブと干渉してハマりました。 Feature #9785: Feature Proposal: Dir.chdir Thread Safety - Ruby master - Ruby Issue Tracking System ↑ こちらの Issue を見つ
職場の同僚が積読していて、153 ページしかないと聞いたので、Kindle 版を買って読んでみた。 10 年前にデバイスドライバとか書いたことがあったので(Linux ではなく VxWorks ですが)、懐かしながら読んだ。アドレス変換やったなーとか。 Linux カーネルを読むのはそこまで特別な知識は要らなくて、マクロ展開が分からない時はプリプロセッサ出力を確認したりして、超地道に読み進める必要があるそう。 P153 ページしかないので、近々で Linux カーネルを読む予定がなくても、興味がある人は読むと面白いかも。 以下は自分用メモ。 P95 周辺機器からの割り込みのことをハードウェア割り込みや外部割り込みといいますが、「/proc/interrupts」を見ることで何回割り込みが発生したかが分かります P144 SystemTap というツールを使うと、カーネルをビルドすることなく
夏休みを利用して読みました。初版は [2016-09-25-1] でじっくり読んで手も動かしたので、本当にさらっとね。 最近は Go のコードをほとんど書いてなくて、Go Modules に追いついている程度でした。ただ、それほど分からない情報もなかったので、ある意味答え合わせにはなった気がします。 例えば拙作の github-nippou で go-bindata から statik に乗り換えた のは、誤りでなかったなとか(P41)。 ちょうど設定ファイルのフォーマットをどうしようとか、置き場所を XDG Base Directory Specification に合わせようとか考えていたので、「2.8 設定ファイルの取り扱い(P45)」もタイムリーでした。 読んでて Interface 使ってコードを Testable にするだとか、HTTP Mock とか、課題をいろいろ思い出しま
会社で使っている Qiita:Team が esa に移行されることになったので、早速作ってみました。 こんな感じに esa の記事を Helm Interface 上で絞り込んで、ブラウザで開くことが出来ます。 デフォルトでは絞り込み対象は “watched:true kind:stock” で検索された記事です。よく参照または編集するであろう記事を、Web ブラウザで素早く開く使い方を想定しています。 MELPAにも取り込まれた ので、M-x package-install helm-esa でインストールできます。 作りながら考えたこと# 今回の helm-esa.el は helm-qiita.el [2016-05-06-1] の後継ツールのような気持ちで作り始めました。 最初、Qiita:Team の Stock は、esa だと Watch なのかなーくらいの考えで作っていま
【ダウンロード版】Pragmatic Terraform on AWS - KOS-MOS - BOOTH これも職場の同僚氏がオススメしていた本。 普段から Terraform の設計に課題を感じていたので、ざーっと斜め読みして、第17章からしっかり読んだ。 その中での設計のやり方が モノリス → モジュールの利用 → 環境(ステージ)の分離 → コンポーネント分離 と段階を踏んでおりとても良いと思った。そう、これなんですよ。最初は main.tf だけで十分。 Terraform の設計はアプリケーション設計とよく似ており、初めから抽象化すると難しくなると思う。 基本は宣言的に書いていき、設定ファイルのような読めるコードにする。3回くらい重複し始めたくらいで、変数やモジュールに落とし込むのが良いはず。 17.4.1 の “安定度の高いコンポーネントは、変動を想定したコンポーネントに依存
職場の同僚氏から勧められた本。ブラウザのチューニングについて、レンダリングプロセスから説明されている。ブラウザがどう動いているかの解説本としては弱いけど、他に代わりはないそう。 kosamari さんの記事 も紹介してくれたので、あとで読む。 2017 年の本なので、TLS 1.3 は言及しつつも説明してなかったり、Microsoft Edge のレンダリングエンジンがまだ EdgeHTML だったりするけどが、丁寧に書かれており良書だと思った。 私は最初の会社ではレーザープリンタのファームウェア側のレンダラを担当していたので、その知識と照らし合わせながら読んだ(Display List という単語を見た時はニヤリとした)。 なぜ 1 つの Display List でページ全体を表現しないのかと思ったけど、プリンタと違って再レンダリングが発生するからか。なるほど。他にもブラウザはアニメー
先月、固定 IP アドレス機能を提供する QuotaGuard Static Add-on の Buildpack を作りました。 https://github.com/masutaka/heroku-buildpack-qgsocksify https://github.com/masutaka/heroku-buildpack-qgtunnel Buildpack を自作したのは今回が初めてです。 Add-on のドキュメント の通りにインストールすると、バイナリファイルをリポジトリに commit することになります。あまりきれいな方法に思えなかったことが、これらの Buildpack を作った動機です。 Buildpack を作ってみて、それがどのようにインストールされるか興味が湧いたので、詳しく調べてみました。 前準備# 今回は Getting Started on Heroku
人事の超プロが明かす評価基準―――「できる人」と「認められる人」はどこが違うのか (三笠書房 電子書籍) amazon.co.jp 柴田さんの記事 を読んで、これだ!と思って衝動的に買った。 本の中では「評価される人」=「影響力のある人」が一番響いたかな。 反面、この本の核心である後半に進むに連れて、ピンと来ない箇所が増えていった。総合職向けだからかな。 特に「スペシャリストとしての道を歩むなら、そのスキルが陳腐化するものではないか、よく見極める必要がある」のくだり。スペシャリストとして重要なのはスキルそのものではなく、スキルを習得するためのスキルだと思うので、何かが違う気がした。 コンピテンシーをまあそうだよねと思えるのは、ここ数年で構築された今の会社の評価制度を作った方々のおかげだろうなあ。私はただのフリーライダー…(白目 それはさておき、この記事を書いていて、気がついたら妄想し自分の
追記(2019-09-23): ⚠️ この記事の GitHub Actions は HCL 記法を使う古い方法です。現在は YAML 記法に変わりました。参考にしないで下さい。 先日 [2019-02-03-1] 作った GitHub Action のリポジトリページにこんな表示が出てました。 https://github.com/masutaka/github-actions-all-in-one-project こちらのドキュメント によると、リポジトリの Release ページ から公開できるとのこと。 全部グリーンになるように、Icon や Color などを直しました 。あとは普通にリリース。 あっさりとリリースできました! https://github.com/marketplace/actions/all-in-one-project Marketplace の目立つところに
追記(2019-09-23): ⚠️ この記事の GitHub Actions は HCL 記法を使う古い方法です。現在は YAML 記法に変わりました。参考にしないで下さい。 このブログの CI には割高なので、CircleCI あたりに乗り換える予定です。 と [2019-01-27-1] で書いたばかりですが、舌の根も乾かぬうちに GitHub Actions に移行してみました。 料金はさておき、たまたまクラスメソッドさんの記事 を見て移行出来そうだったことと、GitHub Actions は一度素振りしてみたかったからです。 GitHub Actions とは# CircleCI の Workflows と非常に良く似た機能で、Pipeline を組んで CI を実行することが出来ます。 現在はまだベータです。https://github.com/features/actions
この記事は heroku Advent Calendar 2018 の 21 日目の記事です。 20 日目は @pukka さんの『【Heroku検討者向け】デプロイ方法5選! 』でした。(4)マニフェストでの heroku.yml の使い方は初めて知りました。デプロイした ところ、heroku18 Stack の Docker Image が使われているようでした。Slug を作る従来の非 Docker デプロイも Docker に寄せられていくのかな? 今日はそんな Slug に注目した記事をお届けします。 Slug とは# みなさん、Heroku の Slug はご存知でしょうか? ダッシュボードの Settings タブからサイズを確認できます。 でもこれしか情報がないのですよね。恥ずかしがり屋さんかな? Slug Compiler のドキュメントによると、 Slugs are c
これは Redash Advent Calendar 2018 の 17 日目の記事です。 16 日目は @mazamachi さんの『kubernetess の redash か黒魔術』ですが、まだ投稿されていないようですね。今回の記事にも関連するので期待してます。 1 日目の『2018年12月現在における Redash のはじめかた 』を拝見しました。実際問題、どこに立てれば良いか、悩む方もいらっしゃるのではないでしょうか。今回はその点をまとめていきます。 Redash をどこに立てれば良いか?# 身も蓋もありませんが、ご自身が一番慣れた Docker の PaaS 上で動かすのが良いと思います。 AWS EC2 や GCE などの、非 Docker 環境は運用負荷がそれなりに発生するため、避けたほうが良いでしょう。アップグレードでハマったり、ストレージ使用量 100% になるのはある
https://herokujp.doorkeeper.jp/events/82754 最近業務で Heroku 周りのことを一手に引き受けています。社内に本番環境での知見はあまりないので、参加してきました。 参加は初なんですが、前回の記事 [2018-11-21-1] を Slack の HerokuJP User Group にシェアしたら成り行きで話すことに。LT 以外で外で話すのは初でしたが、良い意味でこじんまりした Meetup で、割とリラックスして話せましたね。 会社の勉強会だと 20 人くらいいるので、良い訓練になっていたのかも。 アプリケーションエンジニアから見た The Twelve-Factor App by @kimihom The Twelve-Factor App は以前読んだことがあったけど、もう一度確認しようと思いました。 config/environmen
先週 Building Docker Images with heroku.yml が GA になってました。 Building Docker Images with heroku.yml Is Generally Available heroku.yml は使ったことがなく、最近 Redash を Docker on Heroku で 立て、モチベーションが上がっているので、早速試してみました。 今までの方法と比較しながら、気づいたことを中心にまとめていきます。 Container Registry & Runtime (Docker Deploys) 今まで Heroku で Docker を使うときは、このようにデプロイしていました。 $ heroku container:push web # (1) $ heroku container:release web # (2) (1)
https://rebuild.fm/209/ を聞いたら、なんとなく購買意欲が湧いて買ってしまいました。会社の MVP 賞 で頂いた Amazon ギフト券のそこそこ有意義な使いみちを探していたという事情もあります。 IRKit は [2015-12-19-1] から便利に使っていて、Nature Remo が出たことも知っていましたが、IRKit の 2 倍の値段は高いなーと見送っていました。 結果的に非常に満足しています。せっかくなので少し前に出た Nature Remo mini ではなく、Nature Remo を買いました。 ※ Nature Remo mini は主にセンサーが省かれた廉価版です。 https://nature.global/ の下の方に Nature Remo との比較があります。 ¥14,040 の価値があったかはまだ微妙ですが、今後アップデートしていくそ
混乱しやすいが、SFTP は SSH を使って暗号化・認証を行うプロトコルで FTPS とは別。 ・HTTP のセキュア版が HTTPS ・FTP のセキュア版が FTPS と覚えると良いだろう。 サンプルコード# FTP の SaaS である BrickFTP にアカウントを作った。 Net::FTP で接続可能。以下は FTPS 接続し、PWD を発行する Ruby コー ド。password はマスクしている。 #!/usr/bin/env ruby require 'net/ftp' ftps = Net::FTP.new( 'masutaka.brickftp.com', ssl: true, username: '[email protected]', password: '********', debug_mode: true, ) puts ftps.pwd 結果。 con
さて、では通知をどうやって読むか?だが、原点にかえって GitHub の Notifications ページで頑張ってみたい。 私も何年も GitHub の Notifications ページをメインにしている。mention には絶対気づくし、周辺の情報もきちんと取捨選択が出来ていると思う。 GitHub の Notifications ページ# Notifications の良いところは、イシューや Pull Request の件名が一覧表示されるので、件名で仕分けできそうな点だ。 そうなんですよね。実はだいぶ使いやすいです。 まずは https://github.com/notifications を訪れて Participating をクリックし、自分宛ての mention を読む。初めから Participating を訪れても良いかもしれない。 その後に Unread をクリッ
次のページ
このページを最初にブックマークしてみませんか?
『マスタカの ChangeLog メモ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く