カテゴリー: tech

  • [ERROR] Runtime.ImportModuleError: Unable to import module ‘app’: cannot import name ‘escape’ from ‘jinja2’ (/var/task/jinja2/__init__.py)

    以下は、Jinja2 ライブラリのバージョンに互換性の問題がある場合に発生するエラーについての対処法についての説明です。

    Runtime.ImportModuleError エラーが発生した場合、Lambda 環境で使用される Jinja2 ライブラリのバージョンに互換性の問題がある可能性があります。この問題を解決するには、互換性のあるバージョンの Jinja2 を使用するように環境を構成する必要があります。

    まず、requirements.txt ファイルを確認して、Jinja2 のバージョンが明示的に指定されているかどうかを確認し、以下のようにバージョンを指定します。

    Copy code
    Jinja2==2.10.1

    次に、Lambda 関数にデプロイされる依存関係を更新し、Lambda 関数を再デプロイします。これにより、互換性のあるバージョンの Jinja2 がインストールされ、エラーが解消されるはずです。

    もし最新バージョンの Jinja2 を使用している場合、互換性の問題が発生する可能性があるため、古いバージョンを使用するか、コードを更新する必要があります。それでもエラーが解決しない場合は、Lambda 関数のログを確認し、原因を特定する必要があります。

  • [ERROR] Runtime.ImportModuleError: Unable to import module ‘app’: cannot import name ‘BaseRequest’ from ‘werkzeug.wrappers’ (/var/task/werkzeug/wrappers/__init__.py)

    Flask と Werkzeug ライブラリのバージョンに互換性の問題がある場合に発生するエラーについての対処法についての説明です。

    Flask==1.1.2
    Werkzeug==0.16.1

    次に、Lambda 関数にデプロイされる依存関係を更新し、Lambda 関数を再デプロイします。

    これにより、互換性のあるバージョンの Flask と Werkzeug がインストールされ、エラーが解消されるはずです。

     

    もし最新バージョンの Flask と Werkzeug を使用している場合、互換性の問題が発生する可能性があるため、古いバージョンを使用するか、コードを更新する必要があります。それでもエラーが解決しない場合は、Lambda 関数のログを確認し、原因を特定する必要があります。

     

  • Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考:書評

    Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考:書評

    開発者向けの書籍『Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考』を読みました。 本記事では、本書の要点と私の感想も交えてまとめていきます。   この本は初心者から経験豊富なエンジニアまで幅広い読者にとって有益ですが、現実の開発現場ではさまざまな要因が影響を与えるため、適切な判断と柔軟な対応が必要かと思います。  

    はじめに

    近年、ソフトウェア開発の現場では、品質の高いコードを書くことが求められています。 本書『Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考』は、開発者が品質の高いコードを書くための考え方や技術を網羅的に紹介しており、現場で直接活用できる内容が多く含まれています。

    章ごとの要点

    以下に、本書の各章ごとの要点をまとめます。

    第1章: 良いコードと悪いコードの基本的な考え方

    この章では、良いコードと悪いコードの定義やそれらを判断する基準について解説されています。 良いコードとは、可読性、保守性、拡張性が高く、効率的で堅牢なコードのことをこの本では指しています。 一方、悪いコードは、読みにくく、保守や拡張が困難で、パフォーマンスや安全性に問題があるということが特徴です。

    第2章: コード品質を向上させるためのプログラミング原則

    この章では、SOLID原則やDRY原則など、コード品質を向上させるためのプログラミング原則が紹介されています。 これらの原則を遵守することで、可読性や保ち続性、拡張性が高いコードを実現することができます。

    第3章: リファクタリングによるコード改善

    リファクタリングは、コードの構造を変更することなく、可読性や保守性を向上させる手法です。 この章では、リファクタリングの重要性や具体的な手法が紹介されており、Martin Fowlerの「リファクタリング」などの他の資料とも相互補完的な関係があります。

    第4章: チームでのコード品質向上

    チームでのコード品質向上のための取り組みとして、コードレビューやペアプログラミングが紹介されています。 また、コーディングスタイルの統一やドキュメントの整備など、チーム全体での品質向上に役立つアプローチも解説されています。

    第5章: テスト駆動開発と自動化

    この章では、テスト駆動開発(TDD)と自動化の重要性が説明されています。 TDDは、テストを先に書くことで、コードの品質と保守性を向上させる開発手法です。 また、自動化により、ビルドやテスト、デプロイの効率化が実現されます。  

    感想

    私の感想として、本書は非常に読みやすく、実践的な内容が多く含まれているので、ソフトウェアエンジニアにとって有益な1冊だと思います。 特に、SOLID原則やリファクタリングに関する部分は、現場で直接活用できる知識が豊富に紹介されていて、非常に役立ちます。 ただし、実際の開発現場ではさまざまな要因が影響を与えるため、本書の内容を鵜呑みにせず、適切な判断と柔軟な対応が必要です。 また、開発者は継続的な学習やスキルの向上を心がけることが重要であり、本書を参考にしつつ、自身の経験や状況に応じて最適な方法を見つけることが求められます。 ただし、以下の部分は気になりました。

    • 一部の章が他の資料と重複している: 本書の内容の一部は、他の書籍や資料と重複しているため、すでにそれらを読んでいる読者にとっては新規性が低い場合があります。
    • 初心者向けの内容が少ない: 本書は経験豊富なエンジニア向けの内容が多く、初心者にとっては難解である可能性があります。
    • 個々のケースに対する具体的な解説が不足している: 本書では、一般的な原則や技術が紹介されていますが、特定のケースに対する具体的な解説が不足しているところがあるように感じました。
    • 実践のしやすさに関する懸念: 本書では多くの実践的な指南が提供されていますが、これらをすぐに現場で実践することが容易でない場合もあります。例えば、既存のプロジェクトで多くの技術的負債がある場合や、組織の文化が変更に抵抗する場合などです。このような状況では、開発者は段階的に改善を進めることや、組織全体の意識改革を促すことが重要です。
    • 学習の効果に関する懸念: 本書を読むことで、多くの知識や技術を習得できる可能性がありますが、それらを継続的に練習し、実際の開発現場で活用できるようになるまでには、時間と努力が必要かと思います。開発者は、継続的な学習やスキルの向上を心がけるとともに、定期的に知識を見直し、新たな技術や手法を取り入れることが重要と感じました。

    まとめ

    『Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考』は、ソフトウェア開発者にとって有益な書籍であり、多くの実践的な知識や技術が紹介されています。ただし、実際の開発現場ではさまざまな要因が影響を与えるため、適切な判断と柔軟な対応が求められます。 最後に、開発者は本書を参考にしつつ、自身の経験や状況に応じて最適な方法を見つけることが重要です。組織全体で品質向上の取り組みを行い、継続的なスキルアップを目指すことで、持続可能な開発を実現できるのではないかと感じました。  

  • WARNING: The command completed successfully but no settings of ‘sumito.tsukada’ have been modified.

    概要

    powershell を叩いて以下のようなエラーが発生した

    WARNING: The command completed successfully but no settings of 'sumito.tsukada' have been modified.

    調査した結果

    この警告メッセージは、PowerShellで実行されたコマンドが正常に完了したものの、

    「sumito.tsukada」という設定が変更されなかったことを示しています。

    つまり、コマンドは実行されましたが、特定の設定の変更が実際には行われなかった、または変更する必要がなかったということのようです。

    調査した限り、このような状況は、以下のような場合に発生することがあります。

    1. コマンドが正しく実行されましたが、既に設定されている値と同じ値が指定されたため、実際には変更がなかった。
    2. コマンドが正しく実行されましたが、条件に一致する設定が見つからなかったため、変更が行われませんでした。
    3. コマンドが何らかの理由で適用されるべき設定を見逃してしまった。

    この警告メッセージに対処するには、コマンドを再確認し、正しい設定が適用されるように修正するか、

    既に適切な設定がされている場合は、この警告メッセージを無視しても問題ありません。

    ただし、期待した変更が正しく適用されているかどうかを確認するために、関連する設定やログをチェックすることが推奨されているようです。

  • Pythonによる日付の操作方法について – datetimeとtimedeltaの使い方

    Pythonのdatetimeモジュールは、日付や時刻を操作するためのクラスを提供しています。

    このモジュールを使用して、日付の計算やフォーマットを簡単に行うことができます。

    from datetime import datetime, timedelta
    
    # 現在の年月を取得
    now = datetime.now()
    this_month_str = now.strftime('%Y%m')
    
    # 先月の年月を取得
    last_month = now - timedelta(days=now.day)
    last_month_str = last_month.strftime('%Y%m')
    
    # 10週間前の年月を取得
    ten_weeks_ago = now - timedelta(weeks=10)
    ten_weeks_ago_str = ten_weeks_ago.strftime('%Y%m')
    
    # 今月日付を取得
    today_str = now.strftime('%Y%m%d')
    
    print('今月:', this_month_str)
    print('先月:', last_month_str)
    print('10週間前:', ten_weeks_ago_str)
    print('今日:', today_str)
    

    出力結果

    今月: 202303
    先月: 202302
    10週間前: 202301
    今日: 20230316

    datetimeモジュールから現在の日付を取得します。

    ここでは、nowメソッドを使用して現在の日付と時刻をdatetimeオブジェクトとして取得します。

    その後、strftimeメソッドを使用して、年月のみを表す文字列を生成します。

     

    timedeltaモジュールは現在を軸に先月の日付や10週間前の日付を相対的に計算することができます。

    timedeltaは、日付や時間の差分を表すオブジェクトです。

    ここでは、daysやweeksを指定して、現在の日付から指定した期間だけ引いた日付を取得しています。

     

  • Poetryでインストールしてあるパッケージのバージョンを変更する

    Poetryでインストールしてあるパッケージのバージョンを変更する

     

    poetry addコマンドで新しいバージョンを指定してパッケージをインストールします。例えば、requestsパッケージのバージョンを2.26.0に変更する場合は、以下のようにします。

    poetry add requests==2.26.0
    

    このコマンドを実行すると、指定したバージョンのパッケージがインストールされます。

    poetry lockコマンドでpoetry.lockファイルを更新します。これにより、新しいバージョンのパッケージがプロジェクトで使用されるようになります。

    poetry lock
    

    poetry installコマンドで、poetry.lockファイルに従ってパッケージを再インストールします。

    poetry install
    
    以上の手順で、Poetryでインストールしてあるパッケージのバージョンを変更することができます。
    
    
    
    
  • ValueError: Public Client should not possess credentials

    python で AzureAD の認証をする際 msal を使うことが多いが、

    PublicClientApplicationクラスに証明書を渡すと、

    ValueError: Public Client should not possess credentials というエラーになる。

    対処法として ConfidentialClientApplication クラスを使うことで回避できる。

    PublicClientApplicationクラスはパブリッククライアントを表し、アプリケーション自体が認証されることはないため、証明書の提供はサポートされていない。

    証明書ベースの認証には、ConfidentialClientApplicationクラスを使用する必要がある。

    このクラスは機密クライアントを表し、アプリケーション自体が認証されるため、証明書の提供が必要となるという理由

    以下、サンプルコード

    from msal import ConfidentialClientApplication
    
    client_id = 'YOUR_CLIENT_ID'
    tenant_id = 'YOUR_TENANT_ID'
    client_secret = 'YOUR_CLIENT_SECRET'
    authority = f'https://login.microsoftonline.com/{tenant_id}'
    
    app = ConfidentialClientApplication(
        client_id=client_id,
        client_credential=client_secret,
        authority=authority
    )
    
    result = None
    result = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])
    
    if "access_token" in result:
        print(result['access_token'])
    else:
        print(result.get("error"))
        print(result.get("error_description"))
        print(result.get("correlation_id")) 
    
  • 「AWSではじめるデータレイク」を読んだ

    「AWSではじめるデータレイク」は、AWSを使ってデータレイクを構築する方法について詳しく解説された書籍である。本書は、AWSのデータレイクについて初心者から中級者までのユーザーに向けて、豊富な事例や具体的な手順を示しながら、データレイクの概念や構成要素、設計方法などについて詳細に解説している。

    本書の特徴の一つは、AWSのデータレイクを利用するメリットや機能面の解説が非常に丁寧であることだ。また、AWSのサービスを組み合わせて、スケーラブルで堅牢なデータレイクを構築するためのベストプラクティスについても解説されている。さらに、実際のビジネスケースを通じて、データレイクがどのように活用されるかもわかりやすく説明されている。

    本書で取り上げられたデータレイクの構成要素は、ストレージ層、処理層、分析層、セキュリティ層の4つである。それぞれの層の機能や使い方について、AWSのサービスを活用した実践的な手順が解説されている。例えば、ストレージ層では、S3やGlacierなどのAWSのストレージサービスを使って、データの保管やアクセス方法について詳しく解説されている。

    処理層では、EMRやLambdaなどのAWSのサービスを使って、データの加工や変換方法について解説されている。分析層では、RedshiftやAthenaなどのAWSのデータ分析サービスを使って、データの分析や可視化方法について解説されている。また、セキュリティ層では、IAMやKMSなどのAWSのセキュリティサービスを使って、データの保護やアクセス制御方法について詳しく解説されている。

    本書の内容は非常に実践的であり、データレイクの構築に必要なスキルや知識を習得する上で非常に役立つ。AWSのサービスを組み合わせることで、大量のデータを効率的に扱うことができるため、データ分析やビジネスインテリジェンスの分野での活用において、非常に有用な知識となる。また、本書で紹介されたベストプラクティスを活用することで、スケーラビリティや可用性など、データレイクを構築する上での課題に対しても十分な対応が可能となる。

    さらに、本書ではAWS以外のデータレイクの構築方法やツールについても言及されており、AWS以外の環境でもデータレイクを構築する際に役立つ情報が得られる。また、データレイクの構築におけるトラブルシューティングやパフォーマンスチューニングのポイントについても詳しく解説されているため、実際の運用においても非常に参考になる。

    一方で、本書はAWSを利用する上での基本的な知識があることが前提となっており、AWSの初心者にとっては難易度が高い可能性がある。また、本書で紹介されたAWSのサービスや機能が、新しいバージョンにアップデートされた場合には情報が古くなる可能性もあるため、最新の情報を得るためにはAWSのドキュメントや公式の情報源を参照する必要がある。

    総じて、本書はAWSを使ったデータレイクの構築に興味がある方や、既にAWSを利用している方にとって非常に有用な一冊である。豊富な実践的な事例や手順が示されており、AWSのデータレイクを効果的に活用するためのノウハウが詳しく解説されているため、データ分析やビジネスインテリジェンスの分野での活用を目指す方には、必読の書と言える。

  • [: 1: unexpected operator

    github actions で [: 1: unexpected operator というエラーが出た時の対処法を紹介。

    原因はshell が POSIX に準拠していないため起こる。

    POSIX に準拠している構文かどうかは checkbashisms コマンドで確認することができる。

     checkbashisms hogehoge.sh
    possible bashism in hogehoge.sh line 16 (should be 'b = a'):
        if [ $exist == 0 ] ; then
    

    この構文が問題であることがわかった

    上記の通りアドバイスをくれる。

     if [ $exist == 0 ] ; then
    

    今回はアドバイス通りではなく

    if [ $exist -eq 0 ] ; then

    と変更して対処した。

  • docker remote repository に image があるか確認する

    dokcer manifest inspect を使って確認することができる

    $ docker manifest inspect $IMAGE_NAME:$IMAGE_TAG
    

    上記コマンドを実行して、イメージが存在していると

    {
    	"schemaVersion": 2,
    	"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    	"config": {
    		"mediaType": "application/vnd.docker.container.image.v1+json",
    		"size": 9641,
    		"digest": "sha256:xxxxxxx"
    	},
    	"layers": [
    

    というレスポンスを返す

    存在しない場合は以下のようなレスポンスになる

    no such manifest:
    

    そのため

    $ docker manifest inspect $IMAGE_NAME:$IMAGE_TAG > /dev/null ; echo $?
    

    で存在確認が可能