CentOS 7(32bit版)のインストールから初期設定
なぜか、CentOS 7なのに32bit版をインストールしたときのメモです。
最終的には実機に入れるんですけど、とりあえず、実験をかねて仮想環境にインストール。Vagrantは使ってません。なぜか。
動作を確認した環境
環境 | 情報 |
---|---|
CentOS | CentOS-7-i386-Minimal-1511.iso |
VirtualBox | VirtualBox-5.1.10-112026-Win.exe |
Date | 2016/12/09 |
インストール
仮想環境を作成
『ぎりぎり、最低限』と言えるような環境を用意しました。
- メモリ: 1GB
- HDD: 8GB
インストール中の設定
- ネットワークを有効に
- rootのパスワードを設定
- ユーザーを作成
インストールが終わったらそのまま再起動。
ポートフォワード
仮想環境を使う場合、ポートフォワードの設定をしておきましょう。最低でもsshの設定は必要では? あとは好みで。
ここまで出来たら、sshで普通に接続できるようになっているはずです。
初期設定
sudoを使えるようにする
忘れないうちに、sudoを使えるようにしておきます。
$ su -
# visudo
『root ALL=(ALL) ALL』と書かれた行を探して、その下に、ユーザーごとの設定を追加します。
## Allow root to run any commands anywhere root ALL=(ALL) ALL {name} ALL=(ALL) ALL
{name}の部分はsudoを使えるようにするユーザー名が入ります。viの使い方は・・・ ネットで調べて下さい。
アップデート
とりあえずアップデートしておきましょう。
# yum update -y
よく使うソフトのインストール
何を入れるかは好みの問題ですが。
# yum install -y wget
# yum install -y nano
ついでに、nanoの環境を設定しておきます。
# nano ~/.nanorc
以下の内容で保存します。
set nowrap set smooth set tabsize 4 set quickblank
SELinuxを無効にする
SELinuxが不要な場合は無効にしておきます。
# nano /etc/sysconfig/selinux
『SELINUX=enforcing』を『SELINUX=disabled』に修正します。
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of three two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are pr$ # mls - Multi Level Security protection. SELINUXTYPE=targeted
再起動して設定が反映されていることを確認。
# reboot $ getenforce Disabled
本当に無効にして良いのかどうか、よく考えましょう。
sshの鍵を設定
手抜きで、パスワード無しで接続できるようにしておきます。
- クライアントで作業
// クライアントで秘密鍵・公開鍵を作成 $ ssh-keygen -t rsa // サーバーに公開鍵をコピー $ scp ~/.ssh/id_rsa.pub {user_name}@{server_url}:
- サーバーで作業
// ディレクトリとファイルを作成。権限を設定 $ mkdir .ssh $ touch .ssh/authorized_keys $ chmod 700 .ssh $ chmod 600 .ssh/authorized_keys // 公開鍵を登録 $ cat id_rsa.pub >> .ssh/authorized_keys
- クライアントから接続を確認
別の端末を開いてサーバーに繋がることを確認しておきます。
$ ssh {user_name}@{server_url}
パスワードの入力を求められなければ成功です。『rootはsshでログインできなくする』とか『パスワードでのログインを禁止』とか、さらに凝った設定はお好みでどうぞ。
yumのfastestmirrorが遅いサイトを選ばないように設定
以下のサイトを参考に、
yumのダウンロードが遅い事象に対処する - Qiita
http://qiita.com/toshiro3/items/11a97ac67d65cf94ae91
設定ファイルに『include_only=.jp』と『prefer=ftp.iij.ad.jp』を追加しておきます。
# nano /etc/yum/pluginconf.d/fastestmirror.conf
[main] enabled=1 verbose=0 always_print_best_host = true socket_timeout=3 # Relative paths are relative to the cachedir (and so works for users as well # as root). hostfilepath=timedhosts.txt maxhostfileage=10 maxthreads=15 #exclude=.gov, facebook #include_only=.nl,.de,.uk,.ie include_only=.jp prefer=ftp.iij.ad.jp
Swiftにおける名前空間の問題点と、その回避方法
動作を確認した環境
環境 | 情報 |
---|---|
Xcode | 8.0 (8A218a) |
Swift | 3.0 |
Date | 2016/10/12 |
Swiftにおける名前空間とは?
モジュールの名前のことです。
そもそも『モジュールとは何か?』と言う話を始めると長くて面倒な割りにメリットが少ないので省略しますが、簡単に言うと『import ○○○』の形で指定する、『○○○』がモジュールの名前になります。
複数のモジュールで同じ識別子が使われている場合、名前空間を使うことで、どのモジュールの識別子を使うか指定することが出来ます。
名前空間を指定して識別子を指定する例:
import UIKit // 両方のモジュールに『JunkClass』が存在する import JunkFramework1 import JunkFramework2 class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // これはコンパイルエラー JunkClass.printName() // 名前空間を指定すれば問題ない JunkFramework1.JunkClass.printName() JunkFramework2.JunkClass.printName() } }
Swiftにおける名前空間の問題点
名前空間は便利ですが、別モジュールへのextensionを区別できないという問題点があります。
例えば、複数のモジュールでこんなextensionを定義した場合。
extension String { public static func extensionName() { // フレームワークの名前を出力 print("JunkFramework1 - extension") } }
現在のSwiftでは、どのモジュールで定義されたextensionを使うか、指定することが出来ません。
import UIKit // 両方のモジュールにStringへのextensionが存在する import JunkFramework1 import JunkFramework2 class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // 識別子がぶつかっているのでコンパイルエラー String.extensionName() // 以下、すべてコンパイルエラー → モジュールを指定できない JunkFramework1.String.extensionName() String.JunkFramework1.extensionName() (JunkFramework1.String).extensionName() (String.JunkFramework1).extensionName() } }
Swift 3でどうにかなるかと思ってましたが・・・ 無理でした。このままだと、Swift 4でもこの問題は残ったままになりそうです。
名前空間の問題点を回避する方法
では、どうやってこの問題を回避するべきでしょうか?
1. extensionを作る時点で、prefixを付けておく
モジュールを作る側が、名前がぶつからないようにしておく方法です。
『prefixが付いてるなんてSwiftらしくない』と言う意見が出そうですが、『どのモジュールで定義された物かすぐにわかる』といったメリットもあります。たぶん。
2. extensionを使う側で、どれか1つだけ使うようにする
モジュールを使う側で工夫する方法です。
基本的に、よく使うモジュールだけでをimportするようにして、そうでないモジュールは呼び出し元を1カ所にまとめて、何らかの形でラップします。
そもそも、extensionの名前がぶつかる事なんて滅多にないと考えれば、これはこれで有りかもしれません。
3. その他
いつか、Swiftがこの問題をどうにかしてくれるのを待ちましょうか・・・
よくわかるAuto Layout
iOSレスポンシブデザインをマスター
種類 | 情報 |
---|---|
著者 | 川邉 雄介 |
監修 | 所 友太 |
発行日 | 2016年6月 Ver.1.0 (電子書籍版) |
発行 | 株式会社リックテレコム |
感想
Auto Layoutとその関連技術について、丁寧にまとめた本。
この本で使われてる環境はこんな感じ。
- OS X 10.11.4 El Capitan
- Xcode 7.3.1
Auto Layout関係の話がかなり細かく解説してある。外接矩形とかFirstBaseLineについて、ちゃんと説明してある日本語の本はこれぐらいなのでは? iOS9で追加になった、NSLayoutAnchorをちゃんと解説してあるのも良い。
UIScrollViewでAuto Layoutをうまく使う話や、UIStackViewの話も良い。Auto Layout関連の技術で、Dynamic Typeやトレイトコレクションをちゃんと説明してあるのも参考になる。
ただ・・・ よく出来てるだけに、細かいミスが残ってるのがもったいない。
Interface BuilderでViewを設置した場合、ViewControllerのレベルでAuto Layoutが使われているならtranslatesAutoresizingMaskIntoConstraintsは確実にfalseでは?
viewWillAppear()は、バックグラウンドからアプリを開き直したときは呼ばれないのでは?
UITraitCollectionのdisplayScaleがRetina端末では2.0と書いてあるが、5.5インチ系では3.0では?(設定にもよるけど)
他にも、セミコロンが残ってるとか、変数名がおかしいところがあるとか、今さらCGRectMakeやCGSizeMakeは無いだろうとか、細かいところが気になったり。
ちゃんと理解していないまま、なんとなくでAuto Layoutを使っている人なら一度は目を通しておく価値があるかと。個人的には、Auto Layoutのデバッグの章で、良くあるパターンの解消法とかあったら嬉しかったけど、そこまで書いてたらキリが無いか。
おすすめ指数:☆☆☆☆☆
(2016/09/20 読了)
Objective-Cの要点
種類 | 情報 |
---|---|
著者 | 柴田文彦 |
発行日 | 2014年4月25日 初版発行Ver1.0 (リフロー版) |
発行 | 株式会社インプレスR&D |
感想
Kindle Unlimitedで無料だったので読んでみたシリーズ。
Objective-Cの仕様を簡単に説明した本。
表紙には『Objective-Cの要点』とか『iOSアプリ開発の基本中の基本』とか『Objective-Cに対する苦手意識を一掃する明快な解説』とか書いてあるけど、そんな事はどこにも載ってない。
Objective-Cの言語仕様について、簡単に説明しただけの本。一応、NSArrayやNSNunmberの話もあるけど、これはリテラルの説明で出てきているだけで、詳しい使い方が載っているわけでは無い。
Objective-Cを使う上でハマりやすいところを説明しているわけでも無ければ、iOSアプリを開発する話が載っているわけでも無い。本当に、最初から最後まで、Objective-Cの言語仕様の話だけ。
ぶっちゃけて言ってしまうと、荻原剛志さんの『詳解 Objective-C 2.0 第3版』の単なるサブセット。値段はこっちの方が安いかもしれないけど、内容は底が浅くて幅が狭い。
わざわざこの本を買うぐらいだったら、古本屋で『詳解 Objective-C 2.0 第3版』を探す方がおすすめ・・・ 素直に、Swiftを勉強した方が良いとは思うけど。
おすすめ指数:☆☆
(2016/08/23 読了)
iOSアプリ開発 AutoLayout徹底攻略
種類 | 情報 |
---|---|
著者 | 森巧尚 |
発行日 | 2015年5月12日 電子書籍版発行 v1.0 |
発行 | 株式会社マイナビ |
感想
Kindle Unlimitedで無料だったので読んでみたシリーズ。
Auto Layoutでよく使われるパターンについて、簡単に説明した本。
本が書かれた環境は、 Xcode 6.3.1 / Swift 1.2 とのこと。
Auto Layoutの使い方に的を絞った本。それなのに、Auto Layout関係で説明が不足しているところがある不思議。少なくとも、タイトルの『AutoLayout徹底攻略』というのは無理がある。
『Constrain to margins』の設定で具体的にどこがどう変わるのか・・・ せっかくのAuto Layoutの本なら、こういう所をちゃんと説明するべきだったのでは?
表紙には『すぐに役立つ12パターン』と書いてあるけど、中には同じパターンを無理やり分けたようなものが。そこで水増しする必要があったんだろうか?
そもそも目次の作りがおかしいとか、ページの使い方がおかしいとか、内容以前に本として突っ込みどころが目立つ。
まったく価値が無いとまでは言わないけど、お金を出してまで読む必要があるかと言われるとかなり疑問。内容も、既に古くなってるしね。
おすすめ指数:☆☆
(2016/08/22 読了)
iOS9対応のアプリ開発
サラッと読んでおきたいiOS9の新技術
種類 | 情報 |
---|---|
著者 | マーク山崎 |
発行日 | 2016年1月(?) |
感想
Kindle Unlimitedで無料だったので読んでみたシリーズ。
iOS9で追加になった機能を紹介した本。
iOS9で追加になった『マルチタスク』とか『3D Touch』とか、そのあたりの機能をそれなりに詳しく説明してある。
それなりに詳しく説明してあるんだけど・・・ それぞれの機能を紹介する具体的なサンプルがまったくないのは微妙。機能の紹介とリファレンスの翻訳で終わってるレベル。結局、Appleのサンプルを見に行くんだったら、無理にこの本を読む必要は無いような気が・・・
機能によっては、日本語で解説された情報がほとんどないものとかあるし、この本の情報が助けになる人も居ないことは無いかもしれない。けど、この本の情報で機能を使えるようになる人だったら、ネットの情報だけでもなんとかなるのでは?
素直に、QiitaでiOS9タグでも片っ端から見てた方がマシかも。
おすすめ指数:☆☆
(2016/08/22 読了)
はじめてのiPhoneアプリ開発
はじめる前にサラッと読んでおきたい基礎技術
種類 | 情報 |
---|---|
著者 | マーク山崎 |
発行日 | 2015年4月 |
感想
Kindle Unlimitedで無料だったので読んでみたシリーズ。
まともな(?)iPhoneアプリ開発の入門書であれば、序盤にまとめてあるような内容を抜粋した本。
プログラミング言語の説明無しに、iPhoneのアプリを開発するときに使う考え方とかフレームワークをざっと説明してある。狙いとしては面白かもしれないけど、実際に読んでみると・・・ こう言うのを、日本語だと『片手落ち』って言うんだろうな。
よく使われるクラスの説明の部分は、ほとんどが、ただのリファレンス。具体的なサンプルも無しに機能だけ紹介されてもねぇ。
そもそも、本を書くにあたって動作を確認した環境が書かれていない時点で問題外か。
この本をサラッと読むぐらいだったら、まともな入門書を真面目に読んだ方が良いかと。
しかし、表紙はもう少しどうにかならなかったんだろうか?
おすすめ指数:☆☆
(2016/08/22 読了)