#!/usr/bin/ruby
require 'uri'
require 'net/http'
require 'json'
require 'csv'
site = ARGV[0]
json_uri = URI.parse("http://b.hatena.ne.jp/entry/jsonlite/%s" % [site])
response = Net::HTTP.start(json_uri.host, json_uri.port) do |http|
http.get(json_uri.path, "User-Agent" => "Mozilla/5.0")
end
json_data = JSON.parse(response.body)
json_data['bookmarks'].each do |bookmark|
puts [bookmark['user'], bookmark['timestamp'], bookmark['comment'], bookmark['tags'].to_s].to_csv
end

引数に取得したいページのURLを入れる。hatebuapi-csv.rbという名前で保存したとしたらこんな感じで実行。

% hatebuapi-csv.rb https://anond.hatelabo.jp/20180315######## ＞結果.csv

このケースでは朝の7時から爆発的にブクマが付き始める様子が分かる。

https://imgur.com/66FlJIB

Permalink | 記事への反応(0) | 00:28

2017-12-22

■Google Chromeのアドレスバー周りがバグみたいな挙動する

再現方法

「https://www.google.co.jp/」をコピーする(クリップボードに格納する)
Google Chromeで「https://www.yahoo.co.jp/」のページを開く
ショートカット「Ctrl+L」を押し、素早く「Ctrl+V」でGoogleのアドレスを貼り付ける
Enterキーを押す

どうなるか？

「Googleが開かれる」と思うじゃん？違うんだわ

Yahoo!JAPANがそのまま開かれる(再読み込みされる)

こうなってしまう

どうもCtrl+Lを押すと、0.5秒くらい空けて今現在のページのURIが選択状態になるっぽい

選択状態になる前に素早く別のURIをペーストしても、無視されて今現在のURIが選択状態になってしまう

マジでこれどうにかして欲しい

Permalink | 記事への反応(1) | 00:56

2017-11-05

■Google news RSSのURIが新しくなるらしい

12月1日に旧URIが廃止されるらしいのだが、新しいRSSの場所が分からん。

というか、配信終了なんだろうか。

Permalink | 記事への反応(0) | 20:02

2017-09-25

■anond:20170925210919

URI貼れ、実力が相応か見てやる

Permalink | 記事への反応(0) | 21:19

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

■てすと

　URIがどうなるのか実験。

Permalink | 記事への反応(0) | 12:27

2016-08-17

■コミケの薄い本って電子化しないの？

DL 販売をしろって話ではなくて、あくまでコミケ会場における頒布方式の話ね。

なんで紙媒体にこだわっているのだろう？

現地での同好の士どうしの触れ合いの場という意義を守るにしても

重くて数量が限られる紙の本オンリーである必然性はないよね？

例えば、QRコードが印刷された紙片をブースで100円とかで売る。

「これをスキャンすればデータを落とせます。よかったら感想コメもください☆」

とかでよくない？

QRコードの内容は、本データが格納されたクラウドへアクセスする認証スクリプトに、

GETでユニークなシリアルコードが予め入力されるようなURI。

別に NFCとかで送ってもいいけど。

もちろん従来どおりの紙の本500円とかと併売してもいいし、

紙の本が完売したらコード販売に切り替えていける。

実体物でしかありえないグッズの類ならともかく、

同人誌ならこれで救われる人もいると思うんだよね。

コミケット準備会が、シリアルコード生成アプリと、

コード認証機能を提供するWeb APIだかウィジェットみたいなのを

出してくれたらスムーズだけど、そこらへんも同人開発者の力でいけそうでしょ。

データ置き場も自分のサイトじゃなく、準備会の指定するクラウドにしちゃえば楽。

データで買ったが紙の本も読みたいって人に関しては、

シリアルコードをオンデマンド印刷業者に渡すと、

業者は印刷用データをDLできて、製本されたのが届く、みたいな

オプションサービスをどっかの業者が始めればいいだけじゃない？

1冊単位での印刷所利用が広がっていけば、

サークル参加者にとっても、見本誌や試し読み用のを

最小限刷るだけって選択肢も可能になる。

まあ印刷単価は高くなるけど、トータルの負担は減るでしょ。

これで身銭を切って印刷所課金した上に在庫リスク・不安を抱えなくても、

アプリから QRコードを多目に自宅のプリンタで印刷しとけばすむ。

ついでに見本誌もデータで納められるようになれば、

完全にデータだけ用意すればよくなる。

紙の本を否定するわけじゃないし、趣を考えると共存する方がいいけど、

積極的に電子化を取り入れたら、作る側にとっても読む側にとっても、

より便利で、よりフェアで、より可能性が広がると思うんだよね。

Permalink | 記事への反応(5) | 11:55

2016-08-09

■golangを半年近く使ってみて

シンプルで良い
並列処理強くて良い
http serverとして使った時、rails等と違ってオーバーヘットがほぼ無いのが良い
- akkaとかerlangとかアクター的なのいいかもしれないけど、なんか難しいし同じぐらいのパフォーマンス出せるゴルーチンいいと思う
- アクターは耐障害性？ちゃんと使えばエラー・リトライ処理とかで優位性が出てくるのかなーという理解。
- メッセージング的なアーキテクチャを組まないなら無理して奴ら使わなくてもいいのでは？
webでやりたいことは大体出来る
web frameworkはginやirisがよさ気。ginは最近国内でよく見る。
irisは最近 github start見る感じでは流行っているっぽいが国内でblog書いている人とかはあんまいない。middleware系が充実しているっぽいのでいろいろといちいち実装する必要がなさそう。
CORS, JWT のmiddlewareを自分で実装していたけど、iris見た感じ、公式で用意されている？？
ginのrouter、速度重視な仕様なので正規表現使ったりできない。富豪的プログラミングできない（自分でかませばできるけど）のでURI 設計でちょっと悩むことがある気がしないでもない。（筋よく設計すれば困らないのかなぁ）
ORMはdbrが個人的には好み。なんでもいいと思う(●´ϖ`●)
vendoring?やビルドはgbがいろいろと強力だけど、いろいろと標準の流れを外れているっぽいので、goらしく標準にそうならgvtやgovendなど良さそう。
- 別言語から来た人にはgbがしっくり来るきはする…。(僕はJVM系から来た人っす。)
- 最近軽いアプリ書いた時はgvt使った。ビルドはgo buildと標準を使うんだが、/vendorにサードパーティなあれをインストールするときだけgvt fetch github.com/xxx を使う。

後なんかweb系の企業がgolang 採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線。

今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか！

どっちもユーザーです！（ペアーズでは3名ぐらい逢った、メルカリではバイクとMacbook Air売ったなー。）

ポケモンGoとかやんねーし、地味に自分がよく使っているアプリやサービスから成功パターンを得るのがいいのかなぁ

なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが（CtoCなんだから当たり前か、何いってんだ）

人とコンバージョンしたいです。

Permalink | 記事への反応(3) | 03:59

2016-07-18

■アニONの男性差別が酷い

私はアイカツ！が好きだ。私は今や少ない第一話からのリアルタイム視聴者の一人で、アーケードゲームにも金を注ぎ、円盤も全て買っている。無論私のようなファンは沢山いて、様々な形でアイカツ！を買い支えてきたのだろうと思う。実際、アーケードで使用するカードだけで数十万は使っている。もちろん、この程度の金額はファンの間では珍しいものではない。

さて、アイカツ！は3年半に及ぶ放送を経て最終回を迎え、この春からアイカツスターズ！（以下、スターズ！）なる後継番組が始まった。後継番組とはいえ監督を含めたスタッフも変わっており、アイカツ！との直接的な繋がりは（今のところ）ない。

この先はアイカツ！のファンだからと言って必ずしもスターズ！のファンとは限らないという事を頭に入れて先を読んで欲しい。

ところで、ナムコ主催のアニソン好きが集うアニソンバー・カフェ「アニON（アニオン）」というものがある。明日からアイカツ！およびアイカツスターズ！とコラボイベントを行うらしい。その男性差別があまりに酷い。URIを張っておく。

アイカツスターズ！&アイカツ！オールスターズ！LIVEステーション | アニソン好きが集うアニソンバー・カフェ「アニON（アニオン）」

(1) カフェタイム: スターズ！の曲が流れる
(2) ラブリーパーティータイム: アイカツ！とスターズ！の曲が流れる　※男性のみのご入場はできない。
(3) LIVE タイム: アイカツ！とスターズ！の曲が流れる　※オタ芸やる人が来る。

表にまとめるとこうなる。

楽曲（オタ芸の有無）	親子	独身女性	独身男性
アイカツ！（オタ芸なし）	(2)	(2)	×
アイカツ！（オタ芸あり）	(3)	(3)	(3)
スターズ！（オタ芸なし）	(1), (2)	(1), (2)	(1)
スターズ！（オタ芸あり）	(3)	(3)	(3)

親子と独身女性は(1),(2),(3)の全てに参加できる権利を有しているため、アイカツ！の曲を聴きたい場合にオタ芸なしの(2)と、オタ芸ありの(3)を選択する事ができる。一方で、独身男性がアイカツ！の楽曲を聴こうとするとオタ芸ありの(3)しか選択肢がない。

要するに、男性ファンは割高な料金を支払った上にやかましいオタ芸の中でしかコンテンツを楽しむ事が許されないって事なんだが……。

は？

はあああああ？？？？？？？

どうかんがえてもおかしい。独身男性ファンと独身女性ファンに何の差があるの？

なんでこんな明らかな男性差別がまかり通るのか、心底理解できない。担当者は頭沸いてるのか？

性別で差をつける理由を明記しないと誰も納得しないでしょ。

この仕打ち、怨めしい。

Permalink | 記事への反応(3) | 21:33

2016-06-11

■【艦これ】個人的 備忘録

http://twitter.com/DoubleCrossK

↑

の情報があまりにも少なすぎるので個人的な補完用に。

艦これメインで描いてたが東方に出戻りor東方に手を出し始めたサークル
- 秋★枝（ロケット燃料★21）
- 伊東ライフ（伊東ライフ）
- はせがわ（ビタミンごはん）
- 由岐シュウカ（るくしあ大陸）
- 空向（雨漏り宿）
- NT/fiv（かんたんのゆめ）
- 瀬尾（TEDDY-PLAZA）
- 井戸屋（井戸屋）
- 藤島真ノ介（Heart Attack）
- くま（赤色バニラ）
- ユーゴ（アトモスフィア）
- 天乃ちはる（ゴロワーズブルー）
- レッサム社長（日常の狭間）
- たかさか（妖精時計）
- シミヤ（～狂堂～）
- 七篠創太（ナナシノ十字星団）
- あおいまなぶ（BlueMage）
- 田川げんご（オチンチンリーチ）：東方イベで艦これイベ主催を煽る漫画を頒布との情報
- uri（show and tell）
- そーま（海賊帆船）
- なぎ（げるまにうむ）
- 黒和（クロワッサン）
- うがつまつき（あさつき堂）

主にグラブルに乗り換え
- 彩社長（極彩色）
- 織越篠（HumanSystem）
- チョコ（チョコクロワッサン）
- 大出リコ（ヘルメットが直せません）

主にガルパンに乗り換え
- 炒りたて将軍（あっち系美少女）
- 愚者ああああ（ネーミングエラー）：デレマスも
- ポロロッカ（macareo）：ラブライブも
- えむぽん（光と魔法工房）：いろいろ手出しすぎ

主にアイマス（デレマスなど）に乗り換え
- アオジマ（桜吹雪）
- 魚（あじのひらき）：グラブルも
- ふじまる（不可思議）
- 宮下未紀（共月邸）

主にラブライブに乗り換え
- 猫間ことみつ（猫間家）：アイマスも
- ヒナユキウサ（ふるり。）：プリパラも
- ぐっさん。（オレん家超特急）：プリパラも

主にFGOに乗り換え
- でくの（月望）
- 酔月（酔月工房）
- なるみ（横須賀瑞交社）
- 笠猫（けものなべ）
- 雛姫（Loving×Loving）：デレマスも
- 寿（MOMOKO FACTORY）：デレマスも

その他に乗り換え
- 落槻あれれ（あれれ印）：おそ松
- ryo（PPK）：プリパラ
- Mihoco（イチゴ★ドロップ）：アイカツ
- ごう（家具おきば）：あんスタ
- 出雲アユカ（にゃんこ亭）：刀剣乱舞
- momo（くるみちょこ）：刀剣乱舞とグラブル
- たくみそ（半月目集会）：DQX
- かゆらゆか（kurousagi）：D.C.Ⅱ
- アカリ（クズのかけら）：パズドラ
- 天心藍（アゲドウフ）：プリキュア
- 桜沢いづみ（CHRONOLOG）：彼岸花の咲く夜に
- 和泉まさし（うたひめ）：ポケモン

艦これ描かなくなって艦これを見捨てたサークル
- pacchu（角部屋）
- 比村結石（比村乳業）
- abua（アバ番地）

http://anond.hatelabo.jp/20160404011536

↑

によると艦これを描いているサークル総数は年々減り続けているということで、しかもC90でもC89と比べて艦これの申し込み数が減っていた。

（C89＝2425サークル→C90＝2360サークル、しかし当選率が上がったので当選サークル数は同じ）

こういう艦これの危機に我先とジャンルを乗り換えて逃げ出すサークルは艦これへの恩を忘れた自分勝手な同人ゴロであり厳しく追及する必要があると思う。

特に東方が消えていれば今ごろ艦これ一色となっていたのは明らかで、東方のオワコン化に失敗した今逆に東方に流出するサークルは最も艦これに害なす存在であり、そのような背信行為は界隈全体で激しく弾劾し続けなければならない。

こういう厳格な風潮が界隈にもっと広がって艦これを無闇に捨てるサークルが減り、いつまでも艦これ同人が長続きすることを願って。

リストは随時更新予定

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

2016-04-01

■

このエイプリルフールネタをやるためにわざとURI貼り付けまくるネトウヨを放置して場末の掲示板感を演出させてきていた可能性ありそう。

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

2016-03-28

■

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います。

p.4

HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
gulpのgは小文字なのでよろしくです。

p.5

ん〜非常に大きな枠での話をしてますけど、これから出てくる項目がそれらを解決できるのかなぁと、不安がつのりますね
むしろ「なんでそんなルールを？」という質問が噴出しそうですが！？

p.6

こういうアジェンダの書き方、斬新ですね

p.8

EditorCodingってなに

p.9

コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです？
- まぁ、この後gulpタスクについて出てるんでしょう……
  - 出てこなかった

p.10

ちょっとだけ違和感のあるディレクトリ構成

p.15

FixとかAddとかはいいと思うっていうかみんなやってることなんですが、黒括弧はないでしょう。
日本語モードと英語モードを行ったり来たりするのだるいんですよ。
- Fix - about / フッターリンクを修正
- これなら「フッター〜」までを英語モードのまま書ける。

p.16

逆に考えるんだ。Thumbs.dbと.sass-cache/はバージョン管理しちゃっていいさと。

p.18

コードの品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

HTMLの話ですよね？　コードの品質が維持されない難読化や最小化やコンパイルってなんだろう。
あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。

p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
あと日本語が変なんで、それも。

p.20

NGってなってますけど、NGの理由が伝わってこないっすね。
divの閉じタグが不正なのはスペース関わらずNGだよ！

p.21、22

わたしはオッサンなんで、このルールは好きじゃないんですよ。
//で始まってると、ルート相対パスと見間違えちゃうんだよね。
それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
- ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
- 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
- なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

.editorconfigにどう書けばいいかをだな……。

p.25

HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

HTMLの正しさとは？
参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
あと、CSS ファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
「このスプレッドシートでは、年を行に、月を列した2010年から 2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
気遣いではなくウェブサイト製作者の責任として。
ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

いやいや、CSS”設計の”教科書ですからね、その本。
脱字なのかな！？

p.42、43

その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS 設計いらないんじゃないですかね。

p.44、45

セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
省略していいなら、省略のルールまで決めていきましょう。
教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

HEXの短縮は規定しなくていいと思います。
ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
gulpでできますし、ググれば出てきます。
ちなみに、#f00よりもredの方が1バイト少ないんですよ。
容量削減は人が思いつきでやるには不十分なのです。
そんなのはビルド時に機械がやればいい。
容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。