Yasutaka Kato yasutakatou

技術文書の書き方

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

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

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

2022 年の夏休みに Zig で QUIC を実装してオープンソースとして公開するお手伝い

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

提供: 株式会社時雨堂
バージョン: 2022.6.0
著者: @voluntas

成果

SECKUN 2021/ProSec-IT 2021 コンテナ演習資料（公開版）

この資料について

九州大学のSECKUN 2021/ProSec-IT(enPiT-Pro) 2021の共通カリキュラムにおいて、近藤 @udzura が担当したコンテナ概要の授業にて使用した教材です。

今回、公益性を鑑み、授業固有の連絡事項などを削除した状態で公開します。

この記事はTSG Advent Calendar 2020の14日目の記事です。昨日の記事はJP3BGYさんのPXE BootとIntel DCIを用いたLinux Debug環境でした。

はじめに

カリー＝ハワード同型対応ってかっこいいけど、何のことだかよくわからない。わたくし昆布の現時点での（偏った）理解を、疑似コードを交えて説明していきます。ほぼ備忘録です。

概要

直観主義論理（自然演繹）の命題とTypeScriptの型との間のカリー＝ハワード同型対応を考えます。

前提

Wikipediaでは次のように書いてあります。

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

Protocol Buffersで高速な通信を型安全に実現する

最近AppleがProtocol Buffersの公式プラグインをGitHubに公開して話題になったので、実際に使ってみました。APIの通信が速くなったり、型安全に通信処理を書ける など、メリットが多いと感じたので簡単に紹介します。

他の事例だと、iOSオールスターズ2で発表された「これから始めるProtocol Buffers導入」が非常に参考になると思うので併せて読んでみてください。

この記事ではProtocol Buffersの概要について書いています。別途こちらの記事で使い方について サンプルを使って説明している ので、併せて読んでみてください。

Protocol Buffersとは

何故私は Heroku から離れたか、および新しい AWS セットアップのメモ

原著者:	Adrian Holovaty
原文:	Why I left Heroku, and notes on my new AWS setup

金曜日、私は Heroku から Amazon Web Services(AWS) を直接使うように Soundslice を移行しました。私はこの変更ができてとても、そうとても嬉しくて、私がどうやったかということと、もし皆さんが同じような立場だったら何故それを検討すべきかということについて広く伝えたいと思います。

	Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
	- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
	- Reasoning Before Conclusions: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
	- Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
	- Conclusion, classifications, or results should ALWAYS appear last.
	- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
	- What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from p

	#!/bin/bash
	# Wget Api Clinet for NiftyCloud
	# 2012/01/03 @ysaotome

	#===============================================
	# Settings
	#===============================================
	## 公開鍵
	ACCESS_KEY='hoge_accesskey'
	## 秘密鍵