Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

pay.jpでプランを変更すると変更前のプランの金額で決済される不具合(修正済み)に当たった

注意書き

以下の本文は情報だけを伝えようと書いています。 この文章は個人や企業を評価する意図はありません。

本文

pay.jp で定期課金のプランを契約期間中に変更すると、変更前のプランの料金で決済される不具合に当たりました。 この不具合は現在(2018/08/09)、修正済みです。

2018年7月ごろに、有料のプランから他の有料のプランへ変更する際に発生する不具合でした。 例えば月額5000円のプランから3000円のプランに変更したとき、元の料金を返金後に通常3000円で決済されますが、決済が5000円になっていたという不具合でした

昔からあったというわけではなく、新しく発生した不具合でした。 プランの返金は有効にしていましたが、発生したケースが厳密にはどういう場合なのか私には分かりません。

pay.jp にSlackから問い合わせし、不具合の修正とお客様への返金の処理を依頼しました。 このとき追加で問題が発生しました。不具合の対応用の返金をする処理に間違いがあったらしく、該当のお客様にさらに決済されるという問題も起こりました。この重ねての問題も現在は返金にて対応いただきました。

pay.jp は2016年春ごろから導入しており、現在2018年までの2年間で不具合は2件目です (サービスの障害やメンテナンスは除く)。

おわりに

私個人としてはpay.jpさんには今後も頑張って欲しいと思っています。 一緒に良いサービスを作っていきたいと応援の気持ちがとても大きいです。

改めてになりますが、今回の不具合によってご迷惑、ご心配をおかけした方々、申し訳ありませんでした。 pay.jpさんも対応いただきありがとうございました。

クラウドファンディングは支援(バック)するときが気持ちの最高潮なのかなと思った

www.kickstarter.com

クラウドファンディングは支援(バック)するときが気持ちとして最高潮なんじゃないかなって思ったという話です。

僕はクラウドファンディングが好きでKickstarterで色々眺めたり支援したりしています。 PebbleTime、PebbleTime2、HighPerformanceDjango、Magit、ガジェットっぽいものとかOSS系とかを見ています。

そのうちの一つ、以前DeusExAriaというプロジェクトを支援していました。 これはスマートウォッチに取り付けるデバイスで、腕の筋肉を検知してスマートウォッチの操作ができるというものです。

www.kickstarter.com

これはすごくないですか。

スマートウォッチを愛用している人であれば、ふと時計を見たときに簡単に操作するのであれば片手で済ませれば便利だなと思うと思います。 電車のつり革に掴まっているときなど、片手がふさがっているときは結構多いです。それを解決するDeusExAria、これはすごい、と。 支援したのは2年くらい前で、僕はPebble Timeが大好きだったのでそれと互換があるこの製品も支援しました。

支援したときはプロジェクトの支援を呼びかける動画を見返したり、ワクワクしていました。 Pebble Timeも最高でしたし、このとき気持ちの最高潮を迎えるわけです。

人間面白いもので、他に面白いことがあるとスッカリ忘れるものです。今になって完成した製品が届きました。

ただ残念なことにPebble用のリワードで支援したのに、そのPebble自体が死んでしまったのでAndroidWatch用の製品が届きました。 僕はスマートウォッチへの情熱を失っていたので、全く持って要らないものを手に入れてしまったことになります。 あー、なんとも悲しいスタートアップ支援、というお話でした。

ちなみに今はプロジェクト名が変わって Flicktek となっています。 このプロジェクトが成功したのは純粋に嬉しいのですが、僕の求めてたものとはミスマッチになってしまいました。

こんな感じで、クラウドファンディングというのは支援する瞬間こそが気持ちとしての最高潮で、プロジェクトが成功する瞬間や製品が届くのは2の次なのかなと思います (PebbleTime2はどうしようもなく成功してほしかったですが)。 クラウドファンディングは「何かを作ろう」とかのプロジェクトに、お金を払って応援する仕組みですよね。 そういう意味での支援したときが気持ちとして最高潮というのは間違ってないのかもしれません。

応援したい気持ちがあれば支援することはとても良いと僕も思いますし大好きですが、資産の流動性を失っている点や、失敗したときに返金されるかどうかは気をつけたほうが良いですね。 リワードがあっても自分の期待するものとは限りません。 自分の可処分所得というか、その中でも特に使って良い「寄付枠」みたいなものから使うと良いと思います(それにも増してクラウドファンディングは夢があって素晴らしいですが)。

技術書のクラウドファンディング PEAKS も僕もしょっちゅう見ていますが、支援貧乏にならないようには気をつけたいと思います。 見返りを期待しない程度に留めるのが良いのではないでしょうか。 そのほうが夢があって素敵ですしね。

Ubuntu18.04でIMEの切り替えが遅い気がしたのでibusからfcitxに変えた

Ubuntu18.04を使っていてIMEの切り替えがどうにも遅い気がした。 ほんの0.5秒程度もたくつ気がするレベルなんだけど、HTMLとか書いていると頻繁に英語と日本語の入力を切り替えるのでかなりストレスになっていた。

原因は分からないけど、とりあえずibusから馴染みのfcitxにすることにした。

Ubuntu18.04で、以下でインストール

$ sudo apt install fcitx-mozc fcitx-modules

次にターミナルから im-config を起動。 アプリケーションの「入力メソッド」でも良いです。

$ im-config

設定に従って「fcitx」に変更。 この辺も参考にして、既存の設定消したりもしてね。

kledgeb.blogspot.com

違いはかなり感じるんだけど、こんなに違うもんなのかな。 まぁ、早くなったならいっか。。

Ubuntu18.04はXなので、17.10みたいにWaylandじゃないから苦労はなかった。

blog.hirokiky.org

画面右上のメニューバーにもキレイに映ってるし良かった。

ツールやプロセスやメソッドも大事だけど、人や中身や見えない文化も大事だと思っている

僕はツールとかプロセスじゃない、人とか中身とか文化とか空気感みたいなのが大事だと思っている。 自分自身、エンジニアというか、ステレオタイプのThe工学の人間的な発想じゃないのは思ってる。

まず最初に。開発メソッドとかツール、プロセスっていうのは僕もすごく大事だと思う。 見えないものを形式知やプラクティスとすることで、誰でも恩恵に預かれるようになる。これはスゴいことだと思う。 考え方や「うまいやり方」をプロセスに落とし込んでおけば、より多くの人がよりよい仕事ができる。 例えば PyQ のチームでも匠メソッドでの要求開発をしていたり、いわゆるアジャイル的な開発スタイルを取っていたりする。

でも僕は、もっと人とか中身とかも大事だと思っている。プロセスみたいに見えてないけど、個々人とかチームの中にあるものが大事だと思っている。

どんなツールとかプロセスを使っていても、中で作ってる人の発想とかセンス的な何かで変わってくると思う。 良いチームでも遠慮しあってお互い言いたいことを言わなかったら妥協したものができると思う。 チームの信頼関係がなかったり変な競争があれば、どんなチームビルディングメソッドを使っててもダメだと思う。

例えばPyQチームだと僕はお互いに何でも率直に言うようにしている。チーム内で厳しい意見が出ることもある。 でも僕はその文化はすごい良いなと思う。やりにくいと思う人はいるかもしんないけど、製品には良いように働いてると思うし、僕はやりやすくて楽しいチームだと思ってる。 企画から自分たちでビジョンを追いかけて作ってるので、ちょっとでもブレるとすぐに要らないものになってしまう。 小さなチームなので、そうなっちゃえばすぐに続けられなくなって製品もチームも死んでいってしまうと思う (金銭的に生きながらえても、モチベーションもないゾンビプロジェクトになってしまうと思う)。

これはプロセスじゃなくて、PyQチーム内の文化だと思う。 「率直な意見交換が大事」って形式値化したり、意見交換を挙手制にしたりプロセスは作れると思う。 でも中の一人ひとりがどう考えて何を言って何を作るかですべては変わってくる。ここの部分に「中身」の大切さがあると思う。

僕は「プロセスが不要」みたいなことは一つも思ってない。ただ、プロセスとかメソッドは見えやすいので色んなところで語られるので、アンチテーゼとしてこの主張はしたいなと思ってる。 メソッドに対する中身、文化、空気感はあんまり語られないし、語られてもすぐ陳腐になっちゃう。まぁこの記事もただのエモ文章だと思う。 中身は毎度まいど新しくゼロから作らないといけないし、他にも転用できないものだと思う。だから見えにくい。

プロセスはそういうものを促進する触媒であったり、補正具にはなると思う。自転車といっても良いかもしんない。 それが超大事なのは僕も思う。人間の進化はツールの進化だと思う。でも、中身を無視しちゃいけないと思う。 データ構造が良くないとどんなプログラミング言語を使ってもうまくは書けないのと同じ。

そういうのは中身は毎日働く中で少しずつ積み上げていくしかないし、個人が人生の中で感じたものとか、触れてきた感動からくるものだからどうしても見えないと思う。

僕はどっちも大事だと思ってる。 でもツール、プロセス、メソッドが見えやすいからこそ、アンチテーゼとして人とか中身が大事だよっていうのは自分の中に持ち続けたい。

どこにでも通じる「これやったからうまくいった」ってことはないんじゃないかな。

軽いi7のノートパソコンにUbuntu入れたいならASUS ZenBook Flip S をオススメしたい

こんなノートパソコンが欲しい人にオススメしたい

  • Intel Core i7 第8世代(Kaby Lake Refresh)4コア
  • モリー16GB
  • 13インチ
  • Full HD
  • 重さ1kg
  • USB-C給電
  • Ubuntuがインストールできた
  • キーボードが悪くない

ASUS ZenBook Flip Sをオススメしたい

f:id:hirokiky:20180720183224j:plain

ASUS ZenBook Flip S、UX370UAをオススメしたい

スペックは上記の通り、8世代i7、メモリー16GB、13インチFull HD、1.1kg、512GB SSD、USB-C給電。USB-Cが2ポート。 何気に音も良い。

www.asus.com

Amazonのリンクはこれ。

見た目はぶっちゃけMacBook Airを模したもの。1.1kgは超軽い。 Airっぽいデザインはどうしても好きなんですよね。2008年の茶封筒の呪いがかかってる。

スペック的には、まぁ僕も、メモリー32GB欲しかったとか、1TB SSD欲しかったとかはある。 そこはSwap使うとか、そもそも1TB要らんよなとか思って妥協した(前のマシンは100GBのSSDだったから十分多い)

ぶっちゃけ、ついてるけど使ってない機能もある

「いやこれ要らないならもうちょい廉価なほう買うわー」って思うかもしれんけどね、 USB-C給電はマジ最高なんでオススメしたい。あとで話す

Ubuntu入るの?

ここ。ココ重要。 Ubuntu入れてまともに動くのっていうのは大事。ぶっちゃけPC買ってもそこはほぼ博打だからね。 ウン十万円の文鎮はホントにご利益もクソもないからね。

でも大丈夫、 デュアルブートUbuntu 18.04入りました

ただ ぶっちゃけインストールでハマったからこの記事読んで

blog.hirokiky.org

僕ほんとUEFIとか初めてで本当にハマったけど、なんとかアレコレ試してあっけなく解決したのでこれ見て。 他は何の問題もない 。もちろん何かあったら自分で解決してください。。

ただ指紋認証は動いてない。まぁ、要らないかなぁと思っている。 他はキーボード光ってるしWifiBlueTooth動いてるし良いと思う。 ファンが暴走したりもしてないし、当たり前にちゃんと動いてる。

Ubuntuだとディスプレイ変換のドライバーとかでダメなんでしょ?

大丈夫だった から安心してほしい。

純正で付いてきた「USB-C対HDMI、USB、USB-C」のハブは問題なく画面の表示もできた。 あと、下の 9 in 1 のハブでも画面出力もできた。すごい。

これはめちゃくちゃ嬉しかった。

ドライバーとかまた大変なのかなと思ってたので動いて嬉しい。 USB-Cの仕様には詳しくないけど、そういうものなの?

まぁ、こんな感じで、キーボード、マウス、充電用USB-C、HDMIをさして使ってる。

f:id:hirokiky:20180720172745j:plain

USB-CとUSB PDがすごい

USB-Cはすごい。給電できる(USB PDの)USB-Cポートあるノートパソコンがオススメ 。 僕も 「USB-Cだけって拡張性ゼロやん」とか思ってたんだけど、違う

USB-Cはぶっちゃけハブが繋げればそれで良い

拡張性の機能を、すべてハブに任せるのがUSB-Cだと気づいた。 家に帰ってくれば1つのポートにハブを繋げば良いだけ。 「HDMIさして、USBマウスとキーボードさして、充電器さして。。。」とかダルい。

USB-Cだけを1本させば良いようにしてこそのものだと思う。 1本で済むんだよ、すごくない。僕ここ最近で一番これに感動したよ。

ただ買ったハブにはHDMI1つしかついてないので、3つ目のディスプレイがさせない。 もう一個HDMIVGAのポートがあるハブにしたら良かったと思ってる。

とにかくUSB-Cと給電できるハブは良いし、Ubuntuでも動いてる。

USB-Cにさして本体にくっつけるThinkPadベーシックドックみたいなハブもあるけど、あれはナンセンスだと思う。USB-Cの意味ないと思う。

タッチパッドとかキーボードはどうなの

ASUS ZenBook Flip Sはタッチパッドは大きめです。感度も良い。ただタッチパッド全体で押し込んでクリックできないのは残念。 パッドの下部だけがクリックできます。タップでのクリックはできるけどね。 まぁ、apple製品じゃないってことを考慮したら、かなり良いレベルだと思う。 でもapple製品を期待すると3分の1くらいのレベル。

キーボードは「悪くない」くらい。この辺は店頭で確認してほしい。 このサイズのノートパソコンにしたら、しっかりしてる方だと思う。 ただ、ぶっちゃけ Enterキーが入りにくい 。そこはかなりイマイチだと思う。 「跳ね返りが強すぎて疲れる」みたいなことはない。その点では十分良いキーボードだとは思う (メインで使う家だと外部のキーボード使うし)。

充電持たないんでしょう?

まぁ、カタログだと8時間と言ってるけど、Emacsでプログラミング + Dockerでアプリサーバー起動などしてると5、6時間くらい。 JSとかCSSも頻繁にビルドしてると5時間ってところかな。

十二分にあるとは言えないけど、まぁカフェで仕事するなら充電器はいらない。その前にルノアールなら緑茶がいっぱいになる。

でもお高いんでしょう

秋葉原ヨドバシカメラで193,160円。

f:id:hirokiky:20180717121546j:plain

Amazonも同じくらい。

強さ的には新しい(2018年モデル)13インチMacBookを強くした程度のマシン。 TouchBar付き、i7、メモリー16GB、SSD512GBにすると27万5000円になります。 値段的には7,8万円違うくらい。「Macより半額」とかじゃ全然ない。

なので、GNU/Linuxディストリビューション使えないとか、macが良いと言うなら普通にMacBookPro買ったほうが良いと思う。 13インチで32GBモデル、TouchBarなしモデルでアップデートされてたなら僕も超買ってた。

僕はヨドバシのポイントカードが溜まっていたので15,6万円で買えてしまった。 あとこれを買ったときのポイントで、先述のハブ(1万円くらい)は買えてしまったので良かった。

もともとASUS ZenBook 14っていうのを買おうと思ってたんだけど、店頭で触るとイマイチだったのでグレードを上げてFlip Sにした。 店頭で触るのはめっちゃ大事だね。

充電器も買うと良いよ

ZenBook Flip Sに充電器が付いてくるけど、もう一つあったほうが嬉しい。 このCheeroの充電器が USB PD対応で、45W(20V/2.25A)が使えるので充電できる

ケーブルはこれを使っている。ケーブルの長さは1.8mあれば十分かな 勉強会とかに行って充電するときとか、新幹線で充電する時も1.8mあれば十分

一つだけだと何かと面倒なので、充電器は買い足しておいたほうが良い。

余談、前のマシン、X220も良いよ

今まで長いとこThinkPad X220を使ってたんだけど、これもオススメはしたい。

f:id:hirokiky:20180720182301j:plain

換装すればメモリー16GBまで認識したし、SSDも載せればでっかくできるし、Ubuntuは問題なく動く。 キーボードはセパレートじゃない古き良きキーボードで打ちやすい。 CPUもi5の第2世代なので、性能的にはそこまで悪くない。ただ電力をめちゃくちゃ食うので1,2時間しかバッテリーは持たない。

メルカリで1万6000円で買った。

ただ、やっぱり古いとノイズが多かったりディスプレイが貧相だったり、i5の2コアというのが物足りないとこだった。 JavaScriptとかCSSとかバリバリビルドするので、LLでWebだからCPUそんな要らないってことじゃなくなっちゃった。

ASUS ZenBook Flip S良いよ

買って5日ほどかな、仕事でもバリバリ使ってるけどとても良い。 i7マシン買ってUbuntu入れたい人は参考にしてほしい。こういう情報はなかなか出にくいし伝えたいと思った。

良いUbuntuライフを。

他のオススメ記事

blog.hirokiky.org

Djangoで親の親のモデルを1クエリーで取る

Djangoのモデルから親のモデルを取ると(select_relatedなどしていないと)1クエリー実行されてしまいます。 以下のように、親のさらに親を取ろうとすると2クエリー実行されます。

me.parent.parent

me.parent の時点で1クエリー実行されて、 parent.parent の時点で2クエリー目が実行されます。 各クエリーでは親の全カラムの値も取るので、親の親だけが必要な場合は効率が悪いです。

この場合、以下のように子供の子供のIDを指定して取るように置き換えると1クエリーで取れます。

Grandpa.objects.get(children__children__id=me.id)

ObjectDoesNotExist とか MultipleObjectReturned には気をつけて。

DjangoのField.__init__ でクエリーしてはいけない

動的にフォームの choices の値を作りたい場合など、フォームの内容のためにクエリーすることはよくあると思います。 でも、フィールドの __init__ でクエリーしてしまうコードを書くとインポート時に実行されてしまうので注意が必要です。

ダメな例

class FoobarChoiceField(forms.ChoiceField):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

        self.choices = [(foobar.name, foobar.title)
                        for foobar in Foobar.objects.all()]


class HogeForm(forms.Form):
    foobar = FoobarChoiceForm()

理由

フィールドの __init__ はインポート時に実行されてしまうので、インポート時に(上記の場合Foobarへの)クエリーが実行されてしまいます。 インポート時にHogeFormが作成されて、FoobarChoiceField.__init__ も実行されます。 choicesがリストの場合、そのままクエリーも実行されてしまいます。

マイグレーション時(DBが作られる前)などに実行されてしまうとFoobarに対応するテーブルがまだ作られていないのでエラーになります。 また、サーバー起動時にクエリーされる場合、DBに変更があってもchoicesの値が変わらなくなってしまいます。

直す例

Django1.8からchoices指定にcallableを渡せるので、callableにしておきましょう。

class FoobarChoiceField(forms.ChoiceField):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

        self.choices = lambda: [(foobar.name, foobar.title)
                                for foobar in Foobar.objects.all()]

もちろん、フィールドを作らない場合はFormでやってもOK。 まぁFormの __init__ は(普通に書く分には)インポート時に呼び出されないので、1.8以前のように __init__ で choices を作るように書いてもOKです。

class HogeForm(forms.Form):
    foobar = ChoiceForm(choices=lambda: [(foobar.name, foobar.title) for foobar in Foobar.objects.all()])