|
Plorkyeran posted:Well yes, we can have a discussion about when using global variables is and isn't worth it if you're done trying to claim that you aren't using global variables at all.
|
# ? Apr 1, 2014 16:58 |
|
|
# ? Jun 6, 2024 05:58 |
|
Plorkyeran posted:For example, in Python I'm moderately a fan of the following general pattern for mocking out deps for tests: You started two paragraphs with the word "It". What was "it" in those paragraphs?
|
# ? Apr 1, 2014 16:59 |
|
Dren posted:You started two paragraphs with the word "It". What was "it" in those paragraphs? The pattern I gave a brief example of at the top of the post.
|
# ? Apr 1, 2014 17:06 |
|
Why, yes, this is a screenshot of two SQL query results (the latter being rowcount.) And yes, it's a table full of every possible date from January 1st, 2000 for 50 years. And yes, there are DateTime columns elsewhere in the database.
|
# ? Apr 1, 2014 19:18 |
|
JawnV6 posted:I want to check that my code can handle the DateTime cases around leap years and instead of moving some blocks around behind the scenes and leaving production code untouched you're still advocating mucking up the function parameters to pass that information in as if it's tenable for all cases. Sagacity fucked around with this message at 19:24 on Apr 1, 2014 |
# ? Apr 1, 2014 19:19 |
|
Sagacity posted:If you would just read what I'm writing without getting so worked up. Where you are saying I am mucking up function arguments, in my view you are mucking up constructor arguments. Sagacity posted:Is the "Fine whatEVS!" approach how you handle every discussion? Sagacity posted:In your implementation you need to pass in a DateTimeProvider, which then has to become part of the state of your class. I think that obscures what your code is doing, because it is unclear where (and when) you are using this DateTimeProvider.
|
# ? Apr 1, 2014 19:36 |
|
Oh I'm sorry, I thought you were part of this conversation as well. My mistake. Let's continue with the thread!
|
# ? Apr 1, 2014 19:44 |
|
JawnV6 posted:Engagement with that poster will likely be more productive.
|
# ? Apr 1, 2014 19:49 |
|
So, is DI / IOC a horror or not?
|
# ? Apr 1, 2014 19:50 |
|
Sagacity posted:Oh I'm sorry, I thought you were part of this conversation as well. My mistake. Dirty Frank posted:Holy poo poo this is honest, could you just start with this before posting at all in the future?
|
# ? Apr 1, 2014 19:53 |
|
Ithaqua posted:So, is DI / IOC a horror or not? Not sure yet, but could we please decide soon? I need to know whether to regard everyone who does or doesn't use it with extreme derision.
|
# ? Apr 1, 2014 19:55 |
|
Tha Chodesweller posted:
This is not a horror at all and is in fact common practice in BI applications. That would be a date dimension table and more enhanced versions of it will have things like what quarter it is and even potentially things like what fiscal year/quarter it would be.
|
# ? Apr 1, 2014 19:58 |
|
No Safe Word posted:This is not a horror at all and is in fact common practice in BI applications. That would be a date dimension table and more enhanced versions of it will have things like what quarter it is and even potentially things like what fiscal year/quarter it would be. not sure if troll
|
# ? Apr 1, 2014 20:00 |
|
Plorkyeran posted:not sure if troll It's not a troll, I guess you have never done anything with a data warehouse? Just google "date dimension table" and you'll see this all over the place. e: the only thing that's kind of weird is that Id column, everything I've seen/used had a "datekey" field that was just YYYYMMDD instead No Safe Word fucked around with this message at 20:09 on Apr 1, 2014 |
# ? Apr 1, 2014 20:06 |
|
No Safe Word posted:It's not a troll, I guess you have never done anything with a data warehouse? This doesn't convince me that it isn't a horror. Lots of horrors are widespread. What is the reason for such a table?
|
# ? Apr 1, 2014 20:27 |
|
I'm sorry if you thought I was impugning you, rather than your argument. Code with a lot of non-caller-controlled dependencies is IME (very large systems, but in a bunch of domains) fragile and hiding it doesn't help things. PFA can be ugly, though mostly in OO situations you isolate that to initialization. DI systems are, I find, much harder to reason about than ones built around fully-parametrized components that you can test piecewise and incrementally, and I'm surprised that in an embedded context the time and space overhead isn't problematic for you! I've worked in DI environments (the apps I most recently managed at work are built around it, and they do OK), I just find it to be like the general OO action-at-a-distance ick. "Oh, you called this method and it didn't work? Did you call this other invisibly-related one first? Does it have leftover state from a previous thing?" But you can also adopt PFA incrementally too; the dichotomy is false. The report generator might well DI to DateTime and pass the value down, and a test driver for its components would pass a different value down. This lets you incrementally move to a system in which the API describes all the things on which the behavior of the function depends. (BTW, if you're mocking DateTime via DI, make sure it actually advances in time or your timing thing won't work.)
|
# ? Apr 1, 2014 20:27 |
|
Thermopyle posted:What is the reason for such a table?
|
# ? Apr 1, 2014 20:35 |
|
Sagacity posted:It allows a data warehouse to treat date/times like any other type of data. In a regular SQL database this distinction is moot, but these data warehouses also do lots of precalculation in order to respond very quickly to all sorts of queries. In this case it can create a hiearchy of the date/times quite trivially. For instance, if you want your rows grouped by month, it knows that February 2007 lies between id's 150000 and 170000 in your date table, etc. Interesting. You have convinced me that it probably isn't a horror.
|
# ? Apr 1, 2014 20:39 |
|
Sagacity posted:It allows a data warehouse to treat date/times like any other type of data. In a regular SQL database this distinction is moot, but these data warehouses also do lots of precalculation in order to respond very quickly to all sorts of queries. In this case it can create a hiearchy of the date/times quite trivially. For instance, if you want your rows grouped by month, it knows that February 2007 lies between id's 150000 and 170000 in your date table, etc. I've always thought that was a weird reason. Times are already represented by an integer, so why not just use epoch-seconds? You get the same range-compare and representation as int, without needing a dimension table. Edit: maybe because it lets the query system assume that all parameters are references to a dimension table?
|
# ? Apr 1, 2014 20:41 |
|
Yes, it's probably something like that. The tooling usually allows you to autogenerate those tables, so I'm not sure why they didn't abstract it away entirely.
|
# ? Apr 1, 2014 21:05 |
|
Subjunctive posted:I've always thought that was a weird reason. Times are already represented by an integer, so why not just use epoch-seconds? You get the same range-compare and representation as int, without needing a dimension table. This will blow up in your face if you have anything in your warehouse with a date before the unix epoch.
|
# ? Apr 1, 2014 21:55 |
|
necrotic posted:This will blow up in your face if you have anything in your warehouse with a date before the unix epoch. Wouldn't you just store the appropriate negative value?
|
# ? Apr 1, 2014 22:01 |
|
necrotic posted:This will blow up in your face if you have anything in your warehouse with a date before the unix epoch. Probably not, given that signed integers exist. Unix uses one called time_t to represent date-times.
|
# ? Apr 1, 2014 22:04 |
|
necrotic posted:This will blow up in your face if you have anything in your warehouse with a date before the unix epoch. Good job that most people don't log transactions in the past then really.
|
# ? Apr 1, 2014 22:08 |
|
time_t still runs out in 1902 (and 2038).
|
# ? Apr 1, 2014 22:15 |
|
evensevenone posted:time_t still runs out in 1902 (and 2038). Not on anything modern, where it's been 64-bit on 64-bit OSes (and some 32-bit ones as well) for years. If your database can't work with 64-bit ints, I feel bad for you and your data shoebox.
|
# ? Apr 1, 2014 22:24 |
|
Since this is SQL Server if you put a function in a WHERE clause (WHERE YEAR(Date) = 2007) it will cause an index scan which is really slow. Since the data is already computed in the table you can do an index seek because there is no SQL Server function in the WHERE clause (WHERE Year = 2007).
|
# ? Apr 1, 2014 22:41 |
|
If you've seen a fully fleshed out DimDate table (the one above is very narrow) it's a little more clear why you'd use this for reporting out of a Data Warehouse, just a random quick googling for a sample creation script gave me one with the following columns:code:
I've seen even wider date dimension tables than that, some had holidays in them, some had DST stuff in it (which is obviously irrelevant if you have data that transcends boundaries where DST isn't identical in all of them).
|
# ? Apr 1, 2014 22:50 |
|
No Safe Word posted:So when you are doing analysis, you can slice on any of these portions of the date dimension quite fast because of all the precomputation that goes on when you build out all your BI bits. The one above doesn't get you a lot, so if anything the horror is how little is in that table I'm not sure I'm following. You join against the table with WHERE DateDimension.DayOfWeek = "Friday"? If it's about providing int-range behaviour, I don't see how the date dimension table you've described does that.
|
# ? Apr 1, 2014 22:58 |
|
Subjunctive posted:I'm not sure I'm following. You join against the table with WHERE DateDimension.DayOfWeek = "Friday"? If it's about providing int-range behaviour, I don't see how the date dimension table you've described does that. We're getting a bit far on this derail but when you're doing multidimensional queries and whatnot, it's not actually SQL that you're using. I'm only really familiar with the MS SQL flavor of it, so their version of it would be MDX. The actual date dimension table is built into a BI cube that can be sliced on any number of dimensional axes simultaneously. And frankly, I didn't really ever hand-write any MDX code, we used tooling to do that sort of thing. The important thing to note is that you're not really doing traditional SQL joins on a table like that in a data warehouse scenario. If that sort of table is being used for SQL joins then it probably is a horror, but given the structure of it I would be surprised if it wasn't just a date dimension table to be used to build out a data warehouse that was then compiled into BI objects.
|
# ? Apr 2, 2014 00:14 |
|
Munkeymon posted:Link? The site is codewars.com, and god help you.
|
# ? Apr 2, 2014 01:04 |
|
So I've just recently found myself going "...that's it?" to a LONGstanding problem I've only now been allowed to look at. We've used bootstrap for our layout on our product for some time, though we've had some various sheds of the bike-sort pile up, such as a left hand nav we weren't expecting to have which shrank our actual content pane, among other things. Well, that and the fact that nobody really grokked bootstrap all this time. Or JS. Then again I can't blame anyone else for not wanting to deal with the front end poo poo since I hate it too! WELP since I'm still getting back in the thick of things after taking time off to take care of my mom and then grieve her passing, I'm on "CSS cleanup/make a standard for the website and beat up devs until they conform to it" duty. After cutting the size of our less file in half I take a look at getting bootstrap to actually work for varying resolutions, such as the minimum one for small, old monitors we're required to support, instead of having us just wing it with span9 as our max width and do cute poo poo like "Hey, go make invisi-divs that just have margins around them to make stuff space out properly ." All I had to do was read docs and stack overflow for like ten minutes, go to variables.less, change the column width variable to the right number of pixels, recompile the less to css, and then go to my team lead and go "Oh hey told you so like 6 months ago." The most senior dev there was telling me it would be ~black magic~ to actually change an intentionally easy to tweak variable all this time. What particularly kills me is that the size of our content pane just so happens to be almost the exact width as one of the presets for column width that's built into bootstrap itself, 760-ish! I'm still tripping over someone making a "mediumPlusInput" class (which is just a width property containing class) instead of "largeInput."
|
# ? Apr 2, 2014 01:13 |
|
Doc Hawkins posted:The site is codewars.com, and god help you. The real horror.
|
# ? Apr 2, 2014 01:15 |
|
from https://github.com/bitcoin/bips/blob/master/bip-0042.mediawikihttps://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki posted:As is well known, Satoshi was a master programmer whose knowledge of C++ was surpassed only by his knowledge of Japanese culture. The code below:
|
# ? Apr 2, 2014 02:33 |
|
No Safe Word posted:This is not a horror at all and is in fact common practice in BI applications. That would be a date dimension table and more enhanced versions of it will have things like what quarter it is and even potentially things like what fiscal year/quarter it would be. There are 7 tables in the database and 2 of those are for logs. Our actual business database has no concept of this table and the tables are only used to manually create a string from a DateTime in C#. I realize that's probably pertinent information. I will see if I can dig up the extension method tomorrow. Edit: also the guy who implemented this table is one of those guys who textbook copies solutions from Stack Overflow, so I realize now it's use in a data warehouse setup, but we aren't using it for anything close to that. Macichne Leainig fucked around with this message at 05:05 on Apr 2, 2014 |
# ? Apr 2, 2014 05:02 |
|
2banks1swap.avi posted:So I've just recently found myself going "...that's it?" to a LONGstanding problem I've only now been allowed to look at. Long division?! You'd need some kind of computer or something!
|
# ? Apr 2, 2014 05:46 |
|
LOOK I AM A TURTLE posted:And triple boobs lets me do the same thing when there are exactly three missing parameters? This particular idiom is not too bad, once you know it. You just count the boobs: '(.) . (.)' is composing a function that takes two arguments, '(.) . (.) . (.)' one that takes three, and so on. The biggest problem is that it is not infix. In Haskell, you can turn an ordinary function into an infix operator by surrounding it with backticks: code:
code:
code:
(Repeat the above for every type class you want tuples to implement.)
|
# ? Apr 2, 2014 07:11 |
|
gariig posted:Since this is SQL Server if you put a function in a WHERE clause (WHERE YEAR(Date) = 2007) it will cause an index scan which is really slow. Since the data is already computed in the table you can do an index seek because there is no SQL Server function in the WHERE clause (WHERE Year = 2007). Is Postgres the only SQL DB that can do indexes on expressions? I wasn't that surprised to see MySQL was lacking them, but SQL Server is supposed to be good
|
# ? Apr 2, 2014 07:47 |
|
Tha Chodesweller posted:There are 7 tables in the database and 2 of those are for logs. Our actual business database has no concept of this table and the tables are only used to manually create a string from a DateTime in C#. Ah nice, so then the real horror is finding a solution to an entirely different problem and saying "oh hey that's cool I'll use that".
|
# ? Apr 2, 2014 08:01 |
|
|
# ? Jun 6, 2024 05:58 |
|
more like dICK posted:
Tried using this, couldn't get any tests to work.
|
# ? Apr 2, 2014 08:54 |