Friday, April 28, 2017

IntelliJ IDEA - frequently used keyboard shortcuts

Ctrl+Shift+A
Find action by name.
Shift+Shift
Search everywhere.
Alt+Enter
Show the list of available intention actions .
Ctrl+Space
Invoke code completion.
Ctrl+H
Type Hierarchy
Ctrl+P
Parameter Info
Ctrl+Q
Quick Documentation
Ctrl+F
Ctrl+R
Find/replace text string in the current file.
Ctrl+Shift+F
Ctrl+Shift+R
Find/replace text in the project or in the specified directory.
Ctrl+Alt+L
Reformat Code
Ctrl+Alt+O
Optimize Imports
Ctrl+Alt+I
Auto-Indent Lines
Shift+F6 
Refactor - Rename...
Ctrl+F6 
Refactor - Change Signature...
Ctrl+Alt+V
Refactor - Extract Variable...
Ctrl+Alt+C 
Refactor - Extract Constant...
Ctrl+Alt+F 
Refactor - Extract Field...
Ctrl+Alt+P 
Refactor - Extract Parameter...
Ctrl+Alt+M 
Refactor - Extract Method...
Ctrl+Alt+N 
Refactor - Inline...
Ctrl+D
Edit - Duplicate Line or Selection
Ctrl+Y
Edit - Delete Line
Ctrl+Shift+J
Edit - Join Lines
Tab
Shift+Tab
Edit - Indent/Unindent  Selection
Ctrl+/
Code Folding - Comment/Uncomment with Line Comment
Ctrl+Shift+/
Code Folding - Comment/Uncomment with Block Comment
Ctrl+W
Ctrl+Shift+W
Selection - Extend/Shrink  Selection
Alt+Shift+Insert OR Mouse Middle Click
Selection - Column Selection Mode (multi line editing)
Alt+Insert
Insert Live Template (see more here)

Friday, March 24, 2017

Changing author and committer info in Git histroy

The script can be found on the Git official help pages.

I added the -f argument to the command to force rewrite existing backups, which would otherwise fail the script run.

#!/bin/sh

git filter-branch -f --env-filter '
OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

DO NOT REWRITE THE HISTORY OF YOUR GIT REPOSITORY IF IT WAS ALREADY PUSHED AND IS AVAILABLE FOR COLLABORATORS! 

Wednesday, January 25, 2017

IDEs for editing LESS files / Semantic UI Themes

The thing I'm searching for is:

Code Intelligence for LESS files with the following features:
  • Go to definition across files
  • Find usages across files

I started my search for an appropriate tool from the Less reference for tools.

Stuff that does that:


Stuff that does not do that:

Thursday, January 19, 2017

CSS: box-sizing: content-box vs border-box


Sources: http://www.w3schools.com/cssref/css3_pr_box-sizing.asp | https://css-tricks.com/box-sizing/ | http://www.binvisions.com/articles/box-sizing-property-difference-content-border/

Box-sizing

  • content-box
    • Default. 
    • Width or height = content's width or height. Border, padding, or margin are not included
  • border-box
    • Width or height = content + padding + border width or height. Margin is not included.
  • initial
    • Sets this property to its default value.
  • inherit
    • Inherits this property from its parent element.


Wednesday, January 18, 2017

CSS position: static, relative, absolute and fixed

Sources: W3Schools CSS Layout - The position Property | CSS Tricks Absolute, Relative, Fixed Positioning: How Do They Differ?

  • Static
    • The default. Positioned according to the normal flow of the page.
    • Not affected by the top, bottom, left, and right or z-index properties.
    • It is useful when you forcefully want to remove some other positioning that was applied to the element outside of your control.
  • Relative
    • "Relative to itself". Relative to as if it were positioned as static.
    • Affected by the top, bottom, left, right and z-index properties.
    • Other content will not be adjusted to fit into any gap left by the element.
    • Limits the scope of absolutely positioned child elements.

  • Absolute
    • Positioned relative to the nearest non-static positioned ancestor, or the body if there are no such ancestors. 
    • Affected by the top, bottom, left, right and z-index properties. 
    • Does not leave a gap in the page where it would normally have been located.
    • Does not affect the position of any other same-level element

  • Fixed
    • Positioned relative to the viewport (or window), which means it always stays in the same place even if the page is scrolled.
    • Affected by the top, bottom, left, right and z-index properties. 
    • Does not leave a gap in the page where it would normally have been located.
    • The downside of this element is the usability on different screen-sizes. It does not scroll, so if it does not fit the screen, the content is cropped and unreachable.

GIT: the difference between HEAD~1 and HEAD^1

Source: Stackoverflow --> git-rev-parse manual page

^N: Nth parent of the tip of the current branch.
~N: Nth generation first parent of the tip of the current branch.
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C = A^2  = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2
(emphasis by me)

Tuesday, January 17, 2017

Force LF line endings on Windows with GIT

The possible git settings for line endings are:

  • Checkout Windows-style, commit Unix-style
    Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF.
    Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF.
    Git will not perform any conversions when checking out or committing text files. 
    git config --global core.autocrlf true
  • Checkout as-is, commit Unix-style
    git config --global core.autocrlf input
  • Checkout as-is, commit as-is
    git config --global core.autocrlf false

Solution on Stackoverflow:

The proper way to get LF endings in Windows is to first set core.autocrlf to false:
git config --global core.autocrlf false
Now git won’t do any line ending normalization.
If you want files you check in to be normalized, do this:
Set text=auto in your .gitattributes for all files:
* text=auto
And set core.eol to lf:
git config --global core.eol lf
Now you can also switch single repos to crlf (in the working directory!) by running
git config core.eol crlf
After you have done the configuration, you might want git to normalize all the files in the repo. To do this, go to to the root of your repo and run these commands:
git rm --cached -rf .
git diff --cached --name-only -z | xargs -n 50 -0 git add -f
If you now wano also normalize the files in your working directory, run these commands:
git ls-files -z | xargs -0 rm
git checkout .

Personal opinion: 
I set core.autocrlf to input, to make sure that the repo gets LF line endings always.