Ryosuke Horiuchi uchiiii

技術文書の書き方

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

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

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

こちらの応募は終了しました、冬も募集予定です。

グーグルジャパンではなくてUSの本社での採用の話。私が受けたのはSoftware EngineerではなくてDeveloper Advocate。Engineering組織の下についているのでコーディング面接有り。ただし評価項目がSWEとは異なる。

以下転載:

	# wavfile.py (Enhanced)
	# Date: 20190213_2328 Joseph Ernest
	#
	# URL: https://gist.github.com/josephernest/3f22c5ed5dabf1815f16efa8fa53d476
	# Source: scipy/io/wavfile.py
	#
	# Added:
	# * read: also returns bitrate, cue markers + cue marker labels (sorted), loops, pitch
	# See https://web.archive.org/web/20141226210234/http://www.sonicspot.com/guide/wavefiles.html#labl
	# * read: 24 bit & 32 bit IEEE files support (inspired from wavio_weckesser.py from Warren Weckesser)

	package main

	import (
	"context"
	"fmt"
	)

	type GitHub interface {
	CreateRelease(ctx context.Context, opt *Option) (string, error)
	GetRelease(ctx context.Context, tag string) (string, error)

	; /usr/local/bin/nasm -f macho 32.asm && ld -macosx_version_min 10.7.0 -o 32 32.o && ./32

	global start

	section .text
	start:
	push dword msg.len
	push dword msg
	push dword 1
	mov eax, 4