はじめに みなさんは、フォームなので必須項目が入力されてない時、Submitボタンに disabled をつけて押せないようにしていませんか？ この記事では、ボタンにdisabled属性をつけない方がいい理由とdisabledをつけない方法を紹介します。 disabled属性をつけない方がいい理由 disabled 属性をつけると、ユーザーがボタンを操作することを防ぎます。 そのため、キーボード（Tabキー等）で操作している時フォーカスが当たらないため、ボタンの存在が認知できません。 disableがない時 disableがある時 ボタンの存在が認知できないため、支援技術（スクリーンリーダ等）で操作しているユーザーにとって、「送信ボタンどこだろう？」と思ってしまったり、「なんで送信ボタンが出てこないんだろう？」と思ってしまい、操作を完了させることができなくなります。 aria-disabl

はじめに 何回も個人開発に挑戦しては失敗してきた自分が、ようやく安定的に月間5万人くらいが使うサービスを作ることができました。 この記事を通じて、個人開発のアイデアからリリースして運用するまでの流れを紹介し、同じように個人開発に挑戦している方々にとって、少しでも参考になる情報を提供できれば嬉しいです！ アイデアから実現までのステップ 1. アイデアの発想 自分の場合は、シンプルに自分が欲しいと思ったのがきっかけでした。趣味的なサービスなのですが、こんなのあったら便利なのにと思い、まだ世の中にサービスとして存在していなかったので作ろうと思いました。 このように日頃からアンテナを張ったりして、解決したい問題やこんなのがあったら便利ではないかなどアイデアを出します。 ブレインストーミングや本を読んだりとアイデアの出し方は色んな手法があるので、自分に合った方法で見つけるのが良いかと思います。 2.

本記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう！ はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から

Open WebUIを使ってみました。 https://openwebui.com/ 当初は「Ollama WebUI」という名前だったようですが、今はOpen WebUIという名前に変わっています。Ollama専用じゃなくなったということでしょう。OpenAIに対応済みです。 早速使ってみました。もちろんBedrockで。 6/11 続編を書きました。 環境構築 Dockerですんなり構築です。Bedrockに対応はしてないので、「LiteLLM」を使って対応させます。 環境変数でこのあたりを指定 Ollamaを無効化 LiteLLMのエンドポイントをOpenAIのエンドポイントとして登録 APIキーを登録（LiteLLMとの通信には不要ですが、未指定だとOpen WebUIが正しく動作しませんでした） services: open-webui: image: ghcr.io/open-

はじめに 昨今「開発生産性」についての話題をよく目にします。 生産性が向上することで悪いことは無いので、様々な組織の事例が公開されて業界全体に知見が共有されていくことはとても素晴らしいことだと感じています。 話題のこちらの本 「世界一流エンジニアの思考法」にもとても大切なことが書かれておりますし こちらの記事も参考になりました。 それらを踏まえて個人的に生産性向上のベースになる大切なことだと思っている 「即レスの大切さ」 について書きたいと思います。 これまでやってきたお仕事 ツールアプリの新規事業責任者（3年ほど） 全体3名の少人数チームでスタート 私（責任者+PdMの役割）、エンジニア1名、デザイナー1名 最終的には30人前後の組織の事業部長 ゲームアプリのマーケティングマネージャー（5年ほど） 組織全体としてはビジネスサイド20名、エンジニア5名、デザイナー5名ほど 会社経営（4年ほ

はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要

この書き方でも for 文は正常に動作します。 しかしながらこの書き方は 以下の書き間違いが生じることがあります。 for(var i = 0; i < array1.length; i++) { //長い処理 for(var i = 0; i < array2.length; i++) { } } 長い処理の中で i を宣言したことを忘れて 再び i を宣言してしまうことで 外側の for 文のカウントにバグが発生し 期待した動作にならない例になります。 私も他の人が作成した web アプリで このバグを見かけたことがあります。 for の変数を宣言する場合 必ず let で宣言して下さい。 var でなければ正常に動作しないのは 構造的欠陥のハズです。 let array1 = [1, 2, 3]; let array2 = [4, 5, 6]; for(let i = 0; i <

生成 AI の登場によって、僕らはプログラムを書く時代が終わりに近づいている？！ 2023 年に OpenAI 社が発表した ChatGPT は、特に僕ら IT エンジニアにとって衝撃な発表だったのではと思います。 今まで、ググったり、参考書をもとに実装したり、GitHub などからコードを参考にして実装していたものが、「テキストだけ」で実装できるほどになりました。 生成 AI を用いたサービスやツールの登場 ChatGPT の GPTs や LLM、これらを用いたプロジェクトが研究・開発されたり、オリジナル GPT を作成して業務の効率化を図ったり、僕らの仕事は大きく変わっていきました。 また、プログラミングが全くわからなくても、プロンプトのみでいろいろなことができるようになりました。 ビジネスシーンで非エンジニアという方々にも、導入が進んでいるのではないでしょうか？ 僕がウォッチしてい

なぜあなたの共通化は間違っているのかの目次はこちら はじめに この記事では、ついに単一責任原則をより詳しい言葉で説明します。これにより、本連載の目標である 「どうしてあなたの共通化は間違っているのか」をより理論的・体系的な言葉で言語化することが可能になります。これは、設計のバグがソフトウェアの成長によって顕在化して明らかになる前に、理論によって設計ミスを検出してソフトウェアの品質を高められるということです。ソフトウェアアーキテクトにとっては非常にうれしい理論的な結果になると思います。 いいね・ストックが励みになります！ 新・単一責任原則 第1章で述べた通り、単一責任原則とは、設計単位は責務・関心事をただひとつだけ扱うべきだという原則です。この連載では、この原則についてより解像度を高めるために、抽象度と文脈という概念について詳しく解説してきました。この概念を利用することで、単一責任原則は以下

Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル）oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？ 帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなどをDBに保存する オライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz

Slack Slack は必要なメンバーから情報、ツールまで一元化するメッセージプラットフォームと、そのアプリ開発用プラットフォームを提供しています。

この記事はNuco Advent Calendar 2023の4日目の記事です。 弊社では、経験の有無を問わず、社員やインターン生の採用を行っています。 興味のある方はこちらをご覧ください。 はじめに 後輩に 「なぜ0.1+0.2≠0.3になるんですか？」 と聞かれて答えられますか？ コンピュータの計算では「0.1+0.2」は「0.3」になりません。 これを理解していないと予期せぬ重大なバグを生み出す可能性があります。 分からない方、どうぞ安心してください。 この記事を読んだ全員が「0.1+0.2≠0.3」を理解できるように分かりやすく説明していきます。 コンピュータが計算を間違う理由 まず、そもそも「0.1+0.2=0.3」で正しい！「0.1+0.2≠0.3」なんてあり得ない！ という方のために、プログラミング言語のフォーマット処理を経ない、コンピュータの計算結果を見てみます。

ドラえも⚫︎で理解するCSRF はじめに ※コメントにて徳丸浩先生(@ockeghem)に間違いをいくつかご指摘頂き修正中です。 また、@rudorufu1981様よりブラウザの同一オリジンポリシーについての補足を頂いております。 ぜひ記事の下部、コメント欄までご覧頂きますようお願いいたします。 ご指摘や補足、本当に有難うございます。 【追記2023.12.2】 同一オリジンポリシーの補足についても徳丸先生のご見解コメントを頂いております。ぜひそちらもご確認下さい。 【追記2023.12.5】 ご指摘を受けて同一オリジンポリシーはCSRFと直接の関連はない事から、取り消し線にて削除致しました。 対象読者 ・HTTPの特性 ・セッション管理 ・ブラウザの同一オリジンポリシー ・CSRF(Cross-Site Request Forgeries) ⚫︎上記の言葉を聞いてイメージができない人 ⚫

予防線 勘違いされそうなんで先に書いておきますが、私は!派です。 前提 ifの条件式の部分で真偽値ではない値を他の値と比較せずに書くことを禁止するコーディング規約があるとします。 trueと比較する愚かさ

英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について 最初の記事にも書きましたが、日本を離れて１０年以上、外資系の企業にて外国人と働き、または交渉事などをまとめ、何処に行ってもそれなりに不自由しない英語力を獲得し、さらにロックダウン中から２年あまり、毎日毎晩独学でコードを書き続けたことによって獲得したプログラミングスキルによりウェブアプリなどを自作できるようにまでなった訳ですが、そうして身につけた能力をフルに生かして条件の良い働き口を見つけてこましたろ　と思った時に、そういった能力が身を助けるどころか、よりレッドオーシャンの荒波に我が身を晒すことになったことに気付き、愕然としてこの記事を執筆しています。 英語ができることによって競争が激化 例えば、自分は英語も話せて、プログラミングも出来ますよ　となった場合、勿論グローバルな企業にて雇用されることを期待する訳ですが

はじめに 先日こんなツイートを見かけました。 期待値を大きく外してきた成果物に対してどのように対応するかという問題についてのツイートでした。 このツイートのレビュー依頼者は「まずい点」を指摘してもらって修正すれば成果物として成立すると考えているけれど、レビュワーから見ると評価できる点がなくこのままでは成果物として成立させることができないと考えているように読み取れます。 7-8割程度期待値を満たしているものに対してのレビューであれば、レビューによって修正して成果物として成立させることができ、また、考え方を伝えることで次回からの成果物の質も上げられるでしょう。 一方で、期待値を全く満たしていない成果物に対してのレビューは、レビュワー、レビューイともに大きな苦痛を与えます。 懸命に作ったものを跡形なく直されるのは辛いですが、懸命に作ったものを跡形なく直すのも同じぐらい辛いです。 7-8割程度期待

はじめに これはCyberAgent 19新卒 エンジニア Advent Calendar 2018の11日目の記事です。 リーダブルコードを3年ぶりに読み返してみたお話をします。 リーダブルコードを読み直してみた つい先日、友達が「リーダブルコードを数年ぶりに読み返してみたけど、やっぱりバイブルだな」みたいなことを言っていました。 僕もエンジニアになったばかりのころ、先輩にリーダブルコードを渡されました。読んで感動した覚えがあります。あれから一度も読んでいないリーダブルコードをもう一度読み返してみたくなりました。 そうしたら、なんと、、、当時は様々なテクニックの寄せ集めだと思っていた本から、たった1つの大原則が浮かび上がってきました。 それは、 正しく命名せよ たったそれだけです。 「コードは他の人が最短時間で理解できるように書かなければならない」と、リーダブルコードは述べています。そし

概要 この記事では、エンジニアにとって重要な、 「良いコードとはなにか？　どうすれば良いコードが書けるのか？」について、 基礎の考え方から、私なりに頑張ってまとめて記載してみようと思います。 ターゲット 新卒～１年目のエンジニア向けにわかるように、なるべくかみ砕いて説明をしようと思います。 第1章：良いコードとは？ まず初めに、良いコードとは何でしょうか？ ここでは会社に所属するエンジニアの視点から考えてみましょう。 会社に所属するエンジニアに求められるのは、 利益のあるソフトウェア（ゲーム） を作ることです。 言い換えれば、良いコードとは ソフトウェア（ゲーム）が生み出す利益を最大化するためのコードと言えます。 ここから、推論を進めてみましょう。 ⇒　良いコードとは？ ⇒　ソフトウェア（ゲーム）が生み出す利益を最大化するコード ⇒　利益を最大化するためには？ ⇒　少ないコスト（時間・人件

( 2022年、仕事中であった事例からいろいろまとめた資料を Qiita に記載 ) 私は自社開発の会社に勤めるサーバーサイドエンジニア。 去年(2022年)、フロントエンドエンジニアが書いてたHTMLを見てたら以下のようなコードを見つけた。

はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間