|
qntm posted:it's possible you were thinking of lync?? Lync is in fact worse than hitler
|
#
?
May 19, 2015 20:21
|
|
|
|
| # ? May 10, 2024 21:04 |
|
|
uncurable mlady posted:im not really convinced EF is all that bad tho, shaggars way of doing things seems like it adds several layers of complexity in exchange for nebulous benefits
|
|
#
?
May 19, 2015 20:28
|
|
|
Valeyard posted:did you do the interview sulk?
|
|
#
?
May 19, 2015 20:30
|
|
|
coffeetable posted:you know it's not just shaggar, right? the object-relational impedance mismatch has had millions of words written about it. not saying up and up shaggar's right or wrong (i am Bad at db poo poo), but ORMs definitely have their issues yeah but i dont see anyone else here carrying the banner against ORMs
|
|
#
?
May 19, 2015 21:12
|
|
|
djangos ORM is mega ownage
|
|
#
?
May 19, 2015 21:18
|
|
|
Shaggar posted:EF adds massive complexity vs using a statement mapper. wot do u use for db versioning
|
|
#
?
May 19, 2015 21:20
|
|
|
uncurable mlady posted:yeah but i dont see anyone else here carrying the banner against ORMs except lots of people have agreed with shaggar on this front? we're just not as militant about it.
|
|
#
?
May 19, 2015 21:23
|
|
|
orms are awful source: i used activerecord in a couple of apps. it was Bad.
|
|
#
?
May 19, 2015 21:37
|
|
|
no worse than the rest of ruby on rails, really
|
|
#
?
May 19, 2015 21:44
|
|
|
Anime Sandwich posted:wot do u use for db versioning nothing right now. it kind of sucks but there aren't any good tools for it in sql server
|
|
#
?
May 19, 2015 21:47
|
|
|
I thought even something like Liquibase would work since it has a cli that you can script with
|
|
#
?
May 19, 2015 21:52
|
|
|
liquibase is kind of pointless unless your maintaining some pseudo-schema for use across multiple databases.
|
|
#
?
May 19, 2015 21:58
|
|
|
uncurable mlady posted:DOM my neg rear end jesus. also orms are questionable. i guess they're okay if you treat your db like dumb storage but that's a huge waste? unless you're using mysql in which case yes, your storage is definitely dumb.
|
|
#
?
May 19, 2015 22:00
|
|
|
shaggar... was... right...! *explodes like a gundam* hold on, I have to invent my own no-SQL database where everything is just stored in flat text files to leverage the read speed of modern SSDs I'll call it the Cloud Storage Volumizer
|
|
#
?
May 19, 2015 22:01
|
|
|
coffeetable posted:you know it's not just shaggar, right? the object-relational impedance mismatch has had millions of words written about it. not saying up and up shaggar's right or wrong (i am Bad at db poo poo), but ORMs definitely have their issues the people carrying the banner agains ORMa typically fall into a few camps: - they have a large DB against which many heterogeneous apps will be written. using an ORM to provide a nice API for apps won't help much because only some apps will get to use it. - they have business logic in the DB and have only used ORMs with poor support for that. it can be done well, it's a drawback of individual frameworks not ORMs in general. - they want to do reporting using the same techniques as app development. "the ORM is hard to use to do reports!" so don't use it, use reporting tools. - they have used really lovely frameworks that claim to be ORMs without offering the bulk of ORM features (ActiveRecord). - they don't bother to learn the framework they tried and then when something doesn't work like they naively expect (multithreading) they blame the framework or the entire ORM concept. - they have a couple of very specific cases for which issuing an UPDATE ... WHERE will work better than interacting with objects. (mark-all-as-read, batch deletion, etc.) my experience the past decade has been with SQLite and Core Data (I worked on it) in desktop and mobile apps. most of the issues I see boil down to people trying to use Core Data as if it were a wrapper around SQLite rather than a way of interacting with collections of objects that may not all be in-memory. most of the rest of the issues I see are due to developers tossing objects between threads behind the framework's back, rather than using the framework's threading support. very few are actually due to ORM not being a good fit for the application. on the other hand, most uses of SQLite that I see wind up evolving into a reimplementation of portions of an ORM. and then more of an ORM. and then a rewrite to deal with the parts of an ORM that were implemented incorrectly because they started as a wrapper rather than an ORM. and then...
|
|
#
?
May 19, 2015 22:14
|
|
|
eschaton posted:my experience the past decade has been with SQLite and Core Data (I worked on it) in desktop and mobile apps. most of the issues I see boil down to people trying to use Core Data as if it were a wrapper around SQLite rather than a way of interacting with collections of objects that may not all be in-memory. most of the rest of the issues I see are due to developers tossing objects between threads behind the framework's back, rather than using the framework's threading support. very few are actually due to ORM not being a good fit for the application. that's a good point, I use core data and don't even really think of it as an ORM, but that's because i treat it like its own data store with its own query language i've heard it came a long way before i got around to touching it, i heard tons of horror stories but it's been very needs-suiting for my app
|
|
#
?
May 19, 2015 22:17
|
|
|
also because i'm lazy please link me to something related to how to do threads with core data because i'm just now starting to reach the point where i might want to save data on a background thread and all i know right now is "there be dragons if you try to pass an object to a different thread than the context it was fetched from"
|
|
#
?
May 19, 2015 22:19
|
|
|
eschaton posted:my experience the past decade has been with SQLite and Core Data (I worked on it) in desktop and mobile apps. most of the issues I see boil down to people trying to use Core Data as if it were a wrapper around SQLite rather than a way of interacting with collections of objects that may not all be in-memory. most of the rest of the issues I see are due to developers tossing objects between threads behind the framework's back, rather than using the framework's threading support. very few are actually due to ORM not being a good fit for the application. this makes YOU sound like the outlier rather than everyone else.
|
|
#
?
May 19, 2015 22:20
|
|
|
ATTN SHAGGAR OR SOMEONE: HOW DO I MAKE THIS KAFKA THING WORK IN MY CODE https://github.com/spring-projects/spring-integration-kafka all of these configuration exaples don't make any sense to me. like i guess i put the xml somewhere and put some annotation on the main application class and then it will read the xml and ~magically~ create these classes or something?? and then I put @Bean on top of other things and somehow it knows what I mean by @Bean? Seriously gently caress dependency injection frameworks. DI is cool when it's a way to write your code to make it easy to test and an emphasis on interfaces but it's EXTREMELY BAD when it's like worse than a ruby dsl DONT THREAD ON ME fucked around with this message at 00:07 on May 20, 2015 |
|
#
?
May 20, 2015 00:04
|
|
|
i seriously think it's going to be easier to just use the kafka client provided by apache
|
|
#
?
May 20, 2015 00:05
|
|
|
jesus christ i did it in 10 minutes with the really intimidating looking kafka client provided by apache. gently caress you bean injector
|
|
#
?
May 20, 2015 00:30
|
|
|
apache spark + kafka is pretty cool
|
|
#
?
May 20, 2015 00:42
|
|
|
MALE SHOEGAZE posted:bean injector don't post ur mums pet name for me thanks
|
|
#
?
May 20, 2015 00:58
|
|
|
Dessert Rose posted:also because i'm lazy please link me to something related to how to do threads with core data because i'm just now starting to reach the point where i might want to save data on a background thread and all i know right now is "there be dragons if you try to pass an object to a different thread than the context it was fetched from" I don't have any direct links handy but I think the docs should have details about how to structure that using child contexts. I think Marcus Zarra also wrote a blog post about it. also, you want to use Core Data's built-in queue mechanism and treat -[NSManagedObjectContext init] as if it doesn't exist. (use the variants that let you specify a concurrency type instead.) it sounds like you have the right attitude towards multithreading in Core Data: learn how it works, then follow the recommendations. too many people just start throwing things on background threads or queues and blame the framework when their broken code is broken. I'll grant that before OS X 10.7 and iOS 5 introduced child contexts, Core Data concurrency was much more subtle, but the "Core Data isn't thread-safe" canard has always been silly; it was designed for multithreading from the start. I don't know how Entity Framework handles any of this stuff but given that it's in most ways a clone of Core Data (which is itself a successor to Enterprise Objects Framework) I'd expect there to be some similarity.
|
|
#
?
May 20, 2015 01:09
|
|
|
St Evan Echoes posted:never realised how much i lean on linq until i started rewriting a package from c# to java if you need linq as expression trees passed into iqueryables well youre prolly hosed then
|
|
#
?
May 20, 2015 01:09
|
|
|
iirc our problems weren't that Core Data was unsafe, just that moving objects between threads was brutal for performance. it's been a while, though.
|
|
#
?
May 20, 2015 01:10
|
|
|
is there an eli5 of every big data database thing i dont know about. i dont know anything about any of them. like maybe a guide that differentiates each one from postgresql capabilities
|
|
#
?
May 20, 2015 01:11
|
|
|
Flat Daddy posted:is there an eli5 of every big data database thing i dont know about. i dont know anything about any of them. like maybe a guide that differentiates each one from postgresql capabilities they aren't necessary in 99.9999% of the cases people use them for
|
|
#
?
May 20, 2015 01:15
|
|
|
but there's so many of them
|
|
#
?
May 20, 2015 01:16
|
|
|
MALE SHOEGAZE posted:ATTN SHAGGAR OR SOMEONE: its using gradle instead of maven. abort! abort!
|
|
#
?
May 20, 2015 01:18
|
|
|
Shaggar posted:At work we use a transactional model cause we literally get paid through reporting. We have a bunch of different apps that can all share the same core transaction design and then have individual related transaction tables with data specific to that app. So I can write procs that are reusable by all apps to generate common data, and then app specific procs to do more stuff. it makes our data really high quality which is far more important than maybe saving a few minutes of coding time. Shaggar posted:
|
|
#
?
May 20, 2015 01:24
|
|
|
Subjunctive posted:iirc our problems weren't that Core Data was unsafe, just that moving objects between threads was brutal for performance. it's been a while, though. you mean passing object IDs between threads, of course.  nested contexts can help a lot for that because objects can more easily and safely share (immutable) state behind the scenes. using NSFetchRequest well to pre-fetch relationships will also help with performance. basically, I can understand when companies like Facebook. Google, Microsoft do their own thing instead of Core Data, they can afford to invest in the area and might even have solid integration-level reasons to do so. (eg most of the app is in C++ and cross platform so they want a C++ data layer too.) it's when some random James working on their own starts reinventing the world that I think they're probably going the wrong way. even a co whose main business isn't data probably shouldn't be doing things like that, and should use solution that already exists.
|
|
#
?
May 20, 2015 01:32
|
|
|
someone tell me what gradle is
|
|
#
?
May 20, 2015 02:00
|
|
|
PokeJoe posted:someone tell me what gradle is an alternative to maven that uses groovy for its build file rather than xml
|
|
#
?
May 20, 2015 03:05
|
|
|
MALE SHOEGAZE posted:ATTN SHAGGAR OR SOMEONE: in 2015, you should never be using xml configuration with spring spring DI is fantastic
|
|
#
?
May 20, 2015 03:14
|
|
|
opt posted:an alternative to maven that uses groovy for its build file rather than xml its the new default in android studio we are a 'buck' shop which i wouldnt have any problems w/ except i dont have the slightest idea how to use it
|
|
#
?
May 20, 2015 03:31
|
|
|
PokeJoe posted:someone tell me what gradle is its dumb crap for idiots who don't understand why everyone moved from ant to maven
|
|
#
?
May 20, 2015 03:32
|
|
|
idk why jave cant just use a makefile like everybody else
|
|
#
?
May 20, 2015 03:36
|
|
|
MALE SHOEGAZE posted:ATTN SHAGGAR OR SOMEONE: seems like it'd be prone to big, grotesque bugs
|
|
#
?
May 20, 2015 03:56
|
|
|
|
| # ? May 10, 2024 21:04 |
|
|
Shaggar posted:its dumb crap for idiots who don't understand why everyone moved from ant to maven our build.gradle files are just a list of plugins and dependencies...i guess it would suck if people just use it as a place to ad hoc script some build poo poo
|
|
#
?
May 20, 2015 04:04
|
|