  |
はてなキーワード: メンテナンスとは
ヤフオクでずっと探していた物を見つけたので、
数年前から使っていなかったYahoo! IDでログインしようと試みた。
しかし、思いつく限りのパスワードを入力してもログインできない。
まず「Yahoo! JAPAN IDを忘れた」のリンクからIDを確認。
記憶している物と相違なかったので、少なくともIDの間違いはない。
なので、間違っているのはパスワードの方。
まぁ、数年使っていなかった訳だし、パスワードを記憶していないのは、いかにもありそうな話だ。
なので、ここ↓
https://account.edit.yahoo.co.jp/forgot_acct?.src=www&.done=http%3A//www.yahoo.co.jp/
やることは非常にシンプルで、前述のように確認済みのYahoo!IDを入力し、
そうすると、次のメッセージが表示される。
エラーが発生したためお手続きができませんでした。次のような原因が考えられますので、ご確認のうえ、お手数ですが最初からやり直してください。
おまえは何を言っているのかと。
順当な手順を踏んで、パスワードを確認したいだけなのに、なんかこっちが悪いみたいなエラーメッセージが出て、それができない。
時間をおいても（と言っても、今日の出来事なのでたかだか数時間だが）変化なし。
そして腹立たしいことに、Yahoo! JAPANには問い合わせをする窓口が無い。
FAQに、ズバリ自分と同じ悩みが載っていなければ、その先を調べる公式の手段は無くなってしまう。
まぁ、問い合わせ窓口が無いのは有名な話だが、自分が必要に迫られるまで、あまり気にしていなかった。
当事者になると、本当に怒りに震える。
IDを問い合わせれば返答があるのだから、アカウントが失効している訳ではない。
それなのに、パスワードを確認できないとは、本当にどういうことなのか。
日を空けたらしれっと使えるようになっているのかもしれないが、
とにかくホトホト呆れる。
大企業が聞いて呆れるわ。
ミュゼプラチナのCMに出てる娘のCMをよく見るんだけど、もう付き合いたいじゃなくて自分にもあんな娘が居たらなと思う程度のオッサンだ。
最近、会議とか議論とかプレゼンの資料とか、ハッキリ言うと仕事を進める上で、自分でも違うって判っていながら使う技術がある。
ハナキンなのに一人酒してたら凄い罪悪感で歯が痛くなってきたから、懺悔したいと思う。
例えばだけど、こんな感じ
もしくは、地熱が有力ですみたいな説明をする。
リストに意図的に入れていないなんて説明はしないし、商業ベースの発電実績に大きな差があるとか言わない。
そうすると、「知識を持っている人であっても、載っている情報で判断しようとする」バイアスがかかる。
電通と博報堂は売り上げも従業員数も段違いだが、並べて書くと2強に見える。
例えば「ホームセンターでの売り上げに差はないと考えられる」とか書いて、ざっくり説明する。
そして、売り場での実績データや、他社製品の動向を手持ち資料で準備しておく。
リストアップの応用だが、人間は会議中にそんなに記憶しておけない。
だから、レアケースや災害時の対策、計算しにくいリスクをあげると、
「今提案中の議案」VS「指摘されたリスク」のようになる。
例えば「小学校にPRにいく」という提案があったときに「不審者が入ってきたらどうする？」などのケースをあげる。
（それは小学校の担当範囲であるというのが真っ当な反論だが、「我が社としては何も考えないと言うことか？」と畳み掛けたりする）
レアケースの応用だが、本来の意図と違う部分を仮定して、それに対して反論する。
例えば「太陽光発電パネルを小学校に設置すると言うが、例えば小学生がそれで滑り台にして遊んだらどうなるか？危険はないのか？」
ポイントは「小学生が近寄って危険はないのか」であれば、「近づけないように柵で囲う」と言えるが、
「滑って遊んだとき」に関しては「データがない/危険だと思う」などの言い方しかできない。
（つまり、まともに答えてはいけない質問になるが、職場には部署が異なっても上下関係がある）
何を答えても「もし遊んだらどうなるのか？」と繰り返し質問するタイプの上位役職がまれにいるが、対処は諦めよう。
議事録の記載が最たるものだが、発言を言い直すと相当に印象を変えることができる。
例えば「我が社の既存の商材に比べて、大きなアピールポイントとして」を
「うちの商品は売れないから、奇抜な特徴をつくって売るってコトだろ？」など。
提案者側の時には、必ず議事録の作成中にチェックを入れて、面倒そうな指摘は無かったことにしたり、複数の質問をまとめたりする。
例えば「既存に比べてと言うが、どの程度違うのか？結果の売り上げ予想は？」を「既存商材と比較した違いは何か？」など。
（大抵の場合、質問した側は数字が欲しいのではなく、指摘したいだけ）
まともな会議中であれば、この逆や裏をつかった反論には普通指摘が入るが、意外に流されて印象が変わったりすることがある。
例えば「メンテナンスが簡単なので、導入障壁は低い」に対して、
「導入障壁が低いと好評な既存商材は、前に比べてメンテナンス性は変わってないが」
「じゃあメンテナンスが面倒なよその商品は、導入障壁が高いはずだが、売れている」
（対偶まで見ると明確だが、そもそも「参入障壁の要因がメンテのみ」と暗に仮定しているのが間違っている）
「太陽光パネルを推すと言うことは、地熱の可能性を無視するということか？
「売り上げ予想データがないのは、開発した技術を使いたいだけで、利益はどうでも良いんだろう」
「そんな前提は説明されなくても判っている。周回遅れだ。考えが浅い」
「（営業マニュアルが準備されていないが、の質疑後）その必要性？そんなところから説明が必要なら話にならない」
「太陽光発電はネットでの評判が悪いが、ブランドイメージは大丈夫か？」
「私立の学校では、そんな発電よりも給食などが喫緊の課題ではないのか？」
面倒なのでまとめるが、
比較時点で落としたものを再度持ち出す、邪推する、自分が知っているから古い＝だから駄目、自分が信じる必要性を理解していない＝だから駄目、特にデータ無く印象で否定する、全く関係のない話題と比較する。
流石に会議に参加するのは全員良い大人なので、この手のは基本的に「感情的な発言」として無視される。
ただ、「だから駄目」パターンの「オレの言いたいことぐらい判っていろ」に関しては、部署で暗黙に前提とされていたりもするので場合による。
（会議には立場も上下関係も売り言葉に買い言葉もあるので、当然発言そのものは良くある。議事録には残らない）
「〜っていうことか？」という都合の良い言い換え系は大抵馬鹿発言だが、
リストアップして重みの軽重を無視する、レアケースの指摘、仮定しての反論などは、チェックしてると使える技術が拾えたりする。
あとまあ、同じものを違う名前で呼ぶと頭の中がリセットされるとか、違うものを同じ名前で呼ぶと印象を引っ張れるとか色々あるけど、
なんかこういうバッドノウハウの蓄積って不毛だと思うけど、宮仕えじゃなくてもクライアントとの折衝でも使ったりするし、
全部読まなくてもコードから理論がわかればオリジナルで書き下ろすというのもある。
古いのだとFORTRAN77とかで書かれてんじゃない？
根性論なのは申し訳ないけど、いわゆるデスマーチのヘルプで投入されて火消しをするってようするにこういうことをしている。
ということで、出来ないわけじゃない。
だからなんっていったらいいかわからないけど、知的興味から開けたいと思う人がいれば開くし、いなければどっちみち教える人が存命でも引き継がれない。
だって、その人が存命中もみんな中身を聞いたりしないで、ブラックボックスとして使い続けたんでしょ？
引き継ぐ人に引き継ぐ気がないものは引き継がれない。銭金の問題じゃない。
引き継ぐ気があれば最悪のケースでコードが残っていれば引き継がれるし、引き継ぐ気がなければどんだけ金があっても引き継がれない。
Windows8を別のパソコンにインストして、Media Center Packを適用しようとするじゃない？
正規品だっての。
サポートに聞いたら、Media Center Packは元のパソコンでしか使えないんだって。
じゃあパソコン変えるたびに800円払うのかって聞いたら、そうです、だと。
しねよ。
分かったよ。Media Center Packは使わないから、認証済みの状態に戻してよ、つったら、
Media Center Packだけをアンインストールすることはデキマセン。
は？
しねよ。
再インストールするじゃない？
8→8.1→8.1Update
...Windows Updateで1日がかりだよ。
これの初回実行がとにかく遅いんだよ。
プログレバーもないし、実際にどんなメンテやってるのかの表示もねえ。
あほか。
（追記）タスクスケジューラーでDiskFootPrintを削除したら直った
エクスプローラーの詳細表示で複数ファイルをマウスで選択しようとするじゃない？
ユーザー追加しようとするでしょ？
そしたらメトロに飛ぶんだよ。
コンパネ内で完結させとけ、ぼけ。
アプリケーション一覧画面からでは起動できんのよ、Pythonシェルが。
どうやって起動すんのよ。
アプリケーションランチャーの極致にあったスタートメニューを廃止してこのザマか、しね。
タブレットではそこそこ使える。
それは認める。
デスクトップでも設定を練ればわりと使える。
それは認める、、、わけないやろ、
あほか。
めんどいわ。
ただひたすらに、むかつくOS。
それがWindows8。
最近はSNSなどで明後日の方向に勝手にボールを投げ返す馬鹿が居て相手するのも疲れる。
相手をしなければ済むので無視しますが、何を考えているんでしょうか。
例えば「(パソコンでも自動車のメンテナンスでも言えることだけど)不得手な方、プロにお願いしましょう」と投稿すれば「馬鹿はクルマはバラセルwww」「
そんなのは自分で出来るわwww」と身勝手な発言を投げつけられる。
例えば「新中古扱いのこの家電に興味があるな」と呟けば「それはお勧めできないのでこれ買えwww」と意味不明な発言を投げつけられる。
私は対象となるユーザーをある程度絞ったが自称マニアがしゃしゃり出てくる、新中古と言うある意味一点物について発言すれば無関係な事を頼みもしないのに返してくる。
意味があり、商品について漠然と悩んでいるならまだ分かるが、そうではない。
いつから日本人は日本語が読めず、自分の我を貫き通そうと言う馬鹿な発言しか出来なくなったんでしょう？
緊デジ、私的な総括
http://www.pot.co.jp/default/20140501_150904493933661.html
大変興味深く読んだ。うちのことを書いているのかと思ったｗ
緊デジの話があったのはいつのころだったか。うちのような弱小制作会社にとってはとにかく大きな話だった。
そもそもなぜうちに問い合わせがあったのか今となってはそれもわからないが、改めて振り返る機会もなかったから、便乗して総括してみようと思う。
うちにとっての緊デジの結論は
・危うく倒産するところだった。というか話をそのまま鵜呑みにして"法律をしっかり守っていたら"多分倒産しただろう。さらに言えば、それが遠因となって倒産した福島の会社は現にある。
・ようするに、こりごりだ。二度とやりたいとは思わない。
連絡をもらったのは確か2012年の年明けだ。
うちにはそんなノウハウは全くなかったしやったこともなかったが、DTPだのWebだのができる会社だったら大丈夫とのことだった。
東北の雇用を増やすという主旨を聞いてあぁなるほどなと思ったけれど、既に復興バブルが始まっていた当地においては申し訳ない気持ちがあったと同時に、「ま、お役所が考えることっぽいわな」と思ったものだった。
「覚えれば誰でもできる作業」ということだったから、そんなもので一時的に雇用を作ったところでしょうがないじゃないか、と経営者ながら思ったものだ。
そういうことじゃないんだよ、復興っていうのは、とね。
話を聞けば聞くほど、「それ、うちで大丈夫かいな」と思うようになったのを覚えている。年商1億にも満たない我が社に割り当てられる冊数は相当なもので、緊デジだけで1億数千万以上の売上となる計算だった。
フレコミは「これを機に電子書籍の制作体制を作れれば仕事が増えるしうちからも出しますよ」ということだったのだが、電子書籍の未来が我々制作会社にとって大きな市場となるのかどうかなどまだわからなかったし、わからないもノウハウやスキルに時間と機会を投資するのは流れの速い昨今にあって経営上致命傷となりかねない。
とはいえ、確実な売上が見込める特需が舞い込むということで、鼻息荒く「その売上増を何に投資するか」と巡らせたものだ。
これを機にMacを新調しようだとか、これを機に大手出版社さんとの取引を拡大させようだとか、この利益で人材を採用・育てようだとか。
さて、冷静にコストを計算してみる。InDesignは1本10万円としよう。パソコンもどう考えても足りん。
もちろんスペースも足りないから作業場所を確保しなければならない。採用コストと教育コストも馬鹿にならんだろう。
そして何よりも、その間受注を一部停止するわけだが、そんなリスキーな事はできるのか。
一体何人いればその売上を作れるのか。10人そこそこの我が社なのに、どう考えても数十人必要だ。
というか復興バブルが始まっていた当地において「最長でも1年ですよ」「別にスキルが付くわけじゃないですよ」などという仕事で人が集まるのだろうか。
最終的には下記のようになった。
Indesign・・・とりあえず15本(ほんとは60本必要だった。が、後述するがその投資は不可能だったため1ヶ月の期限付きの試用版で多くは乗り切った)
事務所・・・オペレーション上、本社と離れた場所ではいけないから、たまたま空いていた同じビルの上階を借りた。短期で、という無茶な条件だったため、割増で掛かった。
都合数百万か。
しかし、何より痛かった費用は、借り入れの金利と「支出を伴わないが確かに掛かる見えないコスト」だった。
結局、述べ500人程度の応募があり、1通1通履歴書に目を通す。
面接は集団で行ったが、それでもやはり1回2時間程度は掛かる(PCスキルの把握が必要だったため、テストも行ったから)。
これを何十回とこなす。人によって条件(働ける時間や曜日)は違うし、できるだけ丁寧な説明を心掛けた。
そして教育だ。採用したとしても、最初から生産＝売上を上げられるスキルなわけではない。
人によっては80時間程度の研修が必要となった。この間は、いわば持ち出しだ。
管理コストも馬鹿にならない。毎日毎日、名前も覚えていない人達の作業を記録し、適材適所で配していく。どうしてもタグがわからない人がいる。
どうしても長時間画面を見続けることができない人もいる。
そういう一人一人のメンテナンスとケアをし、設備が最大限使われるようシフトを調整していくこれらの時間は、予定時間に含まれているわけではなかったから辛かった。
そして最大のコストとリスクは、これらを管理するために人を配する事で起きる本業の受注減だ。
緊デジの話をもらったときは、もうすぐにでも始まりますよ、といった物言いだった。実際、研修に来いとのことで6～7人を東京に派遣したりした。2泊。
これだけで30万のコストだ。
それが何回もあった。
仕様が変わりましただの、こないだのだけじゃわからなかったでしょだの。1億のため、と先行投資も飲んだ。
いずれにせよ、すぐに始まるというし急いで体制を整えるわけだ。
何事も急げばコストは上がる。
受注しそうだった本業の大型案件は断って緊デジを待つしかない。
が、発注は来ないのだ。待てど暮らせど来ないのだ。
「今月末には始まる」という台詞は春から秋まで毎月聞いたものだった。
そのくせ「貴社はしっかりと体制を整えているようだし、紹介したい発注元がある」などと予定冊数をどんどん増やす。来ないんだけどね。
つか、雇ってんだけども。どうすんのよ！つか、借りてんだけども。どうすんのよ！
制作会社である我々は、制作をしていない時間というのはただのコスト消費になる。
「すいませんまだ上の方で揉めてるみたいで発注できないんです」と言うのは簡単かもしれないが、止めていた受注が来月発生するわけではないし、1時間当たりにこなせる仕事量は決まっているから、来月挽回できるわけでもないのだ。
これは今でも悪夢になってうなされるほど、本当にきつかった。
そして極めつけ「何が復興支援じゃ！」と思ったのは、支払いサイトだ。
今時、手形だ。
納品の定義もどうかしてる。うちは作る。納品する。
でも、相手(出版社)がウンと言わないと納品にならないという。
まぁ、そうかもしれない。それが普通だろうとも思う。
が、弱小制作会社にそんな資金繰りを強いるのはどの辺が復興支援なんだ？と思った。
とっくに納品した電子書籍が、何ヶ月も先方の確認待ちになり、3ヶ月後にようやく納品と思ったら、その月の月末に手形が振り出され、換金は120日後とな。
要するに、最大で数十人分の人件費×9ヶ月程度のお金が先に必要ということだ。
しゃーないから借りたさ。1億な。
月商300万足らずの我が社でよく借りられたもんだ。個人保障付けさせれらたけどな。
いずれにせよ、この金利だけでも相当堪えたよ。
「受注で」1千万強だ。粗利じゃないぜ？この受注額から人件費だの設備だの揃えるんだ。
結局、私を人間不信にさせるほど困憊させたのは発注元の会社と経産省だ。
毎日毎日「まだ仕事始まらないんですか？」と雇った人達を不安にさせながら。
そのたびに答える「実はこの案件は緊デジといって、経済産業省の助成事業なんです。だから何も心配要りませんよ」とな。
だが、それは間違いだったんだ。発注元(東京の超大手企業)が、なんと東北の地の
俺は目を疑ったね。復興支援だからとか東北に本社が必要だとか言ってたけど、おまえら自分でやってんじゃん、と。
おい、それは本来私たちに出すと約束した仕事だったのではないか？
設備を整え、ありもしない仕事のために事務所を借り、結んだはずの労働契約も反故にした私たちはどうなるだよ、と。
つか、雇用契約については結果的に嘘ついたことになったんだぜ？
ま、大手なんてこんなもんだろうと思ってたけど、現実はやっぱり厳しいね。
で、経産省に問い合わせてみたさ。匿名で。責任者とやらに窮状を訴えてみたら「本当にごめんなさい、指示はしてるんですが」やら「ひどい話ですね、指導しておきます」やら、色々言ってはいたが、何も改善しなかった。
「仕事をするもしないも、貴社次第です。そんなに発注元が酷いというなら、緊デジをやらないという選択肢もあるのではないですか？」だとさ。
役人さんよ。民間はそういう力学じゃねーんだよ。やると約束したんだよ。
だからやるんだよ。
例え今上手くいっていなくても、そう簡単に発注元に不義理はできないんだよ。
それはお互い様なのよ。
それに、緊デジ以外でも続くかもしれない関係でしょうよ。
人も雇ってんだよ。
仕事がどうしても作れなくて1度も出勤していない人も大勢いた。
その人達は、うちがキープしてなかったらきっとほかの仕事に就いていたろう。
そのお金で、何かを買っていたかもしれないし、遊びに行っていたかも知れない。
それに、やめろったって、もう金は借りたし設備も買ったよ。
使わねーよこんなに。
そもそも社員分以上あんだしさ。今更やめられないよ。
社員に対してもそうだ。
デザインを覚えたての新入社員も含め「この仕事自体は何のスキルにもならないし経験にもならないかもしれない。でも我が社にとっては非常に大きな機会であり、ここで得た有形無形の利益できっとみんなにも色々還元できる」って言ったさ。
デザインがやりたくて入った社員には、さぞかし苦痛だったろう。
誰でもできる仕事をPC作業という一括りにされて。デザイナーってのは仕事じゃないからさ。生き方だからさ。
本当に申し訳ない気持ちで一杯だ。
こんな仕事がしたかったんじゃないんですと涙を流しながら辞めた社員もいる。
いずれにせよ、これら全ては経営者である私が見極めることができなかったことに起因する。
本当に申しわけないことをしたと今でも思う。
設定された目標冊数＝予算をこなすためだけに揃えられた日の目を見ないであろう本を復興の名の下に電子化する作業は本当に辛かった。
電子ブック屋でいくら探しても、私たちが作った電子書籍が出てこないのも辛い。
本を愛していたからこそ、「津波で流されてしまった本があります。二度とこうならないように」という理念に賛同して最大限リスクを取ろうと思ったが、そんな理念はついぞ体感することはできなかった。
補助金が出るから、という理由で出版社の電子化実験にさせられた本たちもまた、かわいそうだなと思ったものだ。
そして福島では、緊デジに乗って人を増やしすぎた会社が先日潰れた。
それまで3～4名だった会社が、緊デジを機に4～50人になったのだ。
そら、潰れるよ。
というわけで、時間だ。
地方の小さな小さな制作会社がどのように緊デジに臨んだかを記してみた。
はてなの「Presso」を使いはじめた。初期設定のフローで促される「ジャンル」はすべて削除し（はてなブックマークのアプリの利用で互換されるため）、テキトーに好きなタグをフォローしている。好きな著名人、地元付近の地名、出身校、仕事上に必要なアプリケーションなど固有名詞のタグをフォローしている。
Presso、とてもいいと思う。Gunosy、Vingowの過ちを踏まずにいって欲しいと思う。
Gunosy、Vingowの過ちは、情報のキュレーションに特化していればいいものを、情報の軽量化までに手を出してしまったところだ。そこでニュース会社のアプリとの差別化（ひいてはRSSフィード系のサービスとの差別化）が難しくなってしまった。交通整理だけをしていればよいのに、道路を走る車のメンテナンスにまで手を出してしまったところが残念だ。
Gunosy、Vingowのようなサービスを利用するユーザーは、そもそもかなりヘビーに情報を求めにいく層だったはずだ。ニュース会社の一次情報発信に満足できない、情報収集フェチのような層がターゲットだった。彼らは情報の軽量化を求めていなかった。 三行まとめみたいなものは要らなくて、情報は重たいままでいいから、その情報に行きつくまでのフローを簡略化やストレスの排除を担って欲しかったのだ。その正解が、はてなのPressoだと感じる。
僕は毎日はてなを眺め、1,200〜1,500記事に目を通す。情報収集フェチだと思う。何の約に立つのかわからないが、情報のインプットに快楽をおぼえる。ビジネスマンとしての質の高めるとかそんなんじゃなく、もはや趣味の領域かもしれない。
はてなに次にやって欲しいことがある。月イチ程度で、自分がブックマークしたものをPDF化してまとめて送ってきて欲しい。読み返しのフローを充実させて欲しいのだ。僕のような流し読み勢は「あとで読む」はだいたい読まない。読まなければと思ってはてなを開けば、また更新されている数々の記事に目移りしてしまう。情報収集フェチのクズたるゆえんである。そんなクズな僕は、月に一度、PDF化された自分のブックマークが電子書籍的に届けば、タブレットに入れてはてな閲覧とは別世界で読むことができる。あるいは書籍化して届くというのもいいかもしれない。WEBの海を漂いながら「あとで書籍化」タグをつけたものが、月に一度、製本された紙媒体となって自宅へ届く。素晴らしい生活を送れる気がする。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
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に)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
動的言語は使わない。
動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)
動的DBは使わない。リレーションのない動的DBは使わない(mongoDBやNoSQL系）
動的オープンを紹介してくるメデイアのステマに気づき騙されない
Silerが勧めてくる技術は独立できない技術だからやらない 関わらない
職務経歴書に黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない
PHP Java JavaScript Ruby RoR Html5の仕事は請け負わない
C# Objctive-cだけ使う
VisualStudio Xcodeだけ使う
VisualStudio Xcodeを機能をフル活用する
WindowsServerを使う
デザパタを覚える
コミュニケーションはOffice 365 redMine,イラレGit Svnを使う
動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな
セキュリティに問題のある動的言語はどこにいってもトラブルになる
原発のシステムにRuby,RoR,PHP,JavaScriptを使いたいと思うか？Silerはなら提案してくるだろう儲かるから
使えば必ず原発はハックされる
C# ASP.netは2007年頃から海外では大流行だった 一方日本のメディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた
C#（静的言語）は14年前のソースが今でも使うことができる。VisualStudioにはソースを自動バージョンアップ機能があり書き換えてくれる。 コードが負債にならない コンパイル時バグがわかる DLLのバージョンをチェックしてくれる ブレイクポイント リモートデバッグ
動的言語・オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ、機能追加のたびに修正することになる リファクタが使えない 負債言語
この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか？関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性や仕様変更がたくさん埋まっているソースだ 修正には手間と時間と予算がかかる
C#なら一瞬で最新の.netフレームワークのバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単
PHPを捨てたほういい理由
今はRoRのステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更やバグ、脆弱性は出続け、そのたびに全ソースを検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要で中間業者は儲かるのでメディアや無料育成を通して広めてくる 煽っておいて自己責任の国 日本
静的言語のサーバーサイドで何がいいかというと 自分は C＃ Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方
もうお分かりいただけただろうか？動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語をいつまでも高い稼働の保守作業が必要だ。機能追加、言語の仕様変更、脆弱性を修正するのにお金も時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。
これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料で教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語をマスターしたからといって独立はできない。なぜなら、５人以上のプログラマーが働いてやっと出来上がるものがほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。まさにIT版のねずみ講 上のしか儲からないようになっている。 それに加えて酷いピンハネ。１００万で売って７割以上搾取 一人送れば７０万円入る世界だ。Silerにとって開発現場は炎上すればするだけよい。言語は脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人を適当に教育して３年開発の下駄はかせて送り、現場を炎上させて新たに人を送り込んで利益を得ている。
#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報が流出すること結構あるようだ @WikiはPHP
#2 2013年 Javaフレームワーク Strutsのサポートが終了した こういうフレームワークをメデイアで煽っておいて最後は自己責任される。オープン言語はやってはいけない
#3 これはどの業界にも言える事だが、気合い、根性の気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーションで社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合い根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。（○ーイズ、○ルマー、○ニー、旧日本軍、ジオン軍）タバコ室や残業は特定の社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系か体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる
#5 仕事の最終目的はコミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。Office 365やRedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ
#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る
#9思えばSiler業界は自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率な生産性と保守作業は社会の進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的なスキルしか身に付かなかった。それしかやらせてもらえなかった。
しょーもない言語は社会の発展を止め、技術者を路頭に迷せた。有益な言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたのではないか？
C#はロボットや組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。
特にロボットはMocrosoft Robotics StudioというVisualStudioのロボット版の開発環境が2006年頃から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界はJavaとLampが主)
続き
368 ：ソーゾー君：2014/03/09(日) 02:16:04 ID:qMz.cHPI
平常運行すら無理な状態だから管は真っ先に浜岡を止めたのを知らんのか？
平常運行すら無理な状態になると地震や津波を起こして破壊するんだよ？
平常運行でドカーンだと誤魔化せないだろ？言い逃れする理由が欲しいだろ？
「それにもう解ってると思うけど既に仕掛けて準備はしてあるんだよ？ 」
「だから管は福島を見て計画を理解して命を懸けて政治生命を懸けて
真っ先に浜岡を止めたんだよ？」
平常運行すら無理なんだよ？福島の前の知事か？前の前か？佐藤エイサクだったかな？
コイツが福島原発を止めた理由も平常運行すら無理と知ったからだよ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1358943673/
変な年齢になってしまった。
それなりに働いて、そこそこ恋人とも楽しく過ごし、
ずっとここじゃダメだな〜と思ったら転職し、もう止めようと思ったら別れる。
そういうサイクルを自分なりに回して、今は仕事は順調だけど恋人はいない。
周囲にも、30〜40代で仕事に恋愛に楽しく人生を謳歌している人は沢山いる。
友達も多い方だし、仕事は面白い。恋人がいなくても、まあいっか。
普段はそんな感じなんだけど、時々フッと絶望的な気分になる。
まだそんな歳でもないのに、弱音を吐くと周囲の先輩がたに怒られそうだけど、
それでも時々、すごく生きて行くのが怖くなる。
実際には恋愛を望んでいないかというと、全然そんなことはない。
恋人のいる生活は楽しかったし、仕事が忙しい時ほど心の支えが欲しくなる。
生活の様々な役割を分担すると、肉体的にも経済的にもすごく助かるという経験値もある。
二人三脚で家庭を持ち、子供を育てるのはすごく楽しそうだし、羨ましいと思っている。
遠い将来の不安は別にいい。遠い昔に悩んでいたことを忘れているように、
将来はきっと今の胸の苦しさを忘れているだろう。
将来じゃなくて今が怖い。今、自分は他人にとってどういう存在なのだろう。
若いとは言えない微妙な年齢で、容姿も大したことはない。家柄もごく普通。
すごく焦っていて、どんな手を使っても結婚に持ち込み、人を足がかりに
冴えない現状から抜け出したがっている厄介者に見えるのではないか？
「結婚は楽しそう」「子供が好き」と、思ったことをうっかり素直に口にしようものなら、
獲物に向かって恐ろしい神経毒でも吐き始めたかのように扱われるのではないか。
もっと若ければ、気構えず楽しい恋愛の相手として受け容れられるかもしれない。
もっと歳を重ねれば、焦りの消えた余裕のある大人の恋愛として受け容れられるかもしれない。
自分は今、世間の厄介者、触ると暴れ出す地雷のようなモンスターなのではないか。
様々なメディアで嘲笑されるような、誰かにすがりついて人生を楽にしたがる愚かな考えは全くない。
でも自分の特徴を数えれば、そんなモンスターの特徴と相違ないだろう。
もう若くない。これからは内外の衰えを自覚し、メンテナンスを怠らず、
立ち位置をわきまえ、若い子の邪魔にならない、良い先輩にならないといけない。
それに加えて、じぶんから誰かを容易に好きになり、気軽に誘いかけてはいけないと自制すべきなのだろうか。
C# Objctive-cだけ使う
VisualStudio Xcodeだけ使う
VisualStudio Xcodeを機能をフル活用する
WindowsServerを使う
デザパタを覚える
コミュニケーションはredMine,イラレGit Svnを使う
動的言語は使わない。
動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)
動的DBは使わない。リレーションのない動的DBは使わない(mongoDBやNoSQL系）
動的オープンを紹介してくるメデイアのステマに気づき騙されない
Silerが勧めてくる技術は独立できない技術だからやらない 関わらない
職務経歴書に黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない
PHP Java JavaScript Ruby RoR Html5の仕事は請け負わない
動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな
セキュリティに問題のある動的言語はどこにいってもトラブルになる
原発のシステムにRuby,PHP,JavaScriptを使いたいと思うか？Silerはなら提案してくるだろう儲かるから
使えば必ず原発はハックされる
C# ASP.netは2007年頃から海外では大流行だった 一方日本のメディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた
C#（静的言語）は14年前のソースが今でも使うことができる。VisualStudioにはソースを自動バージョンアップ機能があり書き換えてくれる。 コードが負債にならない コンパイル時バグがわかる DLLのバージョンをチェックしてくれる ブレイクポイント リモートデバッグ
動的言語・オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ、機能追加のたびに修正することになる リファクタが使えない 負債言語
この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか？関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性や仕様変更がたくさん埋まっているソースだ 修正には手間と時間と予算がかかる
C#なら一瞬で最新の.netフレームワークのバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単
&blanklink(PHPを捨てたほういい理由){http://www.slideshare.net/neuecc/c-22979400?v=qf2&b=&from_search=42}
今はRoRのステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更やバグ、脆弱性は出続け、そのたびに全ソースを検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要で中間業者は儲かるのでメディアや無料育成を通して広めてくる 煽っておいて自己責任の国 日本
静的言語のサーバーサイドで何がいいかというと 自分は C＃ Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方
もうお分かりいただけただろうか？動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語をいつまでも高い稼働の保守作業が必要だ。機能追加、言語の仕様変更、脆弱性を修正するのにお金も時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。
これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料で教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語をマスターしたからといって独立はできない。なぜなら、５人以上のプログラマーが働いてやっと出来上がるものがほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。それに加えて酷いピンハネ。１００万で売って７割以上搾取 一人送れば７０万円入る世界だ。まさにIT版のねずみ講 上のしか儲からないようになっている。Silerにとって開発現場は炎上すればするだけよい。言語は脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人を適当に教育して３年開発の下駄はかせて送り、現場を炎上させて新たに人を送り込んで利益を得ている。
#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報が流出すること結構あるようだ @WikiはPHP
#2 2013年 Javaフレームワーク Strutsのサポートが終了した こういうフレームワークをメデイアで煽っておいて最後は自己責任される。オープン言語はやってはいけない
#3 これはどの業界にも言える事だが、気合い、根性の気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーションで社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合い根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。（○ーイズ、○ルマー、○ニー、旧日本軍）タバコ室や残業は特定の社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系か体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる
#5 仕事の最終目的はコミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。 RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ
#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る
#7思えばSiler業界は自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率な生産性と保守作業をしている間に社会の進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的なスキルしか身に付かなかったしそれしかやらせてもらえなかった。
しょーもない言語を技術者に学ばせて社会の発展を止め、技術者を路頭に迷よわすよりも、有益な言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたはずだ
C#はロボットや組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。
特にロボットはMocrosoft Robotics StudioというVisualStudioのロボット版の開発環境が2006年頃から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界はJavaとLampが主)
http://gigazine.net/news/20121231-kiva-system/
それを開発している会社の採用情報 採用言語はC++ C# Java
http://www.kivasystems.com/careers-at-kiva/
PHP RoR JS Rubyなんてどこにも書いていない 数年もすれば仕様が変りバグや脆弱性を出す危ない言語だとわかっているのだろう こんな危ない言語は使ってはいけない
Mocrosoft Robotics Studio
http://www.saturn.dti.ne.jp/npaka/robotics/index.html
https://www.microsoft.com/en-us/download/details.aspx?id=29081
続きはWEBで
368 ：ソーゾー君：2014/03/09(日) 02:16:04 ID:qMz.cHPI
平常運行すら無理な状態だから管は真っ先に浜岡を止めたのを知らんのか？
平常運行すら無理な状態になると地震や津波を起こして破壊するんだよ？
平常運行でドカーンだと誤魔化せないだろ？言い逃れする理由が欲しいだろ？
「それにもう解ってると思うけど既に仕掛けて準備はしてあるんだよ？ 」
「だから管は福島を見て計画を理解して命を懸けて政治生命を懸けて
真っ先に浜岡を止めたんだよ？」
平常運行すら無理なんだよ？福島の前の知事か？前の前か？佐藤エイサクだったかな？
コイツが福島原発を止めた理由も平常運行すら無理と知ったからだよ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1358943673/
368 ：ソーゾー君：2014/03/09(日) 02:16:04 ID:qMz.cHPI
平常運行すら無理な状態だから管は真っ先に浜岡を止めたのを知らんのか？
平常運行すら無理な状態になると地震や津波を起こして破壊するんだよ？
平常運行でドカーンだと誤魔化せないだろ？言い逃れする理由が欲しいだろ？
「それにもう解ってると思うけど既に仕掛けて準備はしてあるんだよ？ 」
「だから管は福島を見て計画を理解して命を懸けて政治生命を懸けて
真っ先に浜岡を止めたんだよ？」
平常運行すら無理なんだよ？福島の前の知事か？前の前か？佐藤エイサクだったかな？
コイツが福島原発を止めた理由も平常運行すら無理と知ったからだよ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1358943673/
368 ：ソーゾー君：2014/03/09(日) 02:16:04 ID:qMz.cHPI
平常運行すら無理な状態だから管は真っ先に浜岡を止めたのを知らんのか？
平常運行すら無理な状態になると地震や津波を起こして破壊するんだよ？
平常運行でドカーンだと誤魔化せないだろ？言い逃れする理由が欲しいだろ？
「それにもう解ってると思うけど既に仕掛けて準備はしてあるんだよ？ 」
「だから管は福島を見て計画を理解して命を懸けて政治生命を懸けて
真っ先に浜岡を止めたんだよ？」
平常運行すら無理なんだよ？福島の前の知事か？前の前か？佐藤エイサクだったかな？
コイツが福島原発を止めた理由も平常運行すら無理と知ったからだよ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1358943673/
368 ：ソーゾー君：2014/03/09(日) 02:16:04 ID:qMz.cHPI
平常運行すら無理な状態だから管は真っ先に浜岡を止めたのを知らんのか？
平常運行すら無理な状態になると地震や津波を起こして破壊するんだよ？
平常運行でドカーンだと誤魔化せないだろ？言い逃れする理由が欲しいだろ？
「それにもう解ってると思うけど既に仕掛けて準備はしてあるんだよ？ 」
「だから管は福島を見て計画を理解して命を懸けて政治生命を懸けて
真っ先に浜岡を止めたんだよ？」
平常運行すら無理なんだよ？福島の前の知事か？前の前か？佐藤エイサクだったかな？
コイツが福島原発を止めた理由も平常運行すら無理と知ったからだよ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1358943673/
