【追記】この記事をきっかけに、名著「ノンデザイナーズ・デザインブック」の20周年記念特典eBookの制作に協力させていただきました。詳しくはこちらを御覧ください。 ノンデザイナーズ・デザインブック20周年記念の特典に寄稿しました デザイナーである・なしに関わらず、仕事の中で伝えたいことを「図」で説明する機会は多々あります。提案書で事業内容を説明することもあるでしょうし、具体的な数値をグラフで説明することもあるでしょう。そんな中でこんな指摘を受けたことはありませんか？ ・最終的に何を言いたいのか結論が見えないよ。 ・関係性が複雑すぎて理解しずらいんだけど。 ・要素が多すぎて全てを把握するのが大変。 ・何をどこから見れば良いの？ ・結局一番言いたいことはなんなの？ ・文字サイズがたくさんありすぎてまとまりがないね。 ・安っぽいチラシみたいでダサイなぁ。 ・全体的にバランスが偏ってて不安定。 ・

今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

「英語講師の話す英語はわかるのに、ネイティブ同士の会話が聞き取れない」 「映画を英語字幕付きで見ていても、同じことを役者が話しているように聞こえない」 ある程度の英語力があるにも関わらず、ネイティブの話す英語が聞き取りにくく感じてしまう原因のひとつにリエゾン（リンキング）があります。 リエゾンとは言葉の音声変化のことで、ネイティブスピーカーの英語では自然に発生しています。 このリエゾンを意識できると、相手の英語がぐっと聞き取りやすくなるばかりか、自分でもスピーキングのときにより自然な発音ができるようになりますよ。 しっかりリエゾンを身につけて、リスニングもスピーキングも、自信を持ってできるようになりましょう！ 執筆者：Lin 小4までアメリカの現地校に通い、帰国後は「英語はネイティブ並みでしょう？」という周囲の誤解とプレッシャーゆえに、英語の勉強から遠ざかった過去あり。中途半端な英語力にコ

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

ゲーム作りとかCGとかに関わる数学(初歩)① 今回HIKKYさんのアドベントカレンダーに投稿するにあたって、別の温めてたネタはあったんですが諸事情により封印してしまったので、何か別のテーマにしようと考えました。 で、色々考えたのですが、特に思いつかなかったのでCG数学の初歩的な話をしようかなと思います。実際VKetCloudの中でも基本的な数学は必ず使われてますし。 あと「ゲームメーカーズ」さんの記事でも取り上げていただいた、僕のCEDEC+KYUSHU2023の数学のお話がやたらとウケがよかったため、数学の話で行くことにしました。 で最初に書いておくと、書きたかったことの半分もかけていません。 時間の都合上と、あと数式と頭が多すぎるのか、このドキュメントの編集が何度も落ちるからです。 と言うわけで、今回は概要と三角関数とベクトルの話だけにします。 あとは年末年始休みの間にでも続きを書きま

この記事は DeNA 24 新卒 Advent Calendar 2023 の 23 日目の記事です。 TL;DR DBMSの基本的な仕組みを知るのに有益だったリソース CMUのDBMS講義 先人の素晴らしい自作DBMSの解説記事&ソースコードリーディング 小さな小さな自作DBMSの設計と実装 最小限SELECTやINSERTなど基本的なSQLが動く この記事のゴール データベースの内部構成を超ざっくり理解するために有用なリソースを知り、そして（全開発者のロマンである）自作 DBMS に一歩踏み出すきっかけになればうれしいです。 モチベーション 自分は普段業務でアプリケーションのような割と高レイヤーな開発がメインなこともあって、ミドルウェアやOS、ネットワークと言った低めのレイヤーに憧れを持っており、この気持ちをまずは自作DBMSをやってみることによって解放してあげようと思ったことがきっか

「レイトレーシング」は 3D グラフィックスの重要な技術となっていて、レイトレーシングを使ったリアリティの高いグラフィックス表現を見る機会が増えてきました。 また同時に、「レイトレーシングをオーディオに応用する」といった言及もちょいちょい見かけるようになりました。 しかし、グラフィックスのシミュレーションにレイトレーシングが有効なのは光の特性をレイトレーシングで近似できているからであり、音の特性に関してはレイトレーシングだけで近似するのは困難です。これはもう少し広く知られていて欲しい事実なのですが、何故かあまりきちんと知られていません……。 そもそも悲しいことに、「物理シミュレーションによる音響空間表現(方角、残響、遮蔽などの表現)」を網羅的に真面目に考察した資料は恐ろしく少ないです。この現状では、レイトレーシングだけで音響空間表現が簡単に出来るというような誤解が生まれてしまうのも仕方ない

インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト

2023年6月16日 から改正電気通信事業法が施行なんですけど知ってました？ これ、収益目的なら企業運営でも個人運営でもほとんどのWebサービス・スマホアプリが対象という、めちゃめちゃ広範囲にみんなが対応が必要なやつなんですけど、ヤバくない? 何もしてなくない? やっべえなというWEBサイト担当者/アプリ開発者が結構いそうな雰囲気がいんたーねっつから漂ってまいりました。 企業のオウンドメディアや、個人運営のアフィリエイト目的サイトなんかも対象になる場合があって、メディア系サイトはもちろんアプリ開発者にも影響ある感じですので、やるべき内容をブログにしたためておきます。 ※ぼくは法律の専門家ではないので、ちゃんと総務省の公式ドキュメントなどにも当たってくださいね。 ググると「外部送信規律」とか「電気通信事業者又は第三号事業を営む者」とか専門用語の記事ばっかり出てきて自分が何をしたらいいのかの情

TL;DR 空のコレクションに allMatch() 的な判定をするとtrueになるぞ！気をつけろ！ 背景 あるリストの全ての要素がとある条件を満たすどうかを返すメソッドがあり、 allMatch(何かしらの条件) した結果をbooleanとして返すという実装になっていた。このメソッドを利用しようとした時、ふと頭に疑問が湧いた。これって、リストが空だったら結果はどうなるんだっけ…？ というわけでREPLを開いてちゃちゃっと確認してみたところ、結果はtrueであった。 # 空のリストに対して、「全ての要素が奇数である」という判定をしたら true になる…？ jshell> List<Integer> list = List.of(); list ==> [] jshell> list.stream().allMatch(v -> v % 2 != 0); $3 ==> true 直感的には

たくさん溢れている開脚のための情報。いったいどれが自分に合っているのか、本当にこれで開脚ができるようになるのか、そう思っている人も多いはずです。今回は、運動習慣がない、長続きしないという人のための「５分でできる開脚ストレッチ」を考案。ぜひトライしてみてください！ 開脚ができない人はとても多い まずは床に座り、開脚前屈を試してみましょう。写真のように脚が90度開かない人や、体を前に倒そうとすると腰が丸まってしまう人、多いのではないでしょうか？　このような体の硬い初心者さんに向けたエクササイズをご紹介します。 photo by Yusuke Honda立った状態で体をほぐす いわゆる「身体が硬い」人は、最初から座った状態では開脚をしようとすると「不良姿勢」や「苦しい体勢」など無理な姿勢になりがちです。理由は、身体が硬いために背中をまっすぐにできず、重心が後ろにかかってしまうから。まずは立ち姿勢

リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか？ また、初めてリレーショナルデータベースシステムを開発する者

※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証（本人確認）をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に：暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して

burikaigi 2023 の懇親会で発表したセッションの資料です。 日本では明治6年(1873)よりグレゴリオ暦が採用されましたが、それ以前の年代での和暦の扱いについて注意点をまとめたものです。

先日、社内で技術書に関するイベントが行われた。執筆経験を持つ社内のエンジニア諸氏から話を聞ける、という面白そうなイベントだったので有難く参加してきたんだけど、そこで質問を投げたところ、著者である石川さんからご厚意でこちらの本を頂戴した。 ばばーん！「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」です！ gihyo.jp 実はもともとこのツイートを見て気になっていたんだけど、「私には難しすぎるんでは…」とためらって買っていなかった本だったので、とてもうれしい！ クライアント開発を担当している石川宗寿が執筆した「読みやすいコードのガイドライン -持続可能なソフトウェア開発のために」が10月22日に発売されます。 著者に執筆のきっかけやこだわった点などをインタビューしましたので、書籍情報とあわせてぜひご覧ください。https://t.co/5e7n9UZ2Oz— LINE

バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。