  |
はてなキーワード: スクラッチとは
ゲーセンにおける人間関係はおおむねコミュニケーションノートによって形成される。場合によっては、 twitter などの SNS や、2ch、したらば等のスレッド型掲示板の場合もあるだろう。都会や人口密度の高い地域でのゲーセンは人間関係がプレイに寄与する所は少ないが、田舎のゲーセンは濃密なムラ社会となっており、常連に逆らう事はすなわち論理的・物理的出禁の危険性を孕んでいる。
そういう前提とは一切関係なく、ゲームをやっていて女性と仲良くなれたらとても良いのではないかと思う。何かを始める動機は人それぞれだし、それが不純でも純真でもどうせ100円1プレイの価値は誰がやっても同じなのだから。完全なる主観で適当にモテそうな音ゲーを列挙していくので、音ゲー警察諸氏は余り目くじらを立てないでほしい。
それと、ゲーセンの常連はプレイヤーの顔を意外と見ているし、ゲーセンのゲーム機は公共物である。モテるモテない以前に、人としての最低の水準は守りたい (個人的には、ゲーセンでゲームばっかりやっている人間は自分も含めそもそもに何らかの問題を孕んでいる気もしなくはないが)。
現在もっとも女性比率が高いと思われる音ゲー。ドラム式洗濯機のようなデザインの（というミームの奔流に飲まれすぎた余り公式自らドラム式洗濯機を自称するようになった）筐体であり、2台あるうちの片方がプレイ中の場合もう片方も使用できなくなるという設計になっている。
今ゲーセンにいる女性と交流するためにもっとも適している音ゲーだと思う。
ただ、私事で申し訳ないのだが、肩こりがひどく腕が上がらない為ちゃんとやり込んでおらず、どんな評価体系が存在しており、どういう仕組みでコミュニティが出来上がっているのか全く知らない。ただ普段見ている女性比率と、動画サイト等にアップロードされるさまざまな動画からそう判断した。オフで即ハメ音ゲーに漸近している音ゲーだと考えられる。
maimaiと同じくセガの音ゲーである。操作体系が独特で、上空にあるセンサーの間、虚空へ手を振りぬく操作を求められる。これも結構女性客が付いているが maimai と同じ理由で俺には遊べないので不明。比較的生まれて日が浅い音ゲーで、このゲームをやりこむ前に「このゲームが長生きするのか」という事を各自考える必要があると思っている。
10年前のカジュアル音ゲーの代表格であり、わずかなアニメ・立ち絵(ハリアイ絵)と楽曲のフレーバーテキストだけで数多の女性をスケブ片手に筐体に釘付けた。直線的でシンプルな縦長の筐体、カラフルな9つのボタンがポップでキュートなこのゲームの目印だ。今でこそ「9ボタンとか多くて難しいですよね～」等と言われるものの、カジュアルな音ゲーと競技性のある音ゲーを両立させたその功績は音ゲー界の革命児と言えよう。
最近は相対的に楽曲のパワーが落ちてしまっているのと、流行性の高い版権曲も2～3作で消えるため男女問わず顧客の定着が行われにくくなっている気がする。ゲーセンでこのゲームをやり続けている女子はコアなユーザーが多く、彼女らと警戒されずに話題を合わせるためにはそれなりの上達が求められるだろう。
ゲームシステム的には、プレイヤーの技術を一切要求しない昨今の音ゲー事情としては稀なデザインとなっており(技術を要求したら大不評だったので、以後撤廃された)、はじめてすぐの段階でもすべての要素を楽しむ事が可能となっており、やりこまないと話題に乗り込めない……というような事態は発生しない。
段々書くの飽きてきた。IIDX はコナミの音ゲーで、サウンドブースのような骨組みのデザインに、2つのスクラッチ、14個のボタン、あと正面に謎のボタンやレバーのある筐体である。
あらゆる音ゲーの中で最も高密度な譜面が降り注ぐゲームの為、その内実はともかく非常にアスリート性を高く感じるゲームとなっている。一方で譜面の密度が高いだけでもあり、ある段階を経るまではきわめてシンプルな構造となっている。
さて、 IIDX には Single Play と Double Play の2種類のゲームモードがあるが、モテるのは Single Play である。本作中にはプレイの腕前を格付けする段位認定というシステムがあるのだが、大体6～7段くらいでたむろするユーザーが多いため、10段くらい取っていれば大体ヒエラルキーの上の方に位置出来るだろう。
このゲームは腕前による人間の格付けが驚くほど強烈であり、段位が自分より低い相手、段位のクリアランクが自分より低い相手、自分がクリアマークをつけている曲にマークをつけていない相手など、とにかく他プレイヤーより一点でも優位性を見つけて精神を上層におかないと即死してしまう人が多い。そのため、このゲームをやっている女性と交流しようと思ったらまず彼女らより上手くなりマウントを絶対に取らなくてはならない。より強い雄になる、原始的な交流と言える。
スクラッチの独特のアナログな操作感、本作特有の高密度には慣れが必要なため、ある程度上達するまでに要する時間は1年程度だろうか。ゲームの要領が良い人ならば、最高段位である「皆伝」まで1年掛からずに到達するだろう。音ゲーのそれなりの上達は見た目ほど難しいものではない。もちろん皆伝の上も果てしなくゲームは続いていくのだが、一般的なプレイヤーは余りそういう事を気にしておらず、ランクを評価体系の9割に組み込んでいる。
ボーカロイドの本家（元祖ではない）、ミクちゃんである。このゲームが出た当時はボーカロイドや東方などニコニコ文化が音ゲーに寄与する部分が少なく、ボーカロイドの持つ集客性は音ゲーにとってまだ不可侵領域である時代だった。太鼓の達人など、一部先んじて目をつけていた作品もあるが、ボカロが音ゲーと密接に関わるようになるのはかなり最近の話である。
そういうわけで、ボカロの御大、初音ミクがゲーセンにいてさまざまなニコニコ動画の名曲を遊べるという事、4ボタンしかないシンプル極まりない操作性などの理由で一大カジュアル音ゲーの地位を築き上げたゲームがこの作品である。女性比率の非常に高い作品であり、混雑時は女性の行列に男性一人だけ混ざるという事も頻繁にあった。
とは言え、このゲームも既にリリースから5年近く経過している上に、もはや初音ミクはボーカロイドの主流ではなくなってしまったこと、ボーカロイドはこのゲームの聖地ではなくなってしまった事などの理由で、最近はこのゲームのユーザーもめっきり減ってしまい、まだ更新が続いているにも関わらず、撤去されるゲーセンも徐々に増えてきた。兵どもが夢の跡である。
立方体をくっつけたような小さな筐体があればそれが jubeat である。ボタン数は16個と非常に多いが、叩く場所が光るため光った場所を叩けば良く、ゲーム的にはとっつきやすい構造となっている。リリース当初こそキー音もなくモグラ叩きではないかなどと揶揄されたが、若い世代を中心としてウケがよく、カジュアル層の開拓に一役買ったゲームであると言える。
出だしは比較的好調で客付きも良かったものの、焼畑農業のようなゲーム内イベントをリリースし続けた結果（だと思う）、定着しているユーザー数はほかのゲームに比べ水をあけられてしまった。
最近はややウェイ系のプレイヤーが多く、ガンダム程ではないがプレイ中に騒ぐユーザーをあちこちで見かけるようになったため、女性ユーザーは少し敬遠気味になっているように思う。流動性の高いユーザーはセガの音ゲーにほとんど移動してしまったと思われ、モテ目的でこのゲームを遊ぶ理由はどこにも存在しない。
kinect を利用したアーケードの音楽ゲームであり、画面に表示されたポーズを取るゲームとなっている。他ゲーのコアユーザーに見られる機能性に優れた服装でプレイするユーザーは少な目で、ミニスカや可愛い衣装で踊っている女性が多く、ほかのゲームをやるフリをしてしょっちゅうチラ見するのだが、イケメンで流麗なダンスを踊れればモテるのではないでしょうか？
同名の女児向けアニメと連動しているアーケードカードゲームである。法律上は自販機扱いで、スーパーなどのゲームコーナーでもよく見かける事が出来るだろう。他方バンナムのアイカツとは商売敵のため、バンダイやナムコのゲームセンターでは絶対に見かけることが出来ない。
システムとしては、1プレイする度にランダムで服のパーツ(体上、体下、靴)のどれかと、「トモチケ」と呼ばれる自分のデータを他人に譲るための半券を得る事ができるようになっており、服装データはプレイヤーIDに紐づけられているため、基本的に交換などで手に入れる事は出来ない。唯一ヘアアクセサリだけ交換可能となっており、こちらもトモチケと同じように交流の材料となっている。
幼女から始まり学生、主婦、OLなどなど幅広い年齢層を取り込む事に成功している音ゲーであり、しっかりゲームをやり込んでいると、女性側から声をかけてきてトモチケやヘアアクセを交換するイベントが発生したりもする。
音ゲーマーとしての腕前はほぼ要求されない反面、無数に存在するコーデを組み合わせるセンス、キャラクターへの多少の理解、希少なコーデを入手するための財力と暇が求められる。
人が映った写真を相手に渡すときには、とにかくキレイに仕上げるということに注意しましょう。
そうはいっても外で何の準備もないようなところでキレイに撮るのは難しいですよね。
まずは注意してほしいことは光源の位置です。
男性の場合は彫りが深いことがかっこよく感じられるので比較的影は気にならないのですがが、女性を撮るときは少なくとも真上からの光は避けて光源をできるだけ横から後ろに回すことを意識しましょう。
そうすれば顔全体が柔らかい雰囲気に写るので余計なものが目立たなくなりますよ。
では本日の本題です。
まず覚えておいてほしいことは、写真には撮った後の絵作りが欠かせないということです。
主に使ってるツールがライトルームなのでその用語で書きますね。
まず覚えていただきたいのは、基本的に人が嫌がるのがシワ、吹き出物、頭髪の薄さということです。
女性の場合は明瞭度を下げてるとふわっとした印象になり、男性の場合は明瞭度を上げるとエッジが利いたクールな印象になります。
ノイズ軽減はツルッとタマゴ肌みたいな仕上がりになりますがやり過ぎるとマネキンぽくなってしまうので注意が必要です。
フォトショでいうところのアンシャープマスクやダストアンドスクラッチが該当すると思います。
部分的にぼかしツールでなでてやるのも同じ効果が期待されます。
シワが見える原因は影なのでシャドウを上げてみるのも効果的です。
それなのに写真に残したままにするといつまでもその時の嫌な気持ちを引きずってしまいます。
そんなものはスポット修正ツールできれいな肌をコピペしてして消してしまいましょう。
どうせ写真を渡すのは一週間とか過ぎた後の話ですね。
相手は消えていることにほとんど気づきませんし、気づいたって恨まれるようなことは絶対にございません。
同じようにシミや傷跡なんかも気づかれない程度に薄くしてあげたりするのもやさしい心遣いと言えますね。
写真では回折光というものが肉眼よりも強く感じられてしまいます。その為に細い髪の毛がより細く写ってしまうんです。
そういう時は補正ブラシで露光量を一番低くして生え際や頭頂部周辺をなでてやりましょう。
ハゲたおっさんが黒い粉を頭に撒くのとおんなじで、地肌が目立たなくなるだけで髪が薄い印象はずいぶんと和らぎます。
それにさっき書いた回折光も弱まるので髪が太く感じられるようにもなります。
流量が強すぎると頭頂部に負のオーラをまとったような感じになってしまうので大体10～20くらいで調整するのが望ましいでしょう。
フォトショでいうところの焼きこみツールでなでてやるような感じですね。
撮影時、間違ってもハゲに向かってフラッシュをたかないでください。こればっかりはレタッチではどうにもできません。
そこに写ってるハゲが知人だった場合、ほかにどんな素晴らしい瞬間が納められていたとしても間違いなくお蔵入りです。
それ以外に注意してほしいことは、恥ずかしい瞬間が写っているものはそっと削除してしまうことです。
写真というのは瞬間を切り取りますのでたまに悪意にあふれた写真が撮れてしまうことがあります。
ニュースとかで使われる、おいおいそんな写真つかわなくてもってやつと同じです。
ついつい面白いものが撮れたからと人に見せたくなりますが、そんな写真を見させられて本人が気持ちがいいわけございません。
しかも何が嫌かってその写真が他人の手元に残り続けるわけです。
そんな写真は面白半分でも絶対に他人に見せてはいけません。それ以降その人から写真を撮られることを嫌がられても文句は言えませんよ。
とくに女性の写真には、瞳にキャッチライトを入れると超絶ステキになります。
まずは瞳の黒目部分を拡大して比較的明るい部分を探しましょう。
その後は修正ブラシを使って露光量を最大にして明るい部分をなぞります。
これで潤い輝くステキな瞳の出来上がりです。
慣れてくれば一枚あたりにかかる調整時間はたったの数分です。
たったこれだけの手間なのに、意中のあの子をキレイに仕上げれば二人の距離がぐっと縮まるかも。
あたなの写真ライフがよりすばらしいものになることを願って、それでは皆さんご一緒に「写真に残すのは記録じゃなくて記憶だ！」
またお目にかかりましょう～
webシステムでも絶対にソースコードが流出したらダメな場合はライセンスを買った方が良いです。
http://anond.hatelabo.jp/20140722001658
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
これは大丈夫です。
GPLではソフトウェアの配布時に関係してくるので関係ないです。
これはグレーです。
なんとも言えません。
というのが脅し文句。
ようするに「裁判でどういう判決が出るのか（俺は）分からないので、怖かったら買え」ということ。
でもよく考えるとMySQLが出て長い年月が経ってるのにそういう事例が無い（少なくとも俺は知らない）って時点でリスクなんて無いと思う。
でもいまだにwebシステムでも前者の勘違いをして買ってくれる人が意外に多い。
http://anond.hatelabo.jp/20140722034243
これはMySQLクライアントを利用してDBに接続する多くのwebシステムではグレー。
MySQLに同梱されているクライアントソフトを使わずに自前でクライアントを作って接続してる場合は確実にGPL汚染しない。
前述の通りグレー。わからない。
一端GPL汚染したバージョンが出回った後でライセンスを変更するのは不可能だけど、
次のバージョンからGPL汚染しないように作り直して、ライセンスを変更すれば、
http://anond.hatelabo.jp/20140722143245
有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。
適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。
# どうでもいいけど、元増田の話でOSがLinuxだったりしたら笑うw
GPLは元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスのソフトウェアを利用した場合、WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。
これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。
申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracleの見解である。すなわち、MyODBC(GPLのMySQL用ODBCドライバ)を使わず、GPLでないドライバを用いて接続してしまえば、開発したソフトウェアがGPLにならない。
http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/
# 個人的にGPLがRMSの著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンスで契約しろ」と言われた話を聞いた事があるからだ。
おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通、プログラマが書いたコードの著作権は会社に取られるし、GPLでライセンスされたソフトウェアを受け取ったのは会社であってプログラマ個人ではない。GPLでライセンスされたソフトウェアを物理的にもっていく事は可能でも、きちんとライセンスを受けた訳ではないので機密情報の漏洩にしかならないと思う。
単純な興味なのだけど、例えば最初はGPLだったが途中からはプロプライエタリ(ないし、GPL非互換なライセンス)に変更可能なのか知りたい。個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
http://nippondanji.blogspot.jp/2010/06/gpl.html
http://d.hatena.ne.jp/karasuyamatengu/20110126/1296004598
なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか？ 私の考えが間違っているならなぜ間違っているか指摘していただけますか？ あるいは、下記の増田さんのように具体事例を出してもらえますか？ プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか？
http://anond.hatelabo.jp/20140722071548
とした場合に、PHPを飛び越えて(間接的にしか接続していないにも関わらず)開発したシステムにGPLが適用されるということですか？ その場合、PHPにもGPL汚染が発生するということになると思いますが、間違いありませんか？(FOSS除外規定を設けているのはMySQLであって、FOSS除外規定と無関係な開発したシステムがGPLになってしまうと、開発したシステム側からGPL汚染が発生するという考えから。)
元のパラグラフは下記の通りです。
あと、MySQLのデータベースサーバに接続しただけではGPL汚染は発生しません(AGPLはそのためのものなのは前述の通り)。また、PHPは接続するクライアントになりますよね。ということは、MySQLと一緒に開発システムを一つのパッケージとして納品しない限りはGPL汚染は発生しないのではないでしょうか？(WEBシステムでそんなこと普通しませんよね。yumとかでインストールするし)
根本的な問題として、FOSS除外規定はGPLソフトウェアと他のFLOSSをリンクする際の問題を解決する物であって、MySQLのデータベースサーバに接続する場合には関係のない話だと思います。おそらく、問題だとお考えなのは、PHPのドライバがOracle製のGPLプログラムをリンクしていたためPHPのドライバを利用すればそのような問題が発生するという事だと思います(さらに追記。この通り書かれていますね。よく読んでおらず、失礼いたしました)。現状、PHPライセンスとなっているMySQL Native Driverを利用すればそのような問題は発生しないはずです。
http://php.net/manual/ja/mysqlnd.overview.php
かりに、おっしゃる通り、開発システムもFOSS除外規定に含まれるFLOSSにしなければGPLになってしまうとした場合、それはMySQL独自の問題であり、他のFLOSSに一律で当てはまる問題ではないということでよいでしょうか？ なぜこのような質問をするかというとMongoDBが同じような問題を抱えているからです。下記のURLの通り、MongoDBのコアサーバはAGPLですが、ドライバにApache licenseを適用し、開発システムにAGPL感染が発生しないようにしています。
http://www.mongodb.jp/mongo/licence
上記の様なケースにも実用的に対応する為、（AGPLを採用しつつも）我々はあなた方の（MongoDBを利用する）クライアントアプリケーションは（MongoDBとは）別物扱いする事を約束します。これを円滑に行う為、mongodb.orgサポートのドライバー（あなたのアプリケーションとリンクする部分）はApache licnese（コピーレフト）の元公開します。
返信お待ちしております。
冒頭に書いた通り、間違いがあれば容赦なく指摘してください。
これからのSE業界に新卒で入ってくる人、転職で入ってくる人へ業界の実態とスキルについてアドバイス。
色々就活生と喋っているが、よく言うことを雑多に記載。
【職歴】
・営業社員向けカスタマー管理サービス（CRMシステム）構築：1年
・RFP作成などの上流工程～運用保守の下流工程まで経験あり。
【前提】
・以下は主にSI企業で上流（要件定義）から担当するPM、PLとしてやっていきたい人向けのスキルである。
技術者で食って行きたい人は、全然違うスキルが必要なので無視して良い。
→何も雑談する力が必要なわけではない。ここでのコミュニケーション能力とは「折衝力、人の輪の中に入っていける力」を指す。
システムは人が使うものなので、何をするにもまず人と喋って要件を聞き出さないと話にならない。
技術力があれば良い、と言うのは大きな勘違いで「人に使ってもらえるもの」なので、そこを無視してどんな最新技術を使っても宝の持ち腐れ。
また、往々にして「システムを導入する＝業務をシステムに合わせて変えることが求められる。
これはパッケージシステム導入に限らず、スクラッチでも同様。その時に「業務を変えたくない」連中が抵抗勢力として現れる。
そこを説得するものSEの仕事。そんな敵の中に飛び込んでいって、説得して、最後には協力してもらうまで信頼を勝ち取らなければならない。
そんな場でツボを外したことを言おうものなら、相手からは無視されて終わる。
そんなことが起きないための第一歩としてコミュニケーション能力は必須。
→この２つはセットで考えたい。近年は技術革新が目覚しいため、全部の技術情報を自分で知っているなんて不可能。
そのためにGoogleなどの検索ツールを活用するが、膨大な情報を自分の中でまとめて要点を「つかむ」ことが重要。
細かく知っておくのは専門家の領域なので必要ないが、せめて利用しているツールや技術がなんなのかを、
人に説明できるレベル/類似ツールとの違いを説明できるレベルで知っておく必要あり。
→技術力、プログラミング能力は必須ではない。上記②の人にやってほしいことを伝えるまでには代用できるからである。
しかしプログラマーと対峙するときに、相手はプログラミング言語で会話をしてくる（これは誇張ではなく事実）
その時にいちいち②のプロセスで言ってることを調べていては、理解にロスがかかって進まない。
その時に何か１つでも言語をある程度知っていると、たとえ知らない言語での開発でも言ってることがわかるようになる。
この感覚は例えが悪いが、ピアノを習っておけば、数年後に違う楽器を触っても上達が格段に早いとか、
ドラクエをやっておけば新桃太郎伝説の攻略がスムーズにいく、とかの感覚に似ている。
新卒でプログラミングやったことがなくても、①・②は社会で鍛えられるし、③は研修・OJTという形で経験が積めるから問題ない。
新卒でプログラミングやったことある人は、③が経験済みなので、その分有利である。
転職の場合往々にして即戦力として求められるので、③の経験がないのが大きなネックになる。
巷で言われる業界未経験OKとは、③のスキルがない人のことを指すため、
①・②が人より優れてないと厳しい、ということになる。
参考にされたし。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
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に)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
http://blog.seamonkey-delivery.com/web/910/
このパンくずがイケてないのは分かる。
・ パンくずリストを動的に生成する
（どういう経路でこのページにきたかを表示する）
・ 静的なパンくずリストに拘るのであれば、該当のページは多くのコンテンツからリンクが貼られる汎用的なコンテンツなのでパンくずを表示しない
・ 一つに絞って表示する
くらいしか思いつかない。
パンくずリストの動的生成がCMSに備わっていないのであれば、機能追加でお金がかかるので難しいかもしれない。予算オーバーだろう。
対役所の仕事なので、機能を追加？ じゃあ追加費用ね！ とはいかないし。
そうなると、じゃあどれを表示するか。みたいな話になるんだけど、こういった議論は大体「全部表示すれば問題ないでしょ。足りないなら問題あるけどさ」という結論に陥りがち。
でも、これは閲覧者のことを考えての結論じゃないからな。
結局、色々考えたけど自分が担当者だったら、この表示に落ち着く気がする。
どうでもいいけど、ブコメで
「これダメなの？ なんで？ 委任状で済ませられる届けが一覧できて便利じゃん。全上階層からちゃんとリンク張られているし。利用者目線だと良いと思うけど？」
というコメントがあった。
このリンク自体はあっても良いものだけど、それはもはやパンくずじゃない。「委任状で済ませられる届けが一覧できる」エリアをコンテンツ下部とかに表示しとけば良いだけ。
ぐるなびのポイント「ぐポイント」というものがある。ちょっと前からこのポイントの大盤振る舞いっぷりがすごいことになっているが、意識の高いはてなー（）の間では認知されていないようだ。なので書く。
ぐポイントとは、基本的にぐるなびと契約してる店に行ったり、メルマガに登録したりするとつくポイントで、1ポイント=1円で使えるものだ。
どうせ使った分の5%還元なんだろ、ポイントをためる労力に見合わんとか思うだろ。俺の話を聞け。これがどう大変なのか箇条書きで書く。
5%とかそんなレベルじゃないことが分かっただろうか。650円の定食を食って来店ポイント+メルマガ登録で1000ポイントつくことが普通にある。明らかに経済の原則からしておかしい、異次元といってもいいかもしれない。
さて、これは個人の感想であってぐるなびのステマではないので、よろしくない点も書いておく。
まず、ぐるなびのポイントが使える店が少ない。サイトで使える店を検索できるが、一人の行動範囲の中にせいぜい十数店舗だろう。新宿や渋谷、中央区に住んでいる/勤め先のある諸君は選ばれしものだ。23区でも端の方は壊滅的だ。なんとか県にお住まいの君は、えー、お察しください。リンガーハットは全国全店舗で使えるらしいからちゃんぽん食いまくるといいよ。
次に、これを一番伝えたかったのだが、タダメシを食い過ぎると頭がおかしくなる。先週など毎日銀座で昼メシを食っていたが、1円も払っていない。それなりにちゃんとした店で、サラダ・コーヒーつきのうまいメシを食い、金を払わないで出る。正当な対価を払わないことが、こんなにも、もやもやと据わりの悪いものだと思わなかった。
この大盤振る舞いがぐるなびが儲かっている証拠なのか、食べログに押されてのゴリ押し体力勝負なのかは判断がつかないが、そう長くは続かないだろうと思われる。Naverまとめとかブクマしちゃう諸君は今すぐぐるなびのサイトで検索して、歯ぎしりをするか狂喜するかして頂きたい。
ここ10年のBtoBの成果は、共通の技術基盤という妄想のために用意された
複雑大規模で、完全に閉じてて、他には誰も使えないEclipseで動く謎のゴミ。
自分達でも持て余して、パッケージ導入とか、結局Strutsスクラッチ開発だったね。
まあ、商売ネタとしては成立してたけど。
Struts1のサポートが切れる蓋を開けた時の状況は、笑いどころか失笑でした。
だからってBtoCも凄かったわけじゃない。
そこで事件が起きる。Railsの登場。
ビジネス的には、あんまりインパクトはなかったこれだが、歴史の転換を説明するのには便利。
Railsのアーキテクチャは、エンタープライズのアーキテクチャパターンを程よい感じに取りこんでいる。
Perlパクりから始まって、Javaのクラスパクッて、Railsも速攻パクった。
最近は、所謂関数系言語と分類されるパラダイムも最速でパクてる。
そんな感じで、RailsからパクッたフルスタックのMVCフレームワークが一気に広まる。
そしてこれらのフレームワークは、金魚のフンSierにとって銀の銃弾だったStrutsを、
鼻で笑えるもので、Strutsでドヤ顔してた彼らは、この時点からPHPerからも見下される存在になった。
エース開発リーダーさん。そろそろDIコンテナあたりは使えるようになった？
Javaの方が良いとか言うなら、せめてそのぐらいはフォローしたら良いんじゃないですかね。。。
ただ、これは結果から見たもので、本来の本当の流れは、ネットの普及にある。
BtoCの市場が巨大化し、パイが増えて、それだけ技術者も集まった。
優秀な人材がプロダクトを作れば、優秀なプロダクトが生まれる確率もあがる。
みんなで作れば凄いものが作れるという勘違いは、決してしないように。
これはアーキテクチャにも影響して、その方向性を決めるようになった。
SOAPは、優れていなかったわけじゃない。ただ単に閉じた世界すぎた。
RESTは、実用的なアーキテクチャなんてほとんど無い。ただみんなが適当にやってたのに名前付けただけだ。
だいたい今はそんな感じで
今後はアーキテクチャはBtoCが主導するだろう。
そこの社内SEさん。技術キーワードが凄いからって発注しちゃだめよ。
まともなもんが返ってくると期待しちゃいけない。
BtoBは、この鈍行の間、何もしなかったわけじゃない。
たった数パーセントの稼働率を上げるために、何十倍の時間や金をかけてきた。
彼らは、そういった品質に命をかけてきた。
設計書の文字のタイポをレビューすると、単価計算で１万円以上は余裕でする。
というか、金額の根拠って値切るときに値切り材料を持ってくるのは値切る方の仕事じゃありませんか？
あなたは、テレビを量販店で買うときに、ショップのひとに原材料費はいくらか教えろというのですか？ 仮に原材料費を教えたとしても、そこに研究開発費と利益が乗っているのですが？
また、価格は需要と供給で決まるものであって、原材料費は関係ありません。
つか、ソフトウェアの製造原価で大きなものは 『研究開発費』 だっつーの。
カスタマイズとかサポートなら、人月で受けられるけど、 初期のスクラッチを、人月じゃ受けられない。
認証を許可したら
nginx error!
ってなったよ？ちなみにChrome
いくつかのブラウザでチェックした方が良いよ。
資格なんかより、より実績になるし。
頑張れ。
hakohakoは、バンド好きのためのライブ日程共有サービスです。ツイッターでフォローしている人のライブ日程をカレンダー形式でお届けします。ちょっとでも気になるバンドを見にいきましょう！
すみません。google chromeでしか検証していません。
３つあります。
一つ目は、一人でスクラッチで作りたいからです。プログラムを書くことは楽しいです(たいしたものはかけませんが)。しかし、デザインや運用のことは苦手で経験不足でした。これを期にやってみようと思いました。
二つ目は、少しでも気になるバンドを見逃したくないからです。不精なこともありますが、すべてのバンドをチェックできません。いつのまにか来てたりとか、来る前に解散してました。バンドの魅力は、小野ほりでい先生も認めてます。
一人で小さくwebserviceを作るためにはどうしているかを他の人にも書いてほしいため、自分から書いてみます。
言語はpythonで、web aplication frameworkはflaskを使いました。rubyやphpよりpythonが楽だと思いました。flaskはmicroframeworkで、rubyのSinatraと似ていて、小さいアプリを作成するのに適していました。
永続化のところは、redisを使いました。結果、redisを使った何かになってしまいました。。。mysqlでもpostgresでも、rdbを使った方がよかったです。ただ、sessionの管理やmessage queueを実装できるので、そちらで功を奏しました。
amazon ec2 のmicroで、nginxもuwsgiのreidsもworkerも動かしてます。dot cloudも試していたんですが、無料枠は4月末で終了してました。
デザインが苦手なので、bootstrap、bootswach、font awesomeを使いました。しかし、基礎ができてないためイケてない感があります。ノンデナイザーズブックを読んで出直してきます。
javascriptも苦手なので、coffeescriptを利用しました。pythonを使っているせいか、書きやすいし読みやすいです。mvcframeworkは利用していませんが、modelとviewを意識して書きました。
githubとgitの代わりに、bitbucketとhgを使いました。私にはgithubとgitの敷居は高かったようです。bitbucketは日本語で利用できるので、楽ですね。hgもgitよりも複雑なことを感じないです。ただ、gitの方が日本語ドキュメントは多いです。
gruntは、lessとcoffeescriptのコンパイルで使いました。リアルタイムで変更を通知するlivereloadも併用しました。
楽しいです！
うるせーから調べてきたけど
鷲宮神社においては、彼らが絵馬に『らき☆すた』の登場人物の絵を描いて奉納する、
記念撮影を行う、コスプレ姿で参拝するなどの行動がマスメディアを通じて報じられた[13][14]。
初詣の参拝客も、2008年にはこの年の埼玉県内第3位となる約30万人、
こうした「巡礼」を受け、鷲宮町商工会（現・鷲宮商工会）は、町独自のオリジナルグッズを制作、
同会青年部の運営する大酉茶屋わしのみやや町内の複数の商店にて発売し[17]、
作者や出演声優の鷲宮神社への公式参拝イベントを開催した[18]。
その他にも歳末セールで『らき☆すた』のキャラクターをあしらったスクラッチカードを用いるなど、
様々な地域振興策に取り組んでいる。
地元商工会や町まで巻き込んだビッグビジネスになってるみたいよ。
…っていうことを調べて教えてあげたところで
君は感謝するどころか不機嫌になるだけなんだろうけどね。
頭が良かろうと内容が多ければ長文にならざるを得ないのだけど、その点は考慮外なんだろうなあ。
これじゃあ、スクラッチからHello worldくらいしか書けない程度の技術力なんだろうなあ。
日本企業には上司と部下と非正規しかいない。非正規はよそ者の使い捨ての、封建社会でいうと武士の序列に入らない農民みたいなものなのでこれ以上言及しない。
オレにとって上司の人間でもさらに偉い人からすれば部下だし、その逆もしかり。つまり相対関係。
そしてそれの８０％は入った年次で決まる。つまり同じ会社に何年いるかで決まる。
実力はよっぽど優れたクリエーターとか独占資格を持ってない限り関係ない。
すべては人間関係で決まる、人間関係の根本は親と子、弟と兄といった年齢的要素である。
年次＝企業内での年齢＝親兄弟の人間関係という図式が成立する。すごい事務処理能力の高い奴は逆にねたまれる。
先輩はいつまでたっても上司だが、後輩はいつまでたっても部下。
そして50歳を超えてその積み重ねてきたスクラッチが削られて、役員になれるか子会社に放り出されるかがようやく決まる。
優秀な奴隷は、自社や他社から新しい主人として迎えられることもある。
けど、重要なのは新しい奴隷も古い奴隷もみな平等にただの奴隷だということだ。
先輩後輩はない。
もしかすれば隣で働いている古い奴隷が明日には主人となった自分の奴隷となっているかもしれない。
すべては絶対主義の実力。
主人は主人で独立している。
隣の古い主人の意見は聞かなくてもいい。聞くのは株主というオーナーの意見だけ。
オーナーの一存で放り出されることもあるが、優秀な主人は別の奴隷牧場に今までの奴隷たちを引き連れて、また別の独立王国を樹立する。
http://anond.hatelabo.jp/20120407162253 に便乗して。
それなりに大きなとある会社のプログラマだけど、うちの会社のビルドシステムがおかしい気がする
あまりにも原始的なので違和感を感じるんだけど、自分にビルドシステムに対する知識が圧倒的に不足しているので、今やってる作業に本当に意味があるのかよく分からない。詳しい人に教えてもらいたい。
手動でコピーするからよく事故が発生するし、同じファイルが複数箇所にあるので全然履歴が追えない。
あと、中間ファイルや実行ファイル(.o とか .so とか) も含めてごちゃまぜにチェックインされているので、もっと訳がわからなくなってる。
「ビルドは成功しないのが当たり前」とかいう人ばかりで、正直発狂しそうになる
フォルダツリーがわかりづらいと思うので図を書くと
/ Main/ -- 共通ファイルディレクトリ foo/ bar.c driver/ common.c ProductA/ foo/ bar.c -- ProductA 用の変更が入ってる baz.c -- ProductA 専用ファイル driver/ common.c ProductA_Orig/ -- ProductA/ 内の ProductA用ファイルが丸々入ってる foo/ bar.c baz.c ProductB/ foo/ bar.c -- Main と全く同じ driver/ common.c ProductC/ foo/ bar.c driver/hoge.c ProductC_Orig/ driver/hoge.c
こんな感じになっていて、共通部分は Main/ の中とそれぞれの ProductA, ProductB, ... ディレクトリの中にすべてコピーされている。
チェックインするときはすべてのファイル、例えば bar.c を更新したら Main, ProductA, ProductB, ProductC の bar.c を手動で更新する必要がある。
ビルドするときは Main/ のファイルを ProductA/ にコピーして、 ProductA_Orig/ の中の機種依存ファイルをさらに ProductA/ にコピーする。これは、同名のファイルが Main にもあって、 ProductA のファイルが上書きされるかららしい。
ビルドできないので、最後の最後まで結合テストが出来ずに、みんなローカルPCで開発してる。誰かのPCが吹っ飛ぶとその人が開発していた差分が消失する。
「ツリーを共通部分と依存部分きちんと分けて、ビルド自動化しましょうよ」って上長に提案したら「この会社はこれでやってる。むしろバイナリが入っているのでビルドできなくてもテストできる」という感じであまり真面目に取り合ってもらえなかった。
http://www.yamdas.org/column/technique/hatenablog.html
なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？
まぁ、そんなわけないんだけどね。
「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試みたい。これは、それだけのエントリだ。
というわけで、以下に書くのは、技術の話でも倫理の話でもない。どうか気軽に読んでほしい。
実例を挙げる。
今やワールドワイドな影響力を持つ勝ち組ソーシャルサービスのTwitterだが、彼らは、ここ数年でバックエンドの大半をスクラッチから完全に書き換えた。しかも、RubyからJavaへと、使用言語すら変更してしまった。
http://d.hatena.ne.jp/teppei-studio/20110709/1310168002
もう一つ。Tumblrも、LAMPアーキテクチャからJVMベースへ切り替えた。その過程で、Twitterがオープンソース化した技術を取り入れたりもしている。
http://blog.kyanny.me/entry/2012/02/19/002256
『「古いコードはクズだ」というのは錯覚だ』というJoelの意見は、一面では正しいが、他の面では間違っている。なぜなら、あるソフトウェアに求められていること（要件）は、時間と共にどんどん変化するからだ。
書き直そうが、書き直すまいが、一番ダメなソフトウェアとは「ユーザの要求に応えられないソフトウェア」だ。規模や環境の変化によって古い技術の技術的限界に直面したり、ビジネス環境の変化に追随する必要が出てきたのなら、「スクラッチから書き直す」のは立派に一つの選択肢だ。
はてなダイアリーの最初のバージョンがどういうものかは俺もよく知らないが、おそらく「LAMP」がエッジなキーワードとして持て囃されていた頃に書かれたプロダクトなんじゃないかな（間違ってたら突っ込みを）。それから時代は下り、Ruby on Railsに代表されるCoCなフレームワークの登場を経て、今や大規模分散や非同期を前提としたアーキテクチャが当たり前の時代。当然改修はしているだろうけど、MySQLを職人芸で負荷分散していた時代からは大分遠いところに来たのは間違いない。
何より、はてなダイアリーといえば「はてな記法」とカスタマイズの自由度の高さがウリだったわけだが、これらの存在が、今や機能追加や改良の妨げになっているとしても不思議じゃない。
はてなブログ開発の動機として「今どきの技術で、最初からやり直す」というのがあるのは間違いないが、それは「スクラッチからの書き直し」だから悪手なのだろうか。結局のところ、レガシーコードのメンテナンスを続ける場合と比べてどちらがより低コストか、という話の結論によるとしか言えない。
はてダのソーシャル要素といえば「トラックバック」と「idコール」と「キーワードリンク」だったわけだが、全部Twitter（とTogetter）に持っていかれたよね、という話。
だから、「はてダver.2」や「ブログ2.0」を望む声が大きいのは理解できるけど、ぶっちゃけ、そんなもんに開発リソースを突っ込んでも勝ち目なんか無い。んで、それに代わるアイディアを持ってる奴はどこにもいないと。だから、既存コードの改良ではなくスクラッチから書き直し、スモールスタートでフィードバックを受けながら方向性を考えていく、という方向性はそんなに間違っていないと思う。
ただ、現状を放置すると「それTumblrでできるよ」という話にしかならん、というのはその通りで。それ以外だと、もしgithubがblogサービスを始めたりすると、かなり客を持っていかれるのではないかという予感はする。いっそのこと、Tumblrのデッドコピーから始めるのが一番早いのかもしらんね。
少し別の話を。
これは、Twitterのgithubレポジトリだ。上でも書いた通り、Twitterはサービスをスクラッチから書き換えた。で、その過程で開発した内部向けのフレームワークを、どんどんオープンソース化している。彼らが、内部の技術をきちんと体系化して再利用可能にしていることの証左と言える。
一方、はてなのgithubレポジトリ。正直、サンプルとかプラグインばかりですね、と。
色々と理由はあるんだと思うが、一つ思うのは職人芸頼りで自分たちの技術を体系化するという部分が弱いんじゃないか、ということ（はてな発のオープンソースで広く使われてるのって何かあったっけ？）。
先ほどから散々「書き直していい」と主張しているが、誰かが言っていた通り、技術の本質を捕まえきっていない状態でフルスクラッチをやっても、失敗する可能性は高い。はてなブログがどちらなのかは、中の人にしか分からないことだけど。
はてなが経営的にあまり状況がよろしくない、という推測はおそらく当たっているのではないかと思う。
タイムラインで、誰かが「まっとうな方法で収益化する方法を真面目に考えるべきだった」と言っていたのを見た。それをしていれば、今回のような事態を招くことは無かったのだろうか。
だが、「まっとうなビジネスモデル」とは何だろう。実際問題として、ここ最近成功しているネットサービスのビジネスモデルで「ターゲティング広告」と「マスなユーザベースから抽出したビッグデータを解析して売る」以外で何か有力なものはあっただろうか。FacebookにせよTwitterにせよ、収益化の原動力はユーザ行動解析だったりするわけだ（彼らがオープンソース化に積極的なのは、インフラ技術が差別化の源ではない、という面もある）。
まぁ、あとはガチャだが、どちらにせよ現状では高木先生の逆鱗に触れるようなものしかないよね。
そんなわけで、それらに代わる第四のマネタイズモデルを思いついた人は、ぜひ近藤さんに教えてあげると良いんじゃないかな。あればだけど。
今後はてながどうなるかは分からないけど、一つ希望したいことがあるとすれば、故伊藤計劃氏のダイアリーがこの先も保全されることを望みたい。
それは、エントリを全て魚拓しろ、という話ではもちろんない。彼の生前に書かれたエントリは、当時の「はてな」という生態系を構成する一部でもあるわけで、そこから切り離して文章だけをアーカイブしてもあまり意味がない。
頭よくなりたい。筋肉ムキムキになりたい。
人には実に色々な願望がありますが、ほとんどが実現されないのが現実ではないでしょうか。
ちなみにお察しの通り、上に書いたものはすべて私の今の願望です。
こういった願望を抱くという事は、現状はすべて逆であるということです。
でもどうしても願望を実現し、現状を変えたいという強い思いだけはあります。
そして強い思いだけもって特に何も変わらない、悶々とした日々をすごしてきました。
が、昨日我が家の本棚に「引き寄せの法則」「ザ・キー」という2冊の本を見つけました。
これは母が何年か前に買った本で、今まで特に気にしていなかったのですが
昨日なぜか急にこの本が目に入ったのです。
母に聞いたところ、「結局宗教っぽくてあんま面白くなかったよ」といわれました。
しかしとても気になってしまい昨晩と今朝で一気に2冊読んでみました。
確かに宗教っぽい。でもこれ全部マジだったら俺も変われるかもｗ
とりあえず「引き寄せの法則」よりも「ザ・キー」の方が自分にはわかり易かったので
こっちに書いてあったメソッドとかを一通りやりながら願望を実現してみる。
本当はもっと書いてありましたが、自分の中で印象に残った部分だけ抜粋しました。
では、順に実行していきます。
まず、引き寄せの法則とは、僕らが何か思考すると、それを宇宙が受け取って あとは勝手に現実にそれを物質化して叶えてくれる。 ボールを真上に投げたら、重力によってまた自分のとこまで戻ってくるのと同じように 例外なく自分の思考はすべて現実のものとなっている。という法則のことです。 これがなかなか実現出来ないのは、例えば「超絶美人なお姉さんとHな事したい！」と思考したときに 「でも俺ブサイクだし、そんなお姉さんにすかれるわけがない。」とか「第一出会いがねーし！」みたいな 思い込みによってこの願望は実現を阻まれているそうです。 だから、この思い込みをクリアにすれば願い事はすべてかなうのです！ というのが一番最初に書かれてました。
まず1億円くらい手にする。 免許を取って車とバイクを買う。 顔が向井理みたいにイケメンになる。 体がジェイソンステイタムのようにマッチョになる。 スポーツ万能になり、フットサル・テニス・ボーリング・ゴルフ・ダーツなどの 大会で全て優勝する。 1ヶ月で10カ国以上を旅する。移動の飛行機は全てファーストクラス。 頭がよくなり、業界で世界的に有名な人間になる。 かわいい子にモテるようになり、セフレが５，６人くらい出来る。 風俗に週２で通う。
結構遠慮しませんでしたが、1億円は「さすがに10億は行きすぎだろ」 とか考えてたので、1000億くらい手にする。に変更。 あと、スポーツの大会は「外人には勝てないよね」って思って国内を想定してたので 世界大会で優勝に変更。 旅行の部分は「10カ国とか時間的にキツいかな？」とか考えてたので 1ヶ月で30カ国に変更。
著者の友人はこんなことを言ったそうです。
多くのひとはその瞬間を生きていない。
常に、つぎの契約、つぎの車、つぎの家、つぎの昇給について考えていて、
パワーの基点、つまり、真の奇跡がいまここにあるということに気づいていない。
「ザ・キー」P75より
確かに、僕も今足りないものばかりだから、これが満たされたら幸せになれると思ってました。 でも、つぎばかり求めてると、つぎが来た時にはまた「つぎのつぎ」を求めるようになり 結局いつまでたっても幸せになれないのだそうです。なるほど。 で、ここでは自分が今感謝できることをひたすら書いていきます。 特に大きな病気もなく健康に暮らせている。 家族もみな健康である。 毎日行く場所がある。 毎日おいしいご飯が食べれている。 適度に遊べている。 面白い友人達に毎日会える。 たくさん寝れてる。 帰る家がある。しかも駅から近くて綺麗で広い。 車も原付もほぼ好きな時に寝れる。 書き出してみるとかなり恵まれてると思ったｗ
「愛してる」って言う。というか心で唱えるだけでも問題を解決することを
妨げているものを除去することが出来るらしい。
これからはよく唱えるようにしよう。
自分が望むことをシナリオのように、既に起こったこととして書くと
その通りになるらしい。
私は、はてなの匿名ダイアリーを書いていました。そこには自分が願望実現を リアルタイムで実践していく様子を記していました。 一度書き終えてから、たまたま通りすがった宝くじ屋でスクラッチタイプのくじを2枚購入。 その際には先ほどの教えに従って、売り場のおばちゃんに「愛してます」といいました。(心のなかで) しばらく歩いていると、後ろから急に「おにーさん！」と肩を叩かれ、驚きながら振り返るとめちゃくちゃ可愛いギャルが・・・ きっと美人局に違いないと思った僕は「すいません」と言い残し足早にその場を去ろうとしました。 しかしギャルは「今何してるのー？？どうせ暇なんでしょー！カラオケでも行こうよっ☆」と満面の笑みで誘ってきます。 「か・・・可愛い・・」それでもまだ美人局の可能性を完全には否定できないと思った僕は「ごめんないさい。用事があるので」と ギャルの誘いを断ってしまいました。これが引き寄せの法則の力だとしてもさすがにいきなりは怖いと思ったので自分的には 正しい判断だと思います。結局メアドだけ交換してギャルは去っていきました。 生まれて初めての逆ナンにテンションがあがった僕はまたもや目に入って来た宝くじ屋で今度は5枚 スクラッチタイプのクジを購入しました。 近くにあった漫画喫茶に入り、買った7枚のスクラッチクジを一つ一つ丁寧に削っていきます。 この時、なぜか高額当選が当たり前かのような気分に浸っていました。 そして4枚目のクジを削ったときに見事1等当選！！！ 当たり前とは思っていたものの、思わず叫びそうになるのを必死に押さえ、喜びをかみしめます。 残りの3枚を削ってみると、ほかにも3等と200円の当選が各1枚ずつまぎれていました。 自分の身に起こったシナリオ通りの事態に足を震わせながら換金へと向かいました。 換金後はもちろん先ほどのギャルに連絡し、早速遊びに行っちゃいました。
さて、とりあえず今から、気持ちい気分で最後に書いたシナリオの場面を想像し
※購入後につづきを書きます。
待っていた人などいないと思いますが、皆様お待たせいたしました！
結果報告！！
逆ナン：されず・・・でも可愛いギャルとたくさんすれ違いました。
スクラッチ：購入しましたが、今の気持ちだと何か当たらないような気がするので
正確にはわかりませんが、少し調べた結果エゴが原因なんじゃないか。
という仮説にいたりました。
では、逆ナンされるのを期待しながら歩いてたときの自分の思考を振り返ってみます。
「可愛いギャルからナンパされるかな～」 「いくら引き寄せの法則とは言えど、ありえないかなぁ」 「ありえないとかって感情を抱いた時点で無理かな」 「いや、ありえなくない！でも逆ナンされたときの気持ちい感情を味わえって書いてあったな」 「そもそも逆ナンされたことないから感情とかワカンなくね？」 「とりあえずワクワクしてみよう！！」 「ワクワク・・・これでいいのかなぁ・・」 と、いう具合に自分の中のエゴが 「逆ナンなんてありえない！引き寄せの法則などあったとしても お前のやり方は間違っている！」 って言ってる気がして、自信を喪失してたようにも思います。
そこで、エゴにはそんな能力すらないのだから、否定的な気持ちになるのを
理解してあげつつ、さよならと言って消し去ればよいらしい。
ちなみに、調べてたら「100%バカになる方法」というのを見つけた。
