【映画2017】スパイダーマン ホームカミング / 憎きアベンジャーズ
『スパイダーマン ホームカミング』観た。
なんか違う。。
個人的には、かなり微妙。
何がダメなのかと考えてみると、まずエンタメ感が強すぎるという点。
トビーマグワイアとアンドリューガーフィールドはもうちょいシリアスな感じが強かったと思うのだけど、今回はエンタメコメディーな作品になっている。
あと、前の作品はわりと1作目の構成を踏襲しながらのマイナーチェンジで、サムライミとトビーマグワイアのスパイダーマンを、うまいことマークウェブとガーフィールドの作品にリメイクされていたけども、3作目の今回は本格的に作品をぶち壊しにきてる。
1・2とアベンジャーズあり気の割り切った作品なので、説明もかなり省いてあるし、なんでもアリの感じが従来のスパイダーマンファンをおいてけぼり。
そのスパイダーマン知ってるでしょ。今回はこんな感じに作って見ました。というのを良い方向に裏切ってほしいのだけど、なんか空回り。
まあ、このシリーズは興行的にはどうであれ、絶対2作目は作られるはずなので次作に期待したい。
アメイジングスパイダーマン2がマジで良い出来だったので、あれぐらいの作品を作ってほしい。
以上
trucking cookieって
最近PCを自作したので、セキュリティも気にするか、ということでノートンを買った。
1年1台で2800円。
月換算で230円ぐらいか。まあまだな。
さて、早速クイックスキャンを実施してみると、何やら「Cookieによる追跡を検出しました」というのが32件も出てきた。
なんぞこれ。
(ペーパーの)セキュリティスペシャリストなんだけど知らん。調べてみた。
「Cookieによる追跡」=「Tracking Cookie」らしい。
cookieとtracking cookieの違いについて調べてみると、
cookie情報を二つ以上のサイトで共有してwebマーケティングで利用されるのが、tracking cookie、とのこと。
cookie自体は、amazonとかのwebサイトでは必須なので、web技術としては当然害のあるものではないのだけど、アクセス情報を記憶しとるので、セキュリティソフトが検出しているみたいだ。
なので、検出されても問題ないし、というかwebサイトを巡ってたら絶対検出されるははず。
ついでに、cookieについて調べてみた。
cookieはrfc6265で定義されているので、原文を読めば完全な情報を得ることができるのだけど、そんなに英文を読めないので、日本語訳してくれているサイトをみてみる。
cookieの利用にはhttpヘッダにset-cookieヘッダを追加することで可能になる。
こいつは属性を複数持っており、
name,expire,path,secure,domainなどがある。
セキュリティ的な話でいうと、重要なのはsecure属性で、これをつけておくことでssl通信を必須化できる。
逆に言うとsecure属性がないとhttp通信でもcookieがsetされてしまうので、セキュリティ的にどうなのよ、ということになる。
以上。
【映画2017】LIFE / カルバン
映画『LIFE』観た。
出演者には、ジェイク・ギレンホール、レベッカ・ファーガソン、ライアン・レイノルズとなかなかのメンツを揃えつつも、そこに真田広之も長時間の出演。
個人的には、無理矢理アジア人をぶち込んでぐる近年のバラエティーに富んだ感じは好きではないのだけど、宇宙ステーションの話だけあってそこはまあ納得できるところ。
さて、内容のほうだが、
なんというB級感。クソすばらしい。
期待した通りの古典的なSFホラーで、過去10本はあったであろうようなベタすぎる展開で目新しいところは何もなく、むしろ焼き直しじゃないのかというぐらいの内容には、頭をからっぽにしてボケーと観れる。
とにかく、こういう映画を映画館で観るのがサイコー。
ラストの展開も思わずニヤリですよ。
それにしても、なんで映画の日本人はあんなにカタコトなんだろうか。
ああいう演技指導があるのだろうか、不思議であーる。
以上.
【映画2017_1本目】LION/ライオン ~25年目のただいま~ / never give up
『LION』という映画を観た。
評判がいいという噂だけで、内容についてはあまり知らずに観に行ったのだけど、めちゃくちゃよかった。
冒頭はキャストの名前と上空撮影した色々な国の景色から始まる。
これは、後々出てくるググーグルアースを意図した演出なのだろうけど、映画の雰囲気を醸し出していてとても期待しながら見入ることができた。
あと、全く知らずに観に行ったのに、大好きな女優の一人の「Rooney Mara」という名前を見つけてしまって、さらに自分の中で期待が膨らんだ。
内容も、少年が一人きりになって生き抜く様子はワクワクしたし、幼い主人公がひとりぼっちになってしまった瞬間の孤独感がヒシヒシと伝わってきた。
それに、きれいごとだけじゃなく世界に蔓延る悪い部分にもちゃんと焦点があたっていたり、しっかりとした伏線もありつつ映画としてよく出来上がっていたと思う。
そして、とにかくルーニマーラが可愛すぎる。
マジ天使かい。
冒頭から最後まで退屈することなく楽しませてもらった。
すごくおすすめ。
データベース(オラクル)に接続できない時の確認項目
「データベース(オラクル)に接続できない時の確認項目」について書く。
業務でクライアントにシステムを導入するときにたまにハマるので。
まず、システム導入時の流れとしては、
1. クライアントにオラクル入れる
2. 設定ファイルを入れる (基本的にこの辺はバッチとかで自動化されている)
3. 接続確認する
4. 詰まる ( \(^o^)/
こういう導入や設定系というのは、作業者は特に何も考えずに手順書通りに右から左と言う感じに作業できるようになっているものなのだが、それ故に一度エラーとかが出ると全然解決できなくなる。
上記の流れでも設定ファイル系が分かってないとなにも解決できない。
まず、接続確認はcmdでsqlplus aaaa/bbbb@cccc as sysdba と言う感じで実施。
よくあるエラーだと、「ORA-12154 TNS 指定された接続識別子を解決できませんでした」
とりあえず、クライアントのtnsnames.oraファイルが正しいか確認する。
「tnsnames.ora」は接続するときの@ccccの部分の記述があるところで、ここが間違っているとサーバ側のoracleに接続できない。
(サーバ側のリスナーの設定に依存する
(tnsnames.oraは%oracle_home%¥network¥admin¥にある
次に、確認する内容としては名前解決ができているか。
tnsnames.oraの内容によるが、ホスト名が記述されている場合は名前解決ができていないと、当然サーバ側のoracleまで到達できないので、hostsファイルもしくはdnsを確認する。
(hostsファイルは、c/windows/system32/drivers/etcにある
名前解決ができているか簡単に確認する方法としては、ホスト名宛にpingを飛ばす事。
ipで帰ってきたら名前解決できている。
あと以前ハマったのは、「ORA-12638: 資格証明の取出しに失敗しました 」のエラー。
クライアント側とサーバ側のドメインが違ったので、認証で失敗していたらしい。
認証系の設定ファイルとして、クライアントに「sqlnet.ora」があるのだが、osでも認証しているのでドメイン違いにより認証が失敗していたらしい。
なので、内容の「SQLNET.AUTHENTICATION_SERVICES=(NTS)」を「=(NONE)」にするか、コメントアウトする。
これでOS側の認証機能は使わないけれども、oracle側が結局IDとPASSの認証はやっているので問題ない。
こんなところ。