Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに きっかけは、以下のツイートです。 「配列のすべての要素が条件を満たすならtrueを返す」関数を定義するとき、空の配列を渡したらfalseを返すかtrueを返すかが、良いプログラマかどうかの一つの境目だ — ふみ a.k.a.DJ Monad (@fumieval) May 29, 2023 このリプライや引用リツイート欄では、Trueを返すべき、Falseかな、例外を返すべき、要件による、といった意見がありました。 建設的な議論ができるコミュニティは素晴らしいと思う反面、同じコミュニティに属するエンジニアに対して「センスがない
はじめに 論文書きを最終的なアウトプットとしたとき、まずはマインドマップでの論文読み・論文解剖をすると良いように思う。 思いついたきっかけは、普段から自分の研究プロジェクト管理にマインドマップソフトのXmindを使ってたことと、１００冊読む時間があったら論文を１００本「解剖」した方が良いを読んでいたこと。Xmindを使った研究プロジェクト管理は論文書きとけっこう密接につながっているのでいずれ書く。 前提と目的 前提は、 何事もマネは大事 何事もひとつひとつの要素作りより、構造化の方が難しい 論文書きには、どこかにでかい律速段階がある ということで、これを踏まえて、論文作成のためにリバースエンジニアリングにより論文の要素と構成の関係を把握する。律速段階のうちのいくつかは、たぶんこの方法で解消or軽減されて、論文書きも進みやすくなるはず。 適応症 ・論文を書いたことがない ・自分なりの構成作り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
