難しい単語も一発検索！ Googleドキュメントの「正規表現」を使った検索と置換の便利技 【今日のワークハック】 | ライフハッカー・ジャパン
長い文章を書いているときには、特定の文字列をすばやく見つけることができると便利です。 Googleドキュメントの「検索と置換」は、その役に立ちますが、さらにすごい機能があります。 その隠れた機能というのが「正規表現（regular expression：RegEx）」です。 今日のワークハック：「正規表現」を有効にして「検索と置換」をフルに活用する文章の中で特定の文字列を見つけ出せる機能は、非常に便利です。Googleドキュメントの「検索と置換」は、「正規表現」を使うと、検索機能をもっとレベルアップできます。 標準の検索機能では決まったテキストしか探せませんが、正規表現を使えば、パターンを定義し、複雑な文字列を簡単に見つけ出すことができます。 残念ながら、現在のGoogleドキュメントは、正規表現のキャプチャグループを使った置換には対応していません。つまり、正規表現を使って、特定の文字列を
Design Docs を活用して効果的にプロダクト改善
No one is an island. Learnings from fostering a developers community.
VSCodeでJavaScript / TypeScirptの未使用import文を自動で削除する - Qiita
こうするとファイル保存時に未使用のimport文を削除し、さらにimport文の順番を並べ替えてくれます。順番はimport元のファイルパスをアルファベット順に並べているようですね。 指定できるキーはexplicit以外にもありますので、詳しくはドキュメントをご覧ください。 最後まで読んでいただき、ありがとうございました！
25000行超えのAPIドキュメントを分割した話
はじめに COUNTERWORKSバックエンドエンジニアの伊藤です。 この記事ではAPIドキュメント分割の知見を紹介します。 弊社では OpenAPI を使用したスキーマ駆動開発を採用しています。 1ファイルで管理していたところ、25000行を超える行数となり管理コストが高くなっていました。 そこで分割作業を実施したのですが、どのような方針でどう対応したかを紹介します。 1ファイルで運用するデメリット そもそもどんなデメリットが発生していたのかを記載します。 全体の構造が把握しづらく、新規参画者への認知負荷が高い 行数が多すぎるため、RubyMine など IDE やエディタのパフォーマンスが落ちる 1ファイルの内部で複数の箇所を参照しているが、それぞれCommand fで該当部分を探す必要がある。そのため、見ているコードの箇所が頻繁に飛んで情報が追いづらい 実際にやったこと 方針 チーム
社内技術ドキュメンテーションを科学する - スタディサプリ Product Team Blog
最終更新日: 2024年05月07日(火) 1. ご挨拶 2. 本記事執筆のモチベーション 3. ワークショップを通じて得たフィードバック 3-1. Pains -過去抱えた/現在進行形で抱えている辛み- 3-2. Approaches/Solutions -Pains を解消するために取った方策や導き出した解決策- 3-2-1. えいやで場所を決め打ちしてしまう(e.g., GitHub Wiki + Google docs しか使わない) 3-2-2. 個人的に、2023/12/05時点で〜みたいな書き方を心がけている 3-3. Tips -効果的な手法- 4. オーディエンスからの反響 4-1. 気づきや学び・NEXT ACTIONS 4-2. プレゼンター(@hayat01sh1da)へのフィードバック 4-3. Slack での反応 5. おわりに 1. ご挨拶 初投稿となります
2年間の開発者ブログ運営のノウハウや意識してること - NTT Communications Engineers' Blog
みなさんこんにちは、イノベーションセンターの @Mahito です。普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。 今回は、本 NTT Communications Engineers' Blog を2年間運営してきたノウハウについて共有できればと思います。先日 はてなブログ DevBlog Meetup #1 に登壇させていただく機会があり、ブログ運営に関していくつかお話しさせていただいたのですが、イベント当日に言えなかったことや言ったことの補足などをできればと思います。 目次 目次 開発者ブログのこれまでと目的 運用のノウハウ・意識していること 執筆者の確保・継続・インセンティブ設計 1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう 2. ニュースリリースを見て、技
たくさんセキュリティチェックシートを書いていて悟りが開けそうなので途中経過を書いてみる - Qiita
セキュリティチェックシートって大変ですよね 「契約締結目前で、今日もらったチェックシートを3日後までに出せば決まりです！」 「これNGだと契約できないんですけどなんとかならないですか？」 「（書いてもらったシートをレビュー中）え！？これOKじゃなくてNGですよ！？」 「書き始めたら8時間以上かかってるんですけどこれ無償対応なんですか・・・？」 っていうことありませんか！？ない！？良かったですね！！（血涙） ということで、結構セキュリティチェックシートで苦労しています。 過去にISMS認証を取得したときには「これでちょっとは楽になるな！よかった！」と思ったもんですが、 大きく楽になった感じはありません。 といっても、セキュリティチェックシートは次々来るので、なんとなく悟りが開けてきました。 ということで、道半ばではありますが、 そもそもセキュリティチェックシートってなんだっけ？ なんで苦労し
セキュリティの問題を見つけ警告する慈善団体から連絡が来た - Qiita
ある日、、 「Repo Lookout」という団体から、僕個人のemailに「君のサイト脆弱性あるよ」といった旨の連絡が来ました。 開くと本文には、確かに僕が書いたであろうprivateなgitリポジトリへのコミットメッセージが記載されていたので、事実であることはすぐに分かりました。 問題 どうやら、僕がずっと昔に作った個人のWebサイトに、.gitディレクトリ配下へWeb上からアクセスできてしまう問題があるようです。 当時、プロジェクト直下をそのままドキュメントルートに設定してしまっていたため起きていました。 見られて問題になるようなプロジェクトではなかったのは幸いです。 Repo Lookout この連絡を送ってきた団体は、脆弱性を突いて脅しをかけよう、といったような悪意のある団体ではなく、むしろその逆のようです。 このケースの脆弱性に特化して、世の中のWebサイトから同様の問題を持つ
「エンジニアのためのドキュメントライティング」を読んだので、そのまとめ - Qiita
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング | ジャレッド・バーティ, ザッカリー・サラ・コ―ライセン, ジェン・ランボーン, デービッド・ヌーニェス, ハイディ・ウォーターハウス, 岩瀬 義昌 |本 | 通販 | Amazon 本書は経験に長けた執筆者たちがドキュメントを作成する方法をゼロから説明するフィールドガイドです。 架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測定、保守に至るまで、開発を最適化するためのドキュメント作成の技術を解説しています。 これまで学ぶ機会のなかったREADME、APIリファレンス、チュートリアル、コンセプトドキュメント、リリースノートなど、さまざまな種類のドキュメントの書き方について学ぶことが
Google Researchの神資料を読み解いてみる①【Deep Learning Tuning Playbook】 - Qiita
はじめに 研究しなきゃなのはわかってるが何から始めればいいんだ、とりあえずでモデル組んだけどまともに動かん。なにがダメなのか分からねぇ、どこをどういじれば何がどう変わるんだ、、、と日々悲鳴をあげている中、Google Researchの研究者による、Deep Learning Tuning Playbook（ https://github.com/google-research/tuning_playbook ）が公開されました。 どうやら深層学習ネットワークをチューニングする際の考え方やら注意点を、Googleの神たちがまとめてくださっているようです。これは読んでおこうと思い、自分の読解とメモついでに和訳してみることにしました。 【注意】 翻訳アプリそのままではなく、一応多少自分なりに解釈して理解したいということで、一部抜けてたり言い回しが違ったり、そのまんま和訳になっているとは限りませ
コーディングのようにノートを取る技術 - Qiita
はじめに 何かを学習するとき、ノートを取っているでしょうか？ 小学生の頃や中学生・高校生の時の「ノート」は紙に手書きだったかと思います。 しかし、最近になってからはパソコンを使ってノートを取る、という選択肢が増えました。 その変遷の中で生まれたパーソナル・ナレッジ・マネジメント(Personal Knowledge Management) という考え方があります。 その考え方を共有できたらと思います。 直感的なデジタルノート術の原罪 ケース1: ひたすらに手を動かす 学生の頃、黒板に書かれた内容をそのまま必死にノートに写している人がいたのを覚えていますか？ また、その人は成績が高かったでしょうか？ たいていの場合、成績は乏しい人が多かったと思います。自分もそのタイプでした。 手を動かすだけのノート術の不幸な点は、「考える」というアクティビティが行われないため、本当の意味で筋肉を動かすだけと
日々息をするようにアウトプットしている人は何を意識しているのか？ - Qiita
始めに みなさま、アウトプットしてますか？ Twitter で日々情報発信する Qiita の記事を投稿する 勉強会で発表する などなど、アウトプットの方法はいろいろあります。エンジニアは日々のインプットが大事だけど、アウトプットも大事！というのはみなさまご存じの通りだと思います。 ・・・そうは言っても、アウトプットを多くするにはどうすればいいのかわからない！という方も多いと思います。私もその１人です。 そこで、私の知る範囲で圧倒的なアウトプットを生み出している山田展子さん（@e99h2121）に、「どうやったらたくさんのアウトプットを生みだせるんですか？？」という内容についてインタビューしてみました。 山田さんってどんな人？ 私にとっては、Works Human Intelligence の偉大な先輩です。Qiita のプロフィール（@e99h2121）を見るとわかる通り、ほぼ毎日何かし
プログラマーに贈る、わかりやすい文章を書くための技法 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
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
「詳細設計書」を作ってみる - Qiita
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。 サンプルダウンロード サンプルのダウンロードはこちらから。 作成してみる では作成していきましょう。 作成方針・ポイント 概要でも書きましたが、詳細設計書までの書類で開発に必要となる情報の全てを記述しておく必要があるので、要件定義書、基本設計書の記述として足りない内容を記述していきます。 構成（目次）を考える 今回は下記のような項目を記述してみました。 一般的には基本設計で行う外部設計、内部設計といった内容に加え、実装に必要な情報を記述します。 サーバ/アカウント情報 外部設計 PC用画面 スマホ用画面 画面のマークアップ バリデーションルール（フロント）と表示項目 送信ボタン押下時の処理 スプレッドシートのデータ構造とレイアウト 内部設計 APIの処理フロー APIの仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクニカルライティングの基本 2023年版
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
エンジニアのためのドキュメントライティング / Docs for Developers
ChatGPTの使い方＜26例＞｜入江 慎吾 🚀
REST API設計のパターンと原則｜Sachiko Kijima
