try! Swift で感じたこと思ったこと
先週、東京で開催された try! Swift に参加してきました。参加者のブログエントリとしてはかなり遅いですが try! Swift 後の諸々の課題が完了して落ち着いたのでそこで感じたことを書いてみたいと思います。気付けば前回のこのブログの更新から1年以上もご無沙汰していたようで、アウトプットが減ったのだなと感じています。
try! Swift
try! Swift のイベントそのものの説明や、そこで話されたセッションの内容などはすでにたくさんの方が書かれているのでそちらを参照してください。特に id:niwatako さんのエントリ群はすごいのでぜひ "try niwatako" でおググりください。
英語
当日は英語のセッションが8割以上で、会場に来ている人も印象としてかなり外国人が多くいました。セッションと Q&A についてはすばらしい通訳があったので特に支障はなかったでしょう。ただ、それ以外の休憩中やパーティーの時（特に Speaker Dinner）には通訳がないため多くの日本人は外国人と話すことを躊躇しているように感じました。一部の方は積極的に話している印象はありました。
そんな中 @koher さんの働きかけで、参加者の中で日英両方しゃべれる人が通訳として動くことで、日本人と外国人で会話をするきっかけを作ったのはすばらしい提案だった思います。
一方でどうして日本人は話そうとしないのかなと考えました。
- 通じなかったらどうしよう？
- 聞き返されたらどうしよう？
このような理由で話すことを恐れているのかもしれない。
でも、僕はこう考えます。英語が話せるか話せないかは重要ではない。"コミュニケーションをとる" ことが重要です。 コミュニケーションとは「お互いが考えていることを共有すること」だと思います。なので海外の人と "コミュニケーションをとる" ≠ "英語を話す" です。海外のカンファレンスでは、当然何かのテーマがあって人が集まっています。一定以上の共通テーマがお互いに存在していることが保証されています。特に開発関連のイベントにエンジニアが行く場合、英語以外にもコミュニケーションを取る "言語" があります。Computer Language です。英語で話せなくても、コードを書けば分かる。ホワイトボードに書けば良い。UMLでもなんでも図を書けば良い。それにエンジニアの場合、毎日のように英語のドキュメントなんかを目にしています。普通の人は知らないような単語を結構日常的に触れていると思います。コードを書くとき、クラス名・変数名は英語ですよね？ ごく一般の人と比べて英語に触れる機会は多いのだからなんとかなります。大事なのは姿勢。街中でいきなり外国人に話しかけても普通は気持ち悪いと思われるだけだけど、幸運にもその手のカンファレンスでは、僕らの話す内容を聞いてくれようとしてくれます。これは絶好のチャンスです。僕はたぶんかなり間違った英語を使ってるはずです。それでも、それなりに言わんとしていることは通じているとが感じます。
母国語で書かれている文章だからって全部理解できるわけはないですよね？母国語で話された内容が適切に伝わるってこともないですよね？それが出来ていたらみんなみんな医者でも弁護士でも政治家でもなんでもなれる気がします。業務の中でもコミュニケーションロスなんて発生しないはずです。 でも実際には母国語を使っていても伝わらない事なんて日常です。だから英語をしゃべって外国人に伝わってなくてもしょげることは全くないです。そんなときは、言い方を変えてみたらいい。言いたいことの直訳にあたる英単語が浮かばなくても、そこで思考停止しなくていい。言いたい単語を説明するような発言をすればいい。
自分が考えるコツ
- 大きな声で話す
- 単語が浮かばなくても気にしない
- 抑揚・強弱・リズムを英語風に
聞き返されるときの大半は単純に声が聞こえてないだけなように感じます。大きな声で話すだけでも聞き返される回数は減ると思います。 単語が浮かばなければ、言いたいことを別の言い方で説明すればいいと思います。 英語はダイナミズムに溢れた言語です。日本語っぽく抑揚がない平坦な話し方よりも、それらしいイントネーションで話すだけで大分伝わりやすくなります。
まとめ
昨年から海外出張を含め外国人と話す機会が多いなか、いつも折角の機会なのに外国人に話しかけないのはもったいないなぁと思っていました。try! Swift に参加したきっかけに久々のブログエントリにしました。
英語を積極的に話せるとエンジニアとしてまだまだ武器になるのでは？と思いました。僕自身もこの事を忘れずに英語力を上げていきたいと思います。
Atom から RedPen を簡単につかう Package を作りました
GitHub がメインで開発しているエディタ Atom の Package redpen を作りました。
RedPen とは
普段僕は Objective-C で iOS アプリの開発をしています。Objective-C のようなコンパイル言語で typo した場合にはコンパイルエラーがでたり、型を謝ったコードを書いてると警告がでたりすることで事前にミスを防げているわけです。RedPen は自然言語を書いている時にもそれに近いものを得るために作られた自動文書検査ツールです。詳しくは gihyo.jp で連載されているこちらを見ていただいた方がわかりやすいと思います。
Atom Package を作った理由
仕事で書く文書ではアルファベットの前後にスペースを入れるような基本ルールがあって、最近はよくそのレビューを任されることがあり結構面倒な作業でした。そんなときに RedPen の事を知ったのは凄くうれしかったのを覚えています。でも、僕は Terminal の操作が苦手です。このような環境で文書のチェックのために Terminal を開いてコマンドを叩くのは億劫です。自分でブログの記事を書くときには Mou や Atom を使って Markdown で書いています。このような時も同様です。どうにか自分が楽に使いたい。RedPen のようなテキストのチェック機能はエディタに備わっているべきだと思い、ちょっと書いてみようと思いました。
エディタに元々 RedPen の機能があるものは当然ながらなかったので自分で拡張を作る必要がありました。拡張機能の開発がサードパーティでできるエディタとして浮かんだものは以下のようなものです。
この中で自分が使っているのは Sublime と Atom だけです。Sublime は Python で拡張を書く必要があります。Atom は CoffeeScript (JavaScript) です。どちらもほとんど触ったことがない言語でした。1番大きかったのは JSONLint の拡張(Package)を Atom で使っていてその UI や使い心地が気に入っていたところです。この Package と同じような作りにすればできるんじゃないかと思ったので Atom Package として書くことにしました。
redpen Package でできること
基本的な使い方はここの Usage を見てもらうと大体わかると思いますが、以下のような感じです。
- RedPen CLI のインストール
- 現在 Homebrew でインストールできるようにするための formula が PR 中
- redpen package のインストール
- RedPen CLI のパスを設定
- Configuration XML の作成とパスの設定
- 未設定の場合、僕が用意している日本語向けのデフォルト Configuration XML を使います
- JAVA_HOME のパスを設定
使い方
適当な
- Markdown
- Textile
- Plain
ファイルを Atom で開いてもらって
- コマンドパレット(⌘+Shift+P)を開いて
RedPen: Validateを実行 ⌘+ ⌥ + oを押す
いずれかを実行してもらえば実行結果がエディタ下部に表示されます。問題が検知された場合にはレポート部分をクリックすると該当行にジャンプします。
redpen package の設定画面で Validate on save を有効にすると保存時に実行してくれるので便利かと思います。
まとめ
RedPen というツールは日本語文書を書く人にはとても有益なツールだと思いますのでぜひ1度使ってみてください。その際に redpen package も使ってみてもらえるとありがたいです。
プレゼンするときに気をつけたいと思ってるたった3つのこと
id:yashigani が良いこと書いているなぁと思った。
[yashigani days] プレゼンするときに気をつけてるたった3つのこと
僕もプレゼンや人前で話す事について思うことがあったので便乗エントリ。
声を大きく
すごい普通で当たり前のことです。けど、勉強会とかに行くとせっかく、おもしろいこと、凄いことを話しているのに声が小さくて聞こえにくいことがあります。もったいないので声は大きくはっきりと話したいです。大きくはっきり話す事で自信をもって話しているような印象を与えるので聴衆も聴こうという気になります。
「え〜」「あ〜」とか言わない
話出す時に頻繁に「え〜」とか「あ〜」とかを言う人がいます。話す側としては間が空くのが怖いとか勢いをつけるために言ってしまいます。僕もよく言っています。でも、あれが頻繁に聞こえてくるとそればかりが際立って聞こえてきてしまい本来の内容が耳に入ってきません。もったいないので極力言わないようにしましょう。間を恐れてはいけません。むしろ間を恐れて言葉で埋めてしまうと早口にもなりがちですし、プレゼン内容にメリハリがなくなります。「間はメリハリだ」と思い込むくらいの気持ちでちょうどいいのかもしれません。
Demo をどこでいれるのか考える
技術系のプレゼンをやっているとデモを披露することが多いと思います。単純に内容説明だけならブログで十分かもしれません。せっかくプレゼンという形をとっていますし会場に来てくれた人にはブログを読む以上に得るものがあるかもしれないので良いことだと思います。ただ、一つのプレゼン内に数回デモを挟むのはリズムが悪くなる印象があります。たいていの場合デモってワタワタしてしまっています。プレゼン資料とデモとの切り替えがもたついたり、通信環境の影響で待ちができたり。デモの数を絞ってプレゼンを一通り行ったあとの方が聴衆にとっては振り返りになります。またプレゼン部分で時間的に押していたり巻きが入っていてもデモが最後であれば調整を行いやすいです。そのまま質疑応答も行いやすいのでデモを入れるタイミングを合間にいれるのか最後に入れるか検討してみましょう。
まとめ
特にテクニック的な話でもなく基本的なことばかりです。ただ特に最初の2つは事前に準備するものではなく現場での事なのでなかなか難しいものです。僕も場数を踏んでうまくプレゼンできるようになりたいと思います。
JSON を jq で確認しやすくする CSNJQFormatter
UITableViewController 以外で UIRefreshControl を使う方法 [リスクあり]
Tweetie で有名になった Pull to refresh ですが iOS 6 から UIRefreshControl として OS 標準で追加されました。残念ながら UIRefreshControl は UITableViewController と一緒に使うしかまっとうな方法はありません。UIViewController + UITableView のような構成で無理矢理使う方法を書いてみます。
重要
個人的におすすめしません。素直に UITableViewController で使うような方向でまず実装を検討してください。これから紹介する方法は OS バージョン等の要因に左右されて期待するような動きをしない危険性があります。
方法
UIRefreshControl を生成して UITableView のインスタンスに addSubview するだけです。
ただし、これだけではアプリが Background から Foreground に戻ってきた時やタブの切り替え等で viewWillAppear などが呼ばれたあとに UIRefreshControl が UITableView よりも前面に出てくることがあります。
最前面に出てくるのをねじ伏せる方法
viewWillAppear で
[self fixRefreshControlLayout];
if (self.refreshControl.isRefreshing) {
[self.tableView setContentOffset:self.scrollOffsetToRestore animated:NO];
}
というような感じにします。
- 1行目で
UIRefreshControlのレイアウトを調整 - 2行目以降で refreshing 状態の時のために保持しておいた
UITableViewのcontentOffsetを復元させています。
1行目の fixRefreshControlLayout はこんな感じ。
- (void)fixRefreshControlLayout
{
if ([self isViewLoaded] == NO) {
return ;
}
BOOL isRefreshing = self.refreshControl.isRefreshing;
if (isRefreshing) {
[self.refreshControl endRefreshing];
}
[self.refreshControl removeFromSuperview];
self.refreshControl = nil;
[self.tableView addSubview:self.refreshControl];
if (isRefreshing) {
[self.refreshControl beginRefreshing];
}
}
最前面に出てきても再度 addSubview すれば期待する位置に出てきてくれるので念のため都度都度張り直しをしています。特にパフォーマンス上は大きな足かせにはなっていない印象です。
self.scrollOffsetToRestore は viewWillDisappear: のタイミングで現在の contentOffset を保持しておくようにしています。
まとめ
このような無理矢理な実装をしてねじ伏せるような実装を追加してもそんなに綺麗な感じじゃないです。ですので繰り返しになりますが素直な実装をとることを激しくおすすめします。Apple にはバグレポを通じて UIRefreshControl が UITableViewController に限定されずに使えるように要望しましょう。
Blocks のアレゲなシンタックスのための Xcode の Snippet
Blocks のアレゲなシンタックスは有名で非常に覚えにくいです。なので有名な OSX / iOS アプリ開発者のココロの叫びを表したサイトがあるのはもはや有名ですね。ココに書かれているシンタックスを Xcode の Snippet にして置いてます。
griffin-stewie/XcodeBlockSyntaxSnippets
デフォでもいくつかは入ってますし、他にもすでにいっぱいあると思いますが自分自身が環境変更があったときに便利なように GitHub に置いておこうと思ったしだいです。
UILabel の文字色をハイライト時に暗めの色にする
UI のインタラクションとしてテキストカラーを少し暗めにしたいことがあったのでその時に使った方法です。
HSB(HSV) で元の色の Brightness を変更する
先に書いたとおり暗くしたいだけなので RGB でどうこうしようとするのはめんどくささこのうえないです。ですので前回紹介した HSB(HSV) を素直に使いたいと思います。HSB(HSV) で元の色の Brightness を変更するアプローチです。
やりかた
まず暗くしたい元の UIColor から HSB の要素を抜き出します。これには - (BOOL)getRed:(CGFloat *)red green:(CGFloat *)green blue:(CGFloat *)blue alpha:(CGFloat *)alpha を使います。各要素の値が抜き取れたところで Brightness の値だけ変更します。今後使いやすいように変更率で調整出来るようにします。すると以下のような感じです。
+ (UIColor *)csn_colorWithBaseColor:(UIColor *)baseColor brightnessRatio:(CGFloat)ratio { CGFloat hue = 0; CGFloat saturation = 0; CGFloat brightness = 0; CGFloat alpha = 0; BOOL converted = [baseColor getHue:&hue saturation:&saturation brightness:&brightness alpha:&alpha]; if (converted) { return [UIColor colorWithHue:hue saturation:saturation brightness:(brightness * ratio) alpha:alpha]; } return nil; }
使い方
self.label.textColor = [UIColor redColor]; self.label.highlightedTextColor = [UIColor csn_colorWithBaseColor:self.label.textColor brightnessRatio:0.65];
0.6 ~ 0.7 くらいの値を brightnessRatio に渡してやるとほどほどに暗くなっていいと思います。
まとめ
RGB でやるよりも HSB でやった方が遙かに直感的に明度の調整ができると思います。今回のメソッドを UIColor のカテゴリメソッドとしてヘッダファイルも含めて Gist に置いておきます。良かったら使って見てください。
