<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">
<channel>
	<title>Code is Poetry</title>
	<link>http://www.xarg.org/</link>
	<description>OpenSource Development, MySQL and PHP Blog</description>

	<language>en</language>
	
		<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/exarg" /><feedburner:info uri="exarg" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:emailServiceId>exarg</feedburner:emailServiceId><feedburner:feedburnerHostname>http://feedburner.google.com</feedburner:feedburnerHostname><item>
		<title>Flag based COUNT using MySQL</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/M3CmchfYbFE/</link>
		<comments>http://www.xarg.org/2011/10/flag-based-count-using-mysql/#comments</comments>
		<pubDate>Thu, 27 Oct 11 13:45:49 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[Bits]]></category>

				<category><![CDATA[MySQL]]></category>

				<category><![CDATA[Optimization]]></category>

				<category><![CDATA[Flags]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/10/flag-based-count-using-mysql/</guid>

		<description><![CDATA[I was asked for help in optimizing a MySQL query where flags are stored in a database and references should be counted based on the flag value. Sounds not complicated at first, but there are several flags that should be counted and also just once per reference. A lot of food for GROUP BY you may think. Having said this, search and group for flags in this table would be really slow due to a very poor cardinality. But let's start with the actual problem. The example is fictitious, but I did my best to find a general use case for this problem.]]></description>

		<content:encoded><![CDATA[<p>I was asked for help in optimizing a MySQL query where flags are stored in a database and references should be counted based on the flag value. Sounds not complicated at first, but there are several flags that should be counted and also just once per reference. A lot of food for <em>GROUP BY</em> you may think. Having said this, search and group for flags in this table would be really slow due to a very poor cardinality. But let's start with the actual problem. The example is fictitious, but I did my best to find a general use case for this problem.</p><p><a href="http://www.xarg.org/2011/10/flag-based-count-using-mysql/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/M3CmchfYbFE" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/10/flag-based-count-using-mysql/</feedburner:origLink></item>
		<item>
		<title>Optimized Pagination using MySQL</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/f5ecbmg1cFo/</link>
		<comments>http://www.xarg.org/2011/10/optimized-pagination-using-mysql/#comments</comments>
		<pubDate>Mon, 24 Oct 11 13:45:12 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[Pagination]]></category>

				<category><![CDATA[MySQL]]></category>

				<category><![CDATA[Optimization]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/10/optimized-pagination-using-mysql/</guid>

		<description><![CDATA[Dealing with large data sets makes it necessary to pick out only the newest or the hottest elements and not displaying everything. In order to have older items still available, Pagination navigation's have become established. However, implementing a Pagination with MySQL is one of those problems that can be optimized poorly with MySQL and certainly other RDBM systems. However, knowing the underlying database can also help in optimizing pagination queries, because there is no real copy and paste solution.]]></description>

		<content:encoded><![CDATA[<p>Dealing with large data sets makes it necessary to pick out only the newest or the hottest elements and not displaying everything. In order to have older items still available, Pagination navigation's have become established. However, implementing a Pagination with MySQL is one of those problems that can be optimized poorly with MySQL and certainly other RDBM systems. However, knowing the underlying database can also help in optimizing pagination queries, because there is no real copy and paste solution.</p><p><a href="http://www.xarg.org/2011/10/optimized-pagination-using-mysql/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/f5ecbmg1cFo" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/10/optimized-pagination-using-mysql/</feedburner:origLink></item>
		<item>
		<title>Optimized trend analysis</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/jn7wmvXSYm8/</link>
		<comments>http://www.xarg.org/2011/09/optimized-trend-analysis/#comments</comments>
		<pubDate>Tue, 27 Sep 11 00:43:48 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[Trend]]></category>

				<category><![CDATA[Analysis]]></category>

				<category><![CDATA[Math]]></category>

				<category><![CDATA[Smooth]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/09/optimized-trend-analysis/</guid>

		<description><![CDATA[		If you look at the number of visitors of your website, you can only take the data of the previous days for a serious analysis. In itself logical, but it would also be desirable to know which traffic you can expect today, based on the expectation of the day. For the statement about the expected traffic, you can use a simple average, but this has no real significance. A better approach would incorporate all available information.]]></description>

		<content:encoded><![CDATA[		<p>If you look at the number of visitors of your website, you can only take the data of the previous days for a serious analysis. In itself logical, but it would also be desirable to know which traffic you can expect today, based on the expectation of the day. For the statement about the expected traffic, you can use a simple average, but this has no real significance. A better approach would incorporate all available information.</p><p><a href="http://www.xarg.org/2011/09/optimized-trend-analysis/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/jn7wmvXSYm8" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/09/optimized-trend-analysis/</feedburner:origLink></item>
		<item>
		<title>jQuery Pagination revised</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/ek2LzCf3lV8/</link>
		<comments>http://www.xarg.org/2011/09/jquery-pagination-revised/#comments</comments>
		<pubDate>Sun, 04 Sep 11 13:10:25 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[jQuery]]></category>

				<category><![CDATA[Algorithm]]></category>

				<category><![CDATA[Pagination]]></category>

				<category><![CDATA[Paging]]></category>

				<category><![CDATA[Navigation]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/09/jquery-pagination-revised/</guid>

		<description><![CDATA[There are many nasty pagination implementations and certainly sooner or later I've also written such a cruelty. That's why I've been working on a generalized solution for long in order to combine the variety of needs that are imposed on such a navigation to finally put an end to blocks of code that are copied from one project to another with the consequence that it gets no longer understood over the time.]]></description>

		<content:encoded><![CDATA[<p>There are many nasty pagination implementations and certainly sooner or later I've also written such a cruelty. That's why I've been working on a generalized solution for long in order to combine the variety of needs that are imposed on such a navigation to finally put an end to blocks of code that are copied from one project to another with the consequence that it gets no longer understood over the time.</p><p><a href="http://www.xarg.org/2011/09/jquery-pagination-revised/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/ek2LzCf3lV8" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/09/jquery-pagination-revised/</feedburner:origLink></item>
		<item>
		<title>Faster PHP behind FastCGI</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/zlC3YpzrIi4/</link>
		<comments>http://www.xarg.org/2011/06/faster-php-behind-fastcgi/#comments</comments>
		<pubDate>Fri, 10 Jun 11 08:00:56 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[PHP]]></category>

				<category><![CDATA[Optimization]]></category>

				<category><![CDATA[performance]]></category>

				<category><![CDATA[sendfile]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/06/faster-php-behind-fastcgi/</guid>

		<description><![CDATA[A few years ago, Jan Kneschke came up with
the idea of using lighttpd's X-Sendfile to send dynamic content
without copying it several times. I liked the idea and used it as basis of my
framework. It seems, there are now some immature implementations of this idea
on the lighttpd bug tracker. All of these implementations also use the shared
memory, with the difference that I haven't used PHP's tempfile()
function, but rather exported lighttpd's client-file-descriptor to the PHP
scope in order to use it as the file-name of the temporary file. It could also be the IP or something else but the client-fd is the most unique identifier inside of the webserver &amp;lt;-&amp;gt; PHP construct.]]></description>

		<content:encoded><![CDATA[<p>A few years ago, Jan Kneschke <a
href="http://blog.lighttpd.net/articles/2006/11/29/faster-fastcgi">came up with
the idea</a> of using lighttpd's <em>X-Sendfile</em> to send dynamic content
without copying it several times. I liked the idea and used it as basis of my
framework. It seems, there are now some immature implementations of this idea
on the lighttpd bug tracker. All of these implementations also use the shared
memory, with the difference that I haven't used PHP's <em>tempfile()</em>
function, but rather exported lighttpd's client-file-descriptor to the PHP
scope in order to use it as the file-name of the temporary file. It could also be the IP or something else but the client-fd is the most unique identifier inside of the webserver &lt;-&gt; PHP construct.</p><p><a href="http://www.xarg.org/2011/06/faster-php-behind-fastcgi/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/zlC3YpzrIi4" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/06/faster-php-behind-fastcgi/</feedburner:origLink></item>
		<item>
		<title>PHP Hacking</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/qCcbzGIXxvw/</link>
		<comments>http://www.xarg.org/2011/06/php-hacking/#comments</comments>
		<pubDate>Wed, 08 Jun 11 21:41:48 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[PHP]]></category>

				<category><![CDATA[Patch]]></category>

				<category><![CDATA[Fork]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/06/php-hacking/</guid>

		<description><![CDATA[It took me a while but here's a new toy. Today I publish my own PHP fork
based on the PHP 5.3.6 code base with a few changes that make the everydays
developer life more bearable. It includes some of the patches I've already
published about 3 years ago, my defcon extension and also my infusion extension
plus a good bunch of extra gimmickries.]]></description>

		<content:encoded><![CDATA[<p>It took me a while but here's a new toy. Today I publish my own PHP fork
based on the PHP 5.3.6 code base with a few changes that make the everydays
developer life more bearable. It includes some of the patches I've already
published about 3 years ago, my defcon extension and also my infusion extension
plus a good bunch of extra gimmickries.</p><p><a href="http://www.xarg.org/2011/06/php-hacking/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/qCcbzGIXxvw" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/06/php-hacking/</feedburner:origLink></item>
		<item>
		<title>Find friends of friends using MySQL</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/t40AEeYmt88/</link>
		<comments>http://www.xarg.org/2011/01/find-friends-of-friends-using-mysql/#comments</comments>
		<pubDate>Thu, 20 Jan 11 00:48:43 +0100</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[MySQL]]></category>

				<category><![CDATA[Optimization]]></category>

				<category><![CDATA[Social]]></category>

				<category><![CDATA[Graph]]></category>

				<category><![CDATA[Neo4j]]></category>

				<category><![CDATA[Views]]></category>

				<category><![CDATA[Trigger]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/01/find-friends-of-friends-using-mysql/</guid>

		<description><![CDATA[In a previous article, I've already talked about an optimized way to connect locations in a geographic point of view by using MySQL. In this manner, locations of pubs, drugstores, barbers or even users can be obtained. Communities, or perhaps I should use the newer term Social Networks, make use of the buddy network of indiviual members in addition to the geographical mapping. This has many psychological advantages, because new members can be integrated in an established network very easily and I'm more willing to become involved when I already know some of the members.]]></description>

		<content:encoded><![CDATA[<p>In a previous article, I've already talked about an optimized way to <a href="/2009/12/people-near-you-with-mysql/">connect locations in a geographic point of view</a> by using MySQL. In this manner, locations of pubs, drugstores, barbers or even users can be obtained. Communities, or perhaps I should use the newer term Social Networks, make use of the buddy network of indiviual members in addition to the geographical mapping. This has many psychological advantages, because new members can be integrated in an established network very easily and I'm more willing to become involved when I already know some of the members.</p><p><a href="http://www.xarg.org/2011/01/find-friends-of-friends-using-mysql/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/t40AEeYmt88" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/01/find-friends-of-friends-using-mysql/</feedburner:origLink></item>
		<item>
		<title>Tag Cloud plugin for Smarty</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/2z_9wQTn1gk/</link>
		<comments>http://www.xarg.org/2008/08/tag-cloud-plugin-for-smarty/#comments</comments>
		<pubDate>Thu, 14 Aug 08 01:32:22 +0200</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[Smarty]]></category>

				<category><![CDATA[PHP]]></category>

				<category><![CDATA[Plugin]]></category>

				<category><![CDATA[Tag Cloud]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2008/08/tag-cloud-plugin-for-smarty/</guid>

		<description><![CDATA[I've written a featureful plugin for the Smarty templating engine to be able to generate tag clouds very easily. Smarty by itself is a really slow engine, so that it would not the worst idea to use a plugin which is written in pure PHP instead of generating the list of words with the even slower {math} extension of Smarty.]]></description>

		<content:encoded><![CDATA[<p>I've written a featureful plugin for the Smarty templating engine to be able to generate tag clouds very easily. Smarty by itself is a really slow engine, so that it would not the worst idea to use a plugin which is written in pure PHP instead of generating the list of words with the even slower <em>{math}</em> extension of Smarty.</p><p><a href="http://www.xarg.org/2008/08/tag-cloud-plugin-for-smarty/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/2z_9wQTn1gk" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2008/08/tag-cloud-plugin-for-smarty/</feedburner:origLink></item>
		<item>
		<title>Create a simple and small GIF with PHP</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/sdhCRG6HOck/</link>
		<comments>http://www.xarg.org/2011/01/create-a-simple-and-small-gif-with-php/#comments</comments>
		<pubDate>Wed, 12 Jan 11 20:59:42 +0100</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[GIF]]></category>

				<category><![CDATA[PHP]]></category>

				<category><![CDATA[Compression]]></category>

				<category><![CDATA[Tracking]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/01/create-a-simple-and-small-gif-with-php/</guid>

		<description><![CDATA[There were times, in which table layouts and pixel-bungling was part of the daily life of a web developer. Fortunately, those days are past and nearly every layout can be implemented with XHTML or better HTML5 and CSS only. A nice side effect is that, indirectly, the loading speed of the complete site is reduced by lowering the number of HTTP requests.]]></description>

		<content:encoded><![CDATA[<p>There were times, in which table layouts and pixel-bungling was part of the daily life of a web developer. Fortunately, those days are past and nearly every layout can be implemented with <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> or better <abbr title="Hypertext Markup Language">HTML5</abbr> and <abbr title="Cascading Style Sheets">CSS</abbr> only. A nice side effect is that, indirectly, the loading speed of the complete site is reduced by lowering the number of <abbr title="Hypertext Transfer Protocol">HTTP</abbr> requests.</p><p><a href="http://www.xarg.org/2011/01/create-a-simple-and-small-gif-with-php/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/sdhCRG6HOck" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/01/create-a-simple-and-small-gif-with-php/</feedburner:origLink></item>
		<item>
		<title>Is it possible to avoid query parsing inside of MySQL?</title>
		<link>http://feedproxy.google.com/~r/exarg/~3/y7olY0z8iiU/</link>
		<comments>http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-parsing-inside-of-mysql/#comments</comments>
		<pubDate>Mon, 10 Jan 11 21:54:25 +0100</pubDate>
		<dc:creator>Robert Eisele</dc:creator>
				<category><![CDATA[MySQL]]></category>

				<category><![CDATA[Optimization]]></category>

				<category><![CDATA[performance]]></category>

				<category><![CDATA[Protocol]]></category>

				<guid isPermaLink="false">http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-parsing-inside-of-mysql/</guid>

		<description><![CDATA[I've just started learning MySQL's internals but I've got an idea which I want to convert to a question here, to ask people who are already deeper in it. Is it a bad idea to completeley avoid query parsing on the server side and use a binary protocol instead? This way the client parses the query and could cache the statement structure for further usage or another client API uses a NoSQL approach to send the request data to the server. ]]></description>

		<content:encoded><![CDATA[<p>I've <a href="/2010/11/mysql-my-new-playground/">just started</a> learning MySQL's internals but I've got an idea which I want to convert to a question here, to ask people who are already deeper in it. Is it a bad idea to completeley avoid query parsing on the server side and use a binary protocol instead? This way the client parses the query and could cache the statement structure for further usage or another client API uses a NoSQL approach to send the request data to the server. </p><p><a href="http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-parsing-inside-of-mysql/">Read the rest &raquo;</a></p><img src="http://feeds.feedburner.com/~r/exarg/~4/y7olY0z8iiU" height="1" width="1"/>]]></content:encoded>

	<feedburner:origLink>http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-parsing-inside-of-mysql/</feedburner:origLink></item>
	</channel>
</rss>

