「API」を含む日記 RSS

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

2017-04-29

#ナゲッツ親子

ツイッターAPIでできるのか知らんが、大企業自動返信なんかやったら迷惑まりないな。ちゃんと反省しろよ。

2017-04-21

Orarioとスクレイピング大学側の対応について

すでに学生でもないのになぜこの件について書いているか自分でも分からないが、例の穏便でない大学教授発言ブーストされた感がある。

まず前提として、ID/パスワードを用いてスクレイピングを行うサービスのものは、特殊というほどではない。そのようなサービスはすでにいくつも存在するし、最も有名なところでは口座アグリゲーションサービスMoneyForward等)だ。彼らは業としてそのようなサービスをおこなっている。セキュリティのこと少しでもわかる人間ならそんなサービスやらない、というほどでもない。ただし、セキュリティが分かる人間であればあるほど慎重になる、というのは確かではある。通常ID/パスワードを渡すということは、全権委任とおなじだ。また、ログイン後の行動について、自分がやったか第三者がやったか、全く判別できない状況になる。さらに通常のWebセッションと同等だとすると、パスワードリセットから完全なアカウント乗っ取りまであり得る。つまりサービス事業者に対してよほど強い信頼関係がなければ厳しい、ということになる。

クラウド上で動いているかスマホ上で動いているか、という話は、それほどは重要ではない。クラウドしろスマホアプリしろ、すべてサービス事業者側の組んだプログラム意図に従って動くものであることは確かだからだ。

ただしクラウド上ではユーザが想定していない動作を行っているのかどうかという検証しにくいという問題があるとはいえる。とはいユーザが予め意図した行動から外れることをしてないのであれば、クラウドからアクセスでも別にそれは問題ないわけで、その点で、Orario側の主張であるスマホで動かしているのだから」という主張は、ちょっと見当はずれではある。

なお、ユーザインタラクションを介さな自動的アクセス自体サービス要件に含まれ場合スマホでは厳しいためクラウドアクセス主体が置かれる、というのは、まああり得る。口座アグリゲーションはその典型的ものだろう。Orarioの場合は、たぶんその必要はないのだと思う。

正規手段として学認があるのになぜしない?という主張は、マジでひどいと思う。普通に考えて、ぼっと出の1ベンチャートラストサークルに加えてもらえると思っているのか。このような主張は、Google/Facebookレベル自由APIクライアント登録ができるようになっていて、初めて言えるものだろう。通常は、世に受け入れられるサービスが出て初めて実行力を認めてもらえる、にわとりたまごの話ではないのか。そもそも、学認のShibboleth仕様で、そのような履修情報のやりとりがそもそもできるようになっているのか疑わしい。ホントSSOできるだけではないのか?

大学側にお伺いを立てるべき、という筋論は、そりゃそうかもしれないけど、やっぱりにわとりたまごだと思う。ビジネスの筋論っていうやつは、内輪だけの論理になっている場合が多いし、正直ステークホルダー既得権益側だったりするわけで、話が通じるとは思えない。そのようなもの破壊していくのは常に外部からだろうし、それを単なる破壊行為ではなくDisruptionにできるのは唯一ユーザからの支持であるわけだけど、Orarioは最低限そこはできていたようにもみえる。例の教授はどうも内側のメンバーの感じがひしひしと出ており、傍目から見ると、そりゃそのポジションじゃあね感が強い。

事業モデルがわからいから怪しい、事業が成り立つとしたら収集したデータ第三者への販売ぐらいしかないはずだ、という主張は、気持ちはわかるもの論理として弱い。怪しいサービスに預けるな、というのは、意見の表明ではあるかもしれないが、普遍的に怪しさを証明するには根拠が足りていない。利用規約レベルではまだなんとでもいえる。逆に言うと、Orario側は、そういう色が少しでもあったのでは?と思わせるような内容を否定してさえいけば、その点では勝てるが、やっぱりそこは何らかの形で検討して行きたかったのでは、とも思えるので、そういう将来の自分たち制限することはことはあまりやりたくないだろうなとは思う。

結論を言うと、とりあえず大学側はもうすこしトーンを落としてほしい。このままではFUDだといわれても仕方ない。単位云々の脅しは傲慢以外の何物でもない。少なくとも卒業生にとってそのような大学いたことを恥じるレベルである。嫌なのは分かるが、銀行とかだってそうだったはずだ。もうすこし長い目で見てあげられないのか。ID/パスワードを預けることのユーザへの注意喚起は、もちろん正当だが、それを認識して預けていることについてとやかく言うことは得策でない。

そして、Orario側は、自分たちがやっているサービス説明に少し時間を割いてもいいと思う。特に何をどのように取得しているのか、明確にすることは重要だ。大半のユーザたちはそういうこと気にしないとしても、自分たち自身自分たちサービス定義するのに役に立つし、今はEvilでなかったとしてもいつかEvilになってしまうのを防ぐという意味合いもある。面倒かもしれないが、取得範囲を明確にすることは信頼を得るということであり、最終的にユーザの獲得に寄与するだろう。

2017-04-20

サービス作りの何が面白いの?

私は、Ruby on Rails仕事をしているエンジニア

だけど、自分で「サービス」を作るつもりは全然ない。

ところが、RoR エンジニアたちは、自分サービスを作るのが好きな人たちが多いみたいだ。

ただ、彼らが作ったサービスを見ても、あまり面白いと思わないんだよね…。

私は、サービスに対して保守的で、普段ほとんど新しいサービスを使わない。

携帯電話でもほとんどアプリは入れていないし。

Google Chrome といくつか有名なウェブサービスを使えば、ほとんど用は足りてしまうじゃん派。

正直、もっと重要なのは社会インフラサービス化。

いま、面倒くさい紙の書類を作って郵送したり、あるいは直接事務所に出向かないとできないような、

税申告や各種の国・自治体への届け出のオンライン化とか。

銀行口座を直接いじれるAPIとか(これは一部の銀行が公開しはじめているみたいだけど…

UberAirbnb みたいなサービス重要だろうと思う。

これらは、地道な実業がバックにあって、それをより便利にするためにウェブサービスを作っているものたちだ。

こういうウェブサービスなら否定しない。

ただ、エンジニアが「ちょっと作ってみました」みたいな、思いつきにすぎず、実業的な裏付けがないようなサービスなんて、

ほとんど何の意味もない気がするんだよね…。

2017-04-19

流行ってるOrarioと大学側について思うこと

Orarioについて思うこと

Orarioについて

現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、

ひとまずこの記事については、下記URLにある、京都大学専門家であらせられる記事について、一人歩きしてる感があるので、

もう少し彼のような上流側(という表現で良いかどうかは不明だが)の専門家ではなく、

下流プログラムガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。

  

https://srad.jp/~yasuoka/journal/611343/

  

  

不正アクセスという言葉曖昧

Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。

  

Orarioの特性安全性について、本当にスクレイピング技術クライアント端末側で行っているのであれば、

この部分は間違いではないと私(匿名で失礼)は考えている。

  

この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。

  

KULASISにずっと不正アクセスを繰り返していて

  

上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である

逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である

  

何せ、開発者勝手アカウントを使って入り込んで様々な検証を行う必要があるため、

学生からIDパスワードを借りたはずだ。

借りてログインするのが不正かというと微妙ラインだと思う。

  

この辺りにもやっぱり大学教授のいやらしさがあって

KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、

あくま大学側が定める規約規則から若干外れた使われ方がされているという意味不正アクセスである

  

法律的には、正直不正かどうか微妙ラインになる。

(そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない

  

開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大規約によれば、不正アクセスにあたるのかもしれない。

個人的には当たらないと感じるが。

  

  

現在動いているアプリ不正アクセスと断言できない

現在動いているもの不正アクセスではなく、

京大規定に定められたユーザが「特定ブラウジングツール(Orario)」により、

KULASISにアクセスしているのだからアクセスとしては不正ではない。

本当にスマートWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、

それを不正アクセス断罪してOrarioは不正というのは表現が汚いと考える。

  

  

これはコメント欄にもあるが、

https://srad.jp/comment/3196554

また、ChromeSafari(及びその他マイナーWebブラウザ)なども御校のWebサーバーよりコンテンツデータを取得し、HTML構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか?

  

ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。

それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、

Webブラウザ一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう

京大ユーザが開発に携わったか証明できない以上、彼にとっては不正なのかもしれないが、

ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。

  

  

アクセスパターンを公開できない理由とは?

他にもこの部分

Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン(にインストールされているOrarioアプリ)に学生アカウント大学IDパスワード)を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要情報のみを取得し、Orarioアプリ時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています

全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ

  

この部分も怪しいものである

Webスクレイピング技術に関して、なぜアクセスパターン問題になるかが一つ疑問である

下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング切り貼り)している。

  

それをアクセスパターンを解析で一体何が取れるのか?という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。

  

もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティ観点上公開すべきではないだろうか、

逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである

  

ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから

アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、

学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である

学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。

  

そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、

現在すでにスクレイピング確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。

(ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……

(もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。

  

たとえKULASISが京都大学オリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。

同様に日立富士通も同じような大学教務事務パッケージがあるが、

基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、

本当だろうか?嘘を書くのもいい加減にしろ? と思う。

大学側について思うこと

なぜOrarioが学生に人気か

UIが糞(システムスマートフォン対応がノロい)だからアプリ流行るということに気づくべき。

  

富士通日立にしてもそうだが、API提供したほうがいいのではなかろうか。

とくにKULASISだったか何だったは、京都大学謹製と聞いている(違ったら失礼

少なくとも他の大学教務事務パッケージではなかったと記憶している。

であれば、京都大学API提供大学側で専門家を集めてOrarioを超えるものを作ってはどうか?

  

大学予算確保の問題

実際大学でこういうことをやろうにも、問題になってくるのは予算で。

大学は、縦割り構造で、横とのつながりが極端に薄く。

教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。

これが実に糞で。

つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。

  

その辺りが難しいのは知っているので文句は言えないものの、

ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。


まとめ

学生がアホ → 仕方が無い若いんだし

大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ

教授がアホ → 曖昧表現で、素人を先導しようとするのが見え見えで気に入らない

Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ


以上です

Facebook APIの融通の効かなさは異常。開発者としてはさっさと滅んで欲しいサービスの筆頭。

2017-04-12

IT業界全然進歩してなくて笑えてくるw

業界20年目だけど、まるで成長してない(安西先生)って感じる事ばかり

20年もこんなマッチポンプに付き合わされればそりゃ愛想も付きます

なにか目的があって、それを機械解決してほしいだけなのよ

一部のプログラミング大好きサーバー大好きっ子はその手の仕事が好きなのかもしんないけどこっちはそんなことしたくねーよ

だって本質じゃないだろ?

なんでプログラミング言語処理系ケアまでなんでこっちがしなきゃいけないの?アップデートに付き合わされなきゃいけないの?

自分要望目的をしたいことリストアップ言語かなんかに書いておいて、実現する技術はその時々で最適なものを選定してくれませんか?

したい事は変わらないのにプログラミング言語やらOSアップデートされたので開発をやり直します!ってあきれて物も言えないわww

最近流行りのAI技術とやらで、ここら辺解決してくれませんかね?

2017-04-07

http://anond.hatelabo.jp/20170407112743

意識低い企業研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。

働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。

C言語とかC++・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、

WindowsAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。

組み込みプログラミングではC言語はいまだに現役。お金普通に稼げると思うよ!次代のCOBOLと化しそうで怖いとこはあるけど。

Java・・・使える人が多いからあえて今から学習しなくてもいいような気がする。

文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有セオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。

セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから

Go・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。

ライブラリ選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。

GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。

Goデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。

GoGUIつくるの?あんまり普通じゃない気がする。軽量プロセスうまみがそんなない(詳しい人に否定されそうだけど)

普通にC#(mono/.net)かwebアプリにするかで良くないか

ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。

20言語Hello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。

コミュ症がフランス語英語ドイツ語覚えても、使う機会がないとまったく価値がないと思う。

アルゴリズムは使うものだ書くものではない!!

広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。

twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。

一応著名なプログラマーTwitterフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像RTしてたりと、twitterはメインの情報収集としては利用してない。

twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いか自分からリプは送ったりはしない。

ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。

深さ優先探索とか理解できない。

コード写経しても覚えられないし、仕組みは理解したけど自力コードが書けない。

コードにする能力ってどうやって鍛えるのか知りたい。

アルゴリズムは使うものだ書くものではない!高階関数とかテンプレートプログラミングとかその辺勉強するといい。

あと計算制限時間内に終わるなら総当たりが最速で品質も高いぞ。

エディタサクラエディタからVimに変えた。

どうしてVimかというとプラグインが多いしIDEっぽくできるから

Vim使う一番の理由は補完が強いのが気に入ってるから

Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。

NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。

Vim知らない。Linux使うならVimemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。

パソコンスペックもどのくらいのものを用意したらいいのかわからない。

10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートからプログラミングに向いてないのかもしれない。

VirtualBox上のubuntuMySQLコンパイルすると2時間20分ぐらいかかった記憶がある。

CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。

スペックお金をかけることで時間節約ツール選択肢が増える

EclipseなどのIDEが支障なく使えるレベルスペックってどのくらいするんだろう。

ノートCore i3メモリ4GBにランクアップしたらいけるのかな。

他人がどんなスペックPCで何のツール使ってプログラミングしているか知りたい。

3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。

もっと早いPCが欲しいけど、年度末に買うのを忘れた。

Python・・・機械学習する上で避けて通れないけど、今のPCだと無理。

例題が豊富逆引き辞典みたいなサイトや本がほしい。

あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。

過大請求されるの怖いし、トラブルが起きた時に英語コミュニケーション出来ないから。

Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。

使ってないけど最先端研究では機械学習使って当たり前感があってそろそろヤバい

僕は中学生の頃、いじめにより心の余裕なんてなかったか勉強どころではなかったけどもっと英語勉強しておけばよかったと後悔している。

やっぱり子供の頃の生活環境って大事だなと思う。

今は英検3級に向けて勉強中。

APIドキュメント頑張って読もう。俺も頑張って読んでる。

何を学習したらいいのか本当にわかんない。

迷宮にいる感じ。

なんとなく、プログラミングじゃないほうがいい気がするなあ。

とりあえずバイトしてPC買わない?プログラミングバイトでもいいと思うよ。

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

プログラミングの学び方がわからない

C言語とかC++・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、

WindowsAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。

Java・・・使える人が多いからあえて今から学習しなくてもいいような気がする。

文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有セオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。

Go・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。

ライブラリ選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。

GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。

Goデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。

ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。

20言語Hello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。

コミュ症がフランス語英語ドイツ語覚えても、使う機会がないとまったく価値がないと思う。

広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。

twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。

一応著名なプログラマーTwitterフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像RTしてたりと、twitterはメインの情報収集としては利用してない。

twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いか自分からリプは送ったりはしない。

ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。

深さ優先探索とか理解できない。

コード写経しても覚えられないし、仕組みは理解したけど自力コードが書けない。

コードにする能力ってどうやって鍛えるのか知りたい。

エディタサクラエディタからVimに変えた。

どうしてVimかというとプラグインが多いしIDEっぽくできるから

Vim使う一番の理由は補完が強いのが気に入ってるから

Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。

NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。

パソコンスペックもどのくらいのものを用意したらいいのかわからない。

10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートからプログラミングに向いてないのかもしれない。

VirtualBox上のubuntuMySQLコンパイルすると2時間20分ぐらいかかった記憶がある。

CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。

スペックお金をかけることで時間節約ツール選択肢が増える

EclipseなどのIDEが支障なく使えるレベルスペックってどのくらいするんだろう。

ノートCore i3メモリ4GBにランクアップしたらいけるのかな。

他人がどんなスペックPCで何のツール使ってプログラミングしているか知りたい。

Python・・・機械学習する上で避けて通れないけど、今のPCだと無理。

例題が豊富逆引き辞典みたいなサイトや本がほしい。

あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。

過大請求されるの怖いし、トラブルが起きた時に英語コミュニケーション出来ないから。

僕は中学生の頃、いじめにより心の余裕なんてなかったか勉強どころではなかったけどもっと英語勉強しておけばよかったと後悔している。

やっぱり子供の頃の生活環境って大事だなと思う。

今は英検3級に向けて勉強中。


何を学習したらいいのか本当にわかんない。

迷宮にいる感じ。

2017-04-05

http://anond.hatelabo.jp/20170404154007

FAXって、なんだかんだ言って送信からしたら、電子化されてるより楽なことってあるんだよな。

例えば、ニッチ商品群の注文書をどこかの現場作成して、問屋に流すとする。

A.Fax利用の場合

1.現場で注文書に手で記載 → 2.FAX

B.メールで送る場合

1.現場で注文書に手で記載 → 2. メールに転記 or スキャン → 3. メール書いて添付して送る

C.電子化されている場合の例

1. iPadの注文アプリを起動、注文書新規作成やらやって、入力して送信

アプリ次第ではあるが、1ステップで済むようで、紙より楽にはならない可能性が高い。かつ、端末の維持・管理の手間が発生する。

この中だと、送信からしたら、FAXが一番楽だってなりがち。

また、発注側としては、それほど発注作業を多くやっているわけではない場合や、

注文のシステムアプリを構築したり(何か既存のを利用するにしても)するほどのものでもない場合など、

電子化したほうがオーバーヘッドが大きいとかもありうる。

尚、つい最近SMS送信APIなどを提供しているTwilioが、今更ながらFAX対応するとのニュースがあったくらいなので、

まぁ、相応に需要があって、これから先もなくならないという算段なんだろうな。

2017-04-04

プログラマとして就職するときの後悔

私は地方情報専門学校の生徒です。

今年度卒業予定であり就活手前ですが、今まで何もしてこなかった自分への苛立ちと後悔を感じています。なぜそんなことになったのかを自分の気晴らしに書きます

今までやってきたことが足りなかった

専門学校入学するのは「プログラマになるための最短ルート」だと思い、学費大学より安いことから専門学校入学。前年度は学校では基本情報技術者勉強をするだけ。基本情報技術者を無事取得しましたがプログラミングの授業はゼロに等しかったので、個人企業apiajaxを利用した簡易的なwebアプリケーションを作ったりしました。

今年度に入り学科就活解禁日より二足ほど早く、プログラミングスキルを判定できる新卒エンジニア向け就活サイト大企業様のスカウトを受け採用試験に挑戦。結果は不採用で通知メールにはコミュニケーション問題なかったが、技術力が足りないと書かれていました。

私はCentOS多目的サーバ高校時代から運用し、webアプリケーションを作った経験国家資格をもあれば十分だろうと思っていたことが甘かったと痛感。

面接(というより面談)の対応をしてくださった方はとても良い方で、面談の中でエンジニアは常に最新技術へのアンテナを貼るべきで学生のうちは何でも作ってみるべきだと教えてくれました。

その教え通り私は今何かを作ろうとしています。それでも自分の中でプライベート時間プログラミングに割くことができず娯楽に使ってしまう心の弱さに苛立ちを感じているのです。

何とかしてプログラムを完成させ、社内開発の会社に入りたい…そう思いながら今日も生きます

ちなみに学校斡旋する企業はどこも社員数30名以下の下請け人材派遣会社なので自分リクナビ等使って探しています

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=投稿のあとの数字とかできたらいいのになあ。

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