News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Christoph Rumpel:
10 Things That Will Make You a Better Developer
December 15, 2014 @ 10:56:19

Christoph Rumpel has posted a list of ten things he thinks will help you be a better programmer overall.

It is easy to become a web developer these days. The only things you need is a computer and Internet. But I believe there is big difference between a developer and a good one. Good developers are like little heroes. They are awesome in what they do and are there when you need them. A real benefit to the our world and definitely someone you can look up to! I believe everyone can make this step and start being a better developer today. This is why I asked great developers from all around the world what they think makes someone a really good developer.

His list covers more than just good coding practices too. He suggests things like:

  • Experimentation
  • Reading the code of other good developers
  • Just build websites
  • Contribute to other projects
  • Watch out for the Hypetrain
  • Never give up

He includes a quick summary of each of these and the rest of the top ten list too. Be sure to check out the full post for more.

0 comments voice your opinion now!
top10 better developer opinion list


Lee Blue:
PHP vs Ruby - Application Shelf Life
December 10, 2014 @ 13:19:15

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.

0 comments voice your opinion now!
ruby shelflife application rot version deployment stack opinion rubyonrails


Eric Wastl:
Your Job Is Not to Write Code
December 04, 2014 @ 09:05:04

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.
0 comments voice your opinion now!
software engineer write code opinion correction medium

Aspect Orientated Programming - thoughts?
December 03, 2014 @ 11:19:18

On the /r/php subreddit on JustSteveKing asks the community about Aspect Oriented Programming. Aspect Oriented Programming makes use of cross-cutting concerns (modular functionality) along with encapsulation to make for more modular code.

What are the general thoughts on AOP? Anybody using it? After reading several articles and tutorials on the matter I have to admit it seems to have its plus points. The only thing I am wondering at this point is why is it not a widely adopted as MVC, I mean there must be a reason?

Most of the comments either fall into two categories. Either the commenter has made use of it in a limited fashion (like logging) or doesn't use it at all. There's also a good comment about some of the risks involved in its use and the "magic" that can come with it. Additionally, there are links to other articles for those wanting a good introduction to AOP and what it can do.

0 comments voice your opinion now!
aspectoriented programming aop opinion adoption


Anthony Ferrara:
A Point On MVC And Architecture
December 02, 2014 @ 12:10:24

Anthony Ferrara has posted another in his series looking at MVC as a design pattern and as an idea for building web applications. In this latest post he goes on to make a point about MVC, how it relates to architecture and CRUD.

Last week I post a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I'm still working on it. It's a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

He responds to the comment (essentially that CRUD is a solved problem) and where the need for customizations is needed. He suggests what the real problem is, though: the three classes of developers - CMS users, custom developers and users of both.

0 comments voice your opinion now!
mvc architecture opinion problem crud comment response


Mattias Geniar:
The PHP circle from Apache to Nginx and back
November 20, 2014 @ 10:26:28

In this new post to his site Mattias Geniar goes in circles...from Apache to Nginx and back in terms of how it relates to PHP.

As with many technologies, the PHP community too evolves. And over the last 6 or 7 years, a rather remarkable circle has been made by a lot of systems administrators and PHP developers in that regard.

He talks about the "early days" and the rise of Apache as the "A" in the LAMP stack. Then Nginx was created/released and PHP developers saw it as a viable option. He talks about how PHP worked with this server and the solutions that were found to "hack" them together. There were issues around the relationship, though, and - in the author's perspective - the circle has come back around to Apache, just with a bit more smarts about how it's configured.

0 comments voice your opinion now!
circle apache webserver nginx opinion configuration phpfpm


Matthias Noback:
Packages the case for clones
November 17, 2014 @ 11:55:21

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

0 comments voice your opinion now!
package reinvent wheel opinion duplication design principles phpfig clone


Anthony Ferrara:
Foundations Of OO Design
October 30, 2014 @ 09:36:24

In his newest post Anthony Ferrara looks at some of the things he calls the foundations of object-oriented design, as set of three things (and principles) to keep in mind when working on OOP applications.

It's quite easy to mix up terminology and talk about making "easy" systems and "simple" ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

He starts with the "simple vs easy" concept and how sometimes making the two meet can be difficult. He includes an example of interdependent interfaces and how they add complexity (and, in turn, make them less easy to use). He also talks about accidental versus essential complexity and how, sometimes, "accidental" isn't always a bad thing. Finally, he wraps it up with a few principles to remember in your development including recommendations to reduce (accidental) complexity and keeping the target developers in mind, making it easiest for them to use.

0 comments voice your opinion now!
foundation oop objectoriented design complex simple developer opinion


Anthony Ferrara:
Educate, Don't Mediate
October 21, 2014 @ 11:53:55

In his latest post Anthony Ferarra makes a suggestion about teaching developers how to solve problems via a "quick fix" versus educating them about the real problem: educate, don't mediate.

Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about "The Dreaded eval(base64_decode()) - And how to protect your site and visitors" have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad. The problem is that these posts have been suggesting things like "Disable eval()" and "Disable base64_decode()" as possible solutions. And while technically that would work, it completely misses the point, and does nothing to protect users

He suggests that developers shouldn't just look for a "quick fix" solution posted in a tutorial somewhere and go on their merry way. One danger in this is that those instructions could only be patching part of the problem, not all of it. In this case, the disable eval/base64 handling is only a code-level fix. If this exploit exists in your application, the attacker was able to get to the local file system - a much bigger problem.

0 comments voice your opinion now!
educate mediate opinion bugfix quickfix eval base64 encode decode


Phil Sturgeon:
PHP Wars Attack of the Clones
October 21, 2014 @ 10:18:02

In one of his recent posts Phil Sturgeon talks about what he calls the "Attack of the Clones" on Packagist. In this case, he's referring to the number of packages that all pretty much do the same thing, just in slightly different ways.

n the last article I said I wanted to write about when its a good idea to release a component. A lot of this comes down to: is there one out there that does what I want, and if so, can I use it. This blog post is going to touch on a lot of points already made well by Anthony Ferrera. His article Reinvent The Wheel! says many of the same things, so if you only have time to read one article right now, go and read that. I've been talking with various people on Twitter about how I see a lot of people building what I consider to be clones. [...] It should go without saying that I'm not trying to quash innovation; I just don't think building identical shit over and over again is innovation. I see people wasting their time, and I know that time could go to better use.

He talks about how he's not opposed to innovation and development for the sake of learning, but that often the packages released are lower-powered versions of already established, well-tested packages. These kinds of packages can clutter the results when the packages are searched and prevent developers from finding the best fit for what they need. He mentions frameworks, but doesn't dwell on them as they're a bit more "self-contained" than just packages. He also touches on the curation of packages (guiding people to the right ones) as a possible solution and looks at how some of the other communities out there handle this same problem.

0 comments voice your opinion now!
clones package opinion curation learning innovation community


Community Events

Don't see your event here?
Let us know!

community artisanfiles podcast series tool opinion voicesoftheelephpant interview conference version symfony list composer language laravel release introduction framework library security

All content copyright, 2014 :: - Powered by the Solar PHP Framework