jipiboily

21 ms·

61.
by jipiboily 12y ago
JP, author of the post here - let me know if you have any additions / questions!
62.
Fourchette: test your GitHub pull requests against a fork of your Heroku app(github.com)
1 points by jipiboily 12y ago|0 comments
63.
by jipiboily 12y ago
That would explain why it's getting on HN today...for the nth time :)
64.
by jipiboily 12y ago
Everytime I see one of those, I want to love them. Then I remember how hard it is for those tools to keep up with the OS features. Not being able to add or fix stuff because a new OS version is out and the tool is not up to date (yet) is a
65.
by jipiboily 12y ago
Two things here: - the +1s show some level of interest, but enough to dive in the code, so it's half interesting, and half useless - also, once you've reached a certain number of +1s....well, it's just noise and annoying. 50
66.
by jipiboily 12y ago
Finally, no more :+1:s when it's all that is being said by everyone, without much discussions...yay to less noise!
67.
by jipiboily 12y ago
Flynn raised money, so I guess it could be considered as making money, too? :)
68.
by jipiboily 12y ago
How does it compare to another PaaS in Ruby: https://github.com/tombh/peas ? Just curious :)
69.
by jipiboily 12y ago
We use Fourchette ( https://github.com/jipiboily/fourchette ), which means we have a Heroku fork of our QA env for each GitHub PR. Also, once something is on develop/staging, it is about to be shipped. If there is a
70.
by jipiboily 12y ago
Commits with unrelated changes should be multiple commits.
71.
by jipiboily 12y ago
For #1, we use Fourchette ( https://github.com/jipiboily/fourchette ), which means we have a Heroku fork of our QA env for each GitHub PR. For merges to master, we submit other pull requests that we call "Release: .
72.
by jipiboily 12y ago
Just an FYI, with this model, we still do multiple deploys each and every day :) There might be a point where this won't work for us anymore, it's always time to change. Also, this is not because a branching model works for a team
73.
by jipiboily 12y ago
Good point! Force push should be avoided at all cost on origin. I think mercurial now has that as a feature!!! Also, I prefer merge over rebase.
74.
by jipiboily 12y ago
We don't squash and we just use plain merges. It gives the real version of what happened. This is what I personally prefer.
75.
by jipiboily 12y ago
Yes, totally! We picked some examples quickly just to demonstrate that people can do better "lol", "fix" or "meh". There is still room for improvements and we have better ones, too.
76.
by jipiboily 12y ago
I agree it useful, but it's more useful overtime than anything, on the short term, issue numbers are not really useful. You are right, those examples were not our best ones ;)
77.
by jipiboily 12y ago
It might feel similar, but they don't take care of the testing itself which is a major pain point. My 2 cents :)
78.
by jipiboily 12y ago
Source for that?
79.
by jipiboily 13y ago
You could always pivot to a chat for people from New Zealand with that name :)
80.
by jipiboily 13y ago
Come join us, we do do awesome and fun stuff! :)
81.
Introducing early version of Fourchette: test PR against a fork of a Heroku app(jipiboily.com)
1 points by jipiboily 13y ago|0 comments
82.
Hey Rubygems, do not include your stuff implicitly (and don't class_eval Class)(jipiboily.com)
2 points by jipiboily 13y ago|0 comments
83.
by jipiboily 13y ago
What? Another service I start to use and shutdowns just a few days later...sad! That's a problem with free services, and sometimes even with some paid services.