I recently wrote an article for Web & PHP Magazine about how you can start using Node.js on your PHP website and shows off a real-time news feed using redis. It talks about sharing PHP session data with Node, and in it I use loads of cool technologies like redis, Socket.IO, bower and composer.
A little while ago, a spent some time hacking in AMD support to Strophe.js, a client-side XMPP library. So far it hasn’t been merged, but if you are interested please comment on the pull request. It would be nice to get this added in so that we can continue to use Strophe as the world slowly moves towards more modular code using something like AMD or ES6 modules.
Update projects to use namespaces. This will move any projects that are in groups to a namespace. bundle exec rake gitlab:enable_namespaces RAILS_ENV=production
I could not get this working, easier to remove all projects from groups on the old install before migrating.
Run the rake:check command and see if it complains about anything. You may need to run the create satellites command or the run the script to update the hooks.
If you get:
FATAL: split conf set, gl-conf not present for ‘gitolite-admin’
fatal: The remote end hung up unexpectedly
Then you need to re-run the gitolite setup. This I think is because gitolite-admin is still in version 2 format.
If you get an error “cannot load such file — rb-inotify”, you need to add gem “ib-notify” to the bottom of the gemfile and run bundle install again.
If you get an error about invalid SSH keys, keep deleting the offending keys until the errors go away.
This post has been sitting as a draft for ages (since before Zend Framework 2.0 ) but I thought I should get it out anyway!
When testing code which makes HTTP requests to web services, you do not want your tests to be reliant on the web service working. This goes against the best practices of unit tests, in which tests should be quick to run (web service might be slow), tests should ideally require no set up to run (web service calls may need API keys) and tests should be as standalone as possible (so that they can be run on say, a continuous integration server, or so you can test offline!). The point of this is so that you have no excuse not to run the tests whenever you make a change to the code. The idea of running unit tests on the client is also not to find bugs in the web service itself.
Thus, here is a basic example of a web service client class and it’s corresponding test class. By using the Zend_Http_Client_Adapter_Test adapter, we can tell Zend_Http_Client when we want it to fail, and test that the code handles failure gracefully.
Configure (I want ODBC support, but you might not need it)
cd ejabberd && ./configure --enable-odbc
Compile code with debugging enabled
Install ejabberd; I couldn’t work out if there was a way to run ejabberd without installing it.
sudo make install
Configure ejabberd as required by editing /etc/ejabberd/ejabberd.cfg. Then run it with
sudo ejabberdctl start
Attach to the running erlang process
sudo ejabberdctl debug
Press any key to continue. Then in the shell type:
This will open up the lovely erlang debugger monitor window, as shown below.
How pretty it is!
Then go to Module -> Interpret and browse to the ejabberd source code folder from earlier, and choose the .erl file you want to debug. This only works if the beam files have been compiled with debugging enabled, using the make step from before. Once you’ve selected a file, it will appear in the list on the left and you can double click it to view it and add break points as shown below.
Adding a function breakpoint
To trigger the break point you just need to join a chat room with a client:
Break point triggered
You can then step through the code by double clicking on the line with the break in it:
Create an ODBC configuration for ejabberd at /etc/odbc.ini,
[ODBC Data Sources]
odbcname = MyODBC 3.51 Driver DSN
Driver = /usr/lib/odbc/libmyodbc.so
Description = MyODBC 3.51 Driver DSN
SERVER = localhost
USER = ejabberd
Password = ejabberd
Database = ejabberd
OPTION = 3
Download mod_archive from Subversion.
svn co https://svn.process-one.net/ejabberd-modules
You may then have to edit Emakefile before compiling. This is because by default it will point to the include files from ejabberd trunk, which will probably be for a newer version of ejabberd than you have installed, unless you installed ejabberd from trunk. in Emakefile replace all instances of:
And then run
This will generate some *.beam files in the ebin directory. Copy these to the ejabberd ebin directory which should contain all the other ejabberd .beam files. The directory for me is /usr/lib/ejabberd/ebin/.
Create the MySQL database schema using the SQL scripts from mod_archive. They are in ejabberd-modules/mod_archive/trunk/src/*.sql. The script for MySQL is mod_archive_odbc_mysql.sql.
Add in the configuration options to enable mod_archive in ejabberd.cfg, under modules:
At the top of the ejabberd.cfg file to ensure that changes in the configuration file take affect. Otherwise, you may experience strange results where changes do not seem to take affect after restarting the server. This is because the configuration file is loaded into the internal ejabberd database. If you do not override certain settings in the configuration file, the old values from the database will be used. Spent much time trying to work out why my changes to the configuration file weren’t being noticed.
Erlang, the language ejabberd is written in, uses nodes. These are controlled with ejabberdctl. ejabberd itself can be controlled with the init script, /etc/init.d/ejabberd. If you get:
Node ‘ejabberd@host’ is started. Status: started
ejabberd is not running
That means the node is running, but inside that ejabberd didn’t start correctly, but didn’t crash. Usually this is a misconfiguration, and the error message will be in a log file, either /var/log/ejabberd/ejabberd.log or /var/log/ejabberd/sasl.log. When making changes to the configuration file, usually you just use ejabberdctl restart, and don’t use the init script.
It seems there is a bug in NetBeans 6.7 which means that PHP projects do not work correctly with license templates. If you specify a license to use in the nbproject/project.properties file, the template file does not seem to read that key, and thus the default template is used. This has been fixed in the daily builds, bug report is here.