DEV Community: tackme

Integrate Current Changes into a Specific Commit without Opening the Editor

tackme — Mon, 22 Jan 2024 03:12:52 +0000

TL;DR

Set up the following alias in your Git configuration.

[alias]
    cmfr = "!f() { git commit --fixup \"$1\"; GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash \"$1\"^; }; f"

Now you can execute git cmfr HASH to apply the changes.

How it works

When integrating current changes into the most recent commit, we typically use the commit --amend command. Adding --no-edit lets us do this without opening the editor. But what if we need to alter not the latest commit, but an earlier one?

The usual steps for this are somewhat cumbersome:

Temporarily commit the current changes.
Perform an interactive rebase.
Shift the temp commit right below the target commit.
Change the temp commit's command to 'fixup'.
Save and exit the editor.

This process involves more steps than necessary. Using --fixup and --autosquash can simplify it. The commands below bring you directly to step 4 of the aforementioned process:

> git commit --fixup HASH
> git rebase -i --autosquash HASH^

Then just close the editor and you are done. Since we've simplified the process considerably, we'd also like to bypass the editor-closing step.

In Git, the rebase editor can be changed by setting the GIT_SEQUENCE_EDITOR environment variable. This variable can be set to vi, emacs, vscode, sed, etc. Interestingly, using the bash built-in command : (a no-operation command) for this variable simulates an immediate exit without performing any action. Using this feature, the following commands can execute all steps in just two commands:

> git commit --fixup HASH
> GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash HASH^

The final step is to save this sequence as an alias:

[alias]
    cmfr = "!f() { git commit --fixup \"$1\"; GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash \"$1\"^; }; f"

Now, whenever you need to tweak a past commit, simply run git cmfr HASH.

Happy coding! 🚀

Reference

Git interactive rebase without opening the editor - Stack Overflow

コントローラでDictionary型のGETパラメータを受け取る

tackme — Fri, 14 Jan 2022 02:29:49 +0000

コントローラのアクションでDictionary型のGETパラメータを受け取るには、以下のようなフォーマットでパラメータを記述します。

https://example.com/api/Sample/SampleData?param[key1]=val1&param[key2]=val2&...

上記のリクエストを投げると、アクションで定義したparam引数で以下のように値を受け取ることができます。

[Route("api/[controller]")]
public class SampleController : Controller
{
    [HttpGet("[action]")]
    public Data SampleData(Dictionary<string, string> param)
    {
        var val1 = param["key1"];
        var val2 = param["key2"];
        return ...;
    }
}

注意点

先ほどの例でparamパラメータ無しのリクエストを投げるとアクションが見つからずエラーが発生します。

https://example.com/api/Sample/SampleData
=> 500 Error

空のディクショナリを渡すには、以下のような値無しのparamパラメータ付きのリクエストを投げる必要があります。

https://example.com/api/Sample/SampleData?param

[HttpGet("[action]")]
public InitData Init(Dictionary<string, string> param)
{
    var _ = param.Count; // => 0
    return ...;
}

参考

c# - Is it possible to get Dictionary from query string? - Stack Overflow

SonarQubeでJavaのメモリ不足エラーが発生した際の対処法

tackme — Wed, 22 Sep 2021 06:07:43 +0000

SonarQubeで大きなプロジェクトの解析を行うと、以下のようなエラーが発生し処理が停止してしまうことがあります。

java.lang.OutOfMemoryError: Java heap space

dockerでコンテナ起動時に環境変数 SONAR_CE_JAVAOPTS="-Xmx1G -Xms1G" を指定してヒープサイズを大きくすると解消できます。

docker run -d --name sonarqube --env SONAR_CE_JAVAOPTS="-Xmx1G -Xms1G" -p 9000:9000 sonarqube:lts

参考

How to set Sonarqube Compute Engine Java memory parameters with Environment Variables - Get help / SonarQube - SonarSource Community

PowerShellでホームディレクトリを変更する

tackme — Fri, 17 Sep 2021 17:05:11 +0000

PowerShellの初期読み込みファイル（ii $PROFILEで開けます）に以下を追記するとホームディレクトリを変更できます。

# $HOMEの変更
Remove-Variable -Force HOME
Set-Variable HOME $env:HOME

# '~'の解決先を変更
$fs = $ExecutionContext.SessionState.Provider.Get("FileSystem")
$fs[0].Home = $env:HOME

これで$HOMEの値やcd ~の移動先が設定したディレクトリに変更されます。

カスタマイズなしでSitecoreの管理画面の色を変更する

tackme — Thu, 01 Apr 2021 07:48:08 +0000

「ローカル環境だと思ってアイテムを編集したら実は本番環境だった😱」みたいな経験、ありませんか？私はあります。何度かやらかしました。
本番環境にアクセスしていることが視覚的に分かれば、こんな事故は起きないはずです。
ということで、この記事では環境ごとにSitecoreの管理画面の色を変更する方法を紹介します。Sitecoreのカスタマイズは不要です。

こんな感じの画面になります。一目瞭然ですね。

変更方法

お察しの方もいらっしゃるかもしれませんが、Chromeの拡張機能であるStylusを使用します。Stylusを使用すると、特定のURLで任意のCSSを適用することができます。
まずはChromeにこの拡張機能をインストールしましょう。Firefox, Operaでも使用することができます。

Stylus - Chrome ウェブストア

インストールしたらStylusの管理画面を開き、左側のメニューから「新スタイルを作成」をクリックします。

スタイルの編集画面が表示されるので、まずは適当な名前をつけて保存してください。

次に左側のメニューの「インポート」をクリックします。テキストエリアが表示されるので、以下のCSSをコピペして「スタイルを上書き」を選択してください。

@-moz-document url-prefix("http://foo.prod.sc"), domain("bar.prod.sc") {
.sc-globalHeader, .scRibbon .chunk, .scRibbonToolbarStrip {
    background-color: #3765bf;
}

.scRibbon {
    background-color: #1c3e7d;
}

.scRibbon .chunk, .scRibbonToolbarStrip,
.scRibbonNavigatorButtonsActive,
.scRibbonToolbar .scRibbonToolbarStrip {
    background-color: #6b94e1;
}

.sc-applicationContent-main {
    background-color: #c3ddff;
}
}

@-moz-document url-prefix("http://foo.prod.sc/sitecore/login"), domain("bar.prod.identityserver") {
body, .login-outer {
    background: none;
    background-color: #6998ff;
}

.login-page [for='Username']:before, #loginLbl:before {
    content: "【本番環境】 ";
}

.login-page [for='Password']:before, #passLabel:before {
    content: "【本番環境】 ";
}
}

以下のように2つのCSSが読み込まれます。上が管理画面のスタイル、下がログイン画面のスタイルです。

それぞれのスタイルの下部に「適用先」とあるので、上のスタイルに管理画面のURL（ドメイン）を指定して、下にスタイルにログイン画面のURL（ドメイン）を指定してください。

最後に保存すればおしまいです。実際にSitecoreにアクセスしてみてください。

Sitecoreのイメージカラーの補色っぽい色を設定していますが、もし色が気に入らなければ適当に変えてください。

それでは、Happy Sitecoring!

JSSのIntegrated ModeでConnected GraphQLを使用すると証明書エラーが発生する

tackme — Wed, 24 Mar 2021 08:30:37 +0000

JSSでウェブサイトを作成していた際にGraphQLで詰まったので備忘録として残しておきます。

Integrated GraphQLだと動的にパラメータを変更するような処理が組めないので、そういう場合はConnected GraphQLを使うことになります。

しかし、Connected GrapQLを使用したコードをSitecoreへデプロイしてIntegrated Modeで動作させると以下のようなエラーが発生します。

unable to verify the first certificate

これはnode.jsはWindowsの証明書ストアを参照しないため、SSRの実行時にAPIへのリクエストで証明書の検証に失敗することが原因です。

対応方法

まずはウェブサイトの中間（ルート）証明書をブラウザから取得します。

Export & Download — SSL Certificate from Server (Site URL) | by Menaka Jain | Medium

証明書の形式は Base 64 encoded X.509 (.CER) を選択してください。

次にその証明書を適当なフォルダに配置します。

最後にSitecore.configへ以下のパッチを適用します。JSSで使用するNode.jsのプロセスに環境変数 NODE_EXTRA_CA_CERTS を割り当てています（システム環境変数に直接設定してもOKです）。

<configuration xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore role:require="ContentManagement or ContentDelivery or Standalone">
    <javaScriptServices>
      <renderEngines>
        <renderEngine name="nodejs">
          <instance id="defaults">
            <!-- 証明書のパスを指定 -->
            <EnvironmentVariables>
              <var name="NODE_EXTRA_CA_CERTS" value="C:\path\to\certificate.cer" />
            </EnvironmentVariables>
          </instance>
        </renderEngine>
      </renderEngines>
    </javaScriptServices>
  </sitecore>
</configuration>

node.jsでは環境変数のNODE_EXTRA_CA_CERTSに証明書ファイルへのパスを設定しておくことで、node.jsがその証明書を参照するようになります。

これでエラーが発生せずにConnected GrapQLを使用できるようになります。

参考

JSS headless SSR proxy “unable to verify the first certificate” – Dev's Encore

Azure Searchで取得したファセットのカウント数が実際のドキュメント数と異なる場合の対処法

tackme — Wed, 24 Mar 2021 02:15:47 +0000

Azure Searchで取得したファセットのカウント数と実際のドキュメントの数が異なっている現象に遭遇しました。

Azure Searchではシャーディングアーキテクチャが原因で不正確な値を返すことがあるようです。ファセット取得クエリで以下のようにcountに大きな値を渡すことで正確な値を取得できるようになります。

&facet=color,count:100

ただしドキュメント数が多い場合はパフォーマンスが低下する可能性があるため注意が必要です。

参考

Add a faceted navigation category hierarchy - Azure Cognitive Search | Microsoft Docs

slick.jsで作成したスライダー読み込み時のレイアウトずれ対策

tackme — Thu, 18 Mar 2021 05:42:13 +0000

トップページなどによく見られるスライダー（カルーセルパネル）は、画像が読み込まれるまで高さが計算できず、コアウェブバイタルのContent Layout Shift (CLS)に影響を与えます。

今回はよく使用されるスライダーのライブラリであるslick.jsでこの問題に対応する方法をご紹介します。

例として以下のようなスライダーのHTMLを考えます。

<ul class="slider">
  <li>
    <img src="/image1" />
  </li>
  <li>
    <img src="/image2" />
  </li>
  <li>
    <img src="/image3" />
  </li>
</ul>

liタグのに設定した画像をスライダーで表示する簡単なHTMLです。

まずCLSの対策では画像に対してwidthおよびheight属性を指定することが重要です。
これらを指定することで画像の縦横比を予め計算でき、画像が表示される箇所に同等のサイズのスペースを確保しておくことができます。これによりユーザーの意図しないレイアウトのズレが解決できます。

<ul class="slider">
  <li>
    <!-- サイズを指定 -->
    <img src="/image1" width="1000" height="400" />
  </li>
  <li>
    <img src="/image2" width="1000" height="400" />
  </li>
  <li>
    <img src="/image3" width="1000" height="400" />
  </li>
</ul>

ただしslick.jsを使用している場合、スクリプトの読み込みが完了するまでは全ての画像が表示されるため、余計なスペースが確保されてしまいます。
更にスクリプトが読み込まれると１つ目以外の画像が非表示になるため、ユーザーの意図しないレイアウトのズレが発生してしまいます。

これを解決するために、以下のスタイルを当てます。

ul.slider > li:not(:first-child) {
    display: none;
}

これは1つ目以外の画像を予め非表示にしておくスタイルです。

これではスクリプト読み込み後でも2つ目以降の画像が表示されないままなのでは？と思うかもしれませんが、slider.jsではスライダーを作成する際にulタグとliタグの間にdivタグを挟み込みます。
上記のスタイルではulタグの直下のliタグに対してスタイルを当てているため、スクリプト読み込み後はセレクターの対象から外れ、スライダーに画像が表示されるようになります。

これにより、スクリプト読み込み前は1つ目の画像のスペースだけが確保され、読み込み語は1つ目の画像のみが表示されるため、レイアウトのズレが発生しなくなります。

参考

Javascript sliders will kill your website performance | by Javier Villanueva | ITNEXT

Sitecore PaaSでデプロイスロットだけにconfigを適用する方法

tackme — Tue, 02 Mar 2021 06:28:45 +0000

Sitecore 9.0以降ではルールベースのconfigに対応しており、検索プロバイダやサーバーロールに応じて異なるconfigを適用できるようになりました。これらの情報はWeb.configで*:defineという名前のApp Settingsを用いて定義されています。

<!-- 他にもたくさんあります。 -->
<add key="role:define" value="ContentDelivery" />
<add key="search:define" value="Solr" />
<add key="exmEnabled:define" value="yes" />

これらの他にenv:defineという独自の環境名を定義することができる設定が用意されており、これを用いることでデプロイスロットにだけconfigを設定することができます。

手順

Azureポータルでデプロイスロットを開き、Configurationを選択します。
New application settingを選択します。
Nameにenv:defineを、ValueにStagingを入力して、Deployment slot settingにチェックを入れます。
Stagingだけに適用したいconfigの属性に env:require="Staging" を追加します。

<!-- 名前空間 env を宣言 -->
<configuration xmlns:env="http://www.sitecore.net/xmlconfig/env/" xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
        <settings>
            <!-- envがStagingのサーバーは異なるURLを使用する -->
            <setting name="Media.MediaLinkServerUrl" env:require="Staging">
                <patch:attribute name="value">http://staging.example.com</patch:attribute>
            </setting>
        </settings>
    </sitecore>
</configuration>

これでデプロイスロットだけにconfigが適用されます。Deployment slot settingにチェックを入れた設定はスワップしてもスワップ前のサーバーに適用されるので、このような挙動を実現できます。

また以下のように!を使って指定した環境名以外に適用することも可能です。

<configuration xmlns:env="http://www.sitecore.net/xmlconfig/env/">
  <sitecore>
    <settings>
      <!-- envがStagingの場合はFooを使用 -->
      <setting name="MySetting" value="Foo" env:require="Staging" />
      <!-- それ以外ではBarを使用 -->
      <setting name="MySetting" value="Bar" env:require="!Staging" />
    </settings>
  </sitecore>
</configuration>

参考

Sitecoreのライブラリを開発する

tackme — Thu, 24 Dec 2020 06:08:54 +0000

先日Sitecoreのレコメンドライブラリ「Cairngorm」をリリースしました。作成にあたって色々詰まったところがあったので、今回は一からライブラリを作成する方法を解説します。

Sitecoreのライブラリに特有の作業は「プロジェクトの作成」節だけなので、パッケージの作成方法をご存じの方はそれ以外は飛ばしてOKです。

プロジェクトの作成

まずはVisual Studioで以下の設定でプロジェクトを作成します。

テンプレート: クラスライブラリ (.NET Framework)
フレームワーク: .NET Framework 4.5.2

つぎにライブラリの作成にあたって必要になるSitecore関連のパッケージをNuGetでインストールします。
インストールするバージョンは8.2.160729を指定してください。今回は例として、Sitecore.Kernelをインストールして進めます。

一度Visual Studioを閉じて、プロジェクトフォルダにある "packages.config" を開いてください。Sitecore.KernelのpackageノードにdevelopmentDependency="true"を追加しましょう。

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Sitecore.Kernel" version="8.2.160729" targetFramework="net452" developmentDependency="true" />
</packages>

これで、Sitecoreのバージョンに依存しないライブラリが作成できます。具体的には Sitecore 8.2.1 - 9.x に対応できます。おそらく10にも対応できると思いますが、試していないのでわかりません。

ライブラリの実装

Visual Studioを開き、ライブラリの中身を実装します。ここは特に注意点はありません。好きなようにコードを書いてください（もちろん、.NET Framework 4.5.2なので構文には制限があります）。

configファイルを使うライブラリの場合は、プロジェクトにファイルを追加してプロパティでビルドアクションを「コンテンツ」に設定しておいてください。こうしておくと、NuGetでライブラリをインストールすると自動的にconfigファイルが追加されるようになります。

NuGetパッケージの設定

実装を終えたら、AssemblyInfo.csを編集します。それぞれの項目に何を設定すべきかは調べれば出てくると思いますが、ひとまず以下の項目を記述しておけばOKです。

AssemblyTitle: ライブラリ名
AssemblyCompany: 作成者の名前
AssemblyProduct: ライブラリ名
AssemblyCopyright: "Copyright c {年} {作成者名}"
AssemblyVersion: 適当なバージョン
AssemblyFileVersion: 適当なバージョン

私は初めてのバージョンは大体0.1.0を設定しますが、別に1.0.0でも問題ないと思います。

次にプロジェクトフォルダ以下に{プロジェクト名}.nuspecという名前でファイルを作成します。ファイルの中身は以下を貼り付けてください。

<?xml version="1.0" encoding="utf-8"?>
<package>
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="expression">MIT</license>
    <description>$description$</description>
    <releaseNotes></releaseNotes>
    <copyright>Copyright @2020 $author$</copyright>
  </metadata>
</package>

ライセンスは好きなものを設定しましょう。また上記以外にも色々と設定項目があるので、詳しくは以下のURLを参照してください。

https://docs.microsoft.com/ja-JP/nuget/reference/nuspec

NuGetパッケージの作成

パッケージの作成にはNuGet CLIを使います。以下のURLからnuget.exeをダウンロードして適当なフォルダに配置し、パスを通しておいてください。

https://docs.microsoft.com/ja-jp/nuget/consume-packages/install-use-packages-nuget-cli

まずはプロジェクトをRelease構成でビルドしてください。
ビルドが終わったらPowerShellを開き、以下のコマンドを実行します。

$ cd /path/to/solution/project # プロジェクトのフォルダに移動
$ nuget pack -Prop Configuration=Release

処理が終わると、作業フォルダに {プロジェクト名}.{バージョン}.nupkg という名前でパッケージが生成されているはずです。

パッケージの公開

最後に以下のサイトに従ってNuGet Galleryにパッケージを公開することができます。一度公開したパッケージは削除できないので注意してください。

https://docs.microsoft.com/ja-jp/nuget/nuget-org/publish-a-package

上記以外にもnuget pushコマンドを使って公開することもできます。どちらを使っても同じなので好きな方を選んでください。

また、NuGet Galleryに公開しなくても.nupkgファイルさえあればプロジェクトにインストールすることができます。

共有フォルダを利用してnugetパッケージを管理する方法 - Qiita

はじめから公開するのは怖い、という方や社内でだけ共有したい、という方はこちらの方法を使うことをオススメします。

最後に

今回はソースコードだけを提供するライブラリの作成方法でした。ライブラリの一部としてSitecoreのアイテムも提供したい場合は今回の方法では実現できません。

アイテムも提供したい場合は、一度ライブラリを適用したSitecoreの環境を作成して、Sitecoreのパッケージを作成しましょう。作成したパッケージはGitHubやSitecore Marketplaceで公開すればOKです。

ライブラリの作成はいい経験にもなりますし、Sitecore MVPへの応募時のアピールにもなります。皆さんもぜひライブラリを作成して公開していきましょう。

それでは、Happy Sitecoring！

Update all items that share the same catalog entity when the item is saved

tackme — Tue, 24 Nov 2020 08:19:31 +0000

In Sitecore Commerce, a category/product entity associated with the different parents is treated as the different items in the Content Editor. Each item's fields are kept in the entity's ExternalSettings component per entity relationship. So one item is edited, the others will not be updated. You can change this behavior by customizing the CatalogDataProvider class.

To retrieve all items that share an entity, use the CatalogRepository class. The implementation is the following.

public List<Item> GetEntityShareCatalogItems(Item item)
{
    // Deterministic ID is an item's ID in the Content Editor.
    var deterministicId = item.ID.Guid.ToString();

    // Sitecore ID is an one-to-one GUID with the entity.
    // This is used for mapping entity with items internally, so not visible in the Content Editor.
    var catalogRepository = new CatalogRepository(item.Language.Name);
    var sitecoreId = catalogRepository.GetSitecoreIdForDeterministicId(deterministicId);
    if (string.IsNullOrWhiteSpace(sitecoreId))
    {
        return new List<Item> { item };
    }

    var entityId = catalogRepository.GetEntityIdFromMappings(sitecoreId);
    if (string.IsNullOrWhiteSpace(entityId))
    {
        return new List<Item> { item };
    }

    // Get all items that share the entity ID.
    var deterministicIds = catalogRepository.GetDeterministicIdsForEntityId(entityId, includeVariations: true);
    if (deterministicIds == null || !deterministicIds.Any())
    {
        return new List<Item> { item };
    }

    return deterministicIds
        .Select(id => ID.Parse(id, ID.Null))
        .Select(item.Database.GetItem)
        .Where(item => item?.Name == item.Name)
        .Where(item => item.DescendsFrom(item.TemplateID))
        .Where(item => item.Language == item.Language)
        .ToList();
}

And apply field changes to all the items by customizing the CatalogDataProvider.SaveItem method.

public class MyCatalogDataProvider : CatalogDataProvider
{
    public override bool SaveItem(ItemDefinition itemDefinition, ItemChanges changes, CallContext context)
    {
        if (!CanProcessItem(itemDefinition, false))
        {
            return false;
        }

        using (new LanguageSwitcher(changes.Item.Language))
        {
            // Call the method here.
            var catalogItems = GetEntityShareCatalogItems(changes.Item);
            var success = true;

            // Apply the same changes to all the items.
            foreach (var item in catalogItems)
            {
                var definition = new ItemDefinition(item.ID, itemDefinition.Name, itemDefinition.TemplateID, itemDefinition.BranchId);
                var clonedChanges = changes.Clone(item);

                try
                {
                    success &= base.SaveItem(definition, clonedChanges, context);
                }
                catch (Exception ex)
                {
                    success = false;
                }
            }

            return success;
        }
    }
}

Then replace the default data provider with the customized one.

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <dataProviders>
      <catalogProvider type="Sitecore.Commerce.Engine.Connect.DataProvider.CatalogDataProvider, Sitecore.Commerce.Engine.Connect">
        <patch:attribute name="type">Namespace.To.MyCatalogDataProvider, Assembly</patch:attribute>
      </catalogProvider>
    </dataProviders>
  </sitecore>
</configuration>

Now when a catalog item is saved, all related items are updated together.

Sitecoreでウェブサイトの初期表示を速くする方法（Viewのプリコンパイルの設定方法）

tackme — Tue, 10 Nov 2020 08:21:09 +0000

Sitecoreでは初めて描画するレンダリング（View）はアクセス時にコンパイルされます。ページへの初回アクセスが遅くなる原因の一つは、この実行時コンパイルにあります。
あらかじめすべてのViewをコンパイルしておくことで、初期表示時間を改善することができます。

設定方法

Viewファイルが含まれているプロジェクトに、NuGetで RazorGenerator.MsBuild をインストールします。依存関係は無視してOKです。

以下のパッチを適用します。

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
  <!-- 物理ファイルの代わりにプリコンパイルされたViewを使用する設定 -->
  <setting name="Mvc.UsePhysicalViewsIfNewer">
    <patch:attribute name="value">false</patch:attribute>
  </setting>
</settings>
<mvc>
  <!-- プリコンパイルされたViewを使用するアセンブリ一覧 -->
  <precompilation>
    <assemblies>
      <assemblyIdentity name="Habitat.Foundation.Account" />
      <assemblyIdentity name="Habitat.Feature.Search" />
    </assemblies>
  </precompilation>
</mvc>
</sitecore>
</configuration>

プロジェクトをデプロイします。

以上です。

dnSpy等でビルドしたアセンブリを除いてみると、名前空間ASPにコンパイルされたViewが生成されていることを確認出来ます。

注意点

プリコンパイルを設定すると、たとえサーバー上のViewファイルを編集してもページに適用されなくなります。Viewファイルを変更した際には必ずソースコードのデプロイを行うよう注意してください。

参考

Olmec Dev | Sitecore 9 View Precompilation