|
|
# ? Sep 4, 2014 12:51 |
|
|
# ? Jun 5, 2024 07:19 |
|
AlsoD posted:and the third is for people who are showing off it lets you do more clever and concise things
|
# ? Sep 4, 2014 13:41 |
|
im the monoid in the category of endofunctors
|
# ? Sep 4, 2014 14:24 |
|
Bloody posted:hey lets argue about tabs vs spaces its not even an argument, tabs are the only answer. but indenting is for readability, not control.
|
# ? Sep 4, 2014 14:34 |
|
Shaggar posted:its not even an argument, tabs are the only answer. but indenting is for readability, not control.
|
# ? Sep 4, 2014 15:00 |
|
monad always makes me think of mounds for some reason also shaggar was right
|
# ? Sep 4, 2014 17:18 |
|
same except gonads
|
# ? Sep 4, 2014 17:23 |
|
Progressive JPEG posted:same except gonads not another gonad tutorial!!!
|
# ? Sep 4, 2014 17:24 |
|
it takes a couple weeks to understand them, everyone has to put in the time
|
# ? Sep 4, 2014 17:25 |
|
the theory might look scary but just play around a bit to get a feel for them and you'll see it's really easy
|
# ? Sep 4, 2014 17:26 |
|
uncurable mlady posted:monad always makes me think of mounds for some reason i prefer almond joy
|
# ? Sep 4, 2014 17:26 |
|
Shaggar posted:its not even an argument, tabs are the only answer. but indenting is for readability, not control. tabs are for indentation, spaces are for alignment. but thats too complicated for most people so welp even if indentation is for readability your compiler/interpreter should tell you to gently caress off if your code isnt well-formatted, and every language should have a gofmt-type utility and require its use
|
# ? Sep 4, 2014 17:27 |
|
AlsoD posted:it's really easy
|
# ? Sep 4, 2014 17:44 |
|
how to learn a monad - don't look at wikipedia - don't look at do notation - don't look at any monad that isn't the maybe monad - do go write some error-handling code w the maybe monad - okay you're past the hump you can look after yourself now
|
# ? Sep 4, 2014 17:49 |
|
coffeetable posted:these are bad words don't use them c'mon, it was a joke about gonads
|
# ? Sep 4, 2014 17:49 |
|
AlsoD posted:c'mon, it was a joke about gonads
|
# ? Sep 4, 2014 17:50 |
|
coffeetable posted:oh wow yeah i totally missed that i do completely agree with your point though
|
# ? Sep 4, 2014 17:53 |
|
coffeetable posted:how to learn a monad but this isnt how i learned
|
# ? Sep 4, 2014 19:20 |
|
fart simpson posted:but this isnt how i learned then it's completely loving wrong and you need to write a blog post about how wrong it is asap!!!
|
# ? Sep 4, 2014 19:23 |
|
i'm pretty sure nobody would have trouble with monads if they had a friendlier name and they didn't know there was a connection to category theory
|
# ? Sep 4, 2014 19:26 |
|
that's the opening sentence of my upcoming blog post
|
# ? Sep 4, 2014 19:26 |
|
fart simpson posted:but this isnt how i learned
|
# ? Sep 4, 2014 19:32 |
|
fart simpson posted:i'm pretty sure nobody would have trouble with monads if they had a friendlier name and they didn't know there was a connection to category theory monads are really simple, but the problem is not just the category theory, the problem is haskell. because of laziness you are forced to use monads to sequence computations, and that's a pretty basic thing to do in any real program, so haskell users are forced to grapple with this concept very early on, probably before they understand its context in haskell
|
# ? Sep 4, 2014 19:39 |
|
coffeetable posted:howd you learn i read a bunch of monad tutorials which didn't really help and then i started actually writing haskell and kept getting type errors in the io monad and kept trying stuff to shut up the compiler and then one day it all suddenly made sense
|
# ? Sep 4, 2014 19:46 |
|
actually that was a lie. i learned what monoids and functors are, because those are both really simple. then i read that monads are just monoids in the category of endofunctors and it was obvious
|
# ? Sep 4, 2014 19:57 |
|
fart simpson posted:actually that was a lie. i learned what monoids and functors are, because those are both really simple. then i read that monads are just monoids in the category of endofunctors and it was obvious
|
# ? Sep 4, 2014 19:59 |
|
fart simpson posted:i'm pretty sure nobody would have trouble with monads if they had a friendlier name and they didn't know there was a connection to category theory
|
# ? Sep 4, 2014 20:23 |
|
see: C#'s Aggregate (fold), Select (map) and how there's a bunch of different functions that are essentially Bind but for Asyncs, Nullables, IEnumerables etc etc
|
# ? Sep 4, 2014 20:26 |
|
fart simpson posted:i'm pretty sure nobody would have trouble with monads if they had a friendlier name and they didn't know there was a connection to category theory this but regular expressions and finite state automata
|
# ? Sep 4, 2014 20:47 |
|
fart simpson posted:actually that was a lie. i learned what gonoids and fucktors are, because those are both really simple. then i read that gonads are just gonoids in the category of inthe endofucktors and it was obvious
|
# ? Sep 5, 2014 01:26 |
|
I have a phd in math and I've been doing it for money for a bunch of years now and whenever anybody starts talking about category theory and all that stuff I just tune them out for a while
|
# ? Sep 5, 2014 02:44 |
|
fritz posted:I have a phd in math and I've been doing it for money for a bunch of years now and whenever anybody starts talking about category theory and all that stuff I just tune them out for a while I wish more interviews would do this. Have the interviewers start talking out of their asses and if the candidate engages or appears to be listening show them the door.
|
# ? Sep 5, 2014 02:47 |
|
Stringent posted:I wish more interviews would do this. Have the interviewers start talking out of their asses and if the candidate engages or appears to be listening show them the door. you'd get a lot of false positives from people who've learned that disrespecting authority is a bad career move
|
# ? Sep 5, 2014 07:13 |
|
i had a friend in grad school who always talked in category theory language and i understood maybe 1/3 of what he said. he's now a professor at a top 10 department
|
# ? Sep 5, 2014 08:11 |
|
Forums Terrorist posted:you'd get a lot of false positives from people who've learned that disrespecting authority is a bad career move
|
# ? Sep 5, 2014 09:09 |
|
what does <filtering> even do in pom.xml?? I am reading http://maven.apache.org/pom.html and they write stuff like quote:filtering: is true or false, denoting if filtering is to be enabled for this resource. Note, that filter *.properties files do not have to be defined for filtering to occur - resources can also use properties that are by default defined in the POM (such as \${project.version}), passed into the command line using the “-D” flag (for example, “-Dname=value”) or are explicitly defined by the properties element. Filter files were covered above. alright! filtering decides if filtering is enabled!! what does filtering do?? i am probably dumb and missed a critical doc section, but the docs are not making me happy
|
# ? Sep 6, 2014 21:31 |
|
resource filtering causes maven to replace variables in the files its filtering with their value as specified in your pom. by default you filter the contents of /src/main/resources which is where configs go. so if you had mysettings.properties in /src/main/resources/ and it contained a.setting.the.program.uses=${blahblah.whatever} and then in your pom.xml you had a property named blahblah.whatever with a value of fartz then when maven builds your project it would replace the ${blahblah.whatever} with fartz resulting in a.setting.the.program.uses=fartz Its one way to store your configuration info in the build definition instead of storing it in your code/configs. You can also specify/override them at build time, essentially allowing you to provide all the config values at build time which is handy for automated deployment. Most of the time (really, all of it) your filtering will be done in your deployment packages and not in libraries. you can also add other folders to be filtered and restrict filtering by filename/type. so like if you wanted to filter your actual java code you could do that too.
|
# ? Sep 6, 2014 21:40 |
|
thanks shaggar let's see if i understand correctly: if i have XML code:
1) scan environments/${environment} for *.properties files 2) get the key value pairs from the *.properties files 3) copy the content of environments/${environment} as resources, replacing the keys with values is that correct? also do the *.properties files get copied too or are they ignored after maven reads them?
|
# ? Sep 6, 2014 21:56 |
|
nah, lets back up a bit. In your maven project the default folders are like this: src/main/java -- ur java source files go here src/main/resources -- non-java stuff goes here including things like configs for logging or beans or w/e theres also the tests folders but im not gonna talk bout those right now src/test/java -- ur tests go here src/test/resources - non-java stuff for your tests go here. when it builds a project it compiles the contents of the main/java folder and stores it in the output folder (target/classes by default for java files/resources). Then it goes through your resource folders, filters them if filtering is enabled, and then copies them to the output folder. The general end result is that the stuff you have in src/main/java and src/main/resources goes to target/classes compiled and/or filtered as appropriate. src/main/resources is copied and filtered by default without you configuring it in the pom.xml. Also, all files are copied and filtered by default, not just *.properties. If you want to add additional folders, you add <resource> items to your pom.xml and enable filtering on that folder if you want. You can also filter your source files if you really want to. So like if you want to add additional files to target/classes based on environment, you can do like you have in that config. So back to filtering. Filtering happens during the build when resource files are copied from the source to the output folder. Filtering alters the contents of the resource file, maven doesn't use them as configuration in the build. resource files are resources for your application, not for the build so maven doesn't care about them at all (beyond doing the copying/filtering that you configure in the pom). Lets say you have /src/main/resources/database.properties with the content code:
In your pom.xml lets say you have this XML code:
code:
|
# ? Sep 6, 2014 23:56 |
|
|
# ? Jun 5, 2024 07:19 |
|
I probably confused you with my environments thing so lets talk about build profiles. Build profiles are a way to add custom build configurations that are only used under certain conditions. An example condition is packaging a project for different environments. Most of the config is going to be the same in every environment but you might want to change things like connection strings based on where you're going to deploy it. So heres a basic profile config with 2 profiles. XML code:
so now that we have these profiles, lets move the properties for the db config from the root of the pom, to the profiles XML code:
I don't like to put my properties like that into the profiles. I think its gross, but its personal preference. What I do instead is something like this: XML code:
If you do it this way, then instead of relying on filtering you can have database.properties files in both environments/test and environments/production each with hardcoded configs that wont be filtered. In this mode you wouldn't have any properties in the pom.xml for the database config. When you do the build and specify a profile it will only copy the files from the environment folder for that profile. there are ups and downs for both methods. for example if I have a logging config for test I might have additional logging configurations and files beyond what would be easily filterable so having separate files for test and prod makes sense. the downside is that if I make changes to a file in environments/test that I do need to be in production I have to make sure I make the changes myself. with filtering you would only have the one file in src/main/resources so its harder to make a mistake. with filtering you can also specify properties outside the pom.xml entirely which allows you to do something like set the db connection information in the build system. this is probably the best way if you have a good build system setup. (most people don't)
|
# ? Sep 7, 2014 00:21 |