We were checking the feasibility of using Phabricator in our software development activities.
We are currently using JIRA and is looking for a lighter replacement. We feel JIRA as a generic tool that doesn't only focus on software development and Phabricator for us looks lighter and well integrated.
One feature we couldn't find is Work logging. Currently we are using jira work logging feature for extracting data for project management reporting.
So basically my query is
Is work logging feature available in Phabricator ?
Would it be possible to extend the Phabricator for this purpose ?
Technically, yes, there is a work logging feature called Phrequent. It is one of the prototype applications in Phabricator (prototypes must be turned on from Config).
However, it has a lot of missing features. While individuals can start and stop work time on tasks, they cannot edit or delete time entries, and the reporting features are less than ideal (you can only view by person, not by time range or task). More features are planned, though they appear to be low priority right now for the core development team.
Related
I would like to ship some new features just for a specific group of users to better test it in production and then release it progressively to everyone, should i put IFs in my code and assign specific policies to users in the database?
Is there a better way to do it?
The normal way to handle this is have two versions of your software. The "main" version is the one most people are on, but you also release an "experimental" version which has the new features.
There are various ways to manage the software, but you should look to use strong version management practices in your source code repository, perhaps using some good branching techniques. You should avoid the two versions from diverging too much.
You can choose to invite certain users to the "experimental" version, or have them opt in but give the necessary caveats that things might not work as well, and if you have any SLAs then you might want to caveat them. If you are hoping users will provide you with feedback then make sure there is a good mechanism for that and that the users are aware of it.
If you have client software then uses will need to get hold of the new version themselves. If your software is purely server side (eg a web application or SAAS platform) then you might look at a routing layer eg in the load balancer which automatically sends users to the normal or experimental version depending on whether they are part of the relevant group.
This is a common scenario in software and you should be able to do some good research. I suggest you start by looking into A/B testing.
I am working for a client and they are creating an application that they want to host on Unified Service Desk.
As you all know that Unified Service Desk's new version 4.1 has been released earlier. I read a related article on Microsoft as well that things to keep in mind when you check the existing Unified Service Desk Version.
But the thing I want to know here is on what technologies should they built there third party applications are there any nitty gritties that
Are there any points that should be considered so that we can make an application compatible and workable inside Unified Service Desk,
I want to know like,
What platform should they consider
What Language should they consider
And any other specific details that we keep in mind before
creating the application
Any help would be appreciated.
This can depend on their internal dev skillset and whether they want the application to be accessible outside of USD. For web apps, they should consider whether they are targeting a browser that will have long-term support from Microsoft. We're starting to see Chrome support, and will eventually see Edge support also. IE will eventually go away, but it's not clear when. If no one needs the application outside of USD, then a C#/XAML compiled control would naturally provide reliability and speed above and beyond any web app.
We currently have a system that handles translation jobs.
customer creates an order
the project manager hands it over to one or more translator
then it goes to a proofreader
language manager checks quality, if bad, job goes back to translator
project manager delivers it to client
Currently all the status can be assigned manually and/or overridden.
Meaning any step can be skipped or set back.
The app is a ASP.NET WebForms / MVC mix.
Now I would like to re-implement this with Windows Workflow Foundation. Would a State Machine make more sense than a Flowchart?
I'm not really getting the advantage of the State Machine...
Given the way you describe the job you are really switching between states. So using a state machine sounds the logical approach. However it would be perfectly possible to do this using a flow chart and that would certainly be easier to explain to business users.
Now the good thing is you can mix and match state machine and flow chart as needed/wanted.
I prefer StateMachine for most scenarios like this. It is definitely possible to do what you want to do. You should spend some time exploring it. You might want to start with Introduction to State Machine Hands On Lab
We're looking into implementing an issue tracker for our web agency. The problem is that most issue trackers seem to revolve around the assumption that an issue is a bug, whereas in a web agency environment, a lot of the issues (request, or whatever you want to call them) are about changes and additions to a current web site.
It also seems to me that a lot of issue trackers assume that you're working on one main software project, and uses that project as the focus of the tracker. A good issue tracker for a web agency would be one which puts each separate client and their issues at the heart of the system, making it easy for them to track and report issues.
Does anyone know of a good issue tracker for the web agency workflow? What are other people using?
In my experience, issue trackers are so closely coupled to the workflow of the organisation that what works in one place may be a complete misfit in another. That said, could basecamp work for you?
We are using Gemini very flexible with the ability to have workflow at the project level.
But where Gemini really helps us is the cross project views. You can view your work across all projects with really good fitering.
Have you had a look at fixx at all? Obviously, being the developer of fixx, I will want to plug it but I know from first-hand experience that a lot of our customers are web agencies who work in a service-oriented environment and need to track more than just "software development" projects.
With fixx, you can define custom issue types (for example "change request" or "Copy changes") and track work against that type.
Unfortunately, fixx still does suffer from the "project-centric" view but a lot of our customers work around this by defining a project per client/website. So, if you were doing web/maintenance on stackoverflow.com, you would have a project called "stackoverflow.com maintenance" and would assign all your users from that company to that specific project. From there, using notifications and filters, it would be very easy for clients to keep track of progress on their specific issues.
FogBugz – it's simple by default, but extensible; it's got an integrated wiki, charts, tags, and you can even tie it to your source-control system (and they also offer their own integrated source control system, Kiln, which is pretty amazing with FogBugz).
Are you using other applications to manage the rest of your business' operations?
I ask because WORKetc has great issue tracking software, and this software is combined with other aspects of business management which can simplify the management process. So not only could you manage all support inquiries and responses in one place, but also your projects, finances, and contacts. Most importantly, it would allow you to use one central contact base for your entire company, while allowing you to reference that contact information (as well as lead information) while working on support inquiries, projects, invoices, etc.
WORKetc's support system works around email integration and simple ticket system (as well as prioritizing) and directly integrates with projects, contacts, and other aspects of the system so that you can save time while responding and managing tickets.
I think especially for the use case of a web-agency, where it's not really about bugs, but mostly (visual) feedback and all of it happens on the web, a visual feedback tool might be the thing you're looking for. Most of these tools will create a screenshot of the webpage and include the given feedback on it.
Some of them also have some kind of dashboard where you can discuss further, or have integrations to other tools like Basecamp (and some them do both).
Here's an article from smashing magazine, which describes a lot of them, e.g.: TrackDuck, BugMuncher. Another great tool the article doesn't mention, maybe because the article is a bit dated, is Usersnap – this one even includes browser extensions.
I have searched through google and SO for possible answers to this question, but can only find small bits of information scattered around the place, most of which appear to be personal opinion.
I'm aware that this question could be considered subjective, but I'm not looking for personal opinion, rather facts with reasons (e.g. past experience) or even a single link to a blog/wiki which describes best practices for this (this is what I'd prefer to be honest). What I'm not looking for is how to make this work, I know how to create a self updating desktop application.
I want to know about the best practices for creating a self updating desktop application. The sort of best practices I'm especially curious about are:
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
How often should you check for updates? Weekly/daily/hourly and exactly why?
Should the update be visible to the user or run behind the scenes from a UI point of view?
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
Should you allow users to update from a central location or only allow updating through the specified application? (for closed business applications).
Surely there is some written rules/suggestions about this stuff? One of the most annoying things about a lot of applications is the updating, as it's hard to find a good balance between "out of date" and "in the users face".
If it helps consider this to be written in .net C# for a single client, running on machines with constant available connectivity to the update server, all of these machines talk to each other through the application, and all also talk to a central database server.
One best practice that many software overlook: ask to update when the user is closing your application, NOT when it has just launched it.
It's incredible how many apps don't do that (Firefox, for example). You just ran the app, you want to use it now, and instead, it prompts you if you want to update, which of course is going to take 5 minutes and require restarting the app.
This is non-sense. Just do the update at the end.
It's hard to give a general answer. It depends on the context: criticality of the update, what kind of app is it, user preferences, #users, network width, etc. Here are some of the options/trade-offs.
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
As a developer your best interest is to have all apps out there to be as up to date as possible. This reduces your maintenance effort. Thus, if the user does not mind you should update.
How often should you check for updates? Weekly/daily/hourly and exactly why?
If the updates are transparent to the user, do not require an immediate restart of the app, then I'd suggest that you do it as often as your the communication bandwidth allows (considering both the update check-frequent but small-and the download-infrequent but large)
Should the update be visible to the user or run behind the scenes from a UI point of view?
Depends on the user preferences but also on the type of the update: bug fixes vs. functionality/UI changes (the user will be puzzled to see the look and feel has changed with no previous alert)
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
same arguments as the previous question
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
if app size is small download it from scratch. This will prevent all sort of weird bugs created to mismatch between the different patches ("DLL hell"). However, this may require large download times or impose heavy toll on your network.
Should you allow users to update from a central location or only allow updating through the specified application? (for closed business applications).
I think both
From practical experience, don't forget to add functionality for updating the update engine. Which means that performing an update is usually a two step approach
Check if there are updates to the update engine
Check if there are updates to the actual application
Do you force an update if the clients
software is out of date, but not going
to break when trying to communicate
with other version of the software or
the database itself? If so how do you
signify this breaking change?
A common practice is to have a "ProtocolVersion" method which indicates the lowest/oldest version allowed.
The "ProtocolVersion" can either supplied by the client or the server depending on the trust level you have between the client and the server. In a low trust level it is probably better to have the client provide the "ProtocolVersion" and then deny access server side until the client is updated. In a "high trust level" scenario it will be easier to have the server supply the "ProtocolVersion" it accepts, and then all the logic for adapting to this - including updating the client application - implemented in the client only. Giving the benefit that the version check/handling code only needs to be in one place.
Do not ever try to force an update unless your lawyers demand that. Show the the user a update notification she can either accept or ignore. Try not to spam the same version too much is she rejected it. The help her make the decision, include a link to release notes or a short summary of changes.
Weekly would be a good default update check interval but let the user choose this, including completely disabling update check from the web. Do not check too often because she might be on an expensive mobile data plan, or she just doesn't like the idea of an application phoning home.
The update check part should be completely silent. If an update was found, display a notification for the user. During download and installation, show a progress bar.
To keep this simple, notify the user about any newer version. If you do not want to annoy them with frequent updates including just a few minor bug fixes, do not release every minor version at the download location watched by the update checker
Maintaining patches for all previously released versions is too much work. If the download size becomes a problem, figure out some other way than patches to make it smaller (7-zip compressed self-extracting exe, splitting the application to multiple MSI packages that have independent versions etc)
Two more things:
Do not implement the update engine as a process that is constantly running in the background even when I'm not using your application. My PC already ~10 such processes hogging resources, which is very annoying.
When updating the update engine itself, on one hand you need to have the engine running to show the installation progress UI but on the other hand the update process must be closed to avoid the reboot that would result from the exe file being locked. There are a number of things like running a helper program from %TEMP%, using Windows Installer restart manager, renaming the updater exe file before starting the installation package etc. Keep this in mind when architecting the update engine.
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
Ask the user.
How often should you check for updates? Weekly/daily/hourly and exactly why?
Ask the user.
Should the update be visible to the user or run behind the scenes from a UI point of view?
Ask the user.
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
Ask the user (notice a trend here?).
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
Typically, patch, if the application is of any significant size.
As far as the "ask the user" responses go, it doesn't mean always prompt them every single time. Instead, give them the option to set what they should be prompted for and what should just be done invisibly (and the first time a given thing occurs, ask them what should be done in the future, and remember that). This shouldn't be very difficult and you gain a lot of goodwill from a larger portion of your user base, since it's very hard to have fixed settings suit the desires of everyone who uses your app. When in doubt, more options are better than less - especially when they're the kind of option that's fairly trivial to code.