droidkaigi2018 レポート 1日目
３年ぶりのdroidkaigi 2018
僕が参加したのは、2015年の初めて開催されたdroidkaigiでした。
当時は、渋谷のマークシティのビルで、2部屋ぐらいの規模で開催されていたのを今でも覚えていますね。
今日のオープニングトークでも話していたけど、400人ぐらいの規模が、気づけば1000人オーバーって規模。
すごく大きくなったなぁってびっくりしました。
今ではdroidkaigiに参加すること自体が日本のAndroidエンジニアのステータス、みたいになってて面白いなぁとw
1日目レポート
さて、1日目のレポートに入ります。 全部見たことを本当は書きたくて仕方ないんですが、如何せん量が多くて、2日目もあって寝れなくなってしまうので、 これは・・・！と特に気になったものをピックアップして備忘します。
時間と気力が降って湧いたら更新します。
基調講演
最初のセッションは、全員参加で見る基調講演でした。
kotlinのアンチパターンを紹介するプレゼンでしたが、kotlinを事前に手をつけていた身としては、
あーそう書くそう書くww みたいのがあってとても良かったですね。
僕の中で印象深かったのは、拡張関数の乱発についてでした。
拡張関数はどこにでも生やせるので、副作用を生みやすいっていうのは肌感で感じてました。
個人的には、ビジネスロジック層で横断的に利用したい関数が出て来たら、 初めて生やす、ぐらい特別視していいんじゃないかと思ってます。
例えば、UserがLoginしているのかどうか確認したいけど、いちいちレイヤ挟んで確認するのが面倒な時とか。
fun User.isAlive(element: ConfirmElement) {
element.confirm()
}
ユーザーインタフェース層で拡張関数を作るのは、
副作用を許容できないことが多いと思うので、僕なら面倒な方法をとるかなぁ。
と、拡張プロパティを利用する際は、特別視しつつも、副作用が出やすいという特徴を利用・許容する感じでいいと思います。
ただし、こちらもビジネスロジック層で利用することが前提です。
data class User(val sex: String, val name: String) // -------- 以下をどこか別のクラスで利用する Translateあたりとか？ ------- // val User.formatName: String get() = if (this.sex == "men") this.name + "君" else this.name + "さん"
この程度であれば、副作用といっても却って特別視されて、分かりやすく明示化されるので、良いんじゃないかなぁと。
意外とまだ、僕が思っていたよりkotlinで開発するエンジニア少なかったので、 希少価値をつけていこうと思った次第でした笑
Model-View-Intent アーキテクチャ
最近はMVPとかより、Unidirectioanl Data Flow という考え方が良いとされてますよね。
その実現方法の一つとしての提案として MVIアーキテクチャという考え方を教わりました。
Rxをふんだんに有効活用してる感がすごかった。
ユーザーインタフェース層は、
- あくまで、Stateに応じたデータを表示する
- ユーザーからのインプットを
Intentsとして表現する
という考え方で、IntentsをActionに変換、Actionでロジックを集約してRxにぶん投げるって感じがすごく刺激的でした。
眠いので続きは３連休に書きます！！！
ゼロベースからアプリを、お仕事で作ったった！
このアプリをお仕事で作りました〜〜！ ITイベントの情報を複数サービスを使って検索できるアプリです。
これからグロースする予定もあるので、がんばります！┗(｀・ω・´)┛
技術的に取り入れたこと
Android Data Binding
MVVMを実現するためには必要な仕組み。
Viewの状態をObserverクラスとBindingクラスに任せることで、Model（ロジック）内で管理することをなくせる。
findViewByIdの束縛からも解き放たれて幸せになれる。
今度ハマったところをQiitaにあげるかも
RxAndroid
リアクティブプログラミングをAndroidのシステムフレームワークに合わせたライブラリ。
関数型プログラミングの考え方も踏襲されていて、データをごにょごにょする時には今後のスタンダードになりそう。
JSR310 に準拠した Date and Time APIのAndroidライブラリ
スレッドセーフでない現行のDate/Calendarクラスからの脱却を目指したかった。
あと、インスタンスを作らなくてもstaticメソッドが豊富に用意されているので、Date/Calendarより作りやすい。
Jake Wharton 神信者です
苦労したこと
Activityに配置したEditTextの文章（状態）を、FragmentViewPagerで管理しているFragmentに伝える方法。
これは苦い思いで作った。
結局コールバック作ることにしたけど、願わくば直接値を引っ張りたかった。
Bindingを渡すわけにもいかないし、考える時間も惜しかったので、今後リファクタリングすることを前提になるべく綺麗につくったった
と、こんな感じでシンプルなアプリですけど、昨今のモダンな技術も少し取り入れてみたりしてますw
もう少し実装事情について、今後かきまーす
あと次のお仕事は kotlin を使ってゴリゴリっと実装するやつなので楽しみでーす
Goのバイナリを更新してみた
前提
- 64bit debian 7 jessie
バイナリ落とす
windowsやmac向けにもあるので、サクッと勉強するのであれば
ローカル環境に簡単に構築できるはず。
今回は64bitのlinux向けのバイナリ落とした。
go1.8.3.linux-amd64.tar.gz <- この名前のファイル
インストール済みのgoをアンインストール
goはバイナリ単体で動くスタンドアロンなので、ディレクトリ消すだけ。
今回は以下のディレクトリを削除する
rm -rf /usr/local/go
落としたバイナリを解凍・展開する
tar コマンド使ってgoが標準で定めているディレクトリに解凍・展開する
定めていない人は、$GOROOTで定めているディレクトリへどうぞ
tar -xvzf go1.8.3.linux-amd64.tar.gz mv go /usr/local/
動作確認
しましょ
go version
動けば 1.8.3 のバージョン情報が表示されるはず！
おわり
【月１ぐらいは頑張る】更新していなかったので。【割と決意表明】
あれから半年以上が経った。
たしか2016年が始まったころにこの記事を書き始めた気がする。 自分の勉強のため、アウトプットのために始めたんだけど、大して更新できなかった！！！ｗ
記事かくって結構エビデンス作ったり、それなりに気を使ったりして大変なのね。
気を遣うっていうのは、正しいことをしっかり書くってことなんだけど。
間違ったことを書かないように、本当に今書こうとしていることは事実なのかどうかを確認する作業を挟むから、
普通に書いて１時間ぐらいのものが、２、３時間ぐらいになったりする。
まぁその分勉強になるからいいんだけど、ちょっと効率は悪いなって思う。
なんかそれだと自分が楽しめてなくて続かなかったので、
もう少し雑に生きてみようと思う。
月１の更新
これから目指す。できれば週１とか、毎日とか。
気になるテクノロジーニュースとかの感想ぐらいなら毎日書けそうかな。
さいごに
また適当に、雑にやっていくので、細かいところはこれからあまり気にしないで書くかもしれません。 なので細かいところが気になるようなことがあれば、他を当たってみてください。
細かいところにまで手が届くような記事かけるようになるのを意識してがんばるぞい
Ubuntuでショートカット（デスクトップエントリ）を作る
概要
忘れないように書いておきます。今日はもう寝よう。。
タイトルの通りです！
基本的にはパッケージマネージャからインストールすることが多いですが、
ネットから落としてきたバイナリアプリケーションをそのまま使うこともあると思います。
そんな時に、「ショートカット」がないと使い勝手悪いですよね。
Windowsでいえば、ショートカットもないしexeファイルみたいにダブルクリックでも開かないし、みたいな。
自分でターミナルから直接バイナリ実行しなきゃいけない。。
そういう時は
デスクトップエントリーファイル
というのを作ります。
こいつは、アイコンや実行ファイル先、アイコンや説明などを一つにまとめたファイルで、これ一つで実行ファイルへのリンクやアイコンの設定まで全部できてしまいます。
高性能ショートカット。
ということで作ってみまーす
環境
流れ
- アプリの実行ファイルと場所をあらかじめ決めて調べておく
- エントリーファイルを作る
- エントリーファイルへ、ユーザーに対する実行権限を与える
- Dash検索からエントリーファイルで定義した名前でアプリケーションを探してみる
例：Firefoxの場合
ダウンロード
まずは公式からダウンロードしてきます
Firefox をダウンロード — 自由なウェブブラウザー — Mozilla
tar.bz2形式なので任意のディレクトリに解凍します。
アーカイブツール使ってもいいし、コマンド使ってもいいです
~/software $ tar xjf firefox-*.tar.bz2
デスクトップエントリーファイルを作る
解凍ができたら、デスクトップエントリーファイルを作ります。
今回は ~/software/firefox に解凍していると仮定します。
まずは、
$ cd ~/.local/share/applications
に移動します
ls -aを叩くといくつか .desktop という拡張子のついたファイルがあるはず。
今回はその.desktopファイルを作っていきまーす
vim firefox.desktop としてファイルを作っていきましょう（ファイル名は何でもいいです。）
vimの使い方はこのサイトを見ればわかるかも
firefox.desktop
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Firefox
Commend=Firefox for ubuntu 16.04 #ここは好きなコメントでいいと思う
Exec=/home/{user}/software/firefox/firefox
Icon=/home/{user}/software/firefox/firefox.png # Firefox自体にアイコンは無いので、フリーのアイコンを落としましょう
最低限これだけ書いていればOKです。
他にもバージョンを指定できたり、オプションはいくつかあるので詳しくはぐぐってみてくださいｗ
アイコンは落としてきましょう！
実行権限を与える
実行権限を与えてデスクトップに移動させます
$ chmod 773 firefox.desktop $ cp firefox.desktop ~/デスクトップ/
最近のUbuntuはマルチバイトに対応してるんだよねぇ…
ちょっと慣れてくると日本語に直すの面倒で正直英語のままであってほしいｗ
と、desktopに何も置きたくない場合は、 cp コマンド叩かなくてもいいです。
実行権限だけ与えて、 .local/share/applications に移動すればアイコン化されたファイルが存在すると思います。
ランチャーに登録
デスクトップ画面に戻ったら、すでにアイコンが設定されたショートカットみたいなのが出来てると思います。
良ければD&Dでランチャーに登録してみてください！
それでは、良きUbuntuライフを！
端っこエンジニア＠VPSにLaravelをインストールする VPS導入編
概要
いつもはスマホアプリ作ってて、簡単な機能作って遊んだりしてます。
で、少しずつお仕事頂いてるうちに、自分でサーバ立ててAPI作って、もっとアプリらしいことしたいなぁって思って、
Laravelを入れてみようかなぁって思いました。
VPSを直で借りたので、Homesteadとか使わないで、自力で導入して少しでもスキルアップもできたらなぁって。
正直シェルの機能とかコマンドとか、Web鯖の仕組みとかバックエンドもろもろ知らないので、
少しずつ勉強して活かしていきたいと思って書きます。
無宗教なので、興味持ったことだけやっていこうかなぁと。
あと、マサカリに弱すぎて死ぬことがあるので、何か思うところがある方、優しく手解きしてくれると嬉しいです！
VPSを借りる
お金ないので、ServersMan借りました。
ちょっと勉強するぐらいなので、月500円のやつをばｗ
ゲームの課金より安い（でもIT業界もとい僕の懐が暖かくなるなら今やってるゲームの課金も厭わないぞぉ
ちなみにServersManはここです
借り方はまぁ、よしなに、流れに沿って。クレカあると便利です。
あと、土日で契約しても平日に処理されるので、金土日で契約するのはおススメしませんｗ（僕は３日ぐらい待ちました
サーバにログインする
全世界待望の、サーバに潜る時がやってきました！
でもサーバへのアクセスってどうやるんだろ。。
そこからつまづく端っこ族なう。
windowsだと、Teratermとかがクライアントとして有名ですかね。
でもあれか、windows10なら Bash on Ubuntu on Windowsがあるのでそれでもいいかも。
とにかく、僕はbash環境でやるべく、Ubuntu16.04導入済みの遊びノートからアクセスするようにしました。せっかくだしｗ
で、こうやります。
ssh root@xxx.xxx.xxx.xxx -p xxxx
root@の後には、契約時に指定されたIPアドレス、-pオプションの後に指定されたポート番号を入力します。
すると、パスワード求められるので、これも契約に書かれているパスワードを入力します。
まずはパスワード変える
ログイン出来たらまず、作業しやすいように＋最低限のセキュリティ対策のためにログインのパスワード変えました。
まぁrootでログインできないようにするんでしょうけど、遊ぶぐらいなので後でやります
passwd root
パスワードは最低限、 文字・記号・数字 は必ず１つ以上入れて、かつ 10字以上 にしました。
ランダムに織り交ぜるのがいいと思うんですけどね。
とりあえず以上の条件にしておけば、総当たりでチェックされても10字以上なら多分かなり時間かかるし、一旦は大丈夫かなぁと。
辞書類推とかあった気がするので、キャラの名前使うときは要注意で。
あと、大文字・小文字を１字以上入れると尚よさそう。
ここら辺は全然専門じゃないので、ｋｗｓｋって人は調べてみると面白いかも。僕も調べます。
この記事書きつつ、気になって調べてたら最低10桁以上っていうのがあった
セキュリティ回りもしっかり勉強していきたいなー。
Web業界はhttps必須みたいな流れになってるし、iOSなんかhttpsにしろーってお達し出してるし
まとめ
VPSの導入でやったこと
次回予告！
せっかくサーバ入れたんだし、ブラウザで自分のページが見たいじゃない！
でもなんか仕事してると nginx っていうWebサーバをよく耳にする。
処理が早いとか、大量リクエスト来てもapacheより安心とか、何それ美味しそう・・・
次回！nginx + php7をdebian 7に導入！
WebAPI トレーニング 05 -エンドポイント設計編-
エンドポイントとホスト名の設計
よくある例
http://api.fugahoge.com/v1
http://api-public.ikatako.com/v2
ホスト名にプラス、v1やv2といった数値が入っていることが結構ある。
これは API自体のバージョンを表す もの。
あとは api という単語をホスト名に入れておくことで、DNSレベルで分けられて
自サーバ側で管理しやすいというのもあるっぽい。
api-public のように、オープン／パブリックなAPIであることを明示しておいて、
BtoCとBtoBで、エンドポイントを変えて可視性の段階を設けるのもありっぽい。
こっちはBtoC（第三者利用可能）用、あっちはBtoB（提携企業向け）用、って分けると分かり易いかも。
何がいいかは、その都度の状況と背景を考慮して最適化するのがよろしそう。
REST LEVEL3 APIとHATEOASの概念
HATEOASとは、を、結論から簡単に言えば、こんな感じなのかな。
最初に叩いたAPIから、次に起こせる行動のためのURIをリンクとして含める ようなAPIって感じかな。
最初にAPIを叩いたら、数珠式に叩くであろうAPIのURIをあらかじめ仕込んでおくことで、API利用者側は具体的なURIや必要なパラメータを意識することなく、APIを簡単に利用することができる。
それがHATEOASという考え方であり、設計レベルでいえば０〜３まであるうちの、 最高の３らしい。
ちなみにLevel0から3までの区分はこんな感じ
| REST LEVEL | 達成基準 |
|---|---|
| 0 | HTTPを使っている |
| 1 | リソースの概念を導入 |
| 2 | HTTPの動詞（GET, POSTなどのメソッド)を導入 |
| 3 | HATEOASの概念導入 |
で、上記のことを提唱したのが、「Roy Fieldingの論文」らしい。
自分の意識が最高を超えたら読もう。。
HATEOASは、
hypermedia as the engine of application state
の略。
アプリケーションが持つ状態のエンジンとしてのハイパーメディア？？
HATEOASの概念を入れるメリット
- クライアントがURIを知ることが、最初の導線以外知る必要ないので、 URIの変更がしやすくなるのと、 改造しやすい(Hackable) である必要がない
- スマホアプリの開発では、最初の導線のみハードコーディングにすることで、 内部では動的にURIを利用できるから、仕様の変更に強いアプリにすることができる。 （いちいちアップデートする必要がない！！！！）
- URIの間違いに起因するバグを減らせる（動的にURIを利用できるから
たしかに。
まぁただ、その分、サーバ側からJSONとかレスポンス返す時にそういう配慮が必要になってきそうで、ちょっとバックエンド側のコストが高くなりそうやな・・・
次回
-エンドポイント設計編- はこれにて終了！
クライアント側の設計方法を知ったので、今度はサーバ側の設計方法（レスポンスについて）勉強していきまーすっ！！
