Emacsの見た目を思ったよりかわいくカスタマイズする
好きなアドビは Fireworks です。murokacoです。フリーランスでWebデザイナーをやっています。
さて、前回の記事で予告したとおり、 今回は Emacs のカスタマイズについて書いていこうと思います。
Emacsだと背景に画像が設定できるらしい
のが、そもそもテキストエディタを(Vimから)乗り換えるきっかけになったんですが
先日のこと。
飲み友達(男性 50代 会社員 社内SE) 「Emacsこそ最強のテキストエディタなんだよ！」(注: 別に宗教戦争の流れではないです)
わたし「Emacsかー。わたし全く使ったことないんですが、どういう点が最強なんですか？」
飲み友達「メールが送れる」
わたし「えっ」
飲み友達「メールが送れる」
わたし「…メールはメーラーがあるのでいいです。」
飲み友達「背景に好きな画像が設定できる」
わたし「テキストエディタで画像を表示するってなんか変な感じが…」
飲み友達「自分の好きなように見た目を変えられるんだよ。いいでしょう。」
わたし「うーん、まあ確かに今のVimの見た目変えたいなーとは思ってたし…背景に画像、好きなの配置するのは確かによさそうかも…」
いつも見てる画面に自分の好きな画像が表示されている状態って仕事が楽しくなっていいかも！試しにやってみよう！！
というわけで、今回わたしがやったのは
- 背景画像を設定する
- カラーテーマを指定する
- その他もろもろ( scratch を非表示にするとか)
です。
Emacsの背景に画像を指定する
Macに XQuartz を入れる
今回あてたいパッチだと、MacOSで X が動いている環境でしか動作しないようなので XQuartz を入れます。
ここはほとんど人の手を借りて乗り越えた壁なので説明を省略します…… (Oさん、その節は本当にありがとうございました囧！)
BGEX をあてる
背景に画像や色を設定できるようになる BGEX というパッチをあてます。
wac's webpage./Emacs-BGEX patch 今回はわたしの Emacs が 24.4 なので 24.4用のパッチをあてます。 一連の流れは example に書いてあるので、それに従いつつ自分の環境にあわせてコマンドたたいていきます。
BGEX を落としてくる
わたしの環境には wget がないので curl で。 Emacsのディレクトリ内に移動した後、
curl http://umiushi.org/~wac/bgex/patch-bgex_20140112_0-bzr-emacs-trunk.tar.bz2
で落としてきます。
解凍する
tar xjvf patch-bgex_20140112_0-bzr-emacs-trunk.tar.bz2
パッチをあてる
patch < patch-bgex_20140112_0-bzr-emacs-trunk/patch-bgex_20140112_0-bzr-emacs-trunk
ビルドする
./configure --prefix=YOUR-INSTALL-PATH make sudo make install
画像を emacs.d/ に置いて、設定ファイルで画像の呼び出しを指定する
前回の記事で書いた、 emacs.d/ に背景に指定したい画像(今回は bis_white.png という名前のpngです)を置いて、 emacs.d/init.el に
;; background-image (when (boundp 'bgex-exist-p) (bgex-set-image-default "YOUR-DIR-PATH/bis_white.png"))
(YOUR…のとこには置いた画像へのパスをかきます。) と書いて保存します。
カラーテーマを指定する
今回は Emacs にデフォルトで入ってるテーマから選択しました。 下記を emacs.d/init.el に追加するだけ！
;; color-theme (load-theme 'adwaita t)
参考- Emacs24に最初から同梱されているテーマ - AOEの日記
そして Emacs を再起動すると…
できたー！
今回背景に指定したのは BiS っていうアイドルのロゴです。 わー！テンションあがるわー！
というわけで、(個人的に)かわいいと思える(今のとこ)最強のテキストエディタができました！
ちなみに、 BiS をご存知ない方からすると特になんてことないシンプルな壁紙(そして格別かわいくもない)じゃんって思うかもしれませんが、
デビュー曲のMVで メンバーが全裸で樹海を駆け抜けていたりする なかなか衝撃的なアイドルなので、
アラフォーの女性が使うエディタとしては、なかなかの痛エディタに仕上がったと思います。
が、これからもう少し設定いじって、もっと痛めに育てあげていくつもりです。
ちなみに最近のBiSお気に入り曲はこちらです↓
(仕事中に見るのはあまりおすすめできません)
最後に突然の謝罪
数カ月前のことなんですが
わたし「Aさんはテキストエディタ何使ってるんですか？」
Aさん「Vimなんです。気持ち悪いですよね。2015年にもなってぼくまだ Vim 使ってるんですよ。vimrcも170行ぐらいになっちゃってるし、気持ち悪いですよね。他のテキストエディタ、○とか□とか使ってみたんですけど、結局 Vim に戻って来ちゃって…気持ち悪いですよね。この次使いたいエディタも NeoVim なんですよ、気持ち悪いですよね！」
わたし「いや、気持ち悪くはないですけど…www うーんと、なんていうか… Vim 愛凄いですねwww あ、そういえばBさんは何使ってるんですか？」
Bさん「Emacs です」
わたし「Emacs 使ってるんですか！気持ち悪いですねw(愛があるんですね)」
その後ツイートにて
わたし「Emacs使ったこと無いのに気持ち悪いなんて言うの、酷すぎるなわたし」
と、その場ののりで発した「Emacs使ってるんですか気持ち悪いですね」「使ったこと無いのに気持ち悪いって言う」の部分だけがネット上で炎上し、 Emacsをお使いの皆さんに大変不快な思いをさせてしまった事件がありました。 意図違いとは言え、歴史あるエディタをよく知りもしないのにネガティブな言葉で表現をするという失言について、本当に深く反省しております。
そして、今件に関して関係者の皆様にも多大なるご迷惑をおかけしましたことお詫び申し上げます。
というわけでこれが今年最後のブログになりますが、来年もよろしくお願い致します！
テキストエディタの設定ファイルを dotfiles において Github で管理していく生活
これまでも .vmrc を dotfiles において Github 上で管理していたのですが、 はじめて自力で新しいエディタ(今回は Emacs です)の設定ファイルを追加したので その手順を記しておきます。
よくわからないままやったので、間違ってたりもっと良い方法があればご教授ご教示いただけますと幸いです…
dotfilesに .emacs.d/init.el を置いて、シンボリックリンクをはる
まず、シンボリックリンクって何かというと
シンボリックリンクとは、Windowsでいうところのショートカットのようなもので、ファイルや、ディレクトリを参照するファイルの事をいいます。
引用: シンボリックリンクとは
です。
Emacsの設定ファイル( .emacs.d/init.el )を dotfiles に移動させる前に、設定ファイルがそこにあるよーというのを設定しなくちゃいけません。たぶん。
シンボリックリンクはるようのシェルスクリプトを作成する
こちらのブログを参考に、dotfiles 以下に setup.sh というシェルスクリプトを作りました。 setup.shの中身↓
#!/bin/sh
cd $(dirname $0)
for dotfile in .?*
do
if [ $dotfile != '..' ] && [ $dotfile != '.git' ]
then
ln -Fis "$PWD/$dotfile" $HOME
fi
done
すぎゃーんさん、その節はご解説までいただきましてありがとうございました！！！
.emacs.d/init.el を dotfiles に移動させる
わたしの環境の場合、 .emacs.d/init.el はUsers 直下にあるので黒い画面で下記コマンドで移動させます。 (ちなみに dotfiles も Users 直下においてます)
mv ~/.emacs.d/init.el ~/dotfiles/
さっき作ったシェルスクリプトを実行する
下記コマンドをターン！
sh ~/dotfiles/setup.sh
出来ました(たぶん)！
この後は .emacs.d/init.el をgit でadd して commit して Github に push してお終い。
まだほとんど何も書いてないですが、これからちょっとずつ育てていこうと思います。 ちなみにわたしの dotfiles はこちらです。うふふ
それにしても、一年以上vim使ってきたはずなんですけど dotfilesのcommitみた感じだと書き足されて無さが酷いので、 Emacsはもう少しがんばろうと思います。
というわけで
次回の記事予告
Emacsの見た目を思ったよりかわいくカスタマイズする
を書くつもりです。お楽しみに！
Git初心者が初心者に教えたGitコマンド9つ
先日、Gitを使ったことない方にGithubでページを納品してもらう事になったため、 急遽Gitのハンズオンをすることになりました。 (お相手2名とも非エンジニア・デザイナーの方です)
目的が「明日Gitを使ってGithub上で納品PRを出す」だったので 覚えてもらうgitコマンドは最小限にしました。 (ちなみに今回はリモートでサポートする必要があったため、われわれと同じ 黒い画面 を使ってもらうことにしました。)
たった9つのコマンドを覚えるだけとか、 Bootstrapのコンポーネントを覚えるより学習コスト低いと思うので、 まだ使ったこと無い方、分厚い本を読む前にまずはやってみるのおすすめです！
覚えてもらったGitのコマンド
Github からリポジトリをcloneする
git clone hoge
作業ディレクトリに任意の名前をつけたい場合はこちら
git clone hoge ***
(***に任意の名前を入力)
Github からGitの履歴の最新情報をとってくる
git fetch
masterブランチをローカル環境に取り込む
git pull origin master
作業ブランチを作成する
git checkout -b ***
(*** = ブランチ名)
Gitにaddする
- 制作物をgitに追加する
git add ***
add 以降は、その時追加したいものを指定してください。
- 追加出来たか確認する 下記コマンドを打つと変更分が出ます。
git status
- Gitにcommitする
git commit -am "***"
Githubにpushする
git push origin ***
(*** = ブランチ名)
感想(というか反省)
gitのインストール、その他各種設定などは事前にやってきてもらうべきだった。。 (サポートしてくださったエンジニアさん、ありがとうございました！！) 手順書(上記のコマンドに説明を補足したもの)を事前に用意しておいたので、メモに時間をとられることなくスムーズに進めることが出来た(と、思う…)。
追記
ブログを見た方から、GUIで良いのではーって言われて調べたら、マジGUIのほうが楽だった！ http://qiita.com/take/items/29fb6adaec230022fe89
同じ現場でGUI使ってるデザイナーさんが困ってる時に誰も助けてくれないの見かけたことあるので、わたし自信は黒い画面で覚えるのが結果一番楽だなーとは思うけど、どちらにしても使用頻度が高くは無さそうな場合、コマンドではなくGUIのほうが良さそうー
webデザイナーも読める「アジャイルサムライ」
「アジャイルサムライ」まだ読みかけなのですが、
自社webサービスでデザイナーやってます、のようなチームで日々動いてるデザイナーさんは読んだほうが良いと思います！！
ということで久しぶりのブログです。
たぶん、わたしはアジャイルなチームの一員として働くようになって、かれこれ4年目ぐらいです。
4年前、わたし(情弱)の耳にようやく「アジャイル」という言葉が聞こえてきた時、同じチームにいたYさんに質問しました。
4年前のわたし「アジャイルって何なんですか？」
4年前のYさん「むろさんが今馬車馬のように働かされてる現状のことだよ」
今のわたし「それは間違いです！！！！」
って、アジャイルサムライを読んだ今なら言える。
"馬車馬のように働く" と "アジャイルな体制" というのは対義にあるはずだ(て、まだ読み終わってないので理解しきれているか不安)。
本の文体が柔らかめなので読みやすいし、内容も自分に置き換えて読み進めることが出来るので、同じチームにデザイナーさんがいる現場の方々は一度勧めてみるのが良いと思います。
ちなみに、わたしが今回読むキッカケになったのはインセプションデッキに参加することになったので業務上読む必要にせまられたためだったのですが
うおおお とても読みやすい！！！
— 囧 (@murokaco) 2015, 3月 31
非常に高いUXを体感している様子でした。
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (252件) を見る
わたしはKindle版を買いましたー。いつでも読みたい時に読めるのありがたい！
RubyKaigiでデザインテロした話
RubyKaigiの2日目のLTでタイマー係りさせていただけることになったので、RubyKaigiに初参加してきました。
最初は@igaiga555 さん作のタイマーをローカルで動かしてモニタに映し、止めたり動かしたりする簡単で重要なお仕事(を、作者でこれまでタイマー係を担当されてきた@igaiga555さんに補佐して頂きながら)をする予定だったのですが、ルビー会議のロゴかわいいし、会場のいろんなとこでルビー会議デザインテイストのものを見かけて、これはタイマーアプリもテイスト合わさねば！！と思い、急遽、会場でデザインテロすることにしました。
休憩時間中に@igaiga555 さんに使い方を教わり、デザインの変更の仕方を教わり、そこ(たぶん16時ぐらい)から作業スタート。
バックグラウンドの画像とフォントの色をいじっただけなんだけど、縦横比があわないとか、フォント色の指定をGUIでぐりぐりするしかない（rgbの数値を入力したりとか出来ない）とかで大したことしてないのに地味に苦戦しました。
途中でMBPの充電が切れそうになり、近くの柱にコンセントがあるのを見つけて、作業を続けてたんですが、気づけば床にパソコン置いてorzみたいな体制で作業してて、それを見つけたオーガナイザーの○さんに
「女性でそれはない！」
と言われてしまうぐらい残念な感じになってて、お見苦しいものみせてしまったし、風紀を乱したと反省してます。。
(後で謝罪にいったら「コンテンツとしては有り」と言っていただけたので少し救われましたが…)
まあ、とりあえず時間までになんとなく見せられるもの出来たし、突発的ハッカソン楽しかったし、ルビーストじゃないのに参加させて貰えて嬉しかったです。
えにしテックのまゆこさん(RubyKaigiのロゴやその他色々のデザインを担当されている方です)にもご挨拶できて、うれしみ。
タイマーアプリが私のローカルで動かないのを、就業後にお手伝いくださった@120resetさん、突然のデザイン変更を生暖かく見守りながら指導・補佐してくださった@igaiga555さん、そして色々とお忙しい中わたしのようなもののテロを受け入れてくださったかくたにさん、ありがとうございました！！！！
あと蛇足ですが
"デザインテロ"は、あくまで"依頼されていないのに勝手にデザインを送りつけること"を意味していて、送りつけること自体に悪意はなく、今回のタイマーももともと特にデザインに因縁つけたいとかそういう意図は全くなかったです。
エンジニアじゃなくてもGemが作れたよ - 第十二回 RailsGIrls, More!@株式会社万葉に参加してきました
今日は万葉さんで開催された、Rails Girls Moreに参加してきました。
初めての参加なのでどきどきしたのですが、私のコーチ担当してくださったのが@joker1007さんで、その点がとてもラッキーでした。
というのが、@joker1007さんは、私の今回の目的「Gemを作りたい」に最適な、パーフェクトRubyでGemの部分を執筆された方だったのです！
というわけで、執筆されたご本人から直々にパーフェクトRubyを教科書にしながらレクチャーを受けるというとても贅沢な勉強会になりました。
成果物
gem_sampleはパーフェクトRubyに書かれている通りに作っただけのものです。
sass_animationsの中身は
http://www.justinaguilar.com/animations/index.html
をsassに書き換えただけのやつなのですが、これから自分用に育てていく予定です。楽しみだー
感想
- @joker1007さんがとてもわかりやすい説明をしてくださったので、「何か質問あれば聞いてください」って言われても「特にないです」状態だった。
- sass呼ぶだけのgemなら超簡単で、sassさえあれば10分未満で作れてすごい
- 1日中コーチが1on1で付きっきりで教えてくれるので自分の勉強したいことだけに集中できるので良かった。
- 女性が多い(というか100%だ)となんだか安心する。
- コーチのみなさんが全員揃ってやさしいこと鬼のごとし
- 主催者のおだぎりさんのもつ雰囲気の良さと気配りが凄くて癒やされた:)
おだぎりさん、そしてコーチの皆様ありがとうございました！
非エンジニアでも心折れずrailsと仲良くなる方法の2,3
すいません、murokacoです。
謝罪からはじまりましたが、前回から日付が開いてしまい本当にすいません。。
別々に記述したかったのですが、
前回のエントリーから、既に2・3 回とレッスンは終了してしまいました。。
私の体調不良が原因で書くことができなかったのですが2回を1つにまとめさせて頂きます。。
本当にもうしわけございません。。
前回を知らない方は下記からどうぞ。
http://murokaco.hatenablog.com/entry/2013/12/16/134839
前回のエントリーを見た方から「この成果をどこかでLTをするべきだ」というご意見も頂いたのですが、
もしそういうニーズがあればご遠慮なくFBなりtwitterなりでご連絡ください。
私は絶対にやりませんけどね。
コーチをしてくださってる方の情報の方が有力だと思うのでコーチにその旨をお繋ぎいたします。
というわけで、コーチ(先生)が、レッスン毎に人体実験ばりに毎回レッスンについてメモをとってくださってるので
それがいつか明るみになると信じて、私はモルモット目線でゆるふわに成果と感想だけを書いていこうと思います(他人任せ)。
Rails girl2,3(前回・前々回のレッスン)での成果
です。
やってみて本当に実感した1on1の良さ
一回目でも感じた点も含まれますが
- 教えてもらってる以上、わからないまま終えられないという謎の責任感が生まれる
- 理解できなくて先に進められないとかの離脱が起きないので良い
- 疑問に思った点を自分のタイミングで質問し解決できる
- 私の理解力に合わせて説明してもらえる
です。
これは1on1でないと体感が難しい点だと思います。
1・2、3つめに関しては私の主観ですが、4つ目に関しては先生の知識と理解力、つまり「わからない」の受け取り方によるとは思います。
私は理解できない場合は実直に言う方なんですが、多数の生徒がいる場合だと
- わからないけど、誰かが質問するだろうから私からは質問はいいかな…
とか、
- 誰も質問しないってことは理解できないて私って理解力低いのかな…
と思って質問できない場合が多々あるのですが、
今回、コーチングしてくれた先生は、「わからない」を「わかる」方だったというのもあり、わかり難いだろうなーという所は重ねて説明・例えばの実例あげての説明をしてくれたり、都度「難しいところだと思いますがわからない所ありましたか？」と確認・質問の場を設けてくれました。
※もう少し詳細をあげると、こういう時はなんていうコマンドを叩きますか？とか、この1文はどういう意味でしょう？とかを確認・質問として提示してくれていました(結構な確率で答えられなかったですが。。)。
他者がいないので、私がわからなければ私が質問すれば良いし、答えられなければ恥ずかしがらずにわかりませんと言えるし、私が疑問に思ったタイミングで質問すれば良い、というだけなのですが、本当にこれが大きくて、私は何度も1on1を選択してよかったなと思いました。
感想
- 講義を受けるだけだと、理解はできるが覚えていない
です。まあ当然といえば当然ですが。。
1on1のレッスンで3時間だと、1回のレッスンでプログラミング初学者にとっては理解するもの・覚えなければならないものが本当に多くて
教えられた段階では理解・覚えていたつもりが、例えば1時間後に確認されると覚えてない、とかがあって死にたみが高まりますのでメンタル面においてご注意ください。
あと、これは個々の感性によるものかなと思いますが、良かったーという感想としては
- 先生から突然投げられた問題に正解した時に「正解です」とか「完璧です」とか言われだけで、小さな承認欲求が満たされてえへへとなる。
- 質問に対しても、答えてもらった後に「良い質問だったと思います」とか言われるとえへへとなる。
です。どちらも語尾に(小並感)が付きます。
以上です。
