山本ゆうごブログ

山本ゆうごの仕事メモ

最強のフィールド内改行

フィールド内改行って何?

CSVファイルを作っていて悩ましいのが、フィールド内改行。

例えばこんなの

"ユーザーID","ニックネーム","プロフィール"
"tomo1215","ともちゃん","趣味はたべあるき。カワイイもの大好き"
"btspen03","あきちゃん","とにかくBTS大好き
2001line"

3行目の「あきちゃん」のプロフィールがやっかい。プロフィールの中に改行が入ってるから。

CSVの仕様としてはどうよ?

CSVの仕様としては、ダブルクォーテーションで囲まれていれば改行が入っていてもいい。いいんだけど、パースする方がちょっと大変。

エクセルは LF

エクセルはずるいことに、レコード区切はCRLFにしていて、フィールド内改行はLFにしている。だから文字コードレベルでは区別ができる。がしかし、テキストファイルで改行コードが混在するのってめちゃくちゃ面倒。超しんどい。エディタで開いて保存しなおしたらなら、どっちかに統一されかねない。

ファイルメーカーは垂直タブ

垂直タブ(0x0B)というASCIIコードの制御文字がある。エディタによっては、反転したKみたいな化け方をする。Macで昔から有名なファイルメーカーは、垂直タブでフィールド内改行を表現するので、非常にテキストファイルのやりとりがしやすかった。

ただ、この垂直タブ、今ではマイナー。XMLの中にはデータとして保持できなくて、XMLパーサーがエラーを吐いちゃう。超残念。「垂直タブ」って名前からしてフィールド内改行に使っても良い気がする。

完全に独自の文字にしちゃうという案

フィールド内デリミタとして登場しがちなパイプ「|」

そもそも、CSVがカンマ区切であり、フィールド内に何らかのデリミタを用意したいとうケースは有る。よく見るのはパイプ「|」。ただ、ユーザーがパイプを使いたくなったらどうするんだ?って疑問は出て来る。

ユニコード絵文字としてのリターン記号 「⏎」

https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%BF%E3%83%BC%E3%83%B3%E8%A8%98%E5%8F%B7

TwitterAPIのレスポンスを見ていると、改行コードがCRLFではなく⏎となってるケースがあった。他にもmysqlのフロントエンドツールであるSequelproも、一覧での表示には改行を「⏎」で表現していた。表示上は一行にしたいけど、改行があることを示すときには便利。普段のテキストの中にも出てこなさそう。

デメリットとしては、ASCIIコードにも、SJISにも存在しないのでSJISファイルには保存できない。そしてエクセル向けCSVのデフォルトがSJISなので、エクセル向けのCSVには使いづらい。厳密にはUNICODECSVはエクセル向けに作れるんだけど、取扱が難しい。

ASCII制御記号の中から頑張って探す

垂直タブは、XMLの世界からは葬り去られた制御記号だが、まだ生き残ってる制御記号はある。 例えば、0xA0 (NBSP) が存在する。ASCII制御記号でもあるし、SJISでも存在できる。htmlエンティティとして(&#nbsp;)としても書ける。これもユーザーは入力しない。ただ、普通のスペースとパット見区別できない。見えないというのはかなり厄介。

キリル文字から探す

SJISで存在している、目で見える、めったに使わないということで言えば、キリル文字がある。 「ろしあ」で検索すると候補が出て来る。そして私が新人時代に現場で使っていたフィルド内改行がは「Я」。ヤァと呼ぶらしい。「ロシア文字のRの反対のやつ」と声に出しやすい。「ロシア語の本を作るとき苦労するじゃないですか!」って話もありそうだが、たぶんそのときには、JISのキリル文字は使わないだろう。

キリル文字JIS X 0208にも定義されているので、SJIS以外のインフラ、例えばIBMメインフレームとかでも使える。オフコンでも使えるので、めちゃくちゃ守備範囲は広い。日本国内に限れば万人にやさしい。

個人的な勝手にフィールド内改行代替記号ランキング

  1. Я
  2. 垂直タブ(過去お世話になった)
  3. パイプ(|)
  4. おとなしく、普通の改行で正しくCSVパーサーを使う

以下選外 * nbsp (見えない) * LF (見えないしエディタが混乱する)

接続元のドメイン名×メソッドでアクセス制限するのが楽で効果的

攻撃者が捕まるケース

相変わらずセキュリティの問題は出てきていますが、その犯人ってあっけなく捕まったり捕まらなかったり。一方で携帯で匿名掲示板に殺害予告を書くとあっけなく逮捕されてる。これは、接続元のIPアドレスが分かれば、携帯電話会社に警察が問い合わせて契約者を特定できてしまうため。

携帯電話って比較的本人確認が厳格なので、すぐに足がつく。なので、本当に攻撃をしている人達って、日本の通信会社を使わない。IPアドレスで言えば中国が多い。

じゃぁ接続元を日本に絞ればいいじゃない

日本のIPアドレスはだいたいわかる。そして、.htaccessみたいなところに書いておけばいい。 日本[jp]に割り当てられたIPアドレスの一覧 : ipv4.fetus.jp

ただしこの制限をそのまま入れちゃうと、たまに不便。AndoridのChromeとかは、Googleのプロキシを通してアクセスすることで、通信量を節約している。そうなると接続ができない。ちなみにこの制限で私個人も、GyaOとかスカパーのサービスに接続できなくて苦労した。ただし、それくらい乱暴だけどよく使われている手法ではある。

さらにGoogleクローラーは許可したかったりする。

じゃぁ中国と北朝鮮のみを制限すればいいじゃない

そういうフィルタもある。 krfilter : ipv4.fetus.jp

ただし、.htaccessレベルでドーンと制限しちゃうと、「中国からは拒否してるよ!」ってことが攻撃者にバレちゃう。対策練られやすい。

Location × メソッド × ドメインで絞る

例えば、WordPressではadminのディレクトリは、自分しかアクセスしないのなら、自分が契約しているプロバイダのみに絞る。自分が接続しているプロバイダのドメインは、確認くんとかで見れる。

確認くん

私は今、Biglobeでアクセスしているので、mesh.ad.jp のみを許可すればいい。ドメイン別に許可を与えるのは昔ながらのApacheの機能でもできる。

ミケネコの htaccess リファレンス

固定IPアドレスがあるといいのだけれど、そこまで厳密でなくても、プロバイダ外からのアクセスを防止するだけでも1000倍リスクは減る。

また、ドメインでの制限を加えると、IPアドレスからドメイン逆引きするので、パフォーマンスが落ちる。だからログインにつかうようなPOSTメソッドだけに絞るといいでしょう。ログインが高速である必要はない。あと、攻撃者のIPアドレスって、ドメイン名を持ってないことが多いので、逆引きに時間がかかる。攻撃者のみに嫌がらせもできて一石二鳥。

アプリレイヤーでカバーする方法

Webサーバ自体にドメインの逆引きをやらせるのってインフラ面ではハードルが高かったりする。ログイン周りが一番狙われやすいので、ログインの直前に接続元のチェックを入れるという方法もある。IPアドレスPHPでは、$_SERVER['REMOTE_ADDR']で取得可能。

<?php
echo gethostbyaddr("60.237.175.89"); // => flh1aef089.tky.mesh.ad.jp
require 'resolv'
r =  Resolv::DNS.new(:nameserver => ['8.8.8.8'])
p r.getname("202.225.233.218").to_s # "FLH1Amj218.tky.mesh.ad.jp

これで、ドメインが絞れる。docomoからのアクセスがいいなら、「spmode.ne.jp」で絞ったりする。

大半の日本のプロバイダは、.jpで終わるから、それで判断してもいいけど、ソフトバンクはbbtech.netだったりするので面倒。

アプリレイヤーで、接続元ドメインを把握できれば、ユーザが別プロバイダからログインした時に強く警告を出すというようなことも可能。

まとめ

セキュリティに絶対はないので「何桁リスクを減らせるか」を考える。鍵をガチガチにかけると一般ユーザも不便になる。一方で監視カメラは一発目の犯罪の防止はできないが、「足が付きやすい」ことから、抑止にはなる。ピッキングは防げないけど、ドアにカメラがあるとかなりハードルが高い。

Gmailで水平線<hr>を挿入する方法

そう言えば、gmailで水平線ってどうやって入れるんだろうと思って検索すると、こうなる。

oshiete.goo.ne.jp

  • 教えてgooの検索結果とそのコピーサイトで占められる
  • 回答は「何が仰りたいのかよくわかりませんでした。」
  • それがベストアンサー

上からクリックしていくと、このゴミみたいなベストアンサーが続くのでイライラする。

これが正解。

  • gmailの編集画面はhtmlの直接編集はできない
  • しかし、ブラウザでレンダリング済みの画面からのコピー&ペーストは可能
  • どこかしらのサイトから、水平線をコピー&ペーストで可能
  • 手元のPC上でHTMLファイル作って、ブラウザで開いた結果をコピ&ペーストで実現可能
  • 他にも、テーブルでもコピペすれば表現可能

ユーグレナのコアバリューを考えてみる

この記事 http://www.recomtank.com/entry/euglena をみて、いろいろ思うところあり。

起業から上場までのストーリーはR&Dからのスタートアップということで、注目は浴びておりました。

ただ、ビジネスとしては、健康食品というところで落ち着いている。

元は、食糧問題を解決するためのソリューションだったはず。しかしながら、ガチの貧困地域は金がないので売れない。そもそも貧困地域に直接食い物を渡すのではなく、本当なら貧困地域が貧困でなくするようなソリューションが必要。

一方で、貧困が解消するにつれ国民が金を持ち始めると、完全栄養食品よりも不健康な食事の方がニーズが高く、最終的にはダイエット食品に金が集まる。

本当に貧困地域の課題解決が金になるのなら、今頃アース製薬は超巨大起業になっててもいい(今でも大企業だけど「蚊を退治する」という社会的価値からすればマイクロソフトなみの会社でもいいくらい)。

そんで、ユーグレナです。食糧問題解決は金にならない。もう一つのイノベーションとしては、「燃料が作れる」ということ。石油王になれるとなるとこれは急に見る目変わりますよね。すごいすごいと。

1平方kmの培養プールで生産できるミドリムシは油脂換算で日間約11.4t

とある。一見すごい気がするが、1平方kmってでかすぎる。100万平方メートルなので。現実的には千分の1の1,000平方メートル換算にしましょう。20×50メートルのプールならそのスペースで何できるかが分かる。 改めて計算すると、

1000平方mの培養プールで生産できるミドリムシは油脂換算で日間約11.4キロ

ミドリムシの油脂の密度は知らないが、ざっくり10リットルとする。

ちなみに10リットルの原油がどれくらいかの価格かというと、今は1バレル(160リットル)40ドルだから、1リットルあたり約25円。原油と同じ価格で売るなら(売れるのか?)、一日250円の売上。プール1個の面積から燃料を得ようとすると年間では約8万円の売上。これちょっと厳しい。同じ面積つかうなら別の商売したほうが良さそう。

まとめると、ユーグレナ自体の技術的ブレイクスルーはすごいのだけど、商売を考えると、以下の点が課題。

  • 食料問題の解決はビジネスにはならず、必要とされているのは痩せ薬
  • 今あるエネルギー問題は、エネルギー不足ではなく、エネルギー価格が安すぎて投資が回収できないという問題

元を正せば、食べ物も燃料も原価までたどるとめちゃくちゃ安い。商売しようとすると、ある程度の「期待価値」みたいなのが必要で、結局将来的にも健康食品としてのポジションが一番ビジネスになるとは思う。「完全食品ミドリムシだけで絶食合宿!」みたいな「コト消費」にすれば、客単価15万もありえる。

あとは、日本の自治体が学校給食の地産地消をうたっているわりには地元の農産物の生産能力がないので、学校給食を独占するという手もある。

Google Cloud Strage の東京リージョンができたので、巨大なパラパラ漫画を実装してみた

やっとGoogle Cloud Strageの東京リージョンがオープンしました。 S3+CloudFrontの組み合わせのように使えるので、配信にも便利かも知れません。

手順は以下の通り。

  • バケットを作ります
    • バケット単位でリージョンは選べますが、東京リージョンが選べるのは、Regionalというストレージクラスだけのようです。
  • ファイルのアップロードはコンソールからできる
    • S3でもそうですが、ブラウザからアップロードできます。
    • フォルダのドラッグ&ドロップでもアップロードできます。
  • 一般公開はファイル単位
    • フォルダ単位での公開ができません
    • 「デフォルトのオブジェクトの権限の編集」はできますが、アップロードする前に設定する必要があります

そして、大量のjpegをアップロードして、パラパラ漫画にしてみた

画像を高速に切り替えてアニメーションにするというのは、CSSスプライトでよくやる手法ですが、今回は大きな画像でコマ数も多いので、そのままロードします。アニメーションが始まるちょっと前に、JavaScriptの中で、Image オブジェクトをnewして、srcにセットしておきます。あとは、setTimeoutで、ちょっとずつずらしながら、1個のimgタグのsrcを書き換えていくだけ。

デモ

https://storage.googleapis.com/yugoyamamoto/parapara/dance.html

1280pxの巨大な画像を24fpsで動かしてみましたよというデモです。この実装では、3割ほど画像がロードされたらアニメーションが動き始めるロジックにしています。あとは、ロードしながら追いかけてアニメーションします。一応スマホでも動きました。流石にこのサイズのimageオブジェクトが大量になると動きは怪しいですが、画像が一度キャッシュされるとスムーズにアニメーションします。(手元のGALAXY Note3での検証)

影響力の武器をベースにした転職活動

「影響力の武器」というまぁまぁ有名な本がありまして、それを転職活動につかうとどうなるかという話。実際に採用する側もこういうことで左右される。

理由付け

志望動機そのものだが、大した理由でなくてもいい。理由があることそのものが大事。過去の自慢話した後に「なので御社にも貢献できると思ったんです」でいい。

返報性(reciprocation)

何かお土産を持ってく。交渉の現場では、「いい情報」。競合他社の採用現場の状況がわかるといい。やりすぎると秘密の漏洩になるのでほどほどに。

希少性(scarcity)

他社での採用活動が進んでいるように見せると、早く決めなくちゃいけないと思う。

権威(authority)

いわゆるアレオレ詐欺。前職ですごい仕事をしていると思わせる。実際にやっていれば素直に「分かりやすいラベル」でアピールする。

コミットメントと一貫性(consistency and commitment)

一般的な交渉事では、小さな合意を相手から引き出して、「やっぱりヤメ」ということができなくなるようにする。採用の現場では、面接とは別に面談をお願いして、「次の約束」を細かく取りつける。何度も会ってるということ自体が「正式採用間近」に見える。逆に急にアポが取りづらくなったら、「一貫性」を保つために、最終結論もNGの見通しが高い(これは、普通の営業現場でも同じ)。

好意(liking)

そもそも、御社のことが好きですということは最低限言う。

社会的証明(social proof)

本出してたりすると分かりやすい。原稿料が安くてもいいので、共著で何か執筆しているとAmazonに著者として名前が載る。

SQLとO/Rマッパーのポエム

SQLとO/Rマッパーのポエム

http://qiita.com/kantomi/items/f527bc717b10e86335af に関して、最初にO/Rマッパーを見た時の感想としては、同じ印象をもちました。

O/R マッパはSQL知らなくてもいい説には反対

なので新人研修の際には、ActiveRecordを触らせる前には必ず、素のSQLも手書きで一通り書かせている。phpmyadmin やsequel proを使う場合にも素のSQLを書かざるを得ない。そんなのエンジニアじゃなくて今どきのWebディレクターならやってる。

したがって、ORマッパを使ったところで、二重に勉強しないといけないというのが正解かなと。

わたしが作ってる研修メニューでは、 ・素のSQLを一通り覚える ・Railsを通すのではなく、素のRubyにActiveRecordeだけをrequireして、コードの中で接続し、 ActiveRecord::Base.logger = Logger.new(STDOUT) で、どんなSQLが流れているかを一通り眺めながら、ActiveRecordの各メソッドが発行しているSQLを見せる。 ということをしている。

そこまでして二重に学習しなくてはならないの?って質問には、はいすみません、今どきの子大変ですね。でもソースはちょっとだけ見やすいですね。

逆にSQLをとことん高度にしてアプリまで書いちゃうというアプローチ

実はそういうプロダクトがあった。OracleSQLPL/SQLと言って、普通のプログラミングもできる。ストアドプロシジャとか呼んでる奴。プロダクトとしては、KeyWeb Creator という名前だった。しかしながら、そもそもストアドプロシジャの外でPL/SQLをつかう人もいなく、制約も多かったので、陽の目を見ることはなかった。ということで、市場原理の中ではSQLでは最強ではなくなった。

O/Rマッパーをつかうってことは、RDBをNoSQL的に使ってない?

これはYES。複雑なSQL使えないし、基本的な動きは、主キーでダイレクトに取ってくるだけの動きが多い。

心配な点としは、RDBはKVSにくらべて機能が大きいために主キーダイレクトで引っ張ってくるにしても、オーバーヘッドも大きいのではないかという懸念。これはエンジンごとにすごく違う。mysqlはスレッドタイプのコネクションなので、コネクションの接続からしてめちゃくちゃ軽い。

この辺の経験値というのが、業務アプリとユーザーサービスと結構違っている。 業務アプリでは、DBエンジンはOracleバッチ処理性能が大事 ユーザーサービスは、 DBエンジンはMySQLで、ユーザーレスポンスが大事 ユーザレスポンスを大事にするときって、凝ったSQLを書かないというのが割りと大事。レコードの件数によって、プランが変わるようなのは避けたい。

例えば、画面には数十件しかでないのだから、JOINせずに、主キーダイレクトで20回くらいアクセスが発生しても一向にかまわないのだ。

ここでも、RDBをNoSQLみたいに使ってるという批判はアリそうだけれど、主キーで高速にデータを取ってくるってこと自体は、mysqlに関しては超高速。甘えていい。

NoSQLを使えばいい場面でも、マスタの管理とか、主キーそのものがintで管理されていたりとか、実装レベルで便利だったりする。