ローカルテスト用SMTPメールサーバは Mailpit がオススメ！ - Qiita
はじめに 長らくローカルテスト用のメールサーバとして MailHog (DockerHub) を使ってきたのですが、以下のような不満がありました。 今現在(2024)メンテナンスが行われていない ローカル開発用とはいえ、UXが厳しい（日本語を受け付けてくれない） アーキテクチャが amd64 しか対応していない そこで、MailHogよりベターな選択肢はないか調査してみたところ、 Mailpit (DockerHub) が以下の点で良いと感じ実際に使っているので、この記事で紹介します。 今現在(2024)メンテナンスが行われている 良いUX。ちゃんと日本語でメールを検索できる アーキテクチャとして arm にも対応している (amd64/arm64/i386) ほか好ましい点 サーバ再起動後にちゃんとデータが残る (sqlite形式で残るようです) Goで実装されていて動作が軽い Goなの
チームにテストコードを書く文化を定着させる - Qiita
この記事は？ 皆さんお久しぶりです。@cosmeの開発エンジニアをしております、村田です。@cosmeを運営する株式会社アイスタイルではPHP -> TypeScriptへの技術移行を進めており、フレームワークとしてはexpress, oclif, そして本記事で紹介するJavaScript製のテスティングフレームワークであるjestなどの各種ツールを使って開発を進めています。 この記事で紹介する内容は、チームでテストコードを書く文化を定着していく話です。というのも、既存プロダクトにて元々テストコードが十分に書かれていない部分があったため、リプレース後のサービスではしっかりとテストを書いていこう、ということでチームで一致団結しました。今まではテスト記述に対する基準は開発者によって任されていたところ、私の担当しているバックエンドのプロジェクトでは、テスト記述の優先度を高くしてリリース基準とし
要件定義｜3分で読める非機能要件について - Qiita
はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義関連の記事の投稿をしました。時間あればぜひ読んでみてください。 今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。 非機能要件｜6項目について 1. 可用性 システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており
メモ帳でコーディングしていた話 - Qiita
はじめに ひとこと アクセスしていただきありがとうございます。 タイトルの通りの、メモ帳でコーディングしていた話です。 タメになるかどうかは分かりません。 目的 メモ帳でコーディングしていたことで得られた知見を共有すること（） 検証済みの環境 Windows11 Home x64 メモ帳 ご注意 この記事の情報は 2024/08/26現在 のものです 1.前書き 筆者は高校に入学したと同時に、部活でプログラミングを始めました。 HTMLとCSSを一通り学習し、一人で簡単なウェブページをつくれるようになりました。 そして自然とウェブページに機能を実装したいと思うようになり、JavaScriptの学習を始めました。 （今もですが）ここまで独学だったこともあり、一度、挫折しながらも百人一首を4択から選んで覚えるウェブアプリをつくり、高校で公開しました。 その後も学習を続け、高校2年生の夏ごろに全
Python理事会が古参開発者を追い出して開発者コミュニティが騒動に - Qiita
どういうわけか日本では一切話題に上がっていないのですが、Pythonの開発者コミュニティでなんか問題が起きているようです。 どうも話が様々なスレッドにとっ散らかっているうえに半分はDiscordや非公開のところで動いているみたいなので、読み取れていないところが色々あるかもしれません。 誰かが補足してくれるはず。 Proposed bylaws changes to improve our membership experience 最初のきっかけはこのスレッドです。 これは規約の一部を変更する提案であり、その中でも3番目の提案であるAdds provision to remove Members by vote of the Board of Directorsという変更が注目を浴びました。 Python財団にはフェローという制度があり、これはPythonエコシステムやコミュニティに優れた
Java で higher kinded polymorphism を実現する - Qiita
Disclaimer この記事では一般的な（一般的とは…？）Java プログラマにも理解してもらえるように、比較的理解が簡単なかわりに informal な説明をしています。higher kinded polymorphism に関する formal な情報を求めている人は…ちょっと探した感じでは Qiita にはないようなので、適当にぐぐるか、References を参照してください。 TL;DR 俺はスーパー Java プログラマだぜって人は記事最下部の References にある highj を参照してください。これ読まなくていいです。Don't Read. higher kinded polymorphism とは higher kinded polymorphism をさす言葉として、他にも type constructor polymorphism とか実に様々な呼称があるの
PlantUMLでできるだけきれいなAWS構成図を描く方法 - Qiita
はじめに シーケンス図やクラス図などがコードで書けるうえ、AWSやAzureのアイコンを使って構成図までコードで書けてしまうPlantUMLにハマり、しばらく使ってみた結果、ある程度きれいな構成図が描けるようになったため、これまでのノウハウをまとめてみようと思います。 なお、今回はPlantUMLのインストール方法や使い方、初歩的な書式等まで説明していると長くなってしまうため、要点のみまとめます。 今回描いてみた構成図 仕事で描いた図を載せるわけにもいかないので、AWSが公開しているAWSソリューションの1つである「AWSでのワークロード検出(旧AWS Perspective)」の構成図をサンプルとしてPlantUMLでできるだけ基の構成図に近づけるように描いてみました。 もしAWS Perspective自体に興味があるようなら以前私が書いた記事も以下で紹介しておきますので参考にどうぞ。
【令和6年最新版】苦しんでThunderbirdでExchangeのメールを使う - Qiita
・フリーソフトが華やかしときはとうに過ぎさりしかな 筆者が管理している、M365テナントでは主なメーラーにOutlookを推奨している。 なぜならExchange Onlineを使用しており、その機能の恩恵を十分に受けられるのがOutlookだからである。 当然、それ以外のメーラーはサポート対象外として自己責任かつセルフサポートで使うよう指導している。 時に、ユーザより管理テナント特有の事情により、Thunderbirdを使用したいと申し出があった。管理テナント事情のため筆者が対応することになったがふたを開けてみれば、 ・情報が錯そうしていて、どれが最新かわからない ・試してみても出来ない 等由々しき状況であった。 じゃあQiitaに書くしかないな ・前提事項 ・この設定はセキュリティに関わる設定を行うため、何をしているかを必ずDocs上で確認し、理解すること。 ・共有メールボックスは受信
実装する前にきちんとドキュメントを読んだ方が良い、という話 - Qiita
どうも、初めまして。 tokeと申します。 今回は自分の失敗談を話したい、と思います。 実装する前にドキュメントを読まないと、最後になってゴールに辿り着けない可能性がある そういう経験をしたのでご紹介します。 例えば、自社で集めた顧客のデータを活用し、Marketoにデータ連携したいとします。 marketoのAPIドキュメントを調べると、顧客の情報を登録する手段では以下の２パターンがあります。 POST /rest/v1/leads.jsonを使うパターン 以下のドキュメントにあるPOST /rest/v1/leads.jsonを使って、顧客のデータを送信し、連携する事ができます。 https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/lead-database/leads [※Marketoで
オンプレエンジニアがAWSを触って思ったのと違うと感じたこと - Qiita
はじめに この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉をレトロニムというそうです。 私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、この本を読んでいたという知識があった程度です。 ここではずっとオンプレミスのインフラ構築をしていた私がAWSに触れて最初に戸惑ったことを記事したいと思います。また、戸惑いましたということだけ書いても学びがないため対応したことも併せて記載します。AWSに慣れている人からすれば常識ですが
アンチパターンで学ぶDB設計 - Qiita
はじめに データベース（DB）の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て
axiosやfetchに替わるKyのススメ - Qiita
Kyとは Kyは、Sindre Sorhusが開発したJavaScript向けの軽量かつ多機能なHTTPクライアントです。ネーミングの意図はよくわかりませんが、AxiosやネイティブのFetch APIに代わる、より効率的で使いやすい選択肢として設計されています。 Kyの利点 軽量で効率的: Kyのコアは非常に小さく（約2 KB）、パフォーマンスが重要なアプリケーションにとっては特に大きなメリットとなります。 Promiseベース: Fetch APIと同様に、KyはPromiseを基盤としており、async/await構文との組み合わせが容易です。 シンプルなAPI: Kyが提供するAPIは非常にシンプルなので、学習コストが抑えられます。 再試行機能: Kyには、失敗したリクエストの再試行する機能が組み込まれており、エラーハンドリングの実装コストを減らします。 JSON処理: Kyは自動
バッチファイルでzip圧縮する（PowerShellを使用） - Qiita
Y子です。 今日はファイルを圧縮してみます。 概要・用途 PowerShellを使って、zip圧縮します。 自動処理の中で、圧縮してサイズを小さくしたり、複数ファイルを1ファイルにまとめたり、等の用途を想定します。 【確認環境：Windows 10 Home (Bld. 19042.928)】 コード (1) 1ファイルを圧縮する 1つのファイルを圧縮して、1つのzipファイルを作ります。 zipファイルの置き場所は、元ファイルと同じフォルダとします。 zipファイルのファイル名は、元ファイルの末尾に「.zip」を追加しただけとします。 @echo off setlocal rem 引数がない場合は終了する if "%~1"=="" (echo 引数がありません & pause & exit /b) rem 圧縮前ファイル set str_file=%~1 rem 圧縮後ファイル set
なんだか助かる便利なおっちゃんになりたい - Qiita
これまでの生存戦略 それほど尖った能力や知識がない中で、私のこれまでの生存戦略としては求められればなんでもやる、少しくらい泥水でも飲むというものでした。 フロントエンドからバックエンド、データベース設計、API設計、実装、インフラ側の設定、提案書作成、プレゼンテーション、プロジェクト進行、どれも“専門家として誇れるか”というと疑問がありますが、求められればなんでもやるスタンスでそれが自分の価値提供の形と考えていました。 また、以前までは「若い」というのも、強みでした。 一回りほど上の年齢に見られることも珍しくなく、「そんな若かったのか」と驚かれるなかで、「若いのに頑張ってるね」と年齢のフィルターで大目にみてもらえました。 しかし、そんな私も気が付けば40歳、もう若さという武器はありません。 （つい先日まで20代だったはずなのに..何かおかしい..） 体力的にも無理が効かず、新しいことを学ぶ
元々は /usr は user の略に決まってるじゃん？ホームディレクトリを置く場所だったんだから - Qiita
Twitterとか見て「そうだったのかー」とか言うんじゃなくて、ちゃんと調べてみましょうよ。/usr は元々ユーザーのホームディレクトリをおいていた場所ですよ。/bin などを置いていたシステムディスクの容量が足りなくなったので別ディスクだった /usr 以下を使うようになっただけです。Unix System Resources とかそんな長い名前、後付けに決まってるでしょ？ 翻訳は面倒なので、DeepL（の少し手直し）です。 初期の Unix のドキュメントから URLと1972年という年から、おそらく Version 1 Unix (1971) のドキュメントだと思います。ここ 経由で見つけました。 12ページにこのようなものがあります。詳細はよくわかりませんがディレクトリ構造でしょう。 idata: / root 41. 140016 .byte 7,1 9f-.-2 41. <..
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣ - Qiita
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記： OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(
Git不慣れ勢を束ねて安全なチーム開発をするメモ - Qiita
本稿は当初チーム開発時のメンバー向けにまとめたものです。 ある程度、端折っていた背景などを記載しました。 git初心者同士でのチーム開発において、git操作を詳しく知らないメンバーも含め安全に行う必要がありました。しかし、開発期間はごくわずか...この状況を回避するために、下記の対応をとりました。 Gitコマンドの基礎的な内容を理解する（私） 各種操作をGUI上で完結させる拡張機能を色々と導入する シンプルな開発フロー(Github flow)を採用し、コマンド実行に相当する操作を限定する 各操作をGUI上での操作に置き換え、チームメンバーに教える 本稿はその際の、コマンドやGUI操作に関するメモをまとめたものになります。 こういった取り組みのおかげか、チームの開発をすんなりフローに乗せることができました。 ■ 前提条件 対象とする動き Github flowを回すうえで、 cloneする
「JavaScriptで要素をドラッグして移動する簡単な方法」という記事が初耳だらけだった件 - Qiita
はじめに まず↓の記事を見てない方はぜひ見てください！ 自分にとってはこの記事には「えっ、ナニコレ！」なテクニックが多く、特に解説もなかったのでいろいろ調べてたら休日が消えてました... なのでその時間の供養もかねて、自分が知らなかった部分を中心に、僭越ながら元記事の解説を書いてみたいと思います。 ちなみに、以下が元記事のコードそのままを実装したものです。たしかに掲載コードだけで要素がグリグリ動きますね。 See the Pen js-drag-move-original by www-tacos (@www-tacos) on CodePen. 初耳1: $img まずコードのここ <img id="$img" src="https://js.cx/clipart/ball.svg" width="40" height="40"> <script> $img.onpointermove
cowsayを入れておくとAnsibleの出力結果が見やすい - Qiita
if [ ! -e /usr/bin/ansible ];then sudo apt-get install -y ansible cowsay; fi < TASK: packages | install mail > ------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || ok: [localhost] => (item=sharutils,postfix,mailutils,mutt) => {"changed": false, "item": "sharutils,postfix,mailutils,mutt"} _________________________________ < TASK: packages | install guiapp > -------------
エンジニアはどう学んでいけばよいのか - つまりは「知ったかぶり」 の積み重ね - Qiita
はじめに この記事では、学んでいくためのマイルストーンとして「知ったかぶりができること」を設定するのもアリなのでは？ という提案をします。 初学者でなくても『どうやって学んでいこうかな～』は全エンジニアの関心事だと思うので誰かの行動のきっかけになれたらうれしいです。 目次 （エンジニア）人生は勉強や！ 「知ったかぶり」を再定義する 「知ったかぶり」を可視化する 無知の知はすぐに自覚できる どうすれば人に説明できるようになるのか いったんここまでのまとめ 脳内イメージの解像度をどう上げていくか アウトプット先を意識したインプットをしよう " 知ったかbrilliant Journey of Engineers " さあ、なにを知ったかぶりしていこう？ おわりに （エンジニア）人生は勉強や！ 技術は高速かつ複雑に成長しているので、新たな分野を学ばなきゃいけない機会はどんどん増えていく。また、そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
