Folioscope

プログラミング/Unix系/デザイン/CG などのメモがもりもり

人の絵文字のデフォルトが黄色い理由

f:id:ibenza:20160127102027p:plain

人権団体からの要望で、Unicode 8.0 で肌の色が導入されたのは有名な話です。 すでにAppleTwitterでは肌の色のEmojiに対応していますが、同時に肌の色のデフォルトが黄色 になりました。 これは黄色人種が優遇されているとか、黄色人種を差別しているとかではありません。 UTR #51: UNICODE EMOJI - 2.2 Diversity にその答えが載っています。

肌の色が指定されていないとき、次のような非現実的な肌の色を使用すべきです.

  RGB #FFCC22 (スマイルマークでよく用いられている色)

  RGB #3399CC

  RGB #CCCCCC

つまりデフォルトの黄色は黄色人種とは無関係で、肌の色として非現実的な色を選んでいるだけでした。 AppleTwitterがデフォルトの肌の色に黄色 なのは、互換性を考えて人間らしい色を採用したからでしょうか?

Electron + Git でエンジニア向けのノートアプリ作ってます [WIP]

f:id:ibenza:20160123184048g:plain

ElectronとGitを使って、エンジニア向けのノートアプリを作ってます。

github.com

ノートアプリはたくさんあるけど、自分に合うノートアプリを作りました。 主な機能は以下のとおりです。

  • Gitベースでバージョン管理
  • Markdownで書ける
  • 好きなエディタを使える

Gitのパワフルなバージョン管理機能を使うことで、複数ユーザの編集や誰がどこを編集したか、履歴の管理と差分も簡単に見れるんじゃないかと考えてます。 またGitHubやBitbucketをバックエンドに使うこともできるので、自前でサーバを立てる必要もありません。 そして外部エディタでMarkdownを使うことで、自分の慣れた環境でノートを編集できます。

作り始めたきっかけ

非常に便利な時代になったので、クラウドで同期するノートアプリは探せばいくらでもあります。 でもそれだと満足しないんですね。 僕はLinuxユーザでかつオープンソースが好きで、プロトコルもオープンがいいです。 なのでGitベース・Markdown・好きなエディタで書けるノートアプリを作り始めました。

GUIフレームワークにElectron使ってます。 GUIベースのツールキットは数多くありますが、Electron使った理由は、簡単にクロスプラットフォーム化できて、Node.jsのたくさんの資源も使えます。 またMicrosoftを始めとする様々な企業でも採用されているので、フレームワークとしての息も長そうです。

開発を始めて

Node.jsもElectronも初めてなので、Visual Studio CodeAtomShibaを参考にしながら、手探り状態で開発を始めました。 幸いWebにもElectronの情報がたくさん載ってたので、シンプルなアプリはすぐに作れそうでした。 ただ開発が軌道に乗ると、次は設計の壁にぶち当たりました。 どうやら自分は、GUIアプリである程度開発が進むと、設計が破綻してコード全体の見通しが悪くなるようです。 とくにElectronだと、RendererプロセスとBrowserプロセスを考えないの行けないので、「この機能はどっちに実装しよう」と考える必要があります。 そこそこ開発が進むと、全てを取り壊してまた一から設計したくなります。 どうすれば破綻しない設計ができるのでしょうか?

TODO

まだまだ開発段階なので、実装は全然進んでないです。 改善点として

  • Gitのコンフリクト時のふるまい
  • 検索機能
  • キレイなUI
  • ノートのタグ付け

などです。 ひとまずGitのコンフリクト時の振る舞いと、UIの整理と、設計をまともにできれば、リリースかなと思っています。

Qiita始めました

Qiita始めちゃいました

qiita.com

カジュアルに情報発信しよう

Qiitaのように一つのサービスに多人数が記事を投稿すると、やはり記事の質にばらつきがでます。 Qiitaではたくさんの有益な記事にも巡りあえましたが、時々残念記事に遭遇してげんなりした経験もあります。 とはいえそんなQiitaだからこそ、難しいことを考えずにカジュアルに記事を書けるのではないかと考えました。 もちろん読み手がげんなりしない記事を充実させたいですが。

技術の情報が発信しやすい

Qiitaはその目的通り、技術情報が発信しやすいと考えています。 ニッチな技術情報を個人ブログに書いてインターネットの海に埋もれさせるより、Qiitaに書いたほうがもったいなくないと思いました。 そんな情報を必要としている人が一人でもいるならQiitaがいいなーと考えます。

ブログとどう住み分けするか

ブログとQiitaをどう住み分けるか、少し考えないといけません。 些細な技術記事はQiitaに書きますが、ライブラリ作ったよ記事やひとりごと記事は、自分のブログでやれよですね。 とはいえその境界を見極めて、どっちに投稿するかのポリシーを決めないといけません。

Twitterの文字数制限の緩和で気軽にパッチが送れる

Twitterの文字数制限が10000文字になるのではと盛り上がってますが、これが実現されるとTwitterでバグ報告だけでなく、気軽にパッチも送れそうです。 そこでTwitterでパッチまで送れるか調べてみます。 Gitプロジェクトのリポジトリの各コミットからパッチを生成して、 どのくらいのサイズのパッチがTwitterで送れるのか集計してみました。

パッチを生成

Gitにはファイルの差分、コミットメッセージ、作者などの情報を、ひとつのパッチファイルにまとめる git format-patch コマンドがあります。 今回は各コミットから1パッチを作成します。 git rev-list で全てのリビジョンのリストを取得して、git format-patch でパッチを生成します。

for r in $(git rev-list HEAD); do git format-patch -1 $r; don

HEADが 7548842 の状態で、 41633のコミット数なので、対象となるパッチ数も41633となります。

10000文字以内のパッチ

生成した41633のパッチから,10000文字以下のパッチを数えます。 その数は,39344/41633 でした。 この時点で9割以上のパッチが送れることがわかります。 なお10000文字以下の最大のパッチは3つあり、 39598f97b3b151cca5d94 です。 しかしまだ圧縮の余地があるので、パッチを圧縮してみます。

パッチを圧縮する

パッチを一度gzipで圧縮し、圧縮されたバイナリをBase64でASCIIの文字に変換します。

gzip -9 < your_change.patch | base64 >encoded_patch

このトリックを使うことで、圧縮されたバイナリ情報もTwitterで送ることができます。 圧縮・Base64エンコードされたファイルを元のパッチファイルに戻すには、その逆を適用するだけです。

base64 -d < encoded_patch | gzip -d > your_change/patch

ただしBase64によりバイナリ情報がおよそ(4/3)倍になるため、gzipで(3/4)未満のサイズにならないと効果は得られません。 とはいえテキストファイルは基本的に圧縮率が高いので、ファイルサイズが大きくなるにつれて圧縮率が良くなります。 この方法で、Base64後に10000文字以内となったパッチの数は、40859/41633 となりました。 98%のパッチをTwitterで送ることができました。

10000文字以下の最大のパッチは、 1a9d15d でした。このパッチは、圧縮前は27776文字なので、元の半分以下のサイズまで圧縮できました。

Base65536

Twitterで扱う文字はUnicodeです。 ASCIIの1文字もUnicodeの1文字も同じ文字数とカウントするので、1文字あたりの情報量が多い文字を使うとお得です。 2オクテットの文字を65536文字使ってエンコードする、base65536というのがあります。 1文字あたり2バイトなので、20000バイトまでのバイナリをTwitterで送ることができます。 gzip圧縮後のバイト数が20000バイト以下のパッチは、41317/41633でした。 99%のパッチをTwitterで送ることができました。

20000バイト以下の最大のパッチは、 5e9637c でした。 このパッチは圧縮前は64935文字なので、3分の1程度まで圧縮できました。

パッチ以外に

パッチ以外にも、任意のバイナリデータを印刷可能文字に変換することで、Twitter上で送ることができます。 そのサイズは、gzip + base64 なら7.2kBちょっと、Base65536なら20kBまで送ることができます。 Googleのロゴ画像で5.7bytes、slの実行ファイルが14kByteほどなので、簡単なファイルならTwitterで発信できますね。

Bashのバージョン管理ツールを作りました

開発環境を容易に構築するために、 Node.jsだとnvmRubyだとrvmのような、 各言語のインタプリタをローカルにインストールツールが多くあります。 Bashでもそれがしたかったので、作りました。

github.com

インストール

まずGitHbuのプロジェクトを $HOME/.bashvm にクローンします.

git clone https://github.com/ueokande/bashvm $HOME/.bashvm

そして .bash_profile に次の行を追加します。

source $HOME/.bashvm/bin/bashvm-init

使い方

Bashのバージョンをリスト化

list サブコマンドにlocalを与えると、インストールされているBash一覧を取得します。

bashvm list local

remoteオプションをつけると、インストール可能なBashバージョン一覧を表示します。

bashvm list remote

バージョンの切り替え

use サブコマンドで、現在使用しているBashのバージョンを切り替えることができます。

bashvm use X.Y

use サブコマンドは現在使用中のシェルのみに有効ですが、次回起動時にもそのバージョンを使用したいときは、 --default オプションを使用します。

bashvm use X.Y --default

バージョンsystem を指定すると、システムにインストールされているBashを使用します。

bashvm use system

ローカルにインストールされていないが、インストール可能なバージョンを使用するとき、 --install オプションでそのバージョンをインストールして切り替えます。

bashvm use X.Y --install

インストール

install サブコマンドを使用します。

bashvm install X.Y

その他

help サブコマンドを使用すると、利用可能なコマンドとヘルプが表示されます。

bashvm help

Travis-CIで利用する

Travis-CIの設定例を次に示します。

sudo: false
cache:
  directories:
  - .bashvm/usr
env:
- RUN_BASH_VERSION=3.1
- RUN_BASH_VERSION=3.2
- RUN_BASH_VERSION=4.0
- RUN_BASH_VERSION=4.1
- RUN_BASH_VERSION=4.2
- RUN_BASH_VERSION=4.3
install:
- mkdir -p .bashvm
- curl  https://codeload.github.com/ueokande/bashvm/tar.gz/master | tar zx
- cp -r bashvm-master/* .bashvm/
before_script:
- export BASHVM_HOME=$(readlink -f  .bashvm)
- source .bashvm/bin/bashvm-init
- bashvm use --install $RUN_BASH_VERSION
script:
- bash your_test_script.sh

この例ではBashの各バージョンのビルド時間を短縮するために、Travis-CIのコンテナベースインフラを有効化して ディレクトリキャッシュを使用ます。 この例ではビルド済みのBashが格納される $TRAVIS_BUILD_DIR/.bashvm/usr をキャッシュします。 installステップではキャッシュ利用時にソースコードを正常にダウンロードできるよう、git-cloneの代わりにcurlを使用します。

ビルドスクリプトは各RUN_BASH_VERSION変数のバージョンそれぞれで実行します。 各Bashバージョンは、 before_script でインストールして切り替えます。

おわりに

bashvm自体がbashで動いてますが、可能ならPOSIX shellで書き直したいですね。 そして現在はbashのバージョン管理しかしませんが、ashやcshkshzshもインストールできれば素敵です。