martes, septiembre 05, 2017

Markdown syntax guide

Markdown syntax

The page below contains examples of Markdown syntax. For a full list of all the Markdown syntax, consult the CommonMark help or specification.


# This is an H1
## This is an H2
###### This is an H6

This is also an H1

This is also an H2


Paragraphs are separated by empty lines. Within a paragraph it's possible to have a line break,
simply press  for a new line.

For example,
like this. 

Character styles

*Italic characters* 
_Italic characters_
**bold characters**
__bold characters__
~~strikethrough text~~

Unordered list

* Item 1
* Item 2
* Item 3
  * Item 3a
  * Item 3b
  * Item 3c

Ordered list

1. Step 1
2. Step 2
3. Step 3
   1. Step 3.1
   2. Step 3.2
   3. Step 3.3

List in list

1. Step 1
2. Step 2
3. Step 3
   * Item 3a
   * Item 3b
   * Item 3c

Quotes or citations

Introducing my quote:

> Neque porro quisquam est qui 
> dolorem ipsum quia dolor sit amet, 
> consectetur, adipisci velit...

Inline code characters

Use the backtick to refer to a `function()`.
There is a literal ``backtick (`)`` here.

Code blocks

Indent every line of the block by at least 4 spaces.

This is a normal paragraph:

    This is a code block.
    With multiple lines.

Alternatively, you can use 3 backtick quote marks before and after the block, like this:

This is a code block

To add syntax highlighting to a code block, add the name of the language immediately
after the backticks: 

var oldUnload = window.onbeforeunload;
window.onbeforeunload = function() {
    if (oldUnload) {
        return oldUnload.apply(this, arguments);
Bitbucket Server uses CodeMirror to apply syntax highlighting to the rendered markdown in comments, READMEs and pull request descriptions. All the common coding languages are supported, including C, C++, Java, Scala, Python and JavaScript. See Configuring syntax highlighting for file extensions.
Within a code block, ampersands (&) and angle brackets (< and >) are automatically converted into HTML entities.

Links to external websites

This is [an example]( inline link.

[This link]( "Title") has a title attribute.

Links are also auto-detected in text:

Linking issue keys to JIRA applications

When you use JIRA application issue keys (of the default format) in comments and pull request descriptions Bitbucket Server automatically links them to the JIRA application instance.
The default JIRA application issue key format is two or more uppercase letters ([A-Z][A-Z]+), followed by a hyphen and the issue number, for example TEST-123.

Linking to pull requests

Introduced with Bitbucket Server 4.9, you can reference pull requests from comments and descriptions in other pull requests. The syntax for linking to pull request looks like this: 
To link to a pull request in the same project and repository, you only need to include the pull request ID. 
To link to a pull request in the same project but a different repository, include the repository slug before the pull request ID.
To link to a pull request in a different project and repository, include the project key and the repository slug before the pull request ID.


Inline image syntax looks like this:
![Alt text](/path/to/image.jpg)
![Alt text](/path/to/image.png "Optional title attribute")
![Alt text](/url/to/image.jpg)
For example:
![Mockup for feature A](
Reference image links look like this:
![Alt text][id]
where 'id' is the name of a previously defined image reference, using syntax similar to link references:
[id]: url/to/image.jpg "Optional title attribute"
For example:
<--collected definitions--="" image="">
[MockupA]: "Screenshot of Feature A mockup" 

![Mockup for feature A][MockupA]


| Day     | Meal    | Price |
| --------|---------|-------|
| Monday  | pasta   | $6    |
| Tuesday | chicken | $8    |

Backslash escapes

Certain characters can be escaped with a preceding backslash to preserve the literal display of a character instead of its special Markdown meaning. This applies to the following characters:
\  backslash 
`  backtick 
*  asterisk 
_  underscore 
{} curly braces 
[] square brackets 
() parentheses 
#  hash mark 
>  greater than 
+  plus sign 
-  minus sign (hyphen) 
.  dot 
!  exclamation mark

miércoles, agosto 30, 2017

Configuring VirtualHosts in XAMPP on Mac

Development locally, so one of the first applications I installed was XAMPP, a cross platform Apache/MySQL/PHP stack. While I know that MAMP is very popular on Mac, I have been using XAMPP for many years so I thought I’d stick with what I know.
Installing XAMPP was a snap, but when I came to create my own Apache VirtualHosts things started getting fiddly. Here are the steps I followed to get everything running smoothly.

What are VirtualHosts?

First, some quick background on what we’re trying to achieve.
VirtualHosts allow Apache to map a hostname to a directory on the filesystem. You can set up as many VirtualHosts as you need, so that each website operates under its own hostname. For example, you might want to map mysite.local to /Users/yourusername/mysite. To test your development site all you would need to do is plug “http://mysite.local” into your browser’s address bar.

Enable VirtualHosts

The first thing you’ll need to do is open the file /Applications/XAMPP/xamppfiles/etc/httpd.conf in your favourite text editor. Look for the following lines:
# Virtual hosts
#Include /Applications/XAMPP/etc/extra/httpd-vhosts.conf
Uncomment the second line by removing the hash (#), so that Apache loads your custom VirtualHosts configuration file:
# Virtual hosts
Include /Applications/XAMPP/etc/extra/httpd-vhosts.conf

Create your VirtualHosts

Open the file /Applications/XAMPP/xamppfiles/etc/extra/httpd-vhosts.conf. Towards the bottom of the file you will see some example VirtualHosts, which you should comment out or delete.
At the bottom of the file, add ‘localhost’ as the default named VirtualHost:
# localhost

    ServerName localhost
    DocumentRoot "/Applications/XAMPP/xamppfiles/htdocs"
        Options Indexes FollowSymLinks Includes execCGI
        AllowOverride All
        Require all granted
This step is necessary to ensure that http://localhost still points at XAMPP’s htdocs directory once we’ve created our custom VirtualHosts. Personally I don’t use the htdocs directory a lot, but occasionally it’s useful to have somewhere to perform quick tests.
Now you are ready to create your own VirtualHosts. After the default localhost that you just created, add:
# My custom host

    ServerName mysite.local
    DocumentRoot "/Users/yourusername/path/to/your/site"
        Options Indexes FollowSymLinks Includes ExecCGI
        AllowOverride All
        Require all granted
    ErrorLog "logs/mysite.local-error_log"
In the above example you should replace “mysite.local” with your own hostname. This can be anything you wish, but make sure you choose a hostname that won’t conflict with a real domain name. Using a .local extension makes it obvious that the site is hosted locally rather than on a public web server.
The path to your website can point at any folder in your OS X user directory. I store most of my sites inside of Dropbox so that I can access them on both my home and work machines. If your path includes spaces, make sure you enclose it in quotes, like in my example.

Edit your hosts file

Once you’ve saved your httpd.conf and httpd-vhosts.conf files, the next step is to edit your OS X hosts file so it knows how to handle your new ServerName. The hosts file is used by OS X to map hostnames to IP addresses. In this case we want to map your new ServerName to the IP address, which is your localhost.
Fire up a Terminal instance, and at the prompt type the following command:
sudo nano /etc/hosts
Enter your OS X password when prompted, and the hosts file will be opened in the nano text editor. You’ll see that the hosts file already contains some default hostname mappings (e.g. “ localhost”). Use your keyboard’s arrow keys to navigate to the bottom of the file and add your own mapping:
# XAMPP VirtualHost mappings mysite.local
Save the host file using the key combo control+o, and pressing return when prompted to choose the filename. Close the file using control+x.

Restart Apache

So that your changes take effect, restart Apache. This can be done using XAMPP Control, which is found at /Applications/XAMPP/XAMPP
Point your browser at http://mysite.local (or whatever ServerName you chose) and you should see your website. However, there’s a chance that instead you’ll be faced with a…

403 error

Because Apache runs as the ‘nobody’ user by default, it may not have adequate permission to browse your OS X user directory or some of its subdirectories, in which case you’ll see a 403 ‘access forbidden’ error when you try and view your development site. Similarly, you may find that although you can view your dev site, PHP throws errors when you attempt to write files or make directories on the filesystem.
To fix this you can configure Apache to run as your OS X user. Open /Applications/XAMPP/xamppfiles/etc/httpd.conf and look for the following lines:
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
User daemon
Group daemon
Change User to your OS X username, and save the file:
User yourusername
Restart Apache and you should now be able to navigate your site without any issues, including manipulating files and folders using PHP.
If you have problems viewing the XAMPP splash pages at http://localhost now that Apache is running as your user (e.g. nothing happens when you try to set the language), then you’ll need to give your user read/write privileges on the file /Applications/XAMPP/xamppfiles/htdocs/xampp/lang.tmp
Making the change I’ve described above carries certain security risks, and if you choose to run Apache as your OS X user then you’ll need to be quite certain that XAMPP is not accessible from outside your local network. From what I understand, XAMPP’s built in security features ensure that this is the case out-of-the-box, and it is straightforward to beef up security for additional piece of mind.
If you’re not convinced that it’s safe to let Apache run as your OS X user, another option is to change the permissions of your dev directories so that the ‘nobody’ or ‘_www’ user can read/write to them.I suspect that I would quickly tire of setting folder permissions, which is why I have opted to take the path of least resistance!


Hopefully this post helps someone else to get XAMPP up and running on OS X. 


martes, agosto 29, 2017

Instalar Composer Manager Php

Cómo instalar Composer globalmente

Composer es el gestor de paquetes que utilizan todas las aplicaciones PHP modernas. Por eso es muy importante saber instalarlo correctamente en tu sistema operativo.
Cuando se publicó Composer por primera vez, se recomendaba descargarlo para cada proyecto PHP ejecutando este código:
$ cd mi-proyecto/
$ curl -sS | php
Este comando descarga Composer en forma de archivo PHAR. Así que para ejecutar cualquier comando de Composer, debías utilizar lo siguiente:
$ php composer.phar ...
Aunque esta forma de instalar Composer funciona perfectamente, tiene varias desventajas importantes:
  • Debes descargar Composer para cada proyecto que crees, lo cual no es muy productivo y te hará malgastar espacio en el disco duro.
  • Como Composer se actualiza muy frecuentemente, mantenerlo actualizado en todos tus proyectos será casi imposible y te costará mucho tiempo.
Por todo ello, se recomienda instalar Composer globalmente en cada máquina, lo que permite utilizar una única instalación de Composer para gestionar todos tus proyectos PHP.

Instalación global

Sistemas Linux y Mac OS X

Abre una consola de comandos y ejecuta lo siguiente para descargar la versión más reciente de Composer y convertirla en un comando del sistema:
$ curl -sS | php
$ sudo mv composer.phar /usr/local/bin/composer
Si por alguna extraña razón no puedes ejecutar curl para descargar Composer, prueba con el siguiente comando alternativo que usa php:
$ php -r "readfile('');" | php

Sistemas Windows

Descarga el archivo Composer-Setup.exe desde el sitio web del proyecto Composer y ejecútalo como cualquier otro instalador de Windows. 

Comprobando la instalación

Independientemente del sistema operativo que utilices, debes abrir una nueva ventana de la consola de comandos para probar la instalación realizada. Una vez abierta, ejecuta lo siguiente para comprobar que Composer se ha instalado bien:
$ composer --version
Composer version 1e27ff5e22df81e3cd0cd36e5fdd4a3c5a031f4a
Como Composer se actualiza frecuentemente, en tu caso verás un identificador de versión diferente.
Ahora ya puedes ejecutar cualquier comando de Composer en cualquier proyecto de tu sistema simplemente escribiendo composer:
$ cd mi-proyecto/
$ composer install
$ composer update
$ composer create-project symfony/framework-standard-edition mi-proyecto/

Actualizando Composer

Una de las principales ventajas de la instalación global de Composer es que puedes actualizarlo para todos tus proyectos ejecutando simplemente el siguiente comando:
$ composer self-update
En sistemas Linux y Mac OS X es posible que debas ejecutar el anterior comando con sudo por delante.