レガシーなフロントエンドを リプレースするプラクティス。 エネチェンジが挑む 「React化」ENECHANGEでは、電気とガスの料金シミュレーションサービス「エネチェンジ」を開発しています。リプレース前の「エネチェンジ」のフロントエンドは、jQueryがメインで、ところどころVue2が使われていました。今回は、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかに…
Design Docs を活用して効果的にプロダクト改善
No one is an island. Learnings from fostering a developers community.
中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
『みんなで小さく区切って進める』ガイド｜kawanotron
『みんなで小さく区切って進める』とは『みんなで小さく区切って進める』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくための進め方です。 『みんなで小さく区切って進める』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切って進める』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは
kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
kintone フロントエンドリアーキテクチャプロジェクトリーダーの @koba04です。 昨年末から、kintone フロントエンドリアーキテクチャをプロジェクト（フロリア）として再構成してスタートさせました。フロリアという名前は社内での公募により決定しました。 今回はプロジェクトで目指していることについて紹介します。本プロジェクトの開始前に Cybozu Meetup で話したスライドや動画も公開されているのでよければ見てください。 speakerdeck.com www.youtube.com これまでの取り組みについては下記の記事にて紹介しています。 blog.cybozu.io 3 行まとめ フロリアのゴール 全てのページが React によって表示されている 現状 今後 フロントエンドが技術的にもチーム的にも分割されている モノリスな構成からの脱却 アーキテクチャとチーム（
インプットのすゝめ | 外道父の匠
絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の
及川卓也氏×吉羽龍太郎氏が“プロダクトマネージャーの覚悟”を分解 求められる役割のひとつ、“カネを利用する覚悟”
テーマは「プロダクトマネージャーの“覚悟”を分解する」 司会者：それでは、キーノートセッションを開始いたします。「プロダクトマネージャーの『覚悟』を分解する」と題して、Tably株式会社、代表取締役。Global Hands-On VC、Founding Partner。アドビ、Executive Fellow。クライス＆カンパニー、顧問、及川卓也さま。株式会社アトラクタ、取締役CTO、アジャイルコーチ、吉羽龍太郎さまよりご講演いただきます。 及川さま、吉羽さま、よろしくお願いいたします。 （会場拍手） 吉羽龍太郎氏（以下、吉羽）：よろしくお願いします。 及川卓也氏（以下、及川）：おはようございます。よろしくお願いいたします。 吉羽：じゃあ、さっそく始めていきたいと思います。今日は、「プロダクトマネージャーの『覚悟』を分解する」というテーマでお話をさせていただきます。実は、実行委員の方から
LT資料作成の基礎 / Basics of LT Slide Preparation
「広報・人事さん集まれ！LT初心者の会！！」にて登壇 https://connpass.com/event/315746/
Being A Developer After 40
Is age an impediment or an advantage when you are a software developer? How does experience work? What are the consequences of your decisions in your pr…
請求関連テーブルのスキーマ変更をした話 - Feedforce Developer Blog
以前に アプリケーションを停止させずにRDBのスキーマ変更する話 を書きました。 developer.feedforce.jp 今日は、その実践編というか、実例として EC Booster というサービスで請求関連テーブルのスキーマを変更した話をしようと思います。 はじまりのテーブル 元々、 EC Booster の請求を管理するテーブルは、このような形でした。 create_table "monthly_charges", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.uuid "shop_id", null: false t.integer "year", null: false t.integer "month", null: false t.datetime "created_at"
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」そーだいなる輪読会 フィナーレの登壇資料です。 https://connpass.com/event/313898/
週刊Railsウォッチ: Prismの歴史と現況を振り返る、Steepの"narrowing"実装の内部ドキュメントほか（20240426後編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） お知らせ: 来週および再来週の週刊Railsウォッチはお休みをいただき、通常記事を公開します。 🔗Ruby 🔗 Steepの"narrowing"実装の内
攻めと守りのトレードオンを目指した開発ルールの見直し - dely Tech Blog
こんにちは。delyでクラシルリワードのサーバーサイドの開発をおこなっている高松です。 はじめに 今私が開発を担当している「クラシルリワード」は、日々我々が行う購買行動をよりお得に行なってもらうことを目的に作られたサービスです。 dely.jp 私は2023年10月からクラシルからこのクラシルリワードの開発担当として異動してきました。 クラシルリワードにおいては、プロダクトの急成長段階にあり、KPIを伸ばす上で何が適切なのかの解像度が低い状況にあります。 そのため、仮説検証をなるべく早く繰り返すことで、解像度を上げて施策の効果を最大化したい思いがあります。 この記事はそんな中で、開発ルールは現状のもので良いのかを改めて考えてみた経緯です。 トレードオンとは 弊社にはトレードオフと対比する言葉としてトレードオンというどちらのメリットも享受できる方法を考えようという文化があります。 今回はその
桁違いに読書の質が上がる超簡単な読書法｜ふろむだ@分裂勘違い君劇場
本を読んでて、気になるところがあったら、 その要点をテキストファイルに箇条書きにして、整理しながら読書する。 これだけ。 これだけで、読書の質が桁違いに上がります。 これをやると、「普通に本を読むだけだと、理解した気になってるだけで、実はろくに理解してなかった」と分かって驚きます。 話はこれで終わりですが、 以下の点が気になる方もいらっしゃるでしょう。 ●どんな人がどんな本を読む場合にもそうなるわけじゃないだろ。具体的に、どんな人がどんな本を読む場合にそうなるんだ？ ●そんなの面倒くさくてやってらんない。手間をかけずにやる方法はないの？ ●具体的にどうやるとうまくいくのか、もっとちゃんと説明しろ。 そういう方のために、以下、これらについて補足します。 まず、読書を以下の９種類に分類します。 (1)リアルタイム活用読書読んだ知識を今やっている仕事/生活/趣味にリアルタイムに活用しながら読む方
Ruby コミッタの仕事報告 2024Q1 & RubyConf AU 2024 に登壇しました報告 - ANDPAD Tech Blog
こんにちは柴田です。RubyKaigi のスポンサーについて書いていたら、CEO からオーストラリアのことを社内に共有してほしい、という依頼が来たのでテックブログに書けば社内にも社外にも伝わって便利だなと思いエイッと書いてしまいました。こういうのは書き始めるまでが一番難易度高いのでちょうどいいきっかけでした。 というわけで、今回は 4/11-12 にオーストラリアのシドニーで開催された RubyConf AU 2024 と私の発表についてご紹介します。 RubyConf AU 登壇の経緯 RubyConf AU は Ruby Australia というオーストラリアの Ruby コミュニティが主催する Ruby のカンファレンスです。Ruby conferencesによると 2014 年に Sydney で開催され、その後は Gold coast でも開催された年もありますが、Melbou
Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト（エンドツーエンドテスト）とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
若手のうちに知りたかった生産性の高め方
D-Plus Tokyo #1 https://d-plus.connpass.com/event/315744/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ISUCON入門以前_ISUNARABE_LT#1
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
10分でわかるfreeeのPdM
