「API」を含む日記 RSS

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

2017-02-28

くけぇーっ!!

ゴディバのうざい動画広告ブロックしてやったぜふぇーい

api.primecaster.net

2017-02-27

から徒歩x分、◯◯駅からx分、っていうのが可視化できるサービス

無いよね

 

から徒歩x分っていうのは確か不動産の人?が実際に計ってるって聞いたか

そもそも実現不可能な気がするけど

例えば「渋谷駅まで20圏内の駅全部」みたいな可視化API使えばできそうなんだよなぁ

乗り換えN回みたいな表示も含めて出来そう

 

できそうだけど、無い

無いし、作るにはそこそこ面倒くさい(半月は掛かりそう)

精度も問題になるかもしれない

おまけにカネになる気がしない

あーそりゃ無いわ

 

誰かどこかの鉄ヲタ作ってくれないか

引越し先考えるときに使いたい

 

___

 

あれ、家から◯◯駅まで何分かはGoogle経路使えば割と行けそうじゃね?

でも網羅的にはできないから、ポイントポイントになるよね・・

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

http://anond.hatelabo.jp/20170216041052

API使えよ

http://b.hatena.ne.jp/entry/jsonlite/?url=●●

●●に対象ページ(ブクマページでなく元ページ)のURL入れるとブクマ一括取得できるよ

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

俺はどんなクソジジイにも敬意は払うし、幼稚園児のお遊戯を頭ごなしに否定するような真似もしない。

これを読む限りプログラミング守備範囲とか限界とかわかってないし、魔法か何かと勘違いしてるし、アイディアとしては特に面白くも無いし、明確なビジョンがあるわけでもなく、お堅く儲けられそうもない。

ワナビーザッカーバーグとか見て陥りがちな夢物語というのもわかる。

でも老い先短いんだから、酒やたばこももう許すからプログラミングも許してやる。

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

twitter引用API経由でなきゃ違法だ!という誤解

なんかまことしやかにこういう言説が広まっていてなんだかな~と思うわけですが。

twitter社は、API経由なら他人ツイートいくらでも自由二次利用できるという規約を設けている。

それを「引用APIは経由じゃなきゃ無断転載になる!」と誤解してる人が多い印象がある。

いいですか?

twitter規約と、法的に認められた引用行為は全くの別物ですからね。

APIを使っての転載はそりゃ便利ですが、別に使わなくても引用はできますからね?

 

で、最近問題になってるのがツイートスクショ引用について。

他人ツイートスクショを撮ってブログにアップして言及した記事に対して、引用を誤解をした人たちが「APIを使ってない!違法だ!訴える!」と言うわけですよ。

そのスクショ掲載引用条件に則しているか否かを問題にするのではなく、単に「APIを使ってるか否か」だけで「違法だ!」と怒ってるんですね。

それはおかしいでしょうよと。

 

あくまで「引用」についての議論にして、スクショを載せた記事が十分に引用条件に則っているかどうかを問題にしなさいな。

引用条件揃ってるんだったら、別にAPI使ってなくても、文字コピペでなくても、スクショ掲載も立派な引用ですよ。

 

スクショだけ貼ってリンク貼らない!違法だ!」

ツイートスクショ場合別にリンクを貼らなくともアカウント名も入っているので誰から引用かも明確です。

 

スクショ改ざんされてる恐れがある」

改ざんされてる場合こそ、違法だと訴えましょう。スクショ引用できるかとは別問題

 

サイトスクショ引用って、大手ニュースメディアならどこでもやってることなのに(その中には「引用」の範疇に入らないものがいくつも見受けられるが)、それがtwitterになると途端に「引用じゃない!」って人が増えるのは何故なのか。

2017-01-17

Fate/hollow ataraxiaWineプレイ

Mac上でもWineを使えばプレイできたのでメモ。一応アダルトゲームなので、こちらに書いておく。

多分インストーラは動かないので、手動インストールになる。https://www.typemoon.com/users/faq/FHAT/#17 に従えば良い。要はsetup以下を適当場所コピーすればOK。

FateFD.exe本体なので、"wine FateFD.exe"をコマンドラインで実行すれば起動する。起動に時間がかかることはあるが、待っていれば大丈夫

初回起動時にディスクチェックがあるが、これはドライブDVDを入れておきさえすれば、他に準備も要らず通った(MacBook Airで外付けBlurayドライブ確認)。

ADV部分のフォントゲーム内の設定でMac側のフォントが使える(ヒラギノは表示されてないので無理そう)。フルスクリーンにするとおかしくなるので、これはできなさそう。エンジン設定」でフルスクリーン切り替え方法を「ChangeDisplaySettings API」にすればフルスクリーンにもできる。最後までプレイできるかは確認していないが、今の所問題なし。

魔法使いの夜もできればいいのだが、体験版が動かないので厳しそう…

自分の書いたコード自分の作ったプロダクトのどこに価値を見出せばいいのかいまだにわからずにいる。

学生時代簡単アプリケーションを作ったり、フロントエンドを好んで勉強していたから、就職して初めて携わることになったサーバサイドの開発ではこれまでの画面のような目に見える成果物がないことに戸惑った。処理が進むたびに書き込まれる膨大なログDB永続化されたレコードたち、確かなものはそのくらいで、自分が作ったものがここにあるというイメージは全く沸かなかった。

プロダクトを利用してくれるユーザは違う会社のその先にいる遠くの誰か、あるいはいるのかどうかもわからない程度の売れ行き、賞賛どころか不満の声すらこちらには届かない。業務システムからこんなものを作っているのだとドヤ顔して友人に見せびらかすこともできない。案件経験するたびにタスクをこなせる量が増えたり、人に聞かなくてもある程度自力設計してコードを書けるようになったり、そういう実感は多少なりともあるのだけれど、それだって自分から見た自分評価しかない。良い設計ができてバグのない実装ができたところで給料が上がるわけでもなく、お客様から褒められることもない。あるとしても同僚や先輩たちからこいつは多少コードが書ける人間なのだと、見切りをつけられない程度のこと。綺麗なコードを書いても年功序列の弊社では給料は上がらないし、数字で示すことができないものにお偉方は報酬をよこさない。

うちのプロダクトは特別大きな負荷がかかる処理でなければさして性能は重視されないし、設計コードも明らかにまずい作りをしていなければレビューは通る。自分コードは最低限リリースできる程度の品質であることはマージされればわかるけれど、さてこれは良いのか、それとも悪いのか。自分では判断がつかない。あるいはもっと良い作り方があるのか。答え合わせの機会がないまま淡々リリース日だけが迫ってくる。いつのまにか新しい案件下りてきていて、日々はめまぐるしく過ぎていく。

また今日も、いかにも売れなさそうなサービスひとつリリースされた。自分なりに綺麗に設計できたAPIだけれども、API設計が綺麗だからってユーザから褒められるわけでもないし、作ってる人間からしても売れなさそうなだと思うだけあって、そもそもの話、このAPIが実行される予定は未定。

最近自分が初めて開発に携わったサービスのことを思い出す。リリースから1年、いまだにユーザがつかないまま、初めての申込APIが呼び出される日を待ち続けている。

自分が生んだプロダクトの価値を認めてくれる誰かの声を、私も待ち望み続けている。

2017-01-14

http://anond.hatelabo.jp/20170114155348

明確な目標があるのに、もったいない

ネットだと、情報が多すぎるのかな

javascriptかな?と思ったけど、ruby

ifもforもでてこなくてスマ

eachが形を変えたforです

いろんなとこからコピペ量産して、2時間近くかかりました^^

api取得はすぐだったけど、json、hash、arrayでごにゃごにゃ)

rubyソース

# ライブラリ
require 'net/http';
require 'uri'
require 'json'

# 検索文字
$q = 'http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json'

# web-apiから取得
# https://support.nii.ac.jp/ja/cib/api/b_opensearch
def search(q)
    uri = URI.parse(q)
    json = Net::HTTP.get(uri)
    result = JSON.parse(json)
end

=begin
取得データ1件サンプル
{"title":"糞土",
"link":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249"},
"@id":"http://ci.nii.ac.jp/ncid/AN00094249",
"@type":"item",
"rdfs:seeAlso":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249.json"},
"dc:date":"1953",
"dc:creator":"糞土会",
"dc:publisher":["糞土会"],
"prism:publicationDate":"1953",
"cinii:ownerCount":"8"},
=end

# データ整形
#
# 入力データ構造
# {"@id":"http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json",
#  "@graph":[ { "items":[ ,,,
#
# 出力(ハッシュ)
# {title => dc:date ,,, }
def format(hash)
    title_date = Hash.new

    # ハッシュキー"@graph"の値の配列の先頭のハッシュキー"items"のハッシュ配列を取得
    items = hash['@graph'][0]['items']

    # タイトル出版年を取得して、戻り値ハッシュへ追加していく
    items.each do |item|
        title = item['title'].chomp
        date  = item['dc:date']
        title_date.store(title, date)
    end

    return title_date
end

# 並び替え
def sort(hash)
    hash.sort_by do |key, value|
        value
    end
end

# 出力
def print(hash)
    hash.each do |key, value|
        puts "#{value}年 #{key}"
    end
end

# メイン関数
def main
    # web-api検索して、
    result1 = search($q)
    # データを整形して、
    result2 = format(result1)
    # 出版年で並び替えて、
    result3 = sort(result2)
    # 出力する
    print(result3)
end

# 実行
main

rubyスクリプトの実行結果

C:\Users\unko\Desktop\prog>ruby webapi.rb
1848年 人欲辨 (じんよくべん)
1870年 雀糞論説
1920年 青瓷説
1933年 管内ニ於ケル鶏糞ノ利用状況
1947年 糞尿譚 : 小説1953年 糞土
1955年 黒い裾
1955年 形成
1959年 石糞
1972年 糞 : 海田真生個人文芸誌
1972年 乳幼児糞便図譜
1987年 糞尿と生活文化
1991年 皇居と糞尿と大嘗祭 : 皇居「糞尿」裁判を支える会ニュース
1995年 糞袋
2000年 糞尿史 : 遷都は糞尿汚染からの逃避だった
2005年 「糞尿」大全
2007年 糞虫たちの博物誌
2008年 うんちのはなし : う~んとげんきになる
2009年 糞神

プログラミングって難しすぎね?二年ほど学んだけど全く理解できない

なんかifとかforとか使えば色々できるっぽい?ってことまではわかったんだけど

APIがどうのこうのってのが全くわからない

サイトからAPI取得して情報ソートして云々ってのがやりたくて二年以上掛かったけど

未だに答えに辿り着けない、調べても難しい単語ばっかでよくわかんないし

2017-01-11

増田スマホアプリを作りたいんだけど

増田ってAPIないよね?

トップの?page=をいじってreadmore実装するとしても、readmoreするまでに時間かかったら時系列壊れるよね。どうしよう・・・

?max_id=投稿のあとの数字とかできたらいいのになあ。

2016-12-29

はてブで「Amazon」と検索してみると

昨今話題になってるヤマト佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。



2016年12月29日10:54時点、本文、新着順で検索

Amazon検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)


以下略



ECサイト連想させるトピックほとんどなくて、AmazonB2B向けサービスを充実させていることに驚いた。

Amazonって表向きは物流業界革命問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。

↑でブクマ付けた人、何が起きるのか教えて

2016-12-28

http://anond.hatelabo.jp/20161218131014

市況は2chコピペ著作権的に問題になってからtwitterまとめしかしてないけど、「著作権侵害絶対さない」マンは『キュレーションサイト著作権侵害してる画像投稿してるユーザーツイートをまとめて著作権ロンダリングして責任回避しようとしている』って批判してるやん。

単にtwitterAPI使ってれば、「著作権侵害絶対さない」マン批判対象にならないわけではないんだよ。

キャプ画投稿ツイート転載していたり、アイコン著作権侵害画像使ってるアカウントツイート転載していたらアウト。

http://anond.hatelabo.jp/20161227231029

それな

自分で調べられる仕組みほしいよな

どれが一番ブクマ・とらば・いいねついたかとかランキングでぱっとわかる仕組み、はてなAPIつかってできないもんかね

2016-12-12

はてなスターAPIで、

http://developer.hatena.ne.jp/ja/documents/star/apis/entry

uriブログエントリURLつっこんだらちゃんと星データ取得されるんだけど

ブクマについた星データを取得するにはどのURL入れればいいの?

ブコメリンク

b.hatena.ne.jp/entry/000000000/comment/user

を突っ込んでも何も返ってこない

2016-12-09

http://anond.hatelabo.jp/20161209101721

表示されたものフィルタリングするだけだから増田の言うとおり「削除したぶんの補充」が出来ない。

なのでオートページャーを組み合わせるか、GoogleAPIを使って別にサービスを作るしかない。

ドメインNGは -site:xxx.com で出来るから、それを検索ボックス自動入力するとかはできるかもしれない。

でもどちらにしろ続々と登場するクズサイトを手動でブラックリスト登録していくイタチごっこなので効果は薄い。

2016-12-05

プログラマー挫折ポイント

モバイルアプリエンジニアだが、最近RailsAPIを作っている

予想通り、ドハマリ連続

 

Rubyでハマる

Railsでハマる

ライブラリでハマる

Aptanaでハマる

AWSでハマる

ネットワーク知識でハマる

DBでハマる

ActiveRecordでハマる

ルーティングでハマる

自分が何でハマってるかわからない

問題の切り分けができない

デバッグ方法が分からない

テストコードなんて書いてられない

ググっても出てこない

問題を切り分けるためにデータを用意して時間がかかる

公式サイト理解できなくて投げ出す

体系だったHowToを読もうとして、その膨大さに死にたくなる

猿でもわかる入門がわからない

一個覚えて、一個忘れる

情報が古くてハマる

途中で間違いに気づいて遠回りする

一個試して詰んで、別の方法試して詰んで、また元の方法チャレンジする

知り合いに聞こうとするが、何を聞いていいかからない

体系立ったHowToを調べるが、自分が知りたいことが何なのかわからない

ライブラリのReadMeとにらめっこする

飽きてはてブを見る

 

考えてみたら、モバイルアプリの方も似た感じだったな

大体2年位ずっとこれをやればいつの間にか慣れてるんだよね

体系だった本から地道に始められる人はすごいと思う

2016-11-08

ggcリポジトリの騒ぎは誰がいけなかったのか

http://d.hatena.ne.jp/shouh/20161107/1478521182

ggcについて

ggc とは Github Girls Collection の略で、女性 GitHub アカウントMarkdown でまとめたリポジトリでした。実装としては、Followings(自分フォローしたユーザ)の中から、あらかじめリストに書いておいた女性アカウント名のみを抽出して、アバター情報などを取得し、リスト化するというものでした。GitHub APIPython で叩いていました。

リポジトリ炎上している中見ましたが、女性を❤️の数でランク付けしているように見えました。(リポジトリが消えてしまっているので曖昧表現です…)

私はパット見でセクシャルハラスメントに当たるのではと感じました。

しかし、 http://d.hatena.ne.jp/shouh/20161107/1478521182記事ではpublicに晒されているデータを扱ったのになにが問題あるのかと書かれているように感じました。

このあたり

ここで思ったのは、ストーキングとは何だろう、ということです。私としては Google 検索やその他リンクなどから簡単に辿れる範囲女性エンジニア情報を集め、それをまとめて公開していただけで、ストーキングのつもりは毛頭ありませんでした。ストーキングって何なんでしょうね?

データを集めそれを公開しているだけならその理論も通じたのかもしれないと思いました。

ただ、データを集め、それを加工(自分目線ランク付け)を行い、その順に並べて、publicにそれを公開していたのはセクシャルハラスメントに当たるように感じます

じゃあこの人がいけないんですかね、もしかしたら、そういうことを考えることが出来ない環境で育ってきたのが悪いのかもしれないとか個人的には思いましたとさ。

またリポジトリgithubのstaffにより削除されたようですが、セクシャルハラスメントではないかというgithub issueが立っていたらしいので、

githubが幕を下ろさず、issueでのやり取りを見ていたらもう少し先が見えていたのかもしれないなぁと思いました。

2016-10-24

人生は短い

いわゆるプログラマをしているが、60歳で定年だとしてあと、今の年齢から数えて約30年しかない。60歳で定年するとしたら最後の数年は今ほどのパフォーマンスは出せないだろうし、自分の周囲を見る限り、新しいことができるのはギリギリ40代限界ではないかと思っている。つまりあ20しかない。

20年。自由に使える時間としては長いのか短いのか。自分は短いと感じた。

仕事プログラマをしているが、コンピューターサイエンス学位はない。

から外資系企業のjob boardに書いてある必須条件であるCS BSの項目を満たすことができない。これがずっと悔しかった。なぜもっと早くプログラミングに目覚めてCS学位を取らなかったのか。

CS学位を取ってマスターまで行っていれば、社会人になってからphpプログラミングを覚えて、以来ずっと仕事コードを書いてきた俺には見えない世界が見られたのではないか研究現場世界ITはどんな場所なのか。G社やM社やF社やT社で働くというのはどういうことなのか。それを見てみたかった。

仮にCS学位を取っていたとしても外資系企業プログラマとして転職できる可能性は高くはないと思うが、門前払いされているどうしようもない気持ちはぬぐえない。CS出身学生ならだれでも勉強する基本的データ構造アルゴリズムについてもその辺で売ってる本とネット知識による独学の経験しかないし、webアプリばかり作ってきたせいで知識は非常に偏っている。例えばコンパイラインタープリタについては全く分からない。

それが分かって何になる、お前の仕事はそのフレームワークに乗っかってひたすらWeb APIを書き続けることだ、という指摘はごもっともだが、それでも自分勉強してまだ見たことがない世界を見てみたいと願った。

から、周りに話したら多分笑われると思うけど来年とある大学院CS系の専攻を受けてみることにしようと決めた。

CSじゃないが学部卒なので受験資格はある。受験勉強として必死CS学部生が読んでそうな本を読んで、数学もしばらく触ってないので高校数学からやり直して、自分が院で研究したいテーマについても考えて、面接でどう自分を売り込めばよいか考えて(そもそも院の入試面接がどんな感じなのか全然知らんが)日々を過ごしている。

落ちるかもしれない。その時は今の職場でまた1年勉強貯金をしつつまた翌年受ければいい。

受かって無事卒業しても再就職先がないかもしれない。それでもいいと思った。今の職場で、何も変わらない平和毎日をのほほんと過ごして余生を過ごすよりかは、いっそ何もかもなくしてまたゼロからキャリアを積みなおした方がいい。その方が新しい景色も見えるのではないか

2016-09-26

いいこと思いついた

この俺のアイデアを見てくれ。

iOS10からSiriAPIサードパーティーに公開されることになったけど、Siri活用したユーザー行動分析プラットフォームを作ったらアドテク系の企業に受けが良いのではないかと。

プラットフォーム名前はもちろん「Siri Analytics」。(長いので適当に略して欲しい)

こいつをどう思う?

2016-09-20

DMMサービスAPI商品コメント提供停止されていた

さらながら、これはかなりショック。。。

API叩けば、DMMの色々な情報が一気に取得できたのに…

という訳で、今後はどうするのか考え中…

→ APIクローリングコメントを取ってくるしかないと判断

  ついでにCSVにするようにしよう。

つー訳でスクリプト作成しよう。

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