  |
はてなキーワード: MONOとは
Twitterで「消しゴムマニアの私からみんなに向けてのメッセージです…ぜひ参考にしてね…」というつぶやきが話題になっているけど、こういうとき必ず来るリプが、「ちょwお前のツイート伸びすぎww有名人じゃんwww」「パクられてますよ」ともうひとつ、「SeedのRadarとTombowのMonoは同じものらしいです」「TombowのMONOは SEEDのRadarのOEM品らしいので同じ物の様ですよ」といったもの。
どういうことかというと、日本の消しゴムは消しゴム専業メーカーからのOEM供給によって成り立っており（※ぺんてると海外メーカーを除く）、有名文具メーカーの消しゴムも、実際に製造してるのはスリーブのクリーンマークの番号が示す7社のいずれかなのだとか。
つまり、一部番号が印字されてない消しゴムもあるものの、表でまとめるとこういうこと（※無印良品などはよくわからないので除く）。
| 番号 | 製造元 | 販売元 |
|---|---|---|
| 01 | シード | シード、トンボ鉛筆、コクヨ（リサーレ）、ナカバヤシ、三菱鉛筆、クツワ、サンスター文具（MONO） |
| 06 | ヒノデワシ | ヒノデワシ、プラス、三菱鉛筆、サンスター文具（まとまるくん）、レック（激落ちくん） |
| 11 | ラビット | ラビット、サクラクレパス、パイロット、コクヨ（リサーレプレミアム） |
| 13 | ぺんてる | ぺんてる |
ということは、「レーダーよりMONOの方が消える」とか、前述のツイートにもある「MONOは折れるけどレーダーは折れない」みたいなのは全部気のせい…？
修正後: https://thinkit.co.jp/article/11373
差分: http://difff.jp/4jrxz.html
以下、大きく変わった箇所を抜き出します。
ちょまど：もう一つ言えば、開発ツールが無償じゃないのもなんか間違ってるって思っていたんですよ。なのでXamarinがマイクロソフトに買収されたって聞いた時にすごく喜んだんです。これでXamarinはきっとOSSになって無償になるって思って。
↓
ちょまど：もう一つ言えば、開発ツールが有償だと開発者に浸透しにくいって思っていたんですよ。なのでXamarinがマイクロソフトに買収されたって聞いた時にすごく喜んだんです。Xamarinはライセンス代が高かったけど、これによりきっと無償になるし、しかも（XamarinチームはもともとMonoチームが母体でOSS好きなのもあり）XamarinのランタイムがOSSになって人に勧めやすくなるかなって思って。
----
ちょまど：そうです。私は逆にマイクロソフトはWindowsの会社としか知らなくて、開発者になってからはVisual StudioやC#の会社で、とってもOSSな会社だって思ったんですが、入って気づいたのは世の中にはものすごくマイクロソフトがキライな人が多いって言うことで（苦笑）。なんかアンチな人が特にインターネットには多いです。
----
ちょまど：さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、私からすればエディターがOSSなのは当たり前だし、開発ツールは当然マルチプラットフォーム対応だし、そういうのはもうホントに当たり前だったので一緒に盛り上がれなくて悲しいです（笑）。
↓
ちょまど：（さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、）私からすればVisual Studio CodeのようにエディターがOSSなのは当たり前だし、Mac版のVisual Studioが出たように開発ツールは当然マルチプラットフォーム対応だし。マイクロソフトが変わって衝撃！ という話題で一緒に盛り上がれなくて悲しいです（笑）。
----
ちょまど：でも無料じゃない開発ツールっていうのが不思議だったんですよ、そんなことしたら開発する人も増えないし、結果的に不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら無意味だ！」って思ってました。なのでXamarinがマイクロソフトに買収されてホントに嬉しかったです。だってAndroidとiOSの両方作ろうと思ったら1年で25万円くらいかかるんですよ。
↓
ちょまど：でも無料じゃない開発ツールっていうのが不思議だったんですよ、ベースが有料だと、開発する人も増えにくいし、結果的に不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら広まりにくいよ！」って思ってました。XamarinでAndroidとiOS版の両方のアプリを作ろうと思ったら、ライセンス代が1年で25万円くらいかかってたんですよ。私みたいな社会人歴2〜3年の人が趣味でやるには高過ぎる値段でした。
----
正直言って元記事のちょまど氏の発言は不正確なところが多々あった。
Microsoftの方によると
修正は本来ならあり得ないんですけど、コンテキストが落ちちゃってるところがいくぶんあったので(^_^; https://t.co/5TzS8rY5cH— Azure工事担任者 (@rioriost) 2017年5月12日
インタビューなので、なかなか難しい...。分かってる前提、つまりハイコンテキストで喋ってるわけで、そういう前提までは記事に書かれてないんですよ(^_^; https://t.co/lXLjOVg9D7— Azure工事担任者 (@rioriost) 2017年5月12日
意識低い企業内研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。
働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。
C言語とかC++は・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、
WindowsのAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。
組み込みプログラミングではC言語はいまだに現役。お金も普通に稼げると思うよ！次代のCOBOLと化しそうで怖いとこはあるけど。
Javaは・・・使える人が多いからあえて今から学習しなくてもいいような気がする。
文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有のセオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。
セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから。
Goは・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。
ライブラリの選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。
GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。
Goでデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。
GoでGUIつくるの？あんまり普通じゃない気がする。軽量プロセスのうまみがそんなない（詳しい人に否定されそうだけど）
普通にC#(mono/.net)かwebアプリにするかで良くないか？
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いから自分からリプは送ったりはしない。
ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。
アルゴリズムは使うものだ書くものではない！高階関数とかテンプレートプログラミングとかその辺勉強するといい。
あと計算が制限時間内に終わるなら総当たりが最速で品質も高いぞ。
どうしてVimかというとプラグインが多いしIDEっぽくできるから。
Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。
NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。
Vim知らない。Linux使うならVimかemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
VirtualBox上のubuntuでMySQLをコンパイルすると2時間20分ぐらいかかった記憶がある。
CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。
スペックにお金をかけることで時間の節約ツールの選択肢が増える
EclipseなどのIDEが支障なく使えるレベルのスペックってどのくらいするんだろう。
3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。
Pythonは・・・・機械学習する上で避けて通れないけど、今のPCだと無理。
Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。
使ってないけど最先端の研究では機械学習使って当たり前感があってそろそろヤバい。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
なんとなく、プログラミングじゃないほうがいい気がするなあ。
免責： これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」
http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace
この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSSの翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます。
ですが、プログラマの間で単にWeb翻訳をOSSに使ってはいけないんだという認識が広まってるように見えます。個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています。
どういう話かというと、自分が個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースのライセンスで公開しています)
念のため言っておきますが、これは元記事で問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります。
コミュニティの思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。
もとの記事のとおり、Excite翻訳の利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。
ここでは、Google翻訳に焦点を当てた話をします。Google翻訳の利用規約はどうか？というと、Googleの利用規約については翻訳結果の利用についての記載がありません。
https://www.google.com/intl/ja/policies/terms/
記載がないということは、使用してよいのか？使用してはいけないのか？いったいどちらなのでしょうか？
機械翻訳の権利問題と似た構造の話に、GPL（GNU一般公衆ライセンス）で許諾されたコンパイラによってコンパイルした結果の利用があります。
GPLの本文には、GPLのプログラムの出力結果自体にGPLのものを含む場合にのみその出力結果にGPLが適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているかの記載はありません。
これについては、コンパイラによるコンパイル結果に対して、コンパイラの著作者はなんら権利を持たないと考えるのが一般的です。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput
著作権法は人々があなたのプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。
コンパイラと機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります。
ウィキメディア財団の法務チームは、Google翻訳した文書のウィキペディア内での利用についての見解を公開しています。
https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations
これはアメリカの法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスのコンテンツをGoogle翻訳で翻訳してウィキペディアで使用してもGoogleの著作権を侵害する可能性はとても低い(very unlikely)と結論づけています。
要点をまとめると以下の通りです。
ウィキメディア財団の見解には含まれていませんがアメリカの法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。
これはAndroidのAPIにJavaのAPIが流用されていることについて、OracleがGoogleを訴訟したものです。
これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコの地裁では著作権使用料支払いの対象にはならないという判決が下っています。
「フェアユース」というのは、アメリカの著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権の侵害とはしないと考えるものです。
ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidのJava APIの流用と比べても、さらにフェアな利用であるように見えます。
(ちなみにGoogleの利用規約には、「カリフォルニア州の抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州の法律が適用されます。」と書かれています)
著作権情報センターのサイトに、 コンピュータ創作物についての文化庁の報告書が記載されています。
http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html
この報告書は、機械翻訳のユーザーが機械翻訳システムを使用するために行う原文の編集や出力の編集が創作的寄与となりうることを認めている一方で、機械翻訳の開発者が翻訳物の著作者になるということについては否定的です。
なお、原文解析等のプログラムの作成者及び汎用的な辞書データベースの作成者は、一般的に翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定の翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。
これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳の技術は大幅に進歩しましたが、創造的個性の表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます。
これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者の著作物。機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間の二次著作物になるということになりそうです。
これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているかを説明してきました。
では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。
だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。
著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。
有名なところでいうと、Monoが思いつきます。AndroidのDalvikがJavaのAPIを真似したものであるのと同じように、MonoはMicrosoftの.NETフレームワークを真似しています。つまり、Monoについても訴訟リスクはあっただろうということです。
しかし、OracleとGoogleが対立したのとは対照的な道をMonoはたどります。
2016年、Monoのプロジェクトを運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoがMicrosoft公認のプロジェクトになったというわけです。
権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。
すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntuの日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています。
まずは質の問題です。現在のGoogle翻訳などは、UIの翻訳に向いていません。UIのほとんどは、意味合いが文脈に依存する単語や短文です。UIの翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。
Google翻訳などを使って一括で、訳語を割り当てても良いUIの翻訳はできません。
（ UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 ）
次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntuの日本語化ローカライズであれば、すでに多くのユーザーが使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります。
そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。
つまり、クオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。
とはいえ、OSSには個々の事情があります。次は自分の場合の話をしてみます。
まずは質の話です。
自分のプロジェクトの場合、Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティの翻訳が出力されており、自分でゼロから翻訳するよりも、原文を翻訳しやすく修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳を使用しました。
次にリスクの話です。
OSSが企業に権利問題で訴訟されるということはめったにありません。OSSは公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。
訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSSで大金が儲かったらGoogleから訴えられてしまう！どうしよう！と考えるのは、宝くじに当たったら強盗におそわれてしまう！どうしよう！と考えるのに似ています。
まず宝くじは当たらないですし、宝くじが当たったらそのお金で対策を行えば良いだけの話です。
実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立しています。Linuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。
これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。
権利問題で訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業にうんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます。
結局のところ、自分の場合はGoogle翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Googleも翻訳を改善するためのデータを得られます。
わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。
結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか？というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェアの翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。
質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります。
各OSSの翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)
五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee scriptが結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい！！みたいに言ってるんじゃないでしょうか。
まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります。特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ（≒JQuery）と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。
まあこれを突き詰めるとじゃあetaxもactivexで、銀行のシステムはcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、
とりあえずこんなところで、有識者の皆さんよろしくお願いします。
React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。
id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない？という感じです。
id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で（どのくらいの規模のプログラムで）domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。（もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。）なんかReactががりがり（かつユーザー目線から見て有効的に）使われている例がイメージ出来ないのが問題な気がしてきました。
id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。
id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domのメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。
id:manaten もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
1980年代の小学校では、ある玩具が爆発的に流行しては、教師により特定の玩具の持ち込みが禁止されるという状況にありました。
コマなど駄菓子店で売られる玩具については、ほとんどが早期に禁止を言い渡されています。
その後、玩具は子供側に「これは勉強に使うものだから」という言い訳がある、文具店で販売されるものへと移っていきました。
キャラクターがキャップ部分についたシャーペン、色鮮やかな練り消しゴムなどです。
それらも、爆発的に流行して教師が持ち込みを禁止するのは、他の玩具と同じでした。
消しゴムは玩具性が低いとみなされ、子供たちが「自分の考えで」何かを選んだと主張するのに便利な品でした。
例えば、消しカスがひとつにまとまる消しゴムは、練り消しゴムの禁止が教師から告げられたあと、自家製の練消しを密造するのに使われていました。
練り消しゴム以外の、教師にとがめられない消しゴムは、おもに以下の３タイプでした。
・上記の箱が失われ、カドも無くなって、ほぼ円盤上になったもの
・片方が白く、もう片方が灰色の砂消し（すなけし、砂消しゴム）
小学校では休み時間になると、ボールを持って校庭へ飛び出す子供たちとは別に、教室にとどまり、学習机上で上記の消しゴムを使った「ピンピン」で遊ぶ子供たちがいました。
ピンピン基本ルール
1. 複数人が１つの学習机の端に、自分の消しゴムを置きます。
3. 自分の消しゴムを弾き、他の人の消しゴムにぶつけて机から落とします。
1. 自分で弾いた消しゴムを机から落としてしまった場合、勝敗はカウントされません。落とされた消しゴムとともに、落ちた地点に再配置します。
2. 攻撃する消しゴムの持ち主は、親指で溜めて人差し指や中指で弾くほか、逆に親指で弾く、プラスチック定規をばねとして使う、ノック式ボールペン（側面のスイッチで収納するタイプのもの）の戻る勢いを利用する、などの弾きかたがあります。
3. 狙われている消しゴムの持ち主はタイムを取り、机に密着させる、角度を変える、立てて相手ごと落ちやすくするなど消しゴムを置きなおすことで防御ができます。
4. 攻撃側も消しゴムの置きなおしができます。攻撃者と隣接してピンチの守備側が消しゴムを立てる→攻撃側も消しゴムを立てて底を弾こうとする、などの攻防があります。
5. 他のプレーヤーは、攻守の２人が時間を掛けすぎていると、早くやれと急かしていました。
文字を消す能力はないが小学校に持ち込むための言い訳に消しゴムの名がついた樹脂製玩具として、「キン消し」（キン肉マン消しゴム）の発売以前、「スーパーカー消しゴム」がありました。
スーパーカー消しゴムは他の消しゴムとピンピンで争うには軽量すぎ、おもにノック式ボールペンが戻る力で弾く方法で、スーパーカー消しゴムのみで対戦されていました。
必要な道具がひとつ多い、スーパーカー消しゴムどうしでは戦いに変化がない、などの理由で、流行はしたものの早期に廃れていきました。
私のいた小学校でキン消しが流行したのは、ピンピンにおいて、キン消しが適していたためです。
机の端で守備側がキン消しを立たせると、机から相手ごと落ちないようにするために、攻撃側には繊細な力加減が求められます。
重量がある「サンシャイン」、回転させてぶつけることができる「アシュラマン」は特に子供たちから愛用されていました。
プロレス技のポーズをとった姿のキン消しは安定性に欠け、ピンピンでは負けてしまうので嫌われました。自立できるポーズのキン消しがピンピンでは好まれました。
キン消しで漫画内のシーンを再現するような遊びは、ほとんどされていないか、ごく早期に飽きられていました。
私の周囲では、キン消しはピンピンのための器具として扱われていました。
omaeno shoppai ronri de kuetara iina
shinyou no nai neet ga nani ittemo muda dato omouzo
hayaku sono semai sekai kara deteiku yuuki no taisetsu sa ni ki ga tsu ku to i i ne
yuuki ga naito zenshin dekinai no ha youchienji demo wakatteruzo
kodoku ga sekai wo semaku shiteiru kara sonkei dekiru hito wo mitsukeru koto ga taisetu
sore ga dekinai to omae ha itsumade mo dare mo shinjirarenakute hitoribotti de dare no mane mo dekinakute
hikagemono de rouhi site owaru google kensaku site hito ni au yoyaku wo tore mazu sorekara da
sippai ha nankai demo shite iiga shiturei no naiyouni shitahouga nochi nochi iizo muda na baka ha herase
hontou ni suki na hito to dake au jikan wo fuyashi hontou ni suki na koto wo yaru jikan wo fuyasu dake
mesaki no yoku ni oboreruna shikashi challenge shiro
kane ha taisetu ni siro jikoshoukai de kane ha kasanai to ie issen mo dasenai to ie
jiko keihatsu hon nante 35 sugitara taitei no mono ha daredemo kakeru kara
ore ha tenpuu wo chotto hiraite neru
プログラムはclassに記述します。たとえばSampleという名前のclassを作る場合、Sample.csファイル内に次のように書きます。(C#の場合、ファイル名とクラス名は同一でなくても良い。複数のクラスを書いても良い)
public class Sample { }
プログラムはclass内のMainメソッドの先頭から実行されます。Mainメソッドは次のように書きます。
public class Sample { public static void Main( String[] args ) { // 処理を書く } }
Console.WriteLine( "Hello world" );
コメントです。
// 一行コメント /* 複数行コメント */
// 変数 int num;
データ型です。C#のデータ型には値型と参照型とがあります。以下は値型のデータ型です。
// int(整数)型 int num; // char(文字)型 char c; // float(単精度浮動小数点)型 float val; // double(倍精度浮動小数点)型 double val; // bool(論理)型 bool flag; // DateTime(日付)型 DateTime date;
以下は参照型のデータ型です。
// String型 String s; // 配列型 String[] array;
プログラムをコンパイルするには、コマンドラインで以下のようにします。
csc Sample.cs
プログラムを実行するには、コマンドラインで以下のようにします。
Sample.exe
mono ./Sample.exe
int、float、double型の変数に数値を代入できます。int型には整数だけ代入できます。float、double型には整数でも小数でも代入できます。
int i = 2; int i = 100000000; float num = 1.234f; double num = 1.234;
四則演算です。
num = 1 + 1; num = 1 - 1; num = 1 * 2; num = 1 / 2;
商の求め方です。割る数と割られる数が両方とも整数の場合、計算結果の小数点以下が切り捨てられます。
num = 1 / 2; // 0
割る数と割られる数のどちらかが小数の場合、計算結果の小数点以下が切り捨てられません。
num = 1.0 / 2; // 0.5 num = 1 / 2.0; // 0.5 num = 1.0 / 2.0; // 0.5
余りの求め方です。
// 余り mod = 4 % 2
インクリメントとデクリメントです。
// インクリメント ++i; // デクリメント --i;
String str = "abc";
// 結合 String join = "aaa" + "bbb"; // 分割 String[] record = "aaa,bbb,ccc".Split( "," ); // 長さ int length = "abcdef".Length(); // 切り出し "abcd".Substring( 0, 2 ) // abc // 検索 int result = "abcd".IndexOf( "cd" ) // 見つかった場合はその位置、見つからなかった場合は-1が返る
配列です。
// 配列の宣言 int[] array;
配列の生成です。配列の生成時には要素数を指定するか、初期データを指定します。
int[] array; // 要素数を指定して配列を生成 array = new int[5]; // 初期データを指定して配列を生成 array = new int[] { 1, 2, 3 }; // 宣言と同時に配列を生成 int[] array2 = new int[5];
配列の要素の参照と代入です。
// 要素の参照 array[0] array[1] // 要素の代入 array[0] = 1; array[1] = 2;
array_num = array.Length;
int[] from = new int[] { 1, 2, 3 };
int[] to = new int[5];
from.CopyTo(to, 0);
if文です。
if ( 条件 )
{
}
if ～ else文です。
if ( 条件 )
{
}
else
{
}
if ～ else if文です。
if ( 条件 )
{
}
else if ( 条件 )
{
}
while文です。
int i = 0; while ( i < 5 ) { // 処理 ++i; }
for文です。
for ( int i = 0; i < 5; ++i ) { // 処理 }
int[] fields = new int[] { 1, 2, 3 }; foreach (int field in fields) { // 処理 }
C#では関数をメソッドと言います。メソッドを作るには次のようにします。戻り値を返却するにはreturn文を使います。
static int sum( int num1, int num2 )
{
int total;
total = num1 + num2;
return total;
}
ファイル入出力です。ファイル入出力を行うには、プログラムの先頭に以下を記述します。
using System.IO;
以下がファイル入力の雛形になります。ファイルのオープンや読み込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamReader reader = null; try { reader = new StreamReader(filename); String line; while ((line = reader.ReadLine()) != null) { } } catch (IOException e) { // エラー処理: } finally { if (reader != null) { try { reader.Close(); } catch (IOException e) { } } }
またはC#ではusing ステートメントと言うものがあり、この様にも書ける
String filename = "text.txt"; using (StreamReader reader = new StreamReader(filename)) { try { String line; while ((line = reader.ReadLine()) != null) { // 読み込んだ行を処理 } } catch (IOException e) { // エラー処理: } }
usingをつかうとCloseがなくなったことからわかるようにusing(){}を抜けるときに自動的にDisposeメソッドを呼び出し、オブジェクトを廃棄する。その分コードがスッキリするが、使いにくい場面もあるので考えて使うこと。
以下がファイル出力の雛形になります。ファイルのオープンや書き込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamWriter writer = null; try { writer = new StreamWriter(filename)); writer.WriteLine("abc"); writer.WriteLine("def"); writer.WriteLine("fgh"); } catch (IOException e) { // エラー処理: } finally { if (writer != null) { writer.Close(); } }
こちらもusingを使って書ける。が、割愛する。
C#でよく出てくる知っておいたほうがよい文法の一覧です。
繰り返し文の途中で抜けるにはbreak文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { break; // 条件を満たす場合、for文を抜ける。 } }
残りの部分処理をスキップし、次の繰り返しに進むにはcontinue文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { continue; // 条件を満たす場合、残りの部分処理をスキップし、次の繰り返しに進む。 } }
例外を投げるにはthrow文を使用します。
throw new Exception( "Error messsage" );
try { // 例外が発生する可能性のある処理 } catch ( Exception e ) { // 例外発生時の処理 }
の子（Vo, G）、mono（Key）、ちばぎん（B）、みさこ（Dr）の千葉県在住メンバーからなるロックバンド。の子による2ちゃんねるバンド板での宣伝書き込み活動を経て、自宅でのトークや路上ゲリラライブなどの生中継、自作ビデオクリップの公開といったインターネットでの動画配信で注目を集める。
2009年には1600組の応募バンドの中から選ばれ、一般公募枠で「SUMMER SONIC 09」に出演。2010年3月に初のCD作品となるミニアルバム「友だちを殺してまで。」を発表した後、ワーナーミュージック・ジャパンと契約し、2010年12月にメジャーレーベルのワーナーから「つまんね」、インディーズレーベルのPERFECT MUSICから「みんな死ね」という2枚のアルバムを同時リリースした。
2011年4月にはバンド史上最大規模の会場となる国技館ワンマンライブを行う予定だったが、東日本大震災の影響により中止に。これを受け、4月から6月にかけて全国8都市を回るフリーライブツアーを敢行した。同年8月31日に4thアルバム「8月32日へ」を発表。子供の頃の暗い記憶やニートの抱える不安な感情などを美しいメロディに乗せた楽曲、予測のできない破滅的なライブパフォーマンスでファンを増やし続けている。
だそうです。
このインタビューはよく出来ているので、気になったら読めばいいと思う。
http://natalie.mu/music/pp/kamattechan
彼――「の子」という名前なのだが――かまってちゃんについて語られるとき最も話題にされるのは、
やはり「彼は本物なの？」「それとも演技なの？」ということだろう。
だが重要なのは、「頭がおかしいからあんなライブをやっているのではない」という点である。
あれ自体はあくまでパフォーマンスなのだ。
ちょっとの計算に、感情の高ぶりがプラスされて、暴れているだけだ。
かまってちゃんのファンはそこのところをよく弁えている（はずだ）。
たとえば、ライブ映像（ネットに無料でアップされている）なんかでは、
観客席にダイブしたのに受け止めてもらえず頭を打ったり、
ギターを壊そうとして壊せなかったりしているところが見られる。
ライブ終了時にぺこぺこと頭を下げたりもしている。
「かっこいいことを言おうとして思いつかなかったんだな」みたいなこともある。
はっきり言ってカッコ悪い。
でもときどき本当にカッコいい。
ファンはそんな「の子」を愛している。
このあたりの感覚は、各種配信（ネットに無料でアップされている）を観て、
もちろんファンでもない人に「分かれ」とは言わないが、
表面的に「基地外かっけー！」と言って騒いでいるのではないということで。
これが「原作」となる。
の子の意図が完全に反映されているし完成度も最も高い。
次に配信。
自宅でのなんでもない会話、移動中の暇つぶし、
とにかくなんでもネット配信、
その次にライブ。
極論を言えば、「神聖かまってちゃん」というバンドは、の子の曲をライブで演奏するためのものでしかない。
インタビュー等を読むと、なんとかライブで「原作」の再現をしようと努力していることが伺える。
逆に、の子は「バンドは俺のものじゃない」みたいなことも言っていて、
その次がCD。
漫画のアニメ化と同じく、原作ファンが憤慨することしきりである。
というか、の子本人が「あんなの買うな」って言ってるし。
そしてTV出演。
の子本人は「有名になったら嬉しい」と言っているので、テレビには知名度を上げる目的で出ているのだろう。
ただ、ライブ形式ならともかく、観客がいないところで「良い演奏をする」などとはあまり考えていないように思う。
MUSIC JAPANに出演したときは、前日にニコ生で何をやるかを募集して、
「桑田佳祐のモノマネ」とか「ワンピースの黒ひげの真似」とか言ってたようだ。
http://www.youtube.com/watch?v=kWV7UfYYLVk
プロ失格？
代表曲『ロックンロールは鳴り止まないっ』。
http://www.youtube.com/watch?v=U5M9v0nrl0c
http://www.youtube.com/watch?v=ZD0Lk-urGiM
明るい曲調と歌詞の『美ちなる方へ』。
http://www.youtube.com/watch?v=TC53gvkPwhQ
「死にたいな」と「もう嫌だ」のコーラス『天使じゃ地上じゃちっそく死』。
http://www.youtube.com/watch?v=8eFNC3hLkNw
インストゥルメンタル「夜空の虫とどこまでも」。
http://www.youtube.com/watch?v=P3PrTiZa16Q
このあたりが分かりやすくて良いんじゃね？
こんにちは、新婚です。タイトルはホッテントリメーカーから。
いや結婚はいいよマジで。仕事終わってクタクタで帰るだけで好きな人にくっつく特権が！そして相手も満更でもなさそうな顔でニヤニヤしてたりして！それより何より家に男の人がいるってだけですごく安心するよ。ありがとう夫、愛してる夫！
……そんな幸せいっぱいの三十路喪女ですが(ええ、結婚しても喪は喪です)、かつては婚活なんかもしておりました。結婚を意識して動き出して結婚まで7年ほどかかりましたよ。何しろ喪ですから。そんでも！そんでも！アタシいま愛されちゃってるしぃ～、幸せのおすそ分けに？これは効果あったんじゃないかなぁって思ったことを増田に書いてみるよ。だって自分が結婚できたからってリアル友人に上から目線でアドバイスするの恥ずかしいんだもん。
.
.
====
.
喪の婚活には当然のリスクヘッジでしょう。結婚しなくても生きていけるけど、お金が無いと生きていけない。タダでさえ喪というハンデを負った身、婚活が絶対に成功するとは限らないことは折り込まないと。別に勝間和代にならなくても、自分一人食べていけるだけ稼げればそれでいい。どんな有名企業に勤めていても永久就職希望オーラを出すだけで男は逃げ出す。“別に結婚までしていただかなくてもお付き合いしてもらえればいいですよ”くらいの軽さを出す役には立ったと思う。
私の場合、ブラック企業のいじめられ事務(あの頃本当に卑屈だった)を辞め、介護職→ホームヘルパー→家政婦として個人契約して今に至る。家政婦いいよ家政婦。学歴要らないし、性別が女で普通に家事が出来ればとりあえず食べていける。ありがとうお母さん私に家事と敬語を教えてくれて。身体を売らなくても、ババアになってもなんとか食いつないでいけそうです。
結婚願望が強い男に仕事の話をすると、すごい家事能力を期待されてしまってげんなりするけどな！（そーゆーのが顔に出ちゃうから婚活長引いたんだと思う）
.
あるマニュアル本には美のためなら何でもする！って位の覚悟でお洒落しろって書いてあったな。その割にコスメフリークにメンヘラが多いのはなんで……まあいい。性別が女である事をアピールしないことには始まらない。髪を伸ばして、スカートはいて、産毛剃ってメイクしてプチネックレスつける、ってくらいには頑張った。ありがたい事にブラック企業と肉体労働のお陰でダイエットはしなくて済んだ。未だに友達にはお洒落しろって言われるレベルだけど(だから婚活長引いたんだと思う)
.
.
あったら喪なんかやってねぇよ(ﾟДﾟ#) ｺﾞﾙｧ ……と卑屈になるのは大得意。だけど、なんとか売りになりそうな自分の特徴について自己分析してみた。
……ということで需要はある！と考えた。そう思わないとやってられなかった。
.
多分、他の婚活女子を見ていて一番違うのはここを考えたことだと思う。絶対クリアしていて欲しい条件を3つ。
私の場合は
念のため一般的にはアレだけど私は許せる条件も洗いだしてみた。
で、そんな男はどこにいるのか？を考えた。ここでブス山さんメソッド発動。
ブス山さんのモテ哲学 - タケルンバ卿日記 http://d.hatena.ne.jp/takerunba/20071109/p2
スポーツ誌じゃない、男の人が読みそうな雑誌を読むように心がけた。月刊アスキーとか、MONOマガジンとか、ファミ通とかホビージャパンとか。あとDSを買ってインドア派の最大の娯楽？ゲームも始めてみた。ホッテントリの妹の人(http://anond.hatelabo.jp/20110708170527)みたいに明確なターゲットがいたわけではないし、性に合わなかったのですぐ飽きちゃったけど。
.
ブス山さんメソッドで雑誌読んで見つけたイベントも、合コンもお見合いパーティーも行きました。あと用もないのに電気屋をブラブラしたりした。あと自分が興味があって男の人もやりそうな趣味のイベントとか。
合コンやお見合いパーティに関しては、結婚願望のある男女が集まるのはいいんだけどマーケットが絞りきれてないから効率が悪いしすごく疲れる。電気屋行ってもナンパなんかされないｗでも引き篭っているよりはまし。
自分が興味があって男の人もやりそうな趣味のイベントはよかったと思う。別に出会いがなくても趣味が楽しめるから、婚活疲れみたいなストレスがない。気さくに話せる男友達もできたし。そういうのはmixiで探した。
ただ、これといった目的のない、ただの社会人イベサーはア○ウェイとかの温床なので気をつけろ！
.
あー、これ書くと炎上するんだろうな。でも他の婚活女子があまりやってない2番目に大事なことだと思うので書いておく。
[amazon:THE RULES―理想の男性と結婚するための35の法則]
例：
こんな事やってるから婚活が長引いたんだよ(3回目)でも本当にこれはいいと思う。ネットを徘徊してルールズガール(とはいっても大体アラサー)が勧めてる関連図書と合わせておすすめ。女尊男卑とかじゃないんですよ。自分で「積極的に」行動して重たい女になって痛い目見たことがあるから言える！喪女が健気な女をやっても卑屈オーラがでるので碌なことはない！でも、外に出ていればこれをやっててもたまぁーに、ごくたまぁーに、私を複数回デートに誘ってくれる人は現れた！7年間で4人！(うち、最後の一人が夫)あと、ちょっと優しくされるとすぐ舞い上がる喪女(私)が趣味の男友達を作れたのはルールズがあったからだと思う。痛い女にならずに彼らと仲良くできたお陰で男性不信がちょっと治った。
あとはねー、私の女友達で自分からアプローチして彼氏ゲットした子に、あんまり幸せそうな子がいないんだよね。なんでだろ。an-an的メソッドに詳しい友人もまだ独身だし。
実際うまくいってみると、自分から好きになったわけじゃない男の人に好かれて優しくしてもらうのがこんなに楽しいとは思わなかった。で、じわじわと温まるように私も彼のことが好きになった。ありがとう夫、愛してる夫。
.
7年ね、時間かかりすぎだよね。最初に結婚を意識した頃には婚活なんて言葉なかった。
でもその間仕事変わったりいろいろあったし、自分自身もいい方向に変わっていったと思う。諦めないでよかった。
夫への謝辞で締めくくりたいと思います。ありがとう夫、愛してる夫。
.
予想以上のブクマが！ルールズあんまり叩かれなかった！ありがとうございます。
はてな記法がちゃんと効いてない気がする。なんでだろ。。。
.
これは本当にごめんなさい。風俗に行かない男がよかったのと、男を見る目に自信がないのでこんな指標を使いました。
.
＞喪の自称をやめるべき
.
＞7年は短い
まじで？
.
＞7年で4人。。。
本当にねー、時間かかったね。ルールズ系の婚活ブログ読んでると常時3人くらいとデートしてる人は早くて半年～1年、大体2-3年で結婚してた。まあ新しい仕事に適応するのに忙しかったのと、女装キープする根性がなかったのと、それでも周期的にやってくる猛烈な寂しさのお陰で細々と続いた、って感じです。あまり努力した感じはしない。強いて言うなら、ルールズを自分にとって自然なマインドセットとして吸収するのがちょっと難しかったくらいか。デート1回で振られたことはありませんでした。皆さん3回はデートした。
.
今までにを見る限りそうでもないと思うけど、ある程度以上の自信がある男性探し、という側面はあると思う。
.
＞俺もルールズ読んでみよう
男性にはお勧めしない。何の役にも立たないし、胸糞悪くなるかもしれないよ。
それより散髪して、風呂入って、サイズのあった洗濯した服を着て、いいなと思う女の子を気軽にデートに誘ってください。スタバでお茶飲むだけでもいいと思う。都市圏の夜のデートなら、モスorフレッシュネスバーガーで軽く腹ごしらえ→夜の公園をお散歩→カウンターでカクテル一杯くらいのおしゃべり、とかとか。オゴリでも安く上げることはできるはず！短いデートを3回もすれば大体の相性と相手の人となり、自分の気持ちは分かると思う。今の私があるのは夫の勇気のおかげなので、全力で応援してます。
文系の人ってたまにいるんだよ。つーか理系でもいっぱいいるんだよ。
定価２００円で３割引の商品よりも、定価１００円割引なしの方を選ぶ人・・・
なんかさー ダイエーでは2足200円が3割引だけどダイソーでは2足100円だったの・・・どや！みたいな人がいて・・・
いや、うん。でもそれって100円の価値しかないよね。そんなの明らかに粗悪品だからすぐ穴開くよね的な。
その商品に100円+した価値の商品が、+40円で買えるんだよ的な。その100円の価値の差決定的じゃね的な。
ま、値段云々よりブランドだよね。消しゴムはMONO消しとか味噌はマルコメの出汁入りとか醤油はキッコーマンの丸大豆とか。
それが幾ら以下なら安いから買う・・・というスタンスでないとね。
それに、別に100円の価値でいい物ならわざわざ高い物を買う必要性はないよねとは思う。
テンプレとして使えそうだから使ってみたけど。
この元増田はinfotopなんかの情報商材系の webマーケティング会社のディレクターっぽい感じがする…。
過去に何度かセールスレタータイプのくそ長いページを作ったことがあるが、
そのときの相手が言ってる事と、世間知らずっぷりがかなり近い。
ttp://www.j-legend.jp/infocustom/
とか
のテンプレートに文字流し込み&見出しや囲み罫のパーツ選びぐらいのもんだろう。
一般的なWeb制作会社やデザイン会社に勤めている人はセールスレタータイプのサイトの
作成経験とか情報商材系の会社との取引などはあまりないかと思うが、自分が調べた感じだと
企業サイト等がメインの一般的な制作会社と、こういった情報商材を売るWebマーケティング会社では
ビジネスモデルが異なるので料金体系やワークフローがまったく違ってくる。
元増田とその他の人とかみ合っていない原因は、元増田がその事を伏せて、さも一般的な制作会社の
ふりをしていっぱしのディレクターを気取っているせいだと思われる。
だって、OSSの歴史的経緯とか踏まえてる人間から見れば、ひがさんのおっしゃっていることは嘘ではないけどかなり違和感があるのも事実だし。
例えば、ブクマで
みんなで寄ってたかって改変できないものを、ソースさえ入手できればオープンソースと言ってもいいって言っちゃうような人が、もっちーを批判する資格は無かろう。他人の誤りに寛容になるか、自らを律するべし。
と書いているatsushieno氏はMonoプロジェクトの参加者だったはず。…と思って彼のダイアリを見に行ったらこんなエントリを書いてらっしゃった。
ぶっちゃけ、OSSの定義なんてかなり曖昧な部分があるわけで、「OSSとバザールモデルは別物」みたいなオレオレ定義を持ち出して他人を叱責することにどんな意味があるのか。OSSの元祖であるところの、ストールマンの「自由なソフトウェア」みたいに、絶対に譲れない一線だというわけでもないだろう。
もう、スパっと謝っちまえばいいんじゃないかと思うよ。少なくとも、そうしたことでひがさんのお仕事の価値が毀損されるわけではないし。