MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳
このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ！とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi
Howだけ考えると複雑さを導入して仕事が増える - そーだいなるらくがき帳
昨日、リモート雑談会の中で id:katzchang がめっちゃ良いことを言ってたので自分のためにも、みんなのためにもここに残す。 結論 作業を増やすことに敏感な人は少ない。 仕事と作業を同じと捉えていて、作業をすると仕事の進捗があると感じてしまう麻薬みたいなのはある。 それによって複雑さを導入して仕事、作業を増やす。 本当に必要なの作業を減らしてビジネスを前に進めることに注力する。 それが仕事をするってことだよな。— そーだい@初代ALF (@soudai1025) August 13, 2020 ちゃんとWhyを意識して、問題の本質を理解し、解決することで、不要な作業を減らし、仕事を減らしていくことがITを活用する上で肝要である。 仕事を増やさない これは本当に大事。 例えばリリース手順書を作りました！ってなると作業の内容が変更になるたびに手順書のメンテナンスをしなければいけない。 そ
CTOを始めて一年経ったので振り返る - そーだいなるらくがき帳
前回から更に半年経ったので振り返る。 soudai.hatenablog.com 前提 今は株式会社 オミカレって会社でCTOをしてる。 オミカレは婚活パーティーのポータルサイトで、男女問わず、幅広い年齢をカバーした婚活パーティーを取り扱っている。 party-calendar.net もうサイトとしては8年目で息の長いサービスとなっており、レガシィなところも目立ってきた。 それを払拭するためにチーム、サービス、ビジネスの3本柱をメンテナンスしてるフェーズ。 この半年は前回のまとめに書いた通り、大きな目標が2つあった。 自立型のチームとして確立する 売上をしっかり伸ばす それを踏まえて、振り返りをしていく。 10月 スマホアプリがリリースされた。 春からずっとここに標準を合わせて、アプリケーションの設計やらプロジェクト管理やらAPI作成やらしてたので無事出たことに驚きと共に、そんなに大きな
文系でもプログラマになれるのか - そーだいなるらくがき帳
ブログについたコメントに対する自分なりの考えを書く。 soudai.hatenablog.com 私は文系の大学生ですが、プログラミング興味を持ちプログラマになりたいと考えています。 とても難しい事は理解していますが、プログラマに就職するのは やはり難しいでしょうか？ もし可能性があるとしたら、就職先の探しかたや見分け方などの ことを教えてください？ お願いします。 文系でもプログラマを始めとするソフトウェアエンジニアになれるか？の答えは なれる。 例えば自分の周りでも id:daiksy さんとか @shinpei0213 さんは文系出身のソフトウェアエンジニアだしプログラミングしている。 もっと言えば自分自身、高卒エンジニアなので学歴がネックでプログラマになれないということは無い。 だがソフトウェアサイエンスをしっかりと学んだ人からするとスタートラインは後ろである、という事実はあるし、
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
