daisuke furukawaの投稿 - Crieit

2020年買ってよかったものと、買ったけど微妙だったもの

2020-12-13T15:34:50+09:00

2020年買ってよかったものと、買ったけど微妙だったものが良かったのでぼくもやってみる

微妙だったもの

Xiaomi Miband4 シャオミスマートウォッチ

タバタ式トレーニングをやるぞ、ということで心拍計として買ったのだけど、計測結果が信用ならない感じで、もう自分で数えればよくね？ってなった。色々工夫して使おうとしてたのだけど、結局どうにもならなかったので売却。

スマートスピーカー

ぼくの部屋につけて性能評価中なんだけど、明かりつけるのは壁スイッチで困ってないし、暖房とかいちいちswitchbotつけるの面倒だし、ということで、「音楽かけて」以外の用途がなくて、たんなるスピーカーになっている。それで十分といえば十分なんだけど。

良かったもの

スマートロック

Qrio Lock (キュリオロック) スマホで自宅カギを解施錠できるスマートロック Q-SL2

日々快適に動作していて、鍵を持ち歩かなくなった。

Fire TV Stick 4K

古いのはもっさり使い勝手が悪かったのだけど、新型はメモリもCPUも改善したらしく、サクサク動くようになった結果毎日使うようになりました。
YouTubeで動画見ながら運動しています。

靴

ついに靴とか服もAmazonで買うようになってしまった。3つ4つまとめて取り寄せて、気に入ったの以外は返品する。

返品しまくりになるのは抵抗感があったんだけど、Amazonがそうしろと言っているし、
Amazon.co.jp: 試着後の返品・送料無料: ファッション
慣れてくると試着とかせずに「この間の靴を再注文」ってやるようになるので、おそらく長い目で見ればAmazonも損をしてないのだと思う。

スティック茶こし

KINTO (キントー) 茶こし LOOP ティーストレーナーブラック

茶葉をこれですくって湯に入れるとお茶が飲める。一人二人だと急須で入れるよりこっちのほうが楽なので愛用しています

surface変換ケーブル

Surface Pro 充電ケーブル 15V PD充電対応 Surface Connect to USB-C充電

独自のコネクタを採用していて充電器が必要なsurfaceも、この変換コネクタをつかうことでUSB-C充電ができるようになりました。
力不足な充電器だとヤバそうな挙動を示すので駄目かと思っていましたが、窒化ガリウム採用のハイパワー充電器なら充電できる。

『飲むフランク』＆プレミアム生ハム

【ギフトボックス】肉汁ドバーっ！と『飲むフランク』＆プレミアム生ハム（熨斗付き）

食べチョクは開発に関わるとともに、生産者さんにお礼を言えるというシステムが面白いので普通にユーザーとしても使っている。
販売単位が大きすぎて二人暮らしだと持て余す商品も多いのだけど、フランク＆生ハムは、日持ちもするし毎日少しづつ使えるのでリピ買いになった。
生ハムはチーズと一緒にクラッカーに乗せてもいいし、サンドイッチにパスタに、活躍の場がいっぱいあるので家にあると便利です。

とてもよかったもの

動物マスク

狐（キツネ）｜動物マスク水野染工場

外出するたびにかわいいですねと声をかけられ、電車の中で向かいの子供が「ままー、パンダさん🐼」って言っているのが聞こえたりする、大人気マスク。ぼくがキツネでおくさまがパンダ着けています。

時節柄マスクは付けないわけにいかないので、こういうのをつけることでちょっとでも気持ちが明るくなればいいなと思っています。

いまだとクリスマスとか正月用マスクもあるよ。

イベントマスク水野染工場

Googleスプレッドシートでスクレイピング

2020-08-09T13:31:47+09:00

スクレイピングがやりたかったんだけど、サーバの管理がめんどくさくなったので、Googleスプレッドシートの上でスクレイピングを出来るようにした。

やりたいこと

献血で、400mlAB型の血液が不足してます、A型は今大丈夫です、みたいな情報が、献血センターのwebサイトに掲載されるようになった。
たとえば宮城県赤十字血液センターの今週の献血状況。AB型の人は成分献血にするか、次の機会にしたほうが良いらしい。

これ以外の県も、各県の献血センターに掲載されている
こういう情報をオープンにしてくれたのはとてもうれしいことなんだけど、webページに掲載されたって、ぼくらがわざわざ見に行かない限り気が付かない。できればこう、SNSで「今週の献血状況」みたいなことを発表してくれるといいよね。そしたら、「あ、AB型足りない？今週は余裕があるからじゃあぼく行くね」みたいなことが出来ていいと思うのよ。

ないなら作れの精神で、とりあえずWebページ上にあるデータを毎日取得して蓄積してみることにした。あとでグラフとか需要の波が見られたら面白そうじゃない？

でもそのためにサーバとか管理するのもなあ。もうちょっと気軽にやれる方法はないの？

GoogleAppsScript

Googleスプレッドシートには、GoogleAppsScript(gas)というスクリプト機能があって、JavaScriptでスプレッドシートのセルの値を読み書きしたり、ボタンを押すとメソッドを実行するようにしたりすることが出来る。
UrlFetchAppというライブラリがあってWebページをダウンロードすることも出来る。あと時刻を設定して指定した関数を起動したりする機能もある。ということは、タイマーで定期的にWebページを取得させることが出来る。サーバレスでスクレイピングができるとかなり嬉しい。

ただDomパーサーがないので、取ってきたHTMLは正規表現で切り出さないといけない。サーバの管理すらしたくない駄目人間にそれはちょっと厳しい。

ImportXML

スプレッドシートには、importXMLというメソッドがある。
これを使うと、URLとXPathを書くだけでそのページの該当箇所を取ってきてセルに入れてくれるすごいメソッド。

ただこれ簡単メソッドだけに色々問題があって、
・厳密にXMLとして解釈しようとするので、乱暴なHTMLのページは取得できないことが多い
・JSの解釈もしてくれないぽい
・XPath書くの面倒w
・取得タイミングが制御できない

最後のがわりと致命的で、キャッシュ制御がブラックボックスなので、ページが更新されても内容が更新されなかったり、予想されないタイミングでキャッシュが破棄されて内容が更新されていたりする。

現時点の内容がわかれば十分な用途には便利なんだけど、毎日データを取ってくるような用途にはちょっと使いにくい。

cheeriogs

cheerioは、jQueryぽい文法でHTMLをパースすることが出来るnode.jsライブラリ。ブラウザじゃなくてもjQueryぽくHTMLを解析できるので、スクレイピングのときに便利。
残念ながらgasにはサイズ制限があるので、npm install cheerio みたいに気軽に使うことは出来ないんだけど、代わりにつかえるgas library でcheerioを使えるようにしてくれた cheeriogs という神がいるので、これを使うとスプレッドシートのスクリプト内でもHTMLをパースして内容を取ってくることが出来る。これですべての材料は揃った。

実装

スプレッドシートのメニューからスクリプトエディタを立ち上げる。

リソース- ライブラリでライブラリ画面を開いて、cheeriogs に書いてあるIDを入力してcheerioライブラリをインポート。

あとは、こんな感じで書けばページの内容を取得できる。

const content = UrlFetchApp.fetch(url).getContentText();
const $ = Cheerio.load(content);
const title = $("title").first().text();
ret["title"] = title;
ret["description"] = $("meta[name='description']").first().attr("content");
ret["pref"] = title.replace("赤十字血液センター｜日本赤十字社","")
ret["demand_date"] = $(".center-main-today-timedate").first().text();
ret["demands"] = [];
$(".center-main-today-types-state").each((index, element) => {
   ret["demands"][index] = $(element).text();
})
:

まんまjQueryでしょ？

このあと、スプレッドシートに載っている前回の結果を右にずらして左端に今回の結果を追加したりする処理があるんだけど、そこはたんなるgasのスプレッドシート操作なので省略。

まとめ

cheeriogs をつかうことで、献血の需給状況をスクレイピングすることが出来るようになった。タイマーで毎日起動するようにしたので、現在は放置しておいても毎日夜中にその日の情報をとってきてくれるようになっている。

単なるスプレッドシートなので、条件付き書式(セルの色塗り)とかはスクリプトと無関係に出来てしまうのも便利。

gasはrubyでいうirbみたいな即時実行ツールがないし、デバッガも貧弱なので、そんなに開発体験が良いわけではない。
でも無料で使えるし、タイマーとか便利だし、なによりスプレッドシートという強力なアウトプット窓口を使えるので、サービスの管理画面なんかはこれで作るのもありだなあ、と思った。

あとはこれをtwitter botにすれば良いんだけど、例の感染症騒ぎで献血が逼迫した結果、今はどのエリアもみんな「成分献血：非常に困っています」しか出なくなってしまっている。この状況だと、献血を知っている人は献血したら次回の予約をして行く感じになっていて、Twitterで状況を知らせてくれると嬉しいとかいう感じじゃない。
今必要なのは、献血についてあんま知らない人が「えーそんな足りないの？」ということで献血にチャレンジしてくれることなので、この記事を見た人、ぜひご協力をお願いします。献血は不要不急じゃなくて必要なタスクです！

自分で散髪するノウハウ

2020-04-25T21:07:31+09:00

自分で散髪するノウハウの需要が高まってるので書いてみる。

変にならない？

この人見て変な頭だと思ったらやめておこう

思わなかったら、つまりこのノウハウは大丈夫ってことです。この髪型で10年生きてきて、変と言われたことはないのできっと大丈夫。
自分で切ってると言っても「わかんなかった」と言われているので、きっと大丈夫。

( これもし大丈夫じゃなかった場合ぼくの人生が10年分くらい否定されることになるから、こういうの書くのって勇気がいるよねw )

向き不向き

起用不器用はたぶん関係ない。そんな難しくないので。

それよりも、頭の形が凹んでたり歪んでたりする方は、自分でやっちゃうと頭の形がモロに出て目立つので、そういう方はプロに任せたほうがいいかも。頭の形に自信があれば一回やってみるのがおすすめ。
失敗しても一ヶ月くらいすればわかんなくなるし、最悪理髪店に戻っても損失はバリカン代数千円程度です。

用意するもの

パナソニックのバリカンカットモード

別に他のでもいいのだけど、安くて安定してるのでオススメ。数年は余裕で使えます。この御時世でちょっと手に入りにくくなってるけど、普段だと4000円弱で手に入ります。

あと100円ショップで入手すると便利なもの

ブルーシート

　下に敷いてから散髪すると、切った髪の毛の回収が楽になります。フローリングの部屋で切って掃除機かけるとか、新聞紙を敷いておいてそれごと捨てちゃうとか、人によって好みがあるらしい。

ホウキとチリトリ

　掃除用。ちゃんと掃除機かければいらないはずなんだけど、なんのかんのであると便利。

大きいハサミ, 鏡

　上級編で使います

初級編

カットモードには12mmのアタッチメントが付いてるので、これでバッサリやっちゃえば丸刈りになります。慣れるまではこれで行きましょ。

中級編

全体を12mmでカットした後、耳とか後ろの、いわゆる裾部分だけ9mmで刈直しておくと髪の毛がうっとおしくならないし、丸刈り感が薄れていい感じになります。

上級編

おでこの部分だけバリカンかけずに残しておいて、鏡を見ながら水平に整えると、冒頭の写真の髪型になります
バリカンした部分とのつなぎ目が難しくて、うえの写真だってよーく見ると変なんだけど、案外ばれないです。

まとめ

妹の結婚式の時、何年かぶりに理髪店に行ったら、「なんか変わった髪型だなーと思いました。自分でやられてるんですね」と言われたので、プロが見ると自分でカットしてるのはわかっちゃうらしい。でもべつにそれが理由で叩き出されたりしなくて、普通に整えてくれたので、一回自分でやったら二度と理髪店に戻れないなんてことはないです。「自分でやったけどうまく行かないので戻ってきました。てへ☆」とか言っておけば大丈夫。

でも自分でできるようになれば予約も待ち時間も移動時間も不要になって、お店の人と何話していいか悩まなくていいし、コスパ圧倒的にいいので、ぜひお試しください☆

在宅ワークが二人いることに伴う諸問題とその対策

2020-03-28T11:50:27+09:00

ひと家庭で二人以上テレワークor在宅フリーランスの人がいるご家庭で、昼ご飯誰がどうするかとか、打ち合わせの時どうしてるかとか、どうしても入り込んでくる家や相手のアレコレをお互い負担なく過ごす工夫を知りたいこの頃
— 輝竜司（作業中）｜『蜘蛛ですが』2020年アニメ化！ (@citrocube) March 27, 2020

なるほどそういうことが悩みになるのか。

フリーランス夫妻歴10年のうちのケースを紹介します。

仕事部屋は必要

ふたりとも場所を選ばない仕事なのでわりと気軽に引っ越すことが出来て、よい仕事場所を求めて過去4-5回引っ越しを繰り返している。部屋があったりなかったりいろいろ試したんだけど、やっぱり仕事部屋は必要。

ないと、テレカン中に家族が入ってくるとか、ポモドーロが一個崩壊するなどの事故が起きる。逆に「仕事中だから声をかけるな」みたいな事を言ってしまうと、いつ声をかけていいかわからないので家族不和の原因になってよくない

例外として、高いタワーマンションでビジネスフロアがついているとか、近所のコワーキングスペースを定期契約してそこで仕事をすることにする手もある。でもそれは今回のテーマと外れるのでスキップ。

時間を区切る

うちでは朝食7:00、昼食12:00、おやつ15:00、夕食18:00と決めている。この時間前30分は仕事中でも割り込んで声をかけて良いルールで、「ご飯できたよー」って呼ばれたりする。
なのでこの時間にかぶりそうだったら、ポモドーロじゃなくてタスク整理をするとか、いっそ早い目にリビングに移動して食事の用意を手伝ったりする。

逆にそれ以外の時間仕事部屋にこもっていたら、それは仕事中なので原則声をかけないマナー。

食事作る人は決めておく

朝食と夕食はぼく、昼食はおくさまが作ることにしている。もちろん忙しかったり病気のときは随時交代するけど。

一人暮らし自宅で仕事だと、食事はぜんぶUberEatsとか、全食COMP みたいな極端な人もいて、それはそれで時間効率良さそうなんだけど、家族仲と健康と時間効率のバランスを考えた結果、せめて一日一食は野菜とか肉とかバランスの取れたものを食べたほうが良さそうということで、うちではお昼ごはんをそういうメニューにすることにしている。

朝と夜は軽食で、気が向いたときはネットで見つけた面白メニューを作ることもあるし、そうでないときはピザとかパスタとかそうめんとかシリアルが多い。あと神戸なので、週に一度は素敵なおみせでパンをかってきて食べる日もある。

ホットサンドメーカー楽しいよ? うちのはちょっと違うけど。 pic.twitter.com/ItgeWl0ID9
— もぎゃ(daisuke furukawa) (@mogya) January 21, 2020

神戸おいしいものが多すぎるので、「サラダと一緒に食べたら甘パンもサンドイッチと見なす」「おやつと合体すれば晩ごはんにケーキもあり」などの抜け穴を見つけるスキルが急成長している。ちなみに写真は夜アイスと合体した今日の晩ごはん😝 pic.twitter.com/UroJZA8KTC
— もぎゃ(daisuke furukawa) (@mogya) May 15, 2019

がっつりディ

今日はガッツリコード書くことに集中したい。食事で中断されたくない！という日は「今日はお昼食べないで外で仕事します」と宣言して外で仕事をすることにしている。近所のコワーキングスペースとか、ネットカフェとか。あと後述するスーパー銭湯とか。

お買い物の都合があるのでできれば前日までに宣言のこと、ということになっていて、このへんは共同生活ゆえに仕方ない制限かなと。最悪当日宣言でもどうにかならないことはないのだけれど、「家族仲を生贄に効率神を召喚」みたいな技なのであまり使いたくない。

お風呂ディ

近所にスーパー銭湯があって、ここには漫画とパソコンのフロアが用意されているので、ノートパソコンを持ち込むと仕事をすることも出来てしまう。おうちでしごとするのに飽きると「温泉行こー」ということでここで一日仕事をしつつ温泉入り放題の日を作ることもある。

まとめ

Twitterなどで、ひとり暮らししてコード書くのに全力投入している人を見ると羨ましいなあと思ったりするし、ある程度試してみたことはあるのだけれど、運動をサボると肩腰に来るし、食生活に手を抜くとだんだん体調が崩れていって結局集中できなくなったりするので、規則正しい生活をしていても、アウトプットできる量はそんなには変わらないのだと思う。

もちろん人によって家族によって何を快適に思うかはそれぞれ異なるので、うちの例がすべての家庭でフィットするわけじゃないのだけれど、なんかの参考になれば幸いです。

nuxt.jsプロジェクトをnetlifyで公開してredirectを使うときの罠

2020-03-06T09:34:49+09:00

3/6 11:15追記

サブディレクトリにあるときだけ発生する問題ぽい。問題をまとめてサポートに報告しました https://community.netlify.com/t/subdirectory-and-publish-directory-redirection/10120

netlifyにはnetlity.tomlという設定ファイルを書くといろいろ設定ができることになっていて、従来nginxでやっていたような各種リダイレクトも、ここに書くことで実行してくれることになっている。
Syntax for the Netlify configuration file

これと、nuxt.jsみたいにビルド結果をサブディレクトリに出力するツールが組み合わさるとちょっと予想しない対応が必要になる話。

ルートディレクトリに配置したnetlify.tomlにビルドとリダイレクトの設定を書く。

[build]
  base = "front/"
  publish = "dist/"
  command = "npm run generate"

[[redirects]]
  from = "https://gisyohub.netlify.com/"
  to = "https://gisyohub.com/"
  status = 301
  force = true

結果、ビルドはしてくれるのだけれど、リダイレクトは動かない。

ぼくの実験結果だと、同じファイルをコピーして、staticディレクトリにもnetlify.tomlを配置してあげると、ビルドする時dist/にコピーされて、その結果redirectが動作するようになる。

おそらくnetlifyは、ビルド時はルートディレクトリにあるnetlify.tomlを見るけど、リダイレクトのときはpublishディレクトリにあるnetlify.tomlを見ているらしい。実装の都合は何となく分かるんだけど、せめてドキュメントに明示してほしい感じ。

こことかここで話題に上がってるんだけど、バグとしては認めてもらえなかったぽい。
https://community.netlify.com/t/redirects-within-netlify-toml-not-working/1731
https://community.netlify.com/t/netlify-toml-folder-with-nuxtjs-and-netlify-cli/4659/3

シンプル再現環境を作ればバグだと認めてもらえそうな気がするんだけど、この問題のミニマム環境って何で作るのがいいのだろう。nuxtとかの開発環境なしに、index.htmlだけをnetlifyで公開するような構成って作れるのかな？

docker build中にVolumeの中身は参照することが出来ない

2020-03-03T16:09:10+09:00

railsの開発中に、ホストのrailsディレクトリをまるごとコンテナ内で参照してgemもここに入れちゃいたい、そしたらコンテナ作成のたびにbundle installし直さなくて済むし、みたいな需要があって。

volumes:
  - ./:/rails

みたいなことを書いて、dockerfile内で

WORKDIR /rails/
RUN bundle install -j4 --retry=3 && \ bundle clean

しようとすると、/rails/Gemfileが見えないからインストールが上手く行かない、というようなことが起こる。

よくわかんないんだけどbashで入って改めてbundle installすればインストールできるからまあいいか、みたいないい加減な運用をしていた。

んで、heroku環境で運用しようとすると、アクセスが来た時点でbundle installが走り出して、当然timeoutするのでコンテナが殺されて、あやふやな理解じゃだめだね、ということに気づいた。

dockerのvolumeはbuild中に中身を参照できない。

Dockerfileの中に書いたコマンドは、CMDとENTRYPOINT以外、buildのときに実行される。で、このタイミングでは、volumeの中身を読み書きすることは出来ない。
volumeはdocker runの時初めてマウントされる。なので、volumeの中のファイルに依存したコマンドを実行したり、volumeの中に書き込むようなコマンドは、docker run以降にしないといけない。

なんでかというと、docker buildコマンドに-vオプションがないから。
https://docs.docker.com/engine/reference/commandline/build/

つまり、volumeはそういう仕様なのだ。

docker build -v作ろうよ、というissueは過去何度か立ち上がっているのだけれど、こんな感じで却下されている

I think you'll find you get a lot of resistance to a build -v option. The docker team has been very opposed to flags which introduce non-reproducability between builds.
(私訳: build -vオプションには多くの抵抗があると思います。 Dockerチームは、ビルド間に再現性のないフラグを導入することに非常に反対しています)
https://github.com/moby/moby/issues/17745#issuecomment-236785473

そんなこと言ったらCOPYだって環境に依存して再現性がなくなる気がするんだけど。
とにかくそんな仕様で、build中に読み書きすることが出来ないので、/railsに読み書きしようとして失敗していたと。ふむ。

どうするのが良いか

開発環境だったら、起動後のbashからbundle installするか、CMDで起動するスクリプト内でbundle installする運用でも別に困らない。

本番だと、上で述べたようにherokuでアクセスが来てからbundle installがはじまる、みたいなことになるのは困るので、ちゃんとbuild時にbundle installを終わらせておく必要がある。
本番環境でソースを書き換えて即時実行なんて需要はないはずなので、ホストのファイルシステムをマウントするのではなくて、COPYでまるごとコピーするのが正解。
これはなぜかdocker build中でも実行できるので、必要なディレクトリを全部COPYしてbundle installすれば、build中でも実行することができる。

Dockerfile.production

WORKDIR /rails/
COPY . /rails/
RUN echo 'gem: --no-rdoc --no-ri' >> "$HOME/.gemrc"
ENV GEM_HOME /usr/local/bundle
ENV PATH $GEM_HOME/bin:$PATH
RUN gem install bundler \
  && bundle config --local path "$GEM_HOME" \
  && bundle config --local bin "$GEM_HOME/bin"
ENV BUNDLE_APP_CONFIG $GEM_HOME
RUN bundle install -j4 --retry=3 && bundle clean
CMD ["rails", "server", "-b", "0.0.0.0"]

dockerで本番環境と開発環境を使い分ける方法いろいろ

2020-02-22T10:10:40+09:00

dev環境とprod環境で別のDockerfile使うってできるのかなdev環境ではホットリロードしたいからspring-boot:runで動かしてるけど，本番は実行可能jarにして動かしたい🐳
— ysek (@uuusu_) January 25, 2020

よくあるよね。ちょうど今書いているプロダクトがいろいろ使っているので説明してみる

基本１：環境別のファイルを使う

希望：Dockerfile.developmentとDockerfile.productionみたいなのを用意して使い分けたい

docker build -f Dockerfile.development という具合にして指定することができる

http://docs.docker.jp/engine/reference/commandline/build.html

基本２：start.shで分岐

希望：毎回ファイルを指定するのめんどくさい。一個で実現できないの？

Dockerfileじゃなくて、最後に起動するstart.sh的なファイルの中なら、シェルスクリプトだから何だって書ける。

Dockerfile

：
CMD ["sh", "start.sh"]

start.sh

:
if [ "$NODE_ENV" = "development" ]
then
  # develop環境の処理
else
  # それ以外の処理
fi

冒頭の用途ならこれで十分な気がする。javaは知らないけど、たぶんdevとかprodcutionを指定する環境変数みたいなのはあるよね。

ただ、何でもかんでもstart.shにいれると、docker layer cacheが効かなくなってbuildの重いコンテナになってしまう。ライブラリのインストールみたいに重たい処理を切り替えたいときはDockerfileから分けたほうが良い。

docker-composeを使う

dockerと使い分けがよくわからないDocker-composeだけど、ちゃんと使うといろいろ便利な機能がある。ビルドするファイルを環境変数で指定できるのもその一つ

docker-compose.production.yml

  rails:
    build:
      dockerfile: docker/Dockerfile.production

こんな感じでproduction用のdocker-composeファイルを用意して

export COMPOSE_FILE=docker/docker-compose.development.yml

こんなふうに環境変数でファイルを指定しておけば、普段は、 docker-compose build という具合に、特に意識せずに使うことができる
buildとかrun程度の普段の用事ならdocker-composeで全部できるので、使い分けのことはあまり考えずに過ごせる。

おまけ：ディレクトリを整理する

この手の使い分けをすると、プロジェクトのルートディレクトリにやたらとファイルが散逸する問題が起きる

|-- README.md
|-- .circleci
|-- deploy.sh
|-- docker-compose.development.yml
|-- docker-compose.production.yml
|-- Dockerfile.development
|-- Dockerfile.production
|-- .env
|-- (他にもプロダクトのファイルがいっぱい)

気にしなければいいと言えばいいのだけれど、服装の乱れは風紀の乱れ、プロジェクトの破綻はこういうところからやってくる！という感じで気になる人は、サブディレクトリに片付けよう

docker関連ファイルをサブディレクトリに配置する

"Update your client software to continue using Let's Encrypt"

2020-02-04T14:05:06+09:00

Let's Encryptからそんなメールが来たあなた、さてはサーバソフトウェアの更新をサボっていますね？ぼくもです😀

これが来た人が何をしないといけないのかをまとめました。簡単に言うと certbot を更新しましょう

何言われてるの？

According to our records, the software client you're using to get Let's
Encrypt TLS/SSL certificates issued or renewed at least one HTTPS certificate
in the past two weeks using the ACMEv1 protocol. Your client's IP address was:

...

ここ二週間の記録によると、Let's Encrypt TLS/SSL 証明書を取るために使っているクライアント、ACMEv1 プロトコルを使ってるようです。IPアドレスはこれ

Beginning June 1, 2020, we will stop allowing new domains to validate using
the ACMEv1 protocol.
You should upgrade to an ACMEv2 compatible client before then, or certificate issuance will fail. For most people, simply upgrading to the latest version of your existing client will suffice.

2020/01/01から、ACMEv1プロトコルでのドメイン認証は停止されます。
ACMEv2を使うクライアントソフトウェアに移行しないと、証明書が更新できなくなります。大多数の人にとっては、単に使っているクライアントソフトウェアを更新すればよいはずです。

(訳注それ以外の人についての説明があるけど、そんな人はこの記事読まないので中略)

ACMEv1 API deprecation details can be found in our community forum:
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1

ACMEv1 APIの廃止についての詳細はコミュニティフォーラムで見ることが出来ます。
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1
(訳注廃止の進め方の話題なので、ぼくらが何をするかの説明は載ってないぽい)

どうすりゃいいの？

certbotを更新すればOKです。

ぼくの使っているCentOSだと

$ sudo yum update certbot
:
=================================================================================================
       Package                                       Arch                        Version                                                  =================================================================================================
Updating:
 certbot                                       noarch                      1.0.0-1.el7
 python-requests                               noarch                      2.6.0-8.el7_7    
:
  Updating   : certbot-1.0.0-1.el7.noarch      
Complete!

という感じでした。

certbotには自動更新のためのtimerがついているので、これを使っている人は念の為リロードしておきましょう

$ sudo systemctl daemon-reload

自分でcrontab書いた人は自前でなんとかしてね。せっかくcertbotがtimerを用意してくれているので、こっちを使うことをおすすめするよ。

動作確認

一回手動で動かしておけばいいかなと。

$ sudo systemctl start certbot-renew
$ sudo systemctl status certbot-renew
* certbot-renew.service - This service automatically renews any certbot certificates found
   Loaded: loaded (/usr/lib/systemd/system/certbot-renew.service; static; vendor preset: disabled)
   Active: inactive (dead) since Tue 2020-02-04 13:06:36 JST;
   Process: 27876 ExecStart=/usr/bin/certbot renew ...
   Main PID: 27876 (code=exited, status=0/SUCCESS)
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: Processing /etc/letsencrypt/renewal/oasis.mogya.com.conf
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: Cert not yet due for renewalbot-renew.timer
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: The following certs are not due for renewal yet:
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: /etc/letsencrypt/live/oasis.mogya.com/fullchain.pem expires on 2020-04-09 (skipped)
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: No renewals were attempted.
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: No hooks were run.
Feb 04 13:06:36 linode10.mogya.com certbot[27876]: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Feb 04 13:06:36 linode10.mogya.com systemd[1]: Started This service automatically renews any certbot certificates found.

こんな感じで、"Cert not yet"(期限がまだだから更新しなかったよ)的なログが出れば大丈夫かと思います。

心配な人は、expires on の日付にリマインダを仕掛けておいて動作確認しましょう

その他

　たまにルータなんかが勝手にLet's Encrypt にアクセスして証明書をとってくる仕組みになっているものがあるらしいです。
自分で証明書を取得した記憶がないのにこのメールを受け取った人は、この記事の対象じゃないので、ルータメーカーのサポートに相談するのがいいんじゃないかと思います。

Twitter Gemの現状と、メンテされていないGemを使い続ける方法

2020-01-15T22:20:27+09:00

まとめ

Twitter Gemがメンテされなくなっているので、自分が気になる不具合の修正を取り込んだ mogya/twitter-gem を作ったよ。

Twitter Gemの現状

RubyでTwitterAPIを使うには、sferik/twitter が定番になっています。gem install twitterして入るのもこのGemだし、Twitter開発者サイトでも紹介されている著名なGemです。

が、このライブラリは2018/6のコミットを最後にアップデートが行われていなくて、たくさんのPRが残ったままになっています。
もはやコードが完璧でいかなる修正も必要ないのであればそれでもいいのですけど、ぼくがさわった範囲でも結構困るような不具合があって、それに対する修正PRが出されているのだけれど、マージされないまま放置されているのが現状です。

OSSというのはそういうものなので、sferikさんを責める気は全然ありません。長い間メンテしてくださってありがとうございます。とはいえ、現に今TwitterAPIを使いたいのに不具合で動かないのは困る。

extended mode問題

例えば、tweet_mode=extendedにした時、textが取れなくなる。
Cannot retrieve text · Issue #813

client = ...
status = client.status(1216628579099766784, tweet_mode: "extended")
status.text
=> 
status.full_text
=>

tweet_modeは2017年ごろに導入された後方互換性のためのフラグで、最近のTwitterクライアントは、基本tweet_mode: "extended"で利用することが想定されています。それを付けて呼び出すとツイート本文が取れないという、かなり基本的な部分で困る不具合です。

当然複数の修正が提案されているのですが、どれもマージされないまま放置されてしまっています。

ぶっちゃけこの問題だけなら、PRのコードをコピペしてinitialize/twitter_patch.rbみたいなファイルに書いておけばごまかせるわけですが、今後もこのライブラリが更新されないということは、こいつのせいでRailsがアップデートできないとか、新しいRubyを利用できないといった問題が予想されます。

後継Gemを探せ

Twitterで相談したところ、こういうときの後継Gemを探す方法を教えてもらいました

有名なgemがメンテ放置されて、有用そうなPRがいっぱい放置された状態になってるのね。forkしてそういうパッチを取り込んだものを公開している人がたぶんいると思うんだけど、そういうリポジトリを探す方法ってないもんでしょうか？
— もぎゃ(daisuke furukawa) (@mogya) January 14, 2020

Insights タブの中の Network graph を見ると、最近も開発・メンテされている Fork 先のリポジトリを見つけることができると思います。https://t.co/pZy6jEvSFu
— peaceiris (@piris314) January 14, 2020

実際に見たのがこちら。

https://github.com/sferik/twitter/network

右に行くほど新しいブランチで、sferikさんのオリジナルからforkしている人をたくさん見つけることができます。PR名が出ているので、その人が何をしたのかだいたい分かります。

●をクリックすると該当レポジトリを見ることができるのですが、たいていの人は、sferikさんのコードになんか修正を加えてそのまま終わっています。ぼくみたいに特定の問題について困ったから、そこだけ修正して使っておこうという感じですね。

ただそれだと、RubyとかRailsの更新についていけなくなるのが困る。そう思ってリポジトリを次々みていくと、ピンとくる名前を見つけました。

https://github.com/zendesk/twitter

ZenDeskはユーザーサポートを一元化するための有名サービスで、Twitterからの問い合わせも対応できるようになっています。ここで使われているのなら継続的にメンテしてくれることを期待できそうです。

そうおもって更新履歴を見ると

あたらしいRubyへの対応とか、動かない箇所の修正とか、去年の夏まで継続的に修正が加えられています。これなら期待できそう。

ただひとつ問題なのは、最初に述べたextended textへの対応は入ってないようです。Zendeskの人は困ってないのかなあ。

俺Gemを作る

しょうがないので、zendesk/twitterからさらにForkしてmogya/twitter_gem を作ることにしました(mogya/twitterは他の名前で使ってしまっているので、別の名前にしてあります)

zendesk/twitterをForkしたあと、自分が取り込みたいPRを持ってきてマージします。この記事が参考になりました。
GitHub 特定のPRをForkしたローカルリポジトリに取ってきたい - かもメモ

[ ~/develop/twitter-gem]$ git remote add sferik [email protected]:sferik/twitter.git
[ ~/develop/twitter-gem]$ git remote -v
origin  [email protected]:mogya/twitter-gem.git (fetch)
origin  [email protected]:mogya/twitter-gem.git (push)
sferik  [email protected]:sferik/twitter.git (fetch)
sferik  [email protected]:sferik/twitter.git (push)
[ ~/develop/twitter-gem]$ git fetch sferik pull/913/head:fulltext
agent key RSA SHA256:+UeiGLqOys7Ur3KBSq4c10jM4fWlFnacby3izYyfMZg returned incorrect signature type
From github.com:sferik/twitter
 * [new ref]           refs/pull/913/head -> fulltext
10:37:03[daisuke@linode17 ~/develop/twitter-gem]$ git push origin fulltext
:
remote: Create a pull request for 'fulltext' on GitHub by visiting:
remote:      https://github.com/mogya/twitter-gem/pull/new/fulltext
remote: 
To github.com:mogya/twitter-gem.git
 * [new branch]        fulltext -> fulltext

このままgitでマージしても良さそうなのだけれど、なんとなくgithub上でPR作ってマージしておきました。
https://github.com/mogya/twitter-gem/pull/1

ついでにtravis-ciもぼくのものに置き換えたところ、無事テストがPassしたようです。

https://travis-ci.org/mogya/twitter-gem

出来上がったのがこちら。mogya/twitter-gem

Gemfileに gem "twitter"と書くところでぼくのリポジトリを指定します

gem 'twitter', github: 'mogya/twitter-gem'

使ってみる

[2] pry(main)> client = ...
[3] pry(main)> status = client.status(1216628579099766784, tweet_mode: "extended")
[4] pry(main)> status.text
=> "「実際にアプリ☆メーカーも、それまでに作ったサービスで宣伝して初期ユーザーを集めました。そしてマシュマロも、アプリ☆メーカーから初期ユーザーを集めました。雪だるま式戦術がうまくいった例です。」

「持たざる者」の集客方法｜だーすー @Neko_Inu_ #note  https://t.co/hKs4NfSQTj"
[5] pry(main)> status.uris
=> [#"https://t.co/hKs4NfSQTj", :expanded_url=>"https://note.com/neko_inu/n/nfae33c222614", :display_url=>"note.com/neko_inu/n/nfa\u2026", :indices=>[134, 157]}>]

よし完璧。Network graphにも、mogyaの名前が表示されるようになりました。

当面はこの状態で、zendeskの人がなにかアップデートしたら取り込むし、ぼくが使っていて困る不具合を他に見つけたらPRを取り込む感じで運用しようと思っています。

ここからさらに、みんなに呼びかけて支持者を集めて、sferikさんからTwitter Gemの管理権を禅譲してもらえば、ぼくがTwitter Gemのメンテナになることができる可能性があります。OSS contributorの名前は憧れるし、語学力的にできないこともなかろうと思うのですが、普通に考えるとZendeskのみなさまのほうがふさわしいと思うし、なにより、TwitterのすべてのAPIについて使い方を把握して、いま出ているissueを全部さばくとなると、それはちょっと片手間ではできなさそう。
どっか困っている会社さんが毎月5万円くらい払ってくれるということであれば検討するので、興味のある方はご連絡ください:-)

個人開発者のためのクラウドソーシング発注入門

2019-12-27T23:15:26+09:00

この記事はcrieitのなんでも Advent Calendar 2019の27日目の記事です。嘘です。

シモネタサイトの解説記事の中で、お金出してイラストレーターさんに描いていただいた話が興味を持っていただいているみたいなので、クラウドソーシングでデザイナさんにお金を払ってなんかしてもらう系のノウハウをまとめました。

クラウドソーシング

クラウドソーシングって、やばいブログの記事量産とか、安すぎてブラック労働、みたいな感じで良くない印象を持たれていることも多いみたいです。
実際のところは、無数に仕事があるんだからホワイトな仕事もあればブラックな仕事もあるし、そんなの現実社会と一緒でしょ、駄目なもののほうが面白いから目立つだけじゃないの、というのが個人的な感想。

でも仮に条件の良くない仕事がいっぱいあるのだったら、普通の条件で仕事を発注するだけでぼくらは相対的に優良な発注者ということになります。息をするだけで褒めてもらえる異世界転生の世界！

お金ないんだけど？

いやいやそう言ってそれなりに持ってるでしょ？~~ちょっとジャンプしてみ？~~

例えばこれとか魔法にしか見えないじゃないですか？

#本日のイラレ #Illustrator七宝文様のつくりかたその２。前半の線ver.は前回のまま。後半の塗りver.をちょっと改良しました。 pic.twitter.com/TqTTLKzLAh
— コロ / イラレ職人 (@coro46) August 3, 2019

最初の頃これ見て「すげー、覚えよう！」と思っていたのですが、ある時気づきました。それってデザイナさんが『phpの文法を覚えよう』って言ってるのと一緒だよね？
ぼくらにとってプログラミング言語の文法とか、エディタのショートカットは毎日使うから勝手に覚えるものであって、頑張って記憶とかしても意味ないよなーと思うじゃないですか。便利なライブラリとか、べつに意識して探さなくてもTwitterで遊んでいるうちに勝手に知識が入ってきて、必要になったら「なんかあったよね、どこだっけ」って探せば簡単に出てくるものじゃないですか。

同じように、デザイナさんはillustratorを日々使ってるからショートカットとか勝手に覚えているし、街を歩けば「あ、七種泰史さんのフォント」みたいなことを自動的に考えちゃうものなのです。

これ！このセンス！ぼくら見てもなんとも思わない文字、デザイナさんが見ると「あ、あのフォントだ」って見えるの！優秀なデザイナさんはフォントいっぱい持ってて、ふさわしいフォントを選んでくれる。そうするとデザインがバシッと引き締まる！ https://t.co/mLVoN0Lrub
— もぎゃ(daisuke furukawa) (@mogya) August 30, 2019

なので、Webサイトでイラストが必要とか、なんかデザインが締まらないんだけどどうしていいかわからないという時、ぼくらがillustratorでドーナツ一個書くのにも四苦八苦している状態で頑張るより、「こんな感じのイラストがほしいんです」ってお願いしてサクッとやっていただいたほうが効率的な時間の使い方なんじゃないのかなと思っています。

発注先

　ぼくはクラウドワークスを使っています。もともとランサーズ使ってたのですが、クラウドワークスのほうがいい感じで仕事してもらえることが多かったので、最近はクラウドワークスで依頼することが増えています。
イラスト特化のSKIMAというサイトもあるのですが、Webサイトの部品というよりは、壁に飾る絵描いてください、みたいな雰囲気があわなくてまだ試したことがないです。

発注内容

　Webサイトに使うアイコンとか、今回のようなイラストをお願いすることが多いです。

サイトまるごとデザインみたいなのは、一回お願いしたことがあったのですが、出来上がったあとで開発の方向性が間違っていることに気がついてドンガラガッシャンする羽目になるという痛い経験をしたことから、よほどサイト内容が固まって、あとはデザインを良くすれば勝てる！みたいな状態にならない限りもうやらないんじゃないかなあ。

コンペと固定報酬

クラウドワークスの依頼形式は3つあって、コンペと固定報酬、時給制です。

このうち時給制については、使ったことないのでパスします。時給制で雇って、方向性の相談から製作まで全部やっていただくのはちょっと憧れますが、だいぶ金額の大きな仕事になっちゃうので、個人開発でここまでつっこむのは難しいんじゃないかなあ

コンペは、テーマを決めて皆様に応募してもらって、その中から一番いいものを選ぶ形式。コンペにできるものなら、コンペおすすめです。できたものを見て選べばいいので選ぶのが簡単。

ただ応募するデザイナさんの立場に立つと、応募して選ばれないと一円ももらえないので、あんまり大規模な仕事をコンペにすると、やってられまへんわということになって応募してもらえなくなります。そういう仕事は固定報酬にすることになると思います。

ぼくは基本コンペでお願いして、その人がよかったら、追加発注とか、同様にお願いできそうな仕事のときは固定報酬で同じ人にお願いするようにしています。いい人がいたらずっと固定の依頼になりそうなものなのですが、そんなに頻繁に依頼するわけじゃないので、「前回依頼していたあの人」と思ったら退会していて連絡がつかなくなることがよくありますw

あと、個人的にオススメのやり方。イラスト5点とかお願いするときに「一点だけ作って応募してください。選ばれたら、残りも制作して納品をお願いします」というスタイルにすると、ぼくはコンペ形式で選ぶのが楽だし、デザイナさんも、5点作ってコンペ負けして一円にもならない、みたいな悲劇を回避することができます。過去何回か試して好評頂いているので、よかったら試してみてください

金額の決め方

金額は、類似の依頼を見て決めます。
検索ページから今出てる依頼を検索できるので、「この金額なら応募が殺到する」「この金額なら応募は来ない」というのがわかります。
ぶっちゃけ応募が殺到すると見るだけでも手間がかかるので、倍のお値段でいい仕事してもらおう、みたいなやり方はあんまおすすめできません。優秀なデザイナさんの成果に報いるのは、二回目以降の固定依頼の時がいいんじゃないかと思います。

人を集める

クラウドワークスには、デザイナさんに対して「みてみて」って通知を送る機能があります。
クリック一つで送ることができて、一つのお仕事に付き20人まで送ることができるので、「あれ？意外と集まらない？」と思ったときのブーストに使うのがいいかと思います。
「昔やってたけどもうクラウドソーシングは受けてないんです」みたいな人は通知を送っても見てもらえないので、狙い目はクラウドワークスに登録したばっかりの人です。
「イラスト」とかのキーワードで検索して、新着順でソートします。ざっと見て問題のなさそうな人片っ端から「みてみて」を押していきましょう。大丈夫。クラウドワークスに登録したばっかりの人でも、ぼくらが自分でやるよりはるかに優秀な人ばっかりです。

あと、週末デザイナー(平日会社員)という方が結構いるので、「応募ない?」と思っても土日は様子見るのもいいと思います

気持ちよくお仕事をしていただくために

直し

デザイン作っていただいたあとで、「やっぱこうしてほしいです」「違うデザインで」みたいなことを言うのを「直し」といいます。プログラマならこういうの嫌いなのはわかりますよね。
とはいえ全く直さないと意図したものがもらえないので、どのくらい直してもらうつもりか明記しておくと良さそうです。

「ラフ提出→承認→制作→直し(一回まで)」だとわりと受け入れてもらいやすいと思います。

(ラフ: 色塗りとかレイヤー整理とか時間のかかるところはやってないけど、だいたい方向性の分かる程度のデザイン)

最近は慣れてきたので、「ラフ提出→承認→制作→直しなし」で依頼することも多いです。細かいところはデザイナさんを信じる！

用途について

プログラマの場合、勤務時間中に書いたコードは納品先のもので、そのあと何しようがお客さんの勝手という契約が一般的ですが、デザイナさんの世界では、デザインというのは用途を指定して発注することになっています。例えば「このチラシで使います」って発注した場合、他のチラシに転用したり、webサイトに使うのはNGです。

この辺の説明がわかりやすい。
印刷デザインのデータの著作権（版権）は誰のもの？

業界の慣習は尊重したいのですが、ぶっちゃけ個人開発においてこれは非現実的です。挿絵として依頼した画像だけどいい感じだったのでfaviconにも使いたいとか普通にあるし、ぶっちゃけ便利な画像があれば別のサイトでも使いたいでしょ？何年かたって元の絵を描いたデザイナさんに連絡がつくとも限らないですし。

そういうことに配慮したのか、クラウドワークスでは(ランサーズも)、利用規約で著作権の譲渡が定められています。
つまり、デザインで一般的な考え方ではなくて、素人が思う「作ってもらったものはオレのもの理論」が通るということです。

とはいえ相手の商習慣に配慮しておいたほうが気持ちよく仕事していただけるのは確かなので、一言書いておくと、「あ、配慮してくれてるんだなあ」と思ってもらえるかもしれません。

クラウドワークスの利用規約では、取引完了した段階で著作権はクライアントに移転・帰属する事になっています( https://crowdworks.jp/pages/agreement.html )
これを前提に、納品していただいた画像等は無断で適宜編集して他の用途に使う可能性があるので予めご了承ください

あと、著作権を譲渡してもらうと、制作物はぼくらの物になって、デザイナさん自身がポートフォリオに載せるにも許可が必要になってしまいます。ぼくらそんなことは望んでいないと思うので、ここも一言書いておいてあげると、ちょっと恩を売れるかなと思います😜

ただし、納品していただいた画像をデザイナさんが別の用途に使うことは全く制限しません。他の仕事に使ったり、ポートフォリオに掲載したり、自由に使ってもらって大丈夫です

謝辞について

あんま関係ないような気がするのですが、一応毎回、謝辞載せて宣伝に協力しますよということを書くようにしています。

もし希望があれば「アイコンはこの人に作っていただきました」みたいな感じで、ブログやサイトなどで謝辞つけます！

アウトプット形式について

サイトのデザインが変わったとき、イラストのサイズを変えたり、ちょっと他のところに転用したりしたい、ということを考えると、あとで変更が効くフォーマットでもらっておくと便利です。
illustratorが使える人は、レイヤー分けされたaiでもらっておくと、背景を消してオブジェクトだけ取り出したり、サイズを変えて任意のサイズで取り出したりできるようになります。
Adobe税が払えない方は、svgにしておくとサイズ変更できるので、比較的扱いやすいかと思います。

※ この間仕事お願いしたデザイナーさんは、何も聞かずにpngとjpegとsvgとaiをアップロードしてくれて、「こいつ...デキる！」って思いましたw

30px-400pxくらいの任意のサイズでアイコンを作れるように、svg形式での納品をお願いします。コンペ時点ではpngやjpegで大丈夫です

イメージの伝え方

クラウドソーシングサイトでは、標準テンプレートみたいなのを使ってイラストのイメージを伝えるように誘導してきます。

でもまあ、こんなんで伝わるんだったら苦労しないよね。

いらすとやさんの画像とかを使ってとりあえず仮で作っちゃって、このサイトのここに使う画像がほしい！ってお願いするか、どこか別のサイトを示して、「こんな感じのがほしいと思っています」って言ったほうが早い気がしています。

シモネタサイトを全力で作ったよ

2019-12-15T08:56:58+09:00

この記事はクソアプリ2 Advent Calendar 2019 15日目の記事です。14日目はendo_hizumiさんの「お前らのクソアプリは間違えてる」。わーい！寿司が回ってるよ！ぼくの思ってた廻る寿司となんか違う！

クソアプリが作れない

ということで、年末のお祭りを名目に、肩の力を抜いてなんでも公開するといいよ！という趣旨のクソアプリカレンダー、ずっと眺めていたのですが、なかなか参加できなかったのですよね。あっという間にうまるのもあるけど、それ以上に、自分マジメなので、そういうのを作るのが苦手なのです。

どれくらいマジメかというと、中学高校と学級委員長を歴任していました。委員長は何がいいかというと、委員長という役割をしておけば、クラスのなかに居場所がなくなることがないのですよね！

そんな人間にクソアプリを作れだと？無理に決まっている。予約日が15日なのに一週間も前に完成させてバグバッシュしちゃったじゃないか！

誰でもできるクソアプリ

こうなることはわかっていたので、対策を立てておきました。出来栄えがクソなんじゃなくて、ネタがクソならクソアプリ。小学生のごとくウンコとかオシッコとか言っておけばなにを作ってもクソアプリになるに違いない！

【警告】以降、全力でシモネタです。そういうのがお好きでない方はこれ以上読まないことをおすすめします。

(警告したからね？もう遠慮しないよ！？)

というわけで作りました。

ギガントおちんちんランキング

ギガントおちんちんランキング🎉

おちんちんの太さを測って入力すると、日本で何番目くらいの太さなのかわかります。
もちろん結果をTwitterでシェアしてみんなに自慢することが出来ます。

なんで太さ？

いにしえの昔、ハイパーオチンチンランキングというサイトがあったのです。
おちんちんの長さを入力すると順位を調べてくれるこのサイト、それはもうバズりました。

https://b.hatena.ne.jp/entry/pandora.nu/pha/ochinchin/

しかし、このサイトが登場したその当時、SNSは今ほど一般的ではなくて、どんなサイトでもtwitterシェアボタンがあるのが当たり前という時代ではなかったのです。

これだけ面白いサイトが！ここにシェアボタンがあれば！絶対バズるのに！

何回か持論を展開したのですが、みんなおもしろネタとして受け取るばっかりで作る人がいないので自分で作ることにしました。

リスペクト的な意味を込めて、長さじゃなくて太さにしてあります。

技術的な話

大前提として、このサイトをいつまでもメンテしたくないというのがあります。今クソアプリ用のテンションで吹っ切れてるからおちんちんとか平気で書いているけど、年が明けてこれのメンテナンスを継続する自信はない。おちんちんのことは完全に忘れて次のサービスに取り掛かりたい。

自前サーバに載せてなんかの弾みにうっかり消して「もぎゃさん、おちんちんが落ちてるんですけど？」とかいうメンションをもらったりしたら、確実にそんなサイトはなかったことにしてしまう気がします。

だからといってFirebaseみたいなのも、お財布に火が付きそうで怖い。

放っておいたらいつまでも維持されて、アクセス従量課金じゃないサーバ。

あります。Github pagesです。Githubのアカウントさえあれば無料で使えて、リポジトリを消さない限り維持される、高負荷でもそうそう落ちたりしない、理想のサーバ！

Github Pagesは静的サイトしか保持してくれないので、開発言語はJS
しかありえない。去年作ったqiitaRank では、index.htmlにvue.jsをscriptタグで取り込む簡単実装だったので、これをコピペしてサクッと作りました。

OGP問題

Twitterシェアが命のサービスなので、シェアしたときの見た目が大事です。くすっと笑ってぼくも使ってみようと思えるサイトでないといけない。そのためにはOGP画像が必須ですが、Twitterのクローラーはそんなに賢くないので、JSで生成した動的画像をOGPとして使うことが出来ません。
かといってSSRみたいな高度なことをするためにはホストするサーバが必要、CircleCIで頑張る...うー、めんどくさいな。

3日くらい考えてひらめきました。「そもそも動的である必要はないよね」

ソースコード見ていただくとわかりますが、結果ページは独立したHTMLファイルになっています。結果ページの役割は、TwitterにOGP画像を返すこと。人間がアクセスしてきたらトップページにリダイレクトさせます。


 
 
 
ギガントおちんちんランキング

違いはOBP画像だけなんだから、nuxt.jsみたいなの使えば生成できそうですが、意識低く、結果と同じだけのHTMLファイルをそのまま保持しています。

あとはindex.htmlで、結果に応じてシェアするURLを分けてあげれば出来上がりです。

IE対策

サイトの趣旨がとてもオチンチンなので、エンジニアではない方がアクセスすることを想定する必要があります。IEで開くと．．．動かん。

Vue.jsのコードは近代的なブラウザを前提にしているので、IEで動かすのは難しいのです。Polyfill.io入れたら動くんでしょ？と思っていたのですが、scriptタグで取り込むvue.jsは、script部分で新しい記法(テンプレートリテラルとか)をつい使っちゃうので、かなり無理があります。

しばらく頑張ったのですが、どうにもならんので、さっき回避したはずのNuxt.jsを入れてgenerateモードでページを生成してもらうことにしました。このやり方ならbabelがIEの差異を吸収したページを生成してくれるので、IEでも動かすことが出来ます。

Nuxt.js on Github pages

Nuxt.jsで生成したページをGithub pagesで動かす方法はここに載っています(vue.js周りのドキュメント充実度すごいよね)

簡単にいうと、URLがexample.com/_nuxt/hoge.js みたいなんじゃなくて https://mogya.github.io/ochinRank/ という具合にサブディレクトリになるので、それを考慮したHTMLが生成されるように設定する必要があります。

export default {
  router: {
    base: '//'
  }
}

あと、github pagesは基本レポジトリにあげたコードを全部公開してしまいます。generateしたファイルだけ公開するために、「masterブランチのdocsディレクトリ下だけを公開」モードを使うことにしました。

nuxt.config.jsの設定を変更して、distの代わりにdocsディレクトリにHTMLを生成するようにします。

export default {
  generate: {
    dir: 'docs'
  },

docsディレクトリはそんな使い方をするものじゃない？クソアプリだからね。

シモネタライセンス問題

いらすとやライセンス

当初このサイト、イラストは安定のいらすとやを使わせていただく予定でした。自由に使えてなんでも揃ってるぼくらの素材サイト。くすっと笑うのにトーンもあってるよね。しかし。

ですよね。おちんちんランキングはジョークサイトであってアダルトサイトじゃないと思っているのですが、こういうのは結局の所いらすとやさんがどう受け止めるかの問題になってしまいます。
いらすとやさんがあれだけ寛容な条件を用意してくれているのに、「ぼくはアダルトサイトじゃないと思いました」っていう名目で利用を強行して炎上したりすると、いらすとやさんにご迷惑がかかりそう。

ということでお金出してイラストレーターさんに描いてもらいました。クソアプリなのに！
【一点で応募可能】 Twitterのシェア用画像5点の依頼/外注｜イラスト作成の仕事

でもおかげでなかなかいいデザインになったと思います。太さに応じてTwitterシェアしたときの画像が変わるようになっているので、ぜひシェアして見てくださいね。

スタバハック

2019-12-02T14:49:05+09:00

午前中はだいたいスタバでコード書いている。
前の日のうちにやること決めておいて、午前中に成果を出しておけば、午後は心穏やかに過ごせるのがいいですね。

ということで２ヶ月位通ってみてわかった、スタバでコード書いて成果を出すためのノウハウです。

[困] スタバ怖い

　スタバ恐怖症の人が結構いて、呪文怖い/何を頼んでいいかわからないのと、店員さんに話しかけられるのが苦手、の２パターンあるようです。

最短注文メソッドがこちら

「本日のコーヒー、ホットのトールサイズ、マグカップで」

本日のコーヒーは、ぼくらみたいに「ぶっちゃけなんでもいい」というお客さんのためにスタンバイしているコーヒーで、お手頃価格ですぐ出てくるという、いちばん大事な特徴を抑えています。
日々変わるので、好みじゃない味の日もありますが、コーヒーなんて場所代なんだから、苦かろうが酸っぱかろうがそんなことは些細な問題ですよね。

トールサイズは、飲み物のサイズです。スタバ独特なサイズの呼び方、苦手な人が多いと思うのですが、全部覚える必要はありません。トールサイズだけ覚えておけばOK。
それすら出てこないときは「一番大きいので」という逃げ道もあります。

マグカップは、店内用のマグカップか、紙コップに入れてもらうかの選択です。聞かれて応答すると時間の無駄なので呪文として覚えましょう。

紙コップにしてもらうと途中で退店することにしたとき便利なので、先日まで紙コップがおすすめだったのですが、公明党が軽減成立なんて余計なことを考えついた結果、スタバの店員さんは持ち帰りと店内飲食を確認しないといけなくなったので、紙コップと言うと「店内ご利用ですか？」「はい」という余計な会話をしないといけなくなりました。
これを避けるため、マグカップで注文します。これは持って帰れないので、会話を一個減らすことが出来ます。

ということでもう一回。

「本日のコーヒー、ホットのトールサイズ、マグカップで」

これでお金払ったらすぐ飲み物を持って席に逃げることが出来ます。パソコンでTwitter開けばぼくらの世界。もう恐れるものはなにもない!

[困]コーヒー苦手

勘違いしている方が多いのですが、スタバはコードを書くための場所です(断言)
コーヒーを飲みたい方とか、出勤前に買っていく方とかもいますが、あれはスタバが経営を安定させるためにやってることであって、本来スタバはコードを書くための場所なのです(二回目)

なので、実はスタバにはコーヒーじゃないものも結構あります。

問題なのは、下手なものを頼むと注文時間が長くなってMPが減ることです。おしゃれなサイトで紹介されているナントカフラペチーノとか頼むと、受け取りカウンターで待たされるので、これは避けたい。本日のコーヒーなみに早く出てくるコーヒー以外のメニュー...

あります。紅茶です。紅茶はカップにお湯入れてティーバック入れるだけの簡単作業なので、これもレジでそのまま出してくれます。
紅茶専門店みたいにちゃんと淹れたものじゃないですが、ぶっちゃけぼくらにとって飲み物は場所代なので(ry

紅茶メニューがここにあるので、スタバの常連になったら、一個覚えておくといいかもしれません。
https://www.starbucks.co.jp/beverage/#beverage_tea

ほうじ茶とか覚えやすくておすすめです。

[困] Wi-Fiが切れる

スタバのWi-Fiはチェーン系の中で安定して動くほうだと思うのですが、一時間に一回利用規約に同意しないといけないので、そのタイミングで一回切れてしまいます。
で、再開しようと思うと、一回Wi-Fiを切ってつなぎ直して集中力が...

このURLをブックマークに入れておくと、その場で接続画面が出てくるのですんなりつなぎ直すことが出来ます。

WiFi接続

AndroidスマホがWi-Fiの動作確認のためにつなぐGoogleのページです。中途半端なサイトをつかうと、HTTPS警告が出てきたりして苦労することが多いのですが、このURLはまさに接続確認のために作られているので、確実にログイン画面が出てきます。

[おまけ] バターミルクビスケット

スタバの食べ物は全体に高いのであんまおすすめしないのですが、小腹がすいたときはこれがおすすめです。

スタバのバターミルクビスケットが美味しい。自慢の水蒸気トースターが威力を発揮する( ･ิω･ิ) pic.twitter.com/lgVN9D8AKo
— もぎゃ🔌(daisuke furukawa) (@mogya) October 31, 2019

マンションベランダに200Lの水槽を作った話

2019-12-01T11:37:30+09:00

この記事は、farmtory Advent Calendar 2019 の初日です。

夏の趣味として水耕栽培でミニトマトを作るというのをやっていて、その縁でfarmtory-lab というのに誘ってもらいました。衣食住を実現する小さな工場を作る、身の回りで使うものを自分で作る、といったテーマで、レーザーカッターや3Dプリンタはもちろん、ぼくには説明もできないような奇想天外な道具を使いこなして、食べ物はもちろん、服とかキーボードとか家とかお茶とか作っている人たちです。

正直自分はそこまでガチじゃないのですが、レーザーカッターとか好きだし、farmtoryの概念は好きだし、なにより advent calendarが空いていたのでw ぼくがやっている水耕栽培の話をさせてください。

2018年の水耕栽培

2018年は、それ以前から続く大型化の流れを受けて、水タンクと栽培槽に衣装ケースを使って、1本のトマトから150個の収穫を実現しました。

衣装ケースは、サイズとしてはいい感じだったのですが、紫外線で劣化してある日突然崩壊するという弱点がありました。これがなかったら夏後半もっと収穫できたはず...

あと、栽培容器としては深すぎて、ポンプで循環させていても思ったほど養液が移動していなかったのではないか？という感触がありました。

2019年の水耕栽培

これを踏まえて、2019年はこんなふうに考えました

栽培容器に深さは必要でないけど、紫外線で劣化しない何か他の容器を見つけてくる必要がある
水タンクは、引き続き大容量化したい。去年は茨城県の庭で水道が使えたけど、今年はホースで水を引っ張るので、大容量タンクがないと毎日水を運ぶのが大変。

衣装ケースより大きくて、プラスチック以外の素材できていて、安価に手に入るもの...

世間的に事例を見ていると、スタイロフォームや角材を使って自作する人が多いようです。しかしそういう素材は大きく重いので、都会で車なしベランダ水耕栽培という成約でやっているうちには適さないのです...

プロには専用の容器があるのですが、こんなものを自宅で受け取って、ベランダに通じる窓を通せるとは思えません...

スイコーホームローリータンク 200L (レモン)

栽培容器を作ろう

ということで見つけてきたのがこちら。

(特大ポリ袋)

ワイヤーラティスで枠を作って、袋貼れば水を貯められるだろ、という作戦です。

適当にワイヤーを曲げて針金でつないで、車の遮光用シート(100均)の上から袋はって出来上がりです。これだと光が差し込んで水が濁ってしまうので、さらにぐるっと遮光シートで覆います。

棺桶っぽい...

水槽を作ろう

最近の水耕栽培は、トマトが根を張る栽培槽の他に、養液を貯めておくタンクを別に設置してポンプで回すことにしています。
トマトがどれだけ根を張るかで収穫が左右されるので、できる限り根を張るスペースを確保したい、そのためには可能な限り大きな容器が望ましい。
そして大きく根を張ったトマトはとんでもない量の水を消費するので、その消費に耐えられるサイズのタンクも必要になります。

経験的に夏最盛期の水消費量は20L/日。20Lのタンクだと1日たりとも給水を休めない(=旅行が許されない)ことになるので、手間を考えると一週間、140Lはほしいところです。

ワイヤーラティス作戦で行くとしても、140Lの水を貯めておける袋が必要になります。そんなもの...あったw

タンスも入る超特大ポリ袋

一枚1700円と決して安くはないですが、農業用タンクをベランダに搬入するよりはずっと現実的です。

ラティスを針金で止めて枠を作って

内側にプラダン、外から遮光シートを貼り付けます(プラダンがないと、袋が網目に押し付けられることになっちゃうので、たぶんそこから破けちゃうというアドバイスを頂きました)

そんなこんなで出来上がった水槽がこちら。

2m×40cm×40cm、貯水容量はなんと200L。二週間近く耐えられる安心仕様！
ここからポンプで水を汲み上げて、栽培槽に給水。栽培槽でトマトが飲みきれなかった分は下から養液層に戻るようになっています。去年より薄くて養液が行き渡りやすくなりましたが、根を張るスペース自体は十分に確保されているはずです。

運用

で、水を入れてみた写真がこちら

やばいw

明らかに水圧で歪んでます。とは言え夏も近づき、新作を作っている暇はなさそう。仕方がないので、半分のまでしか水を入れない安全運転にすることにしました。

成果

収穫数は、去年を大きく上回る433個に達しました。大型化させて栽培槽を薄くする作戦がうまくいったのかなと思っています。
ただ、(写真撮り忘れたのだけど！)終盤にあけてみると、幅いっぱいに根が張る一方、末端の方は届かなかったみたいなので、来年は深さと長さ維持、より幅広で作ってみるのがいいのかなと考えています。

惜しむらくは、8月の末にポンプが故障して、その事に気づかないまま一週間以上が経過してしまった結果、樹がすっかり傷んでしまって、9月の残暑に収穫ができなくなってしまったことです。あれがなかったら500個いけたのに...

IoT監視は後回しにしていたのですが、さすがにそろそろ考えたほうが良さそう。

2020年の計画

プロから見るとびっくり安価な素材で作った水槽なのですが、意外と行けるので、補強して来年も使おうと思っています。

アングル材で補強してあげれば、水圧にも耐えられるはず。

でもって、作り直した栽培槽をアングルの上に配置すれば、2階建てでかっこよさそう。

あと、野放図にトマトを伸ばした結果、ベランダから溢れ出して下の階にご迷惑おかけしそうだったので、慌てて引っ張り上げることになったので、ここはなんか考えないといけません。
プロだと、庭の真ん中に作って東屋みたいに育てるのが主流なのですが、

(農業用栽培槽で自作水耕　配管について2)

ベランダは前からしか日が差さないので、栽培可能な体積が限られるのですよね。どんな棚を作ればいいのか、考えているところです。

systemd/timerを使ってサーバを毎晩リブートさせる

2019-10-29T17:42:48+09:00

サーバを定期的に再起動したいという需要は常に存在します。

どっかの誰かが開放し忘れたコードにより徐々に減っていく空きメモリ。原因を追求するより、定期的に再起動しちゃえば一発解決だよね🧙

なんか時々落ちるこのサービス、いっそ定期的にサーバを再起動しておけば、たとえ落ちたとしても復活するから、大体の時間は動いてるサービスにできるんじゃないの？😈

いいことか悪いことか、かっこいいかどうかはともかくとして、定期的にサーバを再起動しておけば解決できるある種の問題が存在することは事実です。問題の先送りだって一つの技術力ですし(後ろめたいときって前置きが長くなるよね)

ともかくそういうわけで何らかの理由でサーバを定期的に再起動させたいときの設定です。

CentOS7から標準になったSystemdのTimer機能を使います

serviceの作成と登録

$ sudo nano /etc/systemd/system/reboot.service

[Unit]
Description=Scheduled Reboot

[Service]
Type=simple
ExecStart=/usr/bin/systemctl --force reboot

こうやって出来たserviceファイルを

sudo systemctl enable reboot

で登録します。

この段階で、

sudo systemctl start reboot

ってたたいてあげると、サーバが予告なく再起動するかと思います。

Q: rebootコマンドじゃないの？
A: rebootとかhaltはCentOS7から非推奨になりました
10.4. システムのシャットダウン、サスペンド、休止状態 Red Hat Enterprise Linux 7 | Red Hat Customer Portal

Timerの作成と登録

serviceの作成と登録

$ sudo nano /etc/systemd/system/reboot.timer

[Unit]
Description=schedule reboot

[Timer]
Unit=reboot.service
OnCalendar=*-*-* 5:30:00

[Install]
WantedBy=timers.target

この例では毎朝5:30に再起動する記述になっています

sudo systemctl enable reboot.timer
sudo systemctl start reboot.timer

で登録します。

$ sudo systemctl list-timers --all
NEXT                         LEFT          LAST                         PASSED   UNIT                         ACTIVATES
Tue 2019-10-29 17:04:33 JST  4min 59s left n/a                          n/a      systemd-tmpfiles-clean.timer systemd-t
Wed 2019-10-30 05:30:00 JST  12h left      n/a                          n/a      reboot.timer                 reboot.se
n/a                          n/a           n/a                          n/a      systemd-readahead-done.timer systemd-r

という具合に、次の5:30にrebootが予定されていれば出来上がりです。よい再起動ライフを！

リモート開発には、sshトンネルが便利

2019-10-04T05:08:06+09:00

code-serverを使ってブラウザ上だけでセキュアで快適に開発してみる｜masuidrive｜note

増井さんキター！
だよね？もはやローカルPCで開発とかしないよね？時代はリモートだよね！？

記事に書かれているとおり、リモート開発では、ポートの開閉が問題になります。ローカル開発で気軽にlocalhost:3000にアクセスするような感覚でサーバのポートを開けると、全世界から3000番にアクセス可能になってしまいます。自分のIPアドレスを調べて限定公開すればいい？毎回そんな面倒なことやってられないよ。

そのソリューションとしてVPNはりました、ということだったのですが。記事見て分かる通り、VPNもめんどくさいのですよね。過去何回かトライして、だいたいVPNサーバの維持がめんどくさくなって諦めています。

代わりに使っているのが、SSHのport_forwarding。

sshの設定ファイルに、こんな具合に書いておきます。

Host linode17
  HostName xxx.xxx.xxx.xxx
  LocalForward 127.0.0.1:3000 127.0.0.1:3000
  LocalForward 127.0.0.1:1337 127.0.0.1:1337

んでいつものようにサーバプロセスを立ち上げてlocalhost:1337にアクセスすると

ほい来た。

sshのport_forwadingというのは、sshの接続のついでに、ローカルのポートをサーバのポートにつないどいてね、という機能です。SSHでつないだ接続(トンネル)の中をデータが流れるので、SSHトンネルとも呼ばれます。
SSH port forwarding - Example, command, server config | SSH.COM
man page ssh_config section 5
SSH接続が前提の機能なので、当然そのポートにアクセスできるのは自分だけに限定されます。

この方法の嬉しいところは、WEB開発で当たり前のように使うsshの設定ファイルに書くだけですべてが完了するところです。開発サーバの他にもう一台サーバを維持したりしなくていいし、接続を忘れて「あれ？つながらない？」みたいなことにもならない。

2つ3つの開発を並行していて、localhost:3000の奪い合いになるのはWEB開発あるあるですが、リモートに用途ごとの開発サーバを用意しておけば、接続を切り替えるだけで毎回localhost:3000を使うことができるのも地味に嬉しい。

一方で、VPNを用意しておくと、公衆無線LANなんかで接続するときの安心感が大きいので、そこはトレードオフですね。

よかったらお試しください。

hadolintでDockerfileの書き方を叱ってもらう(VSCode, CentOS)

2019-08-30T17:38:11+09:00

最近の開発環境はとても親切になっていて、コードの補完とか、良くないコードの指摘とか、もはや君が書いてくれたらいいんじゃない？と言いたくなるくらいいろんな機能が充実してきている。

順調に飼いならされているぼくは、いろんなツールに叱ってもらいながらコードを書くのが当たり前になっていて、そうすると、叱ってくれない箇所があるとむしろ不安になってしまう。

そんなわけで不安になるものの一つがDockerのファイルで、dockerfileとかはベストプラクティスがあるんだから、それに沿って書き方チェックしてくれたらいいのになーと思っていた。

そしたら、そういうのがあることを教えてもらった。

雑に書いたdockerfileやdocker-compose.ymlを添削してくれるサービスがほしい
— ﾅｶﾞﾓﾄ@Glideエンジニア (@ngmt83) August 26, 2019

lint?もしかしてと思ったらありました!https://t.co/oQqFRTYtI4
— ﾅｶﾞﾓﾄ@Glideエンジニア (@ngmt83) August 26, 2019

これは使ってみるしかない。すでに何人もの人が試していて日本語の記述もいっぱいあるので、ここではぼくの普段使っている環境 VSCode + CentOS での手順をメモ。

hadolintのインストール

公式サイトによると、

You can download prebuilt binaries for OSX, Windows and Linux from the latest release page.

ということなので、リリースページからダウンロードしてきたファイルをそのまま実行するのがいいらしい。

apt-getで入れないと不安になっちゃうけど、まあ新しいツールはそんなもんよね

[ ~]$ cd /usr/local/bin/
[ /usr/local/bin]$ sudo curl -L -O https://github.com/hadolint/hadolint/releases/download/v1.17.1/hadolint-Linux-x86_64
[sudo] daisuke のパスワード:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   611    0   611    0     0   1615      0 --:--:-- --:--:-- --:--:--  1616
100 3216k  100 3216k    0     0   598k      0  0:00:05  0:00:05 --:--:--  678k
[ /usr/local/bin]$ sudo chmod +x hadolint-Linux-x86_64

試しに実行してみる

[ /usr/local/bin]$ hadolint-Linux-x86_64 ~/develop/dengen_map/docker/front/Dockerfile 
/home/daisuke/develop/dengen_map/docker/front/Dockerfile:3 DL3008 Pin versions in apt get install. Instead of `apt-get install ` use `apt-get install =`
/home/daisuke/develop/dengen_map/docker/front/Dockerfile:3 DL3015 Avoid additional packages by specifying `--no-install-recommends`

叱ってもらえる！

VSCodeから実行

VSCodeには、hadolint というプラグインが用意されている。これをインストールして、設定画面からhadolintのパスを設定する

そうすると、つぎからDockerfileを編集したときに、こんなふうに叱ってもらえるようになる！幸せ！もっと叱って！

いまのところ、docker-compose.ymlまでは見てくれないらしい。構文チェックだけでもやってくれるツールがほしいなあ。

月末だけ失敗するspecテストと対策(テストを時刻に依存させるな運動)

2019-07-31T22:46:21+09:00

この記事で言う現在時刻というのは、例えばTime.zone.nowとか、Date.current, Date.todayのような、今日とか現在時刻、をとってくるメソッドのことです。
railsではtimezoneの扱いを大事にするため、Time.nowじゃなくてTime.zone.nowを使う、みたいなノウハウがありますが、今回の話はそれとは関係がありません。
specテストにおいて、そういう「現在時刻に関するメソッド」を安易に使うと、「特定の日だけ落ちるテスト」「特定の時間だけ落ちるテスト」になりやすいのでやめよう、という話。

例えばこんなケース

渡されたdateに対して、その月の残りの日付を配列で返す関数 remaining_days_of_month を作ります。例えば 1/28が渡されたら、[29,30,31] を返します。31日だと、残りの日付はないので [] です

コーディングテストに良さそうな題材ですね。これをどうにかして実装したとして、この関数に対するspecテストを考えましょう。

「これ、引数に渡したその日は含まれないのよね」

it 'not contains the day' do
  expect(remaining_days_of_month(Time.zone.today)).not_to include Time.zone.today.day
end

「で、その次の日から始まる、と」

it 'contains next day' do
  expect(remaining_days_of_month(Time.zone.today)).to include Date.tomorrow.day
end

いろいろつっこみどころはあるかと思いますが、話の都合で、これがコードレビューを通ったことにしましょう。テストはなにか書いてあればOKという職場、あるでしょ？

月末の悲劇

月末の夜、リリースに向けてコードを書く職場で悲鳴が上がります。
「なんかテスト落ちてるぞ！」
「Aくん、rspec落ちてるから確認して」

AくんはCircleCIで落ちた箇所を確認します。おかしいな。こんなところ触ってないのに、これ一体何なんだろう...触ったこともないところだから全然わからん...これぼく関係ないんじゃないの？だからテストって嫌いなんだ...

問題

簡単な例なので大半の方は気づいていると思いますが、問題のコードはこれです。

it 'contains next day' do
  expect(remaining_days_of_month(Time.zone.today)).to include Date.tomorrow.day
end

このコード、通常はテストが通りますが、月末最終日に限り、Time.zone.todayはその月、Date.tomorrowは翌月を指すようになるのでテストが失敗します。

この一行なら誰だってわかるけど、これ１０行くらい書いた中に埋め込まれると結構わからなくなるのです....

対策

よく言われる対策は「TimeCop / TimeHelpersを使って時間を固定する」です。

ですが、正直この程度のことにそんな大道具持ち出すのもどうなのよ、そういうことしていると、今度は開放し忘れて別の箇所で悲劇を引き起こすんじゃないの？

ぼくがすすめている対策は、「rspecで現在時刻は使わない」です。

例えば今回のテストはどう書くのが正解だったのか。

describe 'remaining_days_of_month' do
  it 'contains remaining days' do
    let(:date) { Date.new(2019, 1, 28) }
    expect(remaining_days_of_month(date)).to match_array [29, 30, 31]
  end
end

テスト日付を固定します。そうすると答えもおのずから決まるから、includeじゃなくてmatch_arrayで確認することができる。

そもそも、テストを実施する日によってテスト内容が変わる時点でおかしいですよね。specテストに書いたコードにバグがあっても、specテストをspecテストすることはできないのだから、テストは可能な限りシンプルなロジックであるべきで、Time.zone.nowみたいに値が変わるものを使うのは良くないことです。

よくある反論

よくある反論は、「現在時刻使っておけばいろんな日付が試せるから潜在バグを洗い出せるよ」です。

甘えるんじゃねえ！

その潜在バグとやらが自分の手元で見つかるのならともかく、わけのわからんタイミングで爆発して始末させられる方の身にもなってください。

境界値が不安なのであれば、自分でテストを書きましょう

  it 'contains remaining days' do
    let(:date) { Date.new(2019, 1, 28) }
    expect(remaining_days_of_month(date)).to match_array [29, 30, 31]
  end
  it 'return empty at the end of the month' do
    let(:date) { Date.new(2019, 1, 31) }
    expect(remaining_days_of_month(date)).to match_array []
  end

使っても良いケース

メソッド内に現在時刻が使われている場合、テスト側も現在時刻を使わざるを得ないケースがあります。
例えば、「今日以降の日付を配列で返す関数」のような場合です。

ただこの場合でも、こういう実装にしてあれば、現在時刻を使わなくてもテストすることができます。

# 指定された日以降の日付を配列で返す. 省略すると当日が使われる
def remaining_days_of_month(date = Time.zone.today)
:

この辺の実装の工夫について、下記が詳しいです。

「現在時刻」を外部入力とする設計と、その実装のこと

で、いろいろな事情によりそこまでやれない場合に、TimeHelpersで時間を固定した上で、Time.zone.now/Time.zone.todayを使うのは仕方ないかなあ、という感じですね。
specテストにおいて、固定しないTime.zone.now/Time.zone.todayを使ってよい場面は存在しません。

まとめ

現在時刻を使うことによって、月末だけ失敗するrspecバグを埋め込むパターンを説明しました。

いくつかのrailsプロジェクトを渡り歩いていて、このルールはあたりまえのように守られているところもあれば、どんなに説明してもご理解いただけないところもあったりして苦労しています。
この記事を示すことで誰でもわかってもらえるようになるといいなあ。

[twitter] url単位で検索に表示されなくなるURLバン現象についてまとめ

2019-07-10T21:56:27+09:00

シャドウバン類似の、URLバン問題

Twitterで、自分のツイートが検索に表示されなくなる、シャドウバンという現象があるらしいということがここ数年明らかになりつつあります。
Twitterのシャドウバン（Shadowban）は3種類！確認・対処方法を解説します | ナギサものおき

これはこれで問題なのですが、個人開発者の間で、これとは別に、URL単位で検索から外される措置があるのではないか、というのが話題になっています。

たとえばこれは、"news.yahoo.co.jp"の検索結果です。当然、ヤフーニュースの記事について言及しているツイートがたくさん出てきます。
https://twitter.com/search?f=tweets&vertical=default&q=news.yahoo.co.jp&src=typd

一方、旅のクイズサイトKoretteの検索結果はこちらです。
https://twitter.com/search?f=tweets&q=korette.fun&src=typd

検索結果一件！Koretteはそんなにマイナーなサービスなのでしょうか？違います。

このツイートも出てきてないし、

【正解しました！】札幌ドームにおいて音楽イベントを初めて行なったアーティストは？ https://t.co/0XTEGA68Dt #Korette #北海道 #札幌市 #札幌ドーム
— nami (@nami88798557) 2019年7月9日

このツイートも。

「上川町とかみっきーに詳しくなれるクイズ」7問中7問正解(正解率100％)でした。全問正解、すごいぽわん！ https://t.co/pR42tky0cR #Korette #上川町とかみっきーに詳しくなれるクイズ
— 黒らべる (@yu1020beer) 2019年7月5日

ぼくのツイートも。

ちなみにこれのクイズも作りましたhttps://t.co/3NVMQLhvzQ
— もぎゃ🔌(daisuke furukawa) (@mogya) 2019年7月9日

いずれも、https://shadowban.eu で確認する限り、shadowbanされていないアカウントです。Koretteと無関係なツイートについては普通に検索結果に表示されます。

さらに、ツイートにつけてあるハッシュタグ #札幌開拓クイズについてはこの惨状です。

このことから、おそらくURLやキーワード単位で検索結果を表示させない制御が働いているのではないかと考えています。

これは個人開発者にとってとても痛いです。
URL単位で検索することは、サービスについて感想をツイートしてくれているユーザーさんを見つける有力な手段だからです。これは推測ですが、おそらくトレンドなどにも出なくなっているので、サービスを知ってもらう重要な武器を一つ失っていることにもなります。

傾向と対策

個人開発者がたくさん集まる運営者ギルドに集まる開発者たちが、自分たちのサービスを次々にBANされて泣きそうになりながら学んだ傾向としては、次のようなものが上げられます。

当然だが、サービス開始直後はBANされていないので、普通に検索することができる
サービス開始後数日くらいで、順調にユーザーが増えてきたと思ったら突然検索できなくなる
一度適用されると、解除してもらう手段はない。何人もの開発者が問い合わせを試みましたが、一度も解除に成功したことはありません
サービスごと移転してドメインを変えれば復活できるけど、またBANされる可能性も当然ある
「結果をシェアしよう」みたいな機能で、類似度の高いテキストにURLとハッシュタグをつけてツイートしてもらうと、ほぼ確実にBANされる
.fun は .comに比べてBANされやすい、という説がある(たんにURLが変わってそれ以降はBANされずに済んでいるだけの可能性もある)

これでようやくtwitterでタグ検索ができるようになった。旧ドメインはどうやら.funのTLDがダメだったぽい。ツイッターから完全にurlじゃないもの扱いされてた。メジャーじゃないTLDは地雷という学びを得た。
— れとるときゃりー (@retoruto_carry) 2019年1月1日

[知見] サービスからゲーム結果などをツイートしてもらう場合は、URLをそのまま書かずにbit.lyで圧縮してからツイートしてもらうようにすると、BANされないぽい
- 今話題の #本田とカードバトルもbit.ly圧縮を使っています

たんにみんなの感想を見るだけであれば、Yahooリアルタイム検索で探すのが現実的な回避手段
- 「korette」のYahoo!検索（リアルタイム）
まとめ
TwitterはURLとハッシュタグをつけたツイートをしてもらうと、そのURLやハッシュタグ単位で検索ができなくなる URLバンとでも呼ぶべき現象が存在する
Twitterの中の人、見てたらなんとかしてください。ぼくらはTwitterのユーザーが楽しめるサービスを作って楽しんでもらっているのに、どうしてこんな仕打ちを受けないといけないのですか
運営者ギルドでは、こんな情報も含め、サービス開発をする上で必要となる宣伝や運営などの知見を交換したり、相互にバグだしを手伝うなどの活動を行っています。自分のサービスを運営している人なら誰でも参加できますので、個人開発者の方、ぜひ参加してください。

コードレビューありがちな問題への対処例

2019-05-24T21:12:29+09:00

コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。

指摘事項について

よくある話
- 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない
- 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう
- 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう

この辺はみんな知ってると思うので略。ぼくが思う大事なルール

コードレビューで指摘された内容は、対応必須ではない

理由：対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。

絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがありうるよね。そういう指摘ができなくなる対応必須ルールはみんなの成長を阻害するのでやめたほうが良い。

Q：なんでも指摘を無視してリリースできちゃう？
A：そういうことにはならない。"Approveについて"参照

Approveについて

レビューアーは、「このPRがプロダクトにマージされて良い」と思えばapprove(👍)をつける。これが一定数集まったらリリースしてOK、というのが一般的なルール。

レビュアーの行動

approveだけする

問題ない。でもできれば、ちょっと感想とか、「こういう観点で見ました」「こういう点が気になったのでチェックして、問題ないことが確認できました」みたいなコメントがあると、あとからレビューする人は別の観点からチェックすることができて嬉しい

approve＋コメント

単なる感想とか、気になるけどまあ直さずにリリースしてもいいでしょ、程度の問題のとき

approveせずにコメント

この指摘を直さないのなら自分はリリースに合意できない、という意思表示。
ただし、approve数のルールによっては、自分が合意しないけどリリースされることはありうる。絶対ダメなコードについては強く指摘して他の人の注意をひこう

5/29 追記 Twitterで指摘いただいた。絶対ダメなコードはこれで止めるのが良いね。

GitHubのプルリクには "Request Changes" というものがあるので、リリースに合意できないときはコメントだけじゃなくて "Request Changes" を使うと良い。 https://t.co/NDWUEIyVGL
— 神速 (@sinsoku_listy) 2019年5月27日

Approveいくつ問題

そんなルールのもとで、いくつapproveを集めたらリリースしていいことにするか

一人合意すればOK

一定数までは、リリースに必要な合意数とコードの品質は比例するので、一人だと品質が微妙になる。
でも、スタート直後のベンチャーなんかだと、スピードを優先して一人合意にするのはアリ。あと、CTO的な人がいて、その人が合意したらOKというパターンもある。
１０人もいるのに一人合意でOKにすると、いい加減なOKを出すやつが出て致命的な問題が見逃されるリスクが出てくるので、もうちょっとしっかりやりたい

全員合意

あまりおすすめしない。少数ならやっても良いかも知れないけど、１０人のチームでこれをやると、それぞれ９人分のPRを見ないといけなくなって死ぬ

２－３

これくらいがおすすめ。このやり方のキモは、合意を集めるためにある程度の指摘に対応しないといけないこと。

「指摘事項について」で書いたとおり、指摘事項は無視ができる。そのかわりレビューアーは、「直さないのだったらapproveしません」権を持つ。
レビューしてもらう人は、approveを集めるために、ある程度の指摘事項には対応しないといけなくなる。結果的に、一人厳しすぎる人の指摘はスルーできるけど、みんなが駄目だと思うような項目はスルーできなくなる

マージボタンを押す人問題

合意を集めた後、誰がマージボタンを押すか問題。
誰でも良さそうな気がするけど、いろいろ妙味があるので、これも決めておいたほうが良い

特定の人が押す

チームのリーダー的な立ち位置の人がいて、その人がマージボタンを押す。
当然その人は全部のコードに目を通すことになるので、プロダクトについてほぼ何でも知っている人みたいな位置になる。

そういう人がいるとみんな頼もしいし便利なんだけど、その人の負荷はとても高く、退職したり爆発四散してしまったりするとプロジェクトが一気にピンチに陥るので、初期のベンチャー以外ではあまりおすすめしない。

別案として、プロダクトオーナーみたいな人が押すという手もある。技術的に深く理解している必要はなくて、「エンジニアがみんな合意してるから大丈夫だろ」みたいな感じで押す。どんな機能が導入されたかプロダクトオーナーが把握できるのがメリット

レビュイーが押す

レビュイー、つまりPRを作ってレビューしてもらう人がマージボタンを押す。とてもおすすめのルール。

このルールのポイントは「👍が集まったら、マージボタンを押しても良い」にしておくこと。つまり、「👍集まったけど、この機能にとても詳しいAさんにも見てほしいからもうちょっと待とう」「👍集まったけど、この指摘は重要なので対応しておきたい」というようなことが出来る。
逆に「いまはスケジュール的に押しているから、最低限の👍でリリースする」という判断もありうる

ひよっこ問題

駆け出しエンジニアみたいな人がいて、普通のコードレビューが成立しなくなる問題に対する対処

甘すぎるapprove問題

👍一個でリリース可能で、ひよっこが合意したらそれでリリースできてしまう、みたいな問題。

放置してしまうと「責任が取れないからapproveしない」みたいな遠慮をすることになってしまって、成長のためにとても望ましくない状態になる。ひよっこが👍したあとで先輩から厳しい指摘がついて「そういうところを見るのか！」ってなる方が良いですよね。

必要な👍数を増やすという手もあるんだけど、「マージボタンはレビュイーが押す」ルールの導入がおすすめ。これがあれば、「彼の合意だけでリリースするのはまずいのでもうひとり見てくれるまで待とう」というブレーキをかけることが出来る。
逆に、「些細なPRなので彼一人でも良いだろ」という判断もできて、柔軟な対処が可能になるのもうれしい。

レビューが成立しない問題

ひよっこの書いたコードがアレすぎて、
- どこから指摘していいかわからない
- 指摘が大量について対処できなくなる
- ひよっこの心が折れちゃう

等に関する対応。

「PRを出す前に、隣の人にチェックしてもらってください」がオススメ。メンターさんとか教育係でもいいし、持ち回りでもよい。

巨大PR問題

リファクタリングとかで、何十ファイルにも及ぶ巨大PRができてしまって誰もレビューできなくなる問題

分割する

approveをあつめるのはレビューイーの責務なので、見てもらえる程度のサイズに分割して小さなPRに分ける。

理想的なんだけど、大変な修正をしたのにPR分割しろと言われると、心が折れちゃうよね...

説明会

時間を決めて会議室にあつめたり、オンライン会議をして、コードについてみんなに説明する場を持つ。その場で質疑応答して、最後にみんなの合意をもらうことで、approveの代わりにする。

まとめ

過去いくつかのプロジェクトでコードレビューして、これは良かった、これは辛かった、というノウハウを書いてみました。~~いかがでしたか~~ これが絶対のルールというわけじゃないので、うちではこうしているとかあれば聞かせてください。

VSCodeのRemote Development機能が革命的な話。

2019-05-04T10:08:55+09:00

背景

今月始めにMicrosoftからRemote Development Extension Pack. というのが発表された。簡単に言うと、VSCodeでコードを書くOSとプラグインが実行されるOSを別にすることが出来る。

よくあるパターンで、「MacでNokogiriがビルドできません」「WindowsでESLintを実行するにはどうしたら良いですか」みたいな質問がある。
最終的にサービスを公開するときにはどうせLinux使うのに、開発するときしか使わない別のOSで同じものを動かす苦労って無駄だよなあ、と思っていた。

じゃあ最初からLinuxで開発すればいいかというと、最近の高度化したWeb開発はIDEの支援なしに実行することが困難で、RubyだったらRuboCop、JavaScriptだったらPrettierやESLintで文法チェックしてもらわないと人類にはついていけない。これらを動かすためには開発環境をIDEと同じOSで動かす必要があって、そのためには上記の質問に悩まないといけない...というのが実情だった。

そういう悩みを解決するのが、VSCodeのRemoteDevelopmentだ。VSCodeはWindowsやMacで動かしつつ、SSHやDocker、WSLなどで動作するLinuxマシン上にあるソースコードを編集し、linuxマシン上でプラグインを動かすことが出来る。つまり、Windows/MacにはVSCodeさえあればよくて、ほかは全部Linux上で実行することが出来る。もはやNokogiriのビルドに悩む必要がなくなる！

やってみた

インストール

やり方はここで解説されている。早速やってみた。
Remote Development with VS Code

Remote Developmentはまだベータ版の機能なので、実行するためにはInsiders というβ版を使う必要がある。これは既存のVSCodeとは別のアプリケーションとして動作して、既存の環境を壊さないのでむしろ便利かも。

インストールが完了したら、ExtenstionsからRemoteDevelopmentをインストールする。ブラウザで開いてInstallクリックすると既存のVSCodeの方に入っちゃうので注意。サイドバーのExtenstionから「Remote Development」と入力してインストールする

マシンに接続

Linuxマシンに接続する方法はいろいろあるけど、今回は既存のマシンにlinux接続することにした。Ctrl+Chift+P でコマンドパレットから"Remote-SSH: Connect to Host"を実行

WindowsのPuttyで接続を管理していると、その設定ファイルの内容をインポートしてくれる(！)

ハマりポイント：Linux側にtmuxが入っているとうまく接続できないので、bash_profile編集して外して上げる必要がある。

接続完了。Open Fileを選ぶと、linuxマシン上のファイルを編集することになっている。

プラグインを使う

ここまではSSH経由でファイルマウントしたりする機能を使えばできないこともなかったので、今までできなかったことに挑戦。

ExtenstionからESLintとPrettierをインストール。WindowsのVSCodeからインストールしても、linuxで実行したほうが良い機能はlinux側にインストールされる。なにそれすごい...

設定から、Format on Saveを有効に。

で、こういう許されないJavaScriptを書いて保存すると...

勝手に整形される。ぼくらが夢見ていた機能！WindowsにはVSCodeしかインストールしていないのにlinuxの機能が使える！

Prettierだけだと、ぶっちゃけlinux上で上書きされたファイルを読んでるだけのような気もするので、あとでESLintも試してみよう

まとめ

ということで、WindowsにインストールしたVSCodeからlinuxの開発ツールの支援を受けつつコードを書くことが出来るようになった。

さいきんMacイケてないと思わない？とかっこいいこと言ってSurfaceに移ったのだけど、パワー不足で仮想マシンを使うのが辛かったり、hyper-Vでlinux動かしてもESLintが使えなかったりして、やっぱりMacに戻らないと駄目かなあ、もうちょっとなんとか...と思っているところだった。

RemoteDevelopmentがあれば、ネットの向こうで実行しているlinux VPSに対してVSCodeの各種支援機能を実現することが出来る。こうなってしまえば、もはやWindowsであれが動かないこれが動かないと悩む必要がなくなる。

数年前まで、開発マシンをインターネットの向こうに置くと、通信環境が確保できないと開発できないのがネックだったんだけど、最近どこでも無線LAN使えるし、テザリングもあるので、SSHでつなぐ程度の回線で良ければほぼ人権レベルに確保できるようになってきた。

この先５Gのモバイル接続が普及すれば、インターネット上で開発する動きはますます加速することが予想される。そういう予想のもとに提供されたのがAmazonのCloud9だったんだけど、MicrosoftはVSCodeという強力なツールに機能を追加することで同様の機能をよりスマートに実現してみせた。

GitHubの買収、TypeScript、VSCodeの提供と、あっという間にWEB開発の主流を抑えつつあるMicrosoftが、唯一ネックだったIDEの実行環境を埋めるツールを出してきて、最近のMicrosoftはイケてるよね。