【書評】やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

きっかけ

いつも行く本屋、丸善丸の内本店で押されていたので購入。
本屋は行き先で見つけたらプラっと入ってしまうけど、丸善丸の内本店は別格。
専門書の品揃えがいいのと、オススメ本がしっかりしているのがいい。
この他にいいと思ったのは、新潟駅近くのジュンク堂書店かな？
さすが新潟だけあって、土地が余ってる余ってる！
店内はかなり広い。
ただし、専門書の品揃えは、丸善に負ける印象。
古い本がおいてあるイメージが勝手に存在している。

話が逸れた。
あと、目次を見て、才能好きの日本人を論破してくれるのではないかという期待から読んだ。

内容

目次

• はじめに ──「生まれつきの才能」は重要ではなかった！
• PART １　「やり抜く力」とは何か？ なぜそれが重要なのか？
  • 第１章　「やり抜く力」の秘密
  • 第２章　「才能」では成功できない
  • 第３章　努力と才能の「達成の方程式」
  • 第４章　あなたには「やり抜く力」がどれだけあるか？
  • 第５章　「やり抜く力」は伸ばせる
• PART ２　「やり抜く力」を内側から伸ばす
  • 第６章　「興味」を結びつける
  • 第７章　成功する「練習」の法則
  • 第８章　「目的」を見出す
  • 第９章　この「希望」が背中を押す
• PART ３　「やり抜く力」を外側から伸ばす
  • 第10章　「やり抜く力」を伸ばす効果的な方法
  • 第11章　「課外活動」を絶対にすべし
  • 第12章　まわりに「やり抜く力」を伸ばしてもらう
  • 第13章　最後に
• 訳者あとがき

まとめと感想

第１章　「やり抜く力」の秘密

挫折した後が重要。
一回折れた後に「継続」が行えるのかが大事。
「あきらめたらそこで試合終了ですよ・・・？」

結果を出す人＝粘り強い人
つまり、己に対して厳しい評論家である人が、結果を出せる。

才能ある人≠やり抜く人
とくに相関関係はない。
才能あるからと言って、結果を出し続けられるわけではない。

第２章　「才能」では成功できない

偉業を成すために必要なこと

1. 才能
2. 熱意
3. 努力を続ける力

特に、2と3が重要。
どこかの企業は、3だけを強制してくるからな。

人は、才能が大好き。
同じ能力でも、才能ある人に将来性を感じる。
ただ、才能というものにスポットライトが当たりすぎて、他の重要なところが霞んでいる。
曇りなき眼で見定めよ！

才能を重視したい場合、努力はその２倍重視するくらいがちょうどいい。

第３章　努力と才能の「達成の方程式」

最高のパフォーマンスは、小さなスキル・行動の積み重ねで達成できる。

圧倒的な能力を目の前にした時、人はそれが才能だと思い込む。
なぜそうするかというと、その人が積み重ねた努力を想像できないのと、神格化することで自分に引け目を感じなくなるから。
一種の自己防衛機能が働くわけですな。

• 才能
  スキル上達する速さ

• 目標達成
  取得したスキルを活用することで得られる成果

何をするにしても、努力することがベースになる。
努力しない場合、才能は陳腐化、達成内容は少なくなる。

第４章　あなたには「やり抜く力」がどれだけあるか？

やり抜く力とは、持久力のこと。
ただ、ガンバることだけがやり抜く力ではない。

偉人と一般人の違いは、目標に対する動機付けにある。
長期目標への努力、意志の強さ、辛抱強さがある。

第５章　「やり抜く力」は伸ばせる

やり抜く力を高めるには、スキルの高い人たちと一緒に作業することが近道。
そして、目標は変えないこと。

第６章　「興味」を結びつける

情熱は、ある日、突然発生するものではない。
長い時間をかけて興味を掻き立てられる経験をすることで、情熱が生まれる。

情熱を持つには、周囲の環境が大切。
情報を与えてくれる人、フィードバックを得られることが大切。

好きだから上達するは間違い。
好きでも、努力しなければ上達はしない。
努力することを楽しめることが大切。

第７章　成功する「練習」の法則

成功する人とは、改善を続けた人たち。

上達するには、練習の時間の長さより、どう練習したかが重要。
濃度が大事。
楽な練習では意味がない。

第８章　「目的」を見出す

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第９章　この「希望」が背中を押す

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第10章　「やり抜く力」を伸ばす効果的な方法

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第11章　「課外活動」を絶対にすべし

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第12章　まわりに「やり抜く力」を伸ばしてもらう

読んだけど、そこまで重要な内容はなかった気がするので、パス。

全体を通して

読んでると、いちいちあの企業が頭をよぎったわ。。。
個人の努力を強要してはいけないなと感じた。
だけど、強要はしなくても、それがやりやすい環境をつくることが、上長や管理職として必要なんだろうなと思った。

結局、大切なのは、濃度の濃い練習をどれだけ継続してやれますか？ってことなんだね。
周りに競う相手がいないと、難しい。
やっぱり、ライバル的な関係のヤツがいることは、重要なんだな。

Oracle Certified Java Programmer, Silver SE 8 認定資格を受けてきた

公式サイト

Java SE 8 認定資格 | オラクル認定資格制度 | Oracle University

受講結果

当然、合格しましたよ。
久々に試験に合格する感触を得た気がする。
IPAの情報処理技術者試験を毎回受けてるけど、スペシャリストになると合格が難しいんだもん！
意欲削がれまっせ！
たぶん、大刀・鮫肌で２回位削られてる。

ＧＷ２日目に受講したから、今はとてもハッピーな感じ。
拳銃持ったら、乱射しちゃうハッピートリガーくらいお気楽な気分！
落っこちてたら、ＧＷがブルーウィークになっていたことだろう。
たぶん、一週間家に篭って、終わってたかも知れない。

試験対策とか流れ

受講までの流れ

1. オラクルにて受講チケット購入
2. ピアソン社で試験予約
3. 受講

ピアソンのアカウントが必要だったりして、結構迷った。
基本的な流れは上記でＯＫ

オラクルから購入しなくても楽天とかで売ってるやつでもＯＫみたいなことが、どこかのサイトに乗ってた気がするけど、怖くて公式なやり方で受講した。
ピアソンのサイトで、「受講料払ってください」みたいな掲示が出た時はビビった。
チケット番号を入れる箇所を見過ごしてたから、かなり焦ったわ。。。
というか、すげーサイトが見づらかった。

受講のためにしたこと

Javaは、ちょっと前まで業務でガッツリ使っていたので、試験対策をある程度すれば大丈夫だろうと思い、問題集に一回全部目を通して受講。

徹底攻略 Java SE 8 Silver 問題集[1Z0-808]対応

そこまで間違うことはなかったけど、パッケージ関連とインポート関連が面倒だった。
そこらへんって、普段ＩＤＥが自動保管してくれる箇所だから、あんまり意識しないのが裏目に出た。
業務でやっている人は、ＩＤＥに頼ってる部分を重点的にやったほうがいいかもしれない。

合格してみての感想

80%行っただろうと思ったけど、そうではなかった。。。
あと、間違った箇所の指摘が来たけど、問題わかんないから、指摘の意味がわかんないんだよね。。。
どっかに試験の問題が乗ってんのかな？
合格したから、どうでもいいやってのが正直な感想。

とりあえず、今年度の目標にしていた資格が合格できて良かった。
あとは、会社から受験料と合格一時金をふんだくるだけですな！

【書評】Java本格入門 感想 老を感じる

商品情報

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

gihyo.jp

きっかけ

Twitterでウザいくらい流れてたので、とりあえず手にとって読んでみた。
たぶん、自分は初心者の部類ではないと思いたい！ 初心を忘れない意味でも読んだ。

よくよく見たら、コレは技術評論社から出てるんだな。
Web+DB pressとか、SoftwareDesiginを出しているところか。
最近、定期購読するようになったから、社名は覚えた。

内容

呼んだ内容と、自分への補足を記載。

目次

はじめに
Chapter　1　Javaの基本を知ろう　～イントロダクション～
　1.1　Javaとは
　1.2　「Hello Java World!」を表示してみよう
Chapter　2　基本的な書き方を身につける
　2.1　Javaの基本的な記法
　2.2　クラスとメソッド
　2.3　情報共有のために知っておきたい機能
　2.4　名前のつけ方に注意する
Chapter　3　型を極める
　3.1　プリミティブ型と参照型
　3.2　クラスの作成
　3.3　型判定とオブジェクトの等価性
　3.4　型にまつわる問題を予防する
Chapter　4　配列とコレクションを極める
　4.1　配列で複数のデータを扱う
　4.2　コレクションフレームワークで複数のデータを扱う
　4.3.　配列に近い方法で複数の要素を扱う　～Listインタフェース
　4.4　キーと値の組み合わせで値を扱う　～Mapインタフェース
　4.5　値の集合を扱う　～Setインタフェース
　4.6　その他のインタフェース
Chapter　5　ストリーム処理を使いこなす　～ラムダ式とStream API～
　5.1　Stream APIを利用するための基本
　5.2　Streamを作成する
　5.3　Streamに対する「中間操作」
　5.4　Streamに対する「終端操作」
　5.5　Stream APIを使うためのポイント
　5.6　Stream APIを使ったListの初期化
Chapter　6　例外を極める
　6-1　例外の基本
　6-2　例外処理でつまずかないためのポイント
Chapter　7　文字列操作を極める
　7-1　文字列操作の基本
　7-2　正規表現で文字列を柔軟に指定する
　7-3　文字列のフォーマットと出力
　7-4　文字コードを変換する
Chapter　8　ファイル操作を極める
　8-1　ファイル操作の基本
　8-2　ファイルを読み書きする
　8-3　ファイルを操作する
　8-4　さまざまなファイルを扱う
Chapter　9　日付処理を極める
　9-1　DateとCalendarを使い分ける
　9-2　Date and Time APIを利用する
　9-3　日付クラスと文字列を相互変換する
　9-4　Date and Time APIで日付／時間クラスと文字列を相互変換する
　9-5　和暦に対応する
Chapter　10　オブジェクト指向をたしなむ
　10-1　プリミティブ型の値渡しと参照型の値渡し
　10-2　可視性を適切に設定してバグの少ないプログラムを作る
　10-3　オブジェクトのライフサイクルを把握する
　10-4　インタフェースと抽象クラスを活かして設計する
Chapter　11　スレッドセーフをたしなむ
　11-1　マルチスレッドの基本
　11-2　スレッドセーフを実現する
Chapter　12　デザインパターンをたしなむ
　12-1　デザインパターンの基本
　12-2　生成に関するパターン
　12-3　構造に関するパターン
　12-4　振る舞いに関するパターン
Chapter　13　周辺ツールで品質を上げる
　13-1　Mavenでビルドする
　13-2　Javadocでドキュメンテーションコメントを記述する
　13-3　Checkstyleでフォーマットチェックをする
　13-4　FindBugsでバグをチェックする
　13-5　JUnitでテストをする
　13-6　Jenkinsで品質レポートを作成する
Chapter　14　ライブラリで効率を上げる
　14-1　再利用可能なコンポーネントを集めたApache Commons
　14-2　CSVで複数のデータを保存する
　14-3　JSONで構造のあるデータをシンプルにする
　14-4　Loggerでアプリケーションのログを保存する

補足

デフォルトコンストラクタ

Javaは、コンストラクタでインスタンス生成時の処理が記述されているが、下記のように記載されてない場合もある。

public class Test {
}

この場合、コンストラクタはないように思うが、実は存在している。
上記のコードは、下記のコードと同義になる。

public class Test {

    public Test() {
    }

}

気をつけなければならないのは、Singletonを使ったケースで発生する。
今は、DIを使ってSingletonを実現することが多いが、そうじゃない場合、デフォルトコンストラクタの隠蔽を忘れて、インスタンス生成がnewで、できてしまう事がある。

public class TestSingleton {

    private static TestSingleton instance;

    public TestSingleton getInstance() {
        if(this.instance == null) {
            this.instance = new TestSingleton();
        }

        return this.instance;
    }
}

上記例だと、一見Singletonを実現できているように見える。
しかし、デフォルトコンストラクタを隠蔽してないため、下記のやり方をされると、インスタンスは複数生成される。

public static void main(String[] args) {
    TestSingleton ts = new TestSingleton();
}

こうなるとSingletonにした意味が無いので、なるべくprivateで、デフォルトコンストラクタを隠蔽させる。

public class TestSingleton {

    private static TestSingleton instance;

    private TestSingleton() {
    }

    public TestSingleton getInstance() {
        if(this.instance == null) {
            this.instance = new TestSingleton();
        }

        return this.instance;
    }
}

FindBugsについて

最近、コミュニティの動きが心配。
分解しないかだけ心配。
下記の記事に簡潔にまとまっている。

blog.kengo-toda.jp

一段レベルアップのために、FindBugsにはお世話になったので、このまま継続していて欲しいのが願望。
似たツールとしては、PMDがある。
こっちも、コードレベルをあげるのに役立った。

気になったこと

ワイドニングとナローイング

型変換のところで出てきた。
学生時代の頃は、「暗黙の型変換」って習った気がする。

今は、横文字主流なのか。。。
俺は、どっちかというと、感じの方が厨二臭くて好きだ。

Javaはデカくなったな。。。

Javaで広範囲をカバーしようとしたら、もっとデカくなりそうな気がする。
フレームワークまわりとかカバーしたら、たぶん広辞苑クラスになるで！

感想

初級者よりちょっと進んだ人向けかな？
広い範囲をカバーしてあるので、気になったところは、別途、本を買うなりしてみたほうがいいかもしれない。
知識領域を広めるために読んでみるのがいいのではなかろうかと思いました。

あと、StreamAPIとか、ラムダ式って、初心者はついてこれるものなのだろうか？
俺、覚えるのに結構時間かかった気がする。
今の若い奴らは、すんなり覚えられるのかと思うと、驚愕！
儂も老いたのぉ。。。。

他に気になったのは、参考文献にあった、ひしだまさんのホームページ。
これって、印税が入ってくるのだろうか？
私、気になります！

実際、読んでたら学生の気分を思い出したわ。
パッケージ関連とか、なんの意味があるのか分かんなかったけど、実際のコードを見て必要性を認識した記憶がある。
あと、ファイル入出力も覚えられなかったころが懐かしいな。
懐かしすぎて、老を感じる。
ちょっと虚しさを覚える一冊やったわ。。。

追加でオススメしたい本

Effective Java

EFFECTIVE JAVA 第2版 (The Java Series)

Javaではこうするべきってのが、理由付きで載っている。
理屈込で書かれているので、覚えやすい。
基本文法がマスターできたら、あとは、理屈でこう書くべきってのを覚えるといいかも。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

どこいってもオススメされるから、あんまり説明の効果ないかな？
一人で開発はありえない。
絶対チームで開発になる。
可読性を重視するためのコツ・ポイントが、コンパクトにまとめられており、読みやすい。
過去に書評書いたので、気になった人は、読んでもらえればと。

suzaku-tec.hatenadiary.jp

リファクタリング―既存のコードを安全に改善する―

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

本書では触れていなかったが、リファクタリングが開発では必須になる。
アホな現場のガチガチの保守でない限りは、絶対必要になる知識。
みんな大好き「改善」をやるためにも、絶対に読んでおいてもらいたい一冊。
新規で開発する場合も、自分で作りながらリファクタリングすることがあるので、保守しないと思っても、一読したほうが良い。

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発 (I・O BOOKS)

環境構築が楽なSpringBootを使った入門書。 Javaを使う＝Web開発がほとんど。
Webフレームワークを簡単に体験できるのでオススメ。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

日本でデザインパターンを学ぶといったら、コレ。
自分は、この本からデザインパターンを学んだわけではないが、内容は簡潔にまとめられているので、一読してみるといい。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

Effective Javaに近い内容だった気がする。
今後、APIの開発は、開発トレンドを見ていると必須だと思う。
この本を読んで、APIとはどうあるべきかを考えてみるといいかもしれない。

Java関連の記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

TypescriptでのEmitterの付き合い方

きっかけ

TypeScriptをやるようになって、EventEmitterでどうも引っかかりを覚えた。
どうするべきか悩んだ挙句、やっと答えっぽいものが見えてきたので、まとめる。

TypescriptでのEmitterの付き合い方

環境

まずは、環境情報

> npm -v
4.0.5

> ver
Microsoft Windows [Version 10.0.15063]

ちなみに、エディターは、VisualStudioCode使ってます。
コードの参照先の検索や、定義に飛ぶのが他のエディターより楽だったので、コイツに落ち着きました。
できれば、リファクタリング機能が増えてくれると嬉しい。

Visual Studio Code - Visual Studio

package.json

{
  "name": "emitter",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/node": "^7.0.13"
  }
}

tsconfig.json

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "noImplicitAny": false,
        "sourceMap": false
    }
}

本題

よくある紹介記事

下記の内容の紹介をよく見かけると思う。

import { EventEmitter } from "events"

class EmitSample extends EventEmitter {

    constructor() {
        super();
        this.on("onTest", () => {
            console.log("on event");
        })
    }
}

const es = new EmitSample();
es.emit("onTest");

この例では、EventEmitterを継承して、コンストラクタで"onTest"イベントを監視する。
インスタンス作成後、emitでイベントを発火させている。
当然、コンパイルして実行すると下記のようになる。

> tsc EmitSample.ts
> node EmitSample.js
on event

しかし、これだと、開発していくうえでかなり問題がある。
それは、どこからでもemitできる点。
これを許していると、イベントを消したいときなんかは、grepをかけて検索する必要があります。
あと、許容される範囲がデカすぎて、Typescriptで想定される大規模開発をしていると、すぐにカオス化する。
いわゆるスパゲッティコードが簡単に出来上がる。
コンパイルで気づけないの点も非常に厄介です。
Typescript使っているから、コンパイルで気づけるって思っていても、コンパイルエラーにならないので、あとで爆発する。
今まで積み上げてきた努力の時間が無に帰る。
キラークイーンのバイツァ・ダストぐらいの威力があるに違いない。

対策としては、公開範囲を極小化すること。
具体的には、下記のようにする。

import { EventEmitter } from "events"

class EmitSample {

    private emitter: EventEmitter;

    constructor() {
        this.emitter = new EventEmitter();
        this.emitter.on("onTest", () => {
            console.log("on event");
        })
    }

    onTest() {
        this.emitter.emit("onTest");
    }
}

const es = new EmitSample();
es.onTest();

継承しなくなったことで、直接emitが呼び出せなくなる。
また、こうすることで、インスタンスに対する操作を提供する形になり、呼ばれたらどうなるのか明確化して、ある程度コントロールができるようになる。
不正なイベント呼び出しもできなくなるので安全に開発ができるようになる。
イベントが不要になったら、関数を削除するので、コンパイルでキチンと弾かれる。

これは、EventEmitterでよく再現されるObserverパターンでも導入可能。
なるべく公開範囲が小さくなるように作るのがコツだと、最近感じ始めた。

以上、終了。
最近は、Typescriptでオーバーロード使うべきか悩んでいる。
あと、ジェネリックスの適用方法も。
もう少し考えがまとまったら投稿予定。

TypeScript関連記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

平成２９年度春季データベーススペシャリストの受験後の感想

午前

たぶん、大丈夫。
分からん問題は２，３問くらいやったし。
過去問も８割近い正答率になってたから大丈夫だろう。
ちなみに、午前Ⅰは免除でした。

午後

Ⅰ、Ⅱ、共に壊滅的。。。
まず、問題が意味分からん設問がいくつかある。
「これには問題がある」その問題とはなにか？って意味が分からん。
問題出す側が問題を聞いてくるってどういうこと？って思ってしまう。
指摘するからには、問題わかってるんじゃねーの？って気になる。
時間が足らずに最後は、適当に書いたわ。。。
６割ギリギリいけるかどうかだと思う。

反省

反復して学習ができてなかった。
特に午後問。
過去問を一回目を通して終わってた気がする。
午前は、そのかわりしっかりやってたな。
回答方法が簡単だからかもしれないが。。。
午後問って、専用の回答容姿がないと回答が書きづらいんだよね。。。
その問題があって、なかなか問題やろうって気にならなかった。

あと、推移的関数従属と部分関数従属をよく理解してなかった。
問題にあって、結構詰まった。
逆に、隔離性水準は完璧に覚えて追った。
利用できる箇所が１回あった気がする。
次回は、正規化、関数従属についてよく復習しておこう。

次回に向けて

試験対策ブログの充実と対策サイトに目を通す！

データベーススペシャリストドットコム

suzaku-tec.hatenadiary.jp

Macで各種バージョン確認まとめ

なるべく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のバージョンによっては、実施方法に差が出るので、一応載せとく。

やり方

プロジェクト作成

兎にも角にもプロジェクト作成が最初の仕事。

1. Xcodeを起動して、Create a new Xcode projectを選択。
2. Single View Applicationを選択してNext
3. Languageをswiftにして、後はテキトーに入力
4. 保存するディレクトリを選んでcreate

StoryBordの削除

SwiftはStorybordを使って、部品の配置を決める。
しかし、WebViewは部品一つしか必要ないので、あっても意味が無いので削除する。
※とくに削除しなくても問題ないので、飛ばしてもいいかも？

1. Xcodeのサイドバーの"Show the Project navigator"を表示
2. 一番トップにある、プロジェクト名のファイルを選択
3. General > Develop Info > Main Interface の内容を空にする
   こいつで参照するStorybordを決めている。
4. 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
    }

やっていることメモ

1. ベースとなるウィンドウのインスタンスを生成。
2. ベースとなるViewControllerを生成。
3. 1.で作成したwindowの一番上位のViewConntrollerにUINavigationControllerを指定。
   さらに、そのUINavigationControllerの一番上位のViewConntrollerに、2.で作成したviewControllerを指定
4. 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を使ったアプリには、可能性を感じる。
ネイティブ側の問題が発生すると死にそうだけどね。。。

参考サイト

iOSでガワネイティブ - Qiita

swift - How to add a navigation bar to WKWebView? - Stack Overflow

SwiftでWKWebViewを使ってみた - Qiita