はてなブックマーク

Shift_JIS の CSV で連携する外部サービスがあり、DB では UTF-8 でテキストを持っていたため文字コードを変換する必要が生じた。 ところが UTF-8 に存在する多くの文字は Shift_JIS に対応がないため変換することができない1。 そこで、事前に NFKC 形式で Unicode 正規化することで変換可能な文字を増やすことを試みた。 まずは Unicode 正規化の前提として、Unicode の正準等価と互換等価について説明する。 以降の U+16進数 という表記は Unicode のコードポイント (文字に ID のようなものが割り当てられている) を示す。 また、コードポイントに対応する文字の詳細は https://codepoints.net/ といったサイトで確認することができる。 正準等価 例として、ひらがなの「が」について考える。Unicode では「

これが こうなった インフラ構成 リバースプロキシをなくした リバースプロキシを採用する場合、主な役割としては以下が想定される。 SSL/TLS 終端 リクエストのキューイング 静的ファイルの配信 このうち 1 と 2 については ALB で代替することができる。現に移行前の時点でこれらは CLB でも行われていた。また 3 については CDN のほうがよりうまく扱えるはずだ。 そこで、リバースプロキシ (今回は nginx) でやっていた処理を Rails に移植してリバースプロキシをなくすことにした。Rails でやることは増えるが、構成をシンプルにできるメリットのほうが大きいと判断した。また、複数のコンテナを協調させる難易度が高いということも理由として挙げられる。 移植した処理内容については後述する。 静的ファイルはコンテナに含める 静的ファイルを S3 等のストレージから配信する場

2.4 GHz 帯はもう諦めている。 前提 駅前のガラス張りのオフィスビル やったこと 周波数帯の調整 W53 (5250 - 5350 MHz), W56 (5470 - 5725 MHz) は気象レーダーなどにも使用されており、それらを検出した場合、レーダー波を優先するために一時的な停波やチャネルの変更を行う必要がある1。恐らく事前の調査 (サイトサーベイ) は行われておらず、レーダー波の影響がないことを保証できないため、W52 (5150 - 5250 MHz) のみを使用することにした。 基本的には W53, W56 の使用は避けたほうが無難である。特に W56 は屋外利用が可能であり、公衆 Wi-Fi にも利用されているため遠方飛来も多い。 帯域幅の調整 調整前は 80 MHz に設定されていたのだが、今回のように外的要因の多い環境でボンディングを安定して運用することは非常に難し

前提 ActiveRecordをutf8mb4で動かす - Qiita 気合でコンテナ上の MySQL の設定を変更する circle.yml database: override: - mysql -u root -e 'set global innodb_file_format = Barracuda' - mysql -u root -e 'set global innodb_file_per_table = 1' - mysql -u root -e 'set global innodb_large_prefix = 1' - bundle exec rake db:create db:schema:load --trace