Corey Hart (@codeNothing) wrote at 12/4/2009 1:17 am:http://www.mantisbt.org/ is a decent size project, and it’s not that ugly in the bug tracking mindset.
| « Data Formatting: It IS Our Job | Five (Good) Lessons The Government Teaches Us About Object-Oriented Programming » |
Trac. CruiseControl. phpUnderControl. Jira. Bugzilla. These are all intensely popular development tools. And not a single one of them is written in PHP.
Why?
Trac is written in Python. CruiseControl is written in Java, and phpUnderControl is built on top of CruiseControl. Jira is written in Java and is a commercial program. Bugzilla is written in Perl. All of these programs have either been around for a long time, or they have commercial components attached to them.
Some might argue that PHP is a lesser language, and thus incapable of producing the results that Python and Java can produce. Others might argue that other languages are more mature. But the truth is that these applications don’t exist in PHP simply because PHP wasn’t previously capable of producing them. With PHP 5’s object model, PHP is finally able to produce the high-quality applications that developers can use. PHPUnit is a perfect example of that.
Next year, I’m devoting myself to writing and developing open source applications for the PHP community to use. These applications will consist of a continuous integration server, a bug tracker (that doesn’t suck or look terrible), and an SVN browser. These applications will be available for free, and will be community driven. I’m taking the initiative because these applications are great ideas but few people have the time; thus, I’m dedicating myself to writing them and making them available for others.
This will be my big contribution to the PHP community in the next year. I think it’s worthwhile and necessary. And it should be a lot of fun, too.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 12/4/2009 at 1:00 am
http://www.mantisbt.org/ is a decent size project, and it’s not that ugly in the bug tracking mindset.
Miles Johnson (@gearvosh) wrote at 12/4/2009 1:31 am:
Funny you mentioned that, I came to the same conclusion and recently started building a PHP bug/issue tracker that users can install on their own system.
Nate wrote at 12/4/2009 1:42 am:
Awesome! Could it integrate with Git too?
Kuba (@jakub_zalas) wrote at 12/4/2009 1:50 am:
Why starting from scratch? There are existing developments tools written in PHP. It is better to join one of that projects than starting your own one.
As an example there are at least two continuous integration servers written in PHP – xinc (http://code.google.com/p/xinc/) and sismo (http://groups.google.com/group/symfony-devs/browse_thread/thread/d0c19cdc1f1a1338). The later is not yet released to the community.
I don’t know any good ticketing system written in PHP. It would be great to copy some of features of Jira and Redmine.
klang wrote at 12/4/2009 1:56 am:
> continuous integration server
We use Hudson, with an ant build file and a few shell scripts for ssh to the target server as a build system for php. We use SimpleTest and JUnitXMLReporter (extends SimpleReporter) to convert SimpleTest Reports to JUnit Reports. That way Hudson can show some nifty nice graphs and linked reports.
I had to bend a few corners to make Hudson work, but it does work.
We are missing something to track code coverage, but Spike has a tool that works with Xdebug that looks promising. Spike PHPCoverage is an example of a (great) development tool written in PHP (yay, I found one)
Maarten wrote at 12/4/2009 2:23 am:
I think it also has to do with the fact that those tools work well enough, and are not too hard to install even though they are not PHP.
I’m looking forward to seeiing your results though, something in PHP would have my preference because I’d be able to extend it more easily.
Maybe also look at Redmine, it’s our current bugtracker and the nice thing about it also has alot of other tools integrated.
Toby (@tobySen) wrote at 12/4/2009 2:25 am:
You should take a look at Arbit: http://arbitracker.org/
Loïc d'Anterroches wrote at 12/4/2009 2:29 am:
Maybe you can take a look at InDefero if you are interested in a bug tracker and a SVN browser. It is doing both of them very well. What is definitely missing is a continuous integration server with some kind of securities (sandboxing of the PHP test runner maybe).
InDefero is available here: http://www.indefero.net and you can check the code here http://projects.ceondo.com/p/indefero/
Stefan (@skoop) wrote at 12/4/2009 2:30 am:
You might want to go and volunteer with Fabien of symfony if you’re interested in doing this. Fabien has already written a basic Continuous Integration server (example? http://ci.symfony-project.org/), perhaps he could use your help in extending it’s features.
Mike van Riel (one of my colleagues) is working on a bugtracker, perhaps he could also use some help with that one. From the previews I’ve seen so far of his work, it looks to become an excellent bugtracker.
Let’s try to not reinvent the wheel, but strengthen existing tools :)
colleen dick (@tixrus) wrote at 12/4/2009 2:35 am:
that so totally rocks! I’ll be tracking this. I disagree that old PHP wasn’t capable of it, after all you can theoretically do any program with a piece of tape. However I agree that true objects make it a lot more tenable.
Ingo wrote at 12/4/2009 2:36 am:
Hi Brandon!
Sounds good, but please reinvent the wheel!
Use or commit to http://arbitracker.org
Best Regards!
Jan wrote at 12/4/2009 2:37 am:
Do you know Arbit (http://arbitracker.org)? It already provides (or will provide) everything you mentioned.
Martin Holzhauer (@woodworker) wrote at 12/4/2009 2:38 am:
Maybe you want to have a look at “Arbit Tracker”
http://www.arbitracker.org/I dont want to say dont start your own Project, but Arbit seems to be great at the moment and has a lot of eatures you want to redevelop. AND its PHP5.
Thomas Hambach (@thomashambach) wrote at 12/4/2009 2:54 am:
I don’t really agree with what you’re saying here. There are plenty of opensource PHP development tools, they are just underdeveloped. Why not contribute to these instead of starting your own?
Rob... (@akrabat) wrote at 12/4/2009 3:02 am:
I disagree that PHP prior to v5 wasn’t capable enough to write a tool like trac or bugzilla. I’d argue that a more likely reason is related to the fact that PHP has come from the web and not from Computer Science. As a result, development best practices like version control, bug tracking and unit testing have been slower to take off within the PHP world. As PHP doesn’t have a “compile step”, it’s obvious why CI tools are also less popular in PHP.
Also, PHP also already has a lot of bug tracking and wiki software available to it. It’s harder to justify writing a new one when you have mantis, eventum, phpBugTracker, Codendi/GForge, flyspray etc. Of course, they may not be all “Web 2.0″…
Also, a new modern tool that’s coming onto the scene is Arbit (http://www.arbitracker.org). This one is so modern that it uses couchdb as a data store! May be worth looking at what they are doing and seeing if contributing to it will get to your goal faster.
I’d like to see a good subversion browser mind you!
Regards,
Rob…
Michael wrote at 12/4/2009 3:05 am:
Great idea, I’d love to test those things :)
Weltraumschaf (@Weltraumschaf) wrote at 12/4/2009 3:09 am:
Why wasting Your rare time? Hudson is a very nice CI server. Its absolutely not neccessary to implement one in PHP. Yes, I’m earning my money with PHP, too. But is a weak language. I give You some points:
– The PHP community is still proud that in 5.3 the self dereference works korrekt. They addded a new keyword for that. Thats not a improvem,ent. Thats a bug!
– The garbage collector still dosn’t support complex references of objects. WTF? I thought it was a OO language.
– The language is not multi concurrent capable. You get a really hard fuck up when you hava parallel AJAX in combination with sessions and more than one webserver. Yes, I know, the community says thats the lack of staes in HTTP. But that’s stupid.and so on …
I think PHP is nice to ramp up some websites. But its not a enterprise architecture language.
When I see what they did with the namespaces… Please give me a gun!
Joris van de Sande wrote at 12/4/2009 3:11 am:
I am looking forward to see your new open source projects, although I think that starting and maintaining 3 new projects at once is a bit too much. Maybe I can find some time to contribute to the new projects when they’ve started.
Thomas Koch (@thkoch) wrote at 12/4/2009 3:22 am:
There are (at least) two PHP written bugtrackers to which I’d contribute if I’d time instead of starting my own:
– Mantis, because it’s powerful and well integrated with other tools. It only needs to get rid of it ancient PHP4 code style
– Arbitracker, because it uses the right storage: CouchDBThere are Hudson and Cruisecontrol. I don’t see any reason not to use Java tools. If you don’t like Java try xinc.
And SVN should die as soon as possible. Once you did distributed version control you never go back.
It would be great, if libgit would get ready and one would have a GIT extension for PHP.
Peter Smit (@Peter_Smit) wrote at 12/4/2009 3:27 am:
It would be nice if besides that it provides great tools, it also really can become examples of good PHP project involving all best-practises.
What framework(s) are you planning to build these applications on?
Evert (@evertp) wrote at 12/4/2009 3:31 am:
Sounds like a lot of work! Very curious where this ends up. Are you thinking of building it on top of existing framework(s), or all from scratch?
jerome wrote at 12/4/2009 3:35 am:
Hi Brandon,
instead of starting something from scratch, why don’t you see if you can contribute to Arbit :
– http://arbitracker.org/arbit/about.html:)
Christof Damian (@cdamian) wrote at 12/4/2009 3:43 am:
I don’t need another new bug tracker or svn browser.
But I could do with a PHP continuous integration server, which integrates the PHP QA tools better. I would love to see this implemented with Symfony or any framework, so not everything is created from scratch again.
I think a few CI PHP tools are already in the pipeline, it might be worth combining some of these efforts.
David Boyer (@misterdai) wrote at 12/4/2009 3:45 am:
A worthy cause indeed. I’ve often looked for PHP alternatives of the tools you mentioned but what I usually find is either nice looking but lacking in features or very ugly but has most of the functionality I’d require.
I think you’re correct with your theory as to why this has happened. I wish you luck in your quest to get equivalent tools written in PHP. I’ll be watching and if I ever think I can help out, I’ll try my best ;)
Jozef wrote at 12/4/2009 3:52 am:
Brandon wrote: “… a bug tracker (that doesn’t suck or look terrible)”
I have been using Mantis, i do not think it is terrible. Are you suffering from NIH syndrome? ;-)
Unomi wrote at 12/4/2009 3:58 am:
Hi Brandon, I hope you succeed with your ambitious goals for the next year and beyond. But, I also hope you start from a simple scratch and build on top of that. What I found most important in using things like phpUnderControl and PHPUnit are the documentation and a thorough tutorial path.
I like the possibility to checkout from SVN and build from source etc. But if the documentation is lacking or way older than the progression made, it becomes useless. I hope you don’t make the same mistakes following the road down there.
– Unomi –
Kore (@koredn) wrote at 12/4/2009 3:58 am:
That’s exactly what we are currently doing with Arbit, see: http://arbitracker.org/news.html
I would prefer seeing contributions to arbit instead of another project, which would double the overall effort. Contributions are very welcome, even we are still in an alpha state with the project. To get in contact with us, see: http://arbitracker.org/arbit/participate.html
Flyingmana wrote at 12/4/2009 4:17 am:
Arbit ( http://tracker.arbitracker.org/dashboard ) is still in development, but i think it will soon be an alternative to tools like CruiseControl or Bugzilla
Giorgio Sironi (@giorgiosironi) wrote at 12/4/2009 4:40 am:
In fact I came here saying: and PHPUnit? :)
I am not sure if this is reinventing the wheel, and we should join forces with existing projects.
For instance, some php bug trackers already exist as you can see from http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
For svn: http://websvn.tigris.org/
phpUnderControl is written in php, and it relies on CruiseControl because php is not very suitable for uses different from creating web pages and cli scripts (running php with cron is a work around). Php scripts should have a definite time of execution (max_execution_limit by default is 30 seconds), while a continuos integration server needs a daemon.
a_musing_moose (@a_musing_moose) wrote at 12/4/2009 4:43 am:
That’s awesome to hear. This is something I am also very interested in and would love to hear more about it, some of the features and infrastructure you are planning to work with. Are you planning to blog some of your idea?
roy simkes wrote at 12/4/2009 5:05 am:
This might be because most of the PHP developers are not interested a lot in the making of the project but the results of it.
Even most of the great development tools are not written in PHP, most of popular software on web is written with PHP, like WordPress or vBulletin or phpBB or Drupal or other kind of things.
And generally PHP developers are not interested a lot in refinding the wheel, because they are not mostly evangelists. If a tool is good, they use it and they don’t care if it’s written on python or perl or whatever.
However I’m sure that an issue tracker written in PHP would rock! :)
Good luck on the job
Sebastian Bergmann (@s_bergmann) wrote at 12/4/2009 5:11 am:
All the components that you list (CI server, issue tracker, vcs browser) are already available for Arbit (http://arbitracker.org/arbit/about.html).
I am confident that Arbit will replace CruiseControl and Trac for PHP-based projects in the long run. Of course it is not limited to PHP-based projects so that it will eventually also attract developers from other software stacks.
Andrei (@andreisavu) wrote at 12/4/2009 5:12 am:
Why reinvent the wheel? Time is important!
Adrian wrote at 12/4/2009 5:24 am:
nice blog post.
Before you reinvent the wheel you might want to check out or even contribute to the project tracker Arbit.
http://tracker.arbitracker.org/dashboard
Tomek wrote at 12/4/2009 5:48 am:
Great idea, if I can have an early request: make it using some framework and PHP 5.3 (Zend Framework 2, Symfony 2, other (simplier/better??)). Will be easier to get high quality user contribution to those projects. Those (versions of) frameworks are not ready yet, but I think some early (beta) versions should be available in a couple of months (6 at worse I believe) and until that you can work on a great and detailed specifications, architecture, interface prototypes. It’s worth to put a lot of thought into that, especially if you set your goals high and will target to achieve the excellence of JIRA (and I believe you should, no point to make half-assed products).
Lee Neilson wrote at 12/4/2009 6:18 am:
Hear hear
David wrote at 12/4/2009 6:21 am:
You seem to be confusing application popularity with programming language capability. Just because the most popular tools don’t seem to be written in PHP doesn’t mean that similar tools don’t exist which are written in PHP. (ie. Codendi, Mantis, ActiveCollab to name a few, and the former two being written before PHP5 was released) In fact, Mantis and Codendi are 2nd and 3rd oldest bug trackers listed on Wikipedia’s comparison of issue tracking systems.
As for the general trend of developer tools not being written in PHP, I would argue that it is because of the lower skill set of the average PHP developer (more so in the past), than a shortcoming of the language itself.
Lastly, object oriented code is not a requirement for high-quality applications. Although I concede that in the PHP world, object oriented code tends to be of higher quality. Again, this has probably little to do with programming style but rather an increase in maturity of PHP developers as PHP’s object model improved. Afterall, C is procedural, but I don’t hear people complaining about the lack of high-quality applications written in C…
Dumitru (@doomhz) wrote at 12/4/2009 6:37 am:
Great! I could give a little help (if you need) if you start coding the apps on Zend Framework.
@Weltraumschaf Totally agree! PHP has so many issues!
Brandon Savage (@brandonsavage) wrote at 12/4/2009 7:18 am:
Allow me to clarify.
There are lots of these tools written in PHP. And lots of them do work well.
But there’s a difference between being a good tool, and being an enterprise-grade tool.
PHPUnit is an enterprise-grade tool. Jira was designed from the ground up to be an enterprise-grade tool.
The business types that are picking software applications are picking the enterprise-grade tools that they can either call someone for support (Jira) or hire the guy who wrote it (PHPUnit) if they need help. They’re less interested in whether or not it uses a good database, or has all the functionality they want.
I think the business types would be even less likely to accept the idea that they should endorse CouchDB, especially since when they hear about it, it’s the first time. They’ve finally gotten on board with MySQL as an alternative to Oracle; they’re not likely to rush off and try the next big thing from Apache, whether it’s better or not.
I don’t propose to start from sratch. I plan to integrate the most popular PHP tools into an application. For example, I’m not going to write a unit testing suite, a documentation suite, etc. into a CI server. No. I’m going to take PHPUnit, phpDocumentor, etc. and integrate them together.
PHP deserves to be in the enterprise. And we need enterprise-ready apps. And that is my goal.
Hans wrote at 12/4/2009 7:32 am:
I’ll throw in my 0.02.
I don’t think there’s any reason why PHP couldn’t produce a great bug tracking system, but I do think building a good bug tracker is extremely ambitious. The basic reason? You’re really building a business process management software, and to be successful it needs to be flexible (and yet still usable). I think both Bugzilla and Jira get the flexibility right; however, I’d say that Bugzilla is pretty horrific on the usability side in comparison to Jira (but can be customized to be more user-friendly). Anyway, it’s clear when you consider that you can build customer workflows in Jira, setup permisssion schemes, issue type schemes, etc. that there is an insane amount of architecture in the concepts they employ. (And I would suggest far more than a man-year of coding.)
On the topic of Continuous Integration servers, I think PHP is ill-suited to the job. I think it’s safe to say that the future of CI really revolves around the distributed model. HudsonCI is the way forward here (not CruiseControl). Or Buildbot on the python side (though that’s not nearly as polished a product). These are long-running network servers that need to be able to inter-communicate, spawn external processes, etc. PHP is really not designed for that type of application. It’s ability to communicate and interact with external processes is very limited (compared to, say, Python), it’s track record as a socket server blows (it’s designed around “share nothing”), and it has pretty limited support for binary protocols, etc. To me that just seems like the wrong platform for an app like that.
Cheers!
If just CouchDB is a problem for you, write a RDBMS (MySQL, f.e. optionally using a genric RDBMS-wrapper) storage backend for arbit. It is designed with that in mind, and it wouldn’t even be much of an effort.
But before you start with that, please get in contact with me.
Florian (@anderiasch) wrote at 12/4/2009 8:57 am:
Simple, don’t reinvent the wheel.
I see zero reasons why a CI server needs to be written in PHP.CruiseControl is actually a horrible piece of software, but it gets the job done. It doesn’t even matter one bit that CruiseControl is written in Java, you could take ant for the build.xml files and just start ant from any other CI server, just like in CruiseControl.
I do agree with the bugtracker thing, as you probably have more webservers with php available if you’re doing PHP than some with python. Then again, unless you need to change stuff, and I’d assume most people just use the bugtracker, not edit the sources, it again doesn’t matter.
Following your logic, you can’t use eclipse for PHP development, because it’s written in Java. Ban .net applications because we’re not developing .net?
Of course you’ve got more knowledge in the domain of that specific language, but I’m using hundreds of tools written in C or perl or python on a daily basis, why should I reimplent it in PHP just for the sake of it?
Sylvain Lévesque (@hexenmaster) wrote at 12/4/2009 9:39 am:
Nice initiative ! :) Interessted in having news about this !
Ciao !
Martin F wrote at 12/4/2009 9:48 am:
Jesus Christ, there are like over 9000 people in the comments talking about not reinventing the wheel and then all linking the same damn URL. (arbit)
I had to skip 75% of the comments because they all talked about the exact same stuff the previous comment did. Verbatim sometimes. Does no one see the irony of their own comments?
(if I missed someone else whining then attribute it to the fact I had to skip comments to not go insane)
jon wrote at 12/4/2009 10:24 am:
I agree with writing tools for PHP. I don’t agree with you basically saying “I am going to create the tools you need”. That’s a bit pompus. I think you may be able to re-create the tools (any true developer can), but we’ll see if it’s up to par or not to replace the existing models that have been maintained for years…
I wish you well on this venture. More developers of PHP should really be thinking like this. Re-inventing the wheel is what brings us new models with new ideas that work better than older philosophys. This is true mainly because we have had the time to see where tools have went wrong and where they need improvement. Google Wave (while it’s still a little crappy) is a great example of this. The ideas behind re-invented applications are usually great.
Again though… I know it’s good to be “confident” of your development, but to say that “your” tools will somehow “restore PHP’s name in the market” is a bit silly.
There’s a lot of people suggesting Arbits, but after downloading it and trying to install it, all I got were exceptions. I followed the directions (http://tracker.arbitracker.org/arbit/documentation/view/InstallationGuide) several times, but got nowhere.
Applications have to be functional in order for them to be useful. This one is clearly not an option in that regard.
Paul (@paulyg76) wrote at 12/4/2009 12:03 pm:
I’ve often wondered why there isn’t a Trac clone written in PHP. The greatest thing about Trac though is that it’s pretty. Arbit looks promising. It seems to need some polishing but that is to be expected for an Alpha project. Writing a MySQL backend for it would be a big boon IMHO.
I’ve also heard rumblings that PHP.net is rewriting their bugtracker. I’ve also wondered why the PHP.net bugtracker isn’t spun off into it’s own open source project that could be used for any PHP project. That would give the PHP community some real unity.
Brent Wong (@bdewong) wrote at 12/4/2009 12:51 pm:
Hey Brandon,
Good luck on your project. I agree with everything you said about wanting an enterprise grade tool.One thing I would love to see, is easy installation and setup. Most of the other tools out there have a long and involved setup process that doesn’t work on the first try. I know that “enterprise grade” and “easy setup” don’t usually work together, but “PHP” and “easy setup” most often do.
I also noticed a lot of people mentioning arbitracker. Do many people actually use an alpha product?
After looking at Arbit… Why do people always need to use SO MANY files and classes to do such a basic task? Its unbelievable how bloated some projects can get. There is a thing with being to modular.
Sigh, still going to build my own.
Kristin wrote at 12/4/2009 9:37 pm:
You’re deleting a lot of interesting comments on this thread, aren’t you. What gives?
I haven’t deleted a single comment. I don’t do that.
Eriksen Costa (@eriksencosta) wrote at 12/4/2009 10:37 pm:
Brandon,
I didn’t knew Arbit until this post. Manuel Pichler is contributing to it and they are integrating a lot of PHP QA tools (PHPUnit, phpcpd, phpmd) to it.
Sebastian Bergmann said in him last talk that Pichler was working on this to substitute phpUnderControl. If they are behind this, it will be good and in some way “enterprise” for the PHP world.
I don’t think that the storage thing can compromise the adopt of a tool like a CI server or Project Management tool. The majority of Trac deploys I know are using SQLite, that lacks a lot of enterprise appeal. And remember, anyboby knows the future of MySQL now that’s an Oracle-Sun product.
The problem about Arbit installation is one that you could have too, specially if you spread the word about your project in an very early stage like they did. I think the enterprise-way would only release it in a more stable point but, this way they would not have the benefit from an early feedback.
Do you think PHP isn’t enterprise yet?
Herman Radtke (@hermanradtke) wrote at 12/5/2009 12:12 am:
@gearvosh
That is a sign that a project is truly object oriented. Using OO (and especially OO design patterns) have the consequence of creating a lot of classes. Classes simply delegating to other classes is a beautiful thing.
There’s also flyspray… check http://flyspray.org
Nicolas BUI (@nicolasbui) wrote at 12/5/2009 6:01 am:
Hi,
Good luck to your futur project, It can be fun, I’ll be happy to participate, I really like new challenge :)
As we can see after years, PHP is capable of lot of things. But one of the few things that PHP cannot perform agains Java/Python is about concurrency. You cannot do concurrency programming in PHP (yes you can overcome but it’s just more a about a hack of something similar. ak. Job queue…).
The available entensions and libraries give your PHP power, but some of them are still limited. I can mention mcrypt per example, it’s powerfull but still limited to what can be done in Java. I had a project recently when it was impossible for to make it work in PHP if I didn’t find the way to convert certificate format.
Les wrote at 12/5/2009 6:32 am:
I do not see the lack of decent tools or apps being a PHP problem; the problem rather is that the infrastructure is not there from within the community.
What we need is someone to take leadership and better manage development not on a project per project scale but on the wholesale scale – you need a team to do that and the community has no team.
The other issue is the PHP community tends to “roll their own” so you have fragmentation all over the place; Zend Framework was supposed to suppress that but failed.
So… We need a framework to better manage and develop PHP software and that is where we developers bow out to politics – by that I mean Zend it’s self.
Get up off your fat -beep- ar*e Zend and do something? It has to be said.
> But there’s a difference between being a good tool, and being an
> enterprise-grade tool.That is very true and real even today. The partnership between Zend and et al (ie IBM anyone?) was supposed to resolve those issues.
Will the advent of PHP6 (actually) make a real difference? I doubt it – I cannot see something really big (and beautiful) happening in the PHP world that actually kicks your butt into next week.
The problem is not developers as we are many and we are (certainly) talented so the problem is politics – Zend stands out in my mind, they are responsible.
Piss poor judgement and management.
Markus Wolff wrote at 12/5/2009 8:00 am:
@Brandon: Don’t give up on Arbit so easily – if you run into problems, get in touch with Kore, he’s a really friendly and helpful guy and I’m sure he’ll help you in getting it up and running.
I’ve taken a risk by introducing Arbit (which is still in its early Alpha stages) as the official task tracking tool in the organisation I work for, and of course we had some initial problems and there was the one or the other bug. Most of those bugs were quite easy to work around though and Kore has always been very helpful and quick to fix bugs or provide workarounds.
Arbit is not yet a fully-finished product. It’s Alpha. But we use it in production regardless, because no other tool fits the bill 100% either and it’s already so good that the few flaws can be overlooked. I am absolutely convinced that, once Arbit matures, it will become the No. 1 Trac killer, and it will even take a good piece of the CruiseControl market share.
Speaking of CC, the guy who wrote the CI functionality for Arbit is the same one who authored the phpUnderControl addon for CC. Having used phpUC before, I can definitely say, yes it works, but CruiseControl is a really bloated monster and a PITA, and since now I have the chance to avoid it, I will.
One last tip: If you’ve tried only a release tarball of Arbit, just try pulling the latest trunk from SVN instead. I’m working with the Arbit trunk all the time and have no problems getting it running – and I can enjoy timely bugfixes and feature additions as well.
Exception e wrote at 12/5/2009 9:14 am:
I’ve looked into the source code, and it seems to be based on ezc.
Not totally convinced. E.g “classes\framework\base.php” tries to outsmart the php opcode cacher. This is a big no-no.
I tried to find the class “arbitController” and had a very hard hard time to locate it. Finally i found it in “classes\controller\base.php” :O
It seems that the model (e.g. class “arbitModelProject”) handles storage responsibilities too.
The code is clean and well documented, but the separation of concerns are likely suboptimal. But compared to projects like phpmyadmin this is a giant leap forward.
@Herman – Hah! Well of course it is, but I personally find it pointless. When the same can be done non-oop. Not everything needs an abstract, or an interface, or have it split into smaller objects.
> abstract, or an interface, or have it split into smaller objects.
Well, yes it does :)
If you want superior software then you use the standard and that (just) happens to be object oriented methodologies.
Drop object oriented methodologies and you drop way too many other natural benefits to software development; so enough of your bullsh*t okay?
@Miles Johnson
You could do it with functional programming (Erlang, F#, Haskell), but *procedural programming* is a no-no. OOP isn’t the only paradigm.
But I think what you are proposing is the procedural clutter as can be found in phpmyadmin etc. For this there is no defense.
Hey, that’s not cool. There was a time when I didn’t see a point to objects; now I write object-oriented code almost exclusively. It’s crucial that we maintain decorum in various debates about software development; Miles may be incorrect but that’s his prerogative.
Please keep comments polite and on topic.
sp2hari (@sp2hari) wrote at 12/6/2009 3:41 am:
I guess wikipedia, wordpress and facebook are written in PHP. Why do you think there aren’t enough apps written in PHP?
I never said im against OOP. But personally I find it pointless and a waste a time to create abstract and interface classes for everything (ala Zend). Ill stick to getting the exact same functionality done, without needing so many classes and files and still keeping it modular. Personal preference, dont need to go full OOP just for the sake to say its full OOP.
Especially for a “bug tracker”, that is installed on peoples boxes and requires so many dependencies. Something just seems really wrong about that. I can see where OOP would be perfect for large applications and websites, but not for something that should be user installed.
kiang (@finjonkiang) wrote at 12/6/2009 8:11 pm:
Maybe we should say “Why there are so many similar development tools written in php” ;)
http://www.jotbug.org/
http://thechaw.com/candycane ( thechaw is also written in PHP/CakePHP, but not available in public )
http://www.codendi.com/
James wrote at 12/6/2009 10:01 pm:
Please don’t reinvent the wheel and contribute something useful.
I’m a Java developer but I don’t expect every development tool I use must be written in Java. I use what’s best in the relevant areas.
I use Trac (Python), Redmine (Ruby on Rails) etc with which I’m fully satisfied.
Do use a IDE which is written on PHP? Do you use a UML modeling tool that is written in PHP?
There are plenty of good apps written in PHP, Python, Java, Ruby etc. Just use what serves you best.
e-75 wrote at 12/7/2009 8:24 am:
Hi,
one of the biggest problems in PHP community is desire to do something from scratch over and over again. Like some people above said, please join some open source project and share your ideas wit them and community will get a nice tool to use. Another one will be just lost in the ocean of similar unfinished projects.
Thanks,
Ivan
Hey Brandon, I don’t know if you read the php.internals list but the subject of a need for an improved bug tracker for PHP has come up. http://news.php.net/php.internals/46344.
Paul, that’s been mentioned to me, and writing a bug tracker is first on the list. Should be ready by April 1, if I keep to my schedule.
Bob wrote at 12/8/2009 4:05 pm:
Jotbug (very alpha, from what I can tell) is currently the only thing I know of that is more like a Trac/Redmine clone in PHP than Mantis is.
Fusionforge and its brethren are PHP, I think, but I’m not sure you’d want to count those.
Jon Adams (@pointlessjon) wrote at 12/16/2009 12:36 am:
@kiang and anyone else interested: thechaw (http://thechaw.com) is open source as of yesterday (http://thechaw.com/wiki/dev/logs/2009-12-14) ;) – tickets, wiki, web based repo viewers and mangement (git, svn and more — I noticed svn stuff in the source but we use mainly for git).
You can see it in action at thechaw itself or at http://rad-dev.org (we’ve done some extensive theme-ing there).
I, too, want to see more killer PHP apps around the web. Though, sites like Digg and Facebook prove that some really fantastic sites can be developed with it; php could use more tools and micro-apps pushing the bar in little and big ways. I guess that’s where we all come in. Good luck with whatever you pursue, Brandon.
Wil Sinclair (@wllm) wrote at 12/22/2009 11:29 pm:
IMO the biggest reason has been mentioned a few times, but not called out as clearly as it might be: lack of support for threads in PHP. This certainly affects the continuous integration tool and the unit test framework (Java can- and JUnit more often than not does- just start threads for a new, clean environment). You can work around it with system-level events, like cron jobs, but it’s simply not the sweet spot for PHP. PHP does seem to be a natural fit for a web-based bug tracker, however.
I’ll break from the pack a bit on the build/reuse issue. I say there are better wheels out there that have yet to be invented- both figuratively and literally. And with the ease of development afforded by frameworks and tools nowadays, brand spanking new web apps often cost less than adapting existing OSS project to your needs. Building a community around these apps is another matter, however, and that’s really the challenge in an open source app.
IMO you should do what’s best for your personal needs under the assumption that others have those needs, with consideration given to existing project. Maybe the users will come, maybe not. At least you have your tool that gets right to the features that you need. If you want an easy solution, base it on an existing framework. ;)
,Wil
| « Data Formatting: It IS Our Job | Five (Good) Lessons The Government Teaches Us About Object-Oriented Programming » |