We are interested in finding out some statistics of various frameworks
Mailing list activity on say richfaces. Much similar to what is available on http://code.google.com (Low, Medium, High) + average number of emails per day | per month.
Number of releases made in a year including patch, minor, major releases. We did look at the maven repositories but that wasn't very useful either.
We did look at ohloh, but didn't get the desired information. Any other ideas on where to get this information (any maven-2 plugins)?
Mailing list activity on say richfaces. Much similar to what is available on http://code.google.com (Low, Medium, High) + average number of emails per day | per month.
You'll get these informations on markmail (check also the other lists for richfaces, e.g. the svn-commits).
Number of releases made in a year including patch, minor, major releases. We did look at the maven repositories but that wasn't very useful either.
I would use Jira's Change Log for that.
Related
For example, on nuget.org there are these preview packages published for System.Text.Json:
6.0.0-rc.2.21480.5
6.0.0-rc.1.21451.13
6.0.0-preview.7.21377.19
6.0.0-preview.6.21352.12
6.0.0-preview.5.21301.5
6.0.0-preview.4.21253.7
6.0.0-preview.3.21201.4
6.0.0-preview.2.21154.6
6.0.0-preview.1.21102.12
I get the 'preview.n' and 'rc.n' parts. I believe these relate to the wider .NET releases.
I wondered if the third number is number of days since some baseline date, but that doesn't seem to be consistent (based on subtracting that number from publication date you get different baseline dates); if it was then I would have guessed the fourth number to be the build number within a given day.
I ask because I am interested in understanding what package versioning strategies are in use in the wild, and whether there is anything to be learned from this scheme in use by Microsoft.
I am working on a trading bot and I wanted to train it by getting a list of my order history from Binance for a specific period of time. I looked at the API documentation here, but it seems that I am always required to provide a ticker symbol. While iterating over all tickers is an option, it will take forever to complete (I'm trying to get data for a full year). Can anyone point me to a less stupid way of doing this?
P.s. I also looked into allOrdersList but that only provides OCO orders and that is different than regular orders. See here. Any help would be greatly appreciated.
It's not currently possible (still, as of June 2021).
Many developers are complaining about the lack of such a commonly-used endpoint. See https://dev.binance.vision/t/fetch-all-account-orders/279
The only workarounds seem to be:
Looking at the user's current coin balances, and iterating over those relevant trading pairs (although this will miss the trades where the balance is now zero)
Iterate over every symbol offered by Binance – and there are a lot! This is ridiculous, and requires careful management of rate limits, but appears to be the only comprehensive solution.
Add your voice to the thread above, so that perhaps Binance might implement a more sane endpoint.
Loop over all symbols once to get your entire order history. Then save the distinct symbols to a file/database. Then every time you make a order and it's on a new symbol append that symbol to your file/database.
I'm having hard time with this project, I'm building a boat configurator which is divided in categories / packages / extras.
Each category is disconnected with the other, so it's not a big problem.
The problem comes out with packages and extras. Extras are options that can be chosen within a package (increasing the total price). I'll explain all dependencies that can exists between these 2 objects:
There are times where you can also purchase a package all toghether, which could have an extra (or 2) that are upgrades to that package
There are times where you can buy a single package between 4-5 and additionally you can buy some extras in another 6th package
Sometimes an extra can be bought only if you have at least one item in a given package
Sometimes an extra can be bought only if you have a specific extra
At the moment I don't have any other dependency in my mind (but I'm sure there are others possible).
I don't know which approach I should take to store all this dependencies, I have 3 basic sql tables (category, package, extra which are not connected because a Package => Extra dependency could be different for other categories) and CategoryRelationship, PackageRelationship, ExtraRelationship but I'm having hard time in express some dependencies, expecially the 2nd which is not limited to a single id field.
How is normally handled all these interdependencies?
I never faced this problem, thanks for any suggestion
Edit 1:
I'm thinking about changing the approach to 1 Table for each "type" of dependency, can it be considered a good way to handle instead of a single table with all type of dependencies?
Because no one answered this, I'm posting the approach I finally used for this project and which I find interesting.
I created 1 table for each type of dependency (as I told in Edit 1). Each table can have multiple reference to an item of any id and is possible in this way to organize quite well all columns that represents dependencies.
The approach is inspired by CakePHP Validation model, where each validation is a class that has a validate method which will be run.
Hopefully this will help someone else; I'll mark this as answer if no one provide an answer with a better suggestion.
I'm working on a large project, for which several thousand branch types are defined, and would like to quickly retrieve a list of "my" branch types. This can be achieved either by listing branch types created by me, or by listing branch types whose names start with my username.
As the full list is huge and lstype runs for approximately an hour normally, is there a way to formulate a query that can be answered quickly?
I never found a native command able to return quickly an answer.
When looking at the cleartool lstype command, the technote "LSTYPE performance improvements" does mention that:
The -short, -nostatus and -unsorted options can be used to improve performance of the cleartool lstype command
But as with everything with ClearCase, this doesn't stand the test of the real world, where the number of (here) types quite be really big...
So what I usually do for this kind of request, considering I don't create a brtype every 5 minutes, is to have a batch job running every 2 hours, updating a list of brtype with the informations I need (owner, date, ...).
I can then at any time filter that file (at least the most updated version of that file) in order to extract the list of brtype I need.
There is the risk this list isn't up-to-date, but in practice this works relatively well.
I use Trac regularly in a team at work, as well as for my own project for the university. In both cases I have never felt the need to use the severity property for a ticket. I feel that by using the type and priority properties gives all the information I need, and I cannot think of anything to do with the severity property that would not be redundant. Does anyone have any good usecases for the severity-property?
You can treat priority and severity as orthogonal values.
The severity can indicate how costly the bug is: low severity could be "the color of this icon is wrong" and a high severity could be "computer hunts down and kills user".
The priority is how urgent it is to fix the problem. An icon that uses the company's biggest competitor's corporate color may be high priority, whereas a deadly error that can happen once in a million years may be a low priority.
You can then work on things based on the priority times the severity; something that is medium severity and medium priority may be more important than something that is low severity and high priority.
OR
You can give the ticket owner control of the severity, and the developer control of priority. That gives you a way to see where views differ without having edit wars over the single priority field. But done naively, users will simply set the severity to the greatest value they can, and you lose all usefulness in that field. (And no, I don't pretend to have a useful, tested-in-the-real-world solution to that. There are lots of possibilities to play with though.)
But honestly, a single priority field of high/medium/low has worked well enough for me in all of my projects. A separate severity field just seems like additional complexity for negligible benefit.
Discloser: I'm one of the Trac devs
Ok it's an old question but I guess I'll weigh in with a very unusual, but quite useful, use case.
Background: I actually use a Trac system to manage my (real) life. Like, I create tickets such as, "Install smart lights in kitchen", "Buy tickets to ball game", "Get flu shot", and so on. This is because I'm very bad at keeping to a schedule, but having a tidy list of tasks and milestones that I set out for myself works for me.
Anyway, I use the Severity field to indicate my anxiety level for that particular task. The severity levels range from "no_problem" to "needs_concerted_effort" to
"panic_attack". (I have about a dozen, and some are special cases.) Whenever I'm in a mood to tackle something hard I'll pull up a report of tickets with high priorty and severity; if I'm feeling defeated by life and just want something easy to take my mind off things, I'll pull up a report of high priority, low severity tickets.
Another example: though it's not quite the most accurate usage, at work we use the severity field to indicate how much time we expect the task to take. The levels are "minutes", "hours", "days", "weeks", and "months".