多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
2024/07/13 大吉祥寺.pm 20分レギュラートーク 登壇資料
無邪気なエンジニアリングができなくなってきた
タイトルの通り。好きでやっているエンジニアがだんだん好きではなくなってきたような気がして、改めて何が起きているのか、思考はまとまらないから箇条書きする。 無邪気なエンジニアリングとはコードを読む、書くのIOがとにかくたくさん気になったOSSやサービスはすぐさわる記事や登壇で書く以外のアウトプットもたくさん無邪気なエンジニアリングをして、これになりたかったインターネットで一発当てる著名なOSSのコミッターカンファレンスのプロポーザルをたくさん通す本をたくさん書いているたくさん質の良い記事を書いて凄い PV 数なりたかったのその行く末生活を全てエンジニアリングに捧げようとする無理あらゆる技術イベントに顔をだそうとする私生活や仕事でしばしば予定がつかずキャンセル帰りが遅くなるのが良くないので、家から近いイベント以外いかなくなった（規模の比較的おおきい）コミュニティを主催するスポンサー探しで苦労こ
ノーコードって結局使えないよね～って話 - Qiita
はじめに コードを書かずにWebサイト/アプリ/ツール等の制作ができるノーコードツールが最近流行っていますよね。 私自信、半年ほど前からn8nやActivepiecesといったOSSのノーコードツールやPower Automateなど、幾つかのノーコードツールを触っていたですが、ツールとして未成熟であったり自由度が低かったりと、「結局流行らないのでは？」と感じています。(GPTのそれと一緒で期待値が高いだけなんですかね) ノーコードツールの幻想 D&D操作だけで直感的に操作できるノーコードツールは、一見、プログラミング初心者にとって救世主のように映ります。しかし、それは十分な選択肢なのでしょうか？ 本当に手軽ですか？ 多くのノーコードツールでは、よくあるような定型作業のテンプレートとD&D操作で実装できるUIを提供することで、直感的に操作できるよう設計されています。 一見、自由度の高い開発
しょーもない事務作業を快適にするためのツールを作りたいとき 〜セキュア意識の高い会社編〜 - Qiita
Pythonインストールできないんだけど！ なんかいつもこれ同じ作業してるよな、自動化出来ないかな…よしやったる！ ↓ みんなー！こんなツール作ったよー、使ってみてー！ ↓ そして起こる「ちょっと、俺、.pyとかいう拡張子使えないんだけど」の声。 会社のPCって外部のアクセス禁止だったり新規ソフトウェアのインストール制限があったりと、色々制約がありますよね。この制約のせいで、作ったはいいが使えなかった、みたいな理不尽なハマり方したり、一方で試してみたら意外とこれ動いちゃうんだ！？みたいなこともあったりするので、ここではそんなずる賢い業務改善を必死に考える社員のみんなに、どれでやれば利用可能なツールづくりができるのか、その選択肢を載せていくよ。 Python + exe化ツール(Pyinstaller) やっぱ中身含めてファイル操作系でちょこちょこやるならPythonが楽だよね。ただ、Pyt
「AWSが分かっていない」のではなく、コンピュータサイエンスが分かっていなかった - Qiita
はじめに ◆この記事は何？ 焦ってAWSの勉強をするよりもコンピュータサイエンスの基礎を勉強してからの方がよかったという私の経験を紹介する記事です ◆対象は？ AWSの勉強をしている方 特に若手 ◆この記事のねらい AWSの勉強効率を上げる 先に結論 AWSの勉強に時間がかかったのはコンピュータサイエンスの基礎ができていなかったから コンピュータサイエンスの基礎を勉強してからの方が、圧倒的に効率が良い 遠回りに見えるが、近道だと考える 急にAWSを勉強した 新卒1年目からデータサイエンティストとして働いています。 急にAWSが必要になったので、急いでAWSの勉強をしました。 結果的には、「AWS Certified Cloud Practitioner」「AWS Certified Solutions Architect - Associate」を取得しました。 当時は知らない用語ばかりで
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
なぜベトナム？オフショア開発でベトナムを選ぶべき理由
（参照：GLOBAL NOTE 世界のインターネット普及率 国別ランキング・推移） 1-4. リアルタイムにやり取りできる時差の魅力国によっては、日本が昼で開発現場が深夜という場合もあります。その場合、急ぎの対応もすぐにできません。しかし、ベトナムは、「-2時間」とほとんどありません（日本時間で11時であればベトナムは9時）。そのため、リアルタイムにコミュニケーションを取ることができるので時差による心配はないと考えて良いでしょう。 他の国の時差も見てみましょう。 ┗フィリピン -1時間 ┗インド -3.5時間 ┗バングラディシュ -3時間 ┗中国 -1時間 ┗ミャンマー -2.5時間 ┗ウクライナ -7時間 ┗アメリカ -14時間 ※一部、時差を利用した開発や運用・保守もあります。例えば、24/365で対応しないといけないとき、日本時間で深夜の時に、ビジネスタイムになる国を利用する開発方法
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
QAエンジニアがSMに憧れてしくじった話
ちょっとだけ読んでから積む「積⭐️読タイムアタック」で、タワーと化した購入書籍の未読圧のプレッシャーから解放されました
新人プログラマ アンチパターン：原理原則多すぎて脳みそOOMエラー - Qiita
この記事で伝えたいこと（忙しい人向け） 新人ほど「保守していく」ことの感覚が腹落ちしにくいのではないか説 我々は保守しやすいコードを書くべきであり、保守しやすいコードを達成するための手段として原理原則やデザインパターンが存在している 保守ってなんで必要なんだっけ？という体系的な理解を持ったうえで、具体的なテクニックを学んでいくことが大事 // 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか？みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき
ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
「H3」初号機打ち上げ失敗【速報中】2段目点火せず指令破壊
日本の新たな主力ロケット「H3」の初号機が7日午前10時37分、鹿児島県の種子島宇宙センターから打ち上げられましたが、2段目のロケットが点火せず、その後、指令破壊の信号が送られ、打ち上げは失敗しました。 これを受けてJAXA＝宇宙航空研究開発機構が会見し、山川宏理事長は「ご期待に応えられず、深くおわびを申し上げます」と謝罪しました。 発射から13分55秒後に「指令破壊」 「H3」初号機の打ち上げは7日午前10時37分、鹿児島県の種子島宇宙センターで行われ、計画では、打ち上げからおよそ17分後に、搭載した地球観測衛星「だいち3号」を軌道に投入する予定でした。 ところが、発射から13分55秒後、ミッションを達成する見込みがないとして地上からの指令でロケットを爆破する「指令破壊」の信号が送られ打ち上げは失敗しました。 「H3」の打ち上げは当初、2020年度の予定でしたが、新型のメインエンジンの開
「実践Django」は筋肉質かつ骨太で、技術書のお手本のような書籍 - ビープラウド社長のブログ
学生時代にビープラウドで仕事をされていた@c-bataさん執筆の実践Django Pythonによる本格Webアプリケーション開発を拝読しました。 読み終わり感じたことは「筋肉質で骨太な書籍である」ということです。 筋肉質である なぜ「筋肉質」かというと、それは書籍の構成にあります。 構成は、1章のチュートリアルを一通り学べば、Djangoの主要機能を広く学ぶことができ、さらに知識を深めたい場合は、2章以降を必要に応じて読めば良い構成になっています。 また各章は、必要最低限の要素が学べる洗練されたサンプルコードをもとに説明されています。 これは現場でDjangoを使った開発に取り組む必要があり、短時間で学ばなければならないエンジニアにとってとてもありがたいことです。 骨太である 「骨太」という点においては、各章の説明が充実していることです。 実運用するWebアプリでは、機能を動かすだけでは
いわゆる受託開発における「プログラミングは簡単な部類」は本当なのか - Qiita
上記ツイートについて、いわゆる「受託開発企業」で働く私の印象としては、本当にその通りだな〜と思います。 そして、これまであまり意識しておりませんでしたが「受託開発における納品（完了）までの各フェーズ出し」をしてみようかと思います。 受託開発における納品までの各フェーズ出し １. 問い合わせへの返答 「お問合せいただきありがとうございます。それでは早速Webミーティングにて詳細を」 ２. 第１回Web打ち合わせ「お互い紹介」編 会社スライドにて自社紹介。依頼内容の確認・質問。 できればここで「依頼内容に対してのざっくりの予算感」をさりげなく聞きましょう。奇想天外な予算を想定しているパターンもあります。 ３. 見積もりの作成 できるだけ素早く見積もりを作成し提出すると吉。（早いと喜ばれやすい） 保守費用についても記載してくださいね。（後で聞かれるパターン多い） 見積もり項目は細かい方が信頼度は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Developers Summit 2024フォローアップ】『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～
COCOAの総括（オープンソースコミュニティとして） · Issue #1144 · cocoa-mhlw/cocoa
