I'm developing a cycle time report in another tool and connecting to Jira via REST api. During my research, I couldn't find any api in Jira similar to Lookupback api in Rally. The Changelog in Jira doesn't give enough information. I need to get the amount of time spent on an particular state, or how long an artifact was blocked or how long it was in Ready State. Any thoughts on how I could get his information?
Thanks,
Leo.
There is no such API in Jira. The whole state is persisted as a current values and only information about the past is in the form of a changelog.
I need to get the amount of time spent on an particular state
Then you will have to parse the changelog, find the moment when issue changed to the desired status and iterate further through changelogs to the moment when status changed to something else.
or how long an artifact was blocked
Then you need to monitor changelogs for issue links, follow those links and find when those issues were resolved.
how long it was in Ready State
Depending on what you mean by ready state, if you mean how long issue was resolved this can be taken from resolution date. If you mean for example for how long all issues in a particular version or component were resolved you could run a JQL search and sort by resolution date.
Other option to changelog parsing would be to register yourself for issue updated events and start collecting data you need, this however will only work from the moment of plugin/addon installation without data from the past.
When I am uploading new builds to the App Store, the processing times for new builds do not seem to be consistent. What I mean is that a build can go through processing quickly as in a matter of minutes and sometimes they seem to get stuck for hours or more. Needless to say, this interferes with my ability to readily use new builds for testing or for submitting them for review.
My question is, is there anything that can be done with regard to the packaging of my IPA or my build settings to obtain more consistent processing times on the App Store?
Please note that I am asking about the initial processing of an uploaded binary and not the time it takes for Apple to review an app.
I’m primarily uploading apps that use both Swift and Objective-C so the Swift runtime libraries are being included in my App Store package. I’m either submitting builds using Xcode 7.0.1 or a custom build script based on xcodebuild. Both methods have successfully uploaded builds but as I stated, the processing times can be wildly irregular and prompts me to reconsider how I am submitting my IPAs.
I want to note that this irregularity can occur at seemingly any time of the day so I’m not sure if that could be a factor.
From casual observation, it seems that newer builds will take priority over older builds. So if you have one build that has not completed processing, the newer build can finish processing before the older one. If a series of builds has been uploaded, the intermediate builds can be stalled for seemingly extended periods of time. This seems like a sensible approach in that more recent builds would have a higher priority in processing. I’m not entirely sure this is happening.
From the experiences of other people having this problem and based on my own observations, I’ve concluded that it is possible for a build to get stuck in the Processing state, sometimes indefinitely. Since Apple does not provide additional information related to this condition, the solution to get more consistent processing times is to submit a new build if a build gets stuck at Processing. Whether or not this is a sure-fire method of affecting the actual processing time is yet to be proven by hard evidence.
This question is open-ended.
App store review times vary wildly and even current time is not a reliable indicator of time if you submit now, but as a guide.
Useful utility here
I know that I can get two pieces of information about an iCloud file: the version and last modified date. The question is, when I'm dealing with two iCloud files that have the same name, would it be better to use the version or last modified date to figure out which is more recent?
It seems to me like last modified date would theoretically be more accurate, but I see many tutorials saying the version should be used to compare two files to determine which one is newer.
I would like to know what the better practice is, and why.
Last modified date is good when you're on a single computer and the system time is consistent. When you're working with iCloud you have at least three system times to think about-- the local time on at least two user devices, plus whatever the iCloud server thinks the time is. Even with NTP there's no guarantee of absolute synchronization.
NSFileVersion exists to get around this-- you can ask it for the latest version of a file, and it's supposed to find the right one. It might well have its own bugs that affect the accuracy of the result, but it's at least intended to get you the right answer regardless of time synchronization.
we want to use gerrit for code reviews but we are missing some settings in the webview.
is it possible to forbid committers to review/verify their own
commits?
is it possible that two reviewers give +1 an accumulate it
to a +2 so it can be submitted?
thanks
You can forbid self-reviews and add a +1 + +1 = +2 rule, but it isn't well documented. Newer versions of Gerrit use a prolog engine to calculate submit rules. Improved documentation for this feature is actually being worked on currently: https://gerrit-review.googlesource.com/#/c/37102/
is it possible to forbid committers to review/verify their own commits?
Yes, setup autobuild to verify all commits. You can set this up by using the Gerrit Trigger for Jenkins or gReview for Bamboo. That way nobody has to verify commits. Additionally, you can setup superusers so only a select group can actually merge the final reviewed change.
is it possible that two reviewers give +1 an accumulate it to a +2 so
it can be submitted?
No, two +1 doesn't make the +2 necessary to submit. Here's what the doc says:
The label that the reviewer selects determines what can happen next.
The +1 and -1 level are just an opinion where as the +2 and -2 levels
are allowing or blocking the change. In order for a change to be
accepted it must have at least one +2 and no -2 votes. Although these
are numeric values, they in no way accumulate; two +1s do not equate
to a +2.
The documentation that Brad mentioned in his answer is now merged into the master branch of Gerrit and available in the latest release (2.5.1 as of now):
Make change submittable only if Code-Review+2 is given by a non author
Make two +1 votes equal +2
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
There are several tricks you can use, but none of them 100% fail save.
You can use some kind of licensing mechanism.
You can store the setup time somewhere hidden in the registry.
You can store the setup time in a file (possibly an executable file or dll).
You can store the IP address in a central database and check each time if the 14 days are passed (you need a internet connection for that).
You can create a file (for example a dll) dynamically on your server and have the installer retreive that file. (Be sure to log the IP so a second attempt will not be possible).
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).