Slack のリマインダーのメッセージ本文を展開して一覧表示する Slack アプリを作った - @kyanny's blog
Slack のリマインダー機能はもっぱら「メッセージにリマインダーを設定」する方法で使っている。書式が難しい /remind コマンドよりずっと使いやすい。自分自身への DM にリマインドしたい内容を走り書きして、そのメッセージにリマインダーを設定したりする。パブリックチャンネルに誰かが書いたメッセージにリマインダーを設定したりもする。 たくさんのメッセージにリマインダーを設定していると /remind list コマンドで一覧表示したときどれがどれだかわからくなって不便。 そこでメッセージ本文を展開して一覧表示する Slack アプリを作った。 /expanded-reminders というコマンドで呼び出せるようにした。やってみたらこれがなかなか便利。 Complete ボタンもつけてみた。 やりたいことがはっきりしていたので、Slack API のドキュメントをあちこち読みながらとに
Rails Developers Meetup 2018: Day 1 で『Quipperにおける「関心の分離」の歴史』という発表をしました - @kyanny's blog
発表で使ったスライドはこちらからどうぞ。発表前にスライドを公開しようとして、エクスポートした PDF / .pptx を Speaker Deck と SlideShare にアップロードしたら変換エラーになってしまい、苦肉の策で GitHub リポジトリに置いたりしてみたのですが、 Google スライドで作ってるんだから単にリンクを共有するだけで良かった。とはいえ変換エラーは気になるので、解決方法を知っている方がいたら教えてください。 docs.google.com ご視聴いただいた皆さま、ありがとうございました。持ち時間を使い切ってしまい、質疑応答の時間が無くなってしまいました。すいません。しばらくの間 ama をチェックしようと思っていますので、質問があればコメントください。 @kyanny に直接質問いただいても構いません。 主催・スタッフの皆さま、ありがとうございました。今回が
はあちゅう童貞セクハラ問題私的まとめ - @kyanny's blog
以下、「受け手が不快と感じたらセクハラ成立」という前提に基づく。 岸氏のはあちゅうに対する言動はセクハラ。なぜなら受け手であるはあちゅうが不快だったと言っているから。 はあちゅうの童貞に対する言動もセクハラ。なぜなら受け手である全国の童貞および元童貞の皆さん（俺含む）が不快だったと言っているから。 突然わいてきて「童貞は努力が足りない、ソープへ行け」とか言い出す人たち*1の童貞に対する言動もセクハラ。努力とかセクハラの話と関係ねぇだろ。炎上案件のドサクサに紛れて便乗セクハラ発言を繰り返して悦に入ってる奴らは人間のクズ。できれば社会的に抹殺されてほしい。 *1:http://kyoumoe.hatenablog.com/entry/20171219/1513682196 とか http://kyoumoe.hatenablog.com/entry/20171220/1513706633 とか
Ruby で JSON を SAX っぽく読む - @kyanny's blog
JSON::Stream というライブラリがあった。 github.com 181MB の JSON ファイルをちょっとずつ読んでパースさせてみて、メモリをどのくらい使うか試してみた。比較用に yajl-ruby でパースするのもやってみた。 たしかに省メモリだけど、だいぶ遅い。 yajl-ruby はこれと違って、 mongoexport の –jsonArray オプション無しが出力するような、 JSON オブジェクトが一行ごとに書いてあるようなファイルを省メモリに読むのに向いているようだ。 citylots.json のような単一の巨大な JSON オブジェクトないし Array の場合は、結局パース後のデータは全部丸ごとメモリに載せる必要がある。 昔に仕事で外部のシステムとそこそこの量のデータを毎日ファイルを介して連携するプログラムを書いたことがあった。 CSV にすると将来フォー
理想的なコードレビュー - @kyanny's blog
理想的なコードレビューとはどういうものだろう。前提として、 Git のよくあるワークフローで常識的なサイズのトピックブランチを、 GitHub か似た何かの Pull Request 的なビューの単位でレビューする、とする。 無言、または LGTM や :+1: など、「ちゃんとレビューしたよ、オッケーだよ」というシンプルな意思表示のみでマージに至るものは理想的に思える。レビュアーの「自分だったらこう作る」という設計・実装イメージとレビュイーの「自分はこう作った」という設計・実装がほとんど違わない、もしくはレビュアーのイメージとは違うけども納得できる結果になっている、よってコメント不要、なのだといえるからだ。 これを理想だとすれば、なんであれコメントがつくのは理想的ではない、ということになる。レビュアーとレビュイーの見解・実力に差があり、それが設計や実装の欠陥を指摘するコメントや、逆にコー
2016年を振り返る - @kyanny's blog
毎年恒例の。 2015年を振り返る - @kyanny's blog Look Back 2014 - @kyanny's blog Look Back 2013 - @kyanny's blog Look back 2012 - @kyanny's blog 2011年を振り返る - @kyanny's blog 2010年を振り返る - 刺身☆ブーメランのはてなダイアリー 2009年を振り返る - 刺身☆ブーメランのはてなダイアリー 仕事 2016年は仕事に追われた一年だった。受験サプリを Quipper プラットフォームへ移管するのが一番大きな仕事だったが、移行当日に体調不良でぶっ倒れてしまい、肝心の移行作業中は自宅で床に臥せっていた。情けない。吐くほど具合が悪くなることは年に一度あるかないかで、なぜあのタイミングだったのか未だに不思議だ。 その後も雑多な仕事に終われる日々が続いたが
「はてなブログ大賞2016」の選者になりました - @kyanny's blog
ご縁があって、「はてなブログ大賞2016」という企画で“推しエントリー”を選ばせていただきました。 blog.hatenablog.com はてなブログの企画にお声がけいただくのは、「はてな エンジニアブロガー祭り」以来です。もう三年も経ったとは...。 私がイチオシに選んだエントリーは...「はてなブログ大賞2016」をご覧ください！ ちなみに、イチオシが他の選者の方とかぶったときに備えて次点に選んだエントリーは「結婚披露宴の写真を頼まれても、お断りする理由がある - 紺色のひと」で、コメントは、 いわゆる「カメラ女子」と対決、もとい、さりげなくフォローにまわったエピソードが印象に残りました。かくいう私も友人の結婚式の写真撮影を引き受けたことがあるのですが、デジタル一眼レフカメラを買ったばかりで写真撮影の基本的な知識も無い素人には荷が重すぎました。幸い、友人はプロの写真撮影も手配していた
Gmail で GitHub の通知メールのパーマリンクをキーボードから開く Chrome 拡張 - @kyanny's blog
GitHub の通知を Gmail で読んでいると、view it on GitHub というリンクをクリックして URL を開くことがしばしばある。キーボード操作で完結したくなったので、 Chrome 拡張を作った。 github.com 2017/10/13 更新 Chrome 拡張ではなく Tampermonkey Script で書き直して Greasy Fork で公開した https://greasyfork.org/ja/scripts/34099-open-github-url-for-gmail 使い方 1. Gmail Labs から「カスタム キーボード ショートカット」を有効にする 2. 「[移動] メニューを開く」のキーボードショートカットを v 以外のキーに変更する 3. Gmail で GitHub からの通知メールのスレッドを開いた状態で v キーを押す す
Solarized Light / Dark themes for Quiver - @kyanny's blog
I made Solarized Light / Dark themes for Quiver. github.com I've used Solarized themes sometimes in my favorite editors (Vim, Emacs and RubyMine). I like it. Now I'm using Quiver, so why not use Solarized? Unfortunately, Solarized themes didn't exist for Quiver. Fortunately, Quiver allows me to make custom theme, and Solarized makes its color scheme public, so why not create theme? It was a really
げんしけん 125 話 126 話 考察 - @kyanny's blog
げんしけんの 125 話と 126 話について、斑目と咲がくっついて欲しい派の立場から考察する。ネタバレなので単行本派の方は読まないことをおすすめ、もしくはいますぐアフタヌーン買って読みましょう。 ネタバレ回避のために少なくとも単行本 20 巻の続き（122 話）が掲載されている 2016 年 5 月号は読んでおいたほうがよい。 アフタヌーン 2016年5月号 [2016年3月25日発売] [雑誌] 作者: 岩明均,竹谷隆之,萩尾望都,ひぐちアサ,木尾士目,新海誠,山口つばさ,沙村広明,芝村裕吏,キムラダイスケ,いとまん,北道正幸,草水敏,恵三朗,榎本俊二,西尾維新,チョモラン,幸村誠,朱戸アオ,藤沢数希,井雲くす,ヤマシタトモコ,高橋ツトム,市川春子,ほづみりや,五十嵐大介,安彦良和,清家雪子,横山キムチ,白乃雪,瀧波ユカリ,端野洋子,芦奈野ひとし,篠房六郎,庄司創,西本英雄,カラスヤサ
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
Atom実践入門 - @kyanny's blog
著者の id:tomoya さんから本をいただきました。ありがとうございます。 d.hatena.ne.jp 宣伝に偽りなし。 Atom の操作方法から内部構造まで丁寧かつ徹底的に解説した一冊だ。 Chrome DevTools しかり、 Web Components しかり、 2016 年に書籍で読む価値のある Web 技術の話であり、それぞれ単体で一冊の本になってもおかしくないトピックだ。それをテキストエディタの解説書でカバーしてしまう発想には脱帽する。 本題のテキストエディタの解説部分も抜かりない。まず目次からしてひと味違う。操作の名前（日本語）と対応するコマンド名（英語）が併記されているので、目当ての操作を見つけたらコマンドパレットにコマンド名を入力してすぐに使うことができる。さらに各項目の解説ページにはそのコマンドを呼び出すデフォルトのキーバインドも掲載されているので、メニューか
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
クローン病患者が MYCODE の遺伝子検査を受けてクローン病の発症リスクを調べてみた - @kyanny's blog
自分は十数年前からクローン病を患っており、現在も治療中の身なのだけど、以前から「遺伝子検査を受けたらクローン病の発症リスクはどのくらいと出るんだろう」とずっと気になっていた。先日 MYCODE が 40% オフキャンペーンをやっていたので、申し込んで検査を受けてみた。 なお、 MYCODE の説明事項において、 本検査結果に示される病気の発症リスクや体質の情報は、個人のリスクを示すものではなく、特定の塩基配列に関する統計的な確率を相対的な数字として表したものであり、特定の塩基配列を持つ集団の平均的な傾向及びリスクです。さらに、環境要因や生活習慣等、他の要因によっても大きく左右され得ます。お客様ご自身の健康状態・体質そのものを示すものではありません。 と説明されており、自分はこれを読んで内容について理解・同意しているので、自分の遺伝子に対するクローン病の発症リスクが高いとでようが低いとでよう
Jenkins のジョブを外部からビルドするには API Token を利用する - @kyanny's blog
Jenkins 1.594 にて確認。 Jenkins の認証ありの場合 「セキュリティを有効化 / Enable security」にチェックを入れている場合。 認証必須環境におけるJenkinsのスクリプトトリガーによるビルドの実行 - そんなこと覚えてない そして Authenticating scripted clients - Jenkins - Jenkins Wiki にあるように、Jenkins のログインユーザー固有の API Token を使って BASIC 認証し、 $JOB_URL/build に POST リクエストを送ればよい。 API Token はユーザー設定ページというものがあり、そこから取得できる。 ログインユーザーのユーザー名が kyanny で API Token が xxxxxxxx だとすると、 $ curl -X POST -u kyanny:
curl(1) で POST する際の --data と --form の違いについて - @kyanny's blog
調べてみた。動作確認用のサーバは plackup で立てている。 app.psgi の中身は一番最後に。 --data (-d, --data-ascii) application/x-www-form-urlencoded 形式で POST する。 @/path/to/file のように value の先頭が @ ではじまっているとファイルを読み込んで改行文字を取り除く。パラメータや @ つきで指定したファイルの中身はすべて URL エンコードされていることが期待される。つまり curl(1) は URL エンコードしてくれない。 -d を複数回指定するとすべてのパラメータが & で連結される。 @ でファイルを指定する場合、 -d 'file=@sale.txt' のようにすると中身が展開されないので注意 (file=@sale.txt という文字列が渡される) $ curl -d '
FORM 要素の accept-charset 属性について - @kyanny's blog
以下の HTML があるとき、 <!doctype html> <html> <head> <meta charset="utf-8"> </head> <body> <form action="http://localhost:9292" method="post" accept-charset="shift_jis"> <input type="text" name="key1" value="ほげ"> <button>submit</button> </form> </body> </html> このフォームを提出すると、ユーザエージェントはサーバに対し "ほげ" を Shift_JIS エンコーディングで送信するはずであり、実際そのようになる。 この挙動が、どの仕様のどの箇所に基づいてそうなっているのか、いまいちよくわからない。 accept-charset 属性の仕様は http
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
最近思ったこと - @kyanny's blog
コードレビューするときに考えること 開発チームもコードベースもプロジェクト規模も大きくなってきたので、もはや実装上の設計の細かい点まで指摘することが難しくなった。個人的な趣味で、自分が直接関わっていないプロジェクトの issues も全部眺めているが、それでも内容を把握しきるのは無理。なので、コードそのものに対する指摘は少なくなり、その代わりに「第三者があとでこのコードを見たとき、意味がわかるだろうか」と考えて、わからなそうだなと思ったらたとえ自分には意図が理解できたとしても「意図がわからないのでコメント書いてくれ」とか指摘するようになった。コードレビューをしているのに、コードレビューをしていない人の気持ちになる、みたいな感じ。ちょっと幽体離脱っぽい。違うかもしれない。 仕事のやり方について考えること 一般に、能力が高い人ほど仕事が増えがちだし、責任感の強い人ほど仕事を抱えてしまいがちだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wantedly Open API を試してみた - @kyanny's blog
