  |
はてなキーワード: Radとは
前回に引き続き今回はカラオケにおける振る舞いについて書いてみる。
ちなみに筆者は20代中盤で、同世代くらいの相手を想定した記事となっている。
これを読むことで、皆の合コンライフが少しでも豊かになることを祈る。
最初に強調しておきたいのは、合コンにおけるカラオケというのは歌が上手い奴がドヤ顔するための場所ではない。
むしろ、どんなに歌が上手くとも毎回ラブバラードを入れまくるような男は合コンに呼んではいけない。
理由としては、合コン参加者全員が歌が上手いなんて可能性はほぼないのだ。
それにも関わらず誰かが自分の歌の上手さを見せつけるためだけの歌を歌っていると、
自分の歌唱力に自信がない、特に女の子は気後れしてしまい会全体に気まずさを感じてしまう。
わかったら手元にあるミスチルだかエグザイルだかのバラード全集を投げ捨てろ。
また、一人で一曲を通じて歌い切るよりもマイクを回し合うなどしてみんなで盛り上がれ。
大事なことなのでもう一度書くと、カラオケで選ぶべきはみんなが楽しめる曲だ。
基本的にはみんなが知っている、歌える曲が望ましい。
デュエット曲は合コンに相性が良く、男性デュエットも自分ばかりが歌っている印象を抑えることができるし、
男女デュエットは共同作業感を出すことができて仲良くなりやすい。
周りにことわりを入れた上でその子に向けてそれを歌うことは有効な一手だ。
ただ、歌があまりに下手な場合逆に好感度ががくっと下がることもあるため自分の実力をわきまえろ。
年代が近い場合、年代メドレーを入れてみんなでマイクを回しながら歌う→歌えなかったら罰ゲーム、というのも盛り上がる。
【鉄板】
気分上々↑↑
【わりとあり】
RAD いいんですか
【まぁあり】
【場合によってはあり】
歌上手い奴のバラード
【女の子に歌ってもらい盛り上がってもらう曲】
しかし、歌が上手くなくてもノリと勢いでカラオケキングになれるのが合コンだ。
こういうふうに語りながらおすすめを決められるのってすごいと常々思う。
自分がいいと思ったからといって他人にもウケるという確証がもてないから、
自分の熱量とは別に客観的に理路整然と分析して機械的に聞くようになったらつまらないし。
両方切り替えられればいいんだろうけどそこまで器用じゃないし。
俺はそれでいい。
めっちゃ傲慢にあれもこれもとすすめちゃってドン引きされちゃいそうだし。
ちなみに俺はジュテーム？が好き。
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
近頃刺激とよべるものが足りない。
興奮するような、人生が180度変わっちゃうくらいなこと怒らないかな。
有名人になるとか、それくらい規模の大きい刺激がほしい。
ちょっと前までは単純なことに刺激感じてたと思う。
歌を歌った、ジャニーズに浸った、RADにはまった、小説も書いた、歌い手の曲をいっぱい聴いた、ギターを弾いた、部活で部長をやった、掛け持ちもした、入賞もした。
もっといっぱいやってきたはず。
でも歌はへたくそと気づいた、ジャニーズは浅いと気づいた、RADは存在が遠すぎた、文才がない、歌い手を聴くとなぜか虚しくなった、ギターも下手、後輩をまとめれない、足手まとい。
独りの時に無気力でいることも増えた。
することなくなって、無理矢理探してもすぐ終わる。
昔、HUNGRY DAYSというバンドがいた。
wikipediaによると、
2003年、TEENS'MUSIC FESTIVALに出場し、ティーンズ大賞を受賞する。大賞受賞曲となった「明日に向かって」でメジャーデビュー。さらに、映画「ビートキッズ」のオーディションを受け合格し出演している。元気で飾り付けないストレートな歌詞が魅力。若いリスナーにメッセージを送り続けていたが、2006年春に解散した。
この「明日に向かって」が流れていたのが僕とHUNGRY DAYSとの最初の出会いだった。
【LIVE】HUNGRY DAYS 明日に向かって ‐ ニコニコ動画:Q
「あーメンバー僕と同い年なんだなー」
「なんじゃこのゴイステみたいなサウンドは」
「うわー青いなーほんとうに青いなーこいつら」
とゲンナリしつつも青春だらけの歌詞と曲に魅かれていった僕は彼らの曲をヘビロテしまくっていたのを覚えている。
曲がやたらとゴイステに似ているのは、今は亡き公式サイトによるとメンバー全員がゴイステ好きだったから。
とは言うものの、高校を卒業してから彼らの曲は聴かなくなり、気付いたら解散していたのをwikipediaで知った。
バンドを解散した後メンバーが何をしているのかさえ分からなかった。
とは言うものの、1年に1、2回くらい「こんなバンドがおったなー」って感じで曲を聞いていたりしていたわけだが、
昨日ベースの人とイケメンドラムの人が女性ボーカルを迎えてバンドを組んでて「ポストいきものがかり」と呼ばれて
ブレイクし始めている事を知った。昨日のドラマの主題歌歌ってるし。
それはもうびっくりである。閃光のようにバァっと光ってひっそりと消えていった人たちが、今こうして
彼らを見ていると、デビュー時期とかは微妙に違うけど、ほぼ同年代のBase Ball Bear と RADWIMPSを思い出す。
ゴイステの影響を受けまってたHUNGRY DAYS。
ナンバガの影響受けまくってたBase Ball Bear。
早々に解散してしまったHUNGRY DAYSと違い、ベボベとradは今でも活動を続けているけど、
ベボベはなんだかスタイリッシュヒカシューみたいになっているし、
radは色恋まみれのBUMP OF CHICKIENみたいになっている。
思い出は変わらないけど、人って本当に変わるもんだなあとしみじみと思ってしまったのだった。
リア充たちは「友達とカラオケ」なんて学生時代に腐るほど経験してる。
でも私は「夜にカラオケだと！？なんというリア充行為！」って、イイ年してめちゃくちゃテンションが上がる。
「この程度のことでテンション上がるって何ｗ」なんて笑われたけど、関係ない。
この歳になって立て続けに初体験して、私はすごく新鮮に感じたし、最高に楽しかった。
あとモテ系の人は「自分がどう思ったか、どう感じたか」っていう個人的な話をよくする傾向にあって、
可愛い子やイケメンはその時点で価値があるから、その人の「どう感じた」っていう情報にも価値がある。
その子を口説きたいと思ってる男は話題を合わせるためにさっそくRADを聴くし、
練習してカラオケで歌って好感度上げることを目論んだりする。
当然私はブス非コミュなので、私自身の情報には価値がないと思って、
芸能人の意外なエピソードなり、引きの強いデータなりを持ち出す、っていう方法で関心を引いてきた。
でも、たまーにだけど、こういうことを言われることがある。
「一般的にそういうのが人気があるのはわかるけど、増田自身はどういうのが好きなの？」
可愛い子やイケメンにとって当たり前のことである「自分自身に関心を持ってもらえること」に、
私は新鮮な嬉しさを感じることができる。
中学くらいのころは、やっぱり私も美少女に生まれてチヤホヤされたかったなーと思ってたけど、
ブスに生まれちゃったものはしょうがないし、ブスならではのメリットもちゃんとある。
ちょっと褒められただけで相当に嬉しいし、まだまだ新鮮に感じられる楽しいこともたくさん待ってる。
ブスも悪くないよ。
規制されてた。規制中でも書ける板で代行スレ使おうと思ったらBBQ焼かれてた。BBQ解除してもらおうと思ったら規制されてて書けない。なにこれ。
もういい。ここでレスする。どうせきづかれねーだろうが。
http://pc12.2ch.net/test/read.cgi/tech/1264745386/
俺が＞＞936なわけだが、単に俺はQtでのPythonとC++の相互利用を知りたかっただけなのだが、明後日の方向にレスが伸びてて残念だ。
コンパイル速度以外の観点からも、そうできたらうれしいと思ってるんだけど、コンパイルしなくていいってだけで十分じゃないの。
＞＞952
Pythonでも他の言語でも、速度面でシビアなところだけをC/C++で書くというのは一般的に行われている。
それを無視して最初から全部C++で、とか言ってる方がよほど偏愛だと思うけどねぇ。
| インタープリタ言語にはインタープリタ言語の得意分野がある。
何でもとりあえず手軽に書いてみて、後で必要ならC/C++に移植ってのも、インタープリタ言語の得意分野だよ。
実行の遅さも、C++より重いことは確かだが、そうはいっても特に重い処理の入ってない部品だと人が使ってて分かるほどの違いなんてないよ。
そこまで速度にシビアな局面ならQt使うってのが間違ってるんじゃない？例えばQtのウリの1つのシグナルとスロット機能は公式ドキュメントには、
普通に呼び出すよりも遅い。とはいえ普通の用途では気にならないから有益って書いてあるよ。これはインタプリタ言語使いがよくする言い訳と同じものだね。
http://doc.trolltech.com/4.6/signalsandslots.html
| だいたいあんたC++や本格的なRADツールの体験はどれだけあるの？
| いままで書いた最も大きなプログラムってどんなもの？
これはあまりにも愚問。それを必要としてない人にそれを要求してどうする。
