前任のエンジニアをリスペクトしよう

一人か二人で保守していたサービスがあって、そのエンジニアがなんらかの事情でいなくなったり入れ替わりで引き継ぐことになったとする。 こういうとき世間全体を見渡せば、前任のエンジニアが自分より劣っているか優れているか、確率は２分の１である。

しかしながら一般的に、前任のエンジニアはディスられやすい。というのは、たいていの現場では引き継ぎは不十分だったり、ソースコードには負債があるためである。

心に胸を当てて考えて欲しいのだけど、前任のエンジニアをdisったことはないだろうか？ 今から考えれば私も「ここの実装はXXだ」とか「サービスに対して過剰に設計してる」だとか「テストがない」とか散々disってた気がする。 しかし最近は手離れしたプロジェクトが増えてきたので、言われる立場になることも多少出てきた。「初期の設計がおかしい」とか「拡張性がない」とか。

当時はプログラミング初めて３ヶ月とかで何もわかってなかったのをタダ同然でプロトタイプとして作ったようなもんなのに、なんだかんだ何年もそのまま使い続けて仕様も変わっていってる中でそんなこと言われても困りますよとか、言いたいことはいろいろあるのだけど上のdisも所詮そんなようなものでしかない。

というわけで、これからは建設的な開発のために以下のようなことを心がけようと思っている。

誰かに引き継いでもらう場合

• 難解な設計は行わない
• ドキュメントを作る
• 技術的な負債や自分が気になっている点、開発期間を経て仕様が変わったことでおかしくなってしまっている点などは明文化する
• 平均的なエンジニアが難なく引き継げるものを作る
  • そういう意味でReactとかってどうなんだろう？

誰かのものを引き継ぐ場合

• 前任者disはあまり行わない
• 学べるところは学ぶ
  • そのレポジトリに含まれてる全ての知識で前任者より自分が優っているということはほとんどない
  • 前任者のスキルが低くても、「スキルが低い人にありがちな設計ミス」などが分かる
• 今のアプリケーションや仕様に対して、ソースコードがおかしいのはしょうがない部分もある。時間軸を考慮してあげる

お互い想像力を駆使したいところである。

歌舞伎界に対する素朴な疑問

news.livedoor.com

いつもこういう記事を見るたびにそもそもの疑問がある。一体全体、歌舞伎ってなんですか、梨園ってなんですかということ。

前から疑問なのだけど、歌舞伎の人は西麻布で暴れてボコボコにされたり隠し子がやたらいたり、誰と誰は絶縁状態とか、飲酒運転だの暴力報道、そんなのが芸能界に詳しくない人でも分かるほどたくさん報じられている。 一時的に騒がれてもすぐに鎮火して、数年後には「色もやんちゃも芸の肥やし」的なムードで明るく迎えられている。

これってどういうことなんでしょう？？

で、これが国民的人気タレントとか人気スポーツとかならまだしも、正直国民の多くは海老蔵等が好きとは思えないし、興味なしまたは嫌いという人が多いのではないだろうか。 さらに歌舞伎自体、野球や相撲などと比べていくら伝統芸能だからとはいえ今の日本的にはマイナーな感がする。そもそも歌舞伎を見たことがある人はどれだけいるのだろう。世の中の95%の男性はAVを見たことがあるだろうけど、歌舞伎を見たことがある人は5%くらいではないか。

だから上の記事のように、報道する意義もないものを報道し、ただひたすら不快に思う人を増やすような記事にいったいなんの価値があるのかと思う。

user-scalableどうするか

viewportにuser-scalable='no'という文字列を指定するとスマホとかで拡大ができなくなる。

私はスマホ対応といったとき、デバイスの横幅に合わせて横スクロールが発生しないことと拡大せずに閲覧できることだと勝手に思っていたが、そもそもスマホ対応していようが拡大しないと読めないレベルの視力の人は大勢いる。 とくに私が主宰のサイトは高齢者層が多いので、極端に拡大しないと文字が読めない人もいる。 そういうわけで以前から、analyticsで高齢者がほかより多いと確認できていたタブレットユーザに関してはviewportのuser-scalable='no'を外していたのだけど、今回全面的にuser-scalable='no'を辞めることにした。

ところで、多くのサイトで今user-scalableがどうなってるのか気になったので調べてみた。

Cookpad => 拡大できない

トップとレシピページしか見てないが拡大できなかった。

食べログ => 拡大できない

こちらもトップとレストランページしか見てない。

Yahoo => 一部できる

トップはできなかったが

ニュースはできた。このように文字数が多いページは拡大できるようにしてるみたい。

はてブ => できない

主要なページ一通り見たができなかった。

Amazon => できない

朝日新聞 => できない

ここまでの傾向から老人のユーザが多い文字が多いサイトは拡大傾向にあるのかと思ったが朝日新聞はそんなことはなかった。

Naverまとめ => できない

できない。まぁ見出しと画像しか見てない気もする。

Wikipedia => できる

楽天 => できない

今回いろいろ見た中で、一番拡大させてくれよと思った。画像の中の文字が読みづらい。読めない人もけっこういると思う。

Apple => 拡大できる

Google => 一部できる

検索結果は拡大できなかったけど、トップはできた。

まとめ

予想以上に拡大できないサイトのほうが多かった。文字数が多くて文章の内容を伝えるのが価値になるサイト、とくに50代以降で老眼が進んでいるユーザが多いサイトでは拡大はできたほうが良さそう。 また、画像にテキストを埋め込む場合、cssでコントロールできないのでレスポンシブでスマホで潰してみた時に識字しづらくなる場合があるけど、拡大を許可するだけで代替画像とか用意しなくてもまぁOKなので、そういう点では楽できると思う。

ちなみに幅を固定したままで文字サイズを変更できるようにしたいなら、htmlの基準font-sizeを14とか20とか動かせるようにして、それ以外のフォントサイズ等をすべてremで指定すればいいと思う。jsで切り替える感じで。 でも、ユーザにとってそれとピンチジェスチャーどっちが楽ですかっていう話でもある。

時空を超え始めた

今日は記念すべき日かも知れない。というのは、こんなことを真顔で言うととうとうあいつも発狂したかと思われそうなんだけど、今日ようやく潜在能力を覚醒させ時間と空間を瞬時に移動することに成功した。

どういうことか、少し詳しく話したい。

私はいま、普段8階建のビルの7階のオフィスで仕事しているんだけど、小さいビルなのでエレベーターが1つしかない。そして古い建物だからエレベーターも遅く、7階から降りる際に適当な階でもたついてるとけっこうな時間を食う。

今日も例によってそんなわけで、私は7階から薄暗い屋内階段を使って降りた。 ちょうどそのとき非常に複雑で、面倒なことを考えていた。というか、そういうことで頭がいっぱいになったときに気分転換にコンビニに行く。

7階から降りると電気がついていない6階になる。 6階から降りると、当然5階になる。

しかし今日は違った。 頭の中を質めんどくさいことが駆け巡った状態で、歩き慣れた階段を脱力状態で降りていた。 7階の次は6階だった。6階の次は・・・、2階だったのである！

一瞬マジで5階の人がふざけて「２」のマークを壁の「５」の上に貼っつけたんだと思って確認したが、やはりこれは2階だった。このビルは2階にゆうちょのATMがある。そして昼の時間帯でATMには列ができていた。 そんなバカなと思いながら2階から降りると、、、、、、やはり1階だった。

ははーんそういうことか、と。私はいかなる超常現象も宗教も迷信も、付け加えれば科学も政治も経済も信じてないのでこれは単に頭の中が考え事でいっぱいの状態で、階段を降りるといった半無意識的で負担のかからない運動だと案外階段も一瞬で感じるということかと理解した。例えば歩きスマホをやってる人が熱中しすぎて自分が思ったよりも歩いてしまって、柱か何かにぶつかるようなものなんだと。

ということで、この日はそのあとも何度か「マジでめんどくさいXXさんを避けるにはどうすればいいか」「2000万くらいほしいけどどうすればいいか」「地上で一番始めに動き始めたものはどうやって動いたか」など難問を考えながら階段を降りてみた。ところが、もう二度とワープ現象は発生しなかった。

そこで最後に、ダメでもともとで「7階の次は1階にワープしろ！」と頭で念じながら降りてみた。 するとどうであろうか。7階の次は1階になったのである。

というわけで何が言いたいかというと、意志の力はどうでもいい現実は捻じ曲げられる(現実歪曲空間)という話と、私が超能力キャラに唐突にはまりだしたという2点である。

カンマ入ったり全角入った数字(の文字列)を数値にしたいやつ

タイトルのやつ自体はrubyだとカンタンなんだけど、適当にこういうクラス作って

module Bacchus
  class IntegerFilter
    def initialize(num_string)
      @num_string = num_string
    end

    def convert
      unless @num_string.is_a?(String)
        return @num_string
      end

      @num_string = @num_string.tr("０-９",  "0-9").gsub(/,|、|，/, '')
      n = @num_string.to_i
      if n == 0 && !['0', 0].include?(@num_string)
        @num_string
      else
        n
      end
    end
  end
end

数字っぽい文字列なら数値にして、それ以外はそのまま戻すコードを用意しておく。 （なんか汚いな、最近エレガントな興味書こうみたいな意欲が全くなくなった気がする...。'hoge'.to_iが0になるの、チェックの仕方これしかないのかな)

問題はウェブアプリケーションでこれをどこに置きますかっていう話。

某クラウド家計簿サービスはこういうのとか、空文字列をnilに変換する処理をわりとRackなのかスーパークラスなのか、とにかく低層の共通処理においてしまったがためにわりと標準の仕組み的にうまくいかないことが増えて負債化してしまったらしい。

一見モデルのbefore_saveあたりに置けば良さそうだけど、Int型のItem#priceとかのカラムに文字列'12,345'を突っ込んだ時点でRailsが12にしちゃうのでそれはできない。

というわけでcontrollerで

  def hoge_params
    _params = params.require(:hoge).permit(*Hoge::ACCESSIBLE_ATTRIBUTES)
    [:price, :item_number].each do |attr|
      _params[attr] = Bacchus::IntegerFilter.new(_params[attr]).convert
    end

    _params
  end

が無難かなぁ・・・と思いつつこれが頻出するのは嫌だよね。 なんか良いやり方思いついたら教えて下さい。

簡潔かつセキュアなログインフォーム

ログインフォームは一般的に「メール」「パスワード」の組み合わせをSSLで送受信して適当にセッションを付与するのが基本なのだろうけど、以下のような問題点がある。

スマホ時代にパスワード入力は鬱陶しい

最大のポイント。一般論として英数字記号などが適度に含まれててある程度の長さを持っているパスワードのほうが安全だけど、スマホはキーボード切り替えが面倒なのでそんなパスワードを設定してもらうのを期待するのは厳しいのでは。

どうせ使い回すのでユーザのパスワードが他サービスから漏れたら不正アクセスされる

「ぱす」とかで入力候補に使い回しパスワードが出るようにしてる人もいるし、「他サービスから漏れたのが原因だからうちのサービスで被害が出たのはこっちの責任じゃない」というのは法的には成立しても親切ではない。

復旧手段が脆弱

パスワードを忘れた場合、メールアドレス宛に再発行URLを送るのが一般的実装だけど、メールは盗聴可能であるという前提を持つと再発行URLは脆弱。このあたりはいろんなサイトで判断が分かれてるところだけど、再発行URLからさらに秘密の質問的なものを踏ませないと安全ではない。それもどこまで効果があるか疑問。 だいいち秘密の質問にまともに回答してますか？ 僕「test」とか適当に入れてるけど。

というわけで対抗策をいくつか考えてみた。

セッションを破棄せず一つのブラウザでしか使わせない

ログイン・ログアウトの概念をなくす。個人のスマホでサービスが使われるという前提があるならわりと安全だと思う。ブラウザをまたぎたい場合は最初に使ったブラウザからソーシャルアカウントと連携させる。

まぁソーシャル連携は案外敷居が高いので、クロスブラウザでは使えないサービスになるけど。

批判

セッションを破棄しないのは危険。なぜなら個人の端末で使われるとは限らないため。またシークレットモードとかの扱いも面倒(シークレットモードで使ってもらうと困るから)だし、そもそもクッキー消されたら一生ログインできなくなっちゃう。

SMS

メール・パスワードの組み合わせではなく電話番号・ワンタイムパスワードにする。 SMSって盗聴されるんですかね？(ちょっとよくわかってない) これならパスワードいらないし、別メール飛ばすよりもiPhoneだと上からぴょっと出るからけっこう楽だと思うけど。

批判

SMSが届く電話番号がないとサービスが使えない=PCのユーザビリティ低下+MVNOでSMS使えないケースもある。 またSMS実装はコストがかかる。

個人的にはこれLINEに送れるといいと思う。そのままLINEで問い合わせ対応できるようにとか・・・。ないのかな？

安全かつシンプルがいいとも限らない

ただ、最大の問題はユーザが電話番号ログインとかワンタイムパスワード慣れしてないので、いま「電話番号だけでログインできます」というサービスを作っても付いてこれない気がする。

ハナマサの神対応

最近引っ越したのだが以前の家にも今の家にも近所にハナマサ(花正)がある。 ハナマサは独り身には量が多かったり業務用のものが多いので少し不便な点もあるのだけど、安いので助かっている。

ただ、残念なことが一つあった。 引越前の店舗には「鶏ヤゲン軟骨」が置いてあったのだけど、今の近所の店舗には置いてないのだ。

これは鶏一羽から一欠しか取れない、貴重なわりに安い軟骨。調理法は極めて簡単でフライパンで適当に焼いて塩コショウをかけるだけでサイコーのつまみになるので前の店舗時代から相当量を買っていた。

しかし引越し先には存在しない。そこでダメ元でハナマサのHPから要望を出してみた。

いつも大変お世話になっております。 赤坂店の近所から池袋店の近所に引っ越したのですが、赤坂店で販売しており 大変好物だった鶏ヤゲン軟骨が池袋店で取り扱っておらず、非常に残念に思っております。 池袋店で鶏軟骨の販売を心待ちにしておりますので仕入れのご参考にしていただければと思います。

翌日すぐに返信が来た(返信いらなかったけど)。

平素は花正をご愛顧頂き誠に有難う御座います。メールを 拝見しました。ご不便をお掛けし申し訳御座いません。 赤坂店では解凍販売させて頂いておりますが池袋店では 冷凍販売をさせて頂いております。ご要望を池袋店に報告 した結果明日より解凍販売もさせて頂くとの報告を受けて おります。何卒御利用頂けます様お願い致します。

神対応ですね。ハナマサ。ちなみに僕は１年に１，２回くらい、どうしても食べたいものにはわりとこうやって直接問い合わせで要望出してるんですが、以前「光◯」というラーメン屋が醤油味を辞めた時に「どうしても醤油味が食べたいから復活してほしい」と送った時は何の反応もなかったです。ちなみに「光◯」は最近破産したらしいんですが、破産するからいちいち対応できないのか、はたまたその逆か、興味深いものです。