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アホ　→　コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ

以上です

Permalink | 記事への反応(4) | 21:37

2017-04-17

■Pixivがpawooを始めた理由は使命感なんかじゃないだろ

この文章は怪文書なので、真に受けるときっと怪我をするよ。

BazzFeedが「この火が消えないうちに」pixivが「マストドン」にいち早く企業として参入したわけなんて記事を出していたけど、PixivがやりたかったのはただTwitterのパイを奪うことだ。

そもそもPixivは以前から、TwitterやLINEなどの短文投稿型SNSを真似た機能を追加している。6年ほど前に追加された「ひとこと投稿」、ほとんど使われていない死に機能になっているけれど、文字数は140文字、Twitterと同じだ。Twitterを意識したものであることは想像に難くない。

コメント欄で利用できるスタンプ、あれもLINEスタンプからだろう。こちらはそれなりに利用されているようである。

これらをパクリ云々する気はない。機能の模倣はある程度どんなプロダクトにもあることだし、明確に何かの権利を侵害しているとは言い難いだろう。

ただ、PixivはTwitterのような短文投稿型SNSに近づけるための工夫を以前から行っていて、それはこれまでのところあまり上手くいっていなかった。

なぜPixivがTwitterのパイを狙うのか。それはPixivが以前、Twitterにパイを奪われたからだ。

日本でTwitterが流行する前、画像投稿型SNSの最大手はPixivだった。ふたばなどの匿名型サイトや弱小投稿サイトもあったが、Pixivにとっては特に気にするほどの勢力ではなかった。

絵師はこぞってPixivに投稿し、Pixivのuser数がステータスであった。

ところが、絵師がTwitterを日常的に利用するようになって、様子が変わった。

Twitterは流動性の高いメディアで、検索機能は弱いし、まして画像をTwitterで検索するのは非常に難しい。だから、画像のデータベースとしての機能は確実にPixivの方が強い。

一方で、リアルタイム性という点では、圧倒的にTwitterが強い。そして二次絵はTwitterでは非常に拡散しやすいコンテンツである（ある程度の質があれば、だが）。あっという間に数百数千のRTが貰える。投稿してすぐにフォロワーのファンから感想が来る。絵師にとってこれほど嬉しいことはないだろう。

その結果、絵師が描き上げた絵を真っ先に投稿するのはTwitterになり、PixivはTwitterに投稿された絵の単なる集積場と化してきてしまった。

もちろん、全部が全部そうではない。しかし、Twitterは確実にPixivの競合となり、Pixivがかつての力を取り戻すには、Twitterと同じようなリアルタイム性を手に入れなければならなかった。

そして、それは失敗した。これまでのところは。

そこに現れたのがmastodonだ。mastodonはTwitterによく似たインターフェイスで、Twitter ユーザーが移行するハードルは低かった。また、Twitter社の業績不振などのニュースによる不安も、mastodon ブームを後押しした。

さらに、mastodonはオープンソースソフトウェアであった。サーバー運営のノウハウと十分なインフラがあれば、即座に立ち上げが可能であり、また、開発者がいればいくらでも改造可能であった。

初めは個人の立ち上げたmstdn.jpにユーザーが集中したが、個人運営ではいずれ限界が訪れることは明白だ。こちらはこちらでさくらのインターネットなどが後押しをする体制になっているようではあるが、現状の運営権は個人の手にある。

Pixivが運営するインスタンスとなれば、データ全消しなどが発生する可能性は低いだろう。そうしてオタク系ツイッタラーは大勢pawooにアカウント登録した。

pawooが二次児ポで国交断絶されたというニュースも、ユーザー数増加に拍車をかけた。つまり登録すれば海外からシャットアウトされるレベルのエロが見れるのだから。

こうしてpawooは十分なユーザーを手に入れた。Pixivはあれほど欲しかった「画像投稿型リアルタイム SNS」の雛形を棚ぼたで手に入れたのだ。

こう考えると、pawooの国交断絶は実は大した問題でないことが分かる。Pixivが欲しかったのは、自由でオープンな世界中と繋がるSNS基盤なんかではない。ユーザー数が十分にあって好きに改造できる二次画像を中心にしたSNSだ。

だからむしろ、うるさいことを言ってくるくらいなら国交断絶くらい構わない。pawooの中で盛り上がればいいのだ。もちろん、新規のユーザーを獲得するためにも、その盛り上がりは多少は外から見えた方がいいけれど。

だからpawooが今本当にやりたいことは国交正常化ではない。Pixivとの連携を強化する機能の追加、より多くのユーザーを内部に囲い込むための仕組み作りだ。

もちろん、企業というものはそういうものだ。全く利益を出さないものに投資をするわけがない。それ自体はそんなに悪いことでもない。

だが、Pixivが今回これだけ即座に動いたのは、以前からリアルタイム SNSの計画があったからであって、使命感などではないのだ。

Permalink | 記事への反応(5) | 23:34

2016-12-31

■増田の管理画面ブクマ数出てくれないかな

ブクマのつかない過去は振り返りたくない。

３ブクマにセルクマは入れたくない。

ブクマのついたエントリだけ見て悦りたい。

しょうがないので、５USERぐらい越えたのだけ、非公開でセルクマしてる。

管理画面にブクマ数とフィルタ機能入れてくれないかな。

Permalink | 記事への反応(0) | 01:06

2016-12-27

■活躍しているVimmerを教えるよ

この記事は増田 Vim アドベントカレンダー2016の27日の記事です。

Vimに興味を持ってるけどtwitterで誰をフォローすべきか分からない・・・

そんな迷える羊たちにデータを提供します。

vim-jpで積極的に活動している(していた) 人達を調査してみました。

vim-jpの3つのリポジトリを見ればだいたい分かります。

vim-jp/issuesでは、issue作成数、コメントを投稿したissueの数を見ていきます。

vimdoc-ja-workingとvital.vimでは、コミットすることが重要なリポジトリだと思いますので、コミット数とPR数のみ見ていきましょう。

データは2016/12/27 17:00-19:00の期間にgithub からスクリプトで取得

vim-jp/issues issueを作成した数 (only member)

name	Open中のissue	Closedしたissue
DeaR	1	5
Flast	0	0
Kuniwak	0	0
SKAhack	0	1
Shougo	14	57
alpaca-tc	0	1
basyura	0	0
bouzuya	0	0
cocopon	0	0
crazymaster	4	3
deris	1	0
deton	0	3
eagletmt	0	3
h-east	8	42
hattya	2	1
haya14busa	3	11
ichizok	2	17
iyuuya	0	0
k-takata	8	45
koron	71	110
lambdalisue	0	1
mattn	39	129
nocd5	2	5
presuku	0	1
raa0121	2	4
rhysd	0	3
ryunix	0	0
saitoha	1	1
splhack	1	5
supermomonga	0	0
syui	0	0
thinca	28	68
tobynet	0	1
todashuta	0	2
tyru	11	23
ujihisa	1	1
withgod	0	0
ynkdir	6	16
zchee	0	0
zoncoen	0	0

vim-jp/issues コメントを投稿したissueの数 (only member)

name	Open中のissue	Closedしたissue
DeaR	3	16
Flast	0	1
Kuniwak	0	0
SKAhack	0	1
Shougo	47	168
alpaca-tc	0	3
basyura	0	0
bouzuya	0	0
cocopon	0	0
crazymaster	13	55
deris	4	2
deton	2	4
eagletmt	0	4
h-east	69	372
hattya	2	2
haya14busa	4	22
ichizok	16	52
iyuuya	0	1
k-takata	78	340
koron	136	374
lambdalisue	0	2
mattn	138	489
nocd5	3	8
presuku	3	8
raa0121	4	16
rhysd	1	12
ryunix	1	0
saitoha	7	15
splhack	2	6
supermomonga	0	1
syui	0	0
thinca	58	189
tobynet	1	1
todashuta	1	15
tyru	41	88
ujihisa	6	15
withgod	1	0
ynkdir	48	204
zchee	1	0
zoncoen	0	0

vim-jp/vimdoc-ja-working Commitした回数 (all user))

name	コミット数
k-takata	302
ynkdir	294
crazymaster	256
koron	239
nakinor	95
mattn	87
thinca	64
kashewnuts	47
h-east	35
tyru	29
rhysd	24
cougar-b	21
rbtnn	15
deton	14
sgur	6
aiya000	5
haya14busa	5
saitoha	3
Milly	3
machakann	2
norisio	2
todashuta	2
Shougo	2
oshow	1
lamsh	1
ichizok	1
miyakogi	1
natnu	1
pocke	1
shiracha	1

vim-jp/vimdoc-ja-working PRした回数 (only member)

name	Open中のPR	ClosedしたPR
DeaR	0	0
Flast	0	0
Kuniwak	0	0
SKAhack	0	0
Shougo	0	0
alpaca-tc	0	0
basyura	0	0
bouzuya	0	0
cocopon	0	0
crazymaster	0	5
deris	0	0
deton	0	0
eagletmt	0	0
h-east	0	1
hattya	0	0
haya14busa	0	0
ichizok	0	0
iyuuya	0	0
k-takata	0	4
koron	0	6
lambdalisue	0	0
mattn	0	14
nocd5	0	0
presuku	0	0
raa0121	0	0
rhysd	0	1
ryunix	0	0
saitoha	0	0
splhack	0	0
supermomonga	0	0
syui	0	0
thinca	0	0
tobynet	0	0
todashuta	0	0
tyru	0	3
ujihisa	0	0
withgod	0	0
ynkdir	0	0
zchee	0	0
zoncoen	0	0

vim-jp/vital.vim Commitした回数 (all user)

name	コミット数
thinca	721
ujihisa	480
tyru	414
lambdalisue	270
haya14busa	145
rhysd	118
mattn	104
Shougo	83
syngan	60
rbtnn	45
crazymaster	43
kamichidu	32
aomoriringo	31
deris	22
cohama	10
hattya	8
itchyny	8
ichizok	7
Milly	5
raa0121	5
ryunix	5
zoncoen	5
aiya000	4
kozo2	2
anekos	2
basyura	2
kannokanno	2
suy	1
deton	1
koron	1
m4i	1
nicoder	1
pocket7878	1
gitter-badger	1
termoshtt	1
alpaca-tc	1
firisu	1
tacahiroy	1
y0za	1

vim-jp/vital.vim PRした回数 (only member)

name	Open中のPR	ClosedしたPR
DeaR	0	0
Flast	0	0
Kuniwak	0	0
SKAhack	0	0
Shougo	0	5
alpaca-tc	0	1
basyura	0	1
bouzuya	0	0
cocopon	0	0
crazymaster	0	23
deris	0	9
deton	0	1
eagletmt	0	0
h-east	0	0
hattya	0	4
haya14busa	0	23
ichizok	0	6
iyuuya	0	0
k-takata	0	0
koron	0	0
lambdalisue	2	35
mattn	1	7
nocd5	0	0
presuku	0	0
raa0121	0	6
rhysd	0	13
ryunix	0	3
saitoha	0	0
splhack	0	0
supermomonga	0	0
syui	0	0
thinca	1	54
tobynet	0	0
todashuta	0	0
tyru	0	28
ujihisa	0	11
withgod	0	0
ynkdir	0	0
zchee	0	0
zoncoen	0	2

数字で見ると一目瞭然ですね。

数字は裏切りません。

数字が2桁ある人はほぼ活躍しているとみなしてよいでしょう。

綺麗に0が揃っている方々は実力を発揮していないだけなのかもしれません。

評価されるべき人が評価される世の中にしましょう。

Permalink | 記事への反応(0) | 18:49

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

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

Permalink | 記事への反応(1) | 18:17

2016-12-07

■http://anond.hatelabo.jp/20161207020046

依存性地獄( Dependency Hell )かな。https://en.wikipedia.org/wiki/Dependency_hell

An application depends on many libraries, requiring lengthy downloads, large amounts of disk space, ...

(アプリケーションがたくさんのライブラリに依存していて、長時間のダウンロードや大量のディスク容量が必要で、...)

app depends on liba, which depends on libb, ..., which depends on libz. This is distinct from "many dependencies" if the dependencies must be resolved manually (e.g., on attempting to install app, the user is prompted to install liba first. On attempting to install liba, the user is then prompted to install libb.).

(アプリケーションがAを必要としていて、そのAはBを必要としていて、(中略)Zを必要としているような場合。ユーザーが手動で依存性を解決しなければいけない場合には、先ほどの例とは違い、ユーザーは「アプリケーションをインストールしようとしたらAが必要と言われ、AをインストールしようとしたらBが必要と言われる」目に遭うことになる)

Permalink | 記事への反応(1) | 02:39

2016-11-30

■開発コミュニティの人柱 行為に辟易する話

ここ数日のJXUG (Japan Xamarin User Group) の話を見ていてなんだかなーと思っていたが、ついに主宰がコメントとポリシーを出した。

これでこの話「だけ」は終息に向かって行けばいいと思う。

今回の件は、担ぎ上げられた方の性別や過去の言動も相まって盛り上がってしまったが、男性だったら同じことが起こっていたか、という問いかけには「起こりうる」と答えたい。

一つの例を出す。

「『テスト書いてない』なんてそれ○○の前で言えるの？」「テスト書いたから大丈夫です！」

これは、別コミュニティの男性の話を基に持て囃された言葉で、IT 業界でコードを書いている人なら似たような内容を見聞きした方も多いだろう。

当の本人は、テストだけにフォーカスされてしまっている事を良いと思っておらず、一つの手段である事を伝えるために苦労しているようだ。

男女問わず、コミュニティの中で誰かを担ぎ上げて人柱にする事は起こる。

コミュニティ内の交流会や発表の場で、ちょっとした有名な方の記念日を祝う事もあるだろう。外部の人がそれを見ても問題のない表現は幾らでもできる。

しかし、コミュニティ内の発言を Twitter等で確認すると「内輪向けすぎて、ないわ」と感じる。イベントログでも同様である。

件のピラミッドが描かれたスライドは、新規参加者を疎外するには十分なもので、現場に居た参加者が「これはマズい」と思わなかったのであるなら、非常に危険な状態ではないか。

考えてみてほしい。何の知識もなく興味だけがある未来の開発者が、その画像を見た時の事を。コミュニティに参加するためには、まず自分は一般ピープルの扱いを受け、ピラミッドの上部と「人脈」として繋がらなくてはならない。それはXamarinを利用するためのコストでは無い筈だ。

自分はMSのプロダクトは気に入っている。また、Visual Studioを普段から利用している。Windows 開発者かと問われれば、Windows 開発者でもある、と答えるだろう。そして、XamarinもVisual Studio for Macも良い方向へ進化していく事に期待している。

だが、少なくとも、現状のコミュニティには参加しようとも思わないし、必要な技術情報や交流は国外の物を利用し、参加するだろう。

あくまで、このコミュニティに限った話であるため、他のコミュニティで邂逅しても特に何も思わない。

一つ、コミュニティポリシーの経緯について。今回の件に影響を受けすぎているように感じるため、中性的な表現に修正した方が良いものになるのではないかと提案したい。

JXUG 名古屋ハンズオンでの事実について - Xamarin 日本語情報

それでは、より良い開発を。

Permalink | 記事への反応(0) | 22:11

2016-11-29

■どんだけ取り繕っても本音は見えてるんだよ

http://b.hatena.ne.jp/entry/310264282/comment/ytabuchi

JXUG のポリシーを明文化しました http://jxug.org/policy.html

ほー

それじゃ、散々燃えたのでここら辺のお気持ちが変わったと言うことですかね。

@y_chu5 大丈夫です。ああいうのは一次的なものでわかってる人はわかってます。— 田淵義人＠エクセルソフト (@ytabuchi) 2016年11月26日

@khb02323 あ、コミュニティのヤツは外野がヤンヤン言ってるだけなので私はスルーしてますw iOS/Androidが書けたらXamarinに踏み込まなくても良いかな？って感じるのは良くわかりますが、そこを乗り越えてもらうにはどういうアプローチがいいのかなーって悩んでます。— 田淵義人＠エクセルソフト (@ytabuchi) 2016年11月27日

今日はスルー力が試されるな。— 田淵義人＠エクセルソフト (@ytabuchi) 2016年11月26日

ポリシーを明文化するのと発端になった話にけりを付けるのは別の話だと思うんですけどね。臭いものに蓋をしたまま良い感じの道具だけ置いてみただけでしょ。

.@chomado ぁわわ、そんな話になってたとは。すみませんm(_`_)m

この場でいっときます。
それを言ったのは私です！断じて、ちょまどさんじゃありません。— 山本康彦＠BluewaterSoft (@biac) 2016年11月26日

「ぁわわ」じゃねーよ、これこそ Japan Xamarin User Group のトップにまともな謝罪文として載っけておくべきだろ。起こったことが断片的にしか伝わってないから余計に「あの女エヴァンジェリストはダメだ」って誤解が広がってくんだろ。ユーザグループと、そしてエヴァンジェリストを守りたければ誰が何をやらかしたのか、そしてその人が偉い立場の人であるなら一定以上のごめんなさいを示すべきだろ。