認証と認可の違いについて調べる
個人的な復習用。
認証とは？
特定の人物や物を特定すること、相手の身元を確認すること。
認証の方法
- 知的情報での認証
- 例えば、パスワード認証などのように本人しか知らない複数のキーワードの組み合わせでの特定
- 生体情報での認証
- 例えば、顔認証や指紋認証などのように本人の体の特徴を使っての特定
- 所持情報による認証
- 例えば、SMSを使って本人の端末にパスコードを送り入力してもらう特定方法。他にも家や車の鍵なども相当する。
認可とは？
とある条件に対して何かしらの権限を与えること。
認証と認可の違い
相手を特定した（認証した）からといって、何かしらの権限が与えられる（認可される）わけではない。
例えば、訪問者が誰かと認証しても家に入る許可を出すわけではない。
何かしらの権限を付与した（認可した）としても、相手を見ているわけではない。
例えば、電車に乗る切符を買ったとしても車掌さんはあなたが誰かをとくていしてはいない。
ただ、認可は認証に依存している事が多い。 つまり「とある特定の条件」というのが「相手が特定の誰かであることが認証されている」という条件であることが多い。
そのためこの2つが密接なもの思われている。
SQLインジェクションについて改めて調べる
個人的な復習用
SQLインジェクションとは？
Wikipediaによると
「アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法のこと。」
例えば、ID検索のフォームがあるとしたら、アプリケーションが用意しているSQLは以下のような感じになる。
SELECT * FROM user WHERE id=‘$ID’
このフォームに「taro’ or ‘A’=‘A」という語句が入力されると
SELECT * FROM user WHERE id=‘taro’ or ‘A’=‘A’
となり、すべてのユーザーの情報がヒットしてしまう。
驚異としては情報漏洩やデータ改ざんや不正ログインなどが考えられる。
対策
パラメータにSQL文を直接指定しない
そもそも論外の実装。
hiddenパラメータ等にSQL文をそのまま指定するという事例があったようだ。
これをしてしまうと、Webページのパラメーター改ざんでSQL自体を改ざんでき、不正利用につながる。
エスケープ処理
検索バーや入力フォームなどユーザーが入力できる機能を実装しているWebサイトに対して、特定の文字が普通の文字として解釈されるように処理することをエスケープ処理という。
不正コードの中の特定の文字列や記号を削除したり置き換えたりして攻撃を無効化できる。
例えば、「'」を「''」と置き換えることで、
SELECT * FROM user WHERE id=‘taro'' or ''A''=''A’
となり攻撃を無効化できる。
プレースホルダの利用
プレースホルダとはSQLを組み立てる仕組みの1つ。
SQL文の中の「変動する箇所」に使用され、後でそこに実際の値を機械的な処理で割り当てることで、機械的にSQLが組み立てられる。
また、プレースホルダに実際の値を割り当てる処理をバインドと呼ぶが、バインドの際にエスケープ処理するものを使うことで独自のエスケープ処理を使わなくてすむようになる。
例えば、perlだと以下のようなSQLの作り方がプレースホルダ。
$sth = $dbh->prepare( "SELECT id, name, tel, address, mail FROM usr WHERE uid=? AND passwd=?"); $sth->execute($uid, $passwd);
キーワードでの検索ってどうすれば早くなるのか？を調べてみる
アプリとか使っているとフリーワード検索がよく実装されている。
しかし、SQLでキーワードを使って検索するとしたらあいまい検索・LIKE検索をまっさきに思い浮かぶけど、LIKE検索は遅い。
フリーワード検索ってどうすれば早くなるのか？どういった実装をしているのか？っていうのをちょっと調べてみようと思う。
そもそもLIKE検索は遅いのか？
調べてみると、LIKE検索が常に遅いわけではないようだ。
インデックス貼っているカラムに対してでも、中間一致・後方一致の場合（%で始まる条件の時）はインデックスは使われずに、データを全部読み込んで条件に一致するかをすべて照らし合わせて結果を求めるので、データ量が多ければ多いほど遅くなってしまう。ということになるみたい。
クエリでの工夫
中間一致・後方一致の場合はインデックスは使われずに遅くなってしまうので、前方一致のクエリを使えばインデックスは使われるという事になる。
例えば、「LIEK "ABC%"」という条件であれば良いのではないか？
ただ、これだと実際にサービスを使うユーザー視点では使い勝手が悪い。
例えば、ソシャゲでキャラクターを探したいならばキャラクター名を完全に覚えている必要があるし、進化や限定などで同じキャラでも複数のプレイアブルキャラとして存在している場合に全プレイアブルキャラを探すことができない。
よって、サービスとしてユーザーに提供するとしてはユーザビリティに欠けるので仕様としてNGになるだろう。
MySQLでngram パーサーを使用する FULLTEXT インデックス
MySQLではngram 全文パーサーという、日本語全文検索の仕組みが存在しているようだ。
イメージとしては全文検索用のインデックスといった感じだろうか？
ngram 全文パーサーは、MySQL5.7以上のInnoDB および MyISAM での使用がサポートされているようなので、日本語のキーワード検索したいならば使える機能と思っても良さそ。
詳しくは以下。
私は使ったことないのですが、使ってみた系の記事を読んでみると、後方一致のLIKE検索と比較して50倍以上早くなったという記事もありました。
デメリット
- 完全一致を求めるにはクエリだけでなく工夫が必要
- データ量が多くなる
- データ挿入に時間がかかる
検索用に別のサービスと組み合わせる
例えばOracle DatabaseにはOracle Textという全文検索機能があり、フリーワード検索だけOracle Databaseにアクセスするとか。
例えばElasticsearchという検索エンジンサービスがあり、定期的に検索したいMySQLのデータをElasticsearchにインポートするなどでElasticsearchとの組み合わせもできるかなと。
まとめ
MySQLだけでもngramパーサーを利用した FULLTEXT インデックスという手法があったり、Elasticsearchなどの他サービスとの掛け合わせという手法もありそうです。
実際に使っている訳ではないので経験や実感と共に書いているわけではないですが、「こういった機能やサービスがある」という知識としては調べてよかったと思います。
池ハロ初日にカメラで参加した感想と反省
池袋ハロウィンコスプレフェス2021にカメラで参加してきました。
屋外の撮影は、普段プラモの撮影ばかりしている自分にとっては難しすぎたので感想とか反省を、忘れないように書いておきたい。
感想
単純にすごいな。というのが最初の感想です。
コミケを散策していたので、コスプレイヤーさんがたくさんいる光景は見たことはあったのですが、自分がカメラとして参加するとまた別の雰囲気を感じました。
最初はサンシャインの屋上にいたのですが、特に人が多かったと思います。
コスプレイヤーさんの前に撮影待ちの列ができて何人もならんでいましたし。
2時とかになるとイケ・サンパークに移動したのですが、イケ・サンパークの方が参入しやすい雰囲気ではありました。
広さに対して人数もそこそこで密度も適度なくらいでしたし、列も数人くらいで並ぶハードルも少なかったです。
何人も並んでいたら気後れしちゃいますからね…
総じては楽しかったです。
可愛いものからかっこいいものまでいろんな方のコスプレを見れて眼福でした。
仮面ライダーとガブリアスにはテンション上がりましたね！
持っていった装備
ストロボ
GODOXのクリップオンストロボのTT600を持っていきました。
人多いだろうしライトスタンドとかもっていくと迷惑だろうと考えて、クリップオンストロボにしました。
（これしか持ってないというのもありますが…）
ディフューザー
ディフューザーはストロボの光を拡散するものです。
ストロボの光をそのまま当てると光が強すぎるので、光を拡散させて弱くした光をモデルさんに当てます。
念の為に２つ用意しました。
一つはリング型のソフトボックス。
1万円を超えるものもあるのですが、初めて使うので安いものを買いました。
もう一つはストロボについていた四角いディフューザーを用意しました。
そのものではないですが、形的にはこんな感じのやつ。
その他
NDフィルターというものを用意しました。
簡単にいうとカメラ用のサングラスですね。
（いや、途中まで用意していたことをすっかり忘れていたんですが…）
反省点
NDフィルター
実はNDフィルターの存在をすっかり忘れていました…
なのでサンシャインの屋上ではそのままの光の強さで撮影していたんですね。
まだ日が高いうちはNDフィルターなしで、絞り優先モードにして露出調整すれば、カメラがモデルさんに合わせて調整したタイミングでシャッター押すことでなんとかなりました。
ただ、2時3時になって太陽光がカメラに入るくらいの角度になると無理でしたね…
幸いにも列に並んでいるときに他のカメラマンさんと雑談している中で思い出して装備したのですが、これはやらかしでした…
太陽光との接し方
太陽光、だいぶきついです。
日が高いうちは太陽がカメラのレンズに映ることがあまりなく、逆光で撮影してもそこそこ綺麗にとれました。
ただ、日が傾いてきて太陽がレンズに写るようになってしまうと撮影もレタッチもキツイです。
NDフィルターつけて、F値を絞って、光を遮るようにしてもなかなかうまく取れなかったです。
日陰で撮影してレタッチで明るさ調整したほうがいい感じに現像できました。
逆光の光がレンズに入ると光が強くてカメラがモデルさんを認識できずにピントがズレ、測光だとモデルさんのお顔に影が入ってしまい、順光だとのっぺりした感じに…
NDフィルターやISOやF値を調整して背景の明るさをいい感じにしつつ、ディフューザーつきのストロボでお顔に柔らかい光を当てるのがいい、と頭ではわかっていてもなかなか実践できませんでした。
次回屋外撮影をやるならば
目指す事としては、「逆光でモデルさんをキラキラさせつつ、F値開放して綺麗に背景ボケして、モデルさんの正面にも柔らかい光を当てて撮影する」です。
そのためには、
- ISOを100か200まで下げれるカメラを用意する
- XT-200の場合はファームウェア更新で200まで下げれるようになりました
- NDフィルターを最初から装備する
- 太陽光がレンズに直接入らないような構図
- あと焦らない
- 別のディフューザーを模索する
- 柔らかい光を出しつつ遠くまで飛ばせるのが理想
荷物は大きくなるけどレフ板っていう選択肢もあるとは思います。
アコスタとかコミケとかで屋外撮影のリベンジしたいですね…
オリジナルのアメインを作りたい(境界戦機プラモ)vol.1
これまでメイレスビャクチ、メイレスケンブ、バンイップ・ブーメランと、3体の境界戦機のプラモを作って来ました。
ここまで来たらオリジナルのものにしたいと思うので、ミキシングしていこうと思います。
どんな機体にしていくか？
まずはテーマを決めたいと思います。
今回は「電子戦、長距離砲撃支援の機体」というテーマで作っていこうと思います。
今の所、境界戦機のアニメにそんな機体はいないので。
ミキシング
詰まったところ
いざミキシングしようとしたのですが、いきなり困ったことがありました。
こいつら、同じ作品のプラモデルなのに全然規格が合ってない！！！
例えば、股関節の凸凹が揃ってない。
バンイップブーメランの特徴的な足をケンブやビャクチの胴体につけることが出来ませんでした。
例えば、足の規格が合ってない。
凸凹が合ってないだけでなく、穴の経もバラバラです。
しかたなくバンイップ・ブーメランの足をばらしてつけようとしても、穴の大きさが…
BigQueryでfhoffa.x.medianを使って中央値を計算する
KPIの分析をするさいに、平均値だけでなく中央値もみたいという場合がある。
実際、新しく中央値も見たいと言われてBigQueryで中央値を出す方法を調べていた。
BigQueryは集計するのが早くて楽だけど、中央値を出すmedian関数がないっぽい。
PERCENTILE_CONTを使う
調べてみると PERCENTILE_CONT を使うことで中央値を出すことができる、という記事が多く出てきた。
例えば
PERCENTILE_CONT(hoge, 0.5) OVER(partition by fuga)
で中央値を出すことができるらしい
なので、最初に PERCENTILE_CONT を使って出そうとしたのだが、いくつか問題が出てきた。
PERCENTILE_CONT の問題点
外部結合でテーブルを作ろうとするとエラー
後からの要望で、欲しい情報が1つのテーブルにまとまっている事はそんなにない。
テーブルが分かれている場合は、JOINで外部結合して欲しい情報をまとめるのだが、外部結合したテーブルで PERCENTILE_CONTをすると以下のようなエラーが起きる。
SELECT list expression references column {hoge} which is neither grouped nor aggregated
サブクエリ内で外部結合して結果から検索するとかも考えれるが手間であるし、その先でも別の問題がおきるかもしれない。
なので、別の方法を探すことにした。
fhoffa.x.median を使う
社内の方に聞いているうちに fhoffa.x.median が使えるという話を聞いたので試したみたが、これはうまくいった。
fhoffa.x.median(ARRAY_AGG(hoge IGNORE NULLS))
このようにするだけで中央値を求めることができた。
また、集計対象のカラムにNULLがある場合でも IGNORE NULLS をつけることでNULLを無視して中央値を出すことができる。
まとめ
fhoffa.x.median が楽でしたので、BigQueryでの集計で今後も中央値がほしいと言われたら、この方法を使おうと思います。
今更ながらの境界戦機HGバンイップ・ブーメラン素組レビュー
以前作った境界戦機のプラモの出来が良かったのと、バンイップ・ブーメランの構造が独特で気になっていたので買ってみました。
もう大勢の方がレビュー記事や動画を出していますが、ブログを書いていこうと思います。
ケンブの記事はこちら。
qbmk-iqu.hatenablog.com
ビャクチの記事はこちら。
qbmk-iqu.hatenablog.com
ヨドバシで壁ができていて作る前から面白かったです。
制作
足の構造
やはりバンイップ・ブーメランと言ったらあの特徴的な足でしょう。
他の境界戦機のプラモデルや他の作品のプラモデルと比べても、関節が多くてパーツも大きいですね。
また、折り畳めるように可動域も大きいです。
この構造のおかげでこれだけ伸ばせます。
よく見てみると、同じ境界戦機のプラモデルと比較して穴の位置が股関節部分についているんですね。
メイレス系は足のほうに穴がついているので、単純に足の差し替えが出来ないみたいです。
（そのあたりは統一してくれたほうがミキシング楽しそうなのに…）
上半身の構造
頭部がボールジョイント接続なのでめっちゃグリグル動きます。
腕（？）の接続はボールジョイント、機関銃の接続には3mm穴が使われているので、パーツの差し替えも無改造ででき、ミキシングやカスタムパーツの取り付けも幅が広そうです。
完成
完成写真を見ていきましょう。
まずは駐機状態。
続いて哨戒状態。
最後に高機動戦闘状態。
高機動戦闘形態でもけっこう自立します。
境界戦機といえば膝立ち…膝？
また足の伸縮によってこれくらい全高が伸びます。
感想
足の伸ばし具合で印象がぜんぜん変わってきて面白いプラモです。
気になる点としては平面が多くモールドが少なめなので、情報量が少ないかなと思います。
自分で新規モールドを増やしたりデカールを貼ったりで情報量を増やすとかっこよくなりそうです。
これ量産機なので足を伸ばした状態で多くの機体が隊列を組んで向かってくるとかなり怖そうですね。
アニメでそういった描写されないかな（笑）
