  |
はてなキーワード: コンポーネントとは
nginxはキャッシュつかってませんし、php-fpmはインストール後のデフォルト状態、
Mysqlはインデックス適当でQueryCacheもOFFの状態…
前半で書いたとおり、サイトのスピードは現状adsenseの表示スピードに
引っ張られているので、このまま。
->aboutとかその辺
いろんなソシャゲのページを作りたかったので、
１．ヘッダー
２．サイドバー
３．メインコンテンツ
３,５．ページャー
４．フッター
またそれぞれ、総合ページからしか見られないコンポーネントと、
それぞれのコンポーネントをユーザ関数ではなく、ファイルをincludeする形で
最終的なinclude用のファイルが18個…
このあたりphpのプロの方はどうやって対処してるんでしょう…
ファイル+functionで分けてるんでしょうか…
また、総合ページとゲームカテゴリページのトップページのSQLの内容がぜんぜん違うため、
abbench（前半参照には情報だしてます）では秒間の処理可能数が倍（総合ページ100req/sec ゲームカテゴリ250req/sec）となっています。
細かく見ると、総合ページではカテゴリー一覧をselectした後に、記事リストをカテゴリーリスト別にselectしてますが、
各ゲームカテゴリページでは１回のselectで終わっています。
現在はゲームカテゴリは３つしか作っていませんが、将来的にはもちろん増やす予定ですので、
今後どんどん重たくなっていく見込み・・・
RSSフィードを取得するCronにあわせて総合ページのメインコンテンツ部分を静的HTMLにしていくのもありかなと。
そうすると負荷がかかるのは作成時の１回のみになるとおもいますので、ユーザさんから見たら早いページ表示になるかと。
ただし、総合ページってどれくらいの人がみられるんですかね…
巷のアンテナサイトさんは、ハテブのブックマーク数やtweet数などのSNSの評価数や、あとで読む機能、
特定のサイトを非表示にする機能など、結構いろいろな機能が付いてます。
今回は夏休み終了に間に合わせるために、というのもあって、ばっさり機能を落としましたが、
こういう機能って必要なんですかね・・・？ 個人的に使ったことがないもので・・・
そういうニーズがあればつけてもいいとおもっているのですが、現状遅いサイトをさらに遅くはしたくないので、
adsenseを１個にして機能をつけるくらいなんでしょうかねー。
adsenseまったくなしだと、鯖代の維持がもったいなくてサイト閉めちゃう方向に動きたくなっちゃいますし。
プログラムのリファクタリングとデザインの変更は必須だなとおもっています。
とくにデザインは早いうちにどうにかしないといけないんですが、
これだけは自分のスキルにないので、そのうちLancersのお仕事一覧にのっちゃうかも…
もちょっといろいろなサイトを見て回って、構想を深めたいのですが、
個人レベルでの大規模サイトって、なかなかノウハウないんですよねー。
ある程度たまったら、こうしてみたらいいじゃない？ってのをまたここに書ければいいなぁとおもっています。
以上、長々とサラリーマンの日記を見てくださってありがとうございました。
（なんか規約違反で通報されたので、サイトURLと前半の日記へのリンクはなしでお願いします。
というより、ここまで書いててなんだけど、増田って書くの初めてだから正直どういうルールかわかんね
「レーザー核融合反応の実験に成功、クリーンエネルギー実現か＝米国」という表題の記事がひどい。という話。
http://news.searchina.ne.jp/disp.cgi?y=2012&d=0720&f=it_0720_001.shtml
大元の記事だと思われるアメリカのローレンスリバモア国立研究所のプレスリリースが下記。題は「National Ignition Facility makes history with record 500 terawatt shot」
https://www.llnl.gov/news/newsreleases/2012/Jul/NR-12-07-01.html
この元記事の題名を見るだけでも大まかにわかるとおり、LLNLの発表した内容は核融合反応に関するものではなく、レーザーに関わるもの。おおざっぱに言うと「安全保障（要は水爆関連）や基礎研究、核融合発電などの研究に用いる大強度レーザー装置の増強、整備によってついに500TWのピークパワーを持ったレーザー発振に成功した」という内容。ちなみに「地下核実験を不要にする唯一の施設」なんて書かれてたりして、実は核融合エネルギーについては大して書かれていない。
そんなわけでサーチナの記事とその元になったチャイナネットの記事はなぜかこれを「核融合に成功して500TWを出力」という記事に書き換えていているという意味で間違っている。が、間違いはそれだけではない。レーザー核融合は「レーザーを燃料球に当てて爆縮し、核融合反応を起こす」ものであるにもかかわらず「「衝撃点火」方式による人類史上もっとも威力のあるレーザー光線の放射」と表現していて、あたかも核融合反応によってレーザーが放出されたかのように書かれているので因果が真逆になっている。ちなみに「衝撃点火」という言葉は元のプレスリリースには含まれておらず、チャイナネットの記者が勝手に付け加えたもの。衝撃点火は阪大のレーザー研が概念として提案している核融合反応の点火手法の一つで、未だ実験は行われていないしLLNLは中心点火なのでこれまたおかしい。
あとついでにNIFの話
LLNLのNIFは核融合研究のための世界最大のレーザー発振施設な訳だけど、実際は水爆のシミュレーション施設としての機能が強い（というか予算は安全保障メイン）。NIFの実験は間接照射の中心点火といって、「金の円筒内部にレーザーを照射、発生したX線で燃料球を加熱、爆縮して核融合を起こすシステム」だが、これは水爆の「原爆の起爆によって発生したX線などによって燃料球を爆縮、起爆する」に近いプロセスで、こういう実験によって水爆関連の研究を行っていることがNIFを「地下核実験を不要とする施設」だと評価する理由であり、NIFが高速点火（阪大などがより核融合発電向きであるとして提唱する点火手法）を採用しない要因になっていると考えられている。(高速点火には主加熱源よりも短パルスな加熱が必要だが、核弾頭にそんなものは組み込めない)
一方で日本の阪大や光産業創成大学なんかがやっている高速点火は「発電炉」に特化した研究が行われている。たとえば「大出力・高繰り返しの半導体レーザードライバーの開発」「発電炉に必要な1秒に10回程度の核融合反応」「1秒に10個使われる燃料球をリアルタイムに生産するシステムの開発」などである。
阪大も光産業創成大もレーザー出力はNIFに数段、もしくは数桁劣るものの、「核融合発電」研究の最先端は日本であると言って過言ではない。
ちなみに、もう一つの核融合発電コンセプトであるところの磁場閉じ込め核融合は現在フランスに国際協力下でITERと呼ばれる実験炉(発電可能レベルのプラズマの数分の保持やより長時間の保持、商用発電炉で用いるコンポーネントの実証が目的)を建設中であり、未だ実験炉の設計すら始まっていないレーザー核融合に比べると数歩は先を行っているのが現状である。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
http://anond.hatelabo.jp/20110908093243を可能な限り段落を再現してエキサイト先生に翻訳して頂きました！
長い間、私は暗箱にいます。
私が箱の外部で聞いた誰かのコメントによれば、劇薬を含んでいる小さなボトルは、この箱に位置します。ボトルは完全に密閉されますが、ハンマーはボトルの近くに配置します。また、彼らは、ハンマーがある時に倒れるだろうと言いました。
いつになるかは「ある時間」です?私は知りません。このまさに瞬間に?あるいは遠い将来?恐らく、それは既に来ました(私はそれに関して考えたくありません)。誰もハンマーに影響することができません。独立事象として、それは、見込みで50%倒れるでしょう。見込みはちょうど50%です。ひょっとしたら、ボトルは壊されるかもしれないしあるいはだろう。自分に関して、死者、あるいは、生きている。
私は言わなければなりません、状況はどれくらい恐ろしいですか。
私は、猛烈な憤慨を持たないようにはすることができません。私の人生(私のための最も重要な問題)は、私から完全に離れており、単純な図、FIFTY PERCENTに単独で依存します!あまりに恐ろしい。
さらに、私は、それは完全に不合理であると思います(そして)。私は、ちょうど50%で見込みを維持する多くの方法で束縛されます。
視覚。箱は、任意の光から完全に保護されます。それは、ボトルと装置を見つけるおよび破壊することから私を回避するためにあります。完全な暗さ。私は完全な暗さにいます。したがって、今、私は、自分のアウトラインさえ見ることができません。恐らく、それは奇妙に思えます。暗さは私に私の体自体の存在について疑問を抱かせます。
聴覚の知覚。恐らく、私が上に言及した理由から、完全な遮音は使用されます。私は、私自身の音声さえ聞くことができません。私はメカニズムを知りません。まず第1に、私は、何も見ることができないとともに、どのようにそれを調査することができますか。したがって、これは恐らく推測だけです、私の鼓膜はこの箱の中の包囲の前に破損されました、あるいは、ある特別の資料は箱の壁に使用されます。
とにかく、光と音の保護であまりによい暗箱では、ちょうど用語が示すように、私の視覚的・聴覚の知覚は死んでいます。
あたかも一層の確認が必要かのように、私を極度に圧迫する巨大な疲労は私のための別の拘束物です。それらは努力から私を回避するために私にある種類の筋弛緩剤を与えたように見えます。私が同じ姿勢から変わることができないとともに、私の触覚はほとんど麻痺しています。
光はありません。音はありません。匂いと味は信頼性が低い。触覚は不調にあります。私は操り人形に似ています。すべての五感は私のコントロールが不足しています。あまりに残酷です。完全な拘束物。それらが睡眠薬を与えていた場合、私は望みます。私は、外傷のない苦悩にいると思います。私の生活(私の存在(自体))は完全に無視されます。そのような屈辱は私の正気を維持します。そのような屈辱だけができます。
自分の生および死をコントロールする権利は完全に奪われます。私はそのような状況を嫌います。私の生活の連続性の中核決定要素は完全に依存します、で、単独で、で、純粋な見込み。誰からでも完全に遠方に、意志があります。私は再びそれを嫌います。私はそれを嫌います!
なぜ私は、そのような箱で囲まれなければなりませんか。そのような途方もない箱では、なぜ私は、そのような完全な拘束物を備えた、生命不安および死にいなければなりませんか。
私は孤独です。私は、中身がなく、水平に感じていますか。すすり泣かないようにすることが困難です?番号私の孤独ははるかに深い。私は空間の海でいます。私は一人です。完全に孤独です。孤児として、私はこの無限の暗さに向けられました。私は絶対零度の中で震動しています。
この箱に展望はありません。暗さだけがここにあります。私はボトルとハンマーを感じることができません。私は壁、底および天井をまた感じることができません。それらはそこにあるに違いありません。しかし、私の五感がすべて奪われます。何もないように、私は感じます。それらのものがいくつかの意味を持っている一方。
正直に話して、私は、箱にいるかどうかそれほど分かりません。私は、私の姿が存在すると確信します。私は考えています。私は空想しています。それは証拠である、私の独自性を示すこと、呼ばれる、自我あるいは意識、あるいは心、固体です。しかし、独自性はありますか、本当に箱で囲まれる?それが別のスペースで浮かんでいることはありえますか。私はそのような疑問を除去することができません。
恐らく、私がここでであるものは、宇宙に結局浮かんでいるか、あるいはマリアナ海溝の底に横になっています。あるいは恐らくキラウエア火山の穴から下降して行くこと。
私には、箱(私を囲んで)がどのようにか知る方法がありません。私の感覚はすべて死んでいます。私は、ここに、箱の内部があるかどうか判断することができません。
私は、本当に生きているように、それに加えて、確かではありません。私には、そんな単純なものを確認する方法がありません。恐らく、50%の見込みは私を越えて既に通過しました。恐らく、私は既に死んでいます。私はまだ、恐らく生きています。浅くて、筋弛緩剤を注入された、呼吸する、弱い心臓の鼓動。あるいはそれらのすべての停止(単に去る肉大型丸薬)。
私は私自身の身体をコントロールする任意の能力を奪われます。誰が私の心が重大な活動を継続する身体に存在すると言うことができますか。五感は完全な暗さで毒されました。それらは感覚器として機能することができません。私は、真実を知る見込みがありません。恐らく、どんな推測も一人で作り上げられます。私を包む状況および自分の独自性は恐らくプログラムされた回転プレーのコンポーネントです。
私の存在に関して、私は振る舞いを決定することができません。私は、それを認めることを嫌います。しかし、私は変動の最中です。
私は、誰かが私を見つけることができたらと思います。私は、誰かが箱を開くことができ私がいかがか言うことができた、らと思い、私がどういう人か決めることができました。私の内側にそうするのに十分な力はありません。私ができるのは孤独の中で震動し続けることです。
もし神ならば、私は言うことができるでしょう「そこにさせる、軽い。」私は、それが不可能なことを知っています。しかし、私は、私がそのように言うことができたならばどれくらい素晴らしいだろうか思わざるをえません。
私自身の自由意志!それは、自分を取り巻くすべての変動を固定することができました!
同時に、切望は影を生産します。箱が開かれるなら、私は見つかり観察されましょう。その結果、私の姿は決定されるでしょう。実を言えば、私は決定を心配しているという事実から視線をそらすことができません。
一人で生きているか死んでいるかどうか判断することができませんが、私は死を恐れています。残念ながら、私は死者として決定します。私は受理することができません。まだ、私は感じることができません。私は特定の現象として死を想像することができません。恐らく、そのため、私は死を恐れています。
いいえ、それは私に制限されるべきではありません。高潔なキング。致命的な殺害者。規則的な人々。すべての同じ。恐らく、悪い疾病の年上の人々あるいは患者は、十分に真実の死に近いある想像を持つことができました。しかし、それでも、死の特定の経験を知ることができません。
結局、死は圧倒する重要性を備えた最終仕向地です。時間と意識は絶対的な不可逆性を持っています。死にはさらに変更することができない完全無欠さがあります。それが儀式の通過点あるいは顕著な印象的な出来事でも。
私自身、ここの私の心はそうです、そのときは消えられるだろう、どれ、私がいかがかが決定されます。それらが生ぬるい水(私はその中で温度を感じることができない)から奪う場合、私は、大気に身をさらさないようにはすることができません。
私はそのような不可逆変化を恐れています。それは死の決定に制限されていません。さらに、非常に心配しているので、私は生きていて決定されます。
自分の現在の存在は、無限のポイント上に立っている小さく小さな幻覚に似ています。それほど大きくない。それほど小さくない。それほど長くない。それほど短くない。拡張はありません。収縮はありません。ユニークな単一のポイントで立っていること。それは数学上正確です。私は、自分の同一性に関する混乱があるそのようなポイントでとどまるゴーストのようなものです。
ポイントは同時(ある位置で既存でない)に座標の飛行機ですべての位置で存在します。ある出来事が生じれば、その瞬間においては、それは、すべての地空(あたかも私の招待がバスから降りるかのように、出来事がその中で生じた)中の単一のポイントに私を集中させるでしょう。関係なしで。ポイントと私がものだったとしても。
幻覚(それはそのようなポイントでとどまった)は、等しい程度に対して、実際で霧のように消されているの可能性を持っています。
さて、私はすべての配当通過時間の中で既存です。そして、私はすべての自然を持っています。同時に、私は孤独からそれを受けています、私はすべての自然から離れています。私は、誰かが私を見つけることができることを望みます。同時に、私は非常に心配しています、私はどこにいてそれ、私はその瞬間にいかがでしょうか。
http://anond.hatelabo.jp/20090713004520
の具体例として書いてみる。
都内を走るのに、ロードよりのクロスがいいなと思って、さあ買いにいこうと思ってもやっぱり悩む悩む。
ので、いくつかよさげ、もしくは5万円付近で定番のものをリストアップしてみた。
ただ、言えることはどんなに悩んでも買ってから乗ってみるとめっちゃ楽しい。なのでこの中でもそうじゃなくてもいいけれど、なんでも買ってみるのをおすすめ。
HTMLとかCSSの書き方をずいぶん忘れている。リハビリが必要だ。
そう思ってCSSの本など買ってみた。
今まであまりにも適当にCSSを書いていたので、この機会にちゃんと理屈を学んでおこうと思って。
今日その本が届く予定。
昨日も同じことを書いているんだが、ロードバイクが出来上がるのが楽しみだ。
事あるごとに思い出してはにやにやしている。変態だ。
どうも自転車店に来る常連っぽい人たちはおかしな人たちが多い気がする。
なぜいつも彼らはニヤニヤしてるんだろう。麻薬でもやっているみたいだ。
誰もいないような夜の山へ走っていって帰れないんじゃないかと不安になりながら、
筋肉を引き絞って汗をかいていることが好きって意味では自分も同類なのかも。マゾなのか？
フレームやホイールはすごく悩んで決めたものなので届く前から思い入れもかなりある。
コンポーネントは以前、友達の自転車についていたコンポーネントで、いつか自分もつけてみたいと思っていたもの。
シートについてはお店がいくつか貸してくれるようなので、しばらく借りてみてどれにするか決めることができる。
このお店に当たったことが幸運だった。
都心のお店は忙しすぎて全体に至るような細かい長時間の相談はしにくい。
だが自転車を一台組むとなると恐ろしく長い様々な検討が必要だ。合計すると数十種類ものプランを考えて片っ端から捨てたり拾ったりする。
このパーツと組み合わせる場合はこういう問題があって、どうしたら解決できるのか、とか、
すべてのパーツを組み合わせたときに最終的にどういう自転車になるのか、ということを何度も考え直す。
特に自分は最近のパーツ動向についてよくわかっていなかった。店員と話す時間の数倍の時間を使ってネットで調べた。
カーボンフレームはどの程度普及していて、耐久性はどのくらいありそうか。
チューブレスは使えるのか。維持するためになにをしたらいいのか。
ビンディング、シューズの種類とシューズのフィット感、硬さの影響。
大規模に展開しているお店はロードバイクにあまり詳しくない、素人みたいな人が店員だったりする。
ロードバイク屋の店員をやるなら毎日数十キロ走っているくらいの人でちょうどいい。
自分の売っているパーツを全部使ったことがあるような人。毎年フレームを使い潰してしまうような人が望ましい。
家の近くの有名なお店は店員は優秀なんだけど、職人的で無愛想すぎて話がしにくい。有名なお店は無愛想になる傾向にある。
もちろん海外から直接購入すれば安くつくのだけれども、余分にお金を払っても彼の店で買い物をしたい。
そもそも全部をカスタマイズして組んでくれる通販なんてないし、自分で１から組み上げる力もないので、ある程度自由にパーツを選びたかったらどこかのお店で買うしかないことはそうなんだけど。
そういえば昔、横浜にあったロードバイクの店はどうなったんだろう。
ある日、突然お店がなくなってたけどやめちゃったのかなあ。
どこかでひっそりと再開とかしていないだろうか。
KUOTAのKEBELを買おうか迷っている。http://www.intermax.co.jp/products/kuota/kebel.html
カーボンモノコックフレームでは比較的安い方だし、デザインも悪くないので候補にしている。
剛性はそこそこ高く、実業団が練習に使うくらいだから信頼性は問題ないだろう。
コンポーネントはアルテグラあたり。デュラエースはどうみてもオーバースペックだし、耐久性やメンテナンス性から電動は使いたくない。
ホイールはイーストンのEA70を考えている。（価格的にもう１ランクくらい下げたいんだが、ちょうどいいのがない）
ハンドルはアナトミックであればなんでもいいようなものなんだけど、いい感じのが見つからない。
見つからなければハンドルはお店の人に聞いて適当なのをつけると思う。
エコだの「地球に優しい」だので自転車（クロスバイク）がちょっとしたブームになったようだから、特に自転車弄りをしたくはないけれど、クロスバイクに乗りたい人に向けて。
以下3点と、蛇足。
1万円以下の自転車は今すぐ捨てたほうがいい。ろくでもない。そういった自転車は鉄の値段の上昇に反比例して重量が軽くなったりする。自転車は比較的単純な機械だが、それでも人間が乗ってそれなりに高速で移動する機械である。命を預ける乗り物が1万円でいいはずがない。
クロスバイクの予算に5万円は欲しい。最初は10万円以下で選んで、だんだん自転車が分かってきたらもっと高いものを買う。自分の求めているものがはっきりしてきて、どういった自転車が自分に合っているのかが明確になる。もちろん、いきなり高級車に乗ったっていい。若葉マークのSクラスだって走っているはず。
ちなみにシティサイクル（ママチャリ）でも、安全面・耐久面を考えると2,3万は出したほうがいい。
いくら良い自転車であっても、自分の体格に合わないものは全くダメである。これはコンポーネントやフレーム云々以前の問題。靴と同じで合わない自転車は乗っていて辛い。
フレームサイズがある程度の目安にはなる。ただし、これはあくまでも目安。適正身長の範囲にあるのに乗り辛く感じる自転車もあれば、大きなフレームでもきちんと乗れる自転車もある。フレーム各部の角度や、クランクやハンドル等のパーツによって合う合わないは決まるからである
だから試乗の出来ない通販はやめるべき。もちろんあらかじめ実店舗で試乗させてもらい、その上で安いネットショップから購入するというやり方が出来ないわけではないが…
要するに、サスペンション。路面が荒れているとか、歩道を走ることも考えられるとか、そういった理由でサス付きがすすめられたりするかもしれない。しかし、メンテナンスが面倒。エアでもオイルでも、あるいは単なるコイルばねだったりエストラマーを組み合わせたり、とにかくメンテナンスが手間。その上重量がかさむ。力のロスもある。
10万円以下の自転車についているサスは、きっぱり安物。まともなサスが欲しければお金払うほかない。だからサスなしがおすすめ。乗り心地が気になるというのであれば、タイヤとサドルで対応するべき。
ディスクブレーキのついている自転車もある。が、こちらもおすすめしない。10万円前後の自転車についているディスクブレーキはおそらくメカニカルディスクブレーキ。雪道、泥道を走らないのであれば選ぶ機能的理由はない。MTBなどに広く採用されているVブレーキよりも、泥や雪の影響を受けにくいところがディスクブレーキの大きな長所である。しかしVブレーキに比べて重く、機構が複雑で、本体や取り付け部に高い精度が求められ、おまけに錆びやすい。
Vブレーキもメンテナンスが当然必要だが、シンプルなぶんだけ簡単お手軽。しかも本体価格も維持費も安い。見た目優先でディスクブレーキだ、というのならそれもまた自由。たしかにディスクブレーキはカッコいい。ところで、個人的にはシマノNEXAVE（シティサイクル向けコンポーネント）のローラーブレーキが気になる。主に見た目。
それから、10万円程度の自転車はほとんどが台湾製であるということは知っていて損ではないかも。10万のビアンキはイタリア製では決してないし、ルイガノもカナダじゃ作っていない。日本の商社が名前だけ借りて台湾の自転車メーカーに作らせていたりする。もちろん別にどこで作ろうと構わない。重要なのは設計と生産であり、台湾だって悪くない。安いんだから仕方がない。
自転車ブームってどうなったんだろう。文字通りブームとして終わったんだろうか…自転車買った人は長く使えるよう、最低限のメンテナンスはしてください。
ブクマが20もついたので続き．
細胞骨格というと，モーターの役割つまり骨格筋における化学エネルギーの運動エネルギーの変換を取り持つアクチンミオシンすべり説が有名だけれど，細胞骨格はどうやら細胞生理において輸送作用をもち重要な機能を持つらしい．この辺を拡散モデルとの対比の分子モーターモデルで説明するのはちょっと理系のカップルならではかな．次元が減るのと熱物理化学的な親和性のための吸着力で輸送が可能になるというお話．細胞外骨格や結合基質もつながる．
結合組織は単に体の支持・結合に役立つだけではなく免疫・情報伝達・熱と物質の輸送等さまざまな機能がある．膠原病から反対に考えてみると普段の結合組織は発生と同様に機能が生理的に制御されている．
で，発生．発生はもう受精卵がヒトになるというので面白いこと請け合い．ちょっと妊娠の話とか混ぜて彼女の考え方を聞いてみてもよいかも，・・・，ではなくてモルフォゲンモデルという古典的な制御のモデルだけでなく最新のモデルの話もあわせて，アポトーシスの話や系統発生繰り返し説にふれてみるとよいかも．発生と完全に地続きのはなしになる．内部状態と環境とが幹細胞の分裂とできた細胞の分化とにかかわってくるんだ．
人間の器官レベルの制御機構は神経系と内分泌系が担っていて，後者の支配を前者が受け持つから神経系―受容効果系は人間の重要な部分．基本的には前者が高コストだから後者の低コストの制御も合わせて使うと考えればよい．糖の出し入れをいちいち神経で支配していたらエネルギーがかかりすぎる．
んで，システムズバイオロジーやさきほどの細胞間情報伝達のつながりで，ある細胞につきそこへの全入力（エネルギー（物質・輻射）・エントロピー・テンパラチャー）と全出力と全内部統合演算とを想定するモデルを考えられるから，細胞の出入力と内部統合につきシステムを建設することが多細胞でも重要なんだなどと自分の扱う細胞のシステム生物学の宣伝をしてみる．
単細胞でも人間でも何でもよいのだけれど，先ほどと同じで出入力と統合あるいは受容統合効果で考えることは同じ．で，感覚器からの情報を統合して，記憶などとも統合し出力をすることを考えるのだけれどこれがしこたま難しい．単細胞生物でも走性に記憶バイアスがかかることなんかが知られているけれど，ブラックボックスとして考えたくなる．強いて僕が考えていることはある入力に大しては特異的に発現しやすい出力があるということから統合のあり方を考えていくのと，神経の機能回路モデルを数学的に建設していくのと，があるけど全然専門外．恋した僕の気持ちも僕にはわからない．
地表（海含む）では重力が卓越していて生物や多くの物質は地表に束縛される．そこで単細胞生物と同様に生態系は多くのコンポーネントがあるシステムだと考えることができる．そのサブシステムとしては大陸・海洋・気象・太陽系との関係なんかがある．ある個体や生物種・生物群の動態は細胞内における細胞小器官の動態に似ているかな．どちらもシステム特性を規定しているのは物理法則だという点は共通．
ダーウィンはすごく頭がよかった．で『The Origin of Species by Means of Natural Selection: The Preservation of Favoured Races in the Struggle for Life』（1st,1859）のなかで
The slightest advantage in one being, at any age or during any season, over those with which it comes into competition, or better adaptation in however slight a degree to the surrounding physical conditions, will turn the balance.
という一節がある．（個体に変異が起こりその）性質がほんの少しでも有利なら生態系のバランスを変化さす，と括弧内をつけくわえてみると，変異と自然選択のモデルが考えられる．たとえば点変異がDNAにおこって対照状態で細胞生理の変化を定量的に計測ないしシミュレートするモデルとか．
僕の興味はというと数理モデルを物理法則のもとに組み立て細胞の制御システムモデルをリバースエンジニアリング的に，帰納することにあるんだよと再び告白．
承前：http://anond.hatelabo.jp/20091005002132
5-10万円くらいの予算があって、やっぱ自転車楽しいし乗りたいなー！でもロードとクロスとどっちがいいんだろう。。って人向けに違いを書いてみようと思う。
クロスバイクというのはロードとMTBの中間だって言われているけれど、実際はどっちかに寄っているものが多い。悪路を走るのでなければ、個人的にはロードよりのものがおすすめ。ロードよりとクロスよりの違いは、下に書く。
前輪がついているフォークに、サスペンションがあるかどうか。サスペンションがあると、衝撃を吸収してくれる。だけどもちろん弱点はその分だけ重くなること、また剛性が減るので力をいれてこいでも、サスペンションに力が逃げてしまうこと。MTBよりはサスペンションあり、ロードよりはなし。サスペンションがないものをリジッドフォークと言ったりする。楽にスピードを出して走りたいならリジッドおすすめ。
ブレーキの種類が違う。ロードよりのものには普通のロードについているような、デュアルピボットブレーキがついている。対してMTBよりのものにはVブレーキという違うブレーキがついている。前者は主にスピード調整用、後者は固定する用なので、効きは後者のほうがよいと言われている。個人的にはデュアルピボットブレーキのほうがずっと好きで、それはメンテナンス性から。Vブレーキはメンテナンスに悩んだことが結構あるので。でもまあそんなに違わないと言えば違わないかも。
ロードにはドロップハンドル、クロスにはフラットバーハンドルがついているものが多い。しかし、クロスでもドロップハンドルのものもあり、またロードにもフラットバーロードがある。ドロップバーの下の部分は実際には街乗りではそんなに使わないと思う。だからフラットバーでもいいと思うけれど、ちょっと競争っぽい感じになってくるとやっぱり姿勢の違いからくる空気抵抗で負けちゃうとかが多い気がする。好みの問題。ただし、どちらかからどちらかに換装するには結構お金がかかる。
タイヤ幅は、ロードは20-23cくらい、クロスは28-35cくらいの大きさが多い。タイヤの幅が狭ければ狭いほど路面抵抗が減るので、らくちんに走れる。安定性はあんまり変わらないけれど、耐パンク性、乗り心地などが幅が広い方がいいと言われる。でも実際幅のせいでパンクすることあんまりないし、乗り心地はまあ好み。おすすめは絶対細いタイヤ。走るのが楽だし、やっぱ疲れないので楽しく走れる。ちなみに径はだいたい700c。650cという小さい径のものもあって、こちらは慣性モーメントの点から出だしがスムーズ。
自転車の乗り味をほとんど決めるって言われてるフレーム。素材が重要で、クロモリ(クロムモリブデン鋼：鉄)、アルミ、カーボン、その他金属って感じにある。クロモリはしなやかで、乗っていて疲れないって言われてる。重量は重め。寿命は手入れがよければ長い。アルミは軽いけれど乗り味堅め、また疲労限がないので徐々に疲労する。だけど軽くて安価なのでアルミの自転車は多いし、いい。カーボンはご存じ巻き方とか繊維とかで全然違う。いまのプロが使ってるのはほとんどカーボンフレーム。特徴は値段が高いこと。フレームだけでだいたいは20万以上すると思う。その他はマグネシウムとかチタンとかスカンジウムとかあるけど、どれも高い。
ロードはロード用のコンポーネント、駆動系がついている。クロスはロードよりのやつはロード用の低いグレードのがついている(SORAとか)か、もしくはMTB用の低いグレードのがついていることが多い。個人的にはレースに出なきゃ、手入れさえしていれば街乗りにはそんなに影響しないのでは・・と思う。サードパーティ製のやつとか微妙な安いやつだと結局あとで変えることになったりするかもしれないけれど。
ということでいろいろ紹介してきました。まだ書き途中だけど、疲れてきたからまとめようかな。
好みですｗ嘘ですｗ
ロードでいいのは、スピードがやっぱりクロスより楽に出せて、さらに本格的にやろうと思えばそのまま山とかに走りにいけること。疲れずに進めて楽しい。デメリットは街乗りにはそんなに必要かな?ってこととか。あとはレース用が主なので、泥よけとか荷台とかつけると若干かっこわるくなる、とか。でもやっぱりロードはいいと思う。どんなのか決めて勝った方がいいけれど。値段はやっぱ8-10万くらいからなんじゃないかなあ。
クロスがいいのは、手軽さとママチャリにはないスピード。やっぱりちゃんと走ろうと思ったり、ロード乗ったことあったりロードといっしょに走ったりすると不満に感じる面は結構ある。だから用途によるんじゃないか。値段は4-10万くらい?安いのはどんなのか注意して買ったほうがいいと思う。
個人的に街乗りでおすすめなのは、かなりロードよりのクロス。重さが軽いし、スピードかんたんに出て快適だし、ロードほどレース用では全然ないし。もし、かなりロードよりのクロスで不満を持ったらそのときはロードを買えｗMTBよりのクロスはあんまり魅力感じないなあ。下に好きなクロスバイクスペックをのせとく。
ソフトウェア開発やシステム開発で、ソフトウェアやシステム内部のアーキテクチャに気を配るのと同様に、
顧客第一主義というのは、一種の盲目的に顧客を肯定する行為であって、きちんと顧客を見据えているかというと全く話は別である。
なにが大切か。それは、顧客の心を感じることだが、それはあくまで理想論で、実際には難しい。
そこで、次善の策として、顧客サイドのアーキテクチャに気を配る。
IT界でも、ソフトウェアやサービスをシステムおよびコンポーネントとして捉える考えが進化してきて、
「ITアーキテクト」という新しい職種が生まれた。
IT企業というと、顧客第一主義のイメージがないが、考え方としては顧客をしっかり見据えるためのフレームワーク
が整備された業界だと思う。
陳腐な顧客第一主義はもう要らないから、顧客をしっかり構造分析するようなアプローチが必要だ。
これには、心理的な分析や経済的な分析、社会学的な分析、それから実際にサービスを使うときの行動分析
といった様々な点からの分析が関係している。
先ほどIT業界は比較的フレームワークが整備されていると言ったが、それでもまだまだ顧客や社会を分析するための
多面的な方法論は整っているとは言えない。
言ってみれば、製品やサービスの内部構造ばかりが念頭にありすぎて、顧客分析は製品やサービスとのインターフェースを
作るために行う表面的なものに過ぎないといった状態である。
それでは企業利益にとってもよろしくない。顧客の心を真っ正面から分析することなく顧客の心に響くものを作ることは出来ないし、
顧客の行動を真っ正面から分析することなく顧客の行動をうながすこともできないし、社会を真っ正面から分析することなく
実際の成功例を挙げずにそういうと偉そうに聞こえるが、別に成功のコツを説きたいわけではなく、
いまはまだ顧客に関するシステム思考・コンポーネント指向的なアプローチは発展途上だけど、
だんだんと確実に世の中はそういうシステム思考・コンポーネント指向的な考えにシフトしてきているよという事実を指摘したいだけのこと。
何を言ってるのか分からない人はスルーしてくれるといい。
あなたが経営者ではなく被雇用者で、なおかつ何か先進的なことをやろうとする気がないならば、まだ今の時代でそれを理解する必要性はあまりないから。
国内で普通に手に入る(入った)機種であればどれでも同じである。違いを意識する必要は全く無い。
PS3専用ゲームの殆ど全てが720p(1280x720)、一部が1080p(1920x1080)に対応している現状、ワイドXGA(1280x728)かそれ以上の大きさであれば良い。
しかしこれらはいわゆる「ハイビジョン」「フルハイビジョン」と言われる解像度で、縦横の比率は16:9である(疑っているのならば電卓を叩けば良い)。ところが一般的なワイド型のPC用ディスプレイは縦横比率が16:10なのだ(最近は16:9の物も少数ながら発売されている)。そうなってしまった経緯は各自で調べてもらうとして、16:9の映像を16:10の画面にめいっぱいに出力しようとすると、当然ながら縦が1割ほど引き延ばされたような状態で表示されてしまう。まるで昔の香港アクション映画のように(実際はあまり気になるレベルではないが)。
よって、縦横比率を維持(16:9)したまま画面一杯に引き延ばす機能の有無が重要となる。これを「アスペクト比固定」「アスペクト比維持」などと呼ぶ。これをONの状態で画面を最大限に使用しようとすると、画面の上下5%ずつが真っ黒で何も表示されなくなる。少し勿体ない気がするが、しかしこれが正しい比率での表示なのだから仕方がない。当然だが、そういった比率を無視して縦横を画面めいっぱいまで引き延ばす機能もある。また、アスペクト比どころか、出力される解像度を忠実に表示するモードもある。これは「ドットバイドット」という状態だ。このモードをONにしたワイドUXGAの液晶ディスプレイでDVDを再生すると、その映像の小ささにため息がでるに違いない。小田和正の「言葉にできない」が似合う状態とも言えるだろう。
実際に使用する際は、アスペクト比固定モードを常用するようにしておけば良い。これなら、720pまでにしか対応していないソフトでも縦横比を維持したまま最大限大きく表示出来るし、1080p対応のソフトやBDの場合は実質ドットバイドットと同じ表示になる。
結論から言えば「別途スピーカーを用意すれば問題無く出せる」だ。PS3は映像出力と音声出力の端子を別々に設定できるので、映像はHDMIで、音声はPS用のAVケーブル、といった分け方も可能である。音質に拘らないのであれば、家電量販店で手頃なスピーカーを購入し、ケーブルの赤白プラグをステレオミニプラグに変換するアダプタを間に挟んで繋げば良い。いずれも高い買い物ではない。
俺のディスプレイの場合、HDMI端子で接続すると、その時までの映像出力設定に関係なく「HDMIが検出されました」とディスプレイ側に表示される。そのまま30秒放置すると以前の設定で映像が出力される。もしこれが有効にならないのであれば、ケーブルを繋いだ状態で一度電源をOFFにし、それから電源ボタンを5秒以上押してみると良いかも知れない(出力設定が初期化される)。この辺とか見とけ。
http://anond.hatelabo.jp/20081217003010
採点が分からないという声に対して。
ソルトレークシティでの採点疑惑というものがあったのが直接のきっかけだったと思いますが、詳しい経緯はWikipediaあたりを参照してもらうとして、新採点方式の方針は、曖昧さの排除です。そうすることで、技術的に正しい事をやっている選手が勝つようにするという事です。技術点何点、芸術点何点というのでは、演技の中でなにが得点に貢献しているのかさっぱり分からないので、それを各要素に分解して評価しようと言うものだと解釈してます。先シーズン導入され、浅田真央選手が受けていたロングエッジ(Wrong Edge = 間違ったエッジ)判定の導入もその流れにあると思われます。
その結果、転倒した選手が優勝する事も増え、一見ルールが分かりにくくなったと言えるでしょう。しかし、新採点方式のもとでは確実にジャンプ以外のスピン、ステップ、スパイラルのレベル(難易度という意味での)が上がったと言えるでしょう。
今、旧採点方式の競技のビデオをYoutubeなどでみると、ジャンプ以外のスキルは現在のレベルより低いものが多いです。ジャンプも旧採点では回転不足でも認定されがちです。競技としてのフィギュアスケートは、新採点方式の導入で確実に向上したと言えるのではないでしょうか。
各要素ごとに採点する新採点方式に対し、演技全体を評価する旧採点方式は、観客から見たときの分かりやすさが優れているのは確かなのですが、新採点にもこのようなメリットがあるのです。
(追記ここまで)
ルールと採点の仕方を理解する事でフィギュアスケートの今の状況を俯瞰出来るようにと解説を書いてみます。
http://www.isuresults.com/results/gpf0809/gpf0809_SeniorLadies_FS_Scores.pdf
これは国際スケート連盟(ISU)のサイトに出ているリザルトつまり結果なのですが、このPDFは先日行なわれたグランプリファイナルのシニア女子部門のフリースケーティング(FS)におけるスコア集となってます。ここには、そのスコアがどのように計算されて出たのかの詳細が表となって各選手ごと、フリースケーティングの順位順に並んでいます。
最初の一ページ目から見ましょう。Mao Asadaとありますね。名前の横にJPNと書いてり、その右に線で区切られて Total Segment Score = 123.17とあるはずです。これがFSの得点にあたる部分です。略してTSSと言います。今回、浅田選手は123.17点をFSで取ったということです。
その右の Total Element Score + 64.57 は略してTESと呼ばれます。これは旧採点における技術点と言われるのですが、直訳すると「要素の点の合計」でしてこちらの解釈の方が正しいと思います。新採点方式では各要素(女子の場合はジャンプ、ステップ、スパイラル、スピンの4種類の要素があります。FSではステップ1回、スパイラル1回、スピン3回、ジャンプ7回の合計12個の要素をこなします)ごとにその要素の難しさに応じた点数とGOE（Grade of Excusionの略で日本語にすると技の出来映えになります） に応じた点数がつけられます。それらを合計したものがTESなのです。
TESの右の Total Program Component Score + 59.60 はコンポーネントの点数の合計です。略す時はPCSとなります。このコンポーネントは5つあり、ファイブコンポーネントとも呼ばれています。日本語ではしばしばプログラム構成点と言われる事もあります。TESは要素の点数の合計なのですが、PCSはプログラム構成という字面から分かる通り、演技全体を5つの軸から評価するものです。ですから表現力の点数とされています。
最後に Total Dedcutions です。減点にあたります。減点は転倒したときにつきます。1.00となってるのは3F(トリプルフリップ)で転倒があったからですね。そのほかにも演技時間がオーバーなどでつく時があります。
ここまではテレビ放送でも表示される部分です。どのようなものかお分かりになったでしょうか。
次にうつります。今まで見てきたものの下を見ると、なにやら記号が表になってならんでますね。1〜12までの番号が振ってある記号は、各要素になります。要素がこなされた順番に並んでいます。1番をみると3A-2Tとなっています。これは浅田選手が演技の最初に跳んだトリプルアクセル-ダブルトゥループというコンビネーションジャンプを表しています。ジャンプの記号は「回転数」+「ジャンプの種類(A = アクセル、Lz = ルッツ、F = フリップ、Lo = ループ、S = サルコー、T = トゥループ)」で表されているのですね。
要素名が書いてある右の9.50は Base Value、基礎点です。各要素にあらかじめ決められている点数のことです。この要素はコンビネーションジャンプなので、3Aの8.20と2Tの1.30を合計した9.50点となっているわけです。さて、その右の0.80にうつりたいと思います。これは先程も述べたGOE、要素の出来映えの点数です。これには+と-があり今回は0.80点の+となっています。つまり出来映えの良いジャンプだったということです。
このGOEは複数の審判によって採点されます。それが右の The Judges Panel です。点数が 1 1 2 1 0… と並んでいますが、これはそれぞれのジャッジがつけたGOEの点数なのです。それらの平均がGOEとなりますが、その前に何人かの審判の採点は抽選であらかじめ採用されないことが決まっています。基礎点とGOEを加えた点数が10.30で、この要素の点数です。
ジャンプ以外の要素はSpと最後の数字の前についているものが、スピン。Stはステップ。SpSqはスパイラルです。最後の数字はその要素のレベルを表します。レベルは1〜4で、トップ選手となるとステップはレベル3で、そのほかはレベル4が当たり前、それ以下だった場合は取りこぼしと言われてしまいます。
ジャンプでついている<の記号はDG（ダウングレード）、日本語では回転不足を表します。基礎点は一つ下の回転数となり、GOEも引かれます。つまり二重に減点される構造があります。そのため回転は足りている3回転ジャンプの転倒は、回転が不足しているがきちんとした着地のジャンプの点数とほぼ同じになることがあります。例えばカロリーナ・コストナーの4番目の要素の3Loの要素点(基礎点+GOE)は2.0。そこから転倒による減点があるのでこのジャンプは1.0の価値があるわけです。一方、安藤美姫の2つめの要素3Fは1.16。安藤選手の3Fは着地が少々乱れた面はあるものの転倒はしてないのですが、点数はほとんど同じです。この問題はショートプログラム(SP)で浅田選手のコンビネーションジャンプの二回目が回転不足となったためにジャンプが一回転になってしまったキムヨナ選手に順位で負けたことの原因です。
TESの解説でもう疲れたのでPCSの解説はしませんが、TESの読み方が分かれば理解可能だと思います。
より詳細なことを知りたい方はこちらのホームページへ。まぁこちらに私の書いた事すべてあるんですが。。。
http://www.geocities.co.jp/Athlete-Athene/9074/index.html
ニコニコでフィギュアスケートを見ると、各要素の点数が要素が実行された後にコメントとして表示されるので、フィギュアスケートの勉強に便利です。もちろんこれはリザルトの結果を書いているので、生放送中には出来ないのですがね。
これでリザルトの読み方が分かったと思いますが、これが分かるといろいろなものが見えてきます。今回の結果のみならず、他の大会や男子のものを見ると、フィギュアスケート界の採点の歪みが見えて来ます。このままではスポーツとして危ういという現状があります。バンクーバーオリンピックは問題はないでしょうが、次のオリンピックでは実施競技から外されてしまうのではないかという危機感がフィギュアスケートファンの中にはあります。
を書こうとして疲れたからもういいや、また今度！
要は二つで、
安藤美姫選手には4S、やって欲しいです。それが彼女へのプレッシャーになってると言えばそうなんですが、それでもやってほしい。最高難度のジャンプが練習でかなりの確率で出来るのに試合で回避するってのはスポーツであるフィギュアスケートにとって良くない事だと思うんですよね。フィギュアスケートがスポーツであることを止めたくないなら、高難度の技への挑戦をしやすくなる方向に競技全体を持って行かないと、と。
Sony Japan｜プレスリリース | 液晶テレビ＜ブラビア＞の情報閲覧機能「アプリキャスト」個人向けソフトウェア開発ツールを公開
早速見てみた。
ここからBRAVIAに搭載されてるJavaScriptインタプリタのソースがダウンロードできる。
まんまSpiderMonkey。
つまりフルのJavaScriptの言語仕様がサポートされてるってこと。
Second Lifeのインストールディスク販売の正当性に関して。
一応、GPLやパブリックドメインなどでライセンスされたソフトは第三者による配布も販売も自由なので、「無料ソフトを販売する」こと自体が一律に非合法であるとか、倫理に反するなどということは無い。ましてや、その販売が営利、非営利に束縛されるものでもない。そして、Second Life自体はGPL互換に近い形のライセンス形態らしい。(詳しくは知らないけど(汗)。参考： https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ )。
で、Second LifeのWikiを探ってみると、、、
(参考： https://wiki.secondlife.com/wiki/Redistribution )
Second Life及び、オープンソースなコンポーネントは再配布できそうな様子だが、Second Lifeが必要とするFMOD, Kakaduといった、いくつかのコンポーネントは再配布ができないので注意が必要である。
ということで、そのインストールディスクに再配布不能なコンポーネントがあるかどうか調べない限り、販売行為の正当性を問うことができないという結論に達しました。(調査がいろいろと不十分だけど。)
なんていうか、「アメリカだから」、「許してよ」でソフトウェアの再配布の正当性を主張されてもまずいと思った。
ちゃんとライセンス的に許可されていれば、ソフトウェアの再配布(有料)は可能なはずなので、そこを確認したかった。
とはいえ、付け焼き刃的な調査なので、自分で商売する場合は本記事を鵜呑みにしないで、ちゃんとライセンス関係は確認して欲しいと思います。
動作確認は、メモとIdHttpコンポーネントを貼り付けて以下のコードを書いて実行してみる。
Memo1.Lines.Text :=
IdHttp1.Get('http://k.nhk.jp/knews/');
tomomori ってなんだあ？: Turbo Delphi その１
734 ：デフォルトの名無しさん：2006/12/29(金) 09:08:08
116 名前：デフォルトの名無しさん[sage] 投稿日：2006/11/04(土) 17:25:13
ttp://beeography.wordpress.com/2006/09/12/just-wanna-let-you-know/
ここに書いてある方法でTurbo Exprorerでも合法にコンポ入れれるよ
117 名前：デフォルトの名無しさん[sage] 投稿日：2006/11/04(土) 18:02:21
あとこれ。
dclusr経由のコンポーネントインストールが、ライセンス違反かどうかの話。
ttp://hpcgi1.nifty.com/MADIA/DelphiBBS/wwwlng.cgi?print+200609/06090014.txt
とても面白い。なるほど。
確かに、俺の働いてる会社でも「ITのスキルは研修でカバーするので不要です」とか言ってるな。「プログラミングの経験と実績がない人や、数学の基本的な知識がない人はお断りです」と言ったら、逆に優秀な人がどっと押し寄せるかもしれん。
それはさておき。
俺が思うに、問題はすでにIT業界(というかいわゆるSI業界)はリンク先やそのリンク先でも語られているようにすでにコモディティ化しつつあるにもかかわらず、ホワイトカラーとブルーカラーが明確に分離されてないことだと思う。
俺の意見として「そうした方がいい」と言っているわけじゃなくて、「そうなってないから問題が発生しているんだ」と思うだけの話です。
ほとんどの産業では、黎明期には職人が設計から製造までやっていた(んだと思う)。
SIだってそう。昔は、つまり討論会に出てるようなご老体たちが現役の頃は、一人で設計もコーディングも運用もやっていた。だから彼らにはプライドもある。努力もしたんだろう。
でももう今はそういう時代じゃない。分業が進み、レベルが低い労働者でもできる仕事が増えた。それは、単純に昔のSEのほうがすごかったというわけではもちろんない。昔のITは単純だったから、それができたということろが大きいと思う。感覚的にだけど、この10年でだって、システム構築全体で必要となるスキルの量は、5倍くらいに増えてる気がする。30年前と比べたら、30倍くらいになってるんじゃないかと思う。
だから、今システム全体を設計する人には、昔のSEよりももっと高度な知識が求められる。設計者には開発の知識も求められる。でも、そういう人はほんの少しでいい。残りの人は、単純労働者でいい。
自動車産業でも一緒。昔は、少人数の技術者が、設計して製造をしていた。でも、どんどん産業が成熟すると、役割の分担が進み、製造に求められるスキルが低下してくる。逆に、設計全体に必要なスキルは増えてくる。設計者と開発者の
今のSI業界は、設計者と単純開発者を一緒くたに採用している。「SE」という一つの呼称で。
だから、優秀な設計者が単純開発者のメンタリティやスキルしか持たない人と一緒くたにあつかわれて、ダルイ環境に「やってられるか」と嫌気を指し、優秀な人と一緒に設計も開発もやれるベンチャーに流れたりする。
一方、単純開発者はほんとは単なる単純作業しかできないのに、過剰に高度なスキルを要求されたりして、疲れ果てたり、燃え尽きたりする。そして、単純開発者なのに給料だけは高いから、インド人や中国人に職を脅かされたりしてしまう。
もちろん、実際に業界で働いてみると、大手のSEと下請け・孫請けのSEには待遇や業務の内容や求められるスキルに大きな差があることがわかる。でも、それは外からはとてもわかりにくいし、内部的にも明確に定義されたものじゃなくて、結果としてそうなっているだけなものだと思う。
また自動車産業の話になるけど、自動車産業はそうじゃない。大手自動車メーカーの設計者とライン労働者は、全く別の職種。自動車メーカーの設計職になろうと思う人は、大学である程度機械工学(や関連した分野)を学んだ人がほとんどだとおもう。ライン労働者の人の苦労話はよく目にするし、それは社会的に保障してあげる仕組みをつくらないといけないとおもうけど、それはまた別の話としてここでは置いておいて。設計者とライン労働者を、一つの職種として採用したほうがいいと思う人は、あまりいないんじゃないかと思う。
話が長くなったけど、SI業界の問題はそこなんじゃないかと。
今後、今以上に開発のコンポーネント化は進み、同時に全体として必要となる知識の総量は増えてくるはず。そこで、現在「SE」として扱われている採用および人材管理を、一部の高度な設計者と、多数のさほど高度なスキルを必要としない単純開発者に分離する、というのが、これから不可避な流れになってくるんじゃないかな。
あまり「優しい」流れだとは思いませんが。
http://anond.hatelabo.jp/20070802205200
一連の議論の中で書いていることは、
東大卒はコモディティ化されたプログラミングというものを仕事にしないということ。
そういうものは全て外注する。なぜなら、コモディティ化しているから。
コモディティ化されてない部分は外注しようがない。
そりゃ当然なんだけど、そうする動機について勘違いをしてるんじゃないかい。
「東大生は優秀だからコモディティ化されてない部分をやる。誰がやっても同じような瑣末な仕事は優秀じゃないやつらに任せとけ」
そう思ってたらしっぺ返しを食らうよ。
なぜ外注するかって言えば、それぞれが自分の得意分野に集中した方が全体の効率が上がるからだろ?
「こんな簡単な仕事、うちでやるのは馬鹿らしいから外注する」んじゃないんだ。
「この仕事はうちがやるよりもあちら(外注先)に引き受けてもらえたらありがたい」から外注するわけだ。
外注先が引き受けてくれなかったら、あなたにとって「つまらない仕事」もあなたがやる羽目になる。そんなの嫌だろ?
そして、あなたは「できるけどやらない」を何度も強調しているけど、想像してみてほしい。
もしあなたが、あなたにとっての「つまらない仕事」を一生やってゆくことになったとしたら、
あなたはその仕事に誇りを持って、文句を言わず、質を落とさずに続けてゆくことはできるかい。
(それがプロの仕事ってものだからね)
それが出来ないとしたら、やっぱりあなたにその仕事は「できない」ってことだよ。
人にはそれぞれ役割がある。他人の役割を貶しちゃいけない。
最後に、本当に新しいモノを作っている時、つまりその作り方さえ世界中探しても知っている人がいないような時、
誰がやっても同じになるようなコンポーネントの組み合わせじゃうまくいかない。
コンポーネントの要求仕様さえ、作ってみなくちゃわからないような状況だからね。
http://anond.hatelabo.jp/20070802135104
まあサラリーマンじゃないけど。
確かに良く言われる。「瑣末なところは人に任せて、もっと大きなチームを率いて、大きなデザインをやってみないか」ってね。
でもそういうのって、別に俺じゃなくても出来る人いるでしょ、って思っちゃう。
漫画家でも、スタジオにしてアシスタントたくさん使ってヒット作を量産する人もいれば
人それぞれだね。
ただ、もう業界で長くメシ喰ってて色んな現場を見てるけど、末端の作業には末端の作業のプロがいるんだよ。
誰がやっても同じなんてコンポーネント、ほとんど無いよ。そう思ってるとしたら、妥協してるだけ。
「中学生にもできる」って、出来るか出来ないかで言えば気の利いた中学生なら出来るかもしれないけれど、プロとしての仕事が出来るとは思わないなあ。
(俺は中学生の時からバイト料もらってハードの設計やったりソフト書いたりしてたけど、あれは教育のために「やらせてもらってた」んだって後で悟ったよ)
係わる人間全員が、それぞれの役割でプロとして最高の仕事をしてこそ、いいモノが出来るわけでしょ。
タグ「delphi」を含む注目エントリー - はてなブックマーク
Delphiアプリケーションのメモリリーク検出法 (山本隆の開発日誌)
http://www.componentsource.co.jp/features/delphi/
TMS Software | Productivity software building blocks
Components > Effects and Multimedia > Video. Torry's Delphi Pages
Components > Effects and Multimedia > Audio. Torry's Delphi Pages
Components > Effects and Multimedia > Voice. Torry's Delphi Pages
Components > Effects and Multimedia > Direct X. Torry's Delphi Pages
eXeScope(Windows95/98/Me / ユーティリティ)
Delphi-ML〓〓〓〓〓〓〓〓〓〓〓??About Delphi
Delphi Q & A 〓f〓〓〓〓 〓〓〓〓〓〓O〓〓(HTML〓o〓[〓W〓〓〓〓)
Delphi WAVEサウンド音を鳴らす/Tips & Tricks
5分ではじめるDelphi - 第1回 簡単なメディアプレーヤの作成（前編）
Controling sound volume from code
lsMicrophone: mxl.dwComponentType :=MIXERLINE_COMPONENTTYPE_SRC_MICROPHONE;
MIXERLINE_COMPONENTTYPE_DST_SPEAKERS
MIXERLINE_COMPONENTTYPE_SRC_WAVEOUT
SwissDelphiCenter.ch : ...set the volume for the microphone/ mute it (enhanced)?
Components > Sound Effects > Mixer. Torry's Delphi Pages
PlaySound('C:\WINNT\Media\start.wav', 0, SND_FILENAME or SND_ASYNC);
Delphi6でプログラミング ビットマップの半透明コピー AlphaDraw
procedure TForm1.Button1Click(Sender: TObject);
bmp1.LoadFromFile('C:\Program Files\Common Files\Borland Shared\Images\Splash\256Color\FINANCE.BMP');
bmp2.LoadFromFile('C:\Program Files\Common Files\Borland Shared\Images\Splash\256Color\FACTORY.BMP');
Form1.Canvas.Draw(10,10,bmp1);
Form1.Image1.Canvas.Draw(10,10,bmp2);
bmp1.Free;
bmp2.Free;
無料版Delphi6でSTGをつくるためのプログラミング講座 Ver.2005 Jan.
SwissDelphiCenter.ch : ...get the MAC Address?
もっと楽にGUIとの連携がしたい：Python + Delphi = P4D(Python for Delphi) - ふにゃるん
Delphi WindowsのOSのバージョンを取得する/Tips & Tricks
SourceForge.net: Gecko SDK for Delphi
BDS(Delphi/BCB)用SQLiteライブラリ (山本隆の開発日誌)
SwissDelphiCenter.ch : programming tips
ナッキーの「Turbo Delphiはじめて奮戦記」- 第1回 Turbo Delphi のインストール
フリーのTurbo Delphiで始めるWindowsプログラミング：ITpro
フリーのTurbo Delphiで始めるWindowsプログラミング：ITpro
http://torrent.borland.com/turbo_hotfix_rollup.zip
http://torrent.borland.com/prereqs_jp.zip
http://torrent.borland.com/turbodelphi_jp.exe
(1) \dotNETRedist\dotnetfx.exe
(2) \dotNETRedist\langpack.exe
(3) \dotNETRedist\NDP1.1sp1-KB867460-X86.exe
最近さ、よくGUIでコンポーネントをペタペタ貼って気軽にプログラミングって感じのやつ多いけれど、初心者向け講座でそういうのを教えるのはどうかなーって気がした。
アレって内部的にはクラスだとかそういうの貼ってるわけでしょ？ ソースにどんどんいろんなこと書き込まれてってる。それを意識してなかったり、たとえ意識してたとしても隠蔽されちゃってよくわからないうちにぐちゃぐちゃと書き込まれたソースを理解できるとは思えないんだけれど。せいぜい用意されたコンポーネントをちょこちょこって手直しするくらいで、それ以上先って言われると行き詰まっちゃうんじゃないかな……
