  |
はてなキーワード: うるおぼえとは
ずっと三浦春馬さんを応援してきた一人のファンとして、三浦さんが亡くなったショックは本当に大きい。
私は三浦さんと同い年で、初めて『キャッチアウェーブ』という映画で三浦さんを知った時からずっと応援していた。
熱烈なファンの方からすれば、かなりゆるい分類のファンになると思うけれど、私の可能な範囲で応援をしていた。
なかなか気持ちの整理がつかず、やめておこうとは思いつつも、無意識に幾つかの関連記事とはてブでの他の方のコメントなどを読んでいた。
そんな中、
https://news.yahoo.co.jp/articles/08dbce09c714f156828b07f2257e89fa170ae2c8?page=1
上記の記事に対してaceraceaeさんという方が下記のコメントをし星も沢山ついていたけれど、
https://b.hatena.ne.jp/entry/4688706332008341410/comment/aceraceae
私はツイッターもフォローしていたのでその時もリアルタイムで見ていたが、あの炎上は元々「国力」に反応した人よりも三浦さんが東出さんを擁護していると考えた人によるリプによる炎上が圧倒的だった。
確かに「国力」に反応し酷いリプを飛ばしていた人もいたが、寧ろ「国力」に関しては、それをピックアップしタイトルなどで煽り焚き付けたサイトなどの影響が大きかった。
このコメントに違和感を感じaceraceaeさんの事はよく知らなかったので氏の過去のブコメとタグを拝見した。
などのタグは大量にあり、「はてサ」に関しては300近いタグ付けしたコメントをしている。
勿論、内容は批判や罵倒する内容、党に関するコメントも批判ばかりだった。
その反面
などのタグは皆無。「自民党」はタグがあったが10数個の関連付けのみで、内容も擁護や自民を批判する側を批判する内容ばかりだった。
その上で再度、氏の「ちょっとした言葉遣いひとつですぐにネトウヨ認定する人達って存在するしそういう人達ってやたら攻撃的だからね。ちょっとした言葉遣いひとつですぐにネトウヨ認定する人達って存在するしそういう人達ってやたら攻撃的だからね」というコメントを三浦さんの死に絡めている姿は本当に残念でならない。
前述したようにあの炎上はどちらかというと東出さん擁護への批判や疑問からであったし、記事の内容も「国力」に関して分量は極わずかだ。
それにもかかわらず、aceraceaeさんはそこのみを取り上げ、自分の主義主張のため、「ネトウヨ認定する人（サヨク）」を叩くために三浦さんの死を利用する事に深い憤りを感じる。
少し前の木村花さんの死もあり、芸能人へのいわれなき誹謗中傷への警鐘として一見するとまともな意見のように読めるし、それは正しい。
しかし、その裏に見える自分は他の人へ同じことをやっているのに無自覚、または自覚していても、棚に上げて人を攻撃する姿勢は酷い。
aceraceaeさんは他のコメントで三浦さんの死を悼んでいるし、それ自体は嘘ではないと思う。
しかし、「ちょっとした言葉遣いひとつですぐにネトウヨ認定する人達って存在するしそういう人達ってやたら攻撃的だからね。ちょっとした言葉遣いひとつですぐにネトウヨ認定する人達って存在するしそういう人達ってやたら攻撃的だからね」は明らかに三浦さんの死を利用した。
aceraceaeさんの過去のコメントからはちょっとした言葉遣いで、簡単にサヨクやはてサ認定し攻撃しているがそれは良いのだろうか？
もしSNSなどでの過激な言葉での攻撃が彼の死に少しでも関係していると思ってい（思っていなければわざわざそのようなコメントはしないと思う）、彼の死を悼むのならばaceraceaeさんは自分の過去のコメントをもう一度読み返し、自分の攻撃性に自覚的になるべきだろう。
https://b.hatena.ne.jp/entry/4688706332008341410/comment/lady_joker
には本当にその通りだと思うと共に、休校が解除されたあと学生の方が拳銃で自ら命を絶った事を思い出す。
その際に、名前を忘れてしまったがブコメで多くの星を獲得していた方のコメントがあった。
みたいな内容だったと思う。
休校明け、元々彼が不登校で今は不登校の子向けの通信制学校い通ってる事からそう考えたのかもしれないけれど、あまりにも安易に人の死の理由を決めつける人たちにはおかしいとさえ感じた。
それがどの程度彼の死に関わっていたかは分からないし、他のあまたある要因や複合的な要素の結果、本当に学校が嫌という理由だけで亡くなったのかもしれない。
ただ、それを学校へ行く事が嫌で亡くなったと決めつけるコメントと星をつける人の多さに落胆する。
lady_jokerさんのコメントの通り、わかりやすいストーリーに落とし込むのは良くないと思う。
だが、lady_jokerさんのコメントにも星をつける反面、「死を選ぶくらいなら、無理に学校行く必要はないよ」へにも星をつけたり同じような決めつけをしている見覚えのあるブッマーカーが何人かいて、なんとも言えない気持ちになる。
しかし私自身も無意識に関連記事を読み、心のどこかで彼の死の理由を知りたいと考え、ストーリーを組みあげ彼の死を納得できるものにしたいと考えている自分にも気づく。
僕が先週買ったCDは、「俺はたまにガンジャを吸ってる ていうかそこらへんの山に生えてる」（本文まま）と歌っていたり、昔の反省をする歌でも「ガンジャと女でマジでいかれてたぜあの頃は」（うるおぼえ）みたいなことを歌っていて、僕は、「おまわりさん、この人です」と、聴くたびにいつも思う。
しかし、今日昼休みに、世界最高峰のディスカッションコミュニティであるところのはてなブックマークを眺めていると、全然別の話題であるが、その話題に、盗んだバイクがうんたらかんたら、とコメントがついており、それを見て、気づくことができたのです。
「盗んだバイクで走り出す」と歌った尾崎豊は、しかし窃盗罪で逮捕されることはなかった。それどころか、その曲は今でもTV番組のSEとかで頻繁に流れるし、名曲とされている。ここから、音楽の歌詞ではなにを言ってもフィクションであることが担保されていることが分かる。
極端なことを言えば「オレはいつか北朝鮮製の超ドープなスーパーデューパーミサイルを首相官邸のケツの穴にクールにブチ込んでやるぜ」と歌詞に書いても、逮捕されることがないのだ。すごくないかそれ、音楽の力はすごいなーー。
これは http://anond.hatelabo.jp/20110316202255 の続編です。
GTをやる前に改を書いてくれている人がいてとてもしっかりした内容なのでちゃんと勉強したい人はそっちを見てね！
d:id:ryoasai:20110317 - ドラゴンボールで学ぶオブジェクト指向 改 | 達人プログラマーを目指して
またオブジェクト指向については
d:id:m-hiyama:20080109 いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ | 檜山正幸のキマイラ飼育記
がとても詳しいです。合わせて読むとかなりしっかりと理解出来ると思います。
ホットエントリに行くとは思っておらず、皆様ありがとうございます。
「ドラゴンボールをオブジェクト指向にする」というコンセプトではなく、「オブジェクト指向を（無理矢理）ドラゴンボールで説明する」という遊びだったので
プログラマーの方々にはツッコミを受けてしまいましたがここは遊びだと思って楽しんで下さい…。
ドラゴンボールは小さい頃から大好きでしたが流石にうるおぼえ過ぎました。
それはさておき「説明する題材を決める→好きな漫画から無理矢理当てはまりそうな例を考える」という思考実験なので、気が向いた方は色々考えてみると楽しいと思います。僕は楽しかったです。
これは難易度が高そうです。
やっぱりドラゴンボールで例えると分かりやすいな！
無理がある！
デザインパターンとはドクターゲロが考えた「こうやって設計すれば色々捗るぞ」という例のことです。実際はGoFという人たちが考えたもので23個のよくあるパターンに名前を付けて整理してくれたわけですね。
23個の中にはブルマさんですらわからないものが多いので（さすがドクターゲロですね）良く使う、代表的な物をいくつか紹介します
Singletonは世界に一つだけしか存在出来ないようにする方法です。
balls = new DragonBalls(); //これでは誰でもドラゴンボールを作れてしまう！ balls.callShenron();
クラスの中にはいくつかのメソッドがありますが、簡単に言うと外から呼べるもの、外からでは呼べないものの
二種類があります。そうやってメソッドを保護することで世界の崩壊を防ぐわけですね。
基本的な戦闘力をアップさせるには本人の努力が必要になり、外から簡単に挙げられてしまうとジャンプの三本柱が外れてしまいます。
ただナメック星の最長老や界王神などはかなり偉いので、本人の才能を引き出すことが可能でした。
現実には思いつきのような仕様を後から言われることが多々あります。困ります。
//地球上にひとつだけ存在するドラゴンボールをつくろう class DragonBalls{ private DragonBalls(){ //ドラゴンボールを作れないように生成メソッドを保護します。 } static function sagasouze(){ static singleton_dragonball; //ドラゴンボールを生成。 //DragonBallsクラスの中なので、保護してある「new DragonBalls()」を呼べます。 if(!singleton_dragonball)singleton_dragonball = new DragonBalls(); return singleton_dragonball; } }
地球のみんなは地球語しか話せませんが、ナメック星にいるクリリンを通して願いを叶える必要があります。
クリリンももちろん地球語しか話せませんが、ナメック語を話せるデンデがいるため、地球のみんなは願いを叶えることが出来ます。
class Kuririn{ private dende = new Dende(); function request( wish1, wish2, wisth3){ this.dende.request(wish1); this.dende.request(wish2); this.dende.request(wish3); } } kuririn.request( "ピッコロを生き返らせてくれ", "ピッコロをナメック星へとワープさせてくれ", "ナメック星にいる孫悟空とフリーザ以外を全員地球へとワープさせる" );
この場合のメリットはデンデが何をやっているかクリリンをプログラミングした人が知る必要が無いということです。
地球の人はナメック星にいるナメック星人が「デンデ」であることを知る必要もありません。
それでも願いは叶うんです。
本来であればデンデやクリリンは願いが叶うのを待つ必要がありましたが、地球の人は一気に伝えることが可能なように設計しました。
//デンデクラス。ナメック星人は英語でNamekianらしいです。 class Dende extends Namekian{ function translate(word){ namekian = *****//ナメック語に翻訳します。 return namekian; } function request(wish){ static polunga; if(!polunga){ polunga = DragonBalls.spell("タッカラプト ポッポルンガ プリピット パロ"); } polunga.ask(this.trasnlate(wish)); } }
大まかなアルゴリズムだけ決めておいて、実装はサブクラスに任せる設計がTemplate Methodです。
ナメック星に行く方法を考えた時いくつかの方法がありました。古い宇宙船を探してきて直して載せて…っていちいち書くより同じメソッドでナメック星に行けたほうが便利ですね。
abstract class WayToNamek{ abstract function prepareSpaceShip(); abstract function launchSpaceShip( ship ) ; function gotoSU839045YX( people ){ ship = prepareSpaceShip( ); //船を修理します ship.load(people); //人を載せます this.launchSpaceShip(ship); //船を出発します。 } }
ナメック星に行く方法を定義したので「ブルマ、クリリン、悟飯」組と「悟空」をそれぞれナメック星に連れて行きましょう。
way = new WayWithKamisamaShip(); way.gotoSU839045YX( buruma, kuririn, gohan ); way = new WayWithSaiyajinShip(); way.gotoSU839045YX( goku );
と簡単に方位SU83、距離9045YXまで乗員を連れて行くことが出来ます。
二つの方法を実装します。神様の船を修理して行く方法と、サイヤ人の船(悟空が乗ってきた船)で行く方法の二つです。
//神様の船で行きます。 class WayWithKamisamaShip extends WayToNamek{ function prepareSpaceShip(){ return new KamisamaShip(); //船を準備します。神様の船を使います。 } function launchSpaceShip(ship){ ship.inputByVoice("ナメック星に出発"); // } } class WayWithSaiyajinShip extends WayToNamek{ function prepareSpaceShip(){ return new SaiyajinShip(); //船を準備します。サイヤ人の船(フリーザの船？)を使います。 } function launchSpaceShip(ship){ //audio = new HighSpecAudio(); //ship.setAudio(audio); ship.turnOnCenterButton(); //真ん中のボタンを押すだけ } }
元になる船も違いますし、発射の仕方も違いますが同じ呼び出し方が出来ます。
オーディオの位置が決まりませんでしたが、今回の運用では不要とのクライアントからのご意見でしたのでだったので
せっかく用意したオーディオも無駄になりましたが、コメントアウトしてあります。
寝る前にいくつか返信。
http://anond.hatelabo.jp/20080902220835]
たぶんそうだと思う。
http://anond.hatelabo.jp/20080902221735]
でもほら、ダイアリーの立ち上げ当時は似たようなもんじゃないかと。
同様の意見としてb:id:hatayasanとかb:id:ululunとかb:id:nakano87とかb:id:te2uとかね。元記事にチェックボックス案もmetaを使う前提でチェックが off なら head に件の meta を入れる
って書いてあるのになぁ。リテラシーって大事だ。
そっちの仕様は別にいいの。自社サービスの機能を使うのにmetaを本文に書かせるのがダメ。
b:id:masayc 技術力を期待してはてな使ってる人ってどれくらいいるんだろうね？俺は、日本”語”でweb2.0ごっこしたいだけで、もし英語が達者ならdiggとdelicious使うけどな。
日本語のWeb2.0ごっこなら、私が唯一中期間使った例で申し訳ないけどドリコムブログの方が優れてた。使ってたの数年前だけど(今はWP)。例えばデザイン編集画面で、ブログの2or3カラムレイアウトに表示する要素をDnDで並べ替えたりとか。DHTMLすげーって感じ。
はてなはWeb2.0の特徴の一つと言われてるマッシュアップとかがろくにできない。はてなのデータを外で使うための機能は多いけど、外のサービスとかをはてなに持ち込めない。Blogパーツ、裏技使わないと自由に貼れないでしょ？
2.0っぽさではてなよりも劣ってるサービスってあんま無いんじゃなかろうかと。むしろ往年のWeb日記の仕様を引きずってるし、メジャーバージョンは1。Web1.9。
b:id:xevra 技術的には指摘の通りだろう。だが経営的にはこれが正解。なぜなら一覧非表示機能を希望し、文句言ってくる人は0.01%程度。この程度のものにリソースは割けない。完璧を求めるのは趣味の領域。jkonは正しい。
今は一覧非表示機能に限った話してないんだけど。上の方のアレもそうだけど、非表示絡みでコメしてる人は何故かピントが合わない。
例えばブログモード使ってる人ってけっこう多いけど、彼らは絶対に記事毎に編集やコメント管理できた方が便利。トラバ先を記憶する機能ってそんなに開発リソース必要ですか。大した事無い機能変更にもがっつりリソースを割かないと改善できないのが問題。
まぁでも確かに、現在のはてダの低い技術ポテンシャルという前提の下では、jkonは正しいね。
b:id:ghostbass なんだって？？テーブルの変更なんか必要ないけど？
そうなんですか。考えてみます。思いつかなかったら勉強してみます。Boromさんの案が正解かも。
b:id:EvilGood おそらくそうなんだろうけど、小手先回避なんだろうとは思うが、さきざきサーバーの処理能力が上がって、すべて記法解析でやった方が速度出る日が来そうなんだよな。はてなはXMLDBとか検討してるんだろうか？
はてなが未来を見据えてそういう拡張をしてきたのか、という点はさておき、すべてを記法でやろうとすると記事の編集時の可読性が下がります。本文にmetaとか記事見出しなのに何故か本文にあるとかトラバ送ったかどうか解らないとか。
ユーザーの快適性とか開発の柔軟性とかを犠牲にしてまで、未来の鯖速度を追求するというのはなかなかどうも、説得されないです。
さらに追記。
b:id:skicco はてな記法でごまかしてくれたおかげで、他のブログサービスではできない重複したカテゴリへの登録ができてる。これが可能なのってはてダくらいじゃね？
最近のブログサービスは知らないですけど、WordPressではできます。ところでカテゴリってリストから選べないと Typo りますよね。
ごめん、年1000万の間違いだったかも。倍近く違うじゃん。malaさんが入社したてのころにどっかでこういうの書いてた。うるおぼえ。
b:id:kana-kana_ceo 「普通なら、日記の編集フォームに一つ『ブクマページでブコメを表示する』というチェックボックスを付ける。チェックが off なら head に件の meta を入れる」← なんで、非表示がデフォなんだろう？
一人くらい勘違いする人がいるとは思ってた。非表示がデフォなんて書いてない。デフォでチェックが on にしてあればおk。
チェックボックスのラベルは肯定文で書くのが UI の Tips。「非」表示は否定語。
b:id:al001 "少なくとも"技術力の問題では無いと思うが。面倒とかそういうのであれば分かるけど。 / チェックボックスでオンオフ出来るだけで良いなら、DB弄らずともJavaScriptだけで出来る。
まず後半。またまたご冗談を。クライアントサイドの解決法じゃ meta が body の下にある事は変わらなかろうて。パース後に動かすつもり？
そういや手元で試してみたら、 Firebug でソースを見ると body 内の meta も head の下にあったものとしてパースされるね。
前半は、他の人も同様の事言ってますね。要するに費用対効果の話。
でも、面倒
=費用が高くついてるのはシステムの出来が悪いから。スパゲッティーを紐解きたくないんでしょう。
ブコメ非表示みたいなおそらくほとんど使われないような機能だけがこうやって糞仕様存置されてるってんなら、経営判断って意見も説得力がありますね。
http://blog.livedoor.jp/dankogai/archives/50979976.html
試訳 - コードをセキュアにする10の作法
セキュアとかいまだに和製単語がないの……？ 根付かないわけだわ。
この10の作法みてても、まるっとただのwebコーディングの話しなのであまりピンとこなかった。
つーか、なんか、ほんとはてブってLLな人ばっかりだよね。
せっかくの内容なので、ちと裾野を広げて考えてみたよ。
どのような操作をうけつけるのか、どのようなデータをうけつけるのかまず最初に決めましょう。
そして受けとったものをもとになにをしたいのか明確になっているのはもっとも重要なことです。
お金のかわりに注文をうけるだけなんていうのもありますよね。
まず最初に決めておくのが重要なことです。
1で決めたように挙動の想定なしには規定外のデータの受け渡しなどは追うことができません。
想定内以外はすべて想定外に落とすのが悪意から身を守りやすいです。
構造的エラーはtryで括るなり、error procでおとすなりし、
構造エラーが起きたときにどこでどのようなエラーが起きたのかは最低限いつでも追えるようにしましょう。
（PHPとかでtryつかってるひといる？）
3匹の子豚の童話をおもいだしてください。
ドアには鍵をかけられるようにして、暖炉には火をともせるようする必要があります。
そしてなによりその前提は建物が頑丈であることです。
その場所に狼が住んでいるのかいないのかは家の設計に大きな影響を与えます。
また狼がいるのがわかったら家を建てる必要があるのか吟味するのはとても重要なことです。
社内のLANで済ませれるシステムをわざわざon Webな設計で建てる必要はありませんよね。
部品が増えれば大工さんの工数は増えますし、住んだあともお掃除が大変です。
家を建てるのにいくら掛かるのか？
そのサイズの家を建てたら家政婦さんにはいってもらわなければならないのか？
家政婦さんがいいのかメイドがいいのか？
庭師をいれなければならない大きさなのか？
警備員を雇わなければいけないのか？
自宅警備員はやくにたつのかたたないのか？
お財布と相談するのは非常に重要なことです。
本当は1Kで十分なんじゃないですか？
見栄はときに判断を見誤らせます。
もしあなたが建てるのを手伝う側だとしてもお客さんを諭すのは大切な仕事です。
家を建てるまえにその地域にすんでみるのも必要です。
甘い言葉に騙されていきなり30年のローンとか抱えないでください。
完成例ばかりに目を奪われると完璧なものばかりに目がいき真似したくなります。
もしあなたが商売を始めようとして、そこに経験がなかったらどうしますか？
路面店を構える前に自転車の後ろに商材つんで売ってみてからでも遅くはないのでは？
最初からすべてを用意しようとすると取り返しがつきません。
「だってみんなやってるよ！」
そういったときに親からなんていわれたか思い出しましょう。
規模に応ずることは非常に重要なことです。
システムキッチンをつかったこともないのに新しく建てようとする家に入れたいのはどうしてですか？
ほんとうに自分にあった家をたてたいのであれば、まずはあれこれ使ってみることが重要です。
あなたのつくった木造の小屋がもし火事になった場合どのような被害を出すか考えておく必要があります。
どんなに頑丈な設計をしていたとしても、地震や台風、放火など”ありえない”なにかの災害はおきうることです。
そのときにあなたのつくったものはどうなりますか？
まわりの建物に火がまわってしまいませんか？
危険というものはすべてを排除しようとするのは困難です。
もしもの時にそなえる方法はいくつかあります。
火災保険にはいるだけではなく、消火器などを用意して被害を最低限に抑えるということも重要になります。
数千円の消火器で家の全焼が防げるならコストパフォーマンスは悪くないですよね。
Hedgeとassessmentは別々(並列)にもうけることができる性質のものです。
ヘッジばかりで満足していませんか？
あと、風の強い日に焚き火をしないとか、そういうわきまえも大切ですよね。
(risk deterって言葉ないね？ こーゆーのなんていうん？）
割られてしまった窓ガラスはさらにわられないために早めに直しましょう。
できるだけ早く「対応した」と見せかけるだけで大きな効果があります。
次なる悪意から身を守る術はできるだけ早い対処です。
検収さえのりきって瑕疵責任だけまぬがれるような糞システムねじこんだらいいやとおもってるから、いつまでたっても糞なんだよだぼがぁあ！！
・・・ゴホン。
失礼しました。
つくったものは古くなります。
建物の場合だってニスを塗り替えるだけで経年劣化は相当防げます。
そのために既成関数などをラップ関数に差し替えて最初に書いておくのも実はメンテナンス効率をあげる手段だとおもいます。
全財産を引き出しに入れておくとか、そういうことはしてはだめですよ。
個人情報だってそもそも集めなければ取られる必要がありません。
不必要なものを保持しておくのは初期費用も保守費用も莫大に押し上げます。
使用用途ができてからでも遅くはありません。
部屋を綺麗にしておきたいなら要らないものは買うな！！
(部屋汚くてごめんなさい……。)
成功例、失敗例、参考にするのは非常に有意義なことです。
ですが、その意味もわからず模倣することほど意味もなく危険なことはありません。
あなたがだれかの真似をして飛ぼうとするまえに、自分の足元を確認する必要があります。
でも自分と他人というものは違います。
相手がどんなものであれ、それをもとに自分を磨かなければ意味がありません。
また相手がどんな体験をしたのであれ自分を磨くことの役に立てることはできます。
人のせいにするのは簡単な事です。×××でよんだから、×××で見たから。
でも、そもそもこの記事だって猫が偶然キーボードの上で暴れて書いたものかもしれないのですからニャー。
日本円を受けるところでインドルピーうけてちゃレートもわからなければ偽札も区別できないよ！
リスクアセスメント（リスクアクセスメントだと思ってたのは内緒）
いいえケフィアです
みんなってダレ？
ヨソはヨソ、ウチはウチ。
全焼
火の用心！
いいえ、あなたの心です
他山の石
