様々な種類のCode scanningアラートと、それぞれのアラートが示す問題の理解に役立つ情報について学んでください。 Code scanning は、GitHub.com のすべてのパブリック リポジトリに使用できます。 Organization によって所有されるプライベート リポジトリで code scanning を使うには、GitHub Advanced Security のライセンスが必要です。 詳しくは、「GitHub Advanced Security について」を参照してください。 code scanning からのアラートについて code scanning を構成して、既定の CodeQL 解析、サードパーティーの解析、または複数の種類の解析を使ってリポジトリのコードをチェックできます。 解析が完了すると、解析によるアラートがリポジトリのセキュリティビューに隣り合わ

アイミツ開発チームでエンジニアリングをしている deliku です！ 直近で Larastan と reviewdog の導入をしたことをブログに書きましたが、 コーディング規約チェックも同様の仕組みを利用して、開発フローに組み込んでいきます。 コーディング規約プログラミング品質を均質にするために定めるルールのことです。 チームで開発をするうえで、個々に好きな書き方をしてしまうと保守性や可読性の低下につながり、不具合が発生する要因になります。 PSR（PHP Standard Recommendation）PSRは、PHP-FIGが策定しているPHPコーディング規約です。 Laravel は、PSR-2 / PSR-4に準拠しているようです。現状PSR-2は非推奨なので、私たちの開発チームでは、PSR-2の拡張版のPSR-12を採用することにしています。 Laravel follows t

こんにちは。Eight でフロントエンドエンジニアをしている鳥山（@pvcresin）です。 ついこの間新卒で入ったと思ったら、もう 2 年目に突入していました。時が経つのは早いものです。 今回は Eight の Web フロントエンドで使っているスタイルのリンター（コードの静的解析ツール）を SCSS-Lint から stylelint に移行した話をしたいと思います。 SCSS-Lint Eight のフロントエンドではスタイリングに Sass（SCSS 記法）を使用しています。 そして、そのリンターとして SCSS-Lint を採用していました。 それをコードレビュー自動化ツールの Sider（旧 SideCI）と組み合わることで、PR（プルリクエスト）上で SCSS ファイルをチェックするように設定していました。 これによりスタイル定義の品質を担保していました。 SCSS-Lint

【4つのステップ】PHP 8.xへの移行方法─Juliette Reinders Folmer氏にインタビュー WordPressサイト、プラグイン、テーマを鑑みたPHPのバージョンアップは、終わりのない作業です。定期的に繰り返していく必要があります。この作業を効率的に行うにはどうしたらいいのでしょうか。見落としがないようにするにはどうしたらいいのでしょう。おすすめのプロセスとは。 今回の記事では、これらの疑問（とそれ以上）に答えながら、ロードマップを含め、WordPressサイト、プラグイン、またはテーマのPHP 8.xへのスムーズな移行に必要な要素を見ていきます。 今回は、PHPのエキスパートであるJuliette Reinders Folmer氏へのインタビューに基づき、その内容をご紹介します。彼女は日常生活のほとんどをプログラミングとその関連分野に捧げ、主にWordPressを含む

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

こんにちは。Tably よういちろう（@yoichiro）です。 皆さんは普段GitHubをお使いでしょうか？お使いの方は、GitHub Actionsを使ってCI/CDしていますでしょうか？ GitHub Actionsを使うことで、Pull Requestの作成や更新、あるブランチへのマージといったタイミングで、コードのフォーマットを整えたり、テストを走らせたり、本番環境にデプロイしたり、一連の作業が終わったことをチャットに通知したり・・・といったことを自動的に行うことができます。GitHubにはGitHub Marketplaceというアクションが公開されているマーケットプレースがあります。やりたいことがあった時に、一般的なものであればそこで見つけることができるでしょう。 ものすごい数のアクションがMarketplaceにて公開されていますが、たまたま僕が行いたかった動作をしてくれる

Below is a listing of all currently available WP-CLI commands with links to documentation on usage and subcommands. Looking to learn more about the internal API of WP-CLI or to contribute to its development? Check out the WP-CLI team’s handbook and the WP-CLI Blog. Commands CommandDescription

Official WordPress developer resources including a code reference, handbooks (for APIs, plugin and theme development, block editor), and more.

【重要なお知らせ】サービス統合に基づくサービス名称の読み替えのお願い（2024年4月1日） 2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。 当サイトのアドレス（ドメイン名）に含まれる「nifcloud.com」は現時点では変更はございませんが、各ページに記載の「ニフクラ」「NIFCLOUD」「nifcloud」は、「FJcloud-V」に読み替えていただきますようお願いいたします。 【重要なお知らせ】サービス統合に基づくサービス名称の読み替えのお願い（2024年4月1日） 2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。 当サイトのアドレス（ドメイン名）に含まれる「nifcloud.com」は現時点では変更はございませんが、各ページに記載の「ニフクラ」「NIFCLOUD」「nifcloud」は

目的 手を動かしながら、ブロック開発の流れを理解する。ブロック開発の用語を知る。 本記事をもとに社内勉強会を行いました。その際の動画アーカイブもご参考ください。 開発環境 DockerNodeJS（NPM） ブロックを作っていく 例として、アラートブロックを作っていきます。 画像のように、サイドバーからブロックの背景色を切り替えることができます。 ボイラープレートを作成 下のコマンドで、ブロックの雛形ができます。

ほぼほぼ全て必要なフィールドに対応しています。頼もしすぎる。 それ以外では以下のフィールドに対応しているようです。 Contact Form 7 Limiter Location Map PayPal Item WP WYSIWYG (WP標準のWYSIWYGですね) Gravity Forms これらのフィールドに対し、予め作成されたCSV、XMLから一括インポートが行えます。その他無償のアドオンが様々提供されていて、国内で有名なもので挙げると「Yoast SEO」「WPML」などのインポートも対応しているようです。 WP All Importの使い方を知りたい WP All Importはウィザード形式で進めることができ、難しい処理は不要でインポートを実施することができます。また嬉しいことに日本語対応している（そして所々機械翻訳を利用しているようで、壊れている）ので、読み進めるのも簡単

＊問題が出る場合があったので若干の修正をしています。 WPでデータ数百件を一気に登録したい！ ということで、CSVでの登録ができるプラグインをGoogle検索したところ、「Really Simple CSV Importer」が今の定番らしくよく使われているらしい。 その他のものも試したが、帯に短し襷に長しという感じでいまいちフィットしない。 Really Simple CSV Importer（以下RSCIと記述）は、なによりシンプルで軽量かつフィルターフックでカスタマイズも結構できそうなので、「Really Simple CSV Importer」を使うえるかテストを開始。 Advanced Custom Fieldの繰り返し（リピート）フィールドに対応したい！(しかも画像フィールド) RSCIは、Simple Custom FieldやCustom Field Suiteには対応して

WordPress の PHPUnit テストスイートには、何千もの自動テストが含まれています。自動テストは、WP の機能の特定の部分を検証する小さなコードです。これらのテストは、機能開発やリグレッションを防止するための強力なツールです。 自動テストは、できるだけ小さく、具体的なものにする必要があります。理想的には、自動テストはユニットテストであるべきです。システム全体の状態に依存することなく、機能の一部を完全に分離して検証するテストです。実際には、WordPress とそのテストスイートの構造上、「純粋な」ユニットテストを書くことは難しいか、不可能です。ここでも他の場所でも、スイート内の自動テストを大まかに指すために「ユニットテスト」という用語を使用します。 あらゆるテストで最も重要なものはアサーションです。アサーションとは、システムから得られる期待値と、実際に得られた値との比較です。最

はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「