iOS で Zip を展開する

はじめに

ZipArchive ライブラリを使用すると iOS で Zip を展開(圧縮も)できる。 これは macOS も tvOS にも対応している。

ここでは Carthage での導入について書く。

Carthage でのライブラリ導入について基本的なことは Carthage で外部ライブラリを導入する - daisuke-t-jp's blog に書いてある。

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)

これで展開できるはず。

関連

macOS コマンドでインターネット上のファイルをダウンロードする

curl コマンドに O オプションを指定すれば、ファイルダウンロードできる。

curl -O https://tetsugaku.info/images/melon-and-lemon.png

curl コマンドは macOS にデフォルトインストールされているはずなので、気軽に使用できる。

もし、Linux ライクに wget コマンドでファイルダウンロードしたければ Homebrew 経由で wget をインストールする。

$ brew install wget

おわり

読む「伽藍とバザール」

基本情報

  • 基本情報
    • 1999年の出版物。(1997年の公園を書籍化)
    • Linux の開発の成功から OSS についての考察。
    • 従来の「伽藍」方式から見ると、カオスな「バザール」方式の客観的観察。
  • 伽藍(がらん)
    • 大聖堂
    • 「中央集権的」「閉鎖的」で「荘厳」かつ「慎重に」に少数の卓越したものにより開発される
  • バザール
    • 市場
    • 「はやめにしょっちゅうリリース」「乱交まがいになんでもオープン」「でかい騒がしいバザールに似ている」。市場のように開かれている、誰でも参加可能。

文中の教訓を抜粋

  1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。
  2. 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ
  3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから(フレッド・ブルックス『人月の神話』第11章)
  4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
  5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
  6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
  7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
  8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
  9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
  10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
  11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
  12. 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
  13. 「完成」(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
  14. ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
  15. ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと!
  16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
  17. セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
  18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
  19. 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。

特に重要に感じた部分を引用

 はっきり言って、ぼくは リーヌスのいちばん賢い、影響力あるハッキングというのは、Linuxカーネル構築そのものではないと思う。むしろ Linux 開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け 者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。あるいはロバート・ハインラインが自作 の登場人物の一人について書いた有名な表現にならえば、「失敗するには怠惰すぎる」。




 そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ(完全な製品レベルの OS カーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね?)。でも、Linux はとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。 リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリング(NeWSとJavaで有名)のような、設計面での革新的天才ではないんだ(少 なくともいまのところは)。むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、A 地点から B 地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。Linux の設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。


 じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的 洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。


 こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず(まさに毎日のように)進歩している様子だ。




 Linux は、意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。 Linux 形成期が、World Wide Web の誕生と同時期なのは偶然ではないと思うし、Linux が幼年期を脱したのが 1993-1994 年という、ISP 産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。リーヌスは、拡大するインターネットが可能に した新しいルールにしたがって活動する方法を見いだした、最初の人間だったわけだ。




 オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。

GitHub の Issue / Pull Request に使われるラベル

f:id:daisuke-t-jp:20190816103640p:plain スクリーンショットIssues · google/science-journal-ios · GitHub から

GitHub で Issue を見ていて good first issue というのがあり、意味が分からなかった。

調べると GitHub ではIssue / PR に使用できるラベルがデフォルトでいくつか用意されていて

help.github.com

その中を見ると good first issue は・・・

Indicates a good issue for first-time contributors

「はじめての貢献に良い問題です。」

という「プロジェクトへ参加するなら。まずはこれが適しているよ」のラベルだった。
問題解決。

ついでに good first issue も含め、GitHub のデフォルトのラベルを一覧しておく。

Label Description
bug バグ
documentation ドキュメントの改善または、追加が必要
duplicate 重複。同様の項目がある。
enhancement 新しい機能
good first issue はじめての貢献に良い問題
help wanted 手助けが必要。
invalid 無効な項目。関連性がない、事実誤認、など。
question 質問がある。
wontfix 修正しない対象。仕様や動作制限の理由などにより、修正しない。

おわり

SNS に対するネガティヴな意見をまとめる

この記事について

  • SNS に対してのネガティヴな意見を
  • ソースの URL と引用と共に
  • まとめる

著名人

Linus Torvalds(リナス・トーバルズ)

gigazine.net

トーバルズ氏はさらに匿名性が過大評価されているとして、「匿名というのは非常に不快だ。つまらないことを書いたりシェアしたりライクしたりするのは自由だが、そこに本名さえ載せてないならそれは全く無益なことだ」と述べています。さらに内部告発など匿名性が重要になる場があることを認めつつ、「身元の証明ができない匿名の人のSNSでの狂った怒りは見せるべきものではなく、そうした投稿をまた匿名の人がシェアしたりライクしたりできるのは良くない」として匿名でのSNS利用がヘイトの温床になっていることを指摘しています。

SNS 関係者

Chris Wetherell(クリス・ウェゼレル)

www.gizmodo.jp

クリス・ウェザレルは10年前、開発者としてTwitterリツイートボタンを作った。彼は今、自分の仕事を後悔しているという。

 

「弾をこめた銃を4歳児に持たせてしまったのかもしれない」。自身が生み出したツールを使った「暴徒」を最初にTwitter上で目にしたときの思いを、ウェザレルはそう回想する。「自分たちがしたのはつまりそういうことだったんだと思います」

Samidh Chakrabarti(サミ・チャクラバーティ)

  • The Civic Integrity Product Director at Facebook.

www.itmedia.co.jp

 Facebookに対しては、2016年の米大統領選の結果に同サービスでの虚偽ニュースの拡散が大きく影響したという非難が続いており、当初は認めていなかったマーク・ザッカーバーグCEOが謝罪し、後にシェリル・サンドバーグCOO(最高執行責任者)も謝罪した。

 

 チャクラバーティ氏は「2016年、われわれは悪人がFacebookを悪用していることに気づくのがあまりにも遅かった。現在、こうしたリスクを緩和することに懸命に取り組んでいる」と語った。同氏は長文で、虚偽ニュース、(ロシアなどの)他国からの干渉、政治的な嫌がらせ、不平等、エコーチェンバーの問題について語り、「これらの問題はまだ未開拓であり、われわれがすべての解決法を知っていると取り繕うつもりはない。だが、解決に向けて努力していくつもりだ」と説明した。

公的機関

Royal Society for Public Health (RSPH)(英王立公衆衛生協会)

www.bbc.com

RSPHは14歳から24歳の1479人を対象に、人気の高いSNS5社の影響を調査。それぞれのSNSで経験する不安感や鬱(うつ)、孤独感、いじめ、自分の外見への劣等感など14項目について質問した結果、写真投稿サイトのインスタグラムが若者の心に与える不安感や孤独感、いじめ、外見への劣等感など否定的な影響が、他のSNSよりも高かったという。

forbesjapan.com

研究機関

Melissa G. Hunt

japanese.engadget.com

ペンシルバニア大学の心理学者Melissa G. Huntが、SNSと幸福感についての因果関係に関する調査結果を発表しました。それによると、SNSの使用を制限することで孤独感が大幅に減少したとのことです。

Gian Paolo Barbetta(ジャン・パオロ・バルベッタ)

  • イタリア サクロ・クオーレ・カトリック大学経済学部教授

gigazine.net

バルベッタ教授らは2016年から2017年にかけて、イタリアの高校70校に通う約1500名の生徒を対象に、ノーベル文学賞作家ルイージピランデッロの小説「生きていたパスカル(Il fu Mattia Pascal)」を読んでもらいました。生徒たちのうち半分はTwitterを利用して、小説を引用しつつ自分の意見を発信し、他人のツイートに返信でコメントするというオンラインディスカッションを実施。残り半分は、従来通り教室で教えるという形態を取りました。そして最後に、「生きていたパスカル」についての理解を確かめる試験を行いました。  

試験の結果、Twitterを利用していたグループは全体的にマイナスの影響を受けており、テストの平均点が標準偏差の約25~40%分低下。特に成績が優秀な生徒で「女性」「イタリア生まれ」「ベースラインテストの点数が高い」ほど成績低下の傾向が顕著だったそうです。

Carthage で外部ライブラリを導入する

Carthage とは?

日本語の読みは「カルタゴ」でいいかしら。

名前の由来は、現在のチュニジアにかつてあった古代の国家の名前らしい。
GoogleMap でみるとこんな場所。

CocoaPods のように Xcode プロジェクトに手軽に外部ライブラリを取り込めるパッケージマネージャ。

CocoaPods との違い

いろいろあるとは思うが、個人的にこれが Carthage を使う理由であり、メリットかな、と思うのは以下。

  • CocoaPods はライブラリの依存関係の解決にワークスペースファイル(xcworkspace) を使用する
    • プロジェクトファイル(xcodeproj) しか使用しない場合でも、CocoaPods により、 xcworkspace が作られるので、その分煩雑になる。
    • Carthage は xcworkspace を使わずに依存関係を解決するので、上記の問題が起きない
    • こちらの方が直感的。
  • またライブラリ開発者側から見たメリットとしては
    • CocoaPods では CocoaPods へライブラリを登録、更新する作業が必要になるが
    • Carthage は GitHub 上にあるライブラリを直接ユーザが利用できるため
    • ライブラリ開発者が、GitHub で開発しているのならば、ライブラリ登録・更新の作業が CocoaPods に比べて、簡易化されることになる

Carthage を macOS にインストールする

すでに Homebrew がインストールされているならば、 brew でインストールするのが楽。

$ brew install carthage

Cartfile を作る

例として AEXML という XML パースのライブラリを iOS プロジェクトで使う方法をのべる。

Cartfile という名前のファイルをプロジェクトのルートに作り、依存するライブラリをを下のように記述する。

github "tadija/AEXML"

もしくは下でも良い。

git "https://github.com/tadija/AEXML.git"

Carthage で依存ライブラリをビルドする

Cartfile があるディレクトリで carthage コマンドを実行する。

carthage update 

もし、ライブラリの取り込みが成功していたら Carthage/Build フォルダ以下に framework ができている。

Xcode で依存ライブラリをリンクする

  1. Xcode でプロジェクトを開く。
  2. BuildPhase -> Link Binary With Libraries を開き、先ほど作った framework を追加する。
  3. BuildPhase から 新しい Run Script Phase を追加して、以下のスクリプトを追加する。
    • /usr/local/bin/carthage copy-frameworks
    • Input Files に framework のパスを以下のように追加する
      • $(SRCROOT)/Carthage/Build/iOS/AEXML.framework

そのた

Carthage のキャッシュを削除したい場合

rm -rf ~/Library/Caches/org.carthage.CarthageKit

おわり

SwiftLint を導入する

このページは

SwiftLint について、導入する方法と使い方を簡単に記す。

もっと詳しく知りたい場合は SwiftLint のプロジェクトを見るべき。 👇

また SwiftLint を試したサンプルプロジェクトは GitHub にある。👇

SwiftLint とは?

Swift コードのスタイルをチェックするリントツール。

  • Lint(リント)?

    • コーディングルール違反や、冗長な記述など、を検査する
  • ルール違反の項目がある場合

    • ビルド時に警告・エラーなどを発生させることができる。
    • または、リントツールに自動でスタイル修正(コード修正)をさせることも可能。
  • リントツール導入のメリット

    • コードのスタイルを機械的に一定に保てる
    • コードレビューの質向上を計れる(スタイルに関する指摘は有人でする必要がなくなる)

インストール

Homebrew が入っている環境ならば
brew コマンドで install 可能。  

$ brew install swiftlint

ルールファイルを作成する

.swiftlint.yml ファイルにルールを記述する。

記述の仕方とルールは以下を参照する。

以下、.swiftlint.yml の例。

# Lint 対象を指定
included:
    - SwiftLintSample/
# Lint 対象から除外する
excluded:
    - SwiftLintSample/T.swift
# 無効にするルール
disabled_rules:
    - file_length
    - trailing_comma
    - trailing_whitespace
    - trailing_newline
    - vertical_whitespace
    - function_body_length
    - type_body_length
    - line_length
    - vertical_parameter_alignment
# 変数などの名前の最低の長さを指定。これより短いと違反となる
# 1 にしておくと、このルールが実質無効となる
identifier_name:
    min_length: 1
# 型名のルールに対しての excluded(除外)
# ここでは lowerCamelClass という型名はルールの検査から除外される
type_name:
    excluded:
      - lowerCamelClass

Xcode プロジェクトへの導入方法

f:id:daisuke-t-jp:20190813121202p:plain

XcodeBuild Phases に新たな Run Script を追加する。

そして以下のスクリプトを埋め込む。

if which swiftlint >/dev/null; then
swiftlint --config .swiftlint.yml 
else
echo "warning: SwiftLint not installed."
fi

上のスクリプトを説明すると・・・

  • if which で SwiftLint がインストールされているかをチェックする
    • インストールされていない場合、 echo で警告を表示している
  • swiftlint コマンドの --config 引数で ルールファイル (.swiftlint.yml) のパスを指定できる。
    • 指定しなければ、カレントディレクトリにある .swiftlint.yml を参照する

これでビルドするたびに、 SwiftLint によるチェックが実行される。
もし SwiftLint に引っかかると、通常の警告・エラーと同じく Xcode 上に結果が表示される。

リントの運用

.swiftlint.yml で全体のルールを指定できるが、局所的にルールを決めたいときもある。

その場合は、以下の enable/disable で挟むことで、その部分だけルールの無効・有効を切り替えすることができる。

// swiftlint:enable ルール名
// swiftlint:disable ルール名

たとえば、 func のパラメーター数は SwiftLint ではデフォルトで 5個までとされているが、それを超えたパラメーター数をもつ func を居所的に許可したい場合は以下になる。

  // swiftlint:disable function_parameter_count
  static private func tooManyParameterFunc(a: Int,
                                       b: Int,
                                       c: Int,
                                       d: Int,
                                       e: Int,
                                       f: Int,
                                       g: Int) -> Int {
    return a + b + c + d + e + f + g
  }
  // swiftlint:enable function_parameter_count

おわり