import "@typespec/http"; using TypeSpec.Http; model User { id: string; name: string; birthday?: utcDateTime; address: Address; } model Address { street: string; city: string; state: string; zip: string; } @route("/users") interface Users { list(@query limit: int32, @query skip: int32): User[]; create(@body user: User): User; get(@path id: string): User; } openapi: 3.0.0 info: title: (title) versio
Over the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include: Hexagonal Architecture (a.k.a. Ports and Adapters) by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book Growing Object Oriented Software Onion Architecture by Jeffrey Palermo Screaming Architecture from a blog of mine last year DCI from James Copli
竹村響@自由 @pinkkacho ヴィレヴァンがマズくなった…のは出版社目線で「POSレジ」の導入からだと思っていて。書店のPOSレジって「5冊入荷した本が24時間以内に3冊売れたら自動的に2冊追加発注する」みたく売り逃しが減る素敵なシステムだけどデメリットは「売場が売れ線の本ばかりになること」 toyokeizai.net/articles/-/728… 2024-01-19 12:22:47 竹村響@自由 @pinkkacho このPOSレジがヴィレヴァンに限らず日本中の書店の売上効率をめちゃくちゃ改善してくれて、でもかわりに日本中の書店のラインナップを均質化してしまった。それでよかった書店が大多数だと思うけど「個性」で売ってたヴィレヴァンはこのデメリットのワナにはまっちゃったんじゃないかなあ 2024-01-19 12:25:21 竹村響@自由 @pinkkacho ヴィレヴァンの
育休中のリスキリングとしてプログラミングを勉強し、Webエンジニアに転職したので本音のところを書いてみるポエム勉強法 育休中のリスキリングとしてプログラミングを勉強し、Webエンジニアに転職したので本音のところを書いてみる どうも、MIDORIと申します。 先日、下記の記事を拝読しました。 「わかる〜〜〜〜」とめっちゃ頷きました。 というのも、私は第2子妊娠中にプログラミングを始め、育休中にWebエンジニアに転職したからです。 ・どんなふうに勉強していたのか ・育休中のリスキリングは現実的なのか ・子育てしながら勉強は可能か 私の経験とその実態を率直に書いてみようと思います。 対象者 ・育休中にリスキリングをしてみたい ・子供がいるけどエンジニアに未経験から転職したい ・エンジニアだけど子供がいて勉強できない ・社員にリスキリングを推奨している そんな方のひとつの参考例になれば嬉しいです。
Follow on FacebookReact has been around for a while. Since then, a well-rounded yet overwhelming ecosystem of libraries evolved around the component driven library. Developers coming from other programming languages or libraries/frameworks often have a hard time figuring out all the libraries for creating web applications with React. At its core, React enables one to create component-driven user i
私はフロントエンドエンジニアとして働いてはいるのですが、巡り合わせが悪いのでしょうか?まともなテストを書いたことがないんですよね。まあ、それもでテストくらい書けないとなぁ。なんて思ってはちょいちょい調べたりする日々を過ごしていました。 そんなある日、たまたま TDD(テスト駆動開発) についての動画を視聴してみました。 TDD 自体は知ってはいて、なんとなく知っているくらいの知識ではありましたが、分かりやすい説明とその思想が好きで、のめり込むように見てしまいました。 その後も何度か視聴して、フロントエンドでも TDD したいなと考え始めました。 普段テストすら書いていないのにいきなり TDD とも思わないこともなかったですが、実際に普段自分がさわっているようなコードに落とし込んで書いていくと、テストする本当の意味というものが、より正確に理解できてきたような気がします。 そんなテスト初心者の
Firestoreにおけるテストの概要 普段の業務では、TDDでの開発をベースにしているため、個人開発でよく利用するFirestoreを使った開発でもテストをきっちり書けるようになりたいと思い、今回まとめてみました。 Firestoreに関連するテスト対象は大きく2つあります。 Firestore Security Rules単体テスト ← 本記事🚀🚀🚀 Firestore 更新に伴い起動するCloud Functions の単体テスト ← COMMING SOON... 本記事では、前者の「Firestore Security Rules単体テスト」をご紹介します。 この記事で紹介したサンプルコード全体は、以下のGitHubリポジトリにアップロードしてあります。 全体を俯瞰したい場合や、細かい確認をされたい方はこちらをご覧ください。 前提 Firebaseの基本的な設定は済んでいる
家族構成は人生に影響するのか われわれ人間はさまざまなものから影響を受けて成長します。この中でも大きな影響を及ぼす要因の一つとして、家族構成が挙げられます。 家族構成は子どもの成長に大きな影響を及ぼすと考えられ、経済学でもこれまでさまざまな分析が行なわれてきました。たとえば、シングルマザー世帯です。離婚を機にシングルマザーとなった世帯における子どもの学業や、成長後の学歴、所得水準といった点が検証されています(*1)。また、海外では同性婚カップルの子どもと、異性婚カップルの子どもに行動面で違いが生じるのか、という点も検証されています(*2)。 これら以外で近年注目を集めつつあるのが「きょうだいの組み合わせ」です。ここでの「きょうだいの組み合わせ」とは、子どもが2人以上いる場合において、同性のみなのか、それとも異性も含まれているのかという点を指しています。 きょうだいの組み合わせが将来の年収や
TypeScriptとドメイン駆動設計(DDD)を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
はじめに 書いていて気づいたのですが、この記事に特に目新しいものはありません。コピペで最速環境構築をしたい方向けです。それぞれのツールについて細かい解説はしていないため、詳細は公式ドキュメントをご参照ください。 リポジトリはこちら。 Node.js この記事では Node.js のバージョン管理に volta を使用しますが、nvm や nodebrew などでも問題ありません。パッケージマネージャーには pnpm を使用したいところですが、2024 年 1 月現在、volta の pnpm サポートは実験段階のため、今回は npm を使用します。(そこまでして volta を使用したい理由はないのですが...) curl https://get.volta.sh | bash source ~/.zshrc # or ~/.bashrc volta install node # LTS版
Googleが開発したチャットボットAI「Bard」はこれまで無料で公開されていましたが、新たにGoogleは、有料サブスクリプションのGoogle Oneを通して、「Bard Advanced」と呼ばれるBardの有料版を開発中であることが報じられています。 Google appears to be working on an ‘advanced’ version of Bard that you have to pay for - The Verge https://www.theverge.com/2024/1/4/24025270/google-bard-advanced-paid-subscription Google is preparing a paid version of Bard https://www.androidpolice.com/google-preparin
この記事は「paiza Advent Calendar 2023」の最終日の記事です。 最終日はpaiza株式会社で社長をやっている片山がお送りいたします。 タイトルはほぼ釣りです。 ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです。(paiza.jp) 記事概要絵にかいた餅は大した価値はなく、実行し成果が出せて初めて価値がある 実行プロセスやプロダクトが良くても、市場ニーズがなければ価値はない 計画は粗くてもいいから一筆書きで描き切ることが重要 一筆書きで書いたら実際に動いてすぐ更新すべし つまり実行が出来る計画を描き、実際に実行し、発見があれば即修正しながら成果を出せ、というごく当たり前な内容です。 ただそれがとても難しいので、どのあたりでつまづきやすいのか、経験を元にまとめてみました、という記事です。 計画は荒くてもいいから一筆書きで書き、高速に
encraft #2 までの間、スキーマスキーマした話をたくさん書きたい。 OGP は昨日食べた火鍋だ。Fire 感があるのでこれを使おうと思った。(Firebase の記事を書く時は炎の画像を使っていたのに、炎系のフリー素材をたくさん使いすぎて似た画像ばかりになりストックがなくなったことは秘密) firestore は withConverter で validation できる なんか似たようなブログを書いた気がしていたのだが、どうやら firestore の入出力に型をつける で withConverter を紹介していた。なので詳しくはそれを見てほしい。 export const sitemapConverter: FirestoreDataConverter<SitemapSchema> = { toFirestore(sitemapDto: SitemapSchema): Do
この記事は 2023 年 11 月 6 日に行われた ZOZO Tech Meetup - Web フロントエンドで発表した資料を記事にリライトしたものです。 資料だけでは伝わらない部分や、もっと詳細に触れたい部分もあったので記事にしました。 当時の発表資料は以下です。多くの部分では同様のことが記載されていますが、細部や扱う内容を若干変えています。 はじめに 3 年前にコンポーネントではなく Hook 自体をテストしたいというモチベーションから「React Hooks でテストをゴリゴリ書きたい」という記事を書きました。 この記事を書いた当時は Hook やコンポーネントで使われる関数がそれぞれ正しく動いていることが確認できれば、それらを組み合わせて作るコンポーネントもある程度正しいことが担保されるではないかと考えていました。 また、コンポーネントは JSX が書かれていて DOM 構造と
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く