terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›7 »

redleader: Aug 18, 2005; Engage according to operational parameters

Shaggar posted:

I did a powershell script for a thing and powershell is still kind of dumb because why didn't they just use c# syntax, but the one thing I do like is you can sign scripts and require signatures for scripts to run. that's cool and way better than Linux where the bad scripting language is not just the UI, but its unrestricted.

for a language designed around piping objects around, it's baffling that powershell has no convenient way of creating a custom object to sling through the pipeline. i'd really, really like the ability to jam a few fields into some ad hoc object, a la c# or js, but in powershell creating an object is just gross

i really wanted to like powershell, but there are so many annoying gotchas (how do you gently caress up multidimensional lists so badly?) that i just can't. it's so, so awkward in practice. powershell should just have been a more dynamically-typed c# with some additional linqy stuff and syntax to make typical scripty tasks easier

# ¿ Dec 3, 2015 11:14

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 00:34

redleader: Aug 18, 2005; Engage according to operational parameters

Shaggar posted:

you can create maps like $aThing = @{ SomeProp="fffff", whatever="guuuuhhhhh" } and then $aThing.SomeProp or $aThing.whatever. I haven't done much diving into the syntax cause I was doing something pretty simple.

nice, didn't know you could access keys of hash tables like that

# ¿ Dec 5, 2015 03:06

redleader: Aug 18, 2005; Engage according to operational parameters

mystes posted:

powershell

these are correct opinions

powershell could be so good. piping actual objects around is objectively better than munging text output, but the language itself is just so awkward in practice. it might be easier if i used it every day, but i'm a casual

# ¿ Dec 6, 2015 04:16

redleader: Aug 18, 2005; Engage according to operational parameters

MononcQc posted:

I guess my problem with C is that I wouldn't trust myself not to make some fatal mistake in there that could severely blow up and then I'd never understand why or how it happens

this is the impression i get from c++

# ¿ Jan 17, 2016 04:53

redleader: Aug 18, 2005; Engage according to operational parameters

Sagacity posted:

Because JSON is not broken enough let's use YAML instead because that is clear and umabigious and...

allowing numbers to be specified in base 60 is one of the weirdest and most baffling design decisions i've yet encountered

quote:

Using �:� allows expressing the integer part [of a floating point number] in base 60, which is convenient for time and angle values (the fractional part is always in base 10).

Example: 190:20:30.15

that's a weakass justification for such an unexpected feature

# ¿ Jan 22, 2016 21:27

redleader: Aug 18, 2005; Engage according to operational parameters

gonadic io posted:

Jesus christ scala xml literals are implemented poorly. They seem fine, until suddenly you spend three hours working out why a test is failing on two identical xml nodes:
code:
val string = <Tag>{"1"}</Tag>
val int = <Tag>{1}</Tag>
val literal = <Tag>1</Tag>
 
println(string)
println(int)
println(literal)
println(string == literal)
println(int == literal)
Prints:
<Tag>1</Tag>
<Tag>1</Tag>
<Tag>1</Tag>
true
false

P.s. The explanation to this behaviour (until I knew exactly what to Google for) was in a comment on a stack overflow answer from 2011

i'll bite. why?

# ¿ Feb 20, 2016 23:54

redleader: Aug 18, 2005; Engage according to operational parameters

over the last couple of days i wrote a truly hideous sql function that does some annoying business logic stuff. it's going to be a maintenance nightmare for the poor bastard who has to deal with it later. i mean, i wrote the drat thing and i'm not sure that i can fully explain all of it. it sort of... evolved organically, in that i understood each change to the function individually, but if you asked me to walk you through the whole thing i'd have to hand wave and mumble a lot

and this is after a rewrite from an even earlier attempt

oh well, it seems to work and passed code review! and of course there's no time to have another attempt at writing it better

... i think i just might be a terrible programmer

# ¿ Mar 30, 2016 11:34

redleader: Aug 18, 2005; Engage according to operational parameters

pfft, all you ivory tower types with your highfalutin "oo design"

just vomit code into your editor until a few cursory manual tests look alright, then throw that poo poo up to production

# ¿ Apr 1, 2016 10:07

redleader: Aug 18, 2005; Engage according to operational parameters

redleader posted:

over the last couple of days i wrote a truly hideous sql function that does some annoying business logic stuff. it's going to be a maintenance nightmare for the poor bastard who has to deal with it later. i mean, i wrote the drat thing and i'm not sure that i can fully explain all of it. it sort of... evolved organically, in that i understood each change to the function individually, but if you asked me to walk you through the whole thing i'd have to hand wave and mumble a lot

and this is after a rewrite from an even earlier attempt

oh well, it seems to work and passed code review! and of course there's no time to have another attempt at writing it better

... i think i just might be a terrible programmer

to absolutely no one's surprise, i had to almost totally rewrite that awful sql function because the client's requirements weren't what we thought they were

it's slightly better now, so that's nice

# ¿ Apr 13, 2016 13:23

redleader: Aug 18, 2005; Engage according to operational parameters

are you loading the data into scala objects just to filter them? could you do the filtering in the db to reduce the number of rows?

it kinda sounds like you might be somewhat underprovisioned, especially if your working set doesn't all fit into memory at once.

bad programmer idea: since you're on aws already, dump a backup of B into an s3 bucket somewhere and send A the location. A can then pull the file, restore a copy of B locally and reconcile poo poo without sending an entire database as a json response.

# ¿ Apr 26, 2016 12:59

redleader: Aug 18, 2005; Engage according to operational parameters

jquery is a much nicer api to use than the standard dom imo

e.g.

JavaScript code:

el.insertAdjacentHTML('afterend', htmlString);

that's just nasty

# ¿ Apr 30, 2016 08:23

redleader: Aug 18, 2005; Engage according to operational parameters

Finster Dexter posted:

Everyone in the company is flipping their poo poo because I added the EF config section and a binding redirect to an updated MySql.Data.dll. Someone loving kill me now. I'm chain-firing email responses to every non-technical piece of poo poo complaining about having to update configs on 50 different client sites.

Sorry I made you do your job, dipshits, now maybe you'll spend some time looking into a deployment solution that doesn't suck poo poo, motherfucker. gently caress I'm pissed right now.

this is us, only if someone makes a config change then they have to manually deploy it to 100+ websites

i've done this once

# ¿ May 21, 2016 05:52

redleader: Aug 18, 2005; Engage according to operational parameters

is the msdn magazine any good? work just bought a bunch of msdn subscriptions and i'm wondering if it's worth cashing in the ~free~ 1 year subscription for a ~hard copy~ of the msdn magazine

# ¿ May 25, 2016 11:12

redleader: Aug 18, 2005; Engage according to operational parameters

MononcQc posted:

property-based testing

you should put these posts up on your blog

# ¿ May 29, 2016 02:08

redleader: Aug 18, 2005; Engage according to operational parameters

LeftistMuslimObama posted:

today i discovered a place where multiple fields were being serialized to the server as a comma-delimited string. the guy even took the time to define a constant COMMA to use in lieu of actually typing "," but at no point thought "what if one of these fields contains a comma". 15 years later, when ambulance data on claims gets sent to the server pickup and dropoff addresses are overflowing into later fields if they contain commas.

we do a bunch of csv exports from various things. i'm amazed at how infrequently people ever stop to think 'hey, what if a field contains a comma?'

i'm constantly finding this poo poo in code reviews, as well as other related things like failing to escape stuff when generating js, not url-encoding data properly, etc.

# ¿ Jun 12, 2016 03:12

redleader: Aug 18, 2005; Engage according to operational parameters

HoboMan posted:

anyways, connection pooling. if I call several functions where several of them are
C# code:
using(a database connection)
will c# take care of optimizing that or do i need to nest all the calls in larger using statement to get them to pool?

ado.net pools connections out of the box, pooling them based on the connection string (and windows identity if necessary). you need to go out of your way to disable connection pooling

msdn has a pretty good writeup on sql server connection pooling, and it looks like a couple of other providers also support connection pools. no idea what the situation is with mysql/postgres/whatever - refer to the individual docs i guess

# ¿ Jun 12, 2016 03:20

redleader: Aug 18, 2005; Engage according to operational parameters

a nice writeup by peter norvig on the travelling salesman problem. very readable for truly awful programmers like myself

# ¿ Jul 3, 2016 12:33

redleader: Aug 18, 2005; Engage according to operational parameters

the talent deficit posted:

scalaz is for when you want to have to figure out what these mean when someone else on your team uses them:

∘, ∘∘, ↦, ↣, ∑, ∃, ∀, ☆, ★, ∋, ∈:, >>=, >~>, |@|

this was not a joke

i imagine there must be some bitter, furious people who've had to track down bugs caused by someone else using a hollow star where they should have used a filled star

# ¿ Jul 10, 2016 11:26

redleader: Aug 18, 2005; Engage according to operational parameters

the talent deficit posted:

scalaz is for when you want to have to figure out what these mean when someone else on your team uses them:

∘, ∘∘, ↦, ↣, ∑, ∃, ∀, ☆, ★, ∋, ∈:, >>=, >~>, |@|

this was not a joke

i mean, i'm not particularly opposed to operator overloading, but this is ridiculous. come on guys, show some restraint

# ¿ Jul 10, 2016 11:27

redleader: Aug 18, 2005; Engage according to operational parameters

today in code review: 15 minute discussion between 3 devs about whether it is better to create xml that uses attributes or xml that uses elements

i.e.

XML code:

<a b="123" c="asd" />

XML code:

<a>
	<b>123</b>
	<c>asd</c>
</a>

# ¿ Jul 19, 2016 13:12

redleader: Aug 18, 2005; Engage according to operational parameters

the answer: we have no standards or conventions for xml in any way, so whatever anyone ever writes is fine

this is unless the cto decides to get on his high horse and proclaim that 'we should be using <Fucking_Awful_Cased_Xml With_Attributes="Wherever possible" />' this week - and, of course, totally forget about his decree the week after

# ¿ Jul 19, 2016 13:25

redleader: Aug 18, 2005; Engage according to operational parameters

Strumpy posted:

I tend to not do this. Users can call ToList on the returned collection of they need multiple enumeration.

i use IEnumerable<T> as the return type but actually return List<T>. this is because most of my colleagues don't know anything about IEnumerable and multiple enumeration and iterator methods and laziness and such

i also have an annoying habit of always typing IEnumberable

# ¿ Jul 23, 2016 08:22

redleader: Aug 18, 2005; Engage according to operational parameters

abraham linksys posted:

using double-equals is so uncommon in js these days

i can assure you that it is, in fact, not uncommon

# ¿ Jul 28, 2016 12:16

redleader: Aug 18, 2005; Engage according to operational parameters

having run into the term 'applicative functor' a couple of times recently, i figured i'd look it up.

haskell wiki posted:

An applicative functor has more structure than a functor but less than a monad.

well, that clears it up!

# ¿ Jul 29, 2016 12:12

redleader: Aug 18, 2005; Engage according to operational parameters

Mr Dog posted:

incidentally hands up everybody here who has once upon a time hosed up in C by typing "typedef enum { true, false } bool;" and then wondering with a sense of creeping dread why random poo poo keeps breaking in the strangest of ways

i don't really do c. what does this break/how does it break things?

# ¿ Aug 5, 2016 11:12

redleader: Aug 18, 2005; Engage according to operational parameters

hackbunny you are an absolute star

# ¿ Aug 18, 2016 12:50

redleader: Aug 18, 2005; Engage according to operational parameters

HoboMan posted:

so the api i am now lead dev on is secretly just a wrapper for a another api that no one even knew about

by a wrapper i mean the endpoints in it literally just call endpoints for a different api

e: i'm really at a loss for what to do about this

oh yeah, we do this. right down to the api making request to other api running on the same machine. the reason that we did such an awful, awful thing was due to time constraints and legacy code

# ¿ Aug 24, 2016 13:00

redleader: Aug 18, 2005; Engage according to operational parameters

i felt bad for the guy who had to go and write integration tests for that

i heard that he needed to use an awful lot of Thread.Sleeps

# ¿ Aug 24, 2016 13:03

redleader: Aug 18, 2005; Engage according to operational parameters

quiggy posted:

it only works with us because we're a small company. svn's branch support is so loving bad that i can't even begin to imagine it working in a setting of 10 or more programmers

uh, just develop on trunk? easy!

every time someone branches here it ranges from a small to a large mess. it's probably down to no one having much useful experience with svn (other than right click -> commit...) and our project structure being unbelievably lovely

i think svn would be fine with a better team. i don't like how slow it is when checking out a new branch, but eh

people who use svn properly: do you check out just trunk + relevant branches, or everything at once?

# ¿ Aug 29, 2016 12:52

redleader: Aug 18, 2005; Engage according to operational parameters

LeftistMuslimObama posted:

not tortoise, that's 4 drat sho

nah, tortoise is legit good

# ¿ Aug 29, 2016 12:54

redleader: Aug 18, 2005; Engage according to operational parameters

hackbunny posted:

I check out the whole project at depth "immediates" (svn co --depth=immediates), this gets me trunk, tags and branches, all empty
then I go in branches and update it, changing depth from "empty" to "immediates" (svn up --set-depth=immediates). this fills the branches directory with (empty) subdirectories for the various branches
repeat with tags if you need the list of tags
when I need a branch or tag, I set its checkout depth to "infinity" (svn up --set-depth=infinity). when I'm done with it, I set it to "empty" and only the placeholder is left

this lets me do things like, branch trunk+bump app version in trunk as a single operation, instead of two. cherry-pick merging is easier too

this prompted me to learn what the hell svn was talking about when it referred to 'depth', thanks!

guess i'm the terrible version controller

# ¿ Aug 31, 2016 11:34

redleader: Aug 18, 2005; Engage according to operational parameters

Powerful Two-Hander posted:

i have heard that there is a team at work that have written an xml import process in sql. unsurprisingly it fucks up all the time

this can probably be blamed on microsoft for giving sql server some pretty freakin good xml support. i can see the thought process too: "well, it's going to go into the database already, and it's already xml..."

for a feature that has no place in a loving database, sql server's xml facilities are astonishingly thorough and well-executed. however, i might be biased as i am intimately familiar with farting xml into and out of sql server

and at least within sql server, dynamic sql is your only option if you want to do some pivoting with data on the fly (i.e. given a set of pivot columns that are only known at runtime). we use dynamic sql (generated and executed in one stored proc) for exactly that reason, although it is (1) delicate (2) easy to gently caress up (3) a pain in the rear end to debug (4) basically black magic for the 90% of devs who are only casual to semi-professional sql users. i'd be interested to know if any other dbs do better with dynamic pivots

# ¿ Sep 7, 2016 11:50

redleader: Aug 18, 2005; Engage according to operational parameters

a few years ago, we had a guy working on a big, important, visible project. his code went though uat just fine etc etc. he deployed it to production, and immediately maxed out the cpu on the db, bringing the site down

it turns out that every single stored procedure he'd written for that project used xml for input and output - exclusively. instead of passing an id in an integer parameter, he'd pass it in wrapped in an xml chunk and parse that out in the db, then return a blob of xml (which, of course, the application loaded into a string to pass around)

so instead of

SQL code:

CREATE PROCEDURE touch_butt (@butt_id INT, @is_sensual_touch BIT)...
SELECT cheek, firmness
FROM butts
WHERE butt_id = @butt_id

he'd go

SQL code:

CREATE PROCEDURE touch_butt (@data XML)...
DECLARE @butt_id INT = @data.value('//butt_id', 'INT')
DECLARE @is_sensual_touch BIT = @data.value('//is_sensual_touch, 'BIT')
...
SELECT cheek AS '@cheek', firmness AS '@firmness'
FROM butts
WHERE butt_id = @butt_id
FOR XML PATH('data'), ROOT('result'), TYPE

i can't remember if this pointless, verbose, cpu-burning overhead on every single db call ultimately turned out to be the root cause of the maxed database cpu, but holy hell it was irritating to work with

# ¿ Sep 7, 2016 12:17

redleader: Aug 18, 2005; Engage according to operational parameters

HoboMan posted:

can someone recommend a book on SQL development? like optimizing queries, best practices, how to think about reads and writes? everything i've seen looks like it's for someone who doesn't even know what an RDBMS is. (i am working on SQL server 2014)

if you wanna huff database performance farts, check out this site which goes into pretty deep detail on db indexes. it's database-agnostic in that it covers all of the major dbs, and points out implementation quirks/weirdnesses and terminology differences. also available in book form

as sql server in particular gets your rocks off, you'll at some point need to dig into some execution plans. pick up this and read through it over a few days/weeks/months. note that execution plans are obtuse as gently caress and difficult to figure out, especially if you only need to look at them occasionally

red gate actually publish a buttload of sql server (and related) ebooks, so you could have a browse and see if anything interests you there

SET STATISTICS IO, TIME ON and execution plans are your sql server perfect troubleshooting bread and butter

special mention goes to sql sentry plan explorer, which is a much nicer and more powerful tool for reading/interpreting execution plans

general advice: watch out when writing functions in join conditions/WHERE clauses - this can easily turn a quick index seek into a full table scan, and can happen easily if you're not looking. an annoying variant on this is the 'surprise! your column data types don't match and there's now an implicit conversion running on every row in the table!'

also try to simplify your queries, by rewriting or by breaking an operation up into multiple queries using temp tables (WITH clauses and views don't count!). simpler queries are easier for the query optimizer to work on and are easier to get good statistics on, meaning the optimizer can check more potential plans with more appropriate row estimates, possibly giving a quicker plan. i recently had a statement with an OR condition that was performing a table scan. by breaking it up on the OR into two separate statements joined by a UNION, i was able to get the optimizer to do a couple of seeks on some sensible indexes - the alternative would have been to introduce a really gross, highly specific, specialized index to the base table, which i wasn't going to do because that would be stupid

i like databases :blush:

# ¿ Oct 6, 2016 11:31

redleader: Aug 18, 2005; Engage according to operational parameters

idk if you do firefighting or on call or whatever, but if you do you will wanna consider learning this stuff on the clock - it's not something you're likely to pick up easily when a client is on the phone complaining about their slow site

in this situation you'll want to know how to quickly figure out if any indexes have blown up and how to rebuild them, because indexes are like 90% of the solution to a slow db. again, maybe practice this at work sometime?

# ¿ Oct 6, 2016 11:39

redleader: Aug 18, 2005; Engage according to operational parameters

Zaxxon posted:

code:


var x = {}
var y = {}
var z = {}

x[y] = "get money smoke dust"

x[z] === x[y] //returns true

x[z] === x["[object Object]"]

are you loving serious

i hope i haven't accidentally written code using objects as keys because holy lol this exactly what i would not expect

# ¿ Oct 8, 2016 06:00

redleader: Aug 18, 2005; Engage according to operational parameters

the "p" in "plang" stands for "production quality"

# ¿ Oct 8, 2016 06:01

redleader: Aug 18, 2005; Engage according to operational parameters

one of the posters in the gray forum c# thread is on the core language team and regularly chimes in on language design stuff and async things which is p cool

# ¿ Oct 8, 2016 06:10

redleader: Aug 18, 2005; Engage according to operational parameters

Wheany posted:

exactly.

people who don't know the language and don't want to learn it copy-pasting poo poo together until it seems to work. i don't think that is acceptable in any other language.

uh, i have some bad news for you

# ¿ Oct 8, 2016 07:58

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 00:34

redleader: Aug 18, 2005; Engage according to operational parameters

Arcsech posted:

javascript as an ecosystem is a garbage fire of which we have never seen the like. this includes the browsers

christ yes. i can deal with the language, but the absolutely batshit ecosystem has become a parody of itself

# ¿ Oct 8, 2016 11:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›7 »