はてなキーワード: Openとは
【国辱的なフェイクニュース】をまた放映したイギリスBBC - Togetterまとめ
これについて、(自分を含め)大半の人が放送自体を見ず(見れず)にあれこれ語っているようなので“番組を実際に観た”という人の感想をいくつかまとめてみます(リンクをたくさん貼るとスパム認定されるのか投稿しても公開されないのでtweetへのリンクは一部のみ)
youtubeで上がってたのを消される前に見たけどそこまで偏向した内容では無かったよ 一方的に決め付けるって言うよりはStacey Dooleyが困惑しながら話を聞いていくって感じで一応は事実を報道してたと思う 日本社会の最も下賎な部分だから見た西洋人は反感を抱くだろうけど最近は海外でもオタク文化に詳しい人は多いから 漫画規制にまで発展するほど炎上するような事は無いと思われる
【@masillo氏】https://twitter.com/masillo/status/837637116125306880
今日わりとおこっていて、全員が当該の映像を見ないまま伝聞でわるぐちをどんどん言うというのがどうして起きてしまうんだというかんじです https://t.co/1FFca3cKmv— タマキ (@masillo) 2017年3月3日
@masillo “In 2014, they decided that they should make it illegal to POSSESS child pornography.“ 2014年、日本人は児童ポルノの所持を違法とするときめた— タマキ (@masillo) 2017年3月3日
@masillo “it was illegal to distribute it and produce it, sell it, but to have it on your laptop and watch it was no problem.”— タマキ (@masillo) 2017年3月3日
@masillo それまでも配布、生産、販売は違法だったけど、自分のノートパソコンにあるだけ、見るだけなら問題なかった— タマキ (@masillo) 2017年3月3日
@masillo 最初の最初でそういうふうに言ってて、それならまとめの最初の人が言ってることとちがわないのに、なんでこんなことになってしまうの。あとインタビュアーの人のヘッダー画像は動画の内容とは関係なくて最後までべつに出てきません。— タマキ (@masillo) 2017年3月3日
【@mishiki氏】https://twitter.com/mishiki/status/838064860701171712
ステイシー・ドーリーの“Young Sex for Sale in Japan”について、幾つかまとめを。①取材されていたJKカフェに良い印象は持ちにくい。あと着エロについても擁護し難い。実在の児童の人権を侵害しているんじゃないのと言われれば、両方そうなりえると思う。— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年3月4日
②疑似ロリAVは、女優の演技や画像加工の話だし、マンガ・アニメについては「紙とインク」なのだが、「子供のように見えるものは何で合ってもダメ」というところで、一貫性を絶対に崩さない人達がいることが改めてよく分かった。ここで蒙を啓く、eye openする方法はよく分からない。— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年3月4日
③ペドフィリアに対しては、存在も欲望も妄想もとにかく全て否定されて、社会生活上、子供に無害なように生きていってもらうというよう選択肢は、存在してないらしい。「自分に生きる権利があるじゃなくて虐待されてたとか言ってくれればいいのに」などというのは実にひどい発想だと思った。— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年3月4日
全体として、このドキュメンタリーが「フェイクニュース」かと言われると、「悪意故または誤解故の印象操作はあるが、嘘は吐いてない」と思う。はっきり誤りと思われるのは、「30代以下のほぼ半分が非正規雇用だからJKカフェが収入源として必要悪になっているのでは」という部分くらい。— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年3月4日
2014年まで児童ポルノは禁止されていなかったみたいな危ない物言いも、嘘ではないように文言が選ばれている。なのになぜ妙な印象を受けるのかだが、これはスクリプトを書いた人の理解と、表で喋るステイシーの考えが一致していないからなのではないか、という疑念を持っている。— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年3月4日
http://anond.hatelabo.jp/20170305024848
私が見た限りでは“番組を実際に観た”という人はだいたい同じトーンです。@mishik氏は上にまとめた以外にも番組内容についてかなり詳細に言及していて、誤解や偏見が見られる点については厳しいツッコミを入れていますが、それでも「捏造」「フェイクニュース」という見方を否定しています。
私もまだ放送を観れてないので上の方たちの感想が正しいと断言することはできないのですが、“番組を実際に観た人”の感想を見る限りtogettreのタイトルは誇張されたものであり、現時点では『【国辱的なフェイクニュース】をまた放映したイギリスBBC』というまとめ自体がフェイクニュースという可能性が高いと考えるのが妥当なのではないかと思います。
本件に限らず日本のオタクカルチャーに対する諸外国(特に欧米)の偏見は酷いと思いますし、それが不十分な取材や偏見に基づく報道によって助長されていることも否定できないでしょう。それ自体は批判されるべきことであっても、だからといってデマ紛いの手法によって反感や悪意を煽るのは本末転倒ではないでしょうか。
免責: これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」
http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace
この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSSの翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます。
ですが、プログラマの間で単にWeb翻訳をOSSに使ってはいけないんだという認識が広まってるように見えます。個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています。
どういう話かというと、自分が個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースのライセンスで公開しています)
念のため言っておきますが、これは元記事で問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります。
コミュニティの思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。
もとの記事のとおり、Excite翻訳の利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。
ここでは、Google翻訳に焦点を当てた話をします。Google翻訳の利用規約はどうか?というと、Googleの利用規約については翻訳結果の利用についての記載がありません。
https://www.google.com/intl/ja/policies/terms/
記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?
機械翻訳の権利問題と似た構造の話に、GPL(GNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります。
GPLの本文には、GPLのプログラムの出力結果自体にGPLのものを含む場合にのみその出力結果にGPLが適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているかの記載はありません。
これについては、コンパイラによるコンパイル結果に対して、コンパイラの著作者はなんら権利を持たないと考えるのが一般的です。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput
著作権法は人々があなたのプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。
コンパイラと機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります。
ウィキメディア財団の法務チームは、Google翻訳した文書のウィキペディア内での利用についての見解を公開しています。
https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations
これはアメリカの法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスのコンテンツをGoogle翻訳で翻訳してウィキペディアで使用してもGoogleの著作権を侵害する可能性はとても低い(very unlikely)と結論づけています。
要点をまとめると以下の通りです。
ウィキメディア財団の見解には含まれていませんがアメリカの法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。
これはAndroidのAPIにJavaのAPIが流用されていることについて、OracleがGoogleを訴訟したものです。
これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコの地裁では著作権使用料支払いの対象にはならないという判決が下っています。
「フェアユース」というのは、アメリカの著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権の侵害とはしないと考えるものです。
ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidのJava APIの流用と比べても、さらにフェアな利用であるように見えます。
(ちなみにGoogleの利用規約には、「カリフォルニア州の抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州の法律が適用されます。」と書かれています)
著作権情報センターのサイトに、 コンピュータ創作物についての文化庁の報告書が記載されています。
http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html
この報告書は、機械翻訳のユーザーが機械翻訳システムを使用するために行う原文の編集や出力の編集が創作的寄与となりうることを認めている一方で、機械翻訳の開発者が翻訳物の著作者になるということについては否定的です。
なお、原文解析等のプログラムの作成者及び汎用的な辞書データベースの作成者は、一般的に翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定の翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。
これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳の技術は大幅に進歩しましたが、創造的個性の表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます。
これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者の著作物。機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間の二次著作物になるということになりそうです。
これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているかを説明してきました。
では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。
だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。
著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。
有名なところでいうと、Monoが思いつきます。AndroidのDalvikがJavaのAPIを真似したものであるのと同じように、MonoはMicrosoftの.NETフレームワークを真似しています。つまり、Monoについても訴訟リスクはあっただろうということです。
しかし、OracleとGoogleが対立したのとは対照的な道をMonoはたどります。
2016年、Monoのプロジェクトを運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoがMicrosoft公認のプロジェクトになったというわけです。
権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。
すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntuの日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています。
まずは質の問題です。現在のGoogle翻訳などは、UIの翻訳に向いていません。UIのほとんどは、意味合いが文脈に依存する単語や短文です。UIの翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。
Google翻訳などを使って一括で、訳語を割り当てても良いUIの翻訳はできません。
( UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 )
次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntuの日本語化ローカライズであれば、すでに多くのユーザーが使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります。
そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。
つまり、クオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。
とはいえ、OSSには個々の事情があります。次は自分の場合の話をしてみます。
まずは質の話です。
自分のプロジェクトの場合、Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティの翻訳が出力されており、自分でゼロから翻訳するよりも、原文を翻訳しやすく修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳を使用しました。
次にリスクの話です。
OSSが企業に権利問題で訴訟されるということはめったにありません。OSSは公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。
訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSSで大金が儲かったらGoogleから訴えられてしまう!どうしよう!と考えるのは、宝くじに当たったら強盗におそわれてしまう!どうしよう!と考えるのに似ています。
まず宝くじは当たらないですし、宝くじが当たったらそのお金で対策を行えば良いだけの話です。
実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立しています。Linuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。
これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。
権利問題で訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業にうんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます。
結局のところ、自分の場合はGoogle翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Googleも翻訳を改善するためのデータを得られます。
わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。
結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェアの翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。
質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります。
各OSSの翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
ここ最近、facebookの投稿をしづらくて、twitterに原点回帰しているという話をよく聞く。
自分もそのうちの一人だ。
見ている分には友達の近況などしれていいけれど、でも自分で投稿したいという気持ちは
1年前と比べるとかなり減っている気がする。
大体のポストはこんな記事。そういうクラスターに入っているだけかもしれないけれど。
「海外出張いってきます、かえってきます(空港のタグを添えて)」これが一番
「カンファレンスに登壇予定です」
「ニュースに出ました」
「昔でいうRSSリーダ的に読んで意識高そうな記事をシェアしました」
といった、ポジショントークまざりの話が 多すぎる気がする。
もうちょっと前のユルフワな、足折れたとか、ここのお店が美味しかったとか、家族写真がきれいーとか
どうでもいい和やかな雰囲気がすきだった。
今はそんなことをつぶやこうと思っても、周りの意識が高いつぶやきに比べると、
「いやまてよ、こんなこと書くよりも、なんかすごいことをしている、常にアンテナはってますよというオーラを出さないといけないのか?」
と我一瞬冷静に事態を振り返り、投稿をやめる というのが最近である。
また、個人的に可愛いと思っていた女の子の写真をググって、そのリンク先がfacebook上にあり、
そこを眺める といったソーシャルネットワークという映画のザッカーバーグ氏の昔のような風景も、
いまでは、可愛いもしくは意識高い女子というのは、Instagramに上げるのみで、プライベートな写真の更新はかなり減っている気がする。
※facebook社としては、買収したサービスであるinstagramにトラフィックが寄り付く分にはID統合されているのであれば、広告面としては問題なっそう。
「同窓生枠だけに投稿する」といった、セグメント別の投稿ができないので、
地元の同級生と意識高いクラスターが納得するであろう最適な投稿が確立できなくて、
結局Read onlyになっているような人が多いような気がしている。
「ごめんね、facebookは本当にprivateな人のみでやっているだ、Linkiedinでつながりましょう」
とよく言われて、それがアメリカでの使い分けらしい。
日本だと、その使い分けができず、ビジネスとプライベートが完全に一体化しちゃったおかげで、
まとまりがなくなってきているから、最近多い使い分けとしては以下となっている模様。
facebookでは意識の高い情報を見て、シェアする場所。他の人に興味もないので退会。
twitterはどうでもいいつぶやきとよさそうなリンクをとりあえずshareするOpen bookmark
Instagramはその瞬間きれいな写真をとって残すのと、オシャレ感をポジション投稿する場所としての Open photo storage
といった使い分けをしている人が多いのではないかなーと思っている。
まったく同じようなことを半年前くらいに書いている記事をみつけた。
http://www.yomiuri.co.jp/fukayomi/ichiran/20160622-OYT8T50037.html?page_no=1
IR上だと、asia pacificでくくられてしまっているので、
https://s21.q4cdn.com/399680738/files/doc_presentations/FB-Q316-Earnings-Slides.pdf
それにしても今日は腰が痛い。
何番煎じだよって感じだけど、既存のブックマークレットがクエリパラメータとかも含めてURLを取得したり、
選択範囲を本文に反映したりとか、俺にとってはいらない機能が色々あったので、
俺用に最適化したブックマークレットを作った。あと、はてな記法使ったことなかったのでそのテストも兼ねて。
javascript:usrID='KokoniIDwoIreru';function enc(s){ return encodeURIComponent?encodeURIComponent(s):encodeURI(s); }void(window.open('http://anond.hatelabo.jp/'+usrID+'/edit?title='+enc(location.href.replace(/\#.*$/, '').replace(/\?.*$/, '')),'_blank',''));
俺が作ったものではないが、便利なブックマークレットを見つけたので一緒に載せる。
▼を押すことで内容が展開されるが、それを全て展開してくれる。
javascript:(function(){d=document;t=d.getElementsByTagName('ul')[1];a=t.getElementsByTagName('a');for(i=0;i<a.length;i++){if('#'==a[i].getAttributeNode('href').value)a[i].onclick();}})();
去年の電通の過労自殺の問題から、労働環境の改善が各方面で話題になっているが、
バローの様な中規模系や地元系チェーン店は、ほぼcloseだった。
やはり安売り店は休めないのかと妄想。只し,業務スーパーはcloseだった。
イオンやイトーヨーカドーの大型ショッピングセンターはopen。
ヤマダ、K's電気 close
と、会社によってまちまちだが、ヤマダは混乱期から脱却しつつあるのと、
顧客満足度が高いと言われているK's電気は、余裕があるのかもと妄想する。
・外食チェーン
全国規模のファミレスや回転ずし、牛丼店やファストフード店はほぼopen
そんな中、closeだった道とん堀とやよい軒は、飲食界の新しい労働環境を
構築しつつあるのかもと妄想。
元旦の需要は高そうだが、昔から元旦営業しているイメージはないので、
・アパレル
アパレル系は、ファッション好きな従業員の労働力の搾取の場なのかもと妄想。
・アミューズメント系
ゲームセンターやボーリング場、ネットカフェやパチンコ等はすべてopen
ディーラーや中古車販売店、買取店はclose。やはり正月から大きな買い物はしないのだろう。
自動車用品店は中古部品店はclose 全国チェーンのイエローハットもclose。
ただスーパーオートバックスはopen。車好きの従業員の労働力の搾取の場になっていなければいいが…と妄想。
・その他
ブックオフヤハードオフなどのブックオフ系列はどこもopenだった。
大型本屋やツタヤのどのレンタルDVDショップに需要があるので、
パソコン部品や家具、洋服の中古品店もオープンさせてしまうのは、
グループ店ならではの文化が、優先されてしまっているのではないかと妄想。
メガネ店では朝礼で、通りに向かて全員で大声で挨拶していたり、
もう一つ意外だったのはセリアやダイソーなどの100円ショップがclose
それでもサービスを提供しなければならないなら、その日は特別賞与を従業員に大いに振る舞おうよ。
そしてお客も割り増し料金を払おうよ。
正月くらい、客がそのサービスへの感謝を形にしてもいいんでないの?
元旦からクロネコの宅急便が届いて、驚いちまったのと同時になんだか申し訳なくて
思わず「すいませんでした」って謝っちまったよ…。
この記事は増田Vimアドベントカレンダー2016の27日の記事です。
Vimに興味を持ってるけどtwitterで誰をフォローすべきか分からない・・・
vim-jpで積極的に活動している(していた) 人達を調査してみました。
vim-jp/issuesでは、issue作成数、コメントを投稿したissueの数を見ていきます。
vimdoc-ja-workingとvital.vimでは、コミットすることが重要なリポジトリだと思いますので、コミット数とPR数のみ見ていきましょう。
データは2016/12/27 17:00-19:00の期間にgithubからスクリプトで取得
name | Open中のissue | Closedしたissue |
---|---|---|
DeaR | 1 | 5 |
Flast | 0 | 0 |
Kuniwak | 0 | 0 |
SKAhack | 0 | 1 |
Shougo | 14 | 57 |
alpaca-tc | 0 | 1 |
basyura | 0 | 0 |
bouzuya | 0 | 0 |
cocopon | 0 | 0 |
crazymaster | 4 | 3 |
deris | 1 | 0 |
deton | 0 | 3 |
eagletmt | 0 | 3 |
h-east | 8 | 42 |
hattya | 2 | 1 |
haya14busa | 3 | 11 |
ichizok | 2 | 17 |
iyuuya | 0 | 0 |
k-takata | 8 | 45 |
koron | 71 | 110 |
lambdalisue | 0 | 1 |
mattn | 39 | 129 |
nocd5 | 2 | 5 |
presuku | 0 | 1 |
raa0121 | 2 | 4 |
rhysd | 0 | 3 |
ryunix | 0 | 0 |
saitoha | 1 | 1 |
splhack | 1 | 5 |
supermomonga | 0 | 0 |
syui | 0 | 0 |
thinca | 28 | 68 |
tobynet | 0 | 1 |
todashuta | 0 | 2 |
tyru | 11 | 23 |
ujihisa | 1 | 1 |
withgod | 0 | 0 |
ynkdir | 6 | 16 |
zchee | 0 | 0 |
zoncoen | 0 | 0 |
name | Open中のissue | Closedしたissue |
---|---|---|
DeaR | 3 | 16 |
Flast | 0 | 1 |
Kuniwak | 0 | 0 |
SKAhack | 0 | 1 |
Shougo | 47 | 168 |
alpaca-tc | 0 | 3 |
basyura | 0 | 0 |
bouzuya | 0 | 0 |
cocopon | 0 | 0 |
crazymaster | 13 | 55 |
deris | 4 | 2 |
deton | 2 | 4 |
eagletmt | 0 | 4 |
h-east | 69 | 372 |
hattya | 2 | 2 |
haya14busa | 4 | 22 |
ichizok | 16 | 52 |
iyuuya | 0 | 1 |
k-takata | 78 | 340 |
koron | 136 | 374 |
lambdalisue | 0 | 2 |
mattn | 138 | 489 |
nocd5 | 3 | 8 |
presuku | 3 | 8 |
raa0121 | 4 | 16 |
rhysd | 1 | 12 |
ryunix | 1 | 0 |
saitoha | 7 | 15 |
splhack | 2 | 6 |
supermomonga | 0 | 1 |
syui | 0 | 0 |
thinca | 58 | 189 |
tobynet | 1 | 1 |
todashuta | 1 | 15 |
tyru | 41 | 88 |
ujihisa | 6 | 15 |
withgod | 1 | 0 |
ynkdir | 48 | 204 |
zchee | 1 | 0 |
zoncoen | 0 | 0 |
name | コミット数 |
---|---|
k-takata | 302 |
ynkdir | 294 |
crazymaster | 256 |
koron | 239 |
nakinor | 95 |
mattn | 87 |
thinca | 64 |
kashewnuts | 47 |
h-east | 35 |
tyru | 29 |
rhysd | 24 |
cougar-b | 21 |
rbtnn | 15 |
deton | 14 |
sgur | 6 |
aiya000 | 5 |
haya14busa | 5 |
saitoha | 3 |
Milly | 3 |
machakann | 2 |
norisio | 2 |
todashuta | 2 |
Shougo | 2 |
oshow | 1 |
lamsh | 1 |
ichizok | 1 |
miyakogi | 1 |
natnu | 1 |
pocke | 1 |
shiracha | 1 |
name | Open中のPR | ClosedしたPR |
---|---|---|
DeaR | 0 | 0 |
Flast | 0 | 0 |
Kuniwak | 0 | 0 |
SKAhack | 0 | 0 |
Shougo | 0 | 0 |
alpaca-tc | 0 | 0 |
basyura | 0 | 0 |
bouzuya | 0 | 0 |
cocopon | 0 | 0 |
crazymaster | 0 | 5 |
deris | 0 | 0 |
deton | 0 | 0 |
eagletmt | 0 | 0 |
h-east | 0 | 1 |
hattya | 0 | 0 |
haya14busa | 0 | 0 |
ichizok | 0 | 0 |
iyuuya | 0 | 0 |
k-takata | 0 | 4 |
koron | 0 | 6 |
lambdalisue | 0 | 0 |
mattn | 0 | 14 |
nocd5 | 0 | 0 |
presuku | 0 | 0 |
raa0121 | 0 | 0 |
rhysd | 0 | 1 |
ryunix | 0 | 0 |
saitoha | 0 | 0 |
splhack | 0 | 0 |
supermomonga | 0 | 0 |
syui | 0 | 0 |
thinca | 0 | 0 |
tobynet | 0 | 0 |
todashuta | 0 | 0 |
tyru | 0 | 3 |
ujihisa | 0 | 0 |
withgod | 0 | 0 |
ynkdir | 0 | 0 |
zchee | 0 | 0 |
zoncoen | 0 | 0 |
name | コミット数 |
---|---|
thinca | 721 |
ujihisa | 480 |
tyru | 414 |
lambdalisue | 270 |
haya14busa | 145 |
rhysd | 118 |
mattn | 104 |
Shougo | 83 |
syngan | 60 |
rbtnn | 45 |
crazymaster | 43 |
kamichidu | 32 |
aomoriringo | 31 |
deris | 22 |
cohama | 10 |
hattya | 8 |
itchyny | 8 |
ichizok | 7 |
Milly | 5 |
raa0121 | 5 |
ryunix | 5 |
zoncoen | 5 |
aiya000 | 4 |
kozo2 | 2 |
anekos | 2 |
basyura | 2 |
kannokanno | 2 |
suy | 1 |
deton | 1 |
koron | 1 |
m4i | 1 |
nicoder | 1 |
pocket7878 | 1 |
gitter-badger | 1 |
termoshtt | 1 |
alpaca-tc | 1 |
firisu | 1 |
tacahiroy | 1 |
y0za | 1 |
name | Open中のPR | ClosedしたPR |
---|---|---|
DeaR | 0 | 0 |
Flast | 0 | 0 |
Kuniwak | 0 | 0 |
SKAhack | 0 | 0 |
Shougo | 0 | 5 |
alpaca-tc | 0 | 1 |
basyura | 0 | 1 |
bouzuya | 0 | 0 |
cocopon | 0 | 0 |
crazymaster | 0 | 23 |
deris | 0 | 9 |
deton | 0 | 1 |
eagletmt | 0 | 0 |
h-east | 0 | 0 |
hattya | 0 | 4 |
haya14busa | 0 | 23 |
ichizok | 0 | 6 |
iyuuya | 0 | 0 |
k-takata | 0 | 0 |
koron | 0 | 0 |
lambdalisue | 2 | 35 |
mattn | 1 | 7 |
nocd5 | 0 | 0 |
presuku | 0 | 0 |
raa0121 | 0 | 6 |
rhysd | 0 | 13 |
ryunix | 0 | 3 |
saitoha | 0 | 0 |
splhack | 0 | 0 |
supermomonga | 0 | 0 |
syui | 0 | 0 |
thinca | 1 | 54 |
tobynet | 0 | 0 |
todashuta | 0 | 0 |
tyru | 0 | 28 |
ujihisa | 0 | 11 |
withgod | 0 | 0 |
ynkdir | 0 | 0 |
zchee | 0 | 0 |
zoncoen | 0 | 2 |
数字で見ると一目瞭然ですね。
綺麗に0が揃っている方々は実力を発揮していないだけなのかもしれません。
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
ネットにはつながるのに
となるとき
http://geekostyle.blogspot.jp/2016/02/4-ways-to-fix-network-icon-shows-not.html
Open registry editor
Right Click on Network List by navigating HKey_Local_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList
The tick the box "replace all child object permissions with inheritable permissions from this object"
[[Markonah]] => (Zootopia) full.MOVIE.P.utlocker.1080p - Cancer ...
www.cancerconnections.com.au › ... › Forums › Discussion
11 mins ago - Watch Zootopia Online Free (2016) Stream HD Putlocker , Now!! Watch ... WATCH HERE http://bit.ly/1TPv0w9. WATCH HERE ... Group content.
imgfave.com/new
http://www.cancerconnections.com.au/content/markonah-zootopia-fullmovieputlocker1080p · Watch X-Men: Apocalypse Online Free M... about 6 mins ago.
imgfave.com/view/7122945
http://www.cancerconnections.com.au/content/markonah-zootopia-fullmovieputlocker1080p. fave; add to collection; reblog on tumblr; post to facebook; post to ...
Last 6 reports on domain: www.cancerconnections.com.au - urlquery.net
urlquery.net/report.php?id=1465139193165
9 mins ago - URL, www.cancerconnections.com.au/content/markonah-zootopia-fullmovieputlocker1080p. IP, 106.187.97.233. ASN, AS2516 KDDI ...
[[Markonah]] => (Zootopia) full.MOVIE.P.utlocker.1080p ... - Verify
www.verify-www.com/...cancerconnections.com.au/content/markonah-zootopia-full...
site address: www.cancerconnections.com.au/content/markonah-zootopia-fullmovieputlocker1080p. site title: [[Markonah]] = (Zootopia) full.MOVIE.P.utlocker.1080p | Cancer Connections supports people affected by cancer. Our opinion: ... Proceed to the page?Powered by: Very Tiny URL Shortener at http://vturl.net ...
Facebook Open Graph URL Check - FB Meta Info Tool
www.facebookog.com/sites/www.reddit.../287c61bddc7085a929d98ba296348d68
http://www.cancerconnections.com.au/content/markonah-zootopia-fullmovieputlocker1080p · http://www.cancerconnections.com.au/content/markonah-zootopia- ...
Facebook Open Graph URL Check - FB Meta Info Tool
www.facebookog.com/sites/aeterna.qip.ru/.../7d6947f2763ceb6a6ed01aa5dcac7919
http://aeterna.qip.ru/test/view/6016743/https://disqus.com/home/channel/theweather/ ... http://www.cancerconnections.com.au/content/markonah-zootopia- ...
「&amp;&amp;」 は 小文字「&&」 に変えてください
javascript:for(var%20u,l=document.getElementsByTagName("link"),i=0;i<l.length;i++)if(l[i].rel&amp;&amp;"canonical"==l[i].rel.toLowerCase()){u=l[i].href;break}u||(u=location.host+location.pathname+location.search),window.open("http://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/"+u);
あこがれの英字キーボードを手に入れたから早速会社のパソコンに接続してみた。会社のパソコンは Windows 7。解像度もメモリも CPU も悲劇的な支給パソコンをなんとか使えるレベルで動かしてくれる頼もしいやつ。
「カシュカシュカシュ」
う〜ん、シングルクォーテーションとダブルクォーテーションがうちやすい! あとアットマークをシフトを押しながら入力するのは新鮮かな。
「コトコトコト」
スペースキーが広い! 打ちやすい! ついつい連打しちゃう。キー配列になれるのは時間がかかりそうだけどハッカーみたいでかっこいい。だけどちょっと、ううん、かなりストレスフルなことが一点あって、日本語を入力しようとしたらキー配列がJIS配列になっちゃうんだ。いちおう英字配列にはキーコンビネーションで切り替えられるんだけど、キートップの印字とちがうじゃない。ほら '*' が '(' だったりさ。
今思えば英語入力にわりきって使えば良かったって思うよ。でも往々にしてわりきるのって無理でしょ。
こまったときのグーグル頼み。グーグルさんに日本語キーボードのパソコンで外付け英字キーボードを上手く使う方法はないのって聞いてみた。そうしたらいろいろおすすめしてくれたから、まあ、このくらいの苦労はしないと英字キーボードを買った意味はないよねって、というかこっちから苦労を買ってやろうって、ふふんと思いながらいろんなページを確認したの。業務中だったけど。
それで、レジストリを書き換えてやればいいって書いてあるページを見つけた(http://blog.heiichi.com/?eid=792239)。書き換えるのは
パス : HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/i8042prt/Parameters キー : LayerDriver JPN, OverrideKeyboardIdentifier, OverrideKeyboardSubtype
か。でもレジストリエディタってなんか使いづらいし、怖いなあ。おっとそういえば業務のデファクトスタンダードアプリ Excel で、拡張コンテキストメニューから「読み込み専用で開く」ためにレジストリを書き換える PowerShell スクリプトを作ったんだっけ。マイクロソフトオフィスがアップデートするたびにレジストリ書き換えられるもんだから、あたまにきて作ったんだっけ……。
New-ItemProperty -Force -Path 'Registry::HKEY_CLASSES_ROOT/Excel.Sheet.12/shell/OpenAsReadOnly' -Name ddeexec -PropertyType String -Value "[open("%1",,1,,,,,,,,,,,,1,,1)]"
よっし、エンジニアならコンポーネントの再利用だな、ってスクリプトをコピーしてぺたぺた(スクリプトは超危険なので割愛!)。パスをかえて、値はこれで、そうそう現在の設定を確認して英字配列と日本語配列を自動で切り替えるようにしたいな、むふふ、なんてつなげたばかりの英字キーボードですくりぷとすくりぷと書いていたの。
そんで実行。エラーか。ふむふむああええおお、パスまちがえちゃった。
こんどこそ実行。エラーなく終わって、ちゃんとキーの名前と値が入っている。さてさてそれでは再起動しましょう。
「ブイーン」
これ面倒なんだよなー。ハードディスクの暗号化解除っと。あれ、起動画面に移らないなあ。メモリチェックが走っているのか。ふーん。
……おわらないんだけど………………………………………………。おそるおそる画面をみたら、
「Windowsが起動できませんでした。システム管理者に連絡してください。」
うっわーーー。ブルースクリーンだーーー。はじめて見たーーー。本当にブルースクリーンででるんだなあ。
正直このときはラピュタをみつけたパズーの気分だったかも。ぼくの場合はこの先にはわくわくなんてなかったけどさ。だんだん、やべー、これやべー、これやべーや、これすごくやばいよね、って正気にもどった。そんで隣のお仲間にバレる前に強制終了。ふう。多分再起動中だっておもってくれたよね。
だいじょうぶだ Windows は軍用にも使われる堅牢性の高い OS だ。これくらいのエラーは普通再起動したらいつもと同じように退屈な起動プロンプトがでるはず。そうやって自分をまず信じる。それが一番大事。
まずは軽い深呼吸。そして電源オン。
「ブイーン」
ハードディスクの暗号化解除は BIOS レベルだから変わらないのか。Windows は予期されない終了をしたって? そのとおり! 気にせずに君はいつものように平常心で起動してくれたまえ。
あかんわ。これ完全にあかんわ。二回起動して二回だめって、これなんかいやってもダメなパターンはいったよね。エンジニアのはしっくれだけどそれくらいはわかる。
とりあえず電源を落として、気持ちを落ち着かせるために散歩しよう。ああ、今日は雲がきれいだなあ。風もふいていてはるだなあ。どうしよ。ぼくも答えはわかっていたんだけどね。管理部にごめなさいしてリカバリ DVD をかりてくればいいんだよね。でもさ、ただの箱になったパソコンはお客様のものっていう派遣の立場だしさ、絶対に原因追求でレジストリいじったことを告白させられるしさ、ああなんか春と秋ってにてるよね。
あとさブルースクリーンになった原因もわかったの。ふいにあああれだなって思い浮かんだんだけどさ、スクリプトつかいまわしちゃったせいで OverrideKeyboardSubtype キーの型を DWORD じゃなくて String にしてたのよ。ぜったいにこれで起動シーケンスで致命的エラーはいてんだろうなって。
そんな風に思いながら、自席に戻って、もう一回電源起動。もう一回よく画面を確認する。……むむ自動修復だと。よかろう最後の望みだ。かなえてやろうじゃないか。へー最後に記録した正常状態にシステムを復元するのか。なんか説明書きに「最近インストールしたプログラムとか消えるかもね。ハハッ。」て書いてあるけど、しばらくインストールなんてしていないし、初期状態に戻んなかったらまあいいよって感じ。ポチッとな。
そんでもって三十分から一時間経ったかなあ。あまりにも時間がかかるからトイレの個室で頭をかかえてたの。自席に戻るとパソコンの電源が落ちているわけ。さてとこれはラストチャンスだ。なんのチャンスかわかんないけどラストであることはあきらかだよね。そして電源をいれた。
この時ばかりは神様に祈ったね。だって計算機はプログラムしたようにしか動かないから、お祈りなんてしても意味ないもんね。だから神様にお祈りしたの、どうかおねがいします、今後はこれにこりてレジストリなんてぜったいにいじりませんので、この計算機が正しく動くことを祈ってくださいって。
結局、無事復旧できた。なにひとつ異常なく Windows 7 は立ち上がって来て、みなれた壁紙がでてきた。おそるおそるレジストリを確認したら、ちゃんとぼくがいじくるまえにもどっていた。ありがとう Windows! ありがとう自動修復機能! いちおうありがとう神様!
それでも外付け英字キーボードで日本語入力したいんだーて人はここらへんを見たら幸せになれるよ。
USB英語キーボード付けた。(英語、日本語キーボードの共存、KeyboardTypeOverride) 202122 (http://202122.iku4.com/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/%EF%BD%95%EF%BD%93%EF%BD%82%E8%8B%B1%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E4%BB%98%E3%81%91%E3%81%9F%E3%80%82%EF%BC%88%E8%8B%B1%E8%AA%9E%E3%80%81%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89)
USBポートに対しての設定だからブートで失敗することはないと思うよ(ブルースクリーンを発生させたもののことば)。
いちおうこれを書くにあたって、自宅のパソコン Windows Vista で再現できないかためしてみた。検証内容は以下の二つ。
結論としては両方とも大成功! ちゃんとレジストリエディタから編集したら、英字キーボードで日本語入力が快適にできるようになったし、 DWORD を String に変更したらブルースクリーンがでるようになったし! Vista だと会社の Windows 7 ではできた自動修復ができないし! なんかブートセクションとデータセクションが分けられるようになったのって Windows 7 かららしいし!
だけどここは会社じゃなくて自宅だから、メイン OS の Ubuntu で Windows 領域をマウントして華麗に chntpw を叩いてレジストリを修復できる。そう Linux ならね。
自分が子供の頃、公衆電話の使い方ってそんなに手取り足取り教えてもらったっけな?と疑問に思う。
少なくとも、親からテレホンカードの使い方を教えてもらった記憶はない。
さらに言うと、オレンジカードで切符を買う方法については絶対に教えてもらっていない。
でも何度か切符買ってる。
小学校に入るか入らないかのあたりで、我が家にCDとCD再生機がやってきた。(それまではテープ)
説明書を読まなくてもCDは再生できた。裏返さないものだといちいち教えてもらっていない、裏返していない。
自分が子供の頃はまだSuicaは無かった。首都圏に住んでも居なかったから、上京して初めてSuicaというものの存在を知った。
誰かにSuicaでの改札のくぐり方、チャージの仕方をいちいち教えてもらったわけではない、今はPasmoを使えている。
昔使ってたガラケーだって、i-modeだってiPhoneだって、使い方は誰にも教わっていない。
全部ね、見ればわかる作りになってるのよ。
公衆電話に使い方、図で書かれてたのよ。
警察や消防はボタンを押せば通話無料っていうのもばっちり書いてた。押したらどうなるんだろうってドキドキしてた。
券売機には「ここにカードを入れろ」って書いてるし、音声でアナウンスもあるし
CDは片面が装飾されていて、こっちは使えないんだと分かったし、
コンボでCDのサイズが入りそうなところは上面にしかなかった、そこに丁寧に「OPEN」てかかれたボタンがついている。
ああ押せば開いて、ここにCD入れればいいんだなって分かるのよ。子供でも。
iPhoneだって最初に見て、どこを押せば良いのか分からないなんて人いないでしょう。
まあ、文字が読めないくらいの小さなお子様なら仕方ないけれど、
公衆電話かけられないとか、Twitterしてる年齢で警察や消防に無料で通話できるの知らない人がいるとか、
http://www.ittyadota.net/2013/12/dota2-letspart1.html
上のブログには、
>このテクニック、デフォルトの設定だとアタックムーブ(初期設定でA+左クリック)で味方を指定しないと出来ないんですが、
>この設定はDota2内の設定画面からは設定できないので少し特殊な設定をします。
今はもうDota2内の設定画面から右クリDenyを設定できるようになっている。
Options → Right-Click to Force Attack にチェックをいれるだけ。
https://steamcommunity.com/app/570/discussions/0/523897277914431844/
>Open options in Dota, go to the options tab, select "Force right-click attack"
最近2階が覗きたくなることが増えたので書いた。2階があればブクマ数の周りに2階のリンクを追加する。
javascript:void[].map.call(document.querySelectorAll("a.entry-info,.entry>a.entry-link,.users a"),function(e,n){n=new XMLHttpRequest,n.open("GET","/entry/jsonlite/"+e.href),n.responseType="json",n.onload=function(t,o){(t=n.response)&&e.insertAdjacentHTML("beforebegin",((o=t.count)+" upper"+(o>1?"s":"")).link(t.entry_url))},n.send()});
http://b.hatena.ne.jp/以下のページで使えるはず。
void [].map.call(document.querySelectorAll('a.entry-info,.entry>a.entry-link,.users a'),function(u,x){ x=new XMLHttpRequest(); x.open('GET','/entry/jsonlite/'+u.href); x.responseType='json'; x.onload=function(j,c){ if(!(j=x.response))return; u.insertAdjacentHTML('beforebegin',((c=j.count)+' upper'+(c>1?'s':'')).link(j.entry_url)) }; x.send(); });
python の質問になります。 - 例えばlist = [[1,あ,い,う,え,お],[2,か,き,く,... - Yahoo!知恵袋
# make csv file import csv def make_csv_file(table_data, file_path): with open(file_path, 'w') as file: for row_data in table_data: csv.writer(file).writerow(row_data) # usage list = [ ['1','a','b','c','d','e'], ['2','f','g','h','i','j'], ['3','k','l','m','n','o'] ] make_csv(list, 'sample.csv')
pythonでのデータファイル読み込みについてpython初心者です。p... - Yahoo!知恵袋 に対する回答。
Step1. 次のようなファイル datafile.py を作成します。
# Set your np object in this file. np = .... # data data = [ [np.array([1,2,3]),np.array([0,1])], [np.array([4,5,6]),np.array([2,3])], [np.array([7,8,9]),np.array([4,5])], ]
Step2. 本体のファイルで datafile.py を呼び出します。
以下、変数 data, np には 上記の内容が、保存されて返ってきます。
from datafile import data, np
注意: 簡単ですが、この方法の場合 datafile.py の中で np オブジェクトも定義する必要があります。PHP で言う所の include 的なのがあったら楽なんですけどね〜。
Step1. 次のようなファイル datafile.csv を作成します。
1,2,3,0,1 4,5,6,2,3 7,8,9,4,5
Step2. data = [np.array..., np.array... ] としたいところを次のように書き換えます。
data = [] e = lambda i: int(c[i]) file = open('datafile.csv') for line in file: c = line.split(',') data.append([ np.array([e[0], e[1], e[2]]), np.array([e[3], e[4]]) ]) file.close
補足 lambda式
結構簡単にできた。
ここから、ページ切り替えてURLを収集する処理も追加すれば、
クローロング部分は完成。
require 'nokogiri'
url = 'http://ja.aliexpress.com/category/200003482/dresses.html?spm=2114.52010108.6.7.gT0qlW&addpid=32546825642&isOnSale=yes%22'
charset = nil
end
doc = Nokogiri::HTML.parse(html, nil, charset)
num=0
doc.css('a[class = "product "]').each do |product|
p product.attribute("href").text
p num = num+1
end