- rawgithub.com - Content-Type aware proxy
- gist.io - gist publisher
- GistDeck - gist slideshow
- prose.io - web-based interface for managing text-based content
- documentup.com - README publisher
As always I did a half-arsed read of the instructions, just forked the github repository then made a lokal clone.
Ξ /srv/http → git clone [email protected]:greenwellness/spree.git
Cloning into 'spree'...
Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts.
remote: Reusing existing pack: 157334, done.
<?xml version="1.0" encoding="UTF-8"?> | |
<layout> | |
<!-- ############# GLOBAL LAYOUT UPDATES ############# --> | |
<default> | |
<!-- Remove unwanted blocks entirely | |
<remove name="right.poll"/> | |
<remove name="right.permanent.callout"/> |
Not a must per-se but damn handy nontheless and the point is we might want to have other applications which require a whole different Ruby version to run so I’ll thank myself later.
-
Ensure your user shell runcommand file (~/.bashrc, ~/.zshrc) doesn’t contain any
$PATH
path which doesn’t include the$PATH
variable itself (e.g.export PATH=/foo/bar:/baz/bara
) and append the$PATH
environment variable postfix (e.g.export PATH=/foo/bar:/baz/bara:$PATH
). -
Pull the latest stable Ruby from rvm.io using
\curl -sSL https://get.rvm.io | bash -s stable --ruby
-
Source the rvm file to obtain access to the function using
source /the/rvm/path/.rvm/scripts/rvm
This is a summary of my current Windows build. Having a incomplete (GNU\Linux vs. Windows) toolset, it was a bit of a scavanger hunt trying to hunt down the best of the best. Of course I still knew some tricks from a few years back, but stuff hasn’t been standing completely still in Redmond so let’s catch up:
<?xml version="1.0" encoding="UTF-8"?> | |
<templateSet group="Magento"> | |
<template name="help" value="Mage::helper('$helperName$')" description="Mage::helper" toReformat="false" toShortenFQNames="true"> | |
<variable name="helperName" expression="" defaultValue="core" alwaysStopAt="true" /> | |
<context> | |
<option name="HTML_TEXT" value="false" /> | |
<option name="HTML" value="false" /> | |
<option name="XSL_TEXT" value="false" /> | |
<option name="XML" value="false" /> | |
<option name="CSS" value="false" /> |
<?php | |
define('PATH_TO_MAGENTO', '/var/www/magento'); // update accordingly | |
require_once PATH_TO_MAGENTO.'/app/Mage.php'; | |
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID); | |
// your php code here | |
?> | |
Although I wouldn’t go as far as to say: "one shouldn’t use a Windows based setup", I’ve had some recent extensive experience in this field, and although amusing at first (trying to get the same (Arch)Linux 'feel') it ultimately failed in a few very essential things. I’ve done my best at it and invite anyone to try for themselves, and nice if you manage to do so properly, but I’ve kept running into some unsurpassable differences which made me flee back to a (Virtualbox) Arch guest: 1) Windows does not know http://pubs.opengroup.org/onlinepubs/009695399/functions/symlink.html [symbolic links as POSIX does] and many shell scripts (read: Bash or more portable 'sh' scripts mostely, btw I use zsh myself); 2) Windows does not know the concept of fork() as *nix systems do.
Both result in either the blatant failure of certain tools (the problem of PHPUnit related libraries relying on PHP ext-pcntl and it being exclusively for POSIX systems) o
{ | |
name: 'greenwellness/wellnessbon' | |
description: 'Definitie voor Green Wellness Wellnessbon.' | |
license: 'proprietary' | |
'minimum-stability': 'dev' | |
config: |