2019年08月10日
pixivFANBOXのクリエイター優待 で
毎月支援していただいている皆様、本当にありがとうございます。
バロンへの思い入れ
前職、spice life時代には、好きな椅子を何でも一つ購入できるという制度があり、覚えているだけでも社内にアーロンチェア、エンボディチェア、バロン、コンテッサがありました。
それらオフィスチェアのなかでも、僕の身体にはバロンがしっくりくるようで、いずれは自宅にもバロンを……という目標をその頃から立てていました。が、いわゆる高級オフィスチェアなのでなかなか手が出ずにいました。
そこにpixivFANBOXでのクリエイター優待としてオカムラのオフィスチェアを購入できるようになり、ついにこの時が！となったものの、公開当初は50人以上の支援がないと利用できず、僕は対象外で悔しい思いをしたものです。
そして、今自宅で使っている椅子は、どこで買ったのかも覚えていない1、上京したとき購入したものです。座面はへたってほぼ板、というかネジか何かが座面に飛び出している、軋みがうるさい、腰が痛くなる……4年ちょっと使っている安物なので、こんなものでしょう。しかしストレスが溜まっていきます。
(部屋が汚ない)
そんなタイミングで、冒頭にあるようにOKAMURAのオフィスチェア優待が10人以上の支援者からでも申し込み可能と知ったときの嬉しさったらありません。
届いた
8月1日に申し込んで、8月9日に自宅に届きました。
(部屋が汚ない)
最高の座り心地ですね。やはり良い椅子は良いです、ありがとうpixivFANBOX。ありがとう支援者の皆さん。重ねて御礼申し上げます。
旧椅子の処分
さて、注文時のオプションに「椅子引き取り」というものがあり、使用中の椅子を引き取ってくれるとのことで、これを有効にして注文しました。
しかし配送の方には「そんなのは聞いていない」と言われてしまい、アレ～となりました。注文確認メールにはしっかり「椅子引き取り」のオプションが有効になった状態になっている2のですが……まあ配送の方を詰めても何もいいことはない3ので、そのまま帰っていただき、こちらで処分することにしました。
我が家には2週間に1回くらいのペースで廃品回収のチラシが来るのですが、ある程度の見積りは書いてあるものの、やはり呼んでから法外に請求されるのは怖いので、行政の廃品回収をお願いすることにしました。行政だと値段が事前にわかるので最高、安心ですね。
そのかわり、狭い部屋に二脚の椅子でより狭いという状況がしばらく続きそうです。
2019年08月06日
OpenAPIによる定義から実装を生成したいニーズはあり、その方法は存在します。
「スキーマファースト開発」という言葉もあるように、一般的にはREST API schemaを定義してから実装にとりかかります。
しかし、様々な事情で「既存のREST API実装に対してOpenAPI schemaを記述したい」というニーズがあります。
例えばRailsの config/routes.rb の内容から OpenAPI の paths に相当するYAMLやJSONを出力するようなgemがあると助かるのですが、rubygems.org を “openapi” で検索してもそれらしいgemは見当りませんでした。
なので、そういうgemをつくりました。
実装にあたって
※ 以下、特記していない場合には Rails v5.2.3 時点のコードになります。
実装にあたって、まず参考にしたのがお馴染み bin/rails routes の処理になります。このとき何が行われているのでしょうか。
bin/rails routes で実行されるコードは以下です。
# frozen_string_literal: true
require "optparse"
desc "Print out all defined routes in match order, with names. Target specific controller with -c option, or grep routes using -g option"
task routes: :environment do
all_routes = Rails.application.routes.routes
require "action_dispatch/routing/inspector"
inspector = ActionDispatch::Routing::RoutesInspector.new(all_routes)
routes_filter = nil
OptionParser.new do |opts|
opts.banner = "Usage: rails routes [options]"
Rake.application.standard_rake_options.each { |args| opts.on(*args) }
opts.on("-c CONTROLLER") do |controller|
routes_filter = { controller: controller }
end
opts.on("-g PATTERN") do |pattern|
routes_filter = pattern
end
end.parse!(ARGV.reject { |x| x == "routes" })
puts inspector.format(ActionDispatch::Routing::ConsoleFormatter.new, routes_filter)
exit 0 # ensure extra arguments aren't interpreted as Rake tasks
end
https://github.com/rails/rails/blob/v5.2.3/railties/lib/rails/tasks/routes.rake
ここでの本質は
inspector = ActionDispatch::Routing::RoutesInspector.new(all_routes)
puts inspector.format(ActionDispatch::Routing::ConsoleFormatter.new, routes_filter)
の2行でしょう。
では、 ActionDispatch::Routing::RoutesInspector は何でしょう。
##
# This class is just used for displaying route information when someone
# executes `rails routes` or looks at the RoutingError page.
# People should not use this class.
class RoutesInspector # :nodoc:
def initialize(routes)
@engines = {}
@routes = routes
end
...sinp
https://github.com/rails/rails/blob/v5.2.3/actionpack/lib/action_dispatch/routing/inspector.rb#L54-L127
はい、private API ですね。
この RoutesInspector に適切なFormatterを渡して、routesの結果を整形すればよさそうです。
では ActionDispatch::Routing::ConsoleFormatter を見てみます。
class ConsoleFormatter
def initialize
@buffer = []
end
def result
@buffer.join("\n")
end
def section_title(title)
@buffer << "\n#{title}:"
end
def section(routes)
@buffer << draw_section(routes)
end
def header(routes)
@buffer << draw_header(routes)
end
def no_routes(routes)
@buffer <<
if routes.none?
<<-MESSAGE.strip_heredoc
You don't have any routes defined!
Please add some routes in config/routes.rb.
MESSAGE
else
"No routes were found for this controller"
end
@buffer << "For more information about routes, see the Rails guide: http://guides.rubyonrails.org/routing.html."
end
private
# ...snip
https://github.com/rails/rails/blob/5.2.3/actionpack/lib/action_dispatch/routing/inspector.rb#L129-L185
RoutesInspectorと同様に(明記されていませんが)これもprivate APIでしょう。
少し下に /rails/info/routes で使用される HtmlTableFormatter も定義されており、それと見比べると、 result、 section_title、 section、 header、 no_routes を定義した独自のFormatterを作成すればよさそうに見えます。
OpenAPI v3 の記法
さて、 OpenAPI v3 では、以下のような記述をするよう、仕様で定義されています。
openapi: 3.0.2
info:
title: example
description: OpenAPI example
version: 0.1.0
servers:
- url: http://api.example.com/v1
description: example server
paths:
/users:
get:
summary: get users
description: Return all user list
responses:
'200':
description: users json
content:
application/json:
schema:
type: array
items:
type: string
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md
これらの定義のうち、 paths 以下のいくつかについては、 config/routes.rb から自動生成できそうです。
なので、以下のようなFormatterを作成すると、それらしい定義を生成できます。
module ActionDispatch
module Routing
class OpenAPI3Formatter
def initialize()
@view = nil
@buffer = []
@openapi_structute = {
'openapi' => '3.0.0',
'info' => {
'title' => '',
'description' => '',
'version' => '0.1.0'
},
'paths' => {}
}
end
def section_title(title)
end
def section(routes)
routes.filter do |r|
!r[:verb].empty?
end.each do |r|
@openapi_structute['paths'][r[:path]] ||= {}
@openapi_structute['paths'][r[:path]][r[:verb].downcase] = {}
@openapi_structute['paths'][r[:path]][r[:verb].downcase] = {
'summary' => r[:name],
'description' => r[:reqs],
'responses' => nil
}
end
end
def header(routes)
end
def no_routes(*)
end
def result
YAML.dump @openapi_structute
end
end
end
end
https://github.com/unasuke/openapi3_definition_generator-rails/blob/3973f11c50a1ccdc69c1d97fce502222ecd92870/lib/openapi3_definition_generator/rails/openapi3_formatter.rb
gemify
そして、それをgemにしたのがこれです。
https://github.com/unasuke/openapi3_definition_generator-rails
使いかたはREADMEにあるとおり、Gemfileに追記して bundle installした上で、 $ bin/rails openapi3_definition:generate_yaml
雑に表参道.rbで話したのが、これです。
上で述べたように、内部でPrivate APIにしっかり依存しているので、いつ動かなくなるかは保障できず、そのため Rails v5.2.3 以上 v6 未満でしかインストールできないようになっています。Pull Requestは大歓迎です。
今後
今後、実装するとしたら
くらいと、あとは表参道.rbでもアドバイスを頂いたように、Rails本体への機能追加も考えています。
2019年07月08日
経緯
そして
絶対に嫌シリーズ
独身男性の皆さん買いましょう
2019年06月25日
経緯
2018年10月頃のgroup buyから積みっぱなしになっていたFortitude60を、重い腰を上げてようやく組み立てました。
発端は、友人の @nikuzuki_29 が職場で布教された結果「自作キーボードを組んでみたい」という気持ちになり、では僕も、とスイッチ、キーキャップを揃えて組み立てることにした、という流れになります。
構成
- Foritude60 Group Buy (ガラスエッジ)
- Gateron Silent Brown
組み立て
肉好きが初心者であることから、一日中遊舎工房のフリースペースを使うつもりで早起きして秋葉原に行き、組み立てを開始しました。(事実、閉店まで居ました)
僕も久々の半田付けであることから、まずはmeishiを各々組み立てて慣れておく作戦をとったのが良かったです。
遊舎工房で1日かけて組み立てたのですが、その場でArch LinuxからFirmwareを焼こうとするとエラーになってしまいました。レンタルスペースで焦っていたのもあったのでその場での解決は諦めましたが、帰宅後プルリクを出しmergeされました。
CとHを取り違えたので、若干ヒビが入ってしまいました。
トラブル
右手側が全く反応しません。テスターを買ったので、追い追い時間を見つけて調査と修正、あるいは再度購入をしていこうと思っています。
これから
適当なTai-HaoのキーキャップとBlank keycapsを購入したのですが、キーごとに高さが違う構成なので、PimpMyKeyboardで改めて好みのを買おうと思っています。またTRRS、USBケーブルも味気ないので買おうかなと考えており、沼感が出てきました。
2019年05月11日
v1.10.3からのdiffはこちらです。
https://github.com/itamae-kitchen/itamae/compare/v1.10.3…v1.10.4
Changelogs
Suppress Ruby warnings
RUBYOPT=-w を指定したときに出る警告を修正するもの。
これは v1.10.3 にmergeされている Add integration test with itamae local command で、test filesを列挙する正規表現が誤っていた問題を修正するもの。 これで 0 examples → 139 examples になりました。よかったですね。
このあたりはpull req authorのpockeさんがブログに書いてくれていますね。メンテナとして気付けなかった僕達のミスでもあります。ありがとうございます。
Itamaeのテストを壊してしまっていた話 - pockestrap
itamae docker コマンドに --tag オプションを指定した場合、成功したときのmessageにtagも表示するようにしたもの。
itamae docker コマンドのhelp messageに --tag オプションの説明を足したもの。
2019年04月30日
セトリ
- Flying Out (Extended Mix) - M.I.K.E. Push
- Black Mirror (Extended Mix) - James Dymond
- Kick Back (Original Mix) - Ashley Smith
- Fight My Way feat. Moses Keenan (Extended Mix) - Morgan Page, Moses Keenan
- With You feat. Emelie Cyreus (Progressive Extended Mix) - Magnificence, Venomenal, Emelie Cyreus
- Never Say Never (Extended Mix) - SICK INDIVIDUALS
- Turn Back Time (Original Mix) (Original Mix) - 3D Nation
- Burn (Original Mix) - DallasK, KSHMR
- We Are the Sound (Original Mix) - Betsie Larkin
徐々にテンションが上っていく感じの曲順になるようにやってみましたが、総評としてはパリピでしたね。精進します。
遅刻
イベント自体は3月末にあったので公開がとても遅れてしまいました。
今回、高専DJ部の開催スケジュール的に平成最後の開催となるので、IMAP++とのコラボを持ちかけたらなんと実現してしまいました。
Webサイトもmazcoさんに特別にデザインしてもらったりと、本当に記念となる回にできたかなと思います。
また、 #unasukefmのために購入したZOOM H4n Proで録音したものを内々に共有したりもしました。冒頭のmixcloudはそこから切り出したものになります。
2019年04月22日
4/15からの1週間、福岡のConference Weekで何をしてきたのかという日記です。
#unasukefm 収録
カンファレンス開始前の15日には、GMOペパボで @udzura さんを相手に #unasukefm の収録を行いました。
ハッシュタグ #unasukefmの様子を見るに、皆さんに楽しんでいただけたようでなによりです。
実はudzuraさんを相手に収録をしたいというのは、Railsdm PodcastがunasukefmとしてSeason 2を開始したときからほとんど決まっていたようなものなのです。達成でき、HaconiwaやCloudNativeの話ができてよかったです。
CloudNative Days Fukuoka 2019
そして1番目のカンファレンス、CloudNative Days Fukuoka 2019に参加しました。
ここではKubernetesだけに留まらない、CloudNativeな技術に関する様々なトークを聞くことができました。特に僕が今課題を感じている点である、秘匿情報の管理についてVaultを使うケースを知れたのはよかったです。
懇親会でも、福岡でしか会えない方々をはじめ、Rubyコミュニティとはまた違うCloudNativeなコミュニティの方々とお話しすることができました。
RubyKaigi 2019
次に、1日挟んで迎えたRubyKaigi 2019です。挟んだとは言ったものの、僕は今回(も)helperとしてお手伝いする立場なので、17日も1日中設営作業をしていました。
https://photos.app.goo.gl/svaNw2jvBtzusJ259 ← 様子を軽くまとめました。
今回はネットワーク斑としてケーブルの敷設、同時通訳レシーバーの受け渡し、スピーカーへの同時通訳打ち合わせ案内などを主に担当しました。英語が咄嗟に出てこない&聞きとれないのがまだまだ課題として感じられる3日間でした。
今になっても、「ああ、良かったなぁ」というふんわりとした感想しか出てきません。
2019年03月24日
participating notification
皆さんは https://github.com/notifications/participating を普段どれだけ見ていますか。僕はこの機能をよく使うのですが、集中していたりすると見に行くのを忘れて、コメントされているのに返事をしそこねてしまったまま長い時間経ってしまうということがしばしばありました。
要件
push型の通知であること
こっちからアクセスしに行かなくても、「未読がこれだけあるよ」と教えてほしいわけです。
即時的でないこと
とはいっても、コメントされて数秒で通知が来る、という即時性は求めていません。なぜなら、例えば社のリポジトリに関することであれば、GitHubのコメントやmergeをSlackに流しているからです。コメントの応酬はそっちで見れます。
https://slack.github.com/
ユースケースとしては、「出社してまず見る」とか、「集中してて気づかなかったけどあのpull reqにコメントついてるっぽい」だとか、そういうのを求めていました。
GitHub notification reminderをつくった
https://github.com/unasuke/github-notification-reminder
これをheroku schedulerで定期的に叩くことによって、このように通知させています。
Deploy to herokuボタンを作ったので同様の問題にお困りの方はご活用ください。
困っていること
GitHubのREST API v3でNotificationsを取得するendpointとresponseは以下URLの通りです。
https://developer.github.com/v3/activity/notifications/#list-your-notifications
ここで、通知の対象であるissueやpull requestの情報を見ようとすると、subject.url がそれっぽいなということになります。しかしよく見ると、domainが api.github.com になっています。例としてdocumentに載っている https://api.github.com/repos/octokit/octokit.rb/issues/123 ですが、ここにweb browserからaccessすると、JSONが返ってきます。この中に、html_url として、human accessableなURLが入っています。
これ、しんどくないですか。いわゆるGraphQLが解決しようとした、RESTによるN+1の実例じゃないか！となりました。そしてGraphQL API v4にはまだNotification Objectは来ていないのですね。
この件、supportに投げたのですが、僕の英語力が未熟なのか、「 https://developer.github.com/v3/pulls/#get-a-single-pull-request を使うといいよ」と返事が来ました。そういうことなのでしょう。
ただ、get-a-single-pull-requestしようにも、responseの中にissueやpull requestのnumberが単体では含まれないので、二進も三進も。(このscriptではgsubでhtmlを組み立てています)
こういう書き捨てのscriptのreadmeを頑張ることについて
よしいっちょブログに書くか〜となり、そんならREADME.mdを整備しておかないと「映え」ないなとなって、heroku appならdeploy to herokuボタン欲しいよなといろいろとmeta dataをつくっていて、正直面倒なんです。
じゃあなんで書くかというと、codeにcommentを書くように、あとで見る自分のためなんですね。未来の自分が環境構築するときに困らないように、という目的があるのかなと思いました。
2019年02月15日
経緯
一言で表わすと、「ノリと勢い」で始まりました。
音質改善の足しに、とKyashで投げ銭をしたのをきっかけに、あれよあれよと話が進んで、いつのまにかRailsdm podcast Season 2として unasuke.fm をやることになりました。
Season 2 episode 1
まずepisode 1として、onkさんをゲストに収録を行いました。以下から聞くことができます。
ジングル
KORG Gadget for iOSで作成しました。カルパスさんから頂いたふんわりとしたイメージをもとに作ってみました。
上のはイントロで使ったshort verで、アウトロで使用したlong verは以下です。
機材
そもそも始めたばかりのpodcastでrebuild.fmレベルの環境・質を実現することは現実的ではありません。
Podcasting Guide 2017 – Tatsuhiko Miyagawa’s Blog
それでも、これまでの収録を聴いて「もっとよくできそうなんだけどな」という気持ちになっていたのも確かです。
今回の収録では、僕がそのとき持っていた機材だけで収録を行いました。それらを以下にまとめます。
録音編
録音にあたって、今回は以下の機材を使用しました。
これはさっちんさんに教えていただいたものです。
購入してから自宅でのボイスチャットに使用していたものをそのまま持ち込んで録音しました。このマイクに関しては、普段の通話で問題になったことがなく(通話相手から何か言われたことがない、という意味)、それなりに安心して収録に臨めました。
収録ではマイクをUni(単一方向のみ集音)にして僕に向けていました。反対側にカルパスさんが居たのですが、カルパスさんの声が入ることがなく綺麗に音声を拾えていました。こちら側の音声についてはそれなりの質で収録できたのではないかなと思っています。
今回onkさんが京都に居るという都合上、Hangout経由で収録しました。そのため、2人が同時に発声しているタイミングだとどちらか(どちらも？)の声が抑えられてしまい、何を話しているのか不明瞭な部分ができてしまいました。これはどうしようもないですね。
また今後ですが、既にある機材の他にもHolyGrailさんの環境を参考に、以下の機材を用意するつもりです。
-
Shure SM58ボーカルマイクロホン
-
UR22 | Steinberg
- リニアPCMレコーダー
- SM58 * 2だと2人の収録しか想定しておらず、以前の複数人ワイガヤスタイルに対応できないため
- ワイガヤスタイルはやらないということもありえます
- SM58を活用するならZOOMやTASCAMの何かしらを購入したい、が高価
- キャリーケース
- 出先で収録、となったときに上記機材を裸で持ち運ぶのはやりたくない、また普段の収納としても……
機材に関してはキリがないので、あまり凝りすぎてもよくないでしょう。上記構成からさらに買い足していったり、上位機種への乗り換えなどはするつもりはありません。たぶんしないと思う。しないんじゃないかな。
機材構成に関しては、他のpodcastでの事例が探すと色々出てくるので、それらを参考にしてみるのもいいかもしれません。
podcastの運営に参加することになった結果、沼にはまっていっているように見えるかもしれませんが、オーディオインターフェースは既に所持していましたし、追加で欲しくなったのはPCMレコーダーくらいなものなので沼ではないです。
4月にどういう機材を手元に揃えているのかは誰にもわかりません。
編集編
録音した音声の編集は以下のような環境で行っています。
- FL Studio (on Windows 10)
- UR22 (前述)
編集環境に関してはこれ以上のupdateはするつもりはありませんし、してもあまり意味がないかなと思っています。
ただ、マスタリングにあたって、低音域と高音域を削るイコライザーはかませましたが、ノイズ軽減などは今回はしていません。それについては改善の余地があると思います。
今後
今後お話ししてみたい方々をカルパスさんと話して十数人ほどリストアップしています。1年くらいは続くと思います。
2019年01月30日
HolyGrail/kibela2esa: Kibela 2 esa.io
りゆう
やっぱりWIPっていいですよね。
どういうことをしているのか
- exportされたmarkdownを読みこむ
- exportされた画像を読みこむ(pathと名前だけ持っておく)
- 画像をesaにアップロードして、S3のURLを持っておく
- markdown内の画像URLをesaのS3 URLに置換する
- frontmatterなどの処理や整形した結果のmarkdownをesaに投稿する
できること
- 投稿した記事の移行
- 画像の置きかえ
- kibelaにアップロードされている画像のURLを、esaにアップロードした画像のURLに置換する
(まだ)できないこと
- kibelaの記事に書かれたkibela記事への参照をesaに移行した後の記事への参照へと置き換える
- 2-pass 処理が必要？
- もしくは依存関係を見るようにする (手間すぎる)
たいへんだったこと
- kibelaにAPIがない
- ユーザー一覧だったり、投稿の情報の取得が手間
- 全部ファイル内容をparseして取得する必要がある
- exportされたファイル形式がしんどい
まとめ
esaが好きです。
HolyGrail/kibela2esa: Kibela 2 esa.io