ダウンロード時にメールアドレス登録＆氏名登録が必要です。メール認証をしないと登録コード（無料）がもらえないので、ちゃんと送受信できるメールアドレスで登録が必要です。（下画像はChromeブラウザーのページ翻訳機能で日本語にしています。） メールアドレスを登録して無料コードを入手できます日本語化2021/01/24追記：現行バージョンのインストーラーでは、インストール時に日本語が選べる（選ばれる？）ようです。 バージョン8から公式に日本語メニューに対応しています。インストール後は英語メニューがデフォルトです。メニューバーから、 Other Tasks ⇒ Edit Defaults and Settings… を選びます。 設定を開くAdvanced Settings ⇒ Language ⇒ Japanese を選びます。 LanguageをJapaneseにしますクローン手順 DELL
質問 2010年7月16日金曜日 5:16 お世話になります。 色々とドキュメントを確認したりネットを検索したりはしてみましたが、どうにも理解できなかったので質問させてください。 w2k8R2standardサーバでHyper-V2.0を設定、その仮想環境でVirtual Keyを使用してw2k8サーバを構築します。 物理サーバに障害があった場合、仮想サーバのデータを別の仮想環境にもっていけばいいと考えています。 なお、SANディスク等の共有ボリュームは使用しません。 質問１. 例えばエクスポートしたデータを利用する場合、別のサーバでインポートした際のライセンス処理はどの様に行われるのでしょうか？（移行先のVirtual Keyには余裕があるものとします） 起動した際に新しいライセンスの入力を求められるのでしょうか？ 質問２. エクスポートデータ全てではなく、VHDファイルだけがある場合、
CentOS 8 が 2021-12-31 でサポート終了 となります。 従来 2029年までとされていたのですが、期間が大きく短縮されました。 主な更新 2021-06-28 Rocky Linux がリリースされました。 2021-04-07 CloudLinux から AlmaLinux がリリースされました。 2021-01-04 Rocky Linux のリリース予定(2021 Q2)について追記しました。 2020-12-21 CloudLinux, Project Lenix のリリース予定(2021 Q1)について追記しました。 本記事の概要 3行 CentOS 8 は 2021-12-31 でサポート終了です。 移行先として推奨される CentOS Stream はアップストリーム(本家 RHEL より先にバージョンがあがる)で更新されるため、RHEL とのバージョン互換
Gitlabを立てているサーバのHDD残容量がかなり少なくなったため、前々からやろうと思っていたけどできていなかった、Docker上への引っ越しをようやく実施しました。 Docker上で構築しておくと、アップグレードも簡単というメリットがあります。今回、移行後についでに7.0.0⇒7.6.2へとアップグレードも行いましたけどかなり楽でした。 以下、移行手順のメモです。 移行先Gitlabの構築 移行先となるGitlab本体は再構築する必要がありますが、Docker上に構築するのでDocker Hubにあるものを利用して簡単に構築できます。今回は一番利用されていそうなsameersbn/gitlabを使用させて頂きました。 データベースにはMySQLを使っていたので、移行後もMySQLを使うことにしました。このMySQLも今回、Docker上に移行します。 なお、MySQLやGitリポジトリ
This page is a translated version of the page Manual:Backing up a wiki and the translation is 45% complete. It is important to make regular backups of your wiki (data and files). This page provides an overview of the backup process for a typical MediaWiki wiki; you will probably want to devise your own backup scripts or schedule to suit the size of your wiki and your individual needs.
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
エムスリーでは Tech Talk という技術勉強会をほぼ隔週で行っているのですが、今日は記念すべき 50 回目ということで飲み会がありました。少しだけ飲み過ぎて遅くなってしまったのですが、エムスリーアドベントカレンダー 12/21（月）の記事がこちらになります。 私は日頃趣味では JavaScript 関連を触っていることが多いのですが、業務ではフロントエンドに加えて、Rails を使ってデータの整合性が何よりも大事な業務系のシステムを書いています。このようなシステムを開発する中で、Rails の Migration、特にスキーマ変更に付随するデータ変更について学んだことをいくつか書いてみようと思います。 バックアップ 何はなくとも、本番環境で Migration を実行する前にバックアップを取りましょう。当たり前のことですが、大事なことなので二度言います。バックアップを取りましょう。
注意: データベースマイグレーション機能はバージョン 1.1.6 以降で利用可能です。 データベース駆動型のアプリケーションを開発し保守していると、ソースコードと同じように、データベースの構造も徐々に進化していきます。 例えば、開発中に、新しいテーブルを追加したくなることがあります。 またアプリケーションが運用段階に入った後で、あるカラムにインデックスを追加する必要があることに気付くかも知れません。 このような構造的なデータベース変更 (マイグレーションと呼びます) の経過を記録することは、ソースコードの変更を記録するのと同じように、非常に重要なことです。 ソースコードとデータベースの同期が崩れた場合には、全体のシステムが壊れる可能性が非常に大きいのです。 こういう理由から、Yii はデータベースマイグレーションツールを提供して、データベースマイグレーションの履歴を管理し、新しいマイグレー
DB移行の7つのステップ
データベース移行ではどのような作業を行わないといけないのか？全体的な流れを俯瞰的に見なければ、作業の見積もりなどが難しいことだろう。というわけで、今日はデータベース移行時に必要になる作業について7つのステップに分けて紹介しようと思う。言うまでもないことであるが、移行時には既存システムを直接いじるわけではない。（稼働中のシステムを直接いじるのは、走ってるクルマに乗り込むのと同じぐらい危険な行為である！！）開発用のシステムを別途用意して作業を進めるという前提で読んで欲しい。 1. データベース構築まずは何はともあれ新規データベースを構築することである。MySQLであれば典型的な構成にしておけばそれなりに高速に動作するので、細かいチューニングは後で問題が出てからやれば良い。my.cnfはインストールディレクトリの下のsupport-filesディレクトリにあるものを弄ってもいいし、MySQL P
先日開催された関西Ruby会議05に参加された方お疲れ様でした。色々な方とお話出来て非常に楽しい1日でした。 さて、「No Sugar 〜私はどのようにしてRails開発に貢献したか〜」という発表をされた @kennyj_jp さんから懇親会で面白い話を聞くことができました。 schema.rbでスキーマ情報を管理するのは限界があるのではないか？ 先日私がリリースしたpg_index_where について失礼ながら意見を聞いてみました。ポイントはスキーマ情報をdumpする処理について現在の実装方法で正しいのかという点。 そもそもユニークインデックスにwhereを付けるようなRDB固有の命令については、Rails標準のschema.rbで管理し続けるのは限界があるのではないかというお話でした。 Railsの設定でdump方法を変更できる 次のようにapplication.rbの一部をコメント
今まで MySQL のカラムにコメントを付ける習慣がなかったんだけど，いざ新メンバーとして既存コードを読んで理解する立場になってみると，ちゃんと書かれたコメントのおかげでスキーマを理解しやすかったし，メンバー間の認識相違も生まれないし，重要だなと実感している． 確かに「コメントを付けないと理解できないならきっとテーブル設計やカラム設計に欠陥があるのでは？」という意見もあると思うし，それは否定しないけど，キレイに設計したとしても，ドメイン依存したコードやマジックナンバーもあるわけで，コメントを付けることが大きなメリットを生む場面は絶対にある． Rails で試してみる 今はもう Rails を使ってないんだけど，Rails で MySQL のカラムにコメントって付けられるの？と思って調べてみたら，基本機能ではできなさそうだった． migration_comments Gem を使う migr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
