Kidzuki_Nihiruのコメント: Re:味は変わらんのか? (スコア 1) 36
いや雁屋とかいう超弩級キチガイ左翼の話はどうでもいいんだが。
> 実際に寿司などにビールのニーズが高まっているのは海外出荷額からも明らかだ
で、ソースは?
こちらは、Kidzuki_Nihiruさんのユーザページですよ。 アナウンス:スラドとOSDNは受け入れ先を募集中です。
いや雁屋とかいう超弩級キチガイ左翼の話はどうでもいいんだが。
> 実際に寿司などにビールのニーズが高まっているのは海外出荷額からも明らかだ
で、ソースは?
Google I/O 2013にてプレビュー版がリリースされたAndroid Studioだが、およそ1年半のPreviewとBetaを乗り越え、2014年12月8日、ついに安定版1.0がリリースされた。
Android Studioは従来からのADT Plugin for Eclipseに代わる、JetBrains社製のIntelliJ IDEAをベースにしたオープンソースのAndroid用IDE。
進化したリソースエディタやデザイナに加え、IntelliJ IDEA由来のコード補完やリファクタリング、コード追跡サポートや強力な静的解析機能を備え、ビルドシステムにはGradleを採用している。
詳しくはAndroid Developers Blogの日本語訳記事を参照いただきたい。
なお、対応状況が長らくComming SoonとされてきたNDK Supportについては、Ver 0.8.0よりビルドがサポートされているとのこと。
> オリジナル設計株式会社は「プライバシーマーク」の使用許諾を受けています。
Pマークとか、あんなん査察機関のおっさんが接待の甘い汁を啜るためだけに存在するような規格だしなぁ…
CGIとしてPHPを実行している環境にて、PHPのオプションを外部から指定できる脆弱性が見つかり、PHP5.3.12とPHP5.4.2がリリースされている。
具体的にどのような影響があるかというと、ソースコードを表示したり、リモートのスクリプトを実行できてしまうようだ。
さらに、リリースされたPHP5.4.2でも対策が不十分であるとのこと。(徳丸氏による[PHP]CVE-2012-1823に関する暫定メモより)
PHPをmod_phpやFastCGIではなく、CGIとして実行しているケースは比較的少ないと考えられるが、レンタルサーバの都合などでCGI動作となっているケースもある。
仕事やプライベートでPHPを利用されている方は急いで確認をしよう。
朝日新聞の記事によると、会社更生手続き中の半導体大手エルピーダメモリは、同社を事実上買収し再建支援するスポンサー企業に米マイクロンを内定したそうだ。最終入札で、マイクロンは買収費用と、国内2工場と開発部門等の一体再建案を提示し、競争相手の投資ファンド連合の条件に勝ったそうだ。
国内半導体メーカーの中心的存在だったエルピーダメモリだが、これで米企業の傘下に入る。
読売新聞によると、消費者庁はソーシャルゲームで流行中の「コンプガチャ」が景品表示法に違反するとして中止を要請するとのこと。
中止要請に応じない場合、景表法の措置命令(旧公正取引委員会の排除命令と同じもの)を出す方針だそうだ。
ソーシャルゲームにおける「ガチャ」とは、ゲームセンターにおけるカプセル自動販売機からの連想で、ゲーム内通貨を投入するとランダムでアイテムなどの景品が手に入るミニゲームを指す。
今回焦点となっている「コンプガチャ」とは、「ガチャ」で手に入る特定の景品の組み合わせでさらに強力な景品が手に入るというものである。
Web版では詳しく記述されていないが、5日付けの朝刊の紙面によると、この「コンプガチャ」は景表法において禁止されている「カード合わせ」に該当すると判断されたようだ。
容易に想像できるとおり、「カード合わせ」は主催者がカードの配分を調整することで当選者を不当に出しにくくできる。
「コンプガチャ」のようなプログラムならなおさらである。
なお、今回の件では「ガチャ」そのものが禁止されるわけではない。
「ガチャ」そのものに関しても、子どもが大金を使ってしまったなどの苦情が後を絶たず、批判にさらされている。
しかし、ソーシャルゲーム提供側の会社としては、収益の柱である「ガチャ」を簡単に手放すわけにはいかないだろう。
「コンプガチャ」が禁止されたとしても、第二第三の新形式「ガチャ」が生まれ、いたちごっこが続きそうだ。
> # 一体どこのバカが1980x1200であんなもん使いたがると思ったんだ?
そんな人いないですよね。
そんな解像度のディスプレイ存在しないですし。
いやいやいやw
別にそんなめんどくさい話じゃなくて、単純に
「入力されたカード情報は決済代行会社に投げるだけで、ショッピングサイト側には保存しない」
とすれば解決する話です。というか今時そうせず、自前でカード情報を保存しているのが既に狂気の沙汰なんです。
そりゃショッピングサイトへのカード情報の入力を全てロギングするようなプログラムを仕込まれたらおしまいですが、
決済代行会社側のカード情報入力画面を使うような作りにすれば、それも回避できます。
# だいたいどこの決済代行会社もそういう仕組みを用意しています。
基本的に、決済代行会社はショッピングサイトへカード情報を全部は公開しませんので(下4桁だけ、など)、
仮にショッピングサイトが完全に乗っ取られたとしても、フルのカード情報が全部漏洩するなんてことにはなりません。
# 決済代行会社によっては有料のオプション契約でカード番号をショッピングサイトの運用者が確認できるようにする、なんてのもありますが。
よく言われる「2度目以降のカード決済ではカード情報の入力をスキップさせたい」なんてのも、
だいたいどこの決済代行会社も「このトークンで○○円の注文を入れる」みたいなAPIを備えていますので、
ショッピングサイト側にカード情報を保存する必要なんて無いんです。
5年前ぐらいには既に多くの決済代行会社のシステムにそのような仕組みが出来ていたと記憶してますので、
2012年にもなって自前でカード番号を保存しているなんてのは、ショッピングサイトのシステム担当者の怠慢以外の何者でもありません。
> EZ 番号と併せて EZ サーバの IP アドレス等、
って言い方をするってことは、auのスマートフォンはEZサーバを経由しないってことでしょ?
現にグローバルIPアドレスが振られているわけだしさ。
正しくは「EZ 番号は(対タンパ性を十分とするなら)auのガラケー以外では詐称可能なため」じゃないの。
# そもそもHTTPでもHTTPSでも同じ値が送信されるX_UP_SUBNO HTTPヘッダでユーザー認証とか狂気の沙汰。
> カード裏面のセキュリティコードと、ネット取引の認証手段である 3D セキュアが活用されるようだ。
セキュリティコードはさておき、3DセキュアはVISA以外ガラケー対応してなかった気が。
Visa Worldwide Tokyo | Visa、本人認証サービスの携帯電話対応を発表
http://www.visa-asia.com/ap/jp/mediacenter/pressrelease/NR_JP_260810_mVbV.shtml
ガラケー通販はクレジットカード利用率がいくらか下がるとはいえ…
しかし結局のところ、利用者が本人認証サービスに申し込んでないとあまり意味無いのがなぁ。
一般消費者への本人認証サービスの啓蒙の方も重要だと思うんだけど大丈夫なんだろうか。
# 本人認証サービスに申し込んでいるかどうかの判定は出来るので、
# 本人認証サービス未登録カード利用の拒否は可能だけど、顧客の手間が増えるので皆やりたがらない。そりゃそうだよね。
Stay hungry, Stay foolish. -- Steven Paul Jobs