funny how your girlfriend stimulates an idea isn't it.
So we've been househunting for sometime, and the main constraint is commute time, however hard i look though there appears to be no way to create a map that shows estimated commute times from a set start point.
This seems odd to me as surely a tool that allowed this sort of data to be plotted would be of benefit to a number of users, supermarkets could show which was your nearest supermarket by driving distance rather than as the crow flies (something that has frustrated me previously)
So - where would i even start on a task like this? Google Maps seems like a good place to start, but apparently needs an A & B and won't function from an A & a distance.
Somebody has suggested openmaps, but i'm not sure if the traffic is overlaid on there, which would definitely need to be a factor for my specific use case when we're talking about commutes.
I'm interested to hear different peoples takes on this, or even if a solution already exists out there (probably as a bespoke piece of software)
Thanks
Neil
My problem is that i keep getting small incremental withdraws on my creditcard, which is fine - but since i run a company i need to book all those micropayments. Which ends up to be hours of work (finding, printing, put in my cover etc) each month.
I'd rather just add $100 or so to the balance and deal with just the one charge.
This seems like a "must have"-feature, especially since the terminology "balance" is used on the "Billing history"-page. But i cannot seem to find where to add money.
Is it possible?
recently i've been given an assignment to work on a new project in c++...and i've been doing some thinking for some days and nights on how to approach it....unfortunately the thinking hasn't worked out and currently struggling on the designing phase. Basically the premise is:
"The management of Ruddles, a well known local department store has decided to implement certain changes to the customer tills throughout the store. Because of problems with staff in providing customers with correct change for their purchases, in future the change will be calculated automatically from the price of the goods and the amount tendered by the customer. The coins will be dispensed automatically by the tills, which are about to be replaced with machines capable of mechanical dispensing."
this is just some information about the business itself. the following is the requirement specification given to me:
"As at present, the member of staff (the cashier) will enter the purchases, and the system will calculate the total cost. This part of the system currently operates satisfactorily, and no changes (!) are envisaged. The total cost will be passed to the new machine, and the amount tendered by the customer will also be entered.
The system will then calculate the amount of change due, and will provide the hardware interface with a list of coin denominations and the number of each to be dispensed.
This constitutes the first part of the exercise. However, management has just realised that the coin dispensing machines will need to be replenished with coins from time to time, and would like the system to be able to keep track of the numbers of coins of different denominations, and issue warnings when the number of coins of any given denomination falls below a certain value. You should therefore include facilities to provide such provision in your solution.
At the present time, the hardware is unable to dispense notes, but future developments may make it possible, and your solution should be such as to cope with this should theses improvements occur. You should therefore indicate what changes would be necessary to the software in the event that such hardware upgrading takes place."
At the moment im really unsure on how to approach the following requirements for the project so im just wondering if any of you who are far more knowledgeable and experienced than me can lend some advice or suggestions, this will be much appreciated for your time and attention:-)
Im aware that there may be multiple ways this can be approached but so far i understand that arrays need to be used and a persistence structure as well although im not entirely sure..
fortunately it doesn't have to be overly completed so long as it does the job. again i appreciate any advice or tips you can give me. thank you.
The described "software" has inputs: the total purchase, and the total tendered by the customer, and outputs: a list of coin denominations and the number of each coin. Sounds like the definition of a function to me. Figure out a good data type for each parameter, and write out the signature of your function.
If I were you, start simple. Pretend you've only got one coin type, and come up with something that will work for that. Then, extend the design to two coins of different values. After that you'll be getting a far better feel for what is needed, and you should be able to see how to extend your solution to cope with coins that have a number of different denominations.
And also forget about the persistence bit until you've got some of the other basics working.
If you try and design the whole thing in your head without actually implementing any code, your brain might explode. So, break the problem down into chunks you can manage.
It sounds like a fun problem, good luck!
What are the advantages and disadvantages?
That depends on what your site is, and how you use that information. On StackOverflow, you are awarded a "yearling" badge once a full year elapses from the time you registered. Clearly here that information is necessary.
If I were you, I'd save it. It's a small piece of information that may become useful eventually. It's better to have it and not need it than to need it and not have it. It would be rather difficult to extrapolate an accurate registration date retrospectively if you don't store it to begin with.
Advantage:
You don't get in a migration horror when needing it at some point. For a lot of data you cannot find out this data afterwards. You could fake around with MODIFICATION_DATE but often this is not accurate and sits in the future (e.g. when profile can be edited by user).
Disadvantage:
In case you never need this information, you wasted space (though another small data payload column shouldn't make a problem). Further more you have an 'all-time' deprecated field, which can be confusing to new developers ("what is this column for, cannot see where it is used...?")
As mentioned the registration-date is most likely a valuable information I would add it from start on. When thinking of persistent data and its model you sometimes have to think "more" for the future.
With things like SO, Digg, Reddit, etc...
Should one keep track of downvotes in the database independent of upvotes? Or should they simply have a "votes" field that is decremented/incremented based off what the user does with no persisting of that?
How should votes be handled?
On SO, up votes earn +10, down votes -2. For this to work they need to be tracked separately. It's quite possible for a controversial answer to generate a few of each, and just showing an aggregate number won't mean much. So I'd say keep them separate.
I would keep them separate. Some questions have a lot of activity (up and down) and you really like to identify those.
Even if you are not interested in the difference right now, an extra field in the table is not that expensive, so it does not hurt to separate it. Because if you want to add it later, there is no way you can retrieve the data if it is not stored separately.
I also assume SO keeps separate votes for CW and non CW entries. Because if the question changes to CW later on, even with a recalc, the original gained/lost rep is kept.
Depends what you wish to do with your data.
If you only want to display votes than I say you only use one field. It's like number of views of a thread on forum. You want to see what gets most clicks, but not how many times someone viewed it.
Voting system on SO is a bit more complex. Since they can cancel all votes from particular user they have to keep track of who voted for/against what. This, I think, is written in another table, but because it is expensive to recalculate all votes every time someone views a question, they keep calculated value in a field, changing it whenever someone votes.
I can advise you to store them separately maybe even with extra data who authored a particular up or downvote. Who knows, you may come up with a nice idea tomorrow and you will need this additional data to implement it.
But it would also be good to have a sort of pre-calculated field (let's call it cache) which is updated whenever an up- or a downvote is submitted. The pages will then be rendered with this precalculated field. This will increase the response time and lessen load on DB.
If it is too costy to recalculate values immediately you may consider runnning some scheduler tasks (once per hour?) which will process up-to-date votes and recalculate the cached values.
Considering the amount of data you'll have in the database for social voting website the additional space for an extra int column to store down-votes is going to negligible so you'd be crazy not to.
Well, given that SO has +10 for an upvote and -2 for a downvote, and there's recalculation occasionally going on, it would need to store them independently.
Otherwise an answer with 10 upvotes and 5 downvotes which originally gave you 90 points, this would recalc to 50 if they weren't stored separately.
I'd keep them separate so that I could review them separately. Socially, upvoting is very different to downvoting, and I'd want to be able to look at them independently if it were me.
Definitely separately for one very simple reason. Tomorrow you'll want to do something extra that needs that information (some sort of report or graph for example). Besides keeping them separately costs you nothing.
since people can usually vote once, and (in SO for example) can cancel their votes, you need to know who voted, at what time, what vote, and on which item.
I am certain that the downvotes and upvotes are kept separately, though there could be an aggregate field that keeps the count. SO lets you change a vote later (make the downvote an upvote), and that's why I believe the votes are logged for each user too.