「Pythonのドキュメントでも読むか～」「え、何その裏技」 - Qiita読み飛ばしてください おはようございます、しなもんです。 Pythonの公式ドキュメントを読んでたら、なんか知らない便利機能がたくさん出てきました。 なんだこれ。 というわけでまとめてみました。 参考になれば幸いです。 f-stringsの拡張機能 f-strings、便利ですよね。大好きです。 そんなあいつには裏技があるみたいです。 デバッグ用の=演算子 Python 3.8以降、f-stringの中で=演算子を使用することで 変数名とその値を同時に表示できるらしい。
2023年に読んでよかった技術書
おそらく 2023 年に Zenn で出す最後の記事になるかと思います。 タイトルの通り、2023 年に読んだ本の中で、特に素晴らしかったものをご紹介します。 とはいえあまり今年は技術書を読んだ印象がなく… というのも、特定の xx(例えば Next.js、Ktor)といった部類に関しては公式のドキュメントを読むことがほとんどになり、書籍に求めるのは公式ドキュメントに書かれていない何かや誰かの経験・ノウハウになったからだと思います。 この記事を書くにあたって今年読んだ本を振り返ってみても、やはり十数冊程度(それでも月に 1 冊は読んでた)のでインプット：アウトプットの割合的には良いバランスではないかと思っています。 ただ、先に述べた通り公式ドキュメントに書かれていないなにかを売っている本というのはどれも本当の意味で価値があるものであり、皆さんにも本当に意味のある情報にお金を使っていただける
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト
技術記事を書かないプログラマへ向けた記事
はじめに 今回の記事では効率的に技術記事を書くための具体的なテクニックは取り扱わない。技術記事を書くことのメリットや技術記事を書く上で重要なマインドセットを中心に徹底解説する。 要旨：プログラマーは積極的に技術記事を書くべき 私たちプログラマーは積極的に技術記事を書くべきだ。TwitterでもQiitaでもこのZennでも構わない。とにかく何でもいいので、自分の学びや気づきを記録してそれを公開する習慣をつけよう。自分で学んで得られた知識や気付き、新しい価値観をまとめる作業は自分にしかできない。 記事を書くべき理由 記事を書くべき理由はざっくり以下の通り。 知識が定着するから 説明する能力が上がるから プログラマーとしての人となり(興味のある技術やプログラミングに対する価値観、説明する能力など)を知られるから それぞれ順番に解説する。 知識が定着するから 知識を定着させるための最高の手段は、
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
自分の行っているセキュリティ関連の情報収集 - ドキュメントを見たほうが早い
聞いてるポッドキャストでセキュリティ情報収集どうしているのかといった話題があった*1ので、いい機会だから自分の行っているセキュリティ関連の情報収集をまとめてみた。 前提 どんな人 セキュリティに興味あるWebアプリケーションエンジニア*2 興味の範囲 Webアプリケーションにまつわるセキュリティ全般 サービス開発・運用まわりに関するセキュリティ 知りたい情報 関係ありそうな脆弱性情報 興味範囲の最近の話題やトレンド その他セキュリティ関係で話題になっていそうなこと 話題やトレンドはキーワードを拾い後から調べられるように脳にインデックスを作っておくのが目的で、網羅や詳細に知ることはあまり意識していない。 情報ソース 前提に書いた知りたい情報を、各種サイト・ブログ、Twitter、Podcast から収集している。 Twitter は脆弱性情報などスピードが重要なものからトレンドまで幅広く知れ
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
研修資料まとめ.md
研修資料まとめ.md エンジニア向け研修 CARTA HOLDINGS（旧VOYAGE GROUP） 技術広報が新卒研修<Open AIハッカソン>をスパイしてみた - (2023/04/11) @t_wadaに学ぶテスト駆動開発【CARTA 23新卒研修】 - (2023/04/19) 【新卒研修】監修者@t_wadaと読む！プログラマが知るべき97のこと読書会 - (2024/04/09) Classi 当たり前にリリースしていく ~ 新卒研修編 - (2021/05/20) リモートワークのための質問力向上研修を実施しました - (2021/12/07) CyberZ 良いコードとは何か - エンジニア新卒研修 スライド公開 - (2021/04/27) DMM.com(旧DMM.comラボ含む) ＤＭＭ.comラボ16新卒エンジニア研修 - (2016/08/24) DMM.com
私たちはどうして公式ドキュメントが読めないのか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 少しプログラミングを覚えてきた初学者が、さらに力をつけるために必要なのが公式ドキュメントを読むことだと思います。 公式ドキュメントには、日本語の記事には書かれていないような詳細な説明や、APIの使用方法、そしてリリースノートなど、実装には不可欠な情報が掲載されています。 しかし、公式ドキュメントが上手く読めずにつまづく人も多いのではないでしょうか？慣れていない人にとっては、技術について書かれたドキュメントを読むのは難しいものです。 この記事では、つまづいてしまう人が少しでも減るように、公式ドキュメントが読めない原因と対策をいくつか書いて
公式ドキュメント読めば5分で解決することで5時間もGoogleとにらめっこするな｜古都こと｜note
世の中には二種類の問題がある。公式ドキュメントを読んで解決する問題と、解決しない問題だ。 読んでも解決しない問題に関しては……まあ頑張れ。今回は解決する場合についてのみ扱う。 公式ドキュメントを読めまず言いたいのはなぜ貴様らは公式ドキュメントというものを読まないかということである。 いや言いたいことはわかる。Node.jsのAPIドキュメント、クソだもんな。あれは完璧なクソだ。でも実は必要なことは書いてある。 公式ドキュメントってのは妙なミスがない限り概ね正しいことが書いてある。バカが適当書き散らしたQiitaと違ってな。 たとえばExpress（Node.js用のサーバフレームワーク）を使うとしよう。公式サイトに必要なことはほとんど書いてある。しかも日本語で。HelloWorldから始まり、ルーティングの仕方、静的ファイルの配信、ミドルウェアの使用法、などなど。APIリファレンスもついて
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
