プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

上祐・少年の国・陰謀論

面白い動画を見つけた。

www.youtube.com


ライターのターザン山本最近ビートたけしに怒られた吉田豪、芸人のプチ鹿島(この人は知らなかった)、そしてオウムで麻原の一番弟子としてメディアに引っ張りだこだった上祐。この4人によるトークライブ。

近年(といっても3,4年前になるけど)上祐がそこまで言って委員会とかオウム総括系の真面目な討論番組等にゲスト出演し、そのたびに真面目な表情でオウムの反省なりを話しては、周りの出演者からバッシングされてることは知っていたが、こんなカジュアルなイベントにも出てるのは知らなかった。

そこまでいって委員会なんかでは「お前が坂本弁護士殺害を知ってたのにそれを否定して遺族を侮蔑していたのを忘れない」だのサイコパスだのと散々な言われようであった。まぁそれだけ見れば少しかわいそうなのだが、当時のオウムをリアルタイムで見ていた人、つまり30代後半くらいの人からはそんなふうに言われても仕方ないように見えるかもしれない。

(私個人としては上祐はわりとセーフで引かない。たぶん佐川一政とか少年Aになると引いちゃう。)


トークライブの内容は本当に面白いしわりと長いので作業用BGMにでもして聞くとちょうど良いのだが、かいつまんで言えば

・上祐が麻原を盲信していたように、自分も猪木を盲信していた
・団体の危機に際しロシアから帰国した上祐は、前田日明と一緒(プロレスファンなら納得できるたとえらしい・・)
・上祐はセックスはもちろんオナニーもしない、瞑想によって性のエネルギーを上半身に移せるらしい、しかし夢精はOKとのこと
・上祐的にはエヴァンゲリオンは麻原のビジョンに似てるらしい
・「大川隆法と奥さんが離婚して、奥さんがアフロディーテだったのが新解釈で新しいアフロディーテが3人できた」などのゴシップも上祐はウォッチしている
・ロシア出張中、ボリショイ・バレエは見に行った。感動したらしい。


上祐が地下に潜る修業を行った話(↓たぶんこれ)も面白い。

www.youtube.com

吉田「一人で入って大変じゃないですか」
上祐「一人のほうが少ない酸素で足りるし一人のほうがずっと楽」
鹿島「(ターザン山本に)週プロの全盛期だって同じじゃないですか? 閉じ込めて原稿書かせて消費してくだけでしょ?」
上祐「それはいくらなんでも笑」
ターザン山本「チリの落盤事故観ててどうでした?」
上祐「あれは酸素があるから〜〜。だけど精神的に落ち着かないでしょうね」

動画は他にもいくつかあって、なぜか小沢一郎についてどう思うか見解を問われわりとまともな返しをしてたり、謎の右翼芸人から「ダライ・ラマに迷惑をかけたのだから今からフリーチベット運動やりましょう」と誘われるなど、かなり私のツボにハマった内容だった。

少年の国


最近この「少年の国」というマンガを読んだが、なんとなくオウムが伸びた80年代・90年代の世相を感じることができた。

===============================
「科学的に証明されている教団の考えがあって、みんながこの通りに活動していかないと環境破壊等で地球は滅びる」というオウムチックな思想で小さな活動団体が巨大化していく。
最終的には教団に批判的な有識者を呪い殺そうとして、呪いが成就しなければそれを成就させるために凶行に及ぼうさえするようになって・・・
===============================


というお話し。今から見れば完璧にオウムがモデルになっているのだけど、この作品が発表されたのは91年である。つまり世間がオウムに確信的に疑惑を深めた95年から4年も前のことだ。

オウム事件について、バブル全盛期で世間が浮ついている中、それ違和感を感じるあぶれた学生たちの心を引きつけた、という主張がなされることがあるけど、これは半分間違ってると思う。そういう話なら「リア充・ぼっち」という言葉ができた今のほうが宗教が流行ってもよさそうだし、上祐には彼女がいた。(彼女と一緒に出家しましたという人もいる)

そういうわけで、まぁそういった人もいたのは間違いないにしてもそれが特徴的だったとまでは言えないのではなかろうか。
それよりは世紀末の特別感だったり、いよいよ地球がパンクするという主張が増え始めた時期というのはオウムを受容した要因として意外と大きいかもしれない。

陰謀論

オウムが発展した思想的背景には妄想的終末論やフリーメイソンとオウムとの戦いというような陰謀論があるわけだけど、オウム自体に対する陰謀論、つまりオウムは北朝鮮・ロシアと密接な関わりがあったのではないかとか、暴力団との関係、村井秀夫刺殺の真相などは未だに世間からの憶測が絶えない。

このへんについてもトークライブで上祐がざっくばらんに話していて、「ロシアとは金を出せばエリツィンと会える所までは持って行けて、金出せばなんでも買えた」とか「村井刺殺に暴力団が関係していたのは事実だが、麻原が村井を疎んで消すように依頼したのではないか」などのことは言ってるのだけど、これについては関係者が存命なので最も陰が感じられる言い回しだった。
上祐が意図してしゃべっていないことがあるとすればやはりこのへんは本命だろう。

ameblo.jp

その関係でいろいろ見てたら、「村井秀夫刺殺事件の真相を追って」というズバリなブログを発見してしまった。

まぁ陰謀だの終末論なんていうのはエンターテイメントとして、与太話として消費するのがちょうどよいだろう。だから昨今のAIが人類を滅ぼすなんていう話も真に受けてはいけない。

npmでパッケージの複数バージョンがサポートされると幸せなんだけど

とうとうbrowserify-railsを入れてしまいました。 で、jsのライブラリがnpmで管理されるようになったんですが、一つ問題が。

僕はふだん app/assets/javascripts/recipe.js app/assets/javascripts/kitchen.js app/assets/javascripts/restaurant.js

みたいにある程度ページ構成とかで同一アプリの中でも住み分けができるものをこのように分割して、jsからcssからcontrollerに至るまで疎結合にしてます。 これには大きく理由が2つあって

app/assets/javascripts/application.js

のように単体のjsに全て圧縮するとPVの少ないマイナーなページだけで使う巨大なライブラリなども含まれた時に無駄な読み込みが増えてしまうこと。

ある程度の画面構成をサブアプリとして捉えれば、サブアプリごとにjsのライブラリを変えていって「今までBackbone.jsを使っていたから今後も使い続ける」のような保守的な理由でモチベーションが下がることを予防するためです。

例えばRailsの場合だと

vendor/assets/javascripts/vue@0.12.1 vendor/assets/javascripts/vue@1.0.0

のようにライブラリを複数バージョン入れておけば、それぞれのrequireで読み込み先を変えて古いページでは古いバージョンをそのままで、新しいページでは新しいバージョンを使用、ということもカジュアルにできました。

時間があったときに古いページのjsもアップデートするか、そもそも古いページでフルリニューアルが合った際などに一気に古いバージョンを捨てるだけなので新規の実装への縛りが減ることやコードの廃棄可能性(他への依存が少なくまるっとリプレイスできる)が上がるので大変気に入ってる仕組みです。

ところが、npmだと現状package.jsonに書いたライブラリのバージョンは一つしか入らないようなんですね。

このことで議論になっているissueを見つけました。

github.com

要約すると例えば

{
  "jquery as jquery1.8" : "1.8";
  "jquery as 2.1" : "2.1"
}

みたいにできたら良くない?っていう主張に対して、isaacs氏が「リファクタリングが足りない」「npmの責務はdependenciesの中のものをnode_modulesの中にぶち込んでrequireできるようにするだけ」と突っぱねてる感じ。

ユースケースとして上で上げてるのが一つ目、あるモジュールで複数のバージョンに互換性があるか検証したいというのが二つ目、2つ以上のプロジェクトをマージしたケースなどが3つ目として上げられている。やっぱり同じことを考えている要望は多いようだが・・・。

個人的には将来的にマイクロサービスにしていきたいものを現実問題として結合させたままにしておこうというノリなのでクライアントサイドはなるべく分けたいのだがどうしようか・・。

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

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

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

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

当時はプログラミング初めて3ヶ月とかで何もわかってなかったのをタダ同然でプロトタイプとして作ったようなもんなのに、なんだかんだ何年もそのまま使い続けて仕様も変わっていってる中でそんなこと言われても困りますよとか、言いたいことはいろいろあるのだけど上の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 => 拡大できない

f:id:tkot:20160326170909p:plain:w300

f:id:tkot:20160326170914p:plain:w300

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

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

f:id:tkot:20160326170919p:plain:w300

f:id:tkot:20160326170923p:plain:w300

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

Yahoo => 一部できる

f:id:tkot:20160326170928p:plain:w300

トップはできなかったが

f:id:tkot:20160326170932p:plain:w300

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

はてブ => できない

f:id:tkot:20160326170936p:plain:w300

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

Amazon => できない

f:id:tkot:20160326170940p:plain:w300

朝日新聞 => できない

f:id:tkot:20160326170945p:plain:w300

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

Naverまとめ => できない

f:id:tkot:20160326170948p:plain:w300

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

Wikipedia => できる

f:id:tkot:20160326170952p:plain:w300

楽天 => できない

f:id:tkot:20160326170954p:plain:w300

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

Apple => 拡大できる

f:id:tkot:20160326171002p:plain:w300

Google => 一部できる

f:id:tkot:20160326171005p:plain:w300

f:id:tkot:20160326171008p:plain:w300

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

まとめ

予想以上に拡大できないサイトのほうが多かった。文字数が多くて文章の内容を伝えるのが価値になるサイト、とくに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」のマークを壁の「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",  "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

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