「mono」を含む日記 RSS

はてなキーワード: monoとは

2020-06-11

No more Tofu Monospace

"Noto Mono"というフォントを使っているのだが、

だったら、"Seto Mono"フォントがあってもいいのではないかと探した。

瀬戸フォントという手書きフォントはあったが、"Seto Mono"はなかった。

残念。

2020-05-22

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

2020-05-14

anond:20200511224232

  形を目指す自分のために何もかも捨てたさ  家族を友をそして恋人さえも ウソ欺瞞に目を潰して 手にした真実は wow マンコとの暮らしほどの 夢はなかった

 wow wow wow wow マンコがここに wow wow wow wow いたなら俺を間違いじゃないと許してくれるかな

   今夜はネット作品に酔い MONOたんと一緒にしこりたい 孤独に震えて差し出す金を 破り去る力は持てなくて

  ブ器用に生きた奇跡の果てに 大切な膣部をなくしても  あこがれに生きた奇跡の果てに 大切な何かを無くしても wow

意味のないスペースや下ネタが明らかに狂ってるのに歌詞自体はポップで草

2020-02-28

段階的にLinux

移行する計画カテゴリー化しようかな)

ググればそんなブログとかもありそうだ。しかし、今日はそういうのを見ない。

デュアルブート嫌いなので、本来ならば、デスクトップパソコンをもう一台しつらえてLinuxマシンとすべきだろうが、そんな金も暇もないので余っているWin7ノートパソコンに白羽の矢。どのみちサポート停止でオフライン専用マシンとなるところだからこいつをLinuxマシンにしつらえよう。

☆ やりたいこと

現状使っている無ファンWindowsマシンは、長時間連続運用すると熱暴走し、極端にレスが遅くなる。数時間ごとに、WinマシンLinuxマシンを交代で運用すればよかろう。これでいいのだ(バカボンのパパ)。

☆ Linuxでできないことども

できないことどもを列挙する。そうこれが大事だ。


VBmonoかいうのがあるらしく、Linuxでも使えるのでは?hidemaru editorは、vim. hidemaru macrosは、python or perl移植LINEは深刻な問題では?Chromeの補助機能経由でできるんだっけ?メーラーは?BirdLinuxでもできるのか?birdは使いたくない。webMailだな。K9Mailは?クラウドとしてMS OneDrive使っているけど、使いやすいのか?昨今スマホでもOneDriveアクセスできるけど( ^ω^)・・・なんでもかんでもGITHUBに放り込む?

2020-01-05

この百合マンガがマヂ尊い…2020 トップ50

1位『ゆりでなる??えすぽわーる』なおいまい

2位『神絵師JKOL腐女子』さと

3位『ワンナイトフレンド』かやこ

4位『相方システム袴田めら

5位『包帯少女期間』須藤佑実

6位『あーとかうー、しかいえない』近藤笑真

7位『レゾナントブルーヨルモ

8位『理想と恋』日野雄飛

9位『定時に上がれたら』犬井あゆ

10位『おとなになっても』志村貴子

11位『ふたりアルカディア』やとさきはる

12位『おりたたぶ』こんちき

13位『割り切った関係ですからFLOWER CHILD

14位『きみのため世界はある』雨水

15位『よいこ先生薄い本悪魔』こめつぶ

16位『メジロバナの咲く』中村明日美子

17位『毒百合乙女童話』ヨシジマシウ

18位『ガラスの靴を脱ぎ捨てて』桐山はる

19位『つきあってあげてもいいかな』たみふる

20位『突然なんとなく隣の同僚とセックスしたくなりました』三浦コズミ

21位『さよならローズガーデン』毒田ペパ子

22位『幸福ごっこ』岬千皓

23位『君のくれるまずい飴』冬虫カイコ

24位『茶の湯時間早川光/pikamaro

25位『うちの師匠はしっぽがない』TNSK

26位『清楚なフリをしてますが』倉地千尋

27位『世界の終わりと魔女の恋』KUJIRA

28位『ささやくように恋を唄う』竹嶋えく

29位『社畜さんと家出少女タツノコッコ

30位『あの鐘を鳴らすのは少なくともお前じゃない』アサダニッキ

31位『君が死ぬまで恋したい』あおのなち

32位『痩せたいさんと失恋ちゃん原作安田剛助 漫画:文尾文

33位『ヴァンピアーズ』アキリ

34位『ヒーローさんと元女幹部さん』そめきち

35位『一端の子』深山はな

36位『トラとハチドリ』ヨドカワ

37位『百合と声と風纏い』蓮冥

38位『不揃いの連理』みかん

39位『レンタルショップでお姉さんをレンタルする話』もちオーレ

40位『ふわふわ・ふたしか・夢みたい』袴田めら

41位『ハローメランコリック大沢やよい

42位『ドラムカン百景』吉田丸悠

43位『月とすっぴん』アケガタユウ

44位『憎らしいほど愛してる』ユニ

45位『飛野さんのバカ筋肉太郎

46位『少女巡礼』にしお栞

47位『ルミナスブルー石見樹代子

48位『疲れきった女が死ぬほど癒されるために』山口えいと

49位『彼女イデア』冬芽沙也

50位『百合片想いちゃんゆりかご

あくまで一個人評価であり、作品の優劣を決めるものではありません。

※当ランキング2019年1月1日から1231日の間に紙媒体及び電子書籍119ページ以上の単行本として発売された商業作品対象にしており、同人作品などは対象外になっています

※某有名年間百合ランキングの人がサボったのでやりました。

※「◯◯が入ってないんだけど?」と思う方もいらっしゃると思いますが、多分読んだうえでランク外です。多分それ読んでます。膨大な数を読んでます(ドヤア

※優れた、かつ百合要素がある作品でも、作品面白さの根幹が百合にないと筆者が判断した場合ランク外になっている場合があります

※例えば自分2019年に新しく単行本が出た萌え4コマで一番よいものは『ぼっちざろっく!』だと思っていて、これは百合要素もあるんですけど、じゃあ百合としてよいもなのかというと正直そこまででもない(個人の感想です)。この漫画面白さの核はぼっちちゃんキャラであり百合ではない。とか書くと「バーカ!ぼっちちゃんメンバーとの交流を通しての成長するのは百合以外の何物でもないだろ!」みたいに難癖をつけられるのがインターネットですが、いやでもそれ作品の魅力の一部分に過ぎないよね?百合があるのは認めるけれど全体の割合を考えた場合以下略戦争とかそんな感じなので百合ランキングに入れるとなると個人的に低いとこに置かざるをえません。ならばもういっそ入れない方がいいのでは?いう感じになるわけです。これは去年のmonoとかもそうてした。なので『ぼっちざろっく!』はランク外です。

※このタイプ作品は他に『白百合は朱に染まらない』『もういっぽん!』『赫のグリモア』などが挙げられます

あくまで一個人評価であり、作品の優劣を決めるものではありません。いや本当に。

おまけ「新年百合マンガ予報」

去年の個人的な大本命だった、でも結局単行本が出なかった須藤佑美先生の『夢の端々』が今年こそ出るはずです。これが多分マイ一位です。全宇宙百合豚よ、読んで己の罪を数えろ!

今月はネットでやたらバズった『マイ・ブロークン・マリコ』と2010年代の百合史に残すべき傑作『アフターアワーズ』の西尾雄太の新作百合水野茶山』が出ます。『水野茶山』は前作から一転、ダークな田舎百合です。マイブロはみんな読んでると思うので紹介は別にええな。切ないよね。

百合からは『欠けた月とドーナッツ』がたいへんよい大人百合です。これも今月発売。

そして二月には仲谷鳰先生短編集が出ます。必読。

萌え4コマ日常系的なものでは荒井チェリー先生の新作『むすんで、つないで。』が最注目です。おねロリの最終兵器だ。

他、とっくに単行本一冊分のページ数溜まってるんだけど 全然出る気配がないんだけど?来年こそ出るといいなぁ……という枠で『かけおちガール』、『ケムリが目にしみる』、『彼女の沈清』などがあります。『かけおちガール』は本当なんとかせぇや講談社

2019-12-19

2009年2019年に使ってるモノの比較

やっほー 増田だよ!

僕が2009年に使っていたものと、

2019年現在使っているものを書いていくよ。ワオ!

なおカッコ内は生産しているメーカーの国だよ。ワオ!

2009年に使っていたもの

PC携帯
家電
エンタメ
PCサービス,SNS
買い物など

2019年現在使っているもの

PC携帯
家電
エンタメ
PCサービス,SNS
買い物など

雑感

この10年で日本製むちゃ減ってるね!ワオ!

9割日本製だったものが、10年後に9割海外製ってやばない?ワァオ!

追記

Lagenaria 消しゴムの話ではなかった

わろた!

MONO消しゴムは使ってないよ!ワオ!

zeromoon0 読みにくいよ!

ごめん!慣れてないんだ!

どうすれば見やすくなるかな?

自動リンクは取りたいけどタグがめんどくさいんだ!

あとzeromoon0さん好きだよ(顔見たことないけど)!

結婚してるか彼氏いる?ワオ!

zeromoon0 読みにくいよ!/国の話にしたいからざっくり国ごとにまとめたほうがいいと思う。日本製 テレビPanasonic洋服ユニクロ)……米国製 買い物(AmazonスマホApple)とか。

ありがとう!やっぱりzeromoon0さん好きだ!

スマホで見たら特に見辛かったので直したヨ!

ところでクリスマスの予定はあるの??ワオ

2019-06-21

MONO消しゴムリュックが当たる!

やべえほしい!…と思ってからの「あの人事担当がいるトンボ鉛筆かあ…」ってなる

企業イメージって本当に大変だな

2018-05-26

MONOレーダー、中身は同じ?

Twitterで「消しゴムマニアの私からみんなに向けてのメッセージです…ぜひ参考にしてね…」というつぶやきが話題になっているけど、こういうとき必ず来るリプが、「ちょwお前のツイート伸びすぎww有名人じゃんwww」「パクられてますよ」ともうひとつ、「SeedのRadarとTombowMonoは同じものらしいです」「TombowMONOSEEDのRadarのOEM品らしいので同じ物の様ですよ」といったもの

どういうことかというと、日本消しゴム消しゴム専業メーカーからOEM供給によって成り立っており(※ぺんてる海外メーカーを除く)、有名文具メーカー消しゴムも、実際に製造してるのはスリーブクリーンマークの番号が示す7社のいずれかなのだとか。

まり、一部番号が印字されてない消しゴムもあるものの、表でまとめるとこういうこと(※無印良品などはよくわからないので除く)。

番号製造販売
01シードシード、トンボ鉛筆コクヨリサーレ)、ナカバヤシ三菱鉛筆、クツワ、サンスター文具MONO
06ヒノデワシヒノデワシプラス三菱鉛筆サンスター文具(まとまるくん)、レック(激落ちくん)
11ラビットラビットサクラクレパスパイロットコクヨリサーレプレミアム
13ぺんてるぺんてる

ということは、「レーダーよりMONOの方が消える」とか、前述のツイートにもある「MONOは折れるけどレーダーは折れない」みたいなのは全部気のせい…?

2018-01-21

最近youtube作業の合間に音楽漁るのにハマってる

ドミコTemplayペトロールズMONO NO AWAREフレデリックかいいな〜と思ってるんだけど、この系列オススメってあるかね

2017-05-26

http://anond.hatelabo.jp/20170526222228

stereo / monoなら英語で書けるけど、「モノラル」はちゃんと英語で書けない人が結構多い、みたいな

ちなみにmonoralではない

2017-05-12

コンパイラーが無料じゃないなんて!」ちょまど氏記事修正箇所

修正前: https://archive.is/gWxJY

修正後: https://thinkit.co.jp/article/11373

差分: http://difff.jp/4jrxz.html

以下、大きく変わった箇所を抜き出します。

ちょまど:もう一つ言えば、開発ツール無償じゃないのもなんか間違ってるって思っていたんですよ。なのでXamarinマイクロソフトに買収されたって聞いた時にすごく喜んだんです。これでXamarinはきっとOSSになって無償になるって思って。

ちょまど:もう一つ言えば、開発ツール有償だと開発者に浸透しにくいって思っていたんですよ。なのでXamarinマイクロソフトに買収されたって聞いた時にすごく喜んだんです。Xamarinライセンス代が高かったけど、これによりきっと無償になるし、しかも(XamarinチームはもともとMonoチームが母体OSS好きなのもあり)XamarinランタイムOSSになって人に勧めやすくなるかなって思って。

----

ちょまど:そうです。私は逆にマイクロソフトWindows会社しか知らなくて、開発者になってからVisual StudioC#会社で、とってもOSS会社だって思ったんですが、入って気づいたのは世の中にはものすごくマイクロソフトキライな人が多いって言うことで(苦笑)。なんかアンチな人が特にインターネットには多いです。

ーーあー、マイクロソフトアンチが多いのはよくわかります。昔を知っている人は特にそうなりがちかもしれませんね。

修正記事からは上記文章が削除されました。

----

ちょまど:さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、私からすればエディターがOSSなのは当たり前だし、開発ツールは当然マルチプラットフォーム対応だし、そういうのはもうホントに当たり前だったので一緒に盛り上がれなくて悲しいです(笑)

ちょまど:(さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、)私からすればVisual Studio CodeのようにエディターがOSSなのは当たり前だし、Mac版のVisual Studioが出たように開発ツールは当然マルチプラットフォーム対応だし。マイクロソフトが変わって衝撃! という話題で一緒に盛り上がれなくて悲しいです(笑)

----

ちょまど:でも無料じゃない開発ツールっていうのが不思議だったんですよ、そんなことしたら開発する人も増えないし、結果的不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら無意味だ!」って思ってました。なのでXamarinマイクロソフトに買収されてホントに嬉しかったです。だってAndroidiOSの両方作ろうと思ったら1年で25万円くらいかかるんですよ。

ちょまど:でも無料じゃない開発ツールっていうのが不思議だったんですよ、ベースが有料だと、開発する人も増えにくいし、結果的不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら広まりにくいよ!」って思ってました。XamarinAndroidiOS版の両方のアプリを作ろうと思ったら、ライセンス代が1年で25万円くらいかかってたんですよ。私みたいな社会人歴2〜3年の人が趣味でやるには高過ぎる値段でした。

----

正直言って元記事のちょまど氏の発言不正確なところが多々あった。

Microsoftの方によると

と、記事にするのに必要な補足がうっかり抜け落ちたようだ。

2017-04-07

http://anond.hatelabo.jp/20170407112743

意識低い企業研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。

働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。

C言語とかC++・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、

WindowsAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。

組み込みプログラミングではC言語はいまだに現役。お金普通に稼げると思うよ!次代のCOBOLと化しそうで怖いとこはあるけど。

Java・・・使える人が多いからあえて今から学習しなくてもいいような気がする。

文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有セオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。

セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから

Go・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。

ライブラリ選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。

GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。

Goデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。

GoGUIつくるの?あんまり普通じゃない気がする。軽量プロセスうまみがそんなない(詳しい人に否定されそうだけど)

普通にC#(mono/.net)かwebアプリにするかで良くないか

ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。

20言語Hello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。

コミュ症がフランス語英語ドイツ語覚えても、使う機会がないとまったく価値がないと思う。

アルゴリズムは使うものだ書くものではない!!

広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。

twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。

一応著名なプログラマーTwitterフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像RTしてたりと、twitterはメインの情報収集としては利用してない。

twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いか自分からリプは送ったりはしない。

ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。

深さ優先探索とか理解できない。

コード写経しても覚えられないし、仕組みは理解したけど自力コードが書けない。

コードにする能力ってどうやって鍛えるのか知りたい。

アルゴリズムは使うものだ書くものではない!高階関数とかテンプレートプログラミングとかその辺勉強するといい。

あと計算制限時間内に終わるなら総当たりが最速で品質も高いぞ。

エディタサクラエディタからVimに変えた。

どうしてVimかというとプラグインが多いしIDEっぽくできるから

Vim使う一番の理由は補完が強いのが気に入ってるから

Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。

NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。

Vim知らない。Linux使うならVimemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。

パソコンスペックもどのくらいのものを用意したらいいのかわからない。

10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートからプログラミングに向いてないのかもしれない。

VirtualBox上のubuntuMySQLコンパイルすると2時間20分ぐらいかかった記憶がある。

CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。

スペックお金をかけることで時間節約ツール選択肢が増える

EclipseなどのIDEが支障なく使えるレベルスペックってどのくらいするんだろう。

ノートCore i3メモリ4GBにランクアップしたらいけるのかな。

他人がどんなスペックPCで何のツール使ってプログラミングしているか知りたい。

3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。

もっと早いPCが欲しいけど、年度末に買うのを忘れた。

Python・・・機械学習する上で避けて通れないけど、今のPCだと無理。

例題が豊富逆引き辞典みたいなサイトや本がほしい。

あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。

過大請求されるの怖いし、トラブルが起きた時に英語コミュニケーション出来ないから。

Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。

使ってないけど最先端研究では機械学習使って当たり前感があってそろそろヤバい

僕は中学生の頃、いじめにより心の余裕なんてなかったか勉強どころではなかったけどもっと英語勉強しておけばよかったと後悔している。

やっぱり子供の頃の生活環境って大事だなと思う。

今は英検3級に向けて勉強中。

APIドキュメント頑張って読もう。俺も頑張って読んでる。

何を学習したらいいのか本当にわかんない。

迷宮にいる感じ。

なんとなく、プログラミングじゃないほうがいい気がするなあ。

とりあえずバイトしてPC買わない?プログラミングバイトでもいいと思うよ。

働き方改革最前線からは以上です。

2017-02-25

Google翻訳オープンソースプロジェクトに使うのはダメなのか?

免責: これは法律専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。

最近プログラマの間で

Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」

http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace

が、話題になってますね。

Ubuntu翻訳プロジェクトで発生したトラブルの話です。

この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSS翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます

ですが、プログラマの間で単にWeb翻訳OSSに使ってはいけないんだという認識が広まってるように見えます個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています

どういう話かというと、自分個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースライセンスで公開しています)

注意書き

念のため言っておきますが、これは元記事問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります

コミュニティ思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。

Google翻訳利用規約について

もとの記事のとおり、Excite翻訳利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。

ここでは、Google翻訳に焦点を当てた話をします。Google翻訳利用規約はどうか?というと、Google利用規約については翻訳結果の利用についての記載がありません。

https://www.google.com/intl/ja/policies/terms/

記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?

GPLコンパイラの例

機械翻訳権利問題と似た構造の話に、GPLGNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります

GPLの本文には、GPLプログラムの出力結果自体GPLのものを含む場合にのみその出力結果にGPL適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているか記載はありません。

これについては、コンパイラによるコンパイル結果に対して、コンパイラ著作者はなんら権利を持たないと考えるのが一般的です。

GNU自体もそういう見解を持っています

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自体がよく知っている話かもしれません。

Oracle vs GoogleJava API訴訟

これはAndroidAPIJavaAPIが流用されていることについて、OracleGoogle訴訟したものです。

これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコ地裁では著作権使用料支払いの対象にはならないという判決が下っています

(この裁判自体はまだ続いているようです)

フェアユース」というのは、アメリカ著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権侵害とはしないと考えるものです。

Google翻訳結果のOSSでの利用をこれに当てはめると

ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidJava APIの流用と比べても、さらにフェアな利用であるように見えます

さて、ここまではアメリカ法律での話でした。

(ちなみにGoogle利用規約には、「カリフォルニア州抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州法律適用されます。」と書かれています)

文化庁見解

今度は日本法律に基づく話です。

著作権情報センターサイトに、 コンピュータ創作物についての文化庁報告書記載されています

http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html

この報告書は、機械翻訳ユーザー機械翻訳システム使用するために行う原文の編集や出力の編集創作的寄与となりうることを認めている一方で、機械翻訳開発者翻訳物の著作者になるということについては否定的です。

なお、原文解析等のプログラム作成者及び汎用的な辞書データベース作成者は、一般的翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。

これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳技術は大幅に進歩しましたが、創造個性表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます

これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者著作物機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間二次著作物になるということになりそうです。

白に近いグレー

これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているか説明してきました。

では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。

グレーなものを作ることの良し悪し

だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。

著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。

有名なところでいうと、Monoが思いつきますAndroidDalvikJavaAPIを真似したものであるのと同じように、MonoMicrosoft.NETフレームワークを真似しています。つまりMonoについても訴訟リスクはあっただろうということです。

しかし、OracleGoogle対立したのとは対照的な道をMonoはたどります

2016年Monoプロジェクト運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoMicrosoft公認プロジェクトになったというわけです。

権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。

Ubuntu日本語化プロジェクトでの良し悪し

すこし元の記事に話をもどします。冒頭にも書いた通り、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というのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業うんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます

そういったこともまた、OSSリスクなわけです。

結局のところ、自分場合Google翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Google翻訳改善するためのデータを得られます

わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェア翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。

質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります

OSS翻訳者コミュニティ機械翻訳の利用についてそのプロジェクトで使って良いか方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合コミュニティ方針確認した上でやっていくしかないんだろうなあと思うところです。

2016-05-21

React.js界隈の人に聞きたい

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

そもそも世の中にそんなにSPAがあるのか

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

JSXを使うことに抵抗ないんですか?

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。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 もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

2016-04-30

とらば[とらば]で 物[もの] 申[もう]す マン だよ

toraba de mono mousu man dayo.

2015-11-15

C#で作ったプログラムmono100%再現できるわけではない

.Net 4.0で作ったプログラムmono動くことは動くけどGUIが崩れたりした。

monoでも動くプログラムを作るならGUIのチェックはしたほうがいいよ。

2015-10-19

消しゴムにこだわりたい

この頃、消しゴムの消え具合に拘っている、よく消える消しゴムは紙を痛めない

今はMONOエアータッチを使っているがとても良い

ログイン ユーザー登録
ようこそ ゲスト さん