読者です 読者をやめる 読者になる 読者になる

RedPen を使った linter-redpen

Atom

Atom の Package linter-redpen を作りました。

以前もこのような RedPen を使った Package を書いていたので第二弾という感じです。

f:id:griffin-stewie:20160403210051p:plain

特徴

"何行目の何文字目" までナビゲート

以前作った redpen package は文書の問題箇所を列挙し、クリックすることで該当行にジャンプすることが出来ました。しかし、具体的な場所(何文字目)までのナビゲーションには対応出来ていませんでした。そこで Atom で使っている他の Lint 系 Package と同じようにピンポイントの場所までナビゲートしてくれるようなものを作りました。

他の linter-XXX ファミリーに準拠した形で linter serviceAPI を使って実装しました。

redpen-server サポート

RedPen にはサーバー機能があります。このサーバーには REST API が実装されています。linter-redpen では通常、RedPen をローカルにインストールしてもらいそのコマンドを叩くのですが、サーバー API を利用する形でも RedPen を利用できるようにしています。設定は通常 redpen コマンドへのパスを入力する 設定項目 Path for RedPen CLIhttp://localhost:8080 のような API サーバーの URL を入力します。

f:id:griffin-stewie:20160403210217p:plain

利用想定としては、以下のような感じです。

  1. ローカルマシン内でサーバーを起動させて使う
    • 文書量とかによるかも知れませんが都度 Command を叩くよりも高速
  2. 社内 LAN 内でサーバーを起動させて使う
    • RedPen 自身をインストールしなくても使えるので技術に疎い人にも使ってもらいやすい

RedPen というツールを試してみたいというのであれば http://redpen.herokuapp.com/ を設定しても良いですがサーバーの負荷もあるので出来れば RedPen をインストールするか自身が管理する環境にサーバーを起動して使うようにしてください。

redpen pacage との違い

指摘箇所が画面下部に一覧で表示されるところは同じです。redpen package のみの特徴として RedPen CLI の実行はユーザー任意のタイミングでできるところです。linter-redpen は Linter Service に依存しているため実行タイミングがコントロールできません。

まとめ

ブログなどテキストを書くことが多い人はぜひ使ってみてください。既存の redpen package も引き続きメンテはしていこうと思っているのでお好きな方をどうぞ。

try! Swift で感じたこと思ったこと

雑感

f:id:griffin-stewie:20160303112222j:plain

先週、東京で開催された try! Swift に参加してきました。参加者のブログエントリとしてはかなり遅いですが try! Swift 後の諸々の課題が完了して落ち着いたのでそこで感じたことを書いてみたいと思います。気付けば前回のこのブログの更新から1年以上もご無沙汰していたようで、アウトプットが減ったのだなと感じています。

try! Swift

try! Swift のイベントそのものの説明や、そこで話されたセッションの内容などはすでにたくさんの方が書かれているのでそちらを参照してください。特に id:niwatako さんのエントリ群はすごいのでぜひ "try niwatako" でおググりください。

英語

当日は英語のセッションが8割以上で、会場に来ている人も印象としてかなり外国人が多くいました。セッションと Q&A についてはすばらしい通訳があったので特に支障はなかったでしょう。ただ、それ以外の休憩中やパーティーの時(特に Speaker Dinner)には通訳がないため多くの日本人は外国人と話すことを躊躇しているように感じました。一部の方は積極的に話している印象はありました。

そんな中 @koher さんの働きかけで、参加者の中で日英両方しゃべれる人が通訳として動くことで、日本人と外国人で会話をするきっかけを作ったのはすばらしい提案だった思います。

一方でどうして日本人は話そうとしないのかなと考えました。

  • 通じなかったらどうしよう?
  • 聞き返されたらどうしよう?

このような理由で話すことを恐れているのかもしれない。

でも、僕はこう考えます。英語が話せるか話せないかは重要ではない。"コミュニケーションをとる" ことが重要です。 コミュニケーションとは「お互いが考えていることを共有すること」だと思います。なので海外の人と "コミュニケーションをとる" ≠ "英語を話す" です。海外のカンファレンスでは、当然何かのテーマがあって人が集まっています。一定以上の共通テーマがお互いに存在していることが保証されています。特に開発関連のイベントにエンジニアが行く場合、英語以外にもコミュニケーションを取る "言語" があります。Computer Language です。英語で話せなくても、コードを書けば分かる。ホワイトボードに書けば良い。UMLでもなんでも図を書けば良い。それにエンジニアの場合、毎日のように英語のドキュメントなんかを目にしています。普通の人は知らないような単語を結構日常的に触れていると思います。コードを書くとき、クラス名・変数名は英語ですよね? ごく一般の人と比べて英語に触れる機会は多いのだからなんとかなります。大事なのは姿勢。街中でいきなり外国人に話しかけても普通は気持ち悪いと思われるだけだけど、幸運にもその手のカンファレンスでは、僕らの話す内容を聞いてくれようとしてくれます。これは絶好のチャンスです。僕はたぶんかなり間違った英語を使ってるはずです。それでも、それなりに言わんとしていることは通じているとが感じます。

母国語で書かれている文章だからって全部理解できるわけはないですよね?母国語で話された内容が適切に伝わるってこともないですよね?それが出来ていたらみんなみんな医者でも弁護士でも政治家でもなんでもなれる気がします。業務の中でもコミュニケーションロスなんて発生しないはずです。 でも実際には母国語を使っていても伝わらない事なんて日常です。だから英語をしゃべって外国人に伝わってなくてもしょげることは全くないです。そんなときは、言い方を変えてみたらいい。言いたいことの直訳にあたる英単語が浮かばなくても、そこで思考停止しなくていい。言いたい単語を説明するような発言をすればいい。

自分が考えるコツ

  1. 大きな声で話す
  2. 単語が浮かばなくても気にしない
  3. 抑揚・強弱・リズムを英語風に

聞き返されるときの大半は単純に声が聞こえてないだけなように感じます。大きな声で話すだけでも聞き返される回数は減ると思います。 単語が浮かばなければ、言いたいことを別の言い方で説明すればいいと思います。 英語はダイナミズムに溢れた言語です。日本語っぽく抑揚がない平坦な話し方よりも、それらしいイントネーションで話すだけで大分伝わりやすくなります。

まとめ

昨年から海外出張を含め外国人と話す機会が多いなか、いつも折角の機会なのに外国人に話しかけないのはもったいないなぁと思っていました。try! Swift に参加したきっかけに久々のブログエントリにしました。

英語を積極的に話せるとエンジニアとしてまだまだ武器になるのでは?と思いました。僕自身もこの事を忘れずに英語力を上げていきたいと思います。

Atom から RedPen を簡単につかう Package を作りました

Atom

GitHub がメインで開発しているエディタ Atom の Package redpen を作りました。

RedPen とは

普段僕は Objective-CiOS アプリの開発をしています。Objective-C のようなコンパイル言語で typo した場合にはコンパイルエラーがでたり、型を謝ったコードを書いてると警告がでたりすることで事前にミスを防げているわけです。RedPen は自然言語を書いている時にもそれに近いものを得るために作られた自動文書検査ツールです。詳しくは gihyo.jp で連載されているこちらを見ていただいた方がわかりやすいと思います。

Atom Package を作った理由

仕事で書く文書ではアルファベットの前後にスペースを入れるような基本ルールがあって、最近はよくそのレビューを任されることがあり結構面倒な作業でした。そんなときに RedPen の事を知ったのは凄くうれしかったのを覚えています。でも、僕は Terminal の操作が苦手です。このような環境で文書のチェックのために Terminal を開いてコマンドを叩くのは億劫です。自分でブログの記事を書くときには Mou や Atom を使って Markdown で書いています。このような時も同様です。どうにか自分が楽に使いたい。RedPen のようなテキストのチェック機能はエディタに備わっているべきだと思い、ちょっと書いてみようと思いました。

エディタに元々 RedPen の機能があるものは当然ながらなかったので自分で拡張を作る必要がありました。拡張機能の開発がサードパーティでできるエディタとして浮かんだものは以下のようなものです。

この中で自分が使っているのは SublimeAtom だけです。SublimePython で拡張を書く必要があります。AtomCoffeeScript (JavaScript) です。どちらもほとんど触ったことがない言語でした。1番大きかったのは JSONLint の拡張(Package)を Atom で使っていてその UI や使い心地が気に入っていたところです。この Package と同じような作りにすればできるんじゃないかと思ったので Atom Package として書くことにしました。

redpen Package でできること

基本的な使い方はここの Usage を見てもらうと大体わかると思いますが、以下のような感じです。

  1. RedPen CLI のインストール
    • 現在 Homebrew でインストールできるようにするための formula が PR 中
  2. redpen package のインストール
  3. RedPen CLI のパスを設定
  4. Configuration XML の作成とパスの設定
    • 未設定の場合、僕が用意している日本語向けのデフォルト Configuration XML を使います
  5. 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

iOS CocoaPods

普段アプリを作っていたアプリが取得した JSON データを Console に出力させています。このままでは改行がなくなっていたりシンタックスハイライトもなくて見づらかったのでこんなものを作りました。

griffin-stewie/CSNJQFormatter

以下のような文字列を返すだけの単純なもので他に機能はありません。

cat <<'END' | jq '.' 
{"foo":"bar"}
END

利用シーンとしては NSLog にこの文字列をくわせてやると、あとで Console に出力されている文字列を Terminal にコピペしてやる感じです。実装的にも単純に文字列連結させているだけです。

デバッグ用途で気が向いたら使ってみてください。

UITableViewController 以外で UIRefreshControl を使う方法 [リスクあり]

iOS 非推奨

Tweetie で有名になった Pull to refresh ですが iOS 6 から UIRefreshControl として OS 標準で追加されました。残念ながら UIRefreshControlUITableViewController と一緒に使うしかまっとうな方法はありません。UIViewController + UITableView のような構成で無理矢理使う方法を書いてみます。

重要

個人的におすすめしません。素直に UITableViewController で使うような方向でまず実装を検討してください。これから紹介する方法は OS バージョン等の要因に左右されて期待するような動きをしない危険性があります。

方法

UIRefreshControl を生成して UITableViewインスタンスに addSubview するだけです。

ただし、これだけではアプリが Background から Foreground に戻ってきた時やタブの切り替え等で viewWillAppear などが呼ばれたあとに UIRefreshControlUITableView よりも前面に出てくることがあります。

最前面に出てくるのをねじ伏せる方法

viewWillAppear で

[self fixRefreshControlLayout];
if (self.refreshControl.isRefreshing) {
    [self.tableView setContentOffset:self.scrollOffsetToRestore animated:NO];
}

というような感じにします。

  • 1行目で UIRefreshControl のレイアウトを調整
  • 2行目以降で refreshing 状態の時のために保持しておいた UITableViewcontentOffset を復元させています。

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.scrollOffsetToRestoreviewWillDisappear: のタイミングで現在の contentOffset を保持しておくようにしています。

まとめ

このような無理矢理な実装をしてねじ伏せるような実装を追加してもそんなに綺麗な感じじゃないです。ですので繰り返しになりますが素直な実装をとることを激しくおすすめします。Apple にはバグレポを通じて UIRefreshControlUITableViewController に限定されずに使えるように要望しましょう。

Blocks のアレゲなシンタックスのための Xcode の Snippet

Objective-C iOS

Blocks のアレゲなシンタックスは有名で非常に覚えにくいです。なので有名な OSX / iOS アプリ開発者のココロの叫びを表したサイトがあるのはもはや有名ですね。ココに書かれているシンタックスを Xcode の Snippet にして置いてます。

griffin-stewie/XcodeBlockSyntaxSnippets

デフォでもいくつかは入ってますし、他にもすでにいっぱいあると思いますが自分自身が環境変更があったときに便利なように GitHub に置いておこうと思ったしだいです。