Type ‘ViewController’ does not conform to protocol ‘UITableViewDataSource’のコンパイルエラーで必要なメソッドを入れたも関わらず改善されないとき
佐伯です。
UIPickerViewのコンパイルエラーの直し方のメモです
UITableViewDataSourceに必要なメソッドをコードに書いていても下のコンパイルエラーが出るときがあります。
Type "myViewController" does not conform to protocol UIPIckerDataSource
import UIKit
class myViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
var myUIPicker: UIPickerView!
var array = ["hoge1","hoge2","hoge3"]
override func viewDidLoad() {
super.viewDidLoad()
self.myUIPicker.delegate = self
self.myUIPicker.datasource = self
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
//datasourceに必要なメソッド
func numberOfComponentsInPickerView(pickerView: UIPickerView) -> Int {
return 1
}
func pickerView(pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
return array.count
}
}
これは、必要なメソッドを書いていないよ、というエラーなのですね。
いや....
書いてるし？？？？？
Xcodeさん目ン玉無いんすか？？？？
ということですごく激情困惑していたのですが、下記リンクに答えが書いてありました。
Swift3から非推奨の書き方みたいです。
以下で通りました。
import UIKit
class myViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
var myUIPicker: UIPickerView!
var array = ["hoge1","hoge2","hoge3"]
override func viewDidLoad() {
super.viewDidLoad()
self.myUIPicker.delegate = self
self.myUIPicker.datasource = self
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
//datasourceに必要なメソッド（ココを修正！）
func numberOfComponents(in pickerView: UIPickerView) -> Int {
return 1
}
func pickerView(pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
return array.count
}
}うまくいくはずなのに通らないときは、非推奨じゃないか疑おうと思いました。
エンジニアがゼロ秒思考を試して1週間が経過した
佐伯です。
本屋でたまたま見つけた「ゼロ秒思考」という本が凄まじく良かったので、とりあえず実践してみようと決意し1週間が経過しました。
ゼロ秒思考って何さ
この本はもともとマッキンゼーで働いていた赤羽 雄二さんが14年もの間で磨き上げてきた思考法と、そこに到達するための、誰でも簡単に実践できるシンプルなトレーニング方法について解説した本です。
「私は、普通に会話をしたり、本を読んだり、インターネットを利用できるような人は、本来的にみな頭がうよいと考えている。」という序文から始まるこの本は、物事を端的に書かれており、非常に読みやすかったです。ゼロ秒思考とは、筆者の言葉を引用すると、こんな感じ。
ゼロ秒とは、 すなわち、瞬時に現状を認識し、瞬時に課題を整理し、瞬時に解決策を考え、瞬時にどう動くべきか意思決定できることだ。迷っている時間はゼロ、思い悩んでいる時間はゼロとなる。
文字通り瞬時にできることが多いが、もう少し時間がかかる場合もある。それでも、従来に比べて驚くほどのスピードアップとなる。
今、目の前で何が起きているのか、どういう現象なのか、一瞬のうちに判断し、判断したら次の瞬間に進むべき道を複数考え、長所短所の比較をし、即座に方針を決定できるようになる。
おお、なんか強くなれそうだ。
んで、そのために何をすればよいのよ、というと
それは、頭に浮かぶことを次々とメモに書くだけだ。ただ、ノートやパソコン上ではなく、A4の紙に1件1ページで書く。ゆっくり時間をかけるのではなく、1ページを1分以内にさっと書く。毎日10ページ書き、フォルダに投げ込んで瞬時に整理する。それだけで、マッキンゼーのプログラムでも十分に教えていない、最も基本的な「考える力」を鍛えられる
（中略）
具体的には、Ａ4用紙を横置きにし、1件1ページで、1ページに4～6行、各行20～30字、1ページを1分以内、毎日10ページ書く。したがって、毎日10分だけメモを書く。たとえば図のメモのようになる（なお、ここではメモ上の実際の行数ではなく、ダッシュ「-」で始まる項目を「行」と表現する）。
自分がきめたテーマについて、ただ頭に思いついたことをただ書き出すだけ。
ほんと、これだけでいいの？というのが実際のところだけど、これだけみたいっす。
僕は言語化能力が乏しかった
なぜ実践しようかと思ったかというと、ぶっちゃけ自分が何考えているか分からなかったんですよね。分からないので何を伝えるべきかもあやふやで、的を得ない発言が増えて結局伝わらない、みたいな。効率的にコミュニケーションが取れないことがとてもストレスだったんです。
それは行動にも現れていて、思い返すと行き当たりばったりだな、と思うことが結構あるんす。仕事でコード書いてても、「ここをまず確認していればこの作業いらんかったかも」みたいな事を後になって気づくことが頻繁にありまして、そのたびに自分の髪の毛がごっそり抜けるほど悔しい思いをするんですね。ああ、もっと頭良くなりてえ、と漠然と思っていたときにこの本と出会い、半信半疑だけどまあ、やってみるか、と。
具体的になにやってん
・判断に一瞬でも迷ったときに
・自分が「わからない」と感じたときに
・何かもやっとしたときに
・感情が荒ぶったときに
1分間でメモを書く。それを1日10枚（＝10分）。それだけです。
僕の場合、会社のコピー用紙がめちゃくちゃ余っているので、それを使っています。（許可は取ってますｗ）
何を書くの？
1分間の間にテーマを決め、ひたすら箇条書きします。
テーマは以下のような感じで
・現在起きている事象は？
・原因として考えられるのは？
・解決策は？
・その解決策を選ぶ基準は？
・今の話のポイントは？
・〇〇さんはどう思うだろう？
・社長が自分の仕事をやるならどうする？
それぞれのテーマ毎で1分です。思ったことをどんどん書き出していきます。テーマの例をみて「これって普段当たり前に考えていることじゃね？」って思ったあなた、そうなんですよね。 これらは仕事をする上で当たり前に考えられて然るべきなのですが、みんなこれらを整理できていないのではないか？というのが筆者の指摘だと僕は考えています。
整理し、構造的に理解することで、瞬時に適切な判断、説明が出来るようになる。これがメモ書きの目的です。
構造的に理解するとは
・どういう問題が起きていて
・原因は〜〜で
・これから取れる選択肢は〜〜と〜〜と〜〜で
・それぞれのメリット・デメリットは〜〜で
・選択肢を決める基準は〜〜でその理由は〜〜で
・現在足りない情報は〜〜だから
・〜〜すべきだ
etc
のような項目それぞれで事実と自分の考えを洗い出し、ポイントを抑える事です。メモ書きはその為の整理ツールであり、瞬時にそれを行うようになるためのトレーニングツールとしても位置づけられています。
1週間やってみたけど、変化はあったのか？
最初の方はまったく何もかけなくて、以外に10枚ってキツイんだな、という印象でした。それでも1週間経つと、ある程度マシなメモになっていきます。なんとか継続した結果、ざっと以下の変化が見られました。
・物事を構造的に理解しようとする癖がついた
何かあったとき、いま考えられていないのはこのあたりかな？と考える癖がつきました
・どう伝えればいいのか、のゴールをぼんやり実感できるようになった
いままでのように闇雲に話すのではなく、こうすればもっと上手く話せたな、というゴールがわかった気がしました。
・ブログを書くスピードと苦しみが半減した
要点をメモ書きしているので、ほとんどストレス無い上に結構さっさと書けちゃうので、この辺りはすごく実践してよかったと思う変化ですね
ここはあまり盛っても意味は無いので、ぶっちゃけて書くとこんな感じですね。この3つは今まででは無かった変化でした。
現時点での不満なところ
・メモを書いた後に「箇条書きで全部挙げられていない感じ」が残る
全体を構造的に理解する、と言えど、結局自分が考えられるレベルでの全体感に過ぎず。まだ自分の及ばない部分が有るのでは？と疑問です。この辺はやっているうちにきたえられるのだろうか？
・構造的に捉える癖はついたが、自分の処理能力が上がったとは思えない
まだコミュニケーションや日々の仕事で実感できるレベルでは無いですね
・1分で凄い急いで書くので、自分の字がすげえ汚い
自分の問題ですね
とりあえず「早い人は3週間〜1ヵ月で効果を実感できるはずだ」みたいなことが書かれていたので、継続します。この作業、有益だとは思うので。
今回はエンジニアチックな要素まったくなかったですが、色々ブログを見たところ、「エンジニア ✕ ゼロ秒思考」みたいなエントリを見つけることが出来なかったので、そういった視点でも今後定点観測してみても面白いかな、と思って今回このエントリを書いた次第です。
また報告します。
ではまた。
なんでみんな聞く前に調べないの？理由を考えてみた
佐伯です。
これ、実は自分もよくあるんですよね。
仕事している上で分からないがあったときに、時間はかかるけど自分で調べれば分かることなのに、あえてひとに聞いちゃうこと。簡単に聞けるからこそついついやっちゃうんだけど、自分が聞かれると精神状態によってはすごいイラッとしますよね。僕はそういうとき「自分！！！で！！！調べろや！！！！！」って思いながら頭の中で相手に熱湯をかけつつ皮膚を剥ぎ取って精神を落ち着かせています。
ぶっちゃけどっちがいいんだろう
今回はこの現象についてまとめたいです。わからないことがあったとき、①調べずに相手に聞いちゃう場合と②自分で調べる場合のメリット・デメリットを自分なりに書き出してみました。
①わからないことを調べずに相手に聞いちゃう
メリット
・自分は楽だよね
・グループチャットなどで聞いた場合に限るけど、第三者で同じ疑問を抱えているひとも解消されるから役立ってる感あるよね
・↑加えて既知の人にもリマインドという意味で共有できるね
・調べる時間が省けるから、自分の解明までのスピートは速いよね
・なにげない疑問が、実は大きな問題を抱えているケースは結構ある
デメリット
・聞く人の時間を奪っている
・意識の話だけど、自分のことを自分でやる感はないよね
・すぐに答えが返ってくる分、あまり頭に入らなそう
②わからないことを自分で調べる
メリット
・自分で調べた分、忘れないと思う。自分にとっては得。
・他人には迷惑をかけない
デメリット
・もし自分で調べてもわからなかった場合、すごく時間を無駄にした感じがする
つらつら挙げてみてわかったこと
良いか悪いかは場合による
元も子もないですね。
いやあ、前提条件が曖昧でものっそい浅い内容になったんですが、その問題の程度や状況、聞き方によって、聞いたほうが得、自分で調べた方が得なケースがあるみたいです。
結局どうすればいいのさ
とりあえず、とりあえず聞いてみる、という行動は必ずしも悪では無いことがわかりました。ただこのままだと埒が明かないので、今までの自分の経験から、聞くべきケースと自分で調べるべきケースをまとめました。
聞くべきケース
・一人でも多くのひとに共有すべき問題であるケース
・グループチャットや会議中（共有＋新しい視点や議論が生まれる可能性がある）
自分で調べるべきケース
・問題点がわかっていないケース（問題点を特定するための前提知識を持っていないケース）
・聞く相手が何かしらの状況で瀕死なケース
こんな感じですかね。
優しいアドバイスおじさんがいらっしゃいましたら、ご意見いただきたく存じます。
ではまた。
Twitterに何を求めているのか分からなくなった
雑記です。自分でも引くぐらい落ちがない。
私は朝起きてから、ご飯を食べる間、仕事が一息ついたとき、信号待ちをしている時にすらTwitterを開く。長い時は数分だが、短い時は5秒ほどしか開いていない。もちろん内容なんて次の瞬間には忘れてる。
私はうすうす気がついている。コレって無駄な時間なのではないかと。
僕が25年生きてきて一番無駄だった時間が「高田馬場でバイトが決まったんだけど、交通費がかかるから新宿で探そうと思っている」という話を聞いている時間だったのだけど、冷静に考えるとTwitterもそれと変わらないのでは、と最近は感じている。
や、別に無駄な時間を過ごすことに対して批判的な立場を取っているわけではない。効率ばかりが大切ではないと思っているし、無駄（に見えること）を楽しむことが以外に重要だという価値観も備えているつもりだ。
それを踏まえたうえで、なぜTwitterに時間を費やしているのだろう、と思うのである。あのどうやって飛んでいるかもわからない鳥になにを求めているのだろうと。
つまらない原因ははっきりしている。繋がる行為が面倒だからだ。
インターネットのすべてのサービスは人が何かと繋がる為にできている。もちろんTwitterを通して簡単に誰かとつながりをもつことが出来る。私はいつしかそれが億劫になっていったのだ。
今はだれともわからない人の何ともわからないような日常をだらだらと見ている感覚だ。まるでテレビを見ているように。なので興味もわかない。
貧困国で4秒に１人子供が死んでようが対して現実味がなくて心が動かないのと同じである（これは私だけかもしれない）
繋がっていない誰かの日常は現実でない。仮想現実と一緒なのだ。しかし繋がる気がない。しかし今日もタイムラインを眺めるのだろう。
Objective-CにSwiftを組み込むときに必須！Bridging Headerについて
最近は会社でiOSを触っているのですが「いい加減新しいのはSwiftで書きはじめよう」ということで、Swiftをじわりじわり書いています。佐伯です。
やはりSwiftは分かりやすい。というよりとっかかりやすい。
Objective-Cの気持ち悪い[ ]記法よりも、javascriptよりで感覚的にメソッド、プロパティにアクセスできる。セミコロンが要らないのはまだ違和感があるけど
んで、よっしゃ！Swiftでばりばり書くでー！と意気込んでやってみたものの、即大きな壁にぶち当たった。Objective-Cのクラスを使えない。
インポートが必要なわけでもないっぽい。
調べるとどうやらObjective-CのプロジェクトでSwiftを使うにはBridging Header（ブリッジングヘッダー）というファイルを作らないといけないみたい。
なんぞそれ
どのObjective-CクラスをSwiftで利用するかを記載したもの。
一般的には"$(TTARGET_NAME)-Bridging-Header.h"という名前のファイルが使われる。
書き方は他のヘッダーファイルのように"#import"を使い、他のヘッダーファイルで定義されているObjective-Cクラスを取り込むようにする。Objective-CのクラスをSwiftへ橋渡ししてくれるものみたい。
ブリッジングヘッダーの初期設定
・プロジェクトに <# $TARGET_NAME #>-Bridging-Header.h という名前のファイルを追加
・Build Settingから上記ファイルを設定
XcodeのBuild Settingから"Swift Compiler - Code Generation"カテゴリがある。その中に"Objective-C Bridging Header"のところに"$TARGET_NAME"/$(TARGET_NAME)-Bridging-Header.h"のように記載することでブリッジングヘッダーが有効化させる。
例えば、以下のようなヘッダークラスがObjective-Cであったとする。
@interface EZOcject:NSObject
@property(readwrite,strong)NSString *name;
@property(readwrite,strong)NSString *note;
-(id)initWithName:(NSString*)name;
-(id)initWithName:(NSString*)name note:(NSString*)note;
@end
//上記コード：http://program.station.ez-net.jp/special/handbook/swift/class/objc.asp
このようなときにブリッジングヘッダーファイルにEzObject.hをインポートしておけば、このクラスをSwiftで利用することが出来る。
class EzObject:EzObject{
override func textWithString(string:String)->String{
return super.textWithString(string)
}
}
//上記コード：http://program.station.ez-net.jp/special/handbook/swift/class/objc.asp
Kindle Unlimitedが遂に日本上陸！さっそく登録してみた！
ついに....
Amazonが提供するサービス、Kindle Unlimitedが日本に上陸しました。
もともと８月にリリースという情報が回っていたので、昨日一昨日から待ちわびていたのですが、３日の朝、ついにやってきました。待っていたよ...お前を...
Kindle Unlimitedとは
Kindleの電子書籍が月額わずか980円で読み放題、というサブスクリプションモデルのサービスですね。初回30日は無料体験が可能なようです。以下は本サイトから。
うむむ
・幅広いジャンルの本を
・好きな端末で
楽しめる感じですね。僕個人は電子書籍よりも紙派ではあるのですが、 「読み放題」という言葉の強さに惹かれて、今回のリリースを心待ちにしていたのです。定額で〜し放題って、素敵な響きですよね。サブスクリプションモデル、恐るべし。
んで、私自身登録して間もないので詳しいことは書けませんが、さわりの部分をすこし紹介できればな、と思います。
まずはトップ。
当たり前かもしれませんが、Amazonのkindle書籍の階層にありますね。UIも同じです。
ジャンルごとに選ぶことも
以前話題に上がっていた本もちらほらあるみたい
個人的にはインベスターZが有るのが嬉しかったですね。まとめ買いしようか悩んでいたのでｗ
現時点での感想
うーん。まずまず、という感じですね。
ちょっと期待しすぎていたのかな...。
最初の感想は「お、結構ジャンル幅広いし、数も多そうだ。いいかも！」だったのですが、かゆいところに手がまだ届いていないというのが正直なところです。
技術本に関して言えば、他ジャンルを学びたい時にある程度の知識を抑えるだけの本はあるが、クリティカルな１冊がないんですよね。ダイレクトパブリッシングな本も多いですしね。オライリーなどが読める日はくるのでしょうか。厳しいかな。。
ただ、本の数は圧倒的（和書12万冊以上、洋書120万冊以上！）なので、これで月額980円なら買いかな？と思います。面白そうな本を発掘する楽しみはありますね
いずれにしろkindle端末、欲しいなあ。
phpでよく見かける＠とは？
久々すぎて自分のブログが怖い佐伯です。
ときどきphpを開発していて「@hoge = ~ 」のようなものを見かけるのですが、「php @」でGoogle先生に聞いても教えてくれず。。
最近「php アットマーク」で出てくることに気付きました。世知辛いですね。
＠とはエラー制御演算子というもののようです。
例えば
$hoge = $_GET["test"];
という変数を宣言していたとして、そこに
$hoge = ＠$_GET["test"];
とするとエラーがあってもエラーメッセージを表示させないようにできるのだそう。
うーん、ライブラリなんかは余計なエラーを出さないように@が必要なのかもしれませんね。基本的に開発ではエラーは可視化したほうが良いと思うけど...
ということで調べてみるとDB関連の関数で使用することが多いようです。
PHPのMySQL関数はデータベースとの処理でエラーが発生した場合、ブラウザに自動的にエラーメッセージを吐き出すようになっているそう。実際に公開中のサイトにエラーが出るのは好ましくないため、@を使って制御しているみたいですね。
$con = mysql_connect("localhost","mysql","password");
↓
$con = @mysql_connect("localhost","mysql","password");
参考：http://park18.wakwak.com/~little-box/Dreamweaver/sql009.htm
