Symphony.

TTD

Textually transmitted disease.

This is the only way to get things right from the beginning.

Agreed.

This is the only way to get things right from the beginning.

Let's not try to focus on getting things right from the beginning... that would slow down development until absolute freezing point. We can wait a decade for the next version of Symphony to become available if we want to get things right from the beginning.

Don't understand me wrong: I think we should really think this through, but we should also timebox the amount of time spent on architectural design. Isn't the whole point of agile development that we learn from our mistakes?

@remie makes a valid point; useless to go on an unending discussion. Setting timelines and a 'date' where we'd like to take a cut off point on directions and structures would be important.

But I guess things like standards & conventions should still be agreed upon first. You don't want every developer to use his own structure when submitting pull-requests. its double the work.

I don't say we have to do things right from the beginning. We are going to run into a lot of errors and missconceptions. It's just the way how we do it.

Yeah, but I think we can also have very lengthy discussion on the how part... at some point we just need to pick something and go with it. In a year of three we can throw it all away again and choose for something else.

Perhaps a valid approach is to create a coding exercise for 2 or 3 frameworks and create teams to solve it with a fixed deadline. Based on the outcome of the exercise we can then choose the framework that suits best.

This is apposed to posting this and that links to make a point.

TTD

Have you double-checked that this is part of POOP?

It is.

And yes, TDD stands for test driven development, although I'd opt for:

Textually transmitted disease

This might be a good start for everyone who's interested. And for all UI devs out there: have a look at Selenium and phpUnit.

Thanks @iwyg. I'll have a watch and read.

Back when I was messing about with Rails I did manage to get automated tests working, complete with sad red/happy green smiley icons appearing in OS status notification messages on every file-save by following tutorials, which I thought was very cool, but I haven't tried it in PHP yet.

Have you double-checked that this is part of POOP?

And it establishes PEE (Perpetual error eradication).

This might be a good start for everyone who's interested.

Great article. Rereading! Completely agree about TDD to minimize headaches down the road.

at some point we just need to pick something and go with it. In a year of three we can throw it all away again and choose for something else

It's all about shipping!...but hopefully nothing will need to be thrown away after a couple of years, rather just swapped and iterated over time on a flexible foundation. :)

So what's the next step now that the Symphony Godfathers and prodigies have thrown their hat into the ring as being in favour? Is a more detailed framework evaluation required now that the principle has been provisionally approved? What are the key considerations applied specifically to Symphony with regard to the philosophy, approach and implementation (such as a hot-swappable template layer). Do the specifics need to be listed and ensured it's possible in the framework of choice?

so we have

• POOP
• PEE
• CRAP (common recursive acknowledgement penetration)

anything else?

So what's the next step now […]

https://github.com/symphonycms/symphony-next/issues/4

This might be a good start for everyone who's interested. And for all UI devs out there: have a look at Selenium and phpUnit.

I've also started to looked at using CasperJS for UI testing. My experience with TDD is limited, but from what I've used (SimpleTest), it's incredibly effective and although it's a little slower to write, it's saving a heap of time knowing that's working correctly at a click of a button (or automatically with a CI server checking things for you).

I have to say that unit testing must be a feature of Next, I can't describe how many hours of testing this will save in the long run.

More Acronyms

I had been working at an agency where I was part of the custom development team, building Ruby on Rails applications. Agile methodology, behaviour-driven development (BDD) and user acceptance testing (UAT) with Cucumber were the approach we took with all application development. It certainly takes more time at the outset of a project to take this approach, as feature and user stories must be developed against which the application can be tested. But, for complex applications, the alternative is the inevitable consequence that new features and bug fixes will break existing functionality. The agency could not fully embrace Symphony in large part because of the lack of these processes in the Symphony workflow.

Another large piece was the inability to use PostgreSQL rather than MySQL. For our highly experienced database developers, MySQL was a non-starter because of its deviation from ANSI standards among other things. Moving to a framework like Laravel opens up the option of using PostgreSQL.

We had developers who were experienced with XSLT but could not get past Symphony's limitations in many other areas.

Opinionated Software

Another thing that was mentioned was that Symphony lacked an opinion. There may be too much freedom in how something can be developed. The developers preferred Rails because it is opinionated software.

Symphony needs a clearly articulated vision and a well-documented approach to application development. That is one of the most important steps on the way forward.

You see, I would have said that the opinion of Symphony is to engender standards, but with the addition of other templating layers, that partly goes out the window.

You are right though, and this should be part of the discussion in How to grow the community: a Symphony approach.

Tutorials on how we build sites from some of the tenured Symphony devs will be a part of the documentation. From me will come a direction toward adaptive content using as close a COPE strategy as is possible without alienating admins. For me, these are the strengths of Symphony. from a content perspective.

Looks like Lemonstand may be being rewritten on top of Laravel.

I think this is why it's evident that while Symphony has framework-like qualities, the essence of Symphony is still rooted in a CMS.

Is Symphony a CMS?

I don't think it is. It doesn't

... centralize data editing, publishing and modification on a single back-end interface.

I'm saying this because a CMS does attract a certain type of person ... what I call an Administration Interface AI user. When I argue for moving toward simpler deployment, plug-n-play extensions or no command line, all things closer to the AI user, I find myself in an echo chamber or a member of the core Symphony team explains the fallacy of this desire.

My wife thinks I'm crazy for even presenting this argument because the core Symphony developers already know Symphony's identity. They've expressed it to me several times. It's just not well-described by Allen's comments.

I've read many of the principles of Symphony-Next and they are well rooted in a good software developer background, but I really think that a discussion of the user interface will help to direct, focus, and control the Symphony team's work if there's any real desire to make this a CMS.

I don't think it is. It doesn't

... centralize data editing, publishing and modification on a single back-end interface.

I am confused. It does exactly THAT plus some developer tools.

Anyways, for every who didn't notice yet: There are lively discussions going on on GitHub.