OmniAICreator/Qiita-1.07M huggingface dataset:
Microsoft 365 Business Basic をお試し

一般法人向け Microsoft 365 は個人契約できて 1 ライセンスから購入可能らしいと聞いて、夜中のノリで契約してみました。必要なのはクレジットカード、個人なので会社名の代わりに自分の名前、契約用メールアドレス、住所と電話番号くらいです。

# Microsoft 365 Business Basic を個人で契約

1 人ユーザーで一般法人向け Microsoft 365 を契約しました。好みのサブドメインもつけて、個人の環境ってなんだか最高。可愛がろうと思います。

Planner は覚え書き (今後作成したいエージェントのチェックリストとか…) に使ったり、SharePoint も自動化ツールの Power Automate や Power Apps も使いたくなるよね…ということで、Microsoft 365 家庭用ではなく、金額的にも一番お手頃な **[Microsoft 365 Business Basic](https://www.microsoft.com/ja-jp/microsoft-365/business/microsoft-365-business-basic?msockid=161007592b3e6f6206c212be2a426e7e&activetab=pivot:%E6%A6%82%E8%A6%81tab)** (Teams 無し[^1]) にしました。

*([Microsoft 365 Business のプランと価格の比較](https://www.microsoft.com/ja-jp/microsoft-365/business/compare-all-microsoft-365-business-products-no-teams)) 公式サイト参考*

[^1]: 今はユーザー 1 人なので。。

# Microsoft 365 Business Basic で使えるアプリ

早速ログインして、実際使えるアプリを確認していきます。

初回ログイン後表示されるアプリ:

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4080582/980ba0b0-2e78-48b6-9174-6d32904f5432.png)

- Viva Engage までついてるっっ
- もちろん Power Platform も一通り
- Planner や Forms など複数人作業における業務改善に簡単に貢献できるツール有
- Word、Excel、PowerPoint、Outlook はウェブ版とモバイル アプリ版のみ使用可能
- Microsoft 365 Copilot Chat が使える ([エンタープライズ データ保護](https://learn.microsoft.com/ja-jp/copilot/microsoft-365/enterprise-data-protection)がありがたい:pray:)
- Exchange サーバーもついているので、組織のメール管理もできちゃいますね

# Microsoft 365 Business Basic で付与されるストレージ

気になる実際使える容量を、それぞれ設定画面から確認してみました。

### OneDrive for Business

> OneDrive 容量は、*ユーザー 1 人につき 1 TB* が付与

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4080582/94c2baaf-43c9-4927-b02f-7ccf01610a29.png)
(実際の表示)

### SharePoint

> *SharePoint の容量は、1TB + (10GB x ユーザー数)* が付与 ([プラン別制限](https://learn.microsoft.com/ja-jp/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits#limits-by-plan)参考)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4080582/3c1a173d-8d44-4f7e-b193-22d827096e24.png)
(実際の表示)

### Exchange のメールボックス

> メールボックスは、*ユーザー 1 人につき 50GB* が付与

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4080582/a5e81d43-68c0-4f68-ba4c-a32c594934aa.png)
(実際の表示)

# Microsoft 365 Business Basic がお得に感じる

これだけ使えて Microsoft 365 Personal よりお値段抑えられているのはすばらしい:raised_hands:

中小規模の会社で大半がライト ユーザーであれば、Business Basic から始めて規模、活用度や必要性など会社の成長具合に応じてアップグレードしていくのアリなのでは。メールボックスが主なレンタル サーバー契約するよりも、オフィスがついて共同作業ができて、自動化ツールもデータ保護された AI チャットも使えるのはコスパ良くないですか？！
プログラミング工程は設計か否か

# 導入
プログラミング工程を「製造」と呼ぶ現場が多々あります。わたしはこの「製造」という呼び方が大嫌いです。なぜなら、プログラミング工程は「設計工程」であり、「製造工程」ではないからです。プログラムを書くのは「制作」であって「製作」ではないからです。

# そもそも「製作」と「制作」って何が違うの？

製作　・・・　機械や道具を使用して有形物を生産する際に使われる。
制作　・・・　芸術作品や映像コンテンツなど、アイデアや表現力を必要とする創作活動を指す。

もっと端的に言えば、作る人の創造力やアイデアを必要とするかしないのか、による違いです。

# プログラミング工程が設計である理由（その１）

工程という側面からみてみます。これは昔からあるウォーターフォールモデルですが、ソフトウェア開発はおおよそ以下のような工程を踏みます。

・設計（基本設計・詳細設計）
・プログラミング
・テスト
・運用開始

ソフトウェア開発においては、テスト工程はプログラミング工程の後にあります。また、ソフトウェア開発における「製造」とは「ビルド」の事を指します。これは現代においては完全に自動化されており人手を介することはありません。人間は IDE で「ビルド」ボタンを押すだけで、製造物(EXEファイル)が自動的に出来上がります。つまり「ビルド」（＝「製造」）には人間の創造力が必要とされることはありません。

これを踏まえて他業界で行っている「製造工程」を見てみましょう。
例えば飛行機や、ビルとか橋などのようなものです。

・設計（図面を書く）
・テスト（プロトタイプを製作してテストする）
・製造（大量生産）
・運用開始

いわゆる製造においては、製造工程の「前」にテスト工程があります。
設計においては法律で基準が定められている場合があり、これを遵守しなければなりません。さらに設計後にテスト（試験）をして設計通りになっているか安全性などを確認します。これに合格しなければ製造はできません。

また、製造におけるテストは昨今ではコンピュータシミュレーションで行うのが当たり前になっています。プロトタイプを製造するコストがかかって大変なのとテストも大変だからです。ビルの耐震テストでは実際にビルを建て地震を起こすわけにもいきません。橋の風洞テストにおいても実際に橋を建設して台風の暴風にさらすなどできません。飛行機は実際に本物サイズのプロトタイプを試作して、何十時間も飛行テストをするらしいです。

ここでソフトウェア開発に話を戻しますがプログラミング工程はテスト工程の「前」になっています。なぜでしょうか？　答えは「プログラミング工程は製造ではない」からです。換言すれば、プログラミングは設計工程であるからです。

# プログラミング工程が設計である理由（その２）
プログラミング工程が「製造」であるならば、作業者（プログラマー）の創造力やアイデアなどが入り込む余地などありません。プログラマーは設計書通りにプログラムを書くことが要求されます。変数名、関数名やモジュール名をプログラマーが自分で考えるなど許されません。コードの書き方さえも自由にはできません。必ず設計書の通りに作ることが求められます。

果たして実際の現場ではどうなっているでしょうか？

ほとんどの現場ではネーミング規則などはあるにせよ、変数名などガチガチに決められていることは無いと思います。場合によっては日本語で書かれたプログラムコードのような設計書（プログラム仕様書）がある場合もありますが、日本語で書かれている以上どうしても曖昧さが残るため、細部についてはプログラマーが考える必要があります。

ちょっと待ってください。プログラミング工程を「製造」だと呼ぶのなら、プログラマーが勝手に考えた変数名などの命名方法に頼っていいのでしょうか？　製造であるなら個人の技量や考え方によって個体差が出てはなりません。それでは品質が担保できないじゃないですか？　本当にそれは「製造」と呼べるのですか？

つまりプログラムを書くという作業は、プログラマーの創造力や経験や知識、技量に左右されるわけです。「製造」は「工学」でなければならず、製作者個人によって品質にバラツキが出てはいけないのです。そんなものを「製造」と呼んではいけないのです。

# プログラミング工程が設計である理由（その３）

今も流行っているのか知りませんが、一時期は

プログラミングは製造なので他の人達に造らせよう。

という風潮がありました。いわゆる「オフショア」というやつです。主に海外の人件費が安い人達にプログラミング工程を発注して安いお金で造ってもらおう、というわけです。結果は散々なものでした。ほとんどのオフショアはまったくうまくいきませんでした。少なくともうまくいってるなんて話は聞くことはありませんでした。

なぜでしょうか？

プログラミング工程は自然言語で書いた仕様書の記載内容だけでは作れないからです。プログラマーが創造力を働かせなければ製作できないからです。だから失敗したのです。

# では、なぜプログラミング工程を「製造」と呼ぶのか

それはお金がからんできます。まず一般的に設計者と製造者（あえて製造とします）には、単価に差があるからです。

設計者（システムエンジニア）・・・単価が高い
プログラマー・・・単価が安い

つまり、なるべくお金を出してくないからです。プログラマーであっても設計者と同様に設計を行っているにもかかわらず、単価を安くしているのです。安い単価の人間に、単価以上の仕事をさせてこき使ってやろうという人達がいるからです。

# まとめ

このように、プログラミングは立派な「設計」であり「製造」ではないのは明らかです。よって、プログラミング工程を製造と呼ぶべきではありません。プログラマーには創造力や技術力が必要であり、設計書に書かれたことを単にやるだけの「ロボット」ではありません。
プログラマーがAIに駆逐されることは当分ないでしょう。何度も言いますがプログラマーには人間としての創造力が求められるからです。現状の「AI（もどき）」に出来る作業ではありません。もし、自我を持った AI が誕生し創造力を発揮するとしたらプログラマーは職を失うことでしょう。いえ、そうなればプログラマーだけでなくすべての職業の人達が失業することになるでしょう。
工学系の論文の書き方

# はじめに
工学系の実験系研究者のKumaです。
IEEE Xploreによると、共著含めて64本の論文を書いてきたそうです。
いろんな人に論文の書き方の指導や添削をすることが増えてきました。
そこで、よく教えているノウハウをまとめておこうと思います。

# この記事は「何ではないか」
- 一般論ではありません。工学系以外の分野では文化が違いますし、工学でも他分野では文化が違うかもしれません。
- 実験系の論文を想定して書きます（理論系でも、一部は参考になると期待します）。
- 「いかにしてアクセプトしてもらうか」にやや偏っています。
# 論文とは何のために書くか

論文とは何をするためのものでしょうか。
**成果をアピールするためでも、自分の研究のプロセスを事細かにメモ書きするためのものでもありません。**
論文とは、**「誰かに読んでもらうためのもの」** だと思います。
そのうえで「読んだ人が内容を最短で理解でき、かつ次につながるようなもの」だと思います。

# 論文とは、いつ書くか
結果が出たとき、あるいは**出そうなとき**に、執筆を考え始めます。
論文化を意識することで、「あと何をしなければいけないか」が明確になります。
また、結果とプロセスを読みやすい形にまとめておくことで、**「自分の研究のセーブポイント」** としての副次的な価値もあります。

# わかりやすい論文を書くには？
論文は、**「誰かに読んでもらうためのもの」** です。
したがって、まず想定読者を考えます。
論文を読むのは、「（その分野の専門とは限らない）査読者」「（その分野の専門とは限らない）一般の読者」です。
したがって、何をおいても可読性を重視すべきです。

# 読んでもらうためには？
以下に、**(原則）絶対にやってはいけないことを書きます。**

なお、言うまでもないこととして、論文のテンプレート（様式）を違反するものは論文とみなされません。

## 文章の構成に関するNG事項
- **必然性のない文章が存在する。**
    - 必然性のないものは、即ち要りません。
- タイトルが長い。簡潔でない。
    - タイトルで中身が推測できないものは読みません。
- 論理が一本道(A⇒B⇒C⇒D...)ではない。
    - 論理が枝分かれしていると、わかりづらく、特に予備知識のない専門外の人に読んでもらえません。
- イントロダクションの一行目が、その分野の専門家でないと理解できない内容になっている。
    - 予備知識のない専門外の人に読んでもらえません。
- 引用している先行研究が、本研究と直接的に関係がない。
    - 必然性のない先行研究の引用は要りません。
- In this paper や we propose が複数回登場する。
    - 本研究の新規性があいまいになります。
- 自身の過去の研究を知っていることを前提とする(In our previous work,...)。
    - **読者はあなたのことなど知りません。**　その場合でも伝わるよう、丁寧に書きましょう。
- 表記ゆれがある

## 図表に関するNG事項
- **図表だけを追っても、論文の骨子、論理構造がわからない。**
    - 図表だけでわかる論文＝よい論文　です。
- **図の大きさが小さい。目盛りが小さい。本文を読まないと図の伝えたいことがわからない。**
    - (原則)論外です。図中の文字サイズの最低ラインは、本文の文字サイズ(8-10 pt)だとよく言われます。
    - **数値の読み取れない図は図ではありません。絵です。**
    - 図に矢印や文字を書き入れて、メッセージを強調する手があります。
- 色がわかりにくい、マーカーがわかりにくい。
    - 色とマーカーにまでこだわるのが一流です。
    
## 参考文献に関するNG事項
- **必然性のない参考文献を挙げる。**
- 自身に有利な参考文献に限定する。
    - 成果アピール系の論文に多いですが、論文の目的を見誤っています。
- 古い参考文献ばかり挙げる。
    - ない場合は仕方ないですが、自身に有利な引用をしていると取られることがあります。
- 参考文献が極端に少ない。
    - この場合、ほとんどはリサーチ不足です。
- すでに報告されている論理、帰結、考察なのに、参考文献がない。
    - 参考文献がない＝オリジナルを主張する　というのが原則なので、避けるべきです。

## 逆に、推奨される（と思う）事項
- **わかりやすくするために、あらゆる手段・労力をいとわない。**
    - コンセプトをイラスト（図）にしたり、図に文字や矢印を入れるなど。
    - 箇条書きにする、表にするなど。 
- 実験条件やシミュレーション条件を細かく記載する。Metricの定義を細かく記載する。
    - 再現性の観点や、結果の読み取りの誤解を防ぐ観点で、推奨されます。

# まとめ
**論文とは、人に読んでもらうために書きます。**
**そして、読む人はとても忙しいかもしれません。**
最低限、常にこれさえ心がけておけば、読みやすい論文になり、結果として査読に通ることが増えます。
確かにすさまじい成果であれば、それが読みにくい論文でも世に評価されますが、そのような大論文を目指すのは非効率的だと思います。

Kumaでした。
初学者に教えること

# 初学者に教える前提知識

初学者に対してプログラムを教えるときにまず教えるのはブラインドタッチだ。
その後Ctrl+Z,Ctrl+shift+Z,delete,tabの使い方を教える。
最後にマインドとして実行しまりく、エラーを一つずつ消していく。

長年PCを触ったとこがある人なら当たり前のこれらのことができない、そもそも知らないのが初学者というものである。スタートラインに立つ方法を教えるのが遠回りに見えて近道である。
【AWS認定】全冠までの道のり。～経過報告～



こんにちは！AWS認定資格の全冠を目指して学習を続けている者です。今回は、これまでの取得状況と目指している理由を記事にしていきます。

##  現在の取得状況（2025年5月11日時点）

- **AWS Certified Cloud Practitioner**  
  取得日：2022年6月28日

- **AWS Certified Solutions Architect - Associate**  
  取得日：2024年7月7日

- **AWS Certified SysOps Administrator - Associate**  
  取得日：2024年8月15日

- **AWS Certified Data Engineer - Associate**  
  取得日：2024年9月1日

- **AWS Certified Developer - Associate**  
  取得日：2024年10月19日

- **AWS Certified Machine Learning - Specialty**  
  取得日：2025年4月27日

- **AWS Certified AI Practitioner**  
  取得日：2025年5月10日

**合計：7資格取得済み**

##  今後の取得予定資格

- **AWS Certified Machine Learning Engineer - Associate**
- **AWS Certified Security - Specialty**
- **AWS Certified Advanced Networking - Specialty**
- **AWS Certified DevOps Engineer - Professional**
- **AWS Certified Solutions Architect - Professional**

**残り：5資格**

##  これまでの道のり

![資格取得の進捗グラフ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4077172/2e49a23e-a3de-4e8c-abda-829978fed6d1.png)

2022年6月に「AWS Certified Cloud Practitioner」を取得してから、約1年半は資格取得から離れていました。

実務では物理サーバの設計構築をしていましたがインフルエンサーの方々に影響されて実務でAWS触りたい！となったのを記憶しています。

当時所属していた会社ではAWSの経験を得ることはできないと考え、転職するべく2024年7月から10月にかけて月1ペースで4つのアソシエイトレベル資格を取得しました。

その後、APNパートナー企業への転職を機に実務でAWSを扱うようになり、資格取得のモチベーションは正直下がっていました。

しかし、JAWS（Japan AWS User Group）に参加したり、LTを聞いてたりするとAWS認定全冠してる人多くね？もしかして全冠はデフォルトなのでは！？と思うようになり、ｴｯﾎｴｯﾎ早く全冠しなきゃっ！てなりましたw
(確かに全冠してる人は多いがデフォルトではなかったw)

また、AWSの勉強仲間とのつながりもでき、現在は資格取得へのモチベーションは絶賛高まっています。

##  今年の目標

- AWS認定全冠の達成
- LPIC Level 3の取得
- Qiitaに20記事を投稿



##  資格学習に対する考え方

資格学習は個人的に机上の学習のみで傾向と対策をしっかりして最短で取得するほうがいいと思って言います。

なぜなら、ハンズオンを行い理解を深めていくことは重要ですが、それなりに時間を費やすことになり、かえって効率が悪くなり、ハンズオンがうまくいかないなどの要因で資格学習のモチベが下がったり、だらけてしまうことになる可能性があるからです。(自分がそうだったw)

取りたい資格があるのならば、最短で取得して後からアウトプットするほうがいいんじゃないかなー


---

以上、現場からでした！
Vimの使い方　備忘録

# ウィンドウ
### 画面を分割する
横に分割
`:vs`
縦に分割
`:sp`
### 現在のウィンドウを閉じる
`Ctrl-w c`
### 他のウィンドウを閉じる
`Ctrl-w o`
### 新しいタブで開く
`:tabe filename`
ファイラーで、ファイルを選択して、`t`
# マクロ
### マクロの記録
aにマクロを記録する場合
`qa`→マクロの記録→`q`
### マクロの実行
aのマクロを実行する場合
`@q`
10回実行する場合
`10@a`
### マクロの閲覧
aのマクロを閲覧
`:reg a`
### マクロの削除
aのマクロを削除する場合
`qaq`
# 履歴
### コマンド履歴
`q:`
### 検索履歴
`q/`
# ターミナルモード
### ターミナルモードに入る
`:term`
### ターミナルモードから抜ける
`exit`
### ターミナルノーマルモードに入る
`Ctrl-\ Ctrl-n`
### ターミナルノーマルモードからターミナルモード戻る
`i`
# その他
### クリップボード貼り付け
`"+gp`
### クリップボードにコピー
`"+y`
### クリップボードに切り取り
`"+x`
### 行頭に連番を作る
`Ctrl-v`で連番を作る行の先頭を選択する。
`Shift-i 1 Esc`
2行目の1にカーソルを移動する。
`Ctrl-v`で以下の行の行頭の1を選択する。
`g Ctrl-a`
### ヤンクして、`:`のコマンドラインにペーストする
`Ctrl-r "`
Chakra UI v3 でのテーマカスタマイズ方法（v2との違いも紹介）

はじめに

Chakra UI は使いやすさと洗練されたコンポーネントで人気の UI ライブラリですが、2024年末にリリースされた v3 ではテーマのカスタマイズ方法が大きく変更されました。

v2まで主に使われていた extendTheme は廃止され、新たに defineConfig と createSystem を使うスタイルに移行しています。

本記事では、v2 と v3 のカスタマイズ方法の違いを明確に示しながら、v3での実装方法を丁寧に解説します。

v2 のテーマカスタマイズ例

まずは、v2まででよく使われていたテーマカスタマイズ方法を紹介します。

```javascript
import { extendTheme } from "@chakra-ui/react";

const colors = {
  primary: "#95CC6A",
  secondary: "#8D4BBE",
};

export const theme = extendTheme({ colors });
```
これをインポートして以下のようにします。
```javascript
import { ChakraProvider } from "@chakra-ui/react";
import { ReactNode } from "react";
import { theme } from "@/config/theme";

interface AppProviderProps {
  children: ReactNode;
}

export const AppProvider = ({ children }: AppProviderProps) => {
  return <ChakraProvider theme={theme}>{children}</ChakraProvider>;
};
```
extendTheme を使って簡単にテーマを拡張・定義できました。

v3 の変更点と背景

v3では、テーマ定義が Design Token ベースに完全移行しました。
これに伴い、extendTheme は削除され、次のような構成に変わります：

defineConfig() でトークンベースのテーマを定義

createSystem() で Chakra UI のテーマシステムを生成

ChakraProvider に渡すプロパティは theme ではなく value

v3 のテーマカスタマイズ方法（実装例）
```javascript
import { createSystem, defaultConfig, defineConfig } from "@chakra-ui/react";

const config = defineConfig({
  theme: {
    tokens: {
      colors: {
        primary: {
          600: { value: "#95CC6A" },
        },
        secondary: {
          600: { value: "#8D4BBE" },
        },
      },
    },
  },
});

export const system = createSystem(defaultConfig, config);
```
```javascript
import { ChakraProvider } from "@chakra-ui/react";
import { ReactNode } from "react";
import { system } from "@/config/system";

interface AppProviderProps {
  children: ReactNode;
}

export const AppProvider = ({ children }: AppProviderProps) => {
  return <ChakraProvider value={system}>{children}</ChakraProvider>;
};
```

import { ChakraProvider } from "@chakra-ui/react";
import { ReactNode } from "react";
import { system } from "@/config/system";

interface AppProviderProps {
  children: ReactNode;
}

export const AppProvider = ({ children }: AppProviderProps) => {
  return <ChakraProvider value={system}>{children}</ChakraProvider>;
};
ポイント：

色などのカスタマイズは tokens 内に定義

カラーのバリエーション（例えば 600 番）を指定して階層化

createSystem で生成した system を ChakraProvider に渡す

まとめ

Chakra UI v3 では extendTheme が使えなくなった

新しい方法では defineConfig + createSystem によるトークンベースの設計が中心

Theme に関する構造は一見複雑だが、柔軟性と拡張性が向上している

v2までの知識がある人ほど戸惑うかもしれませんが、設計思想を理解すればv3のスタイルは非常にパワフルです。

参考

Chakra UI v3 ドキュメント (公式)

Design Tokensについての基礎

気になる点や修正提案があれば、ぜひコメントで教えてください 🙌
AtCoder Easy Test 導入方法


# AtCoder Easy Testとは
AtCoderの問題ページで入出力例を使って素早くテストを実行できるユーザースクリプト。
実行すると入力例のサンプルを自動で試してくれて全て正解だと提出、間違えているとその出力結果を表示してくれる。
# 導入方法
## 1. TemperMonkeyをインストール
ブラウザでユーザースクリプトを実行する用のChrome拡張機能です。
なのでChromeで導入しましょう。

https://chromewebstore.google.com/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja

### ■ このサイトにアクセスして右上の青いボタンでChoromeに追加する
大学のアカウントだと開けない場合があるのでどの場合は他のアカウントで開くことをオススメします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/f2c3f6b7-3af9-4036-b716-7332e90dcc96.png)


### ■ 次にchromeブラウザの右上の三つの点のボタンから拡張機能を管理を開く

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/c73009c6-c2ed-4860-b347-b307b232e7ac.png)

### ■ そうしたら右上のデベロッパーモードをオンにする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/df4a8261-0c77-4178-9afe-7676adda2abe.png)

## 2. ユーザースクリプトをインストール
### ■ AtCoder Easy Test v2のサイトにアクセス
https://greasyfork.org/ja/scripts/433152-atcoder-easy-test-v2

スクリプトをインストールする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/8b50d289-34bd-4b68-a56d-e099c0cf82ca.png)

# 導入確認&実行方法
適当な問題を開いて提出欄にTEST&Submitがあれば導入完了。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/8d6493ad-71ca-4b41-890f-2a13f9d3afdf.png)

適当な問題

https://atcoder.jp/contests/abc405/tasks/abc405_a

コードをペーストしてからCtrl+EnterかTEST&Submitボタンを押せばサンプルのテストと正解ならば提出がされる。
不正解の場合は下にある^を押すと出力結果を見ることができる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806431/f288461f-f127-4cc8-b67f-a61fe465c671.png)

### (重要) 正解が複数通りある問題では出力例と完璧に一致する出力のみが正解とは限らないため、不正解となり提出されない場合がある。その時はそのまま提出ボタンを押そう。
LaravelやVueの開発環境構築について学ぶときのロードマップまとめ



LaravelやVueを使って開発を始めたいけど、  
「環境構築がよくわからないまま、コマンドをコピペしてなんとなく動かしている」  
そんな状態から卒業したい人向けに、**開発環境構築に必要な知識のステップ**を整理しました。

> ✅ LaravelやVue自体の書き方は対象外です。  
> ✅ あくまで**開発環境を作るために学ぶべき内容**に絞ってまとめています。

---

## ✅ 目的

LaravelやVueの開発環境を **「理解して」自分で構築できるようになること** をゴールにしています。

---

## 🔧 ステップ一覧（基礎から順に）

### 1. Homebrew（macOS用パッケージマネージャー）
- ソフトウェアをターミナルで簡単にインストールできる
```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install node
brew install --cask docker
```

---

### 2. PATH（パス）の設定
- ターミナルでコマンドを実行できるようにするための「通り道」
```bash
export PATH="/opt/homebrew/bin:$PATH"
```

---

### 3. Node.js / npm（JavaScriptの実行環境とパッケージ管理）
- VueやViteなどのライブラリを扱うために必要
```bash
node -v
npm -v
npm install
```

---

### 4. package.json（npmの設定ファイル）
- プロジェクトで使うライブラリやスクリプトを記述
```json
{
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  },
  "dependencies": {
    "vue": "^3.0.0"
  }
}
```

---

### 5. Vite / Webpack / Laravel Mix（アセットバンドラ）
- JS/CSSなどの資産をまとめて最適化
- LaravelではViteが主流（Laravel Mix＝Webpackのラッパー）

---

### 6. Gulp（必要なら）
- 古いプロジェクトやテンプレートで見かけることがある
- WebpackやViteと役割は似ているが用途が異なる

---

### 7. PHP / Composer（Laravel実行に必要）
```bash
php -v
composer -V
```

---

### 8. Laravelインストール方法
#### 方法1：Laravelインストーラーを使う
```bash
composer global require laravel/installer
laravel new プロジェクト名
```

#### 方法2：create-projectを使う
```bash
composer create-project laravel/laravel プロジェクト名
```

---

### 9. Docker（仮想開発環境の構築）
- PHP・MySQL・Nginxなどをコンテナで構築できる
- イメージ／コンテナの概念を理解する

---

### 10. docker-compose（複数コンテナの管理）
- `docker-compose.yml` で構成定義
```yaml
services:
  app:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - ./:/app
```

---

### 11. Laravel Sail（Laravel公式のDocker構成）
- Laravelに標準で含まれる簡易なDocker環境
```bash
./vendor/bin/sail up -d
./vendor/bin/sail artisan migrate
```

---

### 12. データベース接続（MySQLなど）
`.env` ファイルに接続情報を記述
```
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=
```

---

### 13. DockerのVolumeとファイル権限
- ホストOSとコンテナ間でファイル共有
- `storage/` や `bootstrap/cache/` の書き込み権限設定に注意

---

### 14. ホットリロード（Viteなど）
- 開発中の変更を即座にブラウザに反映
```bash
npm run dev
```

---

### 15. Gitと.gitignore
- プロジェクトに含めないファイルの指定
- `.gitignore` に以下を追加：
```
/node_modules
/vendor
.env
```

---

## 🎯 最終的にできるようになること

- Laravel + VueをDocker上で動かす開発環境を**自分の理解で構築できる**
- npmやDockerコマンドを**意味を理解して使える**
- `.env` や Vite、Docker Compose などの設定を**自力で読める／書ける**

---

## 📌 おすすめの学習順

1. Homebrew  
2. Node.js / npm  
3. PHP / Composer  
4. Laravelインストール（まずはローカルで）  
5. Docker & docker-compose  
6. Laravel Sailまたは独自Docker構築  
7. ViteやWebpackの構成理解  
8. `.env` やDB接続の理解  
9. Git・コード整形ツール（任意）

---

## 💬 最後に

このステップを1つずつ丁寧に学べば、  
「コピペで動かしていた開発環境」が、「理解して自分で再現できる環境」に変わっていきます。

Laravel × Vue の開発を本気でやっていきたい人は、ぜひこのマップを参考にしてみてください！

---
PostgreSQL で SELECT 結果を JSON 形式で出力

PostgreSQL の psql コマンドで select した結果を JSON 形式で出力する方法のメモ。


# row_to_json() による JSON 形式での出力

-t オプションで select の出力結果にカラム名や区切り線が含まれなくなる。
また、-A オプションで不要な空白を抑止することができる。
```bash:
$ psql -t -A -d db_test
```

row_to_json(テーブル名) でテーブルの全フィールドを出力することができる。
```sql:
db_test=# select row_to_json(test1_author) from test1_author;
{"id":8,"name":"book1_author","target_id":8,"target_type_id":8}
{"id":9,"name":"book2_author","target_id":9,"target_type_id":8}
{"id":10,"name":"article1_author","target_id":7,"target_type_id":7}
{"id":11,"name":"article2_author","target_id":8,"target_type_id":7}
```

row_to_json(row(...)) でフィールドの値を加工して出力することができる。
ただし、フィールド名が f1, f2, ... となる。
```sql:
db_test=# select row_to_json(row(id, concat('[', name, ']'))) from test1_author;

{"f1":8,"f2":"[book1_author]"}
{"f1":9,"f2":"[book2_author]"}
{"f1":10,"f2":"[article1_author]"}
{"f1":11,"f2":"[article2_author]"}
```
【初心者向け】シェルとは何か？bash・zshの違いと使い分け

開発の現場でよく聞く「シェル」「bash」「zsh」って結局何？という方へ向けて、  
シェルの基本と使い分け、違いをわかりやすくまとめました。

---

## ✅ シェル（Shell）とは？

### ▶ 人間とコンピュータの「通訳」

シェルとは、**ユーザーが打ち込んだコマンドをOSに伝えて実行する**「仲介役」です。

- 私たち：`ls` や `npm run dev` と打つ
- シェル：それを解釈してOSに「これやって」と伝える

つまり、**シェルがあるからコマンドでコンピュータを操作できる**というわけです。

---

## ✅ 代表的なシェルの種類と特徴

| シェル名 | 特徴 |
|----------|------|
| **sh** | 最も基本的で古いシェル |
| **bash** | 定番。多くの環境で使われている（Bourne Again Shell） |
| **zsh** | 補完や見た目が強化されていて人気。macOSの標準シェル |
| **fish** | モダンで直感的。設定なしでも高機能 |

---

## ✅ bashとは？

- 「Bourne Again Shell」の略。
- LinuxやWSL、Docker環境などでよく使われる**最も一般的なシェル**です。
- `.bashrc`, `.bash_profile` などで設定します。

---

## ✅ zshとは？

- bashをベースに、補完・色表示・テーマなどを強化したシェル。
- macOS Catalina（2019年）以降、**macの標準シェル**はzshになりました。
- 設定は `.zshrc` に書きます。
- `Oh My Zsh` という拡張パッケージでさらに便利になります。

---

## ✅ シェルによって何が違うの？

| 項目 | bash | zsh |
|------|------|-----|
| 補完機能 | 普通 | 超強力（候補が見やすい） |
| 設定ファイル | `~/.bashrc` など | `~/.zshrc` |
| 配列のインデックス | 0から始まる | 1から始まる（注意！） |
| 見た目のカスタマイズ | 少なめ | 豊富・テーマも多数 |

---

## ✅ Dockerでよく見る「bashで入る」ってなに？

```bash
docker compose exec app bash
```

- これは「コンテナ内でbashシェルを起動して入る」という意味です。
- zshが入っていないコンテナが多いため、**bashがデフォルトで使われています**。

---

## ✅ zshが入っていないときは？

軽量なLinux（例：Alpine Linux）や公式Dockerイメージでは `zsh` が入っていないこともあります。

その場合は代わりに `sh` や `bash` を使いましょう：

```bash
docker compose exec app sh
```

---

## ✅ どれを使えばいいの？

| 状況 | おすすめのシェル |
|------|------------------|
| Docker・サーバー環境 | **bash**（互換性重視） |
| macや普段の開発 | **zsh**（補完が便利） |
| 初心者で迷ったら | **zsh + Oh My Zsh** で快適に学べます |

---

## 📝 まとめ

- **シェル = OSとやりとりするための通訳**
- **bash = 標準的なシェル**
- **zsh = 開発が快適になる高機能シェル**
- **シェルを変えると補完・設定方法・スクリプト構文が微妙に違う**
- Dockerでは主に `bash` が使われる

---

どのシェルでも「やりたいこと」はだいたい同じですが、**快適さや書き方が変わる**ので、自分に合ったシェルを選ぶと開発効率がグッと上がります！
データ構造を基本からまとめてみた【基礎】

## データ構造とは？
- データ構造 : 素材であるデータをどのように扱うか  ゴロだしのデータを扱うのは非効率<br>⇨　用途に応じてデータの格納方法を工夫

## アルゴリズムとデータ構造の違い
- アルゴリズム ⇨ 作業手順
- データ構造 ⇨ データ(素材をどう扱うか？)

## データ構造の基本

- キュー : 古い方からデータを処理し、新しい情報は末尾へ追加
- 構造体 : １つのデータに情報を付加

## データとは何か？
- 素材であるデータを扱いやすくした仕組み ⇨ データ構造を考える前段階
- データ : 0と1の電気信号のこと　CPの中にはメモリIC(集積回路)が何千個もあり、データはその中に保存される
- メモリIC :　A0〜A9のピンでデータを保存　電気のON/OFFで、２進数の0と1を表す 
- メモリIC = ビルディング
- ビルディングにデータを保存

| ビルディングにデータを保存 |
|:---:|
| 1バイトのデータ |
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ |
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ | 
| 1バイトのデータ | 

```
char chr = 'A',
```
```
int apple = 10;
```
## データ構造とポインタの関係
- データ構造はポインタの技術を元に成り立っている
- ビルディングにデータを保存
- 連結リストとポインタ ⇨ データ構造の中で最も基本かつ、ポインタとの関係を理解する上で重要！

## 配列・連結リストについて
- 配列 : 同じデータ型の要素が大量に並ぶ ⇨ 要素へ瞬時にアクセスできる　番号を指定すればデータを瞬時に得ることができる
- 配列のデメリット : ①メモリ上の連続したスロットを使用　②要素の追加・削除が面倒
- 連結リスト : データとポインタ　2つでセット
- 連結リストのデメリット : 1個1個要素を辿るので探索に時間がかかる
- 連結リストのメリット : 追加・削除などの変更に柔軟に対応できる

|  |メリット|デメリット|
|:---:|:---:|:---:|
| 配列 |要素へ瞬時にアクセスできる|追加・削除が面倒|
| 連結リスト |追加・削除などの変更に柔軟に対応 |探索に時間がかかる|

配列は最も基本的なデータ構造 ⇨ メモリの物理的な形そのものだから　ビルディングの形がそのまま配列のデータ構造と同じ


## 参考サイト
[【1/4】データ構造の基本を学ぼう！(なぜデータ構造は必要か？)](https://www.youtube.com/watch?v=b3MlnokCX-E)
[【2/4】データ構造の基本を学ぼう！(メモリICとビルディング)](https://www.youtube.com/watch?v=N-MU5wWzwgg)
[【3/4】データ構造の基本を学ぼう！(データ構造とポインタ)](https://www.youtube.com/watch?v=Z5T8BLZBKA4)
[【4/4】データ構造の基本を学ぼう！(配列と連結リスト)](https://www.youtube.com/watch?v=RBd0vEO6j2M)
【初心者向け】PATH（パス）とは？通ってないときの対処法と、通さず実行する方法

開発中に「パスが通ってない」や「PATHを通す必要がある」と言われることはありませんか？

この記事では、

- PATHとは何か
- なぜパスを通さないといけないのか
- パスが通っていなくても実行できる方法

などを**初心者向けに丁寧に**解説します。

---

## ✅ PATH（パス）とは？

### ▶ PATHとは？

PATHとは、ターミナルでコマンドを打ったときに、**どこのフォルダを探せばそのコマンドが見つかるか**を定義した「環境変数」です。

```bash
echo $PATH
```

出力例：

```
/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
```

これは、コマンドが `/opt/homebrew/bin` などのフォルダ内にあるかどうか、上から順に探しているということです。

---

## ✅ PATHが通っているとできること

例えば、Node.jsをインストールしたときに `node` や `npm` というコマンドがPATHに通っていれば、

```bash
node -v
npm -v
```

のように、**コマンド名だけで実行できます。**

---

## ❌ PATHが通っていないとどうなる？

もしPATHが通っていなければ、次のようなエラーになります：

```bash
npm: command not found
```

これは、「npmという名前の実行ファイルが、PATHで指定されたフォルダの中に見つからなかった」という意味です。

---

## ✅ パスが通っていない状態で実行する方法

### ▶ 結論：**フルパスで指定すれば実行できる！**

たとえば、npmが次の場所にインストールされているとします：

```
/Users/yourname/.npm-global/bin/npm
```

その場合、こうやって実行できます：

```bash
/Users/yourname/.npm-global/bin/npm -v
```

`PATH`が通っていなくても、**フルパスで実行ファイルの場所を直接指定すれば問題なく動作**します。

---

## ✅ PATHを通す方法

毎回フルパスを打つのは面倒なので、よく使うならPATHを通しましょう。

### 例：`~/.npm-global/bin` にパスを通す場合

```bash
# .zshrcや.bashrcに以下を追記
export PATH="$HOME/.npm-global/bin:$PATH"
```

そして設定を反映：

```bash
source ~/.zshrc
# または
source ~/.bashrc
```

---

## ✅ 確認方法まとめ

| 内容 | コマンド |
|------|----------|
| 現在のPATHを確認 | `echo $PATH` |
| npmの場所を確認 | `which npm`（通っていれば出る） |
| フルパスで実行 | `/Users/xxx/bin/npm` など |
| パスが通ってるか確認 | `npm -v` などで確認 |

---

## 📝 まとめ

| 項目 | 内容 |
|------|------|
| PATHとは？ | コマンドを探すフォルダの一覧（環境変数） |
| パスが通ってないと？ | `command not found` になる |
| 通さなくても実行できる？ | ✅ フルパスで直接指定すればOK |
| 通すには？ | `.zshrc` や `.bashrc` に `export PATH=...` を追記 |

---

## ✅ おまけ：npmやnodeが使えないときの確認チェックリスト

- `node -v` でバージョンが出るか？
- `which npm` で場所が表示されるか？
- `echo $PATH` にそのディレクトリが含まれているか？

---

少しでも「パスって何？」「パスを通すってどういう意味？」というモヤモヤが晴れたら嬉しいです！

ご意見・質問があればコメントください 🙌
Linucレベル１勉強メモ　＃３１

＃ 第三章　GNUとUnixのコマンド

練習問題3.6
findコマンドの実行結果とエラー出力を、いずれも　find.logファイルに保存しようとしています。実行しべき適切なコマンドを選択してください。

A. find / -name core > find.log

B. find / -name core 2 > find.log

C. find / -name core 2>&1 | find.log

D. find / -name core > find.log 2>&1

E. find / -name core 2>&1 find.log

（解答）D

（解説）
選択肢Aは、findコマンドの実行結果のみがfind.logに保存され、エラー出力は保存されないので不正解です。選択肢Bは、findコマンドのエラー出力のみをfind.logに追記するのおで不正解です。選択肢Cは、パイプの直後にあるfind.logがコマンドと認識されてしまうので不正解です。選択肢Eは、findコマンドのエラー出力が、標準出力の出力先である端末画面に出力されます。また、find.logはコマンドと認識されるため、不正解です。従って、正解は選択肢Dです。

標準入出力
Linuxでは、通常のファイルと同等に、ディスプレイへの出力やキーボードからの入力もファイルの読み込みも同等に扱い、ディスプレイへの出力もファイルへの書き出しも同等に扱います。このようなデータの入出力に伴うデータの流れのことをストリームと呼びます。Linuxではデータをストリームとして扱うため、３つの基本的なインターフェースが定められています。標準入力はプログラムへの入力ストリームであり、デフォルトはキーボードです。標準出力はプログラムからの出力ストリームであり、デフォルトは画面（端末）です。標準エラー出力はプログラムの正常動作とは関係のないエラーメッセージなどの出力ストリームであり、デフォルトは画面（端末）です。これらの標準入出力を自在に切り替えることにより、同一のプログラムにさまざまな動作を期待することができます。

標準入出力
０　標準入力　キーボード
１　標準出力　画面（端末）
２　標準エラー出力　画面（端末）
【備忘録】Djangoの定期実行で２回呼ばれてしまう修正


# はじめに

こんにちは、エンジニアのkeitaMaxです。python初心者がDajngoを使ってみようと思って色々試しています。

今回はDjangoを使用している時に定期実行を作成していたのですが、なぜか２回実行されてしまうという問題にあたったのでそれの解決した時のことを備忘録として書こうと思います。

誤っていることを書いていたらコメントしてくれると嬉しいです。

# やっていたこと

`apscheduler`を使用して定期的に実行をしようとしていました。

```python:apps.py
import os
from django.apps import AppConfig

class AppConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'app'

    def ready(self):
        from .management.commands.example import start
        start()

```
apps.pyを上記のようにして、example.pyは以下のように５秒ごとに"Hello World!"を出すようにしていました。

```python:example.py
def test():
    logger.info("Hello World!")

def start():
    scheduler = BackgroundScheduler()
    scheduler.add_job(test, 'interval', seconds=5)
    scheduler.start()

```

これを`docker-compose.yml`で
```yml

  backend:
    container_name: backend
    build:
      context: ./docker
      dockerfile: Dockerfile
    command: python3 manage.py runserver 0.0.0.0:8000
```

こんな感じで起動していました。

# 原因

どうやら`runserver` はソースコードの変更を検知して自動リロードするため、実際にはプロセスが2回起動されてしまうらしいです。

1. 最初のプロセスはコード監視専用の親プロセス
2. その後、実際にアプリを動かす子プロセスが起動

そして、ready() はこの両方で呼び出されるため、start() が2回実行されてしまっているらしです。

# 解決策

apps.pyのready() を 子プロセスだけ実行するように以下のように修正しました。

```python:apps.py
import os
from django.apps import AppConfig

class AppConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'app'

    def ready(self):
        if os.environ.get('RUN_MAIN') == 'true':  # 子プロセスだけ実行するように修正
            from .management.commands.scrape import start
            start()

```

これで２回実行されることは無くなりました。


# おわりに


この記事での質問や、間違っている、もっといい方法があるといったご意見などありましたらご指摘していただけると幸いです。

最後まで読んでいただきありがとうございました！

# 参考

https://apscheduler.readthedocs.io/en/3.x/userguide.html
脳神経イメージングソフトウェアについて

ニューロイメージングソフトウェア一覧を作ろうと試みた。

# List
## 3D Slicer
画像解析に携わったことがある人なら一度は触る多次元画像処理ソフトウェア。ハーバード発。テンソルイメージングデータも処理可能。
https://www.slicer.org/

## Analysis of Functional NeuroImage (AFNI)
主にMRIの脳機能解析を目的に開発されたソフトウェア。
https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/background_install/main_toc.html

## AnalyzeDirect
メイヨークリニックのBiomedical Imaging Resources (BIO)部門で開発されたソフトウェア。
脳機能解析だけでなく、いろんな解析が行える。有償。

## Bioimage Suite
イエール大発。デスクトップとWeb型が無償で利用できる。
使いこなすには、YouTube必聴。
https://bioimagesuiteweb.github.io/webapp/

## BrainMagix

いろいろなことができそうな機能満載。有償。一部、SPM処理結果を表示するViewerのみ無償。

## BESA (Brain Electrical Source Analysis)

BESA MRIというパッケージで脳機能解析ができそう。有償。
https://www.besa.de/home/downloads/besa-mri/

## Brain Image Analysis Kit

こちらもいろいろできそうですごい。ノートブックで可視化する方法がいい感じ。
https://brainiak.org/

## BrainVISA

こちらもいろいろできそう。非公開パッケージも気になる。
https://brainvisa.info/web/index.html

## Brain Voyager

有償。でもいろいろできそう。

## CamBA

fMRI用の解析ソフト。2009年に開発が終了している模様。
https://www.nitrc.org/projects/camba/

## Camino Open-source toolkit for diffusion MRI

DW画像の解析に特化したアプリケーション。
http://camino.cs.ucl.ac.uk/

## Caret(Computerized Anatomical Reconstruction Toolkit)

fMRIの可視化用ツールに良く用いられていたようだが、2009年に開発が終わってしまったのだろうか。webcaretもあったはず。
caretというワードで検索しても、Rの機械学習パッケージのcaretがヒットするが、同じものではないはず。

## Fiasco/FIAT

Toolkit for analysis of functional brain images。
開発は終了している模様。

## FMRIB Software Library (FSL)

必須ツール。これがないと処理を完結できない人が多いといってもいいのではないだろうか。
https://fsl.fmrib.ox.ac.uk/fsl/docs/

## FMRLAB

fMRIの解析に特化したMatlabツールボックスのひとつ。いろいろな脳機能解析ができそう。
https://sccn.ucsd.edu/fmrlab/

## FreeSurfer

脳機能解析をしている人は知らない人がいないくらい有名なソフトウェア。
Linux/MacOSのみ。
https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferWiki

## ISAS (Ictal-Interictal SPECT analysis by SPM)

経時的なSPECT画像を解析するためのSPMパッケージ。
http://spect.yale.edu/

## LIPSIA (Leipzig Image Processing and Statistical Inference Algorithm)

fMRI解析用ソフトウェア。
https://www.cbs.mpg.de/institute/software/lipsia

## LONI Pipeline

脳機能解析のパイプラインとなるワークフローを構築して処理を進められる。
https://pipeline.loni.usc.edu/

## MNI MINC

脳機能解析用パッケージ。
https://github.com/BIC-MNI/minc?tab=readme-ov-file

## MRIcro

画像の表示、3D-ROIの編集、線形位置合わせなどが行える。SPM用のanalyze形式データに変換なども可能
https://people.cas.sc.edu/rorden/mricro/mricro.html

## mrVista

DW画像解析など。スタンフォード発。
https://github.com/vistalab/vistasoft/tree/master

## Net Station

有償。（egi.com）

## NITRC

様々なツール群が公開されている。
https://www.nitrc.org/

## PyMVPA

fMRIで多変量パターン分析ができるパッケージ。
http://www.pymvpa.org/tutorial.html

## Shanoir

Shanoir-Next Generation。ニューロイメージングデータのデータベース化や検索を助けるツールのよう。
https://github.com/fli-iam/shanoir-ng

## Signed differencial mappings (SDM)

Seed base d mappings（Signed differencial mappings）は、fMRI、VBM、DTI、PET などの神経画像技術を用いて、脳の活動や構造の違いに関する研究をメタ分析するための統計的手法。これを処理してくれるツール。
https://www.nitrc.org/projects/sdm/

## Statistical parametric Mappings (SPM)

いろいろな脳機能解析ができるツール。
https://www.fil.ion.ucl.ac.uk/spm/

# おわり

単純に3D表示するだけのものや、体積を測るだけ、というソフトウェアはリストから除外したつもりだが、他にもいろいろなツールがあると思う。
（ImageJ系の脳解析ツールは人以外が対象になっているものも多いので載せていないが、たくさんある。）

コアな処理をしているものは列挙してみたが、どうだろう、抜けまくってたらすみません。

2025/05/11
GeminiのCanvas機能でWEBサイト作成してみた

# はじめに
2025年3月18日、Geminiに「Canvas」機能が追加されました。
個人的に興味があったので、Canvas機能を使ってWEBサイトを作成してみました。

# 作成するWEBサイト
今回はバスケットボールチームのWEBサイトを作成しました。
理由は以前から所属しているバスケットボールチームのサイトを作成したいと考えており、
最近複数のメンバーが転勤になり人数が減ったため、
メンバー募集も兼ねて、チームのWEBサイトを作成しようと思いました。

# 作成方法
作成方法は非常に簡単です。
以下の方法で作成しました。

#### ①WEBサイトに記載する情報を考える。
　以下の情報を考えました。(※固有名詞等は適当に考えました。)
>　1.チーム紹介
　　チーム名:ORCAS
　　活動拠点:肥後橋体育館 または 西梅田体育館
　　活動日時:土日
　　所属リーグ:大阪府社会人リーグ　3部
　2. メンバー紹介
　選手:背番号　名前　ポジション　身長　出身校
　　　　01　合田隼人　PG　177　甲南大学
　　　　12　山田康太　SF　180　大阪大学
　　　　16　太田靖　　C 　195　近畿大学
　　　　24　飯田成人　PG　172　京都大学
　　　　34　金田英二　SG　175　神戸大学
　　　　35　会田剛　　PF　184　神戸大学
　　　　55　豪博美　　C 　188　神奈川大学
　　　　60　栄伍大輔　SG　181　京都産業大学
　　　　72　煉獄剛志　PG　174　東京大学
　　　　80　永井葉梨　SF　178　UCLA
　　　　99　須田獏須　C 　199　北京大学   
　3. 試合結果・スケジュール
　　05/24　VS　MONGOL900　@大阪中央体育館　14:00～
　　06/07　VS　BIGAN　@轟アリーナ　14:00～
　　07/01　VS　GOD FATHER　@宝塚総合体育館　14:00～
　4. 入部案内
　　募集要項:大阪でバスケをしたい方、大歓迎!!
　5.部費、その他費用について
　　JBA登録料：3300円
　　ユニフォーム代：15000円

#### ②GeminiのCanvasモード①で考えた情報をもとにしたWEBサイトの作成を依頼する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/3e6cdc58-aecb-42bb-87ea-344464b65d63.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/a4579e14-d221-4f55-9481-78854de4f228.png)



作成方法は以上です。

# 成果物
数十秒ほど待機していると、完成しました。
以下のキャプチャが最初に作成されたWEBサイトのホーム部分です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/54bdcf12-4538-47b0-a521-80d1cea7137a.png)

私が入れてほしいと記載した情報がすべて記載されており、
デザインもさほど悪くないWEBサイトが作成されました。

ただ、背景の文字と被っている部分があったため、
修正してくださいと再度依頼しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/c5af7a1c-9ece-402d-a11b-395487606f9e.png)

文字が被らないように修正され、見やすくなりました。

今回は修正の依頼をGeminiに投げましたが、コードを自分で修正することもできるようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/f46fc298-303e-4b0b-ac52-2c8e4881ef98.png)

# 他の作成部分

#### チーム紹介
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/09240d62-dbc8-49ef-9641-26e4a013d10b.png)

#### メンバー
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/5b440eac-edd6-40c0-a319-4ef27e394486.png)

#### 試合情報
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/27d93abf-3cdc-429e-a893-3041b8118a55.png)

記載した情報では、試合予定しかありませんでしたが
過去の試合結果情報を入れてみてはどうかという提案がされていました。

#### 入部案内
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3836584/cca361f9-ac2b-4fd9-8d35-9e38e8bab854.png)

# 最後に
今回WEBサイトを作成してみて感じたことは、簡単に短時間で作成できしまう驚きと危機感でした。
上記のWEBサイトは、記載する情報を考える時間を含めて15分ほどで作成できました。
エンジニアが上記のWEBサイトと同様のHTMLファイルを作成しようと思っても、
10分ほどで作成はかなり厳しいと思います。
そのため、短時間でこのクオリティのものが作成できるのを目の当たりにして、
AIの進化がすごいなと思いました。
その驚きと同時にエンジニアがいらなくなる日ももうすぐ来るのではとも考えてしまい、
少し危機感を覚えました。
私も日々精進していこうと思います。
個人的備忘録：Elastic IPが割り当てられない？原因は東京リージョンの上限でした

## はじめに

AWS東京リージョン（ap-northeast-1）で作業していた際、Elastic IP アドレス（EIP）を6個目として割り当てようとしたところ、エラーが発生しました。

:::note warn
**原因は「Elastic IP のリージョン単位での上限（クォータ）」にありました。**
:::

この記事では、私がつまずいた内容と解決方法を備忘録としてまとめておきます。

## 書こうと思ったきっかけ

受講中のITスクールのハッカソンの一環で、複数のEC2インスタンスに個別のEIPを割り当てる構成を試していました。

5個目までは問題なく作成できたのですが、6個目の割り当てでエラーが発生し、「なぜ？」と調べた結果、上限に達していたことが原因でした。

## 内容

### 発生したエラー内容

6つ目の EIP を割り当てようとしたとき、以下のようなエラーが表示されました（一部抜粋）：

```
AddressLimitExceeded: The maximum number of addresses has been reached.
```

### デフォルトの制限について

* Elastic IP アドレスの上限は **リージョン単位で 5 個まで**
* 「1つのVPC内での制限」ではなく、「東京リージョン全体でのそのAWSアカウントの制限」

**参考文献**

https://repost.aws/ja/knowledge-center/ec2-troubleshoot-elastic-ip-addresses

### 上限を超えるには？

**Service Quotas** または **AWS Support Center** 経由で、上限緩和申請が可能です。

**参考文献**

https://qiita.com/miriwo/items/ad23293c359b8d8afc82

#### 手順（例：Service Quotas）

1. AWSマネジメントコンソールにアクセス
2. サービス → 「Service Quotas」
3. 検索バーで「EC2」→「Elastic IP addresses」
4. 東京リージョン（ap-northeast-1）を選択
5. 「クォータの引き上げをリクエストする」ボタンから申請

## まとめ

Elastic IP は便利ですが、AWSではデフォルトでリージョンあたり5個という制限があります。

:::note warn
**複数のEIPが必要な構成を想定している場合は、事前にクォータ引き上げ申請をしておくことをおすすめします。**
:::

私自身も、今後はNAT GatewayやALBの活用など、EIPに依存しすぎない構成設計を考えるきっかけになりました...！
大学生ならAI搭載のコーディングツールCursor Proを無料で使えるらしい

# いま話題のAIコーディングツール「Cursor」とは？

AIを活用した次世代の統合開発環境（IDE）として注目されている「Cursor」。  
GPT-4oやClaude 3.7 Sonnetなどの最新AIモデルを搭載し、コード補完・バグ修正・リファクタリング・ドキュメント生成など、あらゆる開発作業を強力にサポートしてくれるツールです。  
特に学生や若手エンジニアの間で、「開発効率が爆上がりする」と話題になっています

---

# 大学生は「Cursor Pro」が1年間無料！

2025年5月、Cursor公式が「大学生向けにPro版を1年間無料で提供する」キャンペーンをスタートしました。  
通常月額20ドル（約2,900円）のProプランが、**条件を満たせば1年間タダ**で使えます。

## 無料で使うための条件

- 大学のメールアドレス（.eduやac.jpなど）で登録・認証すること
- 対象国の大学に在籍していること（日本も対象！）
- Cursorアカウントのメールアドレスと大学メールが一致していること

## 対象国（抜粋）

日本、アメリカ、イギリス、カナダ、オーストラリア、ドイツ、フランス、韓国、ほか多数

---

# Pro版でできること・無料版との違い

| 機能                     | 無料版           | Pro版（学生は1年無料）         |
|--------------------------|------------------|-------------------------------|
| AIコード補完             | 月2,000回まで    | 無制限                         |
| 高速AIリクエスト         | なし             | 月500回（GPT-4o等で超高速）   |
| 低速AIリクエスト         | 月50回           | 無制限                         |
| プレミアムAIモデル利用   | 制限あり         | ほぼ全機能解放                |
| サンドボックス実験環境   | ○                | ○                             |
| ノート/課題連携          | ○                | ○                             |

1年後は通常の有料プラン（月額20ドル）に自動更新されますが、いつでもキャンセル可能です。

---

# 申請・利用方法

1. [Cursor公式学生向けページ](https://www.cursor.com/students)にアクセス
2. 「Verify Status」から大学メールアドレスで認証
3. 認証が通れば、Proプランが1年無料に（既存ユーザーもOK。残り期間分は自動返金）
4. Stripeの決済画面で「$0」になっていることを確認（カード登録は必要。超過分利用時のみ課金）
5. アカウント設定画面で割引が適用されているか確認

---

# どんな学生におすすめ？

- AIの力で**プログラミング学習を効率化したい**人
- レポートや課題で**コードの品質を上げたい**人
- 大規模なコードベースを**AIと一緒に解析・リファクタリングしたい**人
- API開発や実験的なプロジェクトを**サンドボックスで試したい**人

---

# 注意点・FAQ

- 1年後は自動で有料プランに移行（キャンセルはいつでも可能）
- 500回/月を超える高速AIリクエストは追加課金対象
- 対象外の国や大学は今後拡大予定
- 既存Proユーザーも割引適用＆残期間分返金

---

# まとめ

大学生なら、AI搭載のコーディングツール「Cursor Pro」を**1年間無料**で使える超お得なチャンスです。  
最新AIと一緒に、学習も開発も効率化してみませんか？  
興味がある人は、まずは公式サイトで学生認証を試してみましょう！

---
# 参考文献
https://news.yahoo.co.jp/articles/3624cff222ca6e032454c6e9f975e17da0a0dc15

https://pc.watch.impress.co.jp/docs/news/2012724.html

https://note.com/mekann/n/n431fe36271bf

https://www.cursor.com/ja/students
Homebrew完全ガイド：macOSで開発環境を整える第一歩

# Homebrew完全ガイド：macOSで開発環境を整える第一歩

## ☑️ Homebrewとは何か

**Homebrew** はmacOSやLinuxで使える**パッケージマネージャー**です。

### パッケージマネージャーとは

* 開発に必要なソフトやツールをコマンド一発でインストール、管理
* 例：Node.js、PHP、MySQL、git など
* 依存性の解決やアップデートも自動

> イメージ：App Storeをコマンド管理で行うような感覚

---

## 🛠 Homebrewのインストール流れ

### 1. ターミナルを開く

macOS: Launchpad > その他 > ターミナル

### 2. 以下をコピペして実行

```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

### 3. パスの設定

Apple Silicon:

```bash
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"
```

---

## ⚙️ Homebrewの主な使い方

### 1. 検索

```bash
brew search node
```

### 2. インストール

```bash
brew install node
```

### 3. アンインストール

```bash
brew uninstall node
```

### 4. アップデート

```bash
brew upgrade
```

### 5. インストール済みパッケージ確認

```bash
brew list
```

### 6. 不要ファイルの消去

```bash
brew cleanup
```

---

## ★ よく使うパッケージ一覧

| ツール          | コマンド                         | 用途                |
| ------------ | ---------------------------- | ----------------- |
| Node.js      | `brew install node`          | JavaScript開発環境    |
| PHP          | `brew install php`           | Laravel開発に必須      |
| Composer     | `brew install composer`      | PHPの依存管理          |
| MySQL        | `brew install mysql`         | データベース            |
| git          | `brew install git`           | バージョン管理           |
| Docker (GUI) | `brew install --cask docker` | Docker Desktopアプリ |

---

## 🔍 brewとcaskの違い

| brewコマンド                  | 内容            |
| ------------------------- | ------------- |
| `brew install xxx`        | CLIツールのインストール |
| `brew install --cask xxx` | GUIアプリのインストール |

---
Nextjs + rails（fargate）にdatadogを導入する記事まとめ 

nextへの導入・railsへの導入・railsへ導入する事前ローカル検証について記事を書いたので、その置き場です。

nextjs

https://qiita.com/ikeyaH/items/cee9ff6f824bbacf2eb9

rails + fargate

https://qiita.com/ikeyaH/items/b3a7fc6042208186c1f8

ローカルコンテナでrailsかんs

https://qiita.com/ikeyaH/items/338edb2121dbea6b130c
Node.jsとnpmの基礎まとめ

## ✅ Node.jsとは？

### 🔸 一言でいうと

「**JavaScriptをサーバーサイドで動かすための実行環境**」です。

### 🔸 詳細

* もともとJavaScriptはブラウザ内でしか動かなかった
* Node.jsにより、サーバーやローカル環境でもJavaScriptを実行できる
* サーバー構築・CLIツール・ビルドツールなど幅広く活用されている

### 🔸 実務での用途

* Webサーバー構築（例：Express）
* ビルドツール実行（webpack, viteなど）
* Laravel MixやVue/Nuxtなどの開発環境でも裏で動いている

---

## ✅ npmとは？

### 🔸 一言でいうと

「**Node.js用のライブラリ管理ツール（パッケージマネージャ）**」です。

### 🔸 詳細

* `npm = Node Package Manager`
* ライブラリの追加・削除・バージョン管理ができる
* `package.json`でプロジェクト依存関係を管理
* `npm run`でスクリプト実行も可能

### 🔸 よく使うコマンド

| コマンド                | 説明                       |
| ------------------- | ------------------------ |
| `npm install`       | 依存ライブラリを一括インストール         |
| `npm install XXX`   | ライブラリXXXをインストール          |
| `npm uninstall XXX` | ライブラリXXXを削除              |
| `npm run スクリプト名`    | `package.json`内のスクリプトを実行 |

---

## ✅ Node.jsとnpmのインストール方法（macOS/Homebrew）

### 1. インストール

```bash
brew install node
```

### 2. バージョン確認

```bash
node -v
npm -v
```

---

## ✅ npmプロジェクトの作成手順

### 1. プロジェクト作成

```bash
mkdir my-npm-test
cd my-npm-test
```

### 2. 初期化（package.jsonの作成）

```bash
npm init -y
```

### 3. ライブラリインストール（例：lodash）

```bash
npm install lodash
```

---

## ✅ サンプルコード（index.js）

```js
const _ = require('lodash');

const arr = [1, 2, 3, 4];
const reversed = _.reverse(arr.slice());

console.log(reversed); // [4, 3, 2, 1]
```

### 実行コマンド

```bash
node index.js
```

---

## ✅ 実務との関係まとめ

| 作業内容                  | Node.jsの役割   | npmの役割                   |
| --------------------- | ------------ | ------------------------ |
| VueやNuxtの開発           | 開発サーバー起動・ビルド | 必要なライブラリの管理              |
| Laravel MixでのJS/CSS処理 | JSの実行環境      | `npm run dev` などのスクリプト実行 |
| vite/webpackの利用       | ビルド処理の実行     | プラグインや依存関係の管理            |

---

## ✅ まとめ

| 項目          | 説明                         |
| ----------- | -------------------------- |
| **Node.js** | JavaScriptをサーバーサイドで動かす実行環境 |
| **npm**     | ライブラリやツールを管理するパッケージマネージャ   |
datadogコンテナをローカルで動かす（& Rails api）

下記記事の補足という形の記事になります。datadogをrails + fargate環境にデプロイするのが最終目的です。

https://qiita.com/ikeyaH/items/b3a7fc6042208186c1f8

いきなりfargateデプロイも悪くはないかもですが、やっぱりローカルで試せるなら試した方が、これはいけるなという感覚と共にデプロイもできると思います。個人的には。

というわけで、docker composeを利用し、rails と datadogをdockerコンテナで動かす手順です。

# 実装

## 1. railsの設定修正

最初に、rails側にdatadog gemを追加 & 設定を追加します。
[こちら](https://qiita.com/ikeyaH/items/b3a7fc6042208186c1f8#1-rails%E3%81%AE%E8%A8%AD%E5%AE%9A)を参考に、gemのインストールおよびdatadog configの設定ファイルを追加してください。

そして、configを少し変えます。hostの設定です。
※fargateデプロイ時は削除してください。
```ruby:config/initializers/datadog-tracer.rb
Datadog.configure do |c|
  c.env = ENV["DD_ENV"] # 動的な変数は.envやdocker composeに設定するか、'local'などのハードコーディングで良いと思います。
  c.service = ENV["DD_SERVICE"]
  c.tracing.sampling.default_rate = (ENV["DD_TRACE_SAMPLE_RATE"] || 1.0).to_f
  c.tracing.instrument(:rails, service_name: ENV["DD_SERVICE"])
  c.appsec.enabled = true
  c.agent.host = "datadog-agent" # 追加：ホストをdatadog-agentに設定
end
```

## 2. docker composeにdatadog agent追加

```ruby:docker-compose.ymlservices:
  api: # railsの設定をしている箇所としてみてください
  ~略~
    # もしdockerFileがprd向けのみの場合、envを上書き
    environment:
      RAILS_ENV: 'development'
      BUNDLE_WITHOUT: ''
    # env等を上書きする場合、各種インストールを再実行する
    command: >
      bash -c "rm -f tmp/pids/server.pid && 
      apt-get update && 
      apt-get install -y build-essential && 
      bundle install && 
      bundle exec rails db:migrate && 
      bundle exec rails s -b 0.0.0.0 -p 4000"　# ポートなどは実際の開発環境に合わせてください
 # datadog-agentを追加
  datadog-agent:
    profiles: ["datadog"] # 指定した時のみにしたい場合、profile設定をしておく
    image: public.ecr.aws/datadog/agent:latest 
    environment:
      - DD_API_KEY=<keyを設定してください>
      - DD_APM_ENABLED=true
      - DD_LOGS_ENABLED=true
      - DD_APM_NON_LOCAL_TRAFFIC=true
      - DD_SITE=datadoghq.com
      - DD_APM_RECEIVER_PORT=8126
      - DD_SERVICE=<任意のサービス名>
      - DD_ENV=<任意のenv（localなど）>
      - DD_TRACE_SAMPLE_RATE=0.5
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup:/host/sys/fs/cgroup:ro
    ports:
      - 8126:8126
```

apiキーなどは実際の値に置き換えてください。
datadogコンソールで確認できます。
※githubなどの履歴には入れないようご注意ください。

以上で、ローカルのコンテナ環境でrailsのログがdatadog agentに渡され、datadogに送られることが確認できるはずです。
github actionを使ってpowershellのスクリプトを自動テストする

# 概要

たまに使う機会があるpowershell。
再利用できそうな処理はテストを書きたい
毎回ローカルのPCでテストを実行するのは面倒なので、github actionで自動テストを実行するように設定します。


# 開発環境
ソフトウェア名|バージョン|説明
------------|--------------|-------
Windows|10|OS
Powershell|5.1.19041| スクリプト言語およびキャラクターユーザーインターフェイス
VSCode|1.99.3|IDE
powershell |2025.0.0| VsCodeエクステンション　Microsoft製
Pester |---|Powershellのテストフレームワーク
# コード

# GithubAction

```.github/workflows/pester_ci.yml
name: CI

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  test:
    runs-on: windows-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Install Pester
        run: |
          Install-Module -Name Pester -Force -SkipPublisherCheck

      - name: Run Pester Tests
        run: |
          Invoke-Pester .\Service\


```

# プロダクトコード

```powershell
# パソコンの情報を取得するクラス
# 
class machineInfoService{
   
    [String] $cpuName
    [String] $modelName
 
    [String] getMemorySize(){
         Return  Get-WmiObject -Class Win32_PhysicalMemory | %{ $_.Capacity} | Measure-Object -Sum | %{ ($_.sum /1024/1024/1024).toString()}
     }
 
     [String] getModelName(){
         return (Get-WmiObject Win32_ComputerSystemProduct).name
     }
 
     [String] getCpuName(){
           return @((Get-WmiObject Win32_Processor).Name)[0]
     }
 
     [String] getSerialNumber(){
         return (Get-WmiObject Win32_BIOS).SerialNumber;
     }
 
     [String] getOS(){
       $OS = (Get-WmiObject Win32_OperatingSystem).Caption
       $SP = (Get-WmiObject Win32_OperatingSystem).ServicePackMajorVersion
       if( $SP -ne 0 ){ $OS += "SP" + $SP }
       return $OS
     }
 
     [String] getHostName(){
       return hostname;
     }
 
 }
 
 
 

```



# テストコード

```powershell
using module ".\MachineInfoService.psm1"

Import-Module Pester 

# 起動方法
# Invoke-Pester .\Service\MachineInfoServiceTest.Tests.ps1

Describe "MachineInfoService" {
    Context "Get-MachineInfo" {
        It "Serial番号取得のテスト" {
            $result = [MachineInfoService]::New().getSerialNumber();
            [System.Console]::WriteLine("TEST01:SERIALNumber is"+$result)
            $result | Should  -Not -BeNullOrEmpty
        }
    }
}

```


# 実行結果

SerialNumberに値が入っていることを確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2710623/3435ed08-0759-4ada-b06f-3964d9439ce0.png)


https://github.com/RYA234/powershell_tool/actions/runs/14952394756/job/42003597337


# 参考

github コミット分

https://github.com/RYA234/powershell_tool/commit/5b6bc55417f1196501bc274b3b82d245c6d11262
footer を共通化して作成・表示する手順【Laravel9】

# やりたいこと
画像のような footer を作りたい。
![スクリーンショット 2025-05-11 14.19.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/0f7a1f50-03ec-4f00-ad98-e666b610eab4.png)



# Laravel フッターコンポーネント作成手順
## ① コンポーネントファイルを作成
```bash
php artisan make:component Footer
```

自動で以下の2つが作成されます：
・app/View/Components/Footer.php（クラス）
・resources/views/components/footer.blade.php（テンプレート）


## ② footer.blade.php にHTMLを書く
```footer.blade.php
<!-- resources/views/components/footer.blade.php -->
<footer class="bg-white py-4 text-center text-sm text-gray-500 shadow">
    &copy;
    <span class="ml-1">{{ date('Y') }}</span>
    <span class="ml-1">{{ config('app.name') }}</span>
    <span class="ml-1">All rights reserved</span>
</footer>
```


## ③ フッターを呼び出すレイアウトに <x-footer /> を追加
```app.blade.php
<!-- 例：resources/views/layouts/app.blade.php -->
<body class="bg-gray-100 text-gray-800">
    <main>
        @yield('content')
    </main>

    <x-footer /> <!-- ← ここに追加 -->
</body>
```


## ④ APP_NAME を .env に設定（未設定なら）
```
APP_NAME="プロジェクト名"
```
※""をつけるとスペースをつけることができます。

s

それにより config/app.php の以下が反映されます：
```config/app.php
'name' => env('APP_NAME', 'Laravel'),
```


## ※補足：コンテンツ量が少なくてフッターが画面の途中に表示されてしまう場合
修正前
![スクリーンショット 2025-05-12 10.34.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/c822e66d-4c3e-41ea-ad88-4b2b5b3ddd86.png)

修正後
![スクリーンショット 2025-05-12 10.34.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/5f1d7497-1745-4fcb-8ed5-5e17f451b0c5.png)


### ポイント
| 役割 | 必須クラス・構造 | 説明 |
| --- | ------------- | --- |
| **全体ラッパー** | `min-h-screen flex flex-col` | 全体を縦方向のFlexにし、画面高を100vhに固定 |
| **メインコンテンツ** | `flex-grow` | コンテンツ部分を「残りの空間いっぱいに広げる」 |


### コード
```/views/layouts/app.blade.php
<div class="min-h-screen flex flex-col bg-gray-100">
    @include('layouts.navigation')

    <!-- Page Heading -->
    @if (isset($header))
        <header class="bg-white shadow">
            <div class="max-w-7xl mx-auto py-6 px-4 sm:px-6 lg:px-8">
                {{ $header }}
            </div>
        </header>
    @endif

    <!-- Page Content -->
    <main class="flex-grow">
        {{ $slot }}
    </main>

    {{-- footer --}}
    <x-footer />
</div>
```



# 関連：Laravel Bladeでauth画面 + ログイン前 のフッターを作成・表示する方法
https://qiita.com/honaki/items/a77d13de2b34780173bc
GitHub Packagesでnpmパッケージを扱うための設定方法

# GitHub Packagesで公開されているnpmパッケージをインストールする方法

GitHub Packagesで公開されているnpmパッケージをインストールするにはGitHubへ認証する必要があります。GitHubへ認証するにはpersonal access token（classic）が必要です。また、personal access token（classic）にはread:packagesスコープが設定されている必要があります。personal access token（classic）がない場合は発行してください。[New personal access token（classic）](https://github.com/settings/tokens/new)で発行できます。次に

```ini:~/.npmrc
//npm.pkg.github.com/:_authToken=TOKEN
```

のようなファイルを作成してください。`TOKEN`をread:packagesスコープが設定されているトークンに置き換えてください。次にリポジトリのルートのpackage.jsonと同じディレクトリに

```ini:.npmrc
@NAMESPACE:registry=https://npm.pkg.github.com
```

を作成してください。`@NAMESPACE`はインストールしたいパッケージのスコープに置き換えてください。例えば、@tommy-ish/fooというパッケージをインストールしたい場合は`@tommy-ish:registry=http://npm.pkg.github.com`にしてください。後は通常通りインストールできます。例えば、@tommy-ish/fooというパッケージをインストールしたい場合は

```console
$ npm install @tommy-ish/foo
```

を実行します。

# GitHub ActionsからGitHub Packagesにアクセスする方法

GitHub ActionsからGitHub Packagesにアクセスするにはactions/setup-nodeのregistry-urlとNODE_AUTH_TOKENという環境変数を使うと簡単です。具体的には

```yaml
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 22.x
      registry-url: https://npm.pkg.github.com
  - run: npm ci
    env:
      NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

のように書くとGitHub Packagesからパッケージをインストールできます。また

```yaml
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 22.x
      registry-url: https://npm.pkg.github.com
  - run: npm ci
  - run: npm publish
    env:
      NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

のように書くとGitHub Packagesでパッケージを公開できます。

# DependabotがGitHub Packagesで公開されているパッケージをアップデートできるようにする方法

Dependabotの設定ファイルを

```yaml:.github/dependabot.yml
version: 2
registries:
  npm-github:
    type: npm-registry
    url: https://npm.pkg.github.com
    token: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
    replaces-base: true
updates:
  - package-ecosystem: npm
    registries:
      - npm-github
```

のように設定してください。`MY_ARTIFACTORY_PASSWORD`はDependabotシークレットの名前に置き換えてください。そのDependabotシークレットはread:packagesスコープが設定されているトークンが設定されている必要があります。
`brew edit`でVSCodeを使う方法

# Homebrewむずい...
ターミナル上で入力は私にとって難しすぎる！
と言うことでVSCodeを使って`brew edit`を行う方法を調べてみました！

# 手順
- VSCodeのコマンドパレットを開く
`⌘(Command) + Shift + P`でひらけます
- 検索窓に`shell command install`と入力して
「シェルコマンド: PATH内に'code'コマンドをインストールします」をクリック
![shell command install](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3930283/7d4fce5e-ec81-4fe0-a00f-9e40eed42bfa.png)
(これにより、ターミナルからVSCodeが起動可能になる)
- このコマンドを実行 `export HOMEBREW_EDITOR="code"`
Homebrew規定のエディタをVSCodeに変更するみたいです

# 利点
- ターミナルの扱いに慣れてなくでも`brew edit`がやりやすくなる！
- 色がついて読みやすい！

---
最後まで読んでいただきありがとうございます。