Never thought that I would write a post with the ease of VIM in the title. But honestly I tried a lot of editors still coming back to VIM. VIM is a lot more hackable then Atom.

Probably because I like bash, python and javascript, while Atom is javascript hackable only.

VIM is not easy at first sight, and certainly not easy at first touch. Counterintuitive to the noob, all the difference modes VIM can be in, you somehow love it after a while.

Try the VIM editor

If you’re interested just try it out.
apt install vim

Run vimtutor after you installed VIM. I surely recommend the great VIM casts, of Drew Neil. Excellent learning stuff. Best to watch after you installed VIM and tried the VIMTutor.

Back to the title, the ease of VIM for productivity. Sure you need to extend it and use plugins. UltiSnips is one of my favorite.

Use snippets with UltiSnips

A good setup of snippets are a real time saver. There are pre-installed snippets, but you need to setup your own snippets, because they reflect how you think, and they should suit into your workflow.

For testing sites on Apache, or protecting a WordPress login from, you often use access control,  to restrict access to portions of your site based on the host address of your visitors.

You create a Deny Allow directive  for that in .htaccess.

order deny,allow
deny from all
allow from [your-ip]

Create a deny allow snippet

To speed up inserting earlier code in any .htaccess file your editing in VIM/GVIM, create a apache.snippets file in your UltiSnips directory (~/.vim/UltiSnips by default), and add this to the file:

snippet deny "Deny allow snippet" b
order deny,allow
deny from all
allow from `curl ipinfo.io/ip`
endsnippet

Done, every time you type `deny` hit tab and the snippet is inserted with the ip-address of the computer you’re working on. Through  `bash interpolation`, the snippets insert the output of the command `curl ipinfo.io/ip` which is the linux way of getting your ip-adress. Compare that to Microsofts Windows way. Never say again that Linux is not easy.

So, easy after all, isn’t it? That’s why I call VIM easy. Of course it isn’t actually, but there is beauty in the way it works, and the way you can make it work, fast en easy.

Errors give valuable information, it’s worth paying attention to.

Sometimes though when parsing content from different sources you can run into errors you can prevent, or you can’t solve.

Reading something into simpleXML that isn’t 100% validated XML, because it’s encoded in ISO-8859 instead of UTF-8.

Then use the PHP one error control operator @.

When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored.

Tha comes quite in hand in the following piece of code :

$xml = @simplexml_load_file('rssfeed.xml');

No more errors.

It is tempting to simply generate CSV data with writing comma-separated  array-values.

implode(",", $data_array);

Unfortunately this obvious way of doing turns out to be a bad idea. Often it seems to be working at first, but eventually you’ll be faced with annoying bugs, wrongly escaped data.

Fortunately, PHP has a native function to write CSV values to a file.

fputcsv()

With a little trick you can use this function to write values to the screen.
Use the built-in streamwrappers:

 $outstream = fopen("php://output", 'w');
 fputcsv($outstream, $data_array, ',', '"');
 fclose($outstream);

This will echo the data to the screen.
Most people won’t know `php://output`. A pity it’s really powerful.

Consider an RSS feed read in as an SimpleXMLobject $rss.

What’s the difference between:

foreach ($rss->channel as $channel) {
...
}

and
$foo = $rss->channel;
foreach ($foo as $channel) {
...
}

Not much you would say, the first code example is shorter and more to the point. However when putting the scripts to work, (with a big rss file) we’ll soon see the difference.

Memory problem and a growing swap file

After a while the former example is causing a lot of disk activity and you will see your swap file grow and grow, at my computer it reached the maximum of 4 GB and off course it took ages for the script to finish.

And all that while the maximum memory usage for a script is set to 24MB in php.ini. Should run in a 1G computer you would say.
Well example 2 does but example 1 does not!

Is seems that iterating over an object-property in a foreach loop is troubled by a memory leak.

Solution

Example 2 is the workaround!

Conclusion

PHP 5.1 until 5.2 seem to suffer from this memory leak.

Technorati Profile
No further use. 🙂