By default Subversion shows diff without highlighting which makes a bit difficult review of big changes.
But that situation can be changed extremely simple and fast. I assume you use Fedora 17. For the other distributions you need just use different package manager, choose correct package name and find configs in the proper places.
First of all, install utility colordiff:
sudo yum install colordiff
Now you can get highlighted output of SVN diff:
svn diff foo.php | colordiff
But it isn’t convenient way. Since Subversion allows to use any external program to make a diff we just should just add following in the ~/.subversion/config:
diff-cmd = colordiff
And voilà, we can see colored diff just run ordinary SVN diff command:
svn diff foo.php
To change colors in colordiff just copy its global config to your home directory and edit it:
cp /etc/colordiffrc ~/.colordiffrc
Sure all GUI DB tools can do export of result of query into CSV file. But what if you have to do this from command line? There is a simple way perform that task. Here is an example:
INTO OUTFILE '/tmp/products.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
ESCAPED BY '\\'
LINES TERMINATED BY '\n'
When you run that query all records from the table products will be dumped into file /tmp/products.csv. All fields of that dump will be delimited by comma, enclosed by double quotes and escaped by two slashes. Each row will be ended by end of the line character.
Sure you can change delimiter, enclose, escape symbols as well as add any others SQL statements such JOIN, WHERE, LIMIT ORDER etc. Enjoy!
UPDATED: Don’t forget to drop the export file before re-export data. Otherwise you’ll get the error:
ERROR 1086 (HY000): File '/tmp/products.csv' already exists
Brian Foy – the author of Mastering Perl and one of the famous perlmonks, wrote an article on the ONLAMP where described five ways to improve Perl programming:
- Cleaning up your code – I also hate to read unformatted code -without tabs, proper style etc.
- Use configuration – sure, my favorite module – Config::General.
- Logging – log4perl should be used in all your applications.
- Persistence – Brian suggested to use Storable or DBM::Deep but I prefer to use Cache::FileCache (it’s used in my module IMDB::Film to cache already retrieved web content).
- Subclasses for applications – it’s good practice to implement a common functionality in the modules instead of keeping it in your script. This approach allows to have more structured application and reuse the same functionality in some other scripts.
So, generally I didn’t find anything new for me in those recommendations. I just confirmed my own point of view 🙂
We use following approach to build print view of documents in our web-based application. At the begging the document template is filled by real data and HTML page is generated. After that this page is sent to HTMLDOC which converts it into PDF. The users open the document via Acrobat plugin installed in the web browser. This approach has worked fine for years.
But recently we decided to send PDF directly to the printer. I’ve added printer to the our server and implemented a simple function (we have a Xerox printer with PostScript support):
lp -d printer_name -o sides=two-sided-long-edge -o media=A4 -o portrait -o page-ranges=1-7 PDF_file
The strange thing appeared right after that. One type of documents couldn’t print anymore. No errors in the CUPS log or on the printer display. The job just disappeared from the queue and was marked as printed. After spending some time I found the way to solve this problem. I use acroread to convert PDF into PostScript and then send it to the printer:
acroread -toPostScript PDF_file
Acroread creates the PostScript file with the same name but with different extension (.ps) and stores it in the current directory. But you can pass desired directory name as second parameter:
acroread -toPostScript PDF_file /store-dir/
I use Acrobat 5 from DAG repository. It works fine even the server doesn’t have installed X. But if you want to use Acrobat 7 you should do additional work. It needs X and if try to run it from command line it give you an error:
(acroread:6488): GTK-WARNING **: cannot open display:
To solve this just install Xvfb – X server that can run on machines with no display hardware and no physical input devices, and run following command:
xinit acroread -toPostScript PDF_file /store-dir/ -- /usr/X11R6/bin/Xvfb :9 -ac
Some of you know about ActiveMQ – an open source (Apache 2.0 licensed) Java Message Service 1.1 (JMS) message broker packed with many enterprise features. One of the way to communicate with it from none-Java programm languages is STOMP (Streaming Text Orientated Messaging Protocol). STOMP is very simple and looks like HTTP-protocol.
Perl has at least two ways to communicate with ActiveMQ over STOMP:
Using ActiveMQ may help you to integrate your applications with others on Enterprise level.
I came across Ovid’s CGI Course. It’s definitely good tutorial. Both experts and beginners will find there something interesting and helpful. I found the third part – Basic Security the most important and interesting for me. I’d like to add that you can find many useful extensions for CGI like CGI::Forms, for example. This module will do all routine work for you to produce web forms. Or here is a CGI::Framework – a simple-to-use, lightweight web CGI framework.
But notice that using plain CGI is defensible in case of simple web script. If you’re going to develop something serious have a look some Perl framework such Catalyst, Gantry or Maypole. They’re enough powerful to be a base of scalable and efficient web applications.
When you manage some serious system where users can change their passwords you’ll face with problem of quality of those passwords. There is a Perl module – Data::Password, which may do all work to check user passwords: length or the number of character groups. Also, it’s possible to make more complicated checking: the password does not contain the same chars repeatedly or ascending or descending characters, or charcters close to each other in the keyboard. You can use system dictionary files (/usr/share/dict/words for Fedora Core 5, for example) or create you own. The module has only two methods and six variable which can be imported into your script/module to customize checking. Here is a small example of using Data::Password:
use Data::Password qw(:all);
$DICTIONARY = 0;
$GROUPS = 0;
# Will print "Bad password - contains the word 'clear', only lowercase"
If you’re new in XML this simple guide is what do you need to learn XML. Only for beginners! XML guru hardly find something interesting there.