なるべくMac固有のバージョン確認のみ載せる。
ブログとかで環境情報を載せる場合は、下記のコマンドで確認したほうがいい。
| 種類 | コマンド |
|---|---|
| OS | SW_VERS |
| Swift | swift -vターミナルモードが起動してしまうので、 :exitで抜け出す。 |
| Xcode | xcodebuild -version |
| Homebrew | brew -v |
| Java | java -version |
SwiftでWebViewアプリ
きっかけ
Swiftでいろいろアプリを作っているが、なかなか言語が覚えられない。
ネイティブ系のエンジニアではないからかもしれない。
WebViewを使えば、楽できるのではないかと思い、実施に至る。
環境情報
$> SW_VERS ProductName: Mac OS X ProductVersion: 10.12.3 BuildVersion: 16D32 $> swift -v Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.38) $> xcodebuild -version Xcode 8.3 Build version 8E162 igarashitoshio-no-MacBoo
Xcodeのバージョンによっては、実施方法に差が出るので、一応載せとく。
やり方
プロジェクト作成
兎にも角にもプロジェクト作成が最初の仕事。
- Xcodeを起動して、Create a new Xcode projectを選択。
- Single View Applicationを選択してNext
- Languageをswiftにして、後はテキトーに入力
- 保存するディレクトリを選んでcreate
StoryBordの削除
SwiftはStorybordを使って、部品の配置を決める。
しかし、WebViewは部品一つしか必要ないので、あっても意味が無いので削除する。
※とくに削除しなくても問題ないので、飛ばしてもいいかも？
- Xcodeのサイドバーの"Show the Project navigator"を表示
- 一番トップにある、プロジェクト名のファイルを選択
- General > Develop Info > Main Interface の内容を空にする
こいつで参照するStorybordを決めている。 - Main.storyboardを削除
ViewController呼び出し
storybordを削除したので、自前で呼び出す処理が必要らしい。
AppDelegate.swiftファイルを下記の通り編集する。
※コードは一部抜粋
@UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? var navigationController: UINavigationController? func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { window = UIWindow(frame: UIScreen.main.bounds) let viewController: ViewController = ViewController() window!.rootViewController = UINavigationController(rootViewController: viewController) window!.makeKeyAndVisible() return true }
やっていることメモ
- ベースとなるウィンドウのインスタンスを生成。
- ベースとなるViewControllerを生成。
- 1.で作成したwindowの一番上位のViewConntrollerにUINavigationControllerを指定。
さらに、そのUINavigationControllerの一番上位のViewConntrollerに、2.で作成したviewControllerを指定 - 1.で作成したwindowを有効化
WebViewを全画面表示
import UIKit import WebKit class ViewController: UIViewController, WKNavigationDelegate { let webview: WKWebView = WKWebView() override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view, typically from a nib. webview.frame = view.bounds webview.navigationDelegate = self view.addSubview(webview) } override func didReceiveMemoryWarning() { super.didReceiveMemoryWarning() // Dispose of any resources that can be recreated. } }
viewにwebviewのインスタンスを生成したものを埋め込む。
やる際は、WebKitのインポートをお忘れなく！
なんでビルドエラーになるのか分からず、１時間くらい時間を浪費するハメになった。。。
完成
上記をやれば、とりあえず実行するとwebviewが全画面で表示される。
ただし、真っ白だけど。。。
htmlを表示してみる
やりたいのは、ローカル保持しているHTML表示
外部のモノを参照することもあるだろうけど、やりたきことは別なので、やってみる。
配置場所の作成
まずは、htmlを配置する場所を作る。
Resourcesにhtmlなどを置こうと思う。
Xcodeだと、ディレクトリとは呼ばずにGroupと呼ぶらしい。
なぜだかは知らないけど、かなり迷う。
File > New > Group を選択して、Resourcesを作成
HTML作成
作ったResources内に、index.htmlを作成する。
File > New > Fileから、htmlファイルを作る(emptyを選んでindex.htmlという名でファイルを作る)
作ったら、ファイルを以下の内容にする。
今回は表示させたいだけなので、別になんでもいい。
<html> <head> </head> <body> test </body> </html>
htmlファイルのロード
作ったindex.htmlをwebviewに読み込ませる。
import UIKit import WebKit class ViewController: UIViewController, WKNavigationDelegate { let webview: WKWebView = WKWebView() override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view, typically from a nib. webview.frame = view.bounds webview.navigationDelegate = self view.addSubview(webview) let url = Bundle.main.url(forResource: "index", withExtension: ".html")! let request = URLRequest(url: url) webview.load(request) } override func didReceiveMemoryWarning() { super.didReceiveMemoryWarning() // Dispose of any resources that can be recreated. } }
実行
実行すると、index.htmlの内容が出力されるはず。
感想
htmlの表示ができたので、あとはWebの知識とJS・CSSの考えを流用すれば行けるハズ。
デフォルトOptionalが有効なのが、違和感ありすぎて辛い。。。
特に、xcodeが全て英語なので、英語に慣れてないと拒絶反応が出る。
あと、デリゲートって何？おいしいの？
デリゲートの意味が未だに理解できない。
調べはするが、それってinterfaceとか使って呼び出すメソッドを決めておき、処理は宣言しているところで書くのと同じなんじゃ。。。って思う。
これは、いわゆるFacadeなのだろうか？
いままでプログラミングしてきて思うに、Facade使って上手くいったパターンがほぼないのだが、検討違いだろうか？
愚痴っぽくなってしまったので、ここでおしまい。
WebViewを使ったアプリには、可能性を感じる。
ネイティブ側の問題が発生すると死にそうだけどね。。。
参考サイト
swift - How to add a navigation bar to WKWebView? - Stack Overflow
npmにインストールしたものの確認
インストールしたものの確認方法
下記コマンドで確認できる
npm list
もしくは、ailiasが設定されているので、listの箇所は、ls, la, llが使える。
ailiasの確認がしたい場合は、npm list -hとすると下記のような記述がでる。
もちろん、ここのlistも置き換え可能。
npm ls [[<@scope>/]<pkg> ...] aliases: list, la, ll
多すぎる
npm listで表示したものは、依存関係も含めて表示される。
そのため、インストールしているものが多すぎると、ネストが深くなったりして、確認したい一覧が見えない。
なので、依存関係を見たい場合以外は、下記のコマンドで事足りる。
npm list --depth=0
グローバル環境を確認する
今まで紹介してきたものは、全てローカル環境の確認方法。
グローバル環境にインストールしたものではない。
確認したい場合は、ご察しの通り、-gオプションを付ければいい。
npm list -g
もちろん、これにも--depth=0は使える。
やり方が、統一感があるので、覚えやすいはず。
Macのターミナルのカスタマイズ
ターミナルの右側の文字列のカスタマイズ
ターミナルの$前の出力フォーマットは、環境変数のPS1で設定されている。
現状の設定内容を確認したい場合、下記のコマンドで確認する。
echo $PS1
意味は下記の通り。
| 値 | 意味 |
|---|---|
| \h | ホスト名（最初の.まで） |
| \H | ホスト名 |
| \t | 時間（24h） |
| \u | ユーザー名 |
| \w | 現在のディレクトリまでのパス |
| \W | 現在のディレクトリ名 |
値の設定
{変数名}={出力フォーマット} で設定可能
例は下記の通り。
PS1=\W
ただ、上記のやり方だとターミナル再起動で元に戻ってしまうので、~/.bashrc などに記載する。
やり方は、以前の記事を参照。
参考サイト
就活生に送るプログラマ・システムエンジニアの状況
きっかけ
電車の中で就活生何度か見かけるようになり、この業界に抱いている幻想を打ち砕くために書こうと思った。
実際、うちの会社に入ったけど、思っていたのと違うから辞める人が結構いるので、情報発信しようと考えたのがきっかけ。
これまでの経験則に基づくものなので、人によっては個人差が出るかもしれない。
自分の仕事の経緯
職歴：１０年(今年で！)
就職している会社は正社員だけど、職場は派遣で行っている。
業務内容・普段感じていること
入社してすぐ
何もできないと思われている。
だから、それを上手く使って教えてもらう。
最初の数年は、プログラミングさせてもらえなかった。
テスト、テスト、テスト。。。
テスターを軽く見ている職場が多い。
テストに関しては、別なところで話をする。
プログラミングをやりたいなら、大手かサービスを自作している会社に入ったほうがいい。
派遣で喰っているような会社は、最初の数ヶ月は実装をやらせてくれる可能性は低いので、会社選びは慎重に。
仕事について
世間的には、机でひたすらパソコンと向かいあっている印象が強いイメージだが、人との会話が必須となる職業である。
何かしら会話しなくてはいけない。
調べても分からないことがあれば、人に聞かなければいけない。
ここでギャップを覚える人が結構いるように思える。
どういうモノを作るのか、会話で認識違いをなくさなければならい。
なぜそうするかというと、実際作ったあとにイメージと違うってことがあると、かなり印象が悪い。
現物があるわけではなく、作り直しが容易だと考えている人が多いので、認識違いをなくすことが超重要になる。
テスター
新人でもやれるでしょ？って考えている奴が多い。
しかし、実際はテスト仕様書の記述があいまいなことが多く、仕様を理解しきれていないためにバグの発見が遅れることが多々ある。
そして、遅れの責任を押し付けようとするのが、糞ムカつく！
どこの現場でもそんな感じなので、遅れたからといって、気に病む必要はない。
このすばのアクシズ教の教義上手くいかないのは世間が悪いのように、実際に悪いのはプロジェクト責任者！
過度に責任を感じる必要はない。
※どうすれば良かったかは、考えてほしいけどね！
分からないとき
どうプログラミング、設計すればいいかわからないときは、素直に聞く。
それば一番手っ取り早い。
ただ、人によっては威張る人がいたり、笑われたりすることがある。
それが嫌だから聞かないと、あとで責任がどうこう言い出して面倒くさいので、早いほうがいい。
どうしてもムカつくときは、家に帰ってデスノートに名前を書くしかない。
開発者よりの会社であれば、上記のようなことは少ない。
大手も。
職歴の割に実力を持たない人が、そういった傾向になることが強いイメージがある。
あとは惰性で書いているので、好きな人だけ見ればいい。
勤怠
職場による。
お役所からの仕事や、銀行関連は、きっちり時間が決まっている。
ネット関連の職場であれば、厳密に決まっていないので、ある程度の遅れなら多めに見てくれる。
ただし、３０分以上遅れるなど、明らかに勤怠が間に合わないと分かっているときは、連絡が必須。
組織で動くので、連絡は怠ると、営業経由で背中をさされる。
特に、休みすぎは絶対ダメ。
休暇を複数取る場合は、なるべく早めに宣言しておくこと。
職場環境
清潔であることが多い。
ビルの老朽化具合で、環境が左右される。
一番気をつけなければならないのは、トイレの数と椅子。
トイレが少ないと、かなり危険。
この業界の人は、お腹が弱い人が多く、日頃のストレスのせいかもしれないが、トイレが埋まっていることが多い。
なので、周囲のトイレの場所は把握してないと、漏らしちゃうかも。
椅子は、日々の作業をする上で重要。
自席
埃が溜まりやすいので、ウエットティッシュで拭いたりすること週１くらいでしたほうがいい。
花粉症とおもいきや、埃で鼻がやられることが多いので、なるべくした方がいい。
あと、ケーブルはまとめていたほうがいい。
席移動が３ヶ月に１度のペースである。
席替えがあるということは、人が・・・ってことだ。
人の出入りが激しいので、他の業界よりも移動することが多いと思っている。(他の業界知らんけどね！)
ケーブルをまとめていたほうが、移動時にイライラすることがない。
だから、ウェットティッシュは、買っておいて損はない。
ドリンク
自販機は、すぐそばにあることが多い。
いっとくが、職場でコーラを飲んでいるやつは、ほとんどいない。
１０年やってきて、コーラ飲みながら作業している人は、片手で数えられるくらい。
よく観るのが、十六茶、ドデカミンはよく見る。
缶コーヒーは必須。
あと、いろはすにレッドブル。
レッドブルは、これ飲んで深夜も働けってこと？？
マシンスペック
会社の懐事情による。
１０年くらい前のスペックで開発しろってところもあれば、メモリを少し多めにつんだCorei7なんかもある。
どれだけ開発者を大事にしているか、ココで分かる。
開発マシンスペックを聞いて、開発者の立場をつかむのも、アリかもしれない。
Mac
ある現場はみたことあるけど、そんなにない。
Mac使うには、実際に開発でしようするような現場じゃないと無理。
ここでも、開発者の優遇具合が測れる。
gulpでtypescriptのコンパイル
きっかけ
職場には既にgulpがあったけど、一から入れたことがないので、勉強がてら試しにやってみた。
gulpとは？
CIのためのビルドツール。
処理は、タスク単位で書くことができる。
特徴は、ストリームを使ったメソッドチェーン的な記述で処理を書けるところ。
作ったタスクをつなげて、ビルドさせる。
似たツールにGruntというものがあるらしいが、利用したことがないので、ここでは言及しない。
また、gulpの基本は抑えているものとし、詳細な説明は省く。
気が向いたらまとめ記事を投稿予定。。。
準備
実施環境
ProductName: Mac OS X
ProductVersion: 10.12.3
BuildVersion: 16D32
npm
homebrewでインストール
コマンドは以下。nodeと一緒にインストールすれば、npmもインストールされるはず。
brew install node
使い方は下記を参照。
インストールが終わったら、プロジェクトを作る。
※後の話は、プロジェクトがある前提で進める
作り方は、以下。
リンク先の方が詳しく書いた気がするので、合わせてそちらも確認して貰えれば。
npm init -y
typescript
npm install typescript -g
別にグローバル環境である必要はないが、プロジェクトごとに使える／使えないのは、面倒なので、グローバルにインストールすることをおすすめする。
インストール完了後、tsconfig.jsonを作成する。
package.jsonがあるフォルダで、下記のコマンドを実行
tsc --init
gulp
npm install -g gulp
グローバルインストールしないと使えないので注意
その他にも、利用すべきgulpプラグインがあったので、下記のものをインストールする。
- gulp-typescript
typescriptのインストールに必要 - gulp-concat
一つのjsファイルにまとめるために必要 - require-dir
ディレクトリ参照に必要
環境
プロジェクト直下のディレクトリ構成。
※node_moduleディレクトリは、除いてある。
├── build │ └── gulpfile.js ├── gulpfile.js ├── index.css ├── index.html ├── index.js ├── package.json ├── path.json ├── src │ └── index.ts └── tsconfig.json
ここでの仕組み
gulpファイルを多段構成にしてビルドさせている。
なぜビルドファイルを分けたかと言うと、ビルド内容は時間が経つにつれて長大になりやすいので、目的に応じて分けたほうがいいと思ったから。
ビルドには./build/gulpfile.jsを使っている。
./gulpfile.jsonは、参照するgulpfileのパスを保持するだけにしている。
gulpファイルを直接指定する方法もある。
下記のような指定が可能
gulp --gulpfile ./build/gulpfile.js
./gulpfile.js
var requireDir = require('require-dir');
requireDir('./build', {
recurse: true
});
参照するgulpfile.jsがあるフォルダを、require-dirで参照しているだけ。
./build/gulpfile.js
var gulp = require("gulp");
var typescript = require('gulp-typescript');
var concat = require('gulp-concat');
gulp.task("build", () => {
var pj = typescript.createProject("./tsconfig.json");
gulp.src([
"./src/**/*.ts",
"!./node_modules/**"
])
.pipe(pj())
.js
.pipe(concat("index.js"))
.pipe(gulp.dest("./"));
});
肝になっているのは、gulp.src~以降の箇所。
ここで、ビルドまでの一連の処理を実行している。
src()では、配列の一番目に対象にするファイルを正規表現で抽出している。
その次の"!./node_modules/**"で、npmで入れたファイルを対象外にしている。
そして、それで抽出できたものを、tsconfig.jsonを元にコンパイルしている。
それで終わったら、index.jsに集約させて、プロジェクトトップに出力させて終了する。
気をつけなければならないのは、パス指定はプロジェクトトップからになっていること。
このファイルがあるディレクトリからではないので、注意が必要。
実行方法
プロジェクトトップのディレクトリで、gulp buildを実行する。
個人的には、実行はすべてnpm任せにしたほうが、コマンド集約できるので、npmコマンドで実行できるようにしている。
やり方は、package.jsonのscriptに、ビルドコマンドを追加するだけ。
下記の例では、npm run buildを実行すればgulp buildをしたのと同じになる。
{ "name": "localink", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "build": "gulp build" }, "keywords": [], "author": "", "license": "ISC", "devDependencies": { "gulp": "^3.9.1", "gulp-concat": "^2.6.1", "gulp-typescript": "^3.1.6", "require-dir": "^0.3.1", } }
とりあえず、基本的なことはできた！
あとは、プロジェクトとともに成長させてゆくだけ。
参考サイト
Gulp 始めてみましたのメモ – 5 – コピーと削除, ファイル・ディレクトリ « イナヅマTVログ
gulp-tscとgulp-typescriptの利用方法の違いについて - Qiita
gulpでtypscriptをコンパイルする - Qiita
