フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5
いつものようにヘロヘロと仕事をしていると、突如担当編集の松尾氏からMessengerで「これに対するちゃんとした回答を書けるのは大原さんだなということで、また歴史物をお願いしたく」という依頼が飛び込んできた。 いやちゃんとした回答も何も、上のTreeで出題されたSEライダー氏が正解を出されているわけですが、歴史的経緯というか、ここに至るまでの話というのが長い訳で、その辺りを少し説明してみたいと思う。 ちなみに出題に少しだけ違和感がある（なぜ10bitがキリがいいと思うのか？）のは、筆者もこっち側の人間だからかもしれない。 回答の前に、その根底にある2進数採用の経緯 そもそも非コンピュータ業界の方からすれば、2進数がベースという辺りから違和感を覚えるのではないかと思う。実際、世界最初の計算機（≠電子計算機）とされる「バベッジの階差機関」（写真1）にしても、世界最初の電子計算機（※1）であるE
✨nori @00oichan SES→金融系SIer→外資SaaSエンジニア ServiceNow／生成AIプロンプトフェチ／ITIL運用設計／UiPath／Power Automate PowerBIを愛する札幌出身相模原在住の2児の父 Amazonアソシエイト
突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
2023.05.10 官報に使われる「官報文字」というものがあります。 そこには渡辺さんの「辺」の異体字が１４０文字も登録されています。 日本語の常用漢字には２１３６文字ありますが、そこには邉や邊などは入っていません。 そこでＪＩＳの第四水準までを含むJIS X 0213という標準を定め、スマホやパソコンではここまでを標準的に表示できるようにしています。 ところが我が国の戸籍で使ってもよいとされている文字はそれを遙かに超えていて、少なくとも５５，２７０文字もあります。 全ての国民の氏名をコンピュータで扱えるようになることを目指して、戸籍統一文字や住基ネット用の統一文字を網羅した「文字情報基盤」を２０１１年に策定し、それにあわせたフォントを作成し、無償で提供しています。 この「文字情報基盤」（ＭＪ）には、５８，８６２文字が含まれています。 しかし、このＭＪを全庁的に採用している自治体は、川口
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
「どんな機能が欲しいですか？」 この質問、プロダクト開発をしているとプロダクトマネージャーやエンジニアが聞いているのを良く耳にします。 お客さんに質問してしまっているケースもよく見ます。でも僕は、この質問は意味はなく、無駄だと考えています。 なぜ「欲しい機能」を聞くのが悪手なのか聞かれたら何か答えなきゃいけない心理ユーザーインタビューで「欲しい機能ありますか？」と聞かれたら、ユーザーは何か答えなきゃいけないと思ってしまいます。 実際、僕も他社のサービスについてインタビューを受けた時、同じ経験をしたことがあります。特に困ってないけど、聞かれたから「あったら便利かも」程度のことを答えてしまう。でも、それにお金を払うかと言われたら、絶対に払いません。 この「聞かれたから答える」という機能要望は、本当のニーズとは全く違うものです。 ユーザーは自分が欲しいものを知らない「もし顧客に望むものを聞いてい
コンポーネントを作るときや開発チーム、クライアントと話をするときに名称が一致していないと何の話をしているんだか、、？となってしまします。 忘れっぽい自分は毎回名前をうろ覚えでつけてしまっていますが、戒めとして記事を書くことでしっかり覚えていきたいと思います。 ※色んなところから引っ張ってきているので正式名称ではない（複数呼び名がある）ものがあるかもしれませんが、ご了承ください。 UIパーツ見づらくてすみませんが、エクセルのシートを画像にしたものを貼り付けていきます Onscreen keyboards画面上にキーボードの図形や文字を表示し、マウスあるいはペンなどのポインティングデバイスや、指先によるタッチ、あるいは十字キーなどで各キーを指定して文字入力を行うもの Onscreen keyboards (iOS) SegmentedControliOS独自のUIで水平方向に配置された複数のボ
日本IBM（「Wikipedia」より／Yoshi Canopus） NHKがシステム開発を委託していた日本IBMに対し、開発の遅延による契約解除に伴い計約55億円の代金の返還と損害賠償を求めて東京地裁に提訴した係争事案。NHKは、日本IBMが開発の途中で突然、NHKに対して大幅な開発方式の見直しと納期遅延を要求したと主張しているが、これに対し日本IBMは7日、以下のリリースを発表して反論したことがIT業界内で注目されている。 ＜現行システムの解析を進める中で、提案時に（編集部追記：NHKから）取得した要求仕様書では把握できない、長年の利用の中で複雑に作り込まれた構造となっていることが判明したため、当社はNHKに対し、解析の進捗状況、課題およびそれに対する対応策を随時報告し、共にその対応を検討してまいりました。こうした中で当社は、同システムを利用する業務の重要性も鑑みて、NHK指定の移行方
「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ
プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計の…
ふと気になって調べたことの備忘メモです ✍ （2022/4/2追記）Twitterやはてブで色々とご指摘やコメントを頂いたので、それに基づいて加筆と修正をおこないました 特に、幾つかの技術については完全に誤った説明をしてしまっており、大変助かりました…ありがとうございました🙏 （2024/8/13追記）今年に入って、実務で使える メール技術の教科書という本が出版されています🎉 私も買って読みましたが、電子メールに関するトピックについて広くカバーされていました パブリッククラウドに関する記述は少な目ですが、メールサーバーを自身で構築する方法が紹介されていたりなど、より基礎的な内容に主眼をおいている本だと思います なぜ調べたか メール送信機能のあるWebアプリケーションを開発・運用していると、 特定のアドレスに対してメールが届かないんだが とか MAILER-DAEMONなるアドレスからメ
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
風音屋（@Kazaneya_PR）では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級（グレード）」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか？」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと
三井ホーム断熱 UA値0.39天井：160mm 外壁：140mm 床：89mm 窓：樹脂ダブルサッシ 通常のバランスより壁面の断熱材が厚い 天井の断熱が薄い場合夏場に暑くなる可能性があり 床の断熱が薄い場合冬場に床が冷たくなる可能性がある しかし0.39なら十分合格 気密 C値の記載なし高い遮音性を語っているが、音は穴があるとそこから漏れ出すのは研究でわかっている いくら遮音性の高いドアを使っても隙間があれば防音室にはなりえない UA値が高く（分厚いドア）C値も高ければ（隙間なし）自動的に遮音性高くなるので遮音性よりC値を気にしよう 耐震 耐震等級3構造計算の記載なし 耐久性長期優良住宅の記載なし。しかし施主ブログを見る限り普通に対応できる模様 積水ハウス断熱 UA値0.60品確法性能表示制度の“等級5”に標準対応 気密 C値の記載なし耐震 耐震等級3構造計算の記載なし 代わりに独自の技術
25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。） 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化させるのではないかと懸念しています。
昨年、「Googleサービスに課金したいんだけど Google One とか Google Workspace とかいろいろある上に比較表みたいなのがなくて全然わからん」問題に回答する記事を書いたのですが、いまもけっこうアクセスがある＆ちょっと情報が古くなっているので、一年ぶりにアップデート版を公開します。 前回はAI（Gemini）まわりは考慮に入れていませんでしたが、関連機能が充実してきているので今回はそれも含めた比較をしていきます。 先に大事なことを書いておくと、Google Workspace Business Standard を使うと、条件付きでGeminiが割安で使えるのでお得です。 いかれたメンバーを紹介するぜ！ プランの選定条件として、下記が前提です。 組織（自分以外のメンバー）を持たない個人事業主である Google Meet で3人以上のグループ通話を60分制限なしで
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
すまほん!! » ニュース » 社会 » ローチケが炎上。機種変更やアプリ再インストール、SIM差替で「チケット消滅」「復元不能」仕様がアップデートで突如実装のため ローチケ（ローソンチケット）がSNSで炎上しています。 これはローチケが突如アップデートにて、機種変更やアプリ再インストール、異なるスマートフォンへのSIMカード/eSIM入替を行うとチケットが消失・復元不可能という仕様を実装したため。 転売防止を意識した仕様とみられますが、かなり過酷な制約であり、端末の故障や紛失、不具合によるOS初期化を想定しておらず、現実的に履行困難と思われ、消費者保護の観点からも重大な問題があるように見えます。 なお最近のモバイルOSは利用頻度の低いアプリの一時ファイル削除やアプリのアンイストールを行う機能があるため、どうしてもローチケを利用せざるを得ない人は、そうした機能が発動されないよう念の為オフに
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
＜2024年3月27日追記＞ 本記事掲載後、とほほさんの方で大幅に修正が加えられています。 中国茶の部分については、現実的な着地点となる程度の修正は行われたと思われます。 以降の文章については、「ネットに掲載されている中国茶の情報は、必ずしも正しくない」ことを知っていただくためのケーススタディとしてご覧いただければと思います。 随分、放置しておりました本ブログですが、ぜひ語りたいことが出てきましたので、緊急で書いています（YouTuberの「緊急で動画回してます」みたいなノリ）。 お茶好きをざわつかせた記事 インターネットの黎明期から活動されていた、とほほ（杜甫々）さんという方がいらっしゃいます。 Webサイトが”ホームページ”と呼ばれていた時代に、Webサイトを記述するHTMLという言語がありまして、それを分かりやすく解説するサイト（とほほのWWW入門）を運営されている方です。 私もその
2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/
tl;dr foobarhogehoge.invalidは絶対にリクエストが飛ばないのでおすすめ あらすじ 書いていたコードは、とあるミドルウェア向けに内部利用するURLを環境変数で受け取るようになっていた。普段は実際の内部のURLが書かれているのだが、テスト時には以下のようにダミーを設定していた: FOOBAR_EXTERNAL_URL="https://example.com/foobardummy" テストではこのURLを利用しないのだが、内部で環境変数のバリデーションを行っている都合上、とりあえず適当なURLを指定しなければ起動してくれないから、こうなっていた。重ねて言うが、実際はこの環境変数を利用していないのでこれでいい。 しかしこれだと、うっかり内部の様子がおかしくなったりエンジニアが狂ってしまった場合に、example.comに本当にアクセスしてしまう。なおかつ、セキュリティ
システムトレイにある「クイック設定」には、ネットワークのインターネット接続状態を表示するアイコンがある。 システムトレイにあるクイック設定は、フライアウト開かない状態では、ネットワークのインターネット接続状態を示す3種類のNCSIアイコンを表示する このアイコンは「インターネット接続不可」「インターネット有線接続」「インターネット無線接続」のどれかを表示する。これを「ネットワーク接続状態インジケーター」（NCSI、Network Connectivity Status Indicator）という。 この機能は、「ネットワークプローブ」を使って、Windowsのインターネット接続状態を調べ適切な表示・処理をする。アイコンの表示だけでなく、たとえば、公衆Wi-Fi／ホットスポットサービスなどにおいて、ログイン処理が必要なことを通知するのもNCSIの役割である。 原理としては簡単で、Micros
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
安全なパスワードの設定・管理 企業・組織におけるパスワードは、ユーザ名と組み合わせることで企業・組織内の情報資産へのアクセスの可否を決める重要なものです。パスワードの重要性を再認識して、適切なパスワード管理を心がけましょう。 他人に自分のユーザアカウントを不正に利用されないようにするには、推測されにくい安全なパスワードを作成し、他人の目に触れないよう適切な方法で保管することが大切です。 安全なパスワードの設定 安全なパスワードとは、他人に推測されにくく、ツールなどの機械的な処理で割り出しにくいものを言います。 理想的には、ある程度長いランダムな英数字の並びが好ましいですが、覚えなければならないパスワードの場合は、英語でも日本語（ローマ字）でもよいので無関係な（文章にならない）複数の単語をつなげたり、その間に数字列を挟んだりしたものであれば、推測されにくく、覚えやすいパスワードを作ることがで
「プログラミング教育について語る会 」で話した内容をまとめておきます。 「AI時代のプログラミング教育」としたのだけど、内容的には「コンピューティング能力を伸ばそうぜ、その道具としてプログラミングしよう」みたいな話になりました。 https://nextbeat.connpass.com/event/346052/ 資料はこちら まず前提として、AIのコーディング能力が7ヵ月で倍になっているというのがあります。なので、今現在の能力で話をしてもあまり意味がなく、ゆくゆくはかなりのレベルでAIがコードを書くという想定をしておいたほうがいいです。 元ネタのツイートはこれ https://x.com/METR_Evals/status/1902384481111322929 論文はここ [2503.14499] Measuring AI Ability to Complete Long Tasks
ミック @copinemickmack むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず遅くなる箇所があったので直すようにコメントした。すると相手曰く「なあ、それは今やる必要があるか？」。もちろん、今やっておかないと後で大変なことになる。「当然だ」と答えた。 2025-03-28 16:34:34 ミック @copinemickmack すると「どれくらいの確率で問題になると思う？」と聞いてきた。まあ正直分からない。サービスが当たるかどうかなんて事前には分からない。そう答えると「そうだよな。だったら今やる必要はない。日本人てのは起きていない問題まで見つけてくるから大したものだ」。嫌味というより素直に感心している。 2025-03-28 16:38:47 ミック @copinemickmack 「心配事の大半は起きない。だったら期待値の低いこ
HTMLページのhead内に記述する最小限の構成、そしてmeta要素やlink要素、ソーシャルサービス用の要素、デスクトップ・スマホのブラウザ用の要素などがまとめられた「HEAD」を紹介します。 HEAD: A simple guide to HTML <head> elements 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 以前の版からいろいろと変更されています。 2016年版: head内に記述する要素の総まとめ 2018年版: head内に記述する要素の総まとめ head内に記述する最小限の構成 head内の要素 meta要素 link要素 ソーシャル関連のhead内の要素 ブラウザ・プラットフォーム関連のhead内の要素 メモ head内に記述する最小限の構成 下記はシンプルなWebサイトで必須となるhead内に記
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
Agentic AI development from prototype to productionAgentic AI development from prototype to production Kiro helps you do your best work by bringing structure to AI coding with spec-driven development.
織田信長や足利義政などが求め、切り取ったとされる、正倉院に収蔵の「蘭奢待（らんじゃたい）」という香木の香りの成分と、木が生えていた年代が判明した。専門家が大型放射光施設「SPring-8」やガスクロマトグラフィーなど、最新の機器を用いて測定。8世紀後半～9世紀後半の樹木で、ラブダナムという植物の甘い香りをベースに、バニラなど約300種類の成分が混じったものだった。宮内庁正倉院事務所では「今回の研究成果を元に、他の香木についても調べられれば良い」としている。
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
https://cookpad.connpass.com/event/249346/ にて発表。
みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識／運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ
コーヒーの味の説明に「レッドカラント」「デーツ」などと書いてあることがある。よく分からないので、実際に食べてコーヒーの味と比べてみたい。 コーヒーの味の説明が分からない 最近、コーヒーが好きになってきた。いろんなお店を回っているが、よく分からないことも多い。 その一つがコーヒーの風味の説明だ。 いろんなコーヒーを置いてあるところでは、お客さんに分かりやすいようにそれぞれの味の特徴を書いてくれたりする（フレーバーノートというらしい）。 たとえば「ビルベリーのような爽やかさ」「デーツのような奥深さ」と言葉を尽くして説明してくれるのだが、例えられている対象をそもそも知らないことが多い。 「ブラックカラント知ってますよね？ あんな感じです！」と歩み寄ってくれているが、分からないなーと思いながら、雰囲気で選んでいる。 コーヒーの味はどんな風に説明されているのか？ お店によっては、説明を書いた紙をくれ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く