タグ

ブックマーク / qiita.com (1,050)

  • Dockerのコンテナイメージを1/10以上軽量化してみた - Qiita

    はじめに VSCode + Python + Poetry + Docker(docker-compose)でdev-containerを作成して開発を行っていました。 Dockerを勉強し、イメージの軽量化に関する記事を読んでいると、自分が使っているコンテナイメージのサイズが気になりました。 docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > dev-container latest a9b8e3df9087 2.31GB 2.31GB!? サーバとしてアプリを動かしていないのにここまで大きいなんて… というわけで勉強も兼ねて、イメージの軽量化に取り組みました。 イメージが軽量であるメリット ストレージの節約 これは言わずもがなだと思います。 限られたリソースを有効に使うことができます。 ビルド時間の短縮 Dockerは環境を作っ

    Dockerのコンテナイメージを1/10以上軽量化してみた - Qiita
  • 入力欄のプレースホルダーって結局どうなの - Qiita

    入力欄のプレースホルダーの話をします。プレースホルダーというのは、フォームの入力欄で、ユーザーが入力するまでの間に表示されているテキストのことです。 書籍「Webアプリケーションアクセシビリティ1」では、「3.1 ラベルと説明」のところで、紙版にして約1.5ページの分量を割いて、フォーム入力欄のプレースホルダー(<input> 要素や<textarea> 要素の <placeholder> 属性)の問題点を指摘しています。 こので指摘されているプレースホルダーの問題点は以下の3つです。 プレースホルダーの色が薄く視認しづらい プレースホルダーとフォームコントロールの値との区別がつかない フォームコントロールに値を入力したときにプレースホルダーの値が見えなくなってしまう Webアプリケーションアクセシビリティ さらに、Nielsen Norman Groupによる「Placeholders

    入力欄のプレースホルダーって結局どうなの - Qiita
  • プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita

    はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ

    プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
  • 元QAが開発チームにjoinして品質向上を試みたこと3選 - Qiita

    はじめに どうも、元QAのエンジニア @Syahu_Writer です。 今回は、元QAが開発チームにjoinしてから行った品質向上のための施策について紹介していきます。 大なり小なりいろいろとやってますが、代表して以下3つを話します。 ・開発プロセスの改善 ・シナリオテストケーステンプレートの改善 ・不具合の再発防止 開発プロセスの改善 以下は当初の開発フローを図に書き起こしたものです。 この図から読み取れる問題点はざっくりと、 ・すべて直列のフローだが、並列処理にしていいものも混じっている ・テスト完了レビューといった、不要で実際に行われていないものがある ・レビューのタイミングが悪く、大きく手戻りが発生する箇所がある という状態でした。 それを以下の通り修正しました。 ・並列にして問題ないものは並列にする ・不要なプロセスは削除する ・手戻りが最小限となるようにレビューを設置する ま

    元QAが開発チームにjoinして品質向上を試みたこと3選 - Qiita
    ikosin
    ikosin 2024/04/30
    “「今見えている地雷をまず撤去する」「マイナスを0にする」”
  • より良い Git コミットメッセージを書こう - Qiita

    より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか? それについて掘り下げていきたいと思います。 基的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール (「How to Write a Git Commit Message」の和訳記事) https://

    より良い Git コミットメッセージを書こう - Qiita
    ikosin
    ikosin 2024/04/30
  • 生産性における即レスの大切さ - Qiita

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

    生産性における即レスの大切さ - Qiita
  • スクラムを失敗させる51のアンチパターン - Qiita

    スクラムは基的にはスクラムガイドに背くことで失敗しやすくなります。 そんな中でもよくあるアンチパターンと一言解説をまとめました。 スクラムマスター(SM)の失敗 SMがDevを兼任する スクラムマスターの仕事はそうなくならない どちらかの作業が片方の作業のボトルネックになる Devとしての作業量が不安定でベロシティが計画に使いづらくなる SMがチームに奉仕していない サーバント・リーダーシップがない SMはチームが抱えるあらゆる障壁の解消に努める(全部自分でやらずとも周りと話をする) SMがチームを管理している 管理は自己組織化につながらない、Devに自発的に動いてもらうための手助けはOK SMが妨害リスト(impediment list)を管理していない チームが直面するあらゆる障壁をリスト化し管理する 優先順位が高いものからSMが順に対応することでチームは円滑に作業ができる SMがス

    スクラムを失敗させる51のアンチパターン - Qiita
  • 開発生産性について議論する前に知っておきたいこと - Qiita

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

    開発生産性について議論する前に知っておきたいこと - Qiita
  • メンバーレイヤーから 開発生産性向上 を始めるために - Qiita

    はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ナンモワカラン ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には3つのレベルがあることを知る な

    メンバーレイヤーから 開発生産性向上 を始めるために - Qiita
  • 『Winny』の金子勇さんの失われたED法を求めて - Qiita

    普段は「通知が迷惑かなー」と思ってブックマークしていただいている方に通知せず記事を編集しているのですが、この記事をブクマしていただいている方は続きが気になっている方だと思いますので通知させていただきます。 結論から言うと、この記事を読んだ @pocokhc (ちぃがぅ)さんという方が金子勇さんが書いたED法のサンプルプログラムを見つけてくださいました。 ちぃがぅさんの記事はこちら 自分で解明したかったという気持ちも無いことは無いですが、バズった時点で誰かが実装してくれそうな気はしていました。新卒からIT業界に入って4年目が始まったところですが、業務以外で初めて業界にコントリビュートできた気がして嬉しいです! 追記ついでに、謝罪します。初回公開時に記事タイトル含め文中で何か所か「Winney」と書いてしまっていた箇所がありました。失礼いたしました。誤字修正してあります。指摘してくださった何

    『Winny』の金子勇さんの失われたED法を求めて - Qiita
    ikosin
    ikosin 2024/04/17
  • Dockerコンテナ化したJavaアプリのヒープのサイズ調整オプションの検証 - Qiita

    はじめに こんにちは。私は弊社で企画・運営している、Dot to Dotという個人の同意の元に様々なデータを連携することができる分散型データ連携プラットフォームの開発・保守を担当しています。 Dot to Dotではデータ連携をしたい事業者向けに、データ連携用の通信モジュールを、Spring Bootを使用したJavaアプリケーションとして作成したDockerイメージ形式で配布しています。 昨今ではDockerでアプリケーションを実行するのが当たり前の風潮になりつつありますが、実際に番で適用する際に必要なチューニングの話はあまり聞かないかと思います。 そこで記事では、JavaアプリケーションをDockerコンテナで運用する場合に必要な、ヒープのチューニングについて説明します。これからJavaアプリケーションをDockerコンテナ化して運用したい人や、すでに運用中でもヒープチューニングし

    Dockerコンテナ化したJavaアプリのヒープのサイズ調整オプションの検証 - Qiita
  • ふりかえりを更に拡張する「ふりかえりカタログ(コミュニティ版)」 - Qiita

    はじめに あなたのふりかえりを更に拡張するふりかえりカタログ(コミュニティ版)を公開いたします! ふりかえりカタログ(コミュニティ版)は、ふりかえりの手法(現在)84個とその特徴を網羅したカタログです。下記画像はイメージです。 Miroにて作成したものをどなたでも利用可能です! 利用はこちら => ふりかえりカタログ(コミュニティ版) 2021年1月にpdf版/speakerdeck版でリリースして以降、なんと約8万viewと、長く多くの現場にご利用いただいています。そちらを、より使いやすく、みんなで編集できる形にしたものが今回のコミュニティ版です。 過去バージョンのDLはコチラ => ふりかえりカタログ(SpeakerDeck版) ふりかえりカタログ(コミュニティ版)とは ふりかえりの様々な手法をまとめたカタログです。 ふりかえりの各手法を「手法名」「手法を使う場面」「手法のイメージ」「

    ふりかえりを更に拡張する「ふりかえりカタログ(コミュニティ版)」 - Qiita
  • 1年前の自分が読みたかった、データエンジニアリング入門 - Qiita

    はじめに 記事は、trocco® Advent Calendar 2023の9日目の記事になります。 trocco®だけを取り上げるわけではありませんが、この内容をおさえておくとその価値や使い方が理解しやすいと思いますし、もちろんユーザー以外でもデータエンジニアリング入門として読んでいただければと思います。 さて、私は今年の2月にtrocco®を提供する株式会社primeNumberに転職し、現在はtrocco®を利用したデータパイプライン/BIツールによるダッシュボード構築などを行っています。 前職は広告代理店でTableauを使ったマーケティングデータ分析を行っていたのですが、総合職の異動でたまたまデータ関連部門にいただけですし、プログラミング経験もなかったので、異業種異職種への転職でこの1年はめちゃくちゃ勉強をしてきました。 エンジニア出身の方向けには、『実践的データ基盤への処方箋

    1年前の自分が読みたかった、データエンジニアリング入門 - Qiita
  • バッチ処理について考える - Qiita

    TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万~数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ?ネットににも答え載ってないよ?低レイヤも意識しないと動かないよ? 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや

    バッチ処理について考える - Qiita
  • たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita

    はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話: この記事の旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは?リファクタリング耐性低くない?みたいな話は度外視してます。

    たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
  • GPT-4よりすごいらしいClaude 3が気になったあなたへ - Qiita

    Claude 3、気になりますよね 今まで触ったことないけど、興味を持った方へ、入門するところまでのご案内です。 とりあえずチャットがしたい claude.aiにアクセスして、アカウントを作成します。 メールアドレスを入力する方法と、Googleのアカウントと紐付ける方法があります。 私はGoogleアカウントとの紐づけを行いました。 ログインができたら、もう、チャットができます。ChatGPTのような感じです。 日語も自然に回答してくれます。 左下にClaude 3 Sonnetとあります。これはClaude 3のモデルの名称で、SonnetはClaude 3のシリーズの中で真ん中のモデルです。 Haiku - ハイク Sonnet - ソネット Opus - オーパス 名前からモデルの特徴を想像してもらいました。概ね特徴を捉えているのではないでしょうか。 Claude 3の特徴として

    GPT-4よりすごいらしいClaude 3が気になったあなたへ - Qiita
    ikosin
    ikosin 2024/03/10
  • AWSの生成AIで社内文書検索! Bedrockのナレッジベースで簡単にRAGアプリを作ってみよう - Qiita

    この記事について AWSコミュニティ最大級のイベント「JAWS DAYS 2024」内のワークショップにて実施したハンズオンコンテンツとなります。 イベントでは口頭で説明しながら実施しますが、この記事さえ読めば誰でも体験できるように作っていますので、当日イベントにお越しになれない方もぜひご活用ください。(スムーズにいけば30分程度で完了します) ハンズオンの実施にあたり、多少の課金(数十円〜数百円以内)が発生することをご了承ください。実施後には忘れず不要なリソースの削除をお願いします。 なお、Bedrockのモデル呼び出し料金はAmazon製のTitanシリーズを除き、マーケットプレイス扱いとなるためAWSクレジット(クーポン)の適用範囲外となります。 ※事前にAWSアカウントの作成をお願いします。クレジットカード情報が必要です。ログイン用のEメールアドレスとパスワードをお忘れなく! 0

    AWSの生成AIで社内文書検索! Bedrockのナレッジベースで簡単にRAGアプリを作ってみよう - Qiita
    ikosin
    ikosin 2024/03/10
  • AtCoder に登録したら次にやること ~ これだけ解けば十分闘える!過去問精選 10 問 ~ - Qiita

    記事を終えた次は? AtCoder Beginners Selection を終えたら、AtCoder 上の過去問が AtCoder Problems に集大成されていますので、片っ端から埋めるような気持ちで精進していきましょう。記事の続編として AtCoder 版!蟻 (初級編) AtCoder 版!蟻 (中級編) AtCoder 版!蟻 (上級編) AtCoder 版!蟻 (発展的トピック編) も執筆しましたので参考にしていただけたらと思います。また、アルゴリズムとデータ構造に関するトピックを集大成した書籍として、 問題解決力を鍛える!アルゴリズムとデータ構造 (通称、けんちょん) を上梓しました。ぜひ読んでみてください。 1. AtCoder とは AtCoder は以下のコンテストサイトを運営しています。今後常に訪れることになるサイトです: AtCoder コンテスト

    AtCoder に登録したら次にやること ~ これだけ解けば十分闘える!過去問精選 10 問 ~ - Qiita
  • 祖母が就寝するとDBインサートができなくなる - Qiita

    世の中には、一見関係なさそうな物理現象がITシステムに不可思議な影響を及ぼすことがあります 例えば,500マイル以上離れた場所にメールが送れないという話だったり 中国人のAさんがお茶を入れると会社のネットが繋がらなくなる という話があります。 私の場合は、祖母が就寝するとDBインサートが失敗する、という状況でした 実家の見守りシステム 問題が起きているのは、離れた実家にいる一人暮らしの祖母の状態を見守るために作成した自作のシステムです。 気温や湿度、CO2濃度、明るさ、部屋のドアの開閉、冷蔵庫の開閉の状況をモニタリングできるようにしています。 Raspberry Piに各種センサが接続され、定期的にInfluxDBに送信し、Grafanaという可視化ツールでいつでも見られるようにしています。 これらの情報を見ることで、祖母の家の部屋の温度が適切か、活動しているか、部屋にいるかなどが分かりま

    祖母が就寝するとDBインサートができなくなる - Qiita
  • 2023年に見つけたあまり知られていない便利VSCode拡張4選 - Qiita

    はじめに この記事では、2023年に見つけた、Visual Studio Codeで開発作業を効率化するための便利な拡張機能4つを紹介します。 これらの拡張機能は、共通してあまり有名ではないためあえて紹介しようと思います!! 実施内容 紹介するのは以下の4つの拡張機能です。 Multi Cursor Case Preserve VSCode JS Console Utils Laravel Goto Config NPM Dependency Links これらの拡張機能は、それぞれ異なるニーズに応えるものです。 準備 Visual Studio Codeをインストールしておく必要があります。 各拡張機能をVisual Studio Codeのマーケットプレイスからインストールします。 実装手順 Multi Cursor Case Preserve VScodeを使って命名の変更があった場

    2023年に見つけたあまり知られていない便利VSCode拡張4選 - Qiita