  |
はてなキーワード: ファイバーとは
■現在
| 項目 | 7/27 | 7/30 |
|---|---|---|
| 体重 | 80.9kg | 80.6kg |
■ご飯状況
| 時間帯 | 今日飯 |
|---|---|
| 朝飯 | 緑茶1リットル、もち麦梅昆布おにぎり |
| 昼飯 | スリムクラブ 抹茶、イージーファイバー |
| 間食 | なし |
| 夜飯 | タイの味噌漬け焼き、ご飯(小盛り)、卵、納豆、味噌汁(大根、えのき)、しらす |
初めてのジム！というわけではないんだけど、
友達と一緒なのは初めて！1日体験3000円でやってきました。
とりあえず全部の器具を試した。
ランニングマシン、マウンテン(?)マシン、サイクリングマシン、
腕の筋肉を鍛えるマシン4種類、乗るところがブルブルするマシンなどなど。
ブルブルするマシン、良く家電店でも売ってるけど初めて乗った。
振動で歯が痛かった……。
見た目はランニングマシンと同じなんだけど、台の傾斜が勝手に変わる。
富士山選択した2分後くらいには、傾斜15度や20度で走らされた。
富士山は走らないだろう！と突っ込みを入れつつハアハア言ってた。
腕立てのポーズをしたりするやつも結構やった。何ていう名称だろう？
今ジム登録すれば体験料金返金しますよ！と言われたけど断った。
トレーニングも決めてくれるところが一番やりやすいと思ったので
次回はトレーニングも決めてくれるジムの体験に行ってこようと思う。
■雑記
昨日と一昨日は腕周りの筋肉痛がキツかった。
ペットボトルの蓋も開けれなかった…。
昨日と一昨日は腕周り、肩周りなどの上半身が筋肉痛だったんだけど
今日は背中とお腹周りの筋肉痛がきてる。まだ腕周りの筋肉痛直ってないけどね……。
筋肉痛酷いし、今日の運動は、ウォーキングと、ストレッチメインにしよう。
ダイエットにプールとか良いなぁ！と思うんだけれど、生理中何もできないから勿体無い気がしちゃうんだよなぁ。
とりあえず、色々教えてくれるジム(?)に体験に行こう。今日から予約しなきゃ！
まず服は世の中の女子大生が服を買っている店で買うといい
GU、LOWRYS FARM、INGNI、earth music&ecology、Heather、E hyphen world gallery、PAGEBOYあたりならある程度安くて品質もそんなに問題ないです(出てる糸は自分で切る)
あとみんな通販ダメって言うけど通販はその服がどれくらい売れているのかが分かるしショップスタッフのコーデやルックブックなども参考になる
丈感は「服 丈 身長」とかでググると身長別に色んな丈の服を着た写真を載せてるページが5個ぐらい出てくるのでそれを見てください
違う形で似てる色の服よりは似てる形で違う色の服を買った方がコーデの見た目のバリエーションが広がる
バッグは入学祝いにブランド物を買ってもらうというケースが多いが上記のブランドに売ってる普通のバッグも買っておこう
大きさは最低でもA4クリアファイルが入る23cm×32cm
個人的にはカジュアル過ぎないリュックが荷物多くてもどんな服着てても使えるのでおすすめ
全身の色は3色に収めるとgood
できれば無彩色は1～2色
全身黒とか全身白はやらない方が無難
あとGジャンにGパンもやめるべき
デニムなどの目立つ素材や柄物は全身で1つだけにするべき
注意する色の組み合わせ
・緑と赤(クリスマスになる)
かばんや靴を差し色にするのは難しいのでよく着る服の色と同じものを買った方がいい
白は汚れるので注意
そもそも服がないのでよく着る服の色もないというのもありがちだがこれはパーソナルカラー診断というのを受けると解決する
1万円ぐらい払うと資格を持ってる人が似合う色を診断してくれる
ネットに自己診断できるやつ色々あるけどあれは全く参考にならないので注意
1万も払う気ない人はオレンジの服で顔色良くなるならイエローベース、悪くなるならブルーベースぐらいに思っておくだけでもいい(例外有り)
1万円は高く見えるが一生色選びに困らなくて済むと考えると安い
多分この記事を読む人はメイクも全然分からないと思うのでメイクについても少し書く
後ろの()はとりあえずこれ買えばっていう安いやつ
・フェイスパウダー(キャンメイクマシュマロフィニッシュパウダー)
・アイシャドウ(キャンメイクパーフェクトスタイリストアイズ)
・ビューラー(資生堂アイラッシュカーラー213)
これさえ揃えればなんとかなる
リップは外で塗り直す必要があるので持ち歩くことになるが家出る前に塗ってバッグに入れるのが面倒だったらもう1本買う
余力があったらKATEアイシルエットマーカーを買ってアイラインを引こう
黒髪でも茶色を選ぶと抜け感とか呑気なこと言ってるやつもいるが茶色を選ぶなら本当に黒に近い茶色にするべき
抜け感より違和感がやばくなる
アイシャドウはパーソナルカラーを参考に選ぶといいが分からなければピンクと茶色が混ざったようなやつ(パーフェクトスタイリストアイズだと5,10,11)
地方におけるクソしょぼいコンサートであっても、わざわざ「ブラボー」と叫ぶ手合いがだいたい一人はいる。
最初の一人が叫んだのを皮切りに、後続がどんどん出てくるパターンにもしばしば遭遇する。
「こんなソリスト風情にブラボーとは片腹痛い。それはせめてbest everだと感じたパフォーマンスに対してするものではないのか？」
と思っていたが、ふと先日「あれは演者に対する賞賛の行為ではないのでは？」ということに気づいた。
つまり、クソしょぼいコンサートにおけるブラボーおじさんの叫びは自己顕示欲の自然な発露なのだ。
基本は「誰よりも早くブラボーと声を上げる俺のなんと趣を解していることか……」であり、
すなわち「客席でサイバーファイバー（とかなんとか）って大声で唱える俺マジでイケてる……パネぇ……」の同類である。
ほかの大多数がパフォーマンスを見に、聴きに、楽しみに来ている場所で、
きわめて稚拙かつ自己中心的独善的なパフォーマンスを繰り出すことにいささかの躊躇もない。
復電してからもグーグルファイバーって言うインターネットの回線が死んでて、ネット使えなかった！！
移住したばっかりだから、車もないしテレビもない！本も英語の本読んでると飽きてくるから、オフラインでできる仕事してた。
すげえ暇になって、雨おさまったから外ちょっと散歩して、それでも暇で。
これだけ暇になってできることといったら、実際オナニーくらいしかないのね？男性はわかると思うけど。
俺床オナが好きだから、床オナを資料なしでやってたのよ。本とか読まずに。
したらばさ、眠くなるよね？
床オナする⇨眠る⇨15:00
すごいぐっすり寝れて、15:00。電気復旧してた。なのでとりあえず股間洗ってパンツ履き替えるじゃん。お湯あったかい。
ふぅ、ってベットに寝転がるとほらまた、ね？ムラっとね？
女性のかた、これ見てバカだなーって思ったでしょ？？でもね、多分男性は「あ〜ね」ってなるんだよ。人生で1度くらいは同じ経験あるよ！！！
食物繊維には、水溶性と不溶性があって、すごくかんたんに言うと、水溶性食物繊維はコンブのヌルヌルで、不溶性食物繊維はゴボウの繊維だ。
で、野菜のなかで一番食物繊維の多いゴボウであっても、100gあたり5gしか含まれてない。
厚生労働省の発表してる栄養摂取基準は、一日あたり野菜350g、食物繊維は18g、以上。
不溶性と水溶性は半々くらいがいいらしい。(ここらへんほんとに現実に則してねーなって思う。)
で、巷で売ってる食物繊維のサプリや粉はほぼすべてが「水溶性食物繊維」だ。
難消化性デキストリンとかイヌリンってやつ。
最近はコカ・コーラの「からだすこやか茶W」にも入ってる。他にも高いのだと「王様の食卓」？とかいう割高なやつとか。イージーファイバーとかもそう。
かのアマゾンで探してみると、まぁ売れてはないんだが一応存在はしている。
説明文、「上質なパルプを主原料に……」
要するに木くずでできてる。
俺はおもむろに、隣にあるティッシュペーパーを見つめる。
これ食えばよくね？
昼のフレンチトーストは最高だった。
かといって、店で普通に売ってるものもなんか違う。高いのは高すぎて嫌だし
安いものは味も安っぽい。普通のヤマザキとかコンビニパンで売っている、メープルゼリーやらホイップクリームやらも違う。そうじゃない。
もっとこう、卵と牛乳とバニラ、そしてふわぷにょな食感、温かさ、そして適度が甘みが求められる。そして、バターの香り。多分ここだな。香りがポイントなんだと思う。家で作ったんじゃ売り物っぽい香りがしない。普通の、かーさんが土曜日に手抜きで作ったフレンチトーストの域を出ない。きっと売り物はスパイスとか発酵バターとか、生乳とか使ってんだろ。どーせ！知らんけど。
まあそんなことはどうでもいい。今日のお昼は求めていた味と出会えたんだから。
スーパーのパンコーナーにフレンチトーストが無かったのも、牛乳が値引きされてなかったのも、セブンイレブンにすら無かったのも、ローソンでは駐車場に停めることすらできなかったのも、すべてあのフレンチトーストと出会うためであったのだ！全ては神の思し召しであろう！
地方の中でさらに辺鄙な場所にある規模の小さい名の売れないパン屋。けども老舗じゃない。古ぼけた昔の焦げ目のつけすぎたパンじゃない。最近出来たオシャレ系パン屋。ミルクフレンチとか置いてある、しかもシフォンケーキまで置いてあるパン屋。それが良かった。
私がそこに辿り着いたのはお昼も過ぎておやつの時間にさしかかろうとしている時であった。当然大波が過ぎ去った後で、残ったパンも少ない。追加するほど数も作っていない店なので、入った時の閑散とした雰囲気ときたら、選択を間違ったかと早計させたほどだ。
しかし、レジ真正面のオススメパンコーナー。そこに鎮座していたオニオングラタンスープ風の物体に私の目は釘付けとなった。
たしかにそう書いてあった。フレンチトースト、フレンチトーストだ！ついに見つけた！
だが待て。目の前のフレンチトーストはバゲットを一切れ卵液につけただけの小ささ。これだけだとなんか足りない。私は店内を見まわった。5歩もあれば見回り終えるような小さいスペースに、原料であろうバゲットとサンドイッチ、デニッシュ、チーズケーキに件のシフォンケーキが並んでいた。大方の品は売れて、店の半分を占める奥の棚は空だった。
私は野菜を気にしてサンドイッチを手にし、「ココナッツのフレンチトースト」をトングで優しくトレーへ運んだ。そしてすぐ目の前のレジへ差し出す。「お願いします」と会計を頼むと、あまり愛想の無い感じで店員さんはレジを打つ。その間に、私の中の幸福がむくむくと膨らんでいた。ついにフレンチトーストが食べれる。プリンにフレンチトーストが埋まったような風体、紛れも無くふわとろ食感であろう。そしてココナッツ。これ。これこそ家で表現できないプロの香りとなりうる素材。期待できる！
わくわくしすぎてレジのお姉さんに「今日はずっとフレンチトースト食べたかったんですよ！やっと見つけて嬉しいです！」と子供の感想みたいな事を言いそうになったが、お姉さんは無駄のない所作で素早く会計を済ませてしまったため、そんな雑談を挟む隙など無かった。ただ、私が袋をフリフリしながら「どうも〜」とテンションの上がった声音で挨拶をしたため、最後の「ありがとうございました」はなんだか優しげだった。
さて、ここですぐに袋を開けてがっつくのは無粋だ。食事には相応の場も必要なのだ。
静かで、フレンチトーストを食べるのぴったりな、カフェのようなオシャレさと清潔感があるところ。天気が良いならお気に入りの神社に行って神様に「フレンチトースト見つけました！ありがとう！」と感謝をしてから緑の中で岩に腰を下ろして木々の囁きに耳を傾けながら食すところだが、今日は生憎の雨模様だ。屋根付き施設で飲食OKな場所は案外限られる。ので、私の心は早々に決まった。脳裏に浮かぶのは耳をすませば。図書館の飲食スペースで夏の風に髪を揺らしながらサンドイッチでランチをしていたヒロインの姿。あの爽やかさをフレンチトーストで再現してみせようではないか。
私は車を飛ばして中央図書館に辿り着いた。市内で飲食スペースがあるのはここだけだ。
目立たない場所にあるそれは、昼を過ぎていることもあり無人。電気すらついていなかった。白い壁と古ぼけた丸椅子が薄暗闇に浮かび上がるのはさしずめホラー映画のワンシーンだが、フレンチトーストがあれば何の問題もない。私は私だけのために電気をつけ、窓の近くに座った。血糖値と栄養の吸収を気にしてサンドイッチから食べた。辛かった。そして念願のフレンチトーストに手をつけた。
ふわふわだった。
美味しかった。
一部はプリンのように柔らかかった。その一方で卵液の染み込みきっていない部分はパンの食感と風味が残っていた。
そして、上にかかっていたココナッツファイバー。これがシャクシャクと新しい触感をプラスして、とてもとても美味しかった。
私は生涯この日を忘れない。
昔書きためていたメモを放出。ブログ記事にもならないので、メモのママ。
University of TorontoのチームがSikorsky Human Powered Helicopter Competition（シコルスキー賞）を取ってしまったので
対抗馬だった、Univeristy of MarylandのチームのGameraという機体についてまとめたもの。
http://www.macleans.ca/politics/toronto-team-wins-human-powered-helicopter-competition/
http://vtol.org/awards-and-contests/human-powered-helicopter
1980年に作れた。最低60秒の浮上と一瞬でもいいので高度3m以上に上がること。その間10m四方を出ないこと。
Cal Poly Da Vinci Ⅲが1989年に6.8秒。日大のYuri-Ⅰが19.5秒の記録を持っている。
Gamera Ⅰは空虚重量48.6kg。2011年に11.4秒の飛行。Gamera Ⅱは33%の軽量化に成功した。メリーランド大学。
アームは片腕9.5m、高さ2.3m、ローター半径6.5m、ローター弦長1mの矩形。
ヘリコプターは重量の1.5乗に比例して必要出力が大きくなる。
ローターで重量の55%、コクピット・トランスミッションで15%、ローターのうち、スパーが半分、前縁と後縁で1/4づつ。
地面効果：ローター半径と同じ高度で80%程度、半分の高度で70%、1/4で50%になる。必要パワーが。
Gamera ⅠはEppler E387を使っている。矩形で捻り下げもなし。局所の荷重の伝達を考えると人力飛行機などに使われいる2次構造になった。
ちょっと密度低めのビーズ法ポリスチレンフォーム（EPS）。（スタイロはXPSで押出法ポリスチレンフォーム）のリブをCNC切り出し。後縁はバルササンドイッチ。
前縁はXPS（スタイロの仲間）でこれもCNCでカットしている。スキンはミレファンを使っている。
トラスにしたのは同じ小さなスパーの組み合わせによって構造の最適化ができるようにするため。カーボンファイバーとビニルエステル樹脂（リポキシ）の複合材料の市販のパイプが長いパイプ（member）。トラスの網網部はカーボンエポキシの複合材。配向角は全て±45度（当たり前）。三角形の断面にしているのは安定性のため。うまい作り方のためにミニトラスは1時間もあれば作れる。座屈しそうなトラスの網網部分にはXPSをコアにしてサンドイッチしている。
Gamera Ⅰを受けて、Gamera Ⅱでは最大翼厚を厚いものにした。Seling S8037。スパーの剛性を上げてローター端が上がらないようにした。スパーをローターの中央と端で太さを変えた。towの束の数を変えた。前縁をXPSから軽量なEPSにした。
運びやすくするために中央、中、外のフレームにしてある。長さや高さや傾斜はブレードのサイジングによって決まっているから、他の部分の自由度については遺伝的アルゴリズムによって決めた。パラメタはトラスの高さとテーパーとノードの数と分布。剛性を束縛条件にして重量を最小化させるように遺伝的アルゴリズムにした。
GameraⅡはキンクをなくしたのと、パイプの径を色々変えたので軽量化した。
翼素運動量理論とFEMで解析。YURI-1を参考にした。テーパーとか捻り下げは作る時間と技術が必要な割に効果薄いと判断してやめた。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
わからんけど、グラヒクスと音声は リップシンクがあるから必ずしも別じゃないし
そもそも、音声を鳴らすチップ自体が独立したコアみたいなもんだからなぁ・・・
ネットワークチップだって独立したチップのやつは 別のコアみたいなもんだぜ？
話はずれたけど、まともなマルチコア向けプログラムを書くとなると、いわゆる１スレッド１役割みたいな処理は欠かずに
タスクシステムとか、スレッドの役割分担システムみたいなものを自分で書き下ろして、いわゆるマルチファイバーというか、マルチタスク的なシステムで
組んでいくから、（マルチタスクを自前で組むことが必ずしも高速化ではなくて、いくつもノウハウがあるけど） あまり、セマフォというかミューテックスを意識することは少ないよ？
たとえば、ちょっと違うけど 通信が一万本合ったら、１万スレッド起こすのか？起こさないというのと同じかなぁ。
逆に言うと１つのタスク中に入りと出以外に何箇所もロックしたり、開放したりするシステムはコンテキストスイッチの考え方からあまりよくない。
リソースになるべく触らない、触ったらローカルメモリーに移しておく、なるべく長い時間１つのスレッドを走らせる。リソースに触るときは処理終了して次のタスクにしてしまう。
などなど、そんな感じ。 スレッドに役割を振り分ける というよりは、タスクで回していくという感じ。
もちろん、長々走るものもあるだろうけど。
affected そういうシステム
● 動いているネットワークには触るな。
● 配線図を信用するな。
● 特権権限のパスワードが「password」の機器は誰もログインしていない。
● 冗長構成は動かない。
● 機器触っている時に「あっ。」って言う人は信用するな。
● しばらくアラームが来ない場合、何らかの問題が起きている。
● ググれ。
● 再起動は命がけでやれ。
● バックアップは戻らない。
● 素人は素直に申し出ろ。
● 手順書も読めない
● 手順書は読めるが作れない
● 手順書がないと作業できない
● だいたい手順書が間違っている
● 早業で障害対応したのに怒られる
● 飲み会の日は夕方障害発生
● コンフィグを保存し忘れる
● デフォルトオリジネートは消える
● 堅い名前をつけても誰も呼ばない
● MUAにこだわる
● キーボードにこだわる
● OSにこだわる
● そのスイッチのせいでSTP走って混乱
● 攻撃だそれフィルタと安易に言う奴が多い
● それはだいたい管理職
● 攻撃されている顧客には連絡が取れない
● DNSのことは知らない
● 経路交換は政治だ
● 落雷に敏感だ
● 生き字引みたいな人が居る
● その人のデスクはだいたい汚い
● 椅子の座り方をしらない
● 椅子を並べて寝るのが上手い
● ラックの間で昼寝する
● 光ケーブルの受光は目で確認しちゃう
● DC電源が怖い という話が怖い
● 低レイヤの事は以外としらない
● ケーブルは埋め殺す
● 埋め殺されたケーブルが多くてケーブル撤去できないのでそのケーブルも埋め殺す
http://d.hatena.ne.jp/faith_and_brave/20100220/1266673222
まず第一にエンタープライズでの開発が考慮されていない。エンタープライズの開発だと１００人２００人 マスタークラスから ジュニアーまで様々なレベルの開発者が携わる。
その中で重要になってくるのは可読性。
はっきり言って、歴史的な可読性を犠牲にして効率が上がるならともかく、気持ちの問題程度の効率では意味がない。
第２に
スレッドとファイバーの違いぐらいわかれ、わざわざスレッド起こしたらコンテキストスイッチにどれだけコスト食うんだよ。
関数コールするとレジスタとかが、スタックにPUSHされるんだよってわからん奴が、IF書くなと同じで、スレッドってコンテキストスイッチの塊なんだよってのがわかんないのに下手にスレッド書かせるな。
３にラムダ式・・・いらん・・・必要なのは曲芸じゃない、可読性。可読性を犠牲にして早くなるならともかく・・・
４にforeachではlastを変数に取るな。途中でReallocしたり、eraseしたりしたときに余計なバグを生んで面倒だ。レビューの時も邪魔。速度？速度が必要な背景でSTLのVector使うな。配列使うかポインタ使え。
なんつーか、トータルで見て、次はC++と各種OpenCLとかGLとかのライブラリの集合だな。C++0xはまともに使う人もいなさそう。正規表現とかもライブラリ使えば良いし、そもそもC系列ならBisonとかLRとかだろうと。C系列の使い手ならBNFを使え。正規表現使いたければそれこそ、Perl使え。
容器に水を入れ、対象を入れて吸水させたあと引き上げる。
したたる水が1秒に1滴程度になった時点でどの程度水が減ったかを計測する。
手で脱水したあとの吸水量も計測する。
どちらも購入直後の状態で実験した。
200x200x40mm 300円 中国製（会社名不明） MrMax ポリエステル100% マイクロファイバー susu類似品
約φ5mmのモール状のものが無数に生えている形状
1st吸水量677ml
手でにぎって絞った
2nd 吸水量275ml
430x325x2mm 598円 アイオン株式会社 PVAスポンジ ポリエステル
なめらかな手触りのゴム布のような形状
1st 吸水量183ml
雑巾しぼり
2nd 吸水量179ml
超吸水タオル ： 吸水量が多いが形状的に絞りにくく2度目は吸水量が半分になる。（補足：水のしたたりが長く続く）
プラスセーム ： 吸水量は劣るが容易に脱水でき、1度目とほぼ同じ量の水を吸う。（補足：水のしたたりはすぐなくなる）
