「コンパイル」を含む日記 RSS

はてなキーワード: コンパイルとは

2017-04-09

経済格差による情報格差の一例かな?がんばって。

長く書きますお金の話の経験とかも、少しでも参考にしてください。

話に一個ずつ答えてく

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

4年前になるけど、高校生の時は1万円くらいのパソコン中古で買って、使いにくいのを我慢してて、実際損だったなと思うこともある。

お金のない環境を整えられない学生はつらいよね。明らかに札束で殴れず時間を使って損してる。

twitterできないメインで使えないのもまず、重すぎるからっていうのもありそう。

スペックが足りてなさすぎる。まずは6,7万出してスペックを整えよう。

すごい人たちについて

すごい人たちは幼少の頃からパソコンがあって、パソコンをいじるだけの時間があって、承認されてる。

しかも、コミュ症だとかなんだかんだ言いながらも、ネットではきちんと弾けてるし、人望もある。

彼らを理解するのはすっごく難しい。

経済格差が多すぎて、彼らが積んできた経験と持っている環境が違いすぎるから

プログラム自体数学を解くようですごく楽しいのだけれど、なぜ苦しい勉強をしながらプログラムをずっとやっていられるのかわからない。

環境はMac(高すぎて揃えるなんてとんでもない)じゃないから、先人たちの簡単に手順化された知恵を受けづらく、プログラム環境をととえるまでが大変だし、

ライブラリ関係エラーコード自分の力で、ライブラリを見つけに行かないとダメで、ウェブ検索しても彼らよりもずっと時間がかかる。

そこをきちんと理解したうえで、自分がどこまでやりたいのか、どうしてやりたいのか

自分プログラマに向いているのか、考えながら、勉強していったほうが良い。

私について

ちなみに私はプログラムを解くの好きだったし、ある程度は得意だった。

ADHD自閉症混じってるから、だから職人的なことをやりたかったし、テストをかけば不注意で大きな損失を出す可能性も低くなる。

からプログラマを目指しているし、プログラマとして就職するつもりなんだよね。

twitterで有名な人てやっぱりSランクとか余裕なのかな

プログラマレベル

私も無名で、プログラム力的にはpaizaのSランクは、後ちょっと足りない、運が良ければ成功するんじゃない?ってレベル

イッタランドのすごい人たちは目指すと疲れるだけなのでほどほどにね。

彼らは多分余裕綽々でS取れる。

paizaの出題は競技プログラムの一種で、競技プログラムっていうのはある程度出題の仕方が似通ってる。

複数回解いていると昔に残ったコードとか再利用できたりするから有利になるっていうのもある。

ゲームで例えるとRPG好きな奴にFPSやらせても全く活躍できないけど、FPSが得意な奴に別のFPSゲーやらせてもできたりするでしょ。

開発のジャンルの違いがあることは覚えといて。

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

開発環境OSについて

Mac買えなくて開発環境として選ぶなら,windowsよりlinuxのほうが良い。

windowsだと環境整える前にストレスやばいし、パソコンが死んだ場合ストレスやばい

あと、古いパソコンだとUSBブートができなかったのも割とめんどくさかったし、回線がめちゃくちゃ低速だったから、ISOファイルダウンロードに半日かかってたかな。

ubuntuは良いんだけど、スペック足りてない。

VirtualBoxはすごいスペック持っている人が使うものなので、買い換えないならクリーンインストールデュアルブート推奨。

ubuntuにしとけば、ウイルス系もあんまり構う必要性がなくなるからね。

フリーソフト選択肢は狭まるけど。)

起動にVirtualBox起動に数分待って、端末以外を使おうとすると固まるみたいなことやってると辛さが溜まるから

あとデュアルブートはいいよ

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

クレジットカードについて

デビットカードでも行ける。

するが銀行に口座を作ってデビットカードを申しこめば、20歳以下でもなんとかなる。(年齢によっては親の同意は必要だけど)

2,3週間かかるけど、デビットカード作っておくことで色々なサービスを体験できるようになるのは選択肢を増やすにあたって重要なことだから是非。

コンビニからお金を入れられるので地方でも安心だしね。


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

SNSについて

ネット上は怖い人もたくさんいるし、まさかりがちょくちょく飛んでくるけど、変にウケる拡散してくれて色々な人が声をかけてくれるのも確かだったりする。

ゆっくり自分の使い方を覚えていけば少しずつ楽しめると思う。

実際、SNSは情報の精度としては当てにならないし、勉強のためってSNSを使うとストレスで辛くなった。

自分好きな人だけをフォローすると精神安定するよ、あとフォロー返しはやる必要はない。やってるとTL荒れるからね。

リストとか使いこなせるなら別なんだろうけどね)

ちなみにここに飛んできた理由ツイッターかな。







何を改善したら昔よりも良くなったかってことだけつらつらと書いていく。


おすすめ度は◎○△であらわす。

ノートパソコンを新調する
おすすめ度:◎
条件:最低で6,7万円のお金必要おすすめlenovoのeシリーズ。
重いけど、コスパは良好比較的安めに上がってキーボードも打ちやすいのが良い。
いまはcorei5, メモリ8GBの使ってて、大体(重めのゲーム以外)したいことはなんとかなる。
SSDはあったら便利だけど、一番重要なのはメモリな。
開発したいなら8GBは必須。
(苦労話:
古すぎてノートなのにキーボード常時接続必要だったり、画像が多いサイトブラウザを選ぶ必要があったり、何よりもIDEが使えなくて辛かった。
windows vistaのupdateで数日固まったりゴミしかなかった。
)

光回線契約にする。
おすすめ度:◎
条件:契約できる年齢か、親の同意(年4万円くらいの出費)が必要
何をするにもまず回線速度が遅いと話にならない。
IDE落としたり、クラウドファイル上げたり、AWS使う時のアップロードとか、音声会話とか。
〇〇をしてみたいと思ったら,ダウンロード時間がかからないことは、モチベーションのためにめちゃくちゃ大切。

(苦労話:
ISOファイルダウンロードするのに半日かかるのが普通だと思ってたけど、
まともな光回線+まともなルータを利用したら、ダウンロードに1時間ちょいになってびっくりした。
特に古いルータだったりするとボルトネックになったりする。
)

ubuntuクリーンインストールする。
おすすめ度:○
条件:linuxで生きていくという覚悟
windowsよりは快適。
他のlinuxISOファイルを焼いたりするときちょっと苦労するかもしれないし、軽いの選ぶと良いかも。
実際普段使うものネットプログラムツールだけだったから、なんとかなったし、ゲーム選択肢強制的排除されるので、
少しはプログラムに触りやすくなるかもしれない。
(苦労話:
エクセルパワポ必要とか言われた時に、officeレイアウトで死んだりする。
資料はPDFな。

買い換えない場合クリーンインストールは↓
昔のパソコンでもLinuxとか入れればそれなりに動くよっていう人はいるけど、やっぱり社会的通信網と平均的なマシンスペックが上がっているせいで、ウェブ自体要求するスペックも上がってて低スペックだとつらい。
ブラウザはw3mとか使って、端末タブを開いてvimで開発してた。
なんでかって言うと普通にブラウザ使うとレスポンスが重すぎたから。
でもその使いづらさの分だけ損してるんだよね。
)

勉強会に行く、もしくはライブ中継を見る
おすすめ度:○
条件:電車代などの交通費を用意可能
できること:
他人に触発されるタイプなら、すごい人たちの興味の方向を見て学ぶ方向が増えるかもしれない。
後は交通費宿泊費の出る勉強会なんてものもあるので応募してみると良いかもしれない。
高校生なら、交通費出してくれるっていう太っ腹な勉強会もちらほらある。
一、二回は顔出し推奨。
欠点はあって、コミュ症は治らないので、友達ができるとは限らない。


パソコンを触れる時間を増やす
おすすめ度:△
条件:家庭環境による
できること:
自分向上心による。
大学生になって一人暮らしになったら、パソコンに触れる時間は多くなったとは思う。
(勉強しているとは言っていない)


デスク椅子の購入
おすすめ度:○
条件:3,4万円の出費
できること:
まず、パソコンを長時間触っていても疲れなくなる。
デスクの高さと椅子の高さはとても大切なもの。
疲れなくなるし、指が攣りそうになることもない。
机の高さはきちんと調べたほうが良い、あってることが重要
今使っているのは1万ちょいの新品デスクニッセンフリーテーブル)と3万弱の中古オフィスチェア
基本的に3000円位のデスク耐久性と高さがゴミだったりするので注意。
机は http://blog.livedoor.jp/itsoku/archives/38727329.html の66のテンプレを見ておくと良いかな。
(苦労話:
しかノートパソコンデスク椅子がなくて狭いこたつの上か100均で買ってきた台の上で、パソコンを使っていたかパソコン位置の高さが合わなくて姿勢がどうしても悪くなるせいで長時間パソコンをいじることもできなかった。

後は寝ながらパソコンをいじるみたいなみたいな堕落生活してたら、筋肉が硬直してまともに手を握れなくなって、医者にかかることになって1万円程度お金がかかったし、
2ヶ月位まともにパソコン触れなくなった。
ちょうどその時期は、筆記用具をほとんど使わない単位だけだったから良かったものの、他の単位とってたらもっと治療時間がかかったかもね。
)



jetbrainsのIDEの使用
おすすめ度:○
条件:それなりのスペックパソコン、それなり大きさのディスプレイ
できること:
設定しなくても、複数ファイルから補完が聞くし、フォルダ内の全てのファイルから検索、置換ができるのが良い。
ただし、ディスプレイが小さいと実際に開発できる範囲が小さくなるのは注意。
(苦労話:
IDEは普通に使えるなら作業効率が全く違って、設定少なくても補完も他のファイルライブラリから保管してくれるたりする。
でも、昔の環境だとeclipseフリーソフトだけど環境整えるまでが辛いし、重いしで、開くとブラウザすらまともに操作できなくのが辛い。
だからブラウザチュートリアルとか見ててもパソコンに待たされてストレスだった。
まともに使うには設定がめちゃくちゃ必要なのは実際疲れた。

(ac.jpメールアドレス必要だけど)学生無料なIDEでjetbrains製品があるけど、設定しなきゃダメなvimとかと違ってマウス操作できるのがすごい良い。
端末ではコピペ簡単にできなくて、数は少ないけどよくあるミスが、間違えてcommandモードで貼り付けてやり直したり、vimのline numberの設定をいじらずにvimからコピペができる。
コレだけでイライラ具合が全然変わる。
)

図書館からコーディングの本を借りてきて読む(できれば、実践すること)
おすすめ度:◎
条件:図書館や図書室で本を注文できるか、本があるか
できること:
プログラム能力が向上する。
おすすめされている本を探すと良い。
プログラム学者なら、ネットだけで勉強するよりは効率がある。
とりあえず、やりたいことなくて、プログラム力をただ上げておきたい場合は、
競技プログラムやりたいとしても下の順番で進めると良いかもしれない。
あと、プログラムには自分が到達しているところまでで言うと、次の順で壁があって能力が足りないと行き詰まることがある。
>> 関数化 → クラス化 (→ ポインター) → 再帰 → 関数型言語 <<
数年かけて勉強して次の段階に勧めないならプログラマは諦めたほうが良いかもしれない。
(能力が足りないのは上司自分もつらくなるよ)


パソコンディスプレイを買うこと
おすすめ度:○
条件:1万円弱のお金
できること:
ノートパソコンなら2個の画面を使えると作業効率が違う。
特に手打ち系のコーディング練習とかがめちゃくちゃ捗るようになる。
(苦労話:
IDE系列は画面を割と占拠するので、ノートパソコンの狭い画面だと辛い。
でも大きすぎる画面だと持ち運べなくなるのでダメ画素数が上がればその分だけ小さく表現ができるので、画面サイズが同じでも画素数が違うとかなり大きさが違って見えたりする。
)

大学に入って時間を稼ぐ
おすすめ度:○
条件:学力があること努力すること、覚悟
できること:
奨学金を利用して環境を整えたり、時間が増えるから更に勉強できる。
プログラム関係もそれ以外も就職先が増える。
また、これから転職したくなった時に逃げ道が増える。
欠点国立は安いけど、入学にそれ相応の努力必要私立行けるなら、苦労してないと思う。
あと免除制度っていうのがあるから、そういうのも利用しつつ費用を安く上げよう

デビットカードを持つこと
おすすめ度:○
条件:年齢(か、親の同意)
できること:
ちょっとした電子払いができるようになる。
多重債務は起こらない。
欠点としては、定期払いはできないので携帯の契約とかはできないことに注意。




終わりに

スペックパソコンしか無いのは、多分家庭環境のせいでもあって、

君がアルバイトもできるかどうかわからないし、アルバイトしてもそのお金が君のもとに入ってくるかはわからない。

お金無限にあるわけじゃないし、時には経済格差を感じて辛くなることもあるだろう。

少ないお金の中でうまくやりくりして、それでも自分の力にしていってほしい。

お金が潤沢にあるなら親を説き伏せることをがんばって)

応援してるよ。

http://anond.hatelabo.jp/20170407112743

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買わない?プログラミングバイトでもいいと思うよ。

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

プログラミングの学び方がわからない

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

WindowsAPIを使って複雑なプログラムを作りたいわけじゃないので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に変えた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

迷宮にいる感じ。

2017-03-18

http://anond.hatelabo.jp/20170317223350

gccアセンブラーの中間コード吐き出させてみると、楽しいと思うよ。

レジスタ倍増、ビット長倍増、コードホルホルする。

再起されるような、アホほど繰り返されるコード64ビットでリコンパイルしたら、同クロックでも違いがでる

2017-03-08

Railsつらい

バージョンアップがツライ

毎度毎度、バージョンアップで非互換修正加えてコード修正必要になって、Gemも上がって依存が壊れて

いつまでやってんだよw

Railsプロジェクトでどれだけの人が最新版追従できてんだよ?テストを書いてれば余裕?

本当かよ?正直に言ってみろよ?実際はレガシーRailsの山だろw

概念・周辺ツールがツライ

ヘルパーやらマイグレーションの仕組みやら最初は良いかなと思ったけど、どう考えてもやり過ぎだ

短くかけるとか喜んでるやつは一度考え直せ

複雑さがRails側に寄ってるだけでなんも解決してない

それで良いんだって自分コントロールできない知らないコード依存して結局バージョンアップ地獄みてるだろw

最低限中で何が起きてるか理解しとけよwまあ理解できるころにはRailsでなくても良かったんやwってなるけどなw

RAILS_ENV=productionだとstaticファイル自分で返さないassetコンパイルで小さくしましょう

→ developmentで動いてたけど本番だと動きませんでしたw

どんな茶番だよw馬鹿か?

Gemがツライ

毎度毎度、アホみたいにGem入れやがって、もう自分で把握できる状態じゃねーだろ?

bundlerだから完璧にvendoring出来ますだって

本当かよnaitive extensionGemなんてどう考えたってRails管理外のヘッダファイル依存すんだろ

bundle installがこけるなんて日常茶飯事だろw

環境構築がツライ

ruby入れてGem入れてGem入れるためのヘッダ用意して

めんどくせーなbundlerもこけるし、rbenv使ってrubyバージョン揃えろとか

ホントめどくせーよ

deployもcapistrano便利とか言ってるけれど、そんなに便利じゃねーよw

あんDSL覚える時間あんならシェルスクリプト書けるようになっとけ

rackサーバがたくさんあってよかったねじゃねーよ集約しろ馬鹿

unicorn, puma比較しましたとかアホ記事書いてる暇あるなら集約するかなにかしとけ

信者がツライ

この手の話すると信者が使わない方法もある・選択しない方法もあるとか擁護してくるけど

そりゃあるけどそれ調べんのがめんどくせーって言ってんだよw

何でもかんでもレールに乗せてそれを強要してくるような感じがすんだよw

turbolinksなんて仕組みをデフォルトONにしてくるやつらの態度が嫌なんだよ

2017-02-26

anond:20170225195916

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

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

この二つの理由から、元記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

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

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

このようなサービスを利用することの弊害として、(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することが挙げられます

もちろんこれはあまり良いことではない。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティ新規に作られた著作物コミュニティ哲学に反する物に依存するというのは、かなり致命的である

たとえ奇跡が起こり、例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

追記

Ubuntu Japanse Teamの関係者に読まれたようなので満足しました。(2017/2/27 22時)

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

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2017-01-07

ラブライブ映画

ラブライブ映画を見た。1/3にNHKでやっていた。

相変わらずテレビアニメ版と同じ感想だった。

キーワードを挙げると

意味不明

支離滅裂

荒唐無稽

・腑に落ちない。

・雑

コピペ

・つぎはぎ

・取ってつけた感

脈絡のなさ

ふつう物語があって起承転結するわけで、それに沿って必然性のある演出、展開、エピソードがある。だから腑に落ちる。

なんだけど、ラブライブは、経緯、エピソード演出情緒、といったものがクソ。

キャラクターと歌自体はまぁまぁだとは思うが、???が多すぎてそれらが全部吹っ飛んでる。自分の中で。

意味不明すぎてうまく言語化できていない。すごくモヤモヤして、腑に落ちなさだけが残る作品だった。

言いたいことや違和感の詳細は、だいたいこの批判記事に書かれていて腑に落ちた

 劇場版ラブライブ!批判考察http://anond.hatelabo.jp/20160221211019

 劇場版ラブライブ! 見てきたけどマジでソ映画だった:オタクマガジン黒歴史の向こう側へ~ - ブロマガ http://ch.nicovideo.jp/hirasawa_yui/blomaga/ar811153


たとえば、ニチアサ戦隊モノプリキュアっていうのはアタマカラッポにして楽しむことができる。無意味なシーンやエピソードがない。子供と遊ぶような、それはそれでロールプレイして楽しむことができる。ラブライブはそういった類の楽しみ方もできない。

たとえばインドの踊りまくる映画とか、ハリウッドのB級映画とかの「考えるな、感じろ」系の作品は、たしかに同じ馬鹿なら踊らにゃソンソン!的なノリで見れば楽しむことはできるんだが、ラブライブはそういう楽しみ方もできない。一貫したものがないから。

けいおん!あずにゃんが出てきたあたりで視聴挫折している。甘ったるい間延びした空気感に耐えられなくなって、視聴モチベーションの灯火が消えた感じ。

ラブライブを楽しめている人ってどういうノリなのか?わからん・・。楽しみ方の作法を教えてほしい。というかワイはアイドルアニメ音楽部活アニメに向いてないのだろうか。ワイも老害になったのだろうか。

このブコメが腑に落ちた:

 ラブライブ基本的には好きだけど、一貫性のある物語精緻人物描写の「力」を信じている人には、それがなくてもあんなに売れちゃうんだーみたいな絶望感のある作品だと思う - heavenward のコメント / はてなブックマーク http://b.hatena.ne.jp/entry/257185110/comment/heavenward

ワイは、整合性が取れていないものに対して敏感に嫌悪を催すタイプなのか。脳内コンパイルエラーを起こすから整合が取れていないもの発言したり受け入れたりする人が生理的に受け付けられないなぁ・・。

でもアイマスアニメは、まぁまぁ全部みて楽しめたなぁ。あれはちゃんと「完成」されている。王者の安定感がある。単なる「記号」ではなく「人格」としてのキャラ立ち個性表現されていて、困難と努力リアリティがあり、これぞアイドルプロデュースといったところ。ただ重課金ビジネスは嫌い。ラブライブは「人格」が弱い・・。

アイマス信者でもない。アニメやってたから見ただけ。ゲームやったこともない。

艦これテレビアニメ版も、シリアスにしたいのかギャグにしたいのか支離滅裂意味不明最後作戦蛇足すぎたし、かなりのクソだったが、ラブライブはそれよりもさらに下を行くクソさ。

※ただ、艦これ映画シリアス一辺倒路線吹雪編(?)の締めをしていて、それはそれでまとまった作品になっていたので、評価は上がった。

仮に俺がお金を握っている立場だったら、脚本家演出家給料を出したくない。

でも悲しいけどこれってビジネスなのよね。売れればいい。それだけだ。

から色んな作品に出てるんだね・・。

ちなみに、ラブライブ サンシャイン のほうは未視聴です。

2016-12-30

2020年に振り返る2016年Web開発

後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」

先輩「そうかそうか、やっと肩の荷がおりるな」

後輩「これ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じゃダメだったんですか?」

先輩「ダメだったんだよ」

後輩「で、最後Webpackは?」

先輩「リソースモジュール管理して最適化するツールだ」

後輩「最適化サーバー仕事じゃないんですか?」

先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバー馬鹿だったんだよ」

後輩「へ〜大変ですね」

後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」

先輩「一度準備してしまえば、そこから先が楽になるんだ」

後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」

先輩「当時はこれが最善の選択だったんだよ」

後輩「そうなんですね」

2016-12-22

言葉は生き物

ハンドアセンブルのことを「手でコンパイル」と言ってる人がいてああ俺も歳を取ったなあと思った。

2016-12-14

vimコンパイルするならccacheの使用はやめましょう

ccacheを使ってコンパイルすると大量にエラー出るのでやめましょう。

makeに-f付けて並列コンパイルするだけでいいんです。

1core celeronメモリ1GBの10年前の化石スペックノートパソコンでもね、何も並列化せずにコンパイルすればvim hugeも7〜10分以内に終わります

vim tinyだと2分ぐらい

vim normalだと4〜5分ぐらい

今すぐccacheの使用をやめなさい

2016-12-08

奇妙で残酷作業依頼 - フリーランス残酷物語 Advent Calendar 2016 15日目

この記事「フリーランス残酷物語 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ディレクトリがあり、そこにプログラムファイルを配置して共有を行っていました。さすがにこれは不味いと思いバージョン管理ソフト提案も行いました。前職では CVSMicrosoft Visual SourceSafe使用していましたが、CVS には悪夢マスターアップ1週間前にデータが壊れる)しか思い出がない事と、Visual SourceSafe無料ではなかったため、当時流行りだしていた Subversion検証したレポート作成し、それをもってシステム管理部門を説得するということもプログラミングに関連したお仕事でした。システム管理部門企業ガーディアンですので、そうそう実績のないソフトウェア会社内の PCインストールさせるわけにはいきません。2004年頃の SubversionRuby など新しい技術を使う Web 業界ではそれなりに認知度があったかもしれませんが、C++ も使わず C のみで開発を行っているゲーム業界での認知度はとても低いものでした。時間をかけじっくりとシステム管理部門を説得していく必要がありますが、これはプログラミングに関連したとてもとても大切なお仕事です。

なお、会社から社員にならないかとの提案を頂いたのですが、当時はフリーランスという契約のみで結ばれた、ときには人情のかけらもない綱渡り状態スリルと興奮を感じていたため断りました。24歳という若さのためか、それとも前職で壊れた頭がまだ治っていなかったのかはわかりません。

そして奇妙な作業依頼

そのようなプログラミングプログラミングに関連する作業を行っていたところ、プログラマー全体を統括するマネージャーから奇妙な作業依頼を受けました。それはとある社員プログラマースキルチェックをして欲しいというものです。

新人教育でもなく、サポートしながら一緒にゲームプログラミングを行っていくのではなく、スキルチェックです。スキルを見るならペアプロでもしてゲーム実装を行っていくのが良いと思ったのですが、製品にそのプログラムを入れたくという事で却下されました。また、スキルチェックに僕の時間をあまり使ってほしくないそうです。まぁそりゃそうだよねゲーム開発に時間使わないと。そこで、既存の開発とはまったく関係ないプログラム課題を出して実装してもらいました。

しかし、まず課題説明するところから問題が出ます。こちらの説明を全部紙にメモっているのですが、話が先に進むとメモれないとのことでメモり待ちが発生しました。口頭で2分くらいで伝わる仕様10分くらいかかります。全部話しを聞いてから後でメモるのではダメなのかなと思ったのですが、どうもこのやり方でしか話が聞けないようです。

翌日に進捗を確認たかったのですが帰ってしまっていたので、次の日の朝に進捗を確認するとまだ実装中とのことでした。分からないところがあれば聞いて欲しいと伝え、作業を続けてもらいます毎日こちらから進捗を確認するのですが、もう少しでできるという返事を貰う以外に特にアクションを起こしてきません。そんな状態で1週間が経ちました。ちなみに課題は1日くらいで実装できるものと想定していました。そして、この状況をマネージャー説明し、チームメンバーに入れれるかという質問には難しいと答え、作業は終了となりました。

そして、その社員プログラマー退職していかれました。

社員解雇

フリーランス解雇簡単です。しかし、社員解雇というのはとても難しいものです。金の横領など分かりやすい行動をとった場合は別ですが、プログラミングスキルが低い事で一方的解雇しようものなら逆に訴えれて終わりです。僕の今まで関わった会社さんでも、解雇した社員が訴えを起こさない代わりに和解金を要求し成立したケースもありました。スキル不足の社員解雇するなら、社員にその事を納得してもらい円満退職してもらうのが良いと思います。納得してもらうには情報必要です。「○○を依頼しましたが、あなたは達成できませんでした」という情報をいくつも集めて納得してもらいます退職していかれた社員プログラマーフリーランスの僕のところに来る前、2人の社員プログラマーのもとでスキルチェックを受けていたそうです。僕で3人目だったわけですね。それら3人分の評価を伝え、納得してもらい退職してもらったのだと思います

なんにせよ、一連の流れの中で僕は社員印籠引導を渡すという残酷作業をしていたわけです。正直楽しい作業ではありません。このような不幸なフリーランスを増やさないためにも社員の方々には採用時のスキルチェックをしっかりと行って頂きたいと思う次第です。というかそいう首切り作業社員でやって。。。あ、でも外部委託した方が会社としてメリットが大きいか

フリーランスのその後

こちらの会社さんがある意味消滅と言ってしまえるような状態になったので別の会社社員として働いたものの、また頭がおかしくなってたのかフリーになり、受託用の個人会社まで設立し、その会社も今年で閉じ、今はサンフランシスコ英語勉強趣味プログラミングをしています。あまり普通ではないので最初会社でアホになってからそれが治ることはなかったようです。長時間労働マジ怖い。

自己紹介が遅れましたが akiraak といいますQiita に糞ポエム晒すのは公衆衛生上よくないと思い増田に排泄した次第です。Qiita ではこんなのを書いています

TensorFlowで株価予想シリーズ

ディープラーニング面白いのでみんな遊びましょう!

2016-11-20

大多数のプログラマは…

IT業界に努めてもうそろそろ二桁年。

そこそこの企業特にWeb系で渡り歩いた経験から真実を書こう。

一般的プログラマと呼ばれる人たちは

はっきり言う、ほとんどのプログラマ自称する人間の 9 割はコーダーである

言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。

そんな驚きの生体をここに晒していく。

一般的コーダー自称プログラマ)は、アプリケーションの基盤が作れない

標準化と呼ばれるプロセスで、プログラマ環境設計、組み合わせ、開発プラットフォームセットアップ、開発環境の構築手順作成、開発手順の作成必要技術考察を行う。

なぜそうなったのかは知らないが、一般的にそうなっている。

その環境に浸っているせいか、彼らはゼロベースものを作ることが出来ない。

彼らにできるのは HelloWorldコマンドプロンプトで表示するプログラム程度の事しか出来ない。

複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。

一般的コーダー自称プログラマ)は、保守性を考えない

彼らは自分に任されたものを動かせればタスクが終了する。

逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメント記載などの保守に関わることをしない。

それは彼らにとって「必要ない無駄作業」としか考えないのだ。

早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。

そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正地獄を見るという簡単論理に気づかない。

…何度味わっても気づかない。

一般的コーダー自称プログラマ)は、勉強しない。

一般的プログラマコーダー)は勉強をしない。

たとえするとしても、業務時間中に業務で使ってる技術ピンポイント学習するだけだ。

勉強会は確かに多い。「.dits」何かがいい例だ。

だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。

彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの?馬鹿か?」

あえて言おう、馬鹿は彼らだ。

一般的コーダー自称プログラマ)は、自分の使う道具がわからない

Web仕事をするならIDE統合開発環境エディタコンパイルテストデバッグ実行などを画面から行えるツール)はほとんど必須エディタで済ませる事も出来なくはない)が、彼らは状況に応じたセットアップができない。

たとえば「Mavenプロジェクト管理ツール)、checkstyleコーディング規約チェック)、editorconfig(改行、インデント文字コード設定)」が入っていたとする。

するとEclipseなどを使うとして

  1. どのプラグインを入れればいいか調べられない
  2. どうやってプロジェクトを取り込めばいいかからない
  3. プラグインを入れても設定方法がわからない(IDEデフォルト設定と、プロジェクト内の設定の違いを認識できない)
  4. IDE の設定画面がわからない

マニュアルチュートリアルを用意しないと、道具の使用もままならない。

一般的コーダー自称プログラマ)は、テストコードで書かない

テストをなるべく機械やらせようということの利点が理解できない。

コンパイルして動かして確かめればいいと本気で考えている。

そのために、何十回もコンパイルデプロイアクセスログインの手順を何度も繰り返す。

関連する他の修正を行うたびに繰り返す…。

そしてやっと動くとひと仕事終えたと満足感に浸る。

一般的コーダー自称プログラマ)は、プライドが無いか、変なプライドを持っている

ラリー・ウォールというとある有名な人物Perl開発者にしてC言語ハッカー)がいる。

彼の言う三大美徳に「傲慢」がある。

これは、自分の作るもの完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である

一般的コーダー自称プログラマ)は、このプライドはない。

彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。

同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。

変なプライドを持つコーダーは、それで運良く成功すると、自分知識は正しい、自分技術は十分なのだと考えている。

こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人環境のせいにする。

そして調べず周囲を苛立たせるのだ。

おわりに

土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない(んじゃないかと思う。)彼らは自分でなんでもやらないといけないからだ。

だが、大企業に飼われる子飼い企業派遣(そもそも人手のみを求められる企業)、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。

だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ

人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。

必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢思想はどうなんだと。

経営者マネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か?人員最適化だけを行って、生産性が伸び悩んでいないか

そのあたりは考えた方がいい。

2016-11-05

昔々、あるところにソフトウェア開発をしている人達がいたそうな

昔のソフトウェア開発だとコンパイルをできる大型計算機ってのはとっても高価で一台しか無かったそうな

おまけにコンパイルするためには平気で1日とか2日とかかかっていたそうな

ソフトウェアバグが混入しておるとその分の稼動が全て無駄になってしまうので

ソフトウェア開発者コンパイルをする前に入念なチェックをしていたそうな

入念なチェックをフェーズに分けて行うための仕組みとしてウォーターフォール型というものが考案され

抽象的なソフトウェア仕様からコンパイルに書ける前のコードになるまで

段階に分けてソフトウェアバグが無いかチェックしていたそうな

詳細設計書というのはその名残で、コンパイルをかけるときバグがあってはならんから事前に設計するようにしたんじゃ

ところで結局ウォーターフォール型では各工程不都合が生じたときに前の工程に戻ることが難しく

本当の意味でのソフトウェア品質や工期が伸びてしまうのが大きな問題

それを解決できないか試行錯誤しておるうちにハードウェア進化して開発者みんながパソコンを持てるようになり

ソースコードを書きながらコンパイルできるようになったもんじゃからこの方法海外では廃れてしまったのじゃ

一方日本ではウォーターフォール型というもの古来より日本社会システムにある天下り制度マッチしてしまったこともあり

ウォーターフォール型が大変好まれて今も使われているというわけじゃ

これが日本大企業からろくなソフトウェアが生まれない理由なんじゃと思うのぅ

http://anond.hatelabo.jp/20161105155342

2016-10-11

vimのpatchを書く→コンパイルメイクエラーループで嫌になる

patchを書いたとしてもコンパイルメイクエラーになる。

Rubyみたいにさくっと確認できるわけじゃないから面倒くさい。

よっぽどいいPC買わないと時間がかかるだけ。

本当Cって初心者に厳しいね

patch書く時間より無駄時間のほうが多い。

printf入れながらどこの関数が実行されてるのか調べるだけでマジ時間消費パネェッス。

学校コンピュータ室のはCore i5デスクトップパソコンからマジパクりたい。

小学生の時にお年玉で買った中古ノートパソコンだと厳しいわ。

中学生で高性能なパソコン持ってる奴が本当うらやましい。

2016-10-09

http://anond.hatelabo.jp/20161009190010

どうでもいいけど

bool a = nanka();
if ( a && !a ) {
    ....
}

というコードコンパイルしたら「comparison is always true」的な警告が出るはずだと思って試してみたら意外にもgccでは出なかった(最適化時は黙って消える)

「if ( (unsigned int)a >= 0 ) 」だったら警告出るのにね

2016-09-23

やめたソシャゲの話

本格的に初めて遊んだアプリゲーはぷよクエだった。

ぷよぷよコンパイル時代からは知っていたけど、俺自身パズルが苦手だったからずっと手を出してなかった。

それからぷよぷよフィーバーが出て、アコール先生一目惚れしてそれからずっとぷよぷよをやり続けていた。と言ってもエンジョイ勢ぷよひろいだけど。

んで、しばらくぷよぷよ20thをやり続けて、ぷよぷよクエストなるものサービスが始まるとフォロワーから聞いた。俺は即事前登録をしようとした。iPhoneの方が先に登録できるらしくてちょっとお得だった。

最初は無課金でダラダラ続けようとダラダラ遊んでた。最初にアコール先生を選べなかったのは不満だったけど次に好きなリデルがいたから良しとした。

開始したてのぷよクエはなんていうか酷い出来だった。課金ガチャからは☆2のカードボロボロ出てくるし、バランスも滅茶苦茶だったし、アルルシェゾルルーサタンも居なかった。イラストも使い回しばっかりだった。大好きなアコール先生も案内役としてはいたけど実装されていなかった。

それでも俺はぷよクエを続けた。フォロワー愚痴を言い合いながら遊ぶゲームは今思うと楽しかった。

やり続けていくうちに原作キャラストックが尽きたのかどうかは分からんけど、段々と元々いたキャラは影を潜めてぷよクエオリキャラが出まくるようになった。

ま、それでも好きなキャラが居ることには変わりないしって思ってひたすら好きなキャラを集めた。アコール先生は追加されたけど期間限定課金ガチャだったからそれなりに金を溶かした。

しかし、そのオリキャラ既存キャラよりも強力なやつらばっかりで、既存キャラオワコン化していった。

上位ランカーは次から次へと新しいキャラに乗り換え、ツイッターでもあいつはザコこいつはザコ言いまくってた。

ステータスを重視する奴がいるのは仕方ない。

古参オリキャラゴリ押しするなと喚いたし、新規もっと強いヤツだせと騒いでた。

ガチャ更新イベント更新がされる度に古参ぷよクエを叩きまくってた。

プロデューサーも叩いてたし、運営ツイッターアカウントには凸しまくるし、暴徒みたいだった。

それがしばらく続いて俺はぷよクエをやめた。

まさかぷよぷよが好きなフォロワー達の発言ぷよぷよを嫌いになりかけるとは思わなかった。

課金したけど悔いは無い。今もそう思う。

今は別のソシャゲをいくつかかけ持ちしてダラダラ遊んでる。

ソシャゲをやってる人とはあんまり関わってない。また嫌いになりたくないし。

2016-07-06

米光一成って何で偉そうにしているわけ?

ぷよぷよを始めとするコンパイル作品の多くは、元社長仁井谷正充の功績が大きいのではないだろうか。

ポチッとにゃ~」のシステムは素晴らしいし、「にょきにょき」も面白そうだし。裏付けを取るまでもなく間違いないだろう。

米光一成は仁井谷の功績を逆に横取りしてのさばっているイメージ

Twitterで呟いている内容も老害以外の何者でもないのに、何で偉そうにしているわけ?

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語概要
C言語高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++マニアック言語、高速、習得大変
Javaサーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C#主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl広く使われていたが今は若干時代遅れのスプリクト言語。汚い
PythonPerlにかわって主流になりつつあるスクリプト言語。綺麗
PHPWeb開発にフォーカスされたスクリプト言語一世を風靡した。
Rubyとても綺麗なスクリプト言語
JavaScriptブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Goサーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。

2016-06-21

バンバンショートカットキー操作してマルチディスプレイ環境作業してる自分客観視して、ふと思った。

こんなマニアック操作かいきなり初心者に全部覚えろって言っても無理だよなあ、と。

さらに翻って初心者ならどういう使い方をするんだろうと考えてみたら、案外とぬるい使い方でも設計的に懇切丁寧じゃないのかとも思った。

そこでなんでこんなに中級~上級ユーザーとの温度差があるのかと思ったら、使い方にそもそも差異があって、Windowsがその差を吸収してるからじゃないのか、という結論に至った。

ところがトラブルシューティングとか込み入ったところになると初心者の使い方では一生問題がわからない。

このあたりでWindowsバージョンは毎回糞と言い放つユーザーと、らくらく使いこなすユーザーが別れてしまう。

この問題はまんまUbuntuとかにも言えることで、デバイスが動かないならconfに記述するのが筋、と考えるユーザーと、LaunchPadからリポジトリ登録しないと太刀打ち出来ないユーザーに別れる。

もっと言えばコンパイルしろとかソース書けなんて言われてしまう。

こういう差異がありながら初心者上級者を吸収するWindowsは実はすごいんじゃないかと思った。長い。

2016-06-20

全てのCOBOLエンジニアはだいたい糞である

この記事を読んだ。

http://anond.hatelabo.jp/20160619185731

COBOLエンジニア、現Rubyエンジニアとして増田記事がどうしても許せなかったので反応してみる。

この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。

汎用系の現場でもRuby現場でも優秀な人はたくさんいたし。

今では信じられないほどの経験を当時(といっても2年前)はしていた。

改めて今、RubyというかRailsを始めてよかったなーと思う。

そこで僕が経験した糞だった現場をご紹介したい。

(もちろん業界特有ということもあると思うが)

インデントは定規で計る

いやー、これが一番ひどかったな。

まず静的デバッグ(机上デバッグ)といってコンペアファイルソースコードコンパイルログをそれぞれ紙出しして提出用(クライアント)、リーダー上司用の3部印刷する。

全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。

1セットあたり印刷に15分くらいかかったかな。

そしてインデントレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。

媒体のインデントをどうチェックするかって?

定規で計るんだよ。半角スペースが5ミリだったっけな。

それで5ミリずれてたら指摘するんだよ。目がつかれたよね。

っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。

ログを紙出ししてマーカー塗る専属社員がいた

これもびっくりだよね。

専属社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。

ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。

大卒の、しかも僕より先輩の社員たちだったな。

そんな人達サービス残業しているのを見て悲しくなったよね。

ネットは使えない。リファレンスは紙媒体(常に貸出中)

これはクライアント金融特有なんだと思う。

ネットは使えない。現場に入る時も持ち物チェックとかあるしな。

リファレンスは紙媒体だったよ。

でもセキュリティ観点からマスターの1冊のみ。

常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。

まだまだあるんだけど、これだけでもひどい現場だったなーって思う。

そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。

最後の方レビュー適当なって品質下がってバグ生んでたし。

Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。

それでも、やっぱりRubyのほうが未来があるよ。

この先もっともっとブラックボックスフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。

認めたくない気持ちはわかるけど、時代エンジニアも合わせていかなくちゃいけないんじゃないかな。

初心者プログラミング学習するのにおすすめ言語テーマ

初級(手続き型/構造プログラミングの基礎, データ構造, ファイル操作, イベントリブ方式GUI管理)

  • HSP で住所録を作る

中級(オブジェクト指向プログラミングの基礎, IDEの使い方, 名前空間, 疎結合, コンパイルしないと動かない)

  • C# で住所録を作る

上級(サーバ構築, DB設計, html/css, ネットワーク, 黒い画面, AWS, 日本語の壁, コンパイルしなくてもいいの!?)

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