どくぴーの備忘録

真面目なことを書こうとするクソメガネのブログ。いつ投げ捨てられるのかは不明

第48回情報科学若手の会 #wakate2015 に参加してきました

この間の9/19~9/21 の間,情報科学若手の会に参加してきました.

当日の様子

Togetterとか全体をかっちりまとめてくれているなっちゃんの記事をみてくれよな!!(丸投げ)

第48回情報科学若手の会まとめ #wakate2015 - Togetterまとめ

marin72.hatenablog.com

初日

スタート前

  • 熱海でたまたま同じ電車だった @c_bata_ と合流する.買ってきたおみやげがモロにかぶる.
  • 受付だけささっと済ませたのはいいもののすっと入れる飲食店が見つからず,結局モスバーガーに.

初日発表

  • おうちハックの話だったり.
  • ミツバチとIoTの話だったり.ミツバチの話をしている時の笑顔が印象的でした.
  • プログラムの構成と言語の意味で言語工学的な話かなと思ってたら完全に哲学だったり
  • 群ロボットの制御工学でガチ研究発表だったり
  • Alloyのお話だったり

晩ごはん以降

  • 唐揚げめっちゃ美味しい
  • 交流会でマシュマロチャレンジをすることになり,チーム分けがなされるもチーム全員知ってる人
  • マシュマロチャレンジの追加資源をまともに使った記憶が無い
  • 名乗りの「どうも,クソメガネといいます」がそろそろ板についてきた(よくない
  • LTしてみて猛烈にマサカリをくらい,知見がたまる
  • izumin5210/Bletia · GitHub を作った人からそのままレクチャーを受ける

2日目

2日目発表

  • 統合デザイン環境こと,TextAliveのデモを交えたプログラミングに使っている仕組み(開発環境)のお話だったり,
  • HCI分野に関するお話だったり.プログレスバーのアニメーションでスピードが異なるように見えるの面白かったです.
  • ワンスイッチでWiiを操作するお話だったり
  • 物量でICFPCに勝つ(?)お話だったり
  • インターネットの仕組み(ディープ)だったり
  • ITと宇宙の話でJAXAの公開データにwktkしたり
  • SPARQLの話だと思ったら質疑応答で座長さんの充実しまくった補足説明が飛んできたり
  • Denkinovelを作り続けていることを踏まえて「自分がほしいと思うサービスを作ること」「勉強のために作ること」「ユーザがいるから続けること」大事さを教わったり
  • DevOpsで開発環境を良くするお話だったり
  • LT枠みんな5分すれすれだし綺麗にやるなぁって思った

晩ごはん以降

  • キンメの煮付けおいしい
  • きょろさんのfarmdoor,本当にIoTの一つの目標点って感じだった
  • 浮上型キーボードすげぇって思った
  • 常人の10倍の速度でHappy氏のワンボタンドラクエをプレイする @asanon_s 幹事
  • togetter閲覧会に混ざる
  • 夜な夜な買い出しに行く
  • 澪(スパークリング清酒)の「酸」とはなんぞやってなって思考が崩壊.なっさんひどい
  • ルール追加型大富豪で最終的に序列がフィボナッチ数列になる.当然参加者は徹夜.

最終日

最終日発表

  • TwitterRubyからScalaへの移行のお話だったり
  • ICTトラブルシューティングコンテストのお話だったり
  • ルータ芸人のルータのお話でGoogleとルータ芸人が同じ考えに至っていたことが判明したり

帰宅

  • 眠くて死ぬ.徹夜はアカン
  • 翌日大阪日本橋にいって突如HP Elitebookを購入.26k円
  • 海鮮丼美味しい

まとめ

よかったこと

  • 頑張ってコミュ力を使った
  • 完全に @c_bata_ とダブったおみやげが見事完食された.ありがとうございます.
  • 進路に対して考える条件が一つ増えた
  • LTでもなんでもいいから発表してみると良い.ナイトセッションだとよくマサカリが飛んで来る

次に活かしたいこと

  • メモかちゃんとハッシュタグで実況する
  • 徹夜不可避の場合に備えてドライハードのミンティアを持っておこう(?)
  • 次はフルタイム発表かLT発表したい…,ネタを作らねば…

とまぁ,すでに発表をまとめてくださっている人が居たのであっさり目ですが.参加の敷居も全然高くなく,すごいいい意味で経験値がたまります.人脈然り.知識然り….

来年も頑張って参加します!よろしくお願いいたします!

幹事の皆様方も,参加者の皆様方も,三日間お疲れ様でした.本当にありがとうございました!

potatotips #21 に参加してきました

昨日まで株式会社ウォンテッドリーでインターン生をしてました.どくぴーです.

ところで

ということで,一度行ってみたかったpotatotipsに参加してきました.偶然奇跡的に応募当時空きがあったブログまとめ枠での参加です.

connpass.com

初めて参加したpotatotipsの感想ですが,超がっさりいうと

  • 寿司
  • ビール
  • 唐揚げ
  • 知見
  • 知見
  • 知見

って感じでした.最高.

Side iOS

まとめるために頑張って話を聞いていましたが,当方Androidしか触ったことがなく,完全に勘違いしている可能性がありますので,その場合はご容赦を…

Slack compile time is too slow(_mpon さん)

speakerdeck.com

はじめにさらっとDDDの知見(スライド参照)を話していましたが,本題は6分55秒もかかるコンパイル時間を何とかしようってお話でした.直訳すると「速い」ってはずのswiftなのにコンパイルが遅いのは何事だ!という…

  • 特に怪しいたくさんのSwiftファイルを $ cat *.swift > God.swift して神を降臨させたらコンパイル時間がなんと48秒になった.ただしXcodeは死ぬ
  • 次に怪しいたくさんのExtensionを神のお導きにしたがって手動で13個にまとめたらコンパイル時間が1分55秒に
  • 2つの神をまとめるとコンパイル時間が39秒に!これはswift!!
  • デバッグとかエラー追っかけたりとかすごい大変そう…(感想)

Apple Watch Tips(shoby さん)

speakerdeck.com

FRILのApple Watch対応で用いた体感速度向上のためのTipsと困ったことの紹介

体感速度向上のために…

  • 最初に見える部分は高速に描画
    • 通信なしで画面遷移したり
    • ユーザが読んでる間にロードできるように画面の上にテキストを持ってきたり
    • 画像や追加ロードが必要なものは下に移動したり
  • 何故か画像のロードQueueには1枚ずつ詰めたほうが1枚目のロードが早く終わる.すごい不思議.最適化されてる?
  • 画像ロードが一番ストレスになるし画面に合わせたサイズの画像を配信するようにしよう
  • 画像をひたすらキャッシュして通信を出来るだけ少なくしよう

困ったこと…

  • 何故かWatchConnectivityがDebugビルドじゃ動かないのでAdHocつかおう
  • Bundleにいれる画像の場所を確認しよう
  • アプリアイコンにアルファチャンネルがあると提出できないみたい

体感速度向上のためのTipsはiOS/Watch OSじゃなくて,Androidでも十分適用できるなーって思いました.

3D Touch on iPhone(TachibanaKaoru さん)

www.slideshare.net

もうすぐ発売のiPhone6s/6s Plusに搭載される3D Touchに関するお話.

  • Pressure Sensitivity
    • 指かスタイラスかなんて判定もできるらしい,更には入力角度も…?
  • Quick Actions
    • なんかホーム画面でコンテキストメニュー的なのが表示できるように
    • 実装にはいろいろお作法があって大変そうだな…と思いました(iOSわからない並感)
  • Peek and Pop
    • 軽く押す(Peek)とPeek画面が表示されて,そこから強く押す(Pop)とPeek画面が大きくなって,目的の画面に遷移
    • PeekとPop,直感的ですごい良いねって誰かが言ってた
    • どうやらPeek画面のブラー具合も設定できたりするらしい

一応シミュレータでもできるって触れ込みらしいけど,どうやらうまくいかないらしく,まだAppleのドキュメントでしか情報が確認できないらしいので,続報待たれる!って感じでした

UIKit Sound(cocominap さん)

普段ほとんど音を使わないiOSのUIに音を付けてみようというお話.

  • 非常に楽しそう
  • いろんな音を試していく中で思わぬ気付きがあるかも…?
  • インパクトのある音は毎日聞くと疲れるので,その辺の使い分けとかできたらすごい楽しそう

ショボいPull Requestを積み重ねて、自分の中でOSS活動の敷居を下げる(naoyashiga さん)

speakerdeck.com

代理発表,ということで,以前ブログに書いたら反響が大きかった記事のお話でした.

  • GitHubプロフィール豪華にしたいけどそんなライブラリとか思いつかない!じゃあしょぼいプルリクしよう!
  • 割とショボくても出してみたら感謝される.プルリクをもらうことが嬉しいってのもあるみたい
  • 大体どこも英語だけど英語力がない…→コミットメッセージは「Please Review」でおk!
  • ショボいプルリクでも大丈夫だからOSS活動してスキルアップを目指そう!

iOSに限らず,いろんな分野の人にすごいためになる発表だなぁ…って思いました.

絵の描けないエンジニア/コードの書けないデザイナー(grgr56 さん)

  • 金→アイディア湧く 土日→実装 月→ボツに,とってもつらい
  • 結局かっこいい絵がかけないとプロトタイプにはなれない
  • エンジニアにはかっこいい絵の壁があるように,デザイナにはプログラムの壁がある
  • 絵を書く→ゴリゴリ実装,みたいな流れがorigamiのようなツールによって何かが変わるかも…?

naoyashigaさんの話に続いて,iOSに限らず,いろんな人にとってためになるお話でした.

TestFlishtみたいなのを自作する(tomzoh さん)

www.slideshare.net

  • 受託でのバイナリ作る→動作確認→修正→バイナリ作る→・・・ のループつらい
  • iOSにはTestFlightがあるけど,英語だし担当さんにはつらいところが
  • InHouse経由で独自のTestFlightっぽいのをつくったらいいじゃん

君だけの最強のなんとかgate/なんとかFlightをつくろう!

バグのことは嫌いになってもXcodeのことは嫌いにならないでください(daisuke0131 さん)

www.slideshare.net

Xcodeはクソ?いやいやちょっと待って下さいよってお話.

  • 例外発生箇所がいつもAppDelegateでつらい…→Exception Breakpointを使おう!
  • AutoLayoutの制約矛盾もSymbolic Breakpointで対応できる
  • XcodeもちゃんとBreakpointのオプション活用したらデキる子になって幸せになれる

Side Android

framework code reading(kgmyshin さん)

AndroidのFrameworkのコード,結構ためになるからみんな読もう!というお話.

  • 起動シーケンスや割とjava層で書かれているパターンロック/パスワードロック,TelephonyやPermission周りのコードが最近のおすすめだそう
  • すごい人を憑依させるためにお茶と龍角散,チョコレートを用意しましょう(??)
  • 深く深くまで潜り込むから集中できる環境で
  • ちょっとバージョンが古いけど検索できたりメソッドジャンプができるOpenGrokがおすすめ
  • 使わないエミュレータのイメージがあったらこまめに消しましょう.一気に45GBくらい消せたり…(以前そんな話題を記事にしたなぁ)

To learn Interpolator(amyu_san さん)

www.slideshare.net

Androidで数式からアニメーションを作り出すInterpolatorに関するお話

  • 縦軸Value(0%~100%),横軸Time(0~1)で考える
  • radius × Interpolatorの値で拡大縮小をコントールする
  • MacのGrapherを使えばいい感じにイメージしやすくなる.複数の数式の交点でxを分けて考えると良い
  • ぼいんぼいんバウンドするアニメーションだとAnimetionSetでゴリゴリやるからネストがすごいことになったりするけどInterpolatorを使えば幸せになれる

ああ,すばらしきかなInterpolator(引用)

Recently Google Play Developer Console(tarotaro4 さん)

最近のGoogle Play Developer Consoleの解説をしてくれました.ちょくちょくいろいろな部分が変わっていますよね

  • 【朗報】Android Wearがパームレストにあたってつらい!?二の腕に巻けばパームレストに当たらないし時計は見れるし一石二鳥だよ!!
  • アプリのページを表示した回数とそこからどれくらいダウンロードまでしたのかわかるように
  • レーティング,レビューがいろんなスパンで見れるように
  • レビューに対して返信ができるように.そこからレーティングをアップデートしてもらえるとバッジがつく
  • Crash and ANRとかいう超つかえない機能
  • Optimization Tips,アプリがより使われるためのTips教えてくれるけど大体「タブレット対応しような」.でも一応dismissもできる
  • Cloud Test Lab,Early Accessまだですか
  • 外部APIから画像を取ってくるようなアプリはその画像に依存することになるので年齢的なレーティングが高くなる(某Pixivクライアントさんが弾かれたのはそれかな)
  • 意識して改善を続けると自ずと評価がついてくるから頑張ろうな

ReactNative for Android(petitviolet さん)

speakerdeck.com

突如当初の予定を投げ捨て(?)最近出てきたReactNative for Androidを試してみたお話.

  • JSがロードできないとVistaのようなレッドスクリーンが出る.こわい.F2(AVD),F10(GM),シェイク(実機)で呼びだそう
  • Rract強いなら多少楽に書けるはず
  • auto reloadめっちゃいいよね(JRebel for android…,ウッ)
  • CustomViewが非常に楽に作れるみたい
  • StackTraceが貧弱すぎてデバッグができないのつらそう
  • まだ早い.CordovaでReactするのとは何が変わるの?ってツイートも見たような

Nearby Messages 触ってみた(konifar さん)

speakerdeck.com

近距離通信ができるNearby Messages APIのお話

  • BluetoothWi-Fi,Ultrasoundを使ったPublish⇔Subscribeメッセージングモデル.超音波すごいかっこいい
  • 超音波利用時にpermissionが出てくる
  • 虫が跳んでるみたいな音がする
  • iOSとも通信できる(らしい)
  • 割と簡単に試せるけどまじめに実装と思ったら注意が必要
  • 超音波ってあるからネットワークいらないのではって思うけど結局必要

Promisified BLE Client(izumin5210 さん)

speakerdeck.com

konashi-android-sdkを作る上で味わったつらみをごまかすライブラリ「Bletia」のお話

  • izumin5210/Bletia · GitHub
  • PromisifiedなのでThennableに書ける.コールバック地獄からの脱出だ
  • Saiko no Experience with Promise

Create Layouts with the Wearable UI Library(teshi04 さん)

speakerdeck.com

Android Support Wearable Libraby 1.3.0のandroid.suppoer.wearable.viewパッケージのお話

  • Wearデバイス用のListViewとか
  • 円形のImageViewとか
  • 水平・垂直方向に移動できるViewPagerとか
  • 最大行数とViewの幅から最大文字サイズを計算して,表示する特殊なTexiViewとか
  • Wearの丸型,角形のディスプレイに対応いたLayoutとか

Wear向けのView,って言うことだけど,Phone側にもほしいなーって思うものもいっぱいあった

Popup view on Mortar(KeithYokoma さん)

speakerdeck.com

Fragmentへの反対声明で有名な超企業,SquareのFragmentに対する代替?Mortarに関するお話

  • Fragment/ListFragmentはView & Screen.Presenterで代用できる
  • Dialogはどこにも書いてないけどPopuo & Screen.PopupPresenterで代用できる
  • ユーザの選択はonPopupResultでハンドリングできる
  • 表示するデータは必ずPercelableのextendsで,equalsとhashCodeが実装されてないとダメとか,制約に気をつけよう

以上,全発表のアウトラインでした.スライドがアップロードされている発表は全部網羅したので,そちらも見てください.

当日の様子はこちらから

togetter.com

#ma11 フラグ駆動開発のすゝめ

この間あんな記事書きました

e10dokup.hateblo.jp

そしてこの前の土日でMA11のハッカソンに参加してきました

mashupawards.doorkeeper.jp

この時点で圧倒的に以前のハッカソンと違うところがあります.

お分かりですね.

始まる前から死亡フラグが立ってます

そこで今回僕が味わったフラグ駆動開発(FDD : Flag Driven Development)について説明しようと思います

ステップ1

まず,ファシリテーターの伴野さんから冒頭で「Demo or Die」との言葉が飛んできます.すごい最近タイプした言葉な感じがしますね.早速フラグがグサグサ刺さってます.

ステップ2

イデアソン中に「使う予定ではないけど」とても見たかったので実験棟にあるスマートハウスを見せてもらう.

すると夢中になりすぎて公式アカからお叱りが飛んできた.

ステップ3

サポータ企業さんのAPIを何とかして使おうとしたら進捗がつらくなる.
HTML/CSS弱いのにどうにかしてmonacaを使おうとするものの初日で断念.申し訳ありませんでした

ステップ4

片道2時間弱かけて家に一時帰宅.
深夜ソンにかけようとするものの,インターンで消耗した体には厳しすぎて無事に就寝

ステップ5

目覚ましに反応できない.そしてチームの方から飛んできたメッセに気づく. もう申し訳無さの塊みたいになってるので脳内で土下座しながらまた片道2時間かけて奈良へ移動.

ステップ6

焦りに駆られながらコードを書く.ひらすら書く.ギリギリまで書く.残り40分かそこらでレッドブルが飛来してくるのでグビグビ飲む.

終了

なんとかどうにかまともにデモができるものがアウトプットされる.無事にスライドも読み込んで,デモも終了(なんか更新がうまくいかなかった気がする).そして生駒市長賞を頂き,表彰状(この賞だけある),生駒祭りの法被,たけひめプリン*3を頂きました.ありがとうございます.

終わって

チームの方.本当にお疲れ様でした.ありがとうございました.あとすいませんでした.MA事務局を始めとする運営の方々,サポーター企業の方々も,本当にありがとうございました.進捗は無限に大変だったけど,来る前から思ってた「楽しくハッカソンできたらいいなぁ」が無事に達成できたので本当に良かったです.(あとなんとかデモも間に合ってよかった)

最後に

フラグ駆動開発,ダメ,絶対.

ハッカソンに何を求めて参加すべきなのか

あくまで個人の見解であり,当然のように異論は山ほどあるんだろうけどあくまで主観的な意見なのでその辺りは察してください.

ハッカソン(英語: hackathon、別名:hack day,hackfest,codefest)とはソフトウェア開発分野のプログラマやグラフィックデザイナー、ユーザインタフェース設計者、プロジェクトマネージャらが集中的に共同作業をするソフトウェア関連プロジェクトのイベントである[1]。時にはハードウェアコンポーネントが扱われることもある。ハッカソンは一般的に最低限1日から一週間の期間で開催される。いくつかのハッカソンは単に教育や社会的な目的を意図に開催されるが、多くの場合使用に耐えるソフトウェアの開発や既存のソフトウェアを改善することを目標としている。また、使用プログラミング言語オペレーティングシステム、アプリケーション、API、主題や参加プログラマーの人数を定める傾向にある。

ウィキペディアより引用.

雑に言ってしまうと「超短期間開発競争」なハッカソンだが,最近はテレビ局までハッカソンって言い出したり,猫も杓子もハッカソンみたいなことになっている

www.asahi.co.jp

www.mbs.jp

こんな感じに技術が注目されるのはすごい嬉しい(僕もABCハッカソンに参戦したりした)けど,猫も杓子もハッカソン状態になってしまったことで参加者側も主催側も大変な状況になってきてしまったなぁ…って思ってしまうように.

目的,狙いの相違

ハッカソンで「賞金,賞品目当て」な人と「色んな物をハックして楽しみたい」な人が別れてしまったな,って感じがある.というか,この2つを同時に持ってた人も多かったんだけど,ハッカソンって言葉が浸透してきて,「俺のアイデアで一山あててやる!」みたいな一部の激アツの超意識高い(失礼)な人とかの流入が起きたりとかして,リワードに冷めてしまった人が増えてきてるのかな,という個人の感覚がある,どっちが良いとか悪いとかそんなのじゃないんだけど,参加者の中で温度差が広がってきているよね,っていうこと.

ハッカソンで「未来」「世界」は変えられる?

「未来を変える」だ「世界を変える」だの,大仰な言葉とともに「開発奨励金」という名目の大金を賞金に掲げるハッカソンが増えている.一部のハッカソンを見ると開発したプロダクトに対して製品化・事業化まで持っていけるような サポートをしてくれるものもあるのだけど,そこの過程に関しては「それに携わっている人」から聞くくらいしかまともに知る方法が存在しないし,そうでもしないとハッカソンで作ったあれってどうなってるの?事業化を目的とか言ってたけどほんとにそんな気あるの?ってなる.イベントによる発火性っていうのも大切だけど,「未来を変える」だのといった大仰な言葉を並べるなら,参加している人たちがそこまで出来るようなサポートをして,その頑張りを世間に伝えてあとにつながるようにしてあげないと駄目だし,そんなバイタリティがなければそんな言葉を掲げるべきでないと思う.

「つくれない」のにハッカソンで勝つ

ハッカソンっていうのはだいたいその前にアイディアソンとかがくっついていて,アイディアソンで人気のある,光ってるアイデアに集まってチームを作ったりしてハッカソンに望むのだけれど,ハッカソンで「つくれない」アイデアを出して「つくろうとして頑張ったんだけど結局できなかった」で終わるならいいんだけど,それをつくらずに勝ってしまうっていう例を何度か見聞きしたことがある.しかもその理由は「◯◯で☓☓するというアイデアが良かったので」等の,「いや,それアイデアソンで終わっていいやつやん」っていうものがある.「実際にものを作る」ハッカソンだからこそ,それが実現できたのかどうかってのを見て欲しいし,サポーター企業さんの賞とかは「うちのAPIを使ってるし.アイディアも良かったけどできなかったのは残念,今後に期待」みたいな理由があってもいいと思うんだけど,少なくとも最優秀賞みたいな上の賞は実現できた上でのアイデアの良さで勝負されるべきだと思う.僕自身最後まで間に合わなかったハッカソンが何度もあって,いつぞやのハッカソンで審査員の方から聞いた「ハッカソンはDemo or Die,良いアイデアでも実装できないんだったらそこで終わり」っていう言葉がすごい重く響いたので,ハッカソンでは実現はできなくとも「何とかしてデモできるものをつくりあげよう」っていう努力はするようにしている.

何が言いたいのかというと

ハッカソンにいろんなタイプの人が関わるようになって,住み分けが大変だなぁって思うようになってきた.一部では「エンジニア・デザイナの方のみ」と参加者の役職を制限して開催するイベントもあるけど,根本的な解決ではないような気がするし,もっときれいな住み分けができないかなぁって感じた.僕自身ハッカソンによく参加するので,真剣に考えないとなぁって思った.書いてたら何か考えつくかなあって思ってたけど何も考えつかなかったので申し訳なさ満載な感じで終わります.

ちなみに

明日はこのハッカソンに参加します.

mashupawards.doorkeeper.jp

よろしくお願いいたします.

#高専キャリア に行ってきた

久しぶりに更新

今,東京にいます.21日から,YAPC::Asia Tokyo 2015→#高専キャリア→インターンシップって感じです.

YAPCの話はまたこんどにしようかなって.

高専生のキャリアを考える会(仮)

つまるところ,ジースタイラス高専ベンチャー共催の逆求人関連イベント.なんか現役,OBの高専関係者のLT会です.性質の関係上過激な高専カンファって感じ.

そんな感じでLTしてきました.当日の10時から作ったスライドで.

行った理由

何話したの

高専生もっと外向いて生きていこうなって話しました

印象に残ったこと,思ったこと

  • 後先考えずに飛び込むのも大事
  • ばんくしさんの編入話,去年より前に聞きたかった
  • 学位ってなんだかんだ大切なんだなっぁ
  • 電通大,単位認定が大変そう(こなみ)
  • 比較的優位論(経済とか苦手なのでよくわからない)
  • 女の子を深追いしてはなりません
  • 正しい価値観もとうな
  • 休学,ちゃんとそれをすべき理由があるならいいんじゃないん
  • ブログかこうな
  • 高専カンファ,ぼちぼち100回記念なんだって
  • 高専プロコンOB戦とかいう何でもあり大会が今年あるらしい

成果?

  • 新名刺振りまいてきた
  • 東京どこ行っても大戸屋あるやん
  • チェーン店のありがたみ(ドトールサンマルクカフェマジでありがたい)

短いですが,これで終わりますね

SoundPEATS QY7を買った

人生初のBluetoothヘッドセット買いました.安さと謎なBluetooth 4.1+EDRに惹かれました.

早速開封

なんかそれっぽいケースがついてます.ちゃんと箱の底には日本語のユーザーズガイドがついてましたが,並行輸入品なので読解力(?)が求められます.

そして中身を開けると本体と充電用USBケーブルといっぱいあるフィッティングパーツが出てきました.イヤーピース,と耳の形にフィットする奴2種類の大・中・小の3つずつ入っていますね.これだけで大体の人には合いそう.ちなみに技適マークも付いているので安心して使えます.技適マークなかったらそもそも使えませんしね….

使ってみた

とりあえずはUSBケーブルをつないで充電.ある程度充電したら,電源ボタン(R側のロゴ)を長押しすると「パワァオォン」って教えてくれます.そのまま電源ボタンを押し続けていると「ペェアリィング」って言ってくれてペアリングモードに入ります.ココでペアリングを取ります.一応複数台とのペアリングも対応しているみたいですね.R側には音声コントロール(長押しで曲送り)とマイクも有ります.操作系は全部R側に集中していますね.

音質は…よくわからないのですが,安い割にはなんかいい気がします(以前使ってたのがオーディオテクニカのATH-EQ300Mってのもある気がする).Amazonレビュー見てても「低音強め!」って言ってる人もいれば「低音弱い!」って言ってる人も居ますしもうわけがわかりませんね.

せっかくAndroid Wearがあるんだから

そういえばAndroid Wearは4.4W2(最新版は5.1)からBluetoothヘッドセットがあればオフラインでの単独音楽再生に対応していると聞いたので,手持ちのLG G Watchで早速試してみました.

まず最初にAndroid WearとQY7をペアリングします.設定にBluetoothのデバイスメニューがあるのでそこからペアリングが取れます.それが終わったらAndroid端末でPlayミュージックを起動し,設定を出して,「Android Wearにダウンロード」を有効にした後,「Wearのダウンロードを管理する」をタップすると,Androidのローカルにおいてある曲,Playミュージックからダウンロードしてある曲を選択して,Android Wearに移行できます

f:id:e10dokup:20150721204826j:plain

移行が終わったら,Android WearでPlayミュージックを開き「Wear端末で再生」を選ぶと,さっき移行した曲のアートワークが表示されるので,それを選択すると,Android端末のPlayミュージックをWearから制御するUIで普通に再生されます.ちょっとだけ重くなるけど,許容範囲って感じがします.

スクフェスしてみた

はっきり言って,遅延がひどくてまともにプレイできませんでした.音ゲーはこういうのでするものではありませんね…

タイミング調整してみると-47とか出ましたが,プレイしたisai vividでは遅延に加えて動作自体がもっさり気味になるのでタイミングがバラバラになってすごいプレイしにくかったです.

結論

なんだかんだでいい買い物したかなーと思いました.

Javaのenumで定数を分岐させたい

enumって

列挙型と言われる.一連の値を定義する文法.Javaでも使える.

よく

public static final int HOGE = 1;
public static final int FUGA = 2; 

とかいう形で定数を扱うけど,

public enum Piyo{HOGE,FUGA}

みたいにしておけばintメンバが氾濫しなくなるので(個人的に)スッキリする.また,enumの中に記された値以外の値をブロックできるようになるので,「想定していない値が来た」ときの処理を考えなくて良くなるのがよい

Javaにおけるenum

qiita.com

Javaenumというのは,Cのenumみたいなintを列挙をものではなく,オブジェクトの列挙になるので,enum1つ1つにメンバ変数,メソッドを持たせ,振る舞いをつけることができる.

public enum SelesEnum{
    Tomato(100),
    Potato(150),
    Carrot(120);

    private final int price;

    //コンストラクタは必ずprivateに!
    private SalesEnum(final int price){
        this.price = price;
    }

    public int getPrice(){
        return price;
    }
}

こうしてやることで SalesEnum.Tomato.getPrice()150 が返ってくる.enumはあくまで「プログラム実行時にオブジェクトとして保持する」定数であってインスタンスを持ってはいけないので,シングルトンにするためにコンストラクタはprivateにするように.細かいことは上記記事やEffective Javaを見よう.

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

定数を分岐

例えば「手元のバージョン等の違いで利用する定数を無意識的に変更したい」という場合,enumを使わないと

public final static String[] VERSION_STRING = {"v1.0.0", "v1.2.0", "v1.5.0"};
public final static int V1_0_0 = 1;
public final static int V1_2_0 = 2;
public final static int V1_5_0 = 3;


public String getVersionString(Version version){
    if(version.num == V1_0_0) return VERSION_STRING[0];
    else if(version.num == V1_2_0) return VERSION_STRING[1];
    else if(version.num == V1_5_0) return VERSION_STRING[2];
    return null; // エラー処理とか
}

とかこんなかんじに,長ったらしいし,今後バージョンが増えた時にまた新たにintを割り当てて…となかなか面倒.

そこで,enumを使うと

enum Version{
    V1_0_0, V1_2_0, V1_5_0
}

public enum VersionsEnum{
    VERSION_STRING(new String[]{"v1.0.0", "v1.2.0", "v1.5.0"});

    private final String[] versionStrings;

    //コンストラクタは必ずprivateに!
    private VersionsEnum(final String[] versionStrings){
        this.versionStrings = versionStrings;
    }

    public String getVersionString(Version v){
        if(v == Version.V1_0_0) return versionStrings[0];
        else if(v == Version.V1_2_0) return versionStrings[1];
        else if(v == Version.V1_5_0) return versionStrings[2];
        return null;
    }
}

実際のコード量は増えたが,今後バージョンが増えたり,新たにメンバ変数を増やさないといけなくなった時に,簡単に変更が加えられる(と思う).

Javaenumに振るまいをもたせる記事は探せば結構あったのだが,こういう事している記事はStackOverflow以外で見かけなかったので,メモ代わりに….

終わりに

int定数でごちゃごちゃ書いているんだったらenum化して幸せになろうな,ってお話でした