現役プログラマーの僕が選んだ格好いいプログラミングTシャツ5選
佐伯です。好きな飲み物は水です。
プログラムを仕事で書くようになってもうすぐ一年。そろそろ歴代のプログラマが必ずしも通るある欲求が抑えられなくなってきました。
プログラマーっぽいTシャツ着て、コード書けるアピールしたい
あれ？みんな思わないですかね
こんなのとか
こんなのとか、シンプルでかっこいいじゃないですか
かっこいいじゃないですか（二度目）
ということで、個人的に欲しいシャツを挙げていきます。
それではどうぞ
１．バグじゃないです。仕様です。Tシャツ
生けとし生きる全てのエンジニアが欲しいであろうこのTシャツ。
これで責められることはありませんね。
２．それはバックエンドの問題ですTシャツ
クライアント側のエンジニアが安全に生活するために役立ちます。
私も欲しい。
３．万能になった気がするTシャツ
４．挫折しそうな僕を助けてくれそうなTシャツ
成功するまで続けよう、というニュアンスですね。日本語訳にいちいち味を感じます。
５．子供との意思疎通の為に
抱っこしているときは授乳しろ。そうでなければ遊べ。
肝に銘じます。子供居ないけど。
学問とドラマは最悪の組み合わせだと思う
どうも、佐伯です。
個人的にびっくりしたニュース。141 万部の大ベストセラー、アドラー心理学を解説した入門書【嫌われる勇気】が2017年1月のフジテレビ木曜劇場（木10）にて刑事ドラマとして放送されるらしいです。入門書が刑事ドラマです。なかなか新しい組み合わせですよね。むしろそこに勇気を感じます。
https://www.amazon.co.jp/exec/obidos/ASIN/4478025819/pp2203-22/
【嫌われる勇気】を半ページに要約するとこんな感じ
この本、僕の思い出の1冊でもありまして、今の自分に大きく影響を与えた本なんですね。ある哲学者と青年の対話形式で進んでいくもので、ざっくりまとめると「人は今この瞬間から幸せになれる。幸せとは、人に嫌われること（を恐れない自分の態度）だ」って感じです。誤解を招きそうな表現なので簡単にポイントを上げると
原因論ではなく、目的論を推奨する
原因論：過去が自分を決定づける
目的論：今の自分が過去に意味を付ける
過去の出来事によっていま自分が〜できない、という考え方では、事実として永遠に過去に縛られることになる。なので目的論に基づき、過去の出来事を自分を守る盾にせず、今の自分が何をするかに焦点を当てたほうがよいとする。
すべての悩みは人間関係
他者との比較やコミュニケーションの問題＝すなわち人間関係が悩みのもとであるということ。それを解決するために以下の3つで構成される人生のタスクという概念と向き合い続けることが大切
・仕事のタスク：仕事上の人間関係
・交友のタスク：友人との距離
・愛のタスク：恋愛、親子関係
対人関係のスタートは課題の分離
↑に向き合うため、対人関係の入り口として課題の分離という作業が必要。「自分の課題」と「相手の課題」を分けて、相手の課題には絶対に介入してはならない。
対人関係のゴールは共同体感覚
共同体感覚は以下の3つの概念で構成されている
・自己受容：今の自分をそのまま受け入れる
・他者信頼：無条件に相手を信じる
・他者貢献：他者や、共同体（社会などの集団？）に貢献すること
共同体感覚をもつこと＝幸福であるということ。
「私は誰かの役に立っている」という主観的な感覚こそが、貢献感（＝幸福）となる。
人生の嘘ってのがある
人生のタスクをから目をそらさせる外的要因を人生の嘘と呼ぶ
・他者の課題に介入しようとすること
・原因論
・承認欲求など
・嫌われることを恐れる
これらの嘘に惑わされず、今この瞬間を生きる（人生のタスクと向き合い続ける）勇気を持てば、事実上（定義のうえでは）今この瞬間から私たちは幸せになれる。
ものっそいざっくり書きましたが、幸せ、自由、人生っていう凄いふわふわしたバズワードを、ロジカルに言語化してくれた本は僕にとっては初めてで、内容的にも腹落ちできる本でした。一読の価値はあるとおもいます。おすすめ。
学問と物語は相容れないと思うんす
このドラマ化の話、知ったのは最近なのですが、知ったときからものすごくモヤモヤしてたんですね。最初は「好きな作品が実写化されたときのあの憂鬱な感じ」だと思ってたのですが、なんかそれとは近くとも何か違うことに気づきました。単純に表現方法としてドラマ（物語化）ってそぐわないと思うんですよ。
嫌われる勇気のもとになった「アドラー心理学」。名前の通り学問なんですよね。どの学問でもそうだと思うんですが、学問って終わりの無い歩みみたいなもんじゃないですか。
数々の人間が何百年もの間、議論と検証を重ね、こうすれば社会良くなんじゃね？という知恵を断片だけ抜き取って、「これでドラマがハッピーエンド（バッドエンド）になった〜」っていうのは、ちょっとあんまりだと思うんです。進研ゼミの漫画じゃねえんだし。
そんなこと言ってたら何も見れないよ〜って意見もわかるんですけどね。。。
やっぱり好きな本だからかな。銀魂ファンもこんな感じなんだろうか。
おわります。
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
