「フレームワーク」を含む日記 RSS

はてなキーワード: フレームワークとは

2017-05-22

Javaイベントでは、会場の狭さに文句を言うことは許されない

いきさつ

JJUG CCCというイベントで、「会場が狭い」という感想があった

それに対し、イベント関係者から感想に対する不満や、参加者を見下すような発言があった

なので、思うことを書いてみる。

Javaというユーザー層が特殊言語

技術力軽視のSIer的な組織に属する人が圧倒的に多い。

会社技術はいまだにJava5とかで止まってる。

1年の半分以上がデスマーチ

仕事以外にプログラミングをしたり、技術についての情報収集する人が少ない。

PCを家に持たない人もかなりいるのでは?)

彼らの考えるセミナー勉強会

講師が生徒を集めて集合教育を行うイベント

セミナーで話す講師報酬お金)をもらっていて、技術力がない人でも理解できる説明をする。

結論最初に言え。細かい説明とかはいらない。「今一番売れてるフレームワーク」を教えろ)

ここは大きな主催者側とのすれ違いポイントだと思う。

そもそもJJUGJavaOracle関係者と思い込んでる人も少なくない。

特にナイトセミナーの会場でOracleが使われることが多いので、Oracleから金をもらって運営しているという信じている人もいるだろう。

そういう人たちにとって、企業が行うイベントで会場に不満が出ることは落ち度でしかない。

コミュニティ主催イベントというみんなで作り上げるものなのに、ベンダーに招待された「お客様」として参加してしまっているわけである

JJUG側の変化

日本Javaユーザーが一番多い層(SIer関係者)と乖離してきているのでは?

今までは最新のJava SEとか「辛うじて」自分たちでも手の届きそうな話だったのが、マイクロサービスクラウドとか無縁な話が多くなってきている気もする。

「きちんとしたエンタープライズ的なセミナー」を期待している人に対して、コミュニティ活動理解してもらうのは難しい。

Javaエンタープライズ色が強いところも、コミュニティ活動と結びつきにくいのかもしれない。

ただ、それでもコミュニティ理解してない人たちに対して、敵愾心を煽るような発言必要だったのか?

この規模のイベント無料で参加できるようにするための、運営の労力が大変なのは理解できる。

それに対して愚痴りたくなる気持ちはわかる。

ただ、運営側がだれでも見れるSNSつぶやくとかはどうなのか?

打ち上げとか見えないところで愚痴ればよかったのでは?)

参加者は厳しい状況

JJUGイベントでは聞きたいセッションについて悩むというぜいたくはない。

人気あるセッションは埋まるのとにかく早い。

そして、それを知っている常連の行動はもっと早い。

前日までに部屋を決めて置き、目的の部屋の席にさっさと荷物おいてからトイレや買い出しに行くのだ。

ある意味正解だけど・・・なんだかなぁ

まとめ

初めてJJUG CCCに参加した後輩が「聞きたいセッションがいっぱいで残念だった、もうちょっと広い会場でできればいいのに」と言っていたところに、「運営側の苦労も知らないで文句言うな」という意見が流れてきてむしゃくしゃして書いた。

なので、あまりまとまってない。

Javaユーザーも多く、エンプラな人の比率も高めで、コミュニティ理解せず心無いことを言う人や理解すらしようとしない人も多いと思う。

ただ、彼らをディスってもなんの見返りもないし、そもそも彼らの耳には入らない。

それよりも、彼らに向けた発言を見てしまった、無関係な人を傷つけてしま可能性があることを知ってほしかった。

主催者側も参加者側も、新規古参も、みんなで仲良くJavaを楽しめるといいね

2017-05-21

http://anond.hatelabo.jp/20140510231402

文章見ただけでスキル不足だろうなと思いました。

技術って数字で測れないか募集要項には言語フレームワークとかしか書けないけど、年相応の知識を持ってないとダメだろう。

普通に技術の深さや理解度を測ってるってのが分かってなさそうだから、当たり前のことを指摘されて、心が耐えられなくて逃げるために圧迫面接って思ったんだろう。

本当の圧迫面接って事実を指摘するとか、そういうレベルじゃないので。

2014年記事だけど、この人はどうなったのかな。

2017-05-19

二年前に受けた某企業技術研修について

ふと思い立ったので書いてみる。二年前、新卒として某企業技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaフロントエンドのAngularやReactをどう連携させるか、もしかして自作フレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。

詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。

ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチプロダクトを作れということだった。意味が分からなかった。

評価するためには十分量のコード必要ということは理解していた。過去研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか?

Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaプロダクトを理解するのならそれこそフルスクラッチ要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。

Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方からフレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画修正し、適当プロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。

今年の新人も同様のカリキュラムだという。しかもまだWindowsフレームワークは一切使えない。エクセルワイヤーフレームを書けという。SIじゃないか大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身勉強し、論文技術書を読み、週末に自分プロダクトを作る習慣をつけておかないといけない。自衛しないといけない。

そんな不幸な人たちがいればいいのにと思った。

若者PHP離れ

WEB系のベンチャースタートアップ界隈に携わる仕事をしているんだけど

興味本位でどんな言語なの?フレームワークは?なんて質問をしてみたりすることが多い

10年前この仕事を始めたときは圧倒的にPHPだった、そしてJAVA、大きく離れてPerl

というかそれしか選択肢がないといった感じだったが

最近は圧倒的にRuby/Railsだ。半分はRailsで作られているだろう

そして若い人ほどその傾向にあると思った

PHPを使う人は、前の会社がそうだったから慣れてるし・・・みたいな30歳以上で起業するひとにみられる傾向

学生ベンチャーは6割がRailsPHPを使おうって子のほうが少数派になっている。おそらく多く見積もっても3割ない

ブログWordpressでやってて仕方がなくなんてのはカウントしてない)


Python(Django)も1割くらいに増えて、絶滅危惧種みたいな時代は終わった。本当に勢いを感じる。人工知能でもりもり増加してるらしいね

人工知能で触れてみて、そのままWebなんかもPython統一なんてこともあるのかも

このままいけば10年後、Ruby/Railsが今のPHPみたいになってるかもしれないなんて思った

2017-05-09

JavaScript簡単SPAフレームワークってありますか?

勉強が不得意な職業プログラマですが、WindowsアプリSPAに作り替えることになりそう。

プロジェクトメンバー積極的技術習得するような人はいないので、簡単フレームワークを探しています

↑に近いようなフレームワークありませんか?

2017-05-07

http://anond.hatelabo.jp/20170507004349

代案無き反対に耳を傾ける者はいない。

フレームワークを2文字表現するなら、なんて言えばよいのだ?


大昔、ホームページHPって略すのやめろと言ってた人が居たけど、

彼らも代案を提案できてない人がほとんどだった。

http://anond.hatelabo.jp/20170507004349

ハードウェア的な話だったらファームウェアだし、ソフトウェア的な話だったらフレームワークメールだったらフォワード

勝手に補完が効いてくれる素晴らしさを実感した

フレームワークFWって略すのやめろ

主にJavaScript使いどもがフレームワークの乱立の為にいつしか略すようになったこの言葉

他の言語国民は大困惑よ。

お前ら無法地帯国家の悪しき慣習を持ち込むな。

2017-05-06

結局Railsが最強

とりあえずWebアプリ作りたかったらRailsやれ

Railsアンチのやつらが居るが無視していい

その他のフレームワークも全部Railsの影響を多分に受けているのでRailsができないと評価もできない

Rails多数派なので天邪鬼な奴は嫌味の一つも言いたくなるのだろうがRailsで出来ない事はない

からとりあえずRailsをやれ

2017-05-03

http://anond.hatelabo.jp/20170503205540

こうならないように最新からは一歩か二歩引いて、将来性があるフレームワークを選定しないといけない。

新しいものに飛び付いて試すのは楽しいが、仕事で使うとなると話が別。

既にあるものを別の表現で作り直す手間の方が圧倒的に勝る

フロントエンド保守メンテを考えないで開発するのが良い

フロントエンド開発はころころフレームワークが変わっている。

90年代からソフトウェア開発をしている人間には信じられないのだが

これはもう、保守とかメンテナンスとか考えて実装して行くよりも、

新しいフレームワークを選定して、さっさとフルスクラッチで作り直すのが一番早い。

フロントエンドは2年たつともう古臭くなってしまうので、

2年に一回、1~2カ月だけ使って新しくしてしまうのが良い。

2年もたつと、古臭いのはもとより、同じ開発者である可能性も低く、

昔の人の謎仕様修正できない、なんてこともよくあることなのだ。

しかも昔は必要だったけど、今はいらなくなった仕様なんて腐るほどある。

仕様追加の繰り返しで、結局最初機能いらないじゃん、なんてこともあるので、

作り変えてしまって捨ててしまうのがよい。

さすがに似たようなフレームワークであれば、変える必要がないのであるが、

新しいフレームワーク採用する決断をしたら、もうさっさ古いのは捨てて、

作り直してしまおう。

2017-04-30

http://anond.hatelabo.jp/20170430134310

対象としているプログラムの外側まで含めて、とにかくどこで壊れるかを分析する。

対象としているプログラムが想定していないデータが流れてくる、ハードウェア問題、なども考える。

対象としているプログラム問題があることが確定したなら、デバッガが使える環境ならデバッガステップ実行、使えないならPrint文を並べる。

範囲が広すぎるなら、部分ごとに調査して問題の起こる領域を絞り込んでいく。

あるコード片で壊れることが特定できたなら、それを最小限で再現できる状態を作る。

データ依存ならあらゆるデータを放り込んで傾向を見る。

問題ないように見える1行で壊れるなら、利用しているフレームワーク問題を疑ってみる。

2017-04-28

[]岸信夫外務副大臣引用した国連見解ではテロリズム集団組織的犯罪集団はまったくの別概念

 国会ウォッチャーです。カテゴリ化してみました。別に一意にこの増田を同定していただこうとは思っていないので、どうぞ他の増田もこのカテゴリーを使って国会について書いてくださいね

 緒方林太郎議員質疑。緒方さんは間違いなく頭がいいし、論理で攻めてるときはいいんだけど、前半の金田大臣に、Hard cases makes bad lawsとか知ってるかとか聞いたり、テロというHard casesで法律を作るのはまずいんではないかみたいな一般論、いまさらいる?向こうはそんなんもう100も承知で、むしろそこが主目的になってんだから聞くだけ無駄でしょ。後半のとこだけでいいんだけど、もう金田さんと岸信夫外務副大臣無能すぎて、質問するだけ無駄なかんじ。これで審議時間積んでるっていう既成事実化してるっていうのが残念。あと枝野さんが、立法ガイドについては、英語に詳しい仲間に任せますって言ってたからそれは緒方さんのことだろうと思ってたんだけど、この話が出てこなくて残念。国重さん参考人質疑で取り上げてた、undocからの返信についての精査がすんでないのかな。対案主義っていうなら、アメリカだって、州内で完結する犯罪については、この条約対象としない留保を置いてんだから2003年留保なし締結の批准国会決議の取り直しを要請すべきだろ、常識で考えて。金田さんとか岸さんがこの条約の建てつけも法律の内容もわかってないのなんかもう周知なんだからいまさらそこ攻めてどうすんのって話でしょ。

TOC条約テロ関連防止条約

 テロ関連防止条約は、外務省が決めてる13の条約のこと。民主党は、テロ対策だというのなら、TOC条約ではなく、ほかの条約を先に締結して、世界に範を示すべきではないかといっているんですが、岸外務副大臣TOC条約テロ関連防止条約ではないと答弁してますね。まぁこんなのいまさら聞かなくてもいいんですけど。わざわざ、条約作成時に、この条約対象とする組織的犯罪として、テロリズムを含めべきではないってわざわざ当時の日本政府アメリカカナダフランスイギリスなどとともに主張して、現にTCO条約テロリズムなんて文言は盛り込まれなかったんだから、ここは切り分けたんです。岸副大臣は「テロリズム組織的犯罪集団の一部である」って答弁してたけどね。この話も何度もしたし、後半のとこだけでよかったんだよ。

論理の話1「テロリズム組織的犯罪集団には関係がある」と「テロリズム組織的犯罪集団の一部(その典型)」は両立するか?

 緒方さんは、テロ関連条約外務省時代担当してたから、テロ関連条約で使われる単語は、intimidate(脅し)とかそういう他者意思に影響するような言葉出てくるけど、TOC条約にはでてこない。これはテロ防止の条約じゃないからだ、と。それに対し、金田さんや岸さんは、「交渉過程テロリズムを含むリスト化の動きもあった(日本を含む主要国の反対で否定されたことはあえて隠すスタイル)、また国連文書でも、この条約は、テロリズムの防止にも資する、としている、TOC条約テロを含む組織的犯罪を防止することを目的としている」というのですが、緒方さんは、「それならば前文にでているはずだ」と「Links between terrorism and transnational organized crime」というように、国連文書では、テロリズム国際的組織犯罪は別のものとして扱っているだろうと。もし岸さんがいうように、テロリズム国際的組織犯罪に含まれるなら、リンクなんか生じないだろう、と。国際組織犯罪テロリズムは別概念だということが示されているではないかと強く言ってましたが、これは当たり前だよね。岸さんが引いていた、国連事務総長報告でもそういってるもん(s/2015/366)。「テロ組織と国際組織犯罪集団とは関係性がある、理論上はこの二つは区別されるが、実際にはその区別は明確ではない」と都合のいいとこだけ引っ張ってきてたけどね。というかこの文書読んだけど、どこを読んでも国際組織的犯罪の取り締まりにconspiracyの取締り要請してないでしょ。国際的組織犯罪も、テロリズム集団の取り締まりも、両方しっかりやれっていってるだけじゃんねぇ。文字制限の都合上原文は省略するけど、私の訳だから、お疑いの人は自分で原文を読んでね。

テロリストと国際組織犯罪は、「まったく別の」(distinct)事象であり、異なる働きと目的を持っている。また異なる国際法上のフレームワークによって対処されている。それらの違いにも関わらず、過去15年間の国連総会安全保障理事会は、テロリストと国際組織犯罪グループの間の交流について憂慮してきた。なぜならば、それらの交流国際的平和安全に、ますます影響を与えてきているからだ。

理論的には、テロリスト国際的組織犯罪集団は明確に異なる目的を持つ(ここ使ってんだろうけど、いみが全然ちげぇだろ)。テロリスト集団は、故意に国の当局に対して挑戦し、暴力的手段をもって、イデオロギーを含むさまざまな理由のために、政治的な、変革を求める。性的暴力マイノリティに対する暴力を含む、目を引くような攻撃や何かに集中した暴力は、国際的メディアの注目を集めるために行われる(結合の基礎としての共通目的にはなるんです?)。これらの行動を報道することは、結果的に、彼らの勧誘一助になってしまっている。テロリストは、メディアなどによって、彼らの振る舞いが宣伝されることで、彼らの目的のために、より多くの隠れた同調者や公然とした支持者を得ることや活発な勧誘資するようになることを望んでいる。金は彼らにとっては公権力に対抗する活動遂行するための道具であって、ゴールではない。

国際的組織犯罪に参加するグループは、典型的には、公権力メディアからの注目を避けるために、隠れて活動従事する。犯罪的な組織化は、政治的な変革よりも、彼ら自身を富ませるために利用される。当局に対して彼らが行う阻害的行為は、彼らの活動にとって都合がいい条件を作り出し、拡大し、維持するために行われる。(メキシコ麻薬組織が、警察行政を殺しまくる系のやつだろうね。これがTOC条約が取り締まろうとしてるもの

実務的には、上で説明したような違いというのは必ずしも表面化していない。セクションBで示す例に見られるように、テロリスト集団の中には、国際的組織犯罪に関わったり、深く関与しているものもある。両方の集団テロリスト集団国際的組織犯罪集団)が、彼らの活動にとって望ましい状況といえる、永続的な不安定さを維持するために活動している。国際的組織犯罪集団は、資金武器、その他のテロリストが持続するために必要手段提供することができる。

なんでこの文書が、TOC条約テロリズムの防止に役立つもので、TOC条約が、テロリスト資金的活動にconspiracyが必要だって言ってる根拠になるのかわからんよ。ヤクザ親分子分に暗に指示して、子分鉄砲を所持した件については、親分を共謀共同正犯でしょっ引いてる判例があるんだし、ここは共謀で逮捕できるっていう例になってるでしょうよ。ほんとにクソみたいな理屈こねてきやがるな。明らかに、国連事務総長報告では、テロリズム集団国際的組織犯罪集団区別してます理論的に区別できるけど、必ずしも明確ではないっていってるのはその目的国連見解では、テロリスト組織的犯罪集団は別。大事なことだから二回いったよ。クソ外務省

論理の話も通告がないから答えられませーん(金田&岸)

いうとくけど、これ質問主意書への答弁の話やからな。

緒方

テロリズム定義について、一般的意味についてなんといっているかというと、えー”特定主義主張に基づき、国家等にその受け入れ等を強要し、または社会に恐怖等を与える目的で行われる殺傷行為等をいうと承知している”と。これについて特定主義主張とはなんですか、聞いたら”一般的意味としてのテロリズムにかかる集団が行う殺傷行為等のよりどころとなる主義主張”ということです。で、”特定主義主張”を、テロリズム説明のところに、代入すると、テロリズム説明のところにテロリズムという言葉出てくるんです。これ自家撞着を起こしていませんか、副大臣

(暫くの沈黙の後、事務方から耳打ち、多分この後答弁に立つ人たちは林局長以外、自家撞着の意味理解していないと思われる。)

「今のご質問には同意できないと、同意できま、せん。同意できません」

緒方んんんん?)

鈴木

「再度お願いします」

「今の説明には同意できません」

緒方

「いやわたし単に、論理学の話をしているのであって、テロリズムという言葉説明するときに、全部いろんなものを代入していくと、その定義の中にテロリズムという言葉が入ってくるんです。これだとどんどんどんどん議論ループしていって、何がテロリズムなのかということがわからないじゃないですか。これまさに、自家撞着なんですよ。これが政府の答弁なんです。これがおかしいでしょと聞いてるんです。」

(?これ答弁しようがないんだよ。それこそ趣旨を明らかにしてからじゃないと全部を読めない状態でー)←私はアホですとの自己紹介はよしましょう。

緒方だって配布資料に(ありますよ)配布資料見ていただければ。)

緒方

別に法務でも良いですよ。テロリズム定義。」

逢坂:これ考える時間まで質疑の時間にしないで)

鈴木

速記をとめてください」

約一分鈴木

「岸外務副大臣

「あのぉー、テロリズム、の定義につきましては、先ほど主意書の前段にもございます。また先ほど大臣から答弁があったとおりでございます。あの質問主意書の中身の部分につきましては、通告をいただいておりませんので、この場で詳細にお答えすることは差し控えさせていただきます。」

緒方

「じゃあ今考えていただいて結構ですよ。でもこれ、政府答弁で、おそらく外務省法務省も、これ協議にあずかって、どなたか後ろにいる方に話を聞いていただいても結構ですよ。しっかりと詰めて答弁書書いたはずですね。で、そのテロリズム一般的定義の中に、特定主義主張とある。そして、その特定主義主張説明してくれといったらその中にテロリズムという言葉が入ってくる。これであれば、まさにこの法案テロ等準備罪の、テロという言葉が入ってるにもかかわらず、そのテロ、の中身が自家撞着を起こしている状態であるということは、これは、国民からして、納得のいく中身になっていないでしょと聞いてるんです。それはまさに、見て思いましたよ。ほんとに変だと思いましたよ。でもこれが政府の答弁であるのならば、これ答弁の中で自家撞着をおこしていることをどう思いますか、と聞いてるんです。これ外務副大臣でも大臣でもどちらでも結構ですよ。」

「ご通告をいただいていないので(略)・・・・」

緒方

「(略)自家撞着を起こしていることはお認めになるんですね」

「繰り返しになりますが、ご通告をいただいておりませんので、また質問主意書、につきましては、そのー答弁のとおりであります。」

大臣はめんどくさいから略

「あのー自家撞着という意味はわたくし、即座に理解できませんが、言われております答弁書の中で、特定主義主張とは一般的意味としてのテロリズム集団が行う殺傷行為等のよりどころとなる主義主張。という部分についてお答えしているのは、これは、特定主義主張というものが、この殺傷行為テロリズム集団が行う殺傷行為等のよりどころとなる主義主張であるというこの関係性をご説明、あの答弁したものと私は理解しております。そういった意味において、質問に対して、また同じ言葉で答えるとか、そのあるいはお答えの中に質問の前提がすべて含まれているという意味での自家撞着そのものというような理解は私はしておりません」

緒方

「これ閣議決定した答弁書ですよ。単に私は特定主義主張意味的にはテロリズムとはかな)は何かというところで、次の答弁書できたものをパカっとはめたら、それは関係性を述べたものであって、それがすべてではないみたいな言い方されると閣議決定した答弁書なんか何にも信頼できないですよ。今私が言っているのは、ほんとに、単純に、テロ定義の中に特定主義主張とあるから、それは何だと聞いたら、答弁があったから、これをそのままいれたら、議論がぐるぐる回って、成立しないでしょと。関係性とかおっしゃりましたけど、刑事局長のおっしゃること、まったく論理的じゃないですよ。もう一度答弁ください。」

特定主義主張の内容については言ってない、関係性をいっただけだから自家撞着じゃないよ」(これは一応論理は通った。でもテロリズム集団定義を聞いた答弁としてはだめだよ。)

このあと、定義あいまいで、わかりやすい事例とか言うなと切れる緒方議員金田に聞いても無駄だって

最後緒方さんのまとめ主張は筋が通ってるしそのとおりだろうね。

その他の法律では、テロリズムを、政治的主義主張としているが、なぜわざわざ特定のと変えているのはどうしてかという質問について

井野俊郎政務官

「今回の法律におけるテロリズムあくまで例示でありまして、この法律において、テロリズム定義を明確にする必要というのは、あーこの法律においては肝ではないと考えておりましたが、先ほど答弁したように、あくまテロリズムというのは一般的意味で使っているということであります。」

緒方

「すごい答弁ですよ、テロリズムという言葉定義する、これは全然この法律において肝でもなんでもない、とすごい答弁でした。最後一言だけ言わせていただきますが、なぜ、政治的その他の主義主張という言葉を使わないかというと、これにしてしまうと、今回の法律の中で、カバーできないものがあるんですよ。だから特定主義主張と、範囲を広げているんですよ。でも範囲を広げた結果として、それは何ですかと聞かれてしまうと、それが自家撞着を起こすような説明しかならないんですよ。だから問題だといってるんです。」

マジで金田&岸に聞いても時間無駄だし。審議時間にいれないで。

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-04-14

何故特定Rubyエンジニア層はRuby on Rails信仰するのか

何かにつけて「それ、Railsなら出来ます(笑)」と言いながら他言語、他フレームワーク批判する人がいる事に私、気になります

別にSinatraかPandrinoにして必要に応じて追加していくとかでもよくない?

2017-04-06

http://anond.hatelabo.jp/20170406140714

うそうそれなんです

フレームワーク使おうと思ったらオブジェクトクラスについての理解必須なので

勉強しているところなんです

やっぱり難しいもんですね

http://anond.hatelabo.jp/20170406135316

ウェブフォームユーザ入力を受け取って保存するだけとか、

ちょっと特定のページを動的にしたいだけくらいの事例では、クラスを使っても使わなくても全く大差ないと思う。

これが、SNSやECのシステム開発レベルになるとクラスを使わずには居られなくなる。

そもそも、その規模になると、既存PHPフレームワークララベルとかYii)を使って開発することになるので、

オブジェクト指向知識は不可欠になるよ。

2017-04-03

ソニー株式会社退職しました

表題の通り、数年勤めたソニー株式会社退職しました。

個別具体退職理由はいろいろあってそれらは後述しますが、退職を決めた基本的理由は、個人的キャリアパス設計会社方針ミスマッチ労働観のミスマッチ技術投資の考え方のミスマッチの三点に集約できると思っています

キャリアパス設計会社方針ミスマッチ

私はソニーソフトウェアエンジニアとして働いていました。

ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達理想工場"、エンジニア自由活躍できる会社日本メーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。

実際会社説明会などでそういった説明しましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」というふわっとしたゴールを設定し、いわゆる"プログラマ 35 歳定年説"をガン無視した一生エンジニアキャリアパスを描いていました。

しかし、会社の求める人材像、少なくとも自分が配属された事業部で求められる人材像、キャリアパスは、上記と全く異なるものでした。

昇進の段階としては、現場業務(エンジニア)は基本的に常にマネジメント業務(中間管理職)に対して格下に位置得付けられており、一部オーバーラップする部分があるものの、昇進する = エンジニアをやめてマネージャーになるという状態でした。退職の原因になった上司からも「君は優秀なんだからプログラミングみたいな低俗なことは早く辞めて人を動かせるようになれ。私が引っぱりあげてやる」(意訳)といったようなことを言われ、自身の「エンジニアとして生きる」というキャリア設計との相違は明らかでした。

もちろん、組織としてスケールするために、エンジニア経験を活かしてマネジメントに移行することは否定されることではありません。ですが端からエンジニアリングマネジメントになるための踏み台として"しょうがなくやるもの"として扱うことには強い違和感嫌悪感がありました。

退職の際の送別会で、部署の中でもエンジニアとしてレベルが高いと感じていた40代の先輩が、「ソニーではエンジニアリング評価されない。俺はその方向に進んだけれど、給料最近下がる一方だよ。君はい選択をした」と言っていたのが、未だに記憶に残っています

労働観のミスマッチ

はいわゆるライトオタクで、アニメゲームが好きでコンテンツを消化する時間無限に足りないと感じていたり、自分で何かを考えてものを作るという絶望的に時間を食う行為も好きだったりして、ともかく余暇時間の確保が人生重要課題です。

うご推察されたことと思いますが、ソニーでの私の労働時間はそれなりに長かったです。企画ビジネスユニット主導のスケジュールに開発部隊は圧殺されて、長時間労働常態化していました。私も残業時間が 90 〜 100 時間程度の月が 3 ヶ月ほど続いたこともありました。部署の先輩には、残業時間の"平均"が100時間という方もいましたし、月の半ばで法規制が許す残業時間を"使い切ってしまう"ため月の中盤以降は"定時に帰ったことになっている"デバイス系の同期もいました。正直に告白すれば、私もチームリーダーに「打刻してから席に戻ってこい」と言われたことがあり、そのチームリーダーは次の日悔恨の表情で「昨日言ったことは忘れてくれ」と言っていましたが、数カ月後に突然辞めました。

前述の通り、趣味時間人生の意義になっていた私にとって、これは体力的だけでなく精神的にも非常にダメージの大きいものでした。上司からの「君のチームが他のチームに比べて残業時間が少ないので、(労使交渉で通常の上限の)60時間まで残業時間を埋めてほしい」という指示が決定打となり、退職を決意するに至りました。

技術投資の考え方のミスマッチ

昨今の、シャープ東芝等のニュースで明らかになっているとおり、大企業から安泰ということはもう過去の話です。そのため、自分市場価値を高めておく必要があると私は強く感じています

しかし、会社エンジニアリング軽視であり、またその昇進先であるマネジメントについてもお世辞にもプロ仕事とは呼べないものであり(残業100時間を続けないといけないマネジメントとはなんでしょうか?)、ソニーで働き続けることは私の「労働市場自分市場価値を高める」という方針にとってリスクしかありませんでした。

人事担当者に、現在キャリアパスについて不安があるという相談をしたときにも「増田さんがソニーで(定年まで)働き続けることを考えると〜」のような発言をしており、会社がなくなる / 現状の待遇が維持されなくなるというリスクは全く考慮されておらず、いかにただただ嵐が過ぎるのを耐えるかという発想しかありませんでした。

エンジニアリングについても、昨今の汎用チップスペック的に見劣りする高額のカスタムチップの開発、そのカスタムチップを使いこなすための C / アセンブラによる手動の最適化といった"職人芸"に対する信仰、大量のテスターを雇っての人力テストなど、エンジニアとしてのセンスとしてやや疑問符がつく、ともすればレガシーな開発手法がまかり通っていたりと、この技術職場適応したとして、その人物一般的問題対応できるだろうか?その人物市場評価するだろうか?という疑問が拭えませんでした。

また、業務時間がまるで足りないからとコードレビューすらろくにできないので知見がたまらない、時間がないので勉強もできない(しない)、もちろん職場で最新の技術に対するディスカッションどころか雑談すら成り立たない、という状況で、私がこのような職場業務忙殺されている間にも、世界エンジニア勉強技術力を高めているのかと思うと、相対的自分市場価値を毀損されていると感じ、焦燥感にはちきれんばかりの思いでした。

転職

こういった不安・不満があり、また会社の期待にも応えることが難しいということで、先ごろ無事ソニー退職し、新しい職場で働き始めています。新しい職場は上記の 3 要件についてよくマッチしていると感じており、心穏やかに働けています。幸い年収も多少増える結果となりました。

色々書きましたが、これらはソニーが悪い会社だと言う話ではなくミスマッチだと思っています。上記の内容はすべて私の価値観を元にした一面から評価になっており、他方でここで挙げたような会社の考え方(マネジメント優先・仕事優先・安定優先)に同調・納得できる方もいると思います。残念ながら私とはミスマッチだったというまでです。

また、あくまでこれらはソニーという(さらに言えば自分の配属された事業部という)組織に対する評価であり、尊敬できる先輩・同期もたくさんいましたし、そういった方々と出会えた、幸いにして現在も仲良くしていただいているということは、本当にありがたいことです。

みんながしあわせになるといいな。

おもしろ案件お気持ち表明

ここからは単なるおもしろ案件共有コーナーです。

内定もらった時の風景は今でも覚えていて、友人と一緒に出かけていた先で内定通知の電話がかかってきて、本当に2人で喜んで、とても嬉しかったのを覚えている。どうしてこうなっちゃったんだろうなぁ。

ものつくりの現場で、エンジニアリングバカにされたのは悲しかったなぁ。私がいる間だけでも、ものが作れなくなっていってるのが感じられたのも悲しかった。

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

「~を分析してみた」みたいなレポートを共有したり出来栄えを競ったりするサービス

「(ある世の中の事象について)統計等の資料を引っ張ってきたりフレームワークと合わせて考察してみるとこういうことが言えるのでは」っていうレポートをみんなで投稿して、それについてやんややんやいったりするサービス妄想している。

例えば昨今で言えばDeNAレポートがいい資料だねって話があるけど、あそこに出ている数字とその当時のDeNAの動きを追って、関連性を探るとか。

東日本大震災から6年の節目が経ったけど、復興税が何に使われているのか復興庁ホームページから見れる予算執行状況をグラフでまとめて、どの部分に最も支出がされていて重視されているのか探るとか。http://www.reconstruction.go.jp/

サービス提供する側はこういうデータがありますよーとか、今週はこのデータ(資料)を使って何かを分析してみましょうとか、言ったりする。Kaggleみたいにコンペにしてもいいかも。何を基準に優劣を判定すればいいのかはわからないけど。

こういう社会的に何か示唆を与えようとするレポートというか文章個人ブログで書かれていたりすることが多い印象だけど、そういう文章ばかりが集まったサービスってニーズいかなー。

2017-03-12

Webサービス開発ってさぁ、

何年も想定して作るもんではないよね。

そもそも開発しても使われるかわからないし、

2,3年後には相当古くなっているし、

新しいフレームワークでも使って

またスクラッチから作ったほうが早いし。

キレイコード買いてよ、とか言っているのはクソバカに見える。

自分で一から作ればいいじゃん。

そんな勝手なことできないって言うやついるけど、

そんな勝手なことできないような地位にいるお前が悪いんだから

だったらガマンするしかないだろ。

2017-03-05

コメ率の低いはてブエントリ英語エロか?

http://anond.hatelabo.jp/20170305115905増田以外のホットエントリで見ると。

2017年2月コメント率の低いホットエントリ

コメントタイトルコメント数/ブクマブクマページ
0.0%Python3.6 から追加された文法機能 - Qiita0/96b.hatena.ne.jp/entry/324476241
0.8%文章ベクトル化して類似文章の検索 - Qiita2/245b.hatena.ne.jp/entry/324662835
1.0%[wip] 会社サーバサイドエンジニアにReactとかReduxのことを説明する資料 - Qiit1/97b.hatena.ne.jp/entry/319535213
1.1%機械学習ディープラーニングの入門者向けコンテンツまとめ - Qiita1/94b.hatena.ne.jp/entry/321793279
1.9%Web制作時の概算費用と想定納品日を簡単に計算する票をつくってみた – のんびりデザインしているよう7/375b.hatena.ne.jp/entry/320010979
2.0%最近見かけるレイアウト・ナビゲーション・スライダーフォームなどがどうやって実装されているのかのまと7/344b.hatena.ne.jp/entry/322198623
2.2%フロントエンド知らない私のwebpack入門 その1 - Qiita4/186b.hatena.ne.jp/entry/319233247
2.3%フルマネージドのSaaSクラウドデータベースサービスdashDBの活用スタイルとは ~手間いら5/216b.hatena.ne.jp/entry/323891713
2.4%Pythonをやるときに参考になりそうな情報 - のんびりSEの議事録19/807b.hatena.ne.jp/entry/322300431
2.5%React基礎 · GitBook17/681b.hatena.ne.jp/entry/321494522
2.7%開発効率を上げるテスト設計 // Speaker Deck5/183b.hatena.ne.jp/entry/323584734
2.8%畳み込みニューラルネットワーク可視化 - 人工知能に関する断創録3/108b.hatena.ne.jp/entry/322431100
2.8%グランブルーファンタジーを支えるインフラ技術 // Speaker Deck10/359b.hatena.ne.jp/entry/324611754
2.9%仮想DOMの内部の動き | プログラミング | POSTD6/206b.hatena.ne.jp/entry/321289144
3.0%金融データPythonでの扱い方 - 今日も窓辺でプログラム16/527b.hatena.ne.jp/entry/322842311
3.1%Python Jupyter notebookでpandasを使いCSVを読み込みグラフを描画してp5/162b.hatena.ne.jp/entry/321556884
3.1%React Redux Real World Examples 〜先人から学ぶReact Redux9/290b.hatena.ne.jp/entry/323749846
3.2%Awesome Python:素晴らしい Python フレームワークライブラリソフトウェア・リ15/472b.hatena.ne.jp/entry/319013267
3.2%履歴書志望動機|最速で書く方法と受かる書き方14/433b.hatena.ne.jp/entry/279613157
3.4%今日からはじめるGitHub初心者がGitをインストールして、プルリクできるようになるまでを解38/1128b.hatena.ne.jp/entry/318690305
3.4%スケーラブル GCP アーキテクチャ6/178b.hatena.ne.jp/entry/322723492
3.5%アーキテクチャから新しい! 初めてのエディタには、21世紀生まれの「Atom」がおすすめ【続・若手エ11/311b.hatena.ne.jp/entry/322534650
3.5%フロントエンドの基礎知識 // Speaker Deck15/423b.hatena.ne.jp/entry/322749937
3.7%ロードバランサー再入門 | ツチノコブログ26/704b.hatena.ne.jp/entry/323163487
3.7%APIサーバを立てるためのCORS設定決定版 - Qiita5/134b.hatena.ne.jp/entry/321742626
3.8%画像】こんなのソフマップじゃないwwwwwwwwwwwwww|ラビット速報5/131b.hatena.ne.jp/entry/321219627
4.0%動画あり】人志松本のゾッとする話のあるある探検隊の話怖すぎwwwwww | 2ちゃんねるスレッド10/252b.hatena.ne.jp/entry/319507149
4.0%翻訳2017年展望: pandas, Arrow, Feather, Parquet, Spa7/176b.hatena.ne.jp/entry/324411617
4.2%【たまに行くよ!って人向け】いつもと少しちがう東京ディズニーシーデートにするための5つの方法 @ja3/72b.hatena.ne.jp/entry/321496344
4.3%高速なシステムを作る方法 // Speaker Deck9/211b.hatena.ne.jp/entry/283448858
4.3%処分・廃棄にお金は要らない!?パソコン無料引取してくれる業者一覧7/162b.hatena.ne.jp/entry/320803373
4.3%タデサプリを支えるデータ分析基盤 ~設計の勘所と利活用事例~3/69b.hatena.ne.jp/entry/322583838
4.4%「Front-End Developer Handbook 2017」がGitBookで無償公開。フ24/542b.hatena.ne.jp/entry/318947145
4.6%デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの7/152b.hatena.ne.jp/entry/322562611
4.6%大量の要素を高速に表示するためのバーチャルレンダリング入門 / Virtual Rendering 6/130b.hatena.ne.jp/entry/323604383
4.7%MySQLアンチパターン22/473b.hatena.ne.jp/entry/319218778
4.7%5年間コードを書き続けたエンジニアが、新人に読んでもらいたい11冊+αを紹介する - エンジニアHu47/1006b.hatena.ne.jp/entry/313934939
4.7%グーグル社員も長友選手も行う集中力を高める方法 - 自分で学ぶ心理学20/427b.hatena.ne.jp/entry/322090614
4.8%例の機械学習コースが良いらしいと知りながらも2年間スルーし続けたがやはり良かったという話 - Qii68/1418b.hatena.ne.jp/entry/321403591
4.9%NoSQL を使用する場合と SQL を使用する場合Microsoft Docs28/577b.hatena.ne.jp/entry/322834020
4.9%Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita5/102b.hatena.ne.jp/entry/321629987
4.9%誰でもできる、プレゼンが劇的にうまくなる基本テクニック - 科学非科学迷宮77/1557b.hatena.ne.jp/entry/318913434
5.0%脆弱性発見者が注目する近年のWeb技術 // Speaker Deck24/481b.hatena.ne.jp/entry/319516657
5.1%たった3つのコトで仕事が楽になる!「できる上司の会議」がマジで真似したい | CuRAZY [クレイ7/138b.hatena.ne.jp/entry/322534334
5.1%日経電子版を支える基盤API // Speaker Deck13/256b.hatena.ne.jp/entry/319592914
5.1%30歳から始める数学 - Shoyan blog50/982b.hatena.ne.jp/entry/323617832
5.1%インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - VOYAGE GRO20/392b.hatena.ne.jp/entry/323171376
5.1%『How to Get Startup Ideas』 - いかスタートアップアイデアを得るか -17/333b.hatena.ne.jp/entry/324384439
5.1%無料ウェブサイトブログに使える写真を検索可能な28サービスまとめ - GIGAZINE18/350b.hatena.ne.jp/entry/323600897
5.2%内向的な人のための面接ガイド - GIGAZINE14/271b.hatena.ne.jp/entry/322036523

Pythonデータベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。

2017年2月コメント率の高いホットエントリ

コメントタイトルコメント数/ブクマブクマページ
74.5%はてブ要望「返信出来るようにして欲しい」 - interact114/153b.hatena.ne.jp/entry/319990286
73.5%あなた朱雀とか白虎とか四神を覚えたキッカケは何?」という質問に対し世代がバレそうになる人々→「幽319/434b.hatena.ne.jp/entry/322198765
67.8%内海 聡さんのツイート: "あなた甲殻類アレルギーだった場合あなたの心は殻に閉じこもっている可449/662b.hatena.ne.jp/entry/318821783
67.4%日米首脳会談 首相は「ドラえもん」のスネ夫になった!民進党野田幹事長が批判 (産経新聞) - Ya95/141b.hatena.ne.jp/entry/321930776
65.7%いい記事書けばブクマつくとか嘘っぱち!こんな嘘がまかり通るはてな界に物申すっ! - ゆるくいきていく260/396b.hatena.ne.jp/entry/323206934
65.5%痛いニュース(ノ∀`) : 梅沢富美男(66)、老害判定に怒り 「日本は俺達が作ったんだぞ!」 - 190/290b.hatena.ne.jp/entry/322785094
65.5%茶碗に米粒を残した状態で「完食」する人は完全悪ではないけど相容れられない、という話に意見続々 - T413/631b.hatena.ne.jp/entry/321479096
64.6%けものフレンズを視聴1分30秒で挫折。 - 自由ネコ122/189b.hatena.ne.jp/entry/321589678
63.7%けものフレンズコスプレ批判に対する異論まとめ - Togetterまとめ228/358b.hatena.ne.jp/entry/323622485
63.6%レジでバレる!二流の人の超ヤバい3欠点』という東洋経済記事を読んで。クレジットカードイメージ119/187b.hatena.ne.jp/entry/323599229
63.5%痛いニュース(ノ∀`) : 日本在住のイスラム教徒の子どもがハラール対応給食に苦慮→学校側に配慮290/457b.hatena.ne.jp/entry/321128745
63.0%あざなわさんの炎上はてな村権威のなさ - メロンダウト133/211b.hatena.ne.jp/entry/323813866
62.7%プレミアムフライデーって何でこんなに叩かれてるんだろう? - シャイニングマンの「勇気を君に」126/201b.hatena.ne.jp/entry/324113658
62.5%飯田譲治さんのツイート: "日本が悪い日本が悪いって、民間人は殺さないってルール破って、原爆落として65/104b.hatena.ne.jp/entry/321434534
62.4%偏差値40の大学日本必要なのか?子供を焼き殺す大学補助金は不要 - カキカエブログ166/266b.hatena.ne.jp/entry/318786744
62.2%坂上忍 清水富美加の月給5万円は正当「僕らの時もそうだった」 (デイリースポーツ) - Yahoo!237/381b.hatena.ne.jp/entry/321888913
61.9%清水富美加17日著書出版「全部、言っちゃうね。」 - 芸能 : 日刊スポーツ73/118b.hatena.ne.jp/entry/322431771
61.5%警視庁捜査1課長が竹刀で23歳美人記者ボコボコ (文春オンライン) - Yahoo!ニュース415/675b.hatena.ne.jp/entry/322218394
60.7%ゴルフに興じる首相、誇れない」民進・蓮舫氏:朝日新聞デジタル136/224b.hatena.ne.jp/entry/321608217
60.6%金があるのに、理屈をつけてコンテンツに金を落とさない」連中について - うらがみらいぶらり243/401b.hatena.ne.jp/entry/321324226
60.6%痛いニュース(ノ∀`) : 中学校で「やばい」という言葉を使用禁止に 若い世代意味多様化 - ラ132/218b.hatena.ne.jp/entry/324642052
60.3%受動喫煙対策東京だけでやれ」 自民党内で反対論噴出:朝日新聞デジタル241/400b.hatena.ne.jp/entry/321316384
60.1%娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ92/153b.hatena.ne.jp/entry/321299915
60.1%「洗剤いらず」スポンジで教頭などが児童の体こすりけがNHKニュース215/358b.hatena.ne.jp/entry/322584234
60.0%松井一郎さんのツイート: "長谷川さんが、ブログで伝えたかったのは、健康であるための自己管理重要201/335b.hatena.ne.jp/entry/320414066

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

[]さあ、月曜日からまた転職活動だ!

いまだに無職増田です。でも本格的に転職活動を始めたついでにレバテックなるもの登録してみました。レバテックゆうんは多分登録型の派遣とか請け負いのコンサルをしてくれる会社です。

その会社webから登録したら、そのあと電話かかってきて「おうお前いい度胸してんなァ。ちょいシブヤまで来いや」と脅されたので

月曜は渋谷まで行ってケジメをつけてきます。僕の小指が失われないかどうか心配ですが、なんとか交渉成立するといいですね。

それはともかくとして、弊社はPHPおじさんなんですがやっぱりモダンJavaScriptおじさんにも転向しようかなと思うんですが、フレームワーク等々が多すぎてどれを選べばいいかよくわからなくて困ってます

apt-get一発でインストールできてなおかつ一番シンプルコード記述量も少ないフロントエンドの何かってないでしょうか。

ぶっちゃけどのフレームワークJavaScript以外の方言的な記述が多すぎてどれもシンプルはいいがたい気がします。

PHPおじさん的にはいまだに「JQueryでよくね?」と思うんですが、もう2017年ですしね。

というわけで、増田さんたちのおすすめJavascriptフロントエンドをご紹介ください。

紹介いただきました情報採用された方には無職増田オリジナルのクソ雑魚ナメクジイラスト差し上げたいと思います

よろしくお願いいたします。

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