I run daily a job. Today, that job takes 1:45:09 hrs. I have a lot of such durations for that job from the past weeks and I want to be able to show that graphically using a simple column chart. On the Y axis I want duration ticks from 0:00:00 - 5:00:00 or so that I can easily compare the runtimes from the past weeks and see if the job is gradually taking longer and longer.
I have read and implemented a lot of answers from StackOverflow and other internet resources but none of them fit my purpose. When using unix timestamps (since 1970, etc) I get columns that are all of the same hight and Y-axis ticks in years instead of hours from 1970 to now.
Another option was to just calculate the minutes or seconds. Then the difference become appearant, but instead of time elements in the Y axis and tooltips I get integers.
Can someone show me how to achieve my goal in a fiddle? The question looks common enough to me for any monitoring software.
-- EDIT --
Here is a Photoshop sample of what I am trying to achieve:
On the Y-axis: a time scale. In the tooltip: date, objectname and time taken.
-- END EDIT --
BTW, I have no chart type preference. The usual column charts just seem to fit the purpose.
Thanks for any help!
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I build a machine learning algorithms to predict Y' value. For this, I used Log value of Y for data scaling.
As I got the predicted Y' and actual Y value, I have to convert Log value of Y&Y' to Exponential value.
BUT, there was so huge distortion from the values over exp7 (=ln1098)... It makes a lot of MSE(error).
How can I avoid this huge distortion?? (Generally, I need to get values over 1000)
Thanks!!
For this, I used Log value of Y for data scaling.
Not for scaling, but to make target variable distribution normal.
If your MSE arises when real target value arises too - it means that the model simply can't fit enough on big values. Usually it can be solved by cleaning data (removing outliers). Or take another ML-model.
UPDATE
You can run KFold and for each fold calculate MSE/MAE between predicted and real values. Then take big errors and take a look which parameters/features this cases have.
You can eliminate cases with big errors, but it's usually dangerous.
In general bad fit on big values mean that you did not remove outliers from your original dataset. Plot histograms and scatter plots and make sure that you don't have them.
Check categorical variables: maybe you have small values (<=5%). If so, group them.
Or you need to create 2 models: one for small values, one for big ones.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a one week sprint, with workdays as Mon,Tues,Wed,Thur,Fri.
Yet the burndown chart only shows 4 days (4 blocks).
The horizontal axis has 4/24, 4/25, 4/26, 4/27, 4/28 but the chart doesn't show the last day as a whole day.
It only has 4 blocks.
Also the black Ideal Trend line correctly starts at 20 on 4/24 but ends on the 4/28 point.
It should end at the end of the day on the 5th day 4/28.
It also is incorrectly showing 5 hours a day ideal burn down for the one person working on the team.
I have entered in 4 hours a day capacity for that person.
Anyone have suggestions as to what I might be doing wrong?
Is there a workaround or another marketplace tool to use that works better?
I'm trying to do the least amount of customization in VSTS and walk a mile in their shoes.
But the Burndown chart is unusable in this simple case.
The 4 blocks don’t represent 24 hour of each day, it’s just the area which shows the trend between two days. And the five working days on burndown chart only represent by 5 point (4/24, 4/25, 4/26, 4/27 and 4.28). You can verify by changing remaining work for a day (such as 4/26 is for below example):
The remaining work is 14 before 4/26, and you change the remaining work to 10 for today (4/26), the burndown chart will be:
Now if you continue change the remaining work from 10 to 5 today (4/26), the burndown chart will looks like:
You can still change remaining work from 5 to 0 today (4/26), the burndown chart will be:
From three times changing remaining work on 4/26, only the trend of block between 4/25 and 4/26 is adjust as liner to meet the changes. So that means 4/26 on burndown chart only represemt as a point not a block.
As your understanding, you defined the capacity is 4 hours per day, this is reflect on Available Capacity:
4/24 remaining work 16
4/25 remaining work 12
4/26 remaining work 8
4/27 remaining work 4
4/28 remaining work 0
For Ideal Trend:
The Ideal Trend line connects the two points:
(1) Team's total capacity at the start of the sprint
(2) 0 Remaining Work at the end of the sprint. The slope represents the rate at which the team needs to burn down work to finish the
sprint on time.
Ideal trend start with a sprint’s total capacity, so it will start with 20 and the rate will be 5 hours per day. This is more aggressive than available capacity since daily remaining work are always fluctuate and it’s hard to keep it liner.
More details about burndown chart, you can refer sprint-burndown.
Beside, since you need to precise to hour/minute, you’d better check the time zone for VSTS if it's same as your area in https://account.visualstudio.com/_admin/_home/settings.
Correct burn down as per Marina's tips in the comments above. Changing the Sprint calendar days to 6 days and the working days to Mon-Sat. The Ideal trend line now correctly matches the team capacity of 8 hours a day (1 person). Posting this as an answer to provide an image of the correct burn down chart.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm torn between two worlds, I have this very intuitive (but intricate) mechanism in a command line tool, and I'm wondering as to what extent I should explain this.
I can go the simple way, not explaining it at all and trust my users to figure it out themselves, but then some users might never discover this particular feature.
I can go the scary way and put a lot of mathematical notation into the help output and the man pages, but then users might think this is too complicated and they might develop an inexplicable fear towards my tool or this particular feature.
How can I address both experimental and, let's say, conservative users (the ones that don't go the extra mile when something isn't explained properly)?
Details:
The tool is about date and time arithmetic, in particular calculating durations between two dates and/or times, and formatting the results according to format specs.
My internal design uses a multiplication table like this:
- x d t dt
x x x x x
d x D x D
t x x T x
dt x D x S
where x is unknown (unparsable) input, d is a date, t is a time and dt is a datetime, D is a date duration (resolution is 1 day), T is a time duration (resolution is 1 second), and S is a time-stamp duration (resolution 1 second).
Now the result depends on the duration type and the format specifiers given, and I'm really lacking a succinct way of explaining this, so I do it by example:
'%d' will return the duration in days (like 12 days)
'%w' will return the duration in weeks (like 1 week)
'%w %d' will return the duration in weeks and days (like 1 week and 5 days)
...
'%S' will return the duration in seconds (e.g. 86464 seconds)
'%M' will return the duration in minutes (e.g. 1441 minutes)
'%H' will return the duration in hours (e.g. 24 hours)
'%H %M %S' will return the duration in hours, minutes and seconds (24h 1m 4s)
'%H %S' will return the duration in hours and seconds (24h 64s)
...
I mean I could probably work out what I mean with just these few examples given, but there's no formal explanation or anything in there.
For clarity:
The issue I'm trying to address is that you can combine any of the flags (seconds, hours, days, months, etc.) and the program will "intelligently" give you a result. Like %Y %d would give you a year and the number of days (in the range 0 to 365) whereas %Y %m %d would give you the days in the range 0 to 30 (because the rest is "captured" in the month).
Example: %Y %d gives 1 year 90 days whereas %Y %w %d gives 1 year 12 weeks 6 days
If you're looking to create help text within the tool itself, look at the help for the linux date command.
Alternatively, you could do something like this:
$ your_app --help
usage: your_app [OPTIONS] [FORMAT]
Returns the elapsed time between blah blah....
FORMAT:
// list formats here
OPTIONS:
--help Display this help text
--help-detailed Display more extensive help text
--help-examples Display example uses
If I were the user, I'd want --help to list all of the options as a reference, and I'd want the man pages to include as much detail as possible. I tend to use --help as a reminder and the man pages as the authoritative reference.
And no matter how well-written the text may be, a few concrete examples are always valuable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What is the good resolution of time to use for estimating duration of your tasks?
is it like 0.5, 1, 2, 5 days or should you go down to hours like 0.5, 1, 2, 4 hours and then continue up to days?
should a change to a label text be task at all? ( ETA < 1min )
Suggestions?
Scrum uses values of 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The time of the values is in hours, when you plan in finer detail (breaking down feature requests into technical tickets) and days, when you plan the bigger picture (big-picture features).
In general, if you estimate a ticket over 20 hours (or 20 days), your tasks should be split up into smaller pieces.
Well, it really depends. Personally, I like tasks to be smaller (should be estimated in hours, usually using the something close to Fibonacci series: 0.5, 1, 2, 3, 5, 8, ...).
About small tasks, usually they should be estimated too. Even minor changes require some work like creating tests, seeing if none of the other ones broke, sending to server, etc. You could create a 15 min in the series for stuff like these :)
It's really hard to predict the future.
The units (minutes, hours, days, weeks, fortnights) don't matter.
Pick a unit that makes your manager happy.
Just be clear that an estimate of 30 minutes, .5 hour or .0625 days is only a guess, not a fact.
An estimate of 0.0625 days or 30 minutes looks really precise because it has a lot of decimal places. However, any ambiguity about the requirements, the architecture, the language, the libraries, the unit tests, or anything else will make this number incorrect.
The very best you can hope for is that the average of all your estimates is reasonably close to the actual facts as they unfold. This means that half your estimates will be too low and half will be too high. It also means that some fraction of your estimates will be really, really far from your manager's hoped-for accuracy.
Planning and estimating time required is never the goal of your project, so those units must serve some purpose.
The good rule to use is this: split the task into smaller chunks, until you know exactly what you should do next (and it is not planning). This "knowing exactly what to do" thing is a little subjective, but tasks longer than 2 days rarely fit into this category.
I guess it depends on how accurate you want to be.
I personally use minutes as "days" or "months" can be misleading time periods. For example if you say something will take 1 day - does that mean 24 hours solid work? Or 8 hours? Or the average 3-4 hours of productivity within a working day?
All tasks should be listed, but if they are small you can often group them. But remember that just because it's only changing a label text there is more time involved that just changing the label, you have to find it, open the file, make the change, commit the changes, update any documentation, test it etc - so tasks very rarely only take less than 1 minute.
Also try to put an upper limit on the task time. If your adding tasks that are taking over 3-4 hours, break them down into smaller sub-tasks and list those. This will give you a much more accurate estimate.
I have found myself sorting tasks into these categories:
Half a day
Whole day
Whole week
Several weeks
In my work environment where we do a lot of second-level support, it doesn't make sense to have a more granular system. It is also good to have some slack in the planning, so that you can take an hour to make small improvements to your work environment.
I tend to use units of hours should they be appropriate (1h, 4.5h, 6h, etc). Once days creep into the equation then I tend to not use hours and keep days as the only unit being used (3d, 7d, 10d). Overestimating slightly gives room to accommodate those undesired but expected complications you will hit along the way.
There's a difference between est. work effort - how long something should take to complete - and est. when something will be done (aka duration) - when that something is expected to get completed based on other tasks.
You can never predict the future and any est. is just that - an est. - the likelihood of being able to predict 1 week out in 1/2 hour increments isn't that great, what if the first 6 tasks take 5 min. more to complete, you're 1/2 off (after 3 hours of work).
I would suggest creating a work breakdown structure (WBS) to determine effort and then group the tasks into no less then day groupings and no more then week groupings (depending on the overall duration of the project - you never want to have an increment representing more then 2-3% of overall work effort). This will allow programs to switch between tasks (normal working conditions) without the pressure of having to meet a specific 1/2 hour delivery.