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 に置いておきます。良かったら使って見てください。
HSB(HSV) のすすめ
みなさんは普段アプリの開発の際にどのような形で色を指定していますか？個人的な経験と予想では
[UIColor colorWithRed:0.251 green:0.514 blue:0.663 alpha:1.000]
のような RGB での指定だったり、カテゴリやマクロで拡張して #4083A9 のような Hex 指定だったりするのではないでしょうか？このような指定になっている理由としてはデザイナーさんから指定される形式が RGB だからというのが多い気がします。デザイナー不在で開発者だけで作っている場合も RGB の方が何となくわかりやすい気がするという理由だったりします。
色の調整
デザイナーさんがいる環境であれば本職であるデザイナーさんの指示を仰ぐ形がプロダクトとしてはベストだと思うので開発者だけで色調整する場合の話です。特に色に関する知識がほぼない人です。僕自身も全く色に関する知識はありません。
RGB は Red, Green, Blue, Alpha の要素の組み合わせで色を表しています。UIColor であれば R:1, G:0, B:0, A:1 であれば赤。単純です。それではこのような真っ赤ではなく少し暗い赤が欲しい場合にはどうしますか？RGB の各値をいじくり回しますか？気がつけばとんでもない色になったりしませんか？
そこで HSB
HSB は
- Hue: 色相
- Saturation: 再度
- Brightness: 明度
で色を表現します。先ほどの例の少し暗い赤が欲しい場合は HSB 表現の赤の B の値を少し下げるだけで暗い赤になります。単純です。
こちらで配布されている日本語版 PDF の P18 でも進められているように個人的にも HSB は非常に色の調整がやりやすいです。
ちなみにこの PDF はおすすめなので1度見ることをおすすめします。
デモアプリ等で適当な色が欲しい時
ランダムな色が欲しい場合は HSB のうち H の値を変えるだけでそれなりに色が変わります。特に連続した色が欲しい場合は H の値を順番にループさせてやれば非常にカラフルで小綺麗な色になります。
補助ツール
任意の色が欲しいとかはさすがに
[UIColor colorWithHue:0.560 saturation:0.621 brightness:0.663 alpha:1.000]
とかいきなり書いたりはできないですよね。色を見ながら作りたいのでアプリで補助します。個人的におすすめは
上記2つの合わせ技です。
HexColor は OS の Color Picker を単独のアプリとして動かせるアプリです。このアプリ自体にも色を Hex や NSColor に変換してPasteboardにはき出すことができますが、Developer Color Picker プラグインを入れることで UIColor にも吐き出せるようになります。これらのアプリとプラグインは iOS 開発以外でも便利なのでおすすめです。他にも sip なんかもあります。対応するフォーマットが多いのが特徴です。
まとめ
HSB は同系色の調整が割と直感的にできるのでおすすめです。HSB だけでいろんな色を作るのは難しいかもしれませんが RGB でざっくり色を作ってから HSB で微調整するとか、スポイトツール的な機能で欲しい色を抜いてきて HSB で調整とかすると色の幅が広がっていいのではないでしょうか。
