【AndroidStudio 不要】サンプルアプリは「dryrun」で試してすぐ捨てよう

参考にしたいサンプルアプリをGiHubで見つけて試してみる場合は以下のような手順

1. サンプルアプリのリポジトリを探す.
2. zip をダウンロードする.
3. それを展開する.
4. AndroidStudio などIDEを開く.
5. インポートする.
6. Gradle が sync する.
7. プロジェクトを run.
8. 実行するデバイスを選択する.
9. 実際に動かしてみる.
10. zipファイルとプロジェクトフォルダを捨てる.

となりますが,「dryrun」をインストールすると

$ gem install dryrun
...
$ dryrun -h
Usage: dryrun GITHUB_URL [OPTIONS]

Options
    -m, --module MODULE_NAME         Custom module to run
    -p, --path PATH                  Custom path to android project
    -h, --help                       Displays help
    -v, --version                    Displays version

dryrun: Try the demo project of any Android Library

リポジトリのURLのみでターミナルからの一行で起動までが可能になります. AndroidStudioなどIDEは起動しなくてよいです.

プロジェクトディレクトリは残りません.

$ dryrun https://github.com/cesarferreira/android-helloworld

usage_v2

cesarferreira_dryrun__Try_the_demo_project_of_any_Android_Library

アプリ起動後, 動かしてみて, いらなくなったらターミナル出力の最終行に表示されているadbコマンドでアンインストール.

...
> If you want to remove the app you just installed, execute:
adb uninstall github.cesarferreira.helloworld

あなたのマシンには試したテストアプリの不要なプロジェクトディレクトリがたくさんありませんか?

man は長すぎるので「tldr」


2016年5月からの「TOEIC®テスト公式問題集 新形式問題対応編」登場!!

150415472505_TP_V-1

2016年5月29日からテスト形式が変わるのはすでにアナウンスされています.

TOEIC|インフォメーション|2015年度|TOEICテスト 出題形式一部変更について

リスニングセクションの変更点

写真描写問題(Part 1)と応答問題(Part 2)の設問数が減ります。
会話問題(Part 3)の設問数が増えます。
会話問題の中に、発言が短くやり取りの多いものが加わります。
3名で会話する設問があります。
Elisions(省略形: going toが gonnaなど)、 Fragments(文の一部分: Yes, in a minute; Down the hall; Could you?など)を含む会話が流れます。
会話やトークの中で聞いたことと、問題用紙に印刷された図などで見た情報を関連づけて解答する設問が加わります。
会話やトークの中で話し手が暗示している意図を問う設問が加わります。

リーディングセクションの変更点

短文穴埋め問題(Part 5)の設問数が減ります。
長文穴埋め問題(Part 6)の一つの文章に含まれる設問が 3問から4問に増えます。
文書の全体的な構成を理解しているか問う設問が加わります。具体的には、
長文穴埋め問題で、文書内の空欄に最も適切な一文を選ぶ問題
Part 7(1つの文書)で、文書内に新たな一文を挿入するのに最も適切な箇所を選ぶ問題
テキストメッセージやインスタントメッセージ(チャット)、オンラインチャット形式で複数名がやり取りを行う設問が加わります。
Part 7(1つの文書、複数の文書)の設問数が増えます。
Part 7(複数の文書)で 3つの関連する文書を読んで理解する設問が加わります。
文書中で書き手が暗示している意図を問う設問が加わります。

TOEIC|プレスリリース|2015年度|「TOEICテスト公式問題集 新形式問題対応編」

必須の参考書となるでしょうね.


ソースディレクトリの構成時にもっておくべき「会社別」のイメージ

ひとつの部分を変更しようとして, 必死に複数のファイルをいったりきたりしながら更新してみると, 意図しないところが壊れている.

想像してみてください.

マネージャー会社, プログラマー会社, 人事会社, マーケティング会社がある.

プログラマー会社には, マネージャーやマーケティングや人事の人はいなくて, プログラマーしかいない.

いきなり src 直下に「activities」「fragments」「views」ディレクトリを作成してしまうことに似ていません?

「何をするか」ではなく「何であるか」でまとめられたものは, 探そうとすると何度も大きく移動しなければならない.

「会社の業種別」「会社別」のような「何をするか」を優先させたイメージでディレクトリを構成していくと以下のようになります.

1-A-m20R0Qve-eB4ishqZc_Q

良い点

- 高モジュール化.
- 見つけるのが分かりやすい.
- 高レベルな抽象化.
- 機能とレイヤー両方で分けられている
- 構成のメンテがやりやすい.
- 凝縮されている.
- スケール変更しやすい
- 関係ないクラスやファイルを変更するアクシデントが少なくなる.
- 機能の追加や削除がしやすい.
- 再利用しやすい.

Package by features, not layers — The linkedcare Engineering team — Medium

【2015-10-14 公開!!】Google I/O 2015 のソースコードに見るディレクトリ構成

ひとつの考え方として根底にあったほうがよいと思いました.

これに合わせてリソースディレクトリも小分けにできるという話は以下から.
res ディレクトリは小分けにしたほうがいいのではないか