はてなブックマーク

TL;DR 2017-07-20 から、bundle gem my-awesome-gem の生成物で、Gemfile.lockをgit ignoreしなくなった。 Stop gitignoring Gemfile.lock in default template #5822 なんでgit ignoreしていたのか、なぜするべきなのか、どうしてしなくなったのか、あたりを整理する。 なおわたしはignoreしているほうがいいとおもってる。 きっかけ わたしがこう反応したら、 そりゃgemの開発者は無いと困るけどさ 利用者のが圧倒的に多いじゃん 理解できねー こういう反応を複数もらったので。 あれ、利用者がgemfile.lockあってなんか困ります？ 直接それが原因では困らないが、実質困るケースが増えると思う。 環境 $ ruby -v ruby 2.5.1p57 (2018-03-29 r

論理削除はコロセ派なので、いいんだけど、ぼんやり思っていることを書く。特に結論はない。 以下の話を自分で思いつくわけはないので、だいたいどこかの本やエントリーからのコピペや切り貼りです。 参照 論理削除が云々について – mike-neckのブログ Kazuho’s Weblog: 論理削除はなぜ「筋が悪い」か ただ、immutableなマスタ、更新ログと「現時点のビュー」の３テーブルを準備・運用するというのはそれなりにコストがかかるので、筋が悪い「削除フラグ」（より一般化すれば状態フラグ）を使うかどうかはケースバイケースで判断するのもひとつの見識である。 “CRUDのUとDは要らない” 何周も回ってる話に自転車置き場。 さて。論理削除は正しいデータモデリングすべきだよね。まではわかる。 deleteすべきものは正しくdeleteすべし。必要ならaudit log（監査ログ・操作履歴）を取

Cron for GitHub gem作った。 TL;DR 場所はどこでもいいけど、たとえばHerokuから、定期的にブランチを切ることで、webhookを起動させて、GitHubエコシステムを強制起動するコマンド及びgem。 使い方 毎日とか毎週とかHeroku Schedulerから定期実行出来る。Heroku Schedulerは10min/1hour/1day しか選べないが、例えばスクリプト側で、起動されたうちの月曜日の場合は、とか書けばいい。Githubが割とローレベルのapiを提供してくれているので、branch作ったりbranch消したりしてるのにgit clone不要。さくさく快適すぎる。 gemの機能は正確にはcreate branch for github, clear branches for github で、cronにするかどうかは、このgemの外側でどうつかう

CircleCIをpublic reposに使うときに気をつけること TL;DR CircleCIをpublic reposに使うときは、気をつけて使う必要がある。秘匿情報を入れてる時は、fork reposからのpull requestをbuildしてはいけない(CircleCIデフォルト設定)。 経緯 CircleCIでfork reposからのpull requestが来ない。 Tachikoma.io を使ってみた – えいのうにっき circle ciでpublicで同じように使えてる、気がしてたけどprivateとは条件がよく考えると違ったり、travis-ciと全く同じようにはいかない、部分があった。 で、普通に考えるとcircleci的には危ない機能なので設定は安全に倒してあった。 注意 悪意のあるpull requestがたとえばrake testに puts YOUR_

herokuのrails4でasset precompileでabortしたら enable user-env-compile herokuのrails3.xでassets precompileがこけるのは設定して回避するのが(自前でprecompileしてからpushするよりは)定番だった。 config.assets.initialize_on_precompile = false https://devcenter.heroku.com/articles/rails-asset-pipeline rails4.1でも同じくassets precompileで落ちるんだけど、別の原因らしい? —–> Preparing app for Rails asset pipeline Running: rake assets:precompile WARNING: Nokogiri was b

バージョンアップで一番痛みが少ないのは、毎日bundle updateをすること。最新と、現在のバージョンのスナップショット以外で、動くバージョンの組み合わせを見つけるのは不毛。毎日のbundle updateを支援するbotを作ってます。 Edited: 2014-10-01 10:25, Tachikoma.io出来ました!! webアプリです〜 githubのpublicなリポジトリはぼくが手で登録して、回すのでご連絡下さい。また、自前で設置する導入コンサルもやりますので、こちらもご連絡下さい。 http://tachikoma.launchrock.com/ 差分( from CLOUDBEES で BUNDLE UPDATE した上でPULL REQUEST させる) 正しく設定のyamlを読むようにした – アプリの下で複数プロジェクト置いて、bundle in bundleし

恵比寿のEngine Yardさまのオフィスをお借りして、Sikachu Meetup #1やってきた。 ホスト側なのは多分初めてな気がする。司会まね事したのも初めてじゃないかな。「味をしめたので次もやりたいですねー(来年)」って話を帰り道 @junya としてたら「github/heroku/wycatz/aaron級の人・会社ではなくてthoughtbotだったのがよかったかもしれないですね ヨーロッパからの人、soundcloudの人とか来てないのかなあ 来てる人や会社にフォーカス当てて歓迎するのいいですね 明日はどうですか」って言われてヒーってなった。でもそれもいいですね。 時系列順に書いてみる 2012 April Railsconf junya と mochiz がワイワイ言いながら sikachu と写真とってるのは見た記憶がある。その時なんでワイワイしてるかの伏線は知らなか

刺身さんのセッションが良かった。ブログのエントリを見て会社でいいねーってなって定期ビルドするjobを作るところまではkei-sがやりかけてたんだけどpull requestを作るところまで行かなかったから結局続いてない。最後の一手間だけでぜんぜん違うもんだなあ。 セッション中に感想半分質問半分なのをつぶやいてたら良い心がけいただいた @sanemat 戦うRubyistこと @hsbt の導きにより「バージョン固定は出来る限りしない、基本ぜんぶ latest で、困るやつだけ指定」というポリシーでした（だから毎日のように何かしらあがる）あと跳ねた奴はかなり注意して dif 見ざるを得ない — Kensuke Nagae (@kyanny) May 31, 2013 githubのbot作れると色々捗る気がする github drinkupで刺身banyanと話してて目からうろこだったのは、

ひろみつ先生ロックオンの中で数少ない倒せなかった強敵がかんたんログイン。結局スマートフォン移行でうやむやになったのと、いやうやむやにしていいのかよ、、そして結局無くならなかった。ユーザーやプロデューサーに変な常識が刷り込まれちゃって、セキュリティよりユーザ体験みたいな、のがお客様は神様で素敵に使われて、いやそれはどう考えてもありえないだろというか赤信号みんなでわたってるから端の方は死んでも問題ない的な。もちろん説得しきれないエンジニアが全面的に悪いのは前提ね。 あと使い方によってはそれ以上に地雷のoensocialなんとかidが懐かしい響き。

git-svnを使ったときのコミット手順について自分用にまとめた コミットログに必要な情報を書きたい。 gitの使い方は割愛 git-svnの使い方は以下のまとめを読んだ git-svnの使い方を覚えた – idesaku blog git svnとgitを併用する方法のメモ – Hello, world! – s21g $ git commit -v 修正完了 自分のいるブランチを確認 $ git branch master * test_commit $ git checkout master masterにいることを確認 $ git branch * master test_commit $ git svn rebase (svn update相当) $ git merge –no-ff –no-commit [ブランチ名] マージはされるが commit が作成されないので $ g

default roleはあんまりつけたくないので aws configure listでなにもでてこないのがよい browserからswitch roleできることは確認しておく switch roleにVPNが必要で、VPN接続忘れてエラーが出た(1敗) switch roleにmfaが必要で、mfa設定してなくてエラーが出た(1敗) mfa設定後に再ログインしていなかったのでエラーが出た(1敗) access key, secret access keyはiamの画面から取る https://us-east-1.console.aws.amazon.com/iamv2/home?region=ap-northeast-1#/security_credentials?section=IAM_credentials create access key $ aws configure --