ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
Remove TypeScript - laiso
経緯 world.hey.com DHHが「オタクくん見てる〜？ 今からうちのレポジトリからTypeScriptを剥しま〜す」と宣言したことにより、Web開発者界隈でTypeScriptの是非自体の話になり騒ぎになった*1*2。 github.com その後、野次馬がたくさん集ってきてrevertプルリクエストを立てる人やTypeScript公式リポジトリから全ソースコードを消すプルリクエストを出す*3ようなキッズムーブをする人も出てきた world.hey.com 実際の変更 8617行のTypeScriptがJavaScript化された。(Sloc 便利) ❯ scc src/ ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blan
つよつよエンジニアの成果物にある5つの特徴 - Qiita
はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」
アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾 剛
アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ
読みやすいコードを書くためのガイドライン
はじめに 長くシステム開発に携わっていると、最初は素早く開発することができたけども、今では新たな機能を付け加えるのに、多くの時間を費やすようになったという話をよく聞きます。 初めはシンプルだったソースコードも年月が過ぎていくなかで、機能追加やバグ修正、変更を行なっていくと、コードが非常に複雑化していき、開発者が修正するコストの増加やコード品質の低下につながります。設計の良くないコードや複雑化したコードは、同じ処理をするのにも余計にコードを書く必要がでてくるからです。 今回は、コードを複雑化して品質を低下させないために、普段意識しているソフトウェア設計や手法を紹介していきたいと思います。色々書いていますが、結果的にクリーンアーキテクチャー成分が多めになってしまいました。 「読みやすいコード」が持つメリット コードを読みやすくすることは開発全体に好影響を与え、特に以下の点において最大限効果を発
［速報］「GitHub Copilot X」発表、GPT-4ベースで大幅強化。AIにバグの調査依頼と修正案を指示、ドキュメントを学習し回答も
［速報］「GitHub Copilot X」発表、GPT-4ベースで大幅強化。AIにバグの調査依頼と修正案を指示、ドキュメントを学習し回答も GitHubは、GTP-4をベースに「GitHub Copilot」の機能を大幅に強化した「GitHub Copilot X」を発表しました。 GitHub Copilot is already helping developers code faster in their IDEs. But what’s next? Our answer is GitHub Copilot X. It’s our vision for the future of AI-powered software development. Check it out https://t.co/3Xrn7dAPgi — GitHub (@github) March 22, 202
規模感の違う脱レガシーで必要なこと - memo_md
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022 の 15日目の記事です。 qiita.com 筆者は過去に、中〜小規模のWebアプリケーションでレガシーフロントエンドの改善作業を業務でやっていた。その経験を元に技術同人誌を作成し、それがきっかけで「レガシーフロントエンド安全改善ガイド」という書籍を出した。 初版から数年経ってしまい、詳細な利用技術などの説明は少し古くなってしまっているのだが、ベースとなる考え方の部分は今でも変わっていないと思う。 一方で自分自身は、その経験が他の環境でも通用するのかを試してみたくなり、転職して一年強ほど大規模なフロントエンド刷新に関わっていた。 あまりにも規模が大きいため完遂を見届けたわけでもないが、現段階でも学びや得られたものは
ヤマト運輸株式会社 | GitHub
1919年の創業以来、日本初となる路線事業を開始し、1976年には個人間で簡単に荷物を送ることができる「宅急便」を発売するなど、日本全国を網羅する物流ネットワークを構築し、社会的インフラとして社会課題の解決に取り組んできた。現在は、宅配便サービス国内シェア第1位（シェア：46.6%、2021年度、国土交通省調べ※）、国内宅急便ネットワークカバー率100％を誇り、宅配便の年間取扱個数は約22.5億個（2021年3月期）に達した。2020年1月に経営構造改革プラン「YAMATO NEXT100」を策定し、データ・ドリブン経営を推進している。 ※令和３年度 宅配便等取扱個数の調査及び集計方法（国土交通省） 開発環境の内製化の実現に向けAzureとGitHubを採用 開発基盤を統一し、アジャイル開発とDevOpsを促進 ・AzureとGitHubを採用し開発基盤の内製化へシフト、DevOps導入を
TypeScriptでコードを書く時に意識していること
なんだかんだでTypeScriptを業務でも個人開発でも使うようになって3年くらいが経過しました。 TypeScriptは便利ですよね☕️ 世の中的にも、もはやTypeScript以外でフロントエンドの開発を行うことが珍しいくらいの雰囲気になってきたのではないかという感じがします。 最近というかTypeScriptを書き始めてしばらくした今、書き始めた当初とは意識することが変わってきたように感じています。 そういうわけで、今、どんなことを意識しているのかを自分の整理をこめて記載しておこうと思います。 🔥🔥🔥 型を先に定義する ここがかなり気持ちの上で変わった部分です。 TypeScriptで型を書くということは、つまるところ自分が今から記述するコードの設計図を書くということだという意識が強くなりました。 TypeScriptの型推論は非常に強力で、自分でほとんど型を定義しなくても、多
デンソーウェーブ、細長く狭いスペースにも印字できる、長方形型の新しいQRコード「rMQRコード」を開発
デンソーウェーブは、長方形型の新しいQRコード（注1）「rMQRコード（アール・エム・キューアールコード：長方形マイクロQRコード）」を開発しました。rMQRコードは、QRコードの特性である優れた読み取り速度とデータ容量を持ちながら、細長く狭いスペースへの印字を実現するもので、製造業をはじめとした幅広い業界において、情報や資源の効率的な管理・運用に貢献します。また、rMQRコードは国際規格(ISO)を取得しており、世界中のすべてのユーザーに自由に安心して使っていただけます。 (規格番号：ISO/IEC 23941:2022） ■rMQRコードの開発背景 デンソーウェーブは1994年、QRコードを開発しました。QRコードは優れた読み取り速度とデータ容量を持ち、また、パブリックドメインであることから、世界標準となり幅広い分野で活用されています。次いで小型の「マイクロQRコード（注2）」を開発す
SaaSなのにほぼノーコードで2億円調達した話｜Kotaro Harada | HQ
今回は昨日発表されたCoral Capitalさん等からの資金調達におけるプロダクト開発の裏側を書こうと思います。特にソフトウェア領域での新規サービス立ち上げや起業を検討している方に参考になれば何よりです。 本文の前提についてさて、本題に入る前に今回の調達リリース記事にまつわる事実を列挙します。 リリースの内容はこちら 2021年3月: 株式会社HQ創業 2021年5月: kotaroがプロダクトマネージャーとしてジョイン(当時ソフトウェアエンジニアは0人) 2021年9月: トライアルでサービス提供開始 2021年11月: 正式ローンチ 2021年12月: 利用ユーザー200名突破 2022年3月: 利用ユーザーが5倍(1000名)に成長 2022年3月: Coral Capital等からプレシリーズAで約2億円を調達 まだまだ(x100)なのは大前提として、創業1年経過のスタートアップ
なんちゃってアジャイル開発やアカン・ローコード開発のまん延、怖くて震えるぞ
最近、アジャイル開発とローコード開発に共通の問題があると気づいた。あらかじめ断っておくが、アジャイル開発とローコード開発を一緒くたにして暴論しようというわけではない。あくまで両者は別のものと認識したうえで、「なんちゃってアジャイル開発」と「アカン・ローコード開発」に共通する問題を指摘しようという意図である。 「共通の問題があると気づいた」などと偉そうに書き始めたが、実は「気づかせてもらった」というほうが正しい。ユーザー企業におけるアジャイル開発の問題点を述べた識者の指摘と、ローコード開発で陥りがちな誤りについて話してくれたCIO（最高情報責任者）の指摘が見事に一致したのだ。 アジャイル開発における問題点を指摘したのは、日経クロステックのコラム「『ITオンチ経営者』への処方箋」で記事を執筆しているITコーディネータ協会会長の澁谷裕以氏だ。読者からの非難が殺到することもある「極言暴論」の性質上
【初心者向け】AWS Code サービス群を4つをお試しできるハンズオンをやってみた | DevelopersIO
こんにちは、DOP勉強中のリサリサです。 DOP(AWS Certified DevOps Engineer - Professional) の試験ガイドにCode サービスが含まれていますが、触ったことがないのでいまいち分からず…。簡単に試せるハンズオンがないか探していたら見つけたので紹介します。 動画を見ながらできる初心者向けのハンズオンで、全部で2時間程度で完了できました。 ハンズオン概要 無料ですが、こちらからお申し込みが必要です。 AWS Hands-on for Beginners AWS Code サービス群を活用して、CI/CD のための構成を構築しよう！ ゴール AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodePipeline の特徴が理解できます！ 作れるもの CodeCommit のリポジトリへの push をト
Ruby 3.1はエラー表示をちょっと親切にします - クックパッド開発者ブログ
こんにちは、ruby-devチームの遠藤（@mametter）です。 Among Usというゲームをやってるのですが、友達が少なくてあまり開催できないのが悩みです。 今日は、Ruby 3.1に導入される予定のerror_highlightという機能を紹介します。 どんな機能？ NoMethodErrorが起きたとき、次のような表示が出るようになります。 error_highlightの動作例 どこのメソッド呼び出しで失敗したかが一目瞭然ですね。これだけの機能ですが、使ってみると意外と便利です。 もう少し詳しく この機能が本領を発揮するのは、RailsのparamsやJSONデータの取り扱いなどのときです。 たとえばjson[:articles][:title]みたいなコードを書いて、undefined method '[]' for nil:NilClassという例外が出たとします。 この
コマンド1発でKubernetes上にProduction Readyな環境を手に入れる - LIFULL Creators Blog
KEELチームの相原です。 最近開発している コマンド1発でKubernetes上にProduction Readyな環境を手に入れる コードジェネレータの話です。 Kubernetesの利用を広める上での課題 Kubernetes Manifestの難しさ 既存の解決策 設定量の増大 コードジェネレータで解決する 捨てやすさ 抽象度 変更への追従しやすさ Open Application ModelとKubeVela keelctl を開発してきてみて Kubernetesの利用を広める上での課題 KEELチームが開発しているアプリケーション実行基盤は巨大なMulti Tenancy Kubernetesクラスタをベースとしていて、各アプリケーション開発者はKubernetes Manifestといくつかの設定を記述するだけでProduction Readyな環境ですぐにアプリケーション
はてなリモートインターンシップ2021を開催します！ - Hatena Developer Blog
追記：募集開始しました 「はてなリモートインターンシップ2021申し込み」はこちら 追記ここまで こんにちは、CTO の id:motemen です。 はてなは今年も、学生を対象としたエンジニア向けの夏のインターンシップ、「はてなリモートインターンシップ2021」を開催します。 現時点での新型コロナウイルス感染拡大状況などを考慮し、リモートでの短期インターンの実施を企画しています！ 今年のインターンでは、8月後半、3週間程度のプログラムとなる予定です。 リモート開催に最適化したカリキュラムを用意します。 前半はWebアプリケーション開発のオンライン講義を実施後、数日かけて課題に取り組んでもらい、はてなのエンジニアスタッフによるコードレビューや面談でフィードバックを行います。 後半はチーム開発体験です。「フレキシブルワークスタイル制度」という在宅勤務・出社を全スタッフが選択可能な制度を採用し
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AIが「理解」するから、API仕様書のコピペでアプリができあがるローコード開発環境「Flowise」を試す【イニシャルB】
GitHub、コードエディター「Atom」の開発を終了 ～年内にアーカイブ／「Visual Studio Code」の台頭に抗しきれず。「GitHub Codespaces」、「Zed」に期待
やってきたノーコード アプリ開発、誰でも早く安く - 日本経済新聞
