  |
はてなキーワード: トリッキーとは
そんな小保方博士は、ねつ造だなんだとたたかれたので、実験手順を公開した。
確かに、突っ込みどころを見つけたくなるようなセンセーショナルな内容だし、図だって言われてみればなんだかなあ、という感じの論文。
しかしだ。
私が思うに、彼女は神の手の持ち主かつ非常に自分の手の動きに敏感だから、こんなトリッキーな研究ができたんだと思う。
彼女は「ピペッティングの刺激が細胞のストレスになるから、幹細胞ができる」と判断したから、ここまで研究を進めた。
これはtwitterで歩弥丸さんが言及していらっしゃるが、尋常ではない。
https://twitter.com/hmmr03/status/428738964174819328
ではなぜ尋常ではないのか？
それはおそらく、自他ともに認めるずばぬけた実験の正確さと、すばぬけた手の動きへの敏感さが小保方博士にはあるからだろう。
「ピペッティングの刺激が細胞のストレスになる」という判断はおそらく、
・ピペッティングがマイルドだったときは幹細胞化した細胞が少なかった
・ピペッティングが粗暴だったときは幹細胞化した細胞が多かった
ではピペッティングをしてる人にお聞きしたい。
・多少の指の力や、ピペッティングのスピードや丁寧さを加減することができても、各操作の力やスピードの違いを覚えているだろうか？
・その違いを数量化して、実験結果に照らし合わせられるだろうか？
・さらにその違いを比べて議論できるほど、精度の高いピペッティングを普段からできているか？
ちなみに私はどれにもいいえと答えますｗｗｗ
皆さんはどうだろう？
私は使えない人間なので外れ値なんかも知れないが...
もし彼女のような感覚と手腕が多くの研究者にあれば、そうとう生命科学は進歩するだろうなあ。
というわけで、そこまでの人間はめったにいないので、ほかの人が再現するのが難しいんじゃないのか、という気もする。
今、日本を舞台にしたSLGを作っているのだが、
改めて思うのは、日本列島をゲームにした時のMAPの完成度の高さだ。
舞台の中央に大きな島があり、
マップの端に大・中・小の島が１つずつというバランスの良い配置。
このおかげで、ゲームの初心者は四国の小さなマップスタートから慣れてもらい、
徐々に大きな島へとステップアップしていってもらう事が出来る。
そして一番大きな本州の形は円形ではなく、南北に細長い形状になっていて、
比較的何処からスタートしても生産地（注：敵に触れていない土地くらいの軽い意味合いです）が作りやすい。
この形ならば、若干の有利不利はあるかもしれないが、
２０１年劉備や、Civマルチプレイパンゲアど真ん中のような
圧倒的な不利な状況にはなりにくい。
しいて言えば長野・岐阜・滋賀・奈良あたりが
地形上厳しそうに見えるが、
長野・岐阜は周りの山岳が、滋賀は琵琶湖がトリッキーな防波堤になるため、
下手な関東の平野よりも守りやすかったりする。
トリッキーと言えば、その豊富な地形変化も大きい。
こんな狭い島の中に富士山という高い山があり、琵琶湖という大きな湖があり、
瀬戸内海という内海があり、平野もあれば、樹海もある。
それが自然な形で配置されており、非常にバリエーションに富んだ舞台を作成してくれている。
自然という事でいうならば気候の変化もそう。
南北に長い為、北は大雪、南は台風と、舞台によって気を配る事が違ってくる。
さらに時系列でいっても夏に責めるのが有利な地域、冬に責めるのが有利な地域と変化が出て、
自分のスタート地点によって千差万別の戦略が必要になってくる。
しいて言えば、マップサイズにもよるが、
北海道・九州・四国の位置がさほど本州と離れていない為、
海戦の重要さが薄いマップになってしまいがちだが、
まあ、これもマップサイズを大きくすれば、問題は解決する。
このように、日本列島はゲームの舞台としては
驚きの完成度を秘めているのだが、この地形が自然に出来たのだから恐ろしい。
マップデザイナーが四苦八苦して作るマップよりも変化に富んで
バランスの取れたマップがすでに私たちの足元にあるのだ。
きっと神様は相当なゲーマーだったに違いない。
自分もプログラム勉強したての頃はそんな感じだった。自分は特にオブジェクト指向のあたり意味がわからなかったなあ…。
どちらも同じ先生で、質問してもそのうちわかってくる！って言われるからそうか…ってほっといてるけど、
言語の詳しい説明はいつになったら理解できるようになるか不安になる。
最初は「おまじない」として書いてても大丈夫。要は、動けばいい。
でもプログラムをずっと書いてるとそのうちもっとトリッキーなことがやりたくなってくる。そのときに嫌でもどんなことなのか知らなきゃいけなくなる。そういうのを繰り返してちょっとずつちょっとずつ知らないうちにぼんやりしてた概念が身についてくる。
こういう概念ってわかってる人には説明できる。でもわからない人に説明するのは用語の面でも概念の面でも難しい。一神教のひとにアニミズムの考えを理解してもらうような…（ちょっとちがうか）。だから教える側も最初は「おまじない」が限界なんだよね。
プログラムの自習は自分が作りたいものがあるとか作らざるを得ない状況だとかじゃないと課題を見つけるのが難しいかも。でもとりあえず今は習った範囲でできることをいろいろ試してみてごらん。macがあるなら試しにiPhoneアプリ作ってみてもいい。作り始めるといろいろ必要になるから勝手に勉強しちゃうよ。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
コンビニにふらっと出かけて、なんか炭酸系の飲みたいなーと思って手に取りました。
炭酸系で定番以外のものって大概地雷で、最終的におかしのまちおかとかで30円ぐらいで投げ売りされているタイプなんだけど、これは結構好き。
飲むとホップの香りがふわっとして、ほのかな甘味と超微炭酸。この手にありがちなうえってなる後味がなくすっきり。
米発酵エキスやらが入っているのと、ホップの香りが入っているのとでお酒が好きな人は好きかもしれない。
ただ、二日酔いの状態で飲むと香りでうっときて吐いてしまうかも。
ハマちゃんとTKの15年くらい前の曲、モトカノが好きだったんだ。
俺30モトカノ35。
6年付き合って、その内の3年間は一緒に暮らして、その内の2年間は俺が欝でヒモになってて。
付き合った当初、25にもなってもまともな社会人ではなかった俺をここまで導いてくれた。
付き合って2年後くらいに欝になった時に一緒に住んでくれて支えてくれた。
俺のことを大切に思ってくれる女性はもう他にはうちの母やんと婆やんくらいしかいなんじゃないか。
それも分かってたけどフってしまった、更に上を見てしまった、欲が出てしまった。
恋人として見てほしかった、結婚したいと一緒に思ってほしかった。
もうお金は返してくれたんだからヒモ時代はなかったことにしよう、とか言ってほしくなかった。
近くにかわいそうな人がいたから助けたと言ったけどそれが嫌だった。
そんなに気にするな、ということを言いたかったんだと思うが、
俺にとっては「恩を受けたからその金額を返して終わり」じゃないんだ。
これでチャラになったとかそういうのじゃないんだ。
俺はずっと今のままは嫌だった、次に行きたかった。
ステップアップかどうかはわからないけど、引越しなり結婚なり今までより大きな決断を一緒にしたかった。
いや、別に結婚も引越しもしなくても良い、ただ、あなたの人生に俺がいるんじゃなくあなたと俺の二人で一緒の人生を歩みたかったんだ。
それは確かにリスクかもしれないし、それの定量的な意味や価値はわからないんだけど、
あなたとだけは理屈抜きでそうしたかった、俺にとってあなたは唯一理屈抜きに一緒に考えたい相手だった。
更に言い訳する。
俺の欝は甘えだった、4年前の当時あなたはいつも甘えじゃなくこれは病気だと言っていたが、俺の欝は甘えだ。
診断書も出されて薬も飲んでたけどアレは欝じゃない、病気じゃなかったんだ。
確かに当時の職場はブラック企業だったかもしれん、でも全ては俺の甘い性格が招いたことだ。
そして、そんな俺をあなたが隣で叱咤激励してくれたから、俺はまともになれた。
あなたのおかげで何も考えずにダラダラと生きていては駄目だと分かったんだ。
あなたと別れずに一緒に無双したりHAGEX話で盛り上がったりしながらとりあえず付き合っていくことも出来たけど、
考えて考えてクリティカルな決断をしていくことで俺はまともになれたんだから、今になってまた決断をせずにいることは出来ない。
俺にとってそれは昔への逆戻りなんだ、仕事はしてるし給料も月40近くまで増えて貯金もできたけど精神的にはまた元に戻ってしまう。
それが怖いんだ、すごく怖いんだ、元に戻るのがすごく怖いんだ。
もうあなたに迷惑かけたくなかったんだ。
彼は真面目そうで誠実そうで朴訥としていて、俺とは違って全くトリッキーではなかった。
35の女子を、とても世話になった女子をフッた罪悪感から逃れたかったから見た夢かもしれない。
でも、でも幸せになってほしい、あなたのことだからやっぱり彼氏はいらないと思ってるかもしれない。
たまたまGoing Going Homeを聞いて色々と思い出した。
この1ヶ月間、胸に溜めてたものを出したよ。
もう勝手に選曲されることも一緒に歌うこともないけど、、、
もうないけど、ないけど、ないんだけど、、、がんばるよ。
可読性が悪いにもほどがある・・・と思った１関数
http://blog.livedoor.jp/dankogai/archives/51490675.html
inline U64 powmod(U64 base, U64 power, U64 mod){
return base ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: power ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: mod ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: powmod_64(base, power, mod);
}
３項演算子を連打とか・・・
if(base ＞= UINT_MAX){ return powmod_gmp(base, power, mod); }else if(base ＞= UINT_MAX){ return powmod_gmp(base, power, mod); }else if(mod ＞= UINT_MAX ){ return powmod_gmp(base, power, mod) }else{ return powmod_64(base, power, mod); }
って事で、要するに
if(base ＜ UINT_MAX ＆＆ power ＜ UINT_MAX ＆＆ mod ＜ UINT_MAX){ return powmod_64(base, power, mod); } else { return powmod_gmp(base, power, mod) }
って事じゃないのか？実際Cは左辺優先評価で１つ目がFALSEの場合２つめ以後は評価されない（してはいけない）でelseにジャンプ だからif演算の回数だけなら等価
まぁ、確かに、パイプラインを考えればthen節とelse節は等価ではないので、データによって真ん中の書き方のほうが下より早いとか遅いという差はでるけど・・・
なくても、真ん中か、下の書き方でいいよなぁ。
まかり間違って
if(base ＞= UINT_MAX || base ＞= UINT_MAX || mod ＞= UINT_MAX){ return powmod_gmp(base, power, mod) }else{ return powmod_64(base, power, mod); }
と書いても、おそらく、コンパイラ先生がただしく最適化してくれればおなじになるだろう。正しく最適化しないと、コレは遅い可能性もあるが、そんなことはまず無いだろう。
いや？演算子が悪いとは言わないけど、チーム組んで初級の若いプログラマがこういうコードを読めるとは思わないし、読む必要があるとも思わないんだが・・・
ジェネリックに、みんなに分かりやすく。
トリッキーに書くのもいいけど、それは、速度かメモリかで恩恵が受けられる場合で、メリットがないなら、初心者でも読みやすく、メンテしやすくする。って間違ってるのかなぁ？
？連打の方が世の中読みやすいのか？
どうでもいいけど・・・UINT_MAX って、最大値＋１じゃなくて、最大値だよなぁ・・・。確か＞=の＝の有り無し逆じゃね？
もっと、どうでもいいけど、mmレジスタとxmmレジスタのmod演算ってクロック数違うんだっけ？だれか、教えて。ifでパイプライン崩すのとどっちがいいんだろう。
某県の某高校で，何年か前にフェンシング部に所属していた俺が，高校生活2.5年をかけて会得した技術を書いてみる。
というのも，あれからフェンシングに関わることなく過ごしてきたせいで，せっかく汗水流して会得した知識が，どんどん頭から消え去ってしまっているので，ひとまずここにまとめてみる。といっても別に大した成績もろくに残しちゃいないんだがね…。初心者とか現役フェンサーで初心者に毛の生えた程度の高校生が，ちょっと暇つぶしにでも読んでくれて，なおかつ参考にでもしてくれれば本望です。ちなみに，ルール改正前だから，振り込みとか，ばんばん使ってました。あと，用語は適当に使っていたので，細かいところは勘弁してくれ。ここではフルーレを主に解説して，オマケ程度にサーブルについても書いた。
短い（速い）ファントと，長い（遅い），伸びのあるファントね。前者は相手の反撃が期待される時，もしくはコントルアタックを予期した時など，わざと隙の小さいアタックをして相手の反撃を誘い，それから攻撃権を得て攻撃できるメリットがある。具体的にはピスト端に追い詰めての最初からコントルリポスト狙いのアタックなど。手数を用意した攻撃もこれの組み合わせがいいだろう。長いファントは隙が多すぎるので，あまり使わない方がいい。疲れるし。長いファントは，その伸びがメリットだが，初心者はただ遅くなりがちなことが多いからだ。闇雲に打つと疲労の原因になって自爆しちゃうから，相手より早く動けないうちは，相手を追い詰めて短いファントで仕留めよう。ただ，スピードが加算されてきたらこのファントは一発で仕留めるのに有効になる。振り込みと組み合わせてもいいし，ただ突くのもいい。オススメはオクターブ。これはガチで，カルトなんぞいくなら最初からオクターブ狙いでいった方がいい。フェンシングは相手の意表をつけ，というのが俺の師匠の言った言葉。まあ問題はその攻撃範囲にたどり着くまでなんだが…。
何が言いたいかというと，初心者は短いファントを主軸にしつつ，長いスパンでスピードのある長いファントをものにして，最後には使い分けようということ。
パラードはいつからか完全に払ってから攻撃するという習慣が身についてはいないだろうか？思い出して欲しい，攻撃権を得るためには，審判にわかるように相手の剣を払う動作（バッテ）をすればいいということを。相手の剣を音がするくらいの小さい力でちんと叩くだけでいいのだ。そのほうが隙も小さいし，動作も素早い。大きな振りがフェンシングでは致命的なのはお分かりと思う。あとパラードは攻撃が来てから，では遅いと思う。攻撃が来そうな時を把握して，来た瞬間に叩く位が調度いい。懐近くまで剣先が来てからでは遅いのだ。これからは来てから払うでなく，相手の攻撃に先行して攻撃権を取るように防御をして欲しい。ちなみにこの最小のパラードは時に振り込みの餌食となることがあるが，大きなパラードで防ぐのも，相手に付け入らせる隙を与えるようなものだ。これは後に書くコントルパラードで対処をするなどした方がいい。パラードで隙を作るな，である。
大多数の人が使うデフォルトのパラードはカルトパラードだと思う。したがってカルトパラードに対するフェイクと，そこからのアタックがまず最初に練習されると思う。つまりいかにデフォルトとしてのカルトパラードを崩すか，に焦点がおかれることが多い。つまり，デフォルトのパラードをちょっと変えてやるだけで，相手のいつもの技が通じない，という状態にでき，大きなアドバンテージを得ることができる。そこでおすすめするのがコントルパラードである。時計回りに回すアレである。あってたかな？まあとにかく，コントルパラードで全て引っ掛ける，単純ながら大きな効果のある防御をしよう。円の大きさは意外と大きくても隙が小さいので，オクターブに来たアタックでさえ引っ掛けることができる。しかもそれが攻撃権取得に有効であるから，万能である。見た目はカチャカチャ汚くなるが，キレイな防御をしろなどというルールはどこにもない。海外の選手を見てみればいい。
ここで話しているいくつかのテクニックは，相手と同等か，もしくはより早く動けることを前提としている。つまり相手のアタックを見極めて叩いたり，逃げながらコントルアタックができたりするのは少なくともその瞬間は相手より早く動けることが必要なのだ。相手の突進を受けるにも，スピードを変えながらフェイクをするにはこちらには余裕がなければできないことだ。だから，よく足を鍛えることをおすすめする。
コントルアタックは「逃げ」の行動として時にタブー的な指導を受けることがある。確かにフェンシングでは攻めの姿勢が重要視されることが多い。しかし，相手の意表をつく，という俺の勧める戦法で言えばコントルアタックは実に有効な攻撃の手段だ。それにコントルアタックが得意であれば，相手の攻撃の抑止力ともなりうる。コントルアタックはいくつか種類があるが，どれもコンスタントに使えるのがいい。まあそのシチュエーションに適したのがあるだろうが，同じ技は次は効かない，という心構えで繰り出そう。個人的におすすめなのは，相手が突進バカみたいなやつ（剣先を大きく外すなど，胴体ガラ空き君）に対して，突いてからすぐに引くやりかたである。名称は悪いけれどしらない。初心者だと，こういう追い詰め型に苦戦することがあると思うが，このコントルさえマスターしていれば怖くはない。特に日本ではコントルアタックタブーな風潮から，相手の意表をうまくつく有効な技として活躍すると思う。概して初心者のフェンシングでは変な攻撃パターンに苦戦しがちであるが，それぞれの攻撃法に対する，攻略法を学ぶことも大切である。柔軟な戦法も大事だが，こういう奴にはこの型のコントル，こういうヤツにはひたすら攻める，などお決まりの対処をするのも，下らない戦法に苦戦してぐずぐずするよりは何倍もいい。
つまり，カルトフェイントからオクターブ，シクストフェイント（振り込み）からセプティムへなど，上半身へのフェイントから下半身に深く突き込む戦術で，相手の意表をつくという点で有効である。下を突くのは必ずしも長いファントである必要はなく，フェイントをうまく使えば短いファントで十分に脇腹を突ける。ただ，攻撃後はすぐ戻るか，そのままもつれ込む形にするなど，失敗した時の対処も考えておくのがいい。ちなみにこのフェイントの回数は1回にとどめておくのが言いだろう。2回なんて器用なことできやしない。
先程解説した，相手の突進に対処するやり方である。あいてのプレパラーションにびびってただ下がれば，当然ピストの端に追い詰められ，仕留められるのがおちだ。なので，下がるときにも相手の剣をバッテする，ボディフェイントで相手をビビらせる，コントルアタック（突き逃げ・ダッキングなど織りまぜて）をするなど，単純に逃げるのはお勧めできない。そこに戦術・戦略があれば別であるが，下がって下がってリポスト，というのはあまりにも攻撃権がないターンで無力すぎる。ただ，相手のファントの伸びやスピードがある場合，相手の攻撃範囲に入らないように注意すべきだ。あえて入り，攻撃を誘うにしても，こちらの動きが相手より速い必要がある。下がってリポストなりしなきゃならないからね。だから，さきほど言ったように相手よりスピードの面で上回っている事が重要なのだ。
これは攻撃の戦術で，プレパラーションやフェイントの動きと，二番目のアタックの動きを変えることである。縦というのは，剣先を大きく動かすプレパラーションや，クーペのフェイントのことであり，横はというのは剣先をくるくるとしたり，小さな動きのプレパラーションや，デガジェのフェイントのことである。この，異なる動きの組み合わせが相手の意表をつき，うまくアタックが決まることが多い。大きく動いてあまり見えなかった剣が急に小さなフェイントを繰り出す，もしくは頻繁な小さなフェイントをしていた剣先が急に姿を消す，というのはされる側にとっては嫌なものだ。この原則を覚えて，実践で試してみて欲しい。
単純な技。ステップを使いながら攻め，ピスト端近くに追いつめたところで，相手に攻撃をするぞ！と二歩迫る仕草をして一歩下がるのを２回繰り返す。相手は２回目くらいでこないのか…？と思うので，３回目で攻撃をする。コツは２回のフェイントでは力を入れていかにも攻撃をする姿勢をつくり，３回目は急にスピードを落とすなりして，あきらかに戦意をなくしたフリをしつつ迫ることだ。そうすると３回目に相手は誘われて単純にアタックをすることがあり，そこに合わて突いてやるだけでいい。なぜなら攻撃権がこちら側にあるからである。
これも一つの技的なもの。ピストの端に追い詰める前にファントをうつ。あーあ届かなかった…的な感じでルミーズしつつ，そのままの姿勢でフレッシュに持っていくと相手の意表を突ける。
気持ちで勝った方が試合にも勝つ。お願いします！と声を出し，相手の目を真っ直ぐに見る。
個人的にはビスコンチがオススメ。振り込みしやすいし，手首が自由に動く分接近戦で有利。
プレパラーションや，普段の姿勢は常に動くようにする。剣道より動きに幅のある分，相手に動きを読まれないように心がけたい。コツはステップをふみつつ剣先も揺らしておくこと。攻撃に入る瞬間をフェイントでごまかすようにするとよい。
これまでちょこちょこ解説してきた意表をつくこと。つまりトリッキーな動きや戦略を積極的に用いよう。フェンシングはリポストやファントを100回練習したところで試合に勝ち進めるとは限らない。それよりもルールを熟知し，技を考え出し，トリッキーに振舞う，頭を使う方が有効なことが多い。特に高校生から始めたフェンサーは技術的に経験者より劣るところが大きいので，人がやらないようなことを積極的にとりいれつつ，相手と同じ土俵で戦わない戦法をするのがいいと思う。ファントの速いやつにファントで挑んでも負けるのがオチなのは明白だよね。あと相手にあわせて戦法を変えるのも重要。リーチの長い相手に遠くからちょこちょこやってもうまくいかないだろう。特に背の高い相手に対しては剣先をいつもより高めにして上をカバーし，ステップを多めに使って懐に飛び込むのが有効だったと思う。
いくら形の練習をしたりルールの勉強をしたところで，実際に試合で勝たなければ意味がない。古来の剣術においても，試合で使われる複雑な技よりも，単純で気迫のある攻撃のほうが意外と有効であったりしたらしい。技に溺れず，本当に役に立つ技を磨き，試合で十分に扱えるようにならなければ意味がない。あと本番では練習の8割とかそれくらいの実力しか出せないなどと言われるが，そのギャップを埋めるためにも練習試合はどんどんやるべきである。試合でしか分からないこともあるだろうし，試合の中で編み出される技術というものもある。試合においては練習でしたこと以上の挑戦は控えるべきという人もいるが，本番試合は最も経験値を稼げるいい機会だ。余裕があるなら色々試してみるのもいいだろう。
サーブルはやったけど，特に活躍できなかったので一つだけ。サーブルは「切れる」競技だけど，実際突く方が早いので，手首とか顔面を突くのが相手の意表をついて良いだろう。
書こうね、って言ってたのはどこのどいつだよ…
1: 全然コード規約に従ってない -- ok 100歩譲って、規約は口約束だからまぁそこまで気にするな、ということを認めても、だ。script/***/foo.js は .apply を使うスタイルじゃなかったの…？
2: open/close principle に全然沿ってない。これ、どうやって拡張するの？押し付けてきたこのコードだと、僕の問題は全然解決できないんですが…
ライブラリと呼ぶからには、
a) めんどくさいことは全部透過的に解決
b) インターフェイスは極力簡単に
意味がわからんね。
誰もトリッキーなコードやコードゴルフが絶対悪い滅すべきなんて言ってないし、
「遊び」や「芸」としてはそれなりにやられてるのを知らないのか。
そういうので競うためのサイトがあったり、
わざと難解に書いたコードでネタプレゼンやって賞賛されてたりするのに。
本当にそういう価値観に憧れてるんならそのくらい調べてきなよ。
てか、「可読性が高いコード」が賞賛されるのは「成果物としての」コードに関しての話だろ。
「プログラムを書くこと」ではなくて「プログラムを書いて何かを作り出すこと」を目的とした場合の価値基準だろ。
それに異を唱えたら「アホか現場の苦労を知れ」って言われるのは当然で、
それに対して「現場のことなんか一切興味がない」って返しは筋違いだろ。
あとね、「可読性の高いコード」を「愚直」とか言うのって、
「写実的な絵画など面白くもなんともない、ピカソを見ろ！あれこそが芸術だ！」って言ってるような感じがする。
ピカソ絵すげー上手いし写実的な絵も書けてこそのあの絵なんだけどなぁ、それで芸術語っちゃうんだ、みたいな。
最後に言っておくけど「トリッキーなコード」と「スパゲティーコード」は別物な。
「何故君たちは街中にゴミを撒くのを止めてしまったんだ！ゴミに復権を！」
「なにをふざけたことを言ってるんだ。誰が掃除してると思ってんだよ。」
「いや、僕が言ってるのは街を美しく飾る、利用価値のある、素敵なゴミの話であってですね…」
「それはゴミじゃねーだろ。」
などとタイトルをつけてはいますが、どんなことが起こっているのかを説明するつもりはさらさらありません。あしからず。以下のお題に投稿するには余りに長くなったので、勝手ですがこちらを借りました。
上のようなお題がハイク内で立てられ、ちょっと盛り上がったので、以下、全力で釣られてみます。
既にいくつか指摘のあるとおり、表意文字としての漢字を日本語から引き算して表音文字としてのひらがな／カタカナへ統一することは、朝鮮半島でのハングル使用が少なくない同音異義語を産出し混乱を招いている現況と同様の事態を引き起こすだろうマイナスの側面がある。
漢字の使用によって抑圧される弱者として日本語を母語としない外国人を想定するのなら、その弱者の補助ツールとして各種翻訳サービスを挙げることができようが、ひらがな／カタカナのみで表記された文章の翻訳は、日本語において多量に存在する、しかし漢字による表記で区別可能な同音異義語を、前後の文脈から判断して行わなければならなくなる事態を引き起こす。現在の提供されている無償の翻訳サービスですらまともなものではないのに、余計に使えないものになるだろう。
弱者として視覚障害者を想定するのであれば、視覚障害者と晴眼者の差異、視覚障害者の能力が障害と見做される由縁は、「読む」ことと「聞く」ことにおける「読む」ことの利便性に他ならない。ここで、書記言語から口語言語の優位性を説くのであれば、文字を拒否するという極端な姿勢もあり得ようが、一方では、漢字の使用をやめたところで、「読む」ことと「聞く」ことの差異が縮まるというものではないことも容易にわかる。漢字の不使用に「わかちがき」の使用を追加したところで事態は変わらない。ところで、書記言語から口語言語の優位性が説かれるときに、今度は聴覚障害者や構音障害者が抑圧されているかのようにみえるのは、一体どういうことだろうか。
あるいは、単に漢字の読みがわからない、また付随して意味がわからない者を弱者として想定するならば、キッズgooなどの検索先ページへの仮名振り機能は強力なツールとして既に存在しているし、オンライン辞書ツールなどの使用による「学習の啓蒙」がなされて穏当、かつ然るべきではないか。
また、補助ツールを用いずに弱者への配慮をhtml/xmlで記述されたページ内で完結させることを考えるならば（大体、html/xmlで記述されたページがメディア＝媒介なのだが）、例えばhtml/xmlはruby関連タグを備えているが、投稿においてタグを使用できないはてなハイクの仕様が抑圧的だという見方もあり得よう。しかしながら、これは視点を変えれば、タグを使用することができない弱者への配慮でもあることは付記しておくべきだろう。
それどころか、ruby関連タグはxml1.1でようやく認められるに至ったのであり、この点でいえば現状のhtml/xmlが抑圧的であるという判断すらあり得よう。引き算の態度を貫徹するのであれば、漢字を拒否する前に、はてなハイクでの、いや、ネット上の書き込みを拒否する態度というのも、ひとつ考えられよう。あるいは、html/xmlにおける扱いについて問題の多い日本語の使用をやめて、問題の少ないラテン系言語の使用に踏み切るという態度もあり得よう。
話は変わるが、歩道に敷かれている視覚障害者用の点字ブロックがいかに妥協の産物であるか、病院等の公共施設で採用されるユニバーサル・デザインがいかに試行錯誤の、過渡の形象であるか、ということに目をやるのが良い。そこに横たわる根幹的問題のひとつは、弱者とまた別の弱者の利害不一致である。漢字の排除が同音異義語の混乱を招くという形式は、弱者とまた別の弱者の差異を捨象するという形式と相同的なのである。これは、弱者とまた別の弱者の双方に潜在する、共通する性質を汲み取り問題解決へ向かわんとする繊細な作業――それは、不十分とは言え、点字ブロックやユニバーサル・デザインを産み出す過程で行われている作業である――とは全く相反した暴力的行為に他ならない。ユニバーサル・デザインが足し算の思考であるとは、確かに足し算の部分も引き算の部分もあるだろう。しかし、足し算と引き算しかできない小学一年生であれば、最小公倍数と最大公約数の思考の部分についてわからないのも無理はない。
さらに、より根本的には、スピヴァクが古典『サバルタンは語ることができるか』で指摘したのは、サティー（寡婦殉死）の実行者を被抑圧者としてカテゴライズすることだったが、スピヴァクはそれを決して否定したり退けたりなどしていない。外部の視点を持ちこんで、ある彼／彼女を被抑圧者として規定すること、これこそが抑圧以外の何物でもないが、しかしこの規定によって被抑圧者を被抑圧者と認識し、被抑圧者たる彼／彼女に語りかけることが、彼／彼女の身になって考えることができる。抑圧なしのユートピアなど幻想である。抑圧なしのユートピアがお好みならば、まずもって「私」という拭い切れない自己同一性を捨て去ってみればよい。想像はできる。「お前」と同定されることのない、「私」を「私」と呼ぶことのできない、抑圧なしのユートピアがそこに拡がっているだろう。まさに、「サバルタンは語ることができない」。かつてフーコーが打ち出した『魂は身体の牢獄である』
という、一見したところトリッキーなテーゼに込められていたかもしれない苛立たしさには、同意するに吝かではない。この種の原初的抑圧の暴力性には敏感であるべきだし、しかし、しばし躊躇いながらも、この暴力から笑いを産み出す昇華の方法を探るべきなのである。この昇華は幻想ではない。理不尽に突き付けられた、尽きることのない、終わりのない、仕事だからだ。
僕が何を言いたいのかというと、お題ができたら全力で釣られて、あーでもないこーでもないと盛り上がり、次第に飽きては、パロディ化して派生した別のお題で盛り上がり――そんな楽しいところがはてなハイクです。
――落ち込むこともあるけれど、私は元気です
――
偏差値 59
政策関連も少々勉強する。
E.L.H. Electric Lover Hinagiku
偏差値 63
人が傷つく事とはどういうことなのかを学ばされる。
毎週、非コミュと非モテを救う方法をレポート10枚分提出しなければならない。
偏差値 75
近代思想は必修科目で、これを受けていないと講義の内容がわからない。
犬派は基本的に入学できない。
入試は面接試験一本勝負で、猫の魅力について40分間喋り続けなければならない。
偏差値 77
人生を通じて役に立つ知識を持つことができる。
偏差値 44
4年間を通じて毒舌に耐える忍耐力を鍛えることができる。
他人を罵るためのコミュ力も高まる。
そして、表面的な罵倒用語に惑わされずに本質を見抜く眼を養うことができる。
卒業すると、「消毒液処理」という免許がもらえる。
偏差値 54
制度や技術について、人に流されない姿勢を持ち続けることの
id:magician-of-posthuman教授
偏差値 73
「ポスト○○」や「魔術」等のキーフレーズで釣りを書くこともあるが
ただし、分厚い長文の教科書は持ち歩くことができないくらい重たいので、
教室用と自宅用とで二つ以上は購入しておく必要がある。
怠けたはてブコメントを書くと退学処分になる。眉毛が太いと合格率が上がる。
偏差値 75
偏差値 63
2学年に進級すると、「oredoco」という科目が必修になる。
3学年になると、「はてブの魅力」という科目が必修になる。
誰も思いつかない奇をてらったマッチョ論や、
応用すれば、どんなところでも役立つtips。
偏差値 64
1年まではオタク文化論の基礎を学ぶ。
2年になると、揉め事の分析が主流になる。
ぜひとも受講しておきたい。
偏差値 34
全ての問題をメンヘラの問題として対処する実技を学ぶ。
ただし、メンヘラの問題としてしか対処できなくなるので、
いくつか考えてみた
(問1)高階関数と再帰関数を必ず使って数値を要素とするリストの要素の総和を求める関数を書け。ただし高階関数を使うという要件と再帰関数を使うという要件は同じ関数で満たしてもよい。
(問2)二つの引数をとり二つのうち大きいほうを返す関数と高階関数、再帰関数をつかって数値のリストの最大値を求める関数を書け。ただし高階関数を使うという要件と再帰関数を使うという要件は同じ関数で満たしてもよい。
というのは簡単すぎるか？簡単すぎるなら
(問3)高階関数と再帰関数を必ず使ってある数値に5を足し、10かけて2で割った数を求める関数を書け。ただし高階関数を使うという要件と再帰関数を使うという要件は同じ関数で満たしてもよい。
こっちの方がいいかな。でもトリッキーすぎる気もする。
一応問題を出したので、SchemeとPythonで自分で想定している答えを書いておいた。はてなではSchemeが人気のようなので、あまり知らなかったけど関数言語ではSchemeで書いておいた。Pythonで書くのはSchemeだけだとわかりにくいので、なにかスクリプト言語で書いておこうと思ったから。Rubyの方が人気なので、はじめはRubyで書こうと思ったけど挫折した。だれかRubyで書いてくれないかな・・・。コードオブジェクトってなによ。というか関数はオブジェクトなのに引数にできないの？なんで？（以下疑問と愚痴の嵐なので略）Perlは古株が多くてユーザー数も多そうだけど、・・・その・・・無理です・・・。あの言語仕様はやる気がしない。ぶっちゃけ理解できない。Pythonを知らないひとは多そうだけど、知らなくてもSchemeよりは感じは掴めると思うのでPythonでも書いておくことにした。
http://anond.hatelabo.jp/20071110215936
http://anond.hatelabo.jp/20071110220132
これで大部分のひとがこの問題に興味をもたなくて解答するひとがいなくても、興味を持ったひとは安心だね！
追記：
問3で次のは無しとしておきたい。
(define continuous-apply
(lambda (lst obj)
(cond
((null? lst)
obj)
(else
(continuous-apply (cdr lst) ((car lst) obj))))))
(define plus5
(lambda (num)
(+ num 5)))
(define times10
(lambda (num)
(* num 10)))
(define divide2
(lambda (num)
(/ num 2)))
(define plus5-times10-divide2
(lambda (num)
(continuous-apply (list plus5 times10 divide2) num)))
(plus5-times10-divide2 2)
def continuousApply(lst, obj): if lst: return continuousApply(lst[1:], lst[0](obj)) else: return obj def plus5(num): return num + 5 def times10(num): return num * 10 def divide2(num): return num / 2 def plus5_times10_divide2(num): return continuousApply([plus5, times10, divide2], 2) plus5_times10_divide2(2)
スパゲッティはうまかろうがまずかろうがスパゲッティなんだ。本来トリッキーなコードこそ環境や状況が生み出した「やむなし」とされるべきものなんだよ。平易な表現に置き換えられるものを無意味にややこしくして楽しんでるのは"奥が深い症候群"の連中じゃないか？
プログラミングの楽しさはまず書いたものが動くことだろう。
スパゲッティに美しさはない。
難解だが愉快なスパゲッティコード
こないだこんなのがあったんだぜ？
というような話題話しにはできても、愉快だったためしは一度もない。
助けてくれ！というどう考えても死亡フラグのヘルプに駆けつけたことがある。
某メーカー子会社だ。コードスタイルを見るに多分以前はコボルとかをやっていた連中だと思う。
コードを見てこれほど唖然としたことはない。
言語は…なんだったかな…時代的にaspだったような気がする。
コードを見て泣いた。functionのひとつもありはしない。
一晩の徹夜の後、3000行あったコードは300行になっていた。
難読すぎてスパゲッティーを解いた結果がこれだ。
何か機能を盛り込み忘れたのではないのかと目をゴシゴシした。
10人ぐらいをつっこんで数十の主要なコードを直した。
目をごしごしして２日間の貫徹だ。
成果物はなぜかボリュームが減っていた。
普段だったら絶対に許されない修正方法だが、
緊急に緊急を要したためコードを見てからの説得はかなり強引だった。
ただのスパゲティは修正するのがムリだと判断したからだ。
このプロジェクトを進行した連中の無駄な努力をただ恨みながら。
自分のところのメンバーであんなコードを生み出されちゃ適わない。
他の協力会社にもずいぶん口うるさくいうようになった。
君が苦労して実装しているところは既に＊＊が＊＊で実装している。
こういうだけで相当数工数が稼げた。
部品にしておけばみんながそれを利用できるからだ。
1人で組み上げるならいくらトリッキーでも構わない。
2人以上でやるならルールを作れ。
話しはそれからだ。