|
well I sure hope not
|
#
¿
Oct 9, 2017 16:17
|
|
|
|
| # ¿ Apr 29, 2024 00:09 |
|
|
theres gotta be mvc/mvvm frameworks for swing these days, right?
|
|
#
¿
Oct 9, 2017 18:50
|
|
|
I wasn't aware that people used something other than consolas
|
|
#
¿
Oct 9, 2017 21:10
|
|
|
why are you still using scala? I thought you would have learned your lesson by now.
|
|
#
¿
Oct 9, 2017 21:43
|
|
|
I use https://regexr.com/
|
|
#
¿
Oct 10, 2017 18:11
|
|
|
Notorious b.s.d. posted:my current team is obsessed with "pull requests" so I routinely slip poo poo like this into unrelated PRs to reduce the amount of paperwork I do pull request is a stupid loving term for a commit
|
|
#
¿
Oct 11, 2017 15:01
|
|
|
merge request is a stupid term too cause its not a request, its a notification. the code has already changed, there was no request to authorize, and the owner of the code change is going to continue using it. whether you decide to merge it with your own repo is up to you and your company's policies. its one of the core problems with distributed version control.
|
|
#
¿
Oct 11, 2017 15:09
|
|
|
no you don't. they already made the change in their own repo and that's where it matters. the fact that you haven't brought it into your own repo just means your repo is out of date compared to what the originating developer is working with
|
|
#
¿
Oct 11, 2017 15:14
|
|
|
despite it being the only one that matters because its what people are working in
|
|
#
¿
Oct 11, 2017 15:18
|
|
|
cinci zoo sniper posted:e: ^ does anyone irl do intra-team/branch pull requests? my point is that calling it a request is a company policy thing and nothing to do with git which only has notifications. the fact that you must create a policy around notifications in git is one of its failings, but one that's general to distributed version control.
|
|
#
¿
Oct 11, 2017 15:31
|
|
|
cinci zoo sniper posted:while i sort-of agree, im not sure what would then make git request-pull a request in your eyes request is a bad term for the version control system to use, but if your company wants to use it during their process its fine.
|
|
#
¿
Oct 11, 2017 15:35
|
|
|
IE11 and Edge are the only browsers worth supporting. lol if you write for adware like chome or failfox or one offs like slowfari
|
|
#
¿
Oct 11, 2017 15:36
|
|
|
css grids are probably the only worthwhile thing its out of date on, but that's only cause it invented css grids and has its own css for it
Shaggar fucked around with this message at 15:43 on Oct 11, 2017 |
|
#
¿
Oct 11, 2017 15:39
|
|
|
lol auto correct
|
|
#
¿
Oct 11, 2017 15:43
|
|
|
but yeah theres not really much in web "standards" that's worthwhile aside from some CSS features that are still largely browser dependent.
|
|
#
¿
Oct 11, 2017 15:44
|
|
|
mvc/mvvm is the least bad way to do web "development" and razor is the best way to do mvc/mvvm.
|
|
#
¿
Oct 11, 2017 15:50
|
|
|
I don't really care if something works on the android browser
|
|
#
¿
Oct 11, 2017 15:55
|
|
|
nah, just use html and as little css/js as you can get away with. web "devleopers" are the biggest retards and their problems with browser "compatibility" are always their own bad mistakes
|
|
#
¿
Oct 11, 2017 16:02
|
|
|
web "developer" in 2017: well if I load this 30 megs of javascript into my page I can get around all the failings of my javascript backend and render a few lines of text.
|
|
#
¿
Oct 11, 2017 16:04
|
|
|
cinci zoo sniper posted:there are literally 0 things wrong with xml
|
|
#
¿
Oct 11, 2017 16:06
|
|
|
MononcQc posted:I'd be down for a new generation of web browsers that are all about static sites with no JS and very limited design capabilities. Bring back document-based web. webassembly may save us from javascript.
|
|
#
¿
Oct 11, 2017 16:06
|
|
|
people like their terrible web pages with their terrible javascript so we aren't putting that poo poo back in the bottle. the best we can hope for is being able to write web pages in something that isn't trash like javascript is
|
|
#
¿
Oct 11, 2017 16:19
|
|
|
Notorious b.s.d. posted:this hurts why would you store serialized data in your database at all?
|
|
#
¿
Oct 11, 2017 17:03
|
|
|
lol nice scare title. "bad developers roll custom security code" is a better title. because xml signing is well defined we can have our framework handle all of this for us with very little effort on our part. XML is good and the problem here is bad web "developers" who don't understand how to use XML because they are web "developers" and therefore retarded Shaggar fucked around with this message at 17:09 on Oct 11, 2017 |
|
#
¿
Oct 11, 2017 17:07
|
|
|
cinci zoo sniper posted:analytics. most analysts and their tools don't know anything except sql (and excel for the latter). even in my case, when i can confidently write analytics stuff in python or r, i would still highly prefer to have it server-side, so i need to pull less, and get to pull cleaner but why store it as the serialized xml? normalize that poo poo
|
|
#
¿
Oct 11, 2017 17:08
|
|
|
akadajet posted:it's 2017, why are you using knockoutjs? knockoutjs is the least bad client side rendering library
|
|
#
¿
Oct 11, 2017 23:38
|
|
|
you'd have the best technology and nobody would have to write javascript
|
|
#
¿
Oct 12, 2017 14:59
|
|
|
once your company gets to the point where it can afford to buy software, SQL Server is probably the first purchase you should make if data is important to your business. the db is the best, the tools are the best, and the addons like SSIS and SSRS that come with it are so good (esp SSIS). The only downside to sql server I can think of compared to MySQL/PostgreSQL is that sql server licensing can be confusing and it costs money. The one gotcha I can think of is that sql server has pretty sane defaults, except for its default memory limit. By default its set unlimited so sql server can and will starve your os and other applications of resources if you let it. Plan your resource sizing appropriately and set memory limits for your sql instances relative to available resources.
|
|
#
¿
Oct 12, 2017 15:18
|
|
|
good tools cost money and management trying to take them away is a good sign that your company is bad.
|
|
#
¿
Oct 12, 2017 15:26
|
|
|
cinci zoo sniper posted:that sounds fairly good, i guess? going to read up more on ssrs since that might be something relevant to my duties. SSIS is very very good. SSRS is serviceable
|
|
#
¿
Oct 12, 2017 15:50
|
|
|
Sql server on rds is really bad. azure sql is much better if you want sql as a service, but even then you're gonna have some limits that normal sql server wont have.
|
|
#
¿
Oct 12, 2017 16:02
|
|
|
the default isolation level in sql server is read committed which is fine. you can change this at a default level or at an individual transaction level so its not really a problem.
|
|
#
¿
Oct 12, 2017 16:25
|
|
|
cinci zoo sniper posted:my sql jargon is bad, but isn't this saying that you basically can't do anything with t-sql in stored procs? no, its saying there are edge cases you need to worry about when handling transactions in stored procs and triggers. the other major gotcha in sql server is that theres a boatload of mythological knowledge about how you should never do some things cause they're bad from a technical standpoint. These often totally ignore the circumstances of usage and just say its always bad. also many times they are related to limitations of older versions of sql server that people still assume are problems. Always take things like "transactions in procs can cause errors" with a huge grain of salt. Transaction handling in procs isn't any more dangerous than transaction handling outside of procs. the issue here is presented in the Microsoft docs as a technical concern, when it is really a design concern. a better statement would be "if you handle transactions in stored procs, make sure you also handle errors there"
|
|
#
¿
Oct 12, 2017 16:49
|
|
|
HoboMan posted:shaggar, i am genuinely curious how you get around this as you seem to also advocate using procs for everything its not actually a problem. also I generally do transaction handling outside of procs
|
|
#
¿
Oct 12, 2017 16:50
|
|
|
transactions in sql server are just a set of statements you want to happen all at the same time. same as other dbs. The differences from other dbs will come in the form of isolation levels which you should definitely read and understand, though you will almost always use read committed. you can perform transactions at any point in your sql which means they could be in your c# code or they could be in your procs or they could be in both in which case the proc's transaction would normally be joined to the one from your c# code. the only real reason to do transactions in procs is if you want to isolate the proc from any code that might run it and forget to start a transaction. transactions in triggers makes way more sense since triggers are called by sql server directly. also you should generally never use triggers since they present discoverability issues. if you have an application that relies on a trigger a new developer pulling that app out of source control is not gonna be immediately aware that theres a trigger doing things where he can see regular calls to perform statements very obviously in code. The exceptions are mostly around things like auditing where its not related to an applications functionality.
|
|
#
¿
Oct 12, 2017 17:02
|
|
|
HoboMan posted:i guess my real problem is our db procs are exposed to offsite consultants and they have hosed poo poo up and will again yeah bad code in a proc isn't any different from bad code in c#.
|
|
#
¿
Oct 12, 2017 17:02
|
|
|
yeah that would be a no brainer. maven is so good
|
|
#
¿
Oct 12, 2017 17:04
|
|
|
jony neuemonic posted:bad code in c# is way easier to debug, tho. c# is deffo easier to debug than sql, but in this case I should have clarified bad sql statements in c# vs statements in a proc.
|
|
#
¿
Oct 12, 2017 17:10
|
|
|
CRIP EATIN BREAD posted:gradle is easier to cobble something together quickly, but scales terribly when you have a large project. maven is a bit more verbose and strict, but is better at what it does. I would totally disagree. gradle is like rails where "easier to cobble something together quickly" is a difference of maybe 60 seconds from doing it right from the start with a real build tool/language
|
|
#
¿
Oct 12, 2017 17:12
|
|
|
|
| # ¿ Apr 29, 2024 00:09 |
|
|
CRIP EATIN BREAD posted:
is that any different from a default pom? I'm not writing much in a default pom other than setting the build level.
|
|
#
¿
Oct 12, 2017 17:25
|
|