Edu Kotlinプラグイン

Kotlin 1.0リリース記念エントリってわけじゃないけど、ちょっと気になるこのプラグイン

PyCharm Educational Editionよろしく、Kotlinの学習ができるみたい。


というか、このエディションの機能をプラグイン化したってのが正解らしい。基盤になってるプラグインはこれら。ビルドナンバーみるとわかるけど、どれもIDEA16用ね。


ためしにプラグインの中のコースファイル(Kotlin Koans.zip)を覗いてみたんだけど、画面右側のTask Descriptionツールウィンドウに表示してるのは、このHTMLなんでローカライズは簡単そう。プラグインが国際化してれば言語別にHTML追加するだけで済みそうなんだけど、どうなんだろ?


IDEA16用ってことで、ちょっとハードル高いけど「Kotlinちょっと触ってみたい」って人にはおすすめかも。

Search Everywhereでタグ検索

以下のURLから知った。

SHIFTキー2回押しのSearch Everywhereで「#」を入力すると、いくつかのキーワードが出てきて、これを頼りにPreferences画面を開かずとも設定変更ができるらしい。図はIDEA15のものだけど、試してみたらIDEA14でも出てきた(ただし、出てくるキーワードはIDEA15のほうが多い。

へぇーとは思ったけど、便利かどうかはわからない。たぶん、すぐ忘れて普通にPreferencesを開くと思う。

Re:VIEWにあったら良いなと思うこと

Android Studio本はRe:VIEWを使って書いてました。Re:VIEWへのフィードバックと思い、使ってて思った不満点とか改善要望をまとめてみました。このエントリ自体はRe:VIEWに対するネガティブな内容になってますが、今のRe:VIEWでも十分便利です。逆の見方をすれば、これ以外の不満は無いです(実際、超絶便利だったし、PDF生成しやすいこと考えるとSphinxより良かった)。

アイコンが無いのが分かりづらい

本の性質上、@{...}を多用してたんだけど、このタグで指定したアイコンリソースのパスが間違っているのが気づきづらくて最初難儀しました。PDF作成すると、アイコン指定が間違っているページまでしかPDFが生成されないので、それで判別してたけど、@{...}{//image[...]{...}みたく、指定したパスにファイルが無いことを警告してくれると良いなと思いました。

ちなみに、PDF生成のログは読みづらいので、HTML生成をRe:VIEWのlint代わりに使ってました。HTML生成のほうがログメッセージがシンプルで、Re:VIEWマークアップのミスを見つけやすかったです。

見出し参照のスタイルを指定できるとうれしい

@{...}の見出し参照のほかに、そこのページ数も参照したかったので@{...}というマークアップを使ってました。なので、見出し参照するときは、次のように2つセットでマークアップしてました。

詳しい理由は@<hd>{plugins|プラグインの紹介|言語系プラグインを使うときの注意事項}(@<pageref>{plugins|プラグインの紹介|言語系プラグインを使うときの注意事項})を参照してください。

レンダリングすると、こうなるイメージ。

詳しい理由は『言語系プラグインを使うときの注意事項』(p.200)を参照してください


正直大変だったので、@{...}のスタイルを「見出しのみ」「見出し+ページ数」とか複数のスタイルから選べるとよかったなと(そもそも、@{...}は本書用特別あつらえのタグだと思う)。

ps.
あと@{...}で他章のコラムを参照できるようにしてつかあさい。

用語リストの説明文を継続できるといいな

「用語リストの使い方が悪い」と言われれば、そのとおりなのですが、いわゆるこんなやつ。

: 用語1
   説明文1行目
   説明文2行目


これを次のようにマークアップしてます。

: 用語1
   説明文1行目@<br>{}
   説明文2行目


これをこんな風にできたらよいなと思った次第です。

: 用語1
   説明文1行目

   説明文2行目


用語リストについて言い始めると、説明文の中で//image//listなんかも使いたいんですけど、言うは易し行うは難しだよなーと。

リスト内に引用用のマークをつけられるといいな

こっちは単なるオマケです。前にasciidoctorの説明読んでて、うらやましいと思っただけ。//list内で@{...}が使えたので、今回は全然困りませんでした。

Android Studio本のサポート編を製本してみた

なんだかんだで紙の本は付箋貼ったり書き込んだりできて便利なのでAndroid Studio本のサポート編を製本してみた。頼んだところは製本直送.com。ここ、料金シミュレータや用紙サンプルとかあって使い易いです(Safariだと文句言われるのが数少ない難点。


製本したいPDFをアップロードして,判型,用紙,カラーかモノクロかを指定するだけで,とても簡単。ただ,このサイトは製本原稿用にアップロードしたPDFを加工するので,Gihyo Digital Publishingから入手したPDFでは製本できないです。

個人的にはB6が好みの判型なのだけど,本編と揃えるためA5で。もろもろの設定は以下の通り。

  • 製本サイズなど:A5,224ページ,無線綴じ
  • 表紙:カラー&マット加工(用紙:柔らかめ)
  • 本文の用紙:カラー,ラフクリーム

表紙の柔らかさはこんな感じ。使った用紙(ラフクリーム)の厚さや柔らかさも本編のと同じくらいで、安っぽい感じはしなかった。

頼んでから届くのに1週間で届いたし,製本代も1,712円(送料 237円)でトータル 1,949円なので,まあまあリーズナブルだと思う。

普通,自炊っていったら紙の本→電子化だけど,電子本をオンデマンドで製本するってサービスもあると良いなと思った次第(特に好きな判型で製本できるのは魅力ある。

Android Studio本制作の裏側

今後こんな機会がそうたくさんあるとは思えないが、半分自己満足で制作環境についてメモを残しておく(主に使用したツールまわりについて。

フォーマットはRe:VIEW技評さんといえばinao記法が有名なのだけど、それで原稿書くのはいろいろ辛かったので、inao記法テキストに変換できるRe:VIEWで原稿書いていいですか?とお願いしたところ快諾してもらえた(その時点では、まさかRe:VIEWの中の人直々に組版してもらえるとは思っても無かったけど。

ちなみに、Jenkins本のときはSphinx(HTML入稿)、Web連載とSoftware Design誌の記事はMarkdown.mdのまま入稿)、出版社違うけどGradle本のときはSphinx(テキスト入稿)。

原稿書きはもっぱらvim(MacVIMとgVim)。「iPad miniで原稿書き」もちょっと憧れたけど、vimが無いからやんなかった。一部の人には「IntelliJで書いたんでしょ?」って言われたけど、そんなことは無くてほぼvim。(自分にとって)テキスト書くのにこれほど最適なツールは無い。あとATOKvimATOKが無いと死ぬ病。:-)

vimで使ったのはvim-reviewunit.vimの2つ。特にunite.vimは「:Unite outline」でアウトライン確認できたので大変重宝しました。あと、今回の作業でやっとvimgrepを身につけた(これスーパー便利や。

スクリーンショットSkitchかOSのスクリーンショット取得ショートカット、その後の加工にPixelmator。PixelmatorはiPad版も持ってたけど、iPadで画像作成はしなかった(慣れの問題かMacBookで作業するほうが楽だったんで。

スクリーンショット以外の図はSHOT NOTEに手描きしてiPhone経由で取り込む(これは単なる好みの問題。

原稿だいたい完成したら、Re:VIEWでPDFにしてWordに読ませて校正したんで、Wordも使ったツールのひとつ。Wordの校正機能は意外とバカにできない。

リポジトリはBitbucket。無料でプライベートリポジトリ使わせてくれるAtlassianさん太っ腹!クライアントはSourceTreeを主に使っていたけど、ファイルごとの履歴の確認のやり方がわからなかったんで、そんときだけIntelliJを使ってた。

校正やり始めるようになってから使いはじめたのが、Kaleidoscope。有償のdiffツールなんだけど、文字単位の差分を見せてくれるルーツはこれくらいしかなかったので、やむを得ず購入したけど十分元は取ったと思う(ちなみに、WinMergeはフリーのツールにも関わらず文字単位の差分も見せてくれる。
IntelliJこのチケットが対応されてれば、IntelliJでもイケただろうに...。

PDF校正で使ったのは、iOSGoodReader。PDFに注釈入れられるツールは数多くあるんだけど、ちゃんとAdobe Readerで認識できる注釈入れられるツールは実はそう多くなくて、Adobe Reader使うのはもっとも確実(だけど、これ使いづらい)。Adobe Reader以外でまともだったのがGoodReader。iPadのGoodReaderでガーっと校正して、PCのAdobe Readerで微調整ってのが便利な使い方だった。

とりとめないけど、メモだしいいか。

Selenium実践入門

献本いただきました(ご恵投言うんでしたっけ?日本語ムズカシイ)。ありがとうございます。

WebDriverのことがみっちり載っていて、WebDriverを使っている人、これから使ってみようと思っている人は必携ですね。自分自身も最近ぼちぼちWebDriverを使いはじめているので、この手のリファレンス代わりになる本はとてもありがたいです(ネット使えない環境にいるからなおのこと。

改めて思い知らされたのは、Selenium 1の未来の無さ。10年くらい大事(?)にメンテしているSeleneseのテストケースをどうしてくれようかと思っていただけに、ホンキでどうするか決断しないとなと。今までは「WebDriverなんて(難しくて)すっぱいブドウだぞ」と言いふらしてきたけど、この本あれば、そんなこと言う必要もないなと思い直せた。:-)

イムリーなことにSeleniumBasicなるツールの存在も知ることができたので、ちょっとSeleniumとのお付き合いのしかたを考え直そう。


Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Android Studio本を書きましたの補足

ちまたでは「IntelliJ IDEA本格活用バイブル」とか言われていますが、ホントウです。主体はAndroid Studioです。その証拠(?)と言うか、もっとも特徴的なのが「第4章 プロジェクト」ですね。

個人的には、GoogleさんがEclipse ADTを捨ててまで、Android Studioに移りたかったのは、Android Gradleプラグインを使いたかったからだと思っていて。Android Studioは飾りで、このAndroid Gradleプラグインがド本命なんじゃないかと思ってます。

たしかに、Android Studioの大半の機能はIntelliJ IDEAそのものなんですが、プロジェクトの管理方法とビルドプロセスはIntelliJのそれとは異なります。困ったことにGradleでも無いんです。Android Gradleプラグインなんですね。このプラグイン、たぶん第一線でAndroidアプリ開発やってる人たちにとっては便利な機能が満載なんだと思うんですが、それ以外の人らには手に余るというか難解なんでね?と思うんですよね(その辺、どうなんでしょ?

...おっと話が逸れましたが、Android Studioのプロジェクト管理は独特なので、4章を書くのは骨が折れました。さすがに、Gradleから説明できないので、そっちはどうにかして覚えてきて欲しいッってのが本音。
#ちょうど良い本がありますぜ、ダンナ。

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築


ちなみに、IntelliJのプロジェクト管理もこれまた独特なので、Android Studioが分かったからといってIntelliJのプロジェクトもわかるかというと「どうだろう?」と思うわけであります。噂に聞くと、WebStromやCLionなどの他のIntelliJ platformでも、Project Structureが無いものもがあるらしいので、その辺もきっとフォローできないと思うんですよね。

別の言い方をすれば、この辺を調べれば他のIntelliJ platformでどこまで通用するか評価できるし、フォローのやり方もわかるとも言う...。(´・ω・`)


ps.
そんでも、メインウィンドウやツールウィンドウの使い方やエディタの基本操作、VCS連携、管理ディレクトリの構造なんかはIntelliJ platform共通なんで、どれでも通用するでしょうね。