RAGは検索エンジンが命！AI Search初心者入門
RAG（検索拡張生成）は、生成AIを活用したシステムの中で特に注目されている技術で、質問に関連する情報を検索し、これらを組み合わせて回答を生成する手法です。企業はこのRAGを導入していますが、検索精度の向上が重要な課題となっています。本記事では、Azure AI Searchをテーマに、検索エンジンの基本的な仕組みやクエリの記述方法を初心者向けに解説しています。 Azure AI Searchは、Microsoft Azureが提供する検索エンジンサービスで、主にテキスト検索に特化しています。インデックスやドキュメント、フィールドなどの基本用語を理解することが、Azure AI Searchの利用に役立ちます。特に、インデックスはデータの保管場所を示し、ドキュメントはインデックス内の個々のデータ単位を指します。 さらに、Azure AI Searchには特有の用語があり、SKUやパーティション、レプリカなどがその例です。これらの概念は、リソース設計やプロジェクトの可用性、スケーラビリティに影響を与えます。たとえば、基本プランで特定のパーティション数やレプリカ数を設定した場合の課金モデルについても触れています。 検索エンジンの仕組みについては、全文検索の技術を解説し、特に転置インデックスの役割を説明しています。転置インデックスは、文書内の単語の出現位置を記録し、高速な検索を可能にします。この仕組みにより、ユーザーが求める情報を効率的に取得することができます。 さらに、検索クエリの構文についても詳しく解説されています。重みづけや絞り込み、並び替え、グループ集計といった基本的な操作が紹介され、実際のクエリ例も示されています。特に、飲食店の情報を検索する際の具体的なクエリ構造が示され、実際のデータ取得方法が具体的に示されています。 最後に、生成AIの普及に伴い、検索エンジンの需要は増加すると予測されており、技術の向上に寄与することが期待されています。著者は、今後も生成AIやクラウド技術に関する情報を初心者に向けて発信し続ける意向を示しています。読者に対して感謝の意を表し、フォローを呼びかけています。
要素を非活性にするのに、まさか disabled を使ってないよね？
要素を非活性にする際、disabled=trueを使うことがアクセシビリティの観点から適切ではないという指摘があります。特に、disabled属性が付与された要素はフォーカスできなくなるため、キーボードを用いるユーザーにとって、その要素の存在を認識しにくくなります。これにより、ユーザーは要素が存在しないかのように感じてしまい、特に操作中に突然要素が無効になることで混乱を招く可能性があります。そのため、代わりにaria-disabled=trueを使用することが推奨されます。 aria-disabled属性は、要素やその子孫要素が無効であることを示し、スクリーンリーダーなどの支援技術を使用する人々に対して、その要素が編集や操作できないことを通知します。例えば、Voice Overでは無効なフィールドにカーソルを当てると「淡色表示」として読み上げられます。さらに、aria-disabledを設定しても要素の機能は変更されず、見た目も変わらないため、ユーザーは視覚的にその要素を操作することができます。 具体的な実装例として、Reactで書かれたテキストフィールドのコンポーネントが挙げられています。このコンポーネントでは、disabledプロパティがtrueの場合にaria-disabledとreadOnly属性を設定し、CSSで背景色やカーソルのスタイルを変更しています。これにより、ユーザーはキーボード操作で要素間をスムーズに移動でき、誤作動を防ぐことができます。 最後に、フィードバックを提供してくれたシニアエンジニアの言葉を引用し、アメリカではアクセシビリティが非常に重要視されており、aria-disabledを使用することが一般的であるとのことです。このような具体的なフィードバックを受けられる環境がありがたいと述べています。
新しく公開されたAnthropic Quickstartsがサンプルの域を超えている
新たに公開されたAnthropic Quickstartsはサンプルの枠を超えており、GitHubで「Customer Support Agent」プロジェクトが提供されています。このプロジェクトはカスタマーサポートを想定したチャットアプリであり、主な特徴にはAnthropicのClaudeモデルを搭載し、Amazon Bedrockとの統合によってコンテキストナレッジ検索が可能です。また、リアルタイム思考やデバッグ情報の表示、ナレッジベースソースの視覚化、ユーザーの気分検出などの機能を備え、高度にカスタマイズ可能なUIを提供します。 手順としては、Gitをクローンし、.env.localを作成してnpmをインストールし、devサーバーを起動することで動作を確認できます。特に、.env.localにはAnthropic APIのキーやAWSの認証情報を設定する必要があります。このプロジェクトをBedrockのみに対応させるよう手直しを行い、使用ライブラリーをAnthropic Bedrock TypeScript API Libraryに変更し、モデル名もBedrockのものに修正しました。 また、クロスリージョン推論を指定し、Knowledge bases for Amazon Bedrockの設定も行いました。ユーザーへの応答は、適切な情報を提供しつつ、丁寧かつプロフェッショナルなトーンを保つことが求められます。応答はJSON形式で構成され、必要に応じて人間のエージェントに転送することも考慮されています。具体的には、ユーザーの気持ちに配慮し、適切な情報を基にした簡潔な応答を提供することが重要です。 このように、Anthropic Quickstartsはカスタマーサポートの効率を向上させるための強力なツールであり、多様な機能を通じてユーザーとのインタラクションを最適化することが可能です。
Gitを触ったことのないエンジニアがヤバいと言われる理由を考えた
Gitを触ったことのないエンジニアが「ヤバイ」とされる理由について考察した内容です。まず、Gitは現代のソフトウェア開発におけるバージョン管理の標準であり、GitHubやGitLabといったサービスを通じて開発フローが実現されているため、Gitを使ったことがないと業界の慣習に疎いと見なされる可能性があります。また、オープンソースソフトウェア（OSS）の多くがGitを利用しているため、Gitを使えないことはOSSのコントリビュータになる意欲がないと解釈されることもあります。とはいえ、OSSのツールはzip形式でもダウンロード可能で、Gitの使用は必須ではないものの、Gitのコマンドを利用することで効率的に作業が進むことが期待されます。 さらに、反対派の意見として、Gitを使わない理由や代替手段があることが挙げられます。エンジニアという広い概念に対して、主語が大きすぎるとの指摘もあり、開発者に特化した視点での議論が必要です。開発者は新しい技術にオープンであるべきであり、試してみる姿勢が求められます。実際には、開発中にGitからSVNに移行した事例もあり、状況に応じて最適なツールを選ぶことも重要です。 また、就職活動においては、企業によってはGitの使用が必須条件となることが多く、特に駆け出しのエンジニアにはGitの経験が重視される傾向があります。そのため、求職中の人は少しでもGitに触れておくことが無難とされています。総じて、全てのエンジニアがGitを使える必要はないものの、開発者として活躍したいのであれば、Gitを触らないのはあまり良いマインドセットとは言えないでしょう。したがって、Gitを学ぶことは、特にキャリア形成において重要であると結論づけられます。
3分でわかる，Shell Script/Dockerfileの可読性を上げるヒアドキュメントの使い方
ヒアドキュメントは、Shell ScriptやDockerfileを書く際に、コードを簡潔かつわかりやすく保つための手法です。具体的には、通常のDockerfileのRUNコマンドを使用する場合、命令を連続して書くと見づらくなったり、エラーの原因となることがあります。一方で、ヒアドキュメントを使うと、複数行のコマンドをスクリプトの中に直接埋め込むことができ、可読性が向上します。例えば、RUNコマンド内に複数のapt-get命令などを記述する際、エラーを防ぐための工夫や、実行前のデバッグ情報を表示するためのset -exオプションの追加も簡単です。これにより、スクリプトのエラーを早期に発見でき、作業が効率化されます。 また、catコマンドを使ったヒアドキュメントの例も紹介されており、特にAWSのEC2インスタンスでのUserDataを利用する際に役立ちます。ここでは、Dockerのサービスファイルを作成するスクリプトが示され、変数展開を防ぐためにシングルクォートで囲むテクニックが説明されています。さらに、Terraformを使ったインフラ構成の際にもヒアドキュメントが活用できることが述べられています。 総じて、ヒアドキュメントは、コーディングの際に見た目を整え、可読性を高めるための有効な手法であると強調されています。特に、複雑なスクリプトを書く場合は、ヒアドキュメントを取り入れることで、より明快で整然としたコードを書くことが可能になります。今後もさまざまなシーンでの活用が期待されます。
Mac OSユーザーのための必須ソフトウェア
本日は、Mac OSにインストールすべき必須ソフトウェアを紹介します。まず、効率ツールとしてHomebrewがあります。これはコマンドラインのパッケージ管理ツールで、サードパーティのソフトウェアを簡単に管理できるように設計されており、macOSとLinuxに対応しています。次に、ServBayは開発者向けのワンストップ開発環境管理ツールで、環境設定を簡素化し、すぐにコーディングに取り掛かれるようサポートします。さらに、AltTabはウィンドウ管理を効率化し、スムーズなアプリケーション切り替え体験を提供します。 メディア関連では、GIF Brewery 3が挙げられます。このソフトウェアは、GIFアニメーションの再生速度やフレームレート調整、特定のフレームへのテキスト追加など、多くの動画編集機能を備えています。また、Downie 4は非常に効率的な動画ダウンローダーで、数千の動画サイトから動画を簡単にダウンロードできます。Battery Buddyは、Macのバッテリー状態を監視し、ユーザーに現在のバッテリー状況をわかりやすく表示するソフトウェアです。 最後に、ターミナルツールについて紹介します。iTerm2は、Mac OSに付属のターミナルよりも使いやすく、テーマ選択やコマンドのハイライト、自動補完の提案などの機能を提供します。Figは、Macのターミナル向けの自動補完ツールで、500以上のCLIツールをサポートし、新たな補完プロンプトの追加も可能です。これらのソフトウェアを活用することで、Mac OSの使用体験を大幅に向上させることができます。
Pythonで並列処理するコードの雛形（進捗表示つき）
Pythonでの並列処理を行うためのコード雛形が示されています。このコードは、タスクの進捗を表示する機能を持ち、主に備忘録として投稿されています。コードは以下のような構成になっています。 まず、必要なライブラリをインポートしています。具体的には、dataclasses、logging、random、sys、threading、time、ThreadPoolExecutor、およびListが用いられています。次に、ログの設定を行っており、ログのフォーマットを指定して標準出力とファイル出力のハンドラを設定しています。 進捗表示用のカウンターとして、成功とエラーのカウンターがそれぞれスレッドセーフな形で用意されています。WorkerInputとWorkerOutputというデータクラスが定義されており、タスクの入力と出力の構造を示しています。 Workerクラスには、タスクを実行するrunメソッドがあり、ここではタスクを模擬するために10秒間のスリープを設けた後、ランダムにエラーを発生させる仕組みが組み込まれています。成功した場合は成功カウンターを増加させ、エラーが発生した場合はエラーログを記録し、エラーカウンターを増加させます。 メインの処理部分では、ワーカーの数を設定し、実際のタスクに基づいた入力リストを生成します。ThreadPoolExecutorを使用して、指定した数のワーカーを並列に起動します。進捗表示のためのループも設けられており、すべてのワーカーが終了するまでカウンターの状況をログに記録します。 最終的には、各ワーカーの結果を収集し、成功または失敗を示す出力リストを表示します。このコードは、タスクの成功とエラーを追跡しながら並列処理を行うための基本的な枠組みを提供しています。
キャリアふりかえりと転職完了
この記事では、著者のキャリアの遍歴と転職の理由を振り返りながら、エンジニアとしての成長や挑戦について述べています。著者は多くの転職を経験しており、各職場での学びや挑戦が自身の成長につながっていることを強調しています。エンジニアとしてのキャリアをSES、メガベンチャー、スタートアップと多岐にわたって歩んできた経緯を説明し、特にエンジニアの役割や価値観の変化に触れています。 最初のエンジニアとしての仕事は難しく、就職氷河期の影響を受けて、SESでの経験を経て、様々なプロジェクトに携わりました。特に、ソーシャルゲーム開発では実装の楽しさを学び、価値を届ける視点を持つようになったことが重要です。その後、メガベンチャーでのアドテクノロジーの開発に携わり、エンジニアとしての成長を感じる転機となりました。 さらに、メルペイでの経験を通じて、エンジニアリングマネージャーとしての新たな挑戦に取り組み、急成長するスタートアップでの役割を担うことになりました。特に、急成長する環境での採用や組織作りの難しさを体験しながら、様々な技術的な挑戦を楽しんでいます。 最近の転職先である株式会社Datachainでは、ブロックチェーン技術に関わり、社会課題の解決を目指すプロジェクトに取り組んでいます。著者は新しい技術パラダイムに挑戦しながら、成長を続けることの面白さを実感しており、これまでの経験を生かしながら新しい挑戦に向かっています。 最後に、著者は自身のキャリアを振り返り、チャレンジし続けることで成長し、自由にできることが増える楽しさを伝えています。転職の際には、チャレンジの振り幅を考慮し、自分が許容できる環境を選ぶことで、さらなる成長に繋がると結論づけています。
symbol-bootstrapからshoestringへ移行
この記事では、symbol-bootstrapからshoestringへ移行する手順について説明しています。まず、symbol-bootstrapは今後メンテナンスされないため、新たに開発されたshoestringツールでノードを運用する必要があります。そのための情報を提供し、特に委任者の復元に関する課題に焦点を当てています。従来のノードデータを活用することで、時間を短縮できると述べています。 まず、shoestringに必要な前提条件として、symbol-bootstrapでノードを運用していること、gitが使えること、shoestringを実行できる環境が必要であると指摘しています。また、公式のshoestringは現状では委任者の復元に失敗しているため、独自に改良版ツールを用いて作業を進めることが推奨されています。 改良版shoestringのインストール手順が詳述されており、必要なデータを取得するための具体的なコマンドも示されています。特に、委任者の引き継ぎに必要なファイルの作成方法が説明されており、mainPrivateKeyやtransportPrivateKeyなどの重要な情報を保持することが強調されています。 次に、委任者の復元のための手順が紹介されています。symbol-bootstrapの特定のフォルダの内容を新しいshoestringのフォルダにコピーするだけで簡単に実行できるとしています。さらに、overrides.iniの設定によって、委任者の復元を完了させることが可能です。 ノードの起動手順も細かく説明されており、docker-composeを使用してノードを立ち上げる方法が示されています。起動後にノードの状態を確認するためのURLも提供されており、エラー対応の手順についても記載されています。特に、dockerのネットワークの重複によるエラーや、キーの不整合による問題への対処法が解説されています。 最後に、証明書の更新に関する注意点が述べられ、証明書関連のエラーについてのトラブルシューティング方法が説明されています。特に、証明書の有効期限や状態を確認するコマンドが示されており、実際の動作確認が行われています。全体として、この記事はsymbol-bootstrapからshoestringへの移行をスムーズに行うための具体的な手順と注意点を提供しています。
モバイルアプリのクラッシュ原因を効率的に分析しよう
モバイルアプリのクラッシュを効率的に分析するために、New Relic Mobile User Journeyが役立ちます。このツールは、アプリの使用経路を俯瞰的に把握し、原因分析を容易にします。New Relic Mobileは、モバイルアプリのパフォーマンスやエラーを記録する機能を持ち、さまざまなプラットフォームに対応しています。さらに、バックエンドアプリケーションとの情報関連付けも行うことで、ユーザーに影響を与える問題の調査を効率化します。 New Relic Mobileは、クラッシュや例外の分析、ネットワークパフォーマンスの分析、バックエンドのボトルネックの特定、バージョンごとの品質分析、ユーザー操作の分析、ビジネスKPIの可視化などの機能を提供します。特に、クラッシュ分析機能では、クラッシュ時のトレースやユーザー操作を簡単に把握でき、クラッシュの原因を特定する助けになります。 従来の方法では、クラッシュ情報を単独で確認することが困難ですが、Mobile User Journeyを利用することで、アプリの利用開始からクラッシュに至るまでのイベントを直感的に可視化できます。イベント間の遷移を示す線の太さによって、クラッシュに至ったユーザーが多い経路を特定し、その部分から効率的に原因分析を進めることが可能です。 また、特定の経路を選択することで、クラッシュ発生時のユーザーの詳細情報をフィルタリングして確認でき、共通の原因を見つける手助けになります。さらに、選択したセッションを分析することで、特定の操作がクラッシュを引き起こす可能性を探ることもできます。 New Relic Mobile User Journeyの利用には特別な設定は不要で、SDKをアプリに組み込むだけで使用開始できます。フリープランも利用可能で、簡単に試すことができます。最終的に、Mobile User Journeyを活用することで、クラッシュの原因分析を点から面へとシフトさせ、問題への対応がより効率的になります。詳細については公式ブログやQiita Organizationを参照することをお勧めします。
エンジニア歴約10年(資格未取得者)が初級資格に挑む【1】
エンジニア歴約10年を持つ自称ITエンジニアが、資格を一切取得していない状況から、AWSクラウドプラクティショナーとLinuCレベル1の資格取得を目指して勉強を始めることを決意しました。業務の待機期間を利用して、学習の記録を残し、同じような境遇の人々に参考になればと考えています。資格取得に向けた勉強法が未経験であるため、関連する情報を集めることからスタートしました。 AWSクラウドプラクティショナーに関しては、紹介されたテキストを利用し、同様にLinuCレベル1についても家にあったテキストを活用することにしました。学習の進め方としては、テキストを読み込んだ後に練習問題や過去問に取り組む方法を採用する予定です。 初日の学習では、AWSクラウドプラクティショナーの1章を読み終え、AWSに関する公式ドキュメントも確認しました。LinuCレベル1は1章の途中まで進めましたが、他の業務が発生し中断しました。初日の反省を踏まえ、今後は一日の中でテキストを切り替えるのではなく、1日1冊に集中するスタイルに変更することにしました。 2日目は、AWSクラウドプラクティショナーのテキストを集中して読み進め、2章の途中まで完了しました。3日目にはLinuCレベル1の1章から再開し、業務での経験を活かしながら理解を深めました。特にLinuxのコマンドやオプションに目を向ける良い機会となり、tmuxについては別のリソースを参照して理解を深めました。 4日目には、AWSのテキストの2章から再開し、クラウドの概念についての内容を学びました。これまで何気なく使用していた機能についての理解が深まったと感じています。今後も引き続き、資格取得に向けた学習を進める意向を示しています。
【初心者向け】mapメソッドって何？
mapメソッドは、配列の各要素に対して特定の処理を適用し、新しい配列を生成するための便利なツールです。例えば、配列numbersに格納されている数字を2倍にする場合、通常の演算では配列自体が2回繰り返されてしまいますが、mapメソッドを使うことで、各要素を個別に処理できます。具体的には、以下のように記述します。doubled_number = numbers.map {|num| num * 2}。これにより、期待通りの返却値[2, 4, 6]が得られます。 次に、mapメソッドを用いて、配列の要素を文字列に変換することも可能です。通常のやり方ではnumber_str = numbers.map {|num| num.to_s}と記述し、返却値は["1", "2", "3"]になりますが、単一のメソッド呼び出しの場合、より簡潔にnumber_str = numbers.map(&:to_s)と記述できます。これにより、冗長なコードを省略でき、同じ結果が得られます。 また、指示したい処理内容が長くなる場合には、do...endブロックを使うと良いでしょう。例えば、defined_numbers = numbers.map {|num| num > 2 ? "#{num * 100}は大きい" : "#{num * 10 }は小さい"}という冗長なコードを、defined_numbers = numbers.map do |num| num > 2 ? "#{num * 100}は大きい" : "#{num * 10 }は小さい" endのように書き換えることで、読みやすさが向上します。 このように、mapメソッドを使うことで、配列の要素に対する処理を簡潔かつ効果的に行うことができ、状況に応じてコードの書き方を工夫することで、より理解しやすいプログラムを作成することができます。
AIが学習するしくみ 〜 コードを添えて
AIの学習の仕組みについて、特にニューラルネットワーク（NN）の原理を理解するための基礎を解説します。AIサービスは複数のNNを組み合わせた構造を持ち、入力に応じた出力を生成するシステムです。NNは脳細胞を模したノードのネットワークで構成され、各ノードは入力を受け取り、信号を伝達する役割を果たします。ノードの処理にはパラメータがあり、これによって出力が変わります。基本的な接続方法は密結合レイヤで、全ノードが前のレイヤの全ノードから信号を受け取ります。 NNを使用する理由は、因果関係が複雑な場合でも、入力と結果を知っていれば目的の関数を模倣できるためです。例えば、ゲームの状況を入力として、どのように行動すべきかを考えるプログラムを書くのは難しいですが、NNを使えばその学習が可能です。AIの学習は、初期化から始まり、入力に対する出力の計算、望ましい値との差の計算、パラメータの調整のプロセスが繰り返されます。 具体的な学習の流れとして、まず初期値を設定し、入力とターゲットのデータを用意します。その後、出力を計算し、損失を求めます。損失が大きければパラメータを調整し、これを繰り返すことで学習を進めます。NNはさまざまな特性を持ち、用途に応じたモデルが必要です。例えば、CNNは画像認識に、Transformerは自然言語処理に特化しています。 現実の問題にAIを適用する際、まずデータの質が重要であり、不適切なデータでは学習効果が得られません。データ収集や開発環境の構築も課題が多く、人間の介入が必要な場合が多いです。計算の効率化やスケールアップも考慮する必要があり、クラウドサービスを利用することが一般的です。AIサービスの開発には理論だけでなく、実際のデータと環境の整備が重要です。AI技術を理解することで、実際のサービスがどのように機能しているのかをより明確に理解できることを願っています。
MS-DOS 1.25 のソースを動かす
MS-DOS 1.25のソースコードをビルドするためには、まず必要なツールをインストールし、ソースコードをビルドして実行することができる。その過程で、MS-DOSがどのように動作するのかを理解しようという目標が設定された。特に、BIOSの上で動作する自作ファームウェアの開発を目指し、古いMS-DOSを動かしたいという欲求が強調されている。しかし、公開されているソースコードには詳細な説明がなく、ハードウェア依存部分が含まれていないため、IBM PC用のIO.ASMが存在しないことが大きな障害となっている。 IO.ASMはMS-DOSのカーネルであるMSDOS.SYSと連携して動作し、ハードウェアとのやりとりを行うが、公開されているソースからはIBM PCで動作させるためのコードが得られない。このため、目標としている自作ファームウェアの上でMS-DOSを動かすためには、独自のIO.ASMを作成する必要があると結論づけられている。 MS-DOS v1.25の起動プロセスは、IO.SYSから始まり、次にMSDOS.SYSが初期化され、その後COMMAND.COMがロードされる。このプロセスは現代のOSとは異なり、ドライバがシェルをロードする責任を持つ点が特徴的である。また、MS-DOS v1.25ではフロッピーにフォーマット情報が保存されておらず、IO.SYSがハードウェアに応じて必要な情報をMSDOS.SYSに渡さなければならない。 ビルドツールに関しては、MS-DOS v1.25のソースにはリンカが含まれているものの、アセンブラが欠けているため、MS-DOS v2.0のバイナリからアセンブラを使用する必要がある。このようにして、最終的にMS-DOSを動かすことに成功したという報告がされている。全体を通して、古いOSを理解し、実際に動かすことへの挑戦が描かれている。
Amazon BedrockとLangChainをサーバレスで動かす！（ついでにフロントも作る！）
この記事では、Amazon BedrockをLangChainと連携させてサーバレス環境で動作させる方法について説明しています。Amazon Bedrockは便利なサーバレスサービスであるものの、LangChainから利用する際にはコンテナランナーが必要ですが、AWSではFargateが唯一の選択肢となります。そこで、この記事では、バックエンドにAWS Lambdaを利用し、LangChainを通じてBedrockを呼び出すシンプルな方法を試みています。また、フロントエンドも構築しており、生成AIを活用することでほとんどコードを書くことなく実装できるようにしています。しかし、結果的にはあまり簡単なプロセスとは言えなくなったようです。 全体の構成は、フロントエンドにReact、ビルドツールとしてvite、バックエンドにはAWS Lambda、FastAPI、LangChain、そしてAmazon Bedrock（Claude3.5 Sonnet）を使用しています。ソースコードはGitHubに公開されており、参考にしたサイトも多く存在します。特に、AWS LambdaとLangChainを組み合わせたストリーミング出力の実現を支える情報が重要でした。 デプロイ手順は、SAM（Serverless Application Model）を利用しており、API_KEYの検証はLambda上で動作するPythonスクリプトによって行われます。具体的には、適当な文字列をAPIキーとして指定し、SAMを使ってビルドとデプロイを進めます。デプロイ後は、CloudFormationからLambdaのARNやFunction URLが表示され、成功を確認できます。 フロントエンドの実装では、tailwindcssを用いてスタイルを整え、メインのコンポーネントであるAIChat.tsxが作成されています。このコンポーネントはユーザーが質問を入力し、Back-endと連携して回答を得る機能を持っています。具体的には、ユーザーが入力した質問をAPIを通じて送信し、得られた回答をリアルタイムで表示します。エラー処理やリセット機能も実装されており、ユーザーの利便性を考慮しています。 最終的に、この記事では一定の機能を持つアプリケーションの構築が可能であることを示していますが、簡単さを求めるのであればStreamlitでの実装がより適しているかもしれません。それでも、生成AIを利用した一連の処理をサーバレス環境で実行する選択肢は有力であると結論づけられています。
Gradioのカスタムパス設定時にはroot_pathを設定しよう
Gradioのカスタムパス設定において、root_pathを設定することが重要であるという経験を共有します。その理由として、使用していたGradioのバージョン4.42.0での問題が発生したことを挙げています。具体的にはDockerを利用し、FastAPIでサーバーを立てた後、Gradioのmount_gradio_appを用いてアプリケーションを組み合わせ、Caddyでリバースプロキシを設定していました。しかし、本番環境にデプロイした際、開発環境やローカルのDockerでは正常に動作していたアプリケーションが機能しないという問題が発生しました。この問題は、カスタムパスでマウントしたアプリケーションのみがGradioコンポーネントを描画するものの、関連する関数が実行されないことに起因していました。 問題のあるアプリケーションのコード例は、FastAPIを使い、Gradioのmount_gradio_appを利用してアプリケーションをマウントする構成になっていました。具体的には、share.main()とmain.main()がGradio.Blocksを返す設定でしたが、リバースプロキシ経由での本番環境では正しく機能しなくなりました。その解決策として、root_pathを追加することが有効でした。具体的には、share.main()をマウントする際に、root_path="/share"を設定することで問題が解決しました。 Gradioの公式ドキュメントによれば、root_pathはFastAPIアプリケーションの公開デプロイメントにおけるサブパスを指定するものであり、プロキシの存在によってリクエストヘッダーにGradioアプリへの完全なパスが提供されない場合に必要になることが説明されています。このように、プロキシが介在する場合にはroot_pathを設定することが推奨されています。最後に、Gradioは非常に便利なツールであるものの、本番環境では予期せぬ問題が発生することがあるため、今後も知見を共有していくことを約束しました。
はじめて React で作った画像ジェネレーター (超バズった) の裏側の話
今回、著者が初めて作成した画像ジェネレーターに関する詳細な裏話を紹介します。このジェネレーターはTwitterで話題になり、10万回以上利用される人気を博しました。この記事では、技術的な側面や課題、工夫について詳しく説明しています。 このジェネレーターの構成技術には、Astro、React、Canvas APIが用いられています。Astroは静的なサイトやクライアントサイドで完結するページに適しており、JavaScriptを排除する設計思想が特徴です。Reactは初めて使用しましたが、以前の素のJavaScriptと比べて複雑な処理が容易にできるため採用しました。Canvas APIはブラウザ上での2D描画に利用されています。 開発中にはいくつかの技術的な課題に直面しました。最初はOffscreenCanvasを使用して画像を生成し、img要素に表示させていましたが、動作が遅く感じられたため、canvas要素でプレビューしながら画像を表示する方式に変更しました。これにより、パフォーマンスが改善され、スムーズな動作が実現できました。 また、ページのレイアウトが読み込み時に不安定になる「レイアウトシフト」を抑制するために、画像生成前にアスペクト比を指定したプレースホルダーを作成しました。これにより、ユーザーにとって快適な体験を提供できるよう努めました。 フォントに関しても工夫が求められました。開発当初はNoto Sans JPを使用していましたが、バズり始めた際に「けいふぉんと」フォントをWOFF2フォーマットに変換するオプションを追加しました。さらに、フォントのサブセット化を行い、転送量の削減に成功しました。 ユーザー体験を向上させるために、ファーストビューに余計な情報を入れず、プレビューを先に表示することで、ユーザーが作成できる画像のイメージを視覚的に伝えました。また、機能をシンプルにし、入力欄の配置を工夫して、ユーザーが迷わないように配慮しました。 画像生成後は自動的に完成した画像が表示されるようにし、ユーザーがスクロールする手間を減らしました。これにより、直感的に操作できる仕組みが整いました。 残された課題としては、Reactの勉強が必要であること、WebP画像の最適化、特定のブラウザでの画像保存の問題、二重縁取りの最適化などが挙げられます。特にReactについては、コンポーネントの役割分担やレンダリング方法の見直しが求められています。 総じて、ユーザーにとって楽しめる画像ジェネレーターを目指し、技術的な課題を克服しながら工夫を重ねてきた経緯が伺えます。興味のある方は、ぜひ試してみてください。
【Treasure2024】凄まじい成長ができた3週間（参加記）
長文の参加記の要約を以下に示します。 この参加記は、株式会社CARTA HOLDINGSのインターン「Treasure2024」に参加したもとすけさんの体験をまとめたものです。インターンは3週間のオフライン開催で、使用技術はフロントエンドがReact + TS、バックエンドがHono + TSでした。初日には顔合わせが行われ、他の参加者との交流を深めることができました。講義内容はDBモデリングやフロントエンド・バックエンドの技術について学び、実際のアプリを使用して実践的な知識を得ることを重視しました。 特に、チーム開発のフェーズに入ると、チームビルディングやコミュニケーションのルール作りに注力しました。また、PDM講義を通じてアイデア出しやDesign Docsの作成に取り組み、チーム内での意見の相違が課題であることを認識しました。アイデア出しには苦労しましたが、最終的には就活に関連するコミュニケーションの課題を解決するアプリを開発することを決定しました。 開発が進む中で、DBモデリングやコードの役割分担を行い、GitHubを活用して進捗を管理しました。チーム全体の雰囲気は良好で、しっかりとしたコミュニケーションが取れていましたが、タイムキーパーや作業見積もりの甘さが課題として浮き彫りになりました。中間発表ではフィードバックを基に、ユーザーが必要とする情報を再考し、制作物の内容を改善しました。 最終発表では、各チームがサービスを発表し、もとすけさんのチームはアイデア賞を受賞しました。賞を獲得した理由として、MVPを見失うことなく、フィードバックを活かした良いサービスが評価されました。しかし、技術的な挑戦が不足していたことや他チームとの比較も行われ、自分たちの成長点を明確にしました。 インターンを通じて、エンジニアとしての考え方やスキル向上の重要性を学び、優先事項を明確にし、チームとの共通認識を持つことの大切さを実感しました。また、インターン期間中には他の参加者との交流もあり、横のつながりができたことも大きな収穫でした。最後に、参加者や関係者への感謝の気持ちを表しています。
Microsoft Authenticatorを使ったMicrosoft 365の多要素認証設定
Microsoft 365の多要素認証の設定について、特にMicrosoft Authenticatorの利用を推奨する内容です。サイバー攻撃が増加している現状を背景に、企業や個人においてもセキュリティ対策が求められています。多要素認証は、M365やAzureなどのMicrosoftのクラウドインフラを安全に利用するために不可欠であり、特にMicrosoft Authenticatorの登録と設定を推奨しています。 この認証アプリの設定は、慣れている人が近くにいればスムーズに行えますが、不慣れな方には手間がかかるかもしれません。そのため、ユーザーに役立つガイドや動画が必要です。具体的には、Microsoft 365 Japanが提供する「学校の先生向け 多要素認証」動画が非常に分かりやすく、一般の利用者にも適用可能です。 また、TEDが提供するサインイン時の詳細情報やアクションが必要な場合のガイドも役立ちます。M365のポータル画面からセキュリティ情報にアクセスし、認証アプリの追加やデフォルトのサインイン方法の設定を行うことが重要です。サインイン画面に表示される2桁の数字を利用して、PCとスマホ間で認証を行う手順も明記されています。 もしMicrosoft Authenticatorが使用できない場合、他の認証方法を登録しておけば代替可能です。多要素認証の利用はアカウントの安全性を高め、Microsoftのレポートによれば、99.2%以上のアカウント侵害攻撃を防ぐことができるとされています。さらに、複数のスマホを登録することで、スマホを買い替えた際の手間を減らし、安心して利用できる環境が整います。 なお、本投稿ではM365を利用する組織側の多要素認証設定については触れておらず、各ユーザーが認証アプリを設定することに焦点が当てられています。組織の設定に関しては別途ドキュメントを参照する必要があります。Azure Active Directory（現在はEntra IDに名称変更）に関する管理者向けの情報も提供されています。
ElixirでText形式の曲を書いて鳴らす 〜 パート宣言をして再利用可能にする〜
この文章は、Elixirを使ってテキスト形式の曲を作成し、それを鳴らす方法について説明しています。前回の内容からの続編であり、主に曲のデータファイル形式の変更と、パート宣言による再利用性の向上が中心となっています。Ubuntu 22.04を前提条件に設定しており、新たにパート宣言を用いることで、曲データを効率的に管理する方法を提案しています。 具体的なファイル仕様としては、part宣言によって再利用可能な曲データを作成でき、main宣言でどのパートを使用するかを指定します。例として、part1、part2、part3が示され、これらのパートの音符データがどのように演奏されるかが示されています。最終的に、実際に演奏されるデータがどのように組み合わさるのかも詳述されています。 ソースコードの部分では、lib/sox.exというファイルにElixirのモジュールSoxが定義されており、音符の周波数や再生時間を計算するための関数が実装されています。具体的には、音符の周波数を変換する関数や、音符を鳴らすためのコマンドを実行する部分が含まれています。また、音符の種類やそのオクターブ、セミトーンに基づく計算も行われています。 実行に関しては、$ mix testコマンドでテストが行われることが示されています。さらに、曲データの具体例として、前回の曲がどのようにパート宣言を使って再利用されるかが示されており、music.txtファイルの内容が詳細に説明されています。これにより、Elixirを使用して音楽データを効率的に管理し、再生する手法が明確に理解できるようになっています。
BedrockにStabilityAIの新たな画像生成モデルが3つ登場しました！
BedrockにStabilityAIの新たな画像生成モデルが3つ登場しました。2023年9月5日にAmazon Bedrockで発表されたこれらのモデルは、現在オレゴンリージョンでのみ利用可能です。新たに発表されたモデルは「Stable Image Ultra」、「Stable Diffusion 3 Large」、「Stable Image Core」の3種類で、それぞれ異なる特徴を持っています。 これらのモデルのパラメータ数は、Stable Image Ultraが160億、Stable Diffusion 3 Largeが80億、Stable Image Coreが26億です。入力方法については、Stable Image UltraとStable Diffusion 3 Largeはテキストまたは画像を受け付け、Stable Image Coreはテキスト入力のみです。タイポグラフィに関しては、Stable Image UltraとStable Diffusion 3 Largeが大規模表示用に調整されているのに対し、Stable Image Coreは異なるサイズやアプリケーションでの汎用性と可読性を重視しています。視覚的美学では、Stable Image Ultraが写真のようにリアルな画像を生成し、Stable Diffusion 3 Largeは非常に詳細な出力を行い、Stable Image Coreは良好なレンダリングを提供します。料金は、Stable Image Coreが0.04ドル、Stable Diffusion 3 Largeが0.08ドル、Stable Image Ultraが0.14ドルとなっており、SDXL 1.0の料金設定と比較すると、Stable Image Coreが標準品質に、SD 3 Largeがプレミアム品質に相当することがわかります。 実際にこれらのモデルを試すために、AWSが提供するブログにサンプルプロンプトが掲載されており、同じプロンプトを使って各モデルで生成した結果を比較することができます。たとえば、「photo, realistic, a woman sitting in a field watching a kite fly in the sky, stormy sky, highly detailed, concept art, intricate, professional composition.」というプロンプトを用い、各モデルの生成画像を確認しました。さらに、特定の文字列を挿入するプロンプトも試すことができ、モデルごとの違いが明確に表れていました。特にStable Image Ultraはよりリアルな出力が得られる印象を受けました。 また、ローカル環境から画像を生成するためには、事前に必要なパッケージをインストールし、コードを実行することで、モデルを選択し日本語でプロンプトを入力することができます。Stable Diffusion 3 Largeは画像から画像生成も可能であり、特定のサイズの画像をアップロードして利用することができます。ユーザーは、アスペクト比や出力フォーマット、生成モードの選択も行えます。 さらに、アプリケーション内で日本語のプロンプトを英語に翻訳し、適切なプロンプトに変換して生成する機能も搭載されています。画像生成の結果は、選択したモデルや生成モードに応じて表示され、生成された画像は指定したディレクトリに保存されます。ブログでは、各モデルのユースケースも紹介されており、広告やマーケティング、電子商取引、メディアとエンターテイメントにおける利用シーンが挙げられています。これにより、ユーザーは各モデルの特性を活かして様々なシーンでの検証が期待できるでしょう。
Astroで window is not defined エラーを解消する方法
Astroで「window is not defined」というエラーを解消する方法について解説します。まず、Astroはサーバーサイドレンダリング（SSR）や静的サイト生成（SSG）を行うフレームワークであり、サーバーサイドでHTMLを生成し、ブラウザに送信した後、ブラウザ上でJavaScriptが実行される仕組みです。このプロセスは「ハイドレーション」と呼ばれます。しかし、サーバーサイドではwindowオブジェクトが存在しないため、サーバー側でwindowを参照しようとすると「window is not defined」というエラーが発生します。 このエラーの解消方法として、まずAstroのclient:onlyディレクティブを使用することが挙げられます。これにより、ReactやVue、Svelteなどのフレームワークをクライアントサイドでのみ実行することができます。具体的には、コンポーネントをclient:onlyディレクティブを用いてレンダリングすることで、関連する子コンポーネントも同様にクライアントサイドで実行されるようになります。 加えて、Vue.jsのonMountedやReactのuseEffectといったライフサイクルイベントを利用する方法も効果的です。これらのイベントは、コンポーネントがブラウザにマウントされた後に実行されるため、サーバーサイドでのエラーを回避しつつ、クライアントサイドでwindowオブジェクトを安全に使用できます。 具体的なコード例として、VueではonMountedフックを使ってブラウザのパスを取得し、ReactではuseEffectフックを使って同様に現在のパスを取得することができます。これらの方法を利用することで、Astroにおける「window is not defined」というエラーを解消することが可能です。 最後に、HRBrainではコミュニケーションデザインエンジニアの採用も行っていることをお知らせします。興味のある方はぜひご応募ください。
トカマク型核融合炉のトーラス内を二方向に高速でパーティクルが流れるアニメーション。
トカマク型核融合炉の内部を表現するために、HTMLとJavaScriptを使用して二方向に流れるパーティクルのアニメーションを作成する方法について説明しています。具体的には、Three.jsという3Dライブラリを利用し、ワイヤーフレームでトーラスを描画し、その内部でパーティクルが流れる様子を実装します。コードでは、シーン、カメラ、レンダラーを初期化し、ワイヤーフレームトーラスを作成してシーンに追加します。また、トーラス内部に1000個のパーティクルをランダムに配置し、異なる速度で二方向に流れるように設定しています。これによりトカマク型核融合炉の動きを視覚的に表現しています。 もう一つの部分では、3D空間上に英語と日本語のPythonコードを浮かせて表示する方法が示されています。ここでもThree.jsを使用し、照明を設定した後、フォントローダーでフォントを読み込んでテキストジオメトリを生成します。英語の「print('Hello, World!')」と日本語の「print('こんにちは、世界!')」のコードがそれぞれ異なる色で表示され、アニメーションを通じてシーン全体を回転させることで、視覚的な動きを加えています。ウィンドウのリサイズにも対応し、常に適切なアスペクト比で表示されるように設定されています。
エンジニアが Git を触ったことがないのはヤバイか？→ヤバイです
エンジニアがGitを触ったことがないのはヤバイかというテーマについて、この記事では客観的事実と個人的見解を述べています。結論として、実務未経験者はともかく、ミドルやシニアポジションのソフトウェアエンジニアが一度もGitに触れたことがないのは確かに問題であるとしています。 まず、バージョン管理ツールとしてのGitの現状について説明しています。10年前からGitのシェアはトップであり、2022年のStack Overflowの調査によれば、職業エンジニアの96.65%がGitを使用しているという結果が出ています。また、GitHubがSVNのサポートを終了したこともあり、Gitの利用はさらに進んでいます。 次に、日本のIT業界におけるGitの利用状況について触れています。自社開発企業ではGitがデファクトスタンダードとなっており、特にWeb系企業ではSVNを使用しているところはほぼ皆無です。しかし、一部のSIerや金融系、公共系の開発現場ではSVNの利用が続いている理由として、Gitの導入コストやリスクの大きさ、承認プロセスの煩雑さ、中央集中的な管理手法の好ましさなどが挙げられています。 SVNが使われ続ける理由としては、学習コストやリスクを重視していること、Gitのような高機能なバージョン管理を必要としないと考えていること、Gitを知ろうとしない人がいることがあると述べています。しかし、個人的には、SVNを使い続けることはあまり良くないと考えており、その理由として分散型管理のメリットを享受できないこと、非効率なチーム開発が進むこと、ソフトウェアエンジニアとしての市場価値が低下する恐れがあることなどを挙げています。 最後に、ソフトウェアエンジニアとして生き残るためには、基本的な知識を身につけ、広く使われる技術やツールに触れることが重要であると締めくくっています。また、必要なマインドセットについても触れ、これを構築することが大切だとしています。
AI Agentを状態機械として表現する
AIエージェントの実装に関する記事では、生成AIを利用したAIエージェントを状態機械として表現する方法が提案されています。従来の非同期関数を組み合わせた実装は、テストの難しさやメンテナンスの複雑さをもたらします。一方、状態機械を用いることで、明確な状態管理が実現し、各状態に関連したタスクやデータを持たせることで、フロー全体が直感的に理解しやすくなります。 具体的な実装例では、RAGエージェントが三つのステップから成るプロセスを経て、ユーザーの質問に応じた回答を生成します。最初に、入力文から検索クエリを抽出し、次にナレッジベースで検索を行い、最後にその結果を基に回答を生成します。この構造では、テストを書く際にモックを利用する必要があり、テストが長くなってしまう問題がありました。 さらに、進捗状況を表示するための工夫も必要です。状態機械を用いることで、現在の進捗を示すメッセージをコード内に集約し、ユーザーに「検索を実行しています」などのメッセージを送信することが容易になります。このアプローチにより、進捗表示に関するエラーを減少させることが可能です。 最終的に、状態機械を使用することのメリットとして、明確な状態管理、テストの容易さ、進捗表示の統合、拡張性とメンテナンス性が挙げられます。これにより、生成AIアプリや複雑な処理の実装が効率的になり、システムが成熟するにつれてその真価が発揮されることが期待されます。最後に、この記事はElmアーキテクチャからのインスピレーションを得ており、興味があればぜひ関連資料に目を通すことを勧めています。
インフラ初心者がつまづいたアカウント運用管理入門
私は24卒として今年春に入社し、7月からインフラエンジニアとしてキャリアをスタートしました。今回は、世界的に使用されているAWSのアカウント管理について、案件に参加する中で学んだことを整理し、皆さんと共有するためにこの記事を書きました。アカウント管理の概要を紹介しますが、具体的な実装方法のような実践的内容は含まれていませんので、その点ご了承ください。また、入門・発展と2段階に分けてアカウント運用管理の手法やサービスを投稿する予定なので、次の記事も読んでいただければ嬉しいです。 まず、AWSアカウントとは何かを確認します。一般的な「アカウント」は個人の情報と1対1で結び付けられていますが、AWSアカウントは一つの環境に似たものであり、個人用のアカウントに相当するのはIAMユーザーです。IAMユーザーが作業する環境、つまりAWSアカウントが存在します。 次に、アカウント運用管理の重要性について考えます。AWSアカウントは一つの環境であり、システムや環境ごとにアカウントを運用管理することで、運用上の優秀性やセキュリティの向上、コスト最適化などのメリットが得られます。これらのポイントはAWS Well-Architectedフレームワークに基づいています。 アカウント運用管理の基本的なサービスであるAWS Identity and Access Management（IAM）について解説します。このサービスは、AWSアカウント内のリソースを利用するためのユーザーや権限を管理します。IAMが管理する要素には、IAMユーザー、IAMグループ、IAMポリシー、IAMロールがあります。 IAMユーザーは、私たちが普段イメージするアカウントに近い存在で、作業を行うためにログインします。IAMグループは、複数のIAMユーザーをまとめて管理するためのもので、ポリシーをまとめて複数ユーザーに適用できます。IAMポリシーは特定のリソースに対する権限を定義し、権限管理の最小単位です。AWS管理ポリシーやカスタム管理ポリシーを用いて、細かく権限を設定できます。IAMロールは、AWSリソース間の操作権限を管理する仕組みで、複数のポリシーをまとめて適用することが可能です。 ここで、スイッチロールというアカウント運用管理手法を紹介します。単一アカウント内でのユーザー管理の他に、複数のアカウントが利用される場合、スイッチロールを使うことでアカウント間を効率的に移動できるようになります。これにより、ログインとログアウトの回数が減り、作業効率が向上します。 最後に、AWSアカウント管理入門についてまとめました。私自身もAWSアカウントとは何かを再確認できた良い機会でした。次回は、IAM OrganizationsやIAM Identity Centerを利用した多くのアカウント管理についてお話しする予定ですので、興味がある方はぜひ次回の記事もお読みください。
独学からチーム開発へ：未経験エンジニアが成長できた勉強法と成功のポイント～何をどのくらい勉強すれば良いのか
私はプログラミングの勉強を始めてから半年後にITエンジニアとして働き始め、現在はフロントエンドとバックエンドの開発を担当しています。入社から3ヶ月が経過し、Laravelを用いたアプリ開発で、独立してタスクを完結できるようになりました。趣味の筋トレを生かし、PHPとMySQL、Twigを用いて、ユーザーがトレーニング記録や目標を管理できるアプリケーションを開発しました。この記事では、プログラミングを始めたきっかけや勉強法、成長過程を振り返り、特に初学者に役立つ情報を提供します。 私のプログラミングへの挑戦は、前職の人材派遣営業で、多くの企業がエンジニアを募集していることに気づいたことがきっかけでした。未経験者でも高給で、キャリアアップが可能であることから、プログラミングの勉強を始めることを決意しました。最初は何を学べばよいのか分からなかったものの、前職の同僚から「Progate」という学習アプリを薦められ、これを使って勉強をスタートしました。平日は1〜3時間、休日は3〜6時間を勉強に充て、HTML、CSS、JavaScript、PHPを学びました。 Progateでの学習を繰り返す中で、簡単な機能を作成することに挑戦し、YouTubeを参考にしてJavaScriptで入力フォームを作成しました。さらに、Reactに興味を持ち、さまざまなリソースを使って学びを進め、筋トレ用の入力フォームを作成しました。約1ヶ月半の勉強の後、面接用に成果物を作成する必要があり、Docker環境でLaravelとReactを使用して筋トレ記録アプリの開発を始めました。 内定を受けた後の約2ヶ月間は、前職の引き継ぎ業務とともに、運営している「無料PHPスクール」に参加しました。このスクールでは、初心者向けの講義が行われ、面接対策やコードレビューも行われるため、非常に役立ちました。講義を受ける前は、1つのファイルのコードを読むのも難しい状態でしたが、講義を通じて理解度が深まり、入社に必要な知識を身につけることができました。 入社後は、「無料PHPスクール」の講師やメンターとしての経験を通じて、アウトプットの重要性を実感しました。特に、講義でのコードの説明や復習が、私の知識を深める助けになりました。また、チーム開発での経験を通じて、コードの見やすさや一貫性を意識することが重要であると感じました。Gitの使い方も学び、プルリクエストやマージなど、チーム開発での実践的なスキルを身につけました。 その後も、APIの作成やテストコードの作成などを通じて、Laravelの知識を深め、更なる成長を遂げました。約9〜10ヶ月前にプログラミングを始めた私が、今では1つのアプリケーションを作成できるまでに成長し、自信を持ってチーム開発に参加できるようになりました。 最後に、私が特におすすめする勉強法は、作りたいものを決めてから勉強を始めることです。具体的な目標を持つことで、モチベーションも高まり、学習効率が向上します。また、コーディングに慣れてきたら、チーム開発を意識することが重要です。Gitを使って成果物を作ることも、実践的なスキルを身につける助けになります。 私の経験が、プログラミングを始めようとしている方や学び直しを考えている方に少しでも役立てば幸いです。これからも新しい技術に挑戦し続け、自分の成長を信じて歩んでいきましょう。あなたのプログラミング学習が成功することを心から願っています。
【PHP/Docker/Twig】初めて生PHPのアプリケーション作成してみた【Pスク生必見!?】
この文章では、著者が初めてPHPを用いてアプリケーションを作成した経験をまとめたもので、主に全体の構造やモデル、コードの書き方に注目しています。著者は以前はReactやJavaScriptを扱っていたが、バックエンド言語であるPHPには初めて触れたため、様々な難しさやわからないことに直面しました。特に、Dockerとの連携やGDライブラリの使用に苦労しつつ、他の初学者向けに役立つ情報を提供したいと考えています。 アプリケーションの機能としては、画像一覧や検索、ユーザー登録、ログイン、マイページ、画像投稿、購入、ダウンロードなどが挙げられます。また、アプリケーションのディレクトリ構成やDockerの構築手順も詳細に説明されており、docker-compose.ymlやDockerfileの作成、MySQLの初期テーブル設定などが含まれています。 特にMVCモデルに基づいた構造が強調されており、Controllerの役割やデータベースとのやり取りの方法についても触れています。著者は、PHPのクラスを用いてControllerの機能を実装し、コードのクリーンさを保つことの重要性を訴えています。また、開発のきっかけについても言及し、模倣から始めてオリジナルアイデアを育てていくプロセスが重要だと述べています。 最後に、著者はPHPの初体験における戸惑いや苦労を振り返りつつ、次回はReactとLaravelを組み合わせたアプリケーションの構築に挑戦する意欲を示しています。このような経験から、他の開発者にも自分のアイデアを形にしていくことの楽しさを伝えたいと考えています。
Qiita アップデートのお知らせ - 2024年8月
Qiitaは、エンジニアの声をもとに開発を続けており、2024年8月に行ったアップデートを紹介しています。リリース内容は、リリースノートやQiita公式Twitter、Qiita Blogでお知らせしており、質問や機能の要望はQiita Discussionsで受け付けています。 8月29日のリリースでは、スクロールバーの色を背景とのコントラスト比を改善し、視認性を向上させました。また、8月15日には絵文字パネルの操作性を向上させ、矢印キーでカテゴリーや絵文字一覧の移動が可能になりました。加えて、記事や質問執筆に役立つキーボードショートカットの記事が作成され、活用が促されています。 同じく8月15日には、検索結果ページに検索結果件数を表示する機能が追加され、ユーザーが現在のページで表示中の件数を確認できるようになりました。さらに、8月7日には検索結果一覧の記事カードのアクセシビリティが改善され、低コントラストのアイコン色がAA基準を達成するよう変更されました。 最後に、8月19日のリリースでは、記事投稿完了時に表示されるモーダルウィンドウにQiitaの機能紹介が追加され、ユーザーが興味を持つ機能を試す機会が提供されています。これらのアップデートは、ユーザーエクスペリエンスを向上させることを目的としており、活用を促しています。
テックカンファレンス初心者がiOSDC Japan 2024に現地参加してみて
テックカンファレンス初心者が参加したiOSDC Japan 2024についての体験談です。著者は初めての現地参加で期待以上の楽しさと学びがあったと感じ、特に初心者こそ参加する価値があると伝えたいと述べています。これまでテックカンファレンスに参加したことがなく、iOSアプリエンジニアとしての経験も浅かったため不安があったが、実際に参加することで得たものが多かったと振り返っています。 参加の動機としては、技術力向上の足がかり、自社による参加サポート制度の利用、そして参加自体がプラスになると考えたことの3点が挙げられています。特に社内の技術者が多く参加していることが心理的なハードルを下げたと感じています。 実際の参加体験では、参加者が多く、会場の雰囲気が賑やかだったこと、食事が充実していたこと、そして「お祭り」のような楽しい雰囲気が印象に残ったと記しています。セッションの内容も非常に良く、自分でも理解できるポイントが多かったと述べ、現地参加がオンライン参加よりも集中しやすいと感じました。 また、セッションを通じて未知の単語や概念を知り、技術力向上に繋がると期待しています。さらに、他のiOSアプリエンジニアとの交流を通じて、自分のロールモデルを見つけたり、懇親会での貴重な経験を得たりしたことも報告しています。最終的に、iOSDCを通じて自身の成長を感じ、来年も再