Diary

@ssig33

泥酔

14 Feb 2018 Wed 14:28

死んだ人の悪口を書こうと思い書き始めたら長文になってきた

11 Feb 2018 Sun 14:26

ゴリラ

11 Feb 2018 Sun 14:23

CDN がネガティブキャッシュもしてほしい

08 Feb 2018 Thu 11:36

マンガは売れなくなったのか? ということが気になっていて、検証してみた。

ソースは以下の 2 点

紙の単行本

2016 年

紙のコミックス(単行本)が同7.4%減の1,947億円

2017 年

コミックス単行本が約13%減と大幅に減少しました。

ということなので 2017 年のコミックス単行本の売り上げは 1,694 億円。 253 億円減少。

電子の単行本

2016 年

電子が同27.5%増の1,491億円

2017 年

内訳は電子コミックが同17.2%増の1,711億円

220 億円増加。

すくなくとも単行本については「紙が売れなくなった分電子が売れている」という以上の話ではないように思います。少なくとも出版、最後の砦マンガ沈む 海賊版横行で販売2ケタ減 というような話はウソの類いでしょう。海賊版が横行し、メディアミックスも不発の中着実に紙から電子書籍への移行が進んでいるという状態だと思います。

雑誌は、どうなんでしょうね。こっちは 2017 年の分析見る限り確実に落ちていると思われます。こういう状態ですので「暇潰しコンテンツについては確実にスマホコンテンツに客を取られているが、じっくり金払ってマンガを単行本で読む層は増えも減りもしていない」というのが正確なところだと思います。

30 Jan 2018 Tue 18:23

最近仕事ばっかしていてよくない

30 Jan 2018 Tue 12:45

Heroku でのスケジュールタスクの実行(Rails の場合)

Heroku ではいわゆる cron 的なことをしたい人のために Heroku Schedulerというものが用意されています。

ですがこれはかなり問題の多いプロダクトで、シリアスな業務で用いるにはいろいろと厳しいです。まず設定 UI が非常に貧弱で、設定ミスをしても気付きづらいです。またセッション管理の点にも問題があり、自分がいじってるつもりと別アプリの設定をいじってしまうという事故はわりとよく起きます。

そして最大の問題ですが、公式のドキュメント

Scheduler job execution is expected but not guaranteed. Scheduler is known to occasionally (but rarely) miss the execution of scheduled jobs.

とある通り実行されるかどうかは無保証です。実行漏れは「rarely」だと書かれていますが、実感としてレアかどうかと言われると、ガチャのレアぐらいのレアさだなと思います。ユビレジの場合酷いときはまいにちなにか抜けてリカバリーを開発者が手動でやるなんてことをやってる時期がありました。

そこでドキュメントには

If scheduled jobs are a critical component of your application, it is recommended to run a custom clock process instead for more reliability, control, and visibility.

とありますのでこの行き方でやっていく必要があります。ようするに計時専門の Dyno を立ててそこで自前で cron 的なことをしろってわけ。 Rails の場合 resque-schedulerはよい選択肢です。設定がコードになってリポジトリに入れられるのも非常によい(デプロイターゲットに応じてこのあたりの設定をいじりたいとかなってくると欠点として認識されることもあるかもしれませんが)。

ところで Heroku の Dyno は最大でも 24 時間しか連続起動してくれません。また CLI から restart かけただとかデプロイしたとかで頻繁に再起動されます(ユビレジでは一日数回〜数十回のデプロイが行なわれます、最近ではわりとどこの会社もこんなかんじですよね?)。そうなるとその再起動のタイミングで resque-scheduler がなにかすべきだった!!!みたいなときにデプロイが走ったりすると実行漏れが起きます。体感ですけど heroku scheduler のときの半分ぐらいの頻度でこれらが原因となって実行漏れが起きました。

resque-scheduler はこういうことを想定して作られており

You may want to have resque-scheduler running on multiple machines for redundancy. Electing a master and failover is built in and default.

とあります。 Heroku でこれを活用したいときはわりと話は単純で

heroku scale scheduler=2

とかするだけです。ところが

Precautions are taken to prevent jobs from potentially being queued twice during failover even when the clocks of the scheduler machines are slightly out of sync (or load affects scheduled job firing time).

ともあり、 resque-scheduler を複数プロセス実行している場合に重複実行されるケースがあるようです。今のところユビレジでは重複実行されて致命的な事態となりうるジョブがあまりないためこの問題への対処は手をつけていません。ただしユビレジからのメールが二通届いてしまうなどという事態が稀に生じていることは確認されており、頻度次第ですが今後対処を行なう必要があるとは思います。

対処法としてはアプリ側でもう実行済みかどうか確認してハネるみたいなのが必要でしょう。実はユビレジでは一部のジョブでそれが導入されています。というのも Heroku Scheduler 時代に「1 時間に 1 回のタスクがたまに抜けるなら 5 分に 1 回実行して、アプリ側で重複実行だったら弾けばいいんじゃない?」みたいなのが導入されたからです(なおこれは多重実行されて困る系のタスクではなく、重いので実行されまくると困るというタイプのタスクでした)。

Heroku 公式のドキュメントにも説明あるし、いろいろとツールも揃っているのですが、なかなかこういう話を日本語で見聞したことがないので書いておきました。

25 Dec 2017 Mon 17:03

このサイト HTTPS 対応 + HTTPS 強制にした のだが、いろいろやりかた考えた結果 Cloudflare に金払うのが一番楽ということでそのようになったのだが、完全に Cloudflare に依存する人生という感じで危ないですね。

04 Dec 2017 Mon 16:04

優秀なプレイヤーを管理職にするなとかよく言うけど すくなくとも俺はプレイヤーとして自分よりダメな奴に管理されたくないんだよな。いいコーチはかならずしもいいプレイヤー出身じゃないとかよく言うけど、それは横綱クラスじゃないという話であって幕下の奴がいい親方になるのか?優秀なプレイヤーを十分集めてそのなかから管理職をやりたがっててかつその能力のありそうな奴を管理職にするべきなんじゃないのか。

02 Dec 2017 Sat 14:59

Nahoruru

28 Nov 2017 Tue 22:28

かに

22 Nov 2017 Wed 18:00

CDN 最高

22 Nov 2017 Wed 18:00

と思ったらうまくいくようになった、、、

18 Nov 2017 Sat 16:38

CloudFlare の purge が API 経由でうまくいかなくて困ってる

18 Nov 2017 Sat 16:38

ねむい

17 Nov 2017 Fri 16:18

修正すべきことは多分 1 行とか なんだけど、

  • 問題を理解すること
  • 影響範囲を明らかにすること
  • 分かった影響範囲に対してテストコードや人力 QA の手順を確立させること

みたいなところで膨大なコストがかかる作業をしていて、なんでかまあそれの仕切り役の一人みたいになっている(なぜかといえば職務がそういうことのリーダーシップをとることというようになったからです)。

ここでまあ問題はなにかというと「問題を理解する」のに莫大な手間がかかってしまう原因がなにかといえば、理由はまあいろいろあるんですが、その一つが俺が昔書いたコードがアレというものだからです。

我々は常に過去の自分の影と戦闘することになるのだが、今や我々のチーム力は過去と比べものにならないくらい大きいので、僕以外の人が一番厳しい部分をやってくれている。これはいつ殺害されてもおかしくない状況なので緊張感がある。

16 Nov 2017 Thu 18:36

コーヒー豆の量規定の 2 倍にしたら全然うまくなくて、規定量の正しさを感じる

16 Nov 2017 Thu 17:43

かに

16 Nov 2017 Thu 16:54

Web アプリの非同期処理に goroutine 使う の多分だめだと思うんだけどわりとみんなやってるしもうあんま気にせずやっていくことにしてくという気持ちになってきてる。

失敗してもいい非同期処理ならまあこれでもいいのだろう、、、

16 Nov 2017 Thu 16:50

頭痛い、、、

16 Nov 2017 Thu 16:47

dev.to には勝ってた

このサイトは速い

もう 1 か 2 スコア上げて阿部寛もぶち抜きたい

16 Nov 2017 Thu 02:32

日本の店舗でクレカ普及しないのってリボ払いが普及しないせい で結果としてクレカ会社が儲からないから手数料に転嫁されるせい、というのはみんなよく言ってる。

じゃあリボ払いが普及しなかったのがいいことだったのか?というとそれはどうなんだろう。貧しくて資産がなくても資金繰りさえ回ってればまあ生活はできるわけで。毎月ごとにクレカの支払い方法と借金の借り換えで苦労するアメリカ人みたいなの、大変なんだろうけど、そこでクレカという金融システムがなければ彼らが生活を維持できる時間は格段に短くなる。

市民社会の成立にはそういう金融システムというのは不可欠な要素だと言えるのではないか。では現代日本でクレカとリボ払いという要素が受け入れられなかった結果何が起きたかといえば、ロードサイドに立ち並ぶ質屋であり、そして今雨後の筍のようにボコボコと出てきている怪しげは「フィンテック」アプリであろう。これらが最悪なのが「金融サービスである」という理解をされないまま人々に利用されている点であり、特に「フィンテック」界隈に顕著だが意図的に騙しにかかっていることだ。

「これは借金である」という認識をみんながちゃんと持って、クレカのリボ払いに苦労してる社会の方が今と比べればなんぼかマシだったんではないかと思う。

08 Nov 2017 Wed 16:22

glide 捨てて dep に引越した

30 Oct 2017 Mon 16:30

k8s に転居した(このサイトは Heroku だが)

23 Oct 2017 Mon 23:19

全部クライアントサイド JavaScript で実装されててメモは Google Drive に保存される Markdown メモツール作った。

https://memopad.ssig33.com/

以前から自分専用に使ってたメモツールがあったのだが、これにつかってた MySQL が落ちて、その MySQL の復帰のしかたはメモツールにしか書いてなかったみたいな頓知みたいな事態が起きてキレて作った。

バックエンドを自前のサーバーからクライアントサイド向けの Google の API Library に置き換えるだけなのでわりとシュッと出来てよかった。 React のおかげで本当にこういうのはめちゃくちゃ簡単になった。

HTML と JS は S3+Cloudfront でデプロイしている。これでやってる。

サイトの説明にも書いてるけど、あらゆる機能がクライアントで動くように実装されているのでセキュアかつ動作を検証可能です。

23 Oct 2017 Mon 15:45

salesforce の導入 で厳しい事態みたいな話よく聞くんですけど、まあ原因は二つだろうと思っている。

まず開発環境が厳しいという話。 salesforce と apex をガリガリやってましたみたいな転職希望者と話す機会が多いのだが(というのも働いている会社で salesforce と apex が分かる人を探しているからである)、彼らの希望は一貫している。 salesforce に関わらないこと、をとにかく希望している。

これはまあどうにもならないんだけど金(だけ)で解決する話でもある。金さえあれば apex 書くって人いるでしょ。

もう一つはこれが本質的に超高難易度の SI であるということ。 CRM の導入、メンテというのはそれ即ち経営の最高判断であるはずで、 SIer 出身者であればみんなそんなことは知っている(俺は SIer 出身者ではなくクソ映像業界出身者だ)。しかし、 SI の知識のない人達が、メールは G Suite 使いますみたいな感じであまあまでやって失敗している事例を本当によく見る。

CRM に関する知識と業界の知識と企業特有の業務知識に精通した上で、既存の業務をどのように salesforce 流の業務にコンバートしていくのか。それによって発生する余剰の人員の再配置をどう手当するのか。これらの問題に対処できるのは決断力に優れた経営者だけなのだが、実際には大した権限を与えられていなエンジニアが少ないリソースで作業をして、訳のわからないことになっていく。

19 Oct 2017 Thu 16:21

Slack で大きい絵文字を簡単に作る という遊びがあります。

スクリーンショット 2017-10-10 14.34.53.png

こんなん。画像を 4x4 で 16 枚で分割して

:yos-1-1::yos-2-1::yos-3-1::yos-4-1:
:yos-1-2::yos-2-2::yos-3-2::yos-4-2:
:yos-1-3::yos-2-3::yos-3-3::yos-4-3:
:yos-1-4::yos-2-4::yos-3-4::yos-4-4:

みたいな感じで貼るわけです。

スクリーンショット 2017-10-10 14.34.16.png

とか

スクリーンショット 2017-10-10 14.34.45.png

中身としては 16 枚の絵文字なので適当に差し替えて遊んだりできます。

Kobito.7WlpYO.png

とか。

これを手で作るのはだるいので簡単に作る方法です。

画像の用意についてはこれを読んでください。

そのようにして画像が用意されると、これをアップロードしないといけないのですがこれを手でやるとだるいです。そこで emojipacks という悪魔のツールを使います。

emojipacks は以下のような yaml があれば一括で絵文字を登録してくれるという便利ツールです。

---
title: yame
emojis:
- name: yame-1-1
  src: https://s.ssig33.com/s/7da3f11bcf7a4062b12057a4a884f02b
- name: yame-2-1
  src: https://s.ssig33.com/s/391026804f5943bb8feaad01b1660c84
- name: yame-3-1
  src: https://s.ssig33.com/s/77a642d788a84a3fbc8c9ba4c4d35710
- name: yame-4-1
  src: https://s.ssig33.com/s/7202e75135624c67a09b32edb4e1084b
- name: yame-1-2
  src: https://s.ssig33.com/s/0516e5e9861248b4a348fbfa7dfbdd09
- name: yame-2-2
  src: https://s.ssig33.com/s/ea88903d5567426dbaf49138480f7d6b

こういう絵文字のデータは http でアクセスできるところに存在している必要があります。これを手でやるのはだるいので、適当に画像をアップロードする場所をなんか用意したうえで以下のようなスクリプトを書きましょう。

require 'yaml'
hash = {"title" => 'yame', "emojis" => []}

Dir.glob("sob*").sort_by{|x| x.scan(/d+/).first.to_i}.each_with_index do |s,i|
  x = i % 4 + 1
  y = i / 4 + 1

  src  = upload(s) # この upload メソッドはなんか各自の事情で実装したらいい
  hash["emojis"] << {"name" => "yame-#{x}-#{y}", "src" => src}
end
puts YAML.dump(hash)

あとは emojipacks で登録するだけ。

これを全部一括でうまいところやるようにしてガンガン巨大絵文字を登録できるようにしてもいいとは思うんですけど、まだそこまで自動化してません。

10 Oct 2017 Tue 14:42

Google Home は IFTTT と連携できるので それでオッと思う人は完全に買いだと思います。

Google Home => IFTTT => Webhook => IRKit みたいな感じで家電制御系は勝利していきますし、 Webhook あればまああとはただの Web アプリの世界なのでそこでなんでもできます。 API.AI もまあ楽しいんですが普通に何かする分にはたぶん IFTTT のほうがはるかに楽です。

08 Oct 2017 Sun 11:30

Twitter の凍結について思うこととしては 、これ本当に文化差が問題なんだろうなっていう。自分のまわりで Twitter の凍結でよくあるパターンが「あなたのアカウントは一時凍結されました、異議がある場合は正当性をアピールするメールを送ってください」みたいなあのメールが Twitter からきたときに「どうすればいいですか?教えてください」って返事してそのまま永久凍結になるってやつ。

これ何が起きてるかといえば、 Twitter 社のアメリカ人からしてみれば「正当性をアピールしろって言ってるのに質問で返してきやがったな、ナメてんのかこの野郎」っていう印象になってると思うんですよ。

たぶんここでの正解は「私は Twitter を n 年利用しており、 Twitter での情報発信でコミュニティと Twitter そのものへの貢献をしてきた。問題のある発言と捉えられたものがあるとしてもそれは友人との内輪のやり取りであるはずだ」みたいなのを送ることだろうと思うんですよ。

でもまあ日本人の多くが「正当性のアピール」だの「異議」だのを送れって言われてこうはならないだろうし、結果として即永久凍結ということになる。

02 Oct 2017 Mon 00:01

Next