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

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

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-10-05

おうちUbuntuRailsアプリケーション入れたい

なんだ今はredminedebパッケージあるじゃーん

そんな最新機能つきとかじゃなくていいんだからこれでいいよ

みんななんでそんな古式ゆかしくソースから/optにインストールとかしてんのよw Debian/Ubuntu野良コンパイルとかwww


↓(20時間後)


debで入れたやつ動かん…

いやコンソールからrakeすると動く…fastcgi…は諦めたんだ…nginxPassengerモジュールパーミッションはだからwww-dataにしてあるだろおおおがあああ

教訓:公式説明が遠回りなときはなにか理由がある。狂信者として生きていく根性がないのならネットで聞きかじりのポリシーは適宜曲げよう

2017-10-03

https://anond.hatelabo.jp/20171003170033

https://anond.hatelabo.jp/20171003165940 が既に言及しているけど、本家Artdinkで通販している。

こっちから入手するのが正規手法

https://eshop.artdink.co.jp/a_leg.html

ProjectEGGは合法かどうか判断はできない。Artdinkからの案内もないしな。

あと、D4エンタープライズ検索すれば、闇が色々見えるぞ。

コンパイル版権コンパイルハートに全譲渡したのに、まだ版権持ってる風に振舞う企業からな。

2017-09-21

仕事楽しい、これまで毎日出社するのが楽しくて仕方がなかった

退職時の挨拶で話していったやつがい

まじで信じられん

このクソみたいな状態にしたのはテメーが楽しんだせいかと思ってしま

こいつらの30年後に入社した俺達は仕事楽しいどころか人生も楽しくないし

まじで自殺したい

死んだほうが本当にマシだと感じている

責任感とか言うんじゃねー

テメーは責任感で仕事を続けていたのか?

俺は責任感で自殺しないで持ちこたえているのに

これ異常頑張れない

まじで無理

朝起きるのが楽しみだった?ふざけんな

こっちは仕事に追われて寝ている間も会計処理とかエクセル作業の夢とか報告書コンパイルしている夢を見てうなされて3時4時に目が冷めて

泣きそうになりながらなんとか出社しているのに

2017-08-02

知らない間にDebian9がリリースされてた

Dockerバズるくらいだから今どきハードウェア仮想化なんて流行らないのだろうが、Windows10 Proの安いPCを1つ購入してHyper-V有効化したのでCentOSUbuntuのどちらを入れようかと考えてた時に、昔インストールに苦労したDebian 3.1 Sargeのことを思い出して本家サイトに行ったら今年の6月Debian 9が正式リリースされたと聞いてすごく懐かしくなり、こいつを選択することにした。

随分バージョンが上がったものだなあ。しかも今はamd64インストーラーのリスト最初に上がってるし。昔は64は人柱用だったのに。

10年ほど前、玄人志向玄箱というNASOSDebianに入れ替えて単なるファイルサーバから用途サーバにするのが流行ったことがあった。今でも後継品のBuffaloNASDebian化する好事家は細々ながら活動しているが、UbuntuベースであるDebian最初に触れたのがその頃で、当時のバージョンは3.1、通称Sargeだった。タイミングのいいことに、Sarge対応の分厚いDebian入門書存在していたのでレファレンスには事欠かなかった。まあそれでも、スペックの貧弱な玄箱インストールして少しでもパフォーマンスをよくするにはカーネルを書き換えて再コンパイルしたりといった悪戦苦闘があったわけだがもう忘れた。

Hyper-V仮想マシンへのDebianインストールトラブルらしきトラブルもなく、インストールしてすぐに使えるようになっていてまあこれが普通だよなと。OSは使いこなしてなんぼで、インストールで苦労するのは不毛だと当時も思ったし。

あと、エンジニアが多いと聞いているはてな界隈でも個別ディストリトピックはあまり話題にならないんだなというのがちょっと面白かった。

2017-07-14

https://anond.hatelabo.jp/20170714184657

アセンブラ言語、という言い方があったとしても、アセンブラ言語のことを「アセンブラ」って呼ぶのは間違いで、アセンブラ言語ではないって訂正されるでしょ

コンパイラ言語コンパイル言語って言い方は普通に通じるけど、言語のことをコンパイラって呼んだら怒られるのと同じでしょ

ただ一時期アセンブリ言語のことを「アセンブラ」って呼んでて、途中でおかしいって指摘が入って、「アセンブリ言語」に統一されたんじゃないの

2017-07-10

Webアプリを作るときにどの言語/WAFで書くべきか

使ったことあるモノもないモノもごちゃまぜにして経験雰囲気で書いてる。

PHP

Laravelは結構好き。DSL過ぎず、それなりにフルスタック生産性もいい。

何よりLaravel本体ソースコードが読みやすいのがいい。

まともな日本語情報が少ないのは弱点だけど、気になったところは本体コードを読めばすぐに分かる。

最大の欠点PHPってことだ。他のLL言語に比べてPHP自体生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。

Perl

Mojolicious結構好き。これもDSL過ぎず分かりやすい。CPAN豊富ライブラリ群もある。

Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリ普通に読みやすいよ。

最大の欠点Perlってことだ。長期的に開発者を集めることを考えたら茨の道だろ?

Python

今でこそ機械学習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

SIerさんに敬礼

Scala

Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。

そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる?

コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリコードリーディングが出来るならいいんじゃないか

動作は早いし、言語のものは強力だ。

Scalaを好むプログラマ関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。

Node.js

非同期処理で開発することの難しさに耐えられるの?

ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコード保守する自信があるならいいんじゃない。俺はない。

Go

API単体ならともかく、画面も担う普通Webアプリを書くような言語じゃない。少なくとも今は。

正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットほとんどない。

ClojureとかElixirとか

運用実績ノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない

結論

完璧選択などない。

2017-06-27

学校の授業でプログラミングを教えるとしたら言語は何が良いのだろう

自分情報系の大学生

弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。

中学生の頃からパソコン大先生スクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。

ちなみに、試験は紙ベースで、手書きプログラミングをさせられる。つらい。

スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。

結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。

プログラミング学者である人は苦労して書き方を覚えていたように思う。

脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである

本来プログラミングは誰でも出来るはずである

今学期、PHPを書く授業とPythonを書く授業を履修してみた。

PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストコードを動かす気力のない自分にとっては最高の授業だ。

Pythonは、MeCabなどで形態素解析構文解析をする授業で、サンプルコード自分で考えてカスタマイズして毎回レポートで提出する。

Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。

やはり、スクリプト言語楽しい

書いたらすぐに目に見える成果が出るところが大きい。

自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。

そう思っていた矢先に事件が起こった。

最近研究室に入ったところ先生が手当たり次第Javaを教え始めたのである

せめてJavaScriptでいいかスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。

それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。

コンパイル言語も悪くはないと思い始めた。

ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。

絶対にツマラナイだろう。

自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。

こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。

お願いだからプログラミングを教えるのならツマラナイ授業をしないで欲しい。

生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。

別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。

自分は、分かりやすくて直感的なRubyというプログラミング言語学校の授業で採用されるべき言語に間違いないと思う。

別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。

CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。

スクリプト言語を教えた後に、コンパイル言語オブジェクト指向概念を教えていくのがいいのではないだろうか。

これは、あくまでもたった1人の大学生意見しか過ぎない。

みんなの意見を知りたい。

2017-05-25

何でjavascriptとして処理できない拡張書式のコードを「.js」で保存する

コンパイル前はjavascriptとしては動かないコード

コンパイル後はコンパイル前と同じ「.js拡張子

合理的理由って、なんかあるの?

2017-05-20

http://anond.hatelabo.jp/20170520004714

バカか。プログラムだってライセンスはっきりしてないコード仕事では使えないわ。

画像と違って、コンパイルして実行コードだけ公開されると、ソースコードをコピったかどうか確認が難しいってだけだろう。

2017-04-30

http://anond.hatelabo.jp/20170430173449

それはどのレベル文法のことを言っているのか。

文法が正しいだけではコンパイルは通らない。

コンパイルが通った。

おめでとう。

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-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

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

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

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

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

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

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

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

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

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

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん