回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー

定期的に見かけるSAPを入れても碌なことがないみたいなやつ。現場の人や中間管理職の感想としては全く正しいが、本当にERPがゴミならば（主にグローバル大企業で）これだけ普及しているわけもないわけで、なにかしら使う側に問題があるのかもしれません。 マジレスするとSAPというかERPは給料の高い人の生産性を上げるもので、給料の安い人の使い勝手とか優先度低いし、末端にたくさんのデータの入力を要求するから。別になんの矛盾もない。 https://t.co/F2J5TdeWXw — (っ╹◡╹c) (@Heehoo_kun) March 21, 2024 私が新卒入社した会社でも当時のメインフレームをSAPに置き換えるみたいな話があって、コスト削減で大変な工場でそんなものは入れられないみたいな議論があったのは覚えています。その時のラインマネージャーの一人が、「ERPは給料が安い人を大量に使って給料が高

トップページ ニュースリリース 目先のことを過大評価してしまう人間の行動を分析し最適な介入を導出する数理モデルを開発～シミュレーション実験の計算コストをかけずに、個人の目標達成の成功を支援～ 日本電信電話株式会社（本社：東京都千代田区、代表取締役社長：島田　明、以下「NTT」）は、目先のことを過大評価してしまう人間の、長期的な目標達成行動を分析し、さらにそのような人間の目標達成のための最適な介入を求めることができる数理モデルを開発しました。このモデルを用いて導出した適切な介入を適用することにより、健康や教育などにまつわる個人の目標達成の成功を支援することができます。なお、本成果は2024年2月20日から27日までカナダ・バンクーバーで開催された、AI分野の最高峰国際会議 The 38th AAAI Conference on Artificial Intelligence（AAAI 202

2024年4月25日紙版発売 2024年4月25日電子版発売 市原創，板倉広明　著 A5判／456ページ 定価3,740円（本体3,400円＋税10%） ISBN 978-4-297-14178-3 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 SSL/TLSは，通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており，今日のWebでは利用が一般的になっています。本書では，その最新バージョンであるTLS 1.3のしくみと，その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的

はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ？ でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/

はじめに ◆この記事は何？ IPA高度資格「情報処理安全確保支援士」のシラバスに掲載されている用語の備忘録です ◆対象は？ 情報処理安全確保支援士の試験勉強をされる方 ◆この記事のねらい 試験範囲の用語の階層を整理します 試験勉強の一助となれば幸いです ◆この記事について シラバスの用語を参考書等を読みながら自分なりに整理した私の暗記用のノートです シラバスver4.0 試験に向けて高頻度で更新しています ご助言、誤り等あればご指摘いただけると幸いです 試験範囲全体 試験範囲の分解 暗号 認証 ネットワークセキュリティ データベースセキュリティ クライアントセキュリティ httpセキュリティ メールセキュリティ 攻撃と対策 注目技術 ※参考文献の目次をベースに、試験範囲を分解 暗号技術 共通鍵暗号方式 ブロック暗号 ECBモード CBCモード CTRモード（Counterモード） ストリー

この記事は？ 著者は、エンジニアにとって最も大事なものの一つは契約であると考えます。なぜなら、契約によって我々はお金を得ることができ、労働対価を受け取って生きていくことができるからです。プロジェクトにおいてトラブルが発生すると、契約はメンバーを守ってくれるものになります。したがって、雇用契約、請負契約、準委任契約など何の契約であっても隅々まで確認し、不利にならないようにしないといけません。社員であれば誠実に職務に向き合う必要があります。請負契約であれば対価を得るために納品する必要がありますし、準委任契約であれば善管注意義務を背負いプロとして日々業務を行なっていく必要があります。一方で、著者は長くにわたって業務委託契約でパートナーとして参加してくださっているエンジニアたちと長らく協働してきた経験がありますが、ユーザーとしてもベンダーが妨害要素なく働けるように、協力義務を果たす必要があります

はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理

日経BOOKプラスに掲載されている記事、本、著者を任意のキーワードで検索することができます。 ※ISBNも検索にご利用いただけます。ISBNとは出版物固有の13桁の番号で、裏表紙に記載されています。本サイトでISBNを使って書籍を検索する際は、ハイフン（-）を省略し、13桁の数字のみを半角文字で入力してください。

これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ

2023 年に読んでよかった本 2023.12.30 年末なので 2023 年のまとめっぽい記事を書きたくなりました。今年は 1 年間でおおよそ 300 冊の本をよんだようです（そのうち 3 割ほどはラノベなのですが...）。その中でも特に印象に残った本を紹介します。 年末なので 2023 年のまとめっぽい記事を書きたくなりました。 今年は 1 年間でおおよそ 300 冊の本をよんだようです（そのうち 3 割ほどはラノベなのですが...）。その中でも特に印象に残った本を紹介します。 忘れる読書 この本では「本は忘れるために読んでいます」と語られています。というわけでこの本の内容もあまり覚えておりません(?)。 本を読むときには一字一句正確に覚えるような読み方をしていると、「覚えなきゃ」という気持ちが芽生えてしまい、本を読むことが苦痛になってしまうことがあります。そうではなくて、パラパラとペ

おそらく 2023 年に Zenn で出す最後の記事になるかと思います。 タイトルの通り、2023 年に読んだ本の中で、特に素晴らしかったものをご紹介します。 とはいえあまり今年は技術書を読んだ印象がなく… というのも、特定の xx(例えば Next.js、Ktor)といった部類に関しては公式のドキュメントを読むことがほとんどになり、書籍に求めるのは公式ドキュメントに書かれていない何かや誰かの経験・ノウハウになったからだと思います。 この記事を書くにあたって今年読んだ本を振り返ってみても、やはり十数冊程度(それでも月に 1 冊は読んでた)のでインプット：アウトプットの割合的には良いバランスではないかと思っています。 ただ、先に述べた通り公式ドキュメントに書かれていないなにかを売っている本というのはどれも本当の意味で価値があるものであり、皆さんにも本当に意味のある情報にお金を使っていただける

このブログを読んでいる方はご存知だと思うのですが、僕は意思決定のプロセスや態度についてやたらよく書いています。不確実性が高いこと(例えば新規事業など)をやるときは、どういう思考プロセスで意思決定をするかが重要だと考えているからです。 今日は「失敗を恐れない」態度には種類があるという話を書こうと思います。 実は「上手くいくことを信じる」のはとてもとても難しい 新しい事業やプロジェクトをやるとき、少なくともリーダーは成功するつもりでそれに取り組むわけです。 (やりたくもないのに押し付けられてやってる等で、失敗をわかっててやる場合もあるかもしれませんが、そういう例は除外します) 僕自身が事業をやってるときもそのつもりですし、スタートアップや色々な会社の事業に関わっている中でもリーダーはみんな成功するぞという気持ちを持っています。 やったことがない人には想像が難しいかもしれませんが、実はこの「上手

1. 『失敗の科学』マシュー・サイド 著、有枝春 訳 2. 『ヒューマンエラーは裁けるか』シドニー デッカー 著、芳賀 繁 訳 3. 『なぜエラーが医療事故を減らすのか』ローラン・ドゴース 著、林 昌宏 訳 4. 『IT失敗学の研究』不条理なコンピュータ研究会 著、日経コンピュータ 編 keyboard_arrow_down はじめに keyboard_arrow_down 失敗を科学する keyboard_arrow_down 失敗が再発するメカニズム keyboard_arrow_down ミスを厳罰化するとミスが報告されなくなる keyboard_arrow_down ミスから学ぶチームのつくり方 keyboard_arrow_down スイス・チーズの喩え keyboard_arrow_down IT失敗学の研究 keyboard_arrow_down おわりに 明確なゴールと計画

シングルスレッドやマルチプロセスなどの並行処理の話について、 すぐに忘れてしまいます。 どうしたらもっと知識が定着すると思いますか？ 色んなライブラリーでAPIサーバーを立ててパフォーマンスの差などを見てみたりするのですが、結局よくわかりませんでした。 フレームワークに頼って実装していると、そのフレームワークが内部でどの様な仕組みで並列または並行処理しているのかが理解できず、ただ使っているだけの状態になり得ます。 フレームワークの設計者からすると、プログラマがそれらを気にしなくても利用できるというのがプロジェクトのゴールでもあるので、それはそれで正しいのですが「並列処理」や「並行処理」を理解したいというモチベーションでは逆にそれが邪魔をしてしまうかもしれません。 並行処理や並列処理を学ぶのであれば、API サーバ等といった物ではなく、コード片で学び始めるのが良いと思います。 例えば Rub

2023年度リクルート エンジニアコース新人研修の講義資料です