チームでのスマホアプリエンジニア採用のために求人票について考えていた

こんにちは。近頃はSwiftUIでの新機能開発に勤しんでいる id:ikesyo です。

そんなこんなで自分が所属しているはてなマンガアプリチームでは最近、iOSエンジニア・Androidエンジニアを積極採用しようと動き出しています。その中でまず求人票の内容を検討していました。これまでしたことがなかったけれど求人票を考えるのは意外と面白くて、

  • 要件の洗い出しを通じて、これは現在のチームメンバーも含めたスキルマップについて考えているのだなと思ったり、
  • チームの様子を伝えようとチームのカルチャーについて考えたり、
  • このチーム・はてなで働くメリットはなんだろうと考えたり、

日々のタスクに向かい合っているだけだと忘れがちなことに目を向ける良い機会になっています。

この新たな求人票・採用ポジションはそのうちお目見えするはずですが、SwiftUI・Jetpack ComposeとGraphQLをガシガシ使った開発に取り組んでいるので、

  • 漫画が好き
  • 宣言的UI
  • GraphQL
  • マルチモジュール化

といったキーワードにビビッとくる方はTwitterのDMなどで是非ご連絡ください。まずはカジュアル面談しましょう!

GitHubのPRのコードレビューにおけるsuggestionとコミットの凝集度、完全性について

  • GitHubのPRのコードレビューではsuggestionという、PRの差分に対して変更を提案する機能がある
  • レビュイーは、レビュワーからのsuggestionを1つずつ適用(コミット)するのと、複数個まとめて適用することができる
  • レビュワーがsuggestionする時、例えば変数名のtypoの修正提案では、変数名の定義箇所だけsuggestionすることもあれば、変数の利用箇所の方も合わせてsuggestionすることもある
    • 利用箇所も合わせてsuggestionするのは、別々にコメントすることになるので数が多いと手間だし、PRのコメント数も増えて見通しが悪くなる
    • ので定義箇所だけsuggestionしておいて、利用箇所も合わせて手元で直してください、という意図の時がある
  • レビュワーとしては、この時のsuggestionはそのままGitHub上で適用されることを意図していない
    • もしレビュイーがひとまずそのsuggestionを適用して、続きの修正を手元で行ってコミットしようとする時、最初のsuggestionだけのコミットはビルドが通らなかったり実行時エラーになる不完全なコミットになってしまう
    • ので、こういう時は直接suggestionを適用せずに、関連箇所も一緒に直すようでありたい

PRのラインコメントが付いたまさにその箇所だけではなく、周辺のコード・PR内の別の差分についても意識したい・されたい、ということを考えていた最近です。

35歳になった

本日7月29日で35歳になりました。この1年は

  • Webアプリ開発チャレンジ
    • GoでGraphQL API作ったり
    • Next.jsでフロントエンド作ったり
  • SwiftUIをガッツリ使い始めた

という感じでした。

社のDeveloper Blogのアンケートシリーズに取り上げてもらったりもしました。

エンジニア定年などと思わずまだまだ頑張っていく所存です。よろしくお願いします。

ウィッシュリストはこちら


はてなで一緒にモバイルアプリ開発してくれる人も求めています!!!

WEB+DB PRESS総集編[Vol.1~120]の特別企画にSwift担当として寄稿しました #wdpress

なんと20年分のバックナンバーが収録された総集編の特別企画「進化するプログラミング言語の魅力」のSwiftの章を担当させていただきました。

■書き下ろし特別企画「進化するプログラミング言語の魅力」

言語に精通された7名のエンジニアの方々に, 7つの人気プログラミング言語(JavaScript, Java, PHP, Ruby, Go, Python, Swift)の魅力を寄稿いただきました。言語の進化を感じ,人気を確立するに至った経緯と今が見えてきます。言語を学び始めるきっかけになれば幸いです。

肝心の発売日は明後日の7月31日です!買って読んでくれ!!

f:id:ikesyo:20210729102808j:plain

SwiftOnTap: SwiftUIの用例集付きAPIドキュメント

SwiftUIを使い始めて、フレームワークが提供する既存のViewに何があって、どういう表示になるのかがまだピンとこない。そんな状況の手助けになるのがSwiftOnTapというサイトです。

swiftontap.com

各ViewやModifierなどの説明にサンプルコードとその実行結果のキャプチャーが付いていて非常にわかりやすい。

f:id:ikesyo:20210604103627p:plain
サンプルコードと実行結果のキャプチャー

このサイトのコンテンツ自体もGitHubでオープンソースとして公開されているので、プルリクエストを出して用例を追加することも可能です。面白いのは、全てのコンテンツは SwiftUI.swift という1ファイルに集約されて ///ドキュメンテーションコメントとして記載されていることですね。ファイルサイズが2MBを超えていてすごい。

f:id:ikesyo:20210604104757p:plain
2MB超のswiftファイル

NimbleをSwiftWasmに対応させてみた

SwiftWasmとは、SwiftをWebAssemblyにコンパイルしてブラウザやその他WebAssemblyランタイムで動作するようにしようという野心的なプロジェクトです。

ちなみにSwiftWasmには id:kateinoigaku さんがco-maintainerとして多大な貢献をされています。

fortee.jp kateinoigakukun.hatenablog.com


最近試しに、メンテナーをしているNimbleをSwiftWasmに対応させてみました。

github.com

以前にも一度トライして断念していたのですが、現在では標準ライブラリだけでなくFoundationもThread/GCDなど一部を除いて問題なく動作するようになっていたので、意外とすんなりと対応させることができました。Threadが使えないので toEventuallywaitUntil などのAsync expectationsの機能やNotificationのマッチャーは使えませんが、それ以外はテストスイートも全てパスしています。すごい!

喜んでもらえている様子:

GitHub ActionsでのCIについても https://github.com/swiftwasm/swiftwasm-action というアクションが用意されているので、手軽にCIでビルドやテストを実行させることができます。

ということで、Swift製のライブラリをお持ちの方は一度SwiftWasm対応を試してみてはいかがでしょうか。

現代ではSwiftの条件コンパイル用のフラグ定義にはOTHER_SWIFT_FLAGSではなくSWIFT_ACTIVE_COMPILATION_CONDITIONSを使う

タイトルがすべてです。意外と忘れがちなので。

developer.apple.com

Active Compilation Conditions is a new build setting for passing conditional compilation flags to the Swift compiler. Each element of the value of this setting passes to swiftc prefixed with -D, in the same way that elements of Preprocessor Macros pass to clang with the same prefix. (22457329)