ERDをPlantUML形式で自動生成するツールを作った - くりにっき
PlantUML + ERDでPlantERDです github.com モチベーション PlantERDの特徴 使い方 出力するテーブル数の制限について 技術的に頑張ったこと テストのこと Foreign keyで隣接している別のテーブルを探す方法 複数DB対応のつらみ 追記：2019/12/13 9:45 モチベーション 既存プロダクトへの不満が一番大きいです。 https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい そもそもRails前提なので他言語とかでは使えない https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する 僕は初め
git-updateがクソ便利 - くりにっき
git-sync にインスパイヤされて作りました qiita.com ソースコード gist.github.com モチベーション 例えばトピックブランチで作業してて、リポジトリのmasterが更新されたから最新のmasterを取り込んでrebaseするってことよくやると思うのですが、その時にいちいち git checkout master git pull --ff git checkout topic_branch git rebase master みたいなことをやるのが大変なのでサブコマンドにしました。 *1 3ヶ月くらい使ってるけど割と開発が捗ってます。 ~/.gitconfig のaliasにも up = update で登録してるので、1時間に1回くらいは g up 叩いてるんじゃないかなｗ https://github.com/sue445/dotfiles/blob/65
reveal.js + markdownでスライドを作る時は reveal-ck が便利だった - くりにっき
前置き 最近スライドを作る時は reveal.js を使ってmarkdownベースでスライドを作ることが多いです。 サンプル スライド：http://sue445.github.io/omotesandorb-04/ リポジトリ： https://github.com/sue445/omotesandorb-04 markdownでスライドを作れるのは便利なのですが、効率よくスライドを作ろうとすると毎回下記のようなハックが必要でした markdownはhtml中に埋め込む必要があるのでmarkdownのシンタックスハイライトが効かないのが不便。そのためmarkdownだけを別ファイルにしてhtmlに埋め込むrakeタスクを作成 https://github.com/sue445/omotesandorb-04/blob/gh-pages/Rakefile htmlを確認するのに毎回手動でr
JenkinsとGroovyで低レベルなトラブルシューティングをする - くりにっき
昨日会社でJenkins立てた時に .ssh/config が読めなくてハマってました。 読めなかった原因というのはJenkinsを動かしてるtomcat7ユーザのホームディレクトリ*1とJenkinsが見ているホームディレクトリ*2 が食い違ってたためなのですが、そこに至るまでの原因調査で非常に低レベルなトラブルシューティングをしてたので備忘録として残しておきます。 低レベルなトラブルシューティングとは？ ここでは「Jenkinsがシェルコマンドを叩いた時にどう実行できるか」を調べることを低レベルなトラブルシューティングとしてます。 Jenkinsをインストールしてるサーバにsshで入れれば sudo -u tomcat7 〜 でやるのが模範解答なのですが、今回は権限の関係でtomcat7ユーザになれなかったためJenkinsにシェルコマンドを実行してもらうことにしました どうやって？
Githubエコシステムを活用したイマドキの趣味開発 - くりにっき
社内でLTする機会があったので資料を公開します Githubエコシステムを活用したイマドキの趣味開発 from Go Sueyoshi (a.k.a sue445) バックグラウンド 実はこれは先日同僚がRubyKaigi2014で発表した "Gem of this Week" - building culture and making gem のカウンターエントリだったり、補足だったり、そんな感じです。 登壇者のエントリ: RubyKaigi2014で発表した - mitaku.log 残念ながら社内版のcodeclimateやcoverallsに相当するものはないので、業務ロジックや社内のコンテキストが絡まないところに関してはgithubで公開してしまった方がいろいろなエコシステムを活用できると思ってます。 社外に出すとなると 英語でコメント書く issueやPRで英語やり取りが発生す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
