これおもしろい

らふにかいてこ

podcastをやろうと思うのです

podcast

(腰が引ける前にどんどん宣言しておいて、やらざるを得ない状況を作ろうキャンペーン)

きっかけ

podcast好きなんです。
テック系しか聞いていないけれども。
コアな話が出てくるのとかだとなお良し。

色々と聞いている中で「面白そうだなー、やってみたいなー」とちょいちょい思っていましたが、面白い話も出来なければ声が良いわけでもないし、気恥ずかしさもあって、話に出すだけで実際にやろうとはしていませんでした。

そんな中、昨日 yatteiki.fm

rebuild.fm を聞いていた時に、ふと「podcastやりたいなー」とツイートしてみたところ、意外といいねをされ、まあやってみてダメだったらダメで良いんだし、とりあえず動いてみるか、という気持ちになった次第です。

方針

実際にやるにあたって、どういう方針でやっていきたいのかを考えてみました。

色々浮かびはしましたが、一番は「そういう風にエンジニアになる人もいるんだ」とか「そういうエンジニアもいるんだ」と知れる場所を作りたい、ですかね。
「自分って、別段特出した技術も知識も持っていないし、特色のないどこにでもいそうな一般的なエンジニアだよなぁ」と思ったりしますが、誰しもが辿ってきた道も違えば育ってきた環境も違うので、その人じゃないとそのエンジニアにはなれないと考えています。
普通とか、そういう括り自体はあるかもしれないけれど、その中でもその人にしかない色がありますよね。そこを拾いたい感じです。
(ちょっと話違うけど、こちらの話でいう"武器"に近い感じ？ですかね？https://kensuu.com/n/n8a6373dcdb37)

なので、色々な人とpodcastで話して、もしそのゲストの人の経緯やスタイルの話を、必要としていた人が聞いて、エンジニアとしての第一歩を踏み出すなり、何かが始まったりしたならば、素敵なことではないかなと。
まあ、ちゃんとpodcast始められるのかも、続けられるのかも分かりませんがね！
エンジニアに限らず、知り合った色々な人たちから話を聞けたら面白そうですよね。

ちょっと書いてて気恥ずかしくなってきたのですが、そういう思いでやってみようと思うのです。
ちゃんと始められた時には、よろしくお願いします。
ちゃんと始められなかった時には、podcasterの先達にご指導ご鞭撻を賜りますようお願い申し上げに行こうと思います。

ちなみに、やってみたいんだよね！一緒に話してくれないか！と、同僚のwebエンジニアのしーけ (@shikeapp0909) | Twitterにお願いして、月曜の朝に会社で録音してみようと予定しています。(寝坊しなければ試し撮りくらいは出来るはず)

追伸


あ、このツイートにいいねしてくれた方々は、podcastが軌道に乗せられた時にゲストとして声を掛けさせてもらおうと狙ってますので！よろしくね！(｀・ω・´)

(正直こんな記事まで書いて、風呂敷広げるだけ広げている気がして怖い。ひとり細々やるだけだから別に何かある訳じゃないけれども。)

DDDインプット中(iOSDCリジェクトコンで発表予定)

ドメイン駆動設計

今年のiOSDCのリジェクトコンは9/18(火), 20(木)の2日間。

iosdc-reject-conference.connpass.com
その内の1日目のトップバッター、「DDD(ドメイン駆動設計)を知っていますか？？」で30分枠を頂戴している者です。

付け焼き刃でインプットできるものではないと知りながら、ようやくDDDのインプットに着手し始めました...orz
遅くなったのはもう仕方ないので、出来る範囲で全力を尽くしてインプットをし、「DDDの"インプット"の初めの一歩を踏み出したい方」をターゲットに共有できれば、と思っています。

ちなみに、DDDをインプットし始めた動機は、Yuki Anzai (@yanzm) | TwitterさんがDroidKaigi2018で発表されていたY.A.M の 雑記帳: Android アプリの開発でドメイン駆動設計に取り組む話という発表を聞き、今所属しているチームにDDDを導入できないか？と感じたからです。
モバイルアプリでどのようにドメインモデルが定義出来て、コンテキストをどういう感じに分けられるのか、というイメージが全然出来なくて今詰んでいますが...。
DDD導入されている方に是非ともお聞きしたい。本当に是非🙏

以下、メモ書き

今後のインプットの流れ(予定)

  1. 実践DDDを読む
  2. DDD(EricEvans)をさらい読み
  3. (並行)資料作成

実践DDDを読む

頭から読むのは断念。

  1. 目次を洗い出す: 目次には節までしか記載されていなかったので、項を洗い出して表にする → 印刷
  2. 「各章の概要」、各章にある「本章のロードマップ」「まとめ」を目次と合わせて見て、各章をざっくり理解する
  3. 2までやって頭に出来た大枠に内容を詰めていく？(まだ2だからよしなに)

DDD

全部読む時間がないので、実践DDDで蓄えた知識を元につまみ食い？

資料作成

頭の中で構成を組み立てながらインプットを進めること
学んでいく上で持っておくと理解が進むイメージとか、そういうのあったら共有したい

potatotips#52に参加しました！(Android編)

potatotips.connpass.com

Android枠で先日FOLIOさんで開催されたpotatotipsに参加してきました！
遅くなってすみません...orz
基本的に、口頭で話された、スライドに書かれていないものをスライド下に箇条書きで書いています(多分)。
ご覧になる方は、スライドを見つつ参照して頂ければと思います。

にわタコ (@niwatako) | Twitterさんが各LTで書かれていたgistも参考にしながら書かせて頂きました。
niwatako’s gists · GitHub
素敵共有、本当にありがとうございます🙏

LT

Roomのできるまで InvalidationTracker編

Yuichi Araki (@yuichi_araki) | Twitterさん

Room InvalidationTracker potatotips #52

  • RoomはAndroidに標準搭載されたSQLiteのラッパー
  • どうやってSQLiteから通知を受け取るのか？
  • 案1：書き込みメソッドの実装はRoomが生成しているので、その中で通知する→直接SQLiteに書かれたら検知できない
  • 案2：C言語で書かれたSQLiteの拡張機能を使う→最強かと思いきやAndroidで使えない
  • 実際：変更ログのテーブルを準備して、各テーブルに変更があるたびに書き込むトリガーをこっそり仕掛けて使う
  • ObservedTableTracker = 監視されている時だけトリガーを仕掛ける為に、監視されているかを監視する
  • 今後の課題は次バージョンで対応したい。不具合報告、要望受付中。
  • ほぼ直面することはないだろうが、2つ目の課題に関しては、長い書き込みをする前にはダミーのトリガーを仕込むと回避できる

KotshiからMoshi-codegenに乗り換えた経緯

えぐ (@duane0728) | Twitterさん

speakerdeck.com

  • Moshi-codegenとKotshiのどちらを選ぶか？
  • 速度検証、イシューから大きなバグの確認、今までの流れやイシューから将来性の確認
  • Kotshiは作者がdeprecatedになるかもと言っているので、Moshi-codegenの方が安全そう
  • しかし、まだ出て1ヶ月ほどなので、様子を見た方が良いかもしれない

Kyashで使っているTutorial Library

こにふぁー (@konifar) | Twitterさん

speakerdeck.com

  • チュートリアル：ハイライトさせて吹き出しで説明する
  • 似たようなライブラリはあるが、Kyashの要件に合わなかったので自作した
  • ハイライトする部分はTargetという単位で捉えてTargetインスタンスを作り、そこにテキストのアニメーションの設定、テキスト部分のレイアウトを設定していく
  • レイアウトに関しては、指定されたidを持つレイアウトを準備すれば作られるようになっている
  • チュートリアル系のライブラリはどれも癖があるので、要件に合えば使ってみて、合わなければコード見て真似してみてね

github.com

XML Object Mapping

hmori (@moridroid) | Twitterさん

speakerdeck.com

  • Swift4で生まれたCodable、Jsonとコードの変換ができる
  • Javaはこれが得意で、GsonとかMoshiとか色々ある
  • これらの基本的なロジックは空のインスタンスを作って後から値を入れる
  • が、Kotlinのdata classは基本ロジックと考え方が合わない
  • Moshiを使うか自作する(自作の話をしていく)
    1. Reflection: 型パラメータを型に変換する → オブジェクトグラフを作成して、末端のインスタンスから作っていく
    2. APT: アノテーションをつけて、クラス名でアダプタを見つけて生成したものを使う
    3. Transform API: 詳しくは記事で！
  • オブジェクトマッパー作ったけど、仕事で作ったから公開できないです

Tips for Bitrise Android

Shohei Kawano (@shaunkawano) | Twitterさん(へいへいさん)

speakerdeck.com

  • タップル誕生のAndroid開発でBitriseを使っている
  • Bitriseはモバイル開発に重きをおいたCIサービス
  • circleCIを使っていたが、メモリ不足やスクリプト管理が辛いのでBitriseにした(スクリプトはfastlaneで対応)
  • コミットしたタイミングでbitrize.ymlのタスクを実行
  • trigger_mapにpush/prの他にtagを追加したが、意図した動きにならない
  • '--tag'をつけることで今のところ動いている
  • タグが切られた時にドラフトリリース作って署名つきアプリをアップロード、レポジトリではファイルダウンローダーの機能を使ってgradleとkeystoreを取ってきて署名

Android P - Restrictions on non-SDK interfaces

shinobu.aab (@operandoOS) | Twitterさん

speakerdeck.com

動画も公開されている

惜しまず全て共有してくれてるので、追記する内容は特にありませんでした

What’s new in Google Play Billing

やまんだー (@ymnd) | Twitterさん

speakerdeck.com

  • Google Play Billing: Google提供の決済基盤でワンタップで支払いができる。都度購入や定期購入をサポート、アプリで金銭トランザクションを処理する必要がない、ユーザーに一貫した購入フローの提供。
  • 2のproration modeに関しては文字だとわかりにくいので、図でも説明

スライドが詳細なので、ぜひご一読を。

Pay attention to the HUGE logs

わくわく (@wakwak3125) | Twitterさん

speakerdeck.com

  • WorkManager: 実行条件に電源接続されている、Wi-Fi接続されているなどの制限を加えられる
  • 金曜日にWorkManagerに感謝しながら帰宅 → 月曜日全部死んでた: WorkManagerは何も悪くないが、ログが爆発(OOM = Out Of Memory) => めっちゃでかいログには気をつけよう

Hey Guys, I am...

mhidaka (@mhidaka) | Twitterさん

スライドURL:
なし

  • 技術書典5やります
  • エンジニアリングマネージャをやることになった心境を話します
  • エンジニアリング = エンジニアだけのもの、ではない -> 技術を使ってプロダクトを良くすることをしたい
  • 組織の急拡大で、トップとボトムを繋ぐ人が足りない => 適切なアサイン、技術的な評価、施策の選択が難しい
  • 基本的には技術に責任を持ってコミットメントしていく、プロダクト横串で見ていく
  • 長くは心が持たなさそうなので、期間を切ってやるという話をしている
  • マネージャになるという選択肢は誰にでもありうる
  • Hey Guys, I am 'Engineering Manager'