「◯◯GPT」や「ChatGPT搭載」はNG 米OpenAIがブランドガイドライン公開
米OpneAIは現地時間4月24日、ChatGPTなどOpenAIブランドを利用する際のガイドラインを公開した。ロゴマークやその利用方法、また「ChatGPT」などの文言を利用する際の注意点が記されている。 例えば、OpenAIのAPIを利用した製品について「◯◯GPT」「GPT-4搭載の◯◯」「ChatGPT搭載の◯◯」といった表現は使わず、「Powered by GPT-4」や「Built with GPT-4」などの表現を使うよう求めている。また、OpenAIのモデルを指すときはGPT-3、GPT-4、ChatGPT、DALL・Eを使い、Ada、Babbage、Curie、Davinci、GPT-3.5-turboなどのエンジン名を避けるようにとしている。
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
GoDoc を多用している - blog.syfm
最近は設計をする際にできる限り API 仕様を正確に記述するようにしている。このことを意識し始めた大きな要因は主に次の 2 つだと思う。 1 つ目は以前、前職で働いているときに柴田さんに API 仕様の重要性を教えてもらったことから。この時に聞いたことは以下のブログ記事にまとまっているのでぜひ読んでほしい。 yshibata.blog.so-net.ne.jp もう 1 つは、今年の頭に読み終えた A Philosophy of Software Design から。この本では、複雑さを減らすために API の仕様が限りなくシンプルで、多くの機能を提供する deep module を目指すべき、といったことが言及されている。 Go ではドキュメントシステムとして GoDoc が提供されているため、上記のような洗練された正確なインターフェースを記述するためにこれを開発時に利用している。 ロー
Xrea Coreserver API Document
共通 - API環境情報 共通 - API利用方法 【ご利用前に必ずお読み下さい】 共通 - APIステータスコード 共通 - APIエラーコード 共通 - APIサンプルコード・ご利用例 Cms Xoopsインストール WordPressインストール phpPgAdminインストール phpMyAdminインストール phpAdminインストール確認 MovableTypeインストール Cron Cronジョブ一覧 Cronジョブ作成/編集 Cronジョブ削除 DataBase Mysql/Pgsql Restore Mysql/Pgsql一覧 Mysql/Pgsql変更 Mysql/Pgsql Dump Mysql/Pgsql Dump一覧 Mysql/Pgsql Dump(全て) Mysql/Pgsql削除 Mysql/Pgsql作成 Ftp FTP接続情報 サブFTPアカウント一覧
マイクロソフト、Google、W3C、Mozillaらが協力。それぞれのWebブラウザのドキュメントをMozillaサイトに一本化。あちこちのWebサイトを見て回らなくても済むように
マイクロソフト、Google、W3C、Mozillaらが協力。それぞれのWebブラウザのドキュメントをMozillaサイトに一本化。あちこちのWebサイトを見て回らなくても済むように Mozillaは、マイクロソフト、Google、W3C、サムスンなどと協力して、それぞれのブラウザなどに対応した技術解説のドキュメントを一本化し、Mozilla Developer Networkの「MDN web docs」にまとめて掲載する取り組みを開始したと発表しました。 Webブラウザに関するHTMLやCSS、APIなどの機能の解説は、そのWebブラウザを開発するベンダのWebサイト、例えばマイクロソフトならMSDN（Microsoft Develpers Network）、GoogleならChromeのWebサイト、MozillaならMDN（Mozilla Developer Network）のWe
こんなに使える！今どきのAPIドキュメンテーションツール
Acroquest Technology LTxRT 人生がときめくAPIテスト自動化 with Karate Sparking Joy for API Testing Automation This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Ki
Swift API Design Guidelinesの紹介(Swift 3版) - Qiita
Swift.org - API Design Guidelinesを読みながら日本語で書き起こしてみました。 (全訳では無く、また一部意訳など混ざっています。) API Design Gudelinesということで、例えばアプリ実装の特に画面側のコード書く際にはあまり気にしなくても良い気がするものも少し混ざっている気がしました。 原文に豊富にあるコード例はほとんど省いたので、適宜原文見た方が分かりやすいかと思います。 基本 用途が明確なこと 用途が明確なことは、最も重要なゴール。コードは書かれるより読まれることの方がずっと多い。 明確さは簡潔さより重要 短いコードを追い求め過ぎて、可読性など損なうのは良くない。 ドキュメンテーションコメントを書きましょう すべての定義にはドキュメンテーションコメントを書きましょう。 (訳注: 処理に添えるコメントではなくクラス・メソッド・フィールド定義など
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
ESDoc - The Good Documentation For JavaScript - クックパッド開発者ブログ
こんにちは。会員事業部の丸山@h13i32maruです*1。 ソフトウェアのドキュメント(マニュアル)を書くには色々なツールや方法があります。 JavaScriptの場合はJSDocというドキュメンテーションツールがデファクトスタンダードです。 ですが、JavaScriptの最新仕様であるECMAScript2015(ES2015)がリリースされたことにより、 JSDocの競合として新しいツールが登場したり、JSDoc自体もバージョンアップしたりしています。 本記事ではそうした新しいツールの一つであるESDocを紹介します。 ESDocとは？ ESDocとは私が2015年4月から開発を行っている、JavaScript(ES2015)向けの良いドキュメントを作るためのドキュメンテーションツールです。 https://esdoc.org/ https://github.com/esdoc/es
API Documentation & Design Tools for Teams | Swagger
API Development forEveryone Simplify your API development with our open-source and professional tools, built to help you and your team efficiently design and document APIs at scale. Find your toolRead the docs Trusted by Empowering API Development Streamline your workflow with unparalleled API specification support Swagger places API specifications such as OpenAPI, AsyncAPI, and JSON Schema at the
Java版Foundationのこと、覚えてる？ - なるようになるかも
qiita.com 素朴な疑問があったので投稿してみました。これはその補足みたいなもの。 CoreData CoreDataって凄く独特な世界観を持っていて扱いづらいと思った人が多いのではないでしょうか。 なんでこんなのがXCodeやInstrumentsのテンプレートに居座っているのか理解できない、関連張ると動作が重くなりすぎて使い物にならない、CoreData内部の良く分からないエラーに悩まされている、普通にSQL書きたいからFMDB使ってます、幻滅しましたRealmに移行します、そんな雰囲気だと思います。 CoreDataの原型は、NeXTのFoundationが用いられた最初の製品であるEnterprise Objects Frameworkです。 20年前にデータベース製品の学習コストの高さと、オブジェクト指向言語とのインピーダンスミスマッチの問題に取り組んだこの製品は、普及はし
ESDocというJavaScript向けのAPIドキュメントツールを作りました - maru source
こんにちは丸山@h13i32maruです。 昨日、ESDocというツールをリリースしました。GW中になんとかリリースできて一息ついているところです。今回はそのESDocというツールについて紹介します。あと最後に雑談と宣伝があります。 ESDocとは？ ESDocとはJavaScript(ES6)向けのAPIドキュメントツールです。JavaScript界隈ではJSDocがデファクトスタンダードであり、ESDocもJSDocに触発されて作りました。なのでタグの使い方はなるべく互換性を持たせています。とはいえ不要だなと思うタグもかなりあったのでそれらは実装していません。 ESDocの特徴(主にJSDocに比べて)としてはこんな感じです。 詳細なドキュメントを生成する ドキュメントカバレッジを計測する テストコードとドキュメントを関連付ける ES6のclass, import/exportを使った
Python と型ヒント (Type Hints) - forest book
先日、Python の静的型チェッカーとして mypy を紹介しました。 mypy で静的型付け Python プログラミング - forest book 私には難しくてまとめきれないため、Guido が参照している漸進的型付け (Gradual Typing) も含め、また別の機会に、、、。 とか言っているうちに1ヶ月ほど経ってしまいました。 そうこうしているうちに PEP のドラフトも出てきたので区切りとしてまとめておきます。一通り調べたことを基にして書いていますが、私の誤解や勘違いもあるでしょうから怪しいところがあったら調べ直してみてください。もちろんツッコミも大歓迎です。 型ヒント (Type Hints) を導入するという提案 PEP 483 - The Theory of Type Hints | Python.org PEP 484 - Type Hints | Python
Javadoc ドキュメンテーションコメントの書き方 - Qiita
出展: プログラム内のコメントの書き方 | 天才まくまくノート はじめに（モチベーション） こんな話があります。あるソフトウェア企業が一人の技術者の採用を決めました。その決め手となった理由は、「公開しているオープンソースソフトウェアのドキュメントが素晴らしかったから」です。彼らは、作成されたドキュメントを見ただけで、その人には技術力がある、一緒に働いて欲しいと判断したのです。 ある国の言語を学ぶために読み書きの練習が必要であるのと同様に、コーディング技術をつけるには、多くの良質なコードを読み、多くのコードを書くことが必要です。設計ドキュメントを書くのも同じことです。日頃から分かりやすいドキュメントを書く鍛錬を怠らず、長年の経験を積んでいかなければ、良質なドキュメントを書く力は身に付きません。今日からドキュメンテーションコメントをバリバリ書いて、ドキュメンテーション力を付けていきましょう。
Nulab Developer API | Nulab
On your mark, get set, code! Build fantastic apps using Nulab APIs and get support from our developer community. Team chat app tool for sharing documents, files, and information in real-time. Typetalk API Simple diagram tool for creating UML models, flowcharts, network diagrams, and more. Cacoo API Project management, bug tracking, and version control for developers and their teams. Backlog API Ma
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C++ 標準ライブラリ - C++ の歩き方 | cppmap
GitHub - encode/apistar: The Web API toolkit. 🛠
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
