※スマホ対応はしてません。

カテゴリー: 開発環境

Neovim for Windowsでcolorschemeを置く場所は本体らへん。

カテゴリー: 開発環境

<Neovimインストール先>\share\nvim\colors に foo.vim を置いて、 init.vim で colorscheme foo する。ディレクトリはないので自分で作る。

ちなみにGUI版は <Neovimインストール先>\bin\nvm-qt.exe ね。

ちゃんとやらないとこんなエラー。

E185: Cannot find color scheme 'foo'

当たり前すぎるのか情報が見つからなかった。まあgvimもこんな感じだったっけな。

あんまり関係ないリンク

「Web製作者のためのGitHubの教科書」は非技術者におすすめの本です。

カテゴリー: 開発環境

著者の一人、平木聡さんから頂いてましたので、紹介させて頂きます。

GitHubは年中無休なので、お正月に本書を読みながら諸々を試しておくと、新年の業務がスムーズになるんじゃないすかねー。

概要

  • GitだけでなくGitHubだけの機能も紹介
  • GUIアプリ(SourceTree Win/Mac)とコマンドラインとの両方で作業を解説
  • 画像多数、ちなみに総天然色
  • 言い回しや書体、図解が読みやすい

    (さらに…)

最初にドキュメントから書く話。(JavaScriptおれおれAdvent Calendar 2014 – 17日目)

カテゴリー: 開発環境

JavaScriptおれおれAdvent Calendar 2014 – 17日目

特にライブラリー的なものを作るとき、最初にドキュメントを書くようにしてます。

例えばこれ、まだドキュメントしかないです。

最初にドキュメントを書く効能

もちろん後で書く手間が省けるってのもあるけど、それより、最初にAPIのリファレンスを作る事で、成果物の最終形が明確になります。最終形が分かっていれば、ごりごり書いてそれに近づけるだけっすね。

APIが決まっていれば試験を書ける、試験が書ければリファクターができる、リファクターができれば雑なコードでも実装を進められる。とまあそんな感じ。

もしここで明確な最終形を記述できなかったとしたら、それは現時点ではまだ何を作れば良いかわかっていないという事になるでしょう。それだとコードも書けない。

モジュールでも同じように

製品内の部品を作る場合も、同じように最終形を最初に考えます。これはいちいちドキュメント作成したりはしない場面が多いけど、脳内には用意しておく。必要ならメモ書きくらいは作っても良い。

理由は前述のものと同じで、これから何を作るのかを確認するため。

書く内容

短い紹介文が欲しい。というかそれが一番大事だと思う。端的な紹介文はこれが「何であるか」だけでなく「何でないか」も表現し得るので、方向性を定めやすい。

あとはリファレンスと使用例。例は具体的な利用場面も想定できるとなお良し。

別に変更してもいい

実装コードを書いてから気付く(あるいは単純に思い出す)事もあるので、最初に作った仕様を厳守するというわけじゃないです。

あと十分に先が見えていないと最終形を定める事はできず、こういう形で作業を進めるのは無理ですね。そういうときは適当にそれっぽいものを作って、触って、捨てて作り直して、を繰り返す。新しい何かを作るときはそうなりがちだと思う。

ただ、思想については曲げずに進めたいなと。

まあ

言うほど毎回しっかりやってるわけでもないんだけど……。理想的な働き方みたいなもの。

EditorConfigで文字コード設定を共有して喧嘩しなくなる話。(Frontrend Advent Calendar 2014 – 14日目)

カテゴリー: 開発環境

edcon_color_transbg2_400x400

Frontrend Advent Calendar 2014の14日目の記事です。

ご存知ですか、EditorConfig。

便利すぎてほんのり涙出てくるくらいなんですが、いまいち周囲で聞かないので流行っていないのではないかと思います。是非とも流行らせてください。平和のために!!

フロントエンドにあんま関係ない代物だけど、改行コード絡みで恨みつらみを聞く機会が多い気がするのでご容赦くださいまし。

なにそれ

様々なエディターで利用できる、共通の書式設定ファイルです。”.editorconfig”というファイルをプロジェクトのルートに配置しておくだけで、エンコード等の書式をそのディレクトリー配下のファイル編集時に固定できます。

もちろん設定自体は各エディターでやってもらえば良いんだけど、やっぱりほら、好みとかもあるわけじゃないですか。プロジェクトごとに設定変えるとかやってられないし。

サイト

こちらです。

設定

こんな項目を設定できます。

  • 文字コード
  • 改行コード
  • インデント

これでwinとmacと両方からファイルをいじっても「めっちゃ文字化けしとる! ふざけんな!!」とか「なんか^Mが行末にくっついてる! しね!!」とか「ここだけインデントがタブじゃねーか! やろう、ぶっころしてやる。」とか、そういう喧嘩がなくなりますね。平和万歳!

bukkoro
じぶんどうしのあらそいは、みにくいものだ。

他にも余分な空白を除去するとかそういう設定があります。

対応エディター

それぞれのプラグインで対応する感じです。

主要なところでは以下で利用可能です。

  • Atom
  • Brackets
  • Emacs
  • IntelliJ
  • Sublime Text
  • Vim
  • MS Visual Studio

plugins
多数のエディターに(各プラグインが)対応。

んあーCodaやEclipseはないのかな。対応してよーっていう要望だけ見つかった。

設定

プラグインのインストールはエディターごとに違うので、それぞれの配布ページの記述をご覧ください。

で、ファイルは例えばこんな感じ。

root = true

[*]
end_of_line = lf
charset = utf-8
indent_style = tab
indent_size = 2

これは私個人が通常利用している設定です。

ファイルの文法はMS-DOSのiniファイルのやつ? 手元のvimだと”dosini”という名前のシンタックスハイライトが有効になりました。

root=true

.htaccessみたいに、.editorconfigもディレクトリーごとに入れ子(?)にして配置する事ができます。で、その上位ディレクトリーを見に行くのを止める設定が、これ。なければファイルシステムのルートまで遡るのかな。

プロジェクトディレクトリーのルートに配置する場合は書いておきましょう。

ファイル

[*]はファイル名のセクションで、全てのファイルを対象に設定しました。

ここで拡張子やファイル名を指定できます。例えば、前述の設定に加えHTMLだけはインデントにスペースを使いたいなぁーという場合は、追加してこんな感じにします。

root = true

[*]
end_of_line = lf
charset = utf-8
indent_style = tab
indent_size = 2

[*.html]
indent_style = space

他にもディレクトリーを指定したり、個別のファイル名でも指定可能です。

いくつかの個別ファイルで同じ設定を使用する場合は”{}”を利用し、”,”で区切って指定します。

[{package.json,bower.json,Gemfile}]
indent_size = 4

コメント

“#”で始めるとコメントになるみたいです。

リファレンス

そんなに量もないから書いちゃおう。

ファイル名指定

ファイル名の指定では以下のパターンが利用可能です。

記述 説明
* 任意の文字列、ただしパス区切り子”/”を除く
** 任意の文字列
? 任意の1文字
name “name”という名前のファイル
!name “name”という名前でないファイル
{s1,s2,s3} “s1”, “s2”, “s3″という名前のファイル

ファイル名指定はどのディレクトリーにあっても合致します。(つまり”*.js”ならどの階層のJSファイルでも有効。) もし.editorconfigと同じディレクトリーのファイルだけを指定する場合は[./*]のような指定になります。

複数指定とワイルドカードは一緒に使えない模様。あ、でもプラグインに依るかも。

設定

項目名は全て小文字。値に引用符は不要です。また値を空白にしておく事も可能です。

記述 値 説明
charset “latin1”, “utf-8”, “utf-8-bom”, “utf-16be” “utf-16le” 文字コード
end_of_line “lf”, “cr”, “crlf” 改行コード
indent_size 整数 インデントの各階層の幅
indent_style “tab”, “space” インデントの種類
insert_final_newline “true”, “false” 末尾に空行を追加
root “true” このファイルより上位の設定を検索しない。必ず先頭に記述する
tab_width 整数 タブ文字の幅。indent_sizeより優先される。省略時はindent_size
trim_trailing_whitespace “true”, “false” 行末の空白を除去

文字コードにShift JISはないみたい。まあ日本専用の文字コードだしな。

いつまでも幸せに開発を続けましたとさ

めでたし、めでたし。とっぴんぱらりのぷう。

参考

Dashを入れてみたらjQueryやらのドキュメントを見るのが想像以上に快適だったよ。

カテゴリー: 開発環境

自分も正直「え、別にブラウザーで見れば良いじゃん?」と思ってたんだけど、想像以上に快適だったので、皆さんにもお薦めしておきますよ。

なにそれ?

jQueryやBackbone.js、HTMLにCSS、あるいはRubyやJava、PHPといったもののドキュメントを閲覧するソフトウェアですよ。

事前にダウンロードしておくのでさくさくだし、検索が簡単だから欲しい情報がすぐ手に入るし、グローバルキーボードショートカットなんか設定しておくと一瞬で検索開始できるからお手軽です。

ウェブブラウザーのブックマークから開いて見れば良いじゃん、てな人も一度使ってみてくださいな。

インストールも簡単です。

検索してみたところ。

公式サイト

インストール

App Storeからインストールします。公式サイトから見ても、結局ここに誘導されます。

(さらに…)