ドキュメントを書く技術 - blog
READMEを始め、ソフトウェアのドキュメント全般を書く技術というものをもっと洗練させていきたい。要件定義書のようなものだけでなく、開発方針や設計方針、API定義などなど。 これらのドキュメントをしっかりと整備するだけで、レビューの質も上がり新しい人が入ったときもスムーズに意識のズレなく開発ができる。はずだが、なかなかドキュメントの上手い書き方や管理の仕方というものは、コーディングのそれとは違い議論が活発ではない。 最近試してみたこと そういったドキュメントの中でも、"開発方針"や"設計思想"をどう残していくかということを考えている。それらを残しておくことで、コーディングのときも立ち戻る場所ができ、大きく道を踏み外さなくなる。 例えば、レイヤードアーキテクチャのようなものの"境界"をドキュメントにしていく。MVCでもクリーンアーキテクチャでも何でも良いけど、それらのアーキテクチャではそれぞ
賢い質問のしかた
翻訳： アラビア語 インドネシア語 ベラルーシ語 ブラジルポルトガル語 中国語 チェコ語 オランダ語 フランス語 グルジア語 ドイツ語 ギリシャ語 ヘブライ語 ポーランド語 ポルトガル語 ルーマニア語 ロシア語 セルビア語 スペイン語 スウェーデン語 タイ語 If you want to copy, mirror, translate, or excerpt this document, please see my copying policy. 多くのプロジェクトのウェブサイトがヘルプの項目からこのドキュメントにリンクを張っている。それは私達の意図した使い方なので構わない ―― しかしあなたがそのようなリンクをプロジェクトのページに追加しようとしているウェブ管理者ならば、リンクの傍らに目立つように、私達があなたのプロジェクトのサポート窓口ではないことを明示してほしい。 その注意書き無くし
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
エンジニアの10大ウソ · dongri
後でコメント付けるから これは暫定的な方法、本番リリース時はこの方法で書かない 大体終わった。後小さい問題何個か残ってるだけ エンジニア：”十日は必要”。Boss：”五日でできる？”。エンジニア：”できる！” TODO 私の端末ではちゃんと動くのに これはテストする必要ない、絶対問題ないから そう、もうテストした 一行の修正だけ、他の処理に影響しない これは前からあった問題 追加10ウソ 次コード修正する時ユニットテスト書くよ ９０％は終わった これは二分で解決できる そう、これは既知のBugだ 昨日はちゃんと動いてたのに そんなのありえない これはハードウェア/ネットワークの問題、私のコードと関係ない これはBugではなく、特性だ 私は今ドキュメント読んでる 私はサボってない、今ビルド中
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
ドキュメント作成時のあるあるアンチパターン20 - Qiita
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
React Fiberアーキテクチャについて | POSTD
初めに React Fiberは、現在進行形で進められているReactのコアアルゴリズムの再実装であり、Reactチームの2年以上にわたる研究の成果です。 React Fiberは、アニメーション、レイアウト、ジェスチャーといった領域に対する適性を向上させることを目指しています。React Fiberの目玉となる インクリメンタルレンダリング は、レンダリング作業を分割して、複数のフレームに分散させることができる機能です。 他には主に、新たな更新があった際に作業を休止・強制終了・再利用できる機能、更新の種類別に優先順位をつけられる機能、新しい並行プリミティブなどが挙げられます。 このドキュメントについて Fiberは、コードを見ただけでは分かりにくい斬新な概念をいくつも導入します。このドキュメントはそもそも、ReactプロジェクトにおけるFiberの実装に伴って私が取っていたメモを集めたも
ドキュメントをプログラムのように「開発」する時代が来た
一昔前、「厚い財布」は、お札をどっさり入れて高級店に出入りする「お金持ち」の象徴だった。貨幣と交換でモノやサービスを買う社会では、お財布の厚みによって受け取れるモノやサービスの量が決定されたからだ。 しかし、クレジットカードや電子マネーが普及して高額の現金を持ち歩く必要性がなくなった現在では、厚い財布は「スマートさに欠ける人」を指す表現になっている。大量の現金を持ち歩くのは不用心だし、クレジットカードやポイントカードなどで財布が膨らんでいると「お得」や「特典」といった言葉に踊らされている人だと思われがちだからだ。 情報システムの納品物となるドキュメントも、かつてはその厚みが数億円ものコストを象徴していた。基幹系システムなら、ドキュメント一式でキャビネットが数段占有されるのが当然のことだった。 しかし、いまや紙のドキュメントはお荷物。更新が大変なのでソースコードと乖離しやすいうえ、同時に複数
ちゃんと公式ドキュメントで確認するプログラマのリンク集 - Qiita
バグ調査やサポート状況確認するためにオフィシャルなドキュメントで確認することが多いので、公式リンクまとめてみた。 2019/06 最近ちょこちょこ観てる人いるっぽいけど古いままで申し訳ないので更新してみた。自分が参照したやつのメモだったりするので全然網羅してません(｀・ω・´)
ドキュメントの継続的な開発方法 | IIJ Engineers Blog
私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント
head内に記述する要素の総まとめ -meta要素、link要素、ソーシャルサービス用の要素、ブラウザやスマホアプリ用の要素など
HTMLドキュメントのhead内に記述するmeta要素やlink要素、ソーシャルサービス用の要素、ブラウザ用の要素、スマホアプリ用の要素などをまとめた「HEAD」を紹介します。 HEAD -GitHub 翻訳するにあたりいくつか尋ねたところ、著者様はとてもいい人でした。 公開当初から内容がアップデートされ、ライセンスもCC0に変更されています。 オススメの最小限の構成 要素 meta要素 link要素 ソーシャル関連のhead内の要素 ブラウザ・プラットフォーム関連のhead内の要素 スマホアプリ関連のhead内の要素 メモ オススメの最小限の構成 下記は、head内に記述する最小限のタグです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Objective-C 2.0プログラミング言語