Thanks Driven Life

日々是感謝

Fit Boxing を始めて2ヶ月が経過しました

記録は公開する方が続けられそうなので、1ヶ月ごとにやっていく

先月はこちら: http://gongo.hatenablog.com/entry/2019/06/03/223016

記録

開始 (5月上旬) 先月 今月 増減 (先月/開始)
98.8 96.2 95.0 -1.2 / -3.8 kg
  • 先月よりも減りは小さいものの、とはいえ順調な気はする
  • 一日だけ 94 kg 台に突入したことがあり、テンションが上がった

せっかくなので、今回は体脂肪量のグラフも載せてみる。 バラツキがあるのでなんともいえないが、雰囲気減少傾向っぽい。

体重 体脂肪
f:id:gongoZ:20190703083935p:plain:w400 f:id:gongoZ:20190703084313j:plain:w400

体調

肩凝りが軽減されている感触がある

ネクストアクション

94 kg 台を通常のものとし、あわよくば 93 kg 台を目指す

Hackers Champloo 2019 に参加 & 登壇しました #hcmpl

去る6月29日、ハッカーズチャンプルー2019が開催されました。

GW も終わったあたりで、運営の方から「発表しませんか?」というお誘いがありました。 沖縄住まいの時は何度か参加していたイベントで、上京してからは遠い存在になったなーと思っていたところでのお声掛け。 せっかくの機会だからと登壇することになりました。

先に総括

  • 無事発表終わってよかった
  • 他の人の発表も面白かった…さすハカチャン…

発表ネタについて

最新のネタがあるわけでもなかったので、過去の成果物*1を引っ張りだして伏線回収するパターンで乗り切りました。思ったより反応が良かったので安心しました。

airplay-elemacs-nes 、まだまだ改良の余地があり、発表資料作成のために読み直したことで久しぶりに触ってみるかーという気持ちになりました。こういうのも発表駆動の醍醐味の一つかもしれません。

他の発表の感想

つらつらっと印象深かったものを書いていきます。*2 発表資料のリンクは、なんとかがんばって探してくれ!

リアルタイムツイートはこちら from:gongoZ #hcmpl - Twitter検索

開発者向けの基盤をつくる ( deeeet さん )

  • なぜ Microservices なのか
  • なぜ k8s なのか
  • がんばるぞい

ここらへん(特に k8s)名前だけは知ってる! ぐらいだったので、タメになった

JavaScriptで黒魔術 ( りゅうさん )

  • ヒエッ
  • うわぁ
  • やべえ

世界は広い

現代のコンピュータにおける自作OS事情 ( hikalium さん )

  • OS さん…
  • なるほどわかる(わからん)

大学の頃 OS 自作入門で何かを作った記憶が出てきた

好きなことをやり続けるということ ( ちょまどさん )

  • 「パーマ禁止だから天パかけてきなさい!」「えぇ…?」
  • 点と点
  • Excel は素晴しいツールである

3点の話よかった。自分は何点あるのだろうか。

サイドプロジェクトが利益を生むビジネスになるまでの苦労と長い道のり ( Paul McMahon さん )

  • 「来日して初めての会社、しばらくすると経営があやしくなり、その時期に開かれる飲み会は全て送別会でした」 泣いた
  • 「そして1人になりました」泣いた
  • 「有料プランリリース。みんなが使ってくれて、利益も出た。みんなありがとう」泣いた

とにかくいい話だった。ベストオブ泣いたでStory

Re; make perl1.0 ( 八雲アナグラさん )

  • Emacs よりは新しい(ザワザワ
  • Docker イメージ作りました!(古代遺跡っぽい)
  • 夏コミ期待

古文書読んでるみたいでおもしろい

意味不明プログラミングの世界 ( tompng さん )

  • LT のトリに居る理由
  • やっぱりペンさんじゃないか…
  • Ruby コードとして実行可能な BMP 画像があって」「???????」

ペンさんの安心と信頼の意味不明さ

というわけで

運営の皆様、スポンサーの皆様、発表者含め参加者の皆様、ありがとうございました!ハカチャンはやっぱり良い。 おそらく来年もハッカーズチャンプルーあるはずなので、未参加の人は機会があれば是非参加してくれよな!

*1:久しぶりに airplay-el のリポジトリ覗いたら 7 years ago って表示されてた。時の流れ…

*2:途中、発表の準備であまり深く聞けてないところもあり

Fit Boxing を始めて30日が経過しました

ゴールデンウィークも終盤に差し掛かったある日、ふと思い立って FIt Boxing を購入しました。

以前から評判の良さも合わせて話には聞いており、また週末に趣味で格闘技をしている同僚が「これはいいぞ」と勧めてくれたのもあって、 日頃の運動不足解消も兼ねてプレイしてみることにしました。

本記事では、とりあえず1ヶ月続けてみた記念として、数値的な変化も合わせて所感を記していきます。

前提

  • 身体的な話
    • 肥満体(動けば痩せる。動き続けば)
  • 生活的な話
    • 食生活は変えていない
    • 強いて言えば平日にコカ・コーラを飲んでいない
  • 強度的な話(Fit Boxing の設定)
    • 体力強化・全身・20〜40分
    • 朝・夜どちらか必ず20分
      • 夜飲み会などでプレイできない可能性が高い日は朝に

記録

ざっくりとした計測結果です。 体脂肪とかも計測していますが、ブレがすごすぎて微妙だったので今回は載せませんでした。

体重
1日目 98.8 kg
30日目 96.2 kg
結果 -2.6 kg

f:id:gongoZ:20190603221305p:plain

プレイ感

  • 結構楽しい
  • フィードバックがあるのは良い
    • 声かけもそうだが、殴った時の振動が地味に嬉しい
    • Xbox360 + Kinect の「ユアシェイプ フィットネス・エボルブ」経験から、特にそう思う
      • 無を殴ってる感じが強くてつらかった
  • ダッキングや左右ステップが反応しづらい時も多々ある
    • リズムゲーとして追求しすぎると逆にストレス
    • とりあえず自分が体動かせていれば ok

ネクストアクション

いけるところまで

Turnip 4.0.0 (Gherkin 6 対応) リリースしました

本記事の概要

Turnip の依存ライブラリの一つである Gherkin が 6 にメジャーバージョンアップしてそろそろ半年を迎えようとしています。 かなり遅れてしまいましたが、ようやく Turnip も Gherkin 6 に対応したので、その報告です。

また、 Gherkin 6 から新しいキーワードである Rule が追加されたので、その紹介もついでにやっていきます。

Turnip 4.0.0 の内容

https://github.com/jnicklas/turnip/releases/tag/v4.0.0

Gherkin 6 対応がメインとなります。

  • Gherkin 6 は 5 と API 互換性が無いため、Turnip もメジャーバージョンを上げました

    .feature ファイルのパース後の構造が変わっているだけなので、 Turnip::Node::xxxAPI には変更はありません

  • これまで使ってきた .feature ファイルはそのまま使えます

    Turnip を拡張して使っていなければ、バージョンアップに合わせての対応は必要ありません

Turnip そのものに新機能や改善があったわけではないため、普段使いであればあまり意識しなくても良さそうです。

Gherkin 6 の内容

Gherkin 6 では、下記キーワードが追加されました

  1. Rule
  2. Example (Scenario キーワードの別名)
  3. Scenario Template (Scenario Outline キーワードの別名)

2 と 3 はただのシノニム追加なので、1 の Rule について紹介していきます。

A new Rule keyword has been introduced, and acts as a grouping of one or more Example s - a new synonym for Scenario.

gherkin/CHANGELOG.md

これは例題を見るとわかりやすいです。

# https://docs.cucumber.io/gherkin/reference/#rule
# https://github.com/jnicklas/turnip/blob/v4.0.0/examples/gherkin6_syntax.feature

Feature: Gherkin 6 syntax

  Background:
    Given there is a monster with 2 hitpoints

  Scenario: Battle
    When I attack it
    Then the monster should be alive
    When I attack it
    Then it should die

  Rule: Battle with preemptive attack
    Background:
      Given I attack the monster and do 1 points damage

    Example: battle
      When I attack it
      Then it should die

  Rule: Battle with preemptive critical attack
    Background:
      Given I attack the monster and do 2 points damage

    Example: battle
      Then it should die

上記 feature を RSpec に落としてみたイメージはこんな感じ:

describe 'Gherkin 6 syntax' do
  before { send('there is a monster with 2 hitpoints') }

  describe 'Battle' do
    it do
      send('I attack it')
      send('the monster should be alive')
      send('I attack it')
      send('it should die')
    end
  end

  context 'Battle with preemptive attack' do
    before { send('I attack the monster and do 1 points damage') }

    describe 'battle' do
      it do
        send('I attack it')
        send('it should die')
      end
    end
  end

  context 'Battle with preemptive critical attack' do
    before { send('I attack the monster and do 2 points damage') }

    describe 'battle' do
      it do
        send('it should die')
      end
    end
  end
end

これまでの feature ファイルでは、Feature の下にある Background や Scenario が同じレイヤーにのみ存在を許されており、「このバックグラウンドはこのシナリオにのみ適用したいんだけど、ここに書くと全てのシナリオで発動しちゃうんだよなぁ」といったことが稀によくありました。その回避策として「別の Feature に分ける」「タグをつけて Step 側でなんとかする」といった対応が取られていたかと思います。

そこで Rule を使うと、そこらへんをよしなにいい感じに書けるようになる!みたいなやつだと思います!多分!!

まとめ

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

Emacs で動く NES エミュレータを作っている話

本記事は Emacs Advent Calendar 2018 の22日目の記事です。

成果物

まずは現時点 (12/22) での動作状況です。

https://github.com/gongo/emacs-nes

nestest.nes palette_pal.nes
f:id:gongoZ:20181222155809g:plain:w300 f:id:gongoZ:20181222160136j:plain:w300

使い方はいつか README の方に書きますが(いつか)、ざっと書くと:

  1. ソースコードもってくる
  2. nes*.el があるディレクトリに load-path を通す
  3. load-library nes
  4. M-x nes*.nes ファイルを選択

これで動くはずです。Byte Compile 推奨。

経緯

様々な言語で NES (= Nintendo Entertainment System) のエミュレータを実装する、というネタは昔からあります。私も何かしらの言語でやってみようかな? とボンヤリ考えたまま特に手をつけていませんでした。

そんな日々の中で参加した builderscon tokyo 2018 で、とある発表を見ました。

ファミコンエミュレータの創り方 - builderscon tokyo 2018

「何やっているのか良くわかんねえな?」と思いながらも「しかし面白いな!」という感想を得て、いよいよ自分でも何かで書いてみるかーという気持ちが再燃しました。

ちなみに「どの言語で実装するか?」ということですが、まだ誰も作っていなさそう*1Emacs Lisp でやってみることにしました。

記事の概要

  • 書いてあること
    • Emacs Lisp でそれっぽく動くところまでの話
  • 書いてないこと

動作するまでの話

時系列でふんわりと

1. まず ROM パーサの実装

.nes ファイルのフォーマット iNES の仕様どおりに読み込んでいきました。

2. CPU の実装

とにかく CPU が無いと始まらない! ということで CPU 周りに手をつけはじめました。

  1. 命令セットをとにかく Emacs Lisp に落としていく作業
  2. CPU 周りで必要な要素などを Emacs Lisp に落としていく作業

一通り落とし終わったので、いざ動くか試してみるぞ! と検証を開始しました。

検証に使用したのは

This is the best test to start with when getting a CPU emulator working for the first time.

と書かれるまでに便利な、 nestest.nes という「まずはこれ PASS したら次に進もうな」というテスト用 ROM です。

本来の nestest.nes は「コントローラ(ジョイスティック)でテストしたい CPU 命令を選んでテストを開始する」というものなのですが、この時点ではまだ画面やコントローラの実装できていません。そこで「コントローラの操作は無視して、ROM を読み込んで全ての CPU 命令に対するテストを実施する」というようなサンプルプログラムを書きました。

;; 当時のコードではなく、現状のコードで再現した形です
;; (この時はまだ ppu や interrupt は用意していなかったので)
(let ((cart (nes/cartridge-load "/path/to/nestest.nes"))
      (cpu (make-nes/cpu :interrupt (make-nes/interrupt) :ppu (make-nes/ppu))))
  (nes/cpu-set-working-ram cpu (make-vector #x0800 0))
  (nes/cpu-set-program-rom cpu (lexical-let ((cart cart))
                                 (lambda (addr)
                                   (nes/cartridge-read-from-prg-rom cart addr))))
  ;;
  ;; 画面から操作せず、テストだけを実行するために
  ;; nestest.txt の1行目の状況を開始地点(program counter)にセットしている
  ;;
  ;; memo: 長くなるのでここには書いていないが、 status register とかも
  ;;       1行目と合わせておく
  ;;
  (nes/cpu-reset cpu)
  (setf (nes/cpu-register->pc (nes/cpu->register cpu)) #xC000)

  (while t
    (let* ((r (nes/cpu->register cpu))
           (pc (nes/cpu-register->pc r))
           (opcode (nes/cpu-read cpu pc))
           (operand (nes/cpu-read cpu (1+ pc) :word))
           (inst (aref nes/instruction:MAP opcode))
           )
      (message "%04X %02X %s A:%02X X:%02X Y:%02X P:%02X SP:%02X"
               pc
               opcode
               (if (null operand) "    " (format "%4X" operand))
               (nes/cpu-register->acc r)
               (nes/cpu-register->idx-x r)
               (nes/cpu-register->idx-y r)
               (logior (lsh (if (nes/cpu-register->sr-negative r)  1 0) 7)
                       (lsh (if (nes/cpu-register->sr-overflow r)  1 0) 6)
                       (lsh (if (nes/cpu-register->sr-reserved r)  1 0) 5)
                       (lsh (if (nes/cpu-register->sr-break r)     1 0) 4)
                       (lsh (if (nes/cpu-register->sr-decimal r)   1 0) 3)
                       (lsh (if (nes/cpu-register->sr-interrupt r) 1 0) 2)
                       (lsh (if (nes/cpu-register->sr-zero r)      1 0) 1)
                       (lsh (if (nes/cpu-register->sr-carry r)     1 0) 0))
               (nes/cpu-register->sp r)
               )
      (nes/cpu-step cpu)
      )))

このプログラムを実行すると、下記のような結果が *Message* バッファに書き出されます:

C000 4C C5F5 A:00 X:00 Y:00 P:24 SP:FD
C5F5 A2 8600 A:00 X:00 Y:00 P:24 SP:FD
C5F7 86 8600 A:00 X:00 Y:00 P:26 SP:FD
C5F9 86 8610 A:00 X:00 Y:00 P:26 SP:FD
C5FB 86 2011 A:00 X:00 Y:00 P:26 SP:FD
C5FD 20 C72D A:00 X:00 Y:00 P:26 SP:FD
C72D EA B038 A:00 X:00 Y:00 P:26 SP:FB
C72E 38  4B0 A:00 X:00 Y:00 P:26 SP:FB
C72F B0 A204 A:00 X:00 Y:00 P:27 SP:FB
C735 EA B018 A:00 X:00 Y:00 P:27 SP:FB
C736 18  3B0 A:00 X:00 Y:00 P:27 SP:FB
C737 B0 4C03 A:00 X:00 Y:00 P:26 SP:FB
C739 4C C740 A:00 X:00 Y:00 P:26 SP:FB
C740 EA 9038 A:00 X:00 Y:00 P:26 SP:FB
C741 38  390 A:00 X:00 Y:00 P:26 SP:FB
C742 90 4C03 A:00 X:00 Y:00 P:27 SP:FB
C744 4C C74B A:00 X:00 Y:00 P:27 SP:FB
C74B EA 9018 A:00 X:00 Y:00 P:27 SP:FB
C74C 18  490 A:00 X:00 Y:00 P:27 SP:FB
...
...

あとはこの結果と、「 nestest.nespc=C000 以降の動きがこうなっていれば正解やで」が記載されている nestest.log を比較して、PC や各レジスタの値が同じまま最後まで到達したら CPU はひとまず実装終わり!

3. PPU の実装 (白黒・背景画像だけ)

ついに見える化を進めます。

ところで、Emacs で「指定した位置に、この色でピクセルを描画する」という実装を行う場合、様々な方法があると思います。 今回は 18日目の記事でも紹介されていた gamegrid.el を使用しました。 私自身も2年前に gamegrid.el で一ネタ 作っており、とりあえずこれでいいかーという気持ちで選定しました

nes-ppu.el

PPU の実装、ものすごく大変でした。 CPU と違って「目チェックしては修正して〜」の繰り返し*2。そんな PPU の実装を開始して一週間後、ついに…

ここまで来るとモチベーションも高まり、あとは勢いのまま突き進みました。

画面が使えるようになることで、他のテスト用ROMでも試せるようになり、更に便利に。

4. コントローラの実装

コントローラ操作はもちろんキー入力。キー入力と云えば Emacs の独壇場。特に問題もなく実装できました(2Pコンはまだ未実装なのですが)。

nes-keypad.el

コントローラも実装できたことで、以前テキスト比較でのみ使用していた nestest.nes も、ついに画面で結果を見ることに成功。

5. PPU の実装 (色有り・背景画像だけ)

そろそろ白黒から脱却する時期になりました。一気に実装

📝 当時は色テーブルが間違っており、色が変でした。

6. PPU の実装(スプライト画像)

背景画像とはまた別の計算が絡んできて一層混乱しました。

とはいえ、あとはひたすら微調整作業だったので、無事にそこそこ動作するまでもってこれました。終わり。

まだ実装できていないところ

1. スプライトの処理がまだ甘い

まだズレがある

f:id:gongoZ:20181222184432p:plain:w300

2. スクロール処理がおかしい

f:id:gongoZ:20181222155710g:plain:w300

この ROM は ギコ猫でもわかるファミコンプログラミング にある、背景画像スクロールの例題です。何かこう、移動がぎこちない。素直に左に進んで欲しい

3. 遅い

今のところ体感で 3 FPS ぐらいです。なんとか ギコ猫 がギリギリ動かせるぐらい(十字キーの左を押しっぱなしでこれぐらい):

f:id:gongoZ:20181222183547g:plain:w300

4. BGM

さすがに Emacs 単体では無理かもしれない

5. 縦横のサイズを調整するのが少し面倒くさい

gamegrid.el に限らず、Emacs で各ポジションに色つけたりする時は face や font を弄ると思います。 つまり、その位置にある文字の width と height が、そのまま NES エミュレータ側からみる「1ピクセルの width と height 」になります。

これの何が面倒くさいのかというと、基本的に使っているフォントは「縦のサイズ = 横*2」みたいなことが多いので:

f:id:gongoZ:20181222181533p:plain:w300

こんな感じで縦長になってしまいます( iTerm で 256 x 149 の様子。256 x 240 が領域なので、下の方が見えない)

仕方ないので、今のところ端末設定の「行間隔」に相当する設定を弄ってそれっぽく見えるように調整*3しています。(冒頭の画像とかはそれ)

f:id:gongoZ:20181222182238p:plain:w300

  • Emacs の設定だけでは上記のような行間隔設定ができない*4
  • おそらくそれ用(height == width)のフォントを用意すればいけるのかな…?

まとめ

深い解説のない、ただの開発日記みたいになりましたが如何でしたでしょうか。 取り組み始めて約2ヶ月(毎日やっていたわけではないですが)かかり、なんとかモノになったので良かったです。

難しいといえば難しいですが、やはり目に見えて良くなっていくのは開発してて面白いですね。 もう少しマシなゲームが動かせるようになったら、またどこかで報告します。*5

それでは、今年もお疲れ様でした。良い御年を

参考

*1:Lisp」という括りではいくつかありました https://news.ycombinator.com/item?id=8666976

*2:特にパターンテーブルの理解に時間をかけました。つまりどういうことやねん状態

*3:Emacs に限らず、端末に描画するタイプはここらへん調整が必要になりそう

*4:見つけきれてないだけかも。あると嬉しい

*5:吸い出し機買わないと…

年末調整Tシャツを作っています

最近は年末調整のことばかりを考えており、とはいえ実際に記入するのはもう少し先の話です。 息抜きも必要、しかしまったく離れるわけにもいかない。そんな気持ちでTシャツを SUZURI で販売しています。

各書類の詳しい説明は こちら(国税庁) から確認できます。

一例:

追記

買う人いるとは思わなかったんですよね…

Nokia Steel HR を1ヶ月使ってみた記録

ただの記録です

買ったもの

Nokia Steel HR 40mm モデルです

Nokia Steel HR - Withings ウォッチの各モデルの違いはどのようなものですか?

バッテリーについて

  • 前提

    • 継続心拍数モードは使っていない
  • 結果

    25日無充電でもまだ余裕ある

    日付 電池残量
    1/21 85% (購入時)
    2/15 8%

満タンから始めると1ヶ月ぐらいは持ちそう

Nokia Steel HR™ は、一回の充電で最大25日間使用可能ですが、使用可能な日数は継続心拍数モードの使用頻度により変動します。トレーニング中だけでなく、常時継続心拍数モードを使用すると、バッテリーの消耗がより増加します。

Nokia Steel HR - バッテリーの電池寿命はどれくらいですか?

着け心地

普段時計などはつけない(違和感気になるタイプ)が、着けた初日から問題なく睡眠に入れるぐらい

睡眠の記録について

だいたい23時あたりからは動き少ないと寝ている判定をされるっぽい

まとめ