|
Space Whale posted:
you did WHAT now?
|
#
?
Dec 20, 2014 02:50
|
|
|
|
| # ? May 11, 2024 17:47 |
|
|
Shaggar posted:1) don't use an orm and double don't use your own custom orm. Not our call. Also.... Shaggar posted:2) separate duties and assign one group to work on your data layer and stick it in a separate project and maybe separate repo if it makes sense. This eliminates conflicts cause no one is working on the same thing, people just work on what they're supposed to and check it in. It's a DAC. As in we instantiate an object, and then BIZOBJECT's properties are set, then we call BIZOBJECT.SaveYourselfToTheDB. It's awful. We can't really do a refactor like that yet. Our team was hired on to start defuckulating some old crap, basically. It does in fact blow. Our resident 20+ year veteran developer can't stand it, or ASP.NET forms in general. He's trying to push some new development to make some AJAX and use some jQuery for dynamic poo poo soon at least because lolrepeaters. Shaggar posted:Then the data team builds their library and publishes it to a central location as a nuget package. I guess if we all said YO, DAC MAKER, MAKE THESE PROPERTIES AND MAP THEM TO THE DB that would work, and then we'd all share it. rotor posted:you did WHAT now?  Our snowflake orm bleats if a column exists in a db table but doesn't map to a property, and flatly refuses to work for the reasons of "PARAMETER NUMBER MISMATCH" even if it's a nullable loving column. So as we add a property to BIZOBJECT we need to add the column and the sproc called by the loving DAC. The reason this sucks is that when joeGrammer adds a property to BIZOBJECT.CS and the column to the db (and the sproc) and the db change is saved to the database, everyone else's BIZOBJECT.CS calls to that table bleat and fail until they also include that property/column. So, one of the more helpful programmers was like "hey take BIZOBJECT.CS from my branch!" So we would all round robin it as we went. Basically the team is new to git, I'm new to the team AND to get, and data access classes and EF (or whatever) loving suck, and the first idea for how to minimize downtime with big ugly PARAMETER MISMATCH errors is just sharing that file around. The problem is when every dev had a different version of that file and they all merged their branches into the same dev/uat/qa/whatever. We have a problem.
|
|
#
?
Dec 20, 2014 03:04
|
|
|
convert everything to procs and atleast use EF function mapping so u don't want to murder urself so bad. then also use asp.net mvc.
|
|
#
?
Dec 20, 2014 03:09
|
|
|
stop using git and/or commit to the loving central server and tell everyone to update.
|
|
#
?
Dec 20, 2014 03:11
|
|
|
Shaggar posted:convert everything to procs and atleast use EF function mapping so u don't want to murder urself so bad. Well I mean the DAC references a big enum of sprocs (oh god...) so it's calling a stored procedure. But yeah I do wonder why it has to loving poo poo itself if someone adds a row and it's not consumed properly.
|
|
#
?
Dec 20, 2014 03:12
|
|
|
like if someone adds a thing that they changed in the db and that will break the app, they should commit everything immediately and then tell everyone to update. this way everyone is up to date w/ the latest poo poo and there are no conflicts later. do not use your own local copy of a repo. do not check poo poo in locally. only commit to the server otherwise poo poo gets fragmented because dvcs is an idiotic concept that results in exactly what you're seeing
|
|
#
?
Dec 20, 2014 03:12
|
|
|
Space Whale posted:Well I mean the DAC references a big enum of sprocs (oh god...) so it's calling a stored procedure. your procs have input and output and that is independent of table structure. changing tables and views should have no impact on the proc unless you also change those procs in a way that changes parameters. EF sucks poo poo tho so it doesn't have a real statement mapper. it also generates code via a template instead of reflection for better or worse, but it means when someone changes a function definition or imports a new function it changes a shitload of stuff in the templates in addition to generating new classes and that is kind of a nightmare if everyone is in there changing it constantly. again, the best way to fix this is to be smart about who and when these updates happen, commit them to a central repo, and force everyone to update so no one is ever out of date.
|
|
#
?
Dec 20, 2014 03:17
|
|
|
I hate EF so much. its total poo poo
|
|
#
?
Dec 20, 2014 03:17
|
|
|
Shaggar posted:stop using git and/or commit to the loving central server and tell everyone to update. I've taken it upon myself to explain to people how revert HEAD^ works etc. Since, welp,  http://onlywei.github.io/explain-git-with-d3/ this is cool. One thing that sucks is I had someone bitch right in front of me that I made too many commits. Because I had to switch branches to help someone and change projects and poo poo every loving hour so all week. I should learn to squish commits into one big commit or rebase ughhhhhhhhhhhhhhhhhhhhhhhhhhh I MISS TFS Shaggar posted:like if someone adds a thing that they changed in the db and that will break the app, they should commit everything immediately and then tell everyone to update. this way everyone is up to date w/ the latest poo poo and there are no conflicts later. Not only am I co-FNG I've got the least amount of time as a developer so trying to convince people of this will be a challenge. I still remember the incredulity when I was in the command line trying to revert just one file and the text of my branch was yellow being both behind and ahead of HEAD, and my boss was like NOO DONT PUSH THAT NOOO YOU'LL WRECK YOUR BRANCH. Of course it's behind, I reverted one of the files! People are afraid of git, it's sad. Shaggar posted:I hate EF so much. its total poo poo I got hired in part because I don't like it either and I got someone going on a rant about the suckitude of linq to sql
|
|
#
?
Dec 20, 2014 03:19
|
|
|
yeah that stinks. you could force everyone to switch to svn  the thing I hate about EF is its designed to be this retarded in memory cache where you stick objects that may or may not be in the database and then you do stuff in memory and then commit the changes to the database. its a terrible terrible way to interact w/ a db and is so incredibly aggravating to use. atleast when you use function imports it doesn't use that dumb crap and just calls the loving statement. I guess in newer versions they might allow you to use existing classes for function input/output and they're promising way better performance and if that's the case i'll probably be ok w/ it.
|
|
#
?
Dec 20, 2014 03:27
|
|
|
Shaggar posted:yeah that stinks. you could force everyone to switch to svn Ahahha speaking of dumb db poo poo? We managed to snag a cool dude who was on the team at MS that loving wrote MSSQL Server as our DBA. So guess what dumb poo poo we do? We're using mongodb for error logging. By order of some C level exec. Also we're supposed to be putting our photos in there. We used to put the photos in one big flat loving directory. No, we didn't do something smart like split it up by year/month/day/subdivide if you exceed some magic number of files per folder either, we'd put literally millions in one big flat folder so it took forever to pull them out. But I guess mongo would be a step up from that? Also we use Elmah but it's broken on one of our projects lol. I'll bring up the function import thing. What scares me is I didn't actually... ever see an edmx file. I think we have snowflake ORM poo poo.
|
|
#
?
Dec 20, 2014 03:41
|
|
|
lol that's awful.
|
|
#
?
Dec 20, 2014 03:45
|
|
|
dsyp
|
|
#
?
Dec 20, 2014 03:47
|
|
|
you can store the photos in sql server as blobs if you want to make ur sql server dev upset @ u. you can also stick them in a db on another disk so their out of the way. but then u'll have really good relationships between photos and data and you can make sure stuff gets pruned very easily
|
|
#
?
Dec 20, 2014 03:51
|
|
|
Shaggar posted:you can store the photos in sql server as blobs if you want to make ur sql server dev upset @ u. you can also stick them in a db on another disk so their out of the way. but then u'll have really good relationships between photos and data and you can make sure stuff gets pruned very easily My first response to finding out photos are all in a big rear end flat folder (we're talking millions) was "why not split into directories hierarchically up by year, month, and day, and if over how many thousands per day subdivide again, and store the path to the folder in a file server in a database." I dunno we have more pressing problems I guess.
|
|
#
?
Dec 20, 2014 03:56
|
|
|
its probably only a problem if someone tries to open the dir lol.
|
|
#
?
Dec 20, 2014 03:59
|
|
|
I'm not reading all that poo poo but the second you start emailing people files you hosed up bad
|
|
#
?
Dec 20, 2014 04:03
|
|
|
using git is basically like using email cause everyone has their own local copies they send back and forth 2 each other.
|
|
#
?
Dec 20, 2014 04:05
|
|
|
rotor posted:I'm not reading all that poo poo but the second you start emailing people files you hosed up bad but how else am i gonna share this kickass slide deck and word doc
|
|
#
?
Dec 20, 2014 04:08
|
|
|
it is named proposal_final_revSubmit_ak_1730.docx
|
|
#
?
Dec 20, 2014 04:09
|
|
|
darcs is better than hg and git
|
|
#
?
Dec 20, 2014 04:23
|
|
|
FamDav posted:darcs is better than hg and git more like dorks lmbo
|
|
#
?
Dec 20, 2014 05:00
|
|
|
shaggar was truthy
|
|
#
?
Dec 20, 2014 05:40
|
|
|
bobbilljim posted:shaggar was truthy code:
|
|
#
?
Dec 20, 2014 07:33
|
|
|
but seriously as soon as i started reading that my question was "why the gently caress does everyone care what version the DEV database is using?" like, just bring up your own database with some suitable test data when you're testing your local changes. then once that change actually gets to master the dev server gets the new configuration
|
|
#
?
Dec 20, 2014 10:00
|
|
|
Shaggar posted:using git is basically like using email cause everyone has their own local copies they send back and forth 2 each other. nice
|
|
#
?
Dec 20, 2014 14:44
|
|
|
And svn is more like using ftp because everyone just uploads their poo poo to a server
|
|
#
?
Dec 20, 2014 15:38
|
|
|
Jabor posted:but seriously as soon as i started reading that my question was "why the gently caress does everyone care what version the DEV database is using?" Because our lovely architecture poo poo a brick if dev "a" adds a new column to the db (that all devs touch) and dev "b", "c", "..." (etc) do not yet have it. So ClassThatTouchesThatTableAndThoseSprocs has to be modified to not poo poo the bed upon seeing that new column. So we'd share that one file and just C&P away. But when it came time to MERGE DA BRANCHES it predictably went bad. Basically it's fear of the tools. People don't want to say "no, don't push that file, just all the rest, dev 'a' already pushed up a working version" because "WHAT NO I AM AHEAD OF AND BEHIND THE BRANCH NOOO THE TEXT IS YELLOW IN POWERSHELL".
|
|
#
?
Dec 20, 2014 18:10
|
|
|
MononcQc posted:And svn is more like using ftp because everyone just uploads their poo poo to a server svn is a basically better-behaved, version-controlled ftp nothing wrong with that it is kinda funny that versioned file sharing was a thing on vms in the 1980s, while unix users were fumbling around with rcs and sccs to try and make up for a non-version-controlled filesystem
|
|
#
?
Dec 20, 2014 18:29
|
|
|
Does anyone have some favorite resource(s) for programming architecture (particularly related to webapps), be they books or blogs or whatever? Want to find some good resources for things like the queues=sinks post from a while ago, TheresNoThyme fucked around with this message at 19:04 on Dec 20, 2014 |
|
#
?
Dec 20, 2014 19:02
|
|
|
Tefs post history
|
|
#
?
Dec 20, 2014 19:09
|
|
|
Space Whale posted:Because our lovely architecture poo poo a brick if dev "a" adds a new column to the db (that all devs touch) and dev "b", "c", "..." (etc) do not yet have it. So ClassThatTouchesThatTableAndThoseSprocs has to be modified to not poo poo the bed upon seeing that new column. if you really can't fix your poo poo db layer, maybe you could make each version access a view, so when you add new columns to 'table', the old software still accesses 'table_view_v5' and doesn't see the new columns.
|
|
#
?
Dec 20, 2014 19:12
|
|
|
suffix posted:if you really can't fix your poo poo db layer, maybe you could make each version access a view, so when you add new columns to 'table', the old software still accesses 'table_view_v5' and doesn't see the new columns. Fwiw this is the problem I have to deal with now on a very large system. What you're describing is the very reasonable first hack which for this project then led to 50+ views in 6 months and then, when some courageous person finally gets around to fixing the poo poo db layer, suddenly no one is able to trace the tribal knowledge for a hundred iterations of "my data goes like this....."
|
|
#
?
Dec 20, 2014 19:30
|
|
|
all of these problems are solved by not using an ORM and especially not rolling your own ORM. and using svn instead of git.
|
|
#
?
Dec 20, 2014 19:35
|
|
|
rrrrrrrrrrrt posted:all of these problems are solved by not using an ORM and especially not rolling your own ORM. however do isolate your db behind its own service. didnt actually read your story, thanks and god bless tho
|
|
#
?
Dec 20, 2014 19:57
|
|
|
pro tip: comment out the code that throws the column number mismatch exception or swallow it
|
|
#
?
Dec 20, 2014 23:38
|
|
|
sounds like you're swallowing a lot of poo poo already
|
|
#
?
Dec 20, 2014 23:38
|
|
|
hey tef if you're out there when you say ruby enumerators are more like observers what do you mean? just wondering
|
|
#
?
Dec 21, 2014 00:18
|
|
|
AWWNAW posted:sounds like you're swallowing a lot of poo poo already
|
|
#
?
Dec 21, 2014 01:28
|
|
|
|
| # ? May 11, 2024 17:47 |
|
|
c3js, a derivative of D3 which comes with premade charts with a fuckton of easy customization options, is really good
|
|
#
?
Dec 21, 2014 21:32
|
|
