2019年01月に読んだ本
もう2月になってしまったけど1月に読んだ本!1冊だけ!
ITエンジニア的論理思考テクニック! 仕事ができる人になるための13の極意。
チームリーダーにオススメされ読んだ。文章は読みやすかったし、値段相応の量でサックリ読める。
自分がとくにキーワードしてあげるなら以下の2つ!
- 定量的に説明する
- ロジックツリーで伝える
「作業を終えるにはもう少しかかりそう」 => 「作業を終えるには1人日かかりそう」 => 「もう1人日かかりそう。今日は障害対応で作業ができなかったため。」
日々の仕事の報連相でクセづけていきたい、と思うと同時に、やりすぎだろと思う部分もあったので、うまいこと調整してやっていきたい気持ち。
2019年の目標
来年2019年に自分が何に注力するのか、どういう状態になっていたいのか、というのをざっくり書いておくことで、定期的に自分で振り返る材料にしたい。
ここに書いたことは確定ではないし、1年間ずっと固執するわけでもない。多分変わる。
お金を稼ぐ
2019年はお金をもっと稼ぐ。その選択肢はここに書けるものもあれば書けないものもある。
書けるものでいうと、これとは別のブログを作ったり、あとはアプリを作ったりする予定。
なぜお金を稼ぎたいかというと、来年は今年以上にお金を使う年になりそうだから。
お金を使う
しかるべきものにお金を使う。これはプログラミングのことだけじゃなく生活まわりや、自分の健康面などもそうだ。
多分大量にお金を使うことになるのだが、今の収入では確実に足りないので、最初のうちは金額や時期的な面で優先順位を考えながらお金を使っていくことになるだろう。
本を読む習慣をつける
技術書だけじゃないけど、本を読む。
とりあえず外部サービスの読書メーターを使い始めたので、これで管理してこうと思う。
そのほか、読んだ技術書に関しては1ヶ月毎くらいでまとめて記事にしたりしてみる。とりあえず今月はこれ
ということで3つ書いたけど結局のところ2019年で1番大事な目標は、お金を稼ぐこと。そのための環境の変化は受け入れる。
みなさま良いお年を。
2018年12月に読んだ技術書
思いつきで書いてみる。と言っても2冊しか読んでない。
アジャイルサムライ――達人開発者への道
昔から読みたかった気持ちはあったけど、仕事で読む必要に迫られたので読んだ。実際は10月くらいに買ってざっと流し読みしたあと、仕事で必要なときに読み返して使った。
読みやすいし面白かった。また1つのフレームワークが知識として残った。
比較して学ぶRxSwift入門 (技術書典シリーズ(NextPublishing))
これは自分のためにではなく、チームに入ってくるiOS開発未経験のメンバーにオススメできるかどうか、毒味的に読んでみた。
毒味といっても、RxSwiftに関する書籍は現状これぐらいしかないはずなので、結構期待して買った。題名のとおり、iOS開発の入門をサックリ終えたあとにRxSwiftを学び始めたいと思っている人が読むような本だった。内容は基礎的で、そこまで深く説明はされないものの、入門としてはいいんじゃないかと思う。
そこまで高くないし眠くなるようなボリュームではないので、サックリ読める本。Cold/Hotの違いとかも最低限の説明がされてあるので良い。
iOS(Swift)エンジニアがGoでAPI作って感じたこと
普段Swiftを使ってiOSアプリを開発している私が、GoでAPIを開発した際に感じたことを紹介します。
列挙型(Enum)がない!
SwiftではEnumをめちゃめちゃ使います。ですがGoにはありません。が、Goではtypeを用いて擬似的にEnumっぽいことを実現できるようです。
Swift
enum Edge: Int { case top, bottom, leading, trailing }
Go
type Edge int const ( Top Edge = iota Bottom Leading Trailing )
interfaceを実装することでEdgeを拡張することができます。たとえばStringer
インタフェースを実装すると、文字列での出力ができるようになります。
type Edge int const ( Top Edge = iota Bottom Leading Trailing ) func (c Edge) String() string { switch c { case Top: return "上端" case Bottom: return "下端" case Leading: return "左端" case Trailing: return "右端" default: return "Unknown" } }
Swiftエンジニアからするとちょっと違和感がありますね。そうです、ケースを網羅していてもdefault節は必要です。enumではないですからね。
ただinterfaceを実装することでEdgeをどんどん拡張していくことができるので、自由度は高いです。
ついにポインタを学ぶときがきたか...
Swiftにも、UnsafePointerなどのポインタを扱えるAPIがあるのですが、業務や趣味含めて一度も触ることはなかったため、業務としてはGo言語で初めて触れることになりました。正直今も100%理解できている自信はないです。
SwiftエンジニアにおけるGo言語へのハードルを低くする目的で書きますが、ポインタの使い方のひとつとして、SwiftでいうOptional型のような使い方があると思ってみるといいのではないかと思います(あまり真に受けられると困るのですが)。私は最初そう思うことで、自分なりにGo言語に対するハードルを下げていました。
SwiftのOptional型のような、というのはつまりnilを使いたいときにポインタ型を使うということです。たとえばAPIレスポンスのjson定義とか、DBのカラムの定義とかです。
type User struct { ID int `json:"user_id"` Name string `json:"user_name"` Age *int `json:"user_age,omitempty"` }
これでuser_ageがnullじゃなければAgeをjsonに含めるということができるようになったりします。
そのほか、例えば構造体は値型ですので関数に渡すときなどコピーが生成されますが、ポインタを渡すことで元の構造体を参照できます。
type Position struct { X float64 Y float64 } func Exchange(p *Position) { x, y := p.X, p.Y p.X = y p.Y = x }
ただポインタはやはり重要な概念だと思いますので、Goと仲良くなってきたらしっかり腰を据えて学びましょう。 Pointers — An Introduction to Programming in Go | Go Resources
これ使っとけばOKなフレームワークがない
iOS開発でいうところのCocoa Touch(UIKit)に相当するようなものがないという認識です。私は業務でAPIを作りましたが、そのときは社内で一番採用実績があること、ミニマムであること、ドキュメントドリブンなところなどに惹かれgoaを採用しました。
ほかにもたくさんあるみたいなので興味があればご覧になってみてください。7 Frameworks To Build A REST API In Go | Nordic APIs |
ただこれは躓いたというよりは当たり前のことで、「選択肢の中からメリット/デメリットなど特徴を理解したうえでそのとき最適なものを選ぶ」という、課題解決においては普通のことが必要になるということでした。
ビルドはやい
※2018/12/19思いついたので追記
コード書いてビルドして確認(orテスト)の一連のスピード感が速まるとテンポよく開発できます。
iOSアプリではビルドを待ってる間に仮眠したりトイレに行ったりできますので、それもそれで嫌いじゃなかったんですが、やっぱテンポ良く開発できると気持ちがいいもんです。
エラーハンドリングでゲシュタルト崩壊
if err != nil
とif err == nil
がゲシュタルト崩壊を起こしました。今自分がどちらを書こうとしているのかわからなくなります。
if err != nil { // 異常系処理 } if err == nil { // 正常系処理 }
Swiftのエラーハンドリングに慣れていると最初のうちはゲシュタルト崩壊を体験するかもしれませんが、大丈夫ですそのうち慣れます。
Gopherくんが可愛い
iOS開発には存在しない、Go言語公式のマスコットキャラです。仕事で疲れた心を癒してくれました。
おわりに
最初のうちは、Swiftの慣れからくるGo言語への抵抗感がありましたが、今はそうでもないです。
むしろGopherくん可愛いし、やっぱり自分の中に新たな知識が流れ込んでくるのは新鮮ですね。
これからもGoと仲良くしてまいります。
若月佑美卒業セレモニーで若様を見送ってきた
12月4日、会社の大イベントで夜勤をしていたのでお昼頃に家に帰り疲れまくっていたものの、夕方頃家を出て武道館に向かい、若様を見送ってきた。
席は2階の真ん中あたり。決していい席とは言えないが、落選した人に比べれば行けるだけ幸せだ。というか席はもはやどこでもいいから行きたかった。多分ファンみんなそういう気持ちだと思う。
日本武道館でライブを見るのは初めてだ。東京ドームや神宮球場とは違って、ステージが近くに見える。それだけメンバーの姿もよりくっきり見えるので、ライブが始まる前から興奮していた。
19:00になり、影ナレが始まった。誰だかわからないけど泣いていた。泣きながらもハッキリとナレーションしていたのが印象的だった。後の自己紹介で、それは美月だということがわかった。影ナレは、美月、梅ちゃん、たまちゃんの3人が担当した。若月軍団の3人だ。
影ナレが終わってしばらくして、ライブが始まった。はっきりとは覚えてないけど、最初は暗転からのOvertureだった気がする。そのあとは、ダンサーみたいな人たちが踊って、真ん中から若様が登場した。ロボットダンスだった。若様のキャラ渋滞を引き起こしたキャラの1つである。そうか、今日は若様の色んなキャラが見れるんだな、そう思った。
もうあまり覚えてなくて時系列で書けないのでここからは感想。
普段のライブでは聞けないような曲がたくさん聞けたので新鮮だった、とくに私のような新参者からすると。あと途中途中に乃木どこや乃木中の映像が流れてて普通に面白かった。レズロボットのくだりとか。
手紙も最高だった。若様らしい文章だった。
あとは最後の最後、ステージ裏にはけるときの「やっぱ若月だな!」「(会場全体で)だな!」は感動したし、そのあと若様が泣きそうになっているのを見てたまらなくなった。
・・・と、ポイントポイントで何度か泣いたところはあったが、私が一番感動したのは、セレモニー全体をとおして感じられた若様の二期生に対する愛情だ。
曲のチョイスもそうだし、若様のコメントもそうだし、二期生のコメントからも、若様が普段から二期生に対して愛情深く接していたことがわかり、それでもう私は胸がいっぱいになった。
というのも、ファンのみなさんならわかるだろうけど、二期生に関しては各所で不遇だと言われている。これからだというときに加入したものの、一期生の壁が厚く、なかなか歯がゆい時期が長く続き、そして気づいたら入っていたフレッシュな三期性。
蘭世もセレモニー中、「二期生に対して(ファンのみなさん)色々と思うことがあるかもしれないですけど・・・」というようなコメントをしていて、やっぱり二期生本人たちも歯がゆい思いをしているのかなと感じた。
この卒業セレモニーでは若様をはじめとした一期生が、二期生に対して以前から、そして普段から愛情深く接している様子を知ることができた。若様の卒業セレモニーではあるが、なんだか二期生が救われたような気がした。
とても安心した。やっぱ若月だな、やっぱ乃木坂だな、と思った。
若月佑美さん、7年間ほんとうにお疲れ様でした。
iOSDC 2018でLTしたのでその話とか
もう1ヶ月前のことなので忘れつつあるものの、とりあえず書いていく。
スポンサー応募を忘れる
iOSDC 2018のスポンサー募集を何かで見た。うちの会社でスポンサーやったらいいんじゃないと思い上司に提案して資料請求したりしてた。
上司も基本的に「いいじゃん」という感じだったので、スポンサーをやるていで進んでいた。
ある日、twitterでスポンサー募集が締め切られていることを知った。
忘れていた。
cfp応募まで
スポンサー応募を完全に忘れ、意気消沈していたが、もともとスポンサーやるなら誰か登壇しないとね、という話になってたのでぼくもcfpを出すつもりだった。
アプリチームにも当然のごとく宣伝はしたが、みな興味はありそうだったものの、誰もcfpを出したりせず、というかそもそもiOSDCに参加する予定の人はいなかった。
cfp決定
cfpを出そうとは思ってたものの、話す内容はとくに考えていなかった。
いろいろ漠然と考えて、Textureのことなら少し話せそうだなーと思って、軽い気持ちでLT枠/ルーキーズLT枠に応募した。
まさかの採用から当日まで
cfpを出してからは、仕事に追われ、iOSDCのことなど考えてなかった。
ある日メールが届いた。ルーキーズLT枠で採用されたらしい。
ここから登壇当日までの記憶はほとんどない。正直それほど肉体的/精神的にキツかった。
当日
案の定うちの会社からはひとりでの参加となった。
当日はもうなんかてんやわんやしてた。
お昼に接続テストしようと思ったら、ミニディスプレイポーとVGAの変換ケーブルが会場に無くて、池袋に買いに行ったりした。
会場で大学の頃の先輩と偶然出会ったりした。
発表
ある程度は練習していたので、練習のとおりに話していった。
みなさんちゃんと聞いてくれてありがとうありがとうありがとう、という気持ちで話した。
資料はこちら。
振り返り
K
- iOSDC登壇経験(LT)をつめた
- Textureについての知見が得られた
- 大学の先輩に出会えた
P
- スポンサー応募忘れた
- 発表のために成果を出すのがキツすぎた
- 5分でわかりやすく伝えることができなかったと思われる
- そもそも5分で話す内容ではなかったと思われる
- 変換ケーブル無くて焦った
T
- タスクに落とし込む
- カンファレンス駆動開発は今後一切しない
- 話せる見込みがある内容で勝負する
- 伝えたい内容に基づいて発表時間を決める
- ラクそうだと思ってLTに逃げない
- 変換ケーブルは事前に買っとく
おわりに
反省する部分も多いけど、また来年も何らかの形で関わりたいなーと思う。
あとLT後のビールが格別だったし、ストレスから解放されたあとの深夜のマクドナルド爆食は最高だった。
みなさん素晴らしいイベントを開催してくださって本当にありがとうございました。
iOSDC 2018 Reject Conference days1 参加レポ
1週間ほど空いてしまいましたが、先週 iOSDC 2018 Reject Conference days に参加してきました。
iosdc-reject-conference.connpass.com
DeNAさんでの開催でした。エントランスは綺麗でした〜。
発表枠での参加ではないため、聞いたトークの雑感レポになります。
Make our Swift better
実際に自身が考えた改修案が、Swiftに取り込まれるまでのお話。すげ〜。
考案してからacceptされるまでに約6ヶ月かかったそうです。実フローの話は貴重ですねー。
ちなみに提案したDictionaryのメソッドは、Swift 5で使えるようになるそうです!やったね。
エンジニア経験を活かしたスクラムマスターとして 開発チームとプロダクトを成長させる
エモいタイトル!
スクラムの話ですが、私はというと現在アプリの仕事ではウォーターフォールを経験しています。ただ並行でリーダーをやっているAPI開発ではスクラムを目指しているため、興味がありました。
こういう系の発表を聞いていて思うのは、やっぱり一つの正解というのはなくて、チームにフィットした形を見つけることが大切なんだな〜と。
私もやっていきたい。いや、やっていくぞ。
RxTest/RxBlockingテストパターン
私も仕事ではRxSwiftを使っているので、他の方がどうやって書いているのか知れれば、と思い聞いていました。
スライド内ででてきたViewModelの書き方が私の書き方と似ていて、勝手に親近感が。でもRxで書くとだいたいああなる気がします。
TestSchedulerでのテストは書いたことがなかったので、とてもタメになりました。
制約のなかでContainerViewControllerを作る方法
最近とても複雑な画面を目にし、案の定実装もかなり複雑だったため、ContainerViewを使った実装やMicroViewControllerに興味がありました。
画面は作ってオワリではないので、複雑な画面ほど、保守性を意識して実装したいところです。
実際にTwitterぽいUIを作る上での試行錯誤が聞けたので、実用的な話として参考にしたいです。
おわりに
iOSDC 2018はcfpの数がとても多かったみたいで、リジェクトされた中にも素晴らしい発表がたくさんあったかと思います。
そんな発表に巡り会えるReject Conferenceはほんとに貴重です。
所用で懇親会の前に帰りましたが、とても楽しめました!関わった皆さんお疲れ様でした!ありがとうございました!