Review Code or just stare at it
Review others' code with Differential, because they can't be trusted.
...
• Shows text in several different colors.
...
Have terrible software? Keep track of all the defects and problems with
your awful code using Maniphest.
• Keeps track of bugs.
• You can assign them to people.
• Maybe you could fix them eventually. (optional)
...
The arcanist command line tool gives you CLI access to most of Phabricator's
functionality.
• Many cryptic commands.
• ...
When I read the page I couldn't tell if it was serious or some sort of April Fool's joke that someone forgot to take down and almost immediately dismissed it as something that people would actually use.
Personally I interpret language like that as "built by developers, for developers", as opposed to the "built by a committee of graphic artists and lawyers, to appeal to the CEO who imposes random decisions upon developers" feel that I get from most enterprise software...
Anecdotally, we get much more positive feedback about the tone and copy than negative feedback. It's certainly possible we're just not hearing the negative feedback, but we get plenty of other negative feedback about other things, so this would be an unusual blind spot.
The tone of the project itself is similar to the tone of the site, so if you find it off-putting or believe your co-workers would find it unprofessional, the product may not be a great fit for your environment anyway.
We also haven't heard feedback about anyone having difficulty convincing others to try Phabricator because of the project's tone. Again, it's possible we're just not aware of it, but we have heard feedback about other issues in this vein (for example, the LAMP stack being a hard sell).
Evan, thanks for all the hard work on this project.
We use it every day at work. At first we were like, what is this 'Clowncopterize' button? But then we enabled the serious business flag and we were off and running.
We use Phabricator at Bloomberg and I'll take the opportunity to shamelessly plug the add-on tools we've open-sourced to make working with it even easier:
We use phabricator. It has some really nice features.
* Easily automatic updating.
* Really nice code reviews.
* Many features built in.
It also has some very terrible downsides:
* It expects you to use its work flow (though you can work around it) for merging code back into master.
* It requires manual config per git repository.
* arcanist is a pain to install (and php)
* Its expectations don't seem to quite match up with gits. It seems to often have trouble figuring out what I'm trying to send for code review. I've given up on it being smart and now just always run: `arc diff master` or `arc diff master --update D<ID>`.
1. `arc land` is optional, and always has been. If you don't want to use it, you can just use normal `git` commands. All `arc land` gives you is a few checks against human error.
2. `.arcconfig` is no longer required, although if you want to use integrations like lint, you'll still need to configure them.
3. Anything we can improve on?
4. You should be able to use `arc which` to understand what `arc diff` will do. You can change what `arc diff` will do by specifying a different set of "base" rules, according to this document:
We use Phabricator at my company. It's a fantastic issue and task tracking tool kit. The addition of Arcanist and it's integration with git is awesome. Highly recommend trying it. I've used a lot of similar systems of the years (bugzilla, Jira, and others). Phabricator blows them away.
First used phabricator as an intern, and later brought the toolset for class projects (Compilers and now thesis-work). It's been massively helpful, and like others have commented, their IRC is active and helpful.
FWIW, a friend who'd never used the tool got up and running (after a kind of messy install) in less than 2 hrs. For any other undergrads out there doing any serious project work with people, this is worth your time. I mostly use it as a personal task-manager (asana would do the job), but I like how good its command line tools are, and how I can do just about anything from terminal.
Well that would explain the high churn that I've been noticing with my tool. I've always been curious about why they were iterating at the pace that they are.
I know for instance that the Rust project has had some frustrations with Github when it comes to code reviews, possibly for issue tracking too. Does anyone have any experience with phabricator as a bug tracker?
Phabricator was one of the first tools I brought to my latest company. We primarily use it for Differential because the arcanist command line tool is so easy to use. Even those that are somewhat git challenged benefit as it handles merging commands for you when you land a review.
The IRC channel is a great place for Q&A and epriestley et. al. are always there to offer help.
Before you bash it for being written in PHP, take a look at the source; it is unlike any other PHP code I have ever seen.
Don't take this the wrong way but this is still PHP and I say this as someone that's been writing in PHP since 2001, although I've largely shifted away. It didn't take me long to find some really crazy stuff like these nested try-catch blocks in:
// If execution throws an exception and then trying to render that exception
// throws another exception, we want to show the original exception, as it is
// likely the root cause of the rendering exception.
I'm not saying this is a bad project, it looks excellent and the code is pretty good but you can't escape having to do some nutty things in PHP.
I wrote this code, but I'm not sure what's wrong with it. Can you explain what's bad about it and how you'd improve it?
---
To provide some context, this is the top-level entry point for all requests. It routes requests to code which does application-level things, like showing a code review or updating a task or whatever.
When the application-level things go wrong, we try to display a pretty, human-readable exception page with a nicely formatted stack trace (if you're in developer mode), etc. This page relies on some infrastructure subsystems (like configuration, to check for developer mode, and static resources, to include JS and CSS, and rendering, to actually produce the HTML) working correctly.
Normally, the exception is in application code and everything works fine. We produce a pretty page and send it back to the user.
However, sometimes there's an error in one of these subsystems. If we start rendering the page and encounter a second exception during rendering, we fall back to a less-pretty page which has bare text and no dependencies on subsystems. Normally, this happens during development when you've made a mistake in changing one of the subsystems, and all JS inclusion or all configuration checks are failing.
On this bare page, we want to retain the original exception (as well as show the followup exception) because it may be helpful in identifying and resolving the issue.
With the obvious caveat that I wrote the code, this architecture seems sensible and appropriate to me, and appears to function correctly in practice.
I apologize for the late response I was looking at more of the code trying to get a better feel for what it is actually doing.
To answer your question, I'd start with why you are worried about exceptions in rendering your exceptions? Whatever you are using to render your exception should be so simple and stable that you shouldn't need to worry about it.
Also another question, from a fairly quick glance and I admit I didn't read through every last line of code, it appears as if all application execution is wrapped in a try/catch block, instead of exceptions being caught and handled closer to the potential points of failure is there a reason for this?
And one nitpick, because it was kind of a pain to follow some of the code but nested if/else statements five/six layers deep are generally kind of discouraged.
Thanks for taking time out of your weekend to respond and good luck to your team!
Actually I'm not, I think PHP is a perfectly good language for certain things I'm just not blind to the issues with the language. I responded with my reasons that I believe that particular piece of code isn't so great.
Phabricator is definitely interesting. In my limited time with it I really took a liking to it.
Unfortunately, to me, the Atlassian toolchain still wins out over it, provided it's within the budget. I vastly prefer Jira's Agile boards to anything else I've ever used, and it's integration with Stash and Bamboo just make things absolutely lovely.
Phabricator looks so useful, however the one time I tried setting up it up I found it to be an absolutely horrific experience. The documentation was so so and I could never figure out some weird issues with permissions that prevented me from ever getting it to work properly. I really wanted to like it, but I got the impression that so many comprises have been made to it to accommodate the needs of every single development team out there and their esoteric set ups. It would have been much better served saying no to features and promoting a plugin-based approach where you get a dead simple set up out of the box and then extend it as necessary. The fact that there are several dozen configuration guides doesn't help much:
https://secure.phabricator.com/book/phabricator/
I'd love it if someone started a project like phabricator but in community with a decent package manager and robust module ecosystem like node.js, python, go or ruby, with go or node.js being my first choices. Large monolithic projects with half-baked plugin management and profiteering seems to be a recurring theme in the PHP ecosystem (joomla, drupal, magento, wordpress). I feel that a project like this birthed in one of those other communities would promote a much simpler core product the can grow with your needs.
I'm really not trying to hate but just vent some frustration.
On the other hand, looking at the site today, it looks like it might have changed a lot since when I first tried it like 2 years ago. Might have to give it another go.
I still use the redmine which supports git well for me, for all my software stuff plus acting as a nice project management tool. I wish it's not developed in Ruby, so I could have one less language(and its dependencies) to maintain on the server side.
how does this compare to redmine, or gitlab?
Unfortunately, this requires MySQL. I guess it would be okay if you're already running that but I'd rather not introduce a third database daemon (after Postgres and Redis) to my servers.
What's so baffling is a behemoth that attracts some of the top engineers would settle for 2 vastly inferior technologies. To be fair, it is a glorified todo / commenting system.
MySQL works pretty well when you treat it as an unreliable network-accessible key/value store; and PHP works pretty well if you treat it as a pure templating language, and also write your own implementation, and also rewrite the language itself to be a different, better language :P
I must say, there is one concern that keeps me away from using otherwise great Facebook technologies like Phabricator and React is that I don't believe Facebook will be here in 5 or 10 years.
What will happen to these projects if that is the case?
http://phabricator.org:
http://phacility.com/: