2012年8月29日水曜日

Illustratorでイラスト制作!!ーIllustrator使いの道①ー

このエントリーをはてなブックマークに追加
はじめまして、HappyElements株式会社の弱小デザイナー岩﨑です。
日々PhotoshopやIllustratorを使った制作業務をやっております。この機会に普段メインで使っている『Illustrator』についてお話したいと思います。

何かと難しいと聞くIllustratorですが、基本的な部分さえ理解しておけば何も怖くない(ハズ)です。何事も基本が大事。
そんなもん知ってるよと言わず、Illustratorが苦手と感じる方は基礎からもう一度確認してみると面白くなってくるのではないでしょうか。


Illustratorの基礎知識
まず初めに基礎知識から。

画像制作するアプリケーションは大きく分けて2つあります。
「ビットマップ(ラスター)グラフィックアプリケーション」「ベクターグラフィックアプリケーション」です。
前者がPhotoshop、後者がIllustratorを指します。
Photoshopで制作されたデータはビットマップ(ラスター)データ、Illustratorで制作されたデータをベクターデータと呼びます。
PhotoshopとIllustratorの大きな違いはここで、どのような制作物なのかによって使用するツールは別れます。

描画の違いを知っておきましょう
Illustratorの特徴、魅力はこの「ベクターグラフィック」が制作できるという部分にあります。

ビットマップとベクター①

ビットマップがAからBまでをピクセル単位でドットで描画するのに対して、ベクターグラフィックはAからBまで直線を描画するという数値で描画しています。そのためベクターグラフィックはどんなに拡大縮小を行なったとしても画像の劣化がありません。(なんて素晴らしい!)

ビットマップとベクター②

上の比較画像を見てもらえばIllustratorが如何に画像の拡大縮小に優れているのかわかるかと思います。
16倍に拡大するとビットマップが荒れるのに対して、ベクターグラフィックは滑らかな線を保ったままです。


Photoshopで編集
更に、Illustratorで制作した画像・図形はPhotoshopに持っていき編集することも可能です。
その際、Photoshop上ではベクトルスマートオブジェクトとしてレイヤーが作られます。
これはPhotoshop上にベクターグラフィックのリンクを引っ張って来て貼付けている状態なので、ここからベクターグラフィックの編集が可能です。ただし、このままの状態ではPhotoshopの機能を使った編集は出来ません。
編集を行ないたい場合はラスター(ビットマップ)イメージへ変換する必要があり、これをラスタライズと呼びます。
ラスター(ビットマップ)化することでベクターグラフィックとしての特質は失われるので、ラスタライズする場合は注意が必要です。
ラスタライズ手順


今回のまとめ
・Illustratorはベクターグラフィックアプリケーション
・ベクターグラフィックは数値も用いて描画するので拡大縮小しても劣化しない
・Photoshopなどでも編集が可能
・ラスタライズするとラスターデータ(ビットマップ)になり、ベクターグラフィックの特質が失われる


Illustratorは癖がありますが覚えれば制作者としてのスキルは格段に上がるので、是非習得をオススメします。
実践的なお話はまた次回お話出来ればと思います。



一緒に働きたい方、絶賛 募集中!!
Happy Elements株式会社では、ソーシャルゲームのデザインや、イラストの制作に興味を持っているデザイナーを 絶賛募集中 です!
アルバイトも積極募集しているので、ポートフォリオを厚くしたい学生の方、チャンスですよ!

2012年8月27日月曜日

知らなきゃ損するPhotoshopテクニック | 〜”スマートオブジェクト” について〜

このエントリーをはてなブックマークに追加
はじめに
はじめまして、Happy Elements株式会社デザイナーの天野です。
普段の業務では主にUI設計や画像処理、その他雑用などをこなしています。

Happy Elements社内のデザイナーは、基本的にPhotoshop、Illustratorといったツールを利用して作業を行なっているのですが(イラストレータの方は一部例外もあります)他の方とやりとりする中で「こうした方が便利だよ」という場面がちょくちょくあるので、それをさらっとまとめていきたいと思います。


今回のテーマ
スマートオブジェクトを使いこなそう


用意するもの
Photoshop CS2以降


1.スマートオブジェクトってなに?
Photoshopはドットの集合で構成された「ラスター形式」と呼ばれる画像を編集するツールなので、ある画像を拡大したり縮小したりすると、そのドットの間をそれっぽく補ったり、または省略したり、ということが起きます。
そして、その都度画像が書き換えられていくので、繰り返すと当然画像は劣化していきます。一度処理を行った後からは元の状態には戻せない、これを「破壊編集」と呼びます。
(ヒストリー機能(cmd+Z/Ctrl+Z)で戻せるじゃん!と思われそうですが、ヒストリーは処理自体を元に戻しているのでちょっと意味合いが違います。)



そこで登場するのが「スマートオブジェクト」という機能です。

スマートオブジェクトはIllustratorでいう「画像の埋め込み」の感覚に近いもので、別ファイルとしてあるものをPSDファイル内にレイヤーとして埋め込みを行います。大雑把な説明ですが、PSDファイル内にさらに別の画像ファイルがあるような感覚と思って下さい。



スマートオブジェクトの作り方はいくつかあります。
1つは「ファイル>配置」メニューから画像ファイルを選択してPSDデータに読み込ませる方法。ちなみにこれは今開いているキャンバスにファイルをドラッグするだけで出来たりもします。



もう1つが、任意のレイヤーをスマートオブジェクト化する方法。レイヤーパネルから目的のレイヤーを右クリックで選択し、「スマートオブジェクトに変換」を選びます。



そしてできたこのスマートオブジェクトのレイヤーは、元の画像を読み込んでいるだけなので、拡大縮小を何回繰り返そうが、回転をしようが画質が劣化することはありません。
ちなみにこのやり直しが可能な状態のことを「非破壊編集」と呼びます。



2.さらにここがすごいよ、スマートオブジェクト
フィルターで画像を処理する場合、数値をいじってはなんか違った、cmd+Zしてまたやり直し...というようなことが多々あると思います。そんな時に目的のレイヤーをスマートオブジェクト化してからフィルターをかけると、適応されたフィルターの処理をレイヤー効果と同じように扱うことができます。
つまり適応した後にそのフィルターを非表示にしたり、元に戻したりといったことが可能になります。



3.ここが残念、スマートオブジェクト
ただし、スマートオブジェクトの弱点もあります。PSDファイル内に別のファイルを埋め込むため、ファイルサイズが非常に大きくなってしまうこと。埋め込んだ元の画像のファイルサイズが大きければ大きいほど、またスマートオブジェクトを多用すればするほど大きくなっていくので、注意が必要です。

また、スマートオブジェクトは別ファイルを読み込んでいる状態なので、そのままでは直接画像にブラシで絵を描いたり、ということができません。それを行う場合、スマートオブジェクトを右クリックしてメニューの中にある「レイヤーのラスタライズ」を行うか、スマートオブジェクトのサムネイルをダブルクリックして、元のデータを直接編集する、という方法で解決することができます。

4.実際、どういうシーンで使っているのか
一例ですが、広告やゲーム内で使用するバナーを作る際にスマートオブジェクトを利用しています。イラストレータの方に描いてもらった絵を素材に、それを拡縮したり回転したりして位置を調節したり、効果を加えたりして小さな画像サイズでも見栄えをよくしたりします。その際、非破壊での編集というのが非常に役に立ちます。

それ以外の作業でもスマートオブジェクトは非常に使える機能なので、ぜひ色々な場面で試してみて、使いこなして下さい!

===

関連情報
写真はコチラからお借りしました
 (by Konstantin Leonov)

一緒に働きたい方、絶賛 募集中
Happy Elements株式会社では、ソーシャルゲームのデザインや、イラストの制作に興味を持っているデザイナーを絶賛募集中です!
アルバイトも積極募集しているので、ポートフォリオを厚くしたい学生の方、チャンスですよ!

2012年8月25日土曜日

websocket + HTML5(canvas)でのゲーム開発(ボンバーマン風)

このエントリーをはてなブックマークに追加

はじめに

エンジニアの@ryooo321です。
よろしくお願いします。

Happy Elements株式会社では勉強会が活発に行われており、
その中の1つに「1.5時間で○○を作る」エンジニア向けワークショップがあります。(毎週開催@京都)
※ ○○は毎週かわり、設計/実装方法などは自由です。

今回はワークショップ2回(計3時間)で作成したボンバーマン風ゲームの紹介を通して、
他人とリアルタイムで遊べるゲームの可能性を感じていただければと思います。
※ 技術的にはwebsocket、canvasを利用
※ ライブラリ/ツールとしてNode.js、CreateJS、socket.io、coffeescriptを利用
※ 急いで作ったのでほとんどリファクタリングされていませんmm

また、おまけとして
サーバーサイドでのcanvas描画とwebsocketでのバイナリメッセージについて
試してみた結果を共有します。

ボンバーマン風

紹介

基本的にはcanvasで表示する形のゲームですが、
websocketを使って異なる端末・ブラウザで描画情報を同期しています。
下記程度のアウトプットを、338行程度のコーディングで可能でした。

※ わかりづらいですが、2つのブラウザで2キャラが操作できており、表示が同期しています。
※ 動画内consoleに流れているのがwebsocketの通信データです。

ソース

説明

1. サーバーサイド(server.coffee)
マップや爆弾や敵、キャラや炎などあらゆるオブジェクトはNodeサーバー上に持っています。
Nodeサーバーは10回/秒のペースで、canvas描画情報をブラウザにpushしています。(描画差分のみ)

サーバー起動時にマップを作成するので、
起動後にアクセスしたユーザーは同じマップで遊ぶことになります。

2. クライアントサイド(public/javascripts/client.coffee)
ブラウザはCreateJSを使ってcanvasに描画するだけです。
画面全体の描画をさけるために静的要素のcanvasと頻繁に書き変わる要素のcanvasを分けました。
静的要素(芝/石)のcanvasは初回のみ描画するようにすることで付加軽減を図っています。
※ キャラ、敵、炎、爆弾の変更情報のみ通信しています。

所感

[CreateJSすごい]
CreateJS(Easel.js)を使うとcanvas操作が驚くほど楽になりました。
(enchant.js以来の衝撃でした++)

[安定のcoffeescript]
coffeescriptを使うことでクラス化やリファクタリングが楽になり、
単純にタイピング量も減りました。

[websocketはリアルタイムで有利に感じました]
websocketを使うとhttpで同じ回数通信するより通信量が少なくなるので、
大規模にやるならwebsocketは有利だと思います。
しかし、この程度のjsonデータ量であれば規模によっては
ブラウザから同じ回数のAPIリクエストを飛ばしてもよいかもしれません。
500qpsさばける構成なら50人が同時接続しても問題ないかもしれません。
(1クライアントあたり10qpsとして)(簡単なjsonを取ってくるだけなので今のつくりでは重くはありません)


おまけ - サーバーサイドでのcanvas描画

概要

サーバーサイドがjavascriptなので、サーバーでcanvas描画しbitmapをブラウザに転送してみました。
ついでにバイナリでのwebsocket通信もやってみました。
ボンバーマン風で使ったwebsocketライブラリ(socket.io)は現時点でバイナリメッセージに対応していないので、代わりにnode-websocketを利用しました。

ソース

説明

下記でcanvasが使えるようになります。
brew install cairo
brew link cairo
npm install canvas
node.js内では
下記でcontextがとれ、描画できます。
Canvas = require('canvas')
canvas = new Canvas(400, 400)
ctx = canvas.getContext("2d")
描画したcontextは、下記いずれかの方法でブラウザで利用できます。(きっと他にもあります)
1. base64エンコードしてwebsocketでpush
socket.sendUTF(canvas.toDataURL())
2. bitmapの色情報のbyte情報をwebsocket(ArrayBuffer)でpush
imagedata = c.getImageData(0, 0, 400, 400)
bin = imagedata.data
len = bin.length
buff = new Buffer(len)
for i in [0..(len-1)]
  buff[i] = bin[i]
socket.sendBytes(buff)
3. 画像ファイルとしてサーバーに保存して、ブラウザからhttpリクエスト
# 実装例は割愛

所感

[微妙]
サーバーサイドcanvasについては、あまり有用とは感じませんでした。
素直にブラウザでやればよいと思います。
canvasで描画した画像をブラウザに送る形にすることで、
ブラウザ側の処理を軽減できるケースがあるとは思います。
SmartPhoneなどのパワーのない端末で巨大なcanvasを使いたい場合などは、
サーバーで大きなcanvasを作成して一部分だけcontext.getImageData()して転送したりもできそう。

[もっといろいろできる]
バイナリメッセージを使えば、音楽・動画も他人と簡単に共有できるようです。
WebSocketのバイナリメッセージを試したら、ウェブの未来が垣間見えた

[ライブラリ利用]
サーバーサイドでCreateJSを使うにはwindowオブジェクトやdocumentオブジェクトを
Node.jsに組み込まなければなりません。
しかし、jsdomを入れるすることでCreateJSやjQueryも利用できるはずです。
※ jsdomは、nodeの環境にW3C準拠のdomオブジェクト群を定義してくれるライブラリです。

[データサイズ]
bitmapは1ピクセルに4byte使うので、縦横400pxでは640,000byteほどのbitmap配列になります。
これをwebsocketで転送してブラウザで表示するには1push/sが限度でしたorz
一方、今回の例では透明領域の大きい画像だったこともあり、
base64にエンコードする方法だと2,000byte程度でした。
これだと、100push/sでもさくさく表示できました。
※ localhostのサーバーです。感覚値で恐縮です。

[Blobでの通信]
ArrayBufferでなくBlobで通信するバイナリメッセージもあり、
canvasでない場合はBlobで通信した方が早いでしょうね。

画像ファイルをBlob転送してみましたが大きくてもざっと問題なさそうでした。



関連情報


・Node.js
http://nodejs.org/

・CreateJS
http://createjs.com/#!/CreateJS

・coffeescript
http://coffeescript.org/

・websocket
http://www.html5.jp/trans/w3c_websockets.html
http://tools.ietf.org/html/rfc6455

・socket.io
http://socket.io/

・jsdom
https://github.com/tmpvar/jsdom

一緒に働きたい方、絶賛 募集中
京都で開発してみたいというエンジニアの皆さん、ご応募お待ちしています!
技術力を伸ばしたい学生さん、アルバイトも可能なのでご応募お待ちしています!
大阪、滋賀、神戸から通勤実績あり


以上、長文にお付き合い下さいましてありがとうございました。

2012年8月23日木曜日

HEKK流ソーシャルゲームのアプリ構成

このエントリーをはてなブックマークに追加
エンジニアの草苅(@kusakari)です。

Happy Elements株式会社(以下、HEKK)では、モバイル向けのソーシャルゲームに注力して開発を行っています(PCアプリは中国の Happy Elements Ltd. で開発しています)。

HEKKでは全社的にサーバーサイドのプログラミング言語を Ruby で統一しており、フレームワークは Ruby on Rails を使用しています。

データストレージには Cassandra と MySQL を併用しており、スケールする必要のあるデータ(ユーザーデータ)は Cassandra、マスターデータ(例えばアイテム情報)は MySQL に保存するという形で区別しています。

HEKKで開発しているソーシャルゲームの典型的なリクエストフローは、次の図のようなものです。

今回は Rails より後ろのデータストレージ3つを、どのように利用しているかについて簡単にご紹介します。

Cassandra

Apache Cassandra は facebook で開発された大規模データ処理用のKVS(Key Value Store)です。
利用箇所としては前述の通り、ユーザーデータ用のストレージとして利用しています。
HEKKでソーシャルゲームのデータストレージに Cassandra を選択した主な理由は、次のようなものです(一般的によく使われていると思われる MySQL との比較)。

書き込みがリニアにスケールする
ソーシャルゲームは通常のウェブサービスなどと比較して、書き込みの割合が多くなるため、書き込み処理がボトルネックになりやすい傾向があります。そのため、書き込みがリニアにスケールする必要があります。

単一障害点がない
MySQL の場合、マスターが落ちた際に無停止でサービスを運用し続ける難易度は高めです。特にソーシャルゲームで MySQL をメインのデータストレージとしている場合、必然的にDB分割なども必要になってくるため、さらに難易度は高くなります。しかし、Cassandra であれば単一障害点がないため、シンプルな構成で安定したサービス運用が可能です。

書き込み先のサーバーを意識する必要がない
MySQL の場合、アプリかアプリと MySQL の中間層が、書き込み先の MySQL サーバーを意識する必要がありますが、Cassandra であれば ring 内のどのサーバーに書き込んでも問題ないため、サーバーが増えたとき、減ったときなどにシャーディングに関する面倒な問題が発生しません。

ここまで Cassandra の良い点ばかり書いてきましたが、もちろん実際は良い点ばかりではありません。Cassandra と MySQL を比較した時に弱い点の一つとして、クライアントライブラリがあります。

Ruby 用のクライアントライブラリである cassandra.gem がミニマムな機能であることもあり、HEKKでは、Cassandra 内のデータへ ActiveRecord に近い感覚でアクセスできるように cassandra_object.gem を利用しています。また、実運用に耐えうるように、独自に次のような機能拡張を行っています。
  • Cassandra 0.7 以降に対応。
  • 追加の Callback Methods に対応。
  • register_attribute_type の MessagePack 対応。
  • Ruby 1.9.2、1.9.3に対応。
  • Rails3 専用にリファクタリング。

例えば、CassandraObject::Base を使うと次のように書けます。
class User < CassandraObject::Base
  attribute :nickname, :type => :string
  attribute :date_of_birth, :type => :date
  attribute :joined_at, :type => :time_with_zone
  attribute :preferences, :type => :msgpack
  key :uuid
  consistency_levels :read => :one, :write => :one
end
user = User.new(:nickname => "kusakari")
user.preferences = {:hoge => "A", :fuga => "B"}
user.save
user = User.get(uuid)
 => #<User:0x000000XXXXX @schema_version=nil, @key="YYYYY", @attributes={"nickname" => "kusakari", "preferences" => {"hoge" => "A", "fuga" => "B"}}>

さらに、CassandraObject::Base で対応できない、動的な Column Key のデータに対応するため、 cassandra.gem のラッパーライブラリとして CassandraObject::Lite::Base を開発して使用しています。


Memcached

Memcached はご存じの通り、キャッシュ用のミドルウェアです。
利用箇所としては主に MySQL のマスターデータのキャッシュ用ストレージとして利用しています。

memcached 用クライアントライブラリとしては dalli.gem(または memcache-client.gem) や memcached.gem がありますが、大きな違いは dalli.gem と memcache-client.gem はピュア Ruby、memcached.gem は c で書かれているという点です。HEKKでは memcached.gem を使用しています。
ただ、Windows 機で開発している場合、 memcached.gem が利用できないということもあり、memcached クライアント用のラッパーライブラリを作ることによって、アプリからは内部的に使用している gem を意識しないで済むような作りになっています。また、このラッパーライブラリ内で marshal load 時の Model の自動ロードなどの処理を行うなど、実用的な作りとなっています。

MySQL

MySQL については特筆すべきことはありませんが、前述の通り、基本的にはマスターデータのストレージとして使用しています。それに加えて、検索条件が必要になる場合や 、(Cassandra にはない)トランザクションを使って、強い一貫性を保障したい場合には MySQL にデータを格納するようにしています。
また、テーブルが一定以上の大きさになるような場合は、MySQL 5.1 以降で利用できるパーティショニング機能を使用するようにしています。


ということで、HEKK で開発しているソーシャルゲームのアプリ構成の中から、データストレージ部分について簡単にご紹介しました。

Rails や Cassandra を使って、大量のトラフィックをさばくソーシャルゲームを、京都で開発してみたいというエンジニアの皆さん、ご応募お待ちしています!

2012年8月20日月曜日

Bloggerに快適に投稿するたった1つの方法

このエントリーをはてなブックマークに追加

はじめに

はじめまして。Happy Elements株式会社のクズエンジニアの西村(a.k.a Sixeight)と申します。
どうぞよろしくお願いします。

持ち回りで会社ブログを書くことになったのですが、個人的にこのbloggerはあまり使い勝手が良くないと思っています。 個人ブログもやっていたのですが、更新が面倒くさくて放置してしまっています。 しかしながら、書きたくないと言っていられる状況でなくなってしまったので、快適に投稿出来るような環境を整えました。 今回はそのことについて書くことで、お茶を濁させて頂きます。

前提

ブログのように日常的に書くものは、日常的に使っているもので書くのが一番だと思います。 僕は仕事の大半をVimで行なっているため、今回はVimから快適に投稿出来る方法を模索しました。

今回は投稿にujihisaさんのblogger.vim、執筆中のMarkdownのプレビューにquickrunを使うことにしました。 どうも先駆者がいらっしゃるようで、今回の内容のほとんどがこちらのエントリ(VimからBloggerへ快適に投稿できるようにする)で解説されております。 もう、この記事いらないじゃないかと思ったのですが、一部手順が異なるのと細かい点に触れつつ、僕の作業まとめとして記述させて頂きます。

この記事は Mac + MacVim + Homebrew + rbenv な環境を想定しています。

プレビュー

quickrunをご存知ですか。さまざまなコマンドをvim上で実行して結果を出力用のbufferを開き表示します。Vimでプログラミングをされていて、quickrunを使用されていない方はいますぐ導入すべき必須pluginです。ujihisaさんが最初のバージョンを書かれましたが、現在はthincaさんがフルスクラッチで書き直されたものが主流となっています。 今回はこのquickrunを利用して、Markdown形式で執筆中の記事をブラウザで実際に表示して確認してみます。

pandocのインストール

Markdownで記述したものをHTMLへ変換するためにpandocを使用します。個人的にはRedcarpetを使いたかったのですが、pandocのようにDOCTYPEなどを自動で追加してくれず、日本語が文字化けする問題を解決出来なかったため断念しました。

pandocはHomebrewでは提供されていないため、まずは、HomebrewでCabalをインストールして、その後Cabalを使ってpandocをインストールします。

$ brew install cabal-install
$ cabal update
$ cabal install pandoc

quickrunの導入

pandocの準備が出来たので、quickrunをインストールします。一般的なVim使いの方はすでにインストールされているかと思いますので読み飛してください。 Vundleを使います。モダンな方はneobundle.vimを使うようですが、個人的にはVundleのシンプルUIに満足しており、neoという名前に抵抗があるという宗教的な理由でVundleを使い続けています。(もちろんneocomplcacheは必須なため使用しています。) Vundleについては過去に書いたエントリがあるので、そちらを参照してください。(Hack #215: Vundle で plugin をモダンに管理する)

インストールは簡単で、~/.vimrcに以下を追加して、:BundleInstallとすると完了します。今回はquickrunのbrowser outputterを使用するために、open-browser.vimを、MarkdownのSyntax Highlightのために、vim-markdownもインストールします。

Bundle 'thinca/vim-quickrun'
Bundle 'tyru/open-browser.vim'
Bundle 'hallison/vim-markdown'

quickrunの設定

最後に、Markdown形式のファイルを開いているときにquickrunを実行することで、HTMLに変換したものをブラウザで表示出来るように設定します。 設定はHack #230: Markdown形式の文書を書く2 (quickrun0.5.0対応版)の通りにすると問題ないかと思います。

let g:quickrun_config = {}
let g:quickrun_config['markdown'] = {
      \ 'type': 'markdown/pandoc',
      \ 'outputter': 'browser',
      \ 'cmdopt': '-s'
      \ }

実行

Markdown形式のファイルを編集中に以下のコマンドを入力することで、ブラウザが起動し変換されたHTMLが表示されれば成功です。

<leader>r

blogger.vim

先述のようにblogger.vimを使用します。これは自信もBloggerを使用されているujihisaさんが僕のように投稿を楽にしたいという思いから阪急電車の中で書き始められたpluginです。 以下のものに依存しているため用意しておく必要があります。

  • vim 7.2+
    • metarw 0.0.3+
  • ruby 1.9.2+
    • (gem) nokogiri 1.4.2+
    • (gem) net-https-wrapper
  • pandoc 1.2+

metarwのインストール

metarwは、VimのRead/Writeを抽象化してなんでもかんでもVimで読み書きしようというpluginです。(あってます?) blogger.vimはこれを用いて、Blogerへの投稿や、記事の取得を行ないます。

これもVundleを使います。以下の~/.vimrcに追加して:VundleInstallで。

Bundle 'metarw'

Rubyまわりの準備

blogger.vimはblogger.rbというRubyのスクリプトを使っています。

Rubyはとりあえず1.9.2を使っておきます。(普段使いは1.9.3を使いましょう) ふつうにrbenvでインストールします。

$ rbenv install
usage: rbenv install VERSION
       rbenv install /path/to/definition

Available versions:
    ...
    1.9.2-p320
    ...
$ rbenv install 1.9.2-p320

依存gemも特に難しいことはなくRubyGemsでインストールします。

$ rbenv shell 1.9.2-p320
$ gem install nokogiri --no-rdoc --no-ri
$ gem install net-https-wrapper --no-rdoc --no-ri

pandoc

pandocはさきほどインストールしているので問題なしです。

設定

最後にblogger.vimの設定を行ないます。公式の設定に習い以下のように~/.vimrcに記述します。

let g:blogger_blogid = 'your_blogid_here'
let g:blogger_email = 'your_email_here'
let g:blogger_pass = 'your_blogger_password_here'
let g:blogger_ruby_path = '/path/to/ruby'

blogidはBloggerの編集画面などのURLに含まれるblogIDというパラメータの値です。 メールアドレスとパスワードはBloggerのアカウントのものを記述してください。 (.vimrcをgithubに上げられている方はこのあたりは別のファイルに切り出した方が良さそう。)

最後のRubyのパスですが、rbenvを使っている場合はversionsディレクトリ以下のrubyを指定しておくと、バージョンを固定出来ます。 1.9.2-p320の場合は以下のような感じ

let g:blogger_ruby_path = '/Users/yourname/.rbenv/versions/1.9.2-p320/bin/ruby'

これですべての準備が出来ました。

使ってみる

では、公式のドキュメントに習ってblogger.vimを使ってみましょう。

記事の一覧の取得

以下のようにすることで記事の一覧が取得出来ます。タイトルの一覧が表示されますので、開きたい行にカーソルを合せて<Enter>を入力することで開くことが出来ます。この時、pandocを用いてHTMLをMarkdown形式に変換して表示してくれるため、そのまま編集することが出来ます。

:e blogger:list

投稿する

投稿するには適当なbufferを開いておもむろにMarkdown形式で記事を書きます。この時一行目がタイトルになります。 またタイトルの先頭にDRAFTと付けることで、下書き状態で投稿することも出来ます。 quickrunを使用してプレビューしつつ記事を書き上げます。

記事が完成したら、以下のようにすることでBloggerに投稿されます。

:w blogger:create

どうですか、投稿されました? エラーが出た場合は以下のようにすることで回避出来るようです。

:w! blogger:create

DRAFTの状態で投稿して、実際にBlogger上でプレビューすることで微調整を行なってから投稿するのが良さ気です。

最後に

だらだらと作業ログを書きましたが、まだ一度も投稿しておらずこの記事がうまく投稿されることで、この記事の正当性が証明される仕組みとなっております。 これで快適にブログを書くことが出来るようになり、ばんばんと良記事を書けるようになるでしょう。

一部の人が喜びそうなネタを選びつつ書いていきたいと思います。今後ともお付き合い頂けますと幸いです。

参考URL

  • blogger.vim: http://github.com/ujihisa/blogger.vim
  • quickrun: http://github.com/thinca/vim-quickrun

お詫び

なんかうまくいかなかったので、pandocが掃き出したHTMLを貼り付けました。

2012年8月13日月曜日

Macを使いこなして仕事の効率10倍アップ
〜知ってて得する小技とアプリ特集(1/3)〜

このエントリーをはてなブックマークに追加

はじめに

はじめまして、Happy Elements プランナーのアレックスです。

パソコンを使う職業である以上、その環境をいかに使いこなせるかが効率アップへの近道になっていると考えています。どうでもいいことに思えるかもしれませんが、小さいことの積み重なりがかなり邪魔になっている場合もあります。

そこで、今回の記事ではMacユーザー向けにいくつかの小技や便利アプリを紹介したいと思います。個人的な趣味に関わってくる部分も多いと思いますが、1人のギークの実例として参考にしていただければと思います。

少し内容が多くなったので、3部作とさせて頂きます。
内容としては:

1部:OSXの小技
2部:便利アプリ特集
3部:便利アプリ(Alfred特集)

それでは早速、第1部の「OSXの小技」からどうぞ。

OSXの小技

まずは、OSレベルでの設定の話。ここでの大きなテーマは、画面のレイアウトアクションのスピードです。

画面のレイアウト


画面は大きければ大きいほど使いやすいので、まずはディスプレイを使うことをオススメします。複数アプリを隣同士で開けると後戻りが出来ないぐらい快適です。

画面のスペースを有効的に使うという話では、Dockは画面の横に置くべきだと思います。元々横幅のほうが余裕あるのに、画面の下にDockを置くと縦幅をさらに狭くすることになります。この場合も、Dockはなるべく小さくするのがベスト。
よこに寄せると快適

画面の使える部分をなるべく正方形に近づけて、画面いっぱいにアプリを広げるとスクロールがほとんど必要なくなり、効率良く作業が進みます。

画面スペースの管理


全画面でアプリを使うとアプリが重なってくるのは当たり前なので、ここでよく上げられているのがOSXのSpaces機能。デスクトップを仮想のスペースでいくつかつなげることによってワークスペース管理が可能になり、「ツイッターとメールは左上、ブラウザとパワポは左下、その他は右上」、のような使い方があると思います。

ただ、僕は個人的にはSpacesを使っていません。なんとなくですが、ワークスペースが横並びになるとアプリ間の距離が増えるように感覚で、思うようにサクサクといけません。

Spacesの代わりに、単純にアプリスイッチャーの利用をおすすめします

アプリスイッチャーとは、Cmd+Tabで出てくるあれ。
そう、これ

この機能を活用すると、同じスペースで使っていても一瞬で使いたいアプリを前に呼び出せるので高速で切り替えが可能です。スペース移動のアニメーションが入らない分早かったり、Tab押してからすぐCmdを外すとスイッチャーのUIが出ずにすぐに最後に使ったアプリに切り替わったり、超スピーディーです。

スイッチャーのUIはさらに使いこなすことが可能です。マウスオーバーするとアプリが選択され、Tabを連打せずにアプリを選べる。アプリを選択中にCmd+Qなどのホットキーを押すとそこからアプリの終了ができる。スイッチャーのアイコンにファイルをドロップできる。などなど。これ必須です。

キーボードショートカット


さっきのスイッチャーの話でもポイントとなっていましたが、操作のスピードはかなり大事だと考えています。

まずは、なるべくマウスを使わずキーボードで操作すること。ホットキーを使い慣れるとUIのボタンを押しに行くタイムロスがなくなり、快適です。

なるべくシステムのホットキーを覚えることをオススメしますが、実はOSXってほとんど何にでもホットキーを付けることができるんです。どうするかというと、Snow Leopardから登場した「サービス」という機能が活躍します。

環境設定の「キーボード > キーボードショートカット」に盛りだくさんのサービスが登録されています。
本当にやたら多いんです


これにそれぞれショートカットを登録することが出来ます。例えばデフォルトで、適当に文章を選択してからShift+Cmd+L を押すとSafariでGoogle検索が走ります。試してみてください。ショートカットが無いサービスも、右側をクリックすると好きなショートカットを設定できます。

ここにあるサービスだけでもかなり数はあるんですけど、さらに、自分で作ったサービスを登録することも可能です。Automatorを開く時にサービスとして作成をすることが出来て、そうすると自作のワークフローがこの画面にあらわれて好きなショートカットを設定できます。

例えば私が作ったものだと、「Sparrowで新作のメールを開いて、Finderで選択されているファイルを添付する」というアクションがショートカットで走ります。

初めて使った時は感動しました

ワークフローではなんでも作れるんで、本当にショートカットキーの使い方は自由自在です。頻繁に行う動作があれば、それを1−クリックで自動化してみませんか?

おわり

第1部、小技の話は以上となります。次回では、無駄の無い操作に役立つ便利アプリをいくつか紹介したいと思います。便利すぎてなくなったら泣いちゃうぐらい愛用しているものばかりなので、初めて聞くアプリがあれば是非使ってみて欲しいと思っています。

ではでは、また次回まで。

最後まで読んでいただき、ありがとうございます!