はてなキーワード: javaとは
俺、仕事できるんでっていって辞めていったやつのLINEアカウントに
しかもこれ見よがしホーム画像がディスプレイ二つにノートPC+MacBookで僕仕事できるんです風(笑
業務系のJavaサーバサイドとJSしか仕事で触ったことないやつが
ふかしコクにしても大概にしろよって感じ(笑
ものはろくに知らないのに
俺はクソSierでx年も耐えたからどこでもできるっていってたけど
つか仕事ができるやつだったら社内の仕事ガンガン回されてるし色々相談もされるっつーの
それがされないって事がどーゆーことかも理解できないのかねぇ?
敬遠されてんのもわかってねぇしなぁ
結果
Java https://ideone.com/V7rEZP
Javascript https://ideone.com/pUmDJI
Python https://ideone.com/aF48Dm
Ruby https://ideone.com/oyknMD
動的型の言語が流行ったのは、Webプログラミングの隆盛のおかげだろ。
大昔にテキスト処理のawkがあって、その発展版みたいなPerlが現れて、タイミングよくWebプログラミングの波がきて需要が拡大。
でもPerlは、awkの発展版だから、数値も文字列も全部文字列っていう設計思想。
変数に型がない以前に、値に型がない。
で、そのPerlの影響を受けたRubyやPHPがはやってしまって、動的型の言語の隆盛の時代に。
一連のスクリプト言語の特徴は表記が簡略だってことだけど、これは型が動的か静的かというのは関係ない。
でも動的型派は、それが動的型の特徴だと思い込んで「動的型サイコー」みたいに言い出した。
10年くらい前にはハテナでも「Javaで書いたら50行のこの処理が、Rubyで書いたらたったの10行。Javaだせえ!」みたいなブログが流行った。
結論から言うと型を欲するのは成長できた言語のみに許された特権である。
どんな言語も最初から厳密な型チェックをアピールしてしまうと開発を阻害するばかりで流行らない。
増田の理屈だと最初から全部C++かJavaで作ればいいじゃんとなるが、
現状を見るにそうはなってない。
web黎明期のフロントエンドを支えたのは紛れもなく型チェックのゆるい言語だ。
パソコン黎明期の一般向け主力言語はBASIC(あるいはアセンブラ)だったわけだが、
時代が進むにつれて型チェックの厳しい言語を求めるようになるのは理由がある。
それはプログラムの規模だ。
言語が出た当初はライブラリも少なく、できることも少なかった。
時間が経過してライブラリやノウハウが蓄積し、マシン性能向上も相まってできることが増えてくると
プログラムの規模も増えてくる。
すると、厳密な型チェックを取り入れないと全体を統制できなくなるのだ。
参考:http://www.oreilly.com/animals.csp
プログラミングに興味を持ってJAVAを独学で学び始めたけどいまだに簡単なものすら作れない
会社に入って学べって意見が多いが、そもそも未経験の独学なんてどこも拾ってくれないから無理
プログラミング歴10年ちょい、仕事でWebシステムとかiPhoneアプリとか、色々プログラミングしてるアラサーのおっさんからだ。
増田は10代後半〜20代前半くらいかな?と思って、書く。参考にしてほしい。うっかり年上だったら何かゴメン、でも少しは参考になると思う。
こういう「どこからやったらいいんだよ…」っていう悩みは俺もちょうど中学生くらいの頃に思ってて、悩みながら薦めたんだけど、
結局の所「どの経験もムダにはならないから、とりあえず沢山やってみるといい」ってことだ。これについては後述するけど、まずは細かい疑問に答えていこうと思う。
まず、色々調べてて、結構詳しいし感心した。ただ、その詳しさは、まだスタート地点だ。
どの言語がどういうものなのか、何となく知ってるのは役に立つから、これからもアンテナを張り続けるといい。
MySQL使うべきなのかSQLite使うべきなのか、GolangにすべきかRubyにすべきかいっそJava?いやC#?
こういう悩みが出るのは勉強した証拠。しかし、この問題はレベルの高いプログラマーでも難しい。
何故かというと、作ろうと思うもの次第だし、作ってみたら意外と相性が悪いみたいな事も起きるし、
疑問に思っているらしい、言語を複数触れた方が良い理由は、こういう「どれを選んだら良いか」という問いに答えやすくなるからだ。
自分が理解していないものが、今作ろうとしているものにマッチするかしないか判断するには、言語や環境に対する深い理解が必要だ。
エディタは個人的にはVisualStudioやXcode、あるいはIntelliJ系をオススメする。
何も設定していなくても好ましくない書き方の時に警告が出るから、強制ギプスみたいに作用するからだ。
Twitterとかで騒いでる強いプログラマーの皆さんはvimやemacsを薦めるけれど、意外にもchokudaiさんとかはVSでC#を書く派なのを思い出して欲しい。
IDEを作っているのもプログラマーなので、IDEを使うメリットもかなりあるんだ。使った上でやっぱりvimが良ければvimに戻ると良い。
パソコンのスペックについては、確かにスペックが低すぎる。そのマシンで開発するなら、vim/emacsにせざるを得ない。 AtomやSublimeでもキツそうだ。
書いてる通りで、Core i7/RAM 4Gくらいあればとりあえず基本的人権って感じ。
性能は高ければ高いほど良いけど、予算の都合だってあるだろう。 10万用意できるなら、結構選択の幅は広がるんじゃないか。バイトなり親の説得なりお金ためるなり、頑張って調達するんだ。
何から勉強したら良いか分からないなら、とりあえず何かをパクれ。Twitterクローンみたいなのでも良い。フォローとテキストの書き込みだけなら作れるんじゃないか?
なんならそれを公開してもいい。
もしアイディアがないなら、それこそTwitterで誰かが「こんなのあったらいいなぁ」って言ってるもののうち、何となく頑張れば作れそうなものに手をつけてみると良い。
意識低い企業内研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。
働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。
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使う。でも周りはエクセルつかってる、勿体ない。
使ってないけど最先端の研究では機械学習使って当たり前感があってそろそろヤバい。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
なんとなく、プログラミングじゃないほうがいい気がするなあ。
そういうのがない言語に心当たりがないのですが、、、。
目に付いたのをやって、廃ってしまったら、別なのをやる。
ただ、廃ってしまっても大抵その経験は別なのの習得に役立つので、適当に決めると良いです。
ま、まずは一つの言語で、paizaでSランク取るのも良いと思います。
ただ、本当に深く習得するのは、一部の人にしかできないので、壁にぶつかったら他言語に手を出すのも良いです。
仕事は言語指定のものも多いので、Goしかできないときついかもしれません。
JavaかC#かC++はやっといた方が無難です。(C++が一番オススメできない)
制限時間集中してやったことはないのでなんともですが、だいたい何かしながら制限時間*2くらいでといてます。
各パーツを組み合わせて、希望の形を作る。
まずは、もともとあるものに、オプションパーツ的なものを作って、作る能力を上げると良いです。
PCは待たせるものであって、人がPCを待つのはナンセンスです。
VirtualBox等を動かしたいのであれば、メモリーは多めにしましょう。
ホスト側は64bitOSで、メモリー最低8GBは欲しいです。
グラフィックボードは、3Dレンダリングや機械学習をしたいなら欲しいです。
C言語とかC++は・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、
WindowsのAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。
Javaは・・・使える人が多いからあえて今から学習しなくてもいいような気がする。
文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有のセオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。
Goは・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。
ライブラリの選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。
GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。
Goでデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
20の言語でHello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。
コミュ症がフランス語や英語やドイツ語覚えても、使う機会がないとまったく価値がないと思う。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いから自分からリプは送ったりはしない。
ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。
コードを写経しても覚えられないし、仕組みは理解したけど自力でコードが書けない。
どうしてVimかというとプラグインが多いしIDEっぽくできるから。
Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。
NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
VirtualBox上のubuntuでMySQLをコンパイルすると2時間20分ぐらいかかった記憶がある。
CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。
スペックにお金をかけることで時間の節約ツールの選択肢が増える
EclipseなどのIDEが支障なく使えるレベルのスペックってどのくらいするんだろう。
ノートでCore i3、メモリ4GBにランクアップしたらいけるのかな。
他人がどんなスペックのPCで何のツール使ってプログラミングしているか知りたい。
Pythonは・・・・機械学習する上で避けて通れないけど、今のPCだと無理。
あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。
過大請求されるの怖いし、トラブルが起きた時に英語でコミュニケーション出来ないから。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
今の37〜40歳ぐらいのベンチャーやらスタートアップやらWeb系やらの技術者の書くコードがやばい気がする。
それが外注とかフリーとかじゃなく、役職付いている人とか役員だったりする。
コピペしたり入り組んだ関数(メソッド)を書いたりとか・・・。
抽象的な考え方とか、参照透過性とか、100%適応できないまでにしても少し考えてかけないものなのだろうか・・・。
そういう基礎的な部分の技術をまとめた技術書籍がない(もしくは流行っていない)のも原因なのかな。
Javaのオブジェクト指向からRuby on Rails時代に移行していった時代に生きていた人たちなのかな?
色々と今まで学んできたことの基盤が崩れ一気にレガシー化した感覚が強く、新しいものに手を出したがるくせがあるんじゃないかと疑ってしまう。
新しい技術を学んでも、思考を変えずに使っていたら何も変わらねぇっすよ。ゴミを今の技術で再構築するだけ。
GRASPとかSOLID原則とか、できればDDDとか関数型の考えとかを勉強して欲しい・・・。
まあ別に上記知らなくても、構造化プログラミングとか、クラスとはなんぞやとか、関心事をなるべく分離していくようなコーディングとか・・・。そういうのが欲しいです。
リーダブルコードも局所的な事を書いている気がするし、もっと大局的な技術リテラシーを・・・。
てかコレが技術的負債かー。ちょっと直すだけでもすげーめんどくさいし、やる気全然起きないし、なんならリファクタしてから修正していきたい気持ちになる。。。
DB設計もなーーー、なんでNOT NULL制約付けないかなー。もちろんテストなんて書くわけもなく。
創業期なら頑張るって感じだけど、中規模になってきたベンチャーとかだと気合い入れて全て変えてやるぜぐらいのポジションで入らないと環境変わらないだろうし、いわいるプログラマーで入るなら面接時に匂いを察知して回避したほうが良い気がするお。まぁでも入社時のやる気なら変えれるのかな・・・。もはや業務量増えてマンネリ化した状態の今は全くやる気しねぇ。すべての開発を止めて、テストコードを書きながらリファクタしていく、ってならやる。
そしたら今後何か頼まれても工数減るので「いっすよやりますよー」といいやすいし「もっと短く出来ないの?」みたいな地味なストレスがなくなるのでまぁ色々ハッピーなんじゃないのかな。(てめえのゴミ直すのに工数かかるんだよといいたくなる)
的な、ゴミと一緒に働けねぇ、みたいな問題を解決するためにマイクロサービスで開発するのありかもね。ゴミレガシーはラップして、臭いものに蓋をしてまあ許せるインターフェースだけ公開して使わせて欲しい。(驚くほど上から目線)コードレビューですり合わせられるようなレベル感ではなく、でかいゴミ山があり、そいつがゴミ山を整理する気がないならそうするのが折衷案なんじゃないでしょうか。
「サービスを作ってきたコードだから感謝して」って実際その現場になるとあまり思えないものなんだな。サービスをスケールさせられないこの足元作ったやつまじ、考え直してもらわんと対して売上立たず終わるから期待持たせるだけだぞ、みたいな。これがクソ稼いでいるサービスとかだったら別なんだろうなぁ・・・。
http://s.news.mynavi.jp/news/2017/03/30/133/
この記事で、おやおやCOBOLが入ってないぞ?と私も思ったし、他の人も思ってたようだ。
なんでだろう。
個人的には、この21世紀にコボラーとかヤバい、という認識で今まで生きてきたのは事実だが、はて、COBOLで嫌な思いをしたことがあるかというと、幸いにもそんな経験はない。
むしろ、
・関わった人たちが、ちゃんとした金融機関(某大手地銀)とかちゃんとした元請け(N社)だったので、ムチャな開発にもならなかったし、お金もちゃんともらえた
・それまではJAVA専門だったが、COBOLの仕組みとかは勉強になった
・一緒に仕事したおじさんがすごい優秀で経験豊富な技術者で、いろいろ教えてもらえた
と、悪い思い出がない。
やっぱ、悪い言語があるわけじゃなく、向いてないのに無理に採用するのが良くないんだよね。
日本のお役所がPDF大好きなのは、知っている。霞ヶ関から吐き出される有効な資料は、ほぼpdf!
一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。
今、株価が上昇しているIT企業様は、PDFとhtmlとを比べるような使い方はしていないのでは?
世界は、IT企業、htmlとPDFとを比べたらどちらを重用しているのか?
googleがjava script 推しのJQueryを良く使ってるし、これからは、人工知能の時代だから、xml形式とか、マークアップ言語は、良く出てくると思うよ。
Facebookはphpなんでしょう?リア充御用達で、Twitterよりも株価も資本も安定している。
これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
私(♀)は今、北日本のどこかにある某システム会社でシステムエンジニアをしています。
小さいときからパソコンや電子工作が好きで、高校卒業後は情報系の専門学校に入学しました。
飛びぬけて優秀というわけではありませんが、進学の推薦に困らない程度の成績は維持していました。
「私子ちゃんの成績なら進学なんでしょう?」「私子は進学のほうが向いてるよ」と周りからは言われました。
私も進学したいという気持ちがありました。
親に相談したところ、母は「ダメとは言わない。進学するなら奨学金を借りてほしい」と言いました。
父は「四大を卒業した女はすぐに結婚して辞めると思われる。四大なんて女が行くところじゃない」と言いました。
父が言うならそうなのだろうと思いました。
今のシステム会社に入社し、同期の1人と一緒に運用系の部署に配属されました。
学生時代はCやJavaの基本について学んではいましたが、その部署ではプログラミングをすることはほとんどありませんでした。
代わりにLinux,TCP/IP,ネットワーク構築の技術が求められました。
LinuxやTCP/IP,ネットワーク構築は初めて見る知識で先輩が教えてくれる業務をこなすのに必死でした。
一緒に配属された同期は性格の明るさと器用さでどんどん仕事を覚えていき、私と差がついていくのがわかりました。
同期と差がつけられるのが悔しかった私は、勉強をはじめました。
そのころ、我が家は祖母の介護をめぐりよく父と母がけんかしていました。
母が「殺せ!殺せ!私を殺せ!」とはさみを持ってよく叫んでいました。
私と弟が母親をよく羽交い絞めにして止めました。
祖母は、父に対しかなりの毒親っぷりを発揮&クソトメであったため、介護も大変だったようです。
喧嘩を見なければいいと思った私はよく図書館で勉強していました。
その秋のAPは落ちました。
配属されて1年ほどたったころ、私はある女性(40代、既婚)の下で働くことになりました。
以下おばさんと呼ぶことにします。
「なぜわからないの?」「かんがえたの?」「もう1回調べて」とよく言われたので、言うとおりにしました。
厳しいなぁと思いましたが、私の成長を思ってしてくれているのだと思いました。
自分なりにがんばってみるものの、つき返される日々がつづきました。
そのうちに、夜眠れなくなりました。
毎日倦怠感がありました。
「仕事 がんばる 方法」「仕事 落ち込み 立ち直る」でぐぐることが多くなりました。
いろんなにきび治療方法を試したので、にきび治療に詳しくなりました。
元気出す系のドーピングアイテムにも詳しくなりました。(レッドブルからプラセンタまで)
ある日、おばさんが言いました。
「あなたを見てるとイライラするのよ。あなたの成長なんて知ったこっちゃないのよ。さっさとやってよ。」
土日出勤・給料未払いというブラック企業勤めの弟が居たので、相対的ホワイト企業勤めの私がうつ病、ちゃんちゃらおかしかったのでしょう。
夕食のときに、父が「会社を休むのなら学校にでも行け」といいました。
私はおもわず泣きました。
「飯がまずくなる」と父にしかられたため、自分の部屋で食べました。
休んでいる間の家族の目がつらかったので、1ヶ月で仕事に復帰しました。
「つらかったら半日で帰ってもいいんだよ」と上司(男性、おばさんとは別人)に言われましたが、家に帰ってもろくなことがないので、定時まではたらきました。
そんな中、弟が交通事故で重傷を負いました。
弟は障害者手帳を持つようになりました。
用事があり作りませんでした。
弟は帰るなり私を殴り、「なぜ俺の飯がないんだ」と叫びました。
さすがに理不尽だと思い親に訴えました。
母は「あの子はやかんみたいな子だからね。すぐに沸騰するのよ」といいました。
その後親から弟にお叱りがあったようです。
弟は私に会うたびににらむようになりました。
親に言いつけたことへの報復が怖くて、夜は自分の部屋の扉に、机やいすでバリケードを作って寝ました。
APは5回ぐらい落ちました。
親の怒号や弟の報復におびえることなく勉強できる場所がほしいと思いました。
実家暮らしで、うつ病で趣味もなくなっていたので、お金はありました。
親は、一人暮らしをすることについては何も言いませんでした。
隣の部屋のおじさんの声、車の音がうるさかったですが、親の怒号や弟におびえた日々に比べたら天国でした。
好きな時間にご飯が食べられる。
好きな時間に帰ってこられる。
以上です。
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
免責: これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「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の翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
zpicturegroup.com
1-gp.com
1energyportal.net
20-shishakai.com
2123moments.com
26546000.tv
33fclothing.com
3enhancedesigners.com
3x-broussaille.com
43biciclettedilusso.com
48condorcet.com
4wallsandaview.com
5a10parjour.com
7factory-design.com
7inchpunk.com
81books.jp
87mizuki.com
a-homeplan.com
aaronlouisfowler.com
abbysunderland.com
abili.net
abrampineda.com
accessonthepalouse.org
ace-collective.com
actionspf311.org
actiontunisienne.com
adaasia2015.org
addys-rdu.org
adehgua.org
ads-hair.com
advantagecareer.jp
afase.org
afclafontaine.org
affirmativeholdings.com
aftarkeia.org
againmystery.com
agcolares.org
ageing-in-europe.org
ageiowa.org
agenziaimpronta.net
agribusiness-nl-srb.com
agrupacioncinematograficagalega.com
aifuresort.com
aikotoba-sasebo.com
aikuiskasvatuksenkilta.com
aionstuff.com
airpur.org
ajedrezvillamontes.com
akashi149.com
akelarre-hendaia.com
akiba-clinic.com
alannamariemusic.com
aldoukan.com
aldstore.org
aliensview.com
alilapelicula.com
allydurr.com
alpinale.net
alternativekei.com
amepeba.org
anandjon.com
andrehouseaz.org
andrewsafbhotel.com
androkles.com
animalalliancepa.org
anje1001.com
ankarakomedifestivali.com
anunciarmiempresa.com
anzonenergy.com
aocmaps.com
apaa2013.com
apachevasion.com
apf691.com
apfgifted.org
apsa6001.org
aqlpadepuis30ans.com
arahiroko.com
araidsfoundation.org
aramaraphoto.com
arkivradet.org
arktodd.com
armadahotel-petalingjaya.com
armchairsailorseattle.com
aroma-erotica.com
aroma-relaxy.net
art-translation.org
artandprintdesigns.com
artgonia.com
aseandrr.net
ashera-aoyama.com
asianfilmawards.org
askmontana.org
aslumsymphony.com
association-tamany.com
astral-japan.com
atelier-fantastique.com
atelier-fukuoka.com
atelier-heroina.com
atletismoenlarioja.com
atoopix.com
atreegrowsmusicgroup.com
auberge-trinquet.com
audrey2123.com
avesopajaros.com
awelinternational.com
azpcgallery.com
azyoga.net
babelfusion.com
baboinvasion.com
bancodealimentosdearagon.org
bandamusicaalozaina.com
baqueroarquitectos.com
barbermouse.com
barnas-landskap.org
barrhavenfoodcupboard.com
barryintnl.com
barselene.com
batantek.com
batwa.org
agribusiness-nl-srb.com
aldstore.org
onedirectioncdf.com
menuiseriemontout.com
providencepizzaco.com
renover-economiser.com
sakaue-taizou.com
nyotahome.com
portauthoritypolice.org
omappedia.com
projectkarinu.org
mieito.com
soan-officiel.com
shot-travel.com
radionovasertaneja.com
onlybyskate2.com
tw-technowave.com
tankichi.net
relaxhana.com
sencolle-anime.com
musik-und-kunst.net
sylvie-schambill.com
uniathegame.com
mb-autotechnik.com
hippiesreadtoo.com
okikan.jp
biosinav.com
shiftexperience.com
actisku.com
apefalmeria.com
baldwincountynow.com
bonustcm.com
caradaviswrites.com
dkrepublic.com
ecoshift-kouji.org
mammothcaverecording.com
sombriohappenings.com
spiralla.info
madprideto.com
bhrplc.com
casasanclaver.com
evocativepop.com
leituraglobal.com
avaf.info
clonmelswimmingclub.com
doughertyspub.com
fleursdemarie.ch
gdesignbg.com
ritterjon.com
siberut-island.org
so-tm.com
stokescleveland.org
winery51.com
affiliatedacos.org
bradyvanv.com
cataplexic.com
davidrleitch.org
donamisport.org
dresscirclesounds.com
et-kingdom.com
firstagcr.org
freshlysqueezeddesigns.net
garimpochic.com
gitearnoult.com
glisc.info
haiart.org
kathyslamen.com
kobekina.com
lync-social.com
mdmorrissey.info
notundoom.com
nwjsa.org
pacornish.org
pgindia.net
philfiles.com
reservasaragon.com
sirsedricmusic.com
weareaftermidnight.com
yoshidaakira.net
blog-moving.com
ac88kor.com
alps-sizendo.com
artbyrox.com
classroomsacrosscultures.org
oclockpub.com
vinopararobar.com