Vimで文字化けファイルを作りテストする

はじめに 今回はVimであえて文字エンコードの違うファイルを作り、開いたら文字化けさせることが目的です。 Vimに限らず最近のエディタでは、一度エンコードを指定してからファイルを編集すると、文字化けさせたいテキストをコピペしてもよしなに変換してしまいます。例えばShift-JISのファイルのテキストをUTF-8のファイルにコピペしても、変換してくれるので文字化けが怒らないなど。 だから今回はVimを使って文字化けファイルを作成する方法をまとめてみました 方法 結論から言うとエンコードを指定してファイルを作成するということです。 UTF-8を真(文字化けしない)として、Shift-JISを偽(文字化けする)とするならば、まずUTF-8でファイルを作成します。 $... 御覧になる | 御シェアする

Vimプラグインを自作して公開する

はじめに 今更ですが、Vimプラグインを作り公開する方法をまとめたいと思います。 以前、こちらで再帰関数で括弧構文を作るVimスクリプトやRubyスクリプトを作りました。 今回はこのスクリプトをVimプラグインにして公開することにします。 準備 まずはソースの管理と公開のためにGitHubにリポジトリを作ります。短く、分かりやすく、被らない名前が推奨されています。https://github.com/momozo2251/vim-rebrackets ディレクトリ構成 リポジトリを見てもらう方が速いかもしれませんが、一応下記の通りになります。 . ├──... 御覧になる | 御シェアする

ベーシック認証を保存するChrome拡張機能

はじめに 何らかの理由からベーシック認証を求められるサイトを頻繁に利用しなければいけないという状況は多いと思います。エンジニアなら例えばGoogleにクロールされたくないステージング環境などがよくあるケースでしょうか。 そういった時皆様はどうされていますでしょうか?諦めて泣く泣く入力していますでしょうか、それともブックマークレットを作成するでしょうか? 今回は「Basic... 御覧になる | 御シェアする

ddc.vimとvim-lspを使って自動補完機能を設定する

はじめに Vimには標準で自動補完機能が備わっていません。したがって手動でLSPを導入したり、補完候補が表示されるように設定をする必要があります。 今回はvim-lspという非同期LSPを行うVimプラグインと、LSPの設定を簡易にしてくれるvim-lsp-settingsというプラグイン、そして自動補完の設定を行うddc.vimというプラグインを導入していきます。 vim-lspに関しては自動補完以外にも定義ジャンプなど便利な機能もあるようですが、これについては別の機会にまとめようと思います。 Denoインストール ddc.vimがDenoで開発されているらしく、まずはDenoのインストールから行います。 $... 御覧になる | 御シェアする

iTerm2とVim上でSolarizedカラースキーマを利用する

はじめに 最近Macを初期化してしまったので、カラースキーマの設定もし直すことになってしまいました。 とりあえずSolarizedテーマを使っておけば間違いはないと思うので、今回はiTerm2とVimを使用するという前提の下でカラースキーマをSolarizedに設定する方法をまとめてみました。 Vimプラグインをインストール .vimrcに下記を追記して下さい。 Plug... 御覧になる | 御シェアする

Unity備忘録

はじめに これはUnity初心者のUnity初心者によるUnity初心者のために書いた、備忘録です。 ウィンドウサイズをスマホ幅にする ゲームタブの左上の所から変更可能です。 但し最初にビルドプラットフォームをPCに選択している場合は、比率を選択しても縦長になりません。その場合は「File」→「Build... 御覧になる | 御シェアする

WindowsのSourceTreeでGitHubとSSH(公開鍵)接続する

はじめに 今回はWindowsにてSourceTreeを使ってGitHubアカウントに公開鍵暗号方式でSSH接続する方法の説明です。 Linux環境では何度も設定していましたが、最近になって初めてWindowsで設定を行いました。その際に意外と沼にはまってしまう点があったので、次の機会のためにまとめておこうと思います。 鍵の作成 まず認証に使用する秘密鍵と公開鍵を作成します。 SourceTreeを起動して「ツール」→「SSHキーの作成/インポート」を押下します。 PuTTY... 御覧になる | 御シェアする

NoSQLと行・列指向型DBの技術選定

はじめに ログ分析システムを構築するにあたり、ログを格納するDBは何にすればいいのかについて考える機会がありました。 この時、慣れているからという理由だけで行指向型DB(MySQL)を採用するのは非常に危険な考え方です。もし深く考えずに安直な選択をした場合、DBのレコード数が増えて来た頃に1クエリ毎に1分近くも処理時間を待たなければならないという未来を迎えることでしょう。そしてそうなった時には後戻りが出来なくなってしまうのです。 今回はそうならないためにもNoSQLとSQL(行・列指向型DB)の3つを比較しながら、技術選定の観点をかんたんにまとめてみました。 行指向型DB 行指向型DBとはMySQLやPostgreSQLなどの最も一般的なDBです。行単位でレコードを読み書きします。 メリット 少ないレコードへの読み込み・書き込みが速い検索しやすい デメリット レコードが多いほど読み込み(ディスクシーク)が遅くなる HDDとアクセス速度 忘れがちですが、HDDに保存されたデータへのアクセスは結構遅いです。レコードを読み取るということは、すなわち円盤の上のアームが回転して保存された磁気データを探しているということです。 つまりレコードが増えるほど回転量が増えて処理時間も長くなります。 列指向型DB 列単位でレコードを読み取る。列方向はデータ形式が同じで、同値が多いので圧縮保存される。BigQueryなどが代表的。 メリット 大量レコードでも読み込みが速い検索しやすい ※列方向に圧縮して保存するので、HDDのデータシークの観点からレコードが増えても読み込み速度が速い ※クエリは行指向と変わらないので検索しやすい デメリット 書き込みが遅い ※一行であろうと更新する際には、圧縮されたDBを展開してから更新して再度圧縮を行うため時間が掛かる NoSQL NoSQLはキーバリュー型やドキュメント型など種類が多くあります。※ここではAWSのDynamoDBなどで代表的なキーバリュー型を想定しています。 メリット 読み込み・書き込みが速い拡張性が高い ※インデックスキーを登録出来るので該当キーでの読み込みが速いです ※キーバリュー形式で様々なデータを格納出来る インデックス インデックスとは本で言う索引のようなもです。インデックスのロジックはDB毎に様々ですが、ここでは二分探索木をイメージしています。 例えば1,000行のレコードがあるとして、1000番目のレコードを探索する際に頭から順番に検索するのではなく、1~500行目はここ、501行目~1000行目まではここという風にグルーピングされていればより速く検索することが出来ます。 細かい説明は割愛します。 デメリット 検索しにくい設計が難しい ※RDBMSの様な複雑な検索は出来ません。また登録出来るインデックスキーの数に限りがある。 ※どのキーで検索・ソートするのかなど、あらかじめ決めるべき項目が多いため設計が難しい まとめ 各DBの説明は以上です。どのDBを採用するかは、レコード数や検索性、用途や予算などを整理した上で、各データベースの長所と短所を比較しながら選定することになるかと思います。 以上です。 ... 御覧になる | 御シェアする