Leonid Mamchenkov has a post on his site that points out a great resource for all of the podcast fans out there, the Awesome podcasts list.

Awesome podcasts is a curated list of podcasts for software engineers. The list includes a whole lot of sections – one for each programming language out there, generic software engineering, tools, etc.

The list is broken down into sections for various programming languages and technologies such as C++, Git, Python, PHP, Java and Rust. There's also sections for different topics not covered by specific technology such as security, general web development and community/inspirational topics. The list is a GitHub repository so if you have a favorite podcast that's not already on the list, be sure to send in a pull request to get it added.

In this post to his site Jelle Raaijmakers dives into a script that's commonly injected into vulnerable sites and used by spammers to send messages without the knowledge of the site owner.

Let’s take a look at a PHP script used to send spam. These types of scripts run on servers all over the world and might give you some insight into a spammer’s dedication to annoy the hell out of you. Spammers abuse known flaws in unsecured websites and applications to break into a server and install scripts that are able to send loads of spam.

[...] Everyone running a mildly popular WordPress site knows that exploits can be really easily introduced by installing plugins from a less than reputable source – or by not keeping your plugins up to date. Sometimes, a zero-day exploit for a popular WordPress plugins becomes known and thousands of installations worldwide are infected at once.

He then goes through a script he found in an infected WordPress instance of his own on a shared hosting provider. He talks about what these kinds of scripts usually look like (an encoded eval injected into current scripts) and the process he followed to dissect it:

• Step 1: determine method of obfuscation
• Step 2: introduce newlines
• Step 3: replace the $j10 values
• Step 4: concatenate constant strings
• Step 5: replace function invocations
• Step 6: prettify the PHP code
• Step 7: remove default $j10 argument
• Step 8: decode the $pate payload
• Step 9: replace $_POST references
• Step 10: map function and variable names

It's not a super simple process, but in the end he's left with the complete PHP script that loads a remotely defined configuration, tries to send the emails and even retries if there's a failure. He includes a few noteworthy things about the script including STMP connection auto-detection and DNS lookups over UDP.

Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

Sherif Ramadan has a new post to his site today that tries to answer the question "what does a software developer really do?"

As a software engineer I have to learn to see things differently, because my job requires that I solve problems. Though not only is it important that I come up with a solution, but equally important that I can express the solution in code. [...] It is equally important to recognize that not all problems have technical solutions. Some problems are better solved by social solutions.

He talks about the influence that some of the major services have had on the social aspects of our lives and how they're mostly a "convenience to mankind". He suggests that the job of a software engineer has multiple aspects, and not just technical ones. They're required to see things differently, be able to understand the problem well and express the solution in a clear and practical set of code.

The engineer must figure out which problems are worth solving through technology, in order to save people time and money, and defer those which do not to more social means. Let humans do what they do best and computers do what they do best.

The Server-Side Magazine site has posted an interview (10 questions) with Andrei Alexandrescu, a research engineer currently working at Facebook.

Today we caught up with Andrei Alexandrescu for a "10 Question" interview. He is a Romanian born research engineer at Facebook living in the US, you can contact him on his website erdani.com or @incomputable. We will talk about some of the juicy stuff that going on at Facebook, so let's get started.

Their questions include:

• What's your development setup?
• What do you think of PHP as a language from your perspective, regarding that Facebook was initially written in PHP then transformed to C++ using HipHop for PHP. What are the pros and cons of using C++ over PHP at Facebook?
• Currently, what kind of research do you conduct at Facebook? (or is this confidential?)
• Tell us a little bit about the D programming language, in contrast to C, PHP, Ruby and others. In what fields can someone apply D?
• Also, what kind of advice can you give for developers who are considering to apply to Facebook? What kind of skills is Facebook looking for in a potential candidate. Is it really important to be a graduate CS? What kind of skills do the majority of Facebook employees possess?

Read the full interview for his answers to these and other interesting questions.

On 7php.com there's a new interview posted with Enrico Zimual of Zend - "Everything is an Array in PHP".

In this edition, I talked with Enrico Zimuel a computer geek since he was 9yrs old. He has written a couple of books namely "Secrets, Spies and Cipher Codes" published by Apogeo in 1999 and the recent "How to use the digital sign" published by Tecniche Nuove in 2010. Enrico has a pretty impressive 'geek' path. He also speaks at many international conferences [...]. You can find his presentations on slideshare.

Questions in the interview include:

• How do you find PHP now as compared to when you first started?
• Based on your experience, what are the good and bad parts of PHP?
• To someone who wants to become a better PHP developer, what is your advice?
• What are some good PHP blog or resources you highly recommend?

Read the full interview here.

On IT World there's an interesting article about the programming skills that seem to be lost in today's coders and how what they may not know might hurt them in the end.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

Padraic Brady has a new post to his blog asking you, the reader, for your suggestions on how to architect a distribution system for the PEAR2/Pyrus components.

With the idea of PEAR2 and Pyrus, I had hoped to see a renewal – the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme. [...] If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model.

He breaks up his thoughts on the future of PEAR2/Pyrus distribution into a few different topics - the issues he sees surrounding packaging (like static packaging definitions), suggestions for a dynamic channel aggregation system and overall usage of the PEAR system.

According to Chris Aitchison, you're not a "software engineer" if you write code an develop applications - you're a "software gardener":

The engineering metaphor has had its time in the sun, and maybe it even used to be accurate, but now it really only serves to help non-technical people have unrealistic expectations about how software gets built.

The post describes software development as gardens instead of feats of engineering. It talks about the organic nature of development, how no matter the course that's plotted, there'll always be things that can't be anticipated ("weeds") that will need to be handled. It's not about the technology behind the product (anyone can build the same bridges) but more about how its nurtured by the developers. It's an interesting perspective and I'd recommend giving it a read as well as the large amount of comments that come with it.

If you've heard all about the CodeIgniter Reactor project (the community powered branch of the popular framework) and have wanted to get involved, now's the perfect time. Because of a change in the ranks, they're looking for another Engineer to fill an open spot.

If you follow the Reactor team, you probably already know that the venerable Ed Finkler had to resign from his position due to personal time constraints. That means that we have an opening, so if you feel that you qualify, please email iwanttohelp at codeigniter dot com.

The email needs to include your CodeIgniter username, a link to your profile, three contributions back to the framework and a paragraph stating why you think you should be the new Engineer.