|
the problem i've faced with modeling databases with an ERD occurs after the model is implemented in to a schema. at that point you have two documents that need to be kept in sync, the ERD eventually becomes stale. mysql workbench automates this process pretty well. it lets you push the ERD to schema, and back annotate the schema to the ERD. but ofc there isn't a mac version, and its mysql specific.
|
# ? Apr 27, 2015 15:36 |
|
|
# ? May 13, 2024 19:12 |
|
MALE SHOEGAZE posted:wrongo db lmao
|
# ? Apr 27, 2015 15:36 |
|
Barnyard Protein posted:the problem i've faced with modeling databases with an ERD occurs after the model is implemented in to a schema. at that point you have two documents that need to be kept in sync, the ERD eventually becomes stale. mysql workbench automates this process pretty well. it lets you push the ERD to schema, and back annotate the schema to the ERD. but ofc there isn't a mac version, and its mysql specific. there is a mac version
|
# ? Apr 27, 2015 15:38 |
|
MALE SHOEGAZE posted:wrongo db
|
# ? Apr 27, 2015 15:40 |
|
MALE SHOEGAZE posted:wrongo db
|
# ? Apr 27, 2015 16:22 |
|
i guess the mongodb people were thinking of the word "humongous" when they made the name but somehow didn't realize that the rest of the world would think "mongoloid...wait wtf?" its like if they called it niggerdb and said "but we were thinking of the word niggardly, like our database is so niggardly with your resources!"
|
# ? Apr 27, 2015 16:33 |
|
fleshweasel posted:i guess the mongodb people were thinking of the word "humongous" when they made the name but somehow didn't realize that the rest of the world would think "mongoloid...wait wtf?" everyone i know calls it mongDB
|
# ? Apr 27, 2015 16:35 |
|
fleshweasel posted:niggerdb I'll initiate the repo
|
# ? Apr 27, 2015 16:38 |
|
hmongDB for you asians out there
|
# ? Apr 27, 2015 16:42 |
|
so i did really well on my phone interview with Redhat and have an on site scheduled this week. I started the interview process thinking it would just be a good experience, but now it's seeming like something I might actually be able to make happen. I'll be super torn if I get it. 1) It's contract. In talking to everyone at RH, it sounds like, for the most part, they only hire contract and then hire full time out of their contract pool. No idea whether or not that is bullshit. 2) I have a feeling they will pay me enough to make the lack of benefits a wash over my current position. I'd go to redhat even if I was making less money because: 3) It's Redhat. Even if they dont pick me up again after the contract expires, I feel like I'll be opening up a lot of doors. Except: 4) I really like my current company. They're good people and I like my co-workers. But our codebase is awful and I feel like I'm already kinda stagnating.
|
# ? Apr 27, 2015 23:09 |
|
MALE SHOEGAZE posted:so i did really well on my phone interview with Redhat and have an on site scheduled this week. I started the interview process thinking it would just be a good experience, but now it's seeming like something I might actually be able to make happen. you don't owe your current company anything. do what works for you man
|
# ? Apr 27, 2015 23:13 |
|
leaving a nice collection of coworkers behind is the thing I find hardest
|
# ? Apr 28, 2015 00:33 |
|
yeah the problem isn't the company, it's that i like my coworkers and if i leave they're gonna be hosed because i have a ton of product knowledge and there is no one who can replace me. like i know if i have an offer from RH my company is gonna offer me a big raise to compete, because the software I maintain makes way more in a month than I make in a year, and i'm the only one who can keep it running currently. but that might not be enough to keep me on because RH.
|
# ? Apr 28, 2015 00:35 |
|
MALE SHOEGAZE posted:yeah the problem isn't the company, it's that i like my coworkers and if i leave they're gonna be hosed because i have a ton of product knowledge and there is no one who can replace me. these are not necessarily your fault, and your coworkers probably wont be anymore hosed than they already are
|
# ? Apr 28, 2015 00:39 |
|
MALE SHOEGAZE posted:yeah the problem isn't the company, it's that i like my coworkers and if i leave they're gonna be hosed because i have a ton of product knowledge and there is no one who can replace me. they'll figure something out
|
# ? Apr 28, 2015 00:43 |
|
tbh the cowowker thing is not that important. two out of four already know because i told them. just a deead fly in the complex web that is my decision making process
|
# ? Apr 28, 2015 00:44 |
|
I just had to do kind of the same thing, leave a company I liked for a better career and it's rough but it's better in the long view.
|
# ? Apr 28, 2015 01:20 |
|
i have a site on squarespace right now that is basically an infrequently updated blog. they are charging me a somewhat reasonable rate to host it and run their software. which is neat but i remember someone mentioning just using wordpress and rendering it to static pages (because lol @ wordpress' security track record) a bit of searching leads me to some really crappy looking plugins and a bunch of people snorting about "lol why would you ever want to do that, nothing on the web is static except aol home pages" is there something i'm missing?
|
# ? Apr 28, 2015 03:37 |
|
I updated our coding standards document to say that, if you have a value that's used only once and the name of the constant you would make out of it doesn't impart any new meaning to the value, it's fine to leave it as a "magic number." It blew people's minds.
|
# ? Apr 28, 2015 05:14 |
|
MALE SHOEGAZE posted:yeah the problem isn't the company, it's that i like my coworkers and if i leave they're gonna be hosed because i have a ton of product knowledge and there is no one who can replace me. if you're contracted rather than employed by Red Hat you could still do work for your old company. come up with a consulting rate for times they need your help or something, and let them know you'll be available up to 5 or 10 hours/week or something along those lines, and could use that time to train others on the system not just fix bugs. make that rate comparable to the raise they'd offer, plus a bunch because they won't have to withhold taxes or pay benefits (and you will). and if the work for RedHat is true contract work, they can have no say in whether you do this. they might even appreciate it, because it makes you less likely to wind up reclassified as an employee for whom they should've been withholding and paying taxes and the like. (just don't do any work for your old employer at RH or using their stuff, or vice versa.)
|
# ? Apr 28, 2015 07:37 |
|
p sure he's gonna be working 60+ hours if rh contracts him. who says linux is exempt from tech industry average workweek
|
# ? Apr 28, 2015 09:13 |
|
MALE SHOEGAZE posted:yeah the problem isn't the company, it's that i like my coworkers and if i leave they're gonna be hosed because i have a ton of product knowledge and there is no one who can replace me. Congrats, it sounds like you are likely gonna take the job if they offer it. Either way it's nice
|
# ? Apr 28, 2015 12:12 |
|
so in haskell I am used to the standard map definition being something likecode:
code:
in line 3, is it saying that lst_ is the output? im obviously missing some key funamental because I am not understanding how this works, line 7 looks like its telling it just to output an empty list constantly
|
# ? Apr 28, 2015 16:07 |
|
Valeyard posted:so in haskell I am used to the standard map definition being something like In line 3 what you see is the definition of the 'internal' maph function which expects 3 arguments: a function, a list of elements, and an accumulator (lst_) that it passes to itself all the time. The accumulator is initialized as [] on line 7. What you see is a map that uses an accumulator as a third argument, so that the implementation is tail-recursive/iterative rather than just body recursive (the append operation happens before recursing, whereas in the traditional map, the recursion happens before the cons'ing with ':'). I know of sometimes decent reasons to do it in a strict language, but I'm not sure of whether these hold correctly in a lazy language like Haskell, so I'll refrain from speculating on that. E: re lst_ being a terrible name, I'm more surprised it isn't called lst' or just acc or something. MononcQc fucked around with this message at 16:26 on Apr 28, 2015 |
# ? Apr 28, 2015 16:23 |
|
lst_ is a variable, ++ takes two lists and concatenates them together.
|
# ? Apr 28, 2015 16:26 |
|
Valeyard posted:
it's basically doing map as reduce, passing an empty list into the accumulator. Zaxxon fucked around with this message at 16:31 on Apr 28, 2015 |
# ? Apr 28, 2015 16:29 |
|
Valeyard posted:
the others have explained this just fine, MononcQc is quite right in that the accumulator, lst_, is usually called "acc" or something. What's also worth noting is that this definition is written in a pretty horrible way. I was going to pick out exactly the problems with it, but is it a coursework or something, that you have to improve this form of it? Without changing the structure I mean, but this function can be optimised a LOT.
|
# ? Apr 28, 2015 16:39 |
|
MononcQc posted:I know of sometimes decent reasons to do it in a strict language, but I'm not sure of whether these hold correctly in a lazy language like Haskell, so I'll refrain from speculating on that. tail recursion is pretty important in functional languages (at least, those with TCO) because it lets the function be compiled internally as a loop so you don't get the costs of a function call each iteration that recursion normally gives you. Valeyard, see if you can define 'reverse' in a form that uses tail call recursion too i.e. like: code:
gonadic io fucked around with this message at 17:02 on Apr 28, 2015 |
# ? Apr 28, 2015 16:51 |
|
MononcQc posted:a ++ b means the two lists a and b are appended together. FamDav posted:lst_ is a variable, ++ takes two lists and concatenates them together. see that is fine, but ls_++[f x] with no spaces is really weird, so this is just the same as ls_ ++ [f x] with spaces, right? MononcQc posted:In line 3 what you see is the definition of the 'internal' maph function which expects 3 arguments: a function, a list of elements, and an accumulator (lst_) that it passes to itself all the time. The accumulator is initialized as [] on line 7. gonadic io posted:the others have explained this just fine, MononcQc is quite right in that the accumulator, lst_, is usually called "acc" or something. ok the fact that that is just an accumlator does clear up a lot, and I can see what is going on now. its doing a check to see if the length of the tail is 0, if so then just add the function-applied-to-the-head into the accumlator, otherwise call the internal function on the tail and still add the function-applied-to-the-head into the accumlator, gonadic io posted:What's also worth noting is that this definition is written in a pretty horrible way. I was going to pick out exactly the problems with it, but is it a coursework or something, that you have to improve this form of it? Without changing the structure I mean, but this function can be optimised a LOT. no coursework, it's just revision for the exam. I dont think you were around before when i mentioned the exam (80% of the course) is a multiple choice test. This question presented 4 definitions roughly similar to the horrible one I posted and asked which was the right one thank you to all
|
# ? Apr 28, 2015 17:00 |
|
Valeyard posted:see that is fine, but ls_++[f x] with no spaces is really weird, so this is just the same as ls_ ++ [f x] with spaces, right? Valeyard posted:no coursework, it's just revision for the exam. I dont think you were around before when i mentioned the exam (80% of the course) is a multiple choice test. This question presented 4 definitions roughly similar to the horrible one I posted and asked which was the right one
|
# ? Apr 28, 2015 17:03 |
|
gonadic io posted:tail recursion is pretty important in functional languages (at least, those with TCO) because it lets the function be compiled internally as a loop so you don't get the costs of a function call each iteration that recursion normally gives you. everyone knows reverse = foldl (flip (:)) []
|
# ? Apr 28, 2015 17:11 |
|
gonadic io posted:yes yeah think thats bad, heres Q1 I already know the answers to these, Q1 was a total guess between C and D since I couldnt actually tell what it was trying to parse, but the answer is C Q2 I said the answer is A because since the patterns its matching against arent similar so the lack of a try isnt going to cause any issues with consumed input, the real answer is in fact A
|
# ? Apr 28, 2015 17:14 |
|
It looks like there's some text missing in the definition of showParser, as there an infix operator (<|>) without anything to the right of it. Apart from that, I actually like that question though since it isn't stupidly obfuscated (lack of linebreaks not withstanding), asks you about sensible code and makes sure that you know how to use parsec. Which year undergrads is it for? The reason that that's the answer to q1 is because It's trying to parse a haskell type which starts with an uppercase letter then can have and number of upper or lower case letters as in the example given in the question. It's not D because if it were, that would allow lists and tuples in the middle of a name
|
# ? Apr 28, 2015 18:07 |
|
gonadic io posted:tail recursion is pretty important in functional languages (at least, those with TCO) because it lets the function be compiled internally as a loop so you don't get the costs of a function call each iteration that recursion normally gives you. Right, I'm familiar with that. But to give a precise example, for the map function in a strict language (here Erlang because I'm familiar) defined in a body-recursive manner, I have: code:
cons(F(1), cons(F(2), cons(F(3), cons(F(4), [])))). If I go for the tail recursive version: code:
In any case, rather than having a stack frame that is mostly N references to the same function and pending cons operations, the first tail-recursive version instead maintains: the original list in memory (cannot be GC'd yet), the accumulator (which is N conses), and a single reference to a function F. Then a third list has to be generated when the accumulator is reversed. So whereas the standard case is to go for tail-recursive because you don't want a large set of stack frames to be maintained, the tail-recursive map function's reduced frame stack is mostly going to be taken back up by the accumulator you needed to build up in memory and then discard; the body recursive function might be more efficient, especially since you reduce the risk of needing to force a GC right away (or to ask the OS for more memory), and skip an entire traversal (for reversal). This yields a case where body recursion can often micro-benchmark faster than tail recursion for functions such as map. The question I have is whether that cost is similar in the case of a lazy language, where the cost of the '++' append operation might be amortized and done at once. In this case, you wouldn't need the cons+reverse approach, and therefore you wouldn't see a practical advantage to body recursion over tail recursion given just using 'append' could do it. This is where a lack of experience with Haskell makes it hard for me to pronounce myself on the value (or lack thereof) of tail vs. body recursion in this case. MononcQc fucked around with this message at 18:28 on Apr 28, 2015 |
# ? Apr 28, 2015 18:26 |
|
Valeyard posted:yeah think thats bad, heres Q1 wow is he completely loving the indentation on the code in order to up the challenge or something
|
# ? Apr 28, 2015 18:31 |
|
MononcQc posted:Right, I'm familiar with that. But to give a precise example, for the map function in a strict language (here Erlang because I'm familiar) defined in a body-recursive manner, I have: (++) is perhaps the best example for lazy evaluation making it hard to reason about code. it's O(n) in its first argument and O(1) (amortised) in its second. so if you have (xs ++ ys) ++ zs that's a fair bit slower than xs ++ (ys ++ zs) because in the former case xs will get traversed twice - once when evaluating ++ys and once when evaluating ++zs (assuming that the expresion as a whole gets evaluated). this is basically the difference between left folds and right folds. foldl is tail recursive whereas foldr is body recursive. hence reverse gets defined using foldl and map using foldr. in fact in e: i exaggerated a bit but the details are largely correct: https://github.com/nominolo/HTTP/commit/b9bd0a08fa09c6403f91422e3b23f08d339612eb it's a reverse defined in terms of foldr (++), then it got changed to using the built-in foldl one. gonadic io fucked around with this message at 20:02 on Apr 28, 2015 |
# ? Apr 28, 2015 18:58 |
gonadic io posted:(++) is perhaps the best example for lazy evaluation making it hard to reason about code. This is pretty interesting. Thanks for the writeup! Also, I think your foldr link is broken--there was nothing there when I tried going to it.
|
|
# ? Apr 28, 2015 19:28 |
|
Valeyard posted:so in haskell I am used to the standard map definition being something like i dont mean to be rude but are you sure you took a haskell class at the literal haskell place?
|
# ? Apr 28, 2015 19:44 |
|
VikingofRock posted:This is pretty interesting. Thanks for the writeup! Also, I think your foldr link is broken--there was nothing there when I tried going to it. I fixed it, it works for foldr.com but not for https://www.foldr.com also my mistake, the bug was in cabal-install rather than ghc itself
|
# ? Apr 28, 2015 19:45 |
|
|
# ? May 13, 2024 19:12 |
|
gonadic io posted:(++) is perhaps the best example for lazy evaluation making it hard to reason about code. This seems absolutely awful and makes me like Haskell less
|
# ? Apr 28, 2015 19:48 |