LicensePlist を導入し、アプリで使用している OSS のライセンスを表示する
LicensePlist を使うと
これを試してみる。
セットアップ
Homebrew 経由で LicensePlist をインストールする。
$ brew install mono0926/license-plist/license-plist
プロジェクトにルートに Carfile と Podfile を配置する。
プロジェクトルートで LicensePlist を実行する。
$ license-plist
成功すると com.mono0926.LicensePlist.Output フォルダが生成される。
原理的にはこれを Settings.bundle 直下にコピーすれば
iOS の設定アプリ内で、使用している OSS ライセンスが表示されるようになる。
次に Integrate 継続的に Settings.bundle に LicensePlist の成果物ができるように Xcode の RunScript に以下を追加する。
if [ $CONFIGURATION = "Debug" ]; then /usr/local/bin/license-plist --output-path $PRODUCT_NAME/Settings.bundle fi
これでビルドごとにプロジェクトルートの下の $PRODUCT_NAME フォルダ下の Settings.bundle 内に LicensePlist の成果物ができるようになる。
最後に Settings.bundle 内の Root.plist を下のようにする。これをしないと、設定アプリ内にライセンス一覧の陸ができないことに注意。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PreferenceSpecifiers</key> <array> <dict> <key>Type</key> <string>PSChildPaneSpecifier</string> <key>Title</key> <string>Licenses</string> <key>File</key> <string>com.mono0926.LicensePlist</string> </dict> </array> <key>StringsTable</key> <string>Root</string> </dict> </plist>
結果のスクリーンショット
サンプル
今回試した LicensePlist を使用したサンプルは GitHub にある。
注意点
xxHash v0.7.1 リリース
https://github.com/Cyan4973/xxHash/releases/tag/v0.7.1
2019/8/15 にリリースされた xxHash v0.7.1 についてメモする
リリースノートを見る
このリリースは XXH3 に対しての多くのユーザフィードバックに基づいた大きな更新が入っている。
- アルゴリズム計算に
XXH3_SECRET_SIZE_MIN以上の任意のバイトのsecretを使用できる。 seedはまだ利用可能であり、それはsecretジェネレータとして機能する。- これらの変更の結果、
XXH3の戻り値は v0.7.0 と互換性がないことに注意。 - updated
ARM NEONvariant by @easyaspi314 - ストリーミング実装が利用可能
- @aras-p のヘルプで Visual Studio のパフォーマンスと互換性の向上をした
XXH_INLINE_ALLを使用した場合の改善：namespaceを汚さずにXXH_ASSERT()XXH_ALIGHなどの独自マクロを使用する。- 128-bits 用のハッシュ比較用のヘルパ機能の提供
XXH3 はまだ実験段階であることに注意。安定するまでには、少なくとも２つのリリースの間、安定した状態を維持する必要がある。
そのほか一般的な改善
- @easyaspi314 のおかげで
clangでより良いrotl命令を生成できる - @easyaspi314 により
XXH_REROLLマクロが、バイナリサイズ削減のために追加された cmakeスクリプトの改善 by Mezozoysky/tests/benchで、完全なベンチマークプログラムを提供
気になる点
XXH3はまだ実験段階であり、v0.7.0 と v0.7.1 のハッシュ値には互換性がないXXH3にストリーミングが実装された
HEIC を JPEG に一括変換する
macOS であれば 下のように sips コマンドを使って HEIC -> JPEG 変換ができる
$ sips --setProperty format jpeg PIC.HEIC --out PIC.jpg
ただし、ファイル数が多いと一括で変換したくなるので Python スクリプトを作った。（内部で sipsを使用しているので macOS 専用）
使い方は下のリポジトリを clone してきて
$ git clone https://github.com/daisuke-t-jp/heic2jpg.git
以下のように HEIC があるフォルダを指定して実行。
$ python3 heic2jpg.py <HEIC があるフォルダのパス>
スクリプトが完了すると指定したフォルダの中に jpg フォルダができていて、その中に JPEG ファイルが入っている。
おわり
iOS アプリで「Zip ファイルをダウンロード→Zip 展開→展開されたファイルをアプリ内で使用」までを試す
はじめに
https://daisuke-t-jp.hatenablog.com/entry/2019/08/19/162337 で Zip アーカイブの展開（UnZip）の方法を書いたので、これを発展させて
- Zip をサーバからダウンロード
- アプリ内で Zip を展開
- 展開したデータをアプリで使用
というユースケースを試したので、それについて記録する。
リポジトリ
実際にアプリを実行して試せるプロジェクトは 以下の GitHub リポジトリにある。
このアプリの流れは以下である。
- Download ボタンをタッチする
- GitHub リポジトリにある Zip ファイルをダウンロードする
- SSZipArchive で Zip を展開する
- 展開したフォルダの中にある画像（melon.png, lemon.png）を UIImageView に貼り付け
ポイント
全体的にリポジトリで確認できるが、重要そうなポイントをいくつか抜粋する。
ダウンロードの開始
ファイルのダウンロードは URLSessionDownloadTask で実現した。
ダウンロード開始までの流れは以下になる。
- URLSessionConfiguration でセッション構成を設定する
- キャッシュの扱いやタイムアウト、など色々設定できる
- URLSessionConfiguration を元に URLSession を作成する
- URLSession から URLSessionDownloadTask を取得し、ダウンロードを開始する。
ダウンロード開始後の流れ
- URLSessionDownloadDelegate の urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:)
メソッドでダウンロードの進捗がデリゲートに通知される。
- ??% 完了のような表示に使用できるデータが得られる
- URLSessionDownloadDelegate の urlSession(_:downloadTask:didFinishDownloadingTo:) メソッドでダウンロードの完了がデリゲートに通知される。
- ダウンロード先のパスが引数にくるので、このタイミングでファイルに対しての操作（Zip の展開など）ができる
- URLSessionTaskDelegate の urlSession(_:task:didCompleteWithError:) メソッドでセッションタスクの完了がデリゲートに通知される。
- このタイミングで URLSession の finishTasksAndInvalidate() をコールし、タスクを終了・無効化させる。
URLSession で扱えるプロトコル
おわり
そのほか
- Objective-C だと NSURLSession だが Swift だと NS がなく URLSession であることに気をつけたい
- 時代の流れを感じる
- ちなみにアップロードの場合はこちらを使用する → URLSessionUploadTask
以上
iOS で Zip を展開する
はじめに
ZipArchive ライブラリを使用すると iOS で Zip を展開（圧縮も）できる。 これは macOS も tvOS にも対応している。
ここでは Carthage での導入について書く。
Carthage でのライブラリ導入について基本的なことは https://daisuke-t-jp.hatenablog.com/entry/2019/08/14/123730 に書いてある。
Cartfile を準備する
Cartfile に以下を記載する
github "ZipArchive/ZipArchive"
Carthage でライブラリをインストールする
Cartfile があるディレクトリで carthage update を実行する。
$ carthage update *** Cloning ZipArchive *** Checking out ZipArchive at "v2.2.2" *** xcodebuild output can be found in /var/folders/x7/rtyldl812l3f40rb6bpvx8nc0000gp/T/carthage-xcodebuild.GyPErm.log *** Downloading ZipArchive.framework binary at "v2.2.2"
ZipArchive.framework ができれば成功。
展開する
ZipArchive.framework をプロジェクトにリンクした状態で
import ZipArchive // 展開する // zipPath ... Zip ファイルのパス // toDestination ... 展開した Zip の内容の出力先 SSZipArchive.unzipFileAtPath(zipPath, toDestination: toDestinationPath)
これで展開できるはず。
関連
読む「伽藍とバザール」
基本情報
- 基本情報
- 伽藍（がらん）
- 大聖堂
- 「中央集権的」「閉鎖的」で「荘厳」かつ「慎重に」に少数の卓越したものにより開発される
- バザール
- 市場
- 「はやめにしょっちゅうリリース」「乱交まがいになんでもオープン」「でかい騒がしいバザールに似ている」。市場のように開かれている、誰でも参加可能。
文中の教訓を抜粋
- よいソフトはすべて、開発者の個人的な悩み解決から始まる。
- 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
- 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章）
- まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
- あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
- ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
- はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
- ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
- 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
- ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
- いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
- 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
- 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
- ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
- ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
- 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
- セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
- おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
- 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。
特に重要に感じた部分を引用
はっきり言って、ぼくは リーヌスのいちばん賢い、影響力あるハッキングというのは、Linux のカーネル構築そのものではないと思う。むしろ Linux 開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け 者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。あるいはロバート・ハインラインが自作 の登場人物の一人について書いた有名な表現にならえば、「失敗するには怠惰すぎる」。
そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ（完全な製品レベルの OS カーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね？）。でも、Linux はとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。 リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリング（NeWSとJavaで有名）のような、設計面での革新的天才ではないんだ（少 なくともいまのところは）。むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、A 地点から B 地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。Linux の設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。
じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的 洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。
こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。
Linux は、意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。 Linux 形成期が、World Wide Web の誕生と同時期なのは偶然ではないと思うし、Linux が幼年期を脱したのが 1993-1994 年という、ISP 産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。リーヌスは、拡大するインターネットが可能に した新しいルールにしたがって活動する方法を見いだした、最初の人間だったわけだ。
オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。
