はじめに 以前、OSを跨ぐ作業により異なる改行コードが混在してスクリプトが実行出来なかったという事がありました。https://momozo.tech/2019/11/23/fac%e6%94%b9%e8%a1%8c%e3%82%b3%e3%83%bc%e3%83%89/ 異なるエディタを使っていたり、変態的なキーマッピング設定を行っているなど、理由は様々ですが意図しない文字コードがソースコードに入り込む現象は意外と多いです。(他には.editorconfigを作っていないとかも考えられますかね。) その結果プログラムが動かず、あげくデバックに何時間も要したなんて悲しい過去が、エンジニアならば心当たりがきっとあるはずです。そこで今回はVimで制御文字を調査してsedで簡単に除去する方法をまとめたいと思います。 Vimによる制御文字の調査 まずはVimで制御文字を調べる方法です。制御文字の一覧はWikipediaが簡潔でリファレンスに丁度いいです。 Vimにおける制御文字の入力方法は挿入モードで<Ctrl... 御覧になる | 御シェアする
カテゴリー: ツール
VimのaleプラグインでVueへのESLintを非同期で実行する
先頭にシバンを挿入するVimスクリプト
Typoraがただのマークダウンエディタではなくなっていた件
Typoraの悪口言うのやめな? 最近「Typoraは使いづらい」とか、「別のマークダウンエディタに乗り換えました」などといった悲しい台詞をよく耳にします。確かにTyporaはシンプルで直感的ではあるものの、ただそれだけという印象がありました。要するに単にマークダウンが書けるだけで替えが効く地味な子だと思われていたのです。 今日日マークダウンが使えるSaaSも珍しくないのでわざわざローカルにマークダウンエディタをインストールする必要が減ったというのもTyporaがいじめられっ子と化してしまった理由の一つでしょう。 ただしTyporaは周囲からの圧力を受けながらも陰ながら努力を重ねてとても垢抜けた姿に変貌していたのです。というわけで今回はTyporaが十分に使用に耐え得るツールに成長し、ただのマークダウンエディタではなくクラスのカーストトップになっていたということを証明したいと思います。 ファイルツリー・アウトライン こんな機能あったんですね。最近のアップデートというよりも単に自分が知らなかっただけなのですが「表示」から「ファイルツリー」にチェックを入れると左側にファイルツリーを表示出来ます。ここでフォルダを開くことでFinderの様に使用できますし当然編集も出来るので実質Finderの上位互換とも言えます。 また「アウトライン」を選択すると次のようにHeading毎にインデックスを張ってくれます。長いファイルを編集する時に便利です。 ※地味に重要な機能ですがファイルツリー内では全文検索も可能なのでファイルが増えても非常に管理がしやすいです。 ※また最近のアップデートでファイルツリー内のファイルに対してソートも掛けられるようになっています。 タブ機能 <Command... 御覧になる | 御シェアする
vim-airlineの真の設定方法
aleプラグインでRuboCopを非同期で実行する
coc.nvimでVimにRuby/Vue.jsのLSPを導入する
MySQLダンプでDBのバックアップを取る
ダンプとは ダンプとは広義では様々な意味を持ちますが、DB界隈ではバックアップを取ることをDBをダンプすると言います。ダンプして生成したファイルをダンプファイルと呼びダンプファイルをインポートすればDBをそのまま復元出来るためとても便利です。 仮にサービスが壊れてしまい復元出来ないことになっても全く新しいコードを書いて同じサービスを作り直すことは比較的容易です。しかしDBが壊れたら復元することは困難を極めます。というよりもほぼ不可能です。だからこそDBのバックアップは必ず取っておくべきであり、手軽に残せるようなサポートが備わっています。今回はMySQLでダンプファイルを作成する方法と、復元する方法をまとめました。 ダンプファイル作成 下記のコマンドを実行すると全テーブル・全レコードのダンプファイルを作成します。 $... 御覧になる | 御シェアする
GitHubを使って一次情報を読もうな
はじめに エンジニアとして成長したいのであれば一次情報を読むことから逃げてはなりません。今ではQiitaやtaratailといった技術スレッドで日本語翻訳され分かり易くまとまった情報に誰でもアクセスする事が出来るようになりました。何なら質問や意見を交わすことも可能です。何か課題があっても既に同じ課題に直面した先人達の足跡を参考にすることで効率的に解決が出来ます。 しかしこれらはあくまでも二次情報であることを理解しておくべきです。一見合理的に見える課題解決方法ですが二次情報のみで物事を考えているといつか必ず痛い目に遭いますし、かえって自分の成長を阻害する可能性もあります。技術者として高みを目指しているのであれば早い内から一次情報を読む癖を付けたほうが良いです。ということで今回は一次情報の読み方についてまとめてみました。 公式ドキュメントを読む Qiitaなどを読んでも理解出来ない、課題を解決出来ない時は繰り返し同じ様な二次情報を探すのではなく公式ドキュメントを見てみると上手くいくことがあります。公式ドキュメントとは公式サイトやGitHubのREADMEなどのことです。この辺は大抵が長文であったり英文であったりと難かしそうな印象があり読むのが憚られるのですが、作り手の読んで欲しい情報がそこにあるので出来る限り目を通した方が良いです。 とは言え全文を読む必要はありません。コードの部分や単語から辺りを付けて重要な部分だけを読んでみるだけでも十分に効果があります。自分自身三行以上あるだけでうんざりする程ドキュメントを読む行為が苦手なのですが、ご飯を食べながらなど気を紛らわしながら読むよう心掛けています。 GitHubのソースコードを読む 二次情報、公式ドキュメントを読んでもライブラリの挙動を理解出ない、あるいは手元で検証しても分からない場合に次に読むべきものはソースコードです。いざこれを行動に移すのは些か勇気がいります。それはソースコードなんて壮大で理解するのは難しいとか時間が掛かりそうという先入観があるからです。そもそも透過的に利用出来るからこそライブラリとは便利なのであってソースコードを理解しようという発想は出づらい節があります。それでもソースコードには答えが必ず乗っていますし、何なら開発者にissueを投げつけてやりましょう。(むしろ喜ばれます) これはある程度言語仕様に慣れてからやってみるのが一番良いと思いますが、普段コードを書いている言語であれば意外と読めてしまうものです。食わず嫌いで読んでいないのであれば今後は読んでみることをおすすめします。 そしてご存じないかもしれませんが最近のGitHubはコードリーディングをするのに便利なUIが備わっているのです。例えば左上の検索窓ではリポジトリ全体に対して全文検索を行えます。 他にもメソッドをクリックすると定義元にジャンプする事が出来るので、狙いのメソッドの中身をすぐに確認することが可能です。 最近でもDeviseTokenAuthというトークン認証を提供してくれるRuby... 御覧になる | 御シェアする