Skip to content

Instantly share code, notes, and snippets.

View gentamura's full-sized avatar
👋
Hi

Gen Tamura gentamura

👋
Hi
View GitHub Profile
@k16shikano
k16shikano / SKILL.md
Last active November 12, 2026 10:03
japanese-tech-writing/SKILL
name japanese-tech-writing
description 日本語の技術文書・書籍原稿の文章規範。段落と論証の構成(パラグラフライティング)、論証の厳密さ(ツッコミどころの除去)、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、翻訳調の比喩と擬人化の禁止(「運ぶ」「効く」「開かれた問い」など)、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。
license Unlicense(https://gist.github.com/k16shikano/67625f2a7d96e3bbdfae8d571a936063)

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

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

/**
* LINE → GitHub Issue → Google Sheets Logger (signature-less robust版)
* ※ Google Apps Script Webアプリでは HTTP ヘッダーを直接取得できないため、
* LINE 署名検証は割愛しています(Webhook URL を秘匿できる環境前提)。
* @license MIT
*/
/* ---------- 設定 ---------- */
const CONF = {
LINE_ACCESS_TOKEN: PropertiesService.getScriptProperties().getProperty('LINE_ACCESS_TOKEN'),
@Quramy
Quramy / index.tsx
Last active April 11, 2024 15:34
Analogy RSC and GraphQL resolver
import { cache } from "react";
import DataLoader from "dataloader";
// backend service clients
import { getPopularPosts, getUserById, getUsers } from "@/services";
const memoizedGetUserById = cache(getUserById);
const getUserLoader = () =>
@ymmt2005
ymmt2005 / howto-tech-docs.md
Last active March 17, 2026 03:41
技術文書の書き方

技術文書の書き方

このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。

科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。

しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。

@dabit3
dabit3 / marketplace.sol
Last active April 29, 2025 06:06
NFT Marketplace Smart Contract (V2)
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "hardhat/console.sol";
contract NFTMarketplace is ERC721URIStorage {

フロントエンドの技術選定で考えること

Frontend Study 用

前提: フロントエンドは式年遷宮が有効である

  • DB を持たないため、表層の技術を交換するだけで済む
    • JSON API が実質的な分解点になっている
    • 近年ではモバイルアプリのために JSON API が切り離されていることが多く、ここの利用者になるだけでよい
  • Rails や PHP で ORM ヘルパーにべったりな場合に困難になる(クライアントで同等のバリデーションを再現する必要)
@stepney141
stepney141 / BookmarkAPI_en.md
Last active December 10, 2025 02:53
(DEPRECATED) Twitter Undocumented Endpoints for Bookmark

float32
float64
int
int8
int16
int32
int64

Reactの難しさを分解しよう を読んで。

n番煎じの話題。今更な話題、それはわかってる。自分の周りの環境が変わったので、書き下すことで、再度整理したい。

抽象

サーバーが生成するHTMLが一つの粘土の像だとしたら、jQueryがナイフで、Reactは設計図を持った3Dプリンタ。

鼻が大きすぎるから削るとか、ちょっとしたことをやるのが jQuery の主な用途。しかしあるいは、職人的に、大きな塑像から、一つの像を切り出すこともできる。