坂口安吾とセーフティーネット
業務中、いつものようにlivedoor NEWSを確認していたら衝撃を受けました。
二世芸能人の不祥事が取りざたされる中、果たして親の七光りだの、過剰な期待や注目を受けざるを得ない彼らは幸せなのだろうかと思いを馳せていると、次のツイートに第二の衝撃を受け思わず天を仰ぎました。
坂口安吾のパーティグッズ感。これでヒゲがあれば完璧。 pic.twitter.com/NEEmaODmEV
— 吉田光雄 (@WORLDJAPAN) 2016年9月5日
三級知識階級に属するルンペン思想家を自認する私は、今年著作権が切れkindleで激安で並んだ坂口安吾全集を読んでいたわけですが
彼の評論で最も著名だろうという作品に「堕落論」というのがあるんですね。
ちなみに思想家を自認するケは小学生のころからあったので、親が絶賛していた堕落論を小6で読んでいたんですが(事実)、さすがにそのころは内容がいまいち理解できず、いつか堕落論とか難しい話が読めるようになりたいなぁという願望を形成しました。
堕落論は今読むと武士道や封建的権威を否定し、処女の純血純潔を否定し、戦後実存主義の典型のようなことを言っている(というか戦後実存主義をリードしたといえるか)、かなり読みやすい文章です。
人間は堕落する。義士も聖女も堕落する。それを防ぐことはできないし、防ぐことに寄って人を救うことはできない。人間は生き、人間は堕ちる。そのこと以外の中に人間を救う便利な近道はない。
(略)
そして人の如くに日本も亦堕ちることが必要であろう。堕ちる道を堕ちきることによって、自分自身を発見し、救わなければならない。政治による救いなどは上皮だけの愚にもつかない物である。
最後の数行を読んでもその論旨は明瞭なものですが、私はなんとなく同意しつつも何か簡単に同意していいのだろうかと言語化できないものを抱えていました。
そして今日、はっきりとわかったのですが、これは 文明論であるけども、社会思想ではない ということなんですね。
なぜなら坂口安吾の論理をそのまま坂口杏里に適応すれば、 坂口杏里はこのままMUTEKIからS1, 無修正, 東京熱と流れて、覚せい剤で逮捕されたりしながらロック座でストリッパーになるしかないのではなかろうか。
安吾先生はセーフティーネットなんていらないというけれど、今必要なのはちゃんとストップかけてくれる人じゃないでしょうか。
まぁこれはネタなので、まともな文学クラスタはその豊富な読解力でマジレスしないでほしいのですが、せっかくなので民進党の代表選、1人ぐらいは「坂口杏里助け隊」を結成し、AV業界にするどいメスを当てつつついでにしばき隊や在特会とも三つ巴の泥仕合を展開してほしいなぁ。
Google App Engine + Go の良い点・辛い点
ありがちなタイトルだが少しまとめてみます。 案件でAppEngineを使って3ヶ月程度になりますが、限られた用途においてベストパフォーマンスを発揮することは間違いないと思います。 しかしながらいくらかの不安点があるのも事実です。 自分の思考を整理するためにもまとめてみます。
Google App Engineの利点
1. ログやバッチ処理、ジョブの管理が容易
最大の魅力の一つと思いますが、ロギングやバッチ実行に対する管理コストが圧倒的に低いです。 そのほかメール送信や画像等のアップロードなどの機構を標準で持っています。
2. デプロイが容易
コードを書き始めてデプロイまであっという間です。Goの場合、デプロイは20秒程度で終わります。
3. スケーラブル
全く何も考えずにスケールするとまでは行きませんが、インフラに対して考慮すべき諸々から解放されます。 datastoreもスケーラビリティに優れています。バックエンドでCloud SQLを使用した場合はある程度DBがボトルネックになります。
Goの利点
1. 型安全である
これは説明するまでもないですがスクリプト言語に比べ型がある分、同じ処理をする場合に堅牢でしょう。 またコンパイラが厳密すぎるほど厳密なので、不必要なimportでもエラーを出します。go fmtで標準でコードフォーマットする機能もあります。
2. トレンドである
なんだかんだこれが大きいのですが、Goは体感として2010年以降に流行り始めた言語として最も勢いのある言語の一つだと思います。ほかはSwiftとかですかね。 トレンドであることは情報が多いとか枯れる速度が早いという実利もあるけど、人が集まってるほうが賑やかで楽しいと思います。
3. そのほかもいろいろ
goroutine便利らしいですね。ただ、appengineだとあまり出番ないです。使えないわけではないらしい あとAppEngineに関連してスピンアップが40msと非常に優秀なんですが、これは他も400msとかなのでそこまで優位かと言えば...
Google App Engineの辛い点
トレンドに対する不安
App Engineは2008年からリリースされ、2012年くらいにはかなり下火になっていた印象です。 ただし近頃は時代が追いついた？のかGo人気と相まってGAE/Goの資料を良く見ます。
とはいえGoogleが本腰を入れているとはあまり思えない部分があります。 GAEで書いたコードはGAEで運用し続けるのが前提となるわけなのでリスクの大きさは否めません。
Datastoreの制約
スケーラビリティと可用性の恩恵を受ける分、RDBMSでは考えられない制約があります。 少し触った程度で次のような問題とぶつかりました。
LIKE検索ができない
search APIを使うしかない？
OR検索ができない
これは非常に辛く、クエリを分けるかOR検索せずに済むよう検索にマッチするためのindexを作っておく必要があります。
例として restaurant.cuisine = japanese or korean という発想ではなく restaurant.cuisine = asian とした上で、 restaurant.cuisine がリストで [asian, japanese] と複数持つ。
Go の辛い点
ジェネリクスがない
ジェネリクスがないため、定義したstructに対して似たようなコードをたくさん書く羽目になります。
reflect を使う手もありますがおそらくGo的なコードではないでしょう。
テンプレートが辛い
テンプレートエンジンとして標準の html/template がありますが、Railsの豊富な機構になれているといろいろな不自由があります。
Railsでいう partial はGoであらかじめ
tmpl, _ := template.New("").Funcs(funcMap).ParseFiles(paths...)
のように使用するpartialを全て ParseFiles の中に入れる必要があります。
そうすると render のネストのようなことをするときに controller のほうがあらかじめネストされたファイルまで関心を持たないといけません。
Railsのviewは非常に多機能なので render "category/#{@category.category_type}" のようなことも当然のようにできます。
同等のことはできるのかもしれませんが、実装のしわ寄せがviewの外側にできます。
このあたりから、結局同等のことをやるために段階を踏んで細かいコードをたくさん書いていく必要が出てくるのに気づきます。
比較としてGoのほうがRubyよりバグが出ないかというと、このように最終的なゴールまでの過程が長くなる場合当てはまらないように感じています。 そしてRailsで簡単にできたことは、Goだと簡単にはできません。
総論； 堅牢性・保守性はメリットか？
GAE/Goを評価する論調として「LL言語より開発速度はやや遅くなるものの、それを超える保守性・堅牢性が得られる」と言われますが、私が携わるスタートアップ程度では開発速度は非常に重要なものですし、ユーザ数に上限があるサービスという前提を置くのは悪いことではない とも思います。
開発速度が求められるフロント部分はFlexible EnvironmentでRubyを、データベースにCloud SQLを主に利用した上で一部を GAE/Goで書く、などの利用もありなのではないかと感じ始めています。
マルサの女・脱税
前回の記事はこちら
あまちゃんの夏ばっぱが若いころ国税調査官をやっていたころの話である。
マルサの女1ではラブホテル経営者の山崎努を追い込み、マルサの女2では地上げ屋兼宗教団体管長の三國連太郎と戦う。
どちらも実によくできてる。
１作目はラブホテルのように領収書を切る必要がなく、明確な消耗品も少ない産業で容易な売上の除外が大きなテーマになっている。
法人は個人と同様所得に対して課税されるわけだけど、売上が小さく経費が大きいほど払う税金が減る。だから手口は売上を小さく見せるか、経費を大きくするかのどちらかになる。
理髪店なんかは誰も見てない所でお客さんの髪を切っちゃえば簡単に売上を別の勘定にできそうなものだけど、そういう典型的な手口は簡単にバレる。というのは、税務署や国税からすればどんな業態でも財務３表が見れるわけだから、同一業態の中でその比率がおかしい会社を順番に洗えばいいわけ。
そして税務調査に来られて、消費したシャンプー剤や毛髪の廃棄料が明らかに多いとそれを指摘される。
一方、２作目は脱税スキームに宗教法人が組み込まれている。マルサの女の世界では宗教法人が周囲のパチンコ屋やソープランドの実質的経営者、ということになっていた。
そこで宗教法人の税金について少し調べてみることに。
宗教法人にとってその宗教活動に関わる金銭に税金がかからないのは以下のような理由だ。
例えば会社の有志十数人で旅行にいく。一人15万円かかるとする。15人いると225万円集まる。
これを幹事がまとめて旅行代理店に支払う。そして全員で旅行にいく。
このとき、幹事は集金した225万円に対する税金を払う必要はあるだろうか？ あるはずがない。
彼らは自分のお金を自分の口座の外に出しているものの、皆で寄せ合ったお金を皆で使っているだけだ。
宗教も拡張してこの原理による。他人のお金を自分のものにしたときに税金がかかり、自分のお金を移動させることには税金がかからない。
屁理屈のようだけど、そういうことらしい。
ちなみにこの本はそのほかにも参考になることが多くて、とくに新興宗教のビジネスモデルや、各団体の事業規模は勉強になった。
この本に出てくる真如苑、阿含宗とかは知らなかったんだけど、武蔵村山に広大な土地を買ったり、相当潤沢なキャッシュを持っているという。信者数で割ると創価学会を圧倒するらしい。
宗教法人が脱税のスキームに組み込まれることは珍しくなく、本の紹介によれば地上げ+宗教+脱税のハイブリッド(マルサの女2の話そのもの)が近年も実際に会ったという。その場所はこちら。
貞子3Dの感想
まぁ一言で言えば駄作なんですけど、だいたいあらすじはこんな感じ。
石原さとみが可愛すぎてずっと勃起してた///
貞子3D≒ワンピースです。
まず、物語の概要は、覇王色の覇気と見聞色の覇気を身につけている石原さとみが、恋人のため、みんなのためにクモ型足長人間をやっつけていくアクション映画です。分類でいうと、アクション、感動。と言ったとこでしょうか？
この映画を怖いと感じた方はおそらくほとんどのホラー映画を怖いと感じるでしょう。つまり全然怖くないです。とりあえずストーリー展開早すぎ。また貞子3D２という形ではなくべつの形で続きがありそうな気がしました。それで最後貞子の顔が出るのですが、めちゃくちゃカワイイですbbbbbbbbb 正直ヌケるレベル。。。。。。。
あー石原さとみかわいかったーーーーーーーーーーーーー
yahoo知恵袋より引用
もう少し補足します。
話を単純化するために石原さとみは一人目の貞子とします。
平祐奈を二人目の貞子とします。
橋本愛を３人目の貞子とします。
あなたはどの貞子が好きですか？？
上祐・少年の国・陰謀論
面白い動画を見つけた。
ライターのターザン山本、最近ビートたけしに怒られた吉田豪、芸人のプチ鹿島(この人は知らなかった)、そしてオウムで麻原の一番弟子としてメディアに引っ張りだこだった上祐。この4人によるトークライブ。
近年(といっても3,4年前になるけど)上祐がそこまで言って委員会とかオウム総括系の真面目な討論番組等にゲスト出演し、そのたびに真面目な表情でオウムの反省なりを話しては、周りの出演者からバッシングされてることは知っていたが、こんなカジュアルなイベントにも出てるのは知らなかった。
そこまでいって委員会なんかでは「お前が坂本弁護士殺害を知ってたのにそれを否定して遺族を侮蔑していたのを忘れない」だのサイコパスだのと散々な言われようであった。まぁそれだけ見れば少しかわいそうなのだが、当時のオウムをリアルタイムで見ていた人、つまり30代後半くらいの人からはそんなふうに言われても仕方ないように見えるかもしれない。
(私個人としては上祐はわりとセーフで引かない。たぶん佐川一政とか少年Aになると引いちゃう。)
トークライブの内容は本当に面白いしわりと長いので作業用BGMにでもして聞くとちょうど良いのだが、かいつまんで言えば
・上祐が麻原を盲信していたように、自分も猪木を盲信していた
・団体の危機に際しロシアから帰国した上祐は、前田日明と一緒(プロレスファンなら納得できるたとえらしい・・)
・上祐はセックスはもちろんオナニーもしない、瞑想によって性のエネルギーを上半身に移せるらしい、しかし夢精はOKとのこと
・上祐的にはエヴァンゲリオンは麻原のビジョンに似てるらしい
・「大川隆法と奥さんが離婚して、奥さんがアフロディーテだったのが新解釈で新しいアフロディーテが3人できた」などのゴシップも上祐はウォッチしている
・ロシア出張中、ボリショイ・バレエは見に行った。感動したらしい。
上祐が地下に潜る修業を行った話(↓たぶんこれ)も面白い。
吉田「一人で入って大変じゃないですか」
上祐「一人のほうが少ない酸素で足りるし一人のほうがずっと楽」
鹿島「(ターザン山本に)週プロの全盛期だって同じじゃないですか？ 閉じ込めて原稿書かせて消費してくだけでしょ？」
上祐「それはいくらなんでも笑」
ターザン山本「チリの落盤事故観ててどうでした？」
上祐「あれは酸素があるから〜〜。だけど精神的に落ち着かないでしょうね」
動画は他にもいくつかあって、なぜか小沢一郎についてどう思うか見解を問われわりとまともな返しをしてたり、謎の右翼芸人から「ダライ・ラマに迷惑をかけたのだから今からフリーチベット運動やりましょう」と誘われるなど、かなり私のツボにハマった内容だった。
少年の国
最近この「少年の国」というマンガを読んだが、なんとなくオウムが伸びた80年代・90年代の世相を感じることができた。
===============================
「科学的に証明されている教団の考えがあって、みんながこの通りに活動していかないと環境破壊等で地球は滅びる」というオウムチックな思想で小さな活動団体が巨大化していく。
最終的には教団に批判的な有識者を呪い殺そうとして、呪いが成就しなければそれを成就させるために凶行に及ぼうさえするようになって・・・
===============================
というお話し。今から見れば完璧にオウムがモデルになっているのだけど、この作品が発表されたのは91年である。つまり世間がオウムに確信的に疑惑を深めた95年から4年も前のことだ。
オウム事件について、バブル全盛期で世間が浮ついている中、それ違和感を感じるあぶれた学生たちの心を引きつけた、という主張がなされることがあるけど、これは半分間違ってると思う。そういう話なら「リア充・ぼっち」という言葉ができた今のほうが宗教が流行ってもよさそうだし、上祐には彼女がいた。(彼女と一緒に出家しましたという人もいる)
そういうわけで、まぁそういった人もいたのは間違いないにしてもそれが特徴的だったとまでは言えないのではなかろうか。
それよりは世紀末の特別感だったり、いよいよ地球がパンクするという主張が増え始めた時期というのはオウムを受容した要因として意外と大きいかもしれない。
陰謀論
オウムが発展した思想的背景には妄想的終末論やフリーメイソンとオウムとの戦いというような陰謀論があるわけだけど、オウム自体に対する陰謀論、つまりオウムは北朝鮮・ロシアと密接な関わりがあったのではないかとか、暴力団との関係、村井秀夫刺殺の真相などは未だに世間からの憶測が絶えない。
このへんについてもトークライブで上祐がざっくばらんに話していて、「ロシアとは金を出せばエリツィンと会える所までは持って行けて、金出せばなんでも買えた」とか「村井刺殺に暴力団が関係していたのは事実だが、麻原が村井を疎んで消すように依頼したのではないか」などのことは言ってるのだけど、これについては関係者が存命なので最も陰が感じられる言い回しだった。
上祐が意図してしゃべっていないことがあるとすればやはりこのへんは本命だろう。
その関係でいろいろ見てたら、「村井秀夫刺殺事件の真相を追って」というズバリなブログを発見してしまった。
まぁ陰謀だの終末論なんていうのはエンターテイメントとして、与太話として消費するのがちょうどよいだろう。だから昨今のAIが人類を滅ぼすなんていう話も真に受けてはいけない。
npmでパッケージの複数バージョンがサポートされると幸せなんだけど
とうとうbrowserify-railsを入れてしまいました。 で、jsのライブラリがnpmで管理されるようになったんですが、一つ問題が。
僕はふだん
app/assets/javascripts/recipe.js
app/assets/javascripts/kitchen.js
app/assets/javascripts/restaurant.js
みたいにある程度ページ構成とかで同一アプリの中でも住み分けができるものをこのように分割して、jsからcssからcontrollerに至るまで疎結合にしてます。 これには大きく理由が２つあって
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を見つけました。
要約すると例えば
{
"jquery as jquery1.8" : "1.8";
"jquery as 2.1" : "2.1"
}
みたいにできたら良くない？っていう主張に対して、isaacs氏が「リファクタリングが足りない」「npmの責務はdependenciesの中のものをnode_modulesの中にぶち込んでrequireできるようにするだけ」と突っぱねてる感じ。
ユースケースとして上で上げてるのが一つ目、あるモジュールで複数のバージョンに互換性があるか検証したいというのが二つ目、２つ以上のプロジェクトをマージしたケースなどが３つ目として上げられている。やっぱり同じことを考えている要望は多いようだが・・・。
個人的には将来的にマイクロサービスにしていきたいものを現実問題として結合させたままにしておこうというノリなのでクライアントサイドはなるべく分けたいのだがどうしようか・・。
前任のエンジニアをリスペクトしよう
一人か二人で保守していたサービスがあって、そのエンジニアがなんらかの事情でいなくなったり入れ替わりで引き継ぐことになったとする。 こういうとき世間全体を見渡せば、前任のエンジニアが自分より劣っているか優れているか、確率は２分の１である。
しかしながら一般的に、前任のエンジニアはディスられやすい。というのは、たいていの現場では引き継ぎは不十分だったり、ソースコードには負債があるためである。
心に胸を当てて考えて欲しいのだけど、前任のエンジニアをdisったことはないだろうか？ 今から考えれば私も「ここの実装はXXだ」とか「サービスに対して過剰に設計してる」だとか「テストがない」とか散々disってた気がする。 しかし最近は手離れしたプロジェクトが増えてきたので、言われる立場になることも多少出てきた。「初期の設計がおかしい」とか「拡張性がない」とか。
当時はプログラミング初めて３ヶ月とかで何もわかってなかったのをタダ同然でプロトタイプとして作ったようなもんなのに、なんだかんだ何年もそのまま使い続けて仕様も変わっていってる中でそんなこと言われても困りますよとか、言いたいことはいろいろあるのだけど上のdisも所詮そんなようなものでしかない。
というわけで、これからは建設的な開発のために以下のようなことを心がけようと思っている。
誰かに引き継いでもらう場合
- 難解な設計は行わない
- ドキュメントを作る
- 技術的な負債や自分が気になっている点、開発期間を経て仕様が変わったことでおかしくなってしまっている点などは明文化する
- 平均的なエンジニアが難なく引き継げるものを作る
- そういう意味でReactとかってどうなんだろう？
誰かのものを引き継ぐ場合
- 前任者disはあまり行わない
- 学べるところは学ぶ
- そのレポジトリに含まれてる全ての知識で前任者より自分が優っているということはほとんどない
- 前任者のスキルが低くても、「スキルが低い人にありがちな設計ミス」などが分かる
- 今のアプリケーションや仕様に対して、ソースコードがおかしいのはしょうがない部分もある。時間軸を考慮してあげる
お互い想像力を駆使したいところである。
