「 class」を含む日記 RSS

はてなキーワード: classとは

2017-11-17

英語で興味ない話題読んでもそりゃあ楽しくないよだって興味ないんだし

あんまこういうこと言いたくないんだけどさ、「英語」を特別視しすぎじゃね。

英文として優しい文章、難しい文章があるのは間違いないんだけどさ、それが好きか嫌いかってのは別じゃん。

英文を楽しく読むんじゃなくて、楽しく読めそうなのを英文で読むんだよ。

例えばさ、次の例文は日本語だけど判る?

全体会合は9月20日以来、約2カ月ぶり。この日は憲法への自衛隊明記や緊急事態条項の創設を含む「改憲4項目」のうち、参院選県境をまたぐ「合区」の解消を議論憲法47条と92条の改正を目指す方針確認した。

『全体会合って何よ?この日って9月20日から二ヶ月ぶりだから11月だろ?自衛隊明記や云々で、なぜ参院選の合区解消を議論してんの、さっき改憲4項目って言ったじゃん!47条と92条を目指す方針確認してんのに、さっきの合区はなんだったんだ……』

タネ明かしすれば、これは朝日新聞ニュースな。合区解消へ、47条と92条改憲の方針 自民の推進本部:朝日新聞デジタル

自民党憲法改正推進本部細田博之本部長)は16日、衆院選後初となる全体会合を開き、憲法論議を再始動した。」ってところからスタートしてる。

んでさ、オマエさんの次の文って、これニューヨーク・タイムズだろ?

The House is set on Thursday to pass its own version of the tax bill, which would cut taxes by more than $1.4 trillion over 10 years and broadly rewrite the business tax code.

Tax Bill Thrown Into Uncertainty as First G.O.P. Senator Comes Out Against It - The New York Times

英語でも日本語でも新聞写真がモノ言うからさ、

もう記事見たら一発でロイ・ウィデンさんがなんか告発して、オリンハッチさんが睨んでんな、揉めてんだろうなって判るじゃん。

その百聞は一見に如かずという写真キャプションに、そのまんまのことが書いてるじゃん。

Twitter上には画像説明載ってないけど、記事中の写真に対する説明文ね)

Senator Ron Wyden, Democrat of Oregon, left, clashed with Senator Orrin G. Hatch, Republican of Utah, right, during a hearing of the Senate Finance Committee on Wednesday. Credit Eric Thayer for The New York Times

上院議員同士の揉め事ね、アメリカ合衆国上院財政委員会聴聞会で揉めたのね。

んで、省いたのがワザとかどうか分かんないけど、記事最初の文ってこれじゃん。

WASHINGTON — Uncertainty gripped the Senate on Wednesday over efforts to pass a sweeping $1.5 trillion tax cut after a Wisconsin Republican became the first senator in his party to declare that he could not vote for the tax bill as written, and other senators expressed serious misgivings over the cost and effect on the middle class.

全部訳していける人とかはてブにもいっぱいいるだろうけどさ、そういう事が言いたいわけじゃなくてさ。

これ読みたいの?絵本だと簡単すぎてヤなんだろ?

自民党憲法改正推進本部の全体会合と同じでさ、読みたくない記事読んでも楽しくないよ?

そもそもさ、共和党の票をトランプさんが取りまとめて税制改革するって話を知らないとさ、読んでも意味わかんないだろ?

The New York Timesでこの記事を読む人は、Ron Wydenが民主党だって知ってるよ?Orrin Hatch共和党なのも当たり前の知識だぜ。

自民党憲法改正推進本部記事に「公明党の根強い慎重論が」っていきなり書いても問題ないのは、自公連立政権だって記事読むやつは当然知ってるから省いてるってことだよ?

誰に何を吹き込まれたのか知らないけどさ、やっぱ興味のないモン読んでもツマンナイよ。

例えばさ、ニューヨーク・タイムズだったらHEALTH欄とかあるじゃん

オレなんかは、↓みたいな記事は気になって読む。単語とか分かんなかったら調べて読む。

なんでかって言うと、「オレは」血圧を下げる方法みたいな記事が気になるから

How to Lower Your Blood Pressure - The New York Times

人によって気になる記事が違うなんてのは当たり前なんだから、まずは自分の好きな記事を探すところからだと思うよ。

はてなに巣食うんだったらこんな記事とかさ→A New Phone Comes Out. Yours Slows Down. A Conspiracy? No. - The New York Times

興味のある記事を探して読んでみたいなと思って読む、とかにしないと、何の興味もない米国税制改革揉め事読んだって、そりゃ楽しくは無かろうよ。

https://anond.hatelabo.jp/20171116210216

2017-11-07

コメント一覧ページに「リンクを埋め込む」が出来た

ブコメ一覧の一番下に。

からあったっけ?なかったよね?

増田にも埋め込めるのかな?

試してみる。

<iframe marginwidth="0" marginheight="0" src="http://b.hatena.ne.jp/entry.parts?url=https%3A%2F%2Fanond.hatelabo.jp%2F20171105205526" scrolling="no" frameborder="0" height="230" width="500"><div class="hatena-bookmark-detail-info"><a href="<a href="https://anond.hatelabo.jp/20171105205526">https://anond.hatelabo.jp/20171105205526</a>">80年代アニメのおしゃれさ</a><a href="/entry/s/anond.hatelabo.jp/20171105205526">はてなブックマーク - 80年代アニメのおしゃれさ</a></div></iframe>

増田には埋め込めないみたいね

表示されるのは最新コメ4件固定か。スター表示もない。

人気コメ順のほう選べたり、表示件数も設定できたら良いのに。

いつから変わった?

今朝から

毎度の事ながらリリースだせよ。

2017-11-06

ノート文字がかすれて消えそうだからここに置いておく(一応ネタバレ注意)。

1

Adulthood

二人の子から二人の大人へ。最終章「Adulthood」をクリアした。

understand, useless, needed, disable, lost and love

あの出来後のと翌朝。二人でインスタントの朝食を食べ登校する。二人で登校したことで Hanako は注目を浴びてしまい逃亡してしまった。

学校をサボって公園を歩き考え続ける Hisao。考えていたことは二人の間の壁について。昨夜の出来事があったといえども二人の間には互いを理解することを妨げている壁がある。Hisao は Hanako と話をしてその壁を壊したかった。後ろから声をかけられる "H...Hisao"。

Hanako も外出をして公園に来ていた。Hisao の前から逃れて、結局出会ってしまう。とうとう Hanako 自身気持ちを尋ねる Hisao。Hanako の返答は彼の思い込みを打ち砕くものだった。

あの夜の出来事は Hisao の大切な人になりたかたから、他の人より私を見て欲しかたから、庇護対象ではなくて一人の女性として扱って欲しかたから。Hanako告白は Hisao を強く動揺させた。そして告白をした彼女自身も、そんな自分に対して嫌な女だと自覚していた。

"Was... I wrong?"

もちろん彼女は悪くないと思う Hisao だが言葉が出てこない。Hanako告白は続く。家事の前までは少ないけれど友達がいて周りとちゃんとやれていたこと。大火傷を負ってからは全てが変わったこと。周りからの反応で深く傷ついたこと。傷つくことを拒否するために人と関わることを止めたこと。自分が消えてしまえばいいと分かっていたが、人との関わりを止める方がより簡単だったこと。Yamaku 学園に行けば再び社会との接点を見つけられるかと思ったこと。そして Lilly に出会たこと。Lilly と出会って友達になれたけど、Lilly は Hanako ができないことをなんでもできてやっぱり自分は useless だと思い知らされたこと。そして Hisao に出会たこと。Hisao も Lilly と同じで Yuko と簡単に仲良くなれたりして、自分はすぐ不要ものとして切り捨てられてしまうと思ったこと。それは嫌だったこと。誕生日世界中の人が疑いもなく正しくて幸せだと思い込んでいるので、useless な自分はとてもつらかったこと。朝、ベッドで寝ている Hisao を見て、やっぱり自分は切り捨てられてしまうと思ったこと。

そんな Hanako に Hisao は衝撃を受ける。今までか弱くて自分庇護しなければと思い込んでいた Hanako は守られたいと願う子供ではなかった。

語り終えて下を向く Hanako に対して Hisao は振り絞って語りかける。

Hanakoパニックを起こした時心配たこと。寮の自室に閉じこもった時は彼女に拒絶されているのではないかと感じたこと。それからいろいろ考えたこと。

そう言う Hisao に対して Hanako は思わず叫ぶ "I wasn't rejecting you!"。

Hanako がつらくて悲しくて Hisao を押しのけてしまった時も Hisao は彼女を捕まえていてくれたこと。そんな Hisao や Lilly 達の重荷にはなりたくなかったこと。それは Hanako の心から叫びだった。

二人の間にあった壁は崩れた。壁を崩すのに痛みがともなったがとうとう二人は正面から向き合った。

Hisao は続ける。心臓の異常が発覚した時とても怖かったこと。社会から切り離されて Yamaku へ来て自分人生が一度壊れたこと。でも Hanako出会って一緒に過ごして友達になって再び自分を取り戻したこと。そして失ったからこと Hanako気持ちを通じあわせられたのだと。

これは Hisao からの I need you だった。

ずっとずっと自分は useless だと信じていた Hanako はこの言葉を聞いて座り込んで泣き出した。そしていっぱいメチャクチャにしてごめんなさいと謝る。Hisao は彼女を抱きしめてそんなことは言わなくていいという。

そして自分は useless なのにと言おうとする Hanako

"You're my firend, Hanako! You're... No, you're more than that. I love you, Hanako."

泣き続ける Hanako に Hisao は寄り添う。Hanako はずっと自分必要人間だと言って欲しかったと泣く。

ようやく泣き止んだ Hanako に Hisao はいい天気だからこのままクラスをサボろうと提案する。でも……と迷う Hanako に対して大丈夫謝ればいいだけだよと言う Hisao。そんなことができないと拒否する Hanako。だが Hanako はやれる、絶対できるし、力が必要なら自分を頼ってと言う Hisao。そして二人は同じ道を歩いているんだから互いに助け合うのは当然なんだと言う。

"This called love."

公園を抜けて商店街を歩く二人。互いにたがいを横目で見つめながら歩く。なにかを思案しているように見える Hanako に何を考えているのかを聞く Hisao。立ち止まり一心な表情で Hisao に答える。Hisao に私からあげることができることがあると思う。でもそれにはすごく長い時間がかかると思う。だから恥ずかしいけれど、これが最初の小さな贈り物。

Hanako は Hisao の肩に両手を置き、ゆっくり顔を近づけた……

(Fin.)

2

Hanako 編は図書館から始まる。図書館で見かけた Hanako は夢中で本を読んでいた。クラスメイトだと思い出した Hisao は同じ本好きとして Hanako に話しかけるが、全力で逃げられる。

Lilly と出会い再び Hanako と Hisao 。 Hisao - Hanako - Lilly と三人の生活が回り始める。

基本的に仲良くなる→逃げる→もっと仲良くなるというのが Hanako 編。

彼女の逃避は後半になるにしたがってより深刻さを増す。

1. Lilly

Hanako の一番の友人。より正しくは唯一(Yuuko も一応友人だが)の友人。目が見えないのでよく Hanako が買い物に付き合う。

優美な身のこなしでありハイソ雰囲気を持つ。実際言葉遣いがとても丁寧。外見もスコティッシュハーフであり金髪アンド碧眼アンド長身スタイルがいい。

Hisao と Hanako の隣のクラス class represent を勤めており、Hanako と異なり交友関係も広い。

Hanako は Lilly のそんな万能っぷりを頼り、あごがれ、そして対照的自分に対して無力感を抱いている。 Lilly にとって自分価値のない人間だし彼女の重荷にはなりたくないと思っている。

Lilly は、 Hanako は守ってあげなくてはならないけれど、このままでは Hanako にとって良くないとも感じている。

Lilly は Hisao が現れたことで、 Hanako に良い影響が起こることを願っている。

2. Hisao

つい数ヶ月前まで健常者だったが、突然心臓病を発症しそれまでの社会から切り離される。そんな彼為のために両親は障碍児のための学校 Yamaku 学園に転校させる。見慣れない disable (盲目、手足の欠損、聾啞)にはじめは驚いたり疎外感を感じたりしたが、それぞれのユニーク個性を知るにつれて(足を使ってすごい絵を描く Rin義足なのにものすごく足が速い陸上部エース Emi、目が見えないが深い洞察力を持ちできないこととできることの違いを見せてくれる Lilly、聾者だが生徒会長を務める Shizune) disable について理解をしていく。

やがて Hanako、Lilly と仲良くなりともにボードゲームをしたり、お茶をしたり、誕生日会を開く仲となる。そしていつしか Hisao は Hanako の力になりたい、守ってあげたいと思うようになった。

しかし Lilly が家の用事スコットランド滞在している間、 Hanako誕生日が来て、 Hanako の態度が急変する。順調に Hanakofriend-ship を築けていると思っていた矢先に Hanako教室から姿を消し、自室に閉じこもる。 Hanako との関係が壊れるのを心配する Hisao だがどうすることもできない。 Hanako が姿を消してから Hisao はこれまでのことについて初めて考え始めた。そしてこれからのことについて自分が取るべき道を探し始めた。

自室から外へ出てきた Hanako だが、 Hisao は相変わらず彼女自分の間に壁があるのを感じてしまう。なんとか Hanako彼女のことを理解したいと願っていることを伝えようとして、 Hisao は自分の胸の傷を彼女さらす。自分も傷を負っているかHanako は独りではないと伝える。

Hisao の傷に触れた Hanako 。また一つ二人の絆が深まったように感じた。

数日後、図書館勉強していた Hisao 。やってきた Hanako に、 Hanako が自室にこもっていた間ずっと考えていた彼女過去について教えて欲しい、と Hisao は言った。ずいぶんとためらったがとうとう Hanako真剣な表情で語り始めた。

多くの生徒が下校をして静かな校舎の中を二人で歩きながら、 Hanako は昔の火事について Hisao に語り始めた。深夜に突然火が出たこと、熱から逃れようとして体を丸めて小さくなっていたこと、彼女の両親が彼女に覆いかぶさって守ってくれたこと、体の半分だけ助かったこと。

二人はいしか Hanako の寮の部屋まで来ていた。入室を躊躇する Hisao に対して Hanako はドアの鍵を閉めてと言い、カーテンを閉じる。そして大きく息を吸い、覚悟を決めると、ブラウスブラジャーを順番に脱ぎ落した。 Hisao が彼女に傷(心臓手術)を見せたように彼女も傷(火傷)を見せたのだ。

そんなことをする必要は無いと言う Hisao だが、 Hanako はこれが私だからと傷を見せる。そして二人は......

(二人のプレイの後、息も絶え絶えな Hisao は心臓発作の兆候を感じていたところがリアルだった)

はじめは Hanako を守ろうとしていた Hisao だが、結局それは間違いだった。

守るというのは守る人間と守られるべき人間関係だ。その関係は非対称であり、守る者は守られる者に対して優位な力を持つ。

では恋人夫婦としての庇護関係はどうなるだろうか。

3. Hanako

出会いはひどいものだった。話しかけられて、自分空間に入られて、そして目が合ってしまった。

"I..."

"I...I..."

"Ivegottogodosomething!"

パニックになり全力で逃げてしまった。これが出会いであった。

Hanako 編に入ると Hide and Seek (かくれんぼ)という Act がある。彼女と親しくなるということは Lilly や Yuuko そして彼女自身の中に隠れている Hanako を見つけ出すことだ。いろんな彼女がいる。

Life of Pie を読みふける Hanakoチェスを好む Hanakoドールが好きな Hanako 、 Lilly とお茶を飲むのが好きな Hanako 、外へ出る時は顔が隠れるように大きなキャスケットを被ること、火傷の痕を隠すために左側を歩くこと。

何を書いているのだろう。まとまって体系だったことを書かなくては。

3

Disable

Katawa Shoujo とは disable である人々が able であることに焦点を当てた作品だ。例えば Emi は両足が膝より下がないのに、競技義足で誰よりも早く走れるし、 Shizune は聾唖であるクラス委員生徒会長を務めあげる才媛だし、 Rin は両腕が無いのにもかかわらず足で見事な絵を描く。そして Hanako親友の Lilly は、全盲を苦ともせずクラス委員であり友人も多い社交的な女性だ。

ハンディキャップをかかえながらできないことを嘆くのではなく、できることで生活を組み立てている。

それでは Hanako の disable と able は何なのか。実は Hanako には先にあげたヒロイン達のような disability は無い。右半身に皮膚がひきつれるひどい火傷の痕が残るが五体満足であり、他のヒロイン達のような明快なハンディキャップは無い。では Hanako の able は何か。目が見えること?耳が聞こえること?意外と足が早いこと?両腕があること?そう Hanako の able とはそれだけなのだ。 Lilly しか友人はいないし、他人視線が怖くてたびたび授業を逃げ出すし、人からしかけられると赤面してしどろもどろになる。 Hanako とまともに会話できるのは Lilly と Yuuko 、Lilly の姉 Akira、そして Hisao のみだ。Hanako の disable とは able の裏返し、彼女は肉体的に able ではあれど精神的に disable なのだ

どのヒロインも多かれ少なかれ悩みや心の傷はあるが、 Hanako は突出して深く、彼女ストーリーは見えない心の傷とその象徴である人目を惹く火傷の痕をメインテーマとして進む。

Hanako過去トラウマフラッシュバックに襲われて痙攣するレベル)のせいで、火傷の痕を見られることをひどく嫌がり恐る。そのため、普段は髪の毛で顔の半分を多い、人目が多い場所に行く時は大きな帽子を被りLilly の左側で小さくなり、顔の右側にある火傷の痕への視線を遮ろうとする。彼女が心を落ち着かせることができるのは、親しい友人と部外者が来ないところでひと時を過ごすことだけだ。悲しいことに、自分の部屋では外部から侵入者を防ぐことはできても、彼女を苦しめる悲しい思い出が甦るのは防げないのだ。

彼女の disable は他のヒロイン達が外見上のものに対して内面的なものだ。その disable の根本の大火傷が彼女の全てを変えた。親を奪い家を奪い社会を奪った。そしてそれは主人公の Hisao との共通点だった。disable が二人の出発点だった。

Able

「Disable」で Katawa-Shoujo のテーマとは disable の中の able である説明した。そして Hanako は disability を持たない代わりに able が disable になっていることを例をあげて紹介した。ここからはそんな Hanako の数少ない able から彼女の内と外を考察する。

読書

Hanako と初めて言葉を交わしたのは図書館でだった。図書館Hanako にとってクラスからの逃避先であり、本は現実からの逃避先だった。そして読書は Hisao との共通趣味であった。

本編の中で特徴的であるのだが、物語が進み Hisao と Hanako が仲良くなるにつれて、 Hanako図書室へ逃避する回数が減少する。 Hisao たちと外へ出たりして内から外への変化が見られる。しか図書館に来る描写はあるので、本から卒業したというわけではない。本は逃避先から趣味になったというべきだろう。

ゲーム(ボードゲームビリヤード)

振り返ると Hisao と Hanako が交友を深めるのはゲームを通してだった。空き部屋でチェスをすることで友達になり、パブビリヤードを遊ぶことで Hanako の意外と子供っぽい内面を知り、アンティークスタイルチェスセットを贈ることで喜ぶ顔を見た。

いつも Hanako感情を顔に出さず、自分から積極的に出ることもない。Shizune & Misha につつかれても困ってちぢこまるだけだし、知らない人に話しかけられると逃げるし、人に何かを協力してもらうこともできず独りで作業をする。

しかゲームで遊ぶときHanako はかすかに笑み、時には自信を持って駒を動かす。その普段とはちがう姿は Hanako本来気質---人見知りだけど、活発で、遊びに夢中になれて、ちょっと子供っぽい性格が浮かび上がる。

4 Children and Adulthook

Katawa-Shoujo では多くの登場人物高校生だ。高校生というのは肉体的には大人であり精神的にはまだ子であるという、大人子供狭間の期間である。そのためシナリオでも子供から大人への成長を軸とする。 Hanako 編では最終章が「Adulthook」である通り、 Hanako そして Hisao が大人への一歩を歩み出すことがエンディングを通して描かれる。

大人になる」にはいろいろな意味がある。例えば成人することは社会的地位を手に入れるということだし、親元を離れたことに対して「大人だ」と使われることもある。それでは Hanako と Hisao の場合はどのような意味で「大人になった(子供卒業)」のか。これには Hanako 編の主題である体と心が深く関係する。

よく知られた「大人になる」として男女ともに性交経験することがある。Hanako 編においてもこの意味で二人は大人になった。共に痛みを経験し( Hanako処女喪失。 Hisao は軽い心臓発作)一夜を明かしたことで二人は次のステージシフトたかに見えた。しかし後に分かることだが、二人は未だに子供のままの関係だった。

子供(children)という言葉は、作中で直接しかHanako言葉として現れる。

```

"All I ever was to you was... a useless person. Just someone... to protect. Someone like... a child."

```

小さい頃に火傷の原因となった火事により社会と切り離され、そのまま子供のまま育った Hanako は、 Hisao に庇護必要対象(=子供)としてではなく友人以上の人として見て欲しかたか自分の傷を全て見せたという子供のような思いを告白する。 Hisao はこの告白を聞いて自分が全く Hanako のことを理解していなかったことを痛感する。 Hanako の外面的性格ばかり見ていて Hanako がどう感じているかを考えていなかったこと。

しかし Hisao が自分病気のことその心情を同じように告白たことで、二人は互いに理解し合えることを確信した。そして自分相手かでしか考えられなかった二人は、自分相手を同じ道の上の存在として考えられるようになった。

Hanako 編では心をもって「大人になる」ことが提示される。

Hanako は声をあげて泣くことで子供時代に別れを告げた。そして大人最初の一歩としてラストシーン最初ギフト(てれる)を Hisao に送った。

Child

ここから感想(今まではまとめ)。

Hanako のことを語るには子供と成長についてが欠かせない。

子供の頃の Hanako は人見知りするけど純粋好奇心が強い子だったのだろう。しか火事人生を曲げられ、社会から切断され、その気持ちのまま体だけ成長した。自分の生きる意味を見失い、自分を守るため人と関わることを止め、ただ耐えていた。

Hanako が語る言葉に裏はない。 Hanako世界は見たままの世界だ。トラウマフラッシュバックに襲われたときには自分を責める自分の声を周囲に放射するけれど、それが嫌だから鬱の期間は自室にこもる。

フツウならばたとえ Hisao がテキストノートを机に広げていたとしても、勉強より Hanako とのやり取りを優先すると気づくだろう。また茶目っ気のある性格ならばそのことをからかうように勉強しているじゃないというだろう。でも Hanako は見たままを見るのだ(But...)。

Change

成長という言葉を使ったが、作中では Change が使われていた。 You can change という具合に。

変わること、変わるものはいつも Hanako の周りの世界だった(ムービーをみよ)。世界はすごい速さで動き続け彼女はその流れに乗れなかった。しかし Lilly と Hisao に出会たことで、自分でも自覚しないうちに彼女は変わっていた。授業を逃げなくなったこと、自分からしかけるようになったこと、きわめつけは Hisao を電話お茶に誘ったことだろう。そして何より彼女気持ち友達では嫌」。

(ちなみにお茶(デート?)に誘った時の迷台詞はこれ:

"If... if you're not busy... I-I was wondering if y-you would... l-like to... m---"

噛みっかみである。)

エンディングで Hisao は Hanako に変われると保証する。このとき Hanako もいつしか自分が変わっていたことに気づいたのだろう。

5 その他

2017-10-28

anond:20171027101309

タデプログラミングやってみた

実行環境は、Windows 10はてなAPIは知らない

1)URL規則性を見つける

増田場合

https://anond.hatelabo.jp/?mode=top&page=1

page=1、page=1001、・・・

2)各ページの日記規則性を見つけて、投稿時刻の取得方法検討する

増田で、先頭の日記場合

<div class="section">
<h3>
<a href="/20171010162108"> ← (雑だが)ここらへんを取ればよさそう
<span class="sanchor">■</span>
</a>
<a href="/20171010161641">anond:20171010161641</a>
</h3>
~~~
</div>

3)定数、関数の雛形、ループURLを生成・出力するだけのソースをとりあえず作成・実行

実行すると、↓が出力されるだけ

https://anond.hatelabo.jp/?mode=top&page=1

https://anond.hatelabo.jp/?mode=top&page=1001

https://anond.hatelabo.jp/?mode=top&page=2001

・・・

4)「ruby web 取得(スクレイピング)」あたりでネット検索、内容を理解せずにコピペする

4-1) 標準のopen-uriを使うと取得できるよ等見つかる

open-uriを実行すると、謎のエラー発生

C:/Ruby23-x64/lib/ruby/2.3.0/net/http.rb:933:in `connect_nonblock': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

4-2)エラーメッセージ検索、内容を理解せずにコピペする

OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

 

ここまでで、任意URLWebページ取得ができるようになる

5)Webページの内容を解析(パース)し、ページの先頭の日記のYYYY/MM/DD HH:MM:SSを取得

5-1)

HTMLはある程度構造化されているので、今回の場合だと、↓のようなとり方がいいと思う

「divタグ sectionセクション」直下の「最初のh3タグ直下の「最初のaタグhref

5-2)

思うけど、今回は、構造検索じゃなくて、単純に文字列検索だけで済ます

5-3)※

取得対象構造が変化する場合も多々あるが、構造が変化した場合でも、

構造的な取得方法を作っておけば、変化にもある程度対応やすい(パラメータの「1」を「2」にするとか)

文字列を解析的なやり方だと、取得対象の書式が変化した場合に、対処しにくいことが多い

ここらへんを、TODO:あとでやる、なんてするんだけど、もちろんあとでやらなくて不具合の温床になる

これ豆な

6)結果を出力

printコマンドプロンプトへ出力

 

例えばだが出力には、ファイルへ保存、メール送信クラウドへアップ、増田投稿 とかもある

 

ここまでで、page=1の処理ができた

7)繰り返しに注意

page=1ができればあとは繰り返すだけ

繰り返すだけなんだが、取得ごとに10秒待つことにする

あんまが~~ってやると、怒られるので

 

愚直なまでの単純な繰り返しは、PCプログラム) > 人の操作 の最たるものだと思う

 

はいえ、ほんとうに愚直で、

タイムアウトしたらどうなるのか?

・古いページは構造が異なるかもしれないのでは?

・最終ページはどこ?

・・・などなど。これらの忖度AIでも解決しにくい・・・と思う。

8)余談1 プログラム関係ネット検索すると、はてな結構ひっかかる

なにかうれしいセロry

9)余談2 スクレイピングってなんだよ

的な英単語IT用語解説よりも、英和辞典を引くとスって理解できることがある

scraping ・・・ こすること、削ること、削り落としたもの、かきくず

・・・

rubyソース

require 'open-uri'
require 'openssl'

# なんかエラーが出る暫定対処
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

BASE_URL = 'https://anond.hatelabo.jp/?mode=top&page='
PAGE_INCR = 1000

# 4) 指定URLのページを取得
def get_page(url)
    open(url).read
end

# 5) 年月日時分秒を取得
#012345678901234567890123456789012345678901234567890
#<div class="section"><h3><a href="/20171010162108">
def get_ymdhms(page)
    pos = page.index("<div class=\"section\"><h3><a href=")
    #p pos
    #p page[(pos+35)..(pos+35+13)] # YYYYMMDDHHMMSS 14
    aa = page[(pos+35)..(pos+35+13)]
    sprintf("%s/%s/%s %s:%s:%s", aa[0..3], aa[4..5], aa[6..7], aa[8..9], aa[10..11], aa[12..13])
end

# 6) 結果を出力
def print_dat(inc, ymdhms)
    puts sprintf("%06d, %s", inc, ymdhms)
end


# メイン
def main
    inc = 1
    for i in 1..10
        sleep 10 unless i == 1 # 7)初回以外は10秒待つ
        url = BASE_URL + inc.to_s
        page = get_page(url)   # 4)webページ取得
        ymdhms = get_ymdhms(page) # 5)投稿年月日取得
        print_dat(inc, ymdhms) # 6)結果出力
        inc += PAGE_INCR
    end
end

# 実行
main

 

ソース記法で書くと文字化けするので、スーパーpreで)

実行結果

ano_his.rb:67: warning: already initialized constant OpenSSL::SSL::VERIFY_PEER
000001, 2017/10/28 15:04:51
001001, 2017/10/10 17:08:08
002001, 2017/09/19 17:22:26
003001, 2017/08/24 10:23:53
004001, 2017/07/27 11:57:49
005001, 2017/06/27 17:42:17
006001, 2017/05/28 22:57:26
007001, 2017/04/28 10:26:18
008001, 2017/03/21 10:10:38
009001, 2017/02/10 15:01:32

2017-10-21

何でもかんでも揃えようとしないでほしい

プログラマなんだけど、なんでも揃えようとしてる人がうざい

よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「=>」みたいなのの位置

揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒

10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする

面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい

だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たとき結構大きな変更してるように見えたりするからちょっとイヤ

さらgrep かけようにも空白数が不定だから正規表現にしないといけない

正規表現書くの面倒だしそもそも遅い

大規模プロジェクトだと待ち時間が大きく変わってくる

んだけど、まあここまでは別にいい

他でも十分ある宗派の違いだし、まだ理解できる

この揃えるとき

aaa      : {
    bbbb : 100
    ccccc: 200
},
dddd     : {
    e:   : 300
}

みたいに(フォントによっては揃ってなく見えるかも)、ネストが違うのに全部を揃えようとするの、ホントやめろ

わかりづらい

上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい

せめて揃えるのは連続する行で同じ階層のものだけにしてほしい

上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄

bbbb と ccccc みたいなときだけならまあ許せる



仏の顔も三度まで、

ここからは許せないレベルもの


(1) 文字数を合わせようとする

上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる

しか文字数が揃ってたらそんな必要はなく見た目も綺麗だ

きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない

5つ項目があって、4つが6文字単語で残りの1つが4文字だったとする

6文字にしたいからそれっぽい意味単語いか探そうとしてる

無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい

理解できない自己満足しか思えない

揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る

beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語比較ではミスの数が明らかに変わると思う

なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい



(2) 単語の語尾とか

(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語勝手に変化させたものがある

例えばだが、語尾が1つを除き全部 -ly になってたとする

そうすると残り一つに無理やり ly をつける

なんなの?イン踏みたいの?ラッパーなの??

経緯を知らない人が見たら意味不明単語である

そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある



(3) 変化形無視

上の時点で英語を完全無視英語力のなさはわかっただろうが、さらにこういうのもある

過去形には ed複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う

それを完全無視変数名を定義するから見ててすごく気持ち悪い

プレフィックスis つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くとき本来の形で書くとエラーでるからさらイライラする

例えばこういうこと

readed, catched, taked, companys, boxs, mans, childs, fishs, classs

見てるとムズムズする

英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う

まあエラーメッセージdon't have ~ とすべきところを has not ~ とか書いてたくらいだからなぁ

これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、~~』みたいの出るから」と言って直させるけど、上だからどうしようもない

間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない

2017-10-10

anond:20170901082944

勇気<img src="http://d.hatena.ne.jp/cgi-bin/mimetex.cgi?e^{i\pi}" class="tex" alt="e^{i\pi}">倍!

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-08-27

https://anond.hatelabo.jp/20170826201309

どんな歌だったっけと思って"夏の日の1993 class"で検索してYouTubeの曲を聴いてみるんだけど

こんな女声じゃなくてもっとおっさんぽい声色だった気がして、なるほどこうやって記憶が美化改竄されていくのかと自己嫌悪に陥った

2017-06-18

https://anond.hatelabo.jp/20170618000024

そんなあなたお勧めなのが、ブルーエア(Blueair Classic 480i) 。

半年に1回フィルター交換をする際に、どれだけ部屋の空気からほこりが除去できているのか実感できますよ。

私の場合は、ハウスダストアレルギーで、ブルーエアの使用から症状が消えたのですぐに分かりましたが。

2017-06-06

ジェネリック医薬品.java

interface 頭痛薬 {}

class バファリン implements 頭痛薬 {}

class バッサニン implements 頭痛薬 {}

class 薬瓶<T> { /* 中略 */ }

public class Test {

  public static void main(String[] args) {

    薬瓶 頭痛薬入れ = new 薬瓶<頭痛薬>();

    頭痛薬入れ.add(new バファリン());

    頭痛薬入れ.add(new バッサニン()); // バファリンとバッサニンは成分が同じなので、同じ薬瓶に入れて混ぜて服用しても問題ない

    System.out.println(頭痛薬入れ.size()); // 2

  }

}

2017-06-02

http://anond.hatelabo.jp/20170602170355

Javaは、オブジェクト指向を盲信し、すべてにおいてオブジェクト指向強制したのが間違いだった。

Java で、hello worldプログラムすると

public class Hajimete {

public static void main(String[] args){

System.out.println("Hello, world.");

}

}

こんなに長く書く必要があるのが一番嫌われた理由

他の言語なら

print("Hello, world.");

ぐらいの1行で済むんだ。

2017-05-24

[]国連特別報告者の書簡一方的に公開されるのは普通

国会ウォッチャーです。

 ケナタッチ氏の書簡に対する、日本抗議文がアップされるのをwktkしてまってます。あと前文部科学事務次官実名事情を話す覚悟を決められた由、敬意を表しまして、ぜひぜひ参考人招致を実現して頂きたいなと思いますね。

5月22日官房長官会見

朝日記者

国連プライベート権利に関する特別報告者が懸念を表明されたということですが、政府としてはどのような対応をとられますか。」

菅義偉

「まずですね、特別報告者という立場ですけども、これは独立した個人立場で、人権状況の調査、報告を行う立場であって、国連立場を反映するものではない。これは明確に申し上げておく。今回の書簡を受けてですね、政府外務省は、直接説明する機会が得られることも無く、一方的に発出したんです。この点、さらには同書簡の内容が明らかに不適切もの、でありますので、強く抗議を行ったという、行ってます。それと同時に、テロ等準備罪処罰法案名前違うよ)というのは、187の国と地域が締結する本条約締結するために必要国内法整備であってですね。プライバシー権利表現の自由を不当に制約するできる利用がなされるということはまったく当たらないということですを強く抗議したということです。」

情報提供を公開で求めるのは、特別報告者のマニュアル上認められている

下のマニュアルのII methods of work B. Communication 37に、基本的には、レポート掲載されるまでは機密扱いになるけど、特定事情特別報告者が、報告書より前に公開する必要があると判断すれば行うことができると書いてあります。なので、公開するのは全然問題ない。

 菅さん一方的な発出の部分ですが、どれくらい特殊な例なんだろうかと、ケナタッチ氏の場合は、ポスト歴史が浅いので記録がアーカイブされていないのですが、表現の自由に関する特別報告者のComments on legislation and Policyをつらつらと眺めてみると、

http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/LegislationAndPolicy.aspx

もうまったく普通に書簡最後に、この文書はこのウェブサイトで公開しますし、返信も同様に公開しますよ、というようなことが書いてあります。むしろ書いてないほうが珍しい。

アメリカの、宗教的属性で、旅行者スクリーニングをやることをみとめる大統領令に対しての書簡や、旅行者ソーシャルメディア情報を提出させる大統領令など、ドイツインターネット監視法律強化案に対するコメントでは

 最後にお知らせさせていただきますが、この書簡は、特別報告者の任務のために、公に利用可能とするため、ウェブサイト投稿いたします。

 貴国政府からの返信に関しても同様に、同じウェブサイト投稿し、また通常の表現に関する人権議会に提出する活動報告書にも同様に掲載させていただきます

 Finally, I would like to inform that this communication will be made available to the public and posted on the website page for the mandate of the Special Rapporteur on the right to freedom of expression:

Your Government’s response will also be made available on the same website as well as in the regular periodic Communications Report to be presented to the Human Rights Council for its onsideration.

というようなコメントが書かれています

 これに対して、アメリカイギリスドイツなどの先進国は、形式だけにしても「忠告してくれてありがとう、これこれこういう法律から大丈夫です。もしもっと疑問があったら答えるよ」とか「忠告には感謝しますが、現在議会議論している最中で、議会の決定は政府とは独立しているから現段階で、どういう内容の法律になるかは答えられません。もし内容が明らかになったらすぐに情報提供させていただきます」みたいな感じの丁寧な応答がされています

 また先日書いたInvestigatory Powers Billについては、コメントはありませんが、同様にすぐにウェブサイト投稿されています。こっちのほうが珍しいパターン

 理由を書いてある奴もたまにはあって、たとえば、中国インターネットアクセス規制に関するコメント(これが中国から見えるのかは気になるね)では

また私は貴国政府に、この法案に関する私の見解をすぐに公に示すことをお知らせいたします。このプレスリリースは、私が、貴国政府と、この問題の疑問点を明らかにするために、コンタクトを取っていたことを示すことでしょう。

I would also like to inform your Excellency’s Government that I intend to publicly express my views on the draft legislation shortly. The press release will indicate that I have been in contact with your Excellency's Government to clarify the issues in question.

まぁ中国だと、こういう意見表明がされたことを自ら発表することなんて無いだろうしね。中国レスポンスは「中国法治国家から大丈夫」見たいな感じで、西欧諸国のような修辞はないのが笑えた。

 んで、日本特別秘密保護法立法段階でのコメントで見ると

貴国政府の返答は、人権委員会判断を仰ぐために作成する報告書にも公開されることになります

今回の申し立ての重大性、緊急性を考慮しまして、今回の書簡の内容については、プレスリリースを行うこととすることも、貴国政府にお知らせいたします。

The response of your Excellency’s Government will be made available in a report that will be submitted to the Human Rights Council for its consideration.

Given the seriousness and urgency of the allegations, we would like to inform your Excellency's Government that we intend to issue a press release on the issues contained herein.

とこれも一方的に公開書簡を送ってるけど、このとき別に怒った反応はしてない。でもお得意の

意味するところが必ずしも定かではないが、」に類似した

いかなる情報に基づいた書簡かは明らかではないが、特別報告間が得られた情報は正確ではないwhile it is not clear what information the communication based on, the information which Special Rappoteurs obtained is not accurate.」を書いてますね。

https://spdb.ohchr.org/hrdb/25th/Japan_31.01.14_%281.2013%29.pdf

まぁ正直、文章の修辞的な意味での丁寧さの欠如具合が中国の例に近い。

んで今回のケナタッチ氏の書簡

最後に、立法段階が相当進んでいることに照らしまして、私の見解では、迅速な公共の関心が必要な事項である判断いたします。ですから私は、プライバシーに関する特別報告者の任務として、貴国政府に、本書簡を公開するとともに、ウェブサイト投稿すること、そして私の懸念についてプレスリリースをを行う準備をいたしますことをお知らせいたします。またこのことは、私たちと貴国政府が疑問点を明らかにするためにコンタクトを取っていたことを示すものであります。」

と書いているわけで、むしろ丁寧に理由まで書いているという意味では、通例に照らしてなんら失礼な文書ではないと思うわけですが、強くprotestしたということですので、文書の公開が楽しみでならないわけであります

さないけど、特別報告官の行動マニュアル

http://www.ohchr.org/Documents/HRBodies/SP/Manual_Operations2008.pdf

緊急提言として、通常の外交マナーにのっとらない行動もできるとか書いてあるけど、公開書簡はありふれてというか、少なくとも事後的にでも公開されるものは、迅速に公開されるので、まあUrgent Appealから公開だっていうわけじゃなくって、コンタクトを取ってる証拠として公開するから、ちゃんと答えてよ、ということでしょうね。これによると基本的には60日以内には回答することになってるけど、トランプアメリカとか、中国とかは1年、2年回答してないのもあるし。

特別報告者の法的ステータスについて

特別報告者としての活動による訴追等は受けない、逮捕拘禁もされない、書いた報告書は誰にも訂正されない、等々書いてあるので、まぁ特別報告者がただのprivate(私人)ちう意味での個人だというのは相当苦しいですなぁ。

http://www.ohchr.org/Documents/Publications/FactSheet27en.pdf

The experts carrying out United Nations human rights mandates

are legally classified as “experts on mission” in the meaning of the

1946 Convention on Privileges and Immunities of the United Nations.

While they are working on their mandates, the experts enjoy functional

privileges and immunities that are specified inter alia in article VI,

section 22 of the Convention. These include:

“a) Immunity from personal arrest and detention and from seizure

of their personal baggage;

b) In respect of words spoken or written and acts done by them in

the course of the performance of their mission, immunity from

legal process of every kind. This immunity is to be accorded notwithstanding

that the persons concerned are no longer employed

on missions for the United Nations;

c) Inviolability for all papers and documents;

d) For the purpose of their communications with the United

Nations, the right to use codes and to receive papers or correspondence

by courier or in sealed bags;

e) The same facilities in respect of currency or exchange restrictions

as are accorded to representatives of foreign governments

on temporary official missions;

f) The same immunities and facilities in respect of their personal

baggage as are accorded to diplomatic envoys.”


まぁ国連特別報告者の見解がいつもいつも正しいわけじゃないのは当然でしょうから疑義には正面から答えればそれだけですむのになぁという話。正直、「一方的に発出してー!」って切れられても戸惑うんじゃないかしら。他国の反応を見てみると。

2017-05-16

http://anond.hatelabo.jp/20170516144538

tex記法が使えなかった...

[tex: y = x^2]

としても

<img src="http://d.hatena.ne.jp/cgi-bin/mimetex.cgi?~y~=~x^2" class="tex" alt=" y = x^2">

中途半端に処理される

画像が埋め込めると増田が荒れるから無理なのかな

2017-05-10

ざっくり言いたい人へ

Hatelabo::AnonymousDiary

はてなはてラボはてな匿名ダイアリー


ざっくり言いたい人必見!
俺氏ライブドアニュースソースを公開へ

 2017年5月10日 14時25分



ざっくり言うと


 もっとみんなにもざっくり言ってほしい


 ソース公開したら良くね


 ド素人からきったねえと思うけど優しい目でみてね


ソースを読む













<p class="font-l"><b>Hatelabo::<font color=#4296A5>AnonymousDiary</font></b></p>

<p class="recentitem"></p>

<p class="font-ss">はてなはてラボはてな匿名ダイアリー</p>

<br>

<p class="font-ll"><b>タイトル</b></p>

<p class="font-ss"><font color=#2C4F99>■</font> <font color=#2CAAF0>■</font> yyyy年mmdd日 hh時mm分</p>

<br>

<br>

<p class="box-bg-gr">ざっくり言うと</p>

<br>

<font color=#4296A5>✓</font> 内容

<br>

<font color=#4296A5>✓</font> 内容

<br>

<font color=#4296A5>✓</font> 内容

<br>

<p class="box-bg-bl2"><a href="hoge">記事を読む</a></p>

参考文献: はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ

2017-04-09

去年から最近かけておれが執拗に見続けたyoutube(音楽)

気に入ったものを繰り返し見続けることがある。

一日に5回とか。それが数週間。

子供が気に入ったアニメ絵本をずっと見続けようとするのによく似てる。

まあ、そんな音楽です。


------------


JUNGLE FUNK

https://www.youtube.com/watch?v=0_JJqdWSJuA

リヴィンカラーリズムセクションの 2 人と Vinx のユニット jungle funk の曲 "TORN"。

ひたすら美しく切ない。

ウィンビッシュベースデリカシーのある美しいコード進行を多彩なパターンでメロウこなしているが、

ガっと行くトコはきっちり行ってて、甘さだけにならないのが本当にうまい

パーカッション(壺かな?)のオーガニックリズムが、控えめだけど強いビートを一貫して曲に与え続けている。

そして、歌とコーラスワークの美しさにおれの涙腺は何度でも崩壊するわけです。


ちなみに、エリックゲイルズがギターを弾くインストバージョンが下記。

これも良い。

ウィンビッシュが弾いてるところが見れるのがうれしい(凄すぎて何やってるかさっぱりだけど)。

ゲイルズはキャラは粗暴なのに美しいギター弾くよね。

John Page Classic Presents “TORN,” featuring Eric Gales, Doug Wimbish &amp; Will Calhoun

https://www.youtube.com/watch?v=WeefVD1668w


-------------


Chantae Cann All I do Cover Live HD

https://www.youtube.com/watch?v=i5liTAUdFHQ

最近あんまり参加してないっぽいけど、スナーキーピーの鍵盤の人として知られるコリーヘンリーライブ

見どころはシャンティカンの歌!歌!。スナーキープロジェクトでもよく歌ってるけど、それほど

アピールする歌い手には見えなかったんだよね。けど、こっちは本当に良い。

ちょっとチャイルドボイスで、べったり歌い上げる感じにならない乾いた感触ステキ

バックは結構いかつい演奏してるのに、そこからさらに2歩も3歩も前に出るパワーもさすが。

それこそ何度も聴いたけど、後半のロングトーンは何度聴いてもドキドキさせられる。


下のはたぶん同じライブの別な曲。これも上とセットでずっと聴いていた。

歌に加えてダルシマーソロもクセになる。

Cory Henry Plays Gnarles Barkley's "Crazy" feat. Chantae Cann

https://www.youtube.com/watch?v=xp8UCpHk-vk


-------------


North Mississipi Allstars - Turn Up Satan

https://www.youtube.com/watch?v=p1rLGrLAXQ0

NMA のブギ

一見何のひねりもないミドルテンポブギのようだけど、現代的な工夫が多く盛り込まれていて退屈させない。

逆かな?。今時のポップソング典型的ブギのリフを再利用して見せたのかもね。

いずれにしてもそうした要素を中毒性高くパッケージした NMA の手腕はさすが。

ギターソロ開けにリフに戻ってくるとこなんか立ち上がって踊りだしたくなる。

使い古された何の変哲もないギターリフが強烈な輝きを取り戻す一瞬と言って良いと思う。


ルーザーディッキンソンは本当にうまい人で、ブラックロウズのこの曲も執拗に聴き続けた一曲

後半のソロは何度聴いても胸に刺さる。

The Black Crowes - Oh Sweet Nuthin'

https://www.youtube.com/watch?v=lf9-BCix4io

2016-10-14

Bootstrapの div class="col-md-4" って font color="red" とどう違うの?

表示にの関係するclassって意味と見た目の分離も何もなくね?

classと別のstyleclassみたいな属性があってCSS適用させたいだけならそっち使うみたいにするのが理想

2016-10-02

http://anond.hatelabo.jp/20161002010827

インストール後、再起動はした?

MediaPlayer Classic が一緒にインストールされると思うけど、

そのソフトでも動画再生できない状況ですか?

2016-09-03

都会歩行プログラム @author 増田

/**
 * 都会歩行プログラム
 * @author 増田
 * @version 1.0
 */

public class WalkingTimerTask extends TimerTask {
    public void run() {
        if (片側寄り通行の表示がある) {
            // 駅構内通路階段などを想定
            表示に従って片側に寄って直進する。
        } else if (曲がり角進入までの距離 > 0 && 曲がり角進入までの距離 < 5メートル) {
            // 出会い頭の衝突時の衝撃緩和
            歩行速度を下げる。
        } else if (曲がり角進入までの距離 == 2メートル) {
            // 出会い頭の衝突防止
            曲がり角から離れる方向に1歩移動する。
        } else if (曲がり角曲がり中) {
            // 他レーンとの衝突防止
            円弧を描くように歩行する。
        } else if (曲がり角の曲がり終わり) {
            歩行速度を通常に戻す。
        } else {
            // TODO: 通常歩行時の減速および加速を段階的に行う処理を組み込む。
            左側を歩行する。
        }
    }
}

2016-07-30

http://anond.hatelabo.jp/20160730155428

悪い、昼間っからビール飲みだしたから、もうよくわからん

それをそのままってのが意味がよくわからんけど、

newしてから渡せば良いと思うよ。

いちいちクラスに分ける理由は、こういう感じで、クラス内の変数アクセスすれば、画面事の表示とかが簡単に出来る的な?

EventHogeクラスクリックした時のイベント定義するクラス

      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class EventHoge : View.OnClickListener {

        

        //画面事の名称

        public string ViewName = "";

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("画面の名前:" + ViewName); // 画面名称が表示されるイメージ

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }

MainHogeクラス(画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス

    // Androidなにも知らんけど、元増田ボタンイベントを書く処理が書いてあるクラスのことが言いたい

    public class MainHoge {

        // そのメソッド

        public void Main() {

            //ボタン実装サンプル

            final Button button = new Button(this);

            button.setText("ダイアログの表示");

            View.OnClickListener ocl = new EventHoge();

            ocl.ViewName = "画面その一";

            button.setOnClickListener(ocl);

        }

    }


こんな感じにすれば、画面が二つあって、

その画面の名称を表示するようなボタンを、二つメソッドコピペして作らなくていい的な?

もうぶっちゃけ元増田が何を悩んでるのか、ようわからんわ。

サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。

から、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか? とかを考えてこそ勉強だと思うよ?

今回のレイだと「View.OnClickListener」っていうインターフェイス実装したクラスを、setOnClickListenerすればいいってことさえわかれば、

匿名クラス?(っていうのかな? ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方)とかを使わずに、

どういうふうに応用ができるか? とか頑張れ!

頑張れ!

頑張れ!

はああああああ。

おれはビールを飲む!

http://anond.hatelabo.jp/20160730125112

うーん?

いや、なんか、通じてないな。

もうちょいサンプル詳しく書くからサンプルのどこがわからいか言ってくれ。

EventHogeクラスクリックした時のイベント定義するクラス

      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class EventHoge : View.OnClickListener {

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("サンプル");

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }

MainHogeクラス(画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス

    // Androidなにも知らんけど、元増田ボタンイベントを書く処理が書いてあるクラスのことが言いたい

    public class MainHoge {

        // そのメソッド

        public void Main() {

            //ボタン実装サンプル

            final Button button = new Button(this);

            button.setText("ダイアログの表示");

            button.setOnClickListener(new EventHoge());

        }

    }


こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。

元増田サンプルだと、メインの中でインターフェース実装したクラス実装を書いてるから、中とか外とかがあるんじゃないのか?

自分クラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数?の中で実装しなくてもすむじゃん。

http://anond.hatelabo.jp/20160730090832

よくわからん

中が嫌なら外でかきゃいいじゃん。

javaAndroidもしらんから適当だけど。

      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class Hoge : View.OnClickListener {

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("サンプル");

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }

// メインスレッド的なところ

//ボタン実装サンプル

final Button button = new Button(this);

    button.setText("ダイアログの表示");

    button.setOnClickListener(new Hoge());

こう書けば、中で書かなくて良い気がするけど、駄目なの?

なんか、インターフェースから引数の中ってのが意味わからん

どう関係してるの?

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-07-24

あるハンドルさんのまとめ

  • tuna.be
    • jyounetu.tuna.be

↑に「生きざまを見よ!」とあるので、見てみたら別の意味ですごかった。

いわゆる optimisation なのだろうかな。

ちなみに顔写真は↓

  • imagenavi.jp/search/detail.asp?id=10029493

スパム判定にかかるようなので、http 等は削る)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん