Danny van Kooten has an interesting post on his site sharing his experience in converting a Laravel-based application to Go, briefly describing some of the changes made, performance differences and the lines of code required.

Earlier this year, I made an arguably bad business decision. I decided to rewrite the Laravel application powering Boxzilla in Go.

No regrets though.

Just a few weeks later I was deploying the Go application. Building it was the most fun I had in months, I learned a ton and the end result is a huge improvement over the old application. Better performance, easier deployments and higher test coverage.

He talks about why he selected Go and some of the external services he would need to interface with to make the transition complete. He then gets into the actual porting of the codebase and some of the challenges involved to replace Laravel functionality. With the application ported, he then compares the performance of the Laravel application versus the Go version, sharing the request of requests/second for each. He finishes out the post looking at a lines of code comparison between the two and how testing was handled on the Go side.

in a new post to his site Phil Sturgeon talks about a new (old?) proposal to introduce named parameters into PHP.

Named Parameters for PHP is not a new conversation. It's reared its head several times - so much so that the named parameters RFC says: "Since the topic continually gets re-raised, and now PHP has an RFC process, the discussion should be recorded in an RFC (Note this is yet to be done) so the same arguments don't have to be revisited."

He notes the negative attitude that seems to currently be shown in the RFC and has made the offer to rewrite it to be more impartial to the subject at hand. In the comments of the post there's also some feedback about the different syntaxes and varying levels of support for the proposal.

Keith Casey has an interesting new post to his site looking at a common dilema among development groups - whether refactor or rewrite is a better option for the state of the current codebase when it comes time for a change.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.

Hasin Hayder has a quick post to his blog today about how you can configure an AppFog instance to be able to run Zend Framework-based projects on them.

AppFog is quite a popular polyglot PaaS (Platform as a Service) provider and it comes with a generous free plan for the developers. [...] Recently, I was looking for a solution on how to host a Zend Framework based application in AppFog. The main problem was that the url must point to the /public folder inside the app and from there it is initialized. After searching for some time, I found the clue in AppFog's doumentation which is you'll have to redirect all the traffic from the parent domain to the /public/index.php file using the URL rewrite rules.

The rewrite rules are included in the post for easy cut-and-pasting. With the recently announced closing of their phpFog service (in favor of just supporting AppFog) I'm sure this tip could come in handy for a lot of developers out there.

Adam Culp has published the fourth part of his "Clean Code" series to his site today (see more about parts 1-3 here) with a look at the "Rewrite Dilema" - whether it's more productive to just rewrite or to try to refactor.

Unfortunately the first reaction to a poorly written application is usually a resounding “rewrite”. Developers feel like a weight is lifted from their shoulders, as the manager hears a distant “cha-ching” sounds of money slipping away. [...] In the managers mind a rewrite means it must all be duplicated, and that’s not far from the truth when we consider the salaries of an entire development team for the time it will take to rewrite the entire application.

Adam talks about some of his experience in the past with challenging applications and a typical scenario where one group in the company splits off and creates the new version while another maintains the old. He suggests, however, that refactoring may be a more viable option. While it might not seem easier to handle overall, the end results could lead to a more stable system and could take less time than starting from scratch.

The PHP.net site as new post with some supplemental information for those users of the PHP CGI that might be effected by the recently announced bug, the reason for the most recent release. Unfortunately, this patch only fixes some of the cases of the problem, so they've amended their instructions to included a more effective mod_rewrite rule to help protect your applications.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

In this new post to his blog Gaurish Patil shows users of the Yii framework how they can update their configuration settings to hide the "index.php" in their requests and make cleaner URLs.

Finally we figure out the basics of Yii. While working on basic of Yii, I want to rewrite the url to SEO friendly. So I started to search on google, forum got useful information here http://www.yiiframework.com/doc/guide/1.1/en/topics.url To hide the index.php from url I did changes in config/main.php [...] and I created new .htaccess file in the same directory as my index.php file.

The changes are pretty simple - it's mostly a change to the "urlManager" setting to provide some rules for mapping controller and actions to the right place. The .htaccess file uses Apache's mod_rewrite functionality to grab the requested URL and remap it back to lay on top of the "index.php" front controller for the request.

In a recent post to his site Keith Casey mentions something that should be obvious to most software developers (and managers of developers out there) but is easy to forget - technical debt doesn't just disappear, even if the related resources change dramatically.

Just because you set a codebase aside and do it the "right" way, your problems don't disappear. The same bugs that annoyed people yesterday will be there today and tomorrow. In fact, when the bugs are still there a week, month, or year from now, they move beyond annoyances and into frustrations as people think (or say) things like "this has been broken for years.. why haven't they fixed it!?"

He notes that, while tossing the entire codebase out the window and starting over again (a move very, very rarely shown a good idea), you'll still end up with issues - this time involving resources and the work needed to sift through all of the bugs in the new code.

On his PHP Genious blog Timir Shah has written up a new post looking at how you can configure URL rewriting (much like mod_rewrite) in an IIS7 web server running PHP applications.

Few days ago, I faced a URL rewriting problem on windows server. After checking the server configuration, I found that there is an II7 installed. After long research about this, I found that II7 is not support .HTACCESS. If youwant to male your site SEO URL friendly, then you have to use web.config file for URL rewriting instead of .HTACCESS. Now the question is how to make web.config file from .HTACCESS?

He compares the two formats, showing how different directives from the .htaccess file can be translated over. He starts with an example of default documents on either side - the .htaccess defining several "php_value" settings and the web.config setting some default routing and rewrite rules. He shows how to set up a few things on each side - error page redirects and setting up some custom URL rewrite rules for both sides (with examples).