PayPayガチャに挑戦してみる

paypay.ne.jp

御多分にもれず、ビックカメラにてPayPayガチャ、いわゆる全額相当のキャッシュバックがつくかに挑戦してみた。なお、商品はこちら。

いつもカミソリを使ってるけど、やっぱり朝のバタバタしてる時とかにささっと剃りたいこともあり、ちょっと前から電動シェーバーが欲しいなーと思っていたので、他の人からも評判が良かったラムダッシュの5枚刃をチョイスしてみた。

京都だと京都駅前にビックカメラヨドバシカメラがあるのだが、品揃えや商品のみやすさに関してはヨドバシカメラに軍配が上がり、ここ最近ビックカメラは全く利用してなかったのだけど……久々に行ったビックカメラはかなりの混み具合。レジには人が並んでいてかなりの時間待たされている人もいたり、また店員に商品のことを聞こうにも捕まらないという状態で、購入までかなり時間がかかってしまった。念の為ヨドバシの方でも、該当商品の値段などをチェックしてたけど、基本変わらずこれならビックでPayPay支払いの方が得だねということで購入。

結果としては20%キャッシュバックでまあ全額相当にはならなかったけど、支払いの体験としてはまあまあこんなものかという感じ。ファミリーマートでバーコード決済の方はすでに確認してたので、一通りの体験はしたことになる。個人的にはなるべくお金持ち運ばなくてすむようになれば、なんでもいいかなーと思ってるので、Apple PayもKyashもPayPayもそれなりに使うことになりそうである。

Webフロントエンド ハイパフォーマンス チューニングを読んだ

今週のお題「読書の秋」

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

だいたいサーバーサイドの仕事ばっかりやってるので、SQLのチューニングとか何かしらのアルゴリズムの選定とか極力オブジェクト作らないようにするとか、そういうところが高速化の主だったところなのだけど、フロントエンド側もちゃんと知っとかないとなーと思いまして。通勤中、地下鉄に乗る十数分だけ読み進めていっていたので、だいぶ長い時間かかって読み終わった。

内容的にはWebページをレンダリングするためにブラウザが何をしているか、DOMの操作でレンダリングパイプラインのどこに影響が出るか、CSSが変わった時にどうなるか、どういうことをすればその影響を限定できるか、などが細かく記されていてつどつど読み返したい内容だった。実際にはどれだけ時間切り詰めても、サーバー側で大量のデータを扱ったりするとどうしても時間がかかってしまうのでサーバーサイドもクライアントサイドも合わせて、ユーザーを待たせないUIを作らないといけないのだけどフロントエンド側の知識もこの本を片手に色々議論できるようになるんじゃないだろうかと思う。

読んだ端から割と忘れてるので、ささっと出せるようにしておきたいね。

【京都】LINE Developer Meetup 46に参加してきた #LINE_DM

line.connpass.com


例によってメモ書きとちょっとした感想。

LINEでのモバイルアプリ開発プロセス 若狭 建 (LINE)

www.slideshare.net

発表の中で個人的に一番面白かったなと感じた。多分自分の会社での問題意識と同じところがあるんじゃないかと思って聞いていたせいもあるかもしれないけど。

コミュニケーションツールが複数あって統合しないの?とか思ったり、DX(Developer eXperience)大事という話で大きく頷いたり負債を返すためにきっちり話をするというのは反省したいところ。DXに関連したところだと、ReleaseブランチでBugfixしたらMasterに自動的にマージされるようにしていたり、きっちり自動化を推進していてこういうところ見習いたいなと思った。

  • 震災を元にLINE作成
  • 2億人Active/4.5B message per day
  • Primary Device
  • Secondary Device
  • 機能たくさん
  • Webアプリとネイティブアプリの連携
  • LINE iOS
    • ObjC 50% Swift 50%
    • 徐々に移行してる感じ
    • 120万行ぐらい
    • 1K PR merged/month
  • Android
    • 規模感は同じぐらい
    • Java 75% Kotlin 25%
    • 1K PR merged/month
  • チーム
    • 同じソースコード触ってる
    • なるべくモジュールわけて依存関係をなくすようにしてる => けど難しいよね
    • サーバー側やUIなどいろんなチームとコミュニケーションとってる
      • DevOpsチームってなんぞ?
    • Confluence JIRA Zeplin GithubEnterpirse Slack LINE LINE WORKs
      • 3つぐらいあると大変そう、統合しないの?
    • 英語が基本(日本語も韓国語も中国語も)
      • 同時通訳の人がいる
    • 緩やかに集まる
      • かっちりしたチームがあるわけではなさそう?
    • 全社でJIRAの使い方が決まってわけではない?
    • CIは色々だけどJenkinsがほとんど
  • いろんなOSS使ってるよ!
  • Branch戦略
    • Gitlab flowみたいなやつ
    • Releaseブランチがある
    • 別に開発したいときはTopicブランチ作って本線にマージ
    • bagfixはissueとちゃんと紐付ける
    • 規模でかいのでmerge大変
      • Auto merge
  • Biweekly Release Train
    • 2週に一回出す
    • 開発遅れても待たない
    • QAちゃんとやってるのいい
  • サーバーはマイクロサービス化されてるけど、クライアントは……
    • 吟味して、周りを説得して、頑張る
  • 新しいものへの対応
  • 7年経ってるので負債が……
    • 負債を返すことを周り(企画、マネージメント、QAなど)に話す
    • 話して負債を返す
  • 統一されたUXがLINEにない
  • LINEで税金を払う国がある……
  • DXに力を入れてる
    • どういうところから手をつけていったのか?
  • どんどん自動化をしたい
  • テストのカバレッジ増やしたいなど

LINE Creators StudioでのKotlin利用について、あとKotlin Native(仮) 馬見 誠 (LINE Fukuoka)

www.slideshare.net

Kotlin Nativeに対して熱い展望がありそうと思っていたが、今後に期待という感じであった。

個人的には下の動画見たりした関係でロマン感じる話で、ロジック共有にしてサーバーサイドもクライアントサイド(ネイティブ、Web問わず)も同じものを使い回ししたいなーと思ったり。


KotlinConf 2018 - Live Coding Kotlin/Native Snake by Dmitry Kandalov

  • LINE Creators Studio
    • スマフォからLINEスタンプを簡単に作れる
  • Pure Kotlin
  • 色々ライブラリ使ってる
  • 1年半前にリリース
  • 画像の切り抜きが命
    • ユーザーから使いづらかったという意見
  • 自動切り抜き Androidオンリー
  • 今のところKotlinの話なし
  • 事前のデータ処理で負荷が下がるのはよくわかる
  • Kotlin話きた
    • スッキリかける
    • Color.inrの例
      • ExtentionでOS標準のライブラリに追加でメソッドはやせる
  • Kotlin/Native
    • 使い物になる? => まだ実用には程遠い?
    • 効率的に開発できると思ってる
    • まだBeta
    • だいぶロマンがある話

LINE iOSアプリで使っているフレームワークの紹介 上野 賢一 (LINE KYOTO)

www.slideshare.net

内容的には資料にも書かれてるけど、浅めの紹介をさらっと流した感じ。いいライブラリがあったら、教えてもらおうという他力本願メソッドは個人的に好き。情報共有大事。

  • CoreData
  • OSS
    • 管理コストとかも考えないと辛い
    • コストを見極めるためにどうしてるのかな?
  • 社員のOSS
  • CordovaをWebアプリとネイティブのブリッジにしてる
  • ヘビーなライブラリは慎重な議論必要 => だけどReaxtiveCocoa Swift入ってる
  • 色々大変そうな話だった

KotlinやSwiftあたりも手をつけておきたいなと思いつつ、素振りできてないなーという反省もありなんか考えよう。

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinイン・アクション

Kotlinイン・アクション

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

ポール・マッカートニー FRESHEN UP JAPAN TOUR 2018 東京ドームにいってきた

1日休みを取ってポール・マッカートニーのライブを見てきた。

nme-jp.com

洋楽好きの御多分にもれずBeatlesとかはよく聴く方の人間なのだが、自分が仕事始めてからはポールが来てもライブを見るための休みが取りづらかったり、昨年のライブは何かの都合であることすら気づいておらず今後見る機会もないのかなーと思っていた。が、Egypt Stationがリリースされてしかも日本のツアーがある。これは取らねばとささっと取って有給休暇も申請し、風疹の予防接種もして万全の態勢で臨んだ。*1

Egypt Station

Egypt Station

ライブに参戦する場合、自分はあまり予習的なことはしてないのだけど今回ばかりはEgypt Stationをしっかり聞き込んできた。個人的にはアルバムとして結構好き。他はおそらく聞き慣れた曲なんかはやるだろうから、当日を楽しみに待った。


今日はこれ

そんなこんなで当日。11月は気がつけばいろんなところに行かなきゃいけなくなってしまい、ダウンすると予定がダメダメになってしまうので、予防にマスクしたり色々頑張って東京ドームまでたどり着く。すでに開場時間は過ぎていたので、さっさとドーム内に入ったらポールの曲を色々リミックスしたようなものや、誰かのカバーが流れている。I want to hold your handのR&B的なカバーでギターフレーズの部分がブラスになってて、この曲はビートルズなりのR&Bを追求してたのかなと思ったりして待っていた。

だいぶ長く待った気も短かったような気もするが、ポールが現れライブは始まった。

初めはなんとも奇妙な気持ちで、現実味もなくしかし確実に知っている曲と知っている声が真向かいのステージから聞こえてくる。東京ドームのS咳と言ってもスタンド側。はっきり言って肉眼では見えない。現実かなと認識しだしたのはLet me roll itのあたりだろうか。そして1985からのMaybe I'm amazedの流れで完全にいかれてしまった。Being for the benefit of Mr.Kiteなんか完全に万華鏡の世界。SomethingはConcert for Georgeでやったウクレレからの流れ。もうどちらもこの世にいないから、と歌っているんだろうなぁと思ってしまった。

全て終わってみれば、2時間45分ぶっ通しのライブ。ポールはその間休憩も取らず、水も飲まず。もう齢70を超えた人があれほどエネルギッシュに、愛嬌をたたえ、ベースやギター、ピアノを弾きながら歌い続ける。なんて人なんだろうと。前に見たブライアン・ウィルソンとは全く違うライブだった。ああいうのがレジェンドなんだな。うん、素晴らしかった。これからも曲を聴き、楽器を弾き続けようという気力をもらった。また来る機会があるなら見に行きたいなぁ。

*1:インフルエンザの予防接種もしたかったが、ちょっと時間なかった

ゼンハイザー MOMENTUM In-Ear Wireless

shachi.hatenablog.com

shachiさんのブログエントリ見てて、そういや自分もここ最近同じタイプのワイヤレスイヤホン使ってるんだったと。

使用感とか書いてなかったので、記しておく。

raydive.hatenablog.jp

前にDACが壊れてしまってショックと書いたエントリの直後ぐらいに、eイヤホンでゼンハイザー MOMENTUM In-Ear Wireless の中古を見つけて状態も良さそうだったので勢いで購入。そこからかなり使っているが、ワイヤーがないだけこうも楽になるかと実感している。一番ありがたいのは引っ掛け事故がなくなる。急いでる時とか、気がつかずに引っ掛けてイヤホンが外れることがなくなって、それだけもうストレスフリーである。音の方は基本的に好みでゼンハイザーばっかり使ってる人間なので、特に違和感もなく。

毎朝好きな音楽やラジオを聴きながら出社できるのは大変にありがたい。あ、でもそろそろこういうの 欲しいなとかゼンハイザー初完全ワイヤレスも出るそうなのでこれも欲しいです……

Effective DevOpsを読んでいる

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

社内(と前職の合同)で読書会をやっている。まだ途中だけどこの本がなかなか面白い。

DevOpsと言われると、一般的に開発と運用のチームが手を取り合って……というイメージがあるが、この本では開発運用にかかわらず組織が必要とする全ての役割の人たちがチーム内、チーム間、組織でどうよりよく仕事を共同で進めていくか、そのキモの部分をDevOpsというのだ、というところがこの本の言いたいところだと思う。今9章のあたりを読んでいるが、ほとんど技術的な話は出てこないしそういうところは本質でないと言いたげな態度が目から鱗である。

そういう意味だと、CIがどうとかマイクロサービスがDockerが、といった個々の技術について書いた本というより、これらの本に近いのかもしれない。が、これらの本は読んでないので似てるかどうは置いておく。

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

文化的に非難の応酬となるような組織では人は働きづらいし、組織・チーム・個人の価値観の認識があってないとうまくいかない。もちろん違いはあることは認め、そこからどうまとめていくか。はたまた合わない人は離れることを恐れてはいけないし、組織としても退場をお願いすることもある。書かれてる内容は至極まっとうな印象を受けていて、はじめに述べたとおりなかなか面白いなと思う。

DevOpsにおけるアンチパターン、いわゆるDevOpsという役職があったり、資格があったり、DevOpsの人を雇えば一人で二人分の仕事をする、などの誤解についてもしっかり書かれている。ワークライフバランスについての記述はわりとシビアで、自分の理解では、結局のところ人を増やして個々の負担を減らそう(できないところはなんとか割り振って仕事の負担を分割しよう)となっていて、現実感もある。チームの団結力が高い方がいいが、高すぎてもサイロ化してしまうなど、バランス感覚が大事な点に言及しているところも、自分は納得感があった*1。ただ、たまにもやっとした記述もあり、いまいち頭に入ってこないところもある。具体的にどうすればいいというよりは、もう少し理想的な状態とはこういうところだ、という書き方になっていて、実際に個々のケースについてどう解決するかはあなたが所属するチーム、組織によって異なると言いきっている。すぐに手を打てる手法を知りたい人にはあまり向いてない本だと思う。

DevOpsというものの考え方を知るためには良い本だと思う。特に開発者や運用に当たる人だけでなくデザイナーや人事の人も、一緒になって読んでみるのがいいんじゃないかな。

*1:し、今の会社ではよくこの辺を考えているんだろうなというところも気がつかされた