【Swift入門】ディクショナリから値を取り出すときに順番がバラバラになって驚いた

iOSアプリを仕事で作ることになったのでSwiftを始めました。

その中で、勉強したことと少し驚いたことをメモしていきます。

タイトルの件は中盤辺りに書いています。

ちなみに僕は、Objective-Cを2年位前に本1冊終わらせたくらいで、

iOSアプリに関しての知見は殆どありません。

変数・定数・配列・ディクショナリ（連想配列）の宣言と初期化

上記ではそれぞれの型を指定して宣言・代入をしていますが、

型の指定は省略することができます。

var variable = 10  //Int型になる

省略した場合、自動で型を推測して実装してくれます（型推論）。

※Objective-Cではできなかった模様

ループと配列・ディクショナリの操作

一般的で分かりやすいですね。

forの条件式の部分に（）を付けることもできます。

驚いたこと

これが本題です。

上記のような方法でディクショナリから値（キー）を取り出すと、

1,青木さん

2,佐藤さん

3,鈴木さん

ではなく、

2,佐藤さん

3,鈴木さん

1,青木さん

のように、

初期化していた順番とバラバラになって出力されたりします。

※順番通りに表示されることもあります。 

これはSwiftの仕様のようで、

 Unlike items in an array, items in a dictionary do not have a specified order.

訳：配列内の項目とは異なり、ディクショナリの項目は指定された順序を持っていません。

と公式ドキュメントに記載されています。

知らなくて、何とかしようと頑張ってしまった。。

関数（func）

Swiftの関数は「function」ではなく「func」と表現し、

戻り値を返す場合「->」を使って型を指定します。

また、引数に初期値を設定することもできます。

タプル(tuple) 

タプルとは、複数の値（型が違くてもok）を1つにまとめられるものです。

配列とはまたニュアンスが違います。

実際にコードを見た方が分かりやすいです↓

便利そうですが、後から要素を追加したり削除したりはできないようです。

Swiftの暗黙のルールとか空気感

ここまで変数の宣言を「var」で行ってきたのですが、

基本的には「let」を使って定数にし、

変数が必要な部分のみで「var」を使うってスタンスが良いみたいです。

あと、変数の宣言で使う型の指定ですが、

基本的には省略しちゃって良いような空気をググってて感じました。

確かにXcodeが変換してくれるとはいえ、

いちいち「String」とかタイプするの面倒。。

この辺りは賛否両論ありそうですが、

ベターな書き方が分からないので、しばらくは他人が書いたコードを読んで修行あるのみです。

今後も覚えたことや、気づいたことなどをメモしていこうと思うので、

興味のある方はまた来てください。

詳細! Swift iPhoneアプリ開発 入門ノート Swift 1.1+Xcode 6.1+iOS 8.1対応

「ザ・ファシリテーター」を読んだら仕事で使えそうなフレームワークがあったので紹介するよ

読んだのはこれ↓

「ザ・ファシリテーター」

ファシリテーション（ファシリテーター）とは？

簡単に言うと、MTGとかコミュニケーションを

スムーズかつ効率的に進めるための魔法（スキル）です。

IVSとかのカンファレンスで出てくる「モデレーター」と似ていますね。

「モデレーター」は

その場をスムーズに予定通り進行させるアナウンサーのような役割で、

「ファシリテーター」は

ブレストとかMTGを捗るようにハックするコンサルタントのような役割だと認識しています。

書籍に出てくるフレームワークを紹介

とにかく議論やコミュニケーションを円滑に進めるための方法が満載です。

課題を解決するための具体的なフレームワークが随所に出てきます。

ジョハリの窓

自分や他人を理解するプロセスを

窓のように分けて図解する考え方のモデルです。

引用 :Wikipedia

Ⅰの窓をⅢに広げる（Ⅲを狭くする）＝ 自己開示

自信満々の人が弱みをさらけ出すのは、

自信があるから弱みを出せるのではなく、

弱みを開示することで自信を獲得している。

自己開示をすると自信を得ることが出来るそうで、因果関係が逆なのですね。

SWOT分析

• Strengths（強み）
• Weaknesses（弱み）
• Opportunities（機会）
• Threats（脅威）

の頭文字を取ってSWOT.

周りの環境要因としての機会と脅威、

内部要因としての強みと弱みを

マトリックスに落として分析する手法です。

引用:看護師のリーダーシップ開発

これを行うと、問題意識が 深く共有され、

さらには建設的な意見が増えるようです。

フォースフィールド分析

達成できていない課題に対して、

何の「力（フォース）」が邪魔をして達成できないのか、

あるべき姿を妨げている「力」を見える化する手法。

付箋などにひたすら書き出したら、

それをグルーピングして議論するのが通例のようです。

まとめ

他にも、パレート分析とかタックマンモデルとか、

スノーフレークと呼ばれるアイスブレイクなど色々登場して面白いです。

僕はエンジニアなので、

すぐに紹介したフレームワークを使うことはなさそうですが、

頭の片隅にでも置いておきます。

少し前に読んで感想を書いた「V字回復の経営」と同じで、

内容が小説テイストになっています。

そのおかげか、非常に読みやすいのでオススメです。

ザ・ファシリテーター

GWちょー暇という非リア充にオススメする7つの名スライド

ゴールデンウィーク暇過ぎる！

という非リア充な方のために、

僕が今まで読んで感動したスライドをまとめました。

本を読むのはちょっと、、

という方にはちょうど良いボリュームだと思います。

グロースハック系

クックパッドのグロースハックについて

クックパッドのグロースハック事例についてです。

30ページくらいから本題です。

 君にグロースハックはいらない

マイクロソフトでエバンジェリストをしている馬田さんのスライドです。

始めのうちはスケールさせようとするより、

PMF（プロダクト・マーケット・フィット）が大事だよと言っています。

技術者向け

エンジニアのための経営学

あくまでも、技術（プログラミング） は手段だと言う話です。

技術好きな人ほど読んだ方が良いかも。

UIの話は会議室でするな

17ページに出てくる「関係なさそうな人にも聞こえるくらいの声量で話す」、

これは結構重要だと思う派でして。

何故かと言うと、そうすれば他の人の耳に入って、

何かおかしいことを言った場合orその人の方が詳しい場合、突っ込んでくれるから。

そんなのウルサイから止めてくれとか賛否両論ありそうですが、

新人が多い環境とか、コンセンサスを多く得なければいけない環境には向いていると思います。

WebエンジニアのためのWebサービスデザイン実践講座

エンジニアの人もデザインが出来た方が楽しいよという内容です。

そして、具体的なデザインの考えた方も学べます。

キャリア系

転職基準-スタートアップへの転職を検討するための予備知識

上述した「君にグロースハックはいらない」を書いた馬田さんのスライドです。

この人のスライドは本当にためになるので、他のスライドも読んでみてください。

ちなみに、よくY Combinatorのポールグレアムが登場しますw

 私のキャリアチェンジ

最後は、ご存知伊藤直也さんのスライドです。

自分の好きなことが得意なこととは限らないというお話です。

おしまいです。

他に良いスライドあったら教えてくださいm(_ _)m

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

プログラミングとかウェブでよく出てくる小難しい英単語30選

よくプログラマー（エンジニア）は、

数学が得意な人じゃないと出来ないとか言われたりしますが、

個人的には数学というより、

英語が出来る（好きな）人の方が有利だと思っています。

だってプログラミングってコメント以外英語ですし。

「なでしこ」とかはありますけどｗ

僕は学生時代、どちらかと言うと数学が苦手なタイプでしたが、

英語はわりと出来る方でした（というか好きだった）。

もちろん、数学も出来た方が有利に決まっていますが、

普通にご飯を食べていく分にはそんなに必要無いと思います。

ということで、

英語の意味を理解すると、仕事が更に捗るんじゃないかと思いまして、

プログラミングとかウェブで出てくるけど、

ちょっと意味が分かりづらい英単語30個をまとめてみました！

プログラミングで出てくる英単語30選

英単語	読み方	意味
allocate	アロケート	割り当てる
attr（attribute）	アトリビュート	属性
bind	バインド	結び付ける
component	コンポーネント	部品、構成要素
description	ディスクリプション	説明
exception	エクセプション	例外
exec（execution）	エグゼック	実行
extend	エクステンド	拡張する、継承する
extract	エクストラクト	抜き取る
fatal	フェイタル	致命的な
fetch	フェッチ	取ってくる
function	ファンクション	機能
grant	グラント	付与
ignore	イグノア	無視する
implements	インプリメンツ	実装する
init（initialize）	イニット	初期化する
instance	インスタンス	実体
invalid	インバリィド	無効
notice	ノーティス	予告、通知
parse	パース	構文解析する
prefix	プリフィックス	接頭語
prepend	プリペンド	先頭に追加する
previous	プリヴィアス	前の
render	レンダー	表現する
state	ステート	状態
static	スタティック	静的
swap	スワップ	交換
syntax	シンタックス	構文
temp（temporary）	テンプ	一時的な
validation	バリデーション	検証

※2015/4/22 追記

• instanceのスペルミスを修正
• implementsの意味を「実装する」に修正
• noticeの意味に「通知」を追加

implementsは非常に勉強になりました！

もう忘れることは無いと思いますｗ

ご指摘頂いた皆様、ありがとうございました！

まとめた結果

.

..

...

英語の勉強みたいになった。

暗殺教室 殺たん (JUMP j BOOKS)

【Linux】サイズの大きいファイルはお前だ！消してやる！

タイトルの通り、

ストレージ内で容量の大きいファイルを見つけて削除する、Linuxコマンドをまとめました。

環境はAWS(EC2)でCentOS7です。

CentOS7の構築については、

少し前に書いて何故かとても読まれた過去記事を参照してください。

ぶっちゃけ簡単だし、

ググればこの手の類はいくらでも出てくるのですが、 

念のため備忘録としてまとめておきます。

メールのキューが溜まっている場合は以下で対応。

あんまり無いと思うけど。

これで今後忘れてもググらずに済むはず。

ログとかのファイル削除に関しては、

定期的に消すシェルなどの仕組みを作るのが1番良いですね。

Linuxコマンドライン入門　1日目 (ネット時代の、これから始めるプログラミング（NextPublishing）)

「会社を変える分析の力」を読んで"分析"の本当の意味を理解したかも

読んだのはこれ↓

「会社を変える分析の力 (講談社現代新書)」

書籍自体はページ数も少なく、割りとサクッと読めます。

ちゃんとした読書感想の投稿は、「V字回復の経営」以来約3ヶ月ぶりです。

読んだキッカケ

最近、社内の人に「◯◯のデータ出してよ」とよく依頼されます。

で、僕は「はいはい分かりましたよっと」みたいな感じで渡すのですが、ふと感じたのです。

今渡したデータって本当に役立ってるのかな？

そんな矢先に、僕がNewsPicksでフォローしているドコかのエライ人が、

今回紹介する本をオススメしていました。

本書が訴えていること

分析の価値

とにかく一貫して、意思決定に使われない分析は価値が無いと書かれています。

もうしつこいくらいに。

本書で言う分析の価値の定義↓

「分析の価値」＝「意思決定への寄与度」×「意思決定の重要性」

データ分析の成果は、報告書の厚みでも、高度な分析手法でも、データの規模でも無く、

何が分かったか、それは意思決定にどう役立つのか、それだけ。

分析モデルの前提

例えば、ビールの出荷量は気温に影響すると考えた場合、

 「月間ビール出荷量＝ａ×月間平均気温＋ｂ」

というモデルになります。

しかし、この場合、

1. ビール出荷量に対する湿度や休日数の影響は無視している。
2. ビール出荷量と気温の非線形な関係は無視している。
3. 当月のビール出荷量に対する前月気温の影響は無視している。

ということになります。

つまり、やろうとしている分析で、

何を捨てているのかを忘れないようにしないといけません。

この前提がひっくり返ったら元も子も無いですからね。

"分析"の範囲

「分析した結果こういうことが分かったね！」で終わりではなく、

得たデータをどのように使わせて、会社にどのような影響を及ぼしたかまでが分析とのこと。

フォワード型分析者になろう

上述したことに繋がりますが、

本書では、データ分析だけ行う分析者のことをバックオフィス型分析者と呼んでいます。

逆に、自ら分析するべき課題を見つけ、実際に分析し、データを使わせるところまでやる分析者のことをフォワード型分析者と呼んでいます。

分析にフルコミットするのではなく、その前後にも手を広げていける人が、データ分析でビジネスを変えられる人と書かれています。

まとめ

データ分析（者）の定義がガラッと変わる1冊でした。

僕は純粋なデータ分析者ではないのでまだ良いのですが、本職の人が読んだら結構意識が変わるんじゃないですかね？

本職の人にこそ読んで欲しい本です。

少なくとも僕は、次また「◯◯のデータ出してよ」と言われたら、

そのまま結果だけ返すのではなく、「何に使うのですか？」と聞いたり、

「それだったらこっちの方が良くないですか？」とプラスαで返せるようにしたいです。

会社を変える分析の力 (講談社現代新書)

新入社員は最低1ヶ月弁当を持ってくるな！

もうすぐ4月ですね。

4月と言えば、新卒の方をはじめ、入社される方が多い時期です。

そんな方に上から目線でアドバイスします。

最低1ヶ月は弁当を持ってくるな！

理由1（初日）

まず初日は、おカタイ企業では無い限り、歓迎ランチ的なものがあると思います。

このときに「ぼく弁当持ってきてますので」なんて言えないでしょ。

理由2（2日目）

2日目は、会社の人が弁当派なのか外食派なのか確かめます。

初日は、歓迎ランチのために、弁当を持ってこなかった人もいるかもなので。

理由3（3日目）

2日目に確認したので、弁当派と外食派の比率が分かります。 

とは言え、外食派が「0」ということは経験上滅多にありません。

なので、3日目は外食派の人と一緒にランチに行きます。

この辺りで、「皆さんは大体何時くらいに出社するんでかねー」 みたいな質問をしておくと良いかと。

理由4（4日目以降）

4日目以降になると、緊張もほぐれてきて、色々な部分に目を向けられます。

ここからは社員の性格を見極めるフェーズに入ります。

例えば、

1. 冗談が通じる人か
2. 趣味は何か
3. 誰と仲が良いか（悪いか）

など。

特に技術職の人は

仕事をしていると仕事以外の話ってあまりしないと思います。

（ウチは結構しますがw）

特にエンジニアとかデザイナーって、黙々と仕事することが多いので、

コミュニケーションを取る機会があまりありません。

一見エンジニアとかは、「そんなに他人とコミュニケーション取る必要なくね？」と思われるかもしれませんが、結構必要になります。

デザイナー（エンジニア）との連携やセールス側のヒアリングとか。

僕はエンジニアとして、今の会社に入社してから1年半ほど経ちますが、未だに弁当を持っていきません。

単純に面倒なのもありますがw

ランチの時間って、お互いにリラックスして話せるので結構良いです。

普段話さないような「本当にやりたいこと」や「得意なこと」などを、さり気なく話せる良い機会なので。

ということで、4月から新しい環境で働く皆さんは頑張ってください。

口べたでも１時間で誰とでも仲良くなれる技術 ランチは１人で食べるな！