2021年6月2日に行われたSendai Frontend Meetup #6で使用したスライドです。 GitHub サンプルコード https://github.com/KanDai/openapi-sample ReDocで生成されたドキュメント https://kandai.github.io/openapi-sample/ About Swagger Specification https://swagger.io/docs/specification/about/ Swagger Editor https://editor.swagger.io/ Stoplight Studio https://stoplight.io/api-design/ Swagger UI https://petstore.swagger.io/ Redoc https://github.com/Red
All-in-one markdown editor, collaborative canvas, and diagram-as-code builder
GitHubのIssueやPull requestsにアップロードした画像の削除 - coincheck tech blog
はじめに サイバーセキュリティ推進部の吉田です。普段は、CSIRTメンバーとしてAWS環境や各種端末のモニタリング、セキュリティインシデント対応、社内からのサイバーセキュリティに関する相談対応などの業務を行っています。 2023/05/10 追記 GitHubのアップデートによって、プライベートリポジトリのIssueやPull Requestsに新たにアップロードされたファイルは、権限を持たない外部からは参照できなくなったようです。詳細につきましては、以下のGitHubのブログをご確認ください。 https://github.blog/changelog/2023-05-09-more-secure-private-attachments/ 概要 GitHubのIssueやPull requestsに添付した画像はWebにアップロードされ、パブリックなURLが割り当てられます。このURLは
インフラの環境構築を行ったときに、はい、環境です、と接続情報だけ顧客に提供したところで、そのまま受け取ってくれることはない。 ドキュメントはないんですか？。 何を作ったかを示すドキュメントとセットで初めて、プロにお金を払って仕事をしてもらった気持ちになる。今でも、ドキュメントを残せ、ドキュメントがないと今どうなっているかがわからなくなる、常に更新して最新にしよう、そんな掛け声は健在である。 このドキュメント、年々複雑さが増していると思う。というのも、IT関連のソフトウェアにしろクラウドにしろ、機能は増えるばかりだからだ。かつ、設定自体は年々洗練されており、デフォルト値で動くことも多い。たくさんの設定項目があるが、設定するのはほんの一部分である。 ドキュメントに何を残すべきか。設定値全てをドキュメントに書き込もうものなら莫大な量になる。一方で変更したものは少ししかない。このギャップが激しくな
静的サイトジェネレータ「Hugo」と技術文書公開向けテーマ「Docsy」でOSSサイトを作る | さくらのナレッジ
最近ではWebサイトを構築する際にWordPressなどのCMS（コンテンツ管理システム）を利用することが多いが、今日でも静的なHTMLファイルを使ったサイト構築には多くのメリットがある。今回は、こうしたHTMLファイルベースのサイト構築を支援するHTMLファイル生成ツール「Hugo」を紹介する。 静的ファイルでサイトを作るための支援ツール「Hugo」 コンテンツの作成や編集の容易さから、昨今ではWebサイトを構築する際にCMSを利用する例が多い。ただ、CMSを使用するにはCMS自体のインストールや設定、データベースの準備などが必要であるため、更新頻度の低いサイトやページ数の少ないサイトでは静的なHTMLファイルを使って構築したほうがコストが低くなる場合がある。 とはいえ、HTMLファイルをいちいち手動で作成するのは楽ではない。そのため、HTMLファイルを半自動生成するようなツールが数多く
Web フロントエンドにおけるコロケーション (co-location) という考え方について - mizdra's blog
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
機能開発タスクの設計資料のテンプレートを作成してみたら、担当機能をもっと愛せるようになった - Qiita
はじめに この記事は「株式会社ビットキー Advent Calendar 2022」 9日目の記事です。 今回はWork & Experience Product所属の@usu_shinが担当します！ ビットキーでは日々多くの機能開発が行われています。その中で発生する"設計"という工程でどう考えていくのが良いのかを型化し、設計資料のテンプレートとして表現したので、この記事ではそのテンプレートを紹介させていただきます。またテンプレート作成の副次的効果によって、担当する機能に愛情を注げるようになったというところも少しだけ話をさせていただきます。 この記事でいう設計とは この記事ではアサインされた機能開発タスクをどのように理解し、どのような手法で完了まで持っていくかを決定していく作業を設計と呼んでいます。 実装上の技術的決定を行う行為を指す設計よりも広義な意味で設計という言葉を使用しておりますの
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
本記事では、「Chain-of-Abstraction (CoA) Reasoning」についてざっくり理解します。軽めの記事です。 株式会社ナレッジセンスでは普段の業務で、生成AIやRAGシステムを活用したサービスを開発しています。 この記事は何 この記事は、最近聞くようになった「Chain-of-Abstraction (CoA) Reasoning」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合は以下の記事もご参考下さい。 本題 ざっくりサマリー LLMが外部ツールを使って回答を生成するときの、回答精度を高める手法についての論文です。Metaの研究者らによって2024年1月に提案されました。「Chain-of-Abstraction (CoA)」という手法を使うメリットは、RAGに応用することで
「サポートを当初発表よりも長く延長延長延長延長延長延長延長延長延長延長延長」 AWS公式ドキュメントの誤記が「破壊力高い」と話題
一連の誤記は、原語（英語）版からの機械翻訳が原因とみられる。AWS公式ドキュメントの多くには「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します」との注意書きがある。 つまり日本語のドキュメントはあくまで機械翻訳なので、参考程度の情報にすぎないわけだ。冒頭のような派手な誤記は確認し次第修正するが、正確な情報が速やかに必要なら原語版を読んでほしい、ということだろう。 誤記を見つけた人たちも承知しているようで、SNSではおおむね“笑えるミス”として受け止められている様子だ。一方で、中には「企業ならちゃんとしてほしい」とする声もあった。 関連記事 “AWS公式サイト風”にカップ麺を紹介する画像が話題 分かりにくい説明文をそれっぽく再現 「もはやAWS文学」 カップ麺の特徴をAWSの公式サイト風に説明した画像が「もはやAWS文
なぜその API は使われないのか？ API の活用を拒む3つの壁とその対策 - CData Software Blog
こんにちは！ CData Software Japan リードエンジニアの杉本です。 大変ありがたいことに、最近あるSaaSを提供する会社さんから「リリース前のAPIを触ってみてフィードバックをくれませんか？」と依頼を受けました。 私は以前こんな記事 を公開するほど、APIどっぷりな人間なのですが、数多くの SaaS APIを触ってきてよく考えることがあります。 それは SaaS APIというサービス・プロダクトそのものを成長させる上で、もっとも重要なことは「顧客・デベロッパーが、そのAPIをどれだけスムーズにキャッチアップできるか？」という点に尽きるのではないか？ というものです。 以下のグラフはAPI管理ツールを提供するSmartBearのAPI調査において、APIドキュメントで最も重要な要素とは何か？ というアンケート結果のランキングですが、ExamplesやAuthenticati
万能ドキュメントサービス「Notion」をさらに活用できるWebサービス・Tipsを徹底解説！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、多彩なドキュメントを作成できる万能サービスとして人気の「Notion」を、もっと便利に活用できるWebサービスやTipsをご紹介していきます。 Notion単体でもさまざまなことができますが、Webサービスを組み合わせることでデータの可視化やインタラクティブ要素の追加など多彩なことが実現できるので、まさに無限の可能性を手に入れられると言っても過言ではありません。 「Notion」を利用中の人もそうでない方も含めて、ドキュメントサービスにご興味ある方はぜひ参考にしてみてください！ ■「Notion」とは まず最初に「Notion」をまだ使ったことがない人に向けて、どのようなサービスなのか概要を少し解説しておきます。 【 Notion 】 「Notion」はノートやメモなどのドキュメントを作成したり、タスク管理やWikiのようなページを作れ
〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
Diagrams lets you draw the cloud system architecture in Python code. It was born for prototyping a new system architecture without any design tools. You can also describe or visualize the existing system architecture as well.
困った時はドキュメント、どうもかわしんです。最近、諸事情で SQLite のドキュメントを読んでいます。 前回の記事 で紹介した通り SQLite を Rust で再実装しています。おかげさまで 300 を超える Github Star もいただき嬉しいです。 github.com SQLite は全ての仕様が ドキュメント にまとめられているので、そのドキュメントと本家の実装を読み比べながら実装しています。 SQLite を再実装する上で特に以下のドキュメントは役にたちます。これらだけで最小限の SQLite の実装は作れると思います。 Overview Documents > About SQLite いかに SQLite がすごいかを自慢しているドキュメント。使おうとしている人には安心を、再実装しようとする人には絶望を与えてくれます。 Programming Interfaces >
こんにちは。PlayStation 5が一向に買えない@giginetです。普段はモバイル基盤部というところでiOSの基盤開発をしています。 皆さん、行動していますか？我々は日々Webサービス上で様々な行動をしています。サービス開発において、改善に活かすための効率的な行動ログの収集方法はしばしば課題になります。 今回は、サービス開発者がモバイルアプリ上で簡単にログを定義し、分析を行えるログ基盤を導入した事例について紹介します。 行動ログとは何か モバイルアプリの行動ログとは、ユーザーのアプリ上の操作や利用状況を取得、集積するためのものです。 例えば、特定の画面を表示したり、特定のボタンをタップしたり、といったユーザー操作を起点として送信されています。 集められたログは、サービス開発のための分析や実態把握に役立てられます。 最近はFirebase Analyticsなど、PaaSの形態で提供
IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head
Reanimateはアニメーションを作成するためのライブラリです。 ReanimateはHaskellのライブラリとして実装されているのでプログラムによってアニメーションを記述することができます。ライブラリに実装されている機能も多く、ドキュメントも豊富ですし、オンラインのPlaygroundまで用意されていてかなり完成度の高いライブラリになっています。さらにLaTeXや物理エンジン（Chipmonk 2D）, POV-Ray, Blenderなど外部ツールとの連携もサポートされています。アニメーションの各フレームはSVGで書き出されるようになっており、幾何学的な図形やSVGフォントを使った文字などから構成されたアニメーションを作るのが得意です。作ったアニメーションは最終的にMP4, GIF, WebMに出力することができます（中間生成物である各フレームのSVGを取り出すことも可能です）。
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
動的型付き言語は素早くプロジェクトを立ち上げるのに向いており、静的型付き言語は長期間の保守にむいているという仮説 - kmizuの日記
注：誤解されないように最初にこの記事の意図を書いておくと、古典的な静的型付き言語VS.動的型付き言語の論争をするつもりはありません。これまで色々なプロジェクトを観察（風聞も含む）して来たところ、そういう傾向があるのではないかという仮説です。それと、文脈として主にWebアプリケーション開発する時のことを想定しており、それ以外のケースはいったん脇に置いています。WebアプリケーションだとPHP（動的型付き言語）の方が圧倒的に事例多いのではという感想もありそうですが、その辺りを考え出すと話がこんがらがるので、これもいったん脇においています。 たとえば、色々な事例を見聞きするに、スタートアップ企業において動的型付き言語であるRubyのWebアプリケーションフレームワークであるRuby on Rails（RoR）は好まれる傾向にあります。近年のPythonの動向はさておき、未だにRoRの求人がかなり
仕事力のベースになる「メモの能力」を上げる方法。1日に3つ○○をメモするといい - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
ビジネスパーソンであれば、毎日なにかしらの「メモ」をとっているでしょう。ただ、そのメモをきちんと活かせているでしょうか。「とりっぱなし」になっている人も多いかもしれません。 そんな状況はなぜ起きてしまうのか、そしてどうすればメモをきちんと活かすことができるのか——。コクヨ株式会社のワークスタイルコンサルタントであり、著書『考える人のメモの技術』（ダイヤモンド社）が注目されている下地寛也（しもじ・かんや）さんがアドバイスをくれました。 構成／岩川悟 取材・文／清家茂樹 写真／石塚雅人 普段の雑談でアウトプットの習慣をつける よりよい仕事をするために不可欠の「インプットメモ」 日頃のトレーニングだけがメモの能力を向上させてくれる 普段の雑談でアウトプットの習慣をつける メモをとりっぱなしにしてしまう人には、多くの場合、「メモを活かしたアウトプットをする習慣がない」と私は見ています。 メモをとる
Go Style
Documents The Style Guide outlines the foundation of Go style at Google. This document is definitive and is used as the basis for the recommendations in Style Decisions and Best Practices. Style Decisions is a more verbose document that summarizes decisions on specific style points and discusses the reasoning behind the decisions where appropriate. These decisions may occasionally change based on
GitLab的ドキュメント文化を組織にインストールする（実践編:スタートアップMNTSQの事例）｜Anno Takahiro
会社組織にドキュメント文化をインストールすることの有用性や、GitLabのような企業がどのようにドキュメントを運用しているかを、前回記事で書いた（スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ）。今回は、私のいるスタートアップのMNTSQ（モンテスキュー、と読みます）でどのようにそれを実践しているか、実際のところどのような成果が出ているのかについて書いてみたい。 MNTSQでは、当初からドキュメンテーションの重要性を経営メンバー全員で認識しており、社内ドキュメントをGitHub管理でメンテナンスしながら作り上げていくようにしていた。この大枠の仕組みの設計部分は弊社のデザイナーの生谷(@ikutani41)が初期に考案/メンテしたものである。デザイナー視点からこのような仕組みが設計され稼働されることは珍しいと思う。この辺については本人からもどう
前回は「今日から始めるswagger入門」という最低限書けるようになっておいた方が良い物をこちらの記事で解説させてもらいました 今回は、筆者が4〜5年ほど現場で見てきたswaggerを元に、現場で必要になるswaggerの知識をまとめましたので、ぜひご覧になっていただけると嬉しいです！ タグ付け pathsに書かれている各APIendpointをタグ付けしてグルーピングする目的で使用されます 現場では大量のAPIendpointを設計していくこととなるので、多くなってくると大変見辛くなってきます それをグルーピングすることにより見やすくしようということです openapi: 3.0.3 info: title: test-api version: 0.0.1 # ここから tags: - name: user description: ユーザー情報 # ここまで paths: /users
一休.com レストランを開発している所澤です。この記事は一休.comアドベントカレンダーの10日目の記事です。 先日、一休.comレストランの管理画面をリニューアルしました。 この記事ではその際にAPIの実装方法として採用したGraphQLについてフロントエンド視点で利点や使い所について述べます。 GraphQLについて以下の記事がわかりやすかったです。 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！ 短いまとめ 新しくAPIサーバーを書くなら是非GraphQLで！ というくらい良かった Apolloのエコシステムに乗り切らなくてもいい。ふつうのRESTfulなAPIサーバーの代わりに、くらいの気軽さでGraphQLを採用してもいい プロジェクトの概要 今回リニューアルした一休.comレ
オンラインノートサービス「Evernote」は2月14日（現地時間）、無料プランの機能制限を緩和。これまで有料プラン向けに提供していた14の機能を無料プランのユーザーにも開放した。新たに無料化された機能は以下の通り。 ・履歴のメモと復元 ・オフラインノートとノートブック ・PDF 注釈 ・PDFエクスポート ・名刺スキャン ・スプレッドシートのプレビュー機能 ・Evernote にメモをメールで送信 ・メールによるノートの共有 ・カスタム グローバル キーボード ショートカット ・モバイルの「作成」ボタンをカスタマイズ ・カスタム テンプレート ・ブール検索（AND、OR、NOTなどの演算子を使った高度な検索機能） ・位置情報の検索 ・ドキュメントと画像の検索（無料プランでは2月14日以降に追加したコンテンツのみ対応）
No one is an island. Learnings from fostering a developers community.
APIの開発は複雑でコストがかかる可能性があり、頻繁に更新されることからドキュメントを整備するのも難しい。APIの設計、開発、ドキュメントの整備、管理にまつわる課題と効率さの問題に対処するアプローチが、RESTful API Modeling Language（RAML：RESTful APIモデリング言語）だ。 RAMLコードを使えば、開発者はAPIの動作を説明する仕様を策定してからそのAPIをデプロイするまでのAPIライフサイクルを管理することができる。 RAMLとは RAMLは、RESTful APIを記述することを目的とするオープンソースの記述言語だ。2013年、米国のIT自動化および統合ベンダーであるMuleSoftを中心とする数社の企業によって作成されたRAMLはAPIの開発に大きな役割を果たしてきた。2018年、MuleSoftはSalesforceによって買収され、RAML
NTT Com で OSS を作って公開してみた - やったことリスト共有 - NTT Communications Engineers' Blog
この記事は、 NTT Communications Advent Calendar 2022 8日目の記事です。 サマリ OSS 公開中の Go による SDN コントローラー Pola PCE の開発ノウハウを紹介 開発・公開・運用に際してやったことと得られた Tips を紹介 （CI・ドキュメント・コンテナ・その他 Go 関連） はじめに イノベーションセンターの三島です。 普段の業務では Multi-AS Segment Routing（SRv6/SR-MPLS）や Telemetry などの技術検証、BGP 技術の検証と AS 運用などを行っています。 この記事では、SDN コントローラーを OSS として公開して得た知見を、Go による開発支援や GitHub を通じた公開・運用の Tips を交えつつご紹介します。 公開した OSS: Pola PCE 経路制御技術の Segm
この記事は、技術書典 11 で頒布中の「Vivliostyle で本を作ろう vol. 5」から抜粋した記事です。ご興味ありましたら、Vivliostyle を使って組版された本誌もぜひお買い求めください！ また、この記事以外の内容もすべて Vivliostyle 公式サイトで無料公開中です。 技術書やドキュメントを執筆する際、あなたはどのような形式で文章を書きますか？ 最近ではもっぱら Markdown で書かれることが多いですが、この Markdown を拡張するポテンシャルを持つお気に入りの OSS プロジェクト「MDX」を紹介します。 MDX = Markdown + JSX MDX の名前の由来は Markdown + JSX なので、MDX を理解するためにはまず JSX について知る必要があります。 JSX とは JavaScript の拡張構文の一つで、元々 React の
＜この記事の著者＞ ばんか（bamka） - Tech Team Journal Web制作会社の会社員として働きつつ、個人でブログ／メディアライターとしても活動するパラレルワーカー。 ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。 Webサイトや本で学んだ知識を、自分のものにして活用できるレベルまで引き上げるには、アウトプットが重要だと考えて、積極的にアウトプットするようにしています。 ただ、アウトプットの仕方も大事。知った知識をただSNSにコピペで貼り付けるようなやり方は、良質なアウトプットとは言えないと考えています。 そこで今回は、私が実践している「良質なアウトプット」に転換するために気を付けているポイントについてお話しします。 【目次】 １：第三者に見てもらう ２：自分の言葉で語る ３：図にまとめる
ドキュメント執筆にもGit、ビルド、テストで再利用性や整合性を実現する「Writerside」、JetBrainsがプレビューリリース
Kotlinなどの開発元として知られるJetBrainsは、テクニカルドキュメントのための一連のツールを統合したドキュメントオーサリングツール「Writerside」のプレビューリリースを発表しました。 ソフトウェア開発においては、テキストで記述されたソースコードをGitでバージョン管理し、ビルドによって複数のソースコードを1つのアプリケーションへとまとめ上げ、コンパイルし、テストをして本番環境へのデプロイによりアプリケーションを公開します。 そしてこのプロセス全体を、さまざまな機能を備えたツールチェンを用いて自動化することで、ソフトウェア開発の効率を高めています。 一方で、例えばアプリケーションのチュートリアル、SDKやAPIのリファレンスドキュメントなどのドキュメントの制作過程においては、複数のファイルをフォルダにまとめ、手作業で目次のページとリンクさせることや、ソースコードのサンプル
OpenAI API ドキュメントの日本語訳をこちらでまとめます。文字量の多いドキュメントなので、セクションごとに記事を分割しています。 今回は「GET STARTED 」のセクションからLibraries 、Models、TutorialsそしてUsage policiesを抜粋した後編です。 基本 DeepLで翻訳して、気になるところだけ書き換えています(ほぼ気になるところがないのが、DeepLのすごいところ)。原文との突き合わせができるようにはじめに原文を入れてますので、間違いなど見つけられましたら、ぜひご指摘ください。ご指摘箇所は随時反映させていただきます。 原文のリンクが有効になってますので、それぞれ必要な場合は原文リンクの方を参照ください。 前回のおさらいはこちら Python library｜Python ライブラリWe provide a Python library, w
オペレーション部 江口です。 先日、社内でビジネスライティングについてオンラインで講義する機会があったので、その資料を公開しておきたいと思います。 いわゆる技術文書というよりは、メールやSlackなど、相手とやり取りを行う際の文章作成を主に考えた資料となっていますので、その点ご承知おきください。 背景 講義を行ったのは、アカウント周りの作業を行うアカウントチームに対してでした。チームの業務内でメールでの顧客とのやり取りやSlackでの社内でのコミュニケーションなど、文章を作成する機会が多く、その際の書き方に課題を感じている方が多いようだったので、少しでも助けになればと思いこの講座を企画しました。 私は別に人に自慢できるほど文章がうまいわけではないですが、約20年のエンジニアのキャリアで顧客とのやり取りや技術文書の作成などをそこそこの数こなしてきました。先輩や上司などからいろいろな指摘を貰い
2020年後半版Vue.jsを使ってる人には必ず知っていてほしいドキュメントに書かれていないComposition APIのコードの書き方とVuex vs provide/inject - Qiita
2020年後半版Vue.jsを使ってる人には必ず知っていてほしいドキュメントに書かれていないComposition APIのコードの書き方とVuex vs provide/injectJavaScriptVue.jsフロントエンドVuexCompositionAPI まえがき 最近iCAREさんの所で Vue.js を一緒にやらせていただいているのですが、フロントの技術スタックがかなりモダンであり、開発体験が良く、ノウハウをどんどん公開して良いと言っていただけたので、その内容を共有するシリーズです. 今回の記事の内容はiCareさんのDev Meetupで話した内容になります. 最近公式のソースを追った所、 Composition API はapiの紹介はあれども、コードの書き方やその背景、Tips等は全然見当たりませんでした. また、すごく強力なapiである provide/inject
手元で動く軽量の大規模言語モデルを日本語でファインチューニングしてみました(Alpaca-LoRA)｜masa_kazama
イントロ最近、ChatGPTやGPT-4などの大規模言語モデル(LLM)が急速に注目を集めています。要約タスクや質疑応答タスクなど様々なタスクで高い性能を発揮しています。これらのモデルはビジネス分野での応用が非常に期待されており、GoogleやMicrosoftが自社サービスとの連携を進めているという報道も相次いでいます。 今回は、手元で動作する軽量な大規模言語モデル「Alpaca-LoRA」を日本語にファインチューニングしてみました。この記事では、そのファインチューニングのプロセスや応用例について簡単に解説していきます。ChatGPTやGPT-4は、モデルがブラックボックスでありAPI経由でしか入力を与えて出力を得ることができません。さらに、現時点（2023年3月20日）では、独自のデータを用いてファインチューニングを行うこともできません。 しかし、Alpaca-LoRAというモデルを用
2年間の開発者ブログ運営のノウハウや意識してること - NTT Communications Engineers' Blog
みなさんこんにちは、イノベーションセンターの @Mahito です。普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。 今回は、本 NTT Communications Engineers' Blog を2年間運営してきたノウハウについて共有できればと思います。先日 はてなブログ DevBlog Meetup #1 に登壇させていただく機会があり、ブログ運営に関していくつかお話しさせていただいたのですが、イベント当日に言えなかったことや言ったことの補足などをできればと思います。 目次 目次 開発者ブログのこれまでと目的 運用のノウハウ・意識していること 執筆者の確保・継続・インセンティブ設計 1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう 2. ニュースリリースを見て、技
こんにちは、pixivのリクエスト機能を開発するチーム（以下、リクエストチーム）でプロダクトマネージャーをしているgeta6です。 ピクシブでは、社内ドキュメンテーションツールとしてNotionを採用しています。Notionでうまいことドキュメンテーションが機能し、継続できるよう、使い方やルールを各メンバー・各チームみんなで考えています。 本日はそんなNotionで実際にやってみて得られた気づきや知見をシェアします。もし参考になることがあれば、取り入れたり取り入れなかったりしていただければ幸いです。 背景 リクエストチームは立ち上げ当初より一貫してフルリモート体制で働いています。お互いにそれほど顔馴染みのないメンバー同士でしたが、第1回目の緊急事態宣言が出る前後からこちら、ほぼ物理的に顔を合わせることなく仕事をしています。 基本的にメンバーはDiscordに常駐しており、朝会・定例・雑談・
【感想】『りあクト！ Firebaseで始めるサーバーレスReact開発』： #りあクト でmBaaSへ - Rのつく財団入り口
表紙は親密度の上がった笑いあう二人。尊い…(違) 技術同人誌の『りあクト！』３部作と続編も読んだので、5作目を読みました。 今回はこれまでのReact開発の知見を活かし、BaaSあるいはmBaaSの代表格Firebaseにバックエンドをお任せし、世の中に公開していく実際のサービスをサーバーレスで開発していく本となっています。今回もまたまた本文は会話形式で読みやすいです。 表紙は親密度の上がった笑いあう二人。尊い…(違) 第1章 プロジェクトの作成と環境構築 第2章 Seed データ投入スクリプトを作る 第3章 Cloud Functions でバックエンド処理 第4章 Firestore を本気で使いこなす 第5章 React でフロントエンドを構築する 第6章 Firebase Authentication によるユーザー認証 まとめ：Firebaseを使ったサーバーレス開発がわかる本
なかなか上手い表題を考えるのが難しかったのと， 置かれた状況によって「役立つ」の尺度が変わる． また技術文書に限るものでもないように思ったので， 単に文書とした． なんとも正確ではないが， 何も知らずに数式を書き連ねていくよりはよいだろうということで， この表題で本稿を書くことにした． ご容赦願いたい． はじめに 今やテクノロジーは高度に進化して， 様々な分野で数式を用いたコミュニケーションが必須となっている． しかし一方で数式と聞いて，その「書き方」に関して注意が払われることは意外に少ない． 清書する！ 普段，数式に馴染みのある人でも，以下の時間が大部分を占めるのではなかろうか． 計算用紙に式を書く (宿題などの)レポートを書く 板書する これらはそれこそ学生や教員の垣根なく，日々体験していることだろう． だが次の機会がそうそうない． 清書する これは「不特定多数の人に向けて投稿する」と
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenAPIを使ってAPIドキュメントとモックサーバーを良い感じにした話
Eraser – Docs and Diagrams for Engineering Teams
ドキュメントの限界 - orangeitems’s diary
RAGを複雑な質問に強くする手法「CoA」について
Diagrams · Diagram as Code
SQLite を再実装する時に役にたつドキュメント - kawasin73のブログ
ドキュメントベースの型安全なモバイルアプリ行動ログ基盤の構築 - クックパッド開発者ブログ
QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に
複雑なアニメーションをプログラムする 〜Reanimate入門〜
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
現場で必要になるswaggerの知識 - Qiita
新管理画面のAPIにGraphQLを採用した話 - 一休.com Developers Blog
昨年末に無料プランを大幅制限したEvernote、一部機能を無料化
Design Docs を活用して効果的にプロダクト改善
RESTful APIの設計、開発、ドキュメント管理を手助けする「RAML」とは
Markdown を拡張する MDX はドキュメント作成の新たな可能性？
意味のないアウトプットをやめる７つの方法 - paiza times
OpenAI API ドキュメント 日本語訳｜#2 GET STARTED 後編｜ゑぐみかるちゃあ
社内で行ったビジネスライティング講座資料を公開します | DevelopersIO
ピクシブでのNotionのつかいかた - pixiv inside
数式がある文書作成に役立つ資料まとめ | Math Relish