サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
やろう!確定申告
blog.keithyokoma.dev
この記事は SHIROBAKO ADVENT CALENDAR 2020 10 日目の記事です。 とにかく劇場版 SHIROBAKO のエンディングが素敵なのだ。多分にネタバレを含むので、まだ劇場版を見ていない方はいますぐ U-NEXT にサインアップして見てほしい。何ならテレビ放送の分まで配信されているので、それをみてから劇場版を見てほしい。今なら初月無料(劇場版 SHIROBAKO は課金が必要だけど 1 週間見放題)だし(一応申し添えておくと、自分は U-NEXT の回し者でもなんでもない)。 この記事の趣旨としては劇場版 SHIROBAKO のエンディング映像を見てもらいたいが、ここにそれを貼り付けるわけには行かないので、エンディングテーマを歌う fhana さんの「星を集めて」の公式 PV を置いておく。 www.youtube.com 劇場版では、劇中劇である劇場アニメ SIV
コロナ禍のなかで検証用の Android 端末をどう調達・管理するのかという話題を DroidKaigi.fm #4 でしてきました。その会話の中で、自分の場合は検証端末を全部自宅に持っていて、STF を使ってつないでいるという話をしたのでそのあたりを少し掘り下げてみようと思います。 STF とは Smartphone Test Farm という OSS ソフトウェアで、これをつかうことで Web ブラウザから STF サーバにつながっている Android 端末を操作できるようになります。adb による接続もできるので、端末を自分の PC に USB ケーブルでつなぐことなくアプリのデバッグが可能です。 github.com 本来は社内ネットワーク内などで STF サーバを立てておき、社内から誰でもブラウザで端末を使えるようにするようなユースケースで使うものですが、自分の場合は自分で会社
Peaks さんで「チームで育てる Android アプリ設計」と題した執筆プロジェクトに @kgmyshinさんと取り組むことになりました。この記事はこのプロジェクトが発足するまでの経緯や、執筆する本に込めた思いを伝えられればと言うことで書いています。 チームとアーキテクチャを両輪で語る書籍 これまでの様々なアーキテクチャのあるべき論から少し離れてみて、どうやったらうまくチームでアーキテクチャを扱えるようになるかを、釘宮さんと自分のそれぞれで得た経験をベースに話していく書籍が「チームで育てる Android アプリ設計」です。 アーキテクチャは一度整えればそれで終わるわけではなく、プロダクトの成長やチームの成長とともに少しずつ形を変えていくものであるという考えのもとで、新規開発チームでの事例と、走り始めたあとの規模の大きなチームでの事例を紹介していく予定です。 チームで育てる Andro
コロナ禍で在宅勤務が一気に広まり、自宅でアプリの開発やリリースをすることが多くなりました。この状況のなかで、アプリの挙動に問題があるなどで動作確認をしようと思うとき、その問題に対処するためのデータを集めたり、問題が発生したときの状況を確認するための手立てを持っておく必要があります。この記事では、手元にない端末で起きる問題のトラブルシューティングをしやすくするために準備しておくとよいことを書き残しておこうと思います。 端末のログを収集する ある端末でアプリがクラッシュしたときに、そのスタックトレースを記録しておくことはとても重要ですが、そのクラッシュにいたるまでに何があったかをログとして収集しておくことで、クラッシュが起きた状況を把握しやすくなります。 Firebase Crashlytics や DeployGate など、端末からログを収集して Web コンソール上で閲覧できるようにして
この記事は、DroidKaigi 2020 で発表予定だったセッション「持続的なアプリ開発のための DX を支える技術」を解説するための記事です。 セッション概要 Android の歴史はすでに 10 年を超え、数多のアプリケーションがストアで公開されています。これらのアプリケーションの中には、何年も継続的にバージョンアップを重ねているものもたくさんあります。 このセッションでは、このような持続的なアプリケーション開発・リリースをうまく回す秘訣として DX という言葉をとらえ、アーキテクチャやテストのほか、日々の開発に関わるワークフローをメンテナンスするための考え方や手立てとして、モバイル CI や Android 向け各種ツールキットの導入と効率化、Gradle をベースにした独自タスク開発の方法などを紹介します。 資料 speakerdeck.com 一部実装の詳細を資料に委ねています
DroidKaigi 2020 を支えるはずだった技術シリーズの、DroidKaigi 当日にスタッフを支えるはずだった技術の話として、運営スタッフ向けアプリを作った話をします。 運営スタッフ向けアプリを作り始めたきっかけ DroidKaigi も過去 5 開催をしてきていて、2020 で 6 回目になる予定でした。どの年も当日へ向けてたくさんのミーティングを重ね、担当ごとのタスクをこなすのに必要な情報をまとめてドキュメント化し、当日も Slack やトランシーバを駆使して綿密に連絡を取り合うなど、スタッフ間のコミュニケーションが円滑に進むよう準備をしています。 当日、スタッフが参照するドキュメントは多岐にわたります。ひとり一つの担当が割り当てられたとして、見るべきドキュメントは「全スタッフに共通する情報をもっているドキュメント」「担当ごと固有のタスクの説明を盛り込んだドキュメント」「各自
DroidKaigi 運営スタッフの @keithyokoma です。 記事タイトルにあるとおり、DroidKaigi 2020 を支える(はずだった)技術シリーズと題して DroidKaigi 運営スタッフによる一連のブログ投稿をはじめます。 企画の意図 DroidKaigi はこれまで、2015 年から数えて 5 回開催しており、DroidKaigi 2020 で 6 回目の開催となる予定です。 残念ながら 2 月開催は中止となりましたが*1、過去数ヶ月にわたって運営スタッフ一同非常に多くの時間と労力を使って準備を進めてきており、せっかくなら何らかの形でこの準備の成果をお見せできるようにし、少しでも何らかのお役に立ちたいという思いから、このシリーズ企画が動き始めました。 DroidKaigi の理念に照らし、運営スタッフもまた Android またはそれに関わる周辺技術の知見共有とコミ
いまや Git なしでは生きていけないくらい Git に支えられている生活を送っていますが、Git のブランチをマージする手段にはいろいろあって、実際 GitHub でもプルリクエストをマージするときには 3 種類の方法から選ぶよう促されます。 git merge ブランチをマージするコマンドですが、ブランチの状況によって挙動が変わります。具体的には Fast Forward と non-Fast Forward の 2 種類があり、オプションで指定しない限りは Git が勝手に判断してくれます。ここでは、masterから派生したtopic/aブランチをmasterにマージすることを想定したときの動きを説明します。 Fast Forward topic/aの派生元のリビジョンがmasterの最新リビジョンと一致するときは、単純にtopic/aの最新リビジョンをmasterの最新リビジョンに
TL;DR 実を言うと私はDrivemode, Inc.を退職します。 突然こんなこと言ってごめんね。 でも本当です。 本日が Drivemode, Inc. に籍がある最後の日になります。お疲れさまでした。 次も変わらず Android アプリのエンジニアで、明日からメルペイで働き始めます。六本木界隈の皆様よろしくおねがいします。 近況について 実のところ、10月中旬からずっと有給消化をしていて、引っ越しをやったり、ジャパンカップ・クリテリウムやツール・ド・フランスさいたまクリテリウムの観戦をしたり、ジャパンカップのあと LottoNL Jumbo チームのアフターパーティーで選手たちとセルフィーを撮ったり、あとは吉祥寺ニワカを脱するためにハモニカ横丁やらなんやらでランチを楽しんだり、自転車でロングライドをちょくちょくやったりしました。Cafe Kiki という飯能にあるサイクリスト御用
Android Oreo から、Oreo 以上のバージョンをtargetSdkVersionにしているアプリケーションがForeground Serviceを起動するには、Context#startForegroundService()によるサービスの起動とService#startForeground()による通知の表示の両方を実行しなければならなくなりました。またContext#startForegroundService()から5秒以内にService#startForeground()を呼び出さないと、ANRとしてクラッシュレポートが作成されます。 この"Context#startForegroundService()から5秒以内にService#startForeground()を呼ぶ"というのが厄介で、ServiceがContext#startForegroundService
今日は Wercker がビルドキューを無限に積んでビルドしてくれなくなってしまったので、急遽 CircleCI 2.0 を試すことにしました。 メモリが足りずに OOM Killer にデーモンが殺されたり、desugar 中になにかが失敗しているようですが、とりあえず一番大事な「GCR にある private な Docker イメージでビルドを開始する」ことは可能なことがわかったのでよしです。公式にドキュメントが見当たらないのでこの記事で参考にしてください。 config.yml Wercker の設定ファイルとほぼ同じように指定できますが、認証情報とタグの構造が違います。 認証情報は auth に持っていて、タグは image の部分に書きます。 version: 2 jobs: build: docker: # specify the version you desire her
やりたいこと 旧来の AdapterView (ListView や GridView など)でいうところの OnItemSelectedListener と同じように、RecyclerView がもつアイテムにフォーカスが当たったときにその情報をコールバックする方法です。 方法 RecyclerView には OnChildAttachStateChangeListener というインタフェースが定義されています。このインタフェースのメソッドで、Adapter の生成する View が RecyclerView に attach されたタイミングが分かるので、そこで attach された View に OnFocusChangeListener をセットしてフォーカスが当たったことを検知します。 class FocusListeningRecyclerView(context: Cont
Issue Fragment を使わず View をベースにしてレイアウトを組むと、Fragment と同じような役割をもった CustomView を作ってレイアウトを組みます。 このとき CustomView は何かしらの ViewGroup を継承することになりますが、そのレイアウトファイルのルートを<merge>にしないと無駄な ViewGroup がひとつ挟まってしまいます。一方で、<merge>をそのまま使うと、レイアウトのプレビューでは親が何になるのかわからないため、期待通りの表示ができません。 Solution tools 属性に<merge>の親が何になるかを指定するtools:parentTagが AndroidStudio 2.2 から増えています。 <merge xmlns:android="http://schemas.android.com/apk/res/an
前提条件 Service から次のように Activity を起動しようとした時、直近 5 秒以内に他の Activity を Home キーで閉じていると、startActivity の呼び出しからすぐには Activity が起動しません。 // this は Service Intent intent = new Intent(this, SomeActivity.class); // Service から起動するときには FLAG_ACTIVITY_NEW_TASK が必要 intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(intent); Affinity やその他 LaunchMode などの設定に関わらず、Activity を Home キーで閉じたあと 5 秒は Context#startActivi
先日の DroidKaigi 2017 で発表した「Building my own debugging tool on overlay」のなかで、WindowManager で取り扱うレイヤについて触れた部分がありますが、Android の次バージョンである O から使用できなくなるレイヤ、代替レイヤについてのアップデートがありますので、こちらにも書き残しておこうと思います。 developer.android.com developer.android.com 使用できなくなるレイヤ 以下のレイヤは使用できなくなります。 TYPE_PHONE TYPE_PRIORITY_PHONE TYPE_SYSTEM_ALERT TYPE_SYSTEM_OVERLAY TYPE_SYSTEM_ERROR このうち DroidKaigi の発表で取り扱った部分は TYPE_SYSTEM_OVERLAY
この記事は SHIROBAKO Advent Calendar 2016 - Adventar 17 日目の記事です。 昨年は杉江さんについて*1書きました。今年は作中に出てくる「万策」について書きたいと思います。 かなりネタバレしてますのでご注意下さい。途中でだんだん語彙力の万策もつきてきてしまって申し訳ないさが半端ないです😭。 万策といえば本田さんですが、一年目えくそだすのみゃーもりも万策尽きそうな場面がたくさんあります。 えくそだす4話のごたごたの始まり 3話の原画があがらず瀬川さんに代わりをお願いしたことで、4話のスケジュールがおすところです。 色指定の新川さん、撮影の佐倉さんに注意を受けたところから始まり、徐々に切羽詰った感が出てきます。 この時のドーナツをどーんと行きたくなるくだりと、たろーにミンチッと心のなかでぼやくシーンのわかりみの深さたるや。 遠藤さんへの依頼 瀬川さん
それ早く言えよ!というツッコミもあるかとは思いますが、TechBoosterさんの技術系同人誌「AZ異本(アツい本)」でAIDLに関する「そんな使い方するの…」的な記事を担当しました。 techbookfest.github.io techbooster.github.io AZ異本は技術書典という技術系同人誌オンリーの即売会で出まして、現在はBOOTH.PMでも取り扱っています。 techbooster.booth.pm TechBoosterさんで世に出る何かを書く、というのは密かに憧れていたのですが、今回の技術書典でそれがかなってとても嬉しかったです。 技術書典当日も売り子としてブースで来場者の方々が手にとって買っていくのを生で見ていました。これまでは電子書籍の売れ行きやQiita上のストックがたまっていくところでしか実感できなかったことが、直接自分の目で見て体感できたのはとても貴重
このページを最初にブックマークしてみませんか?
『blog.keithyokoma.dev』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く