読者です 読者をやめる 読者になる 読者になる

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

Pocket APIをJackson経由で扱うために

突然ですが、私はPocketが大好きです。

 

多分Twitterと同じかそれ以上に使っています。

 

で、AndroidでPocketクライアントを作ろうとした時壁にぶつかりました。

 

JSONJava Obejctとして扱うには事前にClassを定義しておかなければなりません(Jacksonの場合)。

 

いろいろ調べているとクラスを定義をしなくても読み込みが可能な方法がありました。

【Java】JSONの基本とJSONICを使用してJSONの変換をする方法 - TASK NOTES

JSONをmapとして読みこめばとりあえずは読み込み可能でした。 

 

が、クラスを定義した時に受けられるIDEの自動補完ができなくなるため、できればクラス定義はしておきたい。

 

というわけでクラス定義を行おうと思いましたがいくつか問題が発生。

 

 その中でも一番頭が痛かったのがこれ。

 

・ドキュメントに書かれていない値が帰ってくる

 

例えば、公式ドキュメントのretrieveのページを見てみましょう。

getpocket.com

 

Example Responseを見ると、ルートにある値はstatusとlistだけですが、実際にはこれに加え、completeやerror、search_metaやsinceなどの値も帰ってきます。

 

他にも割りとありましたが省略します。

 

ということで、getter/setterすらないキー値を突っ込んだだけのPOJOを公開しました。(大体自分用)

 

github.com

 

MITですのでfork等ご自由にどうぞ。

 

OkHttpとVolley

AndroidでWebAPIにアクセスしようとすると多分ネットワークライブラリを使うことが基本なんだろうと思うが、最初はVolleyを使っていた。

だが、VolleyはGit経由でGoogleからcloneしてくる必要があるため手間が増えることと、git submoduleでcloneしてbuild.gradleに必要事項を記述してもgradleのbuildがコケてしまう現象に遭遇した。

調べてみるとどうやらAndroid Studio2.0からの現象らしく、moduleフォルダに入っているvolleyのbuild.gradleを修正すればbuildは通るらしい。

i53.hatenablog.jp


それか、jCenterにupされているものを使い、compile 'com.android.volley:volley:1.0.+'で済ませるか。
(compile 'com.mcxiaoke.volley:library:1.0.19'ではないのはここはすでにdeprecatedになっているため)

ただ現在トレンドとしてはVolleyよりOkHttpのほうがよく使われているらしい。

なんとなく名前がダサい気がする。

Volleyのコードを書く前にOkHttpに変更したのでサンプルコードしか見てないが、個人的にはOkHttpの書き方のほうがやることがはっきりわかって好みだ。

以前Pythonを使っていた時に使っていたRequestsっぽいって思ったのも要因かもしれない

Raspberry pi ModelB(初代)にRaspbian liteを入れた話

現在自分はRaspberry Pi model B(初代)を2台所有している。

 

以前は1つは家庭内NAS(smb+WebDav)

 

もう一つはSTBとして運用していた。

 

NASの方で使用していたOSはRaspbianだが、元々重かった(教育用として開発されたHWとOSなのでDEやらいろいろデフォで入っている)のに加え、pi2やpi3に合わせて(多分)開発されているうちにますます重くなってきて、いい加減初代では辛くなってきた。

 

極めつけは、REX-WIFIUSB1というWi-Fiストレージよりも転送速度が遅かったということ。

 

流石に無線接続で性能も低いはずのWi-Fiストレージより速度が下はマズイと思いOSを変えることに。

 

AlpineLinuxなども試してみたが、lbu commitしても変更が保存されないなど(多分自分のやり方が悪い)、どうしようか迷っていたら、Raspbian liteなるものがリリースされていることを知った。

 

これはRaspbianからDEやScratchなどのパッケージを削除し、必要最低限だけのパッケージにしたもの。

 

Ubuntuに対するUbuntuServer/Coreみたいなものかな。

 

まあ多分Raspberry pi zero用として公開されてるものだと思う。

 

とりあえずRaspbian liteを入れて必要最小限のパッケージ(samba,Apache2あたり)を入れてNASとして動かしてみた。

 

結果は大成功。以前とは比べ物にならないほど早くなった。

 

少なくともREX-WIFIUSB1よりは早くなった。

 

初代Raspberry piを持て余してる人はOSをRaspbian liteにしてみると復活するかもしれない。

 

pi zeroでOwnCloudを動かしてる動画(しかも割りと実用的な速度で動いてた)があったのでowncloudを入れてみるのもいいかと思う。

 

pi zeroとpi3欲しい。zeroはWI-FIストレージとして使ってpi3はWindows10 iotで遊びたい。

 

WI-Fiストレージとして使うにはC.H.I.P.のほうが良いかもしれないけど。

 

 

Androidを1から学んでみる

タイトルで1からと書いてますけど実際はActivityとかIntentは知ったので1.1から学んでみるが正しいです。

とりあえず何か作らないと覚えないなと思いカウンターアプリを作ってみることに。

シンプルなアプリだからすぐできるし作れるだろうなとタカをくくっていたら意外と覚えることが多かった。

具体的には、

・Fragment

・ActivityからFragmentを呼び出す

・ActivityからFragmentへのデータ受け渡し

・Database(ORマッパー)

・FragmentからActivityへの通知

・Fragmentの交換

・RecyclerView

・ActionbarMenu

等など

ただ、使っている機能はこれでも一部で、よくわからずに使っている機能もある。

具体的にはRecyclerView(ListViewとよく比較されていたがどう使い分けるのか。)

build.gradle(classpathの役割とかbuildtypesとか)

Actionbar Menuの切り替え(現在はmenu.findItem(R.id.xxxx).setVisible()で切り替えているがこれでいいのか)

ライフサイクルを意識する(頭が混乱してきたので今回は考えてない)


後はpackage構成がよくわかってない。

どう分けているかのテンプレートでもあればいいのになと思う。

次はカウンターアプリを一から作りなおして復習とライフサイクルのお勉強をやろう

その次はAPI叩くのとスレッド処理(AsyncTask)の練習でなんかのクライアント作る。

Android Data Bindingを使ってみる

Pythonでバックエンド書いたり、JavaScriptでフロント書いたり、C++アルゴリズム実装したりしてたけど、スマホアプリ書くかーと思ってとりあえずAndroidを触ってみることにした。

 

Androidのシステム考えるとMVCよりMVVMだよなーとか考えつつ、最近出たらしいAndroidのData Bindingを使ってみる。

 

公式のやり方はここに書いてあるが、自分自身Androidについてよくわかってないのか試行錯誤しながら動かしたのでメモ。

 

環境:Android Studio1.5.1

開発環境を以前まとめて入れた時にAndroidStudioも入れていたが、バージョンが1.3.xと古かったのでとりあえずバージョンアップした。

開発環境がが古くとも特にいいことは無いのでバージョンは上げておこう(だだし破壊的変更がある場合は除く)

 

1.build.gradleに追記する

Android Studio1.3.xを使っている人は他にも追記する場所があるみたいだがここは1.5.1前提で話をすすめる。

1.5.1の場合、すでにDataBindingライブラリは入っているので、build.gradleにそれを有効化する記述を追記する。

gist.github.com

 

 2.Viewにバインディングするtext等を指定する。

次はバインディングするテキストなどを指定する。

View(layout)を適当に作ったあと、まずはルートノードとして<layout>タグを追加する。

テンプレートのままだとルートノードは<RelativeLayout>だから、それをくくる形にする。

gist.github.com

そして、<layout>直下に<data>ノードを追加。

このノードにはバインディングするときに使うオブジェクト(下で記述する)と階層を指定するvariableというノードを記述する。

ここでは、公式ガイドと同じくオブジェクトはUserとする。

gist.github.com

nameはこのxml上で使用するオブジェクトへの変数みたいなもの。

typeはオブジェクトまでの階層を記述するのだが、公式ガイドではユーザー名とアプリ名の部分が省略されているので注意すること。

 あとは、データをバインディングさせたい位置に@"{user.hoge}"のような形式で記述する。

具体的な使用例は公式ガイドのWriting your first data binding expressionsセクションの使用例のところを見て欲しい。

 

3.バインディング用のクラスの作成

次は、バインディング用のクラスを作成する。

これはぶっちゃけガイドのData Objectセクションのコードを見てもらったほうが早いと思う。

コード量が少ないのはPOJOのコードだが、メンバ変数が直接触れてしまうので、下のJavaBeans形式のほうがいいと思う。

2のtypeの書き方だとプロジェクト生成直後のMainActivityと同階層にUserクラスを置くことになるので、階層を作っている人は適宜脳内で置き換えて欲しい。

 

4.gradleでプロジェクトをsyncする

これはたぶんガイドには載っていないが、2で追記したdataノードからクラスを生成する必要がある。

生成しないと、実際にバインディングする時バインディング用のクラスが無いと言われ、ビルドに失敗する。

と言ってもやることは簡単で、単にSync Project With Gradle Filesボタンをクリックするだけ。

エラーが吐かれなければ、バインディングに必要なクラスが生成されているはず。

 

5.バインディングしてみる。

これもガイドのBinding Dataセクションのコードを見てもらったほうが早い。

4行目で2で追記したDataノードがあるxmlバインディングできるようにしてbindingに代入する。

MainActivityBindingという型だが、これが4で生成したクラスの正体。

syncしていなかったり、エラーを吐いていたりすると型の解決に失敗する。

この型は上でも書いたとおりgradleによって生成されるが、命名規則がある。

layout名がmain_activityの場合、スネークケースをアッパーキャメルケースに変更(MainActivity)し、後ろにBindingを付ける(MainActivityBinding)。

5行目では、最初にバインディングするテキストをコンストラクタに渡し、Userオブジェクトを生成し、6行目でバインディングを開始している。

 

そもそもがJavaにあまり慣れていない為用語に間違いがあると思うが、なんとなく察して欲しい。

 

GUIアプリケーションでリアルタイム更新をするとき、get系のメソッドをいちいち叩くのは面倒とかいうレベルでは無いので積極的にMVVMを使っていきたい。

 

 

 

文字列を置き換えするページ作った&最近のjsについて感じたこと

スマホを使ってる時、文字列を置き換えたい時が時々あるから書いた。

 

リアルタイムに反映されるからその辺のテキストエディタの文字列置換機能よりは高機能だとは思う。

 

使ったのはHTML+CSS(SCSS)+javascript サーバーは一切使ってない単なるクライアントアプリ。

 

今回は俗にモダンWebアプリケーション開発においてよく使われるツールを使って開発してみた。

 

使ったのは、

・npm(node.js)

・gulp

・yo

・bower

 

AngularとかのフロントエンドMVVMを使ってる人にとっては当たり前の技術だとはおもう。

 

が、こんな記事もあるように、フロントエンド技術はの流れはかなり早い。今までかなり早いなと感じていた仮想化技術より何倍も早く感じた。

 

そのため、とりあえず導入しようとしてもまず何から手をつけていっていいのかわからなかった。

 

「node.jsを使う?あれサーバー用javascript処理系じゃないの?」

とか

「gruntとかgulpとかbowerとかyoとか名前は聞いたことあるけど使い方とか何が嬉しいのかわからない」

とか

「SASSとSCSSとLESSって何が違うの? Compassって何?」

っていう状態。

 

そんな中ひたすら手探りで開発していった。

 

とりあえず公開できる状態まで持って行った所で、改めて振り返ったことは、

「これらはすべて効率を上げるためのツールである」

ということ。

 

 

使わなくてもプログラムは書ける


 

 少なくとも上で挙げたツール群はあくまで

「今まで手作業でやっていた作業を効率化」

するためのツールであり、自分のアイデアを読み取って形にしてくれるものではないし、ましてや、0から1を生み出してくれるものでもない。

 

つまり使っても使わなくても同じものはできるのだ。

 

じゃあなんでこんなツール群があるのかというと、上でも書いたとおり、手間を省くためにある。

 

例を挙げると、bowerはコマンドを打ち込むか、bowerfileにあることを記述するだけで、使うライブラリをバージョンも合わせて持ってきてくれる。

 

これが手作業だと、公式ページに行って、ブラウザからダウンロードして・・・・・と言った手順を踏まなければならない。

 

もうひとつyoを例にしよう。

 

yoはアプリの雛形を作ってくれるツールだ。

 

いちいち自分でフォルダ構成を考えてフォルダを作って・・・・などどめんどくさいことをする必要が無い。

 

更に、yoの雛形を作っているのは大体現役バリバリのフロントエンドエンジニアなので、ベター/ベストプラクティスを知るのにも役立つ。どことなくRailsの設定より規約っぽい。

 

2つのツールを例に挙げたが、これらのツールがやってることはすべて手動でもできる。

 

実際に使ってみて


 

使いはじめは、右も左もわからないツール群だったのでとにかく苦痛だった。

 

○○の使い方がわからない→調べる→○○はもう死んだ!これからは××だ!という記事を見つける→××をつかう→更にわからなくなる。

 

というサイクルにも陥った。

 

いつまでも調べてもらちが明かないので、とりあえず使い方が理解できたbowerから使ってみることにした。

 

正直とっても楽だった。今まで公式ページに行ってDLしてという作業がめんどくさかったので、これだけでもだいぶ楽になった。

 

次に使ったのはyo、ただし雛形に大幅に手を加えたので実質使っていないに等しい。

 

次にやっとgulp、俗にタスクランナーというものを初めて使った、が、gulpfileを書いているとある落とし穴にハマった。

 

ツールを使うことが目的化する


 

開発も佳境に入った頃、自分はあるツールの使い方で悩んでいた。

 

そこでふと我に帰りあることに気づいた。

 

「自動化する必要がないことまで自動化するという意味のないことをしている」

 

gulpfileを見てみると、1度しか実行したことがないタスクや、手でやったほうが早いタスクなど様々な物があふれていた。

 

つまり、アプリを書くことではなく、gulpを使うことが目的化していたというわけだ

 

初めてgulpを使って作業を自動化出来た時、なんとも言えない快感を味わい、その時すでに目的と過程が入れ替わってしまったんだろう。

 

どう使っていくか


 

 初めてフロントエンド技術に接する人にとっては見慣れない言葉やよくわからないコマンドばかりで戸惑うだろうとは思う。

 

そこでまずはツールは一切使わずすべて手作業で一度コードを書いてもらいたい。

 

そこで一番めんどくさかった物を自動化するツールから使ってみてはどうだろうか。

 

自分も使っていないツールがある(karmaとかjasmineとか)

 

それでもよくわからないという人はBrowser-syncから使ってみてはどうだろうか。Ctrl+sを押せばブラウザが自動的に更新してくれる、と言うのはなかなかくせになる。

 

 

一段落ついたし次はUNIXコマンドの実装でもしようかな。