Oridoki

[adriacidre]

Awesome when you need to evaluate any page script on a page when scrapping.

[adriacidre]

Update with join on postgresql

UPDATE games AS g SET slug = g.slug || '_' || p.slug FROM platforms AS p WHERE g.platform_id = p.id

[adriacidre]

Upgrade default ruby version

You can easily upgrade your default ruby version with rvm, this are the simplest commands to get it working!

curl -L https://get.rvm.io | bash -s stable --ruby --autolibs=enable --auto-dotfiles source /usr/local/rvm/scripts/rvm rvm install 1.9.3 rvm use 1.9.3 --default

[adriacidre]

Singleton using traits

As common software pattern, usually we use singletons, since traits introduction you can use less code just by using this trait to convert any class into a singleton :-)

<?php trait Singleton { private static $_instance; private function __construct(){} public function __clone() { throw new Exception('This object cannot be cloned!'); } public static function getInstance() { if (null === static::$_instance) { static::$_instance = new static(); } return static::$_instance; } } class Product { use Singleton; } $product = Product::getInstance();

[adriacidre]

Init_d template

I've this template on my gists, so I think it's interesting to share it here :-)  

#!/bin/bash # myapp daemon # chkconfig: 345 20 80 # description: myapp daemon # processname: myapp DAEMON_PATH="/home/wes/Development/projects/myapp" DAEMON=myapp DAEMONOPTS="-my opts" NAME=myapp DESC="My daemon description" PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME case "$1" in start) printf "%-50s" "Starting $NAME..." cd $DAEMON_PATH PID=`$DAEMON $DAEMONOPTS > /dev/null 2>&1 & echo $!` #echo "Saving PID" $PID " to " $PIDFILE if [ -z $PID ]; then printf "%s\n" "Fail" else echo $PID > $PIDFILE printf "%s\n" "Ok" fi ;; status) printf "%-50s" "Checking $NAME..." if [ -f $PIDFILE ]; then PID=`cat $PIDFILE` if [ -z "`ps axf | grep ${PID} | grep -v grep`" ]; then printf "%s\n" "Process dead but pidfile exists" else echo "Running" fi else printf "%s\n" "Service not running" fi ;; stop) printf "%-50s" "Stopping $NAME" PID=`cat $PIDFILE` cd $DAEMON_PATH if [ -f $PIDFILE ]; then kill -HUP $PID printf "%s\n" "Ok" rm -f $PIDFILE else printf "%s\n" "pidfile not found" fi ;; restart) $0 stop $0 start ;; *) echo "Usage: $0 {status|start|stop|restart}" exit 1 esac

[adriacidre]

PHP Traits and Alias

PHP traits allow you to call trait methods with an alias on this way:

trait supuTrait { public function test() { echo 'hello'; } } class supuClass { use supuTrait { test as test1; test as test2; } } $o = new supuClass(); $o->test1(); # Will show you hello $o->test2(); # Will show you hello

At this point you could need the name of the called method inside the trait, but when you try:

echo 'hello ' . __FUNCTION__;

It will show you ‘hello test’. So at this point we can hack it to get the alias name by doing something like this:

trait DebuggerTrait { public function getAlias() { $backtrace = debug_backtrace(); return $backtrace[1]['function']; } } trait supuTrait { use DebuggerTrait; public function test() { echo $this->getAlias(); } } class supuClass { use supuTrait { test as test1; test as test2; } } $o = new supuClass(); $o->test1(); # Will show you test1 $o->test2(); # Will show you test2

[adriacidre]

Github compare branches

It's usual when you're working with github to see changes between branches, tags or whatever. You can do it with this hidden url:

https://github.com/myrepo/web/compare/branch1...tag2

Where you can change branch1 and tag2 for anything. This will also work for tags or commit hashes ;-)

[adriacidre]

Symfony2 routes to apache

Some good practices in web dev, says that you should move as many rules as you can from htaccess to apache conf, this is mainly because if you write it on your htaccess, apache should read it every time, but on apache config files this only happens one time. If you want to export all your symfony2 project's rewrite rules, just do:

app/console --env=prod router:dump

  This will show you all rewrite rules configured for a production environment.

[adriacidre]

Symfony cache permissions problem

Every time I try to get working symfony2 on a virtualbox I get the same problem. Problem with app/cache and app/log/ folder permisions.

The problem seems to be the difference between the apache user and the php execution user and it's solution is documented here.

In my case, I can't get working with any of 3 possible solutions sf2 doc explains. And the best / easy solution I've found is to change apache's default user to be the same as php. To do it you just need to change this on /etc/apache2/apache2.conf :

# These need to be set in /etc/apache2/envvars User ${APACHE_RUN_USER} Group ${APACHE_RUN_GROUP}

  by this:

# These need to be set in /etc/apache2/envvars

User your_user

Group your_group

This way, everybody is accessing the files with the same user / group.

Maybe you should remove the contents on app/cache and app/log after this changes, and restart apache ;-)

Remember this is a valid solution just for your dev environments ;-)

Hope it helps

[adriacidre]

Git : Remote tag removal

Supose you have a 'v5.5' tag and you want to delete it on your local and remote repos:

git tag -d v5.5 git push origin :refs/tags/v5.5

[adriacidre]

Code refactor : Scaffolding - Acceptance scaffolding Part I

This point requires the business support to get the 'user acceptance cases'. This means the way the final user it's using the software. This is an important part of the code refactor, because, at least, it becomes on an easy way to discard deprecated parts of the behaviour, and save us many time. The main objective of this point is to get described all the possible scenarios to use our software. This is on an ideal situation, but you can get this info priorized to get feedback about the 'real' important behaviours. To describe this scenarios we will be using Gherkin. Gherkin is a business readable, domain specific language that lets you describe software's behaviour without dealing how that behaviour is implemented. Gherkin syntax example

1: Feature: Some terse yet descriptive text of what is desired 2: In order to realize a named business value 3: As an explicit system actor 4: I want to gain some beneficial outcome which furthers the goal 5: 6: Scenario: Some determinable business situation 7: Given some precondition 8: And some other precondition 9: When some action by the actor 10: And some other action 11: And yet another action 12: Then some testable outcome is achieved 13: And something else we can check happens too 14: 15: Scenario: A different situation 16: ...

Well this looks interesting, at that moment we will have described all the possible scenarios on a plain an non-technical understandable language. At this point you can do manual tests over all this scenarios before each code deploy. But wait, we're developers, we really don't want extra-job, let's automate all this stuff.

[adriacidre]

Code refactor : Scaffolding

The first think we need to do before start changing anything inside our code is to put some scaffolds out there. We will divide this on three scaffold types: 1.- Acceptance scaffold 2.- Integration scaffold 3.- Unit scaffold Yes, we will do it in this order because of the legacy code. This is mainly because the most common thing is to have the 'business' feedback, but we really don't know anything else about the way our software works.

[adriacidre]

PHP : Generate random filenames

Maybe the easy way to generate a random filename

$dFile = tempnam(sys_get_temp_dir(), 'Debug');

[adriacidre]

Built-in PHP Exceptions

When you're building great projects many times, you need to create your own exceptions, it's not a hard work but it's a little bit annoying. I recently discovered that the Standard PHP Library (SPL) provides a number of built-in exceptions:

BadFunctionCallException BadMethodCallException DomainException InvalidArgumentException LengthException LogicException OutOfBoundsException OutOfRangeException OverflowException RangeException RuntimeException UnderflowException UnexpectedValueException

They are so usefull to start with instead of creating your owns.

[adriacidre]

GIT and tags

On software development we work with versions to determine when a piece of software is on a determined stage. With git I always been working with branches named with the version number. Git also provides tags wich are more useful for this task. A tag is just a pointer to a commit, and we will use it as a shortcut to access this commit. Some useful commands to work with tags Create new tag:

git tag -a v1.0.0 -m "Creating the first official version." git push --tags git fetch --tags

[adriacidre]

PHP SimpleXML and CDATA

SimpleXML is giving me many problems to get working with CDATA tag, this is mainly because it is replacing the "<" and ">" with his htmlentities respectives. There is a little hack to get it working: $xml = simplexml_load_string("");

$node = $xml->addChild('supuKey'); $nodeX= dom_import_simplexml($node); $no = $nodeX->ownerDocument; $nodeX->appendChild($no->createCDATASection('supuValue));

Enjoy it!

[adriacidre]

PHP - Legacy code refactor

This should be a series of posts about the best ways to refactor your legacy to a following standards one. There are many projects where you find many lines of legacy code. This code must be refactored and adapted to some kind of coding standards, but you should do it on a secure way. First challenge you have with legacy code is that you really don't have the knowledge of what this code do, and probably nobody on the company has this knowledge. We part here from the basis that you have code working on an object oriented architecture. Well let's start. To refactor legacy code we should do two kinds of tests. 1.- Unit tests: I use phpunit at this point With unit tests we should know step by step what's doing exactly our application separating logic into each method of each class. 2.- Acceptance tests: Cucumber + Ruby: With acceptance tests we verify the how-it-works of the application at a user level. Ideally you should start with acceptance tests to get covered all the hot spots of you application, like booking process, product view… With acceptance tests you're working with the waranty that your code updates doesn't broke the main functionalities of the application. Once you have detected and tested all this hot spots you should start testing each part of code you want to refactor. It's interesant to cover each method as much as possible, before start with any kind of refactor. We can separate refactor on two parts: 1.- Refactor at a class level This means you do refactor just moving / converting / rewriting code just on the current class. This is useful as a first step begofore the point 2. 2.- Refactor at a project level Once you have splited your class on small methods you can think bigger and move all that methods to it's correct place on the framework. I mean, you should think something like, is this logic proper from the model or I should put it on the Controller…? Next day I'll show you how to start with phpunit and mainly how to front the main problems like dependency injection.