スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点RubyRailsScalaポエムスタートアップ この記事を書くに至った経緯 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRuby on RailsからScalaに移行したのですが、その効果が思ったよりだいぶ大きく、いずれこの効果を共有したいなーと思っていました。 弊社ではスタートアップで全員ほぼ未経験状態のScalaを採用するという挑戦をした結果、「Scalaを書きたい」というレベルの高い人材をかなりの確率で捕まえられるようになり、開発がものすごい加速した上に堅牢になったのでそのうちスタートアップでScalaを採用するメリットを記事にする予定。 https://t
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由｜ハイクラス転職・求人情報サイト AMBI（アンビ）
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら
データベースリファクタリングに挑戦してみた。(トリガーを使わないで列名を変更する) · DQNEO日記
下記で紹介しているのはあくまで一例です。(特に、SELECT * に関しては賛否両論あると思います。) 他にもっとよいやり方があったら教えてください！ トリガーを使わない列名変更の流れ 例として、「user.meiというカラムをuser.firstnameというカラムに変更する」ケースをとりあげます。 アプリ側での事前改修 新しいDB列の追加(移行期間の始まり) アプリ側での切り替え 古いDB列の削除(移行期間の終わり) アプリ側での後片づけ アプリ側での事前改修 事前にアプリを改修して、新旧両方対応の仕組みをいれておきましょう。 このフェーズの目標は、DB列が追加されたときにアプリが自動で追従できるようになることです。 SELECT * FROM を使う アプリケーション内のSQLで、SELECT a,b,c FROM という風に列名をハードコーディングしていると、カラム名変更したいとき
レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ
みなさんこんにちわ。 メドピアでエンジニアをやっている内田と申します。 現在メドピアではPHPで作られたレガシーな独自フレームワーク (以下FW) からRailsへと移行するプロジェクトが進んでいます。 今回は移行に向けて行ったことについて共有したいと思います。 移行の計画 メドピア株式会社では、医師限定のコミュニティサイト「MedPeer 」を運営しています。 「MedPeer 」サービス内では、薬剤評価掲示版、症例相談、Forum、ニュースなど、医師同士が情報交換をするための、機能の異なる複数のサービスを提供しています。 それらサービスの内部では7年前に作られたPHPの独自FWが採用されており、コードが肥大化したことで機能の変更や追加がとても困難になっていたことが課題でした。 そうした課題を解決するために、アーキテクチャの見直しを含めたリプレースがエンジニアの主導で計画されました。 様
第2回 移行計画1：詳細設計前に決める「誰が」「いつ」「何を」
小川真示 NEC 第一OMCS事業部 事業部長 上席プロジェクトオーガナイザ，中出勝宏 NEC OMCS事業本部 統括マネージャー 移行計画が重要なことを疑う人はいないだろう。移行計画書を作成すること自体は，もはや当たり前と言ってよい。だが筆者らは，問題があると感じる移行計画書の話をよく見聞きする。 何が問題か―。それは「作るのが遅い」「記述が足りない」「精度が甘い」ということだ。 詳細設計の前には用意する ある客先では，こんな失敗談について意見を求められた。そのシステム担当者は，新システムの詳細設計が終わったところで移行計画書を作成した。データベース仕様が決まらないと，移行ツールの仕様が固まらないと考えたからだ。ところが，詳細設計が終わると開発者の大半が新システムのプログラミングに忙殺されるようになり，移行ツールの開発は後回しにされた。本番間際にようやく出来上がったものの，データを正しく
大規模データ移行の失敗を防ぎたい。計画やプログラム、インフラの注意点と、ありがちなこと - Qiita
仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
