Information Technology Tips

受信側サンプルコード // 基本 var receiveIpAddress = "127.0.0.1" ; var local = new IPEndPoint ( IPAddress . Parse ( receiveIpAddress ) , Port ) ; var remote = new IPEndPoint ( IPAddress . Any , 8006 ) as EndPoint ; socket . Bind ( local ) ; var buffer = new byte [ 3 ] ; while ( true ) { Console . WriteLine ( "Start Receiving" ) ; // var length = socket.ReceiveFrom(buffer, ref remote); var length = socket . Receive ( buffer ) ; var requiredBuffer = new byte [ length ] ; Buffer . BlockCopy ( buffer , 0 , requiredBuffer , 0 , length ) ; var data = Encoding . UTF8 . GetString ( requiredBuffer ) ; Console . WriteLine ( "data received: " + data ) ; } 受信側コードの注意点 bufferの配列サイズがdatagramサイズより小さいと、下記のようなエラーが出る System.Net.Sockets.SocketException (10040): A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datag

問題 IntelliJ IDEAでWSL2上のJDKを追加しようとすると、Microsoft Defenderのスキャンが走ってファイルのIndexingプロセスでほぼフリーズしてしまうという問題が発生しました。 ネットで検索 下記のページで同様の問題に遭遇した人がissueを上げていました。 https://youtrack.jetbrains.com/issue/IDEA-308995 こちらに暫定的な解決方法が記載されていたので試したところ、筆者の場合は解決しました。 https://github.com/microsoft/WSL/issues/8995#issuecomment-1377515755 解決手順 Windows Defenderのスキャン除外リストにfsnotifier-wsl, idea64.exeの2つのプロセスを追加するという方法です。 手順は下記になります。 Windows Security設定を開く(Windowsのタスクバーの検索まどから検索すると早いです) Virus & threat protectionを開く Virus & threat protection settingsのManage settingsを開く ExclusionsのAdd or remove exlclusionsを開く Add an exclusionでProcessを選択し、fsnotifier-wsl, idea64.exeの2つのプロセスを追加

はじめに Firebase Hostingでデプロイ先のプロジェクト(開発、ステージング、本番)ごとにinitializeAppに渡すFirebaseの環境情報を簡単に切り替える方法はないか調査して、FirebaseのHostingのinit.jsを読み込む方法を試してみました。 FirebaseのHostingのmodule形式でないサンプルで、下記のように、init.jsが読み込まれている行が見つかります。 < script defer src = " /__/firebase/init.js?useEmulator=true " > </ script > 中身はこんな感じです。 if ( typeof firebase === 'undefined' ) throw new Error ( 'hosting/init-error: Firebase SDK not detected. You must include it before /__/firebase/init.js' ) ; firebase . initializeApp ( { "apiKey" : "{API Key}" , "appId" : "{App ID}" , "authDomain" : "{domain}" , "databaseURL" : "" , "projectId" : "{projectId}" , "storageBucket" : "{Storage Bucket Domain}" } ) ; initializeApp に渡しているJavascript Object部分を抜き出せば、コードがデプロイされているFirebaseのHosting情報を実行時に取得することができます。 コード init.jsの中身を読み込み、正規表現で欲しい部分を抜き出し、JSON.p

ダイソーでスマホの5.5インチ ガラスフィルムが販売されているというのを知り、近所のダイソーを何店か回って、ようやくお目当ての商品を見つけて購入したので、簡単にレビューします。 あくまで私個人の環境での使用感です。 スマホ用液晶保護強化ガラス 5.5インチ MSGS-29 https://jp.daisonet.com/collections/electricity0215/products/4968583144626 良い点 安い。 自分のスマホの画面をぴったり覆える。 ダメな点 透明度がいまいち：機種専用のガラスフィルムにくらべると、透明度が低いような気がしました。 画面部分しか覆えないので見た目がいまいち。 割れちゃいました。。。 結局、画面の透明度が気になったので、機種専用のガラスフィルムの方に貼りなおして、はがしたMSGS-29に保護シートを貼り直し、保管しておこうと（余計なことをして）いじっていたら、あっさりフィルムが割れてしまいました。😭 （ 普通にスマホに貼った状態で割れたわけではなく、商品の欠陥とかではないので誤解ないように！ ）。 当たり前ですが、ガラスフィルムは ・面に対して垂直でない力に相当弱い ・特定の箇所に力が集中するといきなり破断する というのを実感しました。 MSGS-29についてはこんな構造になっていました。粘着シートのおかげでフィルムが割れてもガラスが飛散しないようになっているようです。 結論 機種専用のフィルムが手に入るならそちらの方がよい。品質はある程度価格に比例しそう。(iPhone用のガラスフィルムはダイソーでもたくさん販売されていますが、そちらの品質はわかりません)。 ガラスフィルムの扱いは丁寧に。

Linuxでbase64エンコードをするにはbase64コマンドを使えばOKです。 base64コマンド ファイルであれば下記のようにファイル名を指定すると、ファイルの中身をbase64エンコードした結果が標準出力に出力されます。 base64 {エンコード対象のファイル} ファイルに保存したい場合は、リダイレクトを使います。 base64 {エンコード対象のファイル} > {エンコードされたファイル} ファイルではなく文字列をbase64エンコードする場合 echoコマンドとパイプを使えば容易に実現できます。注意点として、base64コマンドでオプションを何も与えないと76文字ごとに改行が勝手に入るので、改行を除きたい場合は -w 0 をオプションに指定します。 echo "エンコードしたい文字列" | base64 -w 0

大昔にGoogle App Engineの開発で作成したGoogle Datastoreのインデックスを見つけたので掃除方法を検索したところ、公式の https://cloud.google.com/sdk/gcloud/reference/datastore/indexes/cleanup を見つけました。 筆者の場合は、インデックスを全削除したかったので、下記のような空のindex.yamlを作成し、 indexes: 下記のコマンドを実行しました。 gcloud datastore indexes cleanup index.yaml

筆者の開発しているプロジェクトでは、Spring BootのテンプレートエンジンにThymeleafを使っており、全画面共通のレイアウトテンプレートを定義するために thymeleaf-layout-dialect を利用していました。 このプロジェクトでGraalVMを使ってネイティブコードを生成しようと悪戦苦闘していたのですが、2023年2月時点では thymeleaf-layout-dialect がネイティブコンパイルに対応していないため無理という結論になりました。 native-imageのコマンド実行時にエラーになるクラスを --initialize-at-build-time 、 --initialize-at-run-time で手作業で追加していたのですが、追加する数が多すぎて無理でした。。。 それほどページ数は多くなかったので、泣く泣く thymeleaf-layout-dialect の利用をあきらめ、重複は増えてしまいますが、Thymeleaf標準機能だけで全テンプレートを書き換えました。 GitHub上のissueを見ていたところ、ライブラリの作成者も問題に気づいているようなので、今後対応されるかもしれません。 https://github.com/ultraq/thymeleaf-layout-dialect/issues/232

Google App EngineのJava 17のStandard EnvironmentでSpring Bootアプリケーションを運用していたところ、サーバーから送信されるhtmlにgzip圧縮が効いていないことに気が付きました。 gzip圧縮が効いているかどうかは、下記のようなサイトに調べたいページのURLを入力すれば確認できます。 https://pagespeed.web.dev/ https://www.giftofspeed.com/gzip-test/ Spring Bootでgzip圧縮を有効にするにはapplication.propertiesに下記のように追記すればOKでした。ちなみにGoogle App Engine側の設定は特にいじっていません。 # 圧縮を有効にするかどうか server.compression.enabled = true # 圧縮対象のmite type server.compression.mime-types = text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json # 圧縮を効かせる最小レスポンスサイズ server.compression.min-response-size = 1024 Google App EngineのDash Boardで確認したところ、見事にネットワークの使用帯域が1/5になりました！

Spring BootでテンプレートエンジンとしてThymeleafを使っていると、デフォルトではキャッシュが効いて、開発時にテンプレートを修正するたびにアプリケーションを再起動する必要があます。 Thymeleafのキャッシュをオフにするにはapplication.propertiesに下記の設定を加えればOKです。 spring.thymeleaf.cache: false これによりページリロードの度に毎回テンプレートの解析が行われ、編集内容がすぐに反映されるようになります。 本番デプロイ時は設定を無効にすることを忘れないようにしてください。

gcloudコマンドの実行が遅い！ 筆者はwsl2を利用してWindows上のUbuntuで開発を行っています。 開発中にgcloud コマンドの実行が非常に遅くなってしまうという問題に度々遭遇し、困っていました。例えば gcloud config set project {project_id} といった単純なコマンドでも実行に数分かかってしまうような状況でした。 調査したところ、下記のStack Over Flowの投稿を見つけ、解決しました。 https://stackoverflow.com/questions/61953082/why-is-my-gcloud-command-suddenly-very-slow-inside-wsl2 解決法 Ubuntu上で実行されていたのは、Windows上にインストールされたgcloudコマンドで、そのことが遅くなっている原因でした。 Ubuntu上で /etc/wsl.conf に下記のように追記 (ファイルが存在しない場合は作成)してWindows側のパス設定を読み込まなくすることで、Windows上のgcloudをUbuntu側から参照できないようにする。 [interop] appendWindowsPath = false wsl.exe --terminate {Linuxディストリビューション名、大抵はubuntu} でwslを一度落とし、そのあと再度wslを起動。 起動したUbuntu上でLinuxネイティブのgcloudをインストール。 筆者の場合はこれで普通のLinux環境とそん色ないぐらいコマンドの実行が速くなりました（今までのは何だったのか orz…）。