ikeh1024のブログ

ZennやQiitaに書くにはちょっと小粒なネタをこちらに書いています

Xcodeのアップデートが進行しているかどうかを確認する方法

概要

  • Xcodeのアップデートがいつまで経っても終わらない、ということが偶によくある。
  • しかし下記を見ても表示がざっくりとしていて、進捗があるかどうか分からない…

image

image

  • 具体的に進捗は何%なのかと知りたい…!

アップデートの進捗を確認する方法

  • コンソールを開き、右上にApp Storeと入力し絞り込む
  • メッセージのCompleted: xxx of 1000で進捗が確認できる

ScreenShot_2021-11-01_16_37_20

  • 数字が進んでいれば、進捗があることが確認できる

ScreenShot_2021-11-01_16_37_26

  • 800/1000から進みが遅くなり、そこから5時間ほどかかった…。
  • 一見止まっているのではと思ってしまうので、数字で進捗が見れるとまだ放置していいと分かり精神衛生上良い。

参考

「The DevOpsハンドブック 理論・原則・実践のすべて」の感想

本書の感想まとめ

  • DevOpsで検索しても概念的なところの説明だけで、イメージが全く掴めなかったが、本書を通してやるべき事柄の大枠が見えるようになった(気がする状態なので、あくまで実践しないと効果なさそう)
  • DevOpsとは現代のIT開発の仕事の進め方の基礎になっていて、導入することで利益だけでなく開発者の質・セキュリティレベル・プロダクトの改善率など総合的に向上させることができる
  • またDevOpsは単にツールを導入するだけで達成されるものではなく、タスクの進め方や組織のあり方など地に足をつけた改善も必要
  • 正直ツール類や横文字の分からない用語・馴染みのないデプロイライン周りの話があり、中盤から目が滑りがちになった…。
    • こちらの理解には具体的な実践を必要と感じた

目次:The DevOpsハンドブック 理論・原則・実践のすべて

序章 DevとOpsがDevOpsになる世界を想像してみよう

  • あらゆる人の時間を貴重なもの(資産)として捉える
  • DevOpsによって実現できること
    • コードのデプロイ数
    • デプロイリードタイムの短縮
    • 本番デプロイの成功率
    • 問題時の復元にかかる時間の短縮
    • 生産性・利益率の目標の達成率
  • デベロッパが増えると生産性は普通は下がるが、DevOpsにより容易にデプロイできる環境では線形に増える

第1部 3つの道

  • 習慣として業務改善を実践する構造を作り出さないといけない

第1章 アジャイル、継続的デリバリー、そして3つの道

  • 🐱

第2章 第1の道:フローの原則

  • 制約条件の改善
    • 個人で環境作成できるorいつでも使える環境がある状態にする
    • テストの自動化・並列実行
    • アーキテクチャ疎結合にして安全に変更できるようにする
  • 継続的な学習により、日々の業務から苦痛と重労働を取り除く
    • 余分な処理: 顧客のために付加価値を産まないプロセス

第3章 第2の道:フィードバックの原則

  • 問題解決はコードの修正からなるべく早いほうが良い、デベロッパが反省しやすくなる。素早いフィードバックが大事。
    • テストの自動化
    • リアルタイムの問題発見

第4章 第3の道:継続的な学習と実験の原則

  • 改善したいが無関心という厚い壁がある
    • 日業業務の一部として新しい改善を行う→そういう文化が必要
  • ヒューマンエラーを追求しない
    • ミスは研究、調査のきっかけ
    • 再発防止のためにシステムをどのように作り直すかを追求する
  • インシデント発生→非難のない事後検証をするといい
  • 「日業業務よりも大切なのは、日常業務の改善だ」
    • 以前よりも弱い兆候から問題を見つけ出し、修正できるようになる
  • リーダーとワーカーの協業が必要
    • リーダー: チームが業務内で改善を見つけ出してくる環境をつくる
    • ワーカー: 自身の作業分野で問題を見つける。権限がないのでリーダーに共有して実行してもらう。

第2部 スタートのための糸口

第5章 最初に手を付けるバリューストリームの選択方法

  • グリーンフィールド: 新規アプリケーションの開発環境
  • ブラウンフィールド: 既存アプリケーションの開発環境
  • DevOpsの改善ストーリーの60%はブラウンフィールド
  • 最初の導入時期は小さいグループで早期の成功を目指す

第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる

  • バリューストリーム: 改善に必要な項目を洗い出す
  • 改善が必要な作業を一人で把握している人はいないので、全てのメンバーを明らかにして情報をまとめる
    • 他のチーム等の待機が必要な場所
    • 大量の手戻りが生まれる所
  • 明確な改善の目標をたてる
    • e.g. コードのチェックインから本番リリースまでのリードタイムを1週間以下にする
  • 改善のイテレーションは2-4週間で
  • 20%を開発・運用サイクルの改善にあてる
    • 顧客からは見えないポジティブな価値
    • 技術的負債を増やさないために
    • いわば20%税
  • 技術的負債を改善するとリードタイムと品質が劇的に改善される

第7章 Conwayの法則を念頭に置いた組織とアーキテクチャの設計

  • Conwayの法則: 「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」
  • 職務指向(専門分業)
    • 開発チームの増大・デプロイの回数が増えると結果が振るわなくなる
  • 市場指向
    • 毒力で安全に仕事を進められる小さなチームを編成
    • DevOpsの成果が得られる
  • 職務指向でも、部門間の連携がスムーズに協力できていればいい結果が残せる
  • 全てのメンバーがジェネラリストになることを推奨する
  • ポジティブな破壊(既存の障害を排除)できる人材が良い
  • Conwayの法則に従って、チームを小さく保つ
    • two-pizza rule: ピザ2枚で満足できるチーム人数。5-10人

第8章 開発の日常業務に運用を統合してすばらしい成果を生み出す方法

  • 市場指向の成果を生み出すには…
    • 生産性の上げるツールの標準化をする
      • チームが異動しても高い生産性を保つ
    • 製品チームに運用エンジニアを配置する
      • 運用の知識・専門能力をチームに広げる
      • 知識を自動化コードという知見で残せる利点
  • 運用な製品のバリューストリームの一部、大切にする

第3部 第1の道:フロー改善の技術的実践

第9章 デプロイパイプラインの基礎の構築

  • 本番と同じ環境は自動的に作成できないといけない
    • Git管理されているものを基礎として完全な本番環境を再現するのが目標
  • 全ての成果物をGit管理する
    • コードよりも環境設定が変わることのほうが何桁分も多い
    • 運用・QAに渡って全てのメンバーが使用する
  • 本番環境の手作業の修正を許さない
    • ゼロから新しく作り直す意外の方法を許さない
    • 本番環境に差異が生まれることが無くなる
  • 完成の定義を変える: 本番に近い環境で実証された段階で初めて完成とする

第10章 高速で信頼性の高い自動テストの実現

  • テストがないとき
    • 恐怖で変更を加えるのをやめてしまう
  • ユニットテストで大半のエラーを検知したい
    • ただ我々はマニュアルテストやインテグレーションテストに重点を起きがち
  • テストが書きにくい場合は、アーキテクチャが密結合の可能性がある。疎結合なシステムを作りたい。
  • パフェーマンスの低下を防ぐため、パフォーマンスのテストを追加する
  • 非機能要件のテスト
    • 環境が正しく構成されているか

第11章 継続的インテグレーションの実現と実践

  • テスト自動化がないと新機能の開発に使える時間が無くなってしまう
  • 以下に開発者が優秀であろうと、CI/CDがなければ生産性を上げるのは難しい
  • Selenium回帰テストのツール例として挙げられる
  • CIによりある程度安全に変更を加えられるようにしたい
  • トランクベースなGit運用を行う
    • Git-Flowで充分だろうか
  • CIはとてつもなくメリットが高いことを知ろう

第12章 自動化とローリスクリリースの実現

  • 機能変更をより多く加えたければ、デプロイを増やす必要がある
  • CIによりコードデプロイのリスクと作業工数を少なくする
  • 自動化には、デプロイプロセスのステップを"完全にドキュメント化"する必要がある
    • バリューストリームマッピングの実施や更新されるドキュメント(wiki)を使う
  • ドキュメント化のあとはプロセスの単純化・自動化を図るだけ
  • ダークローンチ(機能のトグル)という手法も有効

    https://www.infoq.com/jp/news/2021/08/dark-launches-best-practices/ ダークローンチとは、新しい能力や機能を公的に発表する前に、システムに対する付加的ロードやパフォーマンス上の影響を測定するという、デプロイメント戦略のひとつで、一般的にエンドユーザが感知することはない。

第13章 ローリスクリリースのアーキテクチャ

  • 絞め殺しアプリケーションパターン(strangler application)が、既存アーキテクチャの改善に有効

第4部 第2の道:フィードバックの技術的実践

第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す

  • 一人の人間でシステム全体を理解することは無理
  • 遠隔測定データを継続的に生成するシステムを作る
    • 問題がどこにあるかすぐに発見・対処できる
    • パフェーマンスの低下も改善できる
    • 全体の健全性を確かめることができる
    • 組織全体で簡単に見れるようにする
    • 致命的な障害を起こす前に兆候にきづける
  • ものの追跡を簡単にする
  • 共通サービスに全てのログを送って一元管理するのが望ましい
  • 作成、運用するアプリではすべての機能を測定すべき
  • 同様にビジネス指標のグラフも取ると良い
    • 問題の

第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす

  • データ分析に、外れ値検出や標準偏差を使うことができる
  • 正規分布に従わないカイ二乗分布の場合も、FFTや線形回帰で対応できる
    • スパイク値とかでもいい感じに処理できるよ、くらいの理解…
  • KS検定により一見抽出しにくいような異常値も検知できる

第16章 フィードバックループを実現して開発と運用が安全にコードをデプロイできるようにする

  • 遠隔測定の仕組みにより、問題を早期に発見できる
  • ステージングでエラーを捕捉するのが理想だが、どうしてもできない部分もあるので遠隔測定でカバー
  • 遠隔測定に関するリリース定義をしておくと良い

第17章 日常業務に仮説駆動開発とA/Bテストを組み込む

  • 長期間開発しながら望ましい成果が得られたかどうかを確認しないことが多い
  • A/Bテストしよう
  • ユーザリサーチをしない場合、1/3の機能しか指標が向上しない
  • A/Bテストを反復的に実施するには、遠隔測定の整備が必要
    • 機能トグル
  • A/Bテストを頻繁に実施しフィードバックのサイクルを早める
    • 価値のある改善案が早く見つかる、その結果デプロイの回数を増やすことができる

第18章 レビューと調整プロセスによって現在の仕事の品質を上げる

  • GitHub FlowによるPRのススメ
  • コードレビューのススメ
  • ペアを組んだ場合仕事のペースが15%下がるが、エラーフリーコードは70->85%に上がる
  • ペアプログラミングは楽しい、教え/教えられる効果的な方法でもある
    • コードレビューのつなぎの方法としても有効

第5部 第3の道:継続的な学習と実験の技術的実践

第19章 日常業務での学習の実現と日常業務への学習の注入

  • ヒューマンエラーは間違いの原因ではなく、必然的な結果
    • システムでの対策が必要
  • 反省の場では「だったはず」「できたはず」を明確に禁止する
  • ポストモーテムのドキュメントは共有の場にドキュメントを残しておく
    • 似た事例のときにそれが読まれ研究される
    • ドキュメントの作成を簡単にすることで、内容に注力できより細かい記録がされる
  • 失敗は下図ではない。変更の頻度が30倍にし失敗の割合を半分に押さえることが優秀
  • 本番環境で環境を壊すテストを行い、見えていなかった問題をあぶり出す
    • 日常的に避難訓練をして、障害が日常的なものにしてしまう

第20章 一部門の発見を全社的な進歩につなげる

  • チャットにBotをいれると、業務の軌跡になり共有するために効果がある
    • 全社的に情報共有することができる
    • チャットが給湯室になる
  • 組織で共有するリポジトリを作る
    • 全社員の専門能力を活用できる価値
  • テストスイートが、システムの生きた最新の仕様書になる
    • システムの使い方を知りたい場合は、テストスイートの中で生きた事例を見つけられる

第21章 組織的な学習と改善を生み出すための時間を確保する

  • 強制的に、日常業務の改善をするだけの時間をとる
    • 期間を決めて、終わりには取り組んだ問題を発表してて議論する
    • そうして日常的に改善する文化を作る
  • 社内で同僚に教えたり、改善専門のチームを作っても良い
  • 日常業務の中で全員が互いに教え合い、学びあう

第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践

  • セキュリティ管理に関しても日常業務に組み込む

第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける

  • 開発・運用・情報セキュリティ人数の比率は100:10:1
  • 開発と運用の日常業務に、自動化された状態でセキュリティが組み込まれる必要がある
  • 共有リポジトリに、情報セキュリティが推薦したライブラリ・サービスを加える
    • 間接的に情報セキュリティのガイダンスを使うことになる
  • 開発と運用にセキュリティのトレーニングを提供するのも良い
  • 情報セキュリティが、開発が作ったもののレビューをしてもいい
  • デプロイライン・自動テストにセキュリティに関するものを含める
  • コードの静的テスト、パフォーマンスなどの動的テスト
  • 情報セキュリテイの目的でも、遠隔測定のデータを集めると良い
  • 実際にサービスが攻撃をうけているのを見ると、デベロッパのセキュリテイの意識が劇的に上がる
  • CI/CD自体のセキュリティを担保する
    • テストに関してもコードレビューをする

第23章 デプロイパイプラインを防御する

  • 自動テストや本番環境のモニタリングにより、マニュアルの変更承認プロセスを必ず通さなくても良いようになる
  • 承認組織に説明の書類、RFCのためのフォームを用意する
  • 承認を省略するため、CABに変更がローリスクであることを説明する
    • 特定の期間で履歴をみて起きた問題をリストアップして、それをもとに説明をする
    • 履歴は結果が自動的に記録されるようにしたい
  • Gitのコミットのコメントに、課題のチケット番号を書き込むと履歴を追いやすくて良い

行動提起:DevOpsハンドブックの締めくくりに

  • DevOps改革によって…
    • 学習するダイナミックな組織を生む
    • フローの速さ・高セキュリティを達成
    • 競争力とシャインの満足感が上がる仕組み
  • 実現には各部門の連携が必要
  • DevOpsはITの仕事のあり方・企業としての必須事項になっている

GitHubのSSH接続設定

追記(2023-11-15)

概要

  • 下記の通りはよ対応しろと言われたのでSSH接続の設定を行った
Hi @xxx,

You recently used a password to access the repository at (unknown) with git using git/2.30.1 (Apple Git-130).

Basic authentication using a password to Git is deprecated and will soon no longer work. Visit https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
Permission denied (publickey). fatal: Could not read from remote repository.

ssh-add -K ~/.ssh/id_ed25519

ssh-add -K ~/.ssh/id_ed25519

py2app触ってみた

概要

  • PythonMacアプリを作るためのモジュール
  • ひとまず動かせるところまで確認。個人ツール用途までならあり。

-w250

  • ソースがそのままリソースに同梱されるので非公開にしたい内容がある場合はNG

感想

  • インストールまでちょっと手間取った。
  • Cocoaのブリッジ部の書き方、またpy2appで学習コストは別途かかりそう。
    • Objective-Cを知らずにいきなりPyObjCなんてもっと辛いかも…。
    • VSCodeの補完が効かない?ので辛い。
    • 情報も乏しいので辛そう
  • やっぱりネイティブは良いですね(ポジショントーク

作業メモ

Python: libpython3.5.dylib not found?

Python env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.8.0

  • Pythonのバージョンが新しすぎると怪しい?

Release history¶
269: Py2app didn’t work with Python 3.8

  • またpythonの削除やpip uninstallアンインストールをごにょごにょしていったらエラーは解消した。

課題

2021-01-21 iOSエンジニアカジュアル雑談会

iOSエンジニアカジュアル雑談会 - クラシルTechTalk

どのような人材がほしいか

  • プロダクトの使いやすさだったり情熱を追求できるひと
  • プロダクトにコミットできる人
  • チームに馴染むか
  • チームの生産性を下げないか
  • 新しい技術を学んで、チームに新しい風もちこんでイケる人

複数のGitアカウントの切り替えがうまくいかなかったときの対処

  • 下記を見ながらGit設定の見直しと確認
  • KeyChainで不要なアカウント情報の削除
  • SourceTreeの不要なアカウントの削除(いらなかったかも)
  • SourceTreeの下記を削除

-w681

動画視聴: 「UDフォントをもっと知ろう!」筆順フォントを使ってみよう

動画

メモ

  • TypeAとTypeBがある

  • 複数レイヤーの組み合わせで下記のような教材が作成できる

  • E,Jはそれぞれ英単語の通り

実際に使ってみる

-w1427

  • 辞書の中身を見て察するに、使わない文字に筆順フォントのグリフを当てはめている

まとめ

  • 筆順フォントは、フォントの仕様をうまく転用して作られていると感じた(というふわっとした感想です)

Macのクラッシュレポートを読むときのヒント

Crashed Thread:        0  Dispatch queue: CompilerConnectionSerialQueue
Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

The Swift runtime uses trace traps for specific types of unrecoverable errors—see Addressing Crashes from Swift Runtime Errors for information on those errors. Some lower-level libraries, such as Dispatch, trap the process with this exception upon encountering an unrecoverable error, and log additional information about the error in the Additional Diagnostic Information section of the crash report.

ということなんだな〜という流れ。 (とはいえ詳細にクラッシュレポートを見ても分からないことも多いのではと思っている。)

MySQL環境構築の忘備録

mysql -u root -p test_db < xxx.sql 
Enter password: 
ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci'
# (1) アンインストール
$ brew uninstall mysql

# (2) mysqlの実体ファイルを削除 (DB消えるため、必要に応じてバックアップ)
$ sudo rm -rf /usr/local/mysql*

# (3) 再インストール
$ brew install mysql
  • しかし再インストールしてもバージョンが変わらず。
<user_name>@<PC名> ~ % mysql --version

mysql  Ver 14.14 Distrib 5.7.32, for osx10.15 (x86_64) using  EditLine wrapper

-w674

  • やっとSQLのバージョンが更新された!
<user_name>@<PC名> ~ % mysql --version
mysql  Ver 8.0.22 for osx10.15 on x86_64 (Homebrew)
  • ただし/usr/local/var周りのエラー
  • 再インストールを行いなんとか動く状態になった。
<user_name>@<PC名> ~ % mysql.server start
Starting MySQL
./usr/local/Cellar/mysql/8.0.22_1/bin/mysqld_safe: line 653: /usr/local/var/mysql/<PC名>.local.err: No such file or directory
Logging to '/usr/local/var/mysql/<PC名>.local.err'.
/usr/local/Cellar/mysql/8.0.22_1/bin/mysqld_safe: line 144: /usr/local/var/mysql/<PC名>.local.err: No such file or directory
/usr/local/Cellar/mysql/8.0.22_1/bin/mysqld_safe: line 199: /usr/local/var/mysql/<PC名>.local.err: No such file or directory
/usr/local/Cellar/mysql/8.0.22_1/bin/mysqld_safe: line 916: /usr/local/var/mysql/<PC名>.local.err: No such file or directory
pp/usr/local/Cellar/mysql/8.0.22_1/bin/mysqld_safe: line 144: /usr/local/var/mysql/<PC名>.local.err: No such file or directory
 ERROR! The server quit without updating PID file (/usr/local/var/mysql/<PC名>.local.pid).
<user_name>@<PC名> ~ % 

後日

(メモ)Android Office Hours #2 Androidエンジニアのキャリアパスについて

Android Office Hours #2 Androidエンジニアのキャリアパスについて

31:20​ androidって潰しが効かなそうって言われることがありますがどう思いますか?

  • Android歴は10年選手が多い
    • 視聴者には1~3年目も多い
  • 色々わからないこともある。キャリアに再現性もない。
  • 話を真に受けず自分なりに解釈をするのが良いですよとのこと。
  • 就職理由: 人に依存する(好きな人がいるとか)・ライフスタイル・キャリアに合わせて
  • Androidの潰しがきかない問題。
    • 概念や考え方か、設計やテストは言語に関わらないので問題ない。
    • 不安なら支流でiOSやサーバサイドを触ってみて、同じだなあという感触をつかめばいい。
    • 不安で何もしないというのが一番良くない。触ってみると良いよ。

39:45​ Q. Manager職って経験したほうが良いと思いますか?

  • マネージャー職って?
    • 人による
    • 世話好きな人・給料上げたい人
    • プログラム書いていたほうが楽ではある
    • 向いていない人は辛いだけなのでやめたほうが良い。

44:36​ Q.業務上で課題に感じていることって何かありますか?

  • Androidの辛い所
    • 古いコード・地層を保守しないといけない
    • 当時の思想とか…
  • Androidエンジニアの数はやっぱり少ない
    • iOSDCの数と比べると…
    • 参加者的には2割ほど増えてるけど
    • 両方書ける人は表に出てきてないだけかも

49:30​ これからどう生きるか、今後のキャリアについて。何歳まで働きたい?個人開発してる?副業は?

  • なるべく働かないようにしたい。
    • 一発当てる。個人開発してる。
    • 77億人中の7700万人に使われる、グローバルで使ってもらうものを作りたい。カナダに行きたい。
    • 一方福岡に戻って働きたい意見も。
    • 個人開発や歳を取ると指摘されなくなる。今は会社で優秀な人に揉まれたい。
    • (inメルカリ)会社の半数が外国人で割と使うけど100%のコミュ力は発揮できない、2年ほど英語の勉強をしている。

59:15​ 転職するなら大事だと考えているポイントはなんですか?

  • 年収・優秀な人と働いて学んで成長したい
  • 基本ステップアップにならないものじゃないときつい。今の自分に必要なもの、が得られるもの。能力や実績やら。ネガティブよりはポジティブな理由が良い。

Teams会議で接続状態が悪くなった場合はキャッシュを削除

  • Teams会議で音声がブツブツ途切れるなどの調子が悪い。こういうときは下記の通りキャッシュ削除をすれば改善した覚えがある。

Teams - High CPU Usage and Crashing on macos Catalina

Close Teams Navigate to following folders and delete them. ~/Library/Caches/com.microsoft.teams ~/Library/Caches/com.microsoft.teams.shipit ~/Library/Application Support/Microsoft/Teams Restart Teams

Qiita: エンジニアの劣等感との付き合い方

エンジニアの劣等感との付き合い方

発表するのが怖い

しかし、その恐怖に耐えながら登壇してみると、意外にウケが良かったりするものです。 知識が初心者レベルの人は、初心者レベルの視点での発表ができることが「強み」なのです。

  • これは実際に自分でやってみないと怖さは取れ無さそう。

自分の強みが何なのかわからない

自分の人生をふりかえってみると、個人でアプリ開発している時間が、何よりも楽しいのです。 「楽しさ」というのは、最強の強みになります。 「楽しい」というだけで、勝手に作業がはかどり、知識が付き、気がついたらその道のプロに到達しています。

  • 目の前の問題をスラスラ解けて、振り返ったときにいい結果が積み重なっているのを見ると、充足感があって好き。
  • アプリ開発でレビューがもらえると嬉しい。
  • 学問を実践できれば、正しい道のように思える。

新人エンジニア時代は、劣等感で心が折れやすい

「最近、技術に対する興味がないんです。プログラムの勉強するのがイヤになっちゃいました。このままでも給料もらえているから、まぁいいかと我慢する日々です。でも、このままでいいでしょうか?」

自分の人生のコントロール権を取り戻す。 「楽しさ」ドリブンで、勉強をしていると、自分の人生のコントロール権を取り戻すことができます。

  • 義務感だけだと長続きしない。

UICollectionViewを触ってみる

UICollectionView Tutorial: Getting Started

OverView

  • この記事では基本的な実装のみ

GitHub

Supplement

a collection view is a UIScrollView subclass.

-w430

  • チュートリアルEstimate SizeNoneにする、が抜けているので補足しておくこと。

-w1290

UICollectionView Tutorial: Reusable Views, Selection and Reordering

OverView

  • ちょっと発展的な内容
  • 選択とかドラッグ・アンド・ドロップとか

GitHub

Supplement

you’ll use UICollectionReusableView.

This class is similar to UICollectionViewCell, except it usually displays headers and footers.

  • Tips: Command-Shift-LでStoryboardにおいてライブラリを表示できる

Fontsフォルダをエクスプローラでプレーンな状態で表示する(Windows)

C:\WINDOWS\system32>cd C:\Windows\Fonts

C:\Windows\Fonts>dir *.ini
 2019/03/19  13:49                65 desktop.ini
               1 個のファイル                  65 バイト
               0 個のディレクトリ  1,702,299,574,272 バイトの空き領域

C:\Windows\Fonts>REN desktop.ini _desktop.ini
2019/03/19  13:49                65 _desktop.ini
               1 個のファイル                  65 バイト
               0 個のディレクトリ  1,702,299,545,600 バイトの空き領域