フレッツ光 "隼" はPPPoEでは本当に使い物にならなかったので...

長いまえおき

引っ越してからネット環境が変わって、隼とかいう「スーパーハイスピード」タイプのものになった、という話は昔書いた。

夜のスループットは壊滅的！

これちゃんと調べてから契約すべきだったなーと激しく後悔しているんだけど、隼は 夜になると実測値で4Mbps出ない状態なのだ。よくこれで「スーパーハイスピード」なんて言えたもんだと思う。

これはたまたまじゃなくて、毎日だ。イライラした時にはTwitterにスクショ撮ってたんだけど↓

こんな感じで、有線でもスマホ以下のスループットしか出ない。しかもこの半年まったく改善されていない。

IPv6にすればいい？

どうやら「PPPoE経由ではなくて、IPv6で直接つなげばいい」みたいなことを書いてるサイトが結構あるなーとおもって、乗り換えることにした。

先に結論を書いておこう

  • フレッツ光 隼 + 「ZOOT NATIVE(1000円/月) だけ」で、望んでいた環境は30分くらいで手に入る。
  • 基本的には「ほげほげ光！」みたいなの(コラボ光)に乗り換える必要はまったくない

  • でもGMO BBでは、ひかり電話対応の機器を所持していない限り、持ち込みルータではv6プラス接続できない！！という罠がある

  • 検索結果の上位を占めるように出てくるキュレーションサイトの数々に騙されることなかれ！

これ以降は、失敗談とキュレーションサイトに対する愚痴しか書いていない。

　

今回の乗り換えでつまづいたところ一覧

世の中のキュレーションサイトがIPv6に対する理解の妨げにしかなっていないということ

「gmobb v6プラス」とかで検索すると、金稼ぎのために書いたようなブログ記事みたいなのがいっぱい引っかかります。 このキーワードに限らず、IPv6の調べ物をしているとかなりの割合で、そういうブログ記事が引っかかります。

「●●に申し込むだけでOK」「△△だと20000円キャッシュバックがあるのでお得！」みたいな情報は、調べ物においては正直何の役にも立たない、ただただノイズです。

　

で、自分がおそらく知りたかったのは、

  • IPoEとIPv4 over IPv6 の２つが揃って、初めてまともにネットが使える
    • IPoE単体でも、とりあえずIPv6サイトの閲覧はできるが、従来のIPv4にしか対応していないサイトは見れない(DNSが引けない?)
  • IPv4 over IPv6 いくつかの名称・規格がある。
    • transixっていうやつを使う場合には、ルーター側で gw.transix.jp というゲートウェイを1箇所設定をするだけで、IPv4サイトも見れるようになる
  • 原理上、ポート開放ができないので、サーバー公開とかやりたい場合は注意してね

くらいの情報です。

　

本当に、世の中のキュレーションサイトには消滅していただきたい・・・。

IPv6で接続ができることと、v6プラスは別物だということ

先にちらっとかいた

IPoEとIPv4 over IPv6 の２つが揃って、初めてまともにネットが使える

ということ。

flets-w.com

たとえばここに書いてあるのはIPoEの話であって、v6プラス, transix, MAP-Eなどの話ではありません。

IPv6で接続できて、なおかつその先でIPv4のサイトも見るための仕組みを用意してあげないといけないよ！それがv6プラス, transix, MAP-Eだよ！ということを理解するまでに結構時間がかかった。

ビックカメラの店員でも対応ルータを間違えるくらい紛らわしい

家のルーターが対応してなかったので、新しいのを買いに行くことにしたんだけど、「IPv6対応しているルータでなるべく安いの下しあ」なんて言うと、求めるルーターが必ずしも案内されない。

IPv6対応しているルータは、結構古くからあるが、transixとかに対応しているルータはかなりレア物で高い。

最初ビックカメラで案内されたのは

BUFFALO 11ac/n/a/b/g 無線LAN親機(Wi-Fiルーター) Giga ビームフォーミング対応 866+300Mbps WSR-1166DHP3-BK

BUFFALO 11ac/n/a/b/g 無線LAN親機(Wi-Fiルーター) Giga ビームフォーミング対応 866+300Mbps WSR-1166DHP3-BK

これ。IPv6パススルーには対応しているけど、v6プラスやtransixなどには対応していないよ。家に設置してから気づき、わざわざ交換しに行って

バッファロー WXR-1750DHP2 無線LAN親機 11ac/n/a/g/b

バッファロー WXR-1750DHP2 無線LAN親機 11ac/n/a/g/b

最終的にこれに行き着いた。（店員に案内されたやつを買ったからなんだろうけど、私の伝え方が悪かったかもしれない＆開封したのに交換対応してくれたビックカメラには結構感謝している）

GMO BBは持ち込みルータではフレッツ光 隼 のv6プラスを使えないということ

これは、GMOBBに明らかに非があると思う。

2017/01/01 00:04:01　SYSTEM　[V6Plus] Can't connect rule server. 
2017/01/01 00:04:01　SYSTEM　[V6Plus] Can't receive rule(status=-2).

ルーターのエラーログで↑みたいなのが出続けてていたんだけど、これはGMO BBでは持ち込みルータでv6プラスは使えませんぞ！ということらしい。

GMOBBの公式には「ひかりルーターorルーターレンタルが必須」とは一言も書いてなくて、

この辺の情報を見ると、なんとなくそれっぽいことがあるらしい、というのがわかる程度。

（ちなみに私はこれを見て、心底腹が立ち、カッとなってそれまで4年くらい使っていたGMOBBを解約するに至りましたｗ）

まとめ

すべてフレッツ光 隼が悪い。もう絶対にこんなサービス使いたくない。

まわりの人に快く動いてもらうための言葉遣いについて

家で仕事する日々が続くと、働く雰囲気というものを割と気にするようになってきた。

なんとなく、「あ、これは言うと損する言葉かも」とか「こういう言い方すると良いかも」みたいなのを自分用のメモみたいな感じで書いておこうかなと思う。

　

DONT: 「影響範囲が大きい」

対話中に見積もりを求められるときには無意識に使っている言葉。

影響範囲が大きいという言葉からは、結局の所「私はそれには協力しない」という"暗黙の姿勢"だけが伝わる。

難易度が高くて、ちゃんとできる保証がない・・・だとすると

「このロジック読み解くのに○日くらいかかってしまいそうだけど、いい・・？」

「今すぐにはうまいやり方が思いつかない・・・」

→へんに客観的な言い方をせずに、"私"を主語にして言ったほうが良さそう

まじでその決断をしてほしくない・・・だとすると

「うーん、この機能にどのくらい情熱ありますかね？」

「なんか別の方法でうまいことできないかなー・・」

「同じ工数つかうなら、△△の機能改善のほうをやってみたい/注力したいな」

→本当にそれが最善なのか？と確認とったり、別の策を一緒に考えたいという姿勢を第一に示したほうが良さそう

DONT: 「もとの作りがよくない」

何かを改造しようとしたら「うわぁ、なんだこれ！」っていうコードを見てしまうことは稀によくある。ただ、それを頭ごなしに否定するのは・・・

もし隣にその機能を作った人が座っていて、たまたま言葉を耳にしたらどんな気分になるだろう？

実は作った当時にはちゃんと理由があって作ったものかもしれない。何らか課題があってお試しでやってみただけなのかもしれない。どうしても暫定対処するしかなかったのかもしれない。

楽しい雑談や議論ができたかもしれないところが、「作りが良くない」なんて言ってしまうと一気に雰囲気が悪くなってしまう。

とにかく作った人を尊敬する。話はそれからだ。

作った人に対して尊敬の念をとりあえずでも持とう。そうすると、まずはgit logなどなどをみて、作られた経緯を今一度確認しようと思うはずだ。

それでもなんでこんな作りになってるの・・？というところがあるとすると、直接作った人に聞く。（すでに退職している人だったら諦めるしかないがｗ） だいたいそういうケースでは、何らかの未練が存在しているので、話す余裕があれば当時の思考過程をいろいろ聞く。で、本当にその未練をバッサリ消すのが良さそうかを合意する。

みたいなことができたら理想的なんじゃないかなぁと思う。

DONT: 「デザインが出てこないと手をつけられない」「プロダクトオーナーに判断してもらわないといけない」

私個人的にはたぶん言ったことはない気がするけど、世の中的には結構使われてる気がする。

ウォーターフォールなプロセスだとこういう態度は正しいと思われがちがけど、これって「自らの作業効率化のため」であって必ずしも他人を思いやっていないよね。

本当に手戻りが嫌なのだとすると・・・

「○○画面のデザイン、リストにするのかカードにするのか他のなにかにするのか、方針が変わると実装が大きく変わるので明日の昼までに決めたい」

→単純に丸投げするような言い方をせずに、選択肢を一緒に考えるように言えると良いんじゃないかなぁ

なんらかの判断に自分が担当/責任を持つのが嫌なんだとすると・・・

「○○画面のデザインのところ、デザイナでまず原案出して欲しいな。それみて議論したい」

→全部考えてくれ、ではなくてベースを作って欲しいという言い方にして、担当/責任はとらずとも協力はしたほうが良さそう

「私は○○がいいとおもってるけど、判断は△△さんを信じておまかせするわー。」

→英断に期待している！という言い方をすると、言われた方は(単純な丸投げよりも)快く&期待に応えるための判断をしようと思うんじゃないかなぁ

　

　

まとめ

結局のところ

  • 他者尊敬は大事だ

に尽きるのかなと思う。

Webサービス(Rails)＋スマホアプリを作るときにやってはいけないこと 2018年版

なんとなく最近いくつかのWebサービスを触って「あ、こういう作りしちゃうとしんどいんだな・・・」というのが少しだけ分かってきたので、ほんとになんとなくメモっておく。

「下書き」「公開」をstatus=draft/publishedとかpublished=true/falseで表現してはいけない

class Article < ApplicationRecord
  belongs_to :user

  scope :draft, ->{ where(published: false) }
  scope :published, -> { where(published: true) }

  def publish!
    update!(published: true)
  end

こういうモデルを作ってしまうと

  • 下書きと公開後で「見ることができる人」が異なるべきなんだけど、ふとした拍子に Article.find(params[:id]) とか書いて（ .published を付け忘れて）事故る
  • 下書きはそんなに厳密なバリデーションなく保存したいが、公開時にはちゃんとバリデーションしていてほしい。そうすると if: :published? unless: :published? がたくさん...
  • 公開時にプッシュ通知を送りたい、というのをやるにも「初めて公開状態になったタイミング」の取得が難しい

などなどの理由で「事故りやすい」コードになってしまう。

「下書き」は素直にモデルを分けよう

class ArticleDraft < ApplicationRecord
  befongs_to :user

  def publish!
    Article.create!(
      user_id: self.user_id,
      body: self.body
    )
  end
class Article < ApplicationRecord
  befongs_to :user

下書き状態をフラグではなくすことにより、

  • Article.find(params[id]) とかを不用意に呼んでしまっても、見えてはいけない下書きが混ざることはもうない。
  • バリデーションも独立で定義できる
  • 初めて公開状態になったタイミングはArticlewのcreateのタイミング。

のように、構造的に少し事故りにくくできる。

　

通知の処理はべた書きしない

class ArticlesController < ApplicationController

  def create
    if @article = current_user.articles.create(params.require(:article).require(:body))
      NotificationMailer.notify_article_created(@article)
    else
      render :new
    end

これは以前に書いたことそのものなんだけど、通知は結構いろんな種類があるのでコントローラにべた書きなんてやってしまうと

  • アプリ作るからプッシュ通知もやりたいな
  • アプリのAPIから通知したお知らせ一覧を見れるようにしたいな

みたいな要件があとづけでやってきたときに詰む。

通知は「きっかけとなったイベント」と「通知履歴」で表現する

yusukeiwaki.hatenablog.com

に書いたこと。

　

コア機能を「とりあえずWebViewで画面つくる」のは絶対にやめたほうがいい

「Railsのコードで画面が作れるし、多少の仕様変更があってもアプリ側にアップデートしてもらわずに変更できるし、フォー最高！」みたいなかんじでWebViewが採用されることが稀によくある。

しかし、以下のような理由でWebViewを採用する場合には、REST API＋ネイティブ実装が本当にダメなのかを再考すべき。

  • iOSとAndroidの両方の画面をメンテするよりは、HTML+CSSでそれっぽい画面が作れる
  • 仕様が変わったときにアプリ側の変更無く反映ができる
  • Railsのコード書けるエンジニアはたくさんいるけど、アプリのコード書けるエンジニアは数人しかいないので、Railsのコードに近いほうがメンテ楽そう

WebViewは

  • 特定のページにJSを注入する
  • 特定のURLをブラウズしようとしたときに処理を横取りしてネイティブ側に処理を戻す
  • カスタムヘッダーをつける

など、ブラウザでは簡単にできないことが自由にできる。

その半面、これらを使ってしまうとブラウザでコンテンツ試験困難になり、iOSとAndroidのアプリ両方と結合動作確認しないといけない。そうすると気づく。「まったくラクできてないぞ？！」と。

WebViewじゃなくて素直にブラウザを使ったほうがいい

WebViewは基本的に使わないほうがラクだが、

  • 認証が不要
  • Web側で機能が完結している（○○のリンクを踏んだときはネイティブ側の画面を表示する、みたいなのが無い）
  • ユーザがブラウザに保存している個人情報（パスワードとか氏名・住所とか）の補完やクッキー情報を利用したい

のような場合には、ネイティブじゃなくてWebViewを採用したいなというのはアリ。ただ、それならWebViewではなく素直にブラウザを使ってWebページを表示したほうがいい。

Yahooの認証画面とかがいい例で、認証時はブラウザで専用の認証ページに飛ばされて、認証が終わったらカスタムスキームのURLでアプリに戻ってくる、という作りをしている。

素直にブラウザで表示すると何がいいかというと

  • ダサい
    • コア機能をWebViewで済ませちゃおうという気が失せる
  • 試験がしやすい

が大きな理由。「コア機能は自然とネイティブ化したくなる」ってのは本当に大きな理由。

WebViewは意外とメンテが大変なので、REST API＋ネイティブ実装したほうが結果的にはラクなことが多い

WebViewは、実運用においては

①思ったほど更新されず　→②メンテされず　→③いつの間にか壊れて　→④意図したとおりの使われ方がされず　→⑤結局ネイティブに置き換えられる or 単純に捨てられる

みたいなライフサイクルをたどることが多い。

REST APIであればrequest specで自動試験しやすく、どこかの誰かがモデル構成を変えて壊れそうになっても事前検知ができる。しかしWebViewのように画面を返すものはRailsでも試験を書くのが格段に面倒だ。雑に試験を書かないでいると、どこかでモデル構成がいつの間にか変わっててWebViewだけいつの間にか壊れる、みたいな状態になる。

また、そもそもWebViewで作る画面は、Railsのコード書く人にとっては「アプリの画面」として敬遠されがちだし、アプリのコード書く人にとっては「CSSとかちゃんとわかってないといじれない画面」として敬遠される。

ヘルプページとか、OSSライセンス表示みたいに、見る人/見るシーンが限られている機能であればWebでいいのだけど、少なからずユーザに使ってほしいコア機能であれば、最初からネイティブ実装したほうが、ちゃんとメンテもされるし継続的に利用されるだろう。

　

「一度しか表示しない」ものは極力なくそう

個人的にはなんで存在しているのか全くわからないんだけど、ウォークスルーみたいな機能って割とたくさんのアプリで実装されている。

ウォークスルーは

  • 「読まない取説を無理やり読まされてる」ものなので、大抵の人は読まずにスキップする
  • 最初の１回しか表示されないので、ユーザの印象には全く残らない
  • 画面のスクリーンショットが貼られていたりすると、画面が変わるたびに画像差し替えが必要になって、デザイナもエンジニアも対応が必要

という、この上なくコスパが悪い機能だ。

説明のためのウォークスルーを実装するくらいなら、コア機能を説明なしで使えるようにUI改善したほうがいい

「説明をしないと使ってもらえない」という不安をウォークスルーとか説明のポップアップみたいなもので払拭するのがそもそもの間違いで、説明しなくてもいい状態を作り出すことがユーザにとっても開発者にとっても良い状態だ。

もっというと、「説明を必要とする機能であれば作らないほうがいい」という判断もアリだ。説明が必要というのは「ユーザが必要としていないものを作っている」ということなのかもしれないと疑ったほうが、シンプルに仕上がる。

ユーザが求めているのは紙芝居のウォークスルーではなく、セットアップウィザード

「iPhone買ったときだって、最初の１回だけ表示される機能があるじゃない？」

そう、あれはウォークスルーではなく、セットアップウィザードだ。「セットアップしないとちゃんと使えないので、一緒にセットアップして行きましょうね！」という目的のセットアップウィザードは、ウォークスルーとは似て非なるもの。

Wantedly Syncが昔、シンクマっていうキャラクターとのチャットを通じて使い方を説明していく面白い仕組みをつくっていた。

会話履歴のない人がアプリを立ち上げると、いきなりボットに話しかけられて

f:id:YusukeIwaki:20180817101847p:plain

他のメンバーの招待の仕方やメンションの仕方を教わる、というもの。

f:id:YusukeIwaki:20180817101833p:plain

こういうインタラクティブにセットアップ/使い方の習得をしていくのが、おそらくユーザが求めているものだ。

　

　

まとめ

複雑なものは、メンテされずに忘れられて壊れて、置き換えられるか捨てられる。

シンプルにいこう。