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

If you want to use Selenium/Webdriver (and you should if you're thinking about creating a serious test platform), you'll need a lot more than suggested so far. You can either do a minimal setup (just install a gnome or unity on top of a server edition) or go multi platform / browser version, which means your box becomes a VM host. For the latter you should look at KVM and Xen, both are non-trivial to get properly set up, know what you're getting into. KVM might be the quicker solution, but still not trivial. It depends on how much value automated functional testing and cross browser compatibility is to you, in any case it is not something to be taken lightly. At work we use SuaceLabs, precisely for the reason that setting up and maintaining a Selenium testing cluster is "expensive": (it takes a lot of time and effort). I didn't see anyone mention Jenkins or Hudson, I would strongly suggest diving into that before Selenium/Webdriver.

Maybe I misunderstood but if the problem pertains to more options regarding file access permissions, I propose you look at setfacl. But it might require administrative control as its not available by default nor enabled on filesystems by default: http://linuxcommand.org/man_pages/setfacl1.html You can avoid sudo and avoid many issues created by inflexible/unconfigurable code. But Tony might have a thing or two to say about it as he's probably more versed on the topic.

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.

Haha, wel some things do, but apparently my tendency to produce rants isn't one of them I'm pretty good, thanks for asking. The past three years I've been the lead senior developer in a medium sized company. I learned a lot, but also had to compromise under extreme pressure from the business a lot, and currently I'm just re-evaluating where I stand. I might freelance as an interim lead / consultant for a couple years although nothing is decided just yet. How are you doing? (we can move this to PM if mods object) Edit: sorry I forgot to address you as sensei old man

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

Cool.

Uhuh, but you didn't reference any of that. Maybe it should've been obvious but I prefer being explicit. In any case let's leave it at this, we're going way off topic. Cool?

Fair enough, though I feel it's a bit irresponsible to provide alternatives that are ill-advised without explicit disclosure of that property.

Guess I prefer giving advice over answering questions.

Even if you never go "big", understanding OO principles is a smart move. It's the quality that I find lacking in developers most often: they stop after learning syntax and language features, perhaps they'll keep in touch with with a public community but the PHP community is catching up too slowly and cling to practices that don't scale. Although, and I speak from experience, you might be tempted to overdo things once you do have a solid understanding of OO: bringing a sledgehammer to a game of midget-golf. But likely you'll start building stuff that justify the size of your hammer PHP has a bad rep as a platform for Enterprise development, you should see the faces when I tell people it's all written in PHP after I tell them what we do. In any case, a better understanding of OO will benefit you using pretty much every common language. You can learn the syntax and facilities of 10 languages and that conceptual knowledge will be useful in all 10 cases.

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);

You could, but you shouldn't, for similar reasons you don't use globals in PHP.

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?

You don't need a specific IDE for a specific framework, Cake or otherwise. While some IDEs include "support" for libraries and frameworks, after a decade I've yet to come across a framework that makes those features a significant accelerator. Pick your IDE based on your workflow. Just give a couple a good try, it's 90% preference when choosing between full-featured IDEs.

Actually, TDD is a paradigm, Unit Testing by itself is not. I'm not trying to undervalue it but strictly it just refers to testing a small subcomponent, and doesn't dictate a development process like TDD does. Unit Tests are written to ensure predictable behavior of existing code as well, despite Kent Beck's explicitly advice worded "don't bother". Symfony also provides facilities for headless functional testing (or Integration Testing), very useful to ensure your components don't just work but work together.

Everyone working in a large-scale professional environment was where you're at now at some point. Assuming you've mastered the syntax and features of at least one language with OO support, you'd do well to explore OO principles. Start with reading about the concepts of coupling and cohesion. This allows you to understand SOLID principles and design patterns. Also get comfortable with the de-facto standard deployment platform: Linux. I always say a good programmer is half a system admin.

Should you want to look at it after it becomes obsolete, look in the repo history. If you're not using a VCS that's an even bigger issue (even the smallest projects should), but if you are, there's no reason to keep code not being used and plenty in favor of removing it. If you need to temporary disable something (a situation to be avoided like the plague btw), remove it and restore the file afterwards using your VCS or IDE. There is no valid reason for commenting out code, seriously. You'll end up committing/pushing that crap at some point, even if you're vigilant. And then your crap it not just your problem anymore. Instead of flushing, you picked up your feces and spread it all over your teammates' faces, to keep with the metaphor Not on topic so I am going to leave it at this, but it annoys the hell out of me especially because it's such a widespread bad habit.