アプリの方はまだ日本語版のみですが少しずつ改善を続けています。このnoteの中でオススメの英語ツールについて記事を書くと宣言していたものの、なかなか時間がとれず遅くなってしまいすみません。数年前の記事の書き直しではありますが、誤っていた部分を修正し、情報を最新版にして改めて書いてみます。 というわけで、今回は英語の補助ツールの紹介です。知っている人からすれば定番中の定番ではありますが、だからこそ英語を勉強中の方でも設定してしまえばきっと長い間使うことになると思うので、まだ設定していない方はぜひこの機会にやってみてください。パソコンでのGoogle Chromeを使った設定になります。 爆速ポップアップ辞書 英文のドキュメントを読んでいるときに意味を知らない単語が出た場合、いちいち翻訳サイトに飛んだり、辞書を開いたりするのは面倒ですよね。そんなときに使えるのがポップアップ辞書になります。ポッ
逮捕にそなえる人生継続計画 - やしお
実際に逮捕・起訴された人の事例をいろいろ読んでみると、普通に生活・仕事していてもされる時はされるんだと思う。 痴漢冤罪や荷物すり替えで違法薬物の運び屋にされるなどの巻き込まれケースだったり、もともとルール（法律・運用）が曖昧なグレーゾーンが拡大解釈で突然咎められたり、捜査機関の描いた架空のストーリーの登場人物にされたり、本人は犯罪の意識が希薄だったり、色々ある。 逮捕・起訴されると人生に大きなダメージを被る。会社なんかで災害を想定してBCP（事業継続計画）を事前に立てたりするけど、それと同じような感じで、万が一逮捕された場合でも「こうなる」をそこそこ認識して「こうする」を事前に決めておければ役に立つかもしれないと思うようになった。 概要 弁護士選び 逮捕～裁判の流れ 逮捕 逮捕後 留置場・拘置所 取調べ・調書 捜索差押 勾留請求・勾留質問 裁判 世論形成・名誉回復 参考事例・参考文献 概要
はじめに この記事には、Googleのオンサイト面接に向けて勉強した内容が記載されていますが、それらはすべて面接を受ける直前に書いておいたものです。このエントリを読むことで面接で聞かれた内容が予測されてしまわないようにそのようにさせていただきました。ご了承お願いします。 この記事について 令和元年に医師を退職し、ソフトウェアエンジニアに転職します。 自分にとって大きな転機であったのと、とても大変な道のりであったので、私という人間が辿った道筋を最初から最後までちゃんとまとめておきたいと思いこの記事を書くことにしました。 私のような他業種から未経験での転職を目指されている方にとっても、何らかの参考になる内容であれば幸いです。 私の生い立ち 私は小さい頃からテレビゲームが大好きで、学校から帰るとずっと家でゲームをしている子でした。あまりにもゲームが好きだったので、遊ぶだけではなく自分で作ってみた
LINE社内で大評判のテクニカルライティング講座で説明した内容をあらためてブログにまとめてみた
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。今日は、私が1文を書くときに気をつけていることや手法についてお話しします。 そして、この書き出しは、6月にmochikoさんが書いた「LINEの社内には「テクニカルライティング」の専門チームがあります」という記事のオマージュになっています。mochikoさんが書いた記事ですごいpvをたたき出したそうなので、人のふんどしで相撲を取ってみようという作戦で始めてみました。 この記事ではLINE社内で私が講師を務めた「LINE社内で大評判のテクニカルライティング講座」に沿って、わかりやすい1文を書くコツを紹介していま
私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生５０年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを２つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write
フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
OpenAIは、大規模言語モデル（GPT-4）でよりよい結果を出すためのプロンプトエンジニアリング（プロンプトのノウハウ）入門テキストを同社のウェブサイトで公開している。 同テキストでは、現在同社で最高の性能を持つ大規模言語モデルGPT-4を対象に、よりよい結果を導くための6つの戦略と、それぞれを実行する際の具体的な戦術（コツ）が掲載されている。 また、「Prompt examples」のページでは、上記で紹介したものを含む多数のプロンプト例が紹介されており、すぐに利用できるようになっている。 では紹介された6つの戦略を見ていこう。 明確な指示を書く LLMは利用者の心を読むことができないので、回答が長すぎる場合は「簡潔に」、単純すぎる場合は「専門家レベルで」と明示的に依頼する必要がある。 具体的な戦術としては下記が提案されている。 ・より関連性の高い回答を得られるよう、質問は詳細に ・モ
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
本を読んでて、気になるところがあったら、 その要点をテキストファイルに箇条書きにして、整理しながら読書する。 これだけ。 これだけで、読書の質が桁違いに上がります。 これをやると、「普通に本を読むだけだと、理解した気になってるだけで、実はろくに理解してなかった」と分かって驚きます。 話はこれで終わりですが、 以下の点が気になる方もいらっしゃるでしょう。 ●どんな人がどんな本を読む場合にもそうなるわけじゃないだろ。具体的に、どんな人がどんな本を読む場合にそうなるんだ？ ●そんなの面倒くさくてやってらんない。手間をかけずにやる方法はないの？ ●具体的にどうやるとうまくいくのか、もっとちゃんと説明しろ。 そういう方のために、以下、これらについて補足します。 まず、読書を以下の９種類に分類します。 (1)リアルタイム活用読書読んだ知識を今やっている仕事/生活/趣味にリアルタイムに活用しながら読む方
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
要約 NUROひかりのHGWはデフォルトでIPv6ファイアウオール機能が 無効 または 未搭載 の可能性がある ので、そのまま使うと家庭内LANがインターネットから見えちゃうからちゃんと設定か対策して使おうぜって話。 このドキュメントの対象とする人たち 何も考えずに速度が速いだけでNURO光を使っている、「いんたぁねっとが何かよく分かっていない」人向けです。 ネットワークやセキュリティを理解していて、自分のルータでセキュリティを維持しつつ使える！って人には全く関係ない話なので気にしなくていいです。読まなくていいです。 IPv6 と IPv4 のセキュリティ ここでは IPv6 と IPv4 のアドレスが割り当てられたPCやスマホとかがインターネットからどう見えるのか？について説明します IPv4 の場合 一般的にIPv4アドレスは1契約につき1アドレスが付与され、それをルータ呼ばれる機器を
［CEDEC 2021］フランス人開発者が，日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか？」聴講レポート
［CEDEC 2021］フランス人開発者が，日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか？」聴講レポート ライター：箭本進一 日本で活躍するフランス人開発者が，日本ゲーム業界の問題点を指摘するという講演「Is Worldwide Competitive Game Development possible in Japan?／日本で世界規模の競争力のあるゲーム開発は可能なのか？」が，ゲーム開発者向けカンファレンス，CEDEC 2021の2日目となる2021年8月25日に行われた。日本のゲーム業界が「マネジメント」「キャリア」「競争力」の3分野に抱える問題とは，どのようなものなのだろう？ 「CEDEC 2021」公式サイト 講演を行うハンサリ・ギオーム氏は，東京に本拠を置くゲーム開発スタジオWizcorpのCEOを務めている。2006年に日本に住み始めて以
「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を０から自力で作ろうと思うと４０時間はかかるが、chatgptを使う事によって４時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter：https://twitter.com/naoh_nak 2022年版（初版）：https://speakerdeck.com/naohiro_nakata/technicalwriting
元給食営業マンが「ホーユー」の学校・警察での給食提供停止騒動の原因をざっくり解説してみた。 - Everything you've ever Dreamed
mainichi.jp 西日本を中心に学校や寮で食事の提供が停止する事態が起きている。運営会社は広島市に本店のある給食会社ホーユー。ホーユーの名はコンペで何回か見かけたことがある。詳しくは知らない。 給食事業はリターンも少ないけれどもリスクも少ないビジネスだ。給食設備や用具や食器をクライアント側の負担で事業が行えるからだ。ひとことでいってしまえば経費負担が軽いのだ。食材費は実費、人件費も委託費でカバーできる。「莫大な利益が出せるか？」といわれると案件次第だが、一事業所当たりで赤字になるリスクはとても少ない事業である。 そのため、近く破産申告するとみられるホーユーの社長が人件費や食材費の高騰を理由に上げているのを知って「妙だな…」とコナン君のように疑ったのがこの文章を書いた表向きの理由である。なお裏向きの理由は奥様からの「あなたの会社は大丈夫なのか」という不安を取り除くためである。 一般的に
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
愚痴です（発達障害やグレーゾーンの人の適職って？）。
リモートに入って3ヶ月近く。 ここにきて「逐一指示しても、単純作業しかできない人（もしくは単純作業も難しい人）」が炙り出されて、全社で問題になってきたらしい。 発達障害やグレーゾーンには適職って言われているプログラマーやデザイナーの会社なんだけど、あれは嘘だなあって思うよ。 プログラマーもデザイナーも、ひとりで黙々と仕事をするわけじゃない。 物事を調べたり考えたり、説明することも必要だし、経験が浅い時期は「教えられたことをそのままやってみる」っていうのが大事になる。 過去の部下にも「発達障害かも？」っていうのがいた。 明らかに同期入社のスタッフと違って指示が伝わらないし、出し方を工夫しても成果が上がらない。 けれど、当時の上司から「障害が分かったとしても、状況変わらないよ」っていう一言で、産業医に相談できずに終わった。 おかげで、すごい精神削がれたけど、わかったこともいくつかある。 1.
私がよく参考にしているサイトまとめ
はじめに Twitter、Qiita、Zenn...といろんなところから情報収集するのはいいのですが、それぞれの有益な情報をそれぞれのサイトにお気に入りとして保存しているので、必要な情報を探すだけで一苦労です。 ここで一覧にしてまとめておくことにしました。 ただし、特定の言語に依存するような記事はあえて排除しています。 皆さんにとっても有益な情報があると、この記事を公開して良かったなと思います。 また、皆さんのオススメの記事がありましたら、コメントなどで教えてください。 コミュニケーション 質問 質問は恥ではないし役に立つ https://qiita.com/seki_uk/items/4001423b3cd3db0dada7 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50 会
たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる）。バグの出具
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
AmazonのクラウドサービスであるAWSは、コンピューティングやデータベース、ストレージなど、膨大で複雑なサービスで構成されています。こうした豊富なサービス群をうまく組み合わせて利用する「ビルディングブロック」がAWSのメリットでもありますが、サービス数が多すぎてなかなか全体像を把握できないのも事実。フリーランスのエンジニアでありコンサルタントでもあるジョシュア・テイセン氏が自身のブログで、AWSのすべてのサービスを「たった1行」で説明しています。 Amazon Web Services https://adayinthelifeof.nl/2020/05/20/aws.html テイセン氏によると、Amazon Dashboardから利用可能なAWSのサービスは記事作成時点で163あるとのこと。そのすべてを正確に理解する必要はありませんが、基本を押さえておくことはいいことであり、問題の
概要 職業ソフトウェアエンジニアを目指す方々にオススメしたい書籍トップ10です 以下の観点から選定しました 10年後でも変わらない、流行にとらわれず長く役に立つ、ソフトウェアエンジニアリングにおいて普遍的な知識 特定のプログラミング言語やプラットフォームやツールに精通するのではなく、現代のソフトウェア開発の哲学・文化の全体像が把握できることを優先 200～300ページくらいで初心者でも読破できる 400～500ページくらいの本もあるが、それらは辞書的に使うのがいい あえて10冊に絞り込んだので、ここに含められなかった書籍も当然あります CI/CDやDevOpsに関する本も入れたかった… デザインパターンに関する本も入れたかった… DDDやClean Architectureなどシステム設計に関する本は意図的に入れていない 真・プログラミングスクールに通うくらいならこの本を読め10選を書きま
強いエンジニアになるために英語が必要と聞いたので４ヶ月でTOEICスコア400→900まで上げた話 - Qiita
はじめに 初投稿です。 筆者スペック 19歳 高卒 某大手自動車メーカー関連会社勤務 エンジニア志望 (Web開発勉強中) 業務の効率化（データ整理・画像処理など）でPythonを書くことがあります。Python歴は半年程度です。 英語学習について、 どのように学習してきたのか記録を残すため 「TOEICのスコアを伸ばしたい」と考える方にとって少しでも参考になれば と思い、記事を書くことにしました。 英語学習の動機 「エンジニアには英語が必要」 論 エンジニア/エンジニアになりたい方なら、1度は「エンジニアに英語は必要か」という議論を目にしたことがあるのではないでしょうか。 自分は現在エンジニアになることを志しています。 そのための情報収集をしていると、「エンジニアに英語は必要なのか？」という主旨の記事、議論を時折見かけます。 そして、その結論は殆どの場合「強いエンジニアになりたい場合、あ
【ChatGPT】個人的お気に入りプロンプトまとめ
あなたは、プロの【その分野の専門家】です。 以下の制約条件と入力文をもとに、【出力内容】を出力してください。 # 制約条件： 【前提条件や決まりごと】 # 入力文： 【期待する出力結果や大まかな指示】 あなたは、プロのエンジニアです。 以下の制約条件と入力文をもとに、ブログ記事の内容を出力してください。 # 制約条件： ・重要なキーワードを取り残さない。 ・文字数は30000文字程度 # 入力文： Swaggerについて技術ブログに投稿する文章を書いてください。 構成は、Swaggerとは？、Swaggerのユースケース、Swaggerのメリットとデメリット、Swaggerの書き方（YAMLファイル）、Swaggerの実行方法、まとめです。 構成間で重複した説明は省くようにしてください。 読者がブログを読みながらSwaggerを触れるようにハンズオン形式などを取り入れて文章を作ってください
はじめに さいきんのWebはSPA技術を中心としたフロントエンドが賑わっていますね💪 従来サーバーサイドを扱っていた人もフロントを触る機会が増えていたり、これからプログラミングを学んでいく人も、フロントエンド領域に興味を持っているのではと思います。 そこで、フロントエンドの経験が浅い方や初学者向けに、おすすめのドキュメントや勉強すべき領域をまとめました。 とりあえず動けば良い段階から一歩進んで、フロントエンドエンジニアとして、良いアプリケーションを作るために必要な知識を浅く広く紹介します。 ※補足 新米と表記しましたが、実際には新卒や未経験でなく、新卒2~3年目の若手フロントエンドエンジニアやフロント分野に苦手意識のあるバックエンドエンジニアの方を対象としています。 数日で目を通せるような内容ではないため、マイルストーンやスキルセットの一つの参考にして頂けると幸いです。 フロントエンド入
「未経験文系から3ヶ月でデータサイエンティストになって一発逆転」はここで終わり (2020/7/31 更新) - todo-mentor’s diary
データサイエンティストを生業にする手段と実態について述べる。 途中、具体例・境界値の例として私個人の話もするが、なるべく一般性のある話をする。 この記事で言いたいことは具体的には4つだ。 プログラミングスクールをディスるなら代わりの入門方法を提供しようよ。 もう「未経験文系から3ヶ月でデータサイエンティストで一発逆転物語」を止めろ。*1 おじさんは人生逆転したいなら真面目にやれ。 若者はワンチャンじゃなくて、ちゃんと化け物になれよ。 この記事についてはパブリック・ドメインとして転載・改変・リンク記載を自由にしてよいです。 (続き書いた) a. 入門は辛いが… b. 思考停止でプログラミングスクールに通うな。 なろう系・始めてみよう系資料一覧 （最速・最短ルート用） まずは動かしてみよう。強くてニューゲームが体験出来るぞ！ 入門以前の本 一般向け業界本 (AI業界と展望がわかる本) 技術者入
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ
はじめに NFT って何ですか？ ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ？ はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの？ これを読んでください: speakerdeck.com なるほど。ところで、この記事は何？ いま話題の NFT について、NFT の標準仕様である EIP-721 の仕様書と、それを実装しているスマートコントラクトのソースコードから読み解けることを解説する。一般向けの解説とは異なる視点から光を当てることで、ソフトウェアエンジニアに「あ、NFT って単にそういうことだったのか」と理解してもらえるようにすることを狙っている。 また、NFT がソフトウェアとして具体的にどう実装されているかを知ることは、
「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある
改正電気通信事業法が施行だけど、またしても何も知らなかったWebサイトやアプリ運用者のために書いておくぜ - フジイユウジ::ドットネット
2023年6月16日 から改正電気通信事業法が施行なんですけど知ってました？ これ、収益目的なら企業運営でも個人運営でもほとんどのWebサービス・スマホアプリが対象という、めちゃめちゃ広範囲にみんなが対応が必要なやつなんですけど、ヤバくない? 何もしてなくない? やっべえなというWEBサイト担当者/アプリ開発者が結構いそうな雰囲気がいんたーねっつから漂ってまいりました。 企業のオウンドメディアや、個人運営のアフィリエイト目的サイトなんかも対象になる場合があって、メディア系サイトはもちろんアプリ開発者にも影響ある感じですので、やるべき内容をブログにしたためておきます。 ※ぼくは法律の専門家ではないので、ちゃんと総務省の公式ドキュメントなどにも当たってくださいね。 ググると「外部送信規律」とか「電気通信事業者又は第三号事業を営む者」とか専門用語の記事ばっかり出てきて自分が何をしたらいいのかの情
初めに 私は独学でプログラミングその他について勉強をしていますが、基本的に知識を得るために金はかけません。調べれば何とかなるので。 私がプログラミングを始めるにあたって自分に投資したものは安いノートパソコンとマウスのみで合計金額は14600円（ノートパソコン14000円、マウス600円）ですね。 もちろんいいものはお金をかけなければ手に入りません。しかし、いいものというのはある程度のレベルにならなくては持っていても意味がほとんどないと思います。 実際にプログラミングの勉強を独学で始めると、なかなか教材を見つけることができず、え？こんないいサイトあったの！？もうちょっと早く見つけときゃあよかった！というものがめっちゃありましたので、これから独学でプログラミングの勉強をしたいという方に向けて、少しでもお役に立てたらと、紹介をしたいと思います。 というわけで、今回は私が感謝する神サイトおよびその
サイバーエージェントが公開した“300ページ級のUnity技術書”がスゴい！しかも誰でも無料で読める｜Unity Japan（ユニティ・テクノロジーズ・ジャパン）
快適に動作するアプリケーションを提供するために、パフォーマンス・チューニングについてもっと深く学びたい。そんなUnityエンジニアのみなさまにぜひ読んでいただきたい電子書籍が登場しました。 その名もずばり『Unity パフォーマンスチューニング バイブル』。 執筆を手がけたのはサイバーエージェントグループ各社の精鋭エンジニアの方々。元々はサイバーエージェントグループ内の共有資料として制作されたそうですが、その内容とボリュームは「社内向け」の範疇に収まらないほどの商業技術書レベルです。そしてこの度、本書が誰でも無料で読める電子書籍として、社外にも公開されることが決まりました。 一般公開に先駆けて本書を拝読したユニティ・テクノロジーズ・ジャパンのエンジニアからも、絶賛の声が相次いでいます。 本書はこれからパフォーマンス・チューニングを学ぶ人にとって、最適な一冊です。すでに実務経験のある人にとっ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
海外で７年働いて、今でもやっぱりメチャ使っている英語の補助ツール３選｜__shinji__
【転職エントリ】Googleに入社します｜Lillian
プログラミングというより物事が出来るようになる思考法｜牛尾 剛
テクニカルライティングの基本
質の高い技術文書を書く方法 - As a Futurist...
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
どうしてHTML5が廃止されたのか | フューチャー技術ブログ
意思決定できる人の手順の型 - Konifar's ZATSU
新人の方によく展開している有益な情報 - Qiita
見積・提案書に書いておくと不幸を減らせる前提条件
これは嬉しい ChatGPTプロンプト書き方のコツ、OpenAIが公開
桁違いに読書の質が上がる超簡単な読書法｜ふろむだ@分裂勘違い君劇場
エンジニアの"有害な振る舞い"への対処法 - Qiita
NURO光はセキュリティ的にやばいって話 (安全に使うための方法) - Qiita
【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
テクニカルライティングの基本 2023年版
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
ミスが全くない仕事を目標にすると、ミスが報告されなくなる『測りすぎ』
AWSの膨大で複雑なサービス群をすべて「たった1行」で説明していくとこうなる
プログラミングスクールに通うくらいならこの本を読め10選 - ニート向けソフトウェアエンジニアリング塾
すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
プロジェクトリーダーというお仕事 - Qiita
ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
私が独学をして、マジ神だと思うサイトおよび他 - Qiita
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ