ブログ運営x集客xマネタイズ

以前買って棚に置いておいた本です。たまたま棚を開けた時に目に入り、ブログを再開し始めた自分にとって何か得られるのではないか、と思い久しぶりに読みました。

ブログを書く上での課題

最近自分がブログを再び始めた理由は、アウトプットする機会を適切に増やすためでした。 しかし、今までの人生、アウトプットというものをほとんどせずに生きてきて、本当にアウトプットへの苦手意識が半端ありませんでした。 ブログが全然書けない。この書けないには2つの意味があります。 1つは、記事数が出せないこと。 1つは、1記事の分量が足りないこと。

本書ではこれらへの解答がいくつか見つけられました。

記事数を増やすことに関して

まずは三ヶ月毎日書くことで自分の個性が見える

ここ数日は本で読む前から、毎日記事を書けたらいいなとやっていました。その上で一昨日昨日でのノー更新…時間が少なかったのもありますが、"残り少ない時間で書けるネタ"を考えてしまって結局筆が進まず…ということでした。

無理やりひねり出したようなネタでも、ブログ記事の体裁に整えるのに時間がかかってしまうので、そこを考えるとより簡単なネタはないか…と考えてしまう。

クソみたいな記事でも集まれば自分の個性を表すものと考えるともうちょっと気楽に書けそうですね。

実際には、雑記ブログと専門ブログは明確に分かれているわけではなく、お互いの良いところどりをします。雑記ブログでは、２、３個の得意な話題をメインに更新することが多いです。

このブログは基本的に技術中心に話している、いわゆる専門ブログのつもりで書いていました。ただ今やろうとしている毎日更新はそれでは難しそうです。

記事数を増やすために雑記ブログにしますが、Androidに関することを軸においたまま、取り扱う範囲を広げようと思います。 趣味に関することを書けるという意識をしておくことで、だいぶハードルが下がりそうです。

ネタについて

誰でも悩むブログネタ。毎日必要となってくるとなると常に用意しておかなければいけません。

毎日更新しやすくするために、曜日ごとに記事のテーマを分けているのがポイントです。 本書で紹介されていたブログの例から。

"なんでもいいから今日書けるネタを思いつく"

だと思考が散らかってしまって選ぶことも難しいのは思い当たります。

曜日ごとに完全に決めてしまうとハードルを上げかねないですが、大まかに選択肢を決めておくとネタ出しに捗りそうです。 - 休日はAndroid技術に関して調査を含めた上での詳しい記事 - 平日はその日遭遇したエラー・トライを書き留めておくメモ - 時間のない日にはラジオやアイマスなど趣味のことに関して

書評にチャレンジしてみよう

書評を書くことはブログネタを増やすこと以上に、読書の理解を深める手段と考えています。 アウトプットすること前提なので、集中してインプットできます。

気になった記事をはてなブックマークしておけば、あとで簡単に読み直せます。

実は最近twitterに流れてくる技術系のネタは、はてなブックマークに入れるようにしていました。

twitterのいいねはイラストとか普通にいいね。twitterのブックマークは…

ということではてなブックマークは今では技術ネタの"後に読む"の場になってます。

あまり定期的に見てはいませんでしたが、定期的に見返したいですね。

記事の分量を増やす

話しかけるように書く 私は文章を書くときは、とりあえず頭に浮かんだ言葉を並べていくのですが、側から見るととてもめちゃくちゃっぽい気がしながら書いています。

自分の頭の中だけで書くと自分の知識前提で書いてしまいがちで、重要な説明が抜けてしまうことも多くあります。

今考えてみると、自分は暇な時に"好きなことについて人に説明する"って妄想をよくします。

確かにこの時は"この説明の前にまずこっちを説明して…"とやってどんどん内容が増えてくるんですよね。 むしろ"今ここでこの説明挟むと脱線するんじゃないか"って考えてしまうくらい。

文章書く時は、とりあえず自分の中にあるもの全部出してから、そこから整えるって方針ですので、文章量を大量に出せそうなこの方法は本当に使えそうです。

1つの記事につき、小見出しは3つ以上入れるようにしてください。3つ未満だと、コンテンツの量だけでなく質的に不足している場合が多いです。

過去の記事を見てもらえば分かりますが、技術に関して小さなアウトプットする時に、

• こういう問題があった
• こうしたら治った

で終わる記事が非常に多くて困っていました。 それだけではなく、

• どういう環境/システム
• どういうことがしたくて
• どう問題が出て
• どう調べて
• どう解決して
• どういう原因で
• 付随する知識は何か

のように、見出しで分けられるくらい周辺情報を詳しくまとめられるのもいいかもしれません。

まとめ

本書では自分の悩んでいたブログ数/分量が少ないことに対する解答を見つけられました。 一番参考になったのは"誰かに話しかけられるように書くこと"

今回まとめたことは本書の一部で、タイトルにある "集客" "マネタイズ" には手をつけていません。 今やっているとにかく更新することを続けられた後のステップとして、またそちらをまとめたいと思います。

WorkManagerの定期実行は思ったより定期実行ではない

WorkManagerでは2種類のWorkRequestが作成できる。

ひとつはOneTimeWorkRequest。 1度だけ実行されるので通常はこちらを使う。

もうひとつはPeriodicWorkRequest。 キャンセルするまで複数回実行される、とある。

ただ、注意するべきは実行時間を指定できないこと。

with the first execution happening immediately or as soon as the given Constraints are met. The next execution will happen during the period interval

初回はすぐに実行され、そこから指定したintervalごとに実行される。 さらにOSのバッテリー最適化のためにこのintervalもずれていく。 時間指定したいのであればOneTimeRequest使えとのこと。

弊アプリでは毎日特定の時間に通知を出すために利用したかったが、上記の理由でOneTimeRequestにしました。

PowerMock辛いよねという話

今触っているアプリは僕がJoinした時点でPowerMockを使っていたわけだが、非常に辛いです。

class HogehogeManager() {
  private val fugafuga: Fugafuga
}

val mockedManager = PowerMockito.spy(Whitebox.newInstance(HogehogeManager::class.java))
Whitebox.setInternalState(mockedManager, "fugafuga", Fugafuga())

field名をStringで渡してmockさせる。型も何もない。辛い・・・

通常のmockライブラリだとダメだけどPowerMockが必要になるケース、次の2つだと思ってます。

1. privateメソッドのモック
2. staticなメソッドのモック

ですが、これらをモックしたいという時点で何かがおかしいはず。

private メソッド

privateメソッドは辿っていけばどこかのpublicなメソッドから呼び出されているはずで、そのpublicメソッドを十分テストできれば透過的にprivateメソッドも正しく動いているはずです。 それでもprivateメソッドをテストしたくなる場合には設計が悪い可能性があります。 privateメソッドにするのではなく、そのメソッドの実行を責務に持つクラスに切り出して使います。

例えば何か計算してTextViewに表示するActivity.

class HogeActivity: Activity {
  override fun onCreate(savedInstanceState: Bundle){
    ...
    val value = calculate(1,2)
    textView.setText(value.toString())
  }

  private fun calculate(i: Int, j: Int): Int {
    ...
  }
}

この場合privateメソッドであるcalculateはそもそもHogeActivityにあるのが間違いであり、別のCalculatorのようなクラスに切り出すべき。

class HogeActivity: Activity {
  override fun onCreate(savedInstanceState: Bundle) {
    ...
    val value = Calculator().calculate(1,2)
    textView.setText(value.toString())
  }
}

class Calculator{
  fun calculate(i: Int, j: Int): Int {
    ...
  }
}

staticメソッド

ステートレスなものであれば、そもそもstaticメソッドをモックする必要がないはず。なぜならメソッドの引数と返り値の組みが常に一定だからで、モックではなく実体を用いれば良いからです。 ステートフルな、例えばSingletonオブジェクトを持つような場合は、これも設計が悪い可能性があります。 staticなメソッドはコードの至る所から触られる可能性があり、どの状態でも叩かれても大丈夫にしないといけないため。 Singletonなオブジェクトを各所で引き回したいのであれば、DIを使って渡していくべき。

結論

設計を改善してPowerMockをはがそう！

Android StudioでRobolectricでテストを走らせるとVerifyErrorが出る

以下のようなエラーが出ることがある

java.lang.VerifyError: Expecting a stackmap frame at branch target 10

テストのConfigにVM optionsに -noverify を追加する。 (テスト) > Edit Configurations... > Configuration > VM options:

Droid Kaigi 2019 実際に使いたいものをまとめる

カンファレンスとか勉強会出た時って、そのときは「おもしろーい」と思うセッションでも、結局普段の業務に活きなかったり、なかなか試してみずらかったりします。 今回のDroidKaigiでは試してみたい！というセッションが多かったので、忘れないうちに今後やることとして積んでおきます。

shiraji.hatenablog.com ASの設定ということで、すぐに試せます。試した。

Quick Lists

ポップアップリストを自分でカスタマイズでき、KeyMapもつけられる。

File color

File名の背景色を変更できる。ScropeをProductionにすることにより、現在のbuild variantで有効なファイルが分かりやすくなる。 ファイル名同じで複数のvariantに存在するファイルを間違えることがなくなる。

コードフォーマット

コードフォーマット漏れしている部分にエラーを表示させる。

Layout Editor

XML Layout Editorで、下のタブのDesignとTextの位置を入れ替える。 Layout ファイルを開く時どちらかというとxmlを見たい時が多いのでありがたい。

Navigation Architecture Component によるアプリ内遷移の管理 - Speaker Deck

1画面1Activityの並アプリでは、SingleActivity内のFragmentの遷移を行うNavigationComponentはすぐには入れられそうにない・・・ とはいえSafeArgsはFragment生成のInterfaceを揃えられそうなので使ってみたい。

Let's migrate to build.gradle.kts - Speaker Deck

kts化へのステップが丁寧に解説され、ハマりポイントも提示されているのでサクッとやってしまいたい。

Unit test for ViewModel and LiveData - Speaker Deck

本筋とはそれるが、Usecaseの使い方はなるほどという感じ。もう一度調べ直してUsecase使えないか考えたい。

Understanding Kotlin Coroutines: コルーチンで進化するアプリケーション開発 - Speaker Deck

API通信の部分はCoroutineにしたい。

From Monolithic to Modularized codebase with Dagger.pdf - Google ドライブ

今回全体的にマルチモジュール化の話しが多かった今回のDroidKaigi。 かなり重いタスクですが、新規機能から切り出していきたい。

DroidKaigi Day2

2日目。パーティーないので気楽。

droidkaigi.jp 今後のエンジニアとしの身の振り方として、Androidネイティブでは厳しいと思っていて、PWAのストア公開開始にも合わせてReact見てみることに。expoええやん

droidkaigi.jp spek+mockkは最近やってる構成。コードカバレッジは現環境的に導入しても微妙なところではあるが、集計スクリプトは便利そう。

droidkaigi.jp waveとかすげぇ。CicleEditorでアニメーションを作るGUIがついてる。 ただこれ実際どう作ればいいんだ・・・？社のアニメーション得意なデザイナーに話聞いてみたい。

droidkaigi.jp PR出した末にktlintで怒られると辛いので、formatの警告出してくれるのは非常にありがたい。 Prefer xml editorは速攻で入れた。

droidkaigi.jp Viewに対するlife cycle eventはそりゃないよね。

droidkaigi.jp 発表練習から聞いてましたが構成がよくなって非常に面白いセッションでした。 ただ 縦書きを実装したい 人がこれ聞いても実装無理ですよね。

droidkaigi.jp 1Activity-1Fragment構成の現アプリではNavigationは難しそうだけど、DroidKaigiアプリを触った結果SafeArgsは使えそう。 Fragmentのインスタンスの作り方がみんなワークアラウンドでやってたのが、統一できそうでいいよね

https://droidkaigi.jp/2019/timetable/69576/ 俺たちは雰囲気でgroovy書いている その時点でbuild.gradleいじるの億劫になるし普段使ってる言語の方がいいですよね

DroidKaigi 2019 Day1

DroidKaigi 2019行ってきました。Day1。

今年もコントリビュートしてます。といいつつバグ仕込んでて申し訳ない・・・

なんか映ってたらしい pic.twitter.com/Qr7t2rr5Xd

— verno3632@おなかペコい (@verno3632) February 7, 2019

以下参加したセッション。と一言。

droidkaigi.jp 境界値のテストが足りてるか計測してくれるpitestが便利そう。

droidkaigi.jp Usecaseって今まであまり理解していませんでしたが、複数のRepositoryを組み合わせて処理をする部分と聞いてなるほど。

droidkaigi.jp チームビルディングとか含めた話で、割と最近関心がある部分だったので聞けてよかった。 自チームで技術を誇れる組織にする的な目標を作って、どうこの1年やってきたか。

droidkaigi.jp ビジネスロジックとはビジネスチームが考えて行う処理 ユースケースとはビジネスロジックを使うケースごとに分割したもの という説明がセッションを通して非常に良く腑に落ちました。

droidkaigi.jp proguard/R8で知らない設定が便利そう。 R8も賢い。ハマりそうだがいずれ入れたい。

droidkaigi.jp Coroutineはなんとなくコードの書き方はわかっていたが、Threadとの違いや並列性並行性など、どういうことを表しているのかわかりやすかった。 特に基礎的なところに絞ったので理解が捗る。

droidkaigi.jp どういう流れでやれば出来るか説明されると実際にmodule分割したい気になる。 Dynamic Feature Modulesは辛そう。

雑感

あるセッションで前の人が1枚1枚スライドを携帯で撮ってて辛かった。。。重要なところだけだったりシャッター音なければよかったのですが、全部でパシャパシャやられると。。。

見たセッションだとモジュール化の話が多かったです。 主に設計の側面から、関心の分離の方法論として語られていました。 加えてGoogle側もDynamic Feature ModuleやInstant Appなどの機能を出し、マルチモジュールが必須となる未来が見えてきているのが影響しているかと思います。

また聞いてる感じ アプリ開発をスケールするための 設計/テスト/リファクタリングなのかなぁと感じました。 うちのような一人でやってる環境だと設計を綺麗にする暇があったら他にビジネスをブーストさせる方向に人月を割くべきなのでは? とはいえ、常にそういう案件があるわけではないし、やれるところからやっていこうという所存です。