サイオステクノロジー（Tech.Lab） の技術ブログ
全524件
はじめに こんにちは、サイオステクノロジーのあさりです。今回は、PythonのWebフレームワークであるDjangoに組み込まれているDjango Adminに独自のページを追加する方法を紹介します。内容としては、DjangoAdminのモデル一覧画面におけるIDのリンク先をデフォルトの編集画面から独自で作成した詳細画面に遷移するようにしたいと思います。 環境 Python3.11 Django4.2 前提 独自のページを追加するにあたって何らかのモデルが必要となります。今回は、プロジェクト内にmyappというアプリケーションが存在し、myapp/models.pyに次のような「Book」モデルが定義されており、データベースに反映、myapp/admin.pyで管理画面に追加済みである想定です。プロジェクトの作成から管理画面への追加については こちら の記事を参考にしてみてください。 # myapp/models.py from django.db import models class Book(models.Model): class Meta: db_table = 'book' verbose_name = '本' title = models.CharField(verbose_name = 'タイトル', max_length=100) author = models.CharField(verbose_name = '著者', max_length=100) # myapp/admin.py from django.contrib import admin from .models import Book class BookAdmin(admin.ModelAdmin): list_display = ('id', 'title', 'author') admin.site.register(Book,BookAdmin) Django Adminに独自のページを追加する 今回は以下のID部分のリンク先をデフォルトの編集画面から独自で作成した詳細ページに遷移するようにしたいと思います。 独自ページ追加は以下の3つのステップで行います。 ビュー関数の作成 テンプレートの作成 URLパターンの登録 それでは実際に実装していきましょう。 ビュー関数の作成 ビューは自作もできますが、今回は単一のオブジェクトの詳細を表示するためのDetailViewという組み込みビューを使用します。DetailViewは、特定のモデルのインスタンスを取得し、それをテンプレートに渡します。それでは、myapp/views.pyで次のようなビューを作成しましょう。 # myapp/views.py from django.views.gneric import DetailView from .models import Book class BookDetailView(DetailView): model = Book #参照するモデルを指定 template_name = 'admin/myapp/book_detail.html' #データを渡すテンプレートを指定 def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) # fieldsに各フィールドのverbose_nameとフィールド値を格納 context['fields'] = [(field.verbose_name, getattr(self.object, field.name)) for field in Book._meta.fields] return context テンプレートの作成 先ほどのビューからデータを受け取るテンプレートを作成していきます。今回はプロジェクト直下にtemplates/adminフォルダを作成し、そこにbook_detail.htmlファイルを置きます。 {% extends "admin/base_site.html" %} {% load static %} {% block content %} <!DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/css" href="{% static 'admin/css/forms.css' %}"> </head> <body> <h1>Book Details</h1> <!-- フィールド名とその値を表示します --> {% for name, value in fields %} <p> <strong>{{ name }}:</strong> {{ value|default:"" }} </p> {% endfor %} </body> </html> {% endblock %} 一行目でadmin/base_site.htmlを継承することにより、管理画面のヘッダーをつけることができます。今回の詳細画面ではビューから受け取ったfieldsを使って、「フィールド名：値」の形で表示されるようにしています。 次に独自に作成したtemplatesディレクトリが参照されるように、設定ファイルのTEMPLATESを次のように編集してください。 # settings.py TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [ os.path.join(BASE_DIR, 'templates'), # templatesディレクトリを追加 ], 'APP_DIRS': True, ... }, ] URLパターンの登録 独自のURLパターンの登録は、ModelAdminのget_urlsメソッドをオーバーライドすることで可能です。今回は次のようにURLパターンと呼び出されるビューを登録しました。また、一覧画面でのIDのリンク先を詳細画面とするlink_to_detailメソッドを定義し、一覧画面で表示するフィールドとして設定しています。 # myapp/admin.py from django.contrib import admin from django.urls import path, reverse from .models import Book from .views import BookDetailView class BookAdmin(admin.ModelAdmin): def get_urls(self): urls = super().get_urls() # URLパターンの登録 my_urls = [ path('<int:pk>/detail/', self.admin_site.admin_view(BookDetailView.as_view()), name='detail_view'), ] return my_urls + urls # 一覧画面でIDのリンク先として詳細画面を指定 def link_to_detail(self, obj): link = reverse("admin:detail_view", args=[obj.pk]) return format_html('<a href="{}">{}</a>', link, obj.pk) link_to_detail.short_description = 'ID' link_to_detail.admin_order_field = 'id' #idに基づくソートの指定 #表示するフィールドの指定 list_display = ('link_to_detail', 'title', 'author') ... これで”/myapp/book/1/detail”のような形でアクセス可能となります。実装としては以上になります。サーバーを立ち上げてID部分を押下した際に詳細画面に遷移するか確かめてみてください。以下のようなページが表示されたら成功です。 おわりに 今回は、DjangoAdminに独自のページを追加する方法を紹介しました。今回はDetailViewを用いて単一モデルの詳細情報を取得しましたが、Djangoには他にもモデル一覧を取得するListViewなど便利なクラスが用意されているので、試してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DjangoAdmin 独自ページの追加方法 first appeared on SIOS Tech. Lab .
こんにちは、サイオステクノロジーの佐藤 陽です。 今回は、ASP.NET Core入門シリーズ第二弾として、 Program.cs ファイル の中身について解説していきたいと思います。 ASP.NET Core をこれから使っていくよ！ Program.cs って何が書いてあるの？ Startup.cs どこいった？ といった方はぜひ読んでみてください。 また前回の記事から繰り返しになりますが まだ自分も勉強中の身なので、記事の内容に誤りなどありましたらコメントにて指摘いただけると幸いです。 はじめに 今回はAPS.NET Core のプロジェクトの肝である(?)、 Program.cs のファイルをコードレベルで解説していきたいと思います。 ちなみにASP.NET Core 5時代のものに関しては、武井さんの記事でも紹介していただいてます。 多分わかりやすいASP.NET Core Webアプリケーション ただ、こちらもなんだかんだ 5 年前の記事であり 色々と ASP.NET Core も変わってきているため、更新の意味も込めて改めて書いてみたいと思います。 ASP.NET Coreとは？ ASP.NET Core は、.NET プラットフォームをベースとするフレームワークです。 以前は、ASP.NET のフレームワークが幅広く利用されていました。 ASP.NET Core は、ASP.NET を改良したものになります。 そして ASP.NET Core も年々進化し、2024年4月現在は LTS リリースとしては ASP.NET Core 8.0 が最新のものになります。 今回の記事は ASP.NET Core 8.0 を対象としたいと思います。 ASP.NET Coreの全体像 まず初めに、 ASP.NET Core のアプリがどのように動作するかについて見ていきたいと思います。 動作を理解したうえで Program.cs の中身を見た方が理解が捗るためです。 なお前提として、今回は IIS インプロセスホスティング のケースを見ていきたいと思います。 「ホスティングについてよくわからないよー」という方は前回の記事をご覧ください。 ASP.NET Core入門 – ホスティング 解説【.NET 8】 ではまず全体の流れを図に示します。 IIS Server に含まれる ASP.NET Core Module が 、dotnet コマンドにより ASP.NET Core アプリケーションを起動します。 なおこの ASP.NET Core アプリケーションというのは 単なるコンソールアプリケーション にすぎません。 そしてこの コンソールアプリケーションのコードこそが Program.cs ファイルに含まれています 。 コンソールアプリケーションが、 IISHTTPServer をホストし、アプリを開始します。 IIS Server がリクエストを受けると IISHTTPServer へとルーティングします。 リクエストは ASP.NET Core ミドルウェアパイプラインにて処理されます ミドルウェアパイプラインでの処理後、HttpContext としてアプリケーションコードに渡され、アプリケーションコードにて処理されます といった流れとなります。 このあたりの流れは 公式のドキュメント にも記載があります。 この後、実際にProgram.csのソースコードを追っていきますが 上の図や、全体の流れと照らし合わせながら見ていただくと、より理解しやすいかと思います。 プロジェクトを作成してみる 早速プロジェクトを作ってみたいと思います。 用意するもの Visual Studio Code C# Extension .NET SDK 8.0 プロジェクト作成 以下の dotnet コマンドを利用して新規プロジェクトを作成します。 dotnet new mvc -o aspnetcore-8-mvc 実行してみる せっかく作ったので一度実行してみます。 dotnet run --project .\aspnetcore-8-mvc\aspnetcore-8-mvc.csproj 実行が完了したら、ブラウザで http://localhost:5088 にアクセスします。 すると、アプリにアクセスできるかと思います。 プロジェクトの中身を見てみる また、プロジェクトの中身としては以下のようなものが作成されるかと思います。 今回は Program.cs ファイルに絞って解説していきたいと思います。 Startup.cs クラスは？ ASP.NET Core 5.0 あたりまでのバージョンをメインで開発されていた方の中には 「Startup.csファイルってどこ行ったの？？」 と思われる人もいるかと思います。 ここが ASP.NET Core 5.0 と 6.0 以降のバージョンで大きな違いの 1 つでもあります。 ASP.NET Core 6.0 以降では 最小ホスティングモデル といったものが採用され Startup.cs と Program.cs が 1 つの Program.cs ファイルに統合されています。 なお、統合されたといっても機能的には同一のものであり ASP.NET Core 6.0 以降でも以前のように Startup.cs ファイルを使った記述も可能です。 「わざわざ新しい最小ホスティングモデルに切り替える必要は無い」と公式ドキュメントにも記載があります。 参考： よく寄せられる質問 (FAQ) Program.cs の中身 先ほど作成したプロジェクトの Program.cs の中身を見てみます。 var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddControllersWithViews(); var app = builder.Build(); // Configure the HTTP request pipeline. if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Home/Error"); // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts. app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.Run(); では早速、上から順を追って見ていきたいと思います。 Builder作成 var builder = WebApplication.CreateBuilder(args); アプリをビルドするための Builder ( WebApplicationBuilder ) を作成します。 ではこの Builder が何をするかというと ソースコード や ドキュメント を見る感じ、以下のようなことを行っているように見えます。 (聞き慣れないワードが出てきているかもしれませんが、今後のブログにて解説する予定です。) 新しい構成ソースとプロバイダーを追加する Hostされる環境の情報を取得する ログプロバイダーを追加する DIで用いるサービスを追加する HostとWebHostを構成する なおASP.NET Core5.0 以前では、以下のように書かれていた箇所に該当します。 public class Program { public static void Main(string[] args) { CreateWebHostBuilder(args).Build().Run(); } //ここの部分 public static IWebHostBuilder CreateWebHostBuilder(string[] args) => WebHost.CreateDefaultBuilder(args) .UseStartup(); } この時、6.0以降の WebApplication.CreateBuilder() と、5.0以前の CreateWebHostBuilder.Build() を比較すると、 「ASP.NET 5.0も6.0以降も同じ処理って言ってたのにApplicationのビルダーなのかWebHostのビルダーなのかで何か違うじゃん」 といったように感じる方もいられるかもしれません。 このあたりがまだ追い切れていないのですが、以下の記事が非常に参考になりました。 Comparing WebApplicationBuilder to the Generic Host これを踏まえての自分の解釈にはなるのですが、 ASP.NET Core 5.0以前においては Program.cs アプリケーションの起動とライフタイムを管理するための WebHost を構築するコードが含まれる Startup.cs パイプラインなどの Application の要素を構築するコードが含まれる (パイプラインに関してはまた今後のブログで紹介していく予定です。) → こちら に書きました。 という区分けになっていたように見えます。 ただ、これらがひとつのProgram.csファイルに統一されるようなになったため Hos tのBuilderではなく、 Hostを含むApplication全体 のBuilderとして実装され、実装が異なっていると考えました。 ただ機能としては同じであり、 WebApplicationBuilder のプロパティとしてもHost, WebHostが含まれていることがわかります。 そのため、WebApplicationBuilderを通してHostやWebHostの構成も可能です。 イメージとしてはWebHostBuilderをWebApplicationBuilderでラップしているような感じでしょうか。 次に進みます。 DIコンテナへのサービス追加 // Add services to the container. builder.Services.AddControllersWithViews(); ここに書かれているコードは、DI コンテナにサービスを追加しているものになります。 DI コンテナ周りについては追ってブログで紹介したいと思うので、本記事では割愛します。 なおこのコードは、以前のバージョンでいうところの Startup.cs クラスの ConfigureServices メソッドで記載している箇所に該当します。 次に進みます。 WebApplicationインスタンスの作成 var app = builder.Build(); ここでWebApplicationBuilderを利用して、WebApplicationのインスタンスを作成します。 このWebApplicationのインスタンスは以下のような仕事をします。 ミドルウェアパイプラインの構築 アプリケーションの開始 続くコードで実際にこれらの処理を実装していきます。 if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Home/Error"); // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts. app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); ここでは利用するミドルウェアを指定し、パイプラインを構築します。 この時、ミドルウェアが実行される順番は重要であるため、コードを記載する順番には気を付ける必要があります。 また、 上の図 のstep4にて 4. リクエストは ASP.NET Core ミドルウェアパイプラインにて処理されます と書きましたが、この処理するパイプラインを構成しているのがここのソースコードになります。 また、こちらのコードはASP.NET Core 5以前のバージョンでいうところの Configure メソッドで記載している箇所に該当します。 アプリの開始 app.Run(); このコードによって、サーバーおよびアプリケーションを起動し、ホストが終了するまで呼び出し元のスレッドをブロックします。 Program.csソースコードの中身としては以上となります。 まとめ 今回は.NET 8.0におけるASP.NET CoreのProgram.csの中身を見てみました。 ざっくりとまとめると ASP.NET Core 6にて採用された最小ホスティングモデルにより、Startup.csファイルとProgram.csファイルが統合された ただし、機能的に違いはなくどちらを採用してもよい Program.csに書かれている内容としては、コンソールアプリケーションのソースコードである コンソールアプリケーションによってホストが構成がされたのちに、実際にサーバーおよびアプリが開始される リクエストは IIS→IISHTTPServer→Middleware Pipeline→ApplicationCode といった順で処理される といった感じです。 次回以降の記事では、リクエストパイプラインや、ルーティング周りなどをもう少し詳細にみていきたいと思います。 ではまた！ 参考文献 ASP.NET Core の概要 Comparing WebApplicationBuilder to the Generic Host ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ASP.NET Core入門 – Program.cs 解説【.NET 8】 first appeared on SIOS Tech. Lab .
はじめまして！ サイオステクノロジー の安藤 浩です。E2Eテストで利用されるPlaywright の入門として、インストールからコード生成、テスト実行の方法についてご紹介させていただきます。 Playwright とは Web アプリのテスト、テスト自動化が可能なNode.jsの ライブラリのことです。 特徴として以下が挙げられます。 クロスブラウザ対応 非同期処理を適切に処理して、シンプルなテストコードが書ける ブラウザ操作からコードが生成できる Visual Regression Test (VRT)に対応 ほかのE2Eテストツールは Selenium, Puppeteer, Cypressなどが挙げられ、比較対象となります。 ここからPlaywright のインストールからブラウザ操作でのテストコード生成、テスト実行、テスト実行結果の確認までご紹介します。 環境 実行環境は以下の通りです。 OS/SW Version Windows 10 Pro 22H2 VSCode 1.88.0 Node.js 20.12.2 npm 10.5.1 Playwright のインストール 対象のプロジェクトにディレクトリでPlaywright を導入したい場合、以下のコマンドを実行します。(現時点での最新バージョンは1.43.0 ) npm init playwright@latest いくつか選択肢が出てくるので、選択して初期化します。例えば、TypeScript か JavaScript でテストコードを書くかというものです。 Getting started with writing end-to-end tests with Playwright:Initializing project in '.' ? Do you want to use TypeScript or JavaScript? ... > TypeScript JavaScript ここでは以下のように設定しておきます。 √ Do you want to use TypeScript or JavaScript? · TypeScript √ Where to put your end-to-end tests? · tests √ Add a GitHub Actions workflow? (y/N) · true √ Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) · true ファイル生成後のファイル構成は以下のようになります。 Playwright Test for VSCode というVSCodeの拡張機能があるのでこちらもインストールします。 https://marketplace.visualstudio.com/items?itemName=ms-playwright.playwright この拡張機能を利用して、 ブラウザ操作からコード生成する方法を紹介します。 ブラウザ操作でのコード生成 まず、VSCodeでTestingを表示します。VSCodeのメニューのView > Testing から表示できます。 Testingの画面下部にPlaywright の拡張機能が表示されているので、「Show browser」にチェックを入れ、「Record new」を押下します。 その時、Chromiumが起動するのでアドレスバーにテスト対象のアドレスを入力します。ここではPlaywright のホームページ ( https://playwright.dev/ )を指定します。 ページが表示されたら、赤枠の箇所を押下し、マウスカーソルを黒背景のPlaywrightの箇所に移動し押下してみます。 すると、文字列が正しいかというチェックをするアサーションの画面(Assert that element contains text)が表示されるので、赤枠のチェックボタンを押下します。 ここまででVSCode上ではtest-1.spec.ts というファイルが生成され、以下のコードが生成されています。 import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { await page.goto('https://playwright.dev/'); await expect(page.locator('h1')).toContainText('Playwright'); }); 続いて、ブラウザで画面上の「GET STARTED」ボタンを押下し、画面を表示します。 先ほど同様、赤枠の文字列のアサーションのボタンを押下し、「Installation」の箇所を押下します。 アサーションの画面(Assert that element contains text)が表示されるので、赤枠のチェックボタンを押下します。 「Introduction」の箇所も同様にアサーションを追加します。 ブラウザを閉じると最終的に以下のテストコードが生成されます。test-1.spec.ts ファイルを保存しておきます。 import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { await page.goto('https://playwright.dev/'); await expect(page.locator('h1')).toContainText('Playwright'); await page.getByRole('link', { name: 'Get started' }).click(); await expect(page.locator('h1')).toContainText('Installation'); await expect(page.locator('#introduction')).toContainText('Introduction'); }); ※テストのタイトル (ここでは’test’になっている) などは分かりやすくするため適宜変更してください。詳細は https://playwright.dev/docs/api/class-test をご参照ください。 生成されたコードによるテスト実行 以下のテストコードの箇所にテスト実行ボタンが表示されるので押下するとテストが実行されます。 テスト実行後は以下のようになり実行結果が確認できます。 すべてのテストを実行したい場合は以下のコマンドを実行します。 npx playwright test テスト結果の確認 (レポートの表示) テストが完了したら、以下のコマンドを実行することでテスト結果のレポートが表示されます。 npx playwright show-report 指定のURLにアクセスするとHTML がlocalhostで見られるようになります。 各ブラウザでのテスト状況などがわかるので便利ですね。失敗した場合のテストは失敗箇所がわかるようになっています。 まとめ Playwrightの特徴とインストール、ブラウザ操作でのコード生成、テスト実行・結果確認までご紹介しました。 ブラウザ操作でのコード生成では、正確なコードであるか検証が必要かつE2Eテストでは人間の見た目に近い操作にしたいはずなのでpage.locator でIDによる指定などはしないはずなので、コードの改良は必要だと思います。 導入も容易にできそうですし、コード生成機能がついているのでメンテナンスも比較的容易になりそうだと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Playwright 入門 – インストール、ブラウザ操作でのコード生成、テスト実行 first appeared on SIOS Tech. Lab .
今回はSBOMツールの一つである「bom: The SBOM Multitool」について解説します。SBOMについてよく分からないという方は、まず こちら の記事を読んでみてください。 bomとは ソフトウェア部品表 (SBOM) を作成、表示、変換できるユーティリティ Kubernetes プロジェクトの SBOM を作成するプロジェクトの一部として作成された ディレクトリ、コンテナー イメージ、単一ファイル、およびその他のソースから SPDX パッケージを生成できる汎用ツール SPDX カタログ内の 400 以上のライセンスを認識するライセンス分類子が組み込まれている Golang の依存関係分析や、 .gitignore Git リポジトリのスキャン時の完全なサポートなどがある 環境 OS、ツール バージョン Ubuntu 22.04 GO 1.21.4 bom 0.6.0 インストール GOプロジェクトなので、下記のコマンドでインストールします。 go install sigs.k8s.io/bom/cmd/bom@latest バージョンを確認します。 bom version 走査対象 JavaでWebアプリケーションを作成する際に使用される Tomcat を対象とします。 SBOMの生成 すべての SPDX ドキュメントは、名前空間を宣言する必要がありますが、今回は全て「http://example.com/」と指定しています。 YAMLファイルからBOMの作成 今回はこちらは省略します。興味のある方は 公式ドキュメント を参照してください。 現在のディレクトリからSBOMを作成 generateコマンドにoオプションで出力ファイル名、formatオプションでJsonを指定します。 bom generate -n http://example.com/ -o tomcat-spdx.json --format json . コンテナイメージから生成 generateコマンドにiオプションでコンテナイメージを指定します。 bom generate -n http://example.com/ -i tomcat:11.0 -o tomcat-image-spdx.json --format json 特定のファイルのみを対象としたい場合 generateコマンドにfオプションでファイル名を指定します。 bom generate -n http://example.com/ \ -o tomcat_spdx.json --format json \ -f java/org/apache/tomcat/JarScannerCallback.java \ -f java/org/apache/tomcat/SimpleInstanceManager.java その他のオプションについては 公式ドキュメント を参照してください。 SPDXドキュメントの構造を描画 documentコマンドにoutlineを指定します。 bom document outline tomcat-spdx.json オプションは 公式ドキュメント を参照してください SBOM 内の情報を検索 documentコマンドにquery、SPDXファイル、検索条件を指定します。 bom document query tomcat-spdx.json "depth:2 name:log4j" depthは深さ、nameは検索したい要素を正規表現で指定できる 成果物を sbom と照合してチェックする validateコマンドとして用意されていますが、こちらは開発中のため今回は省略します。 さいごに 今回はSBOMツールの一つである「bom: The SBOM Multitool」について解説しました。まだメジャーリリースが行われていないので、本来の目的であるKubernetes プロジェクトの SBOM を作成する機能はないですが、興味のある方は試してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SBOMツール紹介 ~ bom: The SBOM Multitool編 ~ first appeared on SIOS Tech. Lab .