2015-01-29 TEX Yodaが届いたので使い始めた


TEX Yoda TrackPoint Keyboard - Massdrop

一部で話題のTEX Yodaが先週の金曜日に届いたので今週から使っている。

とりあえずできた

AKAMATSU Yukiさん(@ukstudio)が投稿した写真 -

ハンダ付け

久々のハンダ付けだけど、MXスイッチの足と基板をつけるだけだし、オフィスに先に組み立て済みの同僚もいたのでそんなに難しいこともなく終了。といっても幾つかミスもあったわけだけど。

  • LEDを付ける前に基板をネジ止めした
  • ハンダ付けしわすれた箇所があった

TEX YodaにはLEDつけるところがあるんだけど、そのLEDがキートップのパーツと同じ袋に入ってる。なので基板にひと通りスイッチつけて、満足してネジ止めして「さー、キートップつけるぞ」と思い袋あけるとそこからLEDがでてきて悲しい感じになる。ハンダ付けするときにLEDの話を同僚としていたのにこれだよ。

ハンダ付けしわすれたのは完全に自分のミス。ひと通り組み立て終わったあとに0のキーが効かず、ハンダ付けのときに基板壊したかなとすごい焦ったけど開けてみたら普通にハンダがついてなかったというオチ。ちなみに現状、左下のFnキーも動いてないのでそこも忘れてる可能性ある。

ゼロのキー動かんと思ったらこれですよ

AKAMATSU Yukiさん(@ukstudio)が投稿した写真 -

選んだ軸

実は買って届くまでMXスイッチの軸の色の意味を知らなかったんだけど、買うときに一番値段が高かったクリア軸にした。わからないときはとりあえず高いのにしておく精神。調べてみると茶軸に近い感じということらしい。茶軸使ったことないからそう言われてもわからないけど…。他にも色々な軸があるので試してみたい気がする。緑とか気になる。

ちょっとしたカスタマイズ

MXスイッチ互換のキートップが売ってたりするので適当に変えてみたりした。PCゲーマーではおなじみのWASD。あとIJKLを赤に。これらはFnを押すとカーソルキーの動きをしてくれる。あとはなんとなくスペースも赤にしたら顔みたいになった。

顔っぽい

AKAMATSU Yukiさん(@ukstudio)が投稿した写真 -

キーレイアウト

現時点のレイアウトはDIPスイッチの1,3,5がオフ、2,4,6がオンになっている。それぞれの意味はマニュアル参照。

TKB-600i-Datasheet_14-0603-Rev 1.0.pdf - Google ドライブ

大体よくあるレイアウトだとは思うけど、珍しいのはESCと`~が同じキーでどちらかをFnキー押しながらじゃないと入力できない(DIPスイッチの3番参照)。

最初は普通に入力したらESCにして`~をFnキー押すようにしていたのだけど~がShiftも押さなきゃいけないのがあまりに不便すぎてやめた。VimmerとしてはESCはコード書くときそんなに使わないし、普段もMacユーザーなのでKarabinerでctrl-[をESC扱いにするようにしてESC単体で押す必要をなくして無事解決。

総評

概ね使い心地には満足している。元々ThinkPad使っていたのでトラックポイントも違和感なく、机からマウスを排除できたし、むしろマウスのためだけに腕を動かさなくなったが大分よい。実はHHKで一番気に入らなかったのがDELETEの位置で、TEX Yodaではそこが\になったのも良い。

本体の重さがそれなりにある。その気になれば撲殺できそうな程度には。なので持ち歩くつもりでいるならHHKの方がよいかなと思う。俺はあまりキーボードを持ち歩く人間ではないので問題ない。

タッチ感だけど、音はクリア軸のせいかTEX Yodaがそうなのかわからないけど、ちょっとちゃっちい音のような気もする。クリック感は個人的には大分気に入っていて、HHK、KinesisとTEX Yoda(クリア軸)だったらTEX Yodaが一番好み。ちなみにAlphaGripは俺の中では黒歴史化している。

今massdropをみると$199までもうちょいなので、興味ある人は買っていきましょう。ハンダ付けも$25でやってくれる模様。買って損はしないキーボードだと思います。実物みないと…という人は弊社に2つあるので遊びにくるとよいですよ。

2015-01-01 株式会社spice lifeに入社しました


あけましておめでとうございます。今年もどうぞよろしくお願いいたします。

さて、タイトル通りではありますが、本日2015年1月1日から株式会社spice lifeに入社しました。社員です。

なので2010年(だったかな)から続いていたフリーランス業も一旦終わりになります。フリーランスの時には様々な人にお世話になりました。本当に感謝の言葉しかでてきません。一部の方々にはご迷惑をお掛けしてしまったこともあります。本来直接伝えることなのでしょうがここで簡単にでもお詫びと感謝の気持ちを述べさせてください。本当にありがとうございました。

spice lifeには6月の終わり頃からフリーランスとして契約させてもらっていてとりあえず半年契約しましょう、その後はその半年働いてよかったら再契約しましょう、という感じでした。ところがどっこい、再契約どころか正式に入社という運びとなりました。元々社員に近い形で働いていたので働き方的にはあまり大きく変わりはしませんが、4年程度フリーランスをしていたのでちょっと感慨深くあります。

ここ最近はリリースの時にもこのブログでお知らせしたSPOTLIGHTSというサービスの開発に携わっています。もうしばらく携わっていく予定ですので何卒よろしくおねがいします。

ウィッスリスト

2014-12-14 esaのストックとフローの絞り込みで(俺にとって)なにがうれしいのか


そもそもesaのストックとフローの絞り込みってなに?っていう人は以下のリンクからどうぞ。

release_note/2014/12/13/検索結果の絞り込み(Stock or Flow) - docs - esa.io

簡単に説明するとesaではカテゴリに日付が入っている記事はフロー、入っていない記事はストックとして扱いそれらを分けて検索できるようになった。

結論から

たまには長い話をすっとばして結論を書く。簡単に言ってしまうと

  • yy年mm月dd日にAの仕様を変更したよ
  • 現時点において最新の仕様はこうです

という2種類の情報を前者はフロー、後者はストックとして分けて検索できるようになった。大体においてほしい情報というのは後者のストックなので個人的には非常にうれしい。

そもそもストックとフローとは

記事自体にストックとフローという概念をもたせるのは実はあまり新しい話でもなく、「wiki ブログ ストック フロー」で検索するとそれなりに記事がでてくる。要はwiki=ストック、ブログ=フローということだ。もちろん、wikiのあるページにフローの概念をもたせることもブログのある記事にストックの概念をもたせることも可能だけど大枠としてそういうことにする。ブログもストックっていう人もいるけど、wikiとかブログとかはここではあまり重要ではないので置いておく。

僕の捉え方でいうと、時系列にそって情報の流れがあるものはフロー、累積されていくようなものはストックと考えている(これなんの説明にもなっていないのでは…)

議事録はフロー

esaでそれなりの量の議事録を書いてきたけど、これらはMTGの日付をカテゴリに入れているのでフローだ。これらは日々の仕様の変更の流れをそのまま現しているのでフローとして扱うのは妥当だと思う。

flow.png

こういった情報がフローだけだと困ることがある。議事録には変更の差分しか書かれていない。なので現時点であるべき仕様を議事録から読み解くのは大変だ。エンジニアにわかるようにいうとgitの各commitのdiffから現在のソースコードを想像しろというものだ。

そこでストック

つまり、フローである議事録とは別に今あるべき姿を累積する記事が必要になる。そこでesa上では日付の入っていない記事を作り、そこにあるべき姿を書いていく。重要なのはフローと違いストックはその記事をちゃんと更新する必要があるということだ。

今まではこういう風にフローとストックの記事を分けてもうまく検索することができずにREADME.mdにリンクを貼っておくということしかできなかった。なのでそもそも人の目につかず、結果更新もされないという感じだったけれど、検索しやすくなったことで情報が古いことが目につきやすくなるので自然と更新も行われやすくなるのではないかと思う(みんな更新してね!)

おまけ

そもそも仕様をesaに書くの?みたいな話ありそうだけど、実装の前にメンバーに仕様を共有するケースはそれなりにあるし、コードを読んでもWhyがわからないのでなぜこうしたのかみたいな部分はドキュメントに残したりもする。

それに今回は仕様の話を例にとったけど、例えばインフラまわりだと議事録でこういう構成にしたという話を残すのとは別に構成がかわったことによってデプロイ手順もかわったならそれはストックとして残したいという話もある。

2014-11-27 spotlights.jpが本日10時にリリースされました


みんなで贈るソーシャルギフト・プレゼント \SPOTLIGHTS/(スポットライト)

今日の10時より株式会社spice life(スパイスライフ)からSPOTLIGHTSがリリースされました!!

ここ2ヶ月弱の追い込みにプログラマとして開発に関わらせて頂いてます(今後も関わっていく予定です)。実は自分のブログで関わってます!って言えるサービスは初めてだと思うので、期間はまだ短いですがちょっと感慨深いものがあります。

結婚式や誕生日のお祝いや日頃の感謝などにご活用ください。

2014-09-21 RSpecでPower Assertをやるには


RubyKaigi 2014でpower assertの話を聞いてrspecでどうにかならんかちょっと考えてみました。まず結論だけ書くとrspecでpower assertを使いたければ以下の様に書けばOK。

require 'rspec'
require 'minitest'
require 'minitest-power_assert'

module Minitest
  module Assertions
    prepend  Minitest::PowerAssert::Assertions
  end
end

RSpec.configure do |config|
  config.expect_with :minitest
end

describe 'Test' do
  it 'test' do
    assert { 1.to_s.class == 1.to_i.class }
  end
end

これを

$ rspec --color -rpower_assert power_assert.rb

で実行するとこんな感じ。power_assertは事前にrequireした方が情報量がちょっと増える。

Failures:

  1) Test test
     Failure/Error: assert { 1.to_s.class == 1.to_i.class }
     Minitest::Assertion:

           assert { 1.to_s.class == 1.to_i.class }
                      |    |     |    |    |
                      |    |     |    |    Fixnum
                      |    |     |    1
                      |    |     false
                      |    String
                      "1"

letとsubject

powerassertの0.1.3だとdefinedmethodで定義されたメソッドの値が取れていないらしく、letやsubjectの値が表示されない。現時点でのmasterの0.1.4devだと修正されているとのことなのでちゃんと表示される。

describe 'Test' do
  let(:klass) { 1.to_s.class }
  it 'test' do
    assert { klass == 1.to_i.class }
  end
end

これを実行すると

Failures:

  1) Test test
     Failure/Error: assert { klass == 1.to_i.class }
     Minitest::Assertion:

           assert { klass == 1.to_i.class }
                    |     |    |    |
                    |     |    |    Fixnum
                    |     |    1
                    |     false
                    String

こんな感じ。subjectも大体おなじ。

expectとマッチャ

この方法はMinitestのadapterとminitest-power_assertを使うようにしているので無理。

ちなみに rspec で 手軽に power_assert 出力できるようにする の方法でexpectを使ってみると

require 'rspec/core'
require 'power_assert'

module RSpec
  module PowerAssert
    def power_assert(&block)
      ::PowerAssert.start(block) do |pa|
        begin
          pa.yield
        rescue RSpec::Expectations::ExpectationNotMetError => e
          e.message << "\nPowerAssert:\n#{pa.message_proc.call}"
          raise e
        end
      end
    end
  end
end

class RSpec::Core::ExampleGroup
  include RSpec::PowerAssert
end

describe 'Test' do
  it 'test' do
    power_assert {
      expect(1.to_s.class).to eq(1.to_i.class)
    }
  end
end

これは

       PowerAssert:
             expect(1.to_s.class).to eq(1.to_i.class)
             |        |    |      |  |    |    |
             |        |    |      |  |    |    Fixnum
             |        |    |      |  |    1
             |        |    |      |  #<RSpec::Matchers::BuiltIn::Eq:0x007f0850c91d78 @expected=Fixnum, @actual=String>
             |        |    |      nil
             |        |    String
             |        "1"
             #<RSpec::Expectations::ExpectationTarget:0x007f0850caa170 @target=String>

こうなってしまう。この場合、expectの@targetにStringという結果が入っているのでそれを取り出すようにして、eqの方も@expectedに期待するものがはいってるのでそれを取りだすようにすればいいのかなぁ。

もしくはexpectとeqの中の値さえわかれば良いといえば良いのでいっそ値をださなくてもいいのかも? 例えばこんな感じ。

       PowerAssert:
             expect(1.to_s.class).to eq(1.to_i.class)
                      |    |              |    |
                      |    |              |    Fixnum
                      |    |              1
                      |    |
                      |    |
                      |    String
                     "1"


別の例としてbe_falseyだとこんな感じ。

     Failure/Error: expect(nil.to_s.to_i).to be_falsey
       expected: falsey value
            got: 0
       PowerAssert:
             expect(nil.to_s.to_i).to be_falsey
             |          |    |     |  |
             |          |    |     |  #<RSpec::Matchers::BuiltIn::BeFalsey:0x007fa84b53bb00 @actual=0>
             |          |    |     nil
             |          |    0
             |          ""
             #<RSpec::Expectations::ExpectationTarget:0x007fa84b3e02b0 @target=0>

これに関していうとbefalseyにはfalseが欲しいという情報がない。befalseyを見れば求めてるものはわかるって話かもしれないけど… 更に言うとRSpec3でComposable Matcherが入ったりとか、以前からあるCustom Matcherとかがあったりして、それら全部対応するのは厳しいなーという感じ(そもそも対応できるのかもよくわからない…)

そもそもの話をするとそういったマッチャというか、たくさんあるassertion methodを使い分けしたくないからpower assertをつかうわけで別にマッチャとか使わなくていいのではという気持ちがある。

なのでexpectとかカスタムマッチャとかは(power assertを使う部分では)諦めてassertですませるのがよさそうかなと個人的には思う。

config.expect_with :minitest
config.expect_with :rspec

spechelper.rbにminitestもrspecも両方使うよう書けばpowerassertを使いたいところと、rspecを使いたいところで分けることができるのでどうしてもマッチャを使いたいところは素直にマッチャを書いてpower assertは諦めるしかない。

今あるテスト資産をそのまんまpower assert対応にはできないのが悲しいところではあるけれども、このassertを使う方法でもexpectation部分以外はrspecの機能そのまま使えるのでそこまで悪くはないかなと思う。

まだpower_assert gemの実装を理解できていないので、もしかしたらうまいことやれるかもしれないけどとりあえずここでギブアップ…