「ドキュメント」を含む日記 RSS

はてなキーワード: ドキュメントとは

2017-04-21

Mastodonインスタンス自力インスコできるだけで羨ましい

改造目的じゃなければRubyからフロントエンド知識なくても問題ないと思うが、大してドキュメント揃ってない中、ものの数時間で公開しちゃう人たちが大勢いるみたいだからすごいなって普通に思う。

少なくともこれだけの知識必要なんでしょ。すごいよ。

http://anond.hatelabo.jp/20170309040708

日本エンジニアクズだが、書き手も目くそ鼻くそほどにバカだ。

海外エンジニアをしているが、Dockerを使ってない会社はこの数年、見たことがない。

開発環境だけで使っている会社もみたことがない。それじゃDockerメリットが何もない。

日本大丈夫か?

シェルや手順書のメンテナンスと変わらないだと?変わらない程度の環境構築しかできないやつがわかったようなことをいうな。

Dockerドキュメントを読み直せ。お前含め日本エンジニアはくずだ。

2017-04-19

PTA委員会にいってきたよ

昨日、今年初めてのPTA委員会があって、年間スケジュール確認とかイベント担当とかが割り振られた後に、委員長からいろんなドキュメントフォーマットが入ったUSBメモリーを見せられて「あとでこのUSBをみなさんに回すから自分ののPCコピーしておいてください」とか言われた。USB手渡しで回すとか超面倒だしウィルス感染でもしてたらどうすんだよ、せめてドロップボックスとかGoogle docとかでURL共有すれば一瞬なのにな~、とか思ってたら甘かった。


「すいません、家にパソコンないんですけど・・・」「パソコン全然さわったことなくて・・・」「USBって何だっけ・・?」「エクセル?知ってる!パソコンでカチャカチャやるのだよね?」って・・、いまって90年代状態。むしろ日ごろからPCやってる私がマイノリティー。


この人たちってPC無しどうやって報告書とか作るんだろう、数値入れ替えだけで済むような資料作成手書きゼロから書くつもりなのかな?

2017-04-18

1対1の強姦レイプAVは抜けるけど、多人数による輪姦AVが抜けない

特に中出しモノ。

輪姦は余計な事をし過ぎる。

あとカメラ映りが悪い。

1対1だとその辺が上手く表現されやすいけど、メーカーモノのAV特に撮影表現の未熟な輪姦モノが大半を占めていて駄目だ。

レイプにも種類はあるけど、やっぱり一番良いのは誰もいなさそうな所で襲う典型的な奴と〇〇業者を装って部屋に侵入する系、父親が娘を母親がいるのに隙を見て犯す系が良い。

輪姦モノは何が駄目って多人数だからそれぞれ見せ場を作りがちでいたいけな演技をする女優とそりが合ってない感じがある。

そしてただガン突きするだけで休む暇もない。

この辺は特に下手に感じる。

いや厳密にいうとレイプ男優が下手な方が映える。

上手い場合、突き方にやたら扇情的になりがちだし、甘い台詞を吐いて、そのせいでこれはレイプ物語なんだと決め付けて現実に引き戻される。

つの物語性が強く残るのが1対1の面白い所であり、逆に多人数だと物語性が一気に希薄になって駄目だ。

ねっとりじっくり犯して完堕ちさせる流れもアリだが、逆に最後まで抵抗する・嫌がる方がよっぽど抜ける。

妊娠・孕ませという男の願望に従った作風なら最高。

中出ししてもピルがあるから大丈夫みたいな言い聞かせ系はクソ。

輪姦モノは特にそんな感じがある。

オプションとしては、偽物でも最後妊婦姿になってる風な描写が望ましい。

AVはその性質上本物の赤ん坊を抱いた姿は見せられないので、せめて産婦人科に通ってる風な演出最後を締め括ってくれれば

レイプ物としては最高の出来だと思う。

出来れば一発で終わらせず何度も中出しする感じが良い。

監禁モノは一回出したら後は多人数かコスプレH、外出しに変化しちゃうのでクソ。

未だに監禁系は抜ける奴がないのが残念だ。

レイプもこれという作品2014年を機に減っている。

いわばジャニーズありきのドラマを見せられている感じ。

女優ありきなのでだから抜けないのかもしれない。

そういう意味では上原亜衣の強姦ドキュメント最初の方は非常に良かった。直ぐ輪姦に代わるから使い勝手は最悪だが。

あいうのはもっと色んな女優でやって欲しいものだ。

2017-04-15

webkitRequestFileSystemのリファレンスってどこにあんの?

サンプルじゃなくて、公式ドキュメントが欲しいんだが?

2017-04-08

http://anond.hatelabo.jp/20170408224500

さてはNHKドキュメント見てたな…。

パンダ可愛かったよな、パンダ

良浜も、永明も結浜も可愛かったな。

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

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

2017-04-03

オンラインストレージ比較

どのオンラインストレージでも有料プランは容量も料金も似たようなもの

でも、若干違いがあるので記載しておく。

オンラインストレージ選択の参考になれば幸いだ。



Onedrive

有料プラン1TBからオフィス無料でついてくるのがありがたすぎる。しか金額は他のストレージとあまり変わらない。特にこだわりがなければOnedriveが最強。

欠点としては、アップロード時に通信速度が遅くなりすぎる。ネットしてるとイライラしてくる。

Dropboxアップロード速度がOnedriveと同じくらいなのに遅くならないんだが。

あと、変なものをアップして垢バンくらったらどうしようかと不安になることもある(マイクロソフトアカウントバンされたらかなり痛い)。



Dropbox

以前は同期が速いのがよかったが、最近は他のストレージも速くなったのであまり変わらない。

Onedriveと違ってバンされても痛くない。

ギャラクシーを使ってると、50GBのストレージ無料付与される。



Boxsync

基本的Dropboxと変わらない。有料プランガッツリ使ってるわけでなく細々としたものしか使ってないが、体感として同期速度は良い。



Googleドライブ

使ってない。

これもバンされたら怖い。Google+子供の水浴び写真を載せててバンされたという話もあるので、使う気になれない。



Amazon Drive

写真の容量無制限が嬉しいところだが、これもバンが怖い。子供が裸で遊んでる写真とか怖くてアップできない。

本の自炊をしているので元データバックアップとして使いたいが、大量すぎるのでアマゾンからクレームがきそうで使えない。

とにかく変なことしてバンされたくない。



SugerSync

フォルダ自体を同期できるのはSugerSyncくらいか

通常はDropboxやOnedriveというフォルダができて、そこにデータを放り込むが、SugerSync適当フォルダを同期できる。

何かしらのソフトデータとかでマイドキュメントしかおけないフォルダを同期するのに便利。

問題は有料プランレベルの大容量になるとまともに同期しない。いつまで経っても同期が終わらない、というか進まない。

2,3日放っておいたり、何回か同期を解除してやり直したりしたが、同期ができなかった。

2,3年前の話なので現在改善されてるかもしれない。

現在無料プランがなく、有料プランは他のストレージより高い。

容量10GB程度で安いプランを作ってほしいところ。



いろいろ使ってるんだが、こんなところか。

最近は外部のHDDフォルダが作れるからデスクトップに8TB HDDとか装備してやると複数ストレージを使い倒せる。

あとは、なんかの拍子に同期に失敗して全データが消えることもあるかもしれないから、バックアップは定期的にしてる。



しかしたら情報が古くて間違ってるところもあるかもしれない。

違ってたら修正求む。

2017-03-30

WebエンジニアWordPressめんどくせー」

htmlファイル置いて公開していた時代があって結局莫大なファイル管理かいちいちFTP使ってってのが面倒ってことでWordPressをはじめとするCMSが扱われたみたいだけど

(ごめんここは知らんから適当に言ってる)

今だとWordPressの内部構造が弄り辛いって理由ゴミ扱いされて静的サイトジェネレーターがWebエンジニアの間で人気になってるじゃん?

にも関わらず、結局クライアント相手には静的サイトジェネレーターが向かないとかなんとかいってWordPress使ってるみたいじゃん。

いや、なんでそこ改善しないの。WordPress以外にもそういう選択肢があることを言えばいいじゃん。

クライアントにとってはちょっと使いにくくても従来の静的ファイルを利用したサイト構築の方が楽だろう?違うの?

それこそ今WordPressなんてドキュメント豊富クライアント勉強すれば弄れるんだから

静的サイトジェネレーターみたいなドキュメントが多くない所を商売道具にしていけよって思うんですけど、どうなんだろう。

2017-03-29

http://anond.hatelabo.jp/20170329160218

嫌がらせだよやっぱり。

パスワードだのタイマーだのは

「変更しないでください」「この日以降は不具合が出るので使用しないでください」

ってドキュメントに残せばいいだけの話。

お前以上の技術者採用されてきて、改良するかもしれないんだから

2017-03-18

http://anond.hatelabo.jp/20170318175606

ドキュメント作成Wordを利用しろって言うのだけれども、Word利用者想像に反して意外と難しかったり、直感的でなかったり、

この程度のことをやりたいだけなのになぜかできない(わからない)とかっていうことが多すぎる。

既存表計算ともワープロとも異なるコンセプトの何かが必要なのでは。

SVN

弊社はWeb系の受託会社

結構大きい企業から仕事をもらっているし、

技術力がある社員も多い(と上の人たちは言っている)

そんな弊社では以下のようにSVNを使いこなしている

1. SVN + ファイル名日付管理

弊社では正統派Web受託会社なので、

Excelドキュメント作成することがメイン業務といっても差し支えないがない。

案件によっては設計書にif文やfor文まで全て書き込む。

Excelさえできれば誰でも実装ができるようにだ。

それらのドキュメントSVN管理するのだが(今流行りのバージョン管理だ)

その際に hogehoge設計書_20170313.xlsx のように日付をファイル名に含めることになっている。

こうすることで以前のファイルを別ウインドウで開きながら作業できるし、

ディレクトリを見たときにひと目で最新のファイルがどれかわかるからだ。

ちなみにドキュメントには必ず 「更新履歴」 というシートが作成され

全ての変更の履歴はこのシートに集約される。

入社したばっかでまだ何もわかっていなかった頃先輩に

ファイル名に日付をつけて管理していますがそれってSVN使う意味あるんでしょうか?」

と尋ねたことがある。

答えはその日一日不機嫌な先輩の表情で察した。

あの頃に比べて僕も成長した。

今では何も考えずに hogehoge設計書_20170313_2.xlsxコミットできる。

未だにファイル名日付管理意味がわかっていないが、

このまま成長すればいつかきっとその意味もわかるだろう。

2. SVNが本当に最新か常に疑う

SVN作業していると他の作業者編集しているファイル名が被ってしまうことがある。

そのため作業時にはチャットで 「今から◯◯のファイルを触ります大丈夫でしょうか?」 と聞くことになっている。

作業終了時には 「◯◯を触ってコミットいたしました!」 と報告することになっている。

先輩方は忙しいため上記の確認/報告をしないことが多々ある。

そのときは 「SVNが最新かどうか常に疑え」と教わった

しかに実際最新じゃないことがよくあるのでなるほどと思った

今では作業前にコミットログを見てコミットされていないことを確認してから

「このファイル触っていましたよね?コミット済みでしょうか?」 と確認するようにしている

コミットしていないと決めつけるのは失礼なので、

飽くまでふんわりとコミットたかどうかを確認するのがコツだ(これも成長した結果だ)

場合によっては

「僕がコミットしておきましょうか?」

と付け加える。

こうすることで最新版ファイルメールで送られてるくるシステムだ。

今日Excelを開いてSVNコミットするお仕事をした

ちなみに僕の肩書

PG(プログラマー)」

だ。

2017-03-12

http://anond.hatelabo.jp/20170312191036

アプリ開発をするのに必要なSDKのドキュメント英語で書かれていることが多いですし、

外注業者ベトナムインドで彼らとの共通語英語だったりするんですわ。



完全に国内に閉じている会社ならほとんど不要です。

私自身も英語が話せなくて困ったことは無いデス。

2017-03-07

自分がした苦労と同等の苦労をひとに強いるやつの脳みそは何色だ。

あなたがこの仕事を覚えた時、

しかしたらあなた指導した人は

「違う」とか「前の仕事を見れば分かるだろ」とかしか言わなかったかもしれない。

具体的なやり方を教えてもらえなかったかもしれない。

その中であなたは苦労して仕事を身につけたのかもしれない。

であれば

なぜその馬鹿げた苦労をもう一度ひとに強いるのだろうか。

頭で覚えるには膨大すぎるルールがあるこの仕事(※量が多いだけで複雑ではない仕事)で

ドキュメントも作らずに

自分けがわかった状態であることに対して

優越感でも味わいたかったのだろうか。

僕は明日

申し訳ございません。もう一度具体的に説明をしていただけないでしょうか」と記されたメール

何度も何度も、送る。

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

カルドセプト乱数問題

当時ドヤ顔で、標準関数rand()を使ってるからって指摘してる連中多かったな。

大昔に書かれたC FAQってドキュメントに、rand()は質が悪いって書かれてる影響でだろう。

でもカルドセプト事件が起きたときにはすでに21世紀でそんなrand()の質の悪い処理系なんてなかったはず。

しろrand()を使わずに、自作たから失敗したんだろ。

あとだいぶ前に2chプログラム板を見てたけど、初心者乱数関係質問をするたびに、乱数の質が悪いから加工して使えとか、メルセンヌ云々でとか言う連中が常駐してたな。

でもその初心者に教えてる乱数を加工するコードバグってたりするの。

初心者が作るゲームに使う乱数なんてrand()で十分だろって言っても、ぜんぜん通じなかったな。

この前のtoto乱数の件で思い出したから書いた。

2017-02-19

明日から未来のいつか

僕もいつかメール最後に「拝承」と書くのだろうか。それとも社内ルールドキュメント規定されているのだろうか。

スコシドキドキ。

2017-02-18

なんか役立たずになってしまった

ドキュメント資料作成が得意というわけでもない

オフショアを取りまとめたり、メンバー進捗管理が得意なわけでもない

技術に詳しいわけでもない

なんかどうすればいいのかわらなくなった

2017-02-11

http://anond.hatelabo.jp/20170211022822

あくま個人的感想みたいなものなのですが、次のものがあると思っています

レビュー体制を作る

 ・ミスは誰にでもあるのでちゃんとレビューする体制を作って責任分散する

  ・個人攻撃は誰も得しないばかりか、批判隠蔽体質を作る

 ・レビュー時にちゃんとテストパターン漏れがないか確認する

  ・逆にいうとレビュアーテストパターン漏れがないことと他に発生し得るテストパターンがないかレビューすればいい

ドキュメント化する

 ・仕様KKD(経験,勘,度胸)で決定していいものではないのでちゃんと仕様としてまとめておく必要があります

  ・特に専門用語はちゃんと共通認識としてできるだけ正確に記述するほうがよい

   ・これをしておかないとどこかで新しい機能を追加すると違うところの整合性が取れなくなる

    ・ドキュメント化していないとそういうことすら気がつかない

リリース毎日する

 ・リリース毎日するというより小さい単位リリースすることが目的

 ・大きい単位修正するとレビュアー負担にもなるしテストも大変

  ・その結果、テスト漏れが発生する

プロとして取り組む

 ・社内勉強会とかしたりして継続的勉強する

  ・ある程度継続しないと人は成長しない

   ・逆に一定期間負荷をかけると最初は大変でも徐々に慣れてくる


今の職場改善案みたいなものなのでモダンな開発スタイルとはまた違うかも。

モダンな開発スタイルアジャイル開発、スクラムDDD勉強してみるといいかもしれません。

職場の開発スタイルが古すぎて限界なんだが

IT業界プログラマなのですが、どれだけ技術進歩しても何年も同じ開発スタイルから一向に改善しなくて限界を感じています

例えば次の点が挙げられる

バグ個人責任のせいにする

 ・世渡りが上手い奴は口だけ出して手は動かさな

  ・こいつが手を動かすのは最小限で、なおかつビビりなのでよく確認する

 ・手だけが早くリリースしてから考えようぜって思っているタイプバグを出すたびに個人攻撃される


開発プロセスが雑

 ・レビューがない

 ・仕様最初から作るつもりがなく、毎回担当者が長年の勘で仕様を考える

  ・故にどこかで矛盾が生じる

  ・担当者の長年の勘が頼りなので、作り手としては要求に答えるしかない

   ・仕様明確化されていないので、言われた通りに作るしかない

   ・一部しか担当していないので、一部しか知らないのだがそれを「もう何年もやっているのに担当したところしかできない」と言われる

    ・尚、これに対し口答えは許されない模様

 ・仕様がないので自分なりに担当者確認して作る

  ・このあたりはOKなのだが、その内容は一切ドキュメント化されていないしするつもりもない

  ・いつでもこの仕様担当者の気分で変更できる

   ・変更できるのは問題ないが、言い方が「お客さんがバグ報告がきた」みたいな切り出し方

   ・バグではなくただの仕様だし「作る時にそう言いましたよね?」と言ってもドキュメントがないので根拠なし

テストを書かない

 ・開発スピードが遅くなるから理由テストを書かない

 ・というか書き方を知らない

  ・xUnitすら使えない

MVCを知らない

 ・単語は知ってて理解しているつもりなんだけど的外れ(いわゆる Fat Controller が普通だと思っている)

・新しい知識を覚えるつもりがない

 ・自分達で勉強した最新の知識デザインパターン

 ・新人が入ってくるもこの調子なので2〜3年もすると社内の仕事はできるが若いのに技術力は10年以上前技術者レベルになる(仕事必要なことしか知らないのでそれ以下か)

 ・そして、いつまで経ってもこの開発スタイル改善しない


けものフレンズがバズったので、ついカッとなってやった。

2017-02-09

教育困難校の生徒はどのようにして生まれるか

http://anond.hatelabo.jp/20170207224412




地方都市で塾をやっているものです。毎年、数人の生徒を教育困難校に送り込んでいます

地域的な事情もあるかもしれませんが、彼らには共通点があります




いちばん多いのは親が離婚をしている(もしくは最初から結婚していない)ということです。

離婚やその後の環境子どもに与えるダメージは相当なものがあります

発達障害先天的に脳に問題がある病気ですが、幼少期の環境後天的に脳の発達を阻害します。

親が忙しくじゅうぶんな愛情を得られなかったり、別れた親の悪口を聞かされ続けたり、虐待を受けたりして育つと発達障害によく似た症状が出ます




そして勉強をする上で特に次のことが問題になってきます

自己肯定感が低い

言語能力(読解力)に問題がある




彼らの心の奥深くには、自分は愛されていない、必要とされていないということが刻まれています

また、読み聞かせをしてあげず、低学年の音読宿題をきちんと見てあげていないと国語力は恐ろしく低い水準で止まったままです。

結果として、人の話や授業を聞けない、教科書を読めない、抽象的な概念がわからない(9・10歳の壁)ということになります




こういう子たちは小学校中・高学年からほとんど勉強についていけなくなり、中学に入っても5教科で100点前後しか取れません。

クラス30〜40人を見ている学校先生に彼らを救うことはまずできません。

塾に週何日通おうが成績は上がりません。こちらが何を言っているか教科書に何が書いてあるか理解できないのですから




そうして彼らは教育困難校入学していきます。愛に飢えた彼らはそこで恋をし、若くして子どもを作ります

もちろんその後うまくいくことは少なく、またその子にも同じことが起きる確率が高いです。

このようにして社会底辺はずっと連鎖していきます




経済的に貧しいからそうなるのかというと、そうでもありません。

一見学力経済力は相関してますが、大事なのはお金のものではないです。

文化資本を持っている人が多くお金を稼いでいる傾向にあるというだけのことです。

例えば年収300万のしんざきさんと、年収2000万のビッグダディがいたとして、どちらの子東大に行く確率が高いか考えてみてください。




参考文献

離婚で壊れる子どもたち」棚瀬一代

「子を愛せない母 母を拒否する子」ヘネシー澄子

ドキュメント高校中退青砥

原始時代を生きる弊社を見よ

http://anond.hatelabo.jp/20170209075944

Rails/PHP7で開発してる

PHP5.3。フレームワークすら導入していない。

Macとサブディスプレイ支給されてる

Win10シングルディスプレイデザイナーはPSDデータとかで容量を圧迫するに決まってるのに、低容量のSSD使用している。逆にプログラマーはそんなに容量使わないのに大容量のHDD使用している。頭悪い。

Vagrantとかで環境構築してる

VirtualBoxで全部手動ですが何か。ドキュメントもないので全員環境がバラバラですが何か。

自動デプロイしてる

huh...?

gitバージョン管理してる

サ ブ バ ー ジ ョ ン

チケット管理してる

口約束なら...

テスト書いてる/自動化してる

テスト工程を削ってる。受入テストすらも。テストせずにぶっつけ本番リリース。画面みたら即わかるnon objectエラーでさえも気にしない。言われるまで直さな

コードレビューしてる

みんな忙しいバリア貼ってるので...

チャットツールコミュニケーション取ってる

弊社のトレンドメールである

Excel方眼紙使ってない

wordやで。

アジャイル開発だ

ウォーターフォールすら理解してない。とりあえず空いてる人全員ぶっこんどけの人海戦術

裁量労働制

実質的な定時は22時やで

ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ

2017-01-29

優秀な外国人技術者活用できている会社

http://anond.hatelabo.jp/20170128125048

優秀な外国人技術者活用できている国内企業一社知っている。とても感銘を受けたのでここに書いておきたい。

ある分野向けの業務システム(参入している企業10社以上ある)を開発販売しているベンチャーだ。



システム連携お仕事をさせていただいたことがあるが、まずその技術力の高さに驚かされた。

2015年前半の時点で競合他社のネイティブアプリよりも高速・多機能ものを、JavascriptによるSPA実装していたのだ。



ネイティブアプリのようにサクサク動き、ビジネスロジックが複雑で巨大なアプリケーションjsでは作成できないと思っていたが、

実際に動くものを突きつけられてはぐうの音も出ない。



次にAPI仕様書提供を受けたがこれも驚き。

今まで見てきた競合他社のAPI仕様書ベンチャー系によくある雑なドキュメントが多かったが、

書籍ですか?」というほどよく編集されSIerも真っ青なほどよくできたものだった。

API品質言わずもがなである



最後仕事スピードが異常に速い。こっちは1か月くらいかなと思っても1週間のうちに上がってくる。

そんな早くて品質大丈夫かと思ったが、全く問題はなかった。




小規模なベンチャーなのにどうしてこれほど高品質・多機能wel documentedな製品を高速に作ることができるのか?

その会社業界の中でも資金力に勝っているわけではなく、有名なエンジニアがいるという話も聞いたことがなかった。



直接その会社CEOに聞いてみたところ、まあタイトルのとおり、理由は「優秀な外国人技術者活用できている」からだった。





あれほどの成功例を見せつけられてしまうと、ビジネスサイドとマネージャー英語を話せる日本人がいれば、日本人エンジニアは最小限でいいかもなと思ってしまいました。

というわけで「優秀な外国人技術者活用」できたらこんないいことあるよという話でした(大多数の日本企業はできないと思うが)。

2017-01-27

http://anond.hatelabo.jp/20170127134732

「爺さん婆さんにも操作可能ドキュメントスキャナ転送装置って他にない」

確かにそう

しかし逆に言えば、コストダウン効率化のための学習コストを支払う意思の無い、不勉強な自堕落者が日本世間に溢れてるってこった

日本生産性disられる根源が、こんなところにもある

2017-01-26

退職する後輩氏ができすぎていて辛い

優秀な子だということは知ってた。難しい資格いっぱい持ってる。

温厚な性格なのも知ってた。周囲の人と話してる様子なんかを見てて。

その後輩氏が退職するとのことで、自分は彼の引き継ぎとして今の現場に入ることになった。

で、作業内容やら手順やらを説明してもらいつつ、日々の業務を覚えているのだけど。

なんというか、非の打ち所がない。

いつも笑顔で物腰は柔らかく親切で謙虚な感じで、嫌な感じをまるで受けない。

説明も丁寧で、且つ分かりやすい。

ドキュメントを読むのもそこそこに何度も同じことを聞いてしま自分に、毎回同じように教えてくれる。

作業はいつも横で付き添って確認してくれる。

手順でミスをしそうな時にはさらっと指摘してくれる。嫌味のない感じで。

分担で作業していて彼自身作業タスクを持っていても、私が声をかけると必ず体をこちらに向け、作業を一緒に確認してくれる。

忙しいからと拒否することもまずない、作業しながら言葉だけで適当に回答する、ということもない。

必ず手を止め、こちらに体を向け、一緒に作業確認する。

そんな後輩氏の教える振る舞いはあまりにもできすぎていて。

優しくて心地よく、理想の先輩や上司といった感じで。

辛くなった。

もうずいぶん長い間、先輩や上司という存在ネガティブな印象しかなかったので。

まりにも後輩氏のふるまいが理想の先輩であることに、

そのことに今更やっと知ったことに、

そんな彼が退職してしまうことに。

辛くなった。

彼の後輩だったら、すごく働きやすかったんだろうなあ。

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