「レキシ」を含む日記 RSS

はてなキーワード: レキシとは

<前の25件

2016-03-27

■【転載】プロジェクトマネジメントなう＼(^O^)／

はじめに

すごく良いこと書いてあったのですが参考にしようとしたらサイトが消えいたので、魚拓から転載。

監督とは、 他人が打ったホームランで金を稼ぐことだ。

by ケーシー・ステンゲル（MLB監督）

ポリシー
  1. やるからには圧倒的な当事者意識と絶対に成功させるという気迫を持つ。
  2. 全てのメンバーが目的・段取りのわからない仕事をしない／させない。
  3. プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識する。
  4. プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。
  5. プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。
  6. リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは中長期的には失敗する。
  7. メンバーの強みを見つけて伸ばすことに注力する。その強みを持ち寄ってチームで仕事をするイメージ。
  8. 一つとして同じプロジェクトはない。どれだけ成功体験を積み重ねて実績のある方法論を確立しても、常に考えて工夫して改善し続けよう。常識という思考停止をしてはいけない。
  9. 人は一人一人別人であり仕事に対するスタンスは様々だが、ほとんどの人にとって仕事はあくまで生活の手段であり、生活のイベントより大切な仕事のタスクなんてないと考える。
  10. リソース（ヒト・モノ・カネ・タイム）が十分に足りてるプロジェクトなんてめったにない。それでも工夫と仕組みでなんとかするのがマネジメントの醍醐味。
  11. 業務システムの開発でどんだけ失敗しても人は死なない。気楽にやろう。最も大切なのは人の心。なるべく楽しくやろう。
  12. リーダーシップやマネジメントは効果の見えづらいものだが、人の集まりである組織には絶対に必要なもの。誰にも理解されなくても淡々とやるべし。

働・学・遊・美をミックスしましょう

by 川瀬武志（コンサルタント）

フラット＆オープン
  1. リーダー、サブリーダー、メンバーはたんなる役割であり、対等に仕事を譲り合い奪い合う関係である。
  2. 役割に関係なくお互いになんでも言い合えるフラットでオープンな関係を作ることが最も大切。
  3. リーダー自身が自由で本音な発言をすることでしかフラットな関係は作れない。
  4. 全ての情報を全てのメンバーにオープンに。基本的にはメール・メッセージは常に全てのメンバー宛に。
  5. 情報連携はできるかぎり速やかに。リーダーとメンバーの情報格差は百害あって一利なし。オープンにできないことはやましいことである。
  6. チーム内に何してるかわからない人がいたり、一部の人しか知らない事情があると、とても雰囲気が悪くなる。
  7. 見積り・計画・スケジューリング・アサインは全員参加で。

門限なんかできたら私が一番困る。幼稚園の子どもではあるまいし。

by 仰木彬（NPB監督）

スピード＆フレキシビリティ
  1. やってみないとわからないことの方が圧倒的に多い。トライ＆エラー＆リスケを繰り返す。スモールスタート＆リスケジュール。
  2. 考えてもしかたないことやわからないことを考えない。下手に予測するより聞いたり試したりする方が速い。
  3. 早く失敗することは遅く失敗することよりも何倍もよいことである。
  4. スピードとクォリティは反比例する。どんな要求にもまずは素早く対応する。
  5. リーダーは自分の作業に集中していてもメンバーからのアクションにはすぐ応える。「今いいですか？」の答えは常に「YES」。メンバーを待たせてはいけない。

明確なのは、楽しく笑顔が生まれる環境ほど、物事は成功しやすいということだ。我々はそういった環境を作り出そうとしている。

by ジョセップ・グアルディオラ（サッカー監督）

スケジューリング
  1. 日々リスケする。プロジェクトの初日に完璧なスケジュールが引けるはずがない。実態と乖離した変化しないスケジュールは失敗の素。
  2. スケジュールはCCPMに準拠したやり方で管理する。これが現状の把握と未来の計画が最もやりやすいやり方。
    1. 個別のタスクにはバッファを積まずに最短期間とする。
    2. フェーズ毎にプロジェクト全体のバッファを持たせ、人単位で管理する。
    3. スケジュールには全てのタスクと人単位のバッファを掲載する。
    4. 個別のタスクの長さは、日々、現状に合わせて変更する。（常にオンスケ状態になる。）
    5. プロジェクトの状況把握はバッファの消費率とメンバーの稼働状態で判断する。
  3. スケジュールとWBSは似て異なるもの。スケジュールは見易さと扱い易さが命。メンバーが手元にスケジュールを持っていないプロジェクトは失敗する。
  4. どの時点でもどれだけ未確定なことがあっても、実際に全体のスケジュールを引いて実名でアサインしてリソースの過不足を確認することは大切。
  5. リソースの状況に関わらず必ずやるべきことと、リソースから逆算してやれる範囲でやることを区別すること。
  6. 重要であること／ないこと・緊急であること／ないことのマトリックスを意識する。
  7. スケジュールを変更する時は必ず担当者と話して一緒に考えること。
  8. 森を見ずに木に手をつけてはいけない。木を見ずに森を見積もってはいけない。

計画は役に立たないが、計画することは不可欠だ。

by ドワイト・D・アイゼンハワー（第34代アメリカ大統領）

アサイン
  1. 一人一人の特徴や好みに合ったアサインをすることはとても重要。
  2. メンバーがちょっと頑張ればできるくらいのちょうど良い質量の仕事を担当させることが理想。
  3. 全てのメンバーが自分の役割と他人の役割に納得できるようになるまで見直す。
  4. プロジェクト期間中に成長したり変化するメンバーもいる。最後まで柔軟に変更する。
  5. 経験年数や業務知識よりも、頭の良さや心の強さや柔軟さを重視する。前者は変わるけど、後者はほとんど変わらない。
  6. ダメな人をイイ人の上につけない。年齢や役職を無視する。新人が入社初日から旧人より仕事ができることもある。
  7. 「どんな仕事でも長時間かけても平気」「面白い仕事なら長時間かけても平気」「どんな仕事でも長時間は嫌」という仕事に対するタイプを意識する。
  8. アサインに関してチームとメンバーの利益が一致しないことはよくある。ありのままをメンバーに話して一緒に考える。
  9. いったん良いチームができたら同じチームで様々な仕事をしていくのが理想。（とても難しいけど。）
  10. 本人がその役割を好きかどうかはとても大切。
  11. 適切なアサインができたら、チームと個人に明確に責任を持たせ、信頼し、任せる。
  12. 各カテゴリのチーム内の権威が自然にチームリーダーをするのが望ましい。
  13. 適材を適所に。それが全て。適材がいなければ始めてはいけない。
  14. 下流工程は人数さえそろえば誰でもいいというのは大きな間違い。また、レビュイーとレビュアーの比率には要注意。
  15. 少数精鋭がベスト。できる人を入れることとできない人を入れないことは同じこと。「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。」（ブルックスの法則）

人を最もダメにするのは「全体像」を見せずに「部分的なこと」をずっとさせること。

これ続けてると何も考える力のない指示待ち人間ができあがる。こわいこわい。

by 外尾悦郎（スペイン、バルセロナのサグラダ・ファミリア主任彫刻家）

プライド
  1. 全ての人には美意識や価値観やプライドやこだわりがある。それをできるかぎり尊重し傷つけないようにする。
  2. 人が一生懸命に話をしてる時にはなるべくさえぎらない。ため息をついたりしない。
  3. 「ダメじゃーん」と言った方ががんばる人もいるし、「よくできました」と言った方ががんばれる人もいる。
  4. いったん優秀さを信頼した人には、どーんと仕事を任せて長い目で見る。
  5. ほめる時はみんなの前で、注意する時は一対一で。
  6. 短期的な効率よりもやる人の気持ちを優先する場面も多い。
  7. 踏んだ人はすぐに忘れても、踏まれた人はその痛みをいつまでも覚えいている。リーダー・マネージャーは常に踏む側。

腹が立ったら自分にあたれ、悔しかったら自分を磨け。

by 村上春樹（小説家）

コミュニケーション
  1. チーム全体で話す。数人で話す。一対一で話す。それを上手に使い分けること。
  2. 状況によって話がぶれないようにする。相手によって話を変えてはいけない。
  3. 常にメンバー全員の気持ちを知っておくことは大切。定期的に一対一で話すなど。
  4. 常に明るく楽しく。仕事に負の感情を持ち込まない雰囲気を作ることが大切。
  5. 必要な話を必要なレベルで必要な人にする。相手が望んでない話を理解できないレベルでしてもムダ。
  6. 神経質な人にはおおらかに、おおらかな人には神経質に、楽観的な人には悲観的に、悲観的な人には楽観的に。
  7. 仕事でミスした人に「ミスしただろ！」と怒っても百害あって一利なし。原因や対応や予防策などを一緒に考えることが重要。
  8. 人や仕事をなめてると感じられるメンバーを見つけた時だけは厳しく。なめられてもなめてもダメ。
  9. 仕事も遊びも類友ではあるが、できるかぎり負の影響が出ないようにする。また、類友とそうでない人の意思疎通の差は要注意。
  10. 議論の対立は失敗ではない。対立を敵視すると自由な議論ができない。
  11. 沈黙を同意と思ってはいけない。多くの場合、沈黙とともに問題が潜在化する。明確なYES以外は全てNOと受け取る。
  12. 全てのステークホルダーと良い関係を築き、明示的・暗黙的な期待を察知してコントロールすることを心がける。
  13. 人と人との問題は徹底的に話し合うしか解決の道はない。感情のぶつかりを恐がってはいけない。

ミスした選手に「ミスしただろ」と言ったり責めてもしかたない。本人が一番わかってる。

by ピクシー（サッカー監督）

クォリティ
  1. 目的、内容、責任の所在、〆切、優先度、質重視かスピード重視かなどは常に明確に。曖昧さを徹底的に排除する。
  2. どんだけ簡単な話でも箇条書きや表や図にして考え、人と議論する時にはどんだけ簡単なものでも良いので必ずなんらかの紙を用意する。
  3. 必要のない冗長性を排除する。ルーティーンワークについては、できる限り何も考えずに簡単にまわる仕組みを作ること。
  4. 成果物・タスクの粒度に注意する。一つ一つが大きいと数が減って管理しやすい。小さいと数は増えるが柔軟にアサインできたりする。
  5. 問題を相談する時は、根本原因を明確にした上で選択肢を洗い出し、最終的な自分の意志を持って臨む。
  6. 最新の問題が最優先ではない。最古の問題が最優先でもない。発生順と優先順位に関係はない。
  7. 目に見える成果物だけではなく、段取りや、会議や、議論などの質を意識する。
  8. 頑張りや心がけではなく工夫と仕組みで救う。

神は細部に宿る。

by ミース・ファン・デル・ローエ （建築家）

コスト
  1. なにかを作るコストとそれを利用するコストのバランスには細心の注意を払う。
  2. 〆切ぎりぎりに慌ててやるのが一番コストが低い。意識的に上手に利用すること。
  3. メンバーの作業を遮る度に生産性はどんどん落ちていく。
  4. だらだらした会議は諸悪の根源。会議のコストは莫大であることを常に意識する。
  5. 短期的に生産性を上げる方法はない。プレッシャーをかけても思考は速くならない。過度の残業（短期を除く）は生産性を落とす。
  6. 費用的なコストだけではなく精神的・身体的なコストを意識する。サービス残業は費用的なコストをメンバーの精神的・身体的なコストに転嫁している。
  7. 全ての仕事を全力でやってはいけない。（そんなことしてたら家に帰れない。）重要度に応じてコスト配分すること。

放っておくと会議の時間の九十五％は「コメントの交換」に使われている。

これを「明確化のための質問」「代替案の提示」「リクエスト」の三つだけに絞ると面白いほど会議が前進する。

by 大橋禅太郎（コンサルタント）

リスク
  1. フラット＆オープンの実現が最大のリスク管理（メンバーからのアラート頼み）である。
  2. 契約前にできる限りリスクを洗い出して契約に反映する。契約後にリスクを洗い出しても手遅れ。
  3. 問題が起きた時は、暫定対処をした後に何度も「なぜ」を繰り返して根本的な原因に到達するまで対処しない。
  4. 知らないことが問題になることより、知っているつもりで誤解していることが問題になることの方が圧倒的に多い。
  5. リソースが足りなければリーダーは無力。それを闇雲に根性で埋めようとするリーダー・マネージャーが最大のリスク。
  6. リスクのない仕事はない。リスクがあることが当たり前。リスクがなければマネジメントなんぞいらない。

たとえば、よく晴れた日曜日の朝に戦争がはじまる。

by 「ケッヘル」（中山可穂）

リーダーシップ
  1. 「いいからやれ！」というのは通用しないし、それを言う人もそれで動く人も信用してはいけない。
  2. 正直に誠実に。自分のミスは素直に認める。公平にはできないけどできるかぎり公正でありたい。
  3. リーダーだけは結果責任。正しくても結果がダメなら意味がない。
  4. 常に問題や誤りが起きるのが当たり前。要件も見積りも常に変化するのが当たり前。問題や誤りや変化に対応することがリーダーの最も大切な仕事。
  5. 過度の残業の発生はマネジメントの失敗をメンバーに救ってもらっているということ。残業は悪ということを徹底する。
  6. 平和だったらリーダーはヒマなのが正しい。メンバーが忙しくなる頃にはリーダーの仕事のほとんどは終わってるはず。
  7. リーダーの笑顔は義務。加えて絶対にくじけない胆力。いつでもヒマで上機嫌が理想。
  8. どれだけオープン＆フラットを実現しても、管理者は同僚ではないし純粋なチームの一員にはなれない。これはしかたない。
  9. メンバーからの信頼は絶対に一朝一夕には得られない。長期間にわたる日々の積み重ねでしか得られない。
  10. 個人の評価は難しく苦しいことが多いが、厳しく明白に成果の差をしっかり反映するように努力すること。
  11. 問題が起きた時には必ず先頭に立って矢面に立つ。絶対に逃げてはいけない。結果が伴わなくともその姿勢がチームの雰囲気をよくする。
  12. 外部からの雑音を遮断することは難しい。一つ一つ理論的に検証してメンバーと共有する。
  13. 旧来の悪習は自分以降の代には持ち越さないという強い意志を持つ。
  14. リーダーの成功は優秀なメンバーに支えられている。常に感謝の気持ちを忘れない。
  15. 北風ではなく太陽でいよう。

重要なことは、正しいか、間違いかではない。うまくいくか、いかないかです。

マネジメントとは、そのようなものです。

by ピーター・F・ドラッカー（マネジメントの神様）

その他
  1. 数値はたんなる道具であり、現場の判断の材料であったり後を追うもの。数値を計測・記録する事務作業はマネジメントの本質ではない。
  2. ウソはあらゆる面でものすごくコストの高い最悪の手段。
  3. 夕会は人気がない。朝会か午後会で。
  4. 人は変化を憎悪することが多いし、変化への基本的な反応は論理的なものではなく情緒的なものであることが多い。
  5. ハラスメント系の問題は何もしなければ絶対に見つからない。発見するための仕組みを用意すること。
  6. ストレスやプレッシャーは逃げると追いかけてくるけど立ち向かうと逃げていく。でもしんどい時は相談してね。

やってみせ　言って聞かせて　させてみて　ほめてやらねば　人は動かじ

話し合い、耳を傾け、承認し、任せてやらねば、人は育たず

やっている、姿を感謝で見守って、信頼せねば、人は実らず

by 山本五十六（連合艦隊司令長官）

クロージング
  1. 評価や反省は厳しくごまかしなく。それが最も本人のためになる。
  2. 反省会は必須。記憶が定かなうちに他者も交えて反省・改善をしないとせっかくの経験がムダになる。
  3. 反省会で、全員がオープンにフラットに悪い部分も含めて相互を評価し合えたら、そのチームはうまくいったということ。
  4. 全ての項目が○な人はいないし×な人もいない。固有のミスや特定のカテゴリで人を評価しない。全期間を通したトータルで評価する。
  5. 打ち上げは必ずやる。絶対にやる。やる。

あなたに幸運の女神が微笑んだのであれば、プロジェクトは無事に完了し、幸せになれます。とてもとても幸せになれます。多くの人々は、自分では何の失敗もしていないのに、ここまで到達することができないのです。豪勢な夜を計画してください。どんちゃん騒ぎをして散財してください。そして、その時のことをいつまでも語り継げるようにしてください。

by 「アート・オブ・プロジェクトマネジメント」

ヒント１（仕事の進め方）
  1. 〆切を確認する。
  2. 成果物の内容を確認・提案して合意する。
  3. タスクを分割してスケジューリングする。
  4. 難しいタスクの目処を早めにつける。放置してはいけない。
  5. 参考になる前例や詳しい人を探す。車輪の再発明はダメ。
  6. 定期的に報告する。ただし、困った時はすぐ報告する。
ヒント２（ミーティングのコスト）
  1. １人が事前に１０時間かけて準備して２時間で終わった場合、５０人時間。
  2. だれもなにも準備せず５時間かかった場合、１００人時間。

この５０人時間の差が大規模で長期間のプロジェクトの場合に大差を生む。

ヒント３（生産性）

２０人のチームの場合。

  1. 各人の生産性が１０％上がったら、２２人分。
  2. 各人の生産性が１０％下がったら、１８人分。

この４人分の差が大規模で長期間のプロジェクトの場合に大差を生む。

ヒント４（報告メッセージ／メール）

ミーティングと同じようにコストを意識する。読む人の時間をムダに奪ってはいけない。

  1. 目的を明確に。問題提起なのか周知なのか依頼なのかメモ（エビデンス）なのか。難問だったり緊急なら直接話そう。
  2. 必要のない重複を削ってなるべくサイズを小さくシンプルにする。時間をかけられる時の方が十分な推敲で文章が短くなるのが正しい。
  3. リーダーは結論だけを知りたい。サブリーダーはその経過も知りたい。他のメンバーは具体的なやり方まで知りたい。だからその順番で書く。
  4. 文章だけのメッセージでもレイアウトとマトリックスを意識する。例えば「ＡはＢでＣはＤで」みたいな部分は箇条書きにする。
  5. 「ご連絡」とか「お願い」というタイトルはダメ。検索できるとはいえ後から探すコストはバカにならない。
ヒント５（オンライン反省会）

反省会は、社内グループウェアのメッセージ機能を使って、こんな感じでやってます。

  1. 全員がなるべく全員の良かったところと悪かったところを書く。
  2. プロジェクト全体やお客さんや会社についてもなにかあればなんなりと。
  3. 非定型に自由にコメントＯＫ。気付いたことがあれば数年後でも書き込みもＯＫ。

オンラインで反省会をする理由はこんな感じ。

  1. 声の大きさや考えるスピードの影響が少ない。
  2. その場の雰囲気や感情に流される確率が低い。
  3. 自分のペースでじっくり消化・表現できる。
  4. 場所とか時間とかの制約がない。
  5. 完璧な記録が残る。
ヒント６（ファイアープロジェクト）

ファイアープロジェクトに助っ人参戦した場合にどうするか。原因のほとんどはマネジメントもしくはコミュニケーション。

  1. 全てのメンバーと１：１で話をして問題や要望を挙げてもらう。リーダー、サブリーダーからは出てこない様々な話が出てくるはず。
  2. 面談でキーマンが浮かび上がってくるのでアサインを見直す。ただし、人を腐らせて雰囲気が悪くならないように細心の注意を払う。
  3. スケジュールに全てのタスクと全てのメンバーの空き工数を記載し、進捗もぴったり現状に合わせて状況をはっきりさせる。
  4. リソース不足や課題が出てきたらすぐに手を打つ。スピード感が変わったことを印象づける。
  5. マネジメントの問題だった場合はメンバーに「君たちの問題ではないよ」と明確に伝える。

２０人程度のチームならこれらを１～２日で終わらせて雰囲気を一新する。あとはふつーのマネジメントへ。

ヒント７（ヒューマンスキル）

ヒ

Permalink | 記事への反応(0) | 22:54

2014-12-10

■『感情に乏しい』・『自分の意見がない』人は読んでみて下さい。

自分の意見がない人は、自分の感情がない人。

感情がない、何も感じない、それを出せない。

ヒントを一応文章という形で羅列します。しかし、ヒントの羅列と捉えてもらえるとありがたいです。

自分が必要だと思う部分を掻い摘んで読んでみてください。直訳したような文章になってしまいました、悪しからず。

●『好き・嫌いの嗜好すらそもそもない人』

感情として、分かりやすいのが、５感。

美味いものは美味い、不味いものは不味い。

次に、例えば、モノの好き嫌い。

アイドル、モデル、芸能人、自分の周りの人間→好き/嫌い。

それは何かを感じるからです。で、こいつはこうだから好き、こいつはこうだから嫌い。

自分の意見も出ます。この感受性を高めて下さい。そのためにはもっと「触れる」「知る」ことです。

●『喜怒哀楽＝自分』

で、ここで言いたいこと。その肝心の「感情」とは、「喜怒哀楽」。

何か物事が起こった時、それに対して「感じる」力が弱いのです。

だから、自分の意見が言えない。

自分の意見が言えない人は特に、「怒り」の感情が弱いと思います。

自己肯定感が低い、自己否定感が強い人は、何かあった時にそれを全て自分に帰属しやすいです。

それはあいつが悪いんだろ、って普通思う局面で、僕が●●だから悪いんだ。

これはいじめとか虐待とかされてた人、周りから否定されてきた人に強いと思います。

理不尽な否定に対して、認知的不協和が起こるために、自己否定感を持ってしまう。


●『感情を抑圧してしまう人』

これを止めるコツ。それはべき思考を消し、自分の感情を素直に受け止め、それを一旦出すこと。

怒っちゃいけない、怒りの感情がある時は、それを一旦出す(自分の内にはそれを認めること)。

たとえ、自分が一方的に悪いことでも、怒られればムカつくし、情けなくもなります。

それは逆ギレという形で出せ！というのではありませんが、怒りの感情を抱いたことは事実でそれは認めてあげることです。

その上で、冷静に考える。これをちゃんと出来て初めて、「感情のコントロール」が出来るようになるのです。

それは感情の否認でも、抑圧でもあってはいけないのです。

怒りを抑圧すれば、いずれ爆発します。感情を抑えれば爆発するか、何も感じなくなります。(失感情症＝アレキシサイミア)

酒飲んで暴れる人間とかはこの典型です。

しかし、これも有効に活用出来ます。酒を飲んで吐き出したくなる感情が普段抑圧しがちな感情です。

●『その対策・改善策』

感情が出にくい人へその改善案です。

感情を否定しないのが前提ですが、

・心揺さぶられる(擬似)体験をする・心揺さぶられるものに触れること。映画、音楽、TV、スポーツ。なんでもいいです。

自分が好き！！と言えるものを探して下さい。泣いて下さい。笑って下さい。笑いが出たらわざと大げさに笑い、涙が出たらもっと泣こうとして下さい。

・その時に出来れば、感情豊かな人の真似をして下さい。

「芸能人、DQN、幸せそうな人、失恋した人、外国人。それらの真似をすることで感情が出やすくなります。」

芸能人のようにわざとらしく泣き、笑い、DQNのように怒り狂い、ウエディングドレスを来た新婦(新郎)のように幸せに身を委ね、失恋した人のように悲しみにくれ、外国人のようにオーバーリアクションをしてみてください。感情は感情ありきでないというか、笑顔になるから楽しい、眉間にしわを寄せるからムカつく、と表情に牽引されて出るものでもあります。

※わざとDQNと書きました。

自分が嫌いなもの、苦手なもの、こうなりたくないというもの、をイメージして下さい。

それは、そうなれないもの、では無いですか？？　それが自分のコンプレックスを刺激するものでは無いですか？ある意味羨望。

だとしたら、一旦それを真似して下さい。地面につばを吐いて、店員に悪態をついて、街を肩で風をきるように、歩いてみて下さい。

自分がなりたいイメージがある、変わりたい場合、あえて真逆を言ってバランスを取るのも手段の１つです。

・アサーティブな場に自分を置いて下さい。

アサーティブとは、自分も相手も台頭ということです。(詳しくは、「アサーション」等でググって下さい。)

自分が何者であるか、そのバックグラウンドがあまり関係ない場です。ネットとかもそうですよね。

それは感情を出しやすいために、抱きやすくさせます。

●『恋愛をしてください』

…ここまで書けば、何をすればいいか分かりますね？？

そう、『恋愛』をして下さい。

アサーティブな関係で、自分の絶対的な「好き・嫌い」、「喜怒哀楽」を出すことの許される関係です。

そして、自分を忘れ、恋に走り、歓び・傷ついて下さい。理性を忘れ、自分の思うがままに相手を求め、SEXして下さい。

恋愛は素晴らしいです。感情主体的行為です。



●『斜に構えないで、自分の人生を生きて下さい』

『恋愛』…ああ、言いたいことはそういうことね。俺には無理だわ。クソ記事乙ｗｗ

こういう自己否定的、斜に構えて物事を見るのを止めて下さい。こういう人はYESマンになって下さい。

物事をそれをする前から、自分には向いてる／向いてない、意味がある／ない、出来る／出来ないで判断しないで下さい。

そんな「効率」や「要領」なら捨てて構わないです。それを誇って生きられるのは、ネットの世界だけですから。

コストパフォーマンス・仕事の効率化…熱量を失った人間ばかりです。それは死に物狂いで何かをして、何かを得た人間がやればいいことです。

あなたは、ネットで難しい言葉で相手を言いくるめ、論破し、罵倒し、勝ち誇った気持ちになれるかもしれません。

自己を肥大化させて万能感でもって、愉しく生きているのかもしれません。

だからこの記事の中にも、批判しやすいように「餌」を何個か用意しました。それを叩いてくれてもかまいません。

しかし、実態は「感情」を持った、人間なのです。感情を失ったら機械です。理性を失ったら動物です。

人間が素晴らしいのは、感情も思考能力(理性)も持っているからなのです。しかし、ベースは感情です。

感情があるから物事を考えることが出来るのです。感情、それは「あなた唯一無二のもの」です。

我思う故に我有り。思うのは、考えられるのは、感じることができるからなのです。

客観性・妥当性だけで生きていたら、平凡な人間にしかなれません。

その平凡さを否定するために、人を蹴落として自分の価値を高めるつまらない人間にしかなれません。

それをしていると、自分より強いものの前に跪き、下しか見れない人間になるのです。

僕はそんな人間になりたくない、過去の自分への戒めとして書きました。

Permalink | 記事への反応(1) | 02:27

2014-05-29

■

サッカー日本代表「戦犯旗」ユニホーム、米紙に批判広告

http://www.chosunonline.com/site/data/html_dir/2014/05/29/2014052900680.html

普段は「レキシシューセー」とうるさい人々は、韓国人による「レキシシューセー」は完全スルー。これがニッポニア・サヨク＝コリアン・ネトウヨである。

Permalink | 記事への反応(0) | 22:50

2012-09-18

■無理に喋らなくて良いのに

http://d.hatena.ne.jp/apesnotmonkeys/20120918/p1

あんまり無茶なこと言うとレキシシューセーシュギって啓蒙も怪しく思われちゃうので、そんな頑張らない方が良いですよ。

Permalink | 記事への反応(0) | 05:13

2012-04-09

■突然「理系の子」をdisる

文芸春秋が先月出した単行本で、「理系の子」というのがある。書評を検索したところ、おおむね好評であるようだ。

たしかに本はとても面白かった。登場人物はそれぞれ個性的だし、エピソードは魅力的で印象に残る。構成もよく練られていてとても読みやすい。

だが、おれは気に入らない。この本は文系の著者による文系の読者のための文系ならざるところはない本だからだ。あいまいで科学的厳密性に欠けるものだからだ。

たとえば、第二章では、「太陽エネルギーによって部屋を暖め、湯をわかすヒーター」が登場する。著者は次のように説明している。

太陽の光がプレキシガラスを通過し、光を最大限に吸収するよう黒く塗られた炭酸飲料の缶に囲まれたラジエーターを暖める。そこから暖かな光がパイプを通じて部屋へ送られ、室温を摂氏三十度以上にすることができ、さらに沸点近くの九十五度くらいまでの湯をわかすことも可能だというのだ。

お前らこれでどんな装置か想像できるか。水温測ったら九十五度でした、以上の情報はおれには読み取れない。

ラジエーターは何のためについてるんだ？装置内で水は循環してるのか？そういう説明は一切ない。

また第六章では、水中のポリフルオロオクタン酸(PFOA）の濃度を正確に計測する方法として

PFOAを含む水を煮詰めて振り、表面にどれほどの泡を生じるか観察するだけでいいのではないか？

と書いている。いいわけないだろ。あのな、お前本当に知らないかもしれないから言っておくけど、界面張力ってすごく微妙で他の有機物はもちろんちょいと無機塩が溶けるだけで変わってきちゃうんだぞ。

そして、この測定法について「この方法でも九十二パーセントの精度で水に含まれるPFOAの量を測定できることがわかった」と書いているが、九十二パーセントの精度ってどういう意味なのかおれにはわからない。測定誤差が八パーセントってことか、ばらつきが九十二パーセントあるってことか、どっちだよ。

測定誤差が八パーセントなら測定誤差が八パーセントと書くべきで、訳文から感じ取れる「こんなに正確に測れるなんてすごい！」的ニュアンスからすると多分こっちかなあという気がするが、でも一○八パーセントの方はどうなっちゃうの、と思わざるを得ない。あるいは、この方法は簡易測定法なんだから、ばらつきが九十二パーセントあったって充分有用なのかもしれない。でも、それならそれでもうちょっと他の書き方があるだろ。測定誤差が大きい測定法なのに、そのことについて触れないとしたら、それは不誠実な態度ってもんだ。

第十一章はカーボンナノチューブネタだが、ナノ粒子についてこう書いている。

ナノ粒子は髪の毛のおよそ十万分の一、分子よりもわずかに大きいだけだ。

お前なあ、と書いて終わらせたいところだが、一応二点だけ突っ込んでおく。

髪の毛のおよそ十万分の一、というのは「髪の毛の太さの十万分の一」というつもりだろうが、太さという重要なタームを省略する感性は理解しがたい。それに、髪の毛の太さが何ミリかお前ら知ってるのか。おれは知らない。ナノ粒子ってすごく小さいんですよ、と言いたいのならもっと具体的にイメージできるものと比較しろよ。「分子よりもわずかに大きいだけだ」って、大きさをどう評価するべきか、という議論も可能だし、そもそも粒子と分子を無造作に並記する鈍感さにうんざりさせられる。

他にもいくらでもあるが、以上を要するに、著者は彼らの研究内容を理解していない。

そして（著者略歴によれば）他の雑誌はともかくWiredに寄稿していることからして、自分が理解していないということは認識していただろう。つまり、理解しようという気がなかったと断定していい。この本の帯には「科学はこんなに楽しく、熱い」と書いてあるが、著者が書いているのは科学の楽しさや熱さではなく、参加した高校生が楽しんだり熱中したりしているその姿である。著者にとっては、そしておそらくこの本のメインターゲットであろう多くの文系の読者にとっては、研究内容などどうでもいいことなのだ。

消費される娯楽。この本に対するおれの評価はそれに尽きる。こういう本が出版されること自体が遠まわしな科学へのdisではないのか。

だいたいからして電子材料ハンドブックだって充分すぎるほど楽しく、熱いよ。

Permalink | 記事への反応(2) | 23:12

2011-03-16

■「ドラゴンボールで学ぶオブジェクト指向」 のクロージャに関して

http://anond.hatelabo.jp/20110316202255 - ドラゴンボールで学ぶオブジェクト指向

また、ポイポイカプセルのように技を塊にして色んな人が使えるように出来ます。

var shotKamehameha = new function(){
	//かめはめ波を打ちます。
}

noumin.kougeki = sendKamehameha;
buruma.kougeki = sendKamehameha;

noumin.kougeki();  //カメハメ波がでます。

このような仕組みをクロージャと言います。クロージャはクロージャの中に記述することも出来ます。

って書いてるけど、クロージャってのはそういうものじゃないよなぁ、と。 まあファーストクラスの関数オブジェクトっていうところはあってるけど、それだけでクロージャと言えるのかというとちょっと違う。

"a closure is a first-class function with free variables that are bound in the lexical environment." (Closure - Wikipedia) とあるように、関数内の変数がレキシカルスコープに結び付けられているようなものがクロージャなのである。 JavaScript で例を書くなら、次のようになる。

// クロージャを返す関数
var getClosure = function getClosure() {
    // クロージャからアクセスされる変数
    var counter = 0;
    // クロージャ
    var closure = function closure() {
        return counter++;
    };
    return closure;
};

// クロージャを取得
var closure = getClosure();

// クロージャを実行
closure(); //=&gt; 0
closure(); //=&gt; 1
closure(); //=&gt; 2

匿名ダイアリーで大なり記号とか書くときってどうしたらいいんですかね... "&gt;" ってなっちゃう

Permalink | 記事への反応(0) | 23:11

2011-02-01

■大学院博士課程はどうなるべきなのか？

id:aionarapです．自分のブログがなく，ブコメじゃ情報を書き足りないのでこの場をお借りしました．

エントリを書くきっかけ

“徒弟制度”や修士論文の廃止求める　大学院博士課程で中教審答申 - MSN産経ニュース http://sankei.jp.msn.com/life/news/110131/edc11013122040003-n1.htm

はてなブックマーク - “徒弟制度”や修士論文の廃止求める　大学院博士課程で中教審答申 - MSN産経ニュース http://b.hatena.ne.jp/entry/sankei.jp.msn.com/life/news/110131/edc11013122040003-n1.htm

この中教審の答申に関して，ブコメでは否定的な意見が多数，というか肯定意見は皆無ですね．しかし，私個人はある程度この試みに賛成です．あ，先に書いときますが，完全肯定じゃないですけどね．修論は書いたほうがいいし，徒弟制の完全廃止もどうかとは思っています．

じゃぁ何が賛成なのよ，という話ですが，Qualifying Examの導入，及び広い範囲の教育に関してです．これは必須，と私は考えています．この辺りのお話に関するご意見を皆さんに聞いてみたいと思い，当エントリを書くことにしました．

要約

今回の中教審の答申は，博士の現状の問題を反映した意欲的な取り組みに感じる．丸呑みにするには良くない部分もあるが，期待しても良いのではないのか．

博士とはなんなのか

さて，そもそもの出発点ですが，博士は「スペシャリスト」でありさえすれば良いのでしょうか？私は否と考えます．博士こそ「ジェネラリスト」にもならねばならない．…と書くと誤解を招きますね．要は専門馬鹿になっちゃいかん，ということです．

勿論，博士課程の人間は自分の専門分野に関して，国際的な第一線に立てるような知識と経験が必須です．一生懸命に自分の研究に取り組む必要があります．ですが，それだけではダメで，最低限隣接領域(まぁ定義が微妙ですが)に関して，可能であればもっと大きな枠組で知識を深めなきゃいけません．科学技術はどんどん煮詰まってきて，先に進むためには学際分野の融合による新しい概念の創出が必要です．それをイノベーションと呼ぶこともあるでしょう．それを生み出すためには，少なくとも2つの分野に関してよくものを知っていないといけません，そうですよね？

テクニシャンとして分野を極めるのもひとつの道かもしれませんが，博士に求められているのはそういうことではないと私は考えています．

国はどういうつもりで博士を育てているのか

加えて，博士が「スペシャリスト」のみを意識していると，博士課程の人材の活用先は研究者，それもかなり狭い分野に限定されます．

ここで，大学院設置基準が定めている博士課程の役割を見てみましょう．昭和49年の時点では，

「専攻分野について，研究者として自立して研究活動を行うに必要な高度の研究能力及びその基礎となる豊かな学識を養うことを目的とする。」

というものでした．それを，平成元年の時点で

「専攻分野について，研究者として自立して研究活動を行い，又はその他の高度に専門的な業務に従事するに必要な高度の研究能力及びその基礎となる豊かな学識を養うことを目的とする。」

と，敢えて変更を行っています．差分は，

「又はその他の高度に専門的な業務に従事するに必要な高度の研究能力」

が必要，と明文化したところ．その意図を，

「社会の多様化，複雑化等に対応し，博士課程において，大学等の研究者のみならず，社会の多様な方面で活躍し得る高度の能力と豊かな学識を有する人材を養成する必要から明確化」

した，と説明しています．

(以上，http://www.mext.go.jp/b_menu/shingi/chukyo/chukyo0/toushin/05090501/021/003-3.pdfの2ページ目より引用．)

平成元年の時点で，大学院設置基準は博士課程学生に「社会の多様な方面で活躍しうる」人材たることを求めているのです．

博士はどこで活躍できるのか / あるいはすべきなのか

「おいおい，博士が研究者にならなくてどうするのよ…」という意見もあるでしょう，それは理解します．ですが，包含関係を取り違えてはいけません．研究者として生きて行けるのは，博士号を取得したうちの一部の人間です．研究者になるのは博士号取得者でしょう．ですが博士号取得者は全員研究者にはなれません．国家として，限られた国庫の中から博士を全て取り込めるほどポストを恒久的につくるのなら別ですけどね…．

それに，(ありえませんが)もしそうなったとしても，全員研究者になるのもどうかと思います．一人ひとりが研究テーマを持って，プロジェクトリーダー的な役割を果たしつつ，世界の最先端を突っ走ってきた人間が，その経験と知見を他の分野に持っていくことは非常に意義があるでしょう．ある意味，一人でプロジェクトチームに求められる役割を全て果たす必要があるのですから，その能力は推して知るべしです．是非，社会のあちこちで活躍するべきです．

非常にポピュラーなのは，専門を活かした職業でしょう．企業での研究開発を初めとした「明示的に博士を求めている」職業は多いです．…まぁ敢えて書く必要はないですね．

初等，中等教育の教師もいいでしょう．勿論高専も．起業もいいですね．

そして，本当はその他の「博士が求められていない」と考えられている職業にも行ったほうがいいと思うんです．だって，ずっと知的体力を鍛えてきたわけですから，同年代の博士号非保持者と比較してその辺りは大きくリードしているはずです．

彼ら/彼女らが持っている問題発見能力は，必ずや企業にとって大きな助けになります．

現状はどうなのか

前節の内容に関して，同意して頂けましたでしょうか？して頂けた方も，そうでない方もいらっしゃるでしょう．

でも，同意/非同意にかかわらず，ほとんどの人は「夢物語乙!www」という感想を抱くのではないでしょうか．いえ，私もそう思います．

だって現状が全く異なるのですから．

例えば，id:scicom 氏の快著，「博士漂流時代「余った博士」はどうなるか?」(http://goo.gl/Pd0ls amazonへのリンク)には現状の博士号取得者，特にポストドクター(PD)の状況が整理されています．

簡潔に言えば，現状は散々たる物です．企業は博士号に魅力を感じていません．これは伝聞ですが，採用担当者は「博士は当たり外れが大きい」と感じているようです．ハズレを引くリスクを恐れて採用を控えるそうです．

そもそも，皆さん，博士号をとっている人間が「最低限」「共通して」何を出来るか，分かりますか？

言い換えると，博士号が担保しているものは何か，知っていますか，ということです．

公開されたばかりの中教審の資料から引用しましょう．

特に，博士課程では，①学生に特筆すべき顕著な研究業績を求める大学院もあるなど，博士の学位が如何なる能力を保証するものであるかについての共通認識が確立されていないこと，②博士課程（後期）の教育が，個々の担当教員がそれぞれの研究室等で行う研究活動を通じたものにとどまり，学位プログラムの整備という観点から不十分であること，③大学と産業界等との間において，大学院が養成する人材像と産業界等の評価や期待に関する認識の共有が十分でなく，修了者が産業界等の社会の様々な分野で活躍する多様なキャリアパスが十分に開かれているとは言えないこと，といった問題点が見られる

(http://goo.gl/Jq0LU, pdfファイル，5ページ目)

文科省は，博士号が担保するものに関する共通理解は無い，と述べています．また，教育の質もバラけていることを指摘しており，このことも共通理解の妨げになるかと思います．

個人的には，博士号は「専門知識」と「プロジェクト(研究)遂行能力」は担保していると思います．…が，サンプル数が少ないので断言はできません．

この「一般的な博士像の不存在」が，世間一般への博士の浸透を妨げていることは想像に難くありません．

現状は問題なのか

敢えて節を作って強調しますが，現状は問題です．

当の本人たる博士号取得者は活躍の場が減る，すなわちたつきの道の選択肢が減ります．

納税者の皆さんは，せっかくお金をつぎ込んで育てた人材が有効に活かされず，「税金の無駄だ！」と感じるかもしれません．

後進の学生は，この惨状を見て博士に進まなくなります(というかそうなってます)．

こうして，本丸たるアカデミックの世界ごとジリジリと衰弱し，…あとは言わずもがな．

どうすればよいのか

勿論，「これさえやれば万事解決!」みたいな簡単な処方箋はないでしょう．でも，チャレンジは出来ます．

私は，そのチャレンジの一環が今回の中教審の答申だったのではないか，と考えています．(というか資料はそれを物語っています)

すなわち，博士の質を担保すれば良いのです．

専門の知識だけではなく，基礎知識や計画力，語学力，倫理観などもちゃんと持っていることをQualifying Examで保証しましょう．

教育の質がばらけない様に，たくさんの先生で教育しましょう．

どこに放り出しても生きて行けるほど強くするために，総合的な教育もちゃんとしましょう．

そういった取り組みが，今回の答申の意図ではないのでしょうか．

この新課程を出た博士がその有用性をアピール出来れば，在野の博士号取得者にもスポットが当たり始めるでしょう．

さて，ここで，「大学院に進んでまで人に教育を受けるとかwww自分で学べよそれぐらいwww」という気持ちになる人もいるかもしれません．

正直，私も「それぐらいじぶんでするわい」と思ってたりします．

でも，主眼はやっぱり「質の保証」なんだと思います．ちゃんと大学院は「最低限」「共通して」一定の能力を持った博士を輩出しますよ，という保証．

さぁ，雇用者の皆さん，安心して雇用してください．

さぁ，経営者の皆さん，安心して共同事業を博士が経営するベンチャーと行って下さい．

さぁ，保護者の皆さん，安心して博士の教員を迎え入れてください．

そういう事を，皆が自信を持って主張できるように，ということでしょう．

ちょっとやりすぎじゃないのか？

ええ，上記の効果を狙ったとしても，逆効果になる部分もあるでしょう．

徒弟制を完全廃止すると，一本軸の通った研究ができなくなって，結果として「スペシャリスト」にもなれなくなります．

(念の為に再度主張しますが，博士は「スペシャリスト」の能力を最低限備えてなければなりません，と考えています)

博士課程に進学希望の学生が修士論文書かないと修士/博士の間のフレキシビリティを損なうことになります．

なので，細かい部分は考える必要があるでしょう．

でも，今回みたいに，現在抱えている問題に対してちゃんとコミットメントしたということで，私は文科省をちょっと見直しました．

というかなんか雰囲気で「お役人は肝心なことに取り組まない」みたいな思い込みがあったのですが，やっぱりそんなこともないよなぁ，と思いました．

なんせ，前述の「博士漂流時代」を読んで気になったことを調べ始めたら，殆ど中教審の資料にまとめられていたのですから．

さて，長くなりましたが，これにて本エントリはお終いです．お付き合い下さり誠にありがとうございます．

ご意見，コメント，批判，大歓迎です．皆さんの意見を知りたいです．

私のtwitterアカウントはhttp://twitter.com/aion_a_rapですので，何か有りましたら．

Permalink | 記事への反応(4) | 14:04

2010-07-02

■XmlSerializer vs SoapFormatter

.NETでオブジェクトの永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。

全体的に速度が重要な場合か永続化するオブジェクトが単純な場合はXmlSerializerを、それ以外の場合はSoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター。

あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。

Permalink | 記事への反応(0) | 00:14

2009-12-01

■http://anond.hatelabo.jp/20091201013806

普通にクロージャという場合、レキシカルスコープを持つことを期待されると思うけど、DLLやらsoからエクスポートされる関数は普通のCのスコープだからクロージャとは言わないと思うよ。（そもそもDLLもsoも標準C/C++じゃないから、もしこれらがクロージャ的な動きをするとしてもこれを以て「Cのクロージャ」と呼ぶのはおかしいというのは置いといても。）

ダイナミックスコープなemacs Lispのlambdaとか、ダイナミックスコープもどき(っていうのか?なんて表現したらいいか分からん)なPHPのcreate_functionは動的に作りはしてもクロージャとは言わないんじゃないかな。

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%B8%E3%83%A3

Permalink | 記事への反応(0) | 03:30

2008-10-15

■[増田に聞け][プログラミング]いまいちな用語

javascriptを理解するためのたった2つの大切なこと、javascriptを理解するためのたった2つの大切なこと:改(改があるなんて知らなかった）を読んで感じたところ。

束縛、レキシカルスコープ、クロージャーがミソなんだけど、イメージが掴み難い用語だと思う。

増田のみんなだったら、もっといけてる言葉にしてくれそうなんで、聞いてみる。

みんなだったらなんて呼ぶ？

Permalink | 記事への反応(1) | 12:55

2008-06-21

■[perl]もういつでもどこでもだれでもMooseでいいじゃねぇか

おれはもうMooseしかつかわねぇ。後にも先にもMooseMooseMooseMooseMoose!!!!!!！！！！！１１１１１１１

ってな人の為にいつでもどこでもMooseする。automooseを実装しますた。


package automoose;
use strict;
use warnings;

sub import {
    strict->import;
    warnings->import;
}

package automoose::before;
use Moose; no Moose;

package automoose::after;
use Moose;

my @before  = keys %automoose::before::;
my @after   = keys %automoose::after::;
my @exports = do { my %u; @u{@before} = (); grep { !exists $u{$_} } @after };

package UNIVERSAL;
use Moose;

for my $func (@exports) {
    __PACKAGE__->meta->remove_method($func);
    __PACKAGE__->meta->add_method($func,sub {
        my $class = shift;
        my $auto  = $class.'::__auto__';
        no warnings 'redefine';
        local *Moose::_get_caller = sub { return $class };
        Moose->import( { into => $auto } );
        my $code = $auto->can($func);
        $class->meta->add_method($func,sub {
            shift;
            goto $code;
        });
        goto $code;
    });
}

1;

使い方はいたって簡単。useするだけ。


use automoose;

my $obj = Foo->new;

いきなりnewが呼べちゃう。

他にも


use automoose;

Foo->has( hoge => is => 'rw' ,default => 9999 );
Foo->has( muge => is => 'rw' ,default => 7777 );

print Foo->new->hoge;
print Foo->new->muge;
Bar->extends('Foo');

print Bar->new->hoge;

ょーかんたん。げーべんり。

しっかしこれ、automooseだけど実装するの結構めんどかったのよ。Moose-0.44をベースに作ったんだけどさ。

Moose内部で使用している$CALLERって変数がレキシカルなもんだから、どうやってそれを外から制御すればいいのかすんごい苦労したわけさね。

で結局importの引数にinto渡してさらにMoose::_get_caller関数を上書き無理矢理ハックしたってわけさ。

でもね。でもね。でもね。ちょっと聞いてよ。

ふと最新のMoose-0.50見てみたらさ、Moose::__CURRY_EXPORTS_FOR_CLASS__なんて関数が定義されてるわけよ。

外から明示的に$CLASSを変更できるインターフェイスなわけよ。おいおいおいおい、勘弁してくれよ。こっちゃ折角苦労してハックしたのにあっさり公式対応するなってばよ。メゲルヨ？ぼく。

まぢめげるよ。めげる。ってかもうめげたよ。もうMooseなんてつかわんね！つかわんね！

Mooseなんて大嫌いだー！

俺はMooooooooooseをやめるぞぉおおおおおおおおお、ＪＯＪＯぉぉぉおおおおお！！！！１１

プログラ増田のあなぐら

Permalink | 記事への反応(1) | 13:47

2007-06-22

■javascriptを理解するためのたった2つの大切なこと:改

9割ぐらいはハッシュ

何がハッシュなのか

javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。

var arr = [0,1,2,3];

とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。

これは

var has = {0:0,1:1,2:2,3:3};

と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。

ためしに

arr[4] = 4;
arr['x'] = 'string';
arr[-1]  = -1;

としてみよう。

Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。

でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。

それどころかarr.xで'string'がかえってくるんだ。

別の例を見てみよう。

var fx = function(){};
fx[0] = 'somestring';

こうするとfx[0]に'somestring'が束縛される。

つまりfunctionも一つのハッシュだったんだ。

これでほとんどのものがハッシュだということが解ってくれたかな？

ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。

ハッシュへのアクセス

ハッシュへはhash[name]でアクセスすることが出来る。

それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。

これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。

関数のあれこれ

無名関数

関数には名前を付けなくても使用可能だよ。

function(x){return x+x}(2); -> 4
宣言文

関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？

function funcname(args){ do something};

でもこれはsystax sugerだってことを知ってほしい。

上でも使ってるんだけど。

var funcname = function(args){ do something};

と等価になる。もちろんどちらの書き方でもかまわないよ。

ただ、(無名)関数を宣言してそれをfuncnameに束縛しているっていうことを理解しておくと便利だよ。

スコープ closure

javascriptはレキシカルスコープを採用してるんだ。

レキシカルスコープなんていうと難しく感じるかもしれないけど、結構単純なんだ。

var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}

これの実行結果は以下になるよ。

fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'global'

fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。

でも以下のような場合に注意してほしいな。

var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){x = 'local';return x}

fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'local'

fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。

つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。

別の場合を見てみようね。

var x = 'global';
var fx1 = function(){
  var x = 'local';
  return function(){return x}
};
var fx2 = fx1();

x -> 'global'
fx2() -> 'local'

この例だとfx2()の値がlocalになってるね。

なぜなら外側スコープっていうのは関数を評価した場所じゃなくて、関数を定義した場所の外側なんだ。

関数は返り値として関数やハッシュを指定できるよ。

一つ上の例では実際に関数を返り値にしているね。

戻り値に関数を指定するとこんなことが出来るよ。

var fx1 = function(){
  var x = 0;
  return function(){
    x = x+1;
    return x;
  }
};
var fx2 = fx1();
var fx3 = fx1();

fx2() -> 1
fx2() -> 2
fx2() -> 3
fx3() -> 1
fx3() -> 2

fx2とfx3の値が違うのはそれぞれ別の関数が作られるからだよ。

こんな風に関数が状態を持つことも出来るんだ。クロージャーとよんだりするよ。

関数がハッシュを使って複数の関数を返すとこんなことも出来るよ。

var fx = function(){
  var x = 0;
  return {
    'up':function(){
      x = x+1;
      return x;
    },
    'down':function(){
      x = x-1;
      return x;
    }
  }
};
var obj = fx();

obj.up(); -> 1
obj.up(); -> 2
obj.down(); -> 1
obj.down(); -> 0

最後に一度ハッシュについてもうちょっとだけ。thisのはなし。

thisという機能があるよう。ちょっとだけつかってみるね。

var x = 0;
var add = function(n){this.x = this.x + n; return this.x};
var mul = function(n){this.x = this.x * n; return this.x};
var obj = {'x':0,'do':add};

add(1);   -> 1
add(1);   -> 2
mul(2);   -> 4
obj.do(); -> 1
obj.do(); -> 2
obj.do = mul;
obj.do(); -> 4

thisは評価された場所によって値がかわるよ。

objの中にいるときはobj.xを扱うし、グローバルにいるときはグローバルのxを扱うんだ。

http://anond.hatelabo.jp/20070620200618を改訂してみたよ。

このぶんしょうがjavascriptを覚える上の一助になるとうれしいんだ。

あとここでつかってるハッシュは伝統的な意味。連想配列のことね。

突っ込みも大歓迎だよ。

Permalink | 記事への反応(2) | 10:13

2007-06-20

■javascriptを理解するためのたった2つの大切なこと

9割ぐらいはハッシュ

何がハッシュなのか

javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。

var arr = [0,1,2,3];

とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。

これは

var has = {0:0,1:1,2:2,3:3};

と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。

ためしに

arr[4] = 4;
arr['x'] = 'string';
arr[-1]  = -1;

としてみよう。

Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。

でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。

それどころかarr.xで'string'がかえってくるんだ。

別の例を見てみよう。

var fx = function(){};
fx[0] = 'somestring';

こうするとfx[0]に'somestring'が束縛される。

つまりfunctionも一つのハッシュだったんだ。

これでほとんどのものがハッシュだということが解ってくれたかな？

ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。

ハッシュへのアクセス

ハッシュへはhash[name]でアクセスすることが出来る。

それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。

これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。

関数のあれこれ

スコープ

javascriptはレキシカルスコープを採用してるんだ。

var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}

これの実行結果は以下になるよ。

fx1() -> 'global'

fx2() -> 'local'

fx1() -> 'global'

fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。

でも以下のような場合に注意してほしい。

var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){x = 'local';return x}

fx1() -> 'global'

fx2() -> 'local'

fx1() -> 'local'

fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。結果fx

つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。

宣言文

関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？

function funcname(args){ do something};

でもこれはsystax sugerだってことを知ってほしい。

上でも使ってるんだけど。

var funcname = function(args){ do something};

と等価になる。もちろんどちらの書き方でもかまわないよ。

ハッシュを返す関数、関数を返す関数。closureとthis

関数は返り値として関数はハッシュを指定できるよ。次のハッシュを返す関数を見てみよう。

var fx = function(){
  var x = 0;
  return {
    'x':x,
    'add1':function(y){this.x = this.x+y;return this.x},
    'add2':function(y){x = x+y;return x}
  }
}
var obj = fx();

実行結果を見てみよう

obj.x -> 0
obj.add1(0) -> 0
obj.add1(0) -> 0

obj.x -> 0
obj.add1(1) -> 1
obj.add1(0) -> 0
obj.x -> 1

obj.x -> 1
obj.add1(0) -> 1
obj.add1(2) -> 2
obj.x -> 1

となる。

add1はthis.xにたいして演算をしている。つまり返された値が変化しているんだ。

add2は関数fxに閉じ込められた値に対して演算している。つまりこれらは別の値なんだ。

とここまでかいたら疲れた。

読んでくれた人ありがとう

追記

落書きのつもりでかいたんだけどブクマがついててびっくり。

ちゃんとまとめてなかったし、自分のブログに描いても見てくれる人はいないから増田に書いてみたよ。

ほかの言語や技術についても同じような解説が欲しかったら何らかの方法で言及してくれるとうれしいな。

さらに追記

ここまではてブが300突破してるみたいだけどいま、自分のブログへリンクを張ったら増田に書く意味がなくなるんじゃないかと思うんだ。

やらないけど。

こんなのもかいてみたよ、増田で。　http://anond.hatelabo.jp/20070621153600

Permalink | 記事への反応(9) | 20:06

2007-04-30

■ブロック付きメソッド呼び出し/レキシカルクロージャについて

「ブロック付きメソッド呼び出し」がわからん、ということでいいのかな。この概念は是非とも解ってほしいので、今日始めて Ruby を触った俺が頑張って解説しよう、と思ったけれど、いいドキュメントを見つけたのでリンクしておくよ。

これで解らんかったらOn Lispを途中まで読みんさい(お金がないならWeb 版をどうぞ)。「ブロック付きメソッド呼び出し」は元々関数型言語の界隈で「レキシカルクロージャ」と呼ばれるもので、要するに中身は一緒なのでクロージャが解れば「ブロック付きなんたら」も解る(Ruby を触ったことのない自分が「ブロック付きなんたら」を理解しているのはこれの為)。 On Lisp は Common Lisp という言語の本なんだけど、 Ruby は言語仕様の多くの点で Common Lisp を参考にしているので、勉強するのはそれほど難しくないと思う(つまり見た目はヘンテコだけど中身は Ruby ってこと)。

Permalink | 記事への反応(2) | 14:10

<前の25件
ログイン ユーザー登録
ようこそ ゲスト さん