自分が書いたコードより目立つな - エンジニアがバズったので自戒 - じゃあ、おうちで学べる
はじめに 私はソフトウェアエンジニアだ。私はソフトウェアエンジニアだ。私の本質的な仕事は、複雑な問題を解決し、効率的で革新的なソフトウェアを開発することだ。長年、私の世界はコードとアーキテクチャとアルゴリズムで構成されてきた。そして、それは今も変わらないはずだった。しかし、予期せぬ出来事が起こり、私の認識は大きく揺さぶられることになった。 パターン認識 エンジニアとして働く中で、私は一つの重要なスキルを磨いてきた。それは、パターンを認識し、分析する能力だ。この能力は、複雑なシステムを理解し、効率的なアーキテクチャやアルゴリズムを設計し、バグを特定する上で不可欠だ。 私たちエンジニアは、コードの中にパターンを見出し、それを活用することで問題を解決する。重複するコードを関数化したり、似たような処理をクラスとして抽象化したり。パターンを見抜く目は、より良いソフトウェアを作る上で欠かせない。 プロ
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話
↑by Image Creator from Microsoft Bing CodeRabbitのレビュー もう初回コードレビューはAIに任せる時代になった - CodeRabbit -を読んだ。レビューはとても負担が多く、時間もかかる。これをAIがやってくれたら、こんな有難いことはない。というわけですぐに使ってみた。 CodeRabbitを使った結論 結論から書くと、レスポンスも速く、技術レベルも高く、気を使う必要もない上に、コミュニケーションも出来る。若干問題に対して答えを言いすぎるキライはあるが、これも使い方に依る。さらにレビューを意識することでコードの健康まで得られてしまう。良いことしかない。 CodeRabbitの価格体系 気になっていたのはやっぱり価格だが、調べてみたらオープンソースであれば無料！だった。また有料も以前はOpenAPIのトークン使用量が別途かかっていたようだが、
月10万円の売上を目指して、個人開発でやったこと全てを公開 - Qiita
何の話 エンジニアの勉強として始めたWebサービスの個人開発。 せっかくやるなら収益化をしようと思い、個人開発2作目にして、売上月10万円を目標にサービスをリリースしました。まだ目標の売上は達成出来てないですが、その収益化モデル、サービス内容の確定、デザイン、システムアーキテクチャ、など全てを公開しようと思い、本ブログを書きました。 私はつよつよ個人開発者ではなく、1年前に組み込みエンジニアからWeb系に飛び込んだ若輩者なので、悪しからず。 [公開したサービス] オンライン動画学習のランキングサイト | Tech Course Rank 後半で詳しく本サービスについて、説明します。 プロフィール 大学卒業後、セキュリティ製品のサポートエンジニア -> Webエンジニア -> ロボット系の組み込みエンジニア-> Web系のエンジニアという経歴です。現在30才。 得意言語は、Python。フロ
10年前に「ムーアの法則が終わる」と言われた頃から現在までのサーバ進化の技術的模索を振り返る（前編）
先々月、あるサーバベンダ主催のイベントで、最近のサーバにおける技術トレンドを紹介して欲しいという依頼を受けて、過去10年のサーバ技術のトレンドを振り返るという講演を行いました。 ほぼ10年前は「ムーアの法則が終わる」と本格的に言われ始めた頃で、そこから実はさまざまな技術、例えばストレージクラスメモリやFPGAやメモリドリブンコンピュータなどのプロセッサの回路の微細化以外の技術によるサーバの性能向上技術が注目され、その一部は市場に投入され定着しつつある一方で、商業的な成功を収められなかった多くの技術もありました。 それらをざっと振り返る内容にしたところ、現在のサーバ技術の方向性がなんとなく見えてきたのではないかと思うので、ここで記事として紹介します。 記事は前編と後編に分かれています。いまお読みの記事は前編です。 10年前、「ムーアの法則」が終わると言われ始めた 今から約10年ほど前、201
直感を超えたソフトウェア開発８つの常識と注意点 | Social Change!
2023年6月10日に発売の拙著「人が増えても速くならない ～変化を抱擁せよ～」は、経営者やマネージャの方々がソフトウェア開発の経験がなかったとしても、その本質を掴めればと思って書きました。 今や経営や事業をしていく上でITを使ったシステムは欠かせなくなっており、関わらないわけにはいきません。特に、事業そのものにソフトウェアを内包している場合において、ただ使うだけでなく開発して活用していく必要があります。 そこでソフトウェアと、ソフトウェアを作るエンジニアたちをマネジメントしていかねばならないとき、従来通りのマネジメントをしていると、うまくいかないときが出てきます。 ソフトウェアとエンジニアのマネジメントは、ともすれば直感的なものから外れていることがあります。本のタイトルにある「人が増えても速くならない」のも、その一つです。 本書では章の目次ごとに、そうした直感とは違っているソフトウェアな
従来とアジャイルで、品質メトリクスには本質的な違いがあるのではないか - ソフトウェアの品質を学びまくる
ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
10年弱エンジニアをやってきてわかった、あなたの開発効率を倍にしてくれるツール37選｜苦しんでプログラミングを学んだ柴犬（くるしば）
※こちらの記事がはてブの総合人気エントリ、noteの「先週もっとも多くよまれた記事」「先週もっともスキされた記事」に入りました！ こんにちは。 苦しんでプログラミングを学んだ柴犬こと、くるしばです。 元々コンサルタントの仕事をしていましたが、独学でプログラミングを学習し、Webサービスを作って起業しました。 その後個人で開発したサービスを売却したり、また別のIT系の会社を創業したりしています。 今年の8月から下記のTwitterにてプログラミング学習に関して発信し始め、ありがたいことに6000人以上の方々にフォローして頂きました。 プログラミング初心者に絶対覚えてほしい、ググる時の効率が10倍上がるコツ pic.twitter.com/hK1ZhNavwh — 苦しんでプログラミングを学んだ柴犬（くるしば） (@shiba_program) September 13, 2022
プレスリリース駆動開発で起こった3つの変化
ストックマークではプロダクト開発の方法として、プレスリリース駆動開発を採用しています。このアプローチは Amazon で Working Backwards と呼ばれる方法に類似した方法です。本記事では、実際にプレスリリース駆動開発を実施すると何が起こるのか？という点について紹介します。今後、プロダクト開発においてプレスリリース駆動開発を採用してみようかな？という方には、有益な情報になると思います。 先に実物を紹介本記事でベースとしているプレスリリースは Astrategy というプロダクトの新機能になります。 詳細は実物をご覧いただければと思いますが、内容草案はまさにプロダクトのPRD(Product Requirements Document)や、実装が進む前からプロダクトオーナーが書いていたものです。 では、詳細検討が進む前にプレスリリース案を作成すると、社内では何が起こるのでしょう
30分でわかるFour Keysの基礎と重要性
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
月5ドルの自作サービスで最初の500人を集めるまでにやったこと
顧客はいったん継続課金を開始すると、特に大きな問題に遭遇しない限り概ね何ヶ月も継続して利用する傾向があります。最近のチャーンレート(解約率)は2~3%で、驚くほど低いものでした。ターゲット層である開発者はこだわりが強いため、彼らは熱心に他のMarkdownエディタを何年もかけていろいろ試しています。そして僕のアプリを最終的に選択しました。だからそう簡単に他に移ったり辞めないのでしょう。ちょうど彼のように： Your application is a life changer. I’ve tried numerous markdown based applications over the years and I’m so pleased to finally find a keeper! Awesome work! — James Lilliott しかし彼らは常によりよいツールを探し求め
第734回 UbuntuでSBOM（ソフトウェア部品表）を作る方法 | gihyo.jp
「SBOM（Software Bill Of Materials：ソフトウェア部品表）」という概念があります。これはあるソフトウェアを構築する上で利用しているライブラリの一覧をまとめたものです。また、システムにインストールされているソフトウェア一覧を示す場合もあります。今回は手元のUbuntuにインストールされているソフトウェア一覧を簡易的にまとめる方法を紹介しましょう。 SBOMの必要性 昨今のソフトウェアは多種多様なライブラリに依存しながら構築されています。太古のC言語のプログラムなら、シンプルなものならlibcだけ、そこそこ複雑なものでも2、3個のライブラリに依存するだけで済むことが大半でした。それが今風のプログラミング言語になると、特定の便利そうなライブラリに依存するだけで、「だったら俺も僕も私もミーも」といくつものライブラリがバンドルされてしまうのです。 結果的に広く使われてい
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
gRPC サーバのビルドに Earthly を使ってみよう
今 Earthly というビルドツールが (自分の中で) 俄かに話題になっています．自分で手を動かしてサンプルコードを作ってみたので，それを基に簡単に機能を紹介したいと思います．題材は Go + gRPC です． Earthly って何？ Earthly は Makefile と Dockerfile を足したような書き味のビルドツールで， Makefile のように複数のタスクを定義し，タスクの中で Dockerfile を書くような感じでテストのような命令を実行したり，イメージを生成して保存したりできます． すでに他の方が Earthly を紹介している記事もあるのでぜひご覧ください． Earthly の大きな特徴は "Makefile + Dockerfile 風な構文の馴染みやすさ"， "タスクをコンテナ上で実行することによる可搬性の高さ"， "ビルドキャッシュの仕組みの簡単さ (
ちょうどよいビルドツールEarthlyの紹介
ちょうどよいビルドツールEarthlyの紹介 ビルドツールと呼ばれるものは昔から現代まで使われているMake、JavaやKotlinでは一般的なGradle、Googleで使われていたものをOSS化したBazelあたりが有名です。他にも様々なビルドツールが存在するのですが、知名度は低いものの最近自分が注目しているEarthlyというビルドツールを紹介します。 まずEarthlyの特徴をBazelやGradleといった他のビルドツールと比較して簡単に紹介します。 Dockerfile + Makefile風のDSL どんなビルドツールでも基本的には独自DSLでビルド設定を書くことになりますが、EarthlyはDockerfileとMakefileを合体させたようなDSLとなっており、他のビルドツールと比較して分かりやすい方だと思います。このDSLについては後述しますが、このサンプルコードでも
米国では既に標準化の流れ、日本企業も対応を迫られる「SBOM」とは
DX（デジタルトランスフォーメーション）やIoT（Internet of Things）の進展により、ますますその存在感が増しているオープンソースソフトウェア（OSS）。ソフトウェアの高機能化、大規模化によるサプライチェーンの複雑化を背景に、SBOM（Software Bill of Materials）によるOSSサプライチェーンマネジメントに注目が集まっています。米国では既に必須化・標準化の動きが始まっており、日本企業も対応を迫られるようになってきました。本記事では、あらためてSBOMとは何か、そして日本におけるSBOM活用の普及促進にはどういった課題があるかについて、詳しく解説します。 SBOMとはいったい、どのようなものなのか Software Bill of Materials（SBOM、「エスボム」と読みます））とは、ソフトウェアを構成するOSSや商用ソフトウェアなどのライブラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イナバ on Twitter: "元アマゾン社員が「Amazonが新規事業開発で使っているアイデア出しフォーマット」を公開していました。 プレスリリース形式に情報をまとめるとのことです。 出典：forbes「アマゾンのすごい『逆算資料』。新サービス説明資料は『プレスリリース形式』で」 https://t.co/Or2IInQAVC"
yusuke56.eth / Coincheck on Twitter: "新規事業をやる時に見返している「ソニーの開発18ヵ条」 https://t.co/0rLHXsu390"
