表題のとおりです。本日は台風で早期の帰宅許可が出たこともあり、代わりにこの記事を書いています。

ちなみに当日は余裕をもって現地に到着して資料を修正しようと思ったら乗るバスを間違えてしまい、最終的にやや遅刻で到着するハメになりました。バス1本遅れることになっても、ちゃんと確認、しよう!

Androidエンジニア デザイン部 #2 - connpass

話した内容に関しては、すごいちゃんと噛み砕いてまとめてくださった記事があるので発表資料とともに紹介しつつ、この記事では当日話さなかった補足部分などについて書きます。

ありがたいUIをもっと大事にしたい - Speaker Deck

Androidエンジニア デザイン部 #2に行ってきました | achanBlog


Getting Over It with Bennett Foddy
左からPC、iOS、Android版の周回数です。最近ベストタイムを見直したらまだ8分切れてませんでした。悔しい。いつか5分切れる男になりたい。

ちなみに作者のBennett FoddyはGoogle Designのインタビューにも呼ばれています。

Design Notes, Episode 7 - Library - Google Design


AndroidとiOSのデザインは合わせなくていいという主張
第三回で話す機会が出るかもしれないのでここでも割愛しますが、最終的に言いたいことは「Androidアプリを使うのはAndroid端末を触るiPhoneユーザーではないぞ」ということです。


「かっこいい」「美しい」「クール」なデザインについて
こうしたデザインを批判するわけではなくて、あまりにも酷いデザインは使うだけで苦痛を伴うことがあるので、決して無視していい要素ではありません。

この「苦痛を伴うレベル」というのは各ユーザーの主観によって決まる要素でもあるため、どこまで作り込めばいいかという難しさがあるのも事実です。


「※アイコンを除く」について
「ホーム画面を自分好みにカスタマイズしたい(整えたい)」という層は一定数いて、その層にとって見た目の良いアイコンというのは大きな価値を持つからです。

とはいっても、本当にホーム画面を整えるために配置している「だけ」ということもあり、その場合は本来私達が望んでる使われ方と全く異なってしまいます。それを許容すべきかというかという新たな悩みどころです。


Youtubeとマルチウィンドウ対応
これはYoutube側に大きな問題を感じるのですが、Youtubeはバックグラウンド再生をしてくれません。バックグラウンドになった瞬間に再生が止まります。

これは地味に辛い問題で、音だけでも聞こえればCMやら小休止が入ったタイミングでさっとメールやSlackやTwitterを確認するといった作業ができますが、音が聞こえないと気づかないうちに再開する怖さがあって、他のアプリが開けません。

ただこうしてマルチウィンドウ対応していることで、片方をながら観しながらもう一方の作業ができるようになるため、実はいままで利用時間帯で競合していた他のアプリと共存できる可能性すら出てきます。

ということでマルチウィンドウ対応に完全サポートしてくれとまでは(いまはまだ)言いませんが、せめて拒絶しない実装になって欲しいなあと最近思うようになりました。ちなみにニコニコ動画は拒絶されてしまうので、ここ数ヶ月でグンと利用率が減っています。

最後に
正直なところ、自分自身がデザインに関しては一定のルール(それこそノンデザイナーズ・デザインブックで書かれているような内容)や統一感が出ていれば、あまりデザインへのこだわりがないタイプという自覚はあります。

ただデザインというのは経験則として、どんどん世界観とかブランドイメージとか広い範囲に意識が行きがちで、状況によってはもっともユーザーファーストからかけ離れたところで議論が始まる可能性のある部分だという認識があります。

そういった中で、本来アプリは誰のために作っているものかという部分に立ち返るために、たまに「自分たちが触っているアプリには(直接コンテンツと紐付かない部分で)ありがたいと感じるところはあるだろうか」という部分にも目を向けてもらえると、多くのデベロッパーが求めているはずの継続率につながるんじゃないだろうかと感じました。
[PR]
# by yamacraft | 2018-08-08 19:30 | 勉強会
ので、対応してくださいという要望がissuetrackerに上がっています。

https://issuetracker.google.com/issues/76155541

そうまでして少しでもいいスペックでAndroidThingsを動かしたいのか!という意見もあるかもしれませんが、新型のRaspberry Piの方が入手もしやすく、さらに旧型よりも安価で買えることが多いので、割と切実な要望だったりします。

Android ThingsがGoogle Play Servicesに対応=Firebaseに対応しているということもあって、個人的にかなり熱い分野として見ているので、開発のしやすさも含めて対応してくれると嬉しいなあと思う日々です。

なのでstarと+1コメントしました。他にも対応を望んでるみなさん、どんどんstar入れていきましょう!

(個人的にZero系でも対応してくれると嬉しいけど流石に難しそう)
[PR]
<まとめ>
- 5月31日をもって株式会社リーディングマークを退職します。
- 今後はフリーランスになります、現時点で正社員になる気はありません。
- リーディングマークとはその後もしばらく週1契約で働きます。
- 週1〜4日でのお仕事探してます。
- 記事の最下部にKyashの送金先QRコードとmonappyの記事を掲載しています。投げ銭いいよね。

【はじめに】
表題のとおりです。5月31日をもって、現在働いている株式会社リーディングマークを退職することになりました。最終出社日は5月11日となります。

ちょうど自分が担当していたプロジェクトが終了したタイミングでもあり、よりプロダクトに密接した働き方を模索していきしたいというのが主な退職理由です。

【今後について】
今後はフリーランスとして活動していきます。35歳というちょうどいい区切りもあり、一度正社員という枠組みから外れた働き方をしたいという判断です。

また個人的な思いや事情から、正社員として退職はしますが、リーディングマークとは引き続き週1による契約でしばらく働くことになります。

ということで、現在週1〜4日で勤務可能なお仕事を探しています。

連絡はTwitter、もしくはGitHubPages内(https://yamacraft.github.io/) のGoogleフォームからお願いします。突然のFacebookメッセンジャーによるコンタクト申請はお断りしています。

またフリーランスとして活動することを大前提としているので、社員採用目的のご連絡に関してはお断りさせていただきます。

【どんなことができるの?】
主にAndroidアプリエンジニアとして活動していました。

最近はCircleCIやDockerを駆使していろんなことを自動化しながら、開発の土壌作りをすることが得意分野な気がしています。あとはプロダクトの仕様を固めていくのも得意分野な気がしています。

CI環境だけもくもくと作ったプロジェクトですが、例えばプロダクトにおいてはこんな感じの環境を作りたがる人です。
https://github.com/yamacraft/TempRa-android

具体的な細かいスキルやキャリアに関しては、Web上で職務経歴書を公開しているのでご覧ください。ちなみにこれもGitHubで管理し、内容が更新されるたびにCircleCIでPDFファイルをFirebase hostingにデプロイする仕組みで運用しています。
https://yamacraft-cv.firebaseapp.com/

他にもプライベートなプロダクトをいくつか作って運用したりしています。
https://yge.yamaglo.jp/

以上です。

【最後に】
ちょうどnoteを使った有償退職エントリが注目されていました(というのを教えてもらいました)。

自分としては、コンテンツは全部公開した上で「気に入った人が好きな分だけ対価を投げることができる」という投げ銭方式がとてもとても好きです。なのでKyashのQRコードとモナコインが投げ銭できるmonappyの記事(team Y.G.E.の紹介記事)のリンクを掲載することにします。よろしくお願いします。

d0252816_14043951.png


team Y.G.E. について - @yamaglo_ygeのメモログ | Monappy
https://monappy.jp/memo_logs/view/yamaglo_yge/1203
[PR]
# by yamacraft | 2018-04-27 17:30 | いろいろ
この記事は、メルカリアッテ終了に関するブログ記事に触発されて書いたものになります。

http://mercan.mercari.com/entry/2018/03/19/121649

前書き
先月の某日、社内における業務(?)改善の一環として開発と運用をしていたプロダクトを終了しました。
今回はそのプロダクトで得た知見を共有します。

結論
* NFCわかんない…でもおもしろい…
* Androidビーム搭載しているかを調べるのが難しい…
* Androidビームを利用する非タブレット端末の設置ってどうすればよいんだろう…
* Android Things(Raspberry Pi)だといろいろ解決できたかもしれない

どんなプロダクトを作ったのか
現在働いている会社のオフィスでは、入室に某社のスマートロックを利用しています。
d0252816_16552848.png

スマートロックの解錠には、各個人のスマートフォンにインストールした専用のアプリを使います。このアプリが曲者で、一部の端末で正しく動作しなかったり、そもそもスマホにアプリがインストールできない方もいました。

この「アプリが正常に動作しない」社員がほかの手段を使って解決できるようにするために始めたプロダクトです。
社員のスマホに代わり、解錠を行う専用アプリがインストールされた端末を、入り口に設置して運用します。
d0252816_16555456.png

(自分を擁護するために突然書きますが、事前にこのシステム導入の検討を聞いていれば絶対に賛成しません。)

ちなみにこのプロダクトの簡単な説明は、以前にFirebase勉強会でも発表したことがあります

社内用アプリでFirebaseを使っている話 // Speaker Deck
https://speakerdeck.com/yamacraft/she-nei-yong-apuridefirebasewoshi-tuteiruhua

プロダクトを通して感じた問題点
あまりコード部分の技術的な話は書いていません。

NFCの何を一意の情報として取得すべきか判断しきれなかった
詳くないのであんまり解説っぽく書くとマサカリ飛んできそうなので詳細は書きません。NFCにも種類があり、本当に一意となる情報をどうやって取得すべきか正しく判断できませんでした。解錠のログはスタックさせていたので、とりあえず実装最優先でserialIdの値を使って識別するようにしました。

Androidビーム対応している端末がわからない
すべてのAndroid端末はNFCの読み込みに対応しているわけではなく、「Androidビーム対応機種」から今回のシステムに使う端末を選定する必要があります。

ここがとてもやっかいで、各端末の公式サイトを見てもAndroidビームが対応しているの判断できないケースが多くありました。結局今回はNexus5を利用することにしましたが、たとえば受付システムをタブレットにした場合、どれを選べばよいのか私は選定できる自身がありません…。

(実際に先日のDroidKaigiでKIOSK端末に関する発表をしたスピーカーの方もAndroidビーム付きの端末を対応したことがないと言っていました。廉価版ほど非対応な気がします)

スマートフォン端末を受付機として設置しづらい(NFC読み込みを使う場合)
スマートフォンのNFCリーダーは端末の背面に設置されています。そして、カードを認識させるためにはカードを接触させるぐらいには近付ける必要があります。

これがとても曲者で、多くのスマホスタンドはスマホの背面部がスタンドの支点となるように設置されています。つまりカードがタッチしづらくなります。

マイクスタンド的なものもいちおうあるのですが、これは大半がiPad用です。Androidタブレットに対応しているのかは、試しに買ってみないことにはわかりません。おそらくハンドセットサイズのスマホでは使えないでしょう。

Nexus5のBluetoothが頻繁に死ぬ
これは自分が使っていた端末固有の問題かもしれません。Nexus5を点けっぱなしで放置すると、Bluetoothの機能が死んでしまい、その都度端末を再起動する必要がありました。キオスク端末化しておけば、多少は再起動の対応も楽にできたのかもしれません。

プロダクトを通して感じたこと

Raspberry Pi+AndroidThingsだといけるのでは?
今回は既存のスマートフォン端末を利用する形で運用を行っていました。これをAndroid Thingsで動かしているRaspberry PiとUSBのNFCカードリーダーを使えば、もろもろの問題は解決できたかもしれません。これならすべて新規でそろえても10,000円から15,000円程度で用意できますし、何よりOSも常に最新で開発者のモチベーション維持にもつながります。

ただしこの場合、NFCカードリーダーの読み取りをちゃんとアプリ側で認識できるのか、ケース等をどうするかといった部分の課題は残ります。後者に関しては、みんな簡単にレゴとかで作っているケースがあるんですけど、幼少期にレゴとの触れあいがほとんどなかった自分にはまったくわからない世界です…。

ちなみにプロダクトを終了した理由は、上記の実運用を考える上で実験費用がどんどん掛かりそうなこと(注)。あとは諸々の理由です(ここには書きません)。

以上です。

(注)…自分が勝手に始めたので経費はポケットマネー
[PR]
# by yamacraft | 2018-03-25 23:30 | いろいろ
結局所要で記事書く時間が確保できなかったので、いまから30分ぐらいでとりあえず来年絶対にやると決めた目標(+それに至った反省など)を書きます。

テキスト(ブログなど)の執筆環境をちゃんと構築する

これまでブログやGist、Qiitaに記事の下書きはDropboxにあるMarkdownファイルに書いていたのですが、養成読本の執筆以降にRe:VIEWをちゃんと覚えようと思ったのと、Dropboxの保存は頻繁すぎてどうかなと思ったのでRe:VIEWプロジェクトで構築してGit+GitHubで管理するように10月ぐらいに切り替えていました。
さらにRedpenやtextlintを使って「安定した」文章になるようにリントもかかるようにしていました。

ただこれは「一度にいくつもの記事を同時に書きたがる」自分にとって、まずGitのプロジェクトでは1記事1ブランチといった管理が不可能なこと、頻繁なRedpenやtextlintのチェック修正で疲弊するといった問題に直面してしまいました。あと指定のファイルのみをmdやhtmlに変換するといったやり方も用意していなかったのが大失敗でした。

この辺りの反省から、どうすれば自分にとってストレス無くテキストが書ける環境を作れるのかという方向は見えていたので、2018年には真っ先に取り組みたい目標です。

ちなみに「30分ぐらいで書く」と書いたように、これはredpenもtextlintも使わずの一発書きです。

個人プロダクトの開発をもっと積極的に取り組む

去年の9月以降は個人プロダクトで学んだ内容をどんどん業務にフィードバックしていったような印象がありました。というか個人プロダクトを持っていたからこそ先に学んでいたものが多くて助かった…という感じのことが多かったですね。

特に個人プロダクトの場合、わりと気楽に初めての分野に手をだせるところがあるので、来年はより積極的にやっていきたいなあと思いました。特にAWSかGCPのあたりを…。

最後に

という感じでぼんやりとした内容になりました。他にも目標はいくつかありますが、それは自分の中にひっそりとどめておくことにします。

それでは今年一年おつかれさまでした。また来年もよろしくお願いします。
[PR]
# by yamacraft | 2017-12-31 16:03 | いろいろ