Skip to main content

Posts

Showing posts from July, 2013

Configuring node.js JavaScript for Jslint

When I’m writing JavaScript, I always lint my code using jslint to try to minimize any code problems and syntax errors. In a node.js environment, even the simplest of applications will fail linting. For example a simple require statement will fail with: 'require' was used before it was defined. To configure JSLint for a node.js application, add the lint option node: true at the top of the file. JSLint then knows that the JavaScript belongs to a node.js application and will lint more appropriately. /*jslint node: true */ Note, the spacing is important on this line as there should be no space before the jslint keyword.

NodeJS Application on OpenShift Giving 503 Error

If you’ve got a Node.js application running on OpenShift, chances are at some point you’ve seen a 503 error when deploying the application. The OpenShift FAQ tells us to take a look at the log files in this situation. Looking at the log files for my application, I was getting the following error: > node app.js events.js:48 throw arguments[1]; // Unhandled 'error' event ^ Error: listen EACCES at errnoException (net.js:670:11) at Array.0 (net.js:756:28) at EventEmitter._tickCallback (node.js:190:38) npm info application-name@0.0.1 Failed to exec start script npm ERR! application-name@0.0.1 start: `node app.js` npm ERR! `sh "-c" "node app.js"` failed with 1 This error (in OpenShift terms) seems to mean that the server is not listening on the correct port / address. This can be fixed by ensuring that the Node.js server is configured to use the process.env.OPENSHIFT_NODEJS_PORT and process.env.OPENSHIFT_NODEJS_IP , for example: app.listen(process.env....

Autorestarting Node.js Apps During Development

When writing a Node.js application, it’s frustrating to have to start and stop the application whenever changes are made. To allow us to develop more efficiently, we need something that monitors our Node.js application directory and restarts the application whenever changes are made. This is where nodemon comes in. nodemon doesn’t require any changes to your application’s source code and can be used instead of the node command to start an application. To install nodemon, simply use npm : >sudo npm install -g nodemon ... nodemon@0.7.8 /usr/local/share/npm/lib/node_modules/nodemon You can then start your application using the nodemon command instead of the node command and it will be automatically restarted when changes to the source code are detected. >nodemon app.js 24 Jun 20:15:27 - [nodemon] v0.7.8 24 Jun 20:15:27 - [nodemon] to restart at any time, enter `rs` 24 Jun 20:15:27 - [nodemon] watching: ~/dev/MyApp 24 Jun 20:15:27 - [nodemon] starting `node app.js` Expr...

Reading a Configuration File in NodeJS

Using NodeJS, its easy to read a configuration file using the fs module. To read a configuration file, we need to include the fs module, read in the configuration file and then parse it from JSON into a JavaScript variable. Given the following configuration file (configuration.json): { "database" : "mymongodb", "username" : "mongouser", "password" : "secret" } The configuration can be read using the following Node.js code: var fs, configurationFile; configurationFile = 'configuration.json'; fs = require('fs'); var configuration = JSON.parse( fs.readFileSync(configurationFile) ); console.log(configuration.database); console.log(configuration.username); console.log(configuration.password);

Hello World! In Node.js

As is usual in computer programming, when learning a new language or framework, the initial program is the “Hello World!” application. In Node.js, the “Hello World!” program is written with a twist to show of the event-driven nature of the platform. So, without further ado, here’s “Hello World!”, Node.js style. Add the following code into a file called helloworld.js setTimeout(function() { console.log("World !"); }, 1000); console.log("Hello"); Then run the application with: >node helloworld.js

Apache Tomcat 7.0.42 Released

The Apache Tomcat Team have announced the immediate availability of Tomcat version 7.0.42. This new release fixes several issues including one security issue related to Javadoc vulnerabilities.  The highlights include: Add support for time to first byte in the AccessLogValve. Patch provided by Jeremy Boynes. Correct a regression introduced in 7.0.39 (refactoring of base 64 encoding and decoding) that broke the JNDI Realm when userPassword was set and passwords were hashed with MD5 or SHA1. Ensure that the build process produces Javadoc that is not vulnerable to CVE-2013-1571. Based on a patch by Uwe Schindler. As usual, full details of changes in this release can be found in the project's changelog . This new version of Tomcat can be downloaded from the project's download site .

OpenShift Users - time to update your rhc tools

If you use OpenShift , Mike Mcgrath is stating that there are some performance enhancements to the rhc client tools and its a good chance to update them on your system. Users who have been creating scaled applications should now have a better experience controlling those applications. Particularly start/stop/restart type operations. Performance around production level/scaled applications are getting special attention at the moment so please do share your experiences with us –  openshift@redhat.com The latest version of the rhc tools is 1.10.7.  To see if there is a newer version available over what you've got installed, run the following command: $gem list | grep rhc rhc (1.9.6) This will show the current version of your rhc tools that are installed. If you need to upgrade, this can be achieved as follows: $ sudo gem update rhc Password: Updating installed gems Updating rhc =========================================================================== If this is your firs...