スキップしてメイン コンテンツに移動

投稿

JavascriptのObject Literalを使った条件分岐

条件分岐を簡潔に書きたい! 条件分岐をする場合、通常はif~else文やswitch~case文を使うことが一般的ですが、Object Literalを活用すると簡潔にコードを書くことできる場合があります。Object Literalを利用するのは、ちょうどPHPのarray、JavaのMap、C#のDictionaryなどの連想配列を利用するイメージが近いと思います。 switch~case文とObject Literalを使った場合のコード例をいくつか示していきます。 switch~case文とローカル変数を使った場合 function GetStockCode_LocalVariable ( makerName ) { let code = "" ; switch ( makerName ) { case "Asus" : code = "2557" ; break ; case "MSI" : code = "2377" ; break ; default : throw new Error ( "unsupported maker: " + makerName ) ; } console . log ( code ) ; } 一般的な書き方ですが、下記の短所があります。 mutableなローカル変数のcodeを定義しなければならない。 switch~caseのキーワードやbreakキーワードが何度も出現し、重要な部分がわかりにくい switch~case文と即時実行関数式(Immediately Invoked Function Expression)を使った場合 function GetStockCode_IIFE ( makerName ) { const code = ( ( ) => { switch ( m

Unityのバイナリがフォルダに出力されない問題

Visual Studio上でNUnitのプロジェクトから、Unity本体のプロジェクトを参照させて、Unity本体のプロジェクトのコードの一部をテストさせようとしたところ、下記のエラーメッセージが出力され、Debugディレクトリにアセンブリが生成されず、NUnitを実行することができませんでした。 Metadata file 'ProjectFolder\Temp\bin\Debug\Assembly-CSharp.dll' could not be found. Google先生で検索したところStack Overflowでドンピシャの質問を見つけました。 https://stackoverflow.com/questions/58614995/visual-studio-doesnt-put-binaries-of-unity-project-to-output-folder 記事の通り Disable the full build of projects を False に設定すると、無事bin/Debugフォルダにアセンブリが出力されるようになりました。

Bloggerでアップロードされた画像の保存先

2021年5月現在、Bloggerで画像を投稿する場合は、下記の方法があります。 コンピュータからアップロード Google Photosでアップロードされている画像から選択 URLから参照 Bloggerですでにアップロードされている画像(またはアルバムから参照) 2.のGoogle Photoでアップロードされている画像から選択の場合は、Google Photoに自らアップロードした画像なので、元画像はGoogle Photosのアルバムから確認することができます。 問題は、 4.のBloggerですでにアップロードされている画像の保存先 です。少し調べたところ、下記のURLから確認できることがわかりました。 https://get.google.com/albumarchive/ 容量のカウントは、他のGoogleのサービス (Google Drive, Gmail, Google Photosなどと)と合算されるようです。

MSIのDragon Centerを使っているとXboxアプリがスタートアップ時にタスクバーにピン止めされる問題の解決法

MSIのゲーミングノートPCでXboxのアプリをタスクバーのピン止めを外しても、再起動するとまたタスクバーに再度ピン止めされるという問題が発生しました。 下記のMicrosoftのCommunityサイトでも同様の問題が数多く報告されており、解決法が記載されている投稿を見つけました。 https://answers.microsoft.com/en-us/windows/forum/windows_10-desktop/apps-keep-pinning-themselves-on-startup-to-the/44b0bb7b-575d-4534-aa1c-80258f710514?page=2 筆者の環境では、下記の手順でDragon Centerの設定を修正すると解決しました。 C:\Users{ユーザー名}\AppData\Local\Microsoft\Windows\Shell\LayoutModification.xml 内でtaskbar:TaskbarPinListのセクションを探す(下記は例)。 < taskbar: TaskbarPinList > < taskbar: UWA AppUserModelID = " 9426MICRO-STARINTERNATION.DragonCenter_xxxxxxxxxxxxx!App " /> < taskbar: UWA AppUserModelID = " 9426MICRO-STARINTERNATION.CreatorCenter_xxxxxxxxxxxxx!App " /> < taskbar: UWA AppUserModelID = " Microsoft.GamingApp_xxxxxxxxxxxxx!Microsoft.Xbox.App " /> </ taskbar: TaskbarPinList > このセクションを丸ごと削除 (またはxml形式のコメントアウト)を実施して、PCを再起動すればOKです。 念のため編集前のxmlファイルを保存しておいた方が

ElasticsearchのIndexのメンテナンスツールであるCuratorの使い方メモ

詳細は オフィシャルのドキュメント を参照してもらうとして、使い方は下記になります。 # --configでどのElasticsearchを参照するかを指定 # 最後の引数のactions.ymlで何日前のインデックスを消すかなどを設定 curator --config /etc/curator/curator.yml /etc/curator/actions.yml 下記はcurator.ymlの例です。 client: hosts: - http://elasticsearch-host.com/ port: 9200 url_prefix: use_ssl: False certificate: client_cert: client_key: ssl_no_validate: False http_auth: user:password timeout: 30 master_only: False logging: loglevel: INFO logfile: logformat: default blacklist: ['elasticsearch'] 下記はactions.ymlの例です。 actions: 1: action: delete_indices description: >- logstash-で始まり、30日より古いインデックスを削除 options: ignore_empty_list: True disable_action: True filters: - filtertype: pattern kind: prefix value: logstash- - filtertype: age source: name direction: older timestring: '%Y.%m.%d' unit: days unit_count: 30

Visual Studio 2019で静的コード解析 (Static Code Analysis)

最近はVisual Studioも高機能になってきて簡単なコード解析機能はデフォルトで利用できるようになってきました。今回の記事で利用したVisual StudioはVersion 16.9.4です。 サーバー上に継続的にデータを蓄積しているわけではないので、指標の変化は追えませんが、プロジェクト内で改善の必要なファイルはある程度目星をつけられるのではないかと思います。 使い方は簡単で、最上部のメニューの「Analyze > Calculate Code Metrics > For Solution (またはFor {Project名})」を選択すると、コード解析が実行され、Code Metrics Rsultsウィンドウにproject > namespace > class > method の階層で解析結果が表示されます。 解析されるMetricsは下記になります。 Maintenability Index (メンテナンス指標) Cyclomatic Complexity (循環的複雑度) Depth of ingheritance (継承の深さ) Class Coupling (クラスの結合度) Lines of Souce code (コードの行数) Lines of Executable coce (実際に実行されるコードの行数。括弧、コメント、空行を除いた行数)

Dockerでコンテナ内のディレクトリを実ホストのディレクトリにマウントする設定

基本的にDockerのコンテナは使い捨てなので、永続化させたいデータはコンテナ外に置くことが多いと思います。Dockerでは、コンテナ内のディレクトリを実ホストのディレクトリにマウントする設定を入れることで、これを実現できます。 Dockerのコンテナを再起動しても、元のデータが残ります。特にDocker内でデータベースを使っている場合には、重要な設定になると思います。 またDockerのコンテナ内のアプリケーションの設定ファイルなどを、コンテナ外部のディレクトリに置く場合にも利用されます。 設定の書式は「コンテナの外のホストのディレクトリパス:コンテナ内のディレクトリパス」になります。 下記に設定例を示します。Redashで利用しているPostgressのデータベースのデータ本体をコンテナ外マウントした場合を想定しています。 volumes: # コンテナ外のディレクトリ:コンテナ内のディレクトリ - /usr/docker/redash/postgres/opt/postgres-data:/var/lib/postgresql/data