Which would produce this markup:

<!--[if IE 8]> <link href="/path/to/some/styles.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->

Adding a conditional JavaScript file is similar:

And that would produce markup like this:

<!--[if IE]> <script type="text/javascript" src="/path/to/some/script.js"></script><![endif]-->

It can pretty useful when you need to use IE conditional comments just for a single controller action. Otherwise, if it applies site-wide, it’s better to just put conditional stylesheets and/or scripts in a layout file.

1. Creating an index and updating it regularly.
2. Searching the index with a powerful query language.

First, let’s create a fresh search index. I know it’s already tiresome but I will use a simple blog application for my example implementation. To simplify it even further, it will only be possible to search blog posts. The posts schema looks like this:

CREATE TABLE posts (
id INT NOT NULL AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
body TEXT NOT NULL,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_id INT NOT NULL,
INDEX (created_at),
INDEX (user_id),
FOREIGN KEY (user_id)
REFERENCES users(id)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (id)
) ENGINE = INNODB;

Creating the search index is easy:

Pretty straightforward. You can see I have used three different static methods for adding fields to the document:

• UnIndexed: unindexed and unstored (therefor unsearchable) but they are returned with search results. Unindexed fields usually store primary keys, timestamps or file paths.
• Text: indexed, stored and tokenized. Text fields are searchable and are returned with search hits. Titles, first and last names, cities and states, post codes and street names are all good candidates for keyword fields.
• UnStored: indexed and unstored – ideal for large texts.

There are more types of fields you can use (keyword, binary) but you can read about them in the documentation.

Next thing you need to do is update the index every once in a while so the search hits return up-to-date information. There are two ways to get around this problem. The most obvious is to update the index every time a new post is published or an existing post is edited. Another approach would be to set up a cron job to run every now and then and rebuild the index. Which way you choose depends on many variables such as expected index size (a very large index can have few GBs in size).

Secondly, the index is already taken care of, so let’s search it:

That was possibly the simplest possible example of a Lucene search query. You can, however, create very complex queries with the powerful Lucene query language. You can either build queries manually in PHP or you can use Zend_Search_Lucene methods to build them. It’s so easy a baby could do it.

To search for posts with words ‘hello’ and ‘word’ in the contents field you would write this query:

hello

To search for a post that must contain ‘hello’ and may contain ‘world’:

+hello world

To search for a post that must contain ‘hello’ in the contents field and may contain ‘world’ in the title field:

+hello title:"world"

And those were just basics. You can use boolean operators, wildcards, ranges and even perform a fuzzy search.

When it’s so easy with the http_build_query() function:

This is also useful when using cURL to perform POST or GET calls.

So I looked for an alternative and found Pedorosa. It’s more complicated than putty (plus you have to install it) but it remembers your username and password plus it has many more features you might find interesting such as multiple connections in tabs and so on.

The solution is to use partial view helper which allows you to put the repetitive XHTML into a single file. For example, this could be your partial:

And this is how you would include it in all views where the same piece of markup occurs:

It’s really easy and it saves a huge amount of time both to you and to a developer that might work on your application in the future so please, all of you Zend Framework developers, use partial helpers wherever there is a repetitive XHTML markup in your application.

1. Use different font (I have found that Arial is sometimes hard to read, a good replacement seems to be LBRITED.TTF).
2. Set lower dot and line noise level.

You can use “dotNoiseLevel” and “lineNoiseLevel” to tune down the captcha noise (and surpisingly this is not mentioned in the Zend Framework documentation):

Above I went over the top perhaps. Nevertheless, you must be able to find a compromise so that the users will be happy and the security side of your website won’t suffer too much.

The frontend and the backend adapters can take much more arguments, read the documentation to learn all possible options. I initialized the Zend_Cache object with the factory method. First argument means that we want to use the Zend_Cache_Core frontend which is the core of the Zend_Cache module. The second argument is the backend we want to use the Zend_Cache_Backend_File backend or that we want to store cached data as files in a specific directory. The other two parameters are frontend and backend options.

Now we can easily access the cache object in controllers or models:

That was easy, wasn’t it?

Cleaning the cache

You will surely also want to remove cached files at some point in your application:

That’s it for today and, by the way, Merry Christmas

The problem lied in this .htaccess rule:

php_flag magic_quotes_gpc off

So I just commented the line and the error went away.

The line’s purpose was to make sure magic quotes are turned off in PHP.  You can use it if your web host supports it, if not just add this to your bootstrap file:

What I have done is rewrite the code snippet from John Wakefield in the C language. Instead of data type double I used two integer arrays (one denotes x and the other one y coordinates of points from a training set). Plus I have added a simple code do draw a nice graph of the training set and its linear separation. I used GD to draw the image. I would also like to thank Amro for helping me finish this algorithm.

Here’s the entire code:

I used the Dev C++ to write the program. Here is how to use GD in Dev C++.

To clear the command line:

clc

To clear all variables:

clear all

To clear the command history:

com.mathworks.mlservices.MLCommandHistoryServices.removeAll

Just putting this information down for my own reference so I won’t have to search for it later.