Calendarの使い方について(Swift4, 2017/12/2)(編集中)
Foundationフレームワークについて
Calendarを使うにはFoundationフレームワークを使うのが便利です。
Calendarを扱うには、主に以下の２つの構造体を利用します。
- Data
- Calendar
構造体については以下のページを参照してください。
[リンク！！]
また、列挙体については以下のページを参照してください。
[リンク！！]
まず、ViewControllerでFoundationをimportしてください。
import UIKit
//Foundationのインポート
import Foundation
class ViewController: UIViewController {
//構造体の初期化をして、変数に格納
//identifierによって、Identifier列挙体を指定し、カレンダーを日本仕様にする
var cal = Calendar.init(identifier: Calendar.Identifier.japanese)
//今日の日付を取得
var date = Date.init()
//画面が最初に呼び出された時の処理
override func viewDidLoad() {
super.viewDidLoad()
//今日の日付から、カレンダーのComponent列挙体を用いて「月」を取得してくることを明示
print(cal.component(Calendar.Component.month, from: date))
}
//メモリがなくなりそうになった時の処理（あんま関係ない）
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
}
EventKitフレームワークについて
CalendarとEventを同時に扱うには、EventKitフレームワークが便利です。
以下公式Documentです。
EventKit | Apple Developer Documentation
これを読み解きつつ、進めていこうと思います。
現在編集中です。 by TakaMTK
Pythonの仮想環境の必要性（編集中）
Pythonの通例
Pythonでは、必要なパッケージ等はグローバル（全てのプロジェクトに適用される）に入れるべきではなく、
プロジェクトごとに仮想環境を設定して、そこにダウンロードすべきです。
なぜなら、Python2とPython3では、互換性がないため、プロジェクトを作成する時には明示的にバージョンを指定したほうが安定するからです。
Pythonで用いる仮想環境
virtualenv
$ sudo pip install virtualenv $ sudo pip install virtualenvwrapper
でインストールができます。
カレントディレクトリに仮想環境を構築する場合は、以下のコマンドを用いて構築します。
$ cd <仮想環境を作りたいプロジェクト> $ virtualenv <プロジェクト名>
ここでは、プロジェクト名をtestとします。
仮想環境を有効化することにより、仮想環境内で作業することができます。
有効にするには、仮想環境内にある、binフォルダーの中のactivateコマンドを実行します。
$ source test/bin/activate
仮想環境から抜け出すには、以下のコマンドを打ちます。
$ deactivate
pyenv
XcodeのプロジェクトをGithubにあげる方法
全体の概要
Xcode、Github、Gitの基礎知識はあるという前提で話を進めます。
- Xcodeのプロジェクトを作ろう！
- ファイルに変更を加えてみよう！
- Commitしてみよう！
- Githubにログインして、新しいリポジトリを作ろう！
- 作ったリポジトリをXcodeに登録してみよう！
- Pushしてみよう！
1. Xcodeのプロジェクトを作ろう！
以下のようにプロジェクトを作成し、必ず「Create Git Repository on My Mac」にチェックを入れてください。
2. ファイルに変更を加えてみよう！
ViewController.swiftのファイルに変更を加えてみましょう。
以下の例では、
var number: Int = 3
を書き加えています。
すると、ViewController.swiftの隣に「M」という文字が出てきました。
これは、ファイルが変更されたことを示す記号です。
3. Commitしてみよう！
次にファイルをCommitしてみましょう。
Xcodeの場合、ターミナルを使わずに、Xcode上でローカルリポジトリにコミットすることができます。
Step1. メニューバーの、「Source Control」を選択 Step2. 「Commit」を選択 Step3. Commitのコメントを入力し、Doneを押す
以下のようになります。
4. Githubにログインして、新しいリポジトリを作ろう！
README.mdは作成しなくて大丈夫です。
新しいリポジトリができたら、次の画面に表示される、HTTPSのURLをコピーしてください。
5. 作ったリポジトリをXcodeに登録してみよう！
Step1. メニューバーの「Source Control」を開く Step2. 「<プロジェクト名> master」となっているところを開く Step3. 「Configure <プロジェクト名>」をクリック Step4. 以下のような画面が出るので、Remoteをクリック
Step5. +ボタンをクリックし、URLを入力する Step6. originのままにして、完了を押すと、以下のような画面になり、登録は終了
6. Pushしてみよう！
Step1. 「Source Control」をクリック Step2. 「Push」をクリック Step3. アカウント情報を入力し、Pushが完了する
Githubの使い方
1. Githubを使ってみよう！
Githubとは、Gitコマンドを用いてソースコードを管理することのできるサービスです。
複数人で開発を行うときに、必ずと言っていいほど用いるので
エンジニアにとって不可欠な技術と言えるでしょう。
1.1. アカウントを作ってみよう！
はじめに、アカウントを作成します。以下のページに飛んで、アカウントを作ってみましょう。
1.2. リポジトリを作ってみよう！
リポジトリとは、自分の作ったソースを管理するための箱です。 この中に全てのソースが含まれます。
2種類のリポジトリがあります。
リモートリポジトリ
ローカルリポジトリ
1.2.1. リモートリポジトリ
リモートリポジトリとは、Github上に保存されたリポジトリです。 つまり、リモートリポジトリこそが、管理すべき対象であり、オリジナルのものです。
1.2.2. ローカルリポジトリ
ローカルリポジトリとは、リモートリポジトリを自分のパソコン上にコピーしてきたものです！
ローカルリポジトリを用いて、自分のパソコン上で開発を行い、変更をリモートリポジトリに書き加えます。
1.2.3. 実際にリポジトリを作成してみよう！
まず、自分のホーム画面に移動して、Repositorysをクリックしましょう！
次の画面でNewをクリックしてください。
すると以下のような画面になるので、リポジトリの名前を打ち込んでCreate Repositoryしましょう。
initialize this repository with a READMEとありますが、チェックを入れておくことをオススメします。
README.mdは取り扱い説明書のようなものです。
リポジトリの内容が複雑になってくると、この中に使い方などを書きます。
さて、リポジトリを作り終わったら、以下の画面になるはずです。
今、READMEファイルだけで構成されたリポジトリが完成したはずです。
2. Gitコマンドを使いこなす
2.1. git clone
まず、先ほどGithub上に作ったリモートリポジトリをローカルリポジトリとして自分のパソコンにコピーしてみましょう。
先ほどの画面のClone or downloadをクリックして、表示されたURLをコピーしてください。
それを、ターミナルを開いて、以下のコマンドを打ち込んでください。
$ git clone <コピーしたURL>
例えば、以下のようになり、git cloneが完了した後にlsによってディレクトリの中身を確認すると、ちゃんとコピーされていることがわかります。
それではcdコマンドで、Testの中に入ってみてください。
2.2. git status
次に、README.mdファイルに変更を加えてみましょう。
ファイルをエディターで開き、#DreamCodersTestの次の行にThis is a testと書き込んでみてください。
これも立派な変更です。
さらに、新しいファイルを作ってみましょう。
dreamcoders.txt(.txtはテキストファイル）を作って、保存してみてください。
その後、git statusをすると、以下のようにちゃんと変更を確認することができます。
modified のあとに書いてあるのは変更されたファイル、 ただファイル名だけ表示されているのが新しく作成されたファイルです。
2.3. git add
git addはgit commit, git pushとセットです。
順序としては、addしてからcommitし、最後にpushします。
順に説明すると、
addによって、指定されたファイルを「ステージ」に上げることができます。
commitによって、addによって指定された、「ステージ」にあるファイルのみをローカルリポジトリに書き込みます。（つまり、ファイルを変更した時点ではローカルリポジトリに変更は加えられていないことになります）
最後に、リモートリポジトリに反映するために、pushをします。
では、まずgit addからやってみましょう。
以下のコマンドを打ち込んでください。
$ git add *
*は、「全ての」という意味です。つまり、git statusによって表示されていた全てのファイルがaddされます。
そして、
$ git status
で、現在の状況を確認してみましょう。以下のような表示になるはずです。
変更されたREADME.mdと、新たに作られたtext.txtがステージに上げられていることがわかります。
2.4. git commit
次に、commitをしてみましょう。
commitによって変更がローカルリポジトリに正式に反映されます。
また、-mコマンドによって、コメントを打ち込むことができます！
以下のコマンドを打ち込んでください。
$ git commit -m "This is a first commit"
git statusと打っても何もファイル名は表示されません。
これはcommitまで終えてローカルリポジトリに変更を保存したので、ローカルリポジトリが最新の状態になっているからです。
2.5. git push
最後に、ローカルリポジトリをリモートリポジトリに保存してみましょう。
以下のコマンドを打ち込みます。
$ git push
これが成功すると、何かデータを送っている感じの文字が表示されれば完了です。
リモートリポジトリが変更されたということは、Githubのサイトから変更が確認できるということなので、先ほど作った自分のアカウントからTestのリポジトリ内をみてみましょう！
以下のようになっていれば完璧です！
ちゃんとREADME.mdが変更され、text.txtが追加されていることがわかります。
2.6. git pull
ローカルリポジトリを作る時、2.1.では、git cloneを使いました。
しかし、cloneが使えるのは、何もない状態の時（最初のだけ）です。
すでにローカルリポジトリが存在する場合は、その中に入って(この例では、DreamCodersTestのフォルダ内で）、以下のコマンドを打ち込みます。
$ git pull
これにより、最新のリモートリポジトリがローカルリポジトリにコピーされます。
これで、Gitの基本の基本は完了です！
企画書の書き方について
初めましてブログを初めて書きます、コウキです。
今回、僕は企画書を書くのが初めてということもあり、企画書を書く際に参考に読ませていただいた本に関しての要約を書きます。
読ませていただいた本のタイトルは「企画術」で、秀和システムが出版していて、富田眞司さんが執筆されています。今回はこの本を参考・引用させていただきます。
図が多い所と、内容がシンプルで読みやすそうに感じたのが選んだ理由です。感想としては最初に感じたとおり、とても読みやすく、企画書を初めて書く人にとっては入門書として、とてもいい本だと感じました。
内容に関しては以下に記述していきたいと思います。
まず、僕は企画書に関して初心者であったため、最初の発見となったのは提案書と企画書の違いで、以下にそれぞれの特徴について自分が知ったことを書きます。
提案書→課題の解決を口頭で説明するアイデアレベルからもう少し詰め、解決の方向までを示したもの
企画書→提案書を更に具体化し、解決方法を実行できる内容にしたもの。「3要素、7ステップ」を全て盛り込んだもの
企画書の構成要素は大きく分けて3つにわけることができる
・「課題を発見する」
・「基本方針を立てる」
・「解決策を展開する」
またそれぞれの要素について更に7ステップに分解できる
「課題を発見する」
・現状分析
・課題発見
「基本方針を立てる」
・目的の明確化
・対象設定
・解決手段
「解決策を展開する」
・実施方法
・費用/効果
次にこのそれぞれの7ステップについて僕が今回学んだことについて書いていこうと思います。
現状分析
主に収集する項目は5つで、以下に示す
- 社会環境: 人口、景気、経済、経営など社会全般に関する情報
- 市場: 提案に関連する商品、企業動向など
- 生活者動向: 使用率、使用者実態など
- 競合状況: 提案に関連する企業間の競争状況など
- 提案先状況: 提案先の問題点など
情報収集
デスクリサーチ→実態調査の順
現状分析・課題を発見
情報収集によって多くの問題点が抽出される。重要な問題点の中から自分達の提案で解決可能なものや他の情報も考慮して課題を発見する。課題はできれば一つに絞り、問題点に挙がった項目全て課題として取り上げても簡単に解決はできない。課題を決める際に用いるのが、SWOT分析で、Strength（内部環境の強み）,Weakness(内部環境の弱み),Opportunities(外部環境からくる機会),Threat(外部環境の脅威)を克服する戦略などを考慮し、可能性を十分検討して課題を決める。
目的・狙いを決める
課題を受けて提案の基本方針を設定する。具体的な言葉で表現する場合と、数値目標で示す場合がある。抽象的な言葉は避けて、なるべく具体的に誰でも理解できるような明確なものとする。
対象設定
対象設定は、性・年代などの属性だけにとらわれず、生活レベル、趣味・嗜好。生き方やライフスタイル、商品とのかかわり、購入意欲なども考慮して決める。←ペルソナ(?)の設定ぽい
提案にふさわしいタイトルをつける
解決策を決め、タイトルをつける。規格書で大切なのがタイトルで、企画に名前をつけることで提案に独自性をもたせることができる。これは同じ内容でも名称によっては訴求力が全く異なるから。独自のネーミングによって、新しい付加価値をつけることが可能。例えば、「クールビズ」、「夫婦50割」などがある。
解決手段
実施プランは項目別に個条書きにまとめると、初めて提案を受けるほうが理解しやすい。実施方法、内容、場所などの説明は、項目別に整理して具体的に行う。3-4項目に整理するのが最適。項目別に見出し、本文に分けて記載する。見出しはわかりやすい短い言葉で要領よく表現し、本文も同様に表現する。
更に項目わけし、表にまとめるとより見やすくなる
大日程と小日程を立て、費用・効果予想を提示する
おおまかなタイムスケジュールが大日程で、提案決定から準備段階までの期間、実施段階の期間、事後フォロー期間など、数項目程度のものを表示する。小日程では更に細かく詰めたもので、スケジュールは縦軸に業務内容、横軸に日程を取り、一覧表にまとめるとわかりやすくなる。最初の企画提案の段階では、大日程を提示し、提案が決まれば、具体的な詳細スケジュールについて詰める。
費用・効果予想
項目別に概算費用を提示し、提示した費用に実施段階で不足が生じないよう、十分な裏付けを取ったものとする。効果予想は裏付けの根拠を明確にし、あくまでも予想であることを明示する。
説得力のある企画書作成のポイント
(1) 長文は極力避け、個条書きにする
(2) 区切りを明確にし、長文は見出しをつける
(3) 見出しは短く、動詞で終わる
(4) グラフ、表、写真、イラストで説得力を高める
企画書→複雑な要素を除いてできるだけシンプルに書く
シンプルな企画書
最もシンプルになると、企画書は1枚になる。１枚という最初のスペースで必要なことを表現するので、一貫性が出しやすく、論理的な企画書が作成しやすくなる。ただし、１枚の企画書だけでは十分意図が伝わらないときには、添付資料として別紙を添える。
１枚の企画書について
1枚の企画書の書き方としては、主に3パターンあり、結論型、論理型、チャート方式論理型である。以下にそれぞれの特徴を述べていく。
結論型
文章による結論を先に述べる結論型企画書のフォーマット（以下の図を参照）。一枚の用紙に企画書としての7項目が名称を変えて入る。
論理型
現状分析から課題を発見するオーソドックスな展開といえる。１枚の用紙に企画書としての7項目を網羅している。盛り込む内容が多くなるため、現状分析は要領よくまとめないといけない。（以下の図参照）
チャート方式論理型
最も要約された企画書のフォーマット事例。現状分析から入る論理型の企画書。横書きで使用する。１枚の紙を三等分し、左が課題設定（現状分析）、中央が基本戦略、右が解決策展開（具体的展開）である（以下の図を参照）。左の課題設定は現状分析から課題の設定までで、中央の基本戦略は(1)目的・狙い、(2)対象、(3)タイトルを含む基本方針、(4)提案・解決策のポイントを並べる。右の解決策の展開は上段から中段にかけて具体的展開を盛り込み、下段に費用・効果を書く。この流れによって提案の起承転結が明確に表現できるので論理的に展開できる。1枚の用紙を三等分することでシンプルで美しい形の企画書に仕上がる。
複数枚の企画書
各ページは1枚で話が完結するように心がけ、もしもボリュームが増えるなら、要約をつける。この場合、要約を使った提案も可能になる。
次回また機会があれば書きたいと思いますが、「企画術」によると以下のことに気をつけることが、早く書く10の企画術だそうです。今回はどんなものがあるかの概要だけ書いて終わりにしたいと思います。最後まで読んで頂きありがとうございます！これからは技術的なことをメインに僕はブログを書いていきたいと思います。どうぞこれからよろしくお願いします！
早く書く10の企画術
- 情報頭、企画頭、まとめ頭の切り替え
- 企画書の段取りが勝負
- 情報収集ノウハウでスピードアップ
- どこにどんな情報があるか、情報源を明確化する
- マイデータバンクが企画力を高める
- 提案に対する効果予測ノウハウを身につける
- 仮設を立て、企画ストーリーを作る
- 最後に企画書を書く
- 独自の企画書フォーマット化で時間短縮
- 万全な体調で企画書を書く
5W1Hを元にしたアイディアの作り方
5W1Hの思考のフレームワークとは？
5W1Hとは、ビジネス、ディベート、ディスカッション、様々な部分で用いられる思考のフレームワークです。
もっとも単純にして、最強のフレームワークだと思っています。
5WとはWhy, What, Where, When, Who 1HとはHow のことであり、１つの問題、課題に対してこれらの問いを繰り返し投げかけていくことで それの本質にたどり着くことができます。
この思考のフレームワークは、日常生活のあらゆる面で使うことができます。
その使用例について考えていきましょう！
5W1Hを用いて効率的にアイディアを出してみよう！
前節では5W1Hを用いることで問題、課題に対する本質的な解決を行えると言いましたが、 5W1Hは効率的なアイディア出しにも役立てることができます。
いささか雑な例かもしれませんが、１つ動物園について考えてみましょう。
例えば、上司に「従来とは異なる、新しい価値をもつ動物園を考えて欲しい」と言われたとします。
さて、あなたならどのようにしてこの問題に取り組みますか？
大抵の人は、考え、思いついたものから挙げていくと思います。
しかし、それだと漏れが出るし、効率的ではありません。
そこで、5W1Hをうまく活用することで、非効率なアイディア出しをより効率的なものにすることができます！ 主に、以下の3つのStepから構成されます
1. 従来の動物園のあり方を考える
2. Whyに対する理解を深める
3. Where, Who, When, Howを変える、逆にする
まず、従来の動物園のあり方をみてみましょう。
- Why ... 動物のもつ魅力を通してお客さんに楽しんでもらう
- What ... 動物を見せる場所
- Where ... 特定の場所で（上野動物園なら上野）
- When ... 日中（普通は午前から日が暮れるまで）
- Who（Whom） ... デートのカップル、ファミリー、学校の遠足
- How ... それぞれの動物を種類ごとに檻に入れて展示
といったところでしょうか。
アイディア出しをする場合、基本的にはWhy と Whatは揺らがないものとします。 すると、変える余地があるのはWhere, When, Whoですね。
どういう変え方をするかというと、まずWhyをよく考えることです。 この場合、動物の魅力でお客さんを楽しませることが目的であるということをよく理解する必要があります。
次に、5W1HのうちのWhy, What以外の要素を変えていきます。 Where ... 特定の場所で とありますが、Whyがお客さんを楽しませるということなので 特定の場所にこだわる必要は全くありません。 まず移動型動物園とか、そういう発想をすることができます。
すると、WhoもWhenもこだわることがないことがわかります。 Whenを日中から夜にすれば、デートで使うカップルはもちろんのこと、 もしかしたらサラリーマンが会社帰りに来るかもしれません。
また、Howも変える余地があります。 実際にある例ですが、猫カフェなどの動物カフェは動物園の本質を変わった形で提供しています。
こういった風に、5W1Hを元に考えることで、 従来とは違った価値のものを効率的に作り出すことができます。
以上！（厚切りジェイソン風）
by Taka MTK
