The SitePoint PHP blog has made an update to their "Being a Full Stack Developer" article covering what it means to be "full stack" and various technologies that can be used (or skills to learn) to get there.

A full stack developer who can get from a prototype to full MVP (minimum viable product) is often considered a jack of all trades, master of none, and with good reason. To define the modern full stack developer, we first need to focus on what the full stack developer used to be.

The article talks about what it use to mean (back around the early 2000s) to be "full stack" and some of the things they needed to know. He then goes through the things you'll need to know now to be considered basically on the same level:

• [Basic] Server Admin / Devops
• Cloud [Services]
• Back End [Development]
• Front End [Development]
• Design
• Logging
• Mobile

He ends the post by answering the question "is it worth it" to be a full stack developer versus focused on one thing, basically boiling down to two things. First, that most devs aren't actually full stack (even if they say they are) and that it can help to have this experience to, at the least, be able to approach a wide range of projects easier.

There's an interesting article from Christian M. Mackeprang that tries to provide some definition to the term "full stack programmer" and what it really means to the job market.

Back around 2013, the term Full Stack developer started to come up in job descriptions and blog posts. Companies were realizing that hiring developers with expertise in only one language just wasn’t enough anymore. A web developer that can handle a variety of tasks and environments is considerably more useful, and was starting to become the norm.

[...] What is a full stack developer supposed to know, anyway? Job descriptions frequently mention combinations of frontend and backend technologies such as JavaScript and Node, PHP and jQuery, Angular and Spring, and many others. In reality there is a significant amount of information outside those realms that would improve someone’s ability to build a website, and gone are the days when you could stick with what you know and make a career out of a single technology.

He talks about the combinatorial explosion the number of possible technology combinations can cause and how the usefulness of specific posts/resources is dwindling because of it. He then talks about "hackers" as "antifragile programmers" being the ones that enjoy the exploration of the tools and systems and are not bothered by change. He also suggests that developers need good skills in time management and setting expectations to prevent too much "exploration time".

He finishes out the post sharing thoughts about redefining the roles we're actually looking for an the individuals we want to fill them. He offers pointers about gaining context around issues, understand tradeoffs and doing what other people don't like doing to make your way ahead.

On the Dutch Web Alliance blog today Stefan Koopmanschap talks about making technology choices, how flexibility comes into play and suggestions on what to do when things go wrong. He uses some of his own experience (and problems) to illustrate his points.

The amount of times I come into an organization that says any of the above is impossible to keep track of on one hand. Or even two. Most development shops for some reason have decided that they have a single tool that will fit the job. Always. I have to admit the current market is good for developers. There are many projects available, and not enough developers or agencies to work on all of them. [...] But too many times have I encountered projects where the used tool actually was not optimal for the project. I would like to make a case against starting with a full stack from the start. Obviously, this approach does not work for all projects, but too many projects start out small but with a full stack. I’m going to take an old project of mine as an example of how to start out small and not grow until you need to.

He talks about the project first, a transcoding tool that used a third-party service and generate a playlist once the process was complete. He shares some of his thinking about the technology involved (Symfony2 without the full Symfony2 stack) and the decision to go with Cilex. He also talks about database choices (PDO over Doctrine) and how starting with small pieces like this makes it easier to change things in the future (or when a roadblock looms ahead). Then comes the "what went wrong" part of the development - debugging the system without the direct access needed to view the logs. Instead he worked around it, made a simple endpoint to show the logs and output it via Twig templates.

The result of all this work, including changes and extensions, was still a very small and lean application that combined the power of the commandline with a simple but effective web interface. I am sure I could have done a similar thing with Symfony2, but the code would’ve been overkill. [...] It is important to realize that there is not always a need for full stack frameworks or huge CMS’es like Drupal. Sometimes you need to start small and just let it grow.

In this new post to the SitePoint PHP blog George Fekete shares some thoughts about what it means to be a "full stack developer" and what kinds of technology and skills are involved.

The barrier of entering the web development industry as a web developer is still low, but it’s getting increasingly complex. The dynamic nature of the whole industry makes requirements shift often to the most popular and “next best thing” tools and programming languages. Gone are the days when only one programming language or a very specific process was required from a developer. Nowadays programmers must know a range of technologies across multiple platforms in order to do good work.

He starts with his own definition of what the term "full stack developer" means and how it's different from what it meant even just a few years ago (like back in 2000). He breaks up the skills and technology into a few different categories:

• System administration
• Web development tools
• Back-end tech
• Front-end tech
• Design (including UX/UI)

Each item on the list includes a bit of context around the topic and a few items that could fit inside it. He ends the post wondering if it's better to be a full stack developer or not. Is being a generalist better than being a pro in a particular technology?

Users of the Sublime Text 2 editor already know how flexible and useful it can be in developing their own software. SitePoint has a new post that wants to help enhance that experience even more with a list of 10 essential plugins you can use as a full-stack developer.

When I started with web development a few years ago, Vim was my first choice of text editor. It was easy to work with and I could get the basics done without much hassle. [...] In spite of the “Vim vs Emacs” debate out there, about a year ago I decided to try out a native text editor and Twitter was abuzz with one of them (no prizes for the guessing which one.) The creators of Sublime Text say it’s a text editor you’ll fall in love with and, having worked with it for almost a year now, I must say I completely agree with them.

Among their "top 10" list are things like:

• Package Control
• GitGutter
• AllAutocomplete
• ColorPicker
• DocBlockr

Each item on the list comes with a link to the library, a brief description of what it has to offer and a screenshot (in most cases) of it at work.

Fabien Potencier has posted the second part of his "packing a Symfony app in one file" series with this look at the bootstrapping of the application. You can find the start of the series (including his intentions) in part one.

The most common way to create a Symfony project is to start with the Symfony Standard Edition: it defines a sensible directory structure for your project and it make things a lot easier when someone want to take over an existing project as he knows where the templates, the controllers, or the configuration are stored.

This part of the series looks at some of the configurations and settings you'll need to get the application up and working in a minimal way. This includes moving everything into one YAML configuration file including routing information. He shows how some bundles, bootstrap code and things to remove from the composer config.

Fabien Potencier has a new post to his site showing how you can package a Symfony application into one file, the first part of a series. It's not "packing" like you'd think with a phar, but more of an all-in-one file setup.

Sometimes, I'm wondering if I'm not just completely crazy. [...] his is yet another step toward my Quest of the PHP Holy Grail. But besides being a though challenge, there are many other reasons that makes it interesting for everyone. First, that's a good way to learn more about the Symfony internals and especially about the Kernel class. [...] Then, I want to showcase once more the flexibility of the Symfony core framework and the decoupling between all aspects of the framework.

He does talk about one more practical use - making bug reporting easier by having just one file that can reproduce the behavior you're seeing and is easy to drop in, self-contained. He issues a challenge to himself for the course of the series - is it possible to make a full-stack application in one file and in under 200 lines of code.

Lukas Smith has a new post to his blog today with his own take on the MicroPHP manifesto that was posted by Ed Finkler recently. Lukas shares his thoughts on when he sees each type of framework (micro/full stack) has its place and how the project or development team can influence this choice.

Ed's recent blog post labeled the The MicroPHP Manifesto got a lot of attention. [...] In general I totally agree with Ed on the point that we need more decoupled components in the PHP world. The timing seems a bit odd since exactly that seems to be an emerging trend with all the various libraries cropping up since PHP 5.3.

He gets into more of his thoughts comparing the recently popular microframeworks to the full stack, broad use case frameworks that try to provide everything you might need. He talks about the difference between them related to configuration over code and when he sees is a good shifting point to move from the simpler micro world to the full stack (hint: business logic).

So the key take a way point is that when choosing to go micro or full stack its very important to consider in what kind of company on what kind of products you are working on.

In a recent post to his blog, Michael Kimsal asks a question that I'm sure PHP developers everywhere are wondering - why did Google choose to go with Python as the programming language of choice for their new App Engine service.

TechCrunch is announcing Google's new "App Engine" service being launched this evening. The basic service is a full app stack hosted and managed by Google, providing a web framework (maybe I'm misreading this?) and the Google 'big table' database service. [...] My question is "why was Python was chosen instead of PHP?"

There's been some great responses since it was originally posted including everything from agreement to rationalizations for the move (though there is a fair amount of PHP and Python bashing going on - an obvious occurance).

The Zend Developer Zone has posted their latest podcast episode in their PHP Abstract series today. The show i shosted by Chris Hartjes again (see his previous show) and discusses the difference between "glue" and "full stack" frameworks.

Today's special guest is Chris Hartjes. Chris has been building PHP applications since 1998. Currently employed as a Senior Developer for the Cake Development Corporation, Chris has been labeled as an "agent provocateur" within the PHP community. [...] Today Chris is going to talk to us today about Glue Frameworks vs. Full Stack frameworks.

The show can be downloaded directly from here or, as always, you can drop the url to their feed into your favorite aggregator and get this and other great episodes of PHP Abstract.