<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Loïc Hoguin</title><link>http://disqus.com/people/7d00dbf0d2c34e41b694e7ad8fafda02/</link><description></description><language>en</language><lastBuildDate>Thu, 04 Jun 2009 11:10:56 -0000</lastBuildDate><item><title>Re: Cross-Domain AJAX calls using PHP | Md Emran Hasan (phpfour)</title><link>http://phpfour.disqus.com/cross_domain_ajax_calls_using_php_md_emran_hasan_phpfour/#comment-6378124</link><description>Please please please add some caching mechanism to your script. You do not want to allow some kiddie to flood another website using your script. Even 1-minute cache is enough, but just don't call this website everytime like this. Not only will it be slow but the other site owner might get angry at you.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Wed, 05 Mar 2008 17:26:10 -0000</pubDate></item><item><title>Re: Cross-Domain AJAX calls using PHP</title><link>http://phpfour.disqus.com/cross_domain_ajax_calls_using_php/#comment-2839004</link><description>Please please please add some caching mechanism to your script. You do not want to allow some kiddie to flood another website using your script. Even 1-minute cache is enough, but just don't call this website everytime like this. Not only will it be slow but the other site owner might get angry at you.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Wed, 05 Mar 2008 17:26:10 -0000</pubDate></item><item><title>Re: Cross-Domain AJAX calls using PHP | Md Emran Hasan (phpfour)</title><link>http://phpfour.disqus.com/cross_domain_ajax_calls_using_php_md_emran_hasan_phpfour/#comment-6378122</link><description>Indeed, filtering using REMOTE_ADDR is the best if both servers are yours.&lt;br&gt;&lt;br&gt;What's important to note, too, is that if curl_exec can't fetch the data for some reasons it will return false. That means that your script will echo nothing. People using it should take care on the javascript side to check the data they get and if it's empty display an error.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Thu, 06 Mar 2008 12:22:48 -0000</pubDate></item><item><title>Re: Cross-Domain AJAX calls using PHP</title><link>http://phpfour.disqus.com/cross_domain_ajax_calls_using_php/#comment-2839002</link><description>Indeed, filtering using REMOTE_ADDR is the best if both servers are yours.&lt;br&gt;&lt;br&gt;What's important to note, too, is that if curl_exec can't fetch the data for some reasons it will return false. That means that your script will echo nothing. People using it should take care on the javascript side to check the data they get and if it's empty display an error.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Thu, 06 Mar 2008 12:22:48 -0000</pubDate></item><item><title>Re: Difference form submission in Javascript</title><link>http://fliquidstudios.disqus.com/difference_form_submission_in_javascript/#comment-16081464</link><description>That's interesting indeed. Do you have any numbers showing how much it helps? Also, do you use it with xmlhttprequest queries? Because if you leave the form available for more input you'd need to reenable the correct fields too.&lt;br&gt;&lt;br&gt;A jQuery plugin would be great, especially one that could work side by side with the form plugin.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Tue, 30 Dec 2008 04:59:41 -0000</pubDate></item><item><title>Re: Weeding out the weak</title><link>http://fliquidstudios.disqus.com/weeding_out_the_weak/#comment-16081475</link><description>"Am I a raving lunatic or do I make some sort of sense?"&lt;br&gt;Probably both. While I applaud the initiative, and wish there was less bad code around here, I believe there is hundreds more 9-5ers than there is passionate developers. This makes improving things a lot harder. The problem is especially noticeable when the barrier of entry is very low, like with PHP and most other interpreted languages.&lt;br&gt;&lt;br&gt;The good thing is you'll probably get better recognition if you aim for higher standards and are vocal about it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Tue, 30 Dec 2008 05:08:55 -0000</pubDate></item><item><title>Re: Introduction to writing a REST server in PHP</title><link>http://fliquidstudios.disqus.com/introduction_to_writing_a_rest_server_in_php/#comment-16081501</link><description>200 Not Found -&amp;gt; 404&lt;br&gt;&lt;br&gt;I'm not sure if you mentioned it but isn't the point of REST to have resources like &lt;a href="http://example.org/mystuff" rel="nofollow"&gt;http://example.org/mystuff&lt;/a&gt; and to be able to use all 4 methods (GET/POST/PUT/DELETE) on that unique resource? Your example shows an URL per method instead of a unique URL that can be accessed using all 4 methods. That's kinda misleading.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Tue, 13 Jan 2009 09:53:19 -0000</pubDate></item><item><title>Re: Introduction to writing a REST server in PHP</title><link>http://fliquidstudios.disqus.com/introduction_to_writing_a_rest_server_in_php/#comment-16081504</link><description>Yes I might have been a bit too far but that's how far my understanding of REST goes (I look forward for more articles btw). According to the wikipedia link you gave, REST defines resources represented by a URL which can be accessed using different HTTP methods to do different actions. Having a different URL per action didn't seem very "RESTful". Good that it's cleared up.&lt;br&gt;&lt;br&gt;Oh and you might want to correct the "200 Not Found" that should be "404 Not Found" in your example, sorry for not having been more comprehensible about that earlier.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Wed, 14 Jan 2009 16:44:14 -0000</pubDate></item><item><title>Re: Difference form submission in Javascript &amp;#8211; follow up</title><link>http://fliquidstudios.disqus.com/difference_form_submission_in_javascript_8211_follow_up/#comment-16081529</link><description>Nice work, and thanks for the jQuery plugin, we'll definitely use it.&lt;br&gt;&lt;br&gt;I see from the code that it could work very well with the forms plugin and others, allowing you to use it to submit the form diff through AJAX. You'd still have to reenable all the disabled fields after the form gets submitted of course.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Sun, 01 Mar 2009 00:52:59 -0000</pubDate></item><item><title>Re: Difference form submission in Javascript &amp;#8211; follow up</title><link>http://fliquidstudios.disqus.com/difference_form_submission_in_javascript_8211_follow_up/#comment-16081531</link><description>One is an enterprise application that is used by people worldwide, some barely have dialup to access it so less bandwidth used is good, especially since a few of the forms have 30 fields or more including textareas. Another is a dating website that I ported to our framework a few months ago. The huge profile form definitely can make use of it.&lt;br&gt;&lt;br&gt;We'll probably also use it on a project we're going to do as a proof-of-concept of our framework (see link). It will be a kind of collaborative application that will include real-time chatting, file upload, some kind of wiki, calendar integration and more. Basically an user can create or join various teams, with each team having their own channels and tools. Teams have the option of making the whole team or any of their resources private and to control access to each. It will be made available both as a free service and as source along with a lengthy tutorial on its design and implementation that will be included in the framework's documentation. We'll use the framework's mailing list (and trac) to work on it, so feel free to subscribe and follow the project.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Mon, 02 Mar 2009 03:37:15 -0000</pubDate></item><item><title>Re: 5 development techniques to improve software quality</title><link>http://fliquidstudios.disqus.com/5_development_techniques_to_improve_software_quality/#comment-16081634</link><description>I'm a bit late on this but I'd like to comment still.&lt;br&gt;&lt;br&gt;The first point is the most important. And unfortunately it's almost never done. Always write functional specs before you start writing code. Define your project clearly and also define what you would expect to see in upcoming releases of your project, even if they don't make it for the first version. Then always update that document everytime your project changes. Keep it up to date.&lt;br&gt;&lt;br&gt;This has multiple advantages. For one, it allows you to plan correctly your project. If you have to work with other people, that document IS the reference for the project. Not the code. Not everyone is necessarily a coder in your team (if you write it for a client, he certainly isn't able to understand code). It also allows you to easily write a presentation of your project, since it's basically what the functional specs are. You can take chunks of it to insert into the user documentation directly, or to make slides for a conference.&lt;br&gt;&lt;br&gt;It may not be obvious at first, but writing a functional spec before anything else actually makes the process of writing an application both faster and easier. I would recommend reading Joel Spolsky's take on the subject, it is quite interesting.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Loïc Hoguin</dc:creator><pubDate>Thu, 04 Jun 2009 11:10:56 -0000</pubDate></item></channel></rss>