IRKitが届いたので遊んでみた
IRKitが届いたので遊んでみた
- IRKitについて
- やりたいこと
- 手始め
- 初めてのiOSApp
- 実際の開発
- 完成
IRKitについて
引用:公式サイト http://getirkit.com/
IRKitは、 公式iOSアプリ IRKitシンプルリモコン 公式Androidアプリ IRKitシンプルリモコン から操作できるほか、
IRKit iOS-SDK を使えば、 任意のタイミングで赤外線信号を送ることのできるiOSアプリを簡単につくることができます。
また、JavaScriptを使ってブラウザから赤外線信号を送ったり
curlを使って黒い画面(Terminal)から赤外線信号を送ることもできます。
IRKitデバイス自体にHTTPサーバがあり、
JSON形式の赤外線情報を HTTP POSTリクエストにのせて送ることで、赤外線信号を送ることができるのです。
また、IRKitと同じWiFiにいなくても、外出先から赤外線信号を送るための、インターネット上にあるサーバのAPIも公開しています。
IRKitデバイスは、Arduino Derivative(派生)のプロダクトです。
未使用のピンは引き出してあるので、温度センサや明るさセンサなどを追加し、ArduinoIDEを使ってプログラムを書き込めば、
よりスマートなリモコンをつくることもできます。
やりたいこと
「帰ったよ」って言うと電気、エアコン、テレビをつける。
「いってきます」って言うと電気、エアコン、テレビを全部消す。
手始め
まずはcurlでエアコンをつけてみようかと
- IRKitをWifiに接続
- エアコンからIRKitに赤外線を送る
- MacからcurlでIRKitに送信された赤外線をJson形式で取得する
- MacからcurlでIRKitに赤外線を送信してエアコンをつける
1.IRKitをWifiに接続
まずはiPhoneを使って、IRKitに家のWifiの情報を送ってSetUp。
赤いランプの点滅が青くなったら接続完了!
RouterにつないでみるとIRKitが接続されていることがわかるので、
ホスト名を( ..)φメモメモ
2.エアコンからIRKitに赤外線を送る
とりあえずcurlがつながるか確認
curl -i "http://IRKitHoge.local/messages" -H "X-Requested-With: curl"
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/2.1.3.13.gbe33d36
Content-Type: text/plain
つながった!
次、青いランプが点灯している状態で、エアコンのONボタンをIRKitに向かって押した後GET
curl -i "http://IRKitHoge.local/messages" -H "X-Requested-With: curl"
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/2.1.3.13.gbe33d36
Content-Type: text/plain
{"format":"raw","freq":38,"data":
[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,
1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190
,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190
,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190
,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}
赤外線信号って、、、複雑。。。
ということでこれをそのまま送信してみましょう。
curl -i "http://10.0.1.2/messages" -H "X-Requested-With: curl" -d
'{"format":"raw","freq":38,"data":
[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,
1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190
,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190
,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190
,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}'
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/2.1.3.13.gbe33d36
Content-Type: text/plain
エアコンついたーー!!!
ちなみにそれぞれのJsonの意味はこんなんらしい
Key Description
format "raw"のみ
freq 赤外線信号のサブキャリア周波数を表します。38 または 40 のみ。単位 [kHz]
data 赤外線信号は、サブキャリア周波数のオン・オフからなります。IRKitデバイスはオン→オフ間の時間、オフ→オン間の時間を 2MHz のカウンタで数えます。dataには、カウンタで数えた数をオン・オフの回数分ならびます。
よくわからん。
初めてのiOSApp
さて、Siriに話しかけてリモコンを操作したかったものの、
実はiOSAppを作ったことがありませんでした!!!
というかXCodeを触ったこともありませんでした!!!
というかSwift書いたことない!!!
ので、実機確認が無料でできるXCode7をダウンロード。
XCode6まではDeveloperProgramに登録(有料)しないと実機確認
できないので注意。
Swiftは、まぁノリで書けるだろうと。
とりあえずこれだけ覚えた
func メソッド名(引数:型) -> 戻り値の型 {
return 戻り値
}
型の定義とかがJavaと逆なのかー。
でも、なんか書きやすい!
ってか言語仕様わかりやすいから以外とスラスラ書ける。
Swiftおもしろい、iOSAppおもしろい!
実際の開発
最初
本家のSDKを使おうと思ったんですが、、、
Objective-C ! そっちは書きたくない。
BridgeでImportできるらしいけど、
そんな面倒なこともあんまりしたくないなーということで、
UIViewのLoad後の処理にHTTPリクエストを書きましたw
func sendMessage(message: String) { let urlString = "http://IRKithoge.local/message/" var request = NSMutableURLRequest(URL: NSURL(string: urlString)!) request.HTTPMethod = "GET"
request.HTTPBody = message.dataUsingEncoding(NSUTF8StringEncoding)
var task = session.dataTaskWithRequest(req, completionHandler: {
(data, resp, err) in
println(resp.URL!)
println(NSString(data: data, encoding: NSUTF8StringEncoding))
})
task.resume() }
}
普通にHTTPのBodyに赤外線情報のJSONを突っ込んで送りました。
で、このアプリ名を「帰ったよ」にして
iPhoneにデプロイ。
すると、Siriに「帰ったよ」と言うと、
アプリが起動して自動で赤外線が送られるという簡単な仕組み。
Siriがアプリ内のコマンド実行できたらもっといいのになー。。。
完成
「HeySiri 帰ったよ」でエアコンON、電気全灯
「HeySiri いってくる」でエアコンOFF、電気消灯
はい、なぜテレビはできなかったか。。。
テレビはONとOFFの信号が同じなので、
どっちかわからないのです!
まぁ、帰ったらちょっと便利になったのでいいや。
IRKit - iPhone,iPadを使って外出先からエアコン等の家電を操作できる学習リモコン
- 出版社/メーカー: maaash.jp
- メディア: エレクトロニクス
- この商品を含むブログ (1件) を見る
公式サイト
IRKit - Open Source WiFi Connected Infrared Remote Controller
ActiveMQのTransactionに関して検証してみた
ActiveMQのTransactionに関して検証してみた。
通知とトランザクションに関して
JMSでは「通知」と「トランザクション」の二つの方法がある。
通知
プロデューサー(送信者) → JMSサーバー へ送られた時、
JMSサーバー → プロデューサー(送信者)へと受け取った通知を渡して完了する。
JMSサーバー → コンシューマー(受信者)へ送られた時、
コンシューマー(受信者)→ JMSサーバー へと受け取った通知を渡して完了する。
ActiveMQにはこれらに関して3つのモードがある。
- autoモード
メッセージの配信の通知をJMSサーバーが自動的に処理してくれます。一回だけの配信を保証します。
createSession(false,Session.AUTO_ACKNOWLEDGE)で設定します。
- clientモード
確認応答をJMSサーバーではなくJMSクライアントが行うモードです。
createSession(false,Session.CLIENT_ACKNOWLEDGE)で設定します。
- duplicates okeyモード
自動的に確認応答を行ってくれます。数通受け取った場合通知を行うため、autoモードと違い同じメッセージが何通も配信されることがあります。必ず一回だけを保証するautoモードと比べるとその点を保証しない分処理量が少ないというメリットがあります。
createSession(false,Session.DUPS_OK_ACKNOWLEDGE)で設定します。
トランザクション
処理を確定するコミット、処理を復元するロールバックなどを行うことが出来る。
トランザクションモードではコンシューマ/プロデューサーがコミットを行えば、
JMSサーバに対してメッセージ配信が完了したことを通知する。
コンシューマがロールバックを行えば受信されたことをキャンセルし、
再配信を要求することになる。
プロデューサーがロールバックを行えばメッセージ送信をキャンセルする。
ActiveMQでは、
createSession(true,-1)で設定します。
※第二引数は使用しないので、trueにした時点で通知は関係なくなる。
ということで、
トランザクションを検証してみた
コードを全部書くと長いのでわかりそうなレベルで省略しています。
送受信の購読するキューは1つで。
設定は createSession(true,-1)
検証1:トランザクションとコミットが効く
sender.send("test1");
↓
コミット前は読めない
message = (TextMessage) receiver.receive(1000);
assertNull(message);
↓
コミット後は読める
sender.commit();
message = (TextMessage) qmForRecieve.receive(1000);
assertThat(message.getText(), is("test1"));
↓
受信側がコミットしないと消えない
message = (TextMessage) receiver.receive(1000);
assertThat(message.getText(), is("test1")); 未だ読める
receiver.commit();
message = (TextMessage) receiver.receive(1000);
assertNull(message); 消える
検証2:トランザクションとロールバックが効く
sender.send("test1");
↓
ロールバック前は読めない
message = (TextMessage) receiver.receive(1000);
assertNull(message);
↓
ロールバックすると読めない
qm.rollback();
message = (TextMessage) receiver.receive(1000);
assertNull(message);
検証3:他の受信者が使ってるメッセージは読めない
sender.send("test1");
sender.commit();
↓
ある受信者が読んでいる間は
message = (TextMessage) receiver01.receive(1000);
assertThat(message.getText(), is("test1"));
↓
別の受信者は読めない
message = (TextMessage) receiver02.receive(1000);
assertNull(message);
↓
でもある受信者がロールバックして終了すると
receiver01.rollback();
↓
別の受信者が読める
message = (TextMessage) receiver02.receive(1000);message = null;
assertThat(message.getText(), is("test1"));
receiver02.commit();
検証4:別のメッセージでも読めない
sender.send("test1");
sender.send("test2");
sender.commit();
↓
ある受信者が読んでいる間は
message = (TextMessage) receiver01.receive(1000);
assertThat(message.getText(), is("test1"));
↓
別の受信者は別のメッセージでも読めない
message = (TextMessage) receiver02.receive(1000);
assertNull(message);
↓
でもある受信者が終了すると
receiver01.commit();
↓
別の受信者が読める
message = (TextMessage) receiver02.receive(1000);
assertThat(message.getText(), is("test2"));
receiver02.commit();
検証5:別のメッセージは書ける
sender01.send("test1");
sender02.send("test2");
↓
sender02のみコミットする
sender02.commit()
↓
Sender01のコミットを待たずに読める
message = (TextMessage) receiver.receive(1000);
assertThat(message.getText(), is("test2"));
receiver.commit();
↓
sender01をコミットする
sender01.commit();
↓
Sender01のコミットも読める(02のコミットは先ほど消費した)
message = (TextMessage) receiver.receive(1000);
assertThat(message.getText(), is("test1"));
receiver.commit();
結論
Transactionがちゃんと効く!!!
送信側にも受信側にもトランザクションがあるっておもしろいなー。
でも、送信は別のトランザクション待たずに送信するけど、
受信は別のトランザクション待たないと受信できないんだなーと。
UT間違えたかな((((;゚Д゚))))ガクガクブルブル
マーチン・ファウラーのリファクタリングを読んで(第1〜4章)
マーチン・ファウラーのリファクタリング、
とりあえず第1章から第4章のリファクタリングの始め方的なのを読んだので、
一旦まとめてみる。
まだ実際のリファクタリングの方法より、なぜするのかとか、どう始めるのかの辺りですが。
なぜリファクタリングをするのか
リファクタリングすると何がいいの?動いてるからいいじゃん。
ってよく言われますが、
- コードを理解しやすくなる
- → バグを見つけやすくなる
- → より早くプログラミングできる様になる。
- → スケジュールがスムーズに進む
というところで、結局みんながHappyになれる!
「スケジュールを気にする管理者は、
スピーディな方法を望むが、どうやってやるかは知らない。」
結局はこれなので、もし管理者を説得するなら、
この流れで説得するのがいいのかも。
- リファクタリングは設計を保管する
確かに。
最近コードを書くときは、設計はざっくりで、
まず書いてリファクタリングして設計に戻るほうが穴がない。
結局、ウォーターフォール的に先にがっちり設計するよりも、
書いたコードは想定以上のことを見つけられる。
「最初の設計は穴だらけなはず」
まさにこの通り。
-
変更しにくいコードから離れられる
「読みにくい」
「ロジックが重複」
「既存の修正が多い」
「条件分岐が複雑」
こういうコードは変更しづらい、
だから、リファクタリングによって変更を容易にする。
それによって開発効率は上がる。バグは減る。
リファクタリングって、
エンジニアのこだわりとかじゃないんです!
いつリファクタリングをするべきか
- 機能追加の時
- バグフィックスの時
- コードレビューの時
この中で書いてあったのが、
「リファクタリングをリファクタリングだけの時間で切り出さない」
というところかな。結局行う時間が確保できずに借金になりがちだし。
リファクタリングをしてはいけない場合
- 変更するより書きなおしたほうが早い
- 期間が迫っている場合
ちょっとこれは本に書いてあるけど、あまり納得できないかな。
このパターンでリファクタリングできないことが多いんじゃないかと。
まぁ、僕は書き直しますが苦笑。
ただ、
「未着手のリファクタリングは借金」
とはいえ、今はしないけど借金ですよというのも書いてあった。
これ、測れるとリファクタリングをちゃんとできる様になりそうだな。
どうやって測るかな。。。
リファクタリングをする時に最初にすること
テストを書く!
ってまぁあたりまえというか、これをしないと安心してリファクタリングできないですね。
PHPだとFixtureとかPHPUnitで、JavaだとJUnitとかですね。
そのテストを書く時に注意するべき点は2つ
- 実行されない完全なテストより、実行される不完全なテストの方が良い
- 例外のテストを忘れない
無駄にpublicなメソッドのテスト全部書いても、リファクタリングには無意味ですね。
でも、最近思うのは、先にテスト書いておかないと、テストしにくいメソッド構成とかになってて、結局テスト前にリファクタリングが発生したり。。。
テスト大事!
リファクタリングを始める(まずやってみること)
でも、ここで何行以上とか決めちゃうと無駄にメソッドが分割されて結局読みにくくなりそうなので、そういうのはやめておいた方がいいんじゃないかなと。
確かに無駄に一時変数が多いと読みにくいしバグになりやすい。
変数を無駄に増やさない!
ローカル変数を問い合わせによる取得にすれば、その部分だけテストできるし。
- メソッドの移動
使用するデータを持つオブジェクトにメソッドは定義されるべき。
ポリモーフィズムを取り入れるのもいいかと。
「そのメソッドが呼び出されたとき、どう振る舞えば良いかはそのオブジェクトが知っている」
例:Switchは自分自身に対して行うべき
この時、わかりやすい様に、メソッド名とか変数名の変更を躊躇しないのも大事。
ここはまだ導入部分だけど、これだけでもリファクタリングの概念はつかめるかな。
早く先が読みたい(*´Д`)ハァハァ
ここまでのまとめ
リファクタリングを行う必要性をこの辺りまではかなり説明してくれていて、
もし、「リファクタリングしたいけど管理者を説得できないし・・・」とか
思っている人がいれば、まずここを読んでみるのはいいかと。
さて、やっと実際のリファクタリングの方法論に入っていけるヽ(=´▽`=)ノ
Software in 30 days
「Software in 30 days」を読んだ感想を徒然と。
おもしろかった所
予測型プロセスの駄目な所
確かに計画なんて上手くいくはずがない。
それなのに長期的な計画を立ててやろうとするなんて。。。
スクラムチームが上手くいくために必要なこと
個人の尊重
開発チームに大きな裁量
エンジニアに裁量がある時が一番良いものが作れる!
詳細まで考えられていて「こういう風に作って!」
って言われたものはだいたいもっと簡単にできたり、
実際に作った後に「違う」って言われたりするなぁ。
スクラムチームの作り方
召集兵より志願兵であること
チームメンバーを惹きつけるメッセージを作る
メンバーの入れ替えとか自発性とかを重視している本だなぁ。
チームメンバーを惹きつけるメッセージとか、
スクラムを導入しているチームに採用する時に使えるし、
考えてみようかな。
ロール毎の役割
- プロダクトオーナー
バックログを明確に表現できる
作業の価値を保証できる
優先順位をつけれる
- 開発者
肩書はない
自己組織化されている
チーム全体で責任を持つ
- スクラムマスター
効果的なプロダクトバックログの管理方法を探す
プロダクトバックログを明確に説明できる
長期のプロダクト計画を理解している
おー。なかなかスクラムマスターとしてやっている!
良かったw
ちょろっと時間ができた時とかに
よくホワイトボードのタスクとか貼り直してみたり、
プロダクトバックログをどういう風にスクラムチーム用にするかとか、
しょっちゅうやってるなーと。
まだまだできてないことも多いしがんばろう!
プロジェクトの中止
- 損失を限定し、機会を浪費しない価値もある。
ほんとこれがわかっていないプロジェクトが多い気がする。
ダメだってわかったらその時点で一旦破棄するべきだろう。
モチベーション
上がる時:仕事を自ら管理できている時
下がる時:もっと働けというプレッシャーがある時
結局、裁量が多ければそれだけモチベーションは上がるかなー。
まとめ
よくあるスクラム本と違って、
モチベーションのこと、チームづくり、スクラムの組織への導入について
とかがおもしろかったな。
「文化に合わせてスクラムを変えるのではなく、上手くやるために文化を変える」
とか、すごく大変そうだけど、必要なことだなと。
1時間で読めたし、オススメです!
AWS Road Showまとめ
全体を通して
なんか入った時からスーツの人ばっかりだなーと思ってたけど、
どちらかと言うと既存企業向けの導入の話が多かったかな。
エンジニア的な話は少なくてちょっとがっかり。
でも、
ワークショップ
Chat Worksの話
AWS re:Invent速報
企業ブース
は楽しかった!
基調講演
固定費、変動費、大企業への導入の話ばっかりだった。
正直おもしろくなかった。。。
ワークショップ
EC2上にAMIインスタンスを作って、
ELBでバランシングするとこまでできた!
普段だったら3000円ぐらいの1レッスンをタダで受けれた。
これでスケールアウトしやすいWebサービスを簡単に作れる。
...でも、他にもいっぱいAWSの機能あるし、
もっといろいろ勉強しないとなと思った。
Chat Worksの話
最初は社内ベンチャーで、
一人で開発したってすごいなと思った。
という順当な感じで進化したのだな。
企業が成長するにつれてAWSの機能の意味がわかってくるらしい。
AWSで始めることで、将来まで安心できる感じいいなー。
いろいろと参考になった。
大きくなるとAWSの地雷を踏むから注意
- ELBは暖気申請しないと落ちる
これぐらいの負荷がくるから準備してねってやつらしい。 - RDSはProvisionedIOPSは必須
IO保証してもらわないとたまに遅くなるらしい。
S3へのユーザーからのダイレクトアップロード、ダウンロード機能
この機能があるとWebサーバー通さなくていいからいいなー。
現在のインフラの構成
User->ELB->AutoScalingEC2->ElasticCache(Session),DynamoDB->S3(Log) ->RDS->ColudSearch ->SQS->EC2(Back End) S3->Glacier(Backup) 直接Upload,Download
AWS関係ないけど、groongaは1億レコードで潰れるらしい。。。 やばいなそれは。
AWS re:Invent速報
玉川さんのAWS関連の本買いたいなー。
増えてるサーバー数
8000億円規模の企業時代のサーバー数と
同じ数のサーバーを毎日増やしてるとかやばい!
45回も値下げできたのは、
規模の経済が起きてるからなのか。
新機能
- Amazon WorkSpaces
仮想デスクトップ
- Amazon Zocalo
ファイル共有
- AWS Directory Service
共有ディレクトリ
- Amazon RedShift
数PBまで使えるデータウェアハウス
すかいらーくで実績があるらしい。
データを24時間だけ保持するサービス
スシローはリアルタイムで15分後の売上を解析しているらしい。
すぐに捨てるデータにはもってこいだな。
- Amazon RDS for Aurora
現状のRDBは複数のレイヤ(SQL,Transaction,Caching,Logging)
が一枚岩になってしまっているのでDBはスケールしずらいけど、
こいつだと簡単にできるらしい。
こんな感じらしい。
パフォーマンス : MySQL5.6の5倍の性能 ストレージ自動拡張 : 最大64TBまで S3へ自動バックアップ データ暗号化
- EC2 Container Service
Dockerコンテナ管理サービス。
今までEC2上に自分でDockerとかはよくある話だったけど、
それをサービスとして提供するらしい。
コンテナそのままデプロイいいなー。
- Deployまわり
Cloud Formation : プロビジョン
Cloud Watch : モニター
Code Commit : プライベートGitリポジトリ
Code Pipeline : ビルド、テスト、デプロイの自動化
Code Deploy : デプロイツール,Gitとかからでも使える
Service Catalog : 複数サーバーのシステムをテンプレートの管理をして構成できる
この辺に関しては、Gitとか、Jenkinsとか、
今までAmazon以外に他の技術を使ってやらないといけなかったことが
全部On Amazonでできるようになるって感じ。
おもしろい方向性だな。
- AWS Lambda
AWS上のイベントをトリガーに独自のコードを実行させられる。
簡単な処理なら、もうサーバーなんていらないじゃんって考えらしい。
Lambda function(Java Script)をデプロイするだけで動作する。
企業ブース
そんなビジネスもあるんだーっていろいろと参考になった。
おもしろかったブースはこれかな
- Splunk
Splunkのロゴの入ったキットカットもらった!
ステッカーもいっぱいもらった。
無料でダウンロードしてAWSのログ収集して、
サポートだけ有料っていうのがいいなー。
- cloudpack
今までAWSって、小さい会社のサイト作るときとかは変動費だからって
結構導入しぶったりされることが多かったけど、
このサービスはAWS上のサーバーを定額提供するらしい。
他のVPSでも別にいいんだけど、
裏のサーバーがAWSっていうのが安心できる。
総括
まぁ、総括すると、これでタダとは、楽しかったなー。
次はもっとエンジニア的なカンファレンスとかに行きたいな。
がんばろうっと!
あ、ノベルティーいっぱいもらった。
認定プロダクトオーナー研修を受けてきた
認定プロダクトオーナー研修を受けてきた。
Minimize build and First release, Maximize outcome and impact.
のためにどうやって
といったことが学べた。
印象に残っていること
プロダクトオーナーは、プロダクトチーム側のスクラムマスター
プロダクトオーナーは
- Product Manager : 価値
- Dev lead : 実現性
- Design lead : ユーザビリティ
そういった人たちをチームとしてまとめ、
ストーリー、バックログを作成していくというのを
あくまで手助けしていくロールで、
決してプロダクトオーナーだけでストーリーを作るのではない、
というところは、Ah ha!(なるほど) と思った。
別になにかを決めるってわけじゃなくそれらをサポートするのが仕事
だから、似てるなと。
User Story Mapping
プロダクトバックログを作っていくにあたっては、
MVP : Minimize Vaiable Product(最低限生存可能なプロダクト)
を見極めるのが大事で、
それをチームで考える為に”ユーザーストーリーマッピング”という
手法を学んだ。
これらの考えと手法を生かしていくためにアピールがんばらないとな。
がんばろー。
XL1200Xフォーティエイトマフラー交換
フォーティエイトのマフラーをバンスアンドハインズの、ショートショットに交換。 パワービジョン(ECM書き換え)はとどいていますが、まだエアクリーナーは届いてないのでとりあえず、ノーマルで。
交換前
外しました
外す際手順としては - エキゾーストのカバーを剥がす - マフラーとエンジンをつないでいる部分を外す - マフラー下部、サイドのボディと固定している部分を外す - マフラーのステーが残るのでプライマリーカバーを外す ※この時デカイ六角が必要でなくて焦ってたら友達が突然ヘルプに来てくれました(笑) - ステーを外して、バンス用のステーに交換 あとは逆の手順で付けていくだけです!
交換後
レビューとしては カナリ爆音。。。もはや爆発音。 で、インジェクションはチューンしてなくてもまぁふつうに、ギクシャクせずには走れます、(燃料濃い。。。)。 吹け上がりが良くなって気持ちよく加速します。 バイクは楽しい!