「API」を含む日記 RSS

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

2017-06-24

プログラマー技術力とは

やっと理解したけど、出来るだけコードを書かないことなんだな

GitHubでいい感じのライブラリを見つけて、sqlマイグレーション

サーバーレスコンフィグ設定もせず ほぼせず

スケーラビティawsEC2クラウドフロント、S3使っていいかんじ

AIAPIでなんとか

シコシココード書くのは古くなった感じある

2017-06-09

マウントをとろうとしてる?

自分SNSIT技術者コミュニティではない)でIT技術に関する独りごとを言うと、「こういう資料があるよ」とか「自分経験では○○だよ」と話しかけてくる人がいる。

しかし、話の内容はほとんど見当違いである。もう5年以上前になるが、以下のような話をされた。

HTML5で様々なAPIが追加されて、HTMLだけでできることが増える。JSはどうなっちゃうの、って感じだよね~」

この人は「HTMLだけでプログラムが書ける」とでも勘違いしていたのだろうか。当時Chromeには一部のAPIがすでに実装されていたから、一家言あるマン演出するなら、少しだけでも触ってみればよかったのに……。

「追加されたAPIを使って実際にプログラムを書く言語JSだと思いますが」と指摘したら、「自分JSをやったことないので詳しくない」と言葉を濁した。

最初のうちは「詳しくもないのにわざわざ話を振ってくるなんて変な人だなぁ」と思っていたが、何回か同じようなことを繰り返されるうちに、「もしかしてマウントをとろうとしているのでは」と考えるようになった。

しかけてくるのは、技術の話がしたいからではなく、自分の方が技術力があるとアピールしたいからなのではないか

会話としてもマウントとしても成立していないので、あまり真面目に取り合わないようにしているが……。

本人の中では成功して満足している(?)から、ずっと続けているのだろうか。

2017-06-06

自分の書いた増田一覧でブクマついた数のランキング表示するサイトとかどっかにない?

それかはてなが公開してるAPIのどれをどんなふうに使えば取得できるって情報教えて

仕様

エディットボックスOKボタンがあって、エディットボックスhttp://anond.hatelabo.jp/id/をいれてOKおしたら自分が書いた全増田を取得してブクマ数チェックしてランキングしてくれる

ブクマ数じゃなくていいねランキングにも切り替えられる

http://anond.hatelabo.jp/20170606143536

プラモデルで良く見る奴。要は『代わりに色塗って造りますよ』って事だけど、正直頼んでる奴馬鹿なんじゃないか

と思っていたけど、ゲームプレイ動画とか流行時代だし、作る過程無くて完成品見れれば満足な奴も居るんだな。そこまでして節約した時間スマホゲーやってるんだから、訳分からん

うへーあたまわるいなあ

製作代行頼む奴は、作ることではなく所有や鑑賞に価値見出してるだけ

分業化が進んで自分の得意なことや1番したいことに注力するだけ

製作が好きな奴は製作技術もついてくるのでその中でも特に技術あれば製作を請け負える、それだけ


これじゃ将来の技術者育たないわ、コピペテンプレAPIで楽になったとはいえ、今後はパッケージレベルで求めてくるやつばかりなんだからな。搾り取る側は助かるけど

プラモを作る技術に金が払われる、分業化・技術評価される土壌、どう見ても技術者育ちやすくなってるわ

そうやって金が欲しいくせにカネのやりとりに素直になれず

いちいちクライアントを見下さないと精神が持たない変なおっさん独り相撲

見苦しいしおいてかれるだけだよ

いやもう半分置いてかれてるおっさんだろうけどこういうの

制作代行とか言う闇

プラモデルで良く見る奴。要は『代わりに色塗って造りますよ』って事だけど、正直頼んでる奴馬鹿なんじゃないか

と思っていたけど、ゲームプレイ動画とか流行時代だし、作る過程無くて完成品見れれば満足な奴も居るんだな。そこまでして節約した時間スマホゲーやってるんだから、訳分からん

これじゃ将来の技術者育たないわ、コピペテンプレAPIで楽になったとはいえ、今後はパッケージレベルで求めてくるやつばかりなんだからな。搾り取る側は助かるけど

2017-06-02

結局プログラミングってライブラリってことで良いんでしょうか

自分プログラミングしてる感じしない

はいえ、じゃあお前が作ればいいとかいわれても作れる気がしない

なんていうか、全能感がない

正直これ俺のプログラムなの?ってかんじ。いえる自信がない

ライブラリライブラリライブラリ

とにかくライブラリ大事

あとAPI

APIAPIAPIAPI

結局プログラムってAPI操作することなのね

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

NAVERまとめTogetterのちがいがわから

どちらも人のツイート勝手にまとめてアクセス稼ぐことには変わらんと思うんだけど。

違いはTwitterAPI使ってる、すなわち法的にセーフかアウトかだけでしょ?

個人的にはそこはどうでもよく、人のふんどしアクセスを稼ごウロすること自体が気に食わないので、

違いがわからぬと申す次第

http://anond.hatelabo.jp/20170502102151

2017-05-01

はてなブックマークから見たInstagram

2010年3月5日シストロムはベースライン・ヴェンチャーズとアンドリーセン・ホロウィッツの2社からの元手資本としての財政支援、50万ドル資金調達を終えた。(Wikipedia)

2010年8月22日 08:44:06 ファーストブックマークを獲得 http://b.hatena.ne.jp/entry/instagr.am/

2010年10月6日 アプリ初版アップルApp Storeに登場した。(Wikipedia)

2010年10月6日 21:36:56 おそらく2番めのブックマーク獲得

2010年10月10日 17:41:49 おそらく3番めのブックマーク獲得。初のコメント「ただの馴れ合い空間になっていて残念。」

2010年10月14日 11時頃からブックマーク急増。同日15ブクマを集める。

2010/10/16 21:36 instagram.comへのファーストブックマーク http://b.hatena.ne.jp/entry/instagram.com/

2010年10月24日 写真コンテンツへの初めてのブックマーク。3ブクマを集める。削除済み。

2010年10月いっぱい伸び続けて100ブクマまで到達

2010年11月 写真コンテンツへのブックマークが盛んに行われるがどれも3ブクマで止まる。

2011年1月 TechCrunchの2010年ベストモバイルアプリに選定(Wikipedia)

2011年2月8日 API公開。ブログと開発ページがそれぞれ50ブクマくらいづつ集める。

2011/02/25 10:30 stagram APIサイトへのファーストブックマーク

2011/03/17 21:24 instagram.comドメイン写真コンテンツへのファーストブックマーク http://b.hatena.ne.jp/entry/instagram.com/p/CTW2m/

2011年8月から 2桁ブクマを集める写真が出始める。

2012年3月19日 257ブクマを集める写真が出現。史上唯一の100ブクマ超えインスタグラムhttp://b.hatena.ne.jp/entry/instagr.am/p/IWrF0rCp62/

2012年6月 instagr.amドメイントップページへの最後ブックマーク

2012年秋 instagr.amドメインへのブクマが激減、instagram.comドメインブクマする人が増える

instagram.comドメイン以降16万以上の写真ブクマされるが、3ブクマ以上された写真は180に満たないようだ。3ブクマ以上は旧ドメイン、新ドメイン同じくらいの数。

おじさんウケするサービス流行らない」インスタグラムプロが断言 - ホウドウキョク、2017年5月1日

https://www.houdoukyoku.jp/posts/11027

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時)

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