In Java or Ruby, there are many talks about test/TDD/BDD. and there are many tests in Java/Ruby projects.
But I notice that, there are less tests in PHP project, and It seems like PHPer does not like to write tests, I just want to know the reason. thanks
I've used several applications or libraries, in a variety of languages, that did not include unit tests. This is not something isolated to the PHP community.
In fact, PHP has several testing frameworks available. Developers may either choose not to use them for whatever reason, or may be unaware of them. After all, a lot of PHP developers are self-taught with no formal training in computer sciences.
Honestly, most PHP developers I know that do use testing frameworks and other lifecycle tools tend to have been in the field for a long time, or come from another background like Java.
IMO there are multiple contributing factors:
It's a pretty new concept for PHPers. I don't use it myself. Most applications are written without contractual API design, hence code preceedes tests (in practice).
The test frameworks (PHPUnit and SimpleTest) are not natural.
PHP runs in a different environment than Ruby/Java. Moreover application parts are split into include scripts, which have different semantics from packages; sometimes locations variate.
PHP isn't as object-oriented to the core as other languages. Most code is procedural / mixed or hybrid.
I would go so far and ask about the merits of Unit-Testing for PHPs runtime environment. Selenium might be a better choice. But personally I'm looking for a simpler approach: simple (non-unit) test framework, similar to .phpt, should evaluate output/headers/errors/results
Related
I'm deciding on a web framework for an upcoming project, and I'd appreciate any advice. We've decided to use jQuery for the JavaScript, and are heavily leaning toward Python or PHP (more Python) for our server-side logic. I'm especially interested in web2py because of its jQuery integration.
About our project
Our project is to develop a security console for a complex
cybersecurity system operating within an organization's internal
network.
This console will be largely server-driven, as messages come in from the network and must be pushed by the server to the user.
The user will also be able to initiate security actions, the implementation for which will likely be in C++.
The interface we've planned will be relatively rich, and I want to leverage jQuery's power as much as possible.
We have some control over the browser environment we'll be running in (e.g., we don't have to worry about clients with JavaScript disabled).
Our site is likely to have only a few, long-lived client connections.
We are looking for software components with permissive licenses, though we're using some copyleft components (I see that web2py is LGPL while Django is BSD, so +1 to Django)
We have about a month to create a functional demo of our system, of which this interface is a small (but visible) part.
About us
We are two developers with about 5 years of programming experience, but little web development experience. I have several years of Python experience and a summers' worth of experience messing around with PHP. My coworker has some Python experience and has never touched PHP.
I used Django once back in 2008, and was frustrated by the file and code structure, which I found highly unintuitive. Perhaps this structure is inherent to the MVC model (I've had similar experiences with Django and CakePHP since), and I just need to bite the bullet and memorize it.
My Question
Given the information above, what are the relative advantages of the various Python/PHP web frameworks for our project? As mentioned above, I'm especially interested in web2py because of its jQuery integration, though Django's dominance is (once again) hard to ignore.
Thank you very much for your time!
Before deciding on a framework, you should first decide if you want to commit to a language you are unfamiliar with.
You said you've both got minimal PHP experience, so you have to weigh up the advantages here; Will the pros for going PHP (if any) out weigh the amount of time the developers will need to spend to retrain?
(Although depending on your background experience, PHP should be very easy to pick up.)
If you frame it like that, PHP would have to have a pretty convincing offering to give you. From what I'm seeing, specifically Django vs web2py, they both seem very close in functionality - which is good, but doesn't provide the "you must use x!" scenario you may be after.
However, If you will be bringing more people in later and feel finding people to work with web2py will be difficult, it may tip it to PHP. You said your self, Django's popularity (and BSD license) is hard to ignore, and it should make it easier to find people for later expansion.
If it were me, in your shoes, I would go with web2py. Assuming the development team will continue to be Python focused for the foreseeable future.
Python vs PHP: Python
With python, you can always write wrappers for C code so you won't have to mess with starting other processes and passing args to them. That might be useful for your security functions.
Web2py will allow you to easily write a webservice for this too, to more easily integrate the C portions with the web-site infrastructure.
If you already prefer python, I would go with that. If you need to bring on web-developers later that are trained in PHP, teach them Python. It won't take long, and I'm sure they'll appreciate it in the long run. Plus, moving from a PHP MVC framework to web2py or even django would make things easier. I've used CodeIgniter for PHP and find that web2py was so much simpler and easy to understand.
Also as for the directory structure, django is not actually true MVC -- it's MTV (model, template, view).
I find web2py's organization a little more straight-forward. But yes, either way it can seem strange at first. I would say YES, you should bite the bullet and use MVC.
In web2py, the "view" is html markup with the ability to write raw python code. The controller extracts data from the model (database), attaches any needed files (css/js etc) and the model of course simply defines the structure of the data and allows you to access it in an OO way.
Lastly, I wouldn't tip my hat in favor of web2py just because of jQuery integration. It does use it, and a some of the built-in framework stuff (like response.flash/session.flash, the LOAD function that loads a page or data from another controller) rely on jQuery, but using it in another framework only means you have to write an include statement (e.g. ).
But, the way it allows/forces you to focus on development is what takes the cake for me.
I've been using Django as part of my work for a couple years now and truly enjoy it when I can make it work. Unfortunately, and maybe it's just me, but I end up spending hours working on configuration every time I start a new server, or try to make it work in a development IDE.
It's relatively simple to start a new project and start coding. But there are all sorts of little catches that keep things from working if you deviate from the norm. Things like if you want your django project to serve from a subdirectory like example.com/django. The information is out there to make it work. But it's hard to find.
I can't tell you if web2py has those same problems or not. I only just learned about it from your question. It does look slick and simple though. I can tell you that after the hassles of getting the applications to serve properly from whatever server configuration I'm using, django is way more fun to program with than plain php. PHP frameworks may differ.
From my understanding the project not usual web application, you must need event driven program, web server in python.
Django won't help you here.You should look into Flask, Flask has inbuilt console too.http://werkzeug.pocoo.org/, you might need to use twisted, gevent,Flask jquery.
I would recommend asking about web2py on its mailing list -- you'll get lots of help and advice there. Regarding the LGPL license, note that it only applies to the framework, not your application -- you can license your application however you like, including closed source/commercial.
It sounds like you'll need some server push functionality, but if you'll really only need a few long-lived connections at a time, you might not need to bother with solutions like Twisted or gevent. If necessary, though, web2py does include this (requires Tornado, and works using WebSockets, though can be adapted to use other methods).
Don't get me wrong. I think both projects are fantastic.
But as both php and ruby developer I wonder if there are there any compelling reasons, besides possible language barrier, why would one choose Behat over Cucumber (with cuke4php) for BDD even when working with php or some php framework.
I'm a Behat developer.
Why I've developed Behat instead of Cucumber customization:
Speed. There's no simple way to bootstrap/run PHP from Ruby code. This means that you need to implement wires/proxies and other things, which makes your tests insanely slower. And slower tests is not a test, it's just code that eats your customer's money.
Extensibility. There are very few PHP developers that really know Ruby. It's a hard to use tool, that many don't understand! All examples written for Cucumber are Ruby code and you even can't look at Cucumber sources, because, let's say, you don't know Ruby. It's like buying a submarine when you just need a taxi.
In terms of features, Behat and Cucumber are almost the same (I've worked hard to achieve this). But in terms of speed/extensibility/logic from a PHP developer's perspective - Behat is better, because it's a fast and clean native PHP tool. Behat is not a Cucumber port, as you might think by first, it's built entirely from the ground on PHP 5.3. Behat is trying to simulate Cucumber with its input reading (features) and output formatting (formatters), but it's not a Cucumber port (there are no Ruby syntax constructions in PHP).
Yet another reason why you may need Behat is explained here: https://cucumber.io/blog/bdd/when-cucumbers-go-bad/
If you have PHP project, you may want to create context for internals testing (domain layer, application layer).
I wanted to toss in my two cents on this topic with an answer that addresses various use-cases in a professional setting.
If you are working with other developers on a codebase written primarily in PHP, the advantage boils down to your coworkers.
If your team is more comfortable in PHP because that's what the codebase is written in and people have trouble or are annoyed by context switching to different programming languages (most people are this way in my experience) then it is better to accommodate your team and use Behat. People will complain less and (hopefully) get more done.
If your team is fluent in a variety of languages and most people have no problems switching between using Ruby (cucumber) for acceptance tests and using PHP for everything else, use the language best suited for the job. Ruby is much more expressive than PHP, so cucumber is arguably a better choice.
If your team is more comfortable with PHP than Ruby, then go with Behat. Native compatibility ensures expressiveness and avoids weirdness, besides the fact that it's faster.
A little while ago I read a great article which described a number of reasons against using any of the RAD frameworks available for PHP. Basically, it argued that a good framework should get you off the ground quickly, and then should get out of your way. But none of the PHP frameworks did that. It pointed out that Django was good at doing just that (but that's obviously not a PHP framework).
For the life of me, I can't find the article now.
So I'm curious. Does anyone have any solid arguments as to why applications should not be built on top of a RAD framework? And I'm not necessarily talking about generic applications (frameworks by definition try to solve a generic problem. The quesiton is does that translate well to specific problems).
And when I say built on top of, I mean from the ground up based on the framework. I don't mean referencing the framework as a series of libraries. I mean basing the entire architecture of the application off of the framework (which then ties you into the framework).
I'm also not really talking about rapid prototyping where the code will likely be re-written anyway. I'm more looking at long-term applications that have a specific business requirement to meet, and must be supported and maintained (and modified) for a relatively long period of time.
We always hear about why we should be using a framework. There are reasons galore:
Not reinventing the wheel (although I hate this reason)
Faster development time (since architecture is skipped)
Easier to bring new developers in
Common problems are already solved
etc...
But I'm looking for the antithesis...
Any thoughts?
It is implied that frameworks being written by some unknown heroes who is smarter than you by default.
But as a matter if fact it's often not true.
It has bugs, it can be messy and unnecessary overcomplicated.
Thus, having your own helper library is often more handy than using such a monster, knowing roughly 10% of it's features.
A few ideas:
The type application you are creating does not have a commercial or free framework available (custom hardware-based apps come to mind) (this is the obvious answer)
The system has extensibility requirements that are made more difficult by using a RAD framework (i.e. framework values convention over configuration, where you really need the configuration)
The project scope is small enough that it doesn't make sense to invest the learning curve into using a RAD framework (if you already are past the learning curve, this may or may not apply)
The tools/approach/back-end/platform requirements provided by the framework will introduce unnecessary complexity (YAGNI, using a framework without a business need for its features may increase support costs as you have to support the whole thing, including unused features)
My fear has always been, what happens when a framework stops being maintained/updated (for whatever reason)? Your project is locked into whatever PHP/MySQL versions the framework supported.
I'm doing a little framework research lately.
http://matrix.include-once.org/framework/
And to some extend I have to agree. The majority of frameworks don't significantly simplify development. Particularily the "MVC" frameworks are about abstraction more than utility. There are however always features which do help for everyday tasks. ActiveRecord/ORM come to mind as reducing tedious manual work. Form helpers might do, but I haven't seen a seriously helpful one yet.
Generally I believe, the more functional library code a framework provides, the higher the productivity. But in the case of Zend Framework, it's randomly dwarfed by complexity. However, check some of the smaller frameworks out. Avoid the overly abstract. Look for scaffolding tools, not libraries.
One of the main advantage to not use a framework is that you have more flexibility in what you can code. For project with a smaller scale, it is often better to have that flexibility.
Some frameworks need shell access to deploy.
Scalability, I've read that sharding is an issue
If performance is a priority, frameworks tend to slow down execution speeds
Not all developers familiar with MVC pattern so maintainability if developers rotating in/out of project could be a challenge.
We are about to start a new Web2/AJAX app and are trying to decide if its worth the time and effort learning Ruby/RubyOnRails instead of PHP, CodeIgnitor and JQuery we currently use.
The key issues are clean/fast/modern AJAX UI, robust error handling, ans maintainability.
I would appreciate unbiased (if thats at all possible talking languages/frameworks) comments from experienced PHP and RUBY developers.
I can't say too much about Ruby, but I can say that I often feel like PHP gets a bad rap. PHP is what you make of it. Yes, there is a lot of awful PHP code out there, but you know, it was mostly written by people who would have written awful Ruby, or awful Python. PHP has such a wide audience that programmers of all stripes and abilities are using it, and many of them are writing bad programs.
That said, you can write good programs in PHP. Do you have good developers? If so, you can certainly write good code in PHP.
PHP has a terrible reputation because it is so accessible. Anyone can start writing PHP, and most hosting solutions offer PHP these days, so there are a lot of non-programmer types writing programs in PHP. These programs lack proper computer science discipline.
There is a very widespread movement within the PHP community to move toward readable, well formed code as PHP starts to adopt modern language features. With PHP5, OOP became a practical reality and with that an explosion of books and material written about OOP best practices and development patterns. While PHP is often used to write malformed sloppy spaghetti code, the language facilities are there to allow developers to program in development paradigms like MVC, OOP, and TDD.
Not to mention, PEAR has greatly improved the quality and accessibility of community scripts. PHP's strongest asset is its community, and it has been becoming stronger and more disciplined. In many ways, PHP is very much like JavaScript--it had a very sloppy beginning from which the developers and community have been trying to recover. JavaScript is a very sloppy language, but there are some extremely powerful parts of that language that have brought it some well deserved respect in the age of Ajax and interactive web applications.
Languages like Ruby and Python are chock full of things geared toward computer programmers. If you hire a Python or a Ruby programmer, just by virtue of knowing the language that programmer is many, many times more likely to appreciate clean, well organized code than a PHP developer. That is part of the culture of those languages, and the people who evangelize them.
There is nothing inherently better about Ruby or Ruby on Rails in my opinion. Rails was the first mainstream MVC development framework, but its popularity and success has catalyzed the development of similar frameworks in every language imaginable. The choice to write Rails in Ruby isn't an indication that Ruby is better than PHP, which many could argue. Considering the time in which Rails was written and 37signals' fascination with obscure things, I can understand the move completely. At the time, web scripting languages were pretty lame, and 37signals was looking for a language that catered more to the needs of application programmers, not scripters.
You're not being held back using a PHP framework like Zend Framework, CakePHP, or symfony. CakePHP and symfony are both directly modelled after Rails, even if they aren't direct ports. Akelos is an actual port of Rails to PHP. Zend Framework is the most fully featured framework I've used so far. Don't be afraid to experiment, but jumping ship to a completely different platform isn't necessary and it won't change the way you do business. It's the same business in a different dialect.
The most important feature of a language is how much you enjoy using it. If you enjoy the language that you use, not only will your life be better, you will write better code and be more productive. Of course, this is completely subjective; however, I've never heard any first-class programmers talking about how much they love PHP.
Of course, getting to the level of fluency in a language / framework combination that you really know whether it is going to float your boat takes a big investment of time. In my opinion, the time that you spend will make you a better programmer even if in the end you decide that you like a different tool better, so, go for it!
I think it's not about the language but the disciplines that are used in the community. If you are PHP developer who doesn't unit or functional test his code, nobody cares. There are bunch of PHP developers like that. If you are Rails developer and doesn't test your code automatically you're weird, something must be very wrong with you.
Ruby on Rails seems to me more than a framework, all the tools that come with the community. It is recommended that you use some kind of semiautomatic deployment tool like Capistrano. If you're not, you're weird again. And so on.
I agree with dicroce that you can shoot in your leg with both languages/frameworks. You could go with PHP and try to use some of the tools originally ment to Rails and i believe you get a great result.
Back in the scripted ASP and ColdFusion days, I used to work on projects that would build code generators for ASP or Coldfusion, typically in C++, in order to be more object oriented in application design and not have developers writing scripted code, which often was called "spaghetti code" for it's size and complexity.
Since I've been coding asp.net since 2000, I haven't really had to deal with the issue at all, since the platform is not scripted.
I may be working on PHP projects in the future, and I was wondering if any code generators for PHP exist, or if any good references for building these generators exist.
It would be for the Linux platform, not targeted to Win2008 Servers running PHP.
Why not just build a proper app in PHP instead of going through the hassle? Recent PHP is fully object-oriented and lets you do some pretty decent stuff. There are even frameworks that help you do this kind of stuff.
I'm rather sceptical on the merits of code generation in the context of a dynamic language, such as PHP. You can generally use other kinds of abstraction to get the same results. Unlike a statically typed, compiled language, it is rather easy to use dynamic hooks such as __get and __set and reflection, to make generic abstract objects.
It's better that you learned good development practices in PHP than use code-generators. PHP might be a scripting language but it is quite potent, has a nice OO model, plenty of good frameworks and other open-source packages.
It's up to the developer to create well designed and factored code base, regardless of whether it's compiled at run-time or not.