「java」を含む日記 RSS

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

2017-03-27

http://anond.hatelabo.jp/20170327161234

オブジェクト指向言語であることとstaticおじさんが発生しうる余地についてはほとんど関係がないと思うが。

どんな言語でもstaticおじさんは出現しうるし、逆にどんな言語でもオブジェクト言語ナイズドすることは可能やし。

つうか今時「オブジェクト指向言語」みたいなくくりの言語存在せえへんぞ。

RubyだってJavaだってPHPだって関数型っぽく書くことが可能やで。

それはオブジェクト指向言語を使ってるからでしょ

そういう意味ではJavaなのにstaticばかり使うおじさんは、やっぱり馬鹿にされてしまうか

2017-03-19

http://anond.hatelabo.jp/20170319132149

日本のお役所PDF大好きなのは、知っている。霞ヶ関から吐き出される有効資料は、ほぼpdf

一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。

今、株価が上昇しているIT企業様は、PDFhtmlとを比べるような使い方はしていないのでは?

世界は、IT企業htmlPDFとを比べたらどちらを重用しているのか?

  

googlejava script 推しのJQueryを良く使ってるし、これからは、人工知能時代からxml形式とか、マークアップ言語は、良く出てくると思うよ。

Facebookphpなんでしょう?リア充御用達で、Twitterよりも株価資本も安定している。

これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。

オープンソースでもGit hubみたいなツールが使われているんだし。。  

そう言えば、perlcgiは、ほぼお亡くなりになりましたね。

2017-03-13

Javaスクリプト停止させたら、ノートPC電池時間上長持ちになった

省電力モードで、背景16bit設定のときの話な。


糞重たいから止めるだけで、数秒の時短になるし、アフィ広告表示されないし、電池持つし。

なんのためにHavaNicedayもといJavaScript存在するのさ?

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

毒親持ちのシステムエンジニアSC合格するまで

こんにちは

私(♀)は今、北日本のどこかにある某システム会社システムエンジニアをしています

20歳就職し、今年で5年目になります

小さいときからパソコン電子工作が好きで、高校卒業後は情報系の専門学校入学しました。

飛びぬけて優秀というわけではありませんが、進学の推薦に困らない程度の成績は維持していました。

卒業がせまったときに進学か就職かを決めることになりました。

私子ちゃんの成績なら進学なんでしょう?」「私子は進学のほうが向いてるよ」と周りからは言われました。

私も進学したいという気持ちがありました。

親に相談したところ、母は「ダメとは言わない。進学するなら奨学金を借りてほしい」と言いました。

父は「四大を卒業した女はすぐに結婚して辞めると思われる。四大なんて女が行くところじゃない」と言いました。

父が言うならそうなのだろうと思いました。

奨学金を背負うだけの覚悟もなかったので、就職を選びました。

今のシステム会社入社し、同期の1人と一緒に運用系の部署に配属されました。

学生時代はCやJavaの基本について学んではいましたが、その部署ではプログラミングをすることはほとんどありませんでした。

代わりにLinux,TCP/IP,ネットワーク構築の技術が求められました。

LinuxTCP/IP,ネットワーク構築は初めて見る知識で先輩が教えてくれる業務をこなすの必死でした。

一緒に配属された同期は性格の明るさと器用さでどんどん仕事を覚えていき、私と差がついていくのがわかりました。

のし我が家

同期と差がつけられるのが悔しかった私は、勉強をはじめました。

とりあえず応用情報(AP)を取得しようと思いました。

基本情報学生時代に取得済み)

そのころ、我が家祖母介護めぐりよく父と母がけんかしていました。

母が「殺せ!殺せ!私を殺せ!」とはさみを持ってよく叫んでいました。

私と弟が母親をよく羽交い絞めにして止めました。

祖母は、父に対しかなりの毒親っぷりを発揮&クソトメであったため、介護も大変だったようです。

家族喧嘩を見つけたら止めなくてはいけなかったので、

喧嘩を見なければいいと思った私はよく図書館勉強していました。

その秋のAPは落ちました。

パワハラおばさんとの出会い

配属されて1年ほどたったころ、私はある女性40代、既婚)の下で働くことになりました。

ほぼ男性部署で、私が入社する前は部署唯一の女性でした。

以下おばさんと呼ぶことにします。

「なぜわからないの?」「かんがえたの?」「もう1回調べて」とよく言われたので、言うとおりにしました。

厳しいなぁと思いましたが、私の成長を思ってしてくれているのだと思いました。

自分なりにがんばってみるものの、つき返される日々がつづきました。

そのうちに、夜眠れなくなりました。

おでこにきびで埋め尽くされました。

出社前に嘔吐するのが日常になりました。

毎日倦怠感がありました。

仕事 がんばる 方法」「仕事 落ち込み 立ち直る」でぐぐることが多くなりました。

いろんなにきび治療方法を試したので、にきび治療に詳しくなりました。

元気出す系のドーピングアイテムにも詳しくなりました。(レッドブルからプラセンタまで)

ある日、おばさんが言いました。

あなたを見てるとイライラするのよ。あなたの成長なんて知ったこっちゃないのよ。さっさとやってよ。」

その後、うつ病と診断され、1ヶ月会社休みました。

うつ病になってから

我が家うつ病理解があるとは言いがたい家庭です。

土日出勤・給料未払いというブラック企業勤めの弟が居たので、相対的ホワイト企業勤めの私がうつ病、ちゃんちゃらおかしかったのでしょう。

夕食のときに、父が「会社を休むのなら学校にでも行け」といいました。

私はおもわず泣きました。

「飯がまずくなる」と父にしかられたため、自分の部屋で食べました。

休んでいる間の家族の目がつらかったので、1ヶ月で仕事に復帰しました。

「つらかったら半日で帰ってもいいんだよ」と上司男性、おばさんとは別人)に言われましたが、家に帰ってもろくなことがないので、定時まではたらきました。

そんな中、弟が交通事故で重傷を負いました。

弟は障害者手帳を持つようになりました。

弟の日常生活を、家族サポートするようになりました。

ある日、私が自分と弟の夜ご飯を作るよう言われていましたが

用事があり作りませんでした。

弟は帰るなり私を殴り、「なぜ俺の飯がないんだ」と叫びました。

さすがに理不尽だと思い親に訴えました。

母は「あの子やかんみたいな子だからね。すぐに沸騰するのよ」といいました。

その後親から弟にお叱りがあったようです。

弟は私に会うたびににらむようになりました。

親に言いつけたことへの報復が怖くて、夜は自分の部屋の扉に、机やいすでバリケードを作って寝ました。

一人暮らしをはじめる

APは5回ぐらい落ちました。

親の怒号や弟の報復におびえることな勉強できる場所がほしいと思いました。

実家暮らしで、うつ病趣味もなくなっていたので、お金はありました。

親は、一人暮らしをすることについては何も言いませんでした。

引っ越したのは大通り沿いの木造アパートでした。

隣の部屋のおじさんの声、車の音がうるさかったですが、親の怒号や弟におびえた日々に比べたら天国でした。

好きな時間にご飯が食べられる。

好きな時間勉強ができる。

好きな時間に帰ってこられる。

家事料理も楽しくて苦になりませんでした。

引っ越しからAPに受かりました。

調子に乗ってSCも受けたら、受かりました。

以上です。

2017-03-05

birudoおわんねえええええ

top - 13:40:50 up 207 days, 19:02,  3 users,  load average: 3.22, 2.62, 2.45
Tasks: 299 total,   2 running, 297 sleeping,   0 stopped,   0 zombie
%Cpu(s): 33.7 us,  6.0 sy,  0.4 ni, 59.0 id,  0.5 wa,  0.0 hi,  0.5 si,  0.0 st
KiB Mem:   3972236 total,  3752196 used,   220040 free,   312220 buffers
KiB Swap:  4116476 total,  2114100 used,  2002376 free.   640840 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
15297 chimpo    20   0 3453328 1.120g  20964 S 167.6 29.6 340:03.02 java        
 9130 chimpo    20   0 1610872  54064  20628 S   6.0  1.4 129:22.78 compiz      
16283 chimpo    20   0   30236   3032   2440 R   6.0  0.1   0:00.02 top         
18916 chimpo    20   0 1247204 163832  59420 S   6.0  4.1  63:20.63 chrome      
    1 root      20   0   37344   2284    972 S   0.0  0.1   0:11.30 init        
    2 root      20   0       0      0      0 S   0.0  0.0   0:22.08 kthreadd    
    3 root      20   0       0      0      0 S   0.0  0.0   2:17.54 ksoftirqd/0 
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+ 
    7 root      20   0       0      0      0 R   0.0  0.0   9:53.66 rcu_sched   
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh      
    9 root      20   0       0      0      0 S   0.0  0.0   5:27.98 rcuos/0     
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/0     
   11 root      rt   0       0      0      0 S   0.0  0.0   0:01.48 migration/0 
   12 root      rt   0       0      0      0 S   0.0  0.0   0:03.20 watchdog/0  
   13 root      rt   0       0      0      0 S   0.0  0.0   0:03.57 watchdog/1  
   14 root      rt   0       0      0      0 S   0.0  0.0   0:01.48 migration/1 
   15 root      20   0       0      0      0 S   0.0  0.0   0:40.06 ksoftirqd/1 

2017-03-01

Macでまともな2chブラウザ

ないの?

今はV2Cの改造版使ってるけど、絵文字がちゃんと出ないのとJavaベースで重いのとで捨てたい

バチスカーフはタブ未対応の時点で論外

検索しても古い情報ばかりだから増田集合知に期待

2017-02-26

http://anond.hatelabo.jp/20170226153940

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

http://anond.hatelabo.jp/20170221234633

RoRはそんなにおちんぎん高くないし案件も無いぞ。Pythonも同様。バックエンド言語は今のところPHP/Javaの二択やで。

PHPできるおじさんはJavaも大体できるから、そっから先は本当に好みやな。

あえてJavaScriptなのはフロントサーバー需要が高まってるからあえて特化してみるとおじさんパワー(加齢臭)が高まるかな? と思ってのことだ。

実際、サーバフロントを一つの言語にまとめたいっていう需要結構ある。

中古ドメイン販売サイトで売れた中古ドメインについて調べてみた

中古ドメイン販売しているサイトの中でも一番有名なところで

購入された中古ドメイン調査してみましたので紹介します。

アフィリエイトサイト作成SEO対策の参考にどうぞ。



zpicturegroup.com

1-gp.com

1energyportal.net

20-shishakai.com

2123moments.com

26546000.tv

33fclothing.com

3enhancedesigners.com

3x-broussaille.com

43biciclettedilusso.com

48condorcet.com

4wallsandaview.com

5a10parjour.com

7factory-design.com

7inchpunk.com

81books.jp

87mizuki.com

a-homeplan.com

aaronlouisfowler.com

abbysunderland.com

abili.net

abrampineda.com

accessonthepalouse.org

ace-collective.com

aciphx.org

actionspf311.org

actiontunisienne.com

activeo2japan.jp

adaasia2015.org

adachi-noumachi.com

addys-rdu.org

adehgua.org

ads-hair.com

advantagecareer.jp

aed-hm.org

afase.org

afclafontaine.org

affirmativeholdings.com

aftarkeia.org

againmystery.com

agcolares.org

ageing-in-europe.org

ageiowa.org

agenziaimpronta.net

agribusiness-nl-srb.com

agrupacioncinematograficagalega.com

aifuresort.com

aikotoba-sasebo.com

aikuiskasvatuksenkilta.com

aionstuff.com

airpur.org

ajedrezvillamontes.com

akashi149.com

akelarre-hendaia.com

akiba-clinic.com

alannamariemusic.com

aldoukan.com

aldstore.org

aliensview.com

alilapelicula.com

allornothingproductions.com

allydurr.com

alpinale.net

alternativekei.com

amcis2010.org

amepeba.org

ami-10.org

anandjon.com

andrehouseaz.org

andrewsafbhotel.com

androkles.com

animalalliancepa.org

animepapers.net

anje1001.com

ankarakomedifestivali.com

anunciarmiempresa.com

anzonenergy.com

aocmaps.com

apaa2013.com

apachevasion.com

apf691.com

apfgifted.org

apsa6001.org

aqlpadepuis30ans.com

aquarian-ac.net

arahiroko.com

araidsfoundation.org

aramaraphoto.com

arkivradet.org

arktodd.com

armadahotel-petalingjaya.com

armchairsailorseattle.com

aroma-erotica.com

aroma-relaxy.net

art-translation.org

artandprintdesigns.com

artandspiritmixology.com

artgonia.com

articultores.net

aseandrr.net

ashera-aoyama.com

asianfilmawards.org

askmontana.org

aslumsymphony.com

aso-java.com

association-tamany.com

astral-japan.com

atelier-fantastique.com

atelier-fukuoka.com

atelier-heroina.com

atletismoenlarioja.com

atoopix.com

atreegrowsmusicgroup.com

auberge-trinquet.com

audrey2123.com

aurora-nikko.jp

avesopajaros.com

awelinternational.com

azpcgallery.com

azyoga.net

babelfusion.com

baboinvasion.com

bancodealimentosdearagon.org

bandamusicaalozaina.com

baqueroarquitectos.com

barbermouse.com

barnas-landskap.org

barrhavenfoodcupboard.com

barryintnl.com

barselene.com

baseballem2013.ch

batantek.com

batwa.org

agribusiness-nl-srb.com

aldstore.org

artandspiritmixology.com

onedirectioncdf.com

menuiseriemontout.com

providencepizzaco.com

renover-economiser.com

sakaue-taizou.com

nyotahome.com

portauthoritypolice.org

omappedia.com

projectkarinu.org

mb-kobe.com

mieito.com

soan-officiel.com

shot-travel.com

radionovasertaneja.com

onlybyskate2.com

tw-technowave.com

tankichi.net

relaxhana.com

sencolle-anime.com

musik-und-kunst.net

sylvie-schambill.com

uniathegame.com

mb-autotechnik.com

hippiesreadtoo.com

okikan.jp

biosinav.com

shiftexperience.com

actisku.com

apefalmeria.com

baldwincountynow.com

bonustcm.com

caradaviswrites.com

dkrepublic.com

ecoshift-kouji.org

mammothcaverecording.com

sombriohappenings.com

spiralla.info

madprideto.com

bhrplc.com

casasanclaver.com

evocativepop.com

leituraglobal.com

avaf.info

clonmelswimmingclub.com

doughertyspub.com

fleursdemarie.ch

gdesignbg.com

jp-angel.info

ritterjon.com

siberut-island.org

so-tm.com

stokescleveland.org

winery51.com

affiliatedacos.org

bradyvanv.com

cataplexic.com

davidrleitch.org

donamisport.org

dresscirclesounds.com

et-kingdom.com

firstagcr.org

freshlysqueezeddesigns.net

garimpochic.com

gitearnoult.com

glisc.info

haiart.org

kathyslamen.com

kobekina.com

lync-social.com

mdmorrissey.info

notundoom.com

nwjsa.org

pacornish.org

pgindia.net

philfiles.com

reservasaragon.com

sirsedricmusic.com

vintage-house.jp

weareaftermidnight.com

yoshidaakira.net

blog-moving.com

aarton100.com

ac88kor.com

alps-sizendo.com

artbyrox.com

classroomsacrosscultures.org

kagawa-all.com

oclockpub.com

senpu-ki.jp

vinopararobar.com

2017-02-10

ツールが人を馬鹿にする

まあみろと思う。

「便利なツールによって人は馬鹿になった」とは、上司の口癖のひとつである

だが厳密にいうとこれは間違いだ。

便利なツール人間を均しているのだ。つまり馬鹿になっているのは、あたまのいい連中だけだ。ははは。ざまーみろ。

テラタームの普及により、新人からtelnet概念が掴めなくなった。

ffftpばっか使うからftpすらままならない。

環境変数存在するからjavaバージョンも変更できねえ。

みんなそうなんだ。ははははは。ざあまあみろ。ははははは。

かつて、コマンドとかカレントディレクトリとか、エンジニア界の絶対的概念理解できず躓いて、頭が悪い認識されたやつ

そんなやつが、それを明らかにせず、あたまのいいやつと同等のパフォーマンスを上げられる時代になったんだ。

そうして自分馬鹿であることに自覚がないやつは、ある程度の時期で気づく。浅い。考える力がない。

そして、できないやつとレッテルはっていた、自分バカにしてきた、

作業の遅いやつが、一番だいじな「思考力」をもってるのだと気づく。

便利な道具うんぬんじゃなくて、

それは経過にちょっと影響を与えるだけで、

本質はなにもかわってないんじゃないかなって、

わたしは思います

どう思いますか。上司さん。

http://anond.hatelabo.jp/20170210130932

Java書いているならいくらでもチャンスはある

他の増田も言っているとおり環境立ち上げてチュートリアルをやってみればいい

それすらしたくないなら知らん、SIerのままでも死ぬだけだ

焦って転職するより今の環境から勉強して少しでもアウトプットを出せたらより良い条件ですぐ転職できると思う

http://anond.hatelabo.jp/20170210130822

ああ、まあそれ未経験じゃねーから

Javaプログラミング工程管理ができる経験者として応募していいよ。

まあ1人でMySQLRailsPHP(Laravel)の環境ぐらいは作れたほうがいいけど。

2017-02-09

http://anond.hatelabo.jp/20170209002119

うーん、行間からいろんなものが漂ってくるな。

>在学中はC言語からプログラミングを学んだのだが理解できずJavaもまったく理解できない状態に陥った。

相談した講師からネットワーク関係DB関係知識を深めれば就職のあてはあると言われてCiscoCCNAとか

オラクルDB資格とかLinuxLPICまで取ってたのだが学歴の壁に苦戦。

専門学校に行っても全く理解できないってことは、素養が無かったんだろう。

あと、IT場合学歴あん関係なくて(DeNAみたいなところは除く)、結果的高学歴ハイスペック人材が成果を出しているだけなんだよね。資格も実際に使えないんじゃペーパー免許と一緒。

SE肩書倉庫での作業がメインでパソコンに触れるのが在庫管理表を更新する週に1回か2回ほどだった。

テスターとかコーダーとか底辺人材ですら人手不足のこのご時世に、そんな仕事を振られるってことはよっぽど使い物にならなかったんだろう。

会社あんたを雇ったときいくらなんでも専門学校まで出ているんだから、最低限使えるだろ」っておもったら、研修の段階で想定以上に使えなくて誰も行きたがらない現場に回したんだろう。

うちの職場にも、あなたみたいな人が高ギャラのエンジニアバーター派遣されてきているけど、そいつ教育管理する工数のせいで高ギャラエンジニアパフォーマンスが下がっている。

悪いことは言わない。他の業界に行ったほうがいい。SIerにしがみついたところで、あなた派遣先派遣元も誰も得しない。

会社辞めた

情報系の専門を卒業就職してから2年、辞めた

在学中はC言語からプログラミングを学んだのだが理解できずJavaもまったく理解できない状態に陥った。

相談した講師からネットワーク関係DB関係知識を深めれば就職のあてはあると言われてCiscoCCNAとか

オラクルDB資格とかLinuxLPICまで取ってたのだが学歴の壁に苦戦。

 

何とか特定派遣会社就職できたが就職してから2年間は酷かった・・・

インフラエンジニアが足りないから是非うちにと言う事でその会社就職を決めたのだが1ヶ月の研修後、派遣先が見つからないと言う理由で急きょ運用現場半年派遣された

SE肩書倉庫での作業がメインでパソコンに触れるのが在庫管理表を更新する週に1回か2回ほどだった。次に1年ほど派遣された保守現場では保守サポートが行われている現場

日替わり2交代制の24時間365日体制現場責任者シフト作成社員の都合は一切聞かない)を行い2日以上休むのは禁止と口頭で注意された。

そんな感じで働いていたが精神と体に限界が来て会社営業に「現場を変えて欲しい」と訴えると契約終了後、社内待機になった。

社内待機の間は打ち合わせと称した会議管理職5人と営業2人がいかに僕が会社負担になっているか昏々と説明したのち転職を勧める事が続いた。

僕に転職を進める理由営業は、派遣する現場がないのと業務経験評価できるようなものではないからと説明した。

さすがに憤りを感じたため反論したが「でもお前、大した経験できてねーじゃん。そんな技術者はうちにいらないよ。」と言いい聞いてくれなかった。

社内待機になって半年後、退職届会社に出した。

 

退職届を出したのちに、ハロワに行き僕がいた会社実態を話して「あの酷い会社制裁を加える事ができないのか」と聞いてみたら

「グレーでも法律違反していない以上はどうすることもできません。」

と言われたため不満を持ちつつ納得するしかなかった。

自分なりに2年間頑張ったのに評価されるどころかバカにされて実質的にクビになったのが惨めだった。

 

転職を勧められるまでは会社を信用していたが今、考えてみれば初めから都合よく捨て駒的な使われ方をされた思う。

派遣先がない事を理由に大した経験の出来ない現場新卒派遣して以降は適当現場派遣して派遣できなくなったり不満を言い出したら追い出す。

実にいいように利用されたものだ、会社を信用していた自分が恥ずかしい。

 

インフラエンジニア希望して入社したのにインフラに一切触れることはなかった。

希望職種に就くのがこんなに大変だとは思わなかった、IT業界は本当に人手不足なのだろうか・・・

しばらくしたら転職活動を始めようと考えているが僕は本当にインフラエンジニアIT業界を目指すべきなのか悩んでいる。

2017-01-29

Ruby on Rails違法サイト構築言語と化した

キュレーション騒動問題になった企業求人サイトを見ると、開発環境Ruby on Railsであるケースが多い、というかそれしか見たことない。

DeNAもそうだし、トリッピースも、Speeeも、あれも、これも。

この手のevil企業Java.net系の言語募集がかかっているのは見たことがない。

Ruby違法サイト構築言語と化してしまった。違法なことに手を染めたくなければ、Ruby以外の言語を身に着け、Ruby求人を出していない企業に行くべきである

2017-01-28

C言語Go言語Java言語COBOL言語HTML言語JavaScript言語

ジャパニーズ語」とか「イングリッシュ語」とか書いたら絶対受け入れられないと思うけど「C言語おかしい」みたいな事を言ったら、めちゃくちゃ叩かれるんだよな。

http://anond.hatelabo.jp/20170128085025

理想を言えばmac,iphone, windows, androidを一通りそろえることだけど、

とりあえず始めるにあたってはいずれか一つあればいい。

サーバvpsを借りるか、自宅サーバ(linux)。独自ドメインもとってみると面白いと思う。

言語phpとかの方がいいんじゃね。javaめんどい



webサービスネタがないならはてブ(ソーシャルブックマーク)を作るのが王道

サーバサイドスクリプトDB基本的連携体験できる。

2017-01-25

マイナポータルJava必須案件

なぜマイナポータルJava必須なのか、開発者側の理屈ユーザー体験おざなり

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

に、はてブコメント付けてる奴、ど素人過ぎてお話にならない。

Javaスタンドアローンアプリ作れとか正気かよ。

まともな代替案を考えることもできないのに口出しするな。

あ、それだからはてブあたりで毒吐くくらいしかできないのか。

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でミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

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