  |
はてなキーワード: コンパイルとは
Dockerがバズるくらいだから今どきハードウェア仮想化なんて流行らないのだろうが、Windows10 Proの安いPCを1つ購入してHyper-Vを有効化したのでCentOSとUbuntuのどちらを入れようかと考えてた時に、昔インストールに苦労したDebian 3.1 Sargeのことを思い出して本家のサイトに行ったら今年の6月にDebian 9が正式リリースされたと聞いてすごく懐かしくなり、こいつを選択することにした。
随分バージョンが上がったものだなあ。しかも今はamd64がインストーラーのリストの最初に上がってるし。昔は64は人柱用だったのに。
10年ほど前、玄人志向の玄箱というNASのOSをDebianに入れ替えて単なるファイルサーバから多用途サーバにするのが流行ったことがあった。今でも後継品のBuffalo製NASをDebian化する好事家は細々ながら活動しているが、UbuntuのベースであるDebianに最初に触れたのがその頃で、当時のバージョンは3.1、通称Sargeだった。タイミングのいいことに、Sarge対応の分厚いDebian入門書が存在していたのでレファレンスには事欠かなかった。まあそれでも、スペックの貧弱な玄箱にインストールして少しでもパフォーマンスをよくするにはカーネルを書き換えて再コンパイルしたりといった悪戦苦闘があったわけだがもう忘れた。
Hyper-Vの仮想マシンへのDebianのインストールはトラブルらしきトラブルもなく、インストールしてすぐに使えるようになっていてまあこれが普通だよなと。OSは使いこなしてなんぼで、インストールで苦労するのは不毛だと当時も思ったし。
あと、エンジニアが多いと聞いているはてな界隈でも個別のディストリのトピックはあまり話題にならないんだなというのがちょっと面白かった。
使ったことあるモノもないモノもごちゃまぜにして経験と雰囲気で書いてる。
▼PHP
Laravelは結構好き。DSL過ぎず、それなりにフルスタックで生産性もいい。
何よりLaravel本体のソースコードが読みやすいのがいい。
まともな日本語の情報が少ないのは弱点だけど、気になったところは本体のコードを読めばすぐに分かる。
最大の欠点はPHPってことだ。他のLL言語に比べてPHP自体の生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。
▼Perl
Mojoliciousは結構好き。これもDSL過ぎず分かりやすい。CPANに豊富なライブラリ群もある。
Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリは普通に読みやすいよ。
最大の欠点はPerlってことだ。長期的に開発者を集めることを考えたら茨の道だろ？
今でこそ機械学習でPythonが人気になっているけど、Web系はまだまだマイナーだ。
Djangoのプロジェクト/アプリケーションという構成単位の考え方が好きじゃない。理論的な利点は分かるけど、現実問題それが必要になるケースが浮かばん。
Django以外でフルスタックのWAFが出てくればいいんだけど。Tornadoはフルスタックじゃないのでちょっと違う。
Python3で安心して開発できるならアリだと思うけど今はどうなの？使いたいライブラリが3系に対応していないとかで躓きたくないよ。
あと単純に速度が遅いよね。いや書き方を気をつければマシにはなるんだけど、書き方を気をつけなければいけない時点でつらい。
▼Ruby
Railsは便利だ。周辺ライブラリの充実度もすごい。情報は玉石混交だけどまともな情報もたくさんある。
ただあまりにもDSL過ぎる。Railsはプログラミングではなく、一つの巨大なDSLだ。
Railsプログラマの何割が、少しでもいいからRails本体のソースコードを読んだことがあるのか。めっちゃ読みにくいんだけど。Rubyは可読性が高いなんて嘘だろう。Perlと一緒でちゃんとしたコードは読みやすいけどそれはプログラマに依存する話で、言語自体に可読性の高さはない。言語思想の通り書くのは楽しいよ。でも読むのがつらい。
Rails自体がDSLみたいなもんなのに、RSpecやらRakeやら周辺ツールもDSL。意識高すぎる。
問題があった時にググらずにコード読んで解決できるRailsエンジニアはどれだけいるのか。情報量が多いからググれば解決すると答えるやつは、底辺PHPerと大差ないからな。
あとバージョンアップに追従するのが面倒過ぎる。でも放置したら負債になるし。意識高くRailsで開発したやつの大半はバージョンアップやらの保守に入る頃にはもうそのプロジェクトにはいないんだろ？だからそのつらさを知らないんだろ？
散々罵ったけど、このDSLを覚えれば生産性が高いのは事実だ。だから結局ついていく確率が高い。モテ男なんだよ結局こいつは。
▼Java
Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。
そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語の運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる？
コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリのコードリーディングが出来るならいいんじゃないか。
Scalaを好むプログラマは関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。
非同期処理で開発することの難しさに耐えられるの？
ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコードを保守する自信があるならいいんじゃない。俺はない。
▼Go
API単体ならともかく、画面も担う普通のWebアプリを書くような言語じゃない。少なくとも今は。
正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットがほとんどない。
運用実績のノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない。
■結論
弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。
中学生の頃からパソコン大先生でスクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。
ちなみに、試験は紙ベースで、手書きでプログラミングをさせられる。つらい。
スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。
結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。
プログラミング初学者である人は苦労して書き方を覚えていたように思う。
脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである。
今学期、PHPを書く授業とPythonを書く授業を履修してみた。
PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストのコードを動かす気力のない自分にとっては最高の授業だ。
Pythonは、MeCabなどで形態素解析や構文解析をする授業で、サンプルコードを自分で考えてカスタマイズして毎回レポートで提出する。
Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。
書いたらすぐに目に見える成果が出るところが大きい。
自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。
そう思っていた矢先に事件が起こった。
最近、研究室に入ったところ先生が手当たり次第Javaを教え始めたのである。
せめてJavaScriptでいいからスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。
それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向を理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。
ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。
絶対にツマラナイだろう。
自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。
こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。
お願いだから、プログラミングを教えるのならツマラナイ授業をしないで欲しい。
生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。
別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。
自分は、分かりやすくて直感的なRubyというプログラミング言語が学校の授業で採用されるべき言語に間違いないと思う。
別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。
CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。
スクリプト言語を教えた後に、コンパイル言語、オブジェクト指向の概念を教えていくのがいいのではないだろうか。
みんなの意見を知りたい。
長く書きます。お金の話の経験とかも、少しでも参考にしてください。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない
お金のない環境を整えられない学生はつらいよね。明らかに札束で殴れず時間を使って損してる。
twitterできないメインで使えないのもまず、重すぎるからっていうのもありそう。
スペックが足りてなさすぎる。まずは６，７万出してスペックを整えよう。
すごい人たちは幼少の頃からパソコンがあって、パソコンをいじるだけの時間があって、承認されてる。
しかも、コミュ症だとかなんだかんだ言いながらも、ネットではきちんと弾けてるし、人望もある。
彼らを理解するのはすっごく難しい。
経済格差が多すぎて、彼らが積んできた経験と持っている環境が違いすぎるから。
プログラム自体は数学を解くようですごく楽しいのだけれど、なぜ苦しい勉強をしながらプログラムをずっとやっていられるのかわからない。
環境はMac（高すぎて揃えるなんてとんでもない）じゃないから、先人たちの簡単に手順化された知恵を受けづらく、プログラムの環境をととえるまでが大変だし、
ライブラリ関係のエラーコードは自分の力で、ライブラリを見つけに行かないとダメで、ウェブで検索しても彼らよりもずっと時間がかかる。
そこをきちんと理解したうえで、自分がどこまでやりたいのか、どうしてやりたいのか
自分はプログラマに向いているのか、考えながら、勉強していったほうが良い。
ちなみに私はプログラムを解くの好きだったし、ある程度は得意だった。
ADHDと自閉症混じってるから、だから職人的なことをやりたかったし、テストをかけば不注意で大きな損失を出す可能性も低くなる。
だからプログラマを目指しているし、プログラマとして就職するつもりなんだよね。
私も無名で、プログラム力的にはpaizaのSランクは、後ちょっと足りない、運が良ければ成功するんじゃない？ってレベル。
ツイッタランドのすごい人たちは目指すと疲れるだけなのでほどほどにね。
彼らは多分余裕綽々でS取れる。
paizaの出題は競技プログラムの一種で、競技プログラムっていうのはある程度出題の仕方が似通ってる。
複数回解いていると昔に残ったコードとか再利用できたりするから有利になるっていうのもある。
ゲームで例えるとRPG好きな奴にFPSやらせても全く活躍できないけど、FPSが得意な奴に別のFPSゲーやらせてもできたりするでしょ。
開発のジャンルの違いがあることは覚えといて。
Mac買えなくて開発環境として選ぶなら,windowsよりlinuxのほうが良い。
windowsだと環境整える前にストレスがやばいし、パソコンが死んだ場合のストレスもやばい。
あと、古いパソコンだとUSBブートができなかったのも割とめんどくさかったし、回線がめちゃくちゃ低速だったから、ISOファイルのダウンロードに半日かかってたかな。
VirtualBoxはすごいスペック持っている人が使うものなので、買い換えないならクリーンインストールかデュアルブート推奨。
ubuntuにしとけば、ウイルス系もあんまり構う必要性がなくなるからね。
起動にVirtualBox起動に数分待って、端末以外を使おうとすると固まるみたいなことやってると辛さが溜まるから。
デビットカードでも行ける。
するが銀行に口座を作ってデビットカードを申しこめば、２０歳以下でもなんとかなる。（年齢によっては親の同意は必要だけど）
２，３週間かかるけど、デビットカード作っておくことで色々なサービスを体験できるようになるのは選択肢を増やすにあたって重要なことだから是非。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
ネット上は怖い人もたくさんいるし、まさかりがちょくちょく飛んでくるけど、変にウケると拡散してくれて色々な人が声をかけてくれるのも確かだったりする。
ゆっくりと自分の使い方を覚えていけば少しずつ楽しめると思う。
実際、SNSは情報の精度としては当てにならないし、勉強のためってSNSを使うとストレスで辛くなった。
自分の好きな人だけをフォローすると精神安定するよ、あとフォロー返しはやる必要はない。やってるとTL荒れるからね。
（リストとか使いこなせるなら別なんだろうけどね）
おすすめ度は◎○△であらわす。
おすすめ度：◎ 条件：最低で６，７万円のお金が必要。 おすすめはlenovoのeシリーズ。 重いけど、コスパは良好比較的安めに上がってキーボードも打ちやすいのが良い。 いまはcorei5, メモリ8GBの使ってて、大体（重めのゲーム以外）したいことはなんとかなる。 SSDはあったら便利だけど、一番重要なのはメモリな。 開発したいなら８GBは必須。 （苦労話： 古すぎてノートなのにキーボードを常時接続必要だったり、画像が多いサイトはブラウザを選ぶ必要があったり、何よりもIDEが使えなくて辛かった。 windows vistaのupdateで数日固まったり、ゴミでしかなかった。 ）
おすすめ度：◎ 条件：契約できる年齢か、親の同意（年４万円くらいの出費）が必要 何をするにもまず回線速度が遅いと話にならない。 IDE落としたり、クラウドにファイル上げたり、AWS使う時のアップロードとか、音声会話とか。 〇〇をしてみたいと思ったら,ダウンロードに時間がかからないことは、モチベーションのためにめちゃくちゃ大切。 （苦労話： ISOファイルをダウンロードするのに半日かかるのが普通だと思ってたけど、 まともな光回線＋まともなルータを利用したら、ダウンロードに１時間ちょいになってびっくりした。 特に古いルータだったりするとボルトネックになったりする。 ）
おすすめ度：○ 条件：linuxで生きていくという覚悟 windowsよりは快適。 他のlinuxISOファイルを焼いたりするときにちょっと苦労するかもしれないし、軽いの選ぶと良いかも。 実際普段使うものがネットとプログラムツールだけだったから、なんとかなったし、ゲームの選択肢が強制的に排除されるので、 少しはプログラムに触りやすくなるかもしれない。 （苦労話： エクセル、パワポ必要とか言われた時に、officeのレイアウトで死んだりする。 資料はPDFな。 買い換えない場合のクリーンインストールは↓ 昔のパソコンでもLinuxとか入れればそれなりに動くよっていう人はいるけど、やっぱり社会的な通信網と平均的なマシンスペックが上がっているせいで、ウェブ自体が要求するスペックも上がってて低スペックだとつらい。 ブラウザはw3mとか使って、端末タブを開いてvimで開発してた。 なんでかって言うと普通にブラウザ使うとレスポンスが重すぎたから。 でもその使いづらさの分だけ損してるんだよね。 ）
おすすめ度：○ 条件：電車代などの交通費を用意可能 できること： 他人に触発されるタイプなら、すごい人たちの興味の方向を見て学ぶ方向が増えるかもしれない。 後は交通費と宿泊費の出る勉強会なんてものもあるので応募してみると良いかもしれない。 高校生なら、交通費出してくれるっていう太っ腹な勉強会もちらほらある。 一、二回は顔出し推奨。 欠点はあって、コミュ症は治らないので、友達ができるとは限らない。
おすすめ度：△ 条件：家庭環境による できること： 自分の向上心による。 大学生になって一人暮らしになったら、パソコンに触れる時間は多くなったとは思う。 （勉強しているとは言っていない）
おすすめ度：○ 条件：３，４万円の出費 できること： まず、パソコンを長時間触っていても疲れなくなる。 デスクの高さと椅子の高さはとても大切なもの。 疲れなくなるし、指が攣りそうになることもない。 机の高さはきちんと調べたほうが良い、あってることが重要 今使っているのは１万ちょいの新品デスク（ニッセンのフリーテーブル）と３万弱の中古のオフィスチェア 基本的に３０００円位のデスクは耐久性と高さがゴミだったりするので注意。 机は http://blog.livedoor.jp/itsoku/archives/38727329.html の６６のテンプレを見ておくと良いかな。 （苦労話： しかもノートパソコンでデスクと椅子がなくて狭いこたつの上か100均で買ってきた台の上で、パソコンを使っていたからパソコンの位置の高さが合わなくて姿勢がどうしても悪くなるせいで長時間パソコンをいじることもできなかった。 後は寝ながらパソコンをいじるみたいなみたいな堕落生活してたら、筋肉が硬直してまともに手を握れなくなって、医者にかかることになって１万円程度お金がかかったし、 ２ヶ月位まともにパソコン触れなくなった。 ちょうどその時期は、筆記用具をほとんど使わない単位だけだったから良かったものの、他の単位とってたらもっと治療に時間がかかったかもね。 ）
おすすめ度：○ 条件：それなりのスペックのパソコン、それなり大きさのディスプレイ できること： 設定しなくても、複数のファイルから補完が聞くし、フォルダ内の全てのファイルから検索、置換ができるのが良い。 ただし、ディスプレイが小さいと実際に開発できる範囲が小さくなるのは注意。 （苦労話： IDEは普通に使えるなら作業効率が全く違って、設定少なくても補完も他のファイルやライブラリから保管してくれるたりする。 でも、昔の環境だとeclipseはフリーソフトだけど環境整えるまでが辛いし、重いしで、開くとブラウザすらまともに操作できなくのが辛い。 だから、ブラウザでチュートリアルとか見ててもパソコンに待たされてストレスだった。 まともに使うには設定がめちゃくちゃ必要なのは実際疲れた。 （ac.jpのメールアドレスは必要だけど）学生無料なIDEでjetbrains製品があるけど、設定しなきゃダメなvimとかと違ってマウスで操作できるのがすごい良い。 端末ではコピペが簡単にできなくて、数は少ないけどよくあるミスが、間違えてcommandモードで貼り付けてやり直したり、vimのline numberの設定をいじらずにvimからコピペができる。 コレだけでイライラ具合が全然変わる。 ）
おすすめ度：◎ 条件：図書館や図書室で本を注文できるか、本があるか できること： プログラムの能力が向上する。 おすすめされている本を探すと良い。 プログラム初学者なら、ネットだけで勉強するよりは効率がある。 とりあえず、やりたいことなくて、プログラム力をただ上げておきたい場合は、 競技プログラムやりたいとしても下の順番で進めると良いかもしれない。 あと、プログラムには自分が到達しているところまでで言うと、次の順で壁があって能力が足りないと行き詰まることがある。 >> 関数化 → クラス化 （→ ポインター） → 再帰 → 関数型言語 << 数年かけて勉強して次の段階に勧めないならプログラマは諦めたほうが良いかもしれない。 （能力が足りないのは上司も自分もつらくなるよ）
おすすめ度：○ 条件：１万円弱のお金 できること： ノートパソコンなら２個の画面を使えると作業効率が違う。 特に手打ち系のコーディング練習とかがめちゃくちゃ捗るようになる。 （苦労話： IDE系列は画面を割と占拠するので、ノートパソコンの狭い画面だと辛い。 でも大きすぎる画面だと持ち運べなくなるのでダメ。 画素数が上がればその分だけ小さく表現ができるので、画面サイズが同じでも画素数が違うとかなり大きさが違って見えたりする。 ）
おすすめ度：○ 条件：学力があること努力すること、覚悟 できること： 奨学金を利用して環境を整えたり、時間が増えるから更に勉強できる。 プログラム関係もそれ以外も就職先が増える。 また、これからの転職したくなった時に逃げ道が増える。 欠点、国立は安いけど、入学にそれ相応の努力が必要。私立行けるなら、苦労してないと思う。 あと免除制度っていうのがあるから、そういうのも利用しつつ費用を安く上げよう
おすすめ度：○ 条件：年齢（か、親の同意） できること： ちょっとした電子払いができるようになる。 多重債務は起こらない。 欠点としては、定期払いはできないので携帯の契約とかはできないことに注意。
低スペックのパソコンしか無いのは、多分家庭環境のせいでもあって、
君がアルバイトもできるかどうかわからないし、アルバイトしてもそのお金が君のもとに入ってくるかはわからない。
お金も無限にあるわけじゃないし、時には経済格差を感じて辛くなることもあるだろう。
少ないお金の中でうまくやりくりして、それでも自分の力にしていってほしい。
（お金が潤沢にあるなら親を説き伏せることをがんばって）
応援してるよ。
意識低い企業内研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。
働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。
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使う。でも周りはエクセルつかってる、勿体ない。
使ってないけど最先端の研究では機械学習使って当たり前感があってそろそろヤバい。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
なんとなく、プログラミングじゃないほうがいい気がするなあ。
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上で機械学習するのだけは遠慮したい。
過大請求されるの怖いし、トラブルが起きた時に英語でコミュニケーション出来ないから。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
毎度毎度、バージョンアップで非互換な修正加えてコードの修正が必要になって、Gemも上がって依存が壊れて
いつまでやってんだよｗ
Railsのプロジェクトでどれだけの人が最新版に追従できてんだよ？テストを書いてれば余裕？
本当かよ？正直に言ってみろよ？実際はレガシーRailsの山だろｗ
ヘルパーやらマイグレーションの仕組みやら最初は良いかなと思ったけど、どう考えてもやり過ぎだ
短くかけるとか喜んでるやつは一度考え直せ
それで良いんだって？自分がコントロールできない知らないコードに依存して結局バージョンアップで地獄みてるだろｗ
最低限中で何が起きてるか理解しとけよｗまあ理解できるころにはRailsでなくても良かったんやｗってなるけどなｗ
RAILS_ENV=productionだとstaticファイルは自分で返さないassetコンパイルで小さくしましょう
→ developmentで動いてたけど本番だと動きませんでしたｗ
毎度毎度、アホみたいにGem入れやがって、もう自分で把握できる状態じゃねーだろ？
bundlerだから完璧にvendoring出来ますだって？
本当かよnaitive extensionのGemなんてどう考えたってRails管理外のヘッダファイルに依存すんだろ
めんどくせーなbundlerもこけるし、rbenv使ってrubyのバージョン揃えろとか
ホントめどくせーよ
deployもcapistrano便利とか言ってるけれど、そんなに便利じゃねーよｗ
あんなDSL覚える時間あんならシェルスクリプト書けるようになっとけ
rackサーバがたくさんあってよかったねじゃねーよ集約しろ馬鹿ｗ
unicorn, pumaで比較しましたとかアホ記事書いてる暇あるなら集約するかなにかしとけ
この手の話すると信者が使わない方法もある・選択しない方法もあるとか擁護してくるけど
そりゃあるけどそれ調べんのがめんどくせーって言ってんだよｗ
何でもかんでもレールに乗せてそれを強要してくるような感じがすんだよｗ
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
この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の翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。
安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．
宮森
安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？ これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）
安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh（省略されました
安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
＞ システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して，それで入ってきた人材に C を書かせればよいのでは！(ﾋﾟｺｰﾝ!
藤堂
犯罪ですよそれは
安原
はい．
藤堂
安原
まさにそれをイメージしていました．
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
（この辺で一同寝落ち）
キーワードを挙げると
・意味不明
・支離滅裂
・荒唐無稽
・腑に落ちない。
・雑
・コピペ
・つぎはぎ
・取ってつけた感
・脈絡のなさ
ふつう、物語があって起承転結するわけで、それに沿って必然性のある演出、展開、エピソードがある。だから腑に落ちる。
なんだけど、ラブライブは、経緯、エピソード、演出、情緒、といったものがクソ。
キャラクターと歌自体はまぁまぁだとは思うが、？？？が多すぎてそれらが全部吹っ飛んでる。自分の中で。
意味不明すぎてうまく言語化できていない。すごくモヤモヤして、腑に落ちなさだけが残る作品だった。
言いたいことや違和感の詳細は、だいたいこの批判記事に書かれていて腑に落ちた
劇場版ラブライブ！批判考察① http://anond.hatelabo.jp/20160221211019
劇場版ラブライブ！ 見てきたけどマジでクソ映画だった:オタクマガジン～黒歴史の向こう側へ～ - ブロマガ http://ch.nicovideo.jp/hirasawa_yui/blomaga/ar811153
たとえば、ニチアサ、戦隊モノやプリキュアっていうのはアタマをカラッポにして楽しむことができる。無意味なシーンやエピソードがない。子供と遊ぶような、それはそれでロールプレイして楽しむことができる。ラブライブはそういった類の楽しみ方もできない。
たとえばインドの踊りまくる映画とか、ハリウッドのＢ級映画とかの「考えるな、感じろ」系の作品は、たしかに同じ馬鹿なら踊らにゃソンソン！的なノリで見れば楽しむことはできるんだが、ラブライブはそういう楽しみ方もできない。一貫したものがないから。
けいおん！もあずにゃんが出てきたあたりで視聴挫折している。甘ったるい間延びした空気感に耐えられなくなって、視聴モチベーションの灯火が消えた感じ。
ラブライブを楽しめている人ってどういうノリなのか？わからん・・。楽しみ方の作法を教えてほしい。というかワイはアイドルアニメ、音楽部活アニメに向いてないのだろうか。ワイも老害になったのだろうか。
このブコメが腑に落ちた：
ラブライブ、基本的には好きだけど、一貫性のある物語や精緻な人物描写の「力」を信じている人には、それがなくてもあんなに売れちゃうんだーみたいな絶望感のある作品だと思う - heavenward のコメント / はてなブックマーク http://b.hatena.ne.jp/entry/257185110/comment/heavenward
ワイは、整合性が取れていないものに対して敏感に嫌悪を催すタイプなのか。脳内でコンパイルエラーを起こすから。整合が取れていないものを発言したり受け入れたりする人が生理的に受け付けられないなぁ・・。
でもアイマスアニメは、まぁまぁ全部みて楽しめたなぁ。あれはちゃんと「完成」されている。王者の安定感がある。単なる「記号」ではなく「人格」としてのキャラ立ち・個性が表現されていて、困難と努力のリアリティがあり、これぞアイドルプロデュースといったところ。ただ重課金ビジネスは嫌い。ラブライブは「人格」が弱い・・。
アイマス信者でもない。アニメやってたから見ただけ。ゲームやったこともない。
艦これのテレビアニメ版も、シリアスにしたいのかギャグにしたいのか支離滅裂で意味不明、最後の作戦も蛇足すぎたし、かなりのクソだったが、ラブライブはそれよりもさらに下を行くクソさ。
※ただ、艦これは映画でシリアス一辺倒路線で吹雪編（？）の締めをしていて、それはそれでまとまった作品になっていたので、評価は上がった。
仮に俺がお金を握っている立場だったら、脚本家や演出家に給料を出したくない。
でも悲しいけどこれってビジネスなのよね。売れればいい。それだけだ。
後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」
先輩「そうかそうか、やっと肩の荷がおりるな」
後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」
〜
先輩「まずはじめにnode.jsを入れる」
後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」
先輩「いや、nodeは使ってない」
後輩「え？」
先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」
後輩「なんでまたそんな回りくどいことを・・・」
先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」
〜
先輩「よしnode入れたな。じゃあnpm installだ」
先輩「printFizzBuzzというパッケージが404みたいだな」
後輩「何に使うんですかそのライブラリ」
先輩「知らん。依存してるライブラリが依存してるライブラリが依存してるライブラリかなんかだろう」
後輩「バタフライエフェクトってやつですね」
先輩「思い出した。これは昔話題になったやつだ。printFizzBuzzは何かの特許に抵触していて非公開になったらしい。
npm installで落とすのは諦めて、ローカルに残ってるやつで何とかするしかないな」
後輩「それ使って大丈夫ですかね。法的に」
先輩「仕方ないだろ」
〜
先輩「ようやく諸々揃ってBabelやReactやWebpackを使えるようになった」
後輩「それ何ですか？」
先輩「まずBabelだが、これはES2015をES5にコンパイルするツールだ」
後輩「え、なんでダウングレードするんですか？」
先輩「古いブラウザで当時の最新機能を使うにはこうする必要があったんだ」
後輩「なるほど。ではReactは？」
先輩「これは今で言うWeb Componentsみたいなものだな。あと仮想DOM」
後輩「Babelじゃダメだったんですか？」
先輩「ダメだったんだよ」
先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバーが馬鹿だったんだよ」
後輩「へ〜大変ですね」
〜
後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」
後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」
先輩「当時はこれが最善の選択だったんだよ」
後輩「そうなんですね」
この記事は「フリーランス残酷物語 Advent Calendar 2016」15日目のポエムです。えっ、まだ12月15日じゃない？あぁ、そんな事もあるかもしれないですねぇー。でも気のせいじゃないですかたぶん。
まず前置きですが、mesaka さんの書いた記事が萌えましたねぇ。じゃなくて燃えましたねぇ。まぁ、会社にバカにされたっていいじゃないですか。社員プログラマーにバカにされたってしったこっちゃありませんよ。Qiita ユーザーにもバカにされ、はてブに晒され、社会からゴミ扱いされたかどうか分かりませんが、フリーランサーはそれでも生きている限り契約を繰り返し日々前進していかねばならないのです。愚痴ることで生きていけるのなら問題ないのです！というわけで、mesaka さんには最終日の日記でも燃料を投下してほしいと思うわけです。よろしくお願い致しますm(_ _)m
前置き終わり。さてさて、僕がフリーランスだった2004年頃に体験した、奇妙で残酷な作業依頼のことを書きたいと思います。
フリーランスになる前はゲーム会社で社員プログラマーをしていました。コンシューマやアーケードゲームを何本か開発したのですが、ゲームの発売が近づくと月400時間以上の長時間労働を行います。そんなことを何回もやっていると人間は壊れます。裁量労働制の裁量ってどんな意味だろう、、、と考えながら3年働き、もうダメだなと思った時に同期の10人は誰も残っておらず、一番最後の退職者となりました。その後1年は携帯ゲーム会社でゆるふわな開発を行い、元気がでてきたところでフリーランスとして働き始めました。
初めての契約は 3DRPG を開発している会社と結びました。準委任契約なので会社に出向し決まった時間働き、毎月決まったお金をいただく形です。業務内容はプログラミングとそれに関連する作業となります。関連する作業は曖昧ですが、まぁ雑用含めてお仕事するうえでの作業全てなので、社員プログラマーと働き方はそんなに変わってない思います。
一般的なプログラム作業であれば、例えば MMORPG の開発ではマップ表示を担当しましたが、これはマップ担当の3Dデザイナーさんとデータの仕様などを決めていって、あとはプログラミングするだけのお仕事です。この開発ではプログラム全体の設計とプログラマーのまとめ役もやっていたので、メンバーへの指示出しやタスク管理もプログラミングに関連したお仕事です。
少し変わった作業だと PS2 で発売した 3DRPG のコードを渡され、「VisualStudio で動くようにして。大丈夫、描画エンジンだけ DirectX で動くものを別で用意したから」という依頼だったりします。幸いにして同じような依頼を前職の社員のときに受けていました。その時は PS 用に発売した 3D 格闘ゲームのプログラムを渡され「ナムコのSystem12基板で動かせるようにしてよ。大丈夫、PSと System12 の違いは CPU のクロックが違うだけだから」というものでした。どちらの依頼もプログラムと向き合うだけの作業なのでとても単純なです。CodeWarrior で書かれたコードを VisualStudio でコンパイルすると2万くらいコンパイルエラーを吐き出すのですが、それをもくもくと修正するだけです。
新人プログラマーの教育係もプログラミングに関連したお仕事です。ペアプロで一緒にゲームを開発していくのはとても楽しかった！あと成長していく新人かわいいぺろぺろ。
当時その会社ではまだバージョン管理ソフトを使っていませんでした。社員毎に Samba のディレクトリがあり、そこにプログラムファイルを配置して共有を行っていました。さすがにこれは不味いと思いバージョン管理ソフトの提案も行いました。前職では CVS と Microsoft Visual SourceSafe を使用していましたが、CVS には悪夢（マスターアップ1週間前にデータが壊れる）しか思い出がない事と、Visual SourceSafe は無料ではなかったため、当時流行りだしていた Subversion を検証したレポートを作成し、それをもってシステム管理部門を説得するということもプログラミングに関連したお仕事でした。システム管理部門は企業のガーディアンですので、そうそう実績のないソフトウェアを会社内の PC にインストールさせるわけにはいきません。2004年頃の Subversion は Ruby など新しい技術を使う Web 業界ではそれなりに認知度があったかもしれませんが、C++ も使わず C のみで開発を行っているゲーム業界での認知度はとても低いものでした。時間をかけじっくりとシステム管理部門を説得していく必要がありますが、これはプログラミングに関連したとてもとても大切なお仕事です。
なお、会社から社員にならないかとの提案を頂いたのですが、当時はフリーランスという契約のみで結ばれた、ときには人情のかけらもない綱渡り状態にスリルと興奮を感じていたため断りました。24歳という若さのためか、それとも前職で壊れた頭がまだ治っていなかったのかはわかりません。
そのようなプログラミングとプログラミングに関連する作業を行っていたところ、プログラマー全体を統括するマネージャーから奇妙な作業依頼を受けました。それはとある社員プログラマーのスキルチェックをして欲しいというものです。
新人教育でもなく、サポートしながら一緒にゲームのプログラミングを行っていくのではなく、スキルチェックです。スキルを見るならペアプロでもしてゲームの実装を行っていくのが良いと思ったのですが、製品にそのプログラムを入れたくという事で却下されました。また、スキルチェックに僕の時間をあまり使ってほしくないそうです。まぁそりゃそうだよねゲーム開発に時間使わないと。そこで、既存の開発とはまったく関係ないプログラムの課題を出して実装してもらいました。
しかし、まず課題を説明するところから問題が出ます。こちらの説明を全部紙にメモっているのですが、話が先に進むとメモれないとのことでメモり待ちが発生しました。口頭で2分くらいで伝わる仕様が10分くらいかかります。全部話しを聞いてから後でメモるのではダメなのかなと思ったのですが、どうもこのやり方でしか話が聞けないようです。
翌日に進捗を確認したかったのですが帰ってしまっていたので、次の日の朝に進捗を確認するとまだ実装中とのことでした。分からないところがあれば聞いて欲しいと伝え、作業を続けてもらいます。毎日こちらから進捗を確認するのですが、もう少しでできるという返事を貰う以外に特にアクションを起こしてきません。そんな状態で１週間が経ちました。ちなみに課題は1日くらいで実装できるものと想定していました。そして、この状況をマネージャーに説明し、チームメンバーに入れれるかという質問には難しいと答え、作業は終了となりました。
フリーランスの解雇は簡単です。しかし、社員の解雇というのはとても難しいものです。金の横領など分かりやすい行動をとった場合は別ですが、プログラミングスキルが低い事で一方的に解雇しようものなら逆に訴えれて終わりです。僕の今まで関わった会社さんでも、解雇した社員が訴えを起こさない代わりに和解金を要求し成立したケースもありました。スキル不足の社員を解雇するなら、社員にその事を納得してもらい円満に退職してもらうのが良いと思います。納得してもらうには情報が必要です。「○○を依頼しましたが、あなたは達成できませんでした」という情報をいくつも集めて納得してもらいます。退職していかれた社員プログラマーがフリーランスの僕のところに来る前、2人の社員プログラマーのもとでスキルチェックを受けていたそうです。僕で3人目だったわけですね。それら3人分の評価を伝え、納得してもらい退職してもらったのだと思います。
なんにせよ、一連の流れの中で僕は社員に印籠引導を渡すという残酷な作業をしていたわけです。正直楽しい作業ではありません。このような不幸なフリーランスを増やさないためにも、社員の方々には採用時のスキルチェックをしっかりと行って頂きたいと思う次第です。というかそいう首切り作業は社員でやって。。。あ、でも外部委託した方が会社としてメリットが大きいか。
こちらの会社さんがある意味消滅と言ってしまえるような状態になったので別の会社で社員として働いたものの、また頭がおかしくなってたのかフリーになり、受託用の個人会社まで設立し、その会社も今年で閉じ、今はサンフランシスコで英語の勉強と趣味のプログラミングをしています。あまり普通ではないので最初の会社でアホになってからそれが治ることはなかったようです。長時間労働マジ怖い。
自己紹介が遅れましたが akiraak といいます。Qiita に糞ポエムを晒すのは公衆衛生上よくないと思い増田に排泄した次第です。Qiita ではこんなのを書いています。
そこそこの企業の特にWeb系で渡り歩いた経験から、真実を書こう。
はっきり言う、ほとんどのプログラマと自称する人間の 9 割はコーダーである。
言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。
そんな驚きの生体をここに晒していく。
標準化と呼ばれるプロセスで、プログラマが環境の設計、組み合わせ、開発プラットフォームのセットアップ、開発環境の構築手順作成、開発手順の作成、必要な技術の考察を行う。
なぜそうなったのかは知らないが、一般的にそうなっている。
その環境に浸っているせいか、彼らはゼロベースでものを作ることが出来ない。
彼らにできるのは HelloWorld をコマンドプロンプトで表示するプログラム程度の事しか出来ない。
複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。
逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメントの記載などの保守に関わることをしない。
それは彼らにとって「必要ない無駄な作業」としか考えないのだ。
早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。
そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正で地獄を見るという簡単な論理に気づかない。
…何度味わっても気づかない。
たとえするとしても、業務時間中に業務で使ってる技術をピンポイントで学習するだけだ。
だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。
彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの？馬鹿か？」
あえて言おう、馬鹿は彼らだ。
Web で仕事をするならIDE（統合開発環境、エディタやコンパイル、テストやデバッグ実行などを画面から行えるツール）はほとんど必須（エディタで済ませる事も出来なくはない）が、彼らは状況に応じたセットアップができない。
たとえば「Maven（プロジェクト管理ツール）、checkstyle（コーディング規約チェック）、editorconfig（改行、インデント、文字コード設定）」が入っていたとする。
するとEclipseなどを使うとして
マニュアルやチュートリアルを用意しないと、道具の使用もままならない。
テストをなるべく機械にやらせようということの利点が理解できない。
そのために、何十回もコンパイル、デプロイ、アクセス、ログインの手順を何度も繰り返す。
関連する他の修正を行うたびに繰り返す…。
そしてやっと動くとひと仕事終えたと満足感に浸る。
ラリー・ウォールというとある有名な人物（Perl開発者にしてC言語ハッカー）がいる。
これは、自分の作るものは完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である。
彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。
同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。
変なプライドを持つコーダーは、それで運良く成功すると、自分の知識は正しい、自分の技術は十分なのだと考えている。
こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人か環境のせいにする。
そして調べず周囲を苛立たせるのだ。
土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない（んじゃないかと思う。）彼らは自分でなんでもやらないといけないからだ。
だが、大企業に飼われる子飼いの企業、派遣（そもそも人手のみを求められる企業）、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。
だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ。
人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。
必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢や思想はどうなんだと。
経営者よマネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か？人員最適化だけを行って、生産性が伸び悩んでいないか？
そのあたりは考えた方がいい。
昔のソフトウェア開発だとコンパイルをできる大型計算機ってのはとっても高価で一台しか無かったそうな
おまけにコンパイルするためには平気で1日とか2日とかかかっていたそうな
ソフトウェアにバグが混入しておるとその分の稼動が全て無駄になってしまうので
ソフトウェア開発者はコンパイルをする前に入念なチェックをしていたそうな
入念なチェックをフェーズに分けて行うための仕組みとしてウォーターフォール型というものが考案され
抽象的なソフトウェア仕様からコンパイルに書ける前のコードになるまで
段階に分けてソフトウェアにバグが無いかチェックしていたそうな
詳細設計書というのはその名残で、コンパイルをかけるときにバグがあってはならんから事前に設計するようにしたんじゃ
ところで結局ウォーターフォール型では各工程で不都合が生じたときに前の工程に戻ることが難しく
本当の意味でのソフトウェアの品質や工期が伸びてしまうのが大きな問題で
それを解決できないか試行錯誤しておるうちにハードウェアが進化して開発者みんながパソコンを持てるようになり
ソースコードを書きながらコンパイルできるようになったもんじゃからこの方法は海外では廃れてしまったのじゃ
一方日本ではウォーターフォール型というものが古来より日本の社会システムにある天下り制度とマッチしてしまったこともあり
ウォーターフォール型が大変好まれて今も使われているというわけじゃ
これが日本の大企業からろくなソフトウェアが生まれない理由なんじゃと思うのぅ
