Setting up easy SSH connection.

We'll need to generate a key in order to access our server easily from our home machine.
To generate a key, enter the following on your client PC(probably the PC you're working on)

ssh-keygen -t rsa

You will be prompted to enter a filename of the key generated. It's not necessary, but should you decide to enter one, make sure to enter the full path of where you would like the file to be saved.

Enter file in which to save the key (/home/demo/.ssh/id_rsa):

Next, you will be asked if you want to enter a passphrase. This is great if you'd like to add some security client-side so that anyone using your machine can't just gain access to the remote server.
You will be prompted twice for the password:


Enter passphrase (empty for no passphrase):


This is what you'll see after completing the ssh-keygen operation:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |
+-----------------+

Our next step is to copy the key to the remote server. Lucky for us there's an easy command to achieve this:


ssh-copy-id root@789.123.45.67

Enter the remote username and the remote IP as above.

You will be prompted for the password of the remote server. Enter it and the key will be copied over.

Once done, test if it all worked out by doing an SSH to the server and seeing if it logs you in automatically:

ssh root@89.123.45.67



Well done, so far so good. Now let's make things a little easier by adding an alias to the ssh command, that way we won't have to remember every server's IP address.

sudo vim ~/.bashrc

Ofcourse this assumes you use bash, I use zsh for example and had to edit my ~/.zsh file instead.

Once your file is open, enter the following on a new line:
alias myaliascommand="ssh root@89.123.45.67"

Press escape and run: :wq  to save the file and exit.

Your bash aliases will be available on the next new terminal you open, but if you're like me, you don't like closing and opening terminals for no reason, simply run:
$ source ~/.bashrc

..and this will refresh the .bashrc resource in your bash.

Now test by typing myaliascommand and see how it connects to the server with a single command!

I hope this saves you tons of time, bye now!

Some trickyness when setting up git

Tell git to remember your passwords forever with:
git config --global credential.helper store

Set your upstream forever with:
git config --global push.default current

Make git remove the annoying .orig files after merging:
git config --global mergetool.keepBackup false

Bonus commands:

Make git forget about a file that's already tracked:You've been tracking a file and realised it's not a good idea, so you added the file to the .gitignore, but git still wants to commit the changes you made to it, what do you do?

Make git forget about that file:

git rm --cached

Wordpress and AJAX headaches for days

I just spent over 3 hours wondering why my ajax function only returns 0, yet when I use the exact same function in PHP elsewhere, it returns the correct value.

Turns out, all ajax functions must exit, otherwise the wordpress engine will take over and do other evil things, ending up in world domination and the destruction of mankind!

So remember, echo and exit, or your life will be hell!

add_action( 'wp_ajax_my_function', 'my_function' );

function my_function() {
    echo 'response';
    exit;
}

Gulp Debugging

I recently ran into a problem where Gulp wouldn't give me the line where a parse error had occurred.
The problem was in the uglify dependency.
To solve it, after much googling, I did the following:

Add this to the beginning of the gulpfile.js:

process.on('uncaughtException', function(error) {
    console.log(error);
    process.exit(1)
});

...and then in the guilty task, make sure the uglify function is called first(so that you don't lose line numbers or other data with minify):

var jsTasks = function(filename) {
return lazypipe()
                .pipe(uglify, { // THIS HAS BEEN MOVED UP compress: { 'drop_debugger': enabled.stripJSDebug } }) .pipe(function() {
return gulpif(enabled.maps, sourcemaps.init());
})
.pipe(concat, filename)
.pipe(function() {
return gulpif(enabled.rev, rev());
})
.pipe(function() {
return gulpif(enabled.maps, sourcemaps.write('.', {
sourceRoot: 'assets/scripts/'
}));
})();
};

Vagrant troubles

I think I just found a solution for speeding up vagrant significantly on windows machines
(yes, Windows machines):

In your Vagrantfile, add the "nfs: true" at the end of your synced folder config:(just do it)
config.vm.synced_folder 'www', '/var/www', nfs: true

then do:
vagrant plugin install vagrant-winnfsd

and finally:
vagrant reload

Vagrant runs at least 5 times as fast as it used to.

NOTE: make sure you disable sendfile in the NGINX config, so add :
sendfile  off;
inside the http {} tags

If this isn't done, vagrant will cache everything, and never clear the cache. None of your changes will reflect.

NOTE2:
this might help(not my own work, will replace later, ref: http://laravel.io/forum/09-25-2014-caching-in-homestead-with-nfs-despite-sendfile-being-off):

• I was having the same problem and it turned out to be because of 2 things:
  • 1) opcache.revalidate_freq
  • 2) The guest machine's date needed to be behind the host
  To fix it, first find the location of opcache.so:

  $ sudo find / -name 'opcache.so'
  /usr/lib/php5/20131226/opcache.so`
  

  Add that location to opcache.ini and ensure the file has revalidate_freq set to 0 (I use nano, but you can use vim or whatever editor you want):

  $ sudo nano /etc/php5/mods-available/opcache.ini
  
  zend_extension=/usr/lib/php5/20131226/opcache.so
  opcache.memory_consumption=128
  opcache.interned_strings_buffer=8
  opcache.max_accelerated_files=4000
  opcache.revalidate_freq=0
  opcache.validate_timestamps=on
  opcache.fast_shutdown=1
  

  And to fix the date issue:
  Update the timezone:

  $ sudo dpkg-reconfigure tzdata
  

  Update the time so it's older than the host OS. For example, if your Host OS is at 11:02:15, then set your VM to:

  $ sudo date --set 11:01:00
  $ sudo service nginx restart
  

  You'll need to reset the date each time you vagrant up the box, but this finally fixed the problems for me.
  Note: Don't forget to update /etc/nginx/nginx.conf to have sendfile off;
  Note: And don't run your dev site on HHVM when developing (use the serve.sh script to turn your site off of HHVM if it was setup that way):

   $ cd /etc/nginx/sites-enabled
   $ sudo rm your-hhvm-site.app
  
   $ cd /etc/nginx/sites-available
   $ sudo rm your-hhvm-site.app
  
   $ sudo service nginx restart
  
   $ cd /vagrant/scripts
   $ sudo sh serve.sh your-site.app /home/vagrant/whatever/laravel/public 80
   $ sudo service nginx restart
  

  (use serve-hhvm.sh script with the same directions above to turn your site back on to HHVM later if you want)
  Note: Also for local/dev environments, you can update your .env file to cache using array like so:

   APP_ENV=local
   APP_DEBUG=true
   ...
   CACHE_DRIVER=array
   SESSION_DRIVER=array
   ...
  

  In Laravel, you can run php artisan clear-compiled (the opposite of optimize) to clear vendor/compiled.php and other things.