弊社プロダクト「連絡とれるくん」では、サーバサイドに Kotlin を採用しています。
今回は、 Kotlin の定数について、自身の復習をかねて紹介します。
【目次】
・ 前提条件
・ コンパイル時定数
・ 通常の定数 (非コンパイル時定数)
・ 遅延初期化定数
・ enum 定数
・ object 定数
・ 終わりに
「定数」は、大きな意味だと 不変の値 ですが、クラス機能のある言語だと 静的アクセスが可能なこと も条件に含まれることがよくあると思います。
※ 静的アクセス可能 : クラスのインスタンスを作らなくても使用できる領域に定義したもの
Kotlin だと (トップレベル, object
, companion object
) いずれかに定義したプロパティや enum
、object
この記事で扱う定数としては、下記とします。
・ 静的アクセス可能な val
プロパティ (変更不可プロパティ)
・ enum
・ object
定数の定義場所による分類は、複雑になるためしません。
Kotlin on JVM の話になります。
・ コンパイル時に値が決まる
・ 使用できる値は、プリミティブ型と String 型のみ
・ アノテーションのパラメータにできる
・ バイトコードでは定数の使用箇所にインライン展開される
定数の中で一番強いです。
ただ、コンパイル時に値が決まっておく必要があるので、 new
の必要な参照型は使えません。(String リテラルだけ例外です)
関数を通す必要がある場合 (= コンパイル時に値が決まらない) も使えません。
Spring Boot 等のアノテーションを多用するフレームワーク・ライブラリを使っていると、アノテーションのパラメータにできることは割と重要です。
バイトコードでインライン展開されることによる問題 (定数の値が変更された場合に使用箇所が再コンパイル対象にならない) は、 Gradle + Kotlin 環境では遭遇したことはないです。
Kotlin コンパイラがよしなにやってくれてると思われます。
コンパイル時に値が決まらない定数は、これになります。
アノテーションのパラメータにはできません。
@JvmField
を付けている理由は、 getter 関数が作られることを防ぐためです。
(public プロパティに getter 関数が作られるのは Kotlin の仕様)
定数の getter 関数があることによるコード上での弊害は無いですが、定数は基本フィールドに定義する派なので付けるようにしてます。
個人的に @JvmField
機能も const
のように構文の方がよかったのでは、と思ってます。
Kotlin の Delegated Properties の lazy 機能を使った定数定義です。
Delegated Properties は getter 関数必須のため、 @JvmField
指定はできません。
プログラム内で定数が初めて使用された時に、値が作成されます。
逆に言えば、使用されるまで、値作成のための計算処理は行われず、値に必要なメモリも確保されません。
使用用途としては次になります。
・ プログラムの起動を速めたい場合
・ 共通モジュール (ライブラリ) において、未使用状態であれば値を作ってほしくない場合
クラスのインスタンスをまとめて定義できて、かつ、アノテーションのパラメータにできる優れものです。
まとめて定義するものなので、定数グループが主な使用用途になります。
各種 java ライブラリでシリアライズ・デシリアライズ機能も充実しています。
そのため、 API のリクエスト・レスポンスで値が決まっているもの (いわゆるコード) の型としても採用しやすいです。
Object declarations はシングルトンを作る機能で、定数のように扱えます。
単体だと enum
の 1 個版みたいなものです。
ただし、アノテーションのパラメータにはできません。
Sealed Classes と組み合わせることで、カスタマイズ性の高い enum
のようなことができます。
object
を定数として扱う場合は、これが大半の使用用途になると思います。
enum
だと書き辛い/書けない場合に sealed class
+ object
+ xxx
を選択する感じです。
Kotlin で定数と認識してるものについて、説明してみました。
Java と比べて、遅延初期化定数と object 定数は Kotlin 独自のものになりますが、 Java で実現できないこともないと思います。
(ただ、実装はたぶん面倒...)
定数に限った話ではないですが、使用用途を意識して書くことで、いいコードに繋がると思います。
書いた人: プロダクトデベロップメント部 藤本泰輔
]]> 今回はjourneyappsが提供しているオープンソースライブラリであるZXing Android Embedded(以下ZXingと略します)を使用して実装を進めていきたいと思います。(Android Studioでプロジェクトを作成するところは今回割愛させて頂きます)
プロジェクトを作成したら、まず以下の記述をアプリ側のbuild.gradleのdependenciesに記述します。
また4.1.0はライブラリの中でJava8のラムダ式を使用しているので、以下もアプリ側のbuild.gradleのandroid内に記述しておきます。この記述に関してライブラリ側の使用例に記載されていないので注意が必要です!実装する際にここでハマりました笑
build.gradleへの記述が終わり設定を適用したら、次にAndroidManifest.xmlに以下を追加しQRコード読み取りカメラを起動する準備をします。
hardwareAcceleratedはGPUを用いて画面描写高速にするもので、use-permissionはカメラとフラッシュの使用を許可するために必要な記述です。Activityに関してはZXingがデフォルトで提供しているActivityを起動するのに必要になります。ただ、後述するカスタムレイアウトを使用した別Activityでカメラを起動する場合は用意したActivityを使用することになるので、不要となります。
ここまででQR読み取りを実装する準備が整いました!次に実装に参りましょう。
ここからは実際にQRコード読み取り画面の実装をしていきたいと思います。今回はデフォルトで用意されているものをボタンを押すことで起動するような形で作成していきましょう!
まずはアプリを起動した際に初期表示されるMainActivityを以下のレイアウトにします。とても簡素で実際にこんな画面になることは無いと思いますが、簡単に実装していくことが目的なので今回トップ画面はこのような形になりました。
次にボタンを押した際にQRカメラを起動するようにするため、clickListenerと読み取った結果をトーストで表示する実装をしていきます。
コード上でコメントを記載した通り、たった数行記述するだけで簡単に実装することができます。以下がカメラを起動した際の画面と読み取った後の画面になります。
このようにライブラリを使用するととても簡単に実装することが出来ます!またデフォルトの読み取り画面もコード上で多少のカスタマイズを以下のように行えます。以下に記載した以外にもカスタマイズオプションがあるので実装する際には色々試してみると良いと思います。
ここまででデフォルトで用意されているActivityを使用してQRコード読み取り画面の実装を行いましたが、読み取り画面のレイアウトを自分好みにカスタマイズした画面の実装方法を紹介して終わりにしたいと思います。カスタムレイアウトを適用するにあたって用意するものは以下になります。ファイル名に関しては適宜変更して問題ありません。
・CustomScannerActivity
カメラ起動した際の遷移先Activity。
・activity_custom_scanner.xml
カメラ起動した際のActivityのレイアウトファイル。
・custom_qr_code_scanner.xml
カメラ画面に適用するレイアウト。レイアウトをカスタムする際にはこのレイアウトファイルを編集して見た目を変更していきます。
今回はカスタムレイアウトでQRコードが読み込める旨を伝えるテキストとフラッシュのON/OFFを切り替えられるようなスイッチを配置したレイアウトを作成したいと思います。
フラッシュを使用する際の制御やカメラ設定等を記述するActivityです。今回はフラッシュのON/OFF制御のみとカメラの起動のみの処理を記述していますが、カメラ画面内で別のことをやりたい場合はここに記述することになると思います。以下がコード内容でそれぞれ処理にコメントを入れています。
読み取り画面のActivityに対応するレイアウトファイルになります。今回はカメラ用のレイアウトを用意し、カスタムレイアウトを読み込むだけなので以下になります。
実際にレイアウトをカスタムするためのレイアウトファイルになります。BarcodeViewとViewfinderViewはカメラや読み込み可能範囲の表示に必要なもので、デフォルトで提供されているものを使用します。今回はフラッシュを制御するスイッチとQRコードが読み込める旨を記載したテキストを配置しています。
デフォルトで提供されているBarcodeViewやViewfinderViewにもカスタム属性が用意されており、コード上に記載されているzxing_viewfinder_laser_visibilityをfalseにすることで読み取り可能領域の線を消すことができたり、zxing_possible_result_pointsで読み取り可能領域でバーコードを読み取っている最中の色を変更することもできるので、デフォルトで用意されているViewにおいても様々なオプションが設定出来ます。
カスタムレイアウトの用意が出来たら後は、AndroidManifest.xmlとカメラを起動する際のオプションを以下のような記述を追加するだけでカスタムレイアウトが適用された読み取り画面を起動することが出来ます!
起動した画面は以下になります。左上のスイッチでフラッシュのON/OFFが切り替えられ、可能読み取り領域の下に文言が表示されていますね!
今回はライブラリを使用してのQRコード読み取り画面を作成してみました。なるべく簡単めに実装を進めており、読み取り可能領域フレームの見た目を変更するといったことは今回行っていないので、今後はデフォルトで用意されている部分を変更する実装もしてみたいですね。最近では難しい実装をライブラリで簡単に実装できるのでとても便利なので、使用出来るものは積極的に使用していきたいなと思っています。
お読み頂きありがとうございました。
プロダクトデベロップメント部スマホチーム、チームリーダの高橋 篤史(たかはし あつし)です。
Phone Appliでは週に1回、30分の「1on1」を実施することが必須となっていて、部署・チーム内コミュニケーションの促進に活用されています。今回は私が所属するプロダクト本部、そしてスマホチームでは1on1一つ取っても色々なやり方をしている、ということを紹介してみようかと思います。
特色としては、一般的に1on1というと「上司と部下」が行うもの、とされることが多いですが、プロダクトデベロップメント部では「メンバ同士(正確にはチームリーダ × メンバですが上司と部下の関係ではない)」の1on1も活動の一部として行われています。
以下にその種類について上げていきます。
(これは基本的な形で、状況に応じて追加や調整が行われています)
※尚、コロナ禍の影響で現在1on1はほぼ100%オンラインで行われています。
【ペアリング】
・プロジェクト主担当テックリード × プロジェクトメンバ
・チームリーダ × チームメンバ
【頻度と時間】
・週1回 15 ~ 30分
【メイントピック】
・プロジェクト活動について色々
【ペアリング】
・チームリーダ × チームメンバ
・マネージャ × チームリーダ
【頻度と時間】
・週1回 15 ~ 30分
【メイントピック】
・プロジェクト活動以外について色々
【ペアリング】
・マネージャ × メンバ
【頻度と時間】
・月1回 15分
【メイントピック】
・部やチーム全体の活動について色々
【ペアリング】
・マネージャ × メンバ
【頻度と時間】
・四半期に1回 30分
【メイントピック】
・今後のキャリア活動について色々
基本的な1on1の紹介は以上になります。
以下はスマホチーム独自で運用されている1on1の仕組みです。
全員と話す機会を設ける観点から、毎週1on1を担当するチームリーダが入れ替わる方式を採用(スマホチームのチームリーダは自分含め現在2名)
・つまるところ、隔週でチームメンバ全員と1on1してるよってことです 。
・ペアリング・頻度と時間・メイントピックはメンタリング1on1に準じます。
・ただし、スマホチームでは「メンタリング」ということは強く意識していて、プロジェクト関連の話はプロジェクト1on1に任せて、雑談や気になっていることを話すことが多いです。
【チームリーダとメンターとメンティの3者面談】
・新卒やインターン生のフォローなど、メンターがチームリーダとは別でいる場合に採用。
・頻度と時間・メイントピックはメンタリング1on1に準じます。
・基本オンラインでしかできないので、テレワークの中で生まれた新しい形かと思います(感想)。
1on1とは少し外れるのですが、新卒研修のフォローのために毎日15 ~ 30分、プログラミングや一般業務に関する疑問を解消するためだけの時間を定期的(時間を決めて)に取っていました。
この記事を書こうと思ったきっかけは、最近joinされた方から「(いい意味で)こんなに1on1に力を入れて色々取り組んでいる会社はなかった」という感想をいただいたからでした。
今後テレワークが主流になっていくかもしれないという情勢の中で、1on1などの社内コミュニケーションは更に重要度を増していくのではないかと個人的には思っています。そんな状況下でも「こんなやり方ありますよ」とすぐに提案していけるように、1on1に止まらず色々な活動を工夫できるよう、頑張っていきたいものです。
ちなみに、ブログ投稿2回目なのですが技術以外のことしか書けていないので次こそは技術的なこと書けたらいいなー・・・。
]]>タイトルでなんとなく察する方もいるかもしれませんが、この本は「カイゼン・ジャーニー」の番外編のような内容となっております。ちなみに私はカイゼン・ジャーニーは未読です。もちろん未読でも問題なく読むことができますが、読んでおくとより楽しめる、らしいです。
さて、この「チーム・ジャーニー」がどのような内容かというと、「チーム開発をどうやって進めていくか?」をテーマに書かれています。物語形式でチームメンバーが問題に直面するところを描き、どうやればうまく問題を解決できるかを解説する、というのを繰り返していき、チーム開発に必要なノウハウが理解できるようになるという構成になっています。
物語形式なので最初はとっつきにくいと思いましたが、読んでいるうちにリアリティのある問題に直面するチームメンバーに感情移入でき、最終的にはとても理解しやすいと思うようになりました。
この本のターゲットとしては、アジャイルっぽいことをやっているがいまいち機能しているのかわからないと思っている人、あるいはチームリーダーの人、これからチームリーダーになるかもしれない人、そしてプロダクト開発に関わるチームメンバーの人、という想定がされています。
弊社のウェブチームでは、10月から新しくチーム編成を見直すことになりました。チームの中のチーム編成というと変な気もしますが、「ウェブチーム」という単位そのものが部署のようなものだとイメージしていただけるとわかりやすいかもしれません。
弊社では今までプロジェクトにメンバーをアサインしていく形式でしたが、10月からはチーム単位でプロジェクト開発に取り組んでいく形式に変わります。いままでのメンバーとは違う、新しいチームで開発することになります。そのため、一度チーム開発について理解を深めておこうと思い、たまたま書店で目に入ったこの本を手に取りました。読んでみて、ぜひ他のメンバーにも共有したいと思ったので、こうしてブログという形で感想を書いています。
この本では、開発チームが実際に陥りそうな問題の具体例を上げて物語を進め、解説ターンでどうすればうまくいくのかを説明しています。主人公は3回転職しており、4社目に入社したばかり。この設定に自分と似たものを感じ「うっ......」となりました(笑)
違うところは、入社してすぐにチームリーダーに任命されたあたりでしょうか。
チームとはどういった目的で集まり、何をするために存在しているのか。状況に応じてどういった役割をするべきなのか?など、この書籍では解説されています。とくにチームリーダーの方、スクラム開発に取り組むチームメンバー、それからPO(プロダクトオーナー)の方にもおすすめしたい本でした。
実際のプロジェクトで、役割によってそれぞれがどう立ち回ればチーム開発がうまくいくのか、ということを考えさせられました。
私は今年、会社主催のインターンシップに参加しました。そこで学生の皆さんに自分の仕事内容を説明し、質問を受けたりしました。その最中に「どうしてフリーランスにならないんですか?」という質問を受けたことがありました。
その時は「自分にはフリーランスは向いていないから」という曖昧な返答しかできなかったのですが、チーム・ジャーニーを読んでいてその質問の答えを改めて考えてみました。私は個人プレーよりもチームプレーのほうが得意です。思い返せば学生時代にスポーツをやっていたときも、個人競技よりもチーム戦のほうがやる気にあふれていました。私は「自分のため」よりも「チームのため」「会社のため」という大義名分があったほうがモチベーションが上がることを再認識しました。
10月以降に編成されている新しいチームにも貢献し、最終的には会社のためになるプロダクトづくりをすることを目指したいと思っています。
目次
1. 研修内容
2. 課題成果物発表までの道のり
3. 感想
4. 終わりに
1. 研修内容
今回の研修期間は、約三ヶ月間(6月 ~ 8月)ありました。その期間内に、「プログラミングの基礎(Kotlin)」と「コンピュータの基礎(基本情報技術者)」を中心に、座学での学習を進めていき、最終的には、個人で企画・設計・実装をした成果物を開発チーム全体に発表することを研修のゴールとして進めていくカリキュラムでした。新卒エンジニアには、メンターが一人ついてくださり、質疑応答・成果物の企画・設計のサポート・実装ではレビューなどをしていただきました。さらに、今回は新型コロナウイルスの影響で、これら全てがリモートで行われました。
次に、実際に私がメンターさんと行った成果物発表までの道のりについて書きたいと思います。
2. 課題成果物発表までの道のり
私が行った課題成果物の開発工程としては、「企画」 → 「画面設計」 → 「DB設計」 → 「API設計」 → 「実装」 → 「テスト」 → 「発表」 という流れでした。今回の実装では、「Spring Boot」 + 「Kotlin」を使い、 API側とフロント側に分けて「JSON」形式で通信を行うようにしました。また、各工程で、メンターから自分のやったことに対する評価(レビュー)を受けながら進めていきました。開発を進める中で、特に苦労したことは、「API設計」です。画面・DB設計で、実現したい機能や必要なデータなどを固め、そのために必要なAPIも参考書やサイトを見ながら設計を進めました。しかし、完成した設計書をメンターに見ていただいたところ、「この機能を実装するためのAPIがないのでは?」「このPOSTメソッドは、使い方が正しくないです。」など、抜け漏れからHTTP通信の仕組みなど、幅広く指摘されました。作成している中で、雰囲気で行っていた部分やサイト・参考書の内容をそのまま鵜呑みにして行った部分も多くあったので、Webアプリケーション全体を理解することや「どこの機能を作成しようとしているのか」といった「目的からの逆算」をすることの重要性を知ることができました。そのような経験を重ねながら、開発を進めていき、無事に発表を終えることができました。
3. 感想
個人的に、「良かったな」と感じたのは、「自分で実装した部分を人に説明ができるようにする」という意識が芽生えたことです。開発期間中に「レビュー」をしてもらう時は、アドバイスや指摘だけでなく、「どうして、このようにしたのですか」といった質問も多くありました。自分は「動くことが優先」とすることが多かったため、最初の頃は、「どうしてだろう」と自分でも疑問に思ってしまう場面がありました。しかし、繰り返し行っていくことで「自分のコードはわかりやすいかな」「変数名は合っているかな」など、動かすことができた後に考えられるようになっていきました。このようなことを意識的にできるようになったのは今回の研修で良かったことかなと思っています。
4. 終わりに
三ヶ月間という短い期間ではありましたが、プログラミングやコンピュータの基礎からWebアプリケーション開発まで、いろいろ知ることができました。現在はプロジェクトに配属していますが、研修での経験や知識がなかったら、もっとひどい状態だったのではないかと思うくらいスピード・知識・説明などが求められます。ですが、できることを積み重ねながらレベルアップをしていきたいと思っております。ではでは〜〜〜
弊社プロダクトの「連絡とれるくん」では、サーバサイドに Kotlin を採用しています。
Kotlin 採用理由の 1 つに Null Safety があります。
採用当初はあった方がよさそうくらいの感覚だったのですが、使い続けてみて null の概念のある静的型付け言語には無くてはならないもの、に変わってます。
そんな Null Safety について開発経験を基に紹介します。
【目次】
・ Null Safety とは
・ なぜ null を管理したいか
・ 基本は non-null type
で
・ Kotlin の Null Safety で気を付けるべきこと
・ 終わりに
公式ドキュメント にある通りなんですが、簡単に言うと
・ null を代入できる型 nullable type
・ null を代入できない型 non-null type
の 2 つに分けて null をうまい具合に管理することです。
null とはすべての参照型に代入可能な便利なものです。
初期値やデフォルト値にできます。
ただ、すべての参照型に代入できるということは、制約が無さすぎるのです。
静的型付け言語のメリットの 1 つは、継承関係の無い型 A から型 B への代入をコンパイルエラーで防げること(つまり制約になる)です。
null はこの制約にとらわれないジョーカーのようなものです。
non-null type
があると、 null に対して制約を課せます。
例えば、参照型の引数を 1 つ持つ関数の実装を考えてみます。
参照型の引数は null の可能性があるため、 null についての振る舞いも設計します。
(もちろん null を考慮しないまま実装して NullPointerException が発生したら、その時はスタックトレースから調査、という方針もありますが・・・)
引数が null の場合の振る舞いとしては大体下記になると思います。
・ IllegalArgumentException を投げる
・ 何もしないで終わる (戻り値があるなら null を返す)
・ null を何らかのデフォルト値に置換して、処理を行う
ここで non-null type
の引数にすれば、関数側の null についての振る舞い設計が不要になり、関数本来の機能に集中できます。
non-null type
で関数の引数を non-null type
にしても、関数の呼び出し側で null 除外する手間は残ってます。
Kotlin には null 除外のための便利な機能 ?.
/ ?:
がありますが、手間であることには変わりないです。
関数の呼び出し側、つまりコード全体で non-null type
を使うようにすれば、null 除外の手間は減ります。
どうしても nullable type
を使わなければならない箇所は存在しますが、そこだけ気を付けて null 除外すれば Null Safety なコードになっていきます。
Kotlin on JVM の場合、 Java のライブラリを簡単に使用可能です。
Java のライブラリから取得できる値 (メソッドの戻り値など) は、 nullable type
と non-null type
両方の可能性がある platform type
というものになります。
※ ただし 決められた @NotNull / @Nullable アノテーション が付いていれば nullable type
と non-null type
に明確に分かれます
platform type
は、 non-null type
の可能性があるため null 除外処理が無くてもコンパイルは通りますが、 nullable type
の可能性があるため null である可能性は十分にあります。
もやっとする話なんですが、ようは @NotNull
/ @Nullable
アノテーションを明示していない Java ライブラリは、コンパイラによる Null Safety の支援は受けられないので、ライブラリの仕様を理解して使うしかない、ということです。
Null Safety について感じていることを言語化してみました。
最初に書いたとおりなんですが、 null の概念のある静的型付け言語は nullable type
/ non-null type
の使い分けはできて当たり前、と思うようになってます。
今後、他の言語を採用することになっても、 Null Safety の有無は大きな判断基準の 1 つになると思います。
個人的に好きな言語である C# は 8.0 から Null 許容参照型 が導入されてて嬉しいです。
書いた人: プロダクトデベロップメント部 藤本泰輔
こんにちは。株式会社Phone Appli プロダクトデベロップメント部のくりきです。
今回は私が普段の業務で書いているメモのTipsを書いていこうと思います。
私は業務中によくメモを取ります。メモにはやること、考えていること、聞いたことなどを記録しています。TODO管理もここで行います。
チャットツールなどで議論したことや、ちょっとした雑談で決まった出来事なども書くことで、あとになって「あの会話したのいつだっけ?」「○○やったのいつだっけ?」というようときに検索して見つけやすくなります。作業のログも残します。
チャットは他の人の発言で流れてログを探すのが大変ですが、個人メモならその心配はありません。以下ではメモの書き方を説明します。
1.ファイルを作る
2.テンプレを作る
3.メモを書く
4.TODO欄
5.MEMO欄
まず、アクセスしやすい場所にてきとうな名前をつけたファイルを作成します。
私はデスクトップに「plane text.txt」というファイルをおいています。名前はなんでもいいです。
メモのテンプレです。手順1で作ったファイルをお好きなテキストエディタで開いて以下をコピペします。
---テンプレここから
2020/01/01 ----------------------------------------------------------------------------------------------------------
2020/01/02 ----------------------------------------------------------------------------------------------------------
*************************************************************************************
■ TODO
■ MEMO
----テンプレここまで
ファイル全体の構成は以下の画像のようになっています。各項目に書くことについて、順番に説明していきます。
ミーティングの議事録、チャットへの投稿の下書き、考えていることなどなんでも書きます。以下は私のある日のメモです。その日のTODOも書いておきます。
(見やすいように修正を加えてあります)
この日はミーティングがあったのでそこで質問したいことや、スプリントレビューで出た発言などを記録していました。ほかにも、「これからやろうとしていること」「誰かに相談しようとしていること」なども書いています。
書き方は自由ですが、私は書きやすいという理由でMarkdown風に書いています。
業務開始時に日付の行をコピペして、今日やることや考えていることを書きながら業務スタートします。こうしてどんどんメモを増やしていきます。ファイルの行数が多くなったり、プロジェクトの区切りが来た場合には新しいメモファイルを作成していますが、こだわりが無ければそのままでも大丈夫でしょう。
だいたい一つのプロジェクトで2〜3千行くらいになります。
TODO欄には「思いついたけどすぐやるわけではないもの」を書いています。
TODOは終わった順から削除して、なるべく項目数を少なく保つようにしています。ちょっとしたことでも、忘れる前に書いておきます。
3で書いた日付メモでのTODOとの違いとしては、日付メモのほうはその日の内にやるものを書く。日を跨いで行うものは4のTODO欄に書く、という風に分けています。4のTODO欄から3のTODOへタスクを移動することも、また逆も頻繁にあります。このようにして自由に運用できるのでこのやり方をとっています。
MEMOには頻繁にアクセスする記事のURLや、忘れやすいけれどよく使うコマンドなどを書いています。
毎回ググるのが面倒なので、ここからコピペできるようにしています。私の場合はDockerやgitのコマンドを忘れがちなのでここにメモしてコピペできるようにしてあります。
入社間もない頃は、出退勤時の手順を書いて毎日確認するようにもしていました。
このように、MEMO欄には長期的に保存しておきたい内容を書いておきます。
こんな感じでメモを作っていくことで、自分の作業履歴にもなりますし、「いつあの作業したっけ?」というようなものを探すのが簡単になります。
また、メモが溜まっていくことで日々やったことが蓄積されているな、という感がでてモチベが上がります(個人差があります)
TODO管理で困っている方や記録を残す癖をつけたい方、ぜひお試しください!
]]>
名は体を表すとおり、居場所がわかる、ツールです。
もう少し詳しく説明すると、会社の Wi-Fi に接続した端末を測位して、その端末を所持している人と紐付け、オフィスの画像の上にマッピングして表示する、ツールです。
#「居場所わかるくん」は、Beacon 機器にも対応していますが、本稿では割愛します。
私も入社するまで知らなかったのですが、無線 LAN 機器の中には、電波強度や到達時間やらをプンニャカして測位できるものがあったりします。
1, 2メートル程度の誤差はあるので、精度的にはそれなりーな感じですが、それでも接続するだけでクライアントの場所がある程度わかるのってすごいですよね。
もしお店の無料 Wi-Fi にこの機能があったら、あの席の人こんなページ見てる、まで収集できそうですね、こわいですね、考えないようにしておきます。
と、まあそんな感じの技術を利用して、「居場所わかるくん」は今日も元気に稼働しています。
大きく二つの処理を行っています。
一つ目の処理は、位置情報を収集し、加工して、データベースに保存する処理です。
「居場所わかるくん」は数種類のメーカ・機器に対応していますが、全ての機器で同じパラメータ・キーのデータが取得できるわけではありません。
パラメータやキーだけであれば、まだいいんですが、
・距離の単位がフィートだったりメートルだったり
・取得できる位置がアクセスポイントからの相対値だったり地図上の絶対値だったり
・データの形式が XML だったり JSON だったり
・・・
結構暗黒なことになっています。
そんないかついデータたちを、やさしいデータにノーマライズし、保存しています。
二つ目は、位置を表示するために必要なもろもろの情報の取得要求に対する返却、すなわち API の提供です。
基本的には、来たリクエストに対して、 DB を参照し、結果を返却するだけなのですが、同座標の場合にばらけさせたりなど、細かい調整をすることもあります。
位置情報以外にも、「居場所わかるくん」に登録のある、オフィスのフロア名や画像を提供する API も存在します。
ちなみに、「居場所わかるくん」から提供される位置情報データは、全て端末(PCやスマホ)の位置情報データです。
これは、社員の誰がどのPC・スマホを持っているのか、は、「居場所わかるくん」ではわからないから、なのですが、じゃあどうやって社員と紐づけているのかというと、「連絡とれるくん」の情報を使っています。
「居場所わかるくん」が「連絡とれるくん」のオプションサービスであることにはこんな理由があったんですね〜。
#こちらは、全て internal 用の API なので、現時点でユーザ提供はしていません。
位置情報取得のノウハウを利用して、社員がよく利用している・全く利用していない場所を割り出し、オフィス改修の提案?のようなことや、「居場所わかるくん」の位置情報データを蓄積し、動線追跡(このご時世だと、コロナ罹患者の追跡)のようなことができるのでは〜などなど、活用方法はいろいろありそうだな〜と考えています。
#DOMO(BI ツール) と、位置情報データで可視化してみた〜な記事を note に書いているので、もし良ければご覧ください。
現時点で居場所データの蓄積は行っていないので、やるならそれなりの改修が必要になりそうですが・・・
夢が広がりそうですね!
以上、「居場所わかるくん」の紹介でした。
私が入社して初めて携わったプロジェクトが「居場所わかるくん」関係だったので、それなりに思い入れがあり、今回の寄稿に至りました。
普段は note に投稿したりしているのですが、そこでは書けないような記事が書けて面白かったです。
また機会があったら、別プロジェクトの話を書いたり書かなかったりしたいです。
おしまい
]]>
【目次】
1. このブログを書こうと思ったきっかけと目的
2. DailyShare
3. ProjectSync
4. Welcome Meeting
5. Retrospective
6. まとめ
7. 最後に一言
実は、初回から書くネタに困っておりました(笑)ただ、せっかくチームリーダの役割としてチーム活動のカイゼンを日々考えながら取り組んでいるので、チームで行っていることについて紹介できたらいいのかなーと思い、ミーティング(以下MTG)の紹介をしてみようと決めました。
このブログを読んでいただいた方から
「へぇー、こんなことやってる(やってた)んだ、面白そう!」
「自分のチームでもやってみようかなー」
「スマホチーム楽しそうだなー」
のような感想・感情が生まれることが理想の形となります。
前置き長くなってしまいましたね、そろそろ内容に入りましょう。
※尚、今回紹介するMTGは現在全てオンラインで開催している内容となります。
気取った名前を付けていますが、要するに朝会です(笑)チームで毎日決まった時間に15 〜 30分のMTGを行っています。
【アジェンダ】
・やったこと(Did) / やること(Will do) / 共有したいこと / 気になっていることをチーム全員で共有 -> 15分
・プロジェクトやチーム活動で特別な報告 / 相談事項があれば適宜共有(なければ解散) -> 15分
【なぜやるのか】
・毎日全員で集まることで(タスクの進捗や体調 / メンタル面も含めて)お互いの状態を確認するため
【工夫している点】
やったこと(Did) / やること(Will do) / 共有したいこと / 気になっていることを毎朝「勤務開始直後」にチャットで投稿する形にしています。勤務開始直後に行うことで、まだ頭も体も疲れていない状態で前回の勤務の振り返りや当日やることの整理をすることができます。また、直感的なわかりやすさを求めてMuralという付箋ツールを利用してDailyShareの投稿を行っています(もちろんテキストでの投稿もOKです)
運用イメージは以下です
・毎日定刻にBotからDailyShare用のチャットルームに定型メッセージが投稿される
・定型メッセージにスレッドで返信する形で各自のDailyShareを投稿する
・DailyShare MTGで投稿した内容について全員で共有を行う(あれば書き忘れたことの補足も行ってOK)
週1回1時間、進行しているプロジェクトについてチーム内で進捗や仕様について同期するMTGを行っています。
【アジェンダ】
・(主に)PJの仕様や実装内容について、プロジェクト担当者から説明(共有) / 相談
・動作確認できる成果物があれば実際に動作を全員で確認
・ (あれば)チーム活動について共有 / 相談
【なぜやるのか】
・「プロジェクト担当者しか仕様や動作わかりません」という状態を避けるため
・定期的に開催することにより、プロジェクトで起こっていそうな課題(実装方法 / 仕様の漏れなど)に気付く機会が増え、課題の早期発見 -> 解決をできる可能性を高めるため
スマホチームへのjoinがある度に開催されるイベントです。簡単に言えば自己紹介する会です。2020年7月末までに9回ほど開催されました。(ちなみに初回はスマホチームというチームはなく、スマホ開発に関わるメンバが集まって話すという形で2019年10月に開催されました)。
【アジェンダ】
・各自スライドを用いて自己紹介(要事前準備) -> 30分
・雑談(主にjoin者から既存メンバへの質問。出なければ既存メンバからjoin者へ質問) -> 30分
【なぜやるのか】
・join者がチームに早く馴染めるように、まずは対話を大事にしたいため
・相互理解の機会を増やす(既存メンバ間でもお互いに知らないことが意外と出てくる)ため
【工夫している点】
マンネリ防止のため、自己紹介する内容は2回に1回くらい変えています。最近ネタ探しが少しずつ大変になってきました。
座談会スライドはこんな感じでテンプレを作成しています
2ヶ月に1回、チーム活動に特化した振り返り会を行っています。方法はKPT法と呼ばれるという振り返りのフレームワークを採用しています。
【アジェンダ】
・Keep(よかったこと・継続すること) -> 10分
・Problem(課題) -> 10分
・Try(Keep・Problemを受けて今後やること) -> 40分
【なぜやるのか】
・メンバ各自が感じているチームにおけるKPTの共有 -> いいことは継続する、カイゼンすべきことは具体的な行動に繋げるため
・チーム力の強化、チーム間での認識合わせのため
【今後の展望】
2ヶ月に1回だと曖昧な記憶の元で振り返りをしている感があったため、1ヶ月に1回に開催サイクルを変更予定。振り返り手法も色々と勉強中なので、新しいことをどんどん取り入れていきたいです(個人的願望)
今回紹介した内容は、特にスクラム開発に関わったことがある方は馴染みやすかったかもしれません。と言うのも、スマホチームで行っているMTGのほとんどはスクラムイベントをチーム向けに転用し、チームの変化や課題に合わせて修正をしていっている形だからです。スマホチームは2020年4月にチームとしての活動を開始した新しいチームです。継続的にカイゼンすることによって、少しずつ強いチームに成長していければいいなと思います。
「スクラムって開発だけの話では?」という疑問を抱く方がいらっしゃるかもしれませんが、スクラムは全職種で適用可能なフレームワークと言われています。
興味がある方はスクラムガイドやアジャイルソフトウェア開発宣言参考にすることによって、チーム活動をカイゼンするヒントが得られる(?)かもしれません。
]]>2.技術的な内容
3.使用してみる!
4.終わりに
MESH と Google Maps の Street View を使って屋内で楽しく運動できるアプリを制作しました。
MESH タグが人の動きを感知して Street View の画面を自動で切り替えていくので、屋内にいても屋外を歩いている気分を味わうことができます。
MESH タグ (ブロック) という小さなセンサーを無線で専用アプリと繋ぐことで、誰でも簡単にデジタルなものづくりを体験することができるツールです。MESH タグはさまざまな種類があり、シンプルにボタンを押すだけのものや人の動きに反応する機能を持つもの、明るさの変化を検知するものまで多種多様です。 (一個5000〜6000円。結構お高い。)
たとえば、動きを検知する MESH タグを家の扉に取り付けることで、「家族が家に帰った時に自動で LINE にメッセージが届く」なんてこともできたりします。 IoT (モノのインターネット) と呼ばれる領域ですね!
今回は、「動きを検知する青いタグ」と「ボタンを押すと反応する緑色のタグ」を使用して開発しました。
青い MESH タグ (動きタグ) を振る -> 画面の Street View が前に進む!
緑の MESH タグ (ボタンタグ) を押す -> 画面の Street View が旋回!
全体像としてはこのようになっています。
MESH が検知した動きをサーバ (Node-RED) に POST し、サーバから WebSocket を使ってクライアント (ブラウザ) と通信します。
次からはサーバ側、クライアント側、 MESH 側に分けて解説していきます。
Node-RED を使って実装しています。
フローは以下のようになっています。
アプリの設定画面から使用するタグを選択することで、 Node-RED にタグ ID とクライアントの sessionID がセットで格納されます。
それ以降、 MESH のタグ ID に紐づけられたクライアントのみと Socket 通信を行います。
今回は Google Maps をアプリに組み込むためにいくつかの API を使用しました。
使用していた API は主に二つです。
Google Maps を JavaScript で操作することができる API。
サーバからの通信を受けて、 Google Maps の座標や向いている方角を動かすために使用。
ある地点から目的地までのルートを描画するために使用。
これらの API はインスタンス化を行うことで使用することが出来ます。
詳しくは公式を参照
Node-RED にデータを POST するために、カスタムタグが必要になります。
MESH SDK から Node-RED に POST するカスタムタグを作成して、動きタグとボタンタグを繋ぎます。
アプリ URL から入って、個人プレイを選択。
最初は MESH タグの設定を行います。
動きタグを振り、ボタンタグを押して Sign in!
デフォルトでは弊社の最寄駅である神谷町に徒歩で向かうコースになっています。
それではいざ、、出社!!
ランニングマシーンがあると最強ですが、家にはないので当然もも上げダッシュ一択です。
僕が入社したタイミングでは、新型コロナウイルスの影響で、全社員テレワークが実地されていました。
それは、もちろん新卒社員も例外ではありませんでした。
入社式、集合研修、 OJT までもがテレワークでの実施・・・
そんな『リモートワークネイティブ』とまで呼ばれた新卒社員ですが、たまにはオフィスが恋しくなる時だってあります。
そんな時、、
僕はこのアプリで出社してから、業務を開始するようにしています!
現在、コースは3種類用意してあります。
・東京神谷町にある CaMP を目指すコース
・山口県萩市にあるオフィスを目指すコース (萩市にある弊社オフィスにも僕と同じ新卒社員がいます!)
・ローマの観光地コロッセオを目指すコース (海外旅行に行きたかったという理由です!)
いずれは社内のメンバーの要望を聞いて、コースを追加していきたいですね!
実際に動いている動画も撮ってみたので是非ご覧ください。
今回のアプリはあくまで配属後の研修課題ではありましたが、課題という重圧よりも作っていて楽しいという感情が強かったかなと思います!
Street View をマウスで動かすことなく自分の体で操作するというのは、これまで経験したことがなかったため、 API の使い方の幅広さに可能性を感じました。
機会があれば、今回のものより現実に近い感覚で使えるアプリを作ってみたいなと思います。
1.大まかな書籍の内容
2.オブジェクト指向UIとタスク指向UI
3.実践ページが豊富
4.GUIの歴史
5.最後に
ざっくりとこんなかんじです。
1.オブジェクト指向UIとはなにか
2.オブジェクト指向UIの設計方法
3.実践
4.GUIの哲学
書籍内では、タイトルにある通り「オブジェクト指向UI」と、対になる「タスク指向UI」というものが出てきます。
オブジェクト指向と聞くとエンジニアの方はプログラミング言語を思い浮かべるかもしれませんが、この書籍内では主にGUIのことを指しています。たとえば「コーヒー」というオブジェクトがあり、それに対してユーザーがお金を出して購入する、というタスクを行います。コーヒーという「オブジェクト」をメインにユーザーの行動を設計するのがオブジェクト指向UIと定義されています。
対してタスク指向UIというのはタスクを主にして設計されているUIのことを指します。たとえばCLI(エンジニアの方がよく使っている、黒い画面に文字だけ出ているアレ)のようなものです。CLIでは最初に「コピーする」というタスクを指定してから対象のファイルを選択して命令を実行します。CLIは単純なタスクを連続して実行するのに向いていますが、複雑なオブジェクトを操作するような処理をするのは難しいです。
著者は、世の中にはGUIであるにも関わらずタスク指向UIで作られているシステムが多いと指摘しています。
この、著者が出会った「タスク指向UIのシステム」の例が面白く、自動販売機から牛丼屋の券売機まで、身近な「ダメUI」の例が挙げられています。さらに、現代のシステム(主に業務用)がいかにタスク指向UIで作られているか、ということも書かれています。なぜ業務系アプリケーションはタスク指向UIになりがちなのか。それは、設計者がまずユーザーが期待するタスクをヒアリングし、それを実現する機能を詰め込むために出来上がるものだそうなのです。
これを読んで、私が以前所属していた会社で受託開発をしていたシステムはタスク指向UIのものが多かったということを思い出しました。当時テスト仕様書を作りながら漠然と思っていた「なんか使いづらい」の原因はこれだったのかと思いました。
前半は「オブジェクト指向UIとはなにか」「どうやって設計すればオブジェクト指向になるのか」などの内容ですが、後半では実際にシンプルなアプリケーションをオブジェクト指向で設計する実践ページがあります。
Webからスマホアプリまで、かなりサンプルが豊富です。シンプルな一覧画面と詳細画面を持つものから、複雑なデータベースを表示する業務用アプリケーションまで様々なサンプルがありますので、設計者はもちろんのこと、Web系スマホ系どちらのエンジニアの方にも参考になると思います。また、エンジニア以外の方でも、普段お使いのアプリケーションがどのような設計思想で作られているのかというのがわかるので読んでみると面白い発見があるかもしれません。
最後の方には、コンピュータが作られGUIというものが誕生してから現代のUIになるまでの歴史が書かれています。
先人たちの創意工夫によって、今のスマートフォンのように使いやすいシステムが作られていることがわかります。
初期のコンピュータはタスク指向でしたが、これは機械というものがそもそもタスクを行うことを目的として作られていたからです。そこからコンピュータが進歩し、グラフィカルなUIが誕生し、オブジェクト指向UIになって我々はよりクリエイティブな活動を行えるようになりました。
この章では私が生まれる前の時代のUIが多く紹介されています。今では考えられないような不便そうなUIですが、当時は革新的だったのでしょう。そういった歴史に思いを馳せつつ、より良いシステムを作るために工夫していきたいなと思いました。
今までたくさんのシステム設計に関わってきた方の中には、自分の中でやり方が確立されているというパターンもあることでしょう。
しかし、新しいやり方を取り入れるのもまた、より良いシステムづくりのために必要であると、この書籍を読んで思いました。
今お使いのシステムが、意図してその設計になっているのか、はたまたユーザーから要求されたタスクをただ並べただけなのか、我々は再考する必要があると思います。
繰り返しになりますが、デザイナーとエンジニアはもちろんのこと、システムの設計に関わりのある全ての方にぜひとも読んでいただきたい内容でしたので、今回こうして感想を記事にさせていただきました。
書籍のURLを貼っておきます。Kindle版もあります。
オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
全ての技術書がそうですが、値段が少々お高めなので「買うほどでもないかな...」と思っているかたは著者のブログでも書籍と同じ内容が書いてありますので、そちらを読んでから購入を検討していただいてもいいかもしれません。下記にブログのリンクを張っておきます。
OOUI - オブジェクトベースのUIモデリング
今回は、先日行われた LINE WORKS Tech Talk で LT 登壇しましたのでそちらの模様をお伝えします。
LWTT は、ビジネスチャットである LINE WORKS の API などを使い、Bot を開発したり、他システムと連携したりすることを楽しむ Developer 向けのコミュニティです。
このコミュニティーは、非営利目的で活動しており、技術者同士の情報交換や交流をしたり、LINE WORKS の API やチャットボットなどへの理解を深め合う勉強会を開催します。(後述のコミュニティページからの引用)
イベント名 : LINE WORKS Tech Talk オンライン LT 大会!
日時 : 2020年6月30日(火) 19:00~21:00
コミュニティページ : https://lwugdev.connpass.com/event/
(参加者の方のお顔が写ってしまっている部分はマスクさせていただきました。)
今回のイベントは Zoom 開催でした。
セミナー型でなく、ビデオ会議形式でのイベント開催でしたので、
参加者の方もマイクを ON にしてすぐ発言できるようなフランクなイベントでした。
私は、LINE WORKS のトーク履歴を Salesforce で管理する仕組みについてお話しさせていただきました。
内容としては、Salesforce の取引先責任者に紐づく活動履歴に LINE WORKS のトーク情報を保存する方法です。
5分間の LT でしたので、細かい説明と言うよりは概要の説明のような感じになりました。
また、 LT 中は Zoom のチャットで質問などがきていたのですが、当然拾う余裕はありませんでした!
最後までお付き合いいただきありがとうございます!
まず、初めてのコミュニティでの登壇を無事?に終わらせる事ができ良かったです。
自身が発表する事により改めて自身の知識が整理される事を実感できました。
以前は、社外で登壇する事はとてもハードルが高いと思っていましたが、
2020年6月20日(土) 日本のテスト業界最大級のイベントである JaSST (じゃすと)、その初のオンライン版 JaSST Online Anemone へ参加してきました。
公式サイト:http://jasst.jp/symposium/jasstonlineanemone.html
「そもそも JaSST ってなんだ?」という方も少なくないかもしれませんが、ソフトウェアのテストという実は非常に奥深い技術領域に関わるエンジニアの祭典です。(ちょっと簡単に言い過ぎかもしれませんが)
今回は試験的な開催という事で限定人数(30 名)での開催、しかも参加費も破格の 500 円でした。
ちなみにイベント名の「Anemone」については公式サイトに下記のように書いてあります。
》 『アネモネの花言葉は「期待」「希望」です。ソフトウェアテストをはじめ品質技術の発展に「期待」を込めて、また、この社会的に不安の多い今だからこそ「希望」になれるような場を創っていきたいと思います。』
イベントのテーマとしては「暗黙知」という事で、前半は言語化、形式化の難しいテスト分析の思考プロセスを生ライブで実演、後半は Open Space Technology (以下 OST) というスタイルで、参加者が主体となり自由にトピックを提案し議論をするという二部構成でした。
まずはテスト設計における、テスト分析をマインドマップを使用して考えていくのをライブ鑑賞(観劇?)です。
テスト設計という言葉が聞きなれないという方もいるかもしれませんが、これもまた非常に奥が深く、テスト設計の技術力を競うコンテストがあるほどです。
テスト分析を二人のエンジニアがディスカッションをしながら進めていくというのが、またちょっと斬新でした。
・にしさん(上司):時には厳しく、時には優しく二人のエンジニアを見守っている。
・はるすぷさん(テストエンジニア):テスト分析を主導して進めていく役割。
・ぱいんさん(テストエンジニア):一緒に分析をしつつ、少し外側からの視点で進行を促している役割。
・「かんばんりすと」という、Web ツールがテスト対象
・単体、結合テストまでは開発側で行っている
・システムテストを QA チームが行う
・テストベースはユーザーガイドのみ
・納期短め
休憩をはさみながら、4 スプリントで分析が進んでいきました。
事前の準備としてテストベースをある程度理解している前提ではありましたが、二人での分析の進め方についてはぶっつけ本番での実施とのこと。
しかし、それを感じさせない非常に息もあっていて素晴らしいコンビネーションで、途中沈黙が続くようなこともあまりなく、一言一言が「なるほどー」と感じさせるディスカッションを見せてくれました。
※ちなみに、はるすぷさんとぱいんさんはリアルでは別に同じ会社の人とかではなく、SNS などでちょっと知り合いという程度だそうです。
最初、マインドマップ上にはテストベースから抜き出した機能一覧的なものが展開され、そこから、観点やテストで必要になりそうな項目などを分析していくという形で、二人のエンジニアの思考や知見の違いによる掛け合いが非常にテンポよく、またカジュアルすぎずかといって硬すぎない意見の出し合いが非常に見ていても気持ちがよく、楽しいライブとなっていました。
また、休憩時や所々で入る、にしさんからの的確なツッコミやフォローが入り、振り返りの要素も兼ねていたように感じます。
そして、わざとなのかわかりませんが、スプリントごとにあまり同じような展開にならないようにファシリテートされていて、毎スプリント違う方向性で非常に飽きない展開で、テスト分析自体も「あるある」と感じさせるものや、「そういう視点もあるのか」「そのタイミングで思いつくの?」など、とても刺激を受ける内容でした。
最終的に、想定していた成果物を作成して完了というところまではいかなかったようですが、なんとなく、最後までの流れまで想像できる締めになっていたと思います。
イベント上の特別なやり方というよりも、全然通常の業務でも、取り入れていけそうな手法としてみることができました。
二人以上で分析することにより、途中で悩んで止まるというのが少なく、すぐに相談できて、お互いの持っている視点の違いでより広く分析が行えることが非常にメリットだと感じました。
もちろん、組む相手との相性などもあるかと思いますが、同じチーム内であればいろいろ組み合わせを変えてやってみるというのもよいのかもしれません。
ちなみに、タイムテーブルでは 15:30 までとなっていましたが、気が付くと 16:30 近くになっていました。
1 セッション 30 分程度で、事前に出し合ったテーマで、気になったものへ参加して自由に意見交換するというのを、全部で 3 セット行いました。
※もともと、15:30 過ぎから、各セッション 30 分で 3 セットの予定でしたが、テスト分析ライブが押したため、各セッション 20 分での実施となりました。
自分が参加したのは下記の 3 セッション。(結構現場の中の話だったりもあるので、詳細なコメントは控えます)
・ドメインの違いなどの差異はありつつも、直面する課題は意外とどこの現場でも似通っていたように感じました。
・教育については多くの方がどうすればよいのか悩んでいるようでした。
・意見として多かったのは最初のきっかけをどうするかであったり、モチベーションを保つためにどうするかという部分だったかと思います。
・QA 的な組織の立ち上げ時の大変さや楽しさであったり、アジャイルやスクラムを取り組んでいくときの QA は難しいというようなことをカジュアルに話すことができました。
土曜日の 13:00 から 18:00 くらいまでの 5 時間でしたが、単純にコンテンツの良さと、また、参加した人一人一人の意識の高さにとても感化され、多くの刺激や知見を得ることのできた 1 日でした。
世の中が大きく変化し、今後もオンラインのイベントが増えていくというのは想像に難くありません。
これまで社外のイベントへ参加となると、業務後の夜であったり、普段行きなれない地域へ足を運ばなければいけなかったりと、そもそもの参加のハードルが高いと感じてしまうこともありました。
しかし、今後は手軽に、そして自宅からでも参加できてしまう、それこそスマホ 1 台あれば参加できてしまうような時代になってきています。
今までちょっと社外のイベントへの参加をためらっていた方は、ぜひ、ネット動画を見るような気軽な気持ちで参加してみてはいかがでしょうか。
最後までお読みいただきありがとうございました。
ネタのなさに困り果てたので、我が家の最終兵器のお話をします。
みなさま、NFC タグをご存知でしょうか?
NFC は Near Field Communication の略で、近距離無線通信の規格の1つです。
なんじゃそれ、な方もいらっしゃると思いますが、Suica などの電子マネーカードなどにも使われているやつ、でなんとなくOK です。
(厳密には Suica は NFC の規格の中の一つである FeliCa で、別技術らしい)
そして NFC タグは、それのタグバージョンです。iOS 13 以降の iPhone7 以降(iPhone6も可ですが一部規格のみ)で読み取れます。
通信範囲は 0〜10cm ほどで、タグに iPhone を近づけることで、情報の読み取りや、設定の変更などができます。
(ちなみに Android はもっと昔から使えます。私が iPhone ユーザなので iPhone の話になりますが、ご容赦を〜)
で、本題なのですが、この NFC タグのシールタイプ(Amazon で購入)が大変便利で我が家に溢れております。
ちょっとご紹介をば。
窓近くの壁にペタリ。これに iPhone をかざすと・・・
現在地の天気予報が開きます!地味にめんどくさい動作こそさくっとやりたいのです。
さらに、冷蔵庫そばには2つ設置しています。
冷蔵庫の中身の確認ができます。出し入れの登録もこちらから。
こちらは買い物リスト用。使い切った時に追加しておけば、お買い物前にいちいち冷蔵庫をチェックする必要がありません。
あとは化粧品の底にそっと忍ばせたこちらを読み取ると、
お気に入りの小顔マッサージの動画が開きます。毎度開くのなかなかに手間だったのでこれは良いです。
あとはいろんな消耗品の近くに貼って、読むと Amazon の商品ページが開いたりと、やりたい放題しています。楽しい〜〜〜
iOS13.1 からオートメーションという機能が使えるようになりました。
このおかげで、 NFC タグの読み込みをトリガーに、ショートカットを起動できるようになり、結果、我が家が NFC タグだらけになりました。
設定方法は、ショートカットアプリを開いて、
タグをスキャンして、
やりたいことを選択する。それだけです!
オートメーションのいいところは、アプリを開くことや、本体の設定を変更することが簡単な点、設定すればユーザの承認なしに設定した内容の実行ができることです。
たとえば、QR コードであればアプリの立ち上げにはスキームが必要ですし、本体の設定ですと途中の画面までしか遷移できなかったりします。
(オートメーション使わずに情報を書き込んだ NFC タグを読み取る場合、QR コードと似た状況になります。オートメーションと組み合わせると真価を発揮する感じです)
NFC タグを選択するにあたり、比較対象として QR コードが挙がりやすいかと思います。
なので、両方のメリット、デメリットを考えてみました。
・対応できるデバイスが多い
・マーカーとしてわかりやすい(読めば何かが起こると期待させる)
・コード以外の情報を表示できる(アイコン、文字など)
・作成が容易で設置コストも低い
・カメラを立ち上げる動作が必要
・見た目の主張が強いので空間に馴染みづらい
・書き換えができない
・かざすだけで読み取れる
・書き換えができる(情報が変わっても張り替える必要がない)
・シールタイプはシンプルなデザインが多く、空間になじみやすい
・QR コードの印刷と比べるとコスト高
・対応できるデバイスが限られる
・認知率が低く、わかる人しか使わない
・かざしてみないとなんの情報なのかが分からない
・意外と貼れる場所が限られる(金属面がだめ。ただし対応法はあり)
NFC タグのデメリットが多いのは、実際に使うことが多く気付く機会も多かったからですね。
不特定多数の利用が見込まれるシーンでは QR コードが圧倒的に良いかと思います。
一方、私のケースのように、限られた人の利用、書き換えが発生し得るなどといったシーンだと、NFC タグが活きるのではないでしょうか。
もっと流行って欲しいこの組み合わせ。本当〜〜〜に便利なんです。
今回ご紹介したものはアプリ開いたりブラウザ開いたりと簡単なものでしたが、オートメーション自体は条件によって動作を切り替えたりとより複雑なこともできます。
とはいえ、お家や身の回りのちょっとしたこと、毎日やる動作を簡単に、の切り口で使うと幸せになれます。
iOS ユーザはもうぜひ騙されたと思って一度使って頂きたいです。
NFC タグシール買うのはなぁという方は、オートメーションだけでも良いので、ぜひに。使っていない純正アプリの中にきっと「ショートカット」ってアプリがあります。
オートメーションではNFC タグ以外にも、時間や居場所、動作をトリガーにあれこれできて、これまたやりたい放題です。楽しいです。
あれ、NFC タグの話だった気がする・・・サムネイルもオートメーションですし・・・まぁいいか。
]]>コーディングスタイルとはコードを実装する上でプログラム上エラーにはならないが、コードの可読性を上げ保守し易くするために定められたルールのようなものと捉えて頂ければ良いと思います。文章だと分かりづらいと思いますので、以下に例を記載致します。
かなり極端な例を紹介しましたが、処理毎のブロックが分かりづらく処理を追いづらいですよね。そこで以下のように修正しました。
処理の終わりや変数への代入等がだいぶ見易くなったと思います。今回は簡単な例で5行程度のコードでしたが、ここからメソッドやfor文、callback等が追加された場合にコーディングスタイルが統一されていないと、保守性や可読性が著しく低下するのは容易に想像出来ると思います。
コーディングスタイルについてざっくり説明しましたが、コーディングスタイルを定義したとしてもそれを常に意識しながらコーディング作業をすることはとても大変だと思います。そこで、実装作業後にAndroid Studioの標準機能であるCode Styleの自動整形を使用することで、定義したコーディングスタイルを一発で適用する方法を次章から紹介したいと思います。
まずは、コーディングスタイルを自動適用するために、Android StudioのCode Styleを定義することから始めてみましょう!
Android Studioを立ち上げ、メニューバーの [Android Studio] -> [Preferences] -> [Editor] -> [Code Style] -> [それぞれCode Styleを設定したい言語] から定義を設定できます。全ての設定を紹介することは出来ないので、今回は弊社でAndroidアプリ開発において使用されている言語のJava, XMLのそれぞれのタブ項目で、どのようなCode Styleを主に設定することができるのかを説明致します。
・Java
・Tabs and Indents
タブのスペースサイズや改行時のインデント(字下げ)のスペース数
・Spaces
if文や関数の引数, ()の前後等にスペースを挿入するか否か
・Wrapping and Braces
一行に対する最大文字数の設定や最大文字数を超えた場合に、どのようなルール・区切りで折り返すか
・Blank Lines
メソッドやパッケージ,クラス前後等の空白行数
・JavaDoc
パラメータ説明の位置合わせや折り返し等、JavaDocのスタイル
・Imports
ワイルドカードインポートの制御やインポート文同士の空行等、インポートについて
・Arrangement
メンバ変数やメソッド等の配置順序
・Code Generation
Android StudioのGenerate機能を使用した際に生成されるコードのスタイル
・XML
・Tabs and Indents
タブのスペースサイズや改行時のインデント(字下げ)のスペース数
・Other
一行のおいての最大文字数や改行時のインデント、属性と=間のスペース有無等
・Arrangement
属性の配置順序及びフォーマット時の強制再配置の有無
・Code Generation
コード自動生成時のコメントについて
・Android
Android特有のAndroidManifestやLayoutファイルの折り返しや空白行の挿入等
今回はAndroidアプリ開発において、特に使用頻度の高いJava及びXMLファイルのCode Style定義について記載致しましたが、他にもKotlinやC++等様々な言語フォーマットに対する定義が出来ます。定義まで出来たら後はコードファイルに適用するだけです!実際に定義したCode Styleを適用してみましょう。
メニューバーから [Code] -> [Refomat Code]から現在開いているファイルに定義したCode Styleを適用することができます。この適用方法の他に [Code] -> [Show Reformat File Dialog] から適用項目を決定することも可能です。
・Scope
指定された部分にCode Styleを適用する
・Only VCS changed text
Git等のバージョン管理システムが導入されている場合のみ選択可能になり、差分があるコード部分にのみ
・Selected text
選択範囲のみ
・Whole file
現在開いているファイル全体
・Optional
適用するCode Styleのオプション項目。オプション項目なのでインデントやスペース数等のCode Styleは項目のチェック関係なく反映される
・Optimize imports
使用されていないインポートの削除や順序の並び替え等インポートに関する部分
・Rearrange code
変数やメソッドの順序等の配置修正について
・Code cleanup
コード上に潜在的問題がある部分に関して修正を加える(Code Styleの設定とは少し異なる)
補足としてPackageフォルダ配下等の、複数のファイルにCode Styleを適用させたい時は、以下の画像ように対象フォルダメニューから、該当する複数のファイルに対してCode Styleを適用させることが出来ます。
ここまででAndroid StudioにCode Styleを設定し、コードファイルへの適用まで行いました。これで新しくファイルを作成する時や既存のコードに修正を加えた時等に、コードのフォーマットを行うことで常にコーディングスタイルが統一された実装を行うことが出来るようになりました!ただ、これだけではチーム開発を行う際に共有を行っていないので、最終的に実装者によっては統一性のないコーディングスタイルになってしまいます。Code Styleを変更した項目を共有するのでは、各々の手間がかかりすぎスマートではありません。そこで、あるファイルを共有し設定することで簡単に設定したCode Styleをチーム及びプロジェクト間で共有出来るので、その方法を紹介して終わりにしたいと思います。
設定したCode Styleの共有ですが、ここまで設定を終わらせた皆さんなら、とても簡単に設定を行えると思います。Code Styleを設定したプロジェクトルート配下に存在する「.idea/codeStyles」を共有するだけです。.ideaフォルダとは、Android Studio等のIDEで使用されるプロジェクトの設定が格納されているものと認識頂ければ大丈夫です。.ideaフォルダ配下に格納されているものは、個人の設定がほとんどなのでGit等のバージョン管理ツールで共有する場合は「.idea/codeStyles」フォルダのみを共有する設定にする必要があります。
設定ファイルの共有後は以下の画像のように[Code Style] -> [Scheme]メニューが[Project]になっていることを確認する(なっていなければProjectにする)ことで設定ファイルをプロジェクトに適用します。
ここまででAndroid StudioのCode Styleの設定・適用からチーム間の共有まで行えるようになりました!
コーディングスタイルは、実装を進める上で最初の段階で定義しておくと、開発者それぞれの表記揺れが減り、可読性の高いコードになるのと同時に、コーディングスタイルを開発者側が常に意識する部分が減り、他のことにリソースを割くことが出来ます。また、ファイル数の少ない早い段階で定義しておくと、ファイルの変更が少ないので差分が出過ぎて死にそうになるみたいなこともないので、適用するならなるべく早い方がよいでしょう。今回は、より詳しい設定の説明は省いてしまったのですが、それぞれのプロジェクト毎に違う部分もあるので、使用する際は公式のスタイルルールに則りつつ、自らが見易くなるように精査しながら定義を設定することが必要です。
今後も開発者が考える必要がない領域を増やし、真に考えなくてはいけない領域にリソースを割けるような開発体制にしていけたら良いのではと思っています。今回は設定寄りの記事を執筆したので、次回はもう少し技術的な記事が書ければと思います。
以上、お読み頂きありがとうございました。