OpenAIは、大規模言語モデル（GPT-4）でよりよい結果を出すためのプロンプトエンジニアリング（プロンプトのノウハウ）入門テキストを同社のウェブサイトで公開している。 同テキストでは、現在同社で最高の性能を持つ大規模言語モデルGPT-4を対象に、よりよい結果を導くための6つの戦略と、それぞれを実行する際の具体的な戦術（コツ）が掲載されている。 また、「Prompt examples」のページでは、上記で紹介したものを含む多数のプロンプト例が紹介されており、すぐに利用できるようになっている。 では紹介された6つの戦略を見ていこう。 明確な指示を書く LLMは利用者の心を読むことができないので、回答が長すぎる場合は「簡潔に」、単純すぎる場合は「専門家レベルで」と明示的に依頼する必要がある。 具体的な戦術としては下記が提案されている。 ・より関連性の高い回答を得られるよう、質問は詳細に ・モ
小学生に教えるために編集者歴17年の父親が本気で考えた…｢きちんと伝わる文章｣を書く10のコツ ｢説明ができる｣とは｢生きる力がある｣ということ
「伝わる文章」とはどのようなものか 私はWEB媒体の編集者／ライターをかれこれ17年ほどやっている。日本語で情報を伝えるのが仕事だ。 ジャンルとしては長文の体験レポートを中心に扱ってきた。ライトな読み物で、書くのも簡単そうだと思われるかもしれない。いやいや、そうでもないのだ。それぞれのバックグラウンドを持ち観察力に優れた書き手が、五感をフルに使い数時間かけて体験取材をすると、情報量がとんでもないことになる。それを限られた字数で読者にわかりやすく伝えるのは、実は技術のいる作業なのだ。 また、私は特に編集部の中でも新人ライターを多く担当しており、書き慣れない人が書いた文章を一緒に直し、読み手に伝わる書き方をアドバイスする経験をずっと積んできた。 そんな私が、小学生の子供の中学受験によってあらためて「伝わる文章の書き方」を見つめ直すことになった。本稿ではその経験について少し語らせてほしい。
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter：https://twitter.com/naoh_nak 2022年版（初版）：https://speakerdeck.com/naohiro_nakata/technicalwriting
追記: 10/11 ハテブでバズっているようで、色々指摘があったので追記 getElement*は動作が早いのでIDやクラス名が自明の場合はgetElement*を使う方がいいと言う意見もあり、また、ページの表示で大量に呼び出されるわけではないからボトルネックにはならないと言う意見もある。 getElement*で返されるオブジェクトは動的な変化に対応しており、querySelector*は動的な変化に対応していないため、場合によってはgetElement*を使うといい。このサイトで遊んでみよう。 https://ja.javascript.info/searching-elements-dom#ref-263 for await ... ofは非推奨なので Promise.allを現代的な書き方にした 顧客先のブラウザが古い場合も考慮して、あえてレガシーな書き方もする場合があるらしい。現
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
WEB+DB PRESSと私
「大江戸Ruby会議10」での発表資料です。 https://regional.rubykaigi.org/oedo10/
2024年のCSSの書き方、ワークフローとツールについて
CSSには大きく変わるタイミングが何度かありました。レスポンシブ対応、メディアクエリ、Flexbox、CSS Gridなどはその大きく変わったタイミングでしょう。 そして、2024年もこれらと同様に大きく変わりそうです。CSSのネスト、:has()疑似クラス、subgrid、コンテナクエリ、ビューポート単位などの新機能がすべてのブラウザにサポートされました。 2024年のCSSの書き方として、より保守しやすいCSS、ワークフロー、ツールについて紹介します。 How I'm Writing CSS in 2024 by Lee Robinson 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに デザインの制約 2024年のCSS お勧めのCSSツール 終わりに はじめに 2024年のCSSは、素晴らしいの一言に尽きます。
Go Conference 2023 ( 2023/06/02 Fri. ) https://gocon.jp/2023/ 登壇資料 株式会社アンドパッド プロダクトテックリード 小島 夏海 みなさん、Googleが公開したGo Style Guideは読みましたか？ ソフトウェア開発は継続的な活動であり、一般的に複数人で行うことが多いです。 継続的に複数人で開発を行う場合、自分が書いたコードを他人が読んだり修正したりすることが非常に多いです。 そのため可読性の高いコードを書くことは開発効率やメンテナンス性の向上に役立ちます。 Goはシンプルな言語ですが、どのように書くべきか悩むことが全くないわけではなく、そのような時従来はEffective Go/Uber Go Style Guide/OSSコード等を参考にどのように書くか決めていたと思います。 これらに加え、昨年末にGoogleからG
変更履歴を記録する
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
はじめに 私は他人のコードをレビューしたことも自身のコードを他人にレビューしてもらったこともない初学者として現在のプロジェクトに加わりました。そこから現在までの2年間毎月10から20ほどのプルリクエストをレビューし、またチームメンバー内で読みやすいコードについて議論することで、徐々に読みやすいコードを書くためのポイントが掴めてきました。 これらの経験を通じて、私が現在考えている読みやすいコードを書くためのポイントを本記事にまとめていきます✍️ 前提 言語はJavaScriptで、レガシーな環境での手続き的なJavaScriptを想定しています。 「JavaScriptの文法やメソッドは理解してきたけど、より読みやすいコードの書き方がわからない」と感じている初学者向けです。 筆者は一般的なコーディング規約や設計原則についての書籍や資料をほとんど参照していません（読んだことがある本と言えばリー
日本語からはじめる科学・技術英文の書き方
Online ISSN : 2423-8872 Print ISSN : 0029-0181 ISSN-L : 0029-0181
概要 この記事では、エンジニアにとって重要な、 「良いコードとはなにか？ どうすれば良いコードが書けるのか？」について、 基礎の考え方から、私なりに頑張ってまとめて記載してみようと思います。 ターゲット 新卒～１年目のエンジニア向けにわかるように、なるべくかみ砕いて説明をしようと思います。 第1章：良いコードとは？ まず初めに、良いコードとは何でしょうか？ ここでは会社に所属するエンジニアの視点から考えてみましょう。 会社に所属するエンジニアに求められるのは、 利益のあるソフトウェア（ゲーム） を作ることです。 言い換えれば、良いコードとは ソフトウェア（ゲーム）が生み出す利益を最大化するためのコードと言えます。 ここから、推論を進めてみましょう。 ⇒ 良いコードとは？ ⇒ ソフトウェア（ゲーム）が生み出す利益を最大化するコード ⇒ 利益を最大化するためには？ ⇒ 少ないコスト（時間・人件
「地の文の書き方」は、言語化が難しいと言われてきた――。 だが今は違う！十万字かければ語れる！教えられる！「地の文の書き方」、皆さんはどう習得しましたか？ 的確に「これを読めば書ける」という書物はありましたか？ 今回特に実感しているのですが、「プロット」や「文法」と違って、「小説っぽい文」「小説の描写」は！なかなか！論じるのが難しい！ わたくしもいくつか本を探して読んだことがあるのですが……「これさえ読めば」というものは見つかりませんでした。 言葉って正解がないし、芸術の分野だから「こう書こう」がまず定義・決定できないんですの！ケースバイケースの極み。 特に困るのが、国語やライティングの本を参考に「間違いのない文」は書けるけど「小説っぽい文ってなんだ!?」という中級者段階。 いやはやいやはや……マジで参考にできるやつが（見つけられ）ないんです。「とにかく書いてみよう」「好きな作家を模写しよ
良いシェルスクリプトのためのkillとtrapの基本 ～ シグナル番号は使わない、シグナル名を使う - Qiita
はじめに kill コマンドと trap コマンドはシェルでシグナルの送信と受信を行うためのコマンドです。このコマンドは意外と適切ではない使われ方をよく見かけます。この記事では kill と trap の基礎知識を解説します。 POSIX準拠のkillコマンドの構文 POSIX で標準化されている kill コマンドの使い方は次のとおりです。POSIX で標準化されているというのは移植性が高い書き方ということを意味しています。シグナル名の指定には -s オプションが必要です。そして signal_name であって signal_number でないことに注意してください。POSIX シェルの世界にシグナル番号という概念はありません。シグナル番号を指定した書き方は避ける方をおすすめします。
本稿は，日頃英語で書く経験が乏しい日本語話者が，短期間で英語論文を執筆する方法について解説する。作業手順は，日本語による構想と原稿執筆→AIによる英語翻訳→AIによる文体改善→著者による最終校閲である。一貫している原則は，人間が，AIが不得意としている領域の作業に最善を尽くすことで，最終成果物の質を上げることである。作業の際の留意点は，ストーリー・文体・語法の3つの観点別に説明する。それぞれの強調点は，ストーリーでは戦略的な構想，文体では英語の発想に即した表現法，語法では日本語話者が不得意とする領域である。本稿は総じて，人間とAIが相互補完的に作業を進めることを推奨する。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これは嬉しい ChatGPTプロンプト書き方のコツ、OpenAIが公開
テクニカルライティングの基本 2023年版
"レガシー"と言われないためのJavaScript再入門
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
「Go Style Guide」から学んだ可読性の高いコードの書き方
【JavaScript】読みやすいコードの書き方 - Qiita
チーム開発の生産性が向上する良いコードの書き方：強いエンジニアになるための思考法 - Qiita
【小説講座】地の文の書き方全部教えます！【例文付き約12万字解説】【AI活用講座追加】｜創作おTips@地の文講座
AIを活用して英語論文を作成する日本語話者にとっての課題とその対策