Posts

Flutter の学習をしている 最初は SwiftUI に関する情報や設計などを見聞きしたりするつもりだったはずだったけれど、 試しに Flutter の State managemennt も読んで参考にしてみようと調べ始めたのがきっかけな気がする。 そうしていると色々興味が湧いてきて最近熱心にドキュメントを読んだり、サンプルを clone してきて読んだりしている。 サンプルが豊富なことや、コミュニティが強いこともとても学習に助かっている。 特に YouTube の flutterdev はコンテンツの量と質が良くて、良い塩梅でフランクで見やすい時間の尺の動画が多い。 また、これはサンプル程度の小規模のアプリだからの可能性があるが、開発体験がとても良かった。 具体的には VSCode と Flutter のプラグイン含めた相性が良くて、特にブロッカー無しにスッと取り組めるようになった。 合わせて通常の iOS アプリ開発とは違って、 hot reload が小気味よく動くのも良い。 以下は読んだ記事やコンテンツに関するメモ 1.はじめに読んだ Flutter for iOS developers 現行で iOS アプリエンジニアなので、これを読むと大枠が掴めると勘繰って読んだ。 その読みは大体あっていた位の印象。 少し違っていたのは、全体的に UIKit ベースの iOS アプリ開発との比較対象で書かれているので、 SwiftUI のようなモダンな宣言的 UI との比較ではなかった。 結果としてもこれから読むのはファーストステップとしてとても良いと思う。 Build and release an iOS app ざっと読んだだけだが、 Flutter 特有の便利ビルド設定や配布などは無くて愚直に Runner を編集するしか無いのかと思った。 2.環境構築 brew install flutter flutter doctor で足りないものを直す VSCode で各種プラグインをインストール これくらいで開発を始められた 3.はじめに手を動かした Write your first Flutter app, part 1 Write Your First Flutter App, part 2 ...

読んだ動機や前提 イラストでわかるDockerとKubernetes Software Design plus 予め前提として自分のステータスは以下のような感じ。 Docker 主に業務のみで使用 用途としても人が書いた docker-compose.yml の編集や、 docker-compose up を行うのみ VM を良い感じにしたやつ程度の認識 Kubernetes 聞いたことあるだけ SRE の人達がこれを使っていたので、deploy などに必要なんだろうなという程度の認識 YAML で色々管理されていそう 業務でも手元でのローカル開発などで使う頻度が増えて、ひとまず浅く理解したいという課題感があった。 その中で知人が blog で勧めていたので読んでみた。 感想 主に Docker に関する理解が進んだ。逆に Kubernetes に関しては利用経験も無いのもあってか、概要のみの理解にとどまった。 Docker に関しては 第1章 コンテナ技術の概要 と 第2章 Dockerの概要 によって理解が進んだように感じる。 仮想マシンとコンテナの違い 軽量な実行環境 ポータビリティ ワークフロー Build Dockerfile を元にした docker build Ship レジストリへのアップロード、登録 Run コンテナのレイヤー構造 キャッシュも効く 読み書き可能レイヤーや Copy on Write のところは面白かった Kubernetes に関しては以下のような理解になった。 ...

感想 Hecto: Build your own text editor in Rust を手を動かしながら読んだのでそのメモ。 通して読んでみて総論とても良かった。 今まではチュートリアルや言語概要が主だったが、当初の思惑でもあった実践的な開発をこれを通して感じることができた。 具体的にはエディタというアプリケーションを（ほぼ）スクラッチで作っていく過程で、 学習者に OSS を使って自分のコードを置き換えてもらって便利さを味わってもらったり、 場当たり的な条件式や繰り返しのコードをリファクタリングしていくなど、 実際に即した開発を体感できているように感じた。 ひとまず Rust 学習についてはこれでひと段落させて、少し時間をあけて LeetCode などで Rust を使って行こうかと思っている。 読書メモ 以下は読書時メモ kilo という OSS のエディタの Rust 版実装 Chapter 1: Setup 特に真新しいことはない cargo init hecto しただけ Chapter2: Reading User Input これで標準入力を受け取れる use std::io::Read; for b in io::stdin().bytes() {} デフォルトの Rust のバイナリは canonical mode と呼ばれ、標準入力を Enter を押した後に受ける また、終了するときは Ctrl + C などを入れる必要がある エディタで必要なのは raw mode それを実現するための crate がある termion Rust では character の場合は single quote termion 導入 into_raw_mode を使って標準出力 stdout を取得している なぜ stdout が 入力である stdin に影響する？ Terminal は自身のステートを reader ではなく writer によって管理されているから writer は screen への描画やカーソルの移動に使われている into_raw_mode で取得した stdout はどこにもアサインされていないのに動くのはなぜ？ Rust の所有権 Ownership システムによるもの _stdout が存在する限り raw mode が続く _ をつけることで未使用変数でもコンパイラによる警告がなくなる Observing key presses variable shadowing Rust では同じ変数名を2度定義できる println! macro placeholder {} print 可能な string representation を持つオブジェクト向け {:?} 上記以外 carriage return \r インデントなしで次の行に行ける println! が \n を入れる前に ASCII code 0-31 と 127 は control character 32-126 がプリント可能 page up や page down は3~4byteが出力される escape sequence と呼ばれる 必ず27から始まる backspace が 127 enter は 13、 carriage return ctrl + A-Z が 1-26 に割り当てられている Error Handling Rust には try catch はない panic! と return value で Result を使う unwrap は Ok なら中の value、Err なら panic! の sugar syntax Chapter 3: Raw input and output termion を使って stdin に keys を生やせる それを使って Key::Char Key::Ctrl('q") などで match で分岐する impl のなかで &self パラメータがない場合はそれは static method になる Rust で read-only property を作るには pub を付けずに変数定義して、読み取り用の pub fn を作って参照を返すようにするしかない saturating_add は結果の値がその型の最大値もしくは最小値を超える場合、その最大最小で返す カーソルを表示・非表示するのに escape sequence を使う cursor_position を editor に入れてるのが面白い terminal ではないのは、それが screen ではなく document 内の場所だから Chapter 4: A text viewer #[derive(Default)] をつけると、その struct のイニシャライザに default() がついてパラメータ初期化を勝手にやってくれる Rust が default を推測できないパラメータを持つ場合、上記の derive は使えない env::args() の 0 番目はプログラムの名前、引数の最初は 1 マルチバイト文字などを含め、マウスで選択できる1文字のことをGraphemeという https://en.wikipedia.org/wiki/Grapheme grapheme 単位で文字を扱うために unicode-segmentation をインストール 時間関連の扱いに、 std::time::Duration や std::time:Instant がある Chapter 5: A text editor iterator take は 0 から at まで skip は at から終わりまで collect が便利 iterator から collection に変換してくれる Result 型には is_ok() が使える 同様に Option には is_none() is_some() がある &self.file_name などへのプロパティの参照は & をつける これをしないと所有権がうつらない bool flag を pub にしないで、 is_flag の pub fn として後悔するのは一般的なのかな？ read only で pub にできないからかな clippy::restriction で lint ぽいことができる exclude するケースも [allow(clippy::{rule})] で書く get_mut で安全に配列にアクセスすることもできるが、予め index check を行い確実にアクセスすることができるなら冗長になるので直接 array[index] でアクセスする Chapter 6: Search enumerate() で index と value を取得できるのは Swift と同じだな Fn の他にも FnMut がある rfind は見つけた文字列の後ろから数えた index を返す PartialEq は比較できるようにするための trait Chapter 7: Syntax Highlighting 最初は row 内で直接 digit にのみ色を付けて、そのあとリファクタリングする流れ良い

感想 この前にRustプログラミング入門 を読んだ。 そこで Rust の全体像や実際の開発方法については浅くはありながらもキャッチアップできたと思うので、 次はもう少し言語に深く触れてみたいという課題感があり、Tour of Rust をやってみた。 5日くらいかけて一日30分~1時間で全9章を終えることができた。 途中からは日本語訳がないので苦手な人は注意が必要かも。 終わってみての感想としては以前よりは言語に対しての理解が深まった気がする。 特に heap / stack 周りの Box を使ったメモリ管理や、Ownership management (dereference) あたり。 とはいえ、これで自分で何かものを作れるかというとまだ自信がないので次は実践的なアプリケーション開発をしてみようと思う。 この Hecto: Build your own text editor in Rust が良さそうと思っている。 (追記) Build your own text editor in Rust を読んだ で上記のメモを残した。 読書メモ 以下は読書時メモ Chapter 1 The Basics 変数の型が違う場合の as キーワードある 配列の初期化は [T; N] T は型、Nは固定長の長さ 関数の返り値がない場合、空のタプル () が返り値となる Chapter 2 Basic Control Flow loop から値を取り出す、便利 let v = loop { x += 1; if x == 13 { break "13 を発見"; } }; ブロックの最後に ; が無い式は、それが戻り値として使用される if 文を三項演算子のように使うこともできる Chapter 3 Basic Data Structure Types struct はフィールドの集合 フィールドとはデータ構造とキーワードを紐付ける値 その値はプリミティブな型かデータ構造 コンパイラにメモリ上で隣り合うデータの配置を伝える設計図のようなもの メモリ Rust には3種類のメモリ空間がある データメモリ 固定長もしくはライフサイクル中に常に存在するデータを格納 プログラム内の文字列キャラクタは読み取り専用なのでここ メモリ上の一は固定かつ知られているので、高速に使用可能 スタックメモリ 関数ないで宣言された変数を格納 関数から呼び出されている間はメモリ上の位置は変更されないため速くアクセス可能 ヒープメモリ プログラムの実行時に作られるデータ データをヒープメモリに入れることを allocation、削除することを deallocation という タプルを使った構造体も作ることができる struct Location(i32, i32); フィールドを持たない構造体も宣言できる あまり使われない Chapter 4 Generics Types Generics struct や enum につけることができる ::<T> を使う ::<> を turbofish というらしい、魚に見えるから？ Rust には null がない 変数に値がない可能性を意味するため、プログラミングが難しくなる None によって代替する Option を使うのが一般的 Swift ぽい、Swift には nil があるけど main() で Result を返すこともできる Result 強力な ? 演算子がある 以下の2つは等価 do_something_that_might_fail()? - ```rust match do_something_that_might_fail() { Ok(v) => v, Err(e) => return Err(e), } unwrap Option / Result にある 値がある場合はその値を、無い場合は panic! する 可能な限り match を使う Vec 可変サイズのリスト vec! マクロを使うと簡単に作れる Vec は構造体、内部的にはヒープ上の固定リストへの参照を持っている デフォルトの容量よりも多くの項目が追加された場合、ヒープにより大きな固定長を生成して再割り当てする Chapter 5 Ownership & Borrowing Data Rust にはがGarbage Collectionがない C++ではResource Acquisition Is Initializationとも呼ばれる メモリ開放は階層的に行われる 構造体自体がまず消され、その後に子要素が消える 関数の引数に所有者が渡されると、所有権は関数の仮引数にmoveする move後は元の関数内の変数は使用できない 参照を使ってリソースへのアクセスをborrowすることもできる & を使う 参照も変数同様消える 変更可能な参照もborrowすることができる &mut を使う データ競合を防止す流ため、可変な参照は1つしか持てない &mut の参照は * 演算子を使って dereference できる 値のコピーも可能 参照は所有者よりも長くは存在してはいけない 存在しないデータへの参照を防ぐ C言語ではダングリングポインタと呼ばれる 参照の一部を参照することも可能 明示的なライフタイム コンパイラは全ての変数のライフタイムを管理している　' を関数の引数や戻り値に指定してライフタイムの共有を指定する Chapter 6 Text utf-8 可変サイズ 1~4byte 簡単なindexing、例えばstring[3]がO(1)でできなくなってしまった シーケンスを繰り返して見るのでO(N)になる Unicode での文字列の作業が困難なので、Rust では char 型の文字のベクトルにして取得する方法が提供されている char は常に4バイトの長さ Swift のテキスト操作の面倒さもこの辺りからきてるんだろうか？ Chapter 7 Object Oriented Programming Rust には inheritance は無い method の最初のパラメータは必ず self への参照になる fn get_sound(&self) -> &str デフォルトだと object のフィールドやメソッドはモジュール内でのみ公開になる モジュール外にも出す場合、 pub キーワードをつける polymorphism は trait を使って実現する これは Swift の protocol oriented programming と同じ trait は実装済みの method を持つこともできる trait は他の trait を inherit できる dynamic vs static dispatch static dispatch インスタンスの型がわかってる場合は直接その関数を呼ぶことができる dynamic dispatch インスタンスの型がわからない場合、何が正しい関数なのかを知る必要がある　&dyn MyTrait を使うことで引数などで dynamic dispatch が使えるようになる trait object と呼ばれる function へのポインタを持つインスタンスへのポインタ C++では vtable と呼ばれる Generics generics を使うことでコンパイル時に静的に型が付き、static dispatch が可能になる ...

読んだ動機 個人で Rust を使って何か作ってみたいというのと、普段の業務とは別の言語を触ってみて何が良いのか学んでおきたいというのが主な動機だったかなと思う。 前提として1年以上前に プログラミングRust は読んだことがあったけれど、モチベーションが続かず途中で読むのをやめてしまっている。 なので、今回はもう少し実践的で手を動かしながら挑戦してみたいと思っていたところに、タイトルにもある以下のほんの評判を聞き手にとってみた。 実践Rustプログラミング入門 本の概要 この本は Rust の概要から始まり、言語仕様や周辺のツールチェーンの紹介まで書かれており、これらで1/3ほど使われていた。 その後の1/3ほどで実際のアプリケーションの開発を行う。 簡単な TODO 管理を行う Web アプリ WebAssembly を使った Web アプリ GUI ネイティブアプリ 組み込み開発 個人的にこれらの実際のアプリケーション開発はとてもありがたかった。 実際に開発で使う場合に、どんな crate を使うのが良いかなどは初心者にとってはなかなか掴み所が難しかったりするので。 ...

iCloud が登場してから、ずっと iPhone + iCloud のみで写真を管理してきている。 家族もファミリープランに登録しており、以下の200GBのプランを使ってた。 https://support.apple.com/ja-jp/HT201238 しかし子供が産まれてから写真を取る頻度や枚数がとても増えて、契約していた200GBプランの上限が見えてきてしまった。 面倒なので更に上の2TBプランを契約しようかとも考えたが、今後も考えると2TBでもあまり長続きもしなさそうと思い、これを機会に考えることにした。 このブログでは実際に決定した運用方針を説明する。 選定サービス 信頼性とコストの面も考えて、いくつかの対象に分けて保存することにした。 Amazon Photos iCloud Google Photos Time Machine HDD 大きくクラウド3つとローカル2つに分かれる。 全部で5つと対象が多くなってしまったのがやや課題だが、ローカルの2つに関しては元から運用していた。 1. Amazon Photos 以前から Amazon Prime 会員ではあるので、メインのクラウドバックアップ先になった。 Amazon Photos の特徴は主に以下 Amazon Prime 会員だと写真に関しては無制限アップロードかつ品質も元のままでアップロードが可能 Family Vault という概念があり、会員は5名まで招待できて招待されたユーザも招待者と同じ無制限アップロードが与えられる 無制限は写真のみで、動画は Amazon Prime 会員であっても5GBまで Mac 版アプリが配布されているので、スマートフォンでポチポチやる必要無し また心理的な面でも、既に Amazon Prime で年会費は払っているので急な有料化などは起こりづらいのではという仮説があり、 自分の場合は他の無料サービスと比較して安心して決定できた。 2. iCloud 引き続き200GBプランを継続して使用する。 50GB に下げることも可能だが、後述する実運用でバックアップを行うインターバルが短くなって面倒なのと、 現在の値段だと対してどちらも変わらないため。 iCloud は写真と動画それぞれどちらも劣化なしで元ファイルを保持してくれるので、一時キャッシュとして扱うことにした。 3. Google Photo 既に2021年6月1日からのストレージ有料化が発表されているので、メインのバックアップ先としては検討できなかった。 https://photos.google.com/u/0/storagepolicy?hl=ja\ ただ現状は無料なので、サブの保存先としてとりあえずあげている。 万が一何かが消えた時などにもしかしたらここにあるかも？と探せれば良いかな程度の温度感。 4. Time Machine 以前から Mac で Time Machine を使ってバックアップを取っていた。 ...

インストール 以下のページにあるコマンドを実行する https://rustup.rs その時に nightly beta stable を選択するが、M1 Mac の場合は beta を選択する必要があった。 しかし以下のように stable でも 1.49.0 がリリースされていたので、 もう stable を選ぶだけで良い。 s t a b l e - a a r c h 6 4 - a p p l e - d a r w i n i n s t a l l e d - r u s t c 1 . 4 9 . 0 ( e 1 8 8 4 a 8 e 3 2 0 2 0 - 1 2 - 2 9 ) 上記の切り替えは rustup を使って、以下のように行うことができる。 ...

Storyboard/Xib diffs If you’re an iOS Developer, you might have experience storyboard / xib diffs appeared when you just opened it. Those interface builder files have some version specification ih those files named toolsVersion. It can be modified if Xcode version and it’s changed since last time you opened. And it’s noisy because everytime when you opened interface builder files, it’ll be modified even if you don’t want to modify it. ...

ツールの変更 2020年9月末くらいから、ノートやタスク管理系のツールをガッと一気に変更した。 定期的にツールを変えたくなる時は訪れる（良くない癖）けど、ここまで一気に変更するのは初めてかもしれない。 今までの課題感・変更する動機などを簡単にまとめる。 新しいツールを3ヶ月弱使ってみた上での紹介などは長くなるので別の記事などで書きたいと思う。 今までのツールと課題感 今まではノートを取るのは iOS/Mac 純正メモアプリ、タスク管理(主にGTD)は Things を使って行っていた。 変遷でいうとノートはその前は全盛期（今では見る影もない）の Evernote を長く使っていた。 タスク管理は以前は Todoist や iOS/Mac 純正リマインダーも使っていた。 その中で大きな不便などはもちろん無いけれど、漠然とした課題感は大きく以下のようにあった。 消費したコンテンツの内容を体系化して保存できておらず、忘れてしまう 書いたノートを見返す事もほぼ無く、書き捨てを前提にしている 記憶力も良くないので、知識が蓄積されている感じがしない タスク管理とノートは相互でつながっていることが多く、ツールを跨いで移したりなどが面倒 kiriminさんの様々なTODOアプリやタスク管理方法を試行した結果最終的にプレーンテキストに行き着いた話にとても共感する タスク管理をしていても、中・長期的(Weekly, Monthly, Quarterly, Yearly)な目標管理ができていない 上から順に解決したい課題だった。 動機 上記のような課題がある一方で、同時に移行コストも高いので日々良さそうなツールを試したりしながら見送っていた。 そんな中良いタイミングで良いツールや紹介記事と出会い、また個人的にも転職もあり、良いリフレッシュの機会が提供されて移行できた。 あと Rebuild.fm #287 でも話されていて、自分のきっかけなどを書きたくなった。 以降に際しての方針は課題に対して大まかに以下だった。 ノートやタスク管理などを個々で1ツールで扱うのではなく、なるべく一元化して一つの場所で管理したい そのための UI や体験は一定犠牲になっても良い 体系的にノートを管理する上で、必要以上の労力をかけたくない 過去にも Evernote などで頑張って tagging や構造化を試したりしたが、上手くいかなかった メンテナンスコストが非常に高いのと、ノートを作成する心理的消費も同時に高くなる（面倒くさくなる） Mobile アプリは充実していなくても良い これは時節柄、最近はあまり外出しないのと、Mobile デバイスで長いテキストを書くことがほぼ無いから 移行先ツール 移行先のツールに関してはタイトルにもある通り Roam Research を使うことにした。 早速方針の なるべく一元化して一つの場所で管理したい と矛盾するが、その他の補助ツールもいくつかある。 それらの紹介については簡単にしておいて次回以降、以下のようなワークフロー別に書こうと思う。 未読管理 (bookmark, highlight保存など) GTD、タスク管理 目標管理 Roam Research の良かったところは主に以下である。 構造化が不必要なグラフ型のノート管理 [[]] でリンクを作ることで一瞬でノートが作成できる 双方向リンクが簡単に作れる、かつ修正が容易 各アウトラインがノートの単位になっている コミュニティの熱量がとても高い #roamcult 各種サービスとの連携が比較的できる 詳細は長くなってしまうので、これまた別で書こうと思う。 ...

メルカリ・メルペイを退職する 2020年9月末で最終出社となり、有給休暇を挟んだ後にメルカリを退職することに決めた。 入社したのは2016年5月なので、4年4ヶ月の間在籍していたことになる。（間に育休取得もさせてもらったので便宜上4年としている） 当初いわゆる退職エントリを書くつもりはなかったけれど、こういった時世ということもあり、社内・社外に沢山お世話になった方々がいる中で、挨拶もあまり満足にできなかったので書くことにした。 最終出社を終えて、毎日見ていたSlackが見れなくなり、こういう文章を書いてみてようやく少しずつ辞めたんだなぁと実感している。 このエントリは分の4年間の振り返りも兼ねた個人の日記。 改めて振り返ってみると、メルカリに入社した動機は大きく以下の3つであった。 自分や自分の周りが毎日触るようなサービスに携わりたい US 進出を本気で行っている 自分より優秀な人がたくさんいる環境 (一番の下手くそでいよう) 入社を決めた動機は全て正しかったと今でも思える。 そんな4年の経験で得られた一番のモノは、“なんとかやっていく"力だろうと思う。 急拡大する会社・サービスではなんとかしないといけないことが本当にたくさん起こる。 それは Get shit done なのかもしれないし、 Disagree and commit かもしれない。 とにかく"やっていく"しかない状況・環境によって"やっていく"ことができたよう思う。 やっていたこと 移行期にグラーデーションこそあれど、大まかにいうと最初の2年はIndividual Contributor/Tech LeadとしてSoftware Engineer(iOS)、残りの2年をEngineering Managerといった役割で仕事させてもらった。 IC/TL Mercari JP/Mercari US/Merpayという大きく3つのドメインで、主にプロダクト開発業務に携わらせてもらった。 Mercari USでは出品画面を作ったり出品画面を作ったりした。 最終的にはアプリの作り直しをやることになり、複数人で3ヶ月という短期間で望んだ。 iOSDC 2017で発表させてもらった時のスライド US 版 Mercari をまるごと1から作り直した話 Merpayではとても多い機能開発を、メンバーを採用しながら開発も並行で行い1年かけてリリースまで行った。 開発開始からリリースまで1年かかったのは自分の経験では初めてで、リリースの瞬間は今でもよく覚えている。 twitter EM Merpay開発開始から半年経ったくらいからEngineering Managerの業務をすることになった。 具体的には採用から評価・フィードバックまで、体系立てて色々当経験させてもらった。 そんな中で誇れるのは何といっても、優秀かつ多様なメンバーを採用することができたこと。 これには本当に恵まれていたなと今でも思っている。 2019年末には機会を頂いてEOF 2019で以下の発表もさせてもらった。 メルペイのエンジニアリング組織の変化と目指すチーム像 メルペイiOSエンジニアが「EMとしての1年半」で気づいた、チームに必要な3つの要素 #eof2019 2020年に入ってもOrigamiチームの合流や、リモート環境下でのマネジメントやコミュニケーションなどチャレンジングなことが続いた。 次とその動機 次 小さなスタートアップで、もう一度Software Engineerとして働く。 社員数も一桁で、ここまで人数が少ない会社は初めてで不安も無くはないが、熱量高く、楽しんでやっていく。 動機 チャレンジしようと思える(自身の興味のある分野|信頼ある知人のリファレンス|アップサイドの可能性のある)機会をもらったのが一番の動機かと思う。 と同時に自分自身としてもそろそろエンジニアとマネージャの振り子を振るタイミングと思っていた。 Engineering Managerを2年近くやらせてもらって、客観的な評価含め一定成果は出せたと自分で思えているのも、振り子を振り直す理由の一つになったのかなと思う。 個人的見解だけれど、いわゆるマネジメントのスキルはSoftware Engineeringに比べてより普遍で劣化速度も遅いと思っていて、もう少し年齢など含むステージ的に後でもチャレンジできそうと判断した。 逆にこのまま更に数年Engineering Managerを続けてやるという決断をした場合に、もう一度Software Engineerとして振り子を振り直せるかどうか怪しいと思ったのも、大きくはないが理由の一つとしてはあるかもしれない。 エンジニアとマネージャの振り子を強く信じているし、キャリアについても金融のポートフォリオと似たような所があると思っていて、 ...