g-pavlik

Keybase proof

I hereby claim:

• I am g-pavlik on github.
• I am gpawlik (https://keybase.io/gpawlik) on keybase.
• I have a public key ASC4EIgGqLjcl8aWQ5fI9lb6uL42wiS9-2KNexhZ9cZMzwo

To claim this, I am signing this object:

g-pavlik

Export your public key:

keybase pgp export > keybase-public.key

Export your private key:

keybase pgp export --secret > keybase-private.key

g-pavlik

Keybase proof

I hereby claim:

• I am pawlik on github.
• I am gpawlik (https://keybase.io/gpawlik) on keybase.
• I have a public key ASCFa9P50-3UR37Lr2BLvdPPkMxY6TW8cwPvyq8jLghSOwo

To claim this, I am signing this object:

g-pavlik

:medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal: :medal::medal::medal::medal::medal::medal::medal::medal::medal:

g-pavlik

1 | { true }
2 | a := 1
3 | { a = 1 } % comment to clarify your thoughs

g-pavlik

alias gsb="select option in `git branch --sort=-committerdate | head -n $(( $LINES / 2 )) | grep -v '*'`; do git checkout $option; break ;done"

# --sort=-committerdate # sorts branches by commit dates (use --sort=-committerdate for opposite direction)
# $(( $LINES / 2 )) # use half of your terminal height (I like to have some context preserved). 
                    # use -n 100000000 to use all terminal space (select will reduce the number of options for you)
                    
# grep -v '*' - exclude the current branch, if you remove this you have to accomodate the '*' char in $option
# break - remove this if you want to switch, and the immediatelly be given option to switch again :D (just a joke, it's useless without it)

g-pavlik

(function() {
    // Updates GitHub favicon on pull request pages depending on it's check's status
    // if the last checked status was 'pending' 
    //    it will refresh every 5 minutes if you leave the tab
    //    and will refresh once more when you re-enter it
    // if the status was 'success' or 'failure' - it will just update the favicon
    is_pending = function() { return !!document.querySelector('.donut-chart>.pending'); };
    is_failure = function() { return !!document.querySelector('.donut-chart>.failure'); };

    update_favicon = function() {

g-pavlik

  # run specs using shared examples after touching shared example itself
  watch(%r'spec/support/shared_examples/.*\.rb') do |m|
    m.each_with_object([]) do |m, files|

      defline = `grep shared_example.*$ #{m}`
      shared_example_name = %r[shared_examples ["':](.*)["'] do].match(defline)[1]
      new_files =
        `grep -r #{shared_example_name} spec/ --include="*_spec.rb" | grep -E "spec/.*_spec\.rb" -o`.split("\n")
      files.concat(new_files)
    end

g-pavlik

I would suggest to after step: 
"Move incremental configs" 
to add step: 
"run composer update" and push to master.

Arguments: 
- composer update is fairly safe since we moved to explicit versions
- doing so will give us 2 weeks evaluation before next release 
(both when developing and when PO evaluates new release candidate)

g-pavlik

"Write safe migrations" approach.

This is what I've mentioned on our call. Let me prove this could work and please prove me wrong or point weak spots.

Assumptions

• We can agree on how many steps we want to be able to rollback to (capistrano supports it, now on webstore is 2. I think increasing this too much makes no sense. Personally I think 2 is perfect - can't imagine that we release 1.19, after two weekes we release 1.20, after another 2 weeks 1.21 and at this point PO decides we want to rollback to version from a month ago).
• don't think that database migrations is about just database migrations - it's also about writing code in a way it can handle this migrations.
• future actions can be easily managed with something similar to roadsigns. For migrations, in case you need column to be removed in some unspecified future you can leave file CHECK_THIS_BEFORE_MAKING_NEW_MIGRATION, with entry 2015-01-12 prepared for column foo removal. Please remove after at least 5 releases (see first assumpti