わかりやすい説明のための 10 の鉄則
第0部 まずは「分かりづらい説明」を知ろう（p.14～） 第1部 口頭説明編（p.25～） 第2部 資料作成編（p.63～） 第3部 スライド作成編（p.81～） スライドのまとめ（p.115～）
第0部 まずは「分かりづらい説明」を知ろう（p.14～） 第1部 口頭説明編（p.25～） 第2部 資料作成編（p.63～） 第3部 スライド作成編（p.81～） スライドのまとめ（p.115～）
// Good: choose between two options as appropriate (see below). import * as ng from '@angular/core'; import {Foo} from './foo'; // Only when needed: default imports. import Button from 'Button'; // Sometimes needed to import libraries for their side effects: import 'jasmine'; import '@polymer/paper-button'; Import paths TypeScript code must use paths to import other TypeScript code. Paths may be r
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
日本のウェブデザインの特異な事例
sabrinas.spaceより。 8週間もかからなかったはずのプロジェクト 日本のウェブデザインはどう違うのか? 2013年のRandomwireのブログ投稿で、著者(David)は、日本のデザインの興味深い相違点を強調しました。日本人はミニマリストのライフスタイルで海外に知られていますが、ウェブサイトは奇妙なほどマキシマリストです。ページには様々な明るい色(3色デザイン原則を破っている)、小さな画像、そして多くのテキストが使われています。2022年11月に撮影されたこれらのスクリーンショットで、自分の目で確かめて下さい。 ブログ投稿には、文化的専門家、デザイナー仲間、そして不満を抱く市民によって支持されている、考えられる理由がいくつか挙げられていました。 この理論が今でも正しいのか、また、もっと定量的なアプローチが可能なのか気になったのでやってみました。 私が見つけたもの 各国の最も人
OSSで世界と戦うために - ゆーすけべー日記
「日本人」を理由にしたくないし、「コードは全世界共通語」なのは分かっているけど、自分が日本人で日本語を母国語としていることはOSSにおいて不利になる。 この2年間のHonoの開発をしてきた経験で分かったことだ。 そこに目を瞑ってはいけないし、自覚することで世界と戦えるかもしれない。今回はそのことについて書こうと思う。 8k 現在、HonoのGitHubスター数は8,000を超えた。 これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。 数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。 なぜ「戦う」のか なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 ま
Sign-in form best practices Stay organized with collections Save and categorize content based on your preferences. Use cross-platform browser features to build sign-in forms that are secure, accessible and easy to use. If users ever need to log in to your site, then good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress.
JavaScript is cool (don't @ me), but how can a machine actually understand the code you've written? As JavaScript devs, we usually don't have to deal with compilers ourselves. However, it's definitely good to know the basics of the JavaScript engine and see how it handles our human-friendly JS code, and turns it into something machines understand! 🥳 | Note: This post is mainly based on the V8 eng
AIを使った論文の読み方
近年の AI の進歩により、論文の読み方も大きく変化を遂げました。AI を活用することで以前と比べてはるかに簡単かつ早く論文が読めるようになりました。 以前私の個人ブログにて、論文の読み方やまとめ方を紹介しました。その時には要約ツールは用いていませんでしたが、最近はすっかり要約ツールを多用するようになりました。 本稿では、最新の AI を使った論文の読み方を丁寧に紹介します。 基本的な流れ 本稿でおすすめするのは ChatGPT か Claude で要約を生成して論文の概要をつかみ、Readable で精読するという方法です。ChatGPT や Claude では単に全体の要約を生成するだけでなく、肝となる箇所を特定したり理解するためにも用います。具体的な手順については後の項で解説します。 私が特定のテーマについて調査を行う場合には、テーマに関係する論文を被引用数の多いものを中心に 10
Contents Command Line Interface Guidelines An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day. Authors Aanand Prasad Engineer at Squarespace, co-creator of Docker Compose. @aanandprasad Ben Firshman Co-creator Replicate, co-creator of Docker Compose. @bfirsh Carl Tashian Offroad Engineer at Smallstep, first e
しずかなインターネットの技術構成
こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています（楽しい）。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google TypeScript Style Guide
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
Sign-in form best practices | Articles | web.dev
🚀⚙️ JavaScript Visualized: the JavaScript Engine
Command Line Interface Guidelines
Design Docs at Google