I need your good ideas. I am considering to create a big dataset for historical calendar in RDF. For example, one day of 1860 in RDF/XML would simply look like (just an ISO date with the day of a week):
<abc:date rdf:about="https://example.com/date/1860-05-08">
<abc:dayOfWeek>Tuesday</abc:dayOfWeek>
</abc:date>
Apparently, I need to calculate the day of the week, out of YYYY-MM-DD. In this way, I would like to generate this data for c365 days for each year. The overall scope would be around 4000 years (2000 BC - Present), thus including pre- Gregorian calendar. If that's a bit too ambitious, for now, 1800 onward is enough.
What would be a good way to achieve this? Is there a freely available database (CSV etc) out of which I could generate this kind of data automatically?
(Potentially, it would be excellent, if additional information can be added:
<abc:date rdf:about="https://example.com/date/1860-05-08">
<abc:dayOfWeek>Tuesday</abc:dayOfWeek>
<abc:location rdf:about="https://www.wikidata.org/entity/Q1741">
<abc:sunRise>4:29AM</abc:sunRise>
<abc:sunSet>7:23PM</abc:sunSet>
</abc:location>
</abc:date>
See this example here: https://www.wolframalpha.com/input/?i=what+day+of+the+week+was+1860-05-08)
Thank you for your ideas in advance!
I have something like 20,000 data points in a database and I want to display it on the google annotated graph. I think around 2000 points would be a good number to actually use the graph for, so I want to use averages instead of the real amount of data points I have.
This data counts the frequency of something a certain time. it would be like Table(frequency, datetime)
So for the first week I will have datetime have an interval of every 10 minutes, and frequency will be an average of all the frequencies of that time interval (of 10 minutes). Similarly, for the month after that I will I have a datetime interval of an hour etc.
I think this is something you can see on google finance too, after some time the resolution of the datapoints decreases even when you zoom in.
So what would be a good design for this? Is there already a tool that exists to do something like this?
I already thought of (though it might not be good) a giant table of all 20,000 points and several smaller tables that represent each time interval (1 week, 1 month etc) that are built through queries to the larger table and constantly updated and trimmed with new averages.
Keep the raw data in the db in one table the. Have a second reprti g table which you use a script or query to populate from the raw table. The transformation that populates the reporting table can group and average the buckets however you want. The important thing Is to not transform your data on initial insert--keep all your raw data. That way you can always rollback or rebuild if you mess something up.
ETL. Learn it. Love it. Live it.
Does it make any sense to use bitfields to store and manage a schedule?
I'm working on a Ruby on Rails application to handle restaurant opening hours and reservations, and I'm having some difficulty modeling schedule.
Each restaurant will have opening hours (like Monday 9am-12pm and 2pm-5pm) each day, and each table in the restaurant will have a size (2, 4, 8-seat, etc.) and its own openings.
So far, I've been using two tables to keep track of things:
opening_hours
day_of_the_week (string)
starts_at (time)
ends_at (time)
bookings
table_id (int)
starts_at (datetime)
ends_at (datetime)
With those tables, I can make sure new bookings don't overlap other bookings for the same table and that the booking falls within an opening-hour range for that day of the week.
It's problematic to find the open slots in the schedule, though. That is, given a set of opening hours and existing bookings, where are the gaps that could accommodate new bookings?
While looking through StackOverflow for inspiration, I came across this comment about using bitfields for schedules, and it piqued my curiosity. I don't really know anything about bitwise logic, but I wonder if I could replace the above tables with something like:
opening_hours
day_of_the_week (string)
hours (96 bits, representing open/closed times for each quarter-hour of the day)
bookings
table_id (int)
date (date)
hours (96 bits, representing available/booked times for each quarter-hour of the day)
And then I could use bitwise logic (waves hands) and find the open, available times for a given day.
So my questions:
Would it make sense to do something like this?
Can anybody point me to a blog post or tutorial covering using bitfields for schedules?
What else should I look at to learn about bitfields & bitwise logic, specifically in the ruby/Rails realm?
thanks,
Jacob
This seems like a strange way to store what are dates.
Ask yourself what the behavior of the Restaurant or OpeningHours will be? I bet you'll find yourself converting back to real date objects to implement that behavior. So why use a weird encoding in the database (day of week and bit string)?
Additionally, do you ever intend to use SQL date operators to find what Restaurants or tables are open? That just got a whole lot trickier if it's possible at all with your encoding scheme.
I doubt you want to do this.
I'm looking for the best way to implement the following.
I have a MySQL query that analyses performance of a company, and outputs sales, revenue, costs and so on, and basically outputs a final Gross Profit and Net Profit figure. It's working well, and managers can select any date range to run it for, and it will output everything for that range - therefore they can in theory see how the company performed today, yesterday, this week, last month or on the 17th of three months ago... you get the point.
There comes a problem however when some of the figures to be used for the report are variable, and involve fluctuating external costs, such as overheads and so on. I allow users to specify these costs and overheads in a settings table, and the performance query uses these to calculate it's figures. But these variable figures represent now, so would bear no relevance if you wanted to look at the company performance from X months/years in the past, when the overheads for today are being offset against them, creating inaccuracy.
I thought of a couple of solutions.
I could allow the managers to set a date range to apply the overheads for. For example, for June 2011, the daily overhead was £2000, whereas in July 2011 the overhead is £2250.
Or I could save the performance report/query to another table, which would obviously have the variable figure locked in from the time it ran. This could even be automated with a crontab, and perhaps just ran every night.
Which way would you recommend?
If I were you I would go with the first option (1), and create a table to store the delayed overheads for a specific date. This would be much more flexible for you to run any kind of query at any point on time against the pure/"virgin" data you have on the table.
On the other hand the second option doesn't seem that feasible to me, because you can't possibly calculate all the complexity of the queries and reports needed, in different date ranges.
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 9 years ago.
Improve this question
Here is my situation with rough numbers. I had like to know if my thinking (at the bottom) seems sound to you guys. (Side note: I've read many of the related questions on here, and helpful as they were, none seemed to touch on this specific issue.)
For 2 years I was a senior developer at Company X. I was full-time, W-2, and making $100k/yr with benefits. (Roughly $50/hr).
[Then I got laid off, but that's not the point. I am in a large city and can find work easily. I am very happy to work from home rather than in an office.]
For 2 months I've done a few freelance projects for Company Y, a web firm. This was 1099, and I am charging $80/hr. (I did 100 or so hours over 2 or so months and figured I'd need to get some other clients soon).
Company Y loves my work and has gained new jobs because of it. They want more of my time and have offered me a 6 month contract, paid a fixed monthly rate regardless of hours (they assume 40ish per week). I'd still be working remotely.
So...
My freelance rate is higher than my old W-2 full-time rate for obvious reasons. I also realize that since freelancing "full time" requires lots of administrivia and sales, I would never really be racking up 40 hrs/wk at my $80 rate. (I've been toying with the idea of charging any other clients more, like $100/hr.)
However, I realize that from Company Y's perspective, offering me the security of a 6 month retainer contract should drive my hourly rate down (bulk discount?) since I'd now have way more billable hours and less administrivia. This still has got to be a raise on my old W-2 job for it to be worth my while though, especially due to the lack of benefits and the more complex tax situation.
Now I wish I had originally charged Company Y $100/hr for the initial freelance projects so that I could give them a better deal and charge them $80/hr for this 6 month contract.
Sorry for being so long winded, but I hope you guys get my drift. Essentially, I should be giving them a lower hourly, but I really don't want to.
Is my assumption correct that as far as hourly rates go,
full-time-W-2 < long-term 1099 < short-term-project-based 1099 ?
If so, what might a good negotiation strategy be with Company Y to keep my hourly rate as is, and effectively nix their bulk discount? "You were getting a super low rate on those individual projects!"
Company Y loves my work and has gained new jobs because of it. They want more of my time and have offered me a 6 month contract, paid a fixed monthly rate regardless of hours (they assume 40ish per week). I'd still be working remotely.
Are you sure about this? Anytime I was asked to work "fixed monthly rate" it was a none-too-subtle way of trying to get a lot of "free" hours (effectively a massive rate cut).
I don't know any consulting project where you can just quit at 40 hrs, especially if the client gets a "push" where they need stuff sooner rather than later... the urgency is always theirs, and frequently manufactured rather than "real".
So, if they want you AND want a discount, give them maybe $70/hr for an HOURLY contract over the 6 months. That way they get a discount, and you get protection from overtime and any urgency that may arise.
Anything else and you WILL get hosed. Almost guaranteed.
I'm not from the US so the W-2 and 1099 part is beyond me but I'll address the rest as those issues are pretty universal.
Generally speaking, a rule of thumb is that if you earn $100k per year you should be charging $100/hour or pretty close to it. This is to cover some or all of:
No personal/sick leave;
No paid annual leave;
No bonuses;
No training;
Insurances (health, public liability, professional indemnity, etc);
If you are not contracted to a certain number of hours per week, there is variability in income;
The employer can get rid you much more easily than a full-time employee.
Now this is my experience in Australia and Europe where you actually have quite significant public health care. I might imagine that since you don't in the US, the health insurance costs might drive this even higher so perhaps you should be asking for $120+/hour.
Note: if you're not paying things like professional indemnity insurance or you don't have some sort of legal protection (like operating through a limited liability company) you are playing with fire and I strongly urge you to seek professional advice on setting up a structure and/or obtaining relevant insurances to adequately protect you, your assets and your family if you have one.
Of course you have to balance this all out against the current market conditions, which aren't all that great (but vary from locale to locale).
I like the hourly rate scenario because it's "fair". By that I mean if you work 80 hours one week to get something out then you get paid for it. You just get paid for what you do and that's it. It's simple.
Now employers often don't like it because they can't necessarily predict (and thus budget) the costs.
The next step is to get paid a daily rate. I typically try and resist this but I will go for it in certain situations. If so, you need to define exactly what a day is.
If you work at all do you get paid for a half day? A full day?
Do you need to work a certain number of hours to get paid for the day?
Do you only ever get paid for a full day no matter how many hours you work in that day?
Can you get paid for more than 5 days a week?
Generally for this sort of situation I'll mutliply my hourly rate by 9 basing it on an 8 hour day. You're taking on some of the risk so you need to get paid for that.
Beyond that you can go to weekly and then monthly. They too have the issue of having to define what constitutes a week or month. There are on average 20 or 21 working days a month so multiply your daily rate by 21-25 to get a monthly rate.
As for a negotiation strategy, pretty much use the points listed above. If $120/hour sounds like a lot (to them) point out all the costs involved, which are also costs they're saving. Use your proven track record to your advantage because I can guarantee you that there are few things more catastrophic to a company than incompetent software development.
You could just tell them that the contract is only for 40hrs/wk max, and if they need you to go over that then it will be at your new rate of $100/hr, which may not be a problem if you gave them a discount on the first 40hrs.
Then chalk this up as a lesson learned and for any new clients change your rate. :)
6 months, 40 hours per week = almost 1000 hours, therefore for every dollar you drop from your hourly rate, you'll be discounting them $1000, so a drop of $5-6/hr should be significant enough, IMO.
Have this "discount" got into discussion as of yet? If not, the simplest solution would be just going forward with the implicit assumption of no change in payments -remember, a "discount" is something of a generousity, and not a mandatory.
I'm no expert, but I would explain to Company Y that the original rate WAS the discount. If you can convince them that you were charging the bare minimum all along instead of trying to milk more money out of them, I think they would consider that a positive.
If you were completely cool with knocking a significant percentage off of your rate, I think in the back of their minds they would think you were gaming them in the beginning.
As an analogy, say you go to a car lot. The salesman initially quotes $30,000. You come back with $20,000. He accepts without hesitation. You may actually end up with a good deal, but the salesman comes off as being shady anyway.
They want more of my time and have offered me a 6 month contract, paid a fixed monthly rate regardless of hours (they assume 40ish per week). I'd still be working remotely.
My argument would be:
I'll probably end up working over 40 hours per week. If you'd prefer a 6 month guaranteed contract, paid hourly instead of at a flat rate, we can renegotiate that.
However, I also would say that a 6 month contract is not necessarily "long term" - more "mid term".
So 1: you don't want to lower your rates, 2: they want a fixed rate.
It is likely that the fixed part is more important than the lower part to them. So call them and first talk to them and find out if that is true. If it's about being fixed, or about being cheaper. Second, explain them that you can not lower your rate. Plenty of arguments for that. Good luck!