右クリックでお手軽にテンプレートを挿入できるInsert Textが便利でした
ルーティンワークなどで決まったテンプレートを入力しないといけない場面は、けっこうよくあるのではないでしょうか。
テンプレートをどこからか探してきて、コピーするのは面倒・・・
そのようなときにChrome拡張のInsert Textが便利です。
使い方
右クリック > Insert Text > テンプレート名を選択することで、登録しておいたテンプレートを挿入することができます。
テンプレートの作り方
右クリック > Insert Text > Create/Edit Text よりテンプレートの作成と編集ができます。
ダウンロード
ダウンロードは以下のページよりできます。
https://chrome.google.com/webstore/detail/insert-text/abmgjcmmphkhndoahbfanhbgeekconmm
補足
バグがあるようで、2つ以上テンプレートを登録しないと動作しないようです。
codic_parserというGemをつくりました
codic_parserというGemをつくりました。
codic_parserはcodicをコマンドラインより使えるようにしたコマンドラインツールです。
codicとは
codicとは、英語の類義語検索をはじめとする名前づけの支援をしてくれる、デベロッパーのためのネーミング辞書です。
codic は、プログラマーやシステムエンジニアのためのネーミング辞書です。 データベースのカラム名やプログラムのクラス名･メソッド名といったネーミング作業を、もっと「いい感じ」に、そして「もっと楽しく」するための辞書です。
codic_parserの使い方
codic_parserにはgetとbrowseの2つのコマンドがあります。
get
getはcodicより検索結果を取得します。
何もオプションをつけない場合は、意味を取得します。
$ codic_parser get create 1. 動 ～を創造する，作成する★何もないところから創り出す・生み出すイメージ
例えば、データを登録する関数にcreateという名前をつけようと考えていたとします。
ほかによい名前はないだろうか？
こういうときに -w オプションで検索すると便利です。
$ codic_parser get -w create > build / 組み立てる、建築する、構築する make / 作る、メイク produce / 生産する、製造する、作り出す creation / 創造、創作品 creator / 創造者、創作者 creative / 独創的な、クリエイティブ
日本語にも対応しています。
$ codic_parser get 作る > make create
option
-l 単語のみ表示します。(-wオプションのときに有効です)
$ codic_parser get -l -w create > build make produce creation creator creative
-e エントリーリストを取得します。
$ codic_parser get -e create > crapware crawl crawler create creation creative creator credential credit credit account credit card credit card number credit limit criteria
-a 翻訳、ワードリストとエントリーリストを表示します。
$ codic_parser get -a create > 1. 動 ～を創造する，作成する★何もないところから創り出す・生み出すイメージ build / 組み立てる、建築する、構築する make / 作る、メイク produce / 生産する、製造する、作り出す creation / 創造、創作品 creator / 創造者、創作者 creative / 独創的な、クリエイティブ build / 組み立てる、建築する、構築する make / 作る、メイク produce / 生産する、製造する、作り出す creation / 創造、創作品 creator / 創造者、創作者 creative / 独創的な、クリエイティブ crapware crawl crawler create creation creative creator credential credit credit account credit card credit card number credit limit criteria
browse
browseはwebブラウザでcodicのサイトを開くコマンドです。
$ codic_parser browse > codicのトップページをブラウザで表示します。
$ codic_parser browse create > codicでcreateを検索した結果をブラウザで表示します。
インストール方法
gem install codic_parser
リポジトリ
リポジトリはGithubにあります。
追加したい機能などあればお気軽にプルリクしてください。
https://github.com/shoyan/codic_parser
インフルエンザでひどい目にあったので便利情報をシェアします
7年ぶりにインフルエンザにかかってしまいました。
ことの始まりは、木曜日のLINEの勉強会に参加した次の日でした。
金曜の朝、起きたときから寒気がして、どうも調子が悪い。
熱があるわけではなさそうだったので、いつものように会社に出社しました。
その日は金曜日で飲み会があり、1次会まで参加して帰りました。
そのときは、もう明らかに熱がある感じで、週末寝込むことになりそうな予感がしていました。
次の日の土曜日、熱を計ると、37.6℃でした。
近くの病院で、前日の昼から熱が出たと適当なことを言ってインフルエンザの検査を受けました。
なぜ、適当なことを言ったかというと、インフルエンザは24時間たたないと検査しても反応しません。
ですので、正直に申告すると検査してもらえない可能性があったからです。
検査してもらえないと、次の日は日曜日で病院は休みになってしまい、それは困る。
前日の夕方くらいから熱っぽかったので、インフルエンザだとしたら多分出るだろうと思って、適当なことを言って検査をしてもらいました。
検査結果は陰性でした。
抗生剤と解熱剤のカロナールを処方してもらいました。
薬を飲んで安静にしておけば治るだろうと思っていましたが、これが大きな間違いでした。
カロナールを飲んでも、熱が一時的にしか下がりません。
日曜日になっても38℃の高熱が続いたため、これはおかしいと思い、急患センターに行きました。
そこで再度検査をしてもらうと、見事に陽性。
インフルエンザの薬を処方してもらって帰りました。
そこから、息子にインフルエンザが感染し、嫁さんも体調を崩して寝込むといった苦難がありました。
私自身は発熱から5日ほどで、なんとか日常生活を営めるようになりました。
今回のささやかな経験から学んだことをシェアさせてもらいたいと思います。
まず、インフルエンザの検査は発熱してから最低24時間は待ってください。
検査は1回、3000円ほどかかります。
決して安くはないので、無闇に検査をするのはもったいないです。
ここは1発で決める覚悟で多少の熱は我慢して24時間待ってください。
次に、日曜日になると時間外診療になり、治療費がものすごく高額になります。
時間外診療費だけで、約5000円です。
時間外診療を受けるときは、この高額な医療費を払うだけの対価があるのだろうか、と一度考えてください。
時間外診療は、もうどうしようもなくヤバいときの最後の砦というのが私の認識です。
インフルエンザの薬も約4000円となかなか高額です。
これは、もうどうしようもない感じですが。
※ 通常は健康保険に入っていると思うので、実際に支払う金額は減額されます。
Railsをディスろうとしたけれど、素晴らしかった
先週からRailsを使うプロジェクトに配属になって、Railsを触るようになりました。
RailsもRubyも趣味で少しだけ書いたことがある程度で、仕事では使ったことがなく最初は不安でした。
実際のところ、思っていたよりもすんなりとRailsに馴染めている気がします。
Railsを触って感じたことを簡単にまとめておこうと思います。
Railsを触りだして感じているのは、開発のストレスが減ったことです。
それにはいくつかの要因があるのですが、その一つとして記述量の少なさがあります。
もともとRubyは短く簡素に書けるように設計されている言語です。
さらに必要に応じてGemを使うこともできます。
数行で必要な機能が実装できたりして、ここまで楽に開発ができたことは今までにないと思います。
ストレスが減ったもう1つの要因として、テストが容易に書けるということがあります。
RSpecは宣言的にテストコードを書くことができて、可読性がとても高いです。
また、柔軟なモックの機能やletメソッドが便利です。
衝撃的だったのは、メール送信のテストがいとも簡単に書けてしまうということ。
今まではメールのテストを楽に書く方法がわからなくて書く気になれなかったのですが、Railsはメールのテストも簡単に書くことができました。
とりあえず、今のところRailsをディスす要因がこれといって見当たりません。
気になったところとしては、覚えることが多いということ。
Rails自体もそうですし、Railsは様々なライブラリを利用することができるようになっています。
例えば、RSpecやFactoryGirl、Capybara、CoffeeScript、Slim。
これらはDSLでそれぞれが独自の仕様で実装されており、それぞれの使い方を覚えないといけません。
その学習コストがどうしてもかかってしまいます。
僕みたいなズボラな人間には、つらいものです。
あと、ちょっと気になっているのが、モデルが増える傾向にあるということです。
参考にいくつかのサービスのコードを覗いてみたのですが、どのサービスもモデルが膨張していて、モデルの全貌を把握するのが難しく感じました。
機能を抽象化してGemにする、モジュールとして実装する、ActiveSupportのConcernを利用するなど方法はありそうですが、これといった決定打がなくて、もやっとしています。
よい解決方法があれば教えてほしいものです。
ChromeのUser Agentの変更方法
ChromeのUser Agentの変更方法が変わってしまったようで、UIが変わってしまいました。
ググって見つかるChromeのUser Agentの変更方法は、古いバージョンのものが多いようです。
変更方法
- Google Developer Toolsを起動する
- 右上にある歯車アイコンをクリックして、設定画面を起動する
- Appearanceの Show 'Emulation' view in console drawer. にチェックをいれる
- Escを押す
- 新しいViewが起動するのでEmulationタブのDeviceを選択して、User Agent項目のEmulate ボタンを押す
以上でUser Agentが変更されます。
ちなみに、リロードしないとCSSは切り替わりませんのでご注意ください。
解除はUser Agent項目のResetボタンを押してください。
SvnからGitに移行するときに苦労してるところや知っておくと便利なTipsを紹介します
ここ最近、svnで管理されているソースをGitに移行するということを時間を見つけてはやっています。
svnでは以下の問題がありました。
まずは、git svn cloneでsvnからコードをcloneします。
それをあらかじめ作成してあるGitのレポジトリにpushします。
これだけで終われば簡単なのですが、プロダクションとsvnのコードを比較すると、差分が現れます。
きちんとした運用であれば差分はでないのですが、プロダクション環境へのデプロイが自動化されていないことや、svnをソースのバックアップとして運用していたという歴史的な経緯で差分が発生していました。
この差分をマージしないとまずいので、プロダクションのコードを正として差分をマージします。
このときに知っておくと作業がはかどるTipsを紹介します。
不要なファイルは削除する
比較する前にOSが自動で生成するファイル等があると邪魔になるので、先に消しておきます。
find . -name "._*" -exec rm {} \;
find . -name ".DS_STORE" -exec rm {} \;
colordiff
diffをcolorつきで表示してくれるので、見やすくなります。
インストール方法
brewでinstall。
shellにaliasを設定します。
alias diff="colordiff"
diffの便利なオプション
-r 対象ファイルを再帰的にたどる
-w スペースの違いを無視する
-q ファイル名のみ表示
-u 差分の前後の行を表示
---exclude 指定された対象を除外する
再帰的に差分のあるファイル名だけ知りたい場合
diff -rwq dir1 dir2
.svnディレクトリと.DS_STOREを無視したい場合
diff -rwq --exclude=".svn" --exclude=".DS_STORE" dir1 dir2
GUIで差分をみる
GUIで見たい場合は、DiffMerge(Mac)とWinMerge(Windows)があります。
DiffMerge(Mac)
http://sourcegear.com/diffmerge/
WinMerge(Windows)
http://www.geocities.co.jp/SiliconValley-SanJose/8165/winmerge.html
おわりに
いくつか便利なTipsを紹介しましたが、差分の比較をやりやすくすることしかできないので、 最後は気合いでやるしかないです。
根気は必要ですが、Gitのほうがコマンドが使いやすいですし、Githubでプルリクエストが使えるようになるので、メリットも大きいと思います。
