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

RubyPicoが第9回フクオカRuby大賞で優秀賞をいただきました

iOSで動くRuby開発環境のRubyPicoが第9回フクオカRuby大賞で優秀賞をいただきました。

「第9回フクオカRuby大賞」審査結果 - 福岡県Ruby・コンテンツビジネス振興会議

今回で4回目の挑戦となりますが前回のhonyomiではじめて賞をいただき、プレゼンの雰囲気や流れも分かってきたので今度こそ大賞を!とがんばってみましたが残念ながらHaconiwaという素晴らしいソフトウェアが大賞となりました。しかしなんと優秀賞をもらうことができたので大変うれしいです。

RubyPicoについて

mrubyが出始めの頃に「これでiOSAndroidが動くRubyアプリがたくさん作られるんだろうなぁ」とか思っていたらmrubyの主戦場はnginxやH2OといったPCアプリケーションとなり、だれも作らないのなら自分が作ってみようという気分になったのがきっかけです。

最初はopenFrameworksを組み込んだofrubyというアプリを作っていたのですが、途中でiOSのアプリが64bit必須になり、当時のopenFramworks for iOSが64bitビルドに対応していなくて泣く泣くバージョンアップをあきらめました。

次にiOSネイティブのAPIをコツコツと組み込むしかないかと思い直し、写真が加工できたら普段プログラム書かない人も興味持つだろうと安易に考えて、写真加工をRubyスクリプトで行えるPictRubyというアプリを作りはじめました。

そして結局写真を撮るよりもプログラムを書くほうが好きだったと思い直し、よりCRubyに近づけたrequireや無限ループも書けるRubyPicoへと進化していきました。iOSアプリはマルチプロセスできないので、GUIを駆動させるメインスレッドとmrubyを実行するサブスレッドに分けて動かしてloop {...}させてもアプリが止まらなくなったときは大変楽しかったです。

趣味としての挑戦

普段の仕事ではC++などを使うことが多くRubyPicoに使われているObjective-CRubyはあまり使いません(Rubyは隙を見て無理やり使うけど)。私の場合インターネットに公開しているツールはいつもとちょっと違うジャンルで自分の作りたいものを作る、いわば趣味としての開発です。

フクオカRubyの参加者の方を見ていると仕事として参加されている方が多い印象でした(あくまで私の印象でちゃんと調べている訳でもないですが)。最近はオープンソース自体への参加者も仕事として参加されている人が増えているように感じます。そのこと自体はとてもいいことなのですが普段できないことを試したりまったくビジネスにはならないけど面白いことを試すための場としてのフィールドが狭くなっているのだとすると少しさみしい気持ちもあります。

ビジネスとして取り組んでいるオープンソースは実際役立つことが多くソフトウェアの質も高いものが多いです。しかし趣味のソフトウェアにも独特のよさがあるのではないかと考えています。お金にはならないけど楽しいこと優先で作れたり、飽きない限りいくらでも時間をかけることもできます。何よりも自由です。誰に頼まれた訳ではなくただ欲しいから、作りたかったから作ったソフトウェアはRubyのように時折不思議な魅力を持って多くの人々に使われます。私もいつかそういうものが作れたらいいなぁと分不相応なことを思っています。

仕事の延長で、趣味として、腕試しに、試しに作ったら割とよい出来になった、などたくさんのバックグラウンドを持つ人たちがもっとフクオカRubyに参加してくれたらよいなぁと思います。応募資料やプレゼンテーションの準備をするとその過程でより自分の制作物を客観的に眺めることができますし、審査員の方々の質問は示唆に富んで今後の開発に役立つので応募にかける時間は決して無駄にならないので是非。

今後の展望

Rubyを書いて動かすための基本的な土台はできてきたので、次のステップとしてもっとたくさんの人に使ってもらえるようになればよいと考えています。

審査員の方からいただいた質問の中で、コードのバックアップをとれないのかという話と、入力がPCと同じテキストエディタだけど例えばモバイルに特化した入力システムを作らないのか?という指摘がありました。

コードのバックアップはDropboxiCloudと連携ができれば色々便利になりそうです。が、実行可能なコードのダウンロードをAppleが禁止していて実際他のアプリでも昔入ってたけど途中で外したりしているので基本的には大変そうです。今はgithub_downaload.rbというGitHub APIを叩く拡張ライブラリを書いて、PCでコード書く→git push→github_downloadでスマホにダウンロードとかやっています(しかし2手くらい多い)。自分の書いたコードをバックアップ用途としてクラウドに同期するところだけでも許してもらえたら大変うれしいのですが。

モバイルに特化したコード入力システム、フリック入力のようにサクサクプログラムをスマホから入力できるようになったらそれだけで大きな価値がありそうです。Smalrubyのようにブロック入力だけど実際にはRubyスクリプトが書かれている、みたいになっているといいなぁと妄想しています。何かお手本になるようなアプリがないか探してみようかな。

他にもSpriteKitを組み込んでRubyだけでモバイルゲームを作れるようにしたらゲーム作りたい人たちに使ってもらえるのではないか、などと考えています。

まとめ

福岡のカレーが大変美味しかったです。次はとりかわが食べたい。

発表のときに使ったスライドはこちらです。

「最初に学ぶべきプログラミング言語」をスマホから気軽にはじめる

「最初に学ぶべきプログラミング言語」 - mizchi’s blog

  • 「環境構築」に100%成功する(AppStoreからダウンロードするだけ)
  • PC不要
  • Ruby

なので拙作のRubyPicoをすすめてみます。

RubyPico

RubyPico

  • ongaeshi
  • 仕事効率化
  • 無料

本格的にやりたくなったらPC買ってRubyに移行もできるよ。

epubからmobiに変換するならkindlegenが便利

購入したepubKindleに送ろうと思ったら、数ヶ月前にPCを乗り換えたのでcalibreがインストールされていなかった。

しかたないので昔書いた記事を見ながらcalibreを再インストールする。意外とブクマついてたので覗いてみると

変換だけなら公式のkindlegenの方が手軽かと。 http://b.hatena.ne.jp/entry/136255446/comment/hageatama-

これは便利そうなので試してみよう。

kindlgenのインストール

KindleGen v2.9をダウンロードして

$ unzip KindleGen_Mac_i386_v2_9.zip 
$ mv kindlegen /usr/local/bin/

これでインストールは終了。Windows, Linux, MacOS 用が用意されている。

epub -> mobi

$ kindlegen scheme-in-ruby.epub 
*************************************************************
 Amazon kindlegen(MAC OSX) V2.9 build 1028-0897292 
 A command line e-book compiler 
 Copyright Amazon.com and its Affiliates 2014 
*************************************************************

Info(prcgen):I1047: Added metadata dc:Title        "つくって学ぶプログラミング言語 RubyによるScheme処理系の実装"
Info(prcgen):I1047: Added metadata dc:Date         "2013-04-16"
Info(prcgen):I1047: Added metadata dc:Creator      "渡辺昌寛"
Info(prcgen):I1047: Added metadata dc:Publisher    "達人出版会"
Info(prcgen):I1047: Added metadata dc:Contributor  "高橋征義"
.
.
Info(prcgen):I1036: Mobi file built successfully

$ ls
scheme-in-ruby.epub
scheme-in-ruby.mobi

完成、あとはメールにmobiを添付してKindleに送りつければよい。

コマンドラインでさくさくepubからmobiに変換できるとやはり楽でよい。

RubyPico 0.9.4 リリース - GitHubに置かれたスクリプトをダウンロードできるように

拡張スクリプトを追加することでGitHubに置いたスクリプトをダウンロードできるようになりました。 - 更新履歴

RubyPico

RubyPico

  • ongaeshi
  • 仕事効率化
  • 無料

github_download.rb

RubyPicoGemsの仕組みをリニューアルしました。

  1. github_download.rb をインストール
  2. インストールしたいライブラリのパスをコピー(例. ongaeshi/rubypico_github)
  3. github_download.rb を使ってライブラリをインストール

全ての手順がRubyPico内で完結するようになりました。今までとは雲泥の使いやすさなので是非お試しください。自分が書いたプログラムもGitHubに置くことで他の人に配布できるようになります。

※ とりあえずongaeshi/app_installerをインストールしておくとAppタブへの登録が簡単になるのでおすすめです

Image.load()でファイルへの読み書きが可能に

Image.loadでローカルファイル内の画像を読み込んだり、Image#save_toでカメラロールの画像をファイルに保存することが可能になりました。

ということでついに、GitHubレポジトリに画像を入れてコミット、github_download.rbでダウンロード、Image.loadで表示することが可能になります。

ホームページリニューアル

情報が複数のページに拡散していたので1ページにまとめなおしました。スマホからでも読みやすく検索しやすくなったと思います。

http://rubypico.ongaeshi.me/

インストール

App Storeからどうぞ。

日記を書く技術

2017年から日記を付け始めた。個人的にとても役立っているのでやりかたをまとめておく。

基本

日記の魔力

日記の魔力

この本のやり方を真似ている。

  • 1日1記事
  • 時系列に起きたことを順番に書いていく
  • 感想を書く必要はない
  • 客観的な事実を具体的に書く
  • 日記に書かないと消えてしまうことを記録する
  • よく観察する
  • あとで読み返すために文章の方がよい
  • 10日ごとに日記を読み返して大切なことは抽出する

大切な「抽出」について。今までも読んだ本や映画の記録、思いついたプログラムのアイデアなどを書き出していた。しかしそれぞれ違う場所に記録していたため記録が面倒になったり、一箇所に全てまとめるとテキストが大きくなって探せなかったりということがあった。書くときは全て日記に書き出し、10日ごとに専用の場所(例えば本の感想はブックメモアプリなど)に抽出する。こうすることで全てが記録された日記とカテゴリごとに読み返しやすい専用メモの2箇所に情報が蓄積され探しやすくなる。さらに抽出という作業を行うことで自分自身の記憶も強化されるので一石二鳥となる。

自分しか読まないからといってメモの断片の集合のような形にしてはいけない。あとで読み返しにくくなる。日記とは自分という読者に向けて書く「文章」なのでやはり読みやすい方が良い。読み返さないと日記のパワーを半分しか使えていない、みたいなことも本に書かれていた。

ツール

Day One ジャーナル + ライフログ

Day One ジャーナル + ライフログ

  • Bloom Built Inc
  • ライフスタイル
  • ¥600

オーソドックスにDay Oneを使っている。ずっと昔に買って忘れていたのを見つけてそのまま使っている。

抽出作業はPCでやった方がはかどるので、テキストファイルとして保存してくれるDropbox連携は必須。

画像のリサイズ

Day One は1つの日記に対して1枚の画像を付けることができる。あとで思い出すのに役立つのでどこかに行ったようなときは付けるようにしている。問題はDropboxの容量で今のiPod Touchのカメラは画像サイズが大きいため毎日撮っているとすぐに容量がいっぱいになってしまう。そこでRubyPicoを使って横幅1280になるようにサイズ調整するスクリプトを書いている。

gist086ffd836292ae4e4143242bae7f8e65

写真をとったらスクリプトを起動してリサイズ画像を作る。それをDay Oneに貼り付ける(Last Photo Takenを使うと便利)。貼り付けた画像はDay One側にコピーされてるのでカメラロール側のリサイズ画像は消す。

スクリプトDSTの値を変えると横幅を調整できるようにしてある。記憶の手がかりになればよいので、もう少し小さくしてもいいかなとも感じている。

効果と効能

私の書きたい欲の大半はブログじゃなくて日記で解消するのだな、と思った。

自分を客観的に記録することができる。とりあえず書き出してみることで自分が考えていることを整理したり新しい事実に気がつくこともある。

もやもやすることがある時にブログを書こうとすると外向きの文章なのでなかなか筆がすすまないことがある。日記だと「こんなこと書いちゃっていいのかな?」と考えずにストレートな気持ちを書き出しやすい。あとで読み返すことで気持ちの整理もできる(炎上もしない)。他の人にどうしても聞いて欲しいことがあればそのあとでブログに書けばよい。そういえば昔もそんなこと書いてたな。

自分専用のメモを作って簡単に検索出来るようにする - ブログのおんがえし

メインのメモ帳のTiddlyWikiは割とテキスト断片の集合として使っているため読み返すのに向いていなかったと感じる(そういえばTiddlyWikiに書いていた箇条書きの作業ログはほとんど読み返したことがない)。作業ログやTODO管理には引き続きTiddlyWikiを使いつつ、読み返すための文章として日記を書いていこうと思う。

TiddlyWiki備忘録(2017年版)を作りました。

去年に引き続き、TiddlyWiki備忘録の2017年版を作りました。

f:id:tuto0621:20161229210041p:plain

特徴

  1. ブラウザさえあればどこでも使える
  2. 1つのhtmlファイルだけで構成されているので、持ち運びが楽
  3. 見出し、リスト、表組、リンク等、単なるテキスト以上の機能を内包する
  4. 豊富なプラグインが世界中で開発されている、アップデートも簡単
  5. JavaScriptで作られているのでブラウザの進化に合わせて表現力が上がる。

個人用のメモを作った方がよい理由

以下に書きました。

ダウンロード

zipアーカイブを展開します。memo.htmlが入っているのでブラウザで開いて下さい。

2017年版の特徴

要望や不具合、使ってみた報告など頂けたら、2018年版を作る時の励みになります。

書評 - プロ書評家が教える 伝わる文章を書く技術

書評を上手に効率よく書くための「型」を身につけたくて手にとった。

プロ書評家が教える 伝わる文章を書く技術

プロ書評家が教える 伝わる文章を書く技術

筆者は2012年8月から「ライフハッカー」で書評コーナーを担当しており月曜日から金曜日までの毎日、月に20本もの書評を書いている。年間250冊以上の書評を書いている計算になり少なくとも週に5冊(実際には1日1冊以上のペースで読んでいるらしい)以上インプットする必要がある。2016年12月にサイトを覗いてみると引き続き同じペースで書かれているようなので今まで1000冊以上の書評を書いていることになる、すごい。

このような高負荷なインプットとアウトプットをこなせている筆者のテクニックは、趣味として書評をもう少し書きたいと思っている自分にとっても価値があるように感じた。

インプットの「型」

読書を、情報摂取モードと読書体験モードに切り替えているんですよ。

書籍の中でなんども言及されていたのが「たくさん読みたければ、何かを諦める必要がある」ということ。たくさん読んでいる人は全てを精読しているわけではなくいくつかの本は流し読みして情報摂取に勤め、本当に読みたい本は丁寧に読むということだった。これは本を読むのが好きで流し読みするのがなんとなく冒涜のように感じてしまう自分にとっては結構衝撃的だった(今でも少し抵抗感はある)。

さておき、本を読んでいてページ数を増やすために追加された章だなと感じることはたしかにあるので、本当に必要なことを効率よく取り出すために流し読みする勇気が自分には必要なのかもしれないと思った。本文にあった一節が胸に刺さる。

「義務的な精読」は、効率的なように見えてとても非効率的

思い返すとちゃんと読まないといけないと思って買うのを諦めた本、読み切れないからという理由で積読した本がたくさんあることに気がつく。それなら購入して本当に必要な1章だけを読んだ方がよかったのかもしれない。

技術書の場合は隅から隅まで役に立つということはまれで1/4くらいのことはなんとなく知っていて、半分くらいは自分にとって今は必要ないこともしくは難しくてわからないことで、本当に役に立つのは残りの1/4くらいということが結構ある。

例えばDockerの本が売っていて全部読む気はないけど、今知らなくてすごく知りたいトピックが目次に載っていたら購入して読んでそれで終わり!みたいなやり方をしてもいいのかもしれないなぁ。

アウトプットの「型」

筆者の書評のテンプレートが紹介されていてよかった。

署名、著者名、出版社名、内容説明
↓
引用
↓
解説
↓
引用
↓
解説
↓
まとめ

最初に書籍の概要を書いてから引用を使いながら面白かったところを紹介していく。あらかじめ本を読みながら引用したい文章があったら線を引いたりドッグイヤーをしていくとよい。読み終わったら引用したい箇所を集めたり書きたいことの断片を書き出しておく。

実際に本を読んで書評に落とし込むまでの流れ。必要事項をあらかじめ入力する、一気に書ききる、修正は全て推敲で行う、などが参考になった。

  1. 読書 精読の場合は1-3日、斜め読みの場合は30分。
  2. 必要事項の入力 小見出しと引用の入力
  3. 執筆 大切なのは一気に書ききること、細かい部分は推敲でまとめて直す
  4. 推敲 いちばん重要なのがここ。ここに至るまでに少しでも時間を短縮するのがポイント

まとめ

筆者はライフハッカーの読者が本に対して感じていることを以下のように分析している。

「できれば、時間をかけて読み込みたい」

「そして、そのなかから自分に必要な情報を効率的に抽出したい」

「でも現実的に、それはとても困難なこと」

というジレンマのなかにいる

的確で素晴らしい分析だと感じた。引用を多用するスタイルは中身を短時間で知りたいという読者の気持ちに答えるために生まれたもののようだ。私が書く書評もこのように読者の問題を解決するものでありたい。