448191

I scrolled through this thread pretty quickly so perhaps I overlooked something. If I did not, I cannot believe no one asked the obvious question: Why? Why, for whatever you value most, would you want to create a forum application? It has been done to death. Yes, it is fairly easy, yes it has been done before with success, even by latecomers. But as learning experience you've already gotten the best out of it, and probably did so before you even posted on this forum. You're not going to learn anything substantial by having some random dude post XSS vulnerabilities on some app that'll never take off. Codewise, all I need to see are some tiny signs in your code to know that you are way behind in the herd. Seriously, your code includes a statement "or die("whatever")". This was not acceptable 10 years ago, now it's nothing less of a sign of incompetence. I'm sure some popular OSS apps still use it after all this time, all the more reason to stay the fuck away. With the intention of providing some usable advice, I had a look at your profile and found a topic where you made a small effort to attack Symfony, but gave up because you couldn't figure it out. I get that. Symfony uses way too much magic. I like it for the clean code and unbeatable completeness, but hate it for its (intentional) tendency to rely on "conventions", ie "magic". I can't count the times the DI config of a bundle wasn't picked up because the naming of a file/class was off slightly. I've since mastered the beast, but I can't fault you for hating on it. Still, Symfony2 is currently the best framework for PHP, once you accept it's an ugly bitch, the bitch will work her ass off for you. But you'd be smart not to commit to any infrastructure layer, be it from Sensio or from your own hand. This post may be of use to you: http://blog.kleijnweb.nl/3-layer-directed-graph-dependency-model-part-1/ To the point, you may want to abandon this hobby project to start fresh for the purposes of learning, and think of something more original. I would apologize for being blunt if I did not believe I'm doing you a favor.

If this is something you would be able to discuss at your local watering hole, I want to move to wherever you live. You'd have to let me stay on your couch for a week or two until I get my own place though, as I wouldn't feel comfortable in this municipality of retards for longer than a day, knowing that somewhere, out there, is a place where everyone speaks the language of product development methodologies. My kin, that'll use WIP as a euphemism for moving up and down in a manner that can only lead to a larger number of wenches being defloured through pure efficiency. My brothers, running from all directions to the center of a field, daily, locking arms in friendship only to beat each other senseless using packs of cards with a modified Fibonacci sequence tightly grasped moments later, under the influence of that poor excuse for beer that needs help to defy gravity to get into their glasses. Is that what you're saying?

Say I wanted to discuss Kanban vs Scrum vs Prince2 vs RUP and everything in between. Where would I go?

Time to retire (delete) this sticky.

Please excuse the necrophilia since this is my own thread... I've been using PHP Traits (again, mixins, not traits but hey) for a while now and the only use case I've found for them is a "quick duplication hack". If you have duplication and you're too lazy or stressed to revise your object model using aggregation, this is the hack of the day. In fact, from a semantical perspective, Scala is the only language that I know of that gets this right. It gets more right, like getting rid of interfaces which is a technical concept. But that's beside the point, conclusion of this thread and answer to the question of when to use traits: when you're fucked and need to hack your way out of massive duplication.

My apologies, clearly Vim has a plenitude of features I'm not utilizing. But as far as auto-complete goes, I find it indispensable. But perhaps my ability to memorize an absurd number of API's is sub-par

Wow, I'm suprised Dreamweaver got this many votes, even if the topic is almost 4 years old. Didn't even realize they still make it. From my experience you're better off with Vim (which I do use for quick edits of config files but find lacking as an IDE). That said, the single feature I find most useful in an IDE is code completion. I suffer from what we Dutch refer to as "geheugen als een goudvis", which compares one's short term memory to the proposed 3 seconds of retention a goldfish possesses. Unfortunately this is also the feature that provides the biggest challenge to IDE developers in terms of performance when library size approaches he gigabyte. I've tried quite a few. PHPStorm seems perform best right now. ZSfE was awesome featurewise, I might give it another try to see if it performs better now

I get your point. Maybe I *should* become involved in some project but then I'd have to be pretty enthusiastic about it, because I don't want to be that guy that tells everyone everything should be done differently (and I know I will cause I'm insanely opinionated ) and then leave because of RL pressure without confidence that they'll do at least as well without me. And if it's a small project that might prove to be an issue. But I can think of plenty of projects with developers more competent than I am so maybe I should join one of those. Yet somehow I always come back to PHPF, like a bird returning to its nest hoping to find a skyscraper

I could not disagree more. You are implying that once you reach a certain level, you become so self-sufficient that all other views become irrelevant. That rushes by self-confidence straight into complete delusion. Not even the greats (Fowler, Evans, Uncle Bob) dare take that standpoint. And yes, a forum is a slow way of communicating, but also a way to communicate with people outside your reach in terms of physical contact. A forum will always be a great way to share your opinions, in fact, for plain "ask a question get a valid answer" type of communication, platforms like stackoverflow are clearly superior. I'll take your word on the statistics, but as I tried to make clear above, in my view a forum should be more than Q&A, and to be brutally honest can never compete with SO focusing only on that basic level of interaction. And tutoring might have been a core value at some point, looking at the depressing amount of tutorials added since I last visited PHPF, I'd say right now it's mostly a poor substitute for SO. The "best" solution to a problem. There are a million ways to approach a certain problem as soon as you move beyond language facilities, and you can't underestimate the value of other's opinions, as they are based on their own experiences. This is a whole different can of beans, that apparently you feel very strongly about. Which I can relate to, for I too at times feel like a genius in a world of idiots (when clearly I'm not, but it's easy to confuse lack of context with superiority). What I've come to realize though is that we all grip to our golden hammers, and there are many solutions to the same problem. That does not mean that one approach to attacking a problem is not a solution, in fact a solution that seems less ideal from one perspective might be the ideal solution considering the context. AOP *does* solve a problem, but I think I already made clear it is not the only solution, and certainly not always the best. One aspect (no pun intended) AOP does address that OOP (with or without DI) doesn't handle is violations of SoC/SRP because of concerns related to infrastructure. Logging is the de facto example, but there are plenty of other real-life applications such as messaging (AMQP or any other form) and authorization (with a complex Service Layer or Domain Model this can easily become a PITA). There are other ways to solve this, such as publish/subscribe, but any decoupling comes at a cost and the cost of a solution depends on the context. Anyway, way off topic, but I felt that required a lot of nuance, if not for your sake then for every other person who read or will read that post.

I It looked smelly to me when evaluating Ruby, but might've been more useful if it worked as advertised: as interfaces with scope and implementation. I still view it as mostly a risk factor to implementation design, but it's there and I'm not one to forbid my developers using something unless I can properly motivate it. Right now it seems like a useful tool to reduce duplication, assuming you're very explicit about valid use (perhaps even reject pushes with abuse using the Git pre-receive hook). I have a more relaxed view on many things as the past couple of years I've shifted from producing good code to validating the quality of code. I Thanks Tony You've come a long way btw, Proem looks pretty good (although I'm not a big fan of event orientation in a synchronous environment). I might stick around, things are a bit more relaxed at work now compared to last 2 years which were extremely stressful (abnormal by any standard, I've been declared insane for my persistence by pretty much all my friends and family). We'll see, I still have the same concerns about PHPFreaks that made me abandon it in the first place: the lack of advanced topics and competent sparring partners. That probably sounds insanely pompous but you probably get that. Right now I'm content sharing my experiences but that'll get boring at some point. I'm rambling again

In hindsight not too happy about the naming of the trait, seems redundant prefix it with "Use". "use Logging" would a more appropriate statement. Expressing a trait using a verb makes sense to me. One caveat I run into is that using a trait does not affect type. I'm not completely convinced about the logic behind that decision. The diamond problem is not applicable as mixins are conceptually different from inheritance, ensuring the sources for object composition are unequal and allowing precedence. Using a combination of traits that cause name collisions will not parse unless aliased. In short, using a trait provides zero assurances for clients, meaning you have to define an interface as well, which seems somewhat redundant but unavoidable. The proposition "Traits are interfaces with implementation" is false, at least for the current PHP 5.4 implementation. Doesn't change it reduces duplication so it's still a win I guess. One has to ponder though, considering all the boilerplate involved, how useful traits are IRL. use Psr\Log\LoggerInterface; interface LoggingService { public function setLogger(LoggerInterface $logger); } trait Logging { private $logger; public function setLogger(LoggerInterface $logger) { $this->logger = $logger; } protected function log($level, $message, $context = array()) { $this->logger->log($level, $message, $context); } } use Psr\Log\LogLevel; class SomeService implements LoggingService { use Logging; public function doSomething() { $this->log(LogLevel::DEBUG, "I did something worth logging"); } } $service = new SomeService; $service->setLogger(new SomeLogger); $service->doSomething(); var_dump($service instanceof Logging);

We're finally upgrading to PHP 5.4 coming release, and probably it's most prominent addition is that of traits (strictly mixins, but whatever). Mxins in Ruby have always seemed a quick way to get you in a lot of shit, but 5.4 forces me to take another look at them, so I can formulate some guidelines for additions to our codebase. In other words, to make sure they are used without violating a truckload of design principles. Specifically SRP, or more generally cohesion look like a likely victim. One possible application I see is reducing duplication, especially of boilerplate. In a way, a less complete solution to the problem solved by AOP, so the main Use Case I see is adding system/supporting features such as logging and access control. Example: <?php require 'vendor/autoload.php'; use Psr\Log\LoggerInterface; trait UsesLogging { private $logger; public function setLogger(LoggerInterface $logger) { $this->logger = $logger; } public function getLogger() { return $this->logger; } protected function log($level, $message, $context = array()) { $this->logger->log($level, $message, $context); } } use Psr\Log\LogLevel; class SomeService { use UsesLogging; public function doSomething() { $this->log(LogLevel::DEBUG, "I did something worth logging"); } } How do you use traits?

The huge gap between ZF1 and S2 in the OP is more or less in concord with my own experiences. I wasn't to impressed with S1 but S2 ticks a lot of boxes, performance isn't at the top of our list of priorities but S2 in production mode is as fast as any full featured framework can be. We are migrating from ZF1 to S2 and the interface is noticeably more responsive on the same server. Of course you *could* make ZF equally performant with a good chunk of custom development but SF2 makes it effortless. But I feel that's a valid argument: ZF provides a less restrictive infrastructure, S2 pre-chews more for you but Potencier made performance a key concern from the first lines of code so it's not surprising it's more performant. It does introduce some inflexibilities, but having worked with it for a couple of months now I can honestly say the extensibility provided is sufficient and the infrastructure is so much more mature than the ZF MVC component, there's really no comparison.

The polls probably needs Aptana as an option. I know at least three people that use that.

I'll take that one. Expect a "Getting started with TDD" within a couple of weeks. The examples will be using PHPUnit though.