タグ

Qiitaに関するbelka333のブックマーク (34)

  • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

    はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

    なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
  • 「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita

    再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

    「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    はじめに 稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、5年も

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • 「この位置にprintfが無いとなぜか動かないんだ。」 - Qiita

    はじめに 先日ツイッターで見かけた呟き pic.twitter.com/33Yk02hu1U — TOMO (@tomozh) October 14, 2020 そういうこともあるのか的な反応もあるようなので具体例を挙げてみることにする。 例1 所謂FizzBuzz問題。 #include <stdio.h> void fizzbuzz(int n) { int next; int i = 1; do { printf(i % 15 ? i % 5 ? i % 3 ? "%d\n" : "Fizz\n" : "Buzz\n" : "FizzBuzz\n", i); if (i++ >= n) next = 0; } while (next); } int main(void) { printf((char[]){""}); // この位置にprintfが無いとなぜか動かない fizzbuz

    「この位置にprintfが無いとなぜか動かないんだ。」 - Qiita
  • 「Visual Studio Codeの教科書」を読んでVS Codeの設定をゼロから見直してみた - karaage. [からあげ]

    追記:VS Codeの入門書をZennでリリースしました ブログで扱ったVS Code関連の記事をまとめて、無料の電子書籍としてZennというプラットフォームでリリースしました。よければ、こちらも参考にしてみてください。 Visual Studio Codeの教科書 Visual Studio Codeの教科書を購入しました。基的な使い方から拡張機能の作り方まで、広く押さえられていました。 プログラマーのためのVisual Studio Codeの教科書 (Compass Booksシリーズ) 作者:川崎 庸市,平岡 一成,阿佐 志保発売日: 2020/04/30メディア: Kindle版 自分は拡張機能作りには興味なかったのですが、思わず手を伸ばしたくなりますね。拡張機能作りまで興味ある方にとってはかなり良いではないかと思います。 を読むと、色々改めて発見があったのと、拡張機能一回

    「Visual Studio Codeの教科書」を読んでVS Codeの設定をゼロから見直してみた - karaage. [からあげ]
  • チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ

    はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン: チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想

    チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
  • Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita

    はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと(テクニカルライティングとも言います)は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

    Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
  • 4歳娘「パパ、constしか使わないで?」 - Qiita

    休日ワイ ワイ「(カタカタカタカタカタ・・・)」 ワイ「(ッターーーーン!!!)」 ワイ「あっ、ぜんぶ消えてもうた」 娘(4歳)「パパ?」 娘「私のお願いしたシステム、作ってくれた?」 娘「曜日によって色々なメッセージが表示されるシステム」 ワイ「おお、鋭意製作中やで(震え声」 ワイ「今、休日かどうかを表示する機能のコーディングを開始したところや」

    4歳娘「パパ、constしか使わないで?」 - Qiita
  • GitHubをフル活用してカンバン(Kanban)方式による開発体制を構築したノウハウを惜しみなく公開する - Qiita

    簡単な自己紹介 渋谷のとあるプログラミングスクールを経営する会社でCTOを担当しています。 昨年、2019年3月にこの会社にジョインしてから開発から新商品企画まで幅広く担当してます。 背景 2019年3月に私が入社した時、システム開発の案件管理に色々と問題がありました。 それらの問題を各ステークホルダーにヒヤリングして問題点と解決案をまとめて社長に提案し、社長の賛同を得て開発体制の構築を進めてきました。 この度、ようやく開発体制の構築ができて順調に開発案件の管理、運用できるようになってきたので、今回、他の会社の参考になればと思ってまとめてみました。 弊社の組織体制 組織としては、CEO(社長)をトップとして、以下チームが下にある形です。 私は、CTOとして開発チームのマネージャーを担当しています。 開発体制の問題点をステークホルダーの声を聞いて整理した 問題の解決にあたって、まずは各ステー

    GitHubをフル活用してカンバン(Kanban)方式による開発体制を構築したノウハウを惜しみなく公開する - Qiita
  • ラズパイ絡みハード開発依頼の注意点(外注先に伝えて欲しいこと) - Qiita

    はじめに メカトラックスの永里です。弊社は主にBtoB(ビジネスユーザ)向けハードウエアの受託開発と製造をやっていますが、特にラズベリーパイ(ラズパイ)をベースとした開発依頼ですと、ソフトは分かるけどハードはよく分からないというお客様が多いです。そういったご相談で良く漏れている点を受託者視点でまとめてみました。 ※以下ハードウエア慣れてる人には常識的な内容ですのでスルーしていただければ幸いです 何のために何をさせたいのか(目的と機能) 稼働環境(何処で動くのか) 電源 サイズ(寸法) 接続する機器・センサ(含 カメラ)等 通信手段と通信先 至極当たり前の内容ですが、依頼する側は求めてるものがクリアなので、こういった基的なことを伝え忘れてらっしゃるのかと思います。 これら情報を検討してから相談するだけで依頼先とのやりとりが数ステップ省略でき、より質的な課題(開発の来の目的)に焦点を絞れ

    ラズパイ絡みハード開発依頼の注意点(外注先に伝えて欲しいこと) - Qiita
  • エンジニア業界を少し外から眺めて - Qiita

    Help us understand the problem. What is going on with this article? お断り ここに書いたことは、私が所属する会社とは何の関係もない個人的な考えです。 特定の業種には不快感を与えるかもしれませんが、日エンジニアが楽しくモノづくりができるようになる未来を願っているだけで、他意はありません。 あるqiita記事で、「格上と格下」という技術者の類型について熱い戦いが繰り広げられていました。 私がそういうモノに参加すると炎上することはわかっていたので、参加しないほうが良かったのかもしれませんが、ついつい参加してやはり沢山の方に敵認定されてしまったようです。 言い訳というわけではありませんが、私の考え方について書いておきたいと思います。 業界の病 日IT業界は病にかかっている。そのことは、どのエンジニアもうすうす気づいているの

    エンジニア業界を少し外から眺めて - Qiita
  • 製造現場向けの自動化ツールをPythonで作る時に留意すること - Qiita

    この記事のモチベーション 昨年、生産技術職からデータ分析業に転職し、Pythonを書く機会が多くなりました。今は機械学習用の前処理ツールを開発する案件に携わっています。そんな中、生産技術者として働いていた時のことを顧みると自動化できた作業が色々あったなーと思いました。転職後に得たPythonの知識と生産技術者時代の知見を踏まえて、再び製造現場で働く際に使えそうなネタを記載します。同じようなニーズに直面している方の参考にもなれば幸いです。 記事は既存技術を組み合わせてこうしたら良さそう!ということを記載したものであり、技術的に目新しいことがない点を初めに断っておきます。 自動化する内容 生産技術者として働いていた時に工程から出てくるデータを1日の終わりに集約するという作業がありました。製造装置のログや検査結果を製品ごとにcsvファイルで保存し、1日の終わりに集約してその日の進捗率や不良率を

    製造現場向けの自動化ツールをPythonで作る時に留意すること - Qiita
  • 競プロ界隈でpython強者がやっていることをまとめてみた - Qiita

    はじめまして。 先週競プロに入門した初心者です。 今はpythonを使っています。 出来ればC++に頼ることなく競プロで良い結果を出したい! ということでpythonのままスコアを上げる方法を考えました。 例えばC++では こんな感じで高速化をする人が多いです。 要するに、頻繁に使う記述を簡略化しておくって感じですかね。 前からこういうおまじない的な慣習があることは知っていました。 が、これのpythonバージョンはpython競プロをやっているのに知りません。 そこで、python競プロ強者の慣習を学んでいこうと思い、この記事を書きました。 同じような方にも参考になれば幸いです。 はじめにしたこと 強い人の提出コードを読みました。 やっぱりC++競プロと同じようなおまじないがあったので解読していこうと思います。 (とある強そうな人から引用しています) 実際のコード 実際のコードを順に

    競プロ界隈でpython強者がやっていることをまとめてみた - Qiita
  • 4歳娘「パパ、具体的な名前をつけないで?」 - Qiita

    ↓新作もよろしくやで! ジェネリクスをもう少しだけ使いこなす。 コロナウィルス対策でリモートワークしてみたらReduxVuexのメリットが分かった 36歳ザコーダーの休日 ワイ「何やこのコード、全然動かへんやん」 ワイ「怖いな~怖いな~…なんか嫌だなあ~」 よめ太郎「(何で自分が書いたコード見て稲川淳二みたいに怯えとんねん・・・)」 よめ太郎「(そんな鳥肌立つようなクソコード書いてんのかいな・・・)」 娘(4歳)「ねぇ、パパ」 ワイ「なんや、娘ちゃん」 娘「ちょっと、作ってほしい関数があるの」 ワイ「またかいな」 ワイ「娘ちゃんはホンマに関数が大好きやなぁ」 ワイ「しゃあない、パパはプログラミング苦手やけど、頑張って作ったるわ」 娘「ありがとう、パパ」 今回の要件 ワイ「ほんで、今回はどんな関数を作ればええんや?」 娘「えっとね」 娘「'あ'という文字列を渡したら」 娘「['あ', 'あ

    4歳娘「パパ、具体的な名前をつけないで?」 - Qiita
  • 初めてのロバスト統計学① - Qiita

    なんとなくロバスト統計の話がしたくなったので、、、 データに外れ値が混入することによって、分析結果の信頼性が損なわれてしまうことは少なくありません。 例えば、成人男性の身長の平均が知りたくて、成人男性5人分の身長を測定して記録したとします。 しかし、入力の際に間違えて1人分の身長の0が多くなってしまい、次のようなデータが得られたとします。単位は $cm$ です。

    初めてのロバスト統計学① - Qiita
  • VSCodeのマルチカーソル練習帳 - Qiita

    VSCodeを使いこなしている人がカーソルを複数置いて手早く作業してて、カッコいいなと思ったことありませんか?こんな感じで。 私はマルチカーソル使います(キャー素敵!)。冗談はさておき、VSCode使ってる人全員がマルチカーソル使ってるわけではなさそうだと最近知ったので、基をまとめてみました。 なお記事では、以下のテキストをサンプルとして使用しています。お手元にVSCodeを用意できる方は、サンプルを使って同じ操作を試しながら覚えてみてください! { "id" : "12345678-1234-1234-1234-123456789012", "title" : "myTitle", "content" : "myContent", "createdAt" : "2019-09-01 00:00:00", "createdUser" : "12345678-1234-1234-1234-

    VSCodeのマルチカーソル練習帳 - Qiita
    belka333
    belka333 2020/03/15
    秀丸で似た機能をなんとなく使っていたがマルチカーソルと言うものだったのか
  • Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita

    初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正:悪は言いすぎました。訂正します。) Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ

    Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
  • 最短経路問題総特集!!!~BFSから拡張ダイクストラまで~ - Qiita

    的アルゴリズム(幅優先探索など)から応用(経路復元、拡張ダイクストラなど)まで、最短経路問題に関するアルゴリズムを総特集しました。 基的なグラフ理論の用語については、次を参考にしてください。 グラフ理論 用語集 queueなどのデータ構造の用語については、次のスライドの後半を参考にしてください。 C++ STL講習会 by @e869120 最短経路問題とは 一般的に、次のような問題とされます。 $V$ 頂点と $E$ 辺からなるグラフが与えられる。頂点 $u$ と 頂点 $v$ を結ぶパスのうち、重みの総和が最も小さいものはどれか。 始点を固定して他のすべての頂点との対について最短経路問題を解く場合や、任意の2頂点の対について解く場合などが実際には多いです。 実社会とも強く密着した問題のため、古くからたくさん効率的な解法が考えられてきました。 今回はそれらを紹介しつつ、細かいテクニ

    最短経路問題総特集!!!~BFSから拡張ダイクストラまで~ - Qiita
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • 過去の難案件 PS2のカーネル開発 - Qiita

    はじめに 時はPlayStation2も そろそろ終わり。 PS2互換機がゲームセンター等で使われていた時代の事です 私は当時 超新人だったんだけどね ただ私は 大学を3ヶ月で光速中退して すぐにフリーランスになった変な経歴持ちです そんな時 ある人物が 掲示板に メモリマネージャやDMA、3DCGについて質問をしていた ちょうどその時期 仕事が楽だったので 光速で回答しました。 メモリマネージャ作りたいっていうので、簡単な方法として、連結リストでAllocateしていくと簡単だよ DMAについては 方向のふらぐがこーであーするだけだよ 3DCGについては DirectXを知識は入れてたので なんとなく回答 すると やり取りから1週間で 仕事してもらえますか? PS2の自社タイトルを作ってます。コアエンジニアが不足しています とメールアドレス宛にメッセージがきたので 請ける事に これがすべ

    過去の難案件 PS2のカーネル開発 - Qiita