koogawa blog

iOS、Android、foursquareに関する話題

「1人でアプリを作る人を支えるSwiftUI開発レシピ」を読んだ

1人でアプリを作る人を支えるSwiftUI開発レシピ (技術の泉シリーズ(NextPublishing))

1人でアプリを作る人を支えるSwiftUI開発レシピ (技術の泉シリーズ(NextPublishing))

  • 作者:佐藤 剛士
  • 発売日: 2020/11/20
  • メディア: オンデマンド (ペーパーバック)

tl;dr

良い本でした。迷ったらポチることをオススメします

読者(ワシ)のスペック

購入したきっかけ

なんとなく雰囲気で SwiftUI 使ってるけど、基礎的なこととか抜け落ちてる知識があるのではないか?という不安があった。実際、次のような知識が抜け落ちていた。

  • layoutPriority
  • Mid座標
  • Text の fixedSize, kerning 等
  • iOS 14 から登場したもの
    • LazyVStack, LazyHStack
    • LazyVGrid, LazyHGrid
    • TextEditor
    • ProgressView
    • Link
    • Label
    • Map

(各項目の内容まで書いてしまうとネタバレになるので、詳しくは買って読んでみることをおすすめする)

完全な初心者向けの書籍ではなさそう

例えば「プロトコル」「クロージャ」等は知っている前提で話が進むので、Swiftの基本的な知識を学んでから読んだほうが良さそう。余裕があれば Apple公式チュートリアルも軽く流しておくと理解が深まる。

最新の iOS 14 Widget にも対応

iOS 14 で新登場した「ウィジェット」の作り方についても解説されている。タイムラインの概念など、公式ドキュメントを読んだだけでは理解しにくい概念についても丁寧に解説されている。

まとめ

まとめると、本書籍は次の方におすすめである。

  • Swift 言語はある程度わかる
  • SwiftUI を体系的に学びたい・学び直したい
  • SwiftUI における iOS 13 -> 14 のアップデートを知りたい

50代以上エンジニアのキャリアストーリー #over50 〜将来のエンジニアライフを考える〜 に参加した

findy.connpass.com

非常に気になるタイトルのイベントがあったので参加してみました。

第1部の50代エンジニアの皆さんによるパネルディスカッションで、特に印象に残ったお話をメモしておきます。


歳を取るにつれてプログラミングの物覚えが悪くなったりとかありますか?脳のスタックは浅くなりますか?

  • 体の柔軟性と一緒で、意識的に動かさないとどんどん錆びついていく
  • 脳のスタックが浅くなったというより、広くなってる
  • 経験値が増えただけなのかもしれない

エンジニアとして苦労してることは?

  • 面白い、かつ、役に立つ、かつ、対価をいただける「仕事」を見つけるのが大変
  • お金のことだけ考えると面白くないし、面白いだけじゃ食っていけないし
  • もしかすると重要なのは「仕事」じゃなくて「人」なのかもしれない
  • たまに化け物みたいな人がいる。そんな人と一緒に仕事ができると色々吸収できて本当に面白い

技術習得にかけられる時間や習得効率が年々下がっている気がします。エンジニアでいつづけるために技術習得で工夫している点があれば教えて下さい

  • 習得効率はむしろ年々上がっている。
  • やっぱり経験値が活かせるし、効率のよい取捨選択が自ずとできるようになってくる
  • コンピュータの基礎的なところ(ビット演算とかメモリ管理とか)はわかっていたほうが良い
    • 例えばDockerを理解するときとか「プロセス管理の発展型なんだな」みたいに繋がってくる。
  • 逆に流行ってるものを次から次へと追っていくのはあまり効率よくない。賞味期限が短すぎる

急がば回れ

これからチャレンジしたい事は?

  • これからもプログラムはやっていきたい。
  • 若い人がやったらあっという間にできちゃうものより、経験値があるからこそできる難しい設計とかやってみたい

今も毎日勉強されてますか?

  • 年を取ると朝普通に起きられる
  • なので、朝起きて勉強してる

イベント中のツイートを Togetter にまとめたので、そちらを見てもらえれば全体の雰囲気が掴めると思います。

自分より年上のエンジニアの話を聞ける機会はなかなかないので、今回のイベントはとても貴重でした。登壇の皆さま、運営の皆さま、ありがとうございました🙏

2020年を振り返る

f:id:koogawa:20201218222228p:plain
堀切峠

今年はなんかあっという間でしたな。2020年を忘れないよう、この一年を振り返ってみたいと思います。

仕事

  • 今年はフロントエンド中心で、Vue/Nuxt をメインに使ってました。Nuxt が食べ物だと思っていた頃と比べると、この1年でだいぶ詳しくなったと思います。
  • 合間に SwiftUI でウィジェットも作りました。SwiftUIを実戦で使うのは初でした。いろいろと知見を得たので、興味のある方は下記記事をご覧ください。

note.com

個人開発

  • Githubitter という、GitHubにcommitした回数を毎日ツイートしてくれるサービスを公開しました。自分用に使っていたものを一般にもリリースした感じです。良かったら使ってみてください。

  • 真実の鏡」というmacOSアプリもリリースしました。通常、Zoom 等で見る自分の映像は左右が逆になっているのですが、このアプリは、実際に周りから見えている「本当の顔」を映し出すアプリです。macOSアプリの開発は初だったので、知見を下記記事にまとめました。

koogawa.hateblo.jp

  • Marimosoft(個人事業主の屋号)として、宮崎市内の企業様向けに、SwiftUI を使ったiPhoneアプリ開発講座を開催しました。ARKit アプリのデモがとても楽しかった!

プライベート

  • 今まではコワーキングスペースのオープンスペースで作業することが多かったのですが、コロナ禍もあり、思い切って仕事用の個室を契約しました。外付けディスプレイを設置したり、その場でテレビ会議をできるのが便利です。トミカも置き放題。料金は高くなりましたが、それだけの価値はあると感じています。

f:id:koogawa:20201218222931p:plain
作業机のトミカタワー

  • 今年はいくつかのメディアからインタビューを受けました。取材頂いたメディアの皆様ありがとうございました!

magazine.fluct.jp

and-engineer.com

  • 緊急事態宣言時に思い切って電子ドラムを購入しました。1曲演奏するだけで、良い運動になります。

来年

アラフォーということもあり、そろそろ本気で健康にも気を遣っていきたいと思います。

実は未だに高校時代に買った 3,980 円ぐらいの椅子を使っているので、いい加減、腰に優しいビジネスチェアに買い換えたいと思います。

それでは良いお年を!!

はてなブログ 独自ドメインを解除したときのメモ

前提

独自ドメイン koogawa.com を"さくらインターネット"で取得済み

やりたかったこと

独自ドメイン blog.koogawa.com をやめて、 koogawa.hateblo.jp に戻したかった。

例)

旧:http://blog.koogawa.com/entry/2020/10/03/230000

新:https://koogawa.hateblo.jp/entry/2019/02/01/113000

  • ドメインにアクセスが来たら新ドメインにリダイレクト(301)したい
  • URLが変わってしまうため、ブックマークもリセットされてしまう。これも統合したい

やったこと

ゾーン設定

独自ドメインを設定するときに追加した CNAMEレコードを削除。

↑つまり、これと逆のことをやる!

さくらのコントロールパネルからサブドメイン追加

ドメイン/SSL からサブドメイン blog.koogawa.com を追加して SSL(Let's Encrypt)対応。

f:id:koogawa:20201021091751p:plain

.htaccess 設定

blog.koogawa.com にアクセスが来たら koogawa.hateblo.jp にリダイレクトかける。

RewriteEngine On
RewriteCond %{http_host} ^blog.koogawa.com
RewriteRule ^(.*) https://koogawa.hateblo.jp/$1 [R=301,L]

はてなブックマーク統合

この方法で統合できた。

反映されるまでに長い時間がかかることがある、とのこと(実際まったく反映されなかった)。すぐに統合したい場合は「情報を更新する」を、記事ごとに実行する必要がある。

できなかったこと

はてなスターの引き継ぎはできなかった・・!すべてリセットされてしまった

個人ブログとQiitaとZennの使い分け

数年前にこんな記事を書いたのですが、最近 Zenn という新サービスが話題になっているので、改めてそれぞれの特徴を比較した上で、使い分けを整理していきます。

それぞれの特徴

個人ブログ

  • 技術以外の記事でも、なんでも自由にかける
  • デザインのカスタマイズが自由
  • ドメインも好きなものに設定できる
  • ブログサービスによっては公式アカウントがピックアップしてくれることも(はてなブログ、note 等)
  • 有名ブロガーでない限り、まったく読まれないこともある

Qiita

  • 「プログラミングに関する知識を記録・共有するためのサービス」であり*1、ポエムを書くと怒られたりする
  • LGTM機能がある
  • ストック機能もある
  • 記事に対するコメントができる
  • ユーザー、タグをフォローし、フィードに流すことが可能
  • 自分が獲得した総LGTM数が Contributions としてプロフィール画面に表示される
  • 自分が書いた記事を修正するとき、ストックしてくれたユーザに通知を送ることができる
  • Organizations 機能があり、ユーザーは複数の組織に属することが可能
  • SEOが強い💪
  • 新着記事が各タグのフィードに流れるので、誰が書いた記事でも、ある程度は読んでもらえる
  • 1日/週間/月間 単位で、人気の記事がトレンドページに表示される
  • LGTMが増えるとTwitter公式アカウントがピックアップしてくれる
  • LGTMが多い記事は週刊メールマガジンにピックアップされる(効果大)

Zenn

  • 「知見を共有するプログラマーに対価を」をコンセプトとした情報共有コミュニティ
  • 著者への 金銭的なサポート機能 がある
  • 本を書いて、無料/有料で公開できる
  • 記事を書く際、Tech(プログラミングに関する技術記事なのか)or Idea(考え方やポエム)を明確に選べる
  • いいね機能がある
  • バッジ機能がある(一日で最も人気のあった技術記事に対して付与される、等)
  • 記事にdiscussion欄があり、ユーザーは自由に投稿できる
  • Qiita のように、自分が獲得した総いいね数はどこにも表示されない
  • GitHubリポジトリとの連携機能がある
  • SEOはQiitaより弱い印象
  • 新着記事が各タグのフィードに流れるので、誰が書いた記事でも、ある程度は読んでもらえる
  • Tech, Idea, Book ごとのトレンド画面、タグごとの話題記事などがある
  • Twitterの公式アカウントが記事をピックアップしてくれることもある

それぞれの特徴を表にまとめてみます。

個人ブログ Qiita Zenn
共有できるもの なんでも自由に書ける プログラミングに関する知識 - プログラミングに関する技術記事
- 本(無料/有料)
- キャリア、チーム、仕事論、ポエムなど
いいね機能 サービスによる LGTM、ストック いいね
コメント機能 サービスによる あり あり
フォロー機能 サービスによる あり なし
グループ機能 サービスによる Organizations なし
ゲーミフィケーション サービスによる ない? バッジ機能
マネタイズ サービスによる ない 金銭的なサポート機能、本の売上
記事ピックアップ サービスによる - トレンド画面
- Twitter公式アカウント
- メールマガジン
- トレンド画面
- Twitter公式アカウント
SEO サービスと、著者の影響力による 強い

使い分け

それぞれの特徴を踏まえ、使い分けを考えてみます。

ブログ

  • 雑な技術メモ
  • 本の感想
  • アプリやイベントの宣伝
  • 技術と関係ないポエム
  • 勉強会レポート
  • 雑多なメモ
  • 入社・退職エントリ
  • 誰かの役に立つ、というより、自分の考えを整理するためのもの

Qiita

  • プログラミングに関わる内容
  • ググってたどりついて欲しい内容
  • 今後もメンテナンスしていく予定があり、その都度、読者に変更内容を通知したい記事
  • 誰かの役に立つことが目的であり、対価は求めない

Zenn

  • 誰かの役に立ち、かつ、対価も得たい
  • 渾身の記事である
  • 本を書きたい、販売したい

そんなわけで、この記事は「個人ブログ」に書いてみました。

「オンライン勉強会あるある」とその改善策

これは何

この記事では私が色々なオンライン勉強会を主催・参加してきて

  • この時間はもっと短縮できるなー
  • このやりとりは本来不要だよな

と感じた所謂「オンライン勉強会あるある」と、その改善策についてまとめていきたいとおもいます。

※主に Zoom を使った勉強会を想定しています


画面共有しようとしたら権限がないと言われて進行が中断する

自分の発表順が回ってきて、いざスライドを画面共有しようとしたら次のようなエラーが出て発表をスタートできないパターンです。

f:id:koogawa:20200613220926p:plain

これはホストが参加者の画面共有を許可していないためです。

回避策:ホストが参加者の画面共有を許可する設定にする

ホストが「画面の共有」ボタン右の^をクリックし、「高度な共有オプション…」を選択します。

f:id:koogawa:20200613221937p:plain

共有できるのは誰ですか?を「全参加者」にします。

f:id:koogawa:20200613235152p:plain

これで参加者も画面共有できるようになります。

画面共有しようとしたら色々アクセス権限を求められて時間かかる

自分の発表順が回ってきて、いざ画面共有しようとしたら次のアラートが出て、「あっ、、ちょっとお待ち下さいね」となってしまうパターンです。けっこう焦るので、このあとの発表にも影響が出かねません。

f:id:koogawa:20200613222445p:plain

回避策1:勉強会開始までに接続確認させてもらう

接続確認の時間を設けている勉強会もありますが、ない場合は自分からお願いしましょう。

回避策2:事前に画面共有の練習をしておく!

Zoomさえインストールしておけば、事前に画面共有をシミュレーションしておくことができます。勉強会開始までにアクセス権限は許可しておきましょう。

画面共有したいスクリーンが見つからない

自分の発表順が回ってきて、いざ画面共有しようとしたら共有したいスクリーンが見つからなくて焦るパターンです。

f:id:koogawa:20200613223541p:plain

とくにデュアルディスプレイ/トリプルディスプレイにしている場合は選択肢が複雑になるため、あたふたしてしまう方が多いようです。また、プレゼンテーションアプリをフルスクリーンにした際に「発表者用画面(経過時間や次のスクリーンが表示される)」がオーディエンスに見えてしまうケースも何度か見ました。

回避策1:事前に画面共有の練習をしておく!

やはり事前に一度練習しておくことが重要です。とくにデュアルディスプレイ/トリプルディスプレイにしている場合は、どのディスプレイがオーディエンス側に配信されるのかチェックしておきましょう。

回避策2:発表中はシングルディスプレイにする

面倒でなければ、発表中は外部ディスプレイを切断し、シングルディスプレイにしてしまうことで上記のリスクが減らせます(自分はけっこうやる)。

発表を終えた人が画面共有したままにしがち

自分の発表順が回ってきて、いざ画面共有しようとしたら前の発表者が画面共有したままになっていて画面共有できないパターンです。「◯◯さん、画面共有を切ってもらっても良いでしょうか・・!」とお願いすれば解決するのですが、ちょこっとだけ気不味さがあるので、なんとか仕組みで解決したいものです。

回避策:複数の参加者が同時に画面共有できるようにする

ホストが「画面の共有」ボタン右の^をクリックし、「複数の参加者が同時に共有可能」にチェックを入れます。

f:id:koogawa:20200613233359p:plain

これで複数の参加者が同時に画面共有できるようになります。

注意点としては、画面共有している人は、共有している自分のパソコンの画面しか見えないという点です。つまり、自分の発表が終わっても画面共有をオフにしない限りは、次の発表者の画面を見ることができません。自分の発表が終わったら画面共有を完了するようにしましょう。

※画面共有の実験は ( @shu223 ) さんに手伝っていただきました🙏 ありがとうございました!