Yuki Oshima os1ma

name

japanese-tech-writing

description

日本語の技術文書・書籍原稿の文章規範。整形（一文一行、引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。

日本語技術文書の文章規範

日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。

整形

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

結城浩

こんにちは。今後、GPT-4を使ったアプリケーションやサービスがたくさん登場してくると思います。その中には、たとえばSNSを利用したbotもたくさん出てくるでしょう（現在でもすでにありますけれど）。そこで質問なんですが、SNSでおしゃべりしている相手が、人間なのか、GPT-4などの技術を使ったAIなのかを識別するにはどのような会話をしてみればいいでしょうか。一般的なAIでは難しいかもしれないので、GPT-4に限ってもいいです。あなたの考えを聞かせてください。

ChatGPT Model: GPT-4

GPT-4のような高度なAIと人間を識別するのは、時に難しいことがあります。しかし、いくつかの方法を試してみることで、相手が人間かAIかを見極めることができるかもしれません。

複雑な感情やニュアンスについて尋ねる: AIは感情やニュアンスを理解するのが苦手です。複雑な感情を表現する文章やシチュエーションについて尋ねてみて、その反応を見てください。

58 bytes of CSS to look great nearly everywhere

When making this website, i wanted a simple, reasonable way to make it look good on most displays. Not counting any minimization techniques, the following 58 bytes worked well for me:

main {
  max-width: 38rem;
  padding: 2rem;
  margin: auto;
}

デスマーチが起きる理由 - ３つの指標

著者：青い鴉（ぶるくろ）さん @bluecrow2

これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。

今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。

昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。

The repository for the assignment is public and Github does not allow the creation of private forks for public repositories.

The correct way of creating a private frok by duplicating the repo is documented here.

For this assignment the commands are:

Create a bare clone of the repository. (This is temporary and will be removed so just do it wherever.)

git clone --bare git@github.com:usi-systems/easytrace.git

#NoSQLデータモデリング技法

原文：NoSQL Data Modeling Techniques « Highly Scalable Blog

I translated this article for study. contact matope[dot]ono[gmail] if any problem.

NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティックな理論に欠けている。本稿で、私はデータモデリングの視点からのNoSQLシステムファミリーの短い比較といくつかの共通するモデリングテクニックの要約を解説したい。

本稿をレビューして文法を清書してくれたDaniel Kirkdorfferに感謝したいと思う

	# Copyright 2019 Google LLC.
	# SPDX-License-Identifier: Apache-2.0
	# This snippet shows you how to use Blob.generate_signed_url() from within compute engine / cloud functions
	# as described here: https://cloud.google.com/functions/docs/writing/http#uploading_files_via_cloud_storage
	# (without needing access to a private key)
	# Note: as described in that page, you need to run your function with a service account
	# with the permission roles/iam.serviceAccountTokenCreator

	import os, google.auth
	from google.auth.transport import requests

	Latency Comparison Numbers (~2012)
	----------------------------------
	L1 cache reference 0.5 ns
	Branch mispredict 5 ns
	L2 cache reference 7 ns 14x L1 cache
	Mutex lock/unlock 25 ns
	Main memory reference 100 ns 20x L2 cache, 200x L1 cache
	Compress 1K bytes with Zippy 3,000 ns 3 us
	Send 1K bytes over 1 Gbps network 10,000 ns 10 us
	Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD