v0 by VercelGenerate. Refine. Ship.Generate UI with shadcn/ui from simple text prompts and images.
生成AIでシステム開発はどう変わるか
https://layerx.connpass.com/event/301629/ での発表資料
LINE LIVE クロージング連載 Vol.1 - プロジェクト全体の生産性と安定性の向上
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、開発3センターの堀内(horiuchi)です。 現在は LINE ドクターのサーバ開発リーダーとマネージャーをしております。 2015年12月に提供を開始し、2023年3月末にサービス提供を終了したライブ配信サービス「LINE LIVE」では、さまざまな技術的な挑戦や工夫を行ってきました。 そこで、今まで行ってきた施策の紹介や大規模サービスならではのクロージングに関わる話を連載していきます。 初回のこの記事は、プロジェクト全体の生産性と安定性の向上を目指して改善してきたことについて紹介します。 プロジェクトの状況や背景 LINE LIVE は7年以上続いてきました。その間に追加された機能は規模が大きく複雑なものも多
エンジニアの枠を囚われないプロダクト開発 - 事業づくりに求められる「越境」をするには
私は「大きな社会の課題解決に挑む会社であること」、「不確実な状況下で事業づくりにチャレンジができること」に惹かれて新卒でVisionalに入社してから、約3年半新規事業でソフトウェアエンジニア兼プロダクトマネージャーとして手探りながらも事業開発に関わってきました。本記事では、その経験を元に、エンジニアから見たプロダクト開発における越境についてご紹介します。 これまでプロダクト開発を進める中で、事業の解決すべき課題にフォーカスするためには特定の役割のみに閉じているカタチでは実現できないと感じる場面が多くありました。世の中に価値あるプロダクトを提供するために、職種や立場にとらわれず、個々がオーナーシップを持って役割を染み出しながら、事業開発に向き合うということをここでは「越境」としています。 ここからは、私が「BizHint」で実際に行った「メールマガジン配信」における制作改善業務の具体的な体
ヤフーでは開発迅速性と品質のバランスをどう取ってるか（2022年）
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 皆さんは「No Measurement, No Improvement」という言葉をご存じでしょうか。これは「測れないものは改善できない」という意味で、熱力学者であるウィリアム・トムソン博士の言葉とされています。 下図はGoogle社のDORA（DevOps Research and Assessment）を参考にして作成しました。開発スピードとサービスの品質を改善するためには計測が必要です。計測のための4つの指標を紹介します。 四つの指標で計測し、開発スピードとサービスの品質を改善 開発スピードの分析に利用する指標は、1つ目が「Change Lead Time（開発が始まってから本番にデプロイされるまでの時間）」、2つ目が「De
Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG
こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。 以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。 Netflixにおけるフルサイクル開発者―開発したものが運用する 2012年―Netflixでの重要なサービスの運用は骨の折れ
ユーザーは、どのようにしてシステム仕様を検証できるのか？ - Hot Heart, Cool Mind.
なぜ顧客は受入テストで仕様変更に気がつけるのか？ ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう？」という疑問だ。 http://blog.hacklife.net/archives/50737557.html これに対して「本気度の違い」「ドキュメントで書けることの限界」「網羅性の違い」といった答えが、何人かの方から返されていて、僕もこれらの答えには基本的に賛成だということを言っておく。その上で、普段から感じている、もう少し「テクニカル」な要因について、ちょっと書いてみたい。 僕がなんらかの画面を設計して、ユーザーを招いて検証のための
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
Is High Quality Software Worth the Cost?
A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. Betteridge's Law of headlines is an adage that says
ソフトウェア設計原則は変更容易性に通ず - Shin x Blog
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
継続してプロダクトの品質を保つためにはプロダクトに向き合うだけでは足りないという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。 そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。 「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。 じつは直面すべき課題は「内部品質の低さ」や「依存ライ
失敗する書き直し、成功する書き直し / karino2 - Message Passing
全体的な事を言えば、自分は書き直し反対派と思う。 morritaさんの言う20年前の意見をほぼそのまま現代まで持っている。 頭の硬い古い老人という事だろう。 そういう訳で、そんな古い側の人間が書き直しについてどんな事を思っているのかを書いてみたい。 失敗するケースは割と限定されている ソフトウェアの書き直しには、成功するものと失敗するものがある。 失敗する条件を厳密に挙げるのは難しいけれど、失敗する書き直しは、自分は見れば分かる、と思っている（本当に分かるかは議論の余地があるけれど）。 まずshinhさんの言っている半分素人が挑戦するケースは良く見かける。これはまぁいい。全然良く無いけれど。 それ以外で良く失敗するのは、ある程度の規模、だいたい10万行以上のソフトウェアで、 その時点で多くのユーザーを持っていて、 書き直しにかなりの時間と人がかかる奴が多いと思う。 そしてデスクトップ、iO
今年こそWebサービスを作りたい人に伝えたい５つのこと（＋番外編） - パパパパ
長くなったので目次を作りました。 1.アイディア出しより前にするべきたった１つのこと 2.あなたが狙うべきテーマは？ 3.成功するサービスは何が違うのか 4.外さないサービスの実例と僕の実体験 5.僕が考える究極のWebサービスとは 番外編.サービスを作ることと、稼ぐは別物 - アフィリエイトに取り組んだら売上が月3,000万円になった話 まえがき 最近、個人でWebサービスを作りたい人がとても増えている気がしています。僕は個人開発者として、最近リニューアルしたばかりのQ&Aなうや書き起こし.comなど、これまで30以上のWebサービスを作ってきて、失敗したりちょこっとうまくいったりした経験が、これからWebサービスを作りたい人に少しは役に立つことがあるんじゃないかと思ったので、僕なりにWebサービスを作る上で気をつけているポイントを書き残すことで、僕と同じ失敗を避けて、うまくいくWebサ
第1回 Tracをオススメする，これだけの理由：ITpro
Tracの便利さに惹かれるが，インストールに煩わしさを感じ，Tracを簡単にインストールできるTrac Lightning（旧Trac月）の開発を行う。また，日本のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として，プロジェクト管理ツールのTracが注目を集めています。Tracは，Ruby on RailsやSpring IDEなどでも利用されています。本連載では，開発現場を交通整理するために，Tracを利用したプロジェクト管理の効率化を，Tracの基礎から紹介していきます。 ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。 ま
遊べない奴は使えない
1960 年生まれ，独身フリー・プログラマの生態とは？ 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，2007年に至るまでの生活を振り返って，週2回のペースで公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 今回は私の「遊び」について紹介しよう。ここで，華麗なナイト・ ライフや行動的なアウトドア・ライフの話になるのかな，と思った人 はまさかいないと思うが，その通りである。ここで言う遊びは，コン ピュータにひたすら向かうコンピュータ・ライフの一環である。 と言っても，ゲームでもチャットでも掲示板でもない。目新しいラ イブラリのソースコードを入手して読んだり，サンプル・プログ
日本語・英語に対応したサイトを作るときの URL 設計メモ : 管理人@Yoski
日本語・英語に対応したサイトを構築するとき、ドメインや URL の設計をどのようにするのが良いのか、振り返ってみるといろいろ実験してたのでメモ(まとめ)として残します。 これまで、以下のようなパターンを試してみました。 A.完全にドメインを分ける atode.cc と toread.cc B.サブドメインで切り分ける en.abc-yoga.biz と he.abc-yoga.biz C.ディレクトリを分ける www.freshreader.com/ver2/ja と www.freshreader.com/ver2/en D.ファイル名だけで区別する http://reviewposter.com/index.php と http://reviewposter.com/en_index.php E.クッキーや Accept-Language で表示ページを振り分ける http://sid
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ノートラブルシステムへの道
System of Record と System of Engagement