並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 68 件 / 68件

新着順 人気順

要件定義の検索結果41 - 68 件 / 68件

  • テストコードを書き始める前に考えるべきテストの話(2021年版) #scrumosaka / scrum_fest_osaka_2021

    以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/

      テストコードを書き始める前に考えるべきテストの話(2021年版) #scrumosaka / scrum_fest_osaka_2021
    • 要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経

      タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す

        要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
      • 『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ!【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com

        本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』(以下、『龍が如く7』)のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム! まずは阪上氏が開発者たちへ向けて、「バグは好きですか?」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい

          『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ!【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
        • 約束は開発を遅らせる - Mitsuyuki.Shiiba

          観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

            約束は開発を遅らせる - Mitsuyuki.Shiiba
          • 『要求を言え』『5千万円と逃走用の車を用意しろ』ITの人『それは要件だろ!』→わかりやすい解説が登場し、広く共感される

            他業種でもこの2つを区別するの大事よね、と共感されてます。 この場に居合わせてるってことはこのITの人は人質なんだろうなぁ…我慢できなかったのか…と想像してジワる。

              『要求を言え』『5千万円と逃走用の車を用意しろ』ITの人『それは要件だろ!』→わかりやすい解説が登場し、広く共感される
            • ソフトウェアアーキテクトに必要なシステム設計知識を学んだ17冊 - yoshikipom Tech Blog

              はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture 達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう!プロセス設計 ~要件定義のその前に はじめよう! 要件定義 ~ビギナーからベテランまで はじめよう!システム設計 ~要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術

                ソフトウェアアーキテクトに必要なシステム設計知識を学んだ17冊 - yoshikipom Tech Blog
              • プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から

                「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画(いわゆる「予算」)、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ

                  プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
                • システム開発で曖昧な要望を形にしていく方法 - arclamp

                  このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約(プライム) 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的:達成すべきこと 戦略:目的を確実・効率的に達成するためのシナリオ 戦術:戦略を実行するための具体

                    システム開発で曖昧な要望を形にしていく方法 - arclamp
                  • ソフトウェアドキュメント作法 - maru source

                    こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました! #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、

                      ソフトウェアドキュメント作法 - maru source
                    • みずほ銀行システム障害の報告書を読んだ結果

                      (๑╹◡╹๑) @tsuchie88 やたらと「区画」って言葉が出てくるけど、これIBM用語だよなぁ? 仮想マシンか論理または物理的に分離されたパテーションのことなんだろうけど。 pic.twitter.com/SJA2oGfj5a 2021-06-15 19:56:05

                        みずほ銀行システム障害の報告書を読んだ結果
                      • 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022

                        PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク(40分) PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務

                          予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
                        • オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling

                          Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui

                            オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
                          • 【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画

                            1. はじめよう! 要件定義 ~ビギナーからベテランまで(難度:★☆☆) 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級~上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた

                              【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画
                            • 要件定義、基本設計、詳細設計の流れを総復習

                              はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ?」 「基本設計との違いって何だったっけ?」 「基本設計と詳細設計の区別って?」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて1からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部(特に要件定義や基本設計、詳細設計のサンプル)を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく

                                要件定義、基本設計、詳細設計の流れを総復習
                              • オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena

                                定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

                                  オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
                                • プログラミングの授業で「みんながニッコリするセリフ」を考えさせた途端に動けなくなる子がいる→良い"問いかけ"とは何か?

                                  Scratch とMagica Voxelと子どもたち @scratchhub31 ☆ Pythonの第一歩は大抵「print('○○○')」なんですが、 ここで「○○○にみんながニッコリするセリフ入れて」って言うと、1ミリも動けなくなっちゃう子がいます。特に学校の勉強ができる子に多い。 構文とかも大事なんだけど、そこんトコが人間のお仕事なんだけどなー、って感じ。#考える力 2021-03-11 08:13:10 よんてんごP @yontengoP 割とリプ・引用RT含めて 「は?🤔」「何だその指示💢」「クソ客か???✊」って反応されてるけど、 どういう出題というか問い掛けしてるかだなぁ… 「例えばこういうニッコリ言葉があって…」って いくつか例示した上で 「皆も他のを考えてみて」とかならアリだと思う twitter.com/scratchhub31/s… 2021-03-12 10:

                                    プログラミングの授業で「みんながニッコリするセリフ」を考えさせた途端に動けなくなる子がいる→良い"問いかけ"とは何か?
                                  • セブンペイ問題の根本要因。日本の悪習慣「ウォーターフォール」 - まぐまぐニュース!

                                    鳴り物入りで導入されるもすぐに大規模な不正アクセスが発生、セブンイレブンという企業自体のITリテラシーを疑われる事態にまで発展してしまった、セブンペイ問題。なぜこんなことになってしまったのでしょうか。世界的エンジニアでアメリカ在住の中島聡さんは今回、自身のメルマガ『週刊 Life is beautiful』で、いびつで時代遅れな開発体制を持つ日本ITゼネコンと、そんな組織にセブンイレブンが開発を委託したところに根本の原因があると指摘しています。 ※ 本記事は有料メルマガ『週刊 Life is beautiful』2019年7月16日号の一部抜粋です。ご興味をお持ちの方はぜひこの機会に初月無料のお試し購読をどうぞ。 プロフィール:中島聡(なかじま・さとし) ブロガー/起業家/ソフトウェア・エンジニア、工学修士(早稲田大学)/MBA(ワシントン大学)。NTT通信研究所/マイクロソフト日本法人/

                                      セブンペイ問題の根本要因。日本の悪習慣「ウォーターフォール」 - まぐまぐニュース!
                                    • 『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ!【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com

                                      本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』(以下、『龍が如く7』)のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム! まずは阪上氏が開発者たちへ向けて、「バグは好きですか?」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい

                                        『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ!【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
                                      • ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴

                                        www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている(ご存じの方は彼にご一報を)。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80%、いやもしかしたら90%をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく

                                          ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴
                                        • スクラムと見積り

                                          スクラムと 見積り やっとむ 合同会社やっとむ屋

                                            スクラムと見積り
                                          • エンジニアは顧客の要望をちゃんと聞こう 〜「うちの店でカレーを出したい」と言われたら?〜|Katsuma Narisawa

                                            こんにちは。SALESCOREのCTOの成澤です。 今日は、Webサービス開発に携わる方向けに「要望を正しく聞くのは大事だよ」という話を、飲食店の例え話で紹介します。 「うちの店でカレーを出したい」と言われたら飲食店のオーナーから「うちの店のメニューにカレーを加えたい。カレーを作る体制を整備してほしい」と相談されたとします。 敏腕料理人のあなたは何を考えるでしょうか? 普通に考えたら「野菜と肉とルーを仕入れて、あとは鍋と包丁を用意して…」と考えるでしょう。 カレー作りに知見がある人なら「スパイスから手作りした方が美味しく作れる!スパイスを独自ルートで調達しよう!」なんてことも考えるかもしれません。 しかし、ここであなたがするべきことは、オーナーへの追加ヒアリングです。 どんな店なのか? → 喫茶店かも 店内の調理設備は? → 狭い厨房がちょっとあるだけ。調理器具もほとんどない スタッフの体

                                              エンジニアは顧客の要望をちゃんと聞こう 〜「うちの店でカレーを出したい」と言われたら?〜|Katsuma Narisawa
                                            • バグを許さない、完璧なリリースじゃないと許さない風潮をやめないと日本はこれから厳しいのでは「ほんまこれ」「バグるものによる」

                                              だるやなぎのレバーは加熱しろ @daruyanagi バグを許さない、完璧なリリースじゃないと許さないっていう風潮をやめないと、日本はこれからちょっと厳しいな……あと、オープンソースなんだからとかじゃなく、あらゆる社会的なプロジェクトを「公共物」と捉えて合理的な配慮と無理のない参加を心がけるのも学んだ方がいい。お客さん過ぎる 2021-12-21 13:12:59

                                                バグを許さない、完璧なリリースじゃないと許さない風潮をやめないと日本はこれから厳しいのでは「ほんまこれ」「バグるものによる」
                                              • テストを自動化するのをやめ、自動テストを作ろう

                                                July Tech Festa 2020 TrackB https://jtf2020.peatix.com/

                                                  テストを自動化するのをやめ、自動テストを作ろう
                                                • ITエンジニアの新たなバイブル『レガシーコードからの脱却』を読んだ - paiza times

                                                  こんにちは。谷口です。 先日、オライリー社から『レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』が発売されましたね。 弊社でもすぐ購入し、読みまくり、「これはリーダブルコードのように次世代のエンジニアのバイブルになる予感…」と言っているエンジニアもいたので、今回は本書の概要紹介と感想について書きたいと思います。 私の本書はすでに画像の通りふせん貼りすぎ下線ひきすぎ読みすぎでボロボロです。 レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 作者:David Scott Bernstein発売日: 2019/09/19メディア: 単行本(ソフトカバー) 概要について 本書はどんな内容の書籍なのか、まずオライリー社公式サイトにはこう書かれています。 本書では、ソフトウェア開発において、初めからレガシーコードを作りださないた

                                                    ITエンジニアの新たなバイブル『レガシーコードからの脱却』を読んだ - paiza times
                                                  • なぜ自動テストの導入は失敗するのか? - プログラマーの脳みそ

                                                    開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど? まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか? というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ

                                                      なぜ自動テストの導入は失敗するのか? - プログラマーの脳みそ
                                                    • 「要件定義」のまえに、「要求定義」|しょーてぃー/ Experience & Prompt Designer

                                                      多くのアクセスがあったので無料化しました 要求定義テンプレも記事内でDLできます。 はじめにはじめましてUX プランナーのShoty(@shoty_k2)です。 今回は「要求定義」をつかった、UX デザインについてご紹介します。 実践用テンプレートも記事内にて配布しておりますので、参考にしてください。 「要求定義」とは要求定義とは、「事業や施策によって実現したいこと」です。ユーザーにどのような状態になって欲しいのか・何をしてほしいのか、ビジネスで何が必要なのかなどを取り決めることです。 要求定義という言葉は、もともとはシステム開発の現場では頻繁に使われている単語で、非技術者の企画者がシステムに求める仕様を定義することです。 「要件定義」と「要求定義」の違い多くの方が「要件定義」という言葉を聞いたことがあるかと思いますが、「要件定義」と「要求定義」の違いについてご存知でしょうか? ★要件定義

                                                        「要件定義」のまえに、「要求定義」|しょーてぃー/ Experience & Prompt Designer
                                                      • VSCodeでDraw.ioが使えるようになったらしい! - Qiita

                                                        追記 versionによっては設定を変えないとエクスポートができないようです。 エクスポートできない方はこちらの記事をご参考に設定いただくとエクスポートできるかもしれません。 現状バージョン0.4ではこちらの設定が必要となります。 VSCodeでDraw.io Integration使用時にエクスポートできないことがある問題への対処 2020/10/18追記 現在のバージョン0.7ではdrawio拡張子のエクスポートがうまくいかないようです。 その場合はオフラインモードに移行変更していただくか、drawio.pngやdrawio.svg拡張子でファイルを作成してもらうことで直接編集もできた上で、エクスポートとせず末尾の拡張子ファイルとして利用することができます。 はじめに VSCodeで簡単にDraw.ioで描画できるようになったみたいなので、 導入方法と使い方を備忘として残していきます。

                                                          VSCodeでDraw.ioが使えるようになったらしい! - Qiita
                                                        • プログラミングで一番難しいのは「見積もり」だと思う - Qiita

                                                          前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか?」だ。厳しいところだと「何日に納品してくれるのか?」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか? 見

                                                            プログラミングで一番難しいのは「見積もり」だと思う - Qiita