 
|
はてなキーワード: トリッキーとは
ハマちゃんと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割とかそれくらいの実力しか出せないなどと言われるが，そのギャップを埋めるためにも練習試合はどんどんやるべきである。試合でしか分からないこともあるだろうし，試合の中で編み出される技術というものもある。試合においては練習でしたこと以上の挑戦は控えるべきという人もいるが，本番試合は最も経験値を稼げるいい機会だ。余裕があるなら色々試してみるのもいいだろう。
サーブルはやったけど，特に活躍できなかったので一つだけ。サーブルは「切れる」競技だけど，実際突く方が早いので，手首とか顔面を突くのが相手の意表をついて良いだろう。
意味がわからんね。
誰もトリッキーなコードやコードゴルフが絶対悪い滅すべきなんて言ってないし、
「遊び」や「芸」としてはそれなりにやられてるのを知らないのか。
そういうので競うためのサイトがあったり、
わざと難解に書いたコードでネタプレゼンやって賞賛されてたりするのに。
本当にそういう価値観に憧れてるんならそのくらい調べてきなよ。
てか、「可読性が高いコード」が賞賛されるのは「成果物としての」コードに関しての話だろ。
「プログラムを書くこと」ではなくて「プログラムを書いて何かを作り出すこと」を目的とした場合の価値基準だろ。
それに異を唱えたら「アホか現場の苦労を知れ」って言われるのは当然で、
それに対して「現場のことなんか一切興味がない」って返しは筋違いだろ。
あとね、「可読性の高いコード」を「愚直」とか言うのって、
「写実的な絵画など面白くもなんともない、ピカソを見ろ！あれこそが芸術だ！」って言ってるような感じがする。
ピカソ絵すげー上手いし写実的な絵も書けてこそのあの絵なんだけどなぁ、それで芸術語っちゃうんだ、みたいな。
最後に言っておくけど「トリッキーなコード」と「スパゲティーコード」は別物な。
「何故君たちは街中にゴミを撒くのを止めてしまったんだ！ゴミに復権を！」
「なにをふざけたことを言ってるんだ。誰が掃除してると思ってんだよ。」
「いや、僕が言ってるのは街を美しく飾る、利用価値のある、素敵なゴミの話であってですね…」
「それはゴミじゃねーだろ。」
などとタイトルをつけてはいますが、どんなことが起こっているのかを説明するつもりはさらさらありません。あしからず。以下のお題に投稿するには余りに長くなったので、勝手ですがこちらを借りました。
上のようなお題がハイク内で立てられ、ちょっと盛り上がったので、以下、全力で釣られてみます。
既にいくつか指摘のあるとおり、表意文字としての漢字を日本語から引き算して表音文字としてのひらがな／カタカナへ統一することは、朝鮮半島でのハングル使用が少なくない同音異義語を産出し混乱を招いている現況と同様の事態を引き起こすだろうマイナスの側面がある。
漢字の使用によって抑圧される弱者として日本語を母語としない外国人を想定するのなら、その弱者の補助ツールとして各種翻訳サービスを挙げることができようが、ひらがな／カタカナのみで表記された文章の翻訳は、日本語において多量に存在する、しかし漢字による表記で区別可能な同音異義語を、前後の文脈から判断して行わなければならなくなる事態を引き起こす。現在の提供されている無償の翻訳サービスですらまともなものではないのに、余計に使えないものになるだろう。
弱者として視覚障害者を想定するのであれば、視覚障害者と晴眼者の差異、視覚障害者の能力が障害と見做される由縁は、「読む」ことと「聞く」ことにおける「読む」ことの利便性に他ならない。ここで、書記言語から口語言語の優位性を説くのであれば、文字を拒否するという極端な姿勢もあり得ようが、一方では、漢字の使用をやめたところで、「読む」ことと「聞く」ことの差異が縮まるというものではないことも容易にわかる。漢字の不使用に「わかちがき」の使用を追加したところで事態は変わらない。ところで、書記言語から口語言語の優位性が説かれるときに、今度は聴覚障害者や構音障害者が抑圧されているかのようにみえるのは、一体どういうことだろうか。
あるいは、単に漢字の読みがわからない、また付随して意味がわからない者を弱者として想定するならば、キッズ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人以上でやるならルールを作れ。
話しはそれからだ。
可読性の高いソースコードが良いコードとされるに至ったのは、一体いつ頃からであっただろうか……。
その結果、何が起こった？
難解だが愉快なスパゲッティコードは悪となった。呆然とさせられるあの遊び心に満ちたトリッキーコードは悪となった。感動のコードゴルフもまた悪手とされた。
プログラミングとしての技巧的なものに取って代わって、より安易なコードを書くことが良いこととされるに至った。よりテクニカルな、たった一行にも知識と労力を要するコードよりも、誰にでも読めるようなコードが良いとされるに至った。
じゃあ、ぼくらプログラマを志すものは、一体何がしたかったんだ？ ソフトウェアを作りたかった？ 断じて否！ あの考え抜かれたコードの中に美と情熱と思想とを感じ取り、それに憧れたんだ。愚直なコードに誰が感動しよう、誰が憧れよう！ 誰にでも作れるようなソフトウェアでも構わない、他の誰にも書けないようなあのコードを書いた人々と、そのコードに憧れたんだ。それを解読できる人々に憧れたんだ！
そしたら、
というTBをもらった。
どうやら、無知は恥ずかしい、というタイトルにした方が良かったのかもしれない。
サブタイトルが暗に示すように、対話では論理的である必要は必ずしも無い。
その理由を示す。
しかしながら
だから、論理だけを使って何かを証明することができなくもない。
だけどもだっけどー、通常の対話では完全な証明を与える必用は無く
「説得」という形をとるのだ。
じゃあ、説得とはなんなのか？
人間は外部から情報を与えない場合には、「演繹」という論理ステップしか実行できない。
一方で外部から情報を与えると、「帰納」という論理ステップを実行することができるようになる。
ただし、この「帰納」というのは統計的な正しさしか保証しない。
しかしながら、人間が定理だと信じていることは、全て統計的な正しさしか持っていない。
これによって、件の命題の真が統計的に保証されれば、説得が終了したことになる。
つまり、本来は論理的である必要など無く、
外部からの情報を入れれば、あとは各自で演繹してくれればいいのだ。
もちろん、数学のようにピンポイントな仮定と、トリッキーかつ複雑な論理が必用な場合は別である。
だけれど、そんな複雑な論理構造が通常発生することはまずない。
説得が成功するかどうかは、各自の持つ公理系と、各自の持つ論理能力に依存する。
後者は、馬鹿を相手にする気がないので、私にはどうにもできないが、
前者に対してはわかりやすい説明をすることで、
説得力を増すことができる。
従って、これからはこの目的で、説明文を書くのでよろしく。
だけど、これから用事があるので
続きが読みたかったら、ＴＢくださいね。
http://anond.hatelabo.jp/20070615171101
俺は大学四年まで全くきちんとしたプログラミングをやったことが無くて(大学の講義でJavaの超簡単なのを教わったぐらい)で、卒論でプログラミングをしなくちゃならなくて、そのとき初めて Ruby を触った。
Ruby は OOP ですげーんだぜ、とか一部で云われていた時代で、有名なアプリケーションは tDiary ぐらいしかなかった。はじめはクラスとかも解らずに何が何だか。そのとき tDiary のプラグインはクラス使ってないから簡単に書けるよ、というどこかのチュートリアルをみて見よう見まねで。GD という画像ライブラリを使ったら、サンプルをちょっと弄るだけで画像が作れて面白かったんだ。で、それを日記で公開してみた。今見返すとものすごくしょぼいソース。
そのときたまたま Ruby ハカーの方がそのプラグインをリファクタリングしてくれて、クラスを使って抽象化してくれて、初めて OOP をほんの少しだけ理解して、こうやってクラスって使うんだなぁというのを知った。本当に運が良かった。
その後就職して仕事で php ハカーのすごい先輩にいろいろ教えてもらって php を使って基本的な OOP は理解した(PHP を DIS る人が多いけど、プログラミング初心者には良い言語だと今でも思ってる)。これまた運が良かった。
その後またまた Ruby を使い始めたら今までよくわからなかった部分もするする頭に入ってきてホント面白ろくて没頭して。今では一通りのことは Ruby でできるようになった。
プログラミングが解るなら、Rails のソース(トリッキーなことやりまくってるのでつらいかも。ActiveRecord や ActiveSupport はその中でも解りやすい)を読んで、解らなかったら rubygems で興味のありそうなライブラリのコード読んで、あたりが OOP と Ruby 覚えるには手っ取り早いかも。
今なら Rubyレシピブック 268の技 と Rubyクックブック ―エキスパートのための応用レシピ集 あたり読んでおけば良いんじゃないなぁ。
あと今はてダで Ruby を含む日記を書くともれなく ruby-dev な人たちがキーワードからたどって読んでくれるので、解らないことをつぶやいたりすると結構答えてくれるみたい。のではてダ使って勉強日記とか書くのも良いと思うよ。
とあんまり参考にならないと思うけど書いてみた。なんか目的見つけられて、楽しく覚えていけたら勝ちなんじゃないかな。たぶん。
いくつか考えられるな
まず、if で書いた方が可読性が高い、という考え方。まあでも一行で書いてもすぐわかる以上はよっぽどのアホが入るかも知れないプロジェクトで考慮するようなことでしかなくて、まして短文合戦、トリッキー合戦になってるこの話題においてこの理由を持ち出すのは微妙だな。
次に、Java では一行にまとめる慣例があまり無い、と考えているから。確かに Java の場合、簡単な内容であっても C のマクロほど頻繁には一行にまとめないと思う。そもそも C のマクロみたいに関数へのジャンプのコストが無くなるという利点も無いしね。それでも if ぐらいは削ってもいいと思うが。
まあ元のコードが一行にまとまってないからそのままにしただけで、最後に C のマクロなら一行にするような内容だわな、と思って一文書き足して、コードは書き換えずそのまんま投稿、ってのが一番可能性高いとは思うけど。
こういうの書くのはお寒いかもだが、あれは半分ネタで半分本気です。増田は滅多に使わないけど、いろいろ意見が聞けて良い。それはともかく
あるあるｗ自動変数についてはどう名前付けても良いと思います(常識的な範囲で)。
はい。
自分は8タブです。誰がなんと言おうとｗ三項演算子は使いどころを間違えなければいいんだけどね。自分もJavaScriptを弄くり回していた頃、トリッキーなコードを書きまくってました。
K&Rスタイルですね。
CやC++ではハンガリアン記法は有効だと思いますが、ゆとりプログラマですのでｗPython自体はあまり好きじゃないけど、IronPythonはホントに面白い。
新しい行に中括弧を置かないというのは、秀丸のアウトライン解析を利用するためでもあります。でないと正規表現が書けないので。