Davey Shafik has an interesting post to his site sharing some of his views on the "syntax" of different programming communities - PHP, Ruby, Python and Perl.

In my (almost) three years of being in a developer relations type role I have attended events in several communities and have observed how they differ from my primary community (PHP). As I’ve tried to understand those differences and the reasons behind them, I have had many discussions with members of many more communities also.

After attending my first PyCon (US) I was struck by just how welcoming and diverse the community is and had many conversations trying to understand why this is. This is not what this post is about. This post is about conferences specifically, and how communities place different priorities on different things when it comes to how they run, organize, speak at, and attend events.

He talks about conferences - both attending and speaking at them - and how the situation differs from community to community. He did some background research on why things are they way they are and how that has influenced the overall focus of the community.

On the SitePoint PHP blog Phil Sturgeon has written up a comparison of the PHP language versus Ruby suggests that we all just get along from the perspective of a developer that works with both happily.

Quite often you see developers who have a lot of experience in one language try to play with another, then make a rather quick comparison between the two. This comparison is usually quite worthless, but the clickbait titles get them a lot of traffic.

Instead of doing that, I thought it would be interesting to have a slightly more fair comparison, from the perspective of someone who really enjoys writing both PHP and Ruby, and has done so for years. The aim here is not to find out which is “better”, but to point out a few key things I like about Ruby and its ecosystem.

He starts with some of the basics conceptual differences between the two languages including the differences with methods/variables/properties and type hinting versus duck typing. He also covers some "fun features" of each language including:

• Nested classes
• Using debuggers (and the tools offered)
• "Unless" handling
• Predicate methods
• Shorter array syntax (in Ruby)

There's many more mentioned through the end of the post too, so be sure to check out the rest in the remainder of the article. Each point come with some brief code examples show how the feature is implemented depending on which language is being discussed.

Lee Blue has started up a series of posts talking about his reasoning for moving back to PHP from Rails in his applications. In his first post of the series, he looks at application "shelf life" and the overall lifespan of the project and how that relates to things like maintainability and upgrade handling.

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.

He talks about the "rotting on the vine" that one of his clients' Rails 1.0 application faced when the later versions of the Ruby on Rails framework. He talks about how these kinds of upgrades cost money (and time) and how, with the right selections for the deployment stack, some of the costs could be alleviated. He gives the example of a PHP-based deployment setup and how much of the related technology has been stable and (mostly) unchanging over the years, just with new features being added. He offers a few suggestions to avoid this "app rot" and things startups/freelancers can do to help prevent it in their clients' applications.

The Full Stack Radio podcast has released their latest episode today - Episode #3: Ruby, PHP, object oriented design, testing and other crap with Matt Machuga, with host Adam Wathan.

In this episode, Adam talks with Matt Machuga of Think Through Math about being a Rubyist who still writes PHP and the differences between writing PHP like a Rubyist vs. writing PHP like a Java developer. They also talk about common struggles when learning new things, and trying to remain pragmatic while still pushing the boundaries of what you know.

Links in the show notes include Matt's personal website, DHH on dependency injection and a book on Domain Driven Design. You can check out this episode either using the downloading the mp3. If you enjoy the episode, be sure to subscribe to their feed.

Till Klampaeckel has a new post today showing how to get your Composer installation (and package install) to work a bit faster on the Amazon AWS OpsWorks management system.

At EasyBib, we're heavy users of composer and AWS OpsWorks. Since we recently moved a lot of our applications to a continuous deployment model, the benefits of speeding up the deployment process (~4-5 minutes) became more obvious.

He talks some about the current needs of their deployment process and how one option - symlinking the "vendors" directory just wouldn't work. Instead, they make use of Ruby and Chef to work with the OpsWorks hook system that fire on deployment. He includes the example Ruby scripts they put in place to handle "before migrate", "before symlink", "before restart" and "after restart" events. This new setup saved them about two to three minutes on their total deployment time and resulted in a much more stable environment.

Adam Bard has written up a post that takes the same small application (a "Nurblizer") and writes it as a web application in four different languages - PHP, Python, Ruby and Clojure. His point is less about which is "best" but more to show the differences between them.

Here’s a toy program I wrote implemented in PHP, Python, Ruby, and Clojure. I hope it’s helpful for someone who knows at least one of those and wants to learn another. The program is called “Nurblizer”, and it does one thing: Accept free-form text, and attempt to replace all words but the nouns in said text with the word “nurble”. It’s up and running at http://nurblizer.herokuapp.com

He includes the source for each language's version using Sinatra for Ruby and Flask for Python but for PHP and Clojure it's just straight code. For each he briefly explains what its doing and a bit about how it relates to the examples from the other languages. He also points out a Hacker News discussion that's popped up about the examples.

The /Dev/Hell podcast, as hosted by PHP community members Chris Hartjes and Ed Finkler, has posted their latest episode - Episode 28, "Canadian Twinkie Smuggler".

You can blame Chris’s tomfoolery for how crappy he sounds, because his computer pooped all over himself and he had to call in on his iPhone. Nevertheless, we were able to discuss in detail the smuggling of mass-produced pastries of the Twinkie and Tastykake varieties. We also get framework security in the context of recent Rails vulnerabilities, and how PHP developers seem to have a heightened awareness of potential vulnerabilities. Ed’s details his experiences starting a local user group, and then discusses his efforts to speak at developer/tech conferences about his struggles with mental illness.

You can listen to this latest episode either through the in-page player, by downloading the mp3 directly or by subscribing to their feed and getting this and other recent episodes.

In this new post Lee Blue has gone through and compared Ruby and PHP in a "year end review" of their current statuses and what each of them have to offer:

Now that I’ve been working with Ruby in much more depth and both PHP and Ruby have matured dramatically over the past five years it is time to reevaluate the comparison. The previous article was primarily centered around the languages themselves and was not a showdown between any particular frameworks. In this review we will touch a bit more on frameworks, but in the context of a high level review of the two different landscapes of PHP vs Ruby for web development. We will not be getting down to feature-by-feature detail.

He talks a bit about the history and purpose of each of the languages and a good bit about the web frameworks that are available for each (hint: the PHP options are quite a bit more). He also talks about web hosting vs web application hosting and then compares the two languages with a "score card".

The bottom line, as always, is pick the solution that is right for you and your development team. My hope is that this article was helpful in shedding some light on the strengths of both PHP and Ruby, spreading the word about what is available to both languages, and helping you decide what is right for your next project.

If you practice the TDD (test-driven development) methodology in your work, you know that sometimes switching back and forth between a terminal and your IDE can be distracting. In this new tutorial from NetTuts.com, they show you how to streamline things a bit with a simple Ruby script.

Traditional test-driven development can, at times, be cumbersome. You have to stop writing code in order to run your tests. Luckily, there are solutions, which provide the ability to automatically run your tests as you code. In this tutorial, you will learn how to use a Ruby gem, called watchr, to monitor your code and automatically run the appropriate tests whenever you save your work.

The IDE doesn't matter in this case because the "watchr" tool keeps an eye on when things change in the watched directory and automatically fires off a script when it sees an update. They include the few short lines of Ruby to make it all happen and even have the "notify-send" command built in to give you a popup about the pass/fail status.

On DZone.com Giorgio Sironi shares what he describes as his "standard PHP setup" - the tools and standards he commonly uses when developing his projects.

Last week I passed a day speeding up a Java and Ruby oriented team which started developing a PHP application: not only a standard project structure was required, but also some hints on the default tools and process to work with it. Here's what I thought was crucial during the setup, based on the question of my Rubyist colleague. Of course one of the most visible differences is the language itself, but there is a lot more tacit knowledge to share.

Things mentioned in the post include: development tools (like IDEs), the language itself and similarities to other languages, a standardized project setup, a good testing methodology and a bit of discussion about using external libraries.