<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Code Snips</title>
	<atom:link href="http://www.chesterproductions.net.nz/blogs/it/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.chesterproductions.net.nz/blogs/it</link>
	<description>Simple code hopefully worth remembering</description>
	<lastBuildDate>Thu, 08 Apr 2010 05:33:48 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>Comment on Random Passwords by admin</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/scripts/random-passwords/14/comment-page-1/#comment-18</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Thu, 08 Apr 2010 05:33:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=14#comment-18</guid>
		<description>Another alternative, if you have OpenSSL installed, and let&#039;s face it who doesn&#039;t, is:

openssl rand 16 -base64

Or similar.</description>
		<content:encoded><![CDATA[<p>Another alternative, if you have OpenSSL installed, and let&#8217;s face it who doesn&#8217;t, is:</p>
<p>openssl rand 16 -base64</p>
<p>Or similar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by admin</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-15</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Fri, 31 Jul 2009 10:08:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-15</guid>
		<description>The path argument is untidy as it reveals things to the recipient that they don&#039;t need to know and my paranoid self never likes to give too much away if I can help it.  But yes you are right any of those solutions are quite usable.  The regex really is there as an illustration of a point about typical Perl coding approaches rather than the way things should be done.</description>
		<content:encoded><![CDATA[<p>The path argument is untidy as it reveals things to the recipient that they don&#8217;t need to know and my paranoid self never likes to give too much away if I can help it.  But yes you are right any of those solutions are quite usable.  The regex really is there as an illustration of a point about typical Perl coding approaches rather than the way things should be done.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by chorny</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-14</link>
		<dc:creator>chorny</dc:creator>
		<pubDate>Sun, 26 Jul 2009 09:13:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-14</guid>
		<description>You need a &#039;Filename&#039; argument for $msg-&gt;attach only if it differs from real name or use &#039;Data&#039; instead of &#039;Path&#039;, so there is no need for file name extraction, just use &#039;Path&#039; argument. And in any case file name extraction is better done with File::Spec module (for example, it would work on VMS).

sitedesign: I prefer to use MIME::Lite even when sending through sendmail executable.</description>
		<content:encoded><![CDATA[<p>You need a &#8216;Filename&#8217; argument for $msg-&gt;attach only if it differs from real name or use &#8216;Data&#8217; instead of &#8216;Path&#8217;, so there is no need for file name extraction, just use &#8216;Path&#8217; argument. And in any case file name extraction is better done with File::Spec module (for example, it would work on VMS).</p>
<p>sitedesign: I prefer to use MIME::Lite even when sending through sendmail executable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by sitedesign</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-13</link>
		<dc:creator>sitedesign</dc:creator>
		<pubDate>Sun, 26 Jul 2009 03:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-13</guid>
		<description>Would also like to point out that of the various options available there are not enough options that deal with direct email to smtp servers.  Most bash options such as mutt and mail require there be a local MTA installed.

The reasons behind the above two scripts was for an option that sent email directly to a SMTP server and not via a local MTA.

Being a python fan, I have to admit that I would probably choose the perl script for it&#039;s simplicity.

A database person we know said he likes perl because it, &quot;Is still a scripting language and does what you need it to do without too much effort.&quot;

I would add that is true, but only after you get your head around perl.

I had a look for a good netcat script but found none.</description>
		<content:encoded><![CDATA[<p>Would also like to point out that of the various options available there are not enough options that deal with direct email to smtp servers.  Most bash options such as mutt and mail require there be a local MTA installed.</p>
<p>The reasons behind the above two scripts was for an option that sent email directly to a SMTP server and not via a local MTA.</p>
<p>Being a python fan, I have to admit that I would probably choose the perl script for it&#8217;s simplicity.</p>
<p>A database person we know said he likes perl because it, &#8220;Is still a scripting language and does what you need it to do without too much effort.&#8221;</p>
<p>I would add that is true, but only after you get your head around perl.</p>
<p>I had a look for a good netcat script but found none.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by sitedesign</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-12</link>
		<dc:creator>sitedesign</dc:creator>
		<pubDate>Sun, 26 Jul 2009 03:30:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-12</guid>
		<description>Aaah, But as we discussed at work on Friday, you don&#039;t get to set a payload in the perl version.</description>
		<content:encoded><![CDATA[<p>Aaah, But as we discussed at work on Friday, you don&#8217;t get to set a payload in the perl version.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by admin</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-11</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Sat, 25 Jul 2009 05:17:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-11</guid>
		<description>I agree with Perl being more readable than Python in this case.  It&#039;s just nicer to look at too.  On the other hand Perl tends to hide function in plain sight too, which is why I used the regex next to &lt;a href=&quot;http://perldoc.perl.org/Getopt/Long.html&quot; rel=&quot;nofollow&quot;&gt;&lt;code&gt;Getopt::long&lt;/code&gt;&lt;/a&gt;.  So take another look at it, everywhere but the regex is readable, and Perl is known for its cryptic regex code: whereas while the Python example is long winded, nothing about it requires any real mental gymnastics to understand what is being done on any line.  So the illustration is that in one way Perl is more readable but in another Python is.  A dead heat yet again.

However if it was simply a choice between the two snippets of illustrated code, I certainly prefer the Perl because of its elegance and shear class, and would use &lt;code&gt;Getopt::&lt;/code&gt; instead of the code I&#039;ve used in the example.</description>
		<content:encoded><![CDATA[<p>I agree with Perl being more readable than Python in this case.  It&#8217;s just nicer to look at too.  On the other hand Perl tends to hide function in plain sight too, which is why I used the regex next to <a href="http://perldoc.perl.org/Getopt/Long.html" rel="nofollow"><code>Getopt::long</code></a>.  So take another look at it, everywhere but the regex is readable, and Perl is known for its cryptic regex code: whereas while the Python example is long winded, nothing about it requires any real mental gymnastics to understand what is being done on any line.  So the illustration is that in one way Perl is more readable but in another Python is.  A dead heat yet again.</p>
<p>However if it was simply a choice between the two snippets of illustrated code, I certainly prefer the Perl because of its elegance and shear class, and would use <code>Getopt::</code> instead of the code I&#8217;ve used in the example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on To Mail a File Elegantly &#8211; Python or Perl? by chorny</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/to-mail-a-file-elegantly-python-or-perl/144/comment-page-1/#comment-10</link>
		<dc:creator>chorny</dc:creator>
		<pubDate>Fri, 24 Jul 2009 19:03:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=144#comment-10</guid>
		<description>IMHO Perl version is way more readable than Python&#039;s. And if you want better command line parsing in Perl, you should use an Getopt:: module. In your case it would be Getopt::Long.</description>
		<content:encoded><![CDATA[<p>IMHO Perl version is way more readable than Python&#8217;s. And if you want better command line parsing in Perl, you should use an Getopt:: module. In your case it would be Getopt::Long.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Rewriting the Wheel: bin2hex &#8211; hex2bin by admin</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/code/rewriting-the-wheel-bin2hex-hex2bin/34/comment-page-1/#comment-9</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Tue, 11 Nov 2008 08:30:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=34#comment-9</guid>
		<description>Oh yeah, for those of you who think that this is the best way of doing things, here&#039;s a hint:

printf(&quot;0x%02x&quot;,c);

Not every solution fits the same problem.</description>
		<content:encoded><![CDATA[<p>Oh yeah, for those of you who think that this is the best way of doing things, here&#8217;s a hint:</p>
<p>printf(&#8220;0x%02x&#8221;,c);</p>
<p>Not every solution fits the same problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Random Passwords by sitedesign</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/scripts/random-passwords/14/comment-page-1/#comment-7</link>
		<dc:creator>sitedesign</dc:creator>
		<pubDate>Tue, 12 Aug 2008 10:57:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=14#comment-7</guid>
		<description>Just a hint.  If you are using Fedora and wish to use uuencode, you will need to install sharutils.

  # yum install sharutils

should do the trick.</description>
		<content:encoded><![CDATA[<p>Just a hint.  If you are using Fedora and wish to use uuencode, you will need to install sharutils.</p>
<p>  # yum install sharutils</p>
<p>should do the trick.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on NZ e-Commerce Payment Gateways by admin</title>
		<link>http://www.chesterproductions.net.nz/blogs/it/payments/nz-e-commerce-payment-gateways/9/comment-page-1/#comment-6</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Thu, 31 Jul 2008 10:12:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.chesterproductions.net.nz/blogs/it/?p=9#comment-6</guid>
		<description>Yes it&#039;s really hard to get good info on the payment gateways in New Zealand.  I&#039;m not sure that even this write up is really that good.  However you are quite correct about the gateways being able to be broken up into classifications; but I&#039;d do it differently.

Of course first you need to know that I help to run some of the gateways on behalf of some of the banks.  We provide access for merchants to gateways and wallet systems, others use our products in value-added reseller models who then directly interface with merchants.

So the three categories are:

1. Gateways - simple API&#039;s into the banking system like CardPay and BuyLine.

2. Wallets - Paygo, Paypal and others where the money is held by another organisation on your behalf in a virtual wallet.

3. Resellers - like Paystation, flow2cash and SecurePayTech that focus on delivering products to merchants with value added services, like integration and troubleshooting support, advanced merchant reporting, PCI compliance etc.

DPS does most of these things and is the dominant player in the market.  But I suspect is this is mostly due to visibility not real service or price.  (bias warning: I don&#039;t work for DPS).

Each bank has its own preferred gateway so I suggest that you look at your merchant&#039;s bank and ask them which they prefer.  Your merchant has some vested interest in this too as they will need to know the terms, conditions, risks and costs of doing business through whichever gateway is chosen and may wish to shop around.

Lastly:

- Do not handle the customers card details EVER,
- Know all parties involved in the transaction process,
- Minimise your risk and your customer&#039;s,
- Keep it simple, and,
- Make sure you meet your customer&#039;s needs.

Good luck to you and your client.</description>
		<content:encoded><![CDATA[<p>Yes it&#8217;s really hard to get good info on the payment gateways in New Zealand.  I&#8217;m not sure that even this write up is really that good.  However you are quite correct about the gateways being able to be broken up into classifications; but I&#8217;d do it differently.</p>
<p>Of course first you need to know that I help to run some of the gateways on behalf of some of the banks.  We provide access for merchants to gateways and wallet systems, others use our products in value-added reseller models who then directly interface with merchants.</p>
<p>So the three categories are:</p>
<p>1. Gateways &#8211; simple API&#8217;s into the banking system like CardPay and BuyLine.</p>
<p>2. Wallets &#8211; Paygo, Paypal and others where the money is held by another organisation on your behalf in a virtual wallet.</p>
<p>3. Resellers &#8211; like Paystation, flow2cash and SecurePayTech that focus on delivering products to merchants with value added services, like integration and troubleshooting support, advanced merchant reporting, PCI compliance etc.</p>
<p>DPS does most of these things and is the dominant player in the market.  But I suspect is this is mostly due to visibility not real service or price.  (bias warning: I don&#8217;t work for DPS).</p>
<p>Each bank has its own preferred gateway so I suggest that you look at your merchant&#8217;s bank and ask them which they prefer.  Your merchant has some vested interest in this too as they will need to know the terms, conditions, risks and costs of doing business through whichever gateway is chosen and may wish to shop around.</p>
<p>Lastly:</p>
<p>- Do not handle the customers card details EVER,<br />
- Know all parties involved in the transaction process,<br />
- Minimise your risk and your customer&#8217;s,<br />
- Keep it simple, and,<br />
- Make sure you meet your customer&#8217;s needs.</p>
<p>Good luck to you and your client.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
