Skip to content

Instantly share code, notes, and snippets.

Avatar
🎯
Focusing

Grzegorz Pawlik pawlik

🎯
Focusing
View GitHub Profile
View keybase.md

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:

View gist:8e5f99141f83d4b6086e1373d5cf563a

: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:

View hoarecolouring.md
1 | { true }
2 | a := 1
3 | { a = 1 } % comment to clarify your thoughs
@pawlik
pawlik / switch_between_last_git_branches.sh
Created Jul 25, 2018
This allows you to switch between latest git branches
View switch_between_last_git_branches.sh
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)
View update-favicon-on-gh-check.js
(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() {
@pawlik
pawlik / Guardfile
Last active Oct 3, 2016
Run related specs whenever you touch shared_example file
View Guardfile
# 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
@pawlik
pawlik / gist:e1b15aa10f8da3bdb5c3
Last active Dec 8, 2015
Proposal: include additional step to our release action plan: "composer update"
View gist:e1b15aa10f8da3bdb5c3
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)
@pawlik
pawlik / gist:48cc4afba9d1523d4858
Last active Aug 29, 2015
Migration solution - PAIN to write, but compatibile by default
View gist:48cc4afba9d1523d4858

"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
@pawlik
pawlik / git-cache.sh
Created Apr 8, 2015
When full clone is too long - make a cache. You can run it with `watch -n 1 ./git-cache.sh git@github.com:Username/RepoName`, it will create cached version on /tmp/git-cache/git@github.com:Username/Reponame so you can clone new repos from there. Good when you make many clones and it's slow. Add apriopriate remotes when needed.
View git-cache.sh
cache_dir="/tmp/git-cache/"
if [ ! -d "$cache_dir" ]
then
mkdir -p $cache_dir
fi
cache_path=$cache_dir$1
if [ ! -d "$cache_path" ]
then
git clone --mirror $1 $cache_path
else
View delegator.md