Poem

界隈のレベルを下げるエンジニアの特徴

2018-02-12T07:20:12+00:00

辟易してる

名称を正確に書けない

XCode
Github
Javascript
Ocaml
OpenSUSE

スライドが汚い

文字詰めすぎ
色味なさすぎ
デザインにこだわりがなさすぎる
人に見せるなら見やすい資料を作れ

リポジトリが汚い

バイナリファイル置き場として使ってる
ライセンスがない
.DS_Storeとかthumbs.dbとかpushしちゃう
READMEに内容がない

アウトプットがクズ

誰でも知ってることをQiitaとかに書いちゃう
ドキュメントをろくに読まずに記事書いちゃう
仕様を確認してから意見しろ
動かないコードを記事に書いちゃう
WordPressとか使っててエスケープされてたりするのに気づかず動かないコードをそのまま載せちゃう

情報収集が雑

一次ソースを特定できない情報を鵜呑みにしちゃう/拡散しちゃう
ブラック企業は嫌いなくせに権利関係がブラックなコンテンツは拡散しちゃう
パクツイをRTする程度のリテラシーの低さを晒す自己紹介いつもご苦労様です

守るものは守れ

法律を守れ
条例を守れ
権利を侵害するな
労基法を守れサービス残業するなブラック企業の養分になるな潰せ

プログラミングに限定しない知識でも記録・共有したくなるようなブログテーマを作った

2017-05-13T13:00:00+00:00

Markdownで気軽にポエムが書けるサイトがあったような前世の記憶があるのですが、みつからなかったのでGitHub Pagesで色々な知識をひけらかすためのJekyllテーマを作りました。ライセンスはMITです。

mzyy94/jekyll-kieta-theme: Clean knowledge sharing jekyll theme

その名もKieta。最初のKはKnowledgeのKということだけ決めていますが、名前の由来は特にありません。

リポジトリからファイル一式をダウンロードしてきて、Jekyllの作法に従って設定してMarkdownで記事を書くとこのように仕上がります。

特徴

自由な設計

オープンソースなので好きなようにカスタマイズができます。たとえばサイドバーにAmazonの広告を表示して、みんなに充電池をオススメすることができます。

モダンなCSSフレームワーク

みんな忘れかけていたであろうTwitter Bootstrap 4を採用しています。
ReactだVueだの騒がれているこのご時世、コンポーネントとしてではなくCSS単体として提供されているBootstrapを使っている人は少ないかと思います。
俗にいうBootstrap臭がツンと来る人も多く、あまり好まれて使われてこなかったBootstrapですが、基本テーマをフラットデザインに近づける努力を続けています。
そして間も無くベータ版が登場するTwitter Bootstrap 4では、Flexboxなどの機能を引っさげて大幅な更新を仕掛けて来る予定です。

そんなTwitter Bootstrap 4を一足先に導入しました。今回は執筆時点の最新版alpha-6を利用しています。

基本テーマの調整

Twitter Bootstrapの最も自己主張の強いコンポーネントにJumbotronがあります。このKietaテーマでも強い存在感を放つ記事のタイトル部分にそれを用いています。
Jumbotronの協調される色は記事の印象も左右するため、Jekyllの設定ファイルにて変更ができるようにしてあります。

color: deepskyblue

記事にはタグがついていますが、それをタグであるとわかりやすく表示するために工夫しました。タグ自体は1つのａタグですが、これを「タグ」っぽく表示させるために擬似要素を用いてデザインしています。ついでにJekyllのsite変数から全投稿の中のタグ利用数を表示してあります。

.tag {
    background: lightgrey;
    color: black;
    outline: none;
    position: relative;
    font-size: 0.9rem;
    height: 1rem;
    line-height: 1rem;
    padding: 0 8px;
    display: inline-block;
    margin: auto 20px;
    &::before {
        content: '';
        height: 0;
        position: absolute;
        width: 0;
        border: 0.5rem solid transparent;
        border-right-color: lightgrey;
        left: -1rem;
        top: 0;
    }
    &::after {
        content: attr(data-count);
        display: inline-block;
        padding: 0 0.5em;
        text-align: center;
        color: white;
        background: darkslategrey;
        position: absolute;
        margin-left: 8px;
    }
}

追従する目次

技術系記事に限らず、文書の全体のどの位置を読んでいるかが把握できないとモヤモヤするので、常に目次が見れるようにしました。
この記事をデスクトップPCやタブレットで読んでいる方は、右側に目次が追従してきているのがわかると思います。これはtscanlin/tocbotを利用して実現しています。

新鮮なポエムをあなたに

古いポエムには警告が表示されるようにしました。Jekyllは素のLiquidとは違って、数値の比較が動かなかったのでがんばりました。

{% capture one_year %}{{ 60 | times: 60 | times: 24 | times: 365 }}{% endcapture %}
{% capture current_time %}{{ site.time | date: "%s" }}{% endcapture %}
{% capture year_old %}{{ page.date | date: "%s" | minus: current_time | divided_by: one_year | plus: 1 }}{% endcapture %}
{% if year_old contains '-' %}
<div class="alert alert-warning" role="alert">
    <i class="fa fa-clock-o" aria-hidden="true"></i> This article is more than 1 year old. Please read this page keeping its age in your mind.
</div>
{% endif %}

数々のシェアボタン

ポエムはいろいろな人に共有していきたい気持ちが高いと思うので、思いつく限りのシェアボタンを設置しました。
参考にした公式ドキュメントは以下の通りです。

コメント機能とコメント数の表示

コメント機能はGitHub Pages利用者にはおなじみのDisqusを利用しています。また、Jumbotronにタイトルとタグだけを表示して置くだけではあっさりしすぎていたので、いっしょにコメント数とツイートボタンを表示しています。
このコメント数は、DisqusのAPIで取得できるものを整形して出しています。Disqus側で出力を変えられるのですが、ちょっと利用環境の都合でこんな細々とした作業を入れてあります。

<script>
var MutationObserver = window.MutationObserver || window.WebKitMutationObserver;
if (MutationObserver) {
  var obs = new MutationObserver(function(mutations, observer){
    var mutation = mutations[0];
    var count = mutation.addedNodes[0].textContent.replace(/[^0-9]/g, '');
    document.getElementById('comment_count').textContent = count;
    mutation.target.parentNode.removeChild(mutation.target);
    obs.disconnect();
  });
  obs.observe(document.getElementById('disqus_comment_count'), { childList:true, subtree:true, characterData: true });
}
</script>

404ページ

うっかり遭遇すると悲しいページである404 Not Found。悲しさを紛らわすための工夫として、新鮮なポエムが流れるようにしておきました。

まとめ

検閲のない自由なインターネットを謳歌しよう。

😀😬😁😂😃😄😅😆😇😉😊🙂☺️😋😌😍😘😗😙😚😜😝😛😎😏😶😐😑😒😳😞😟😠😡😔😕🙁☹️😣😖😫😩😤😮😱😨😰😯😦😧😢😥😪😓😭😵😲😷😴💤💩😈👿👹👺💀👻

2017-04-25T10:00:00+00:00

管理用リンク: 1コメ(業務連絡) 2コメ(業務連絡) 3コメスクリプトを見る

😎 よくないね 😎 よくないね 😎 よくないね

👎よくないね新バージョン開発中！ 👎よくないね集計

✉新着メッセージ(全て見る)✉

2017/04/26 タイトルの前後で関連性がないという編集リクエストがたくさん飛んできたので最初の状態にもどしました！

2017/04/26 技術系のタグをつけたのはプログラミングの話だからね！文句は運営に言ってね！

2017/04/26

2017/04/25コードだよ

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <link href="https://fonts.googleapis.com/css?family=Bangers" rel="stylesheet">
    <title>@JAVASCRIPT</title>
</head>
<body>
    <canvas width="360" height="60">
        <span style="
            font: 68px 'Bangers';
            color: #24f;
            text-shadow: 1px 0.5px 0 #888, 2px 1px 0 #888, 3px 1.5px 0 #888;
            font-weight: 100;
        ">@JAVASCRIPT</span>
    </canvas>
    <script>
        var span = 8
        var x = 10
        var y = 56
        var text = document.querySelector('span')

        var canvas = document.querySelector('canvas')
        var ctx = canvas.getContext('2d')
        ctx.font = text.style.font

        var canvas2 = document.createElement('canvas')
        canvas2.width = canvas.width
        canvas2.height = canvas.height
        ctx2 = canvas2.getContext('2d')
        ctx2.font = text.style.font
        ctx2.fillStyle = ctx2.shadowColor = "white"
        ctx2.shadowBlur = 1

        var offset = span
        function draw() {
            ctx.clearRect(0, 0, canvas.width, canvas.height)
            ctx.fillStyle = "#888"
            for (var i = 1; i <= 3; i++) {
                ctx.fillText(text.innerText, x + i, y + (i/2))
            }
            ctx.fillStyle = text.style.color
            ctx.fillText(text.innerText, x, y)

            ctx2.clearRect(0, 0, canvas2.width, canvas2.height)
            for (var i = 0; i < 7 * span; i+=span) {
                for (var j = 36; j < 36 + 22 * span*2; j += span*2) {
                    ctx2.fillRect(j - i, i, 1.6, 1.6)
                }
            }
            ctx2.globalCompositeOperation = "destination-in"
            ctx2.fillText(text.innerText, x-offset, y-offset)
            ctx2.globalCompositeOperation = "source-over"
            ctx2.drawImage(canvas2, 0, 0)

            ctx.drawImage(canvas2, offset, offset)
            offset = --offset || span 
        }
        draw()
        setInterval(draw, 100)
    </script>
</body>
</html>

2017/04/25デモ追加❤️

https://jsfiddle.net/7p4wrhfr/

2017/04/26 数あるゴミ記事を差し置いてこの記事を限定公開にするとはさすが！！技術的内容が皆無な記事よりはコード貼ってあったりして「ぷろぐらみんぐと関係のある投稿」ではあるんだけどなー？

漢はコードで語れと言われてきた2020年代の今も説明文を書かなきゃいけないのびっくりだけど、わざわざ説明してあげるね！

トップの画像にあるような若干立体的な文字の表面にドット模様が動いてるロゴをcanvasで作ろうと思った時、どうやって表現するかのお話。

立体っぽく見せるために斜めにずらした灰色の文字を３回描画します。

 for (var i = 1; i <= 3; i++) {
     ctx.fillText(text.innerText, x + i, y + (i/2))
 }

表面の文字を描画します。
```
 ctx.fillText(text.innerText, x, y)
```

別のキャバスにドット模様を描きます。

 for (var i = 0; i < 7 * span; i+=span) {
     for (var j = 36; j < 36 + 22 * span*2; j += span*2) {
         ctx2.fillRect(j - i, i, 1.6, 1.6)
     }
 }

文字の型でドット模様を切り抜きます。

 ctx2.globalCompositeOperation = "destination-in"
 ctx2.fillText(text.innerText, x-offset, y-offset)

ドット模様を濃くします。

 ctx2.globalCompositeOperation = "source-over"
 ctx2.drawImage(canvas2, 0, 0)

ドット模様を描いたキャンバスを文字の書いてあるキャンバスに載せます。
```
 ctx.drawImage(canvas2, offset, offset)
```

offsetをずらして動いているように見せてるよ！

よくないねボタン0.1 ～ReactからVueへ、そしてFluxの消失～

2017-04-11T13:45:14+00:00

よくないねボタン - Poem
よくないよ。こんなこと
大好評をいただいているよくないねボタンですが、おかげさまで512よくないねを達成しました:tada:
それを記念して、大幅にちょっとだけ変更を加えました。バージョン：0.0.4⇒0.1.0
変更点をご紹介します！

RFC 7807に対応した

めちゃくちゃどうでもいいことですが、エラー表現をRFC 7807に対応させました。エラーなんて見る人いないと思いますが、ちゃんとContent-Typeはapplication/problem+jsonになっています。

ReactからVue.jsに乗り換えた

だいたいここに書いてあることに共感したためです。
私たちはなぜReactではなくVue.jsを選んだのか | プログラミング | POSTD

忌まわしきJSX

必要な道具が多すぎる

React+ReduxからVue+Vuexに乗り換えました。

利点1：トランスパイルいらず

トランスパイルとかうんざり。そもそもこんなミクロなプロダクトにReactはデカすぎた。

利点2：コード量の減少

Reactですべてがすべて出来上がっているページではなく、拡張機能としてページに対してコードをインジェクトしているため、どうしてもDOM操作が絡んできます。その都合上、Reactのクリーンな設計を前にしても、document.querySelectorでごちゃごちゃ弄っている部分が多くありました。
Reactでは、仮想DOM¹（？）で作られたCoolな要素をインジェクションするためのdivラッパーを挿入したり、各コンポーネントに分けたクラスをrenderしたりするためにコンポーネントの定義とは別に追加で多く書く必要があったりしていました。

対してVueではコンポーネントの定義と同時にelオプションでマウントする要素を指定でき、1つのコンポーネントで記述量が減りました。
全体のコード記述量も減り、Reactで各コンポーネントに分かれたjsxファイルとindex.jsファイルの累計コード行数が200行を超えていたのに対し、VueではCommonJSを意識しなくしてindex.jsファイルのみに収め、160行程度になりました。
トランスパイル後のReactで書いたものが20000行を超えていたのに対し、Vueのほうはというと、vue.jsとvuex.jsとindex.jsの行数を足し合わせても10000と数百行になりました。

Fluxモデルをやめた

React+ReduxからVue+Vuexに移行したものの、Reduxの時と変わらずFluxストアに対する値の操作がとてもめんどくさいものでした。Fluxストアに対してdispatchする日々は変わらず、そもそも大げさにState管理をするほどでもないことに気付いたのでFluxやめました。ReduxでsetStateばかり書いてあるコード見るのも辛いしね。
そもそもなんでステート管理をしていたかというと、各コンポーネント間でよくないねの状態を共有する必要があったからでした。

digraph G {
	graph [
	layout=neato
	];
	edge [
	labelfloat=false
	];
	"Store" [shape=doublecircle];
	"LikeButton" [shape=box];
	"Label" -> "Store" [label="count", style=dotted ,len=2];
	"Button" -> "Store" [label="diasliked", labelfloat=false, len=2, labelloc="t", labeljust="r"];
	"Button" -> "Store" [label="liked", style=dotted, len=2];
	"Warning" -> "Store" [label="count >= 2, style=dotted, len=2];
	"LikeButton" -> "Store" [label="liked", len=2];
	"LikeButton" -> "Store" [label="disliked", style=dotted, len=2];
}

Vueは全体の状態の値の変化を即座にキャッチしてくれるので、ReduxのsubscribeやgetStateを必要としません。
そのため、Fluxによる管理をやめて、値を最も多く扱うコンポーネントに値を保持させ、それを他のコンポーネントから参照させる形にしました。

digraph G {
	graph [
	layout=fdp
	];
	edge [
	labelfloat=false
	];
	"LikeButton" [shape=box];
	"Button" [xlabel="liked, disliked"];
	"Label" [xlabel="count"];
	"Warning" -> "Label" [label="count", style=dotted, len=2];
	"Button" -> "Label" [label="count", len=2];
	"LikeButton" -> "Button" [label="liked", len=2];
	"LikeButton" -> "Button" [label="disliked", style=dotted, len=2];
}

これでVuexとはおさらば、さらにコード記述量が減り、140行程度まで小さくなりました。vue.jsとindex.jsを合わせても10000行にも満たなくなりました。

Vue.jsのセキュリティ上の懸念点

Vueは便利に書ける反面、セキュリティ上の懸念点が少々あります。よくないねの設定ページもVueで記述していたのですが、最初は動かなくてとても困っていました。いろいろ調べていると原因はCSPでした。
Content Security Policy (CSP) - Google Chrome
Chrome拡張機能はデフォルトでscript-src 'self'; object-src 'self'のポリシーが割り当てられています。しかし、VueJSはテンプレートのコンパイルにnew Function()を用いているようです。
インストール CSP 環境 - Vue.js
この問題を解決するために、CSPを変更して安全でない評価関数の実行を有効にしてあげる必要がありました。これにより、悪意のあるコードが設定ページに注入されることが万が一にでもあった場合、その攻撃を受けてしまう可能性が微粒子レベルで上昇してしまいました。
まぁそこまで気にすることではないんですがね。

ポップアップメニューを追加してよくないね総数を確認できようにした

よくないね総数を確認して世のよくない記事の数を聢と見よ。

Semantic UIやめてUIKit3にした

そもそもどこでそんなUIがあったのか気づいてない人多いと思いますが、設定ページのUIがそれです。
Semantic UI使ってた理由がReactコンポーネントとして使えてたからってたけなので、UIKit3(beta)に変えました。UIKitは昔と比べて見た目が良くなってきましたね。

よくないねページから直接インストールできるようにした

よくないね総数が見られるyokunaine.mzyy94.comのページから拡張機能をダウンロードできるようにしました。Inline installationを試してみたかったので。
Chrome Extension inline installationの使い方 - Qiita

おしまい

なんかいっぱい書こうと思ったけど疲れたのでおしまい。前回予告していたyokunaineの実装に関するGoodな点の話はいろいろと語り尽くされてる感じがして書くのめんどくさいのでコードみて確認してください。

仮想DOMの内部の動き | プログラミング | POSTD ↩

よくないねボタン

2016-12-04T10:10:00+00:00

いいねだけじゃ　だめなんだよ。

良い記事を書くためのガイドライン - Qiita:Support

こういうガイドラインがあるけども、これに沿った良い記事なんて半分もないんだよ。
質問の場所と勘違いしている記事や、READMEを貼り付けただけの記事、ブックマークサービスとしてURL貼るだけの記事ばかり。
Googleで「あれどうやるんだっけ」と調べるとトップにQiitaが出てきて開いてみると、
「このブログにやりかたが書いてありました！」なんて記事ばっか。
そんなんだったらそのブログに検索トップの座をゆずれよお前の記事が邪魔してるんだよ。

そして先日、良い記事がごく少数なのにもかかわらず「👍いいね」ボタンなる間抜けな実装が追加されてゴミ記事にうんざりしている人たちは憤怒ですよ。

「いいね」が使えないのはどう考えてもQiitaが悪い - Qiita

もうだめだよね。「👍いいね」なんて。どうせなら「🍣すし」にしてほしかったくらいだよ。

Twitterの仕様変更を受け入れられなくなったので:heart:を:sushi:に変えて精神を落ち着かせる - Poem

Qiitaの「👍いいね」がイラっとするので内容の無いポストに対して「👎よくないね」を付けるウェブサービスとChrome拡張を作りたい
— はいふり@3日目東v-14a (@mzyy94) 2016年11月24日

と、愚痴を言いだしたら冬コミの薄い本以上に書き上がりそうなのでほどほどにしておいて、
おなじみの技術で歯向かえ「いいね」ボタンの新作、「👎よくないね」ボタンが出来上がりました。

mzyy94/yokunaine: よくないね。

今回はChrome拡張機能として実装しました。Firefoxは知りません。
拡張機能をインストールしてトークンを取得すると、各記事によくないねボタンが現れます。
ためしにこの記事に「👎よくないね」をつけてみてください。

震えて眠れプロポエマー pic.twitter.com/19gGUsZFDa
— はいふり@3日目東v-14a (@mzyy94) 2016年11月28日

先日Lightsailなるお手軽なインスタンスが立ち上がったのでAWSで「よくないね」の数を集計します。
使い方は上記リポジトリを確認してください。

追記：

動かない人、ちゃんとREADME読んでオプションページからTOKEN取得してね！！！ pic.twitter.com/lcqSpKcA9s
— 岬明乃@3日目東v-14a (@mzyy94) 2016年12月4日

あとがき

~~たぶんこの記事も利用規約 - Qiitaに違反しているとかなんとか言われて消されるんだろうなぁ。~~
~~ほかにもっと消えるべき記事はたくさんあるのに。~~
~~もし消えなかったら2017年に向けたモダンな技術をふんだんに使ったこの拡張機能の技術説明記事を書いてもいいかなーって。~~
~~この拡張機能ほんとすごいんだよ。~~
~~拡張機能の方のコードはReact+ES2015だしサーバの方のコードなんて200行足らずで描き上がってるんだよ。~~
~~めちゃくちゃ機能の紹介したいよ。JavaScriptの良さみんなにいっぱい知ってほしいよ。~~

B−CASリーダをDocker内で読もうとしてlibpcscliteのバージョン違いではまった話

2016-07-03T07:35:00+00:00

ChinachuをDockerに入れようとしたらカードリーダーがB−CASをうまく認識しなくてつらかった話。

結論から言うと、ホストのpcscdとゲストのpcsc_scanのpcscliteのライブラリのバージョン違いが問題でしたって話。
要するにこんなかんじ（表1)。

表1. 要するにこんなかんじ

OS	libpcscliteのバージョン
CentOS 7.2	pcsc-lite-libs 1.8.8
Debian jessie 8.5	libpcsclite1 1.8.13

pcscdの使うライブラリのマイナーバージョンよりpcsc_scanのライブラリのマイナーバージョンが新しいと動かないということだった。
解決する方法は２パターンあって、

ホスト側（pcscd側）のライブラリのバージョンを1.8.8で保持してゲスト側(pcsc_scan側）を1.8.8以前にダウングレード
ホスト側のライブラリを1.8.8以上にアップデード

今回はホスト側を汚さないように前者の解決策をとって、wheezy向けのlibpcscliteをインストールして解決した。
おしまい。

以下、駄文なので見なくていいです。

そもそもなんで動かなかったの？

CentOS側で動かしてるpcscdにDebian jessieからpcsc_scanしてみたときのpcscdのログがこちら。

08174657 winscard_msg_srv.c:230:ProcessEventsServer() Common channel packet arrival
00000030 winscard_msg_srv.c:242:ProcessEventsServer() ProcessCommonChannelRequest detects: 9
00000007 pcscdaemon.c:93:SVCServiceRunLoop() A new context thread creation is requested: 9
00000098 winscard_svc.c:299:ContextThread() Thread is started: dwClientID=9, threadContext @0x555636dee7f0
00000025 winscard_svc.c:317:ContextThread() Received command: CMD_VERSION from client 9
00000009 winscard_svc.c:329:ContextThread() Client is protocol version 4:3
00000005 winscard_svc.c:338:ContextThread() Client protocol is 4:3
00000004 winscard_svc.c:340:ContextThread() Server protocol is 4:2
00000007 winscard_svc.c:349:ContextThread() CMD_VERSION rv=0x8010001D for client 9
00000238 winscard_svc.c:309:ContextThread() Client die: 9
00000024 winscard_svc.c:928:MSGCleanupClient() Thread is stopping: dwClientID=9, threadContext @0x555636dee7f0
00000007 winscard_svc.c:934:MSGCleanupClient() Freeing SCONTEXT @0x555636dee7f0

クライアント、死す: 9って書いてあるように、クライアントが死んだらしい。

対して同じCentOSホスト上でpcsc_scanを実行した時のpcscdのログがこちら

99551719 winscard_msg_srv.c:230:ProcessEventsServer() Common channel packet arrival
00000041 winscard_msg_srv.c:242:ProcessEventsServer() ProcessCommonChannelRequest detects: 9
00000008 pcscdaemon.c:93:SVCServiceRunLoop() A new context thread creation is requested: 9
00000103 winscard_svc.c:299:ContextThread() Thread is started: dwClientID=9, threadContext @0x555636db2f80
00000027 winscard_svc.c:317:ContextThread() Received command: CMD_VERSION from client 9
00000011 winscard_svc.c:329:ContextThread() Client is protocol version 4:2
00000005 winscard_svc.c:349:ContextThread() CMD_VERSION rv=0x0 for client 9
00000123 winscard_svc.c:317:ContextThread() Received command: ESTABLISH_CONTEXT from client 9
00000026 winscard.c:193:SCardEstablishContext() Establishing Context: 0x42ADED6E
00000007 winscard_svc.c:410:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 9
00000130 winscard_svc.c:317:ContextThread() Received command: CMD_GET_READERS_STATE from client 9
00000108 winscard_svc.c:317:ContextThread() Received command: CMD_GET_READERS_STATE from client 9
00000093 winscard_svc.c:317:ContextThread() Received command: CONNECT from client 9
00000021 winscard.c:235:SCardConnect() Attempting Connect to Gemalto PC Twin Reader 00 00 using protocol: 2
00000007 readerfactory.c:739:RFReaderInfo() RefReader() count was: 1
(略)

クライアント、死なずにちゃんと最後まで動いた。

ログのdiffをとったら怪しい行があった。

+ Client is protocol version 4:3
- Client is protocol version 4:2

なにが違うのかstraceで確認してdiffしたところ、pcscdに対してpcsc_scanが送ってくるバイナリが違う部分があった。

+ read(9, "\4\0\0\0\3\0\0\0\0\0\0\0", 12) = 12
+ write(1, "00000116 winscard_svc.c:329:ContextThread() Client is protocol version 4:3\n", 75) = 75
- read(9, "\4\0\0\0\2\0\0\0\0\0\0\0", 12) = 12
- write(1, "00000116 winscard_svc.c:329:ContextThread() Client is protocol version 4:2\n", 75) = 75

なるほどクライアントがサーバに要求するプロトコルバージョンが違うのか。

で、libpcscliteの変更を疑って変更履歴を見てきたらビンゴ！プロトコルバージョンがちょうど1.8.8以前と1.8.9以後で変わっていることがわかった。

pcsc-lite-1.8.9: Ludovic Rousseau
16 October 2013

SCardEndTransaction(): Return an error if is called with no
corresponding SCardBeginTransaction()
（中略）

Check the Info.plist file is (a minimum) correct

Update PROTOCOL_VERSION_MINOR from 2 to 3
（後略）

https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/PCSC.git;a=blob;f=ChangeLog;hb=HEAD

ホスト側はCentOS 7.2でlibpcscliteのバージョンが1.8.8、ゲスト側が1.8.13だったというマイナーバージョン程度の違いだけれども、後方互換を残さないような大きな変更があったとは疑いもせず１日をとかしてしまったというポエムでした。まぁ解決できたのでめでたしめでたし。

Twitterの仕様変更を受け入れられなくなったので:heart:を:sushi:に変えて精神を落ち着かせる

2015-11-04T07:50:00+00:00

昨夜未明、Twitter社はとある仕様変更を発表し、同時に実装に踏み切った。
今まで:star:として記されていたFavoriteが:heart:のLikeに変更となったのだ。
そしてこの一方的な変更を我々は強いられることとなった。

とまぁ我々がTwitter社の強制をそのまま受け入れるはずもなく、日本全国・世界各国でこの仕様変更に物議を醸し出している。
とりわけ日本の文化として、何においても:sushi:が至高であるという共通認識が全国民に常識として行き渡っているため、「:heart:になるくらいならば:sushi:にしてしまえ」という考えも多く出ている。
我ら日本人、技術力を駆使して外資系の企業に屈せぬよう努力を重ね、１日たたずとして世には:heart:を:sushi:に変更するプラグインなりが多数公開され、エンジニア各位がTwitter社に意思表明をしている。
私も仕様変更を知った時、敏感に反応した一人である。

Twitterの⭐️を🍣に変項すればこんなに問題視されなかっただろうに
— 友利奈緒 (@mzyy94) 2015, 11月 3

これを呟いた直後、Twitter社に意思表明すべくとある行動に出た。

俺は何をやってるんだ https://t.co/f9eDZ5NKGU pic.twitter.com/viNXuG3E3w
— 友利奈緒 (@mzyy94) 2015, 11月 3

CSSユーザースタイルシートを利用し、:heart:ボタンを:sushi:に置き換えるという意思表明をした。
直後、グレースケールの画像も用意し、仕様変更から１時間足らずで実用的な:sushi:ボタンの実装案を公開し、強い意思表明を行った。

🍣ボタンのグレースケールを追加して🍣の実用性が高まる pic.twitter.com/2MQbkUD3NK
— 友利奈緒 (@mzyy94) 2015, 11月 3

追い打ちをかけるように、:heart:ボタンのアニメーションを真似たさらに強力な:sushi:ボタン意思表明を訴えた。

♥を🍣にするためだけにChrome拡張書くのはスマートじゃないから「いいね」の文字含め全部User Stylesheetでやろうと:after擬似要素やcontentで頑張って「いいね」を「すし」に書き換えてたけど結局のところ🍣アニメーションが製作できずで公開に踏み切れずにいる
— 友利奈緒 (@mzyy94) 2015, 11月 3

しかしTwitter民としてはあろうことか、まだ昼の26時であるのにもかかわらず眠気に襲われ、アニメーションの制作は断念。おふとぅんへと吸い込まれて行ったのである。

夜が明け目がさめると、私の意思表明に賛同した数千のTwitterユーザーからの熱い:heart:が届いていた。

「こんなたくさんの:heart:に溺れさせられるTwitterはTwitterじゃない」

タスクの順序を整理し:heart:を:sushi:に置換する作業のプライオリティを最高に設定した。
すると、:sushi:アニメーション界のプロによってアニメーションの提供を受けることとなった。

あとでみっきー氏に🍣アニメーションを送って公開してもらおう。
— みくげっと (@3qgt) 2015, 11月 4

いただいた画像を取り込み、ユーザースタイルシートによってアニメーション及びTooltipの文字を置換するCSSファイルを完成させた。

Twitterの仕様変更を受け入れられなくなったので:heart:を:sushi:に変えて精神を落ち着かせる - Qiita https://t.co/slx55fcZ07 pic.twitter.com/CRrUMWhziE
— 友利奈緒 (@mzyy94) 2015, 11月 4

like2sushi

https://github.com/mzyy94/like2sushi

[2015-11-4 18:38追記] @3qgtさんによるChrome拡張機能がマージされたので、Chromeに導入の際はリポジトリのREADME.mdに記載の手順でワンステップで:sushi:化できる。

ユーザースタイルシートとして:sushi:を適用する先駆者がすでにおられるので、導入方法はそちらを参照されたい。
Twitterのふぁぼマークを寿司にする - Qiita

以上、快適なTwitterライフのため、少しでも力になれたらと思う。

koaで画像拾ってきてそのまま返すyieldableでスマートな処理

2014-04-22T16:51:00+00:00

別のサーバーにある画像ファイルを、koaで動作しているサービスから渡す必要に迫られました。
そんなときにもkoa。スマートに仕上げてくれます。

コード (sample.js)

var koa = require('koa');
var route = require('koa-route');
var app = koa();
//-- ここから下はcoのサンプルから
var thunkify = require('thunkify');
var request = require('request')
.defaults({ encoding: null }); //←これがミソ！
var get = thunkify(request.get);
//!-- ここまで

app.use(route.get('/hoge.png', function *(){
var url = 'http://www.google.co.jp/images/srpr/logo11w.png';
var img = yield get(url);
this.type = img[0].headers['content-type']; //ヘッダー付ける
this.body = img[1]; //Bufferオブジェクト
}));

app.listen(3000);

実行

node --harmony sample.js

結果

curl -v localhost:3000/hoge.png
もしくは
open http://localhost:3000/hoge.png (OS X限定)

まとめ

yieldを使った非同期処理を同期っぽくこなす場合はその処理がyieldableである必要があります。
httpをつかったファイルのダウンロードをyieldableな処理で実行するサンプルコードは、koaのベースとなるCoのReadmeに書いてあります。
今回はそちらの利用方法を参考にさせてもらいました。

Coにあるサンプルコードのままでは、バイナリデータを扱うようなことはできません。
request.getが取得したデータをテキストとして解釈してしまうためです。
それを防ぐために、default({ encoding: null })とオプションを指定します。
これで正常にバイナリデータをBufferとして扱えるようになります。

JSONオブジェクトを渡した際は、Content-Typeがapplication/jsonにセットされていたのですが、今回のようにBufferが渡された場合は、application/octet-streamがセットされてしまいます。
仕方がないので、this.typeにダウンロードしたファイルのHTTPヘッダ情報から得たContetn-Typeを入れてあげます。

そこまでスマートではないですが、今までのcallback地獄よりはきれいに書けると思います。

koa、使わない手はないでしょう。

koaでJSON返させるシンプルで唯一の記述

2014-04-21T10:30:14+00:00

koaでRESTなものを作ろうと思ったときにJSONでオブジェクトを返す必要がでてきました。
いろいろなことが便利になったkoa、JSONを返すコードも素敵に書くことができます。

コード (sample.js)

var koa = require('koa');
var route = require('koa-route');
var app = koa();
// respond JSON
app.use(route.get('/hoge.json', function *() {
	// set Object you want to respond
	this.body = { foo: 'bar' };
}));
app.listen(3000);

実行

node --harmony sample.js

結果

curl -v localhost:3000/hoge.json
もしくは
open http://localhost:3000/hoge.json (OS X限定)

まとめ

何もせずに、無心にObjectを突っ込めばいいのです。
もうJSON.stringify()とか不要なのです。JSON.stringify()なしで動くのです。
Content-Typeもいじらなくていいんです。全部やってくれるんです。
koa、使わない手はないでしょう。
※動かない場合は、app.use(json());を指定すると動く。（バージョン次第？）

Node.jsでダウンロードしながらGunzipしてmd5の計算しながら保存する奴

2014-02-25T13:18:21+00:00

Node.jsです。
Lempel-Ziv符号化で圧縮されたファイル(.gz)のダウンロードをしようとしたときの話です。
ブラウザからダウンロードすると、拡張子gzで保存され、それを解凍することで必要なデータを得ることができるのですが、圧縮されたファイルは解凍したあとでは不要です。
このような不要ファイルを保存することなく、目的のファイルが欲しいような状況になったので、いろいろと調べて解決しました。

Lempel-Ziv符号化で圧縮されたファイルは、かの有名なzlibによって扱うことができます。
Node.jsの標準モジュールには、zlibがあり、require()で取り込むことでzlibを利用することができます。
標準モジュールであるため、APIに関する説明がNode.js公式ドキュメントにあるのですが、よく使い方がわからなかったので、いろいろと試行錯誤してみました。

結果、zlibモジュールを利用してストリームを扱うオブジェクトを作成し、パイプでつなげることで、前途の目的である、圧縮されたアーカイブファイルを保存することなく、目的のファイルを保存することができました。

以下、ソースコードになります。
引数に拡張子gzのファイルのURLを渡し実行することで、解凍されたファイルを保存できます。

20行目のres.pipe(gunzip).pipe(output);にてhttp.getで得られたストリームをzlib.createGunzip()で作成したgunzipオブジェクトにパイプで渡し、処理されたものを、fs.createWriteStream()で作成されたoutputオブジェクトにさらにパイプすることで不要なファイルを保存することなく、ダウンロードしながら解凍し、保存しています。

保存時に、gunzipオブジェクトの’data’イベントを拾って、crypto標準モジュールでmd5の値を計算させています。
ダウンロードのときはmd5チェックしたいですし。

Node.jsのzlibモジュールに関して、あまり実例がなく、せっかくなので記事にしました。
ご参考になれば幸いです。