DroidKaigi2018公式アプリのAuthorが変わります。リポジトリ公開は1月中旬予定です - Konifar's WIP
DroidKaigi2018のチケット販売が開始されました。公式アプリのリポジトリはどこにあるのか？いつ公開なのか？といった声を何度か見かけたので、2018の方針やスケジュールを簡単に書いておこうと思います。 過去の公式アプリ DroidKaigiでは、2016年、2017年の2回の公式アプリをOSSで作り上げました。Contributeしていただいた皆さんのおかげで、とてもよいアプリを作ることができました。 この取り組みが始まった経緯や盛り上がりについては、以前書いた記事に少しまとめてあります。 konifar.hatenablog.com konifar.hatenablog.com konifar.hatenablog.com 2018公式アプリのAuthor 2016年、2017年は私がAuthorとして初期のプロジェクト作成、Issue整理、Pull Requestレビューなどを
DroidKaigi 2017 公式アプリのコードを公開しました - Konifar's WIP
去年、DroidKaigi2016の公式アプリをオープンソースで作りましたが、2017もコードを公開しました。 github.com コードだけではわかりにくいところを少し補足しておきます。 2016とは別アプリ 2016とはリポジトリもパッケージも違います。別アプリです。 なぜ去年のリポジトリを引き継がなかったかというと、個人のリポジトリではなくDroidKaigiのリポジトリとして管理したかったというのが1つ。もう1つは、同じアプリをメンテナンスしてると飽きちゃうし、またゼロから作りたかったからです。 余談ですが、カンファレンスアプリに必要な機能はほぼ決まっているので、モデルや画面をガチガチに固めて設定ファイルとリソースを用意するだけで作れるライブラリに切り出してもいいかもなと考えています。 Kotlin メインはKotlinではなくJavaで作っています。ｺﾄﾗｰが「Kotlin一択
ブログで炎上しないために工夫していること - Konifar's WIP
最近、ほぼ毎日炎上した記事を目にします。時には 炎上した記事を叩く記事まで出てきたりして、なんだか殺伐としてるなぁと感じることもあります。 中にはあえて炎上させている人もいると思うんですが、自分はできれば炎上させたくないです。炎上するとTwitterやはてブですごい勢いで色んな意見が来て、めちゃくちゃ精神が消耗するからです。ブログを書き始めてから何度か炎上してしまったことがありますが、本当に仕事が手につかなくなるレベルです。 炎上と一口に言っても理由は様々なのでひとくくりにはできません。個々のケースを引っ張り出して「ここがよくなかったよね、こうしたらよかったよね」という感じでケーススタディにしたとしても、 どういうところがまずかったか本質的に理解できなければあまり意味がないように思います。 このあたりは自分もちゃんと整理できていないので、 自分が炎上しないように最低限工夫してるところをまと
AndroidではMVCよりMVPの方がいいかもしれない - Konifar's WIP
Android開発していると、なんかMVCうまくいかないなぁとモヤモヤしてきました。そろそろ他のアーキテクチャを模索してみた方がいいんじゃないかと思い始めまして、ある程度考えがまとまったので自分なりの指針を残しておこうと思います。 そもそもアーキテクチャ必要なのか 世の中には色々なアーキテクチャが存在するんですが、なんか概念を読んでもスッと理解できることが少ないんですよね。これはなぜかと言うと アーキテクチャが解決しようとしている問題を理解できないからです。 極端に言うと、HelloWorldを表示するアプリにMVCを導入する必要があるの？って言うと答えはNoですよね。じゃあ猫の名前をリストで表示するアプリだったらどうかと言われると、これもまだ必要ないかもしれません。 つまり、アーキテクチャを適用しなくても問題がないほど小さなアプリにおいては、ただ冗長になるだけなので別にいらないわけです。
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
