Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ManlyWeevil posted:

The full paste is too long (~200 lines) but I was going through my groupmate's contribution to our senior project, and have been constantly banging my head on the desk reading it.
code:
Byte[] latitude = new Byte[8];

(snip)

latitude[0] = pack[4 + (32 * i)];
latitude[1] = pack[5 + (32 * i)];
latitude[2] = pack[6 + (32 * i)];
latitude[3] = pack[7 + (32 * i)];
latitude[4] = pack[8 + (32 * i)];
latitude[5] = pack[9 + (32 * i)];
latitude[6] = pack[10 + (32 * i)];
latitude[7] = pack[11 + (32 * i)];

(snip for 4 other variables)

lat = BitConverter.ToDouble(latitude, 0);
These blocks occur twice in a switch statement from adjacent cases where its identical. The full paste is: http://pastebin.com/ArbTafTP

For added fun: the files themselves are duplicated completely for two different projects in the solution. Or rather, they should be the same files, but comparing diffs seems to imply that one was updated when the other wasn't. I suppose its almost not fair mocking students, but the person who wrote this is a CS senior.

I looked at it and yup, there's code that messes with the GUI in that method too. Mixing presentation layer and business layer should be an automatic D in these programs.

# ? May 6, 2012 15:25

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 22:24

MononcQc: May 29, 2007

Zombywuf posted:

1) Block ads, problem solved
2) I'm saying you shouldn't use CGI in that very specific (evil) case.

That's fine, although I'll keep the 'evil' as an option there, not a mandatory attribute of the business

# ? May 6, 2012 15:29

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

pigdog posted:

This. CGI performance is fine I guess if 1) you write your web apps in C and 2) they don't actually do anything. The difference in overhead between opening and reusing (or pooling) database connections is particularly obvious.

The whole point of my post is that CGI is *not* fine if you're writing your web app in C. It cripples your site's performance.

If you've written your app in Python or Ruby or Java, yeah, fine, go ahead, use CGI; nobody will notice an extra few milliseconds if it's already taking 300ms+ to return a page.

Zombywuf posted:

Thus demonstrating that the only reason to not use CGI is if you are on the side of evil.

Or if your goal is to serve web pages, quickly, and don't want your users waiting around while some dogshit-slow virtual machine churns its way through a hundred indirect function pointers.

Zombywuf posted:

Then it's probably best not to enter the CGI handler at all. Most web apps could most benefit from better design that revolved around cache performance.

What does this even mean? How could a web app's design "revolve around cache performance"? Are you on drugs?

# ? May 6, 2012 16:51

Zombywuf: Mar 29, 2008

Janin posted:

What does this even mean? How could a web app's design "revolve around cache performance"? Are you on drugs?

I...

just...

I have no words.

Please do me a favour and never ever write anything that I might have to maintain, scrape, crawl or have any contact with in any way. If you think caching is not the absolute most important thing in making HTTP applications fast then you are on a par with people who think the web works by the medium of magic pixies.

Even the use case MononcQc is talking about relies heavily on caching to make it snappy. The caching infrastructure of the web makes it irrelevant though so long as basic guidelines to make the served ads cache friendly. I mean, really, what the hell do you think Akamai do?

# ? May 6, 2012 17:53

tef: May 30, 2004; -> some l-system crap ->

Zombywuf posted:

1) Block ads, problem solved
2) I'm saying you shouldn't use CGI in that very specific (evil) case.

Hey this is the coding horrors thread not the judgemental programmers thread.

# ? May 6, 2012 17:57

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zombywuf posted:

Even the use case MononcQc is talking about relies heavily on caching to make it snappy. The caching infrastructure of the web makes it irrelevant though so long as basic guidelines to make the served ads cache friendly. I mean, really, what the hell do you think Akamai do?

Please tell me how you would cache the SA forums properly, assuming we're serving logged in users.

# ? May 6, 2012 17:59

pigdog: Apr 23, 2004; by Smythe

Zombywuf posted:

I...

just...

I have no words.

Please do me a favour and never ever write anything that I might have to maintain, scrape, crawl or have any contact with in any way.

I'm sure you're trolling, but that's not very funny. And if you're not, then the last pages are just :psyduck:

Zombywuf posted:

CGI is a perfectly good way of running code.

It's a lovely and useless way of running code that only exists because very long time ago it was the only way. All it has going for it is safety in memory management (barring bugs in the code itself) and ease of deployment, while for anything you'd want a website of 2010s to do it's a slow pain in the rear end. Interfacing with databases, keeping session information, the works.

# ? May 6, 2012 18:13

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Zombywuf posted:

Even the use case MononcQc is talking about relies heavily on caching to make it snappy. The caching infrastructure of the web makes it irrelevant though so long as basic guidelines to make the served ads cache friendly. I mean, really, what the hell do you think Akamai do?

How do you think Akamai's http servers work? You realise that they aren't running them with CGI, right?

# ? May 6, 2012 18:18

Novo: May 13, 2003; ^{Stercorem pro cerebro habes}; Soiled Meat

Zombywuf posted:

I...

just...

I have no words.

Please do me a favour and never ever write anything that I might have to maintain, scrape, crawl or have any contact with in any way. If you think caching is not the absolute most important thing in making HTTP applications fast

The ironing here is just delicious.

# ? May 6, 2012 18:28

Zombywuf: Mar 29, 2008

Janin posted:

How do you think Akamai's http servers work? You realise that they aren't running them with CGI, right?

They're web proxies you numpty.

# ? May 6, 2012 18:30

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Zombywuf posted:

They're web proxies you numpty.

You didn't answer my question. How do you think Akamai's http servers work? Do you think they wrote them as Perl CGI scripts because "ehhhhh, a few ms here and there, whasamatter!?"

# ? May 6, 2012 18:40

Zombywuf: Mar 29, 2008

Suspicious Dish posted:

Please tell me how you would cache the SA forums properly, assuming we're serving logged in users.

The vast majority of the content displayed on any given page is exactly the same for all the users viewing it, the post content, images, headers, footers, etc... The key point to note is that these have wildly different cache lifetimes, the header for example almost never changes, individual posts rarely change (but can change), very few posts change (but they do), the data that changes the most often is which posts to display, which is a very small amount of data, both to be served and in terms of data needing to read from platters on the server.

The ideal scenario would be that each of these types of data is served up separately from distinct urls, with the rarely changing data set with caching headers to expire at some future far off date. This presents a problem for posts where changes need to be reflected immediately and not at cache expiry. You could handle this with 304s and If-Not-Modified since but that would be a helluva lot of round trips on every page load. Better to make each version of a post have a distinct url, then you're only changing bit of data is the post list. This can be served up as the page, loading all of the content in iframes (edge side includes if you're on Akamai). This way, with an application cache (mod_cache in Apache for example) and the browsers cache, almost none of the data requests will ever hit your backend. Initial loads of full pages that have not been viewed in long enough to expire from your app cache will be a bit slow, but that's a rare case.

@Janin, why would you write a web proxy as CGI? That would be madness. Use an existing implementation.

# ? May 6, 2012 18:48

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

So your ideal web app is performing dozens of requests to get different parts of the page, hosted in iframes, served by Apache of all things, and backed by loving platter drives? Are you a time traveller from 1994?

# ? May 6, 2012 18:54

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zombywuf posted:

The vast majority of the content displayed on any given page is exactly the same for all the users viewing it, the post content, images, headers, footers, etc... The key point to note is that these have wildly different cache lifetimes, the header for example almost never changes, individual posts rarely change (but can change), very few posts change (but they do), the data that changes the most often is which posts to display, which is a very small amount of data, both to be served and in terms of data needing to read from platters on the server.

Of course you'll get the wrong answer when starting out with wrong assumptions. You can disable signatures, avatars, smilies, [img] tags. You can choose to highlight the OP or not. So you can't cache the post content, because every user has a potentially different interpretation of the post content.

The real pants kicker is the best option, "Mark posts on pages I've already seen in a different color", which requires state tracking for every user. The only thing you could possibly do would be to cache different post renderings as HTML, or use one cached post rendering and use client-side scripting/CSS to hide imgs/smilies/avatars/signatures, and then generate a different class name for the wrapper <div> depending on the last viewed time vs. the latest post.

# ? May 6, 2012 18:55

Zombywuf: Mar 29, 2008

Suspicious Dish posted:

Of course you'll get the wrong answer when starting out with wrong assumptions. You can disable signatures, avatars, smilies, [img] tags. You can choose to highlight the OP or not. So you can't cache the post content, because every user has a potentially different interpretation of the post content.

That's a relatively small set of options, you're going to get a hell of a high cache hit ratio over a thousand users.

quote:

The real pants kicker is the best option, "Mark posts on pages I've already seen in a different color", which requires state tracking for every user. The only thing you could possibly do would be to cache different post renderings as HTML, or use one cached post rendering and use client-side scripting/CSS to hide imgs/smilies/avatars/signatures, and then generate a different class name for the wrapper <div> depending on the last viewed time vs. the latest post.

Two separate urls for seen and unseen, the top level page that's including the post is then the only part that needs to know whether or not a user has seen that bit of the page, and we're not caching that anyway.

EDIT: also, grats to Janin for exemplifying exactly the "lol old" stupidity I'm arguing against. Anyway, I've gotta go water my SSD tree as apparently they grow on them now.

Zombywuf fucked around with this message at 19:13 on May 6, 2012

# ? May 6, 2012 19:10

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

If your website is not on the list of top 100000 most popular websites, using cgi over in app dispatch or python over c or apache over lighttpd (or something, idk) is not going to make any significant difference to the user experience minus the occasional slashdotting (or redditing or whatever the hell you call them these days :corsair:

)

# ? May 6, 2012 19:32

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Zombywuf posted:

EDIT: also, grats to Janin for exemplifying exactly the "lol old" stupidity I'm arguing against. Anyway, I've gotta go water my SSD tree as apparently they grow on them now.

You don't even understand the positions in this argument, do you?

Serving from platter drives with Apache and CGI and so on was fine fifteen years ago, because users had different expectations about how quickly a web page should load. If it took ten seconds to get a product list or load a homepage, then that site was doing pretty good. The extra overhead of spinning platters and fork/exec and so on was minimal compared to unavoidable latencies elsewhere in the system (user's modem, user's browser).

Now, that sort of stuff is no longer acceptable. Users expect to see the page they clicked on appear "instantly", meaning in under 200ms. Unless you can afford to co-locate your frontends in multiple datacenters, network latency will take a *big* chunk out of that time.

So lets say you're not co-locating, and the user's browsing on a phone, so they have a round-trip ping of 100ms. That means that your server has only 100ms to generate and return a result before the user starts getting annoyed about how slow your site is.

100ms is pretty decent, but it's not infinite. In particular, you do *not* have time to read stuff from platters (time: 10ms per paged-out file) or fork request handlers (time: 5ms per request). To provide a good user experience, you need to be serving out of RAM, or at least SSD.

Don't go bitching about costs. You can buy a low-end server (64GB RAM, 1TB SSD) for only a few thousand. This isn't exactly Big Iron we're talking about here.

# ? May 6, 2012 19:48

Zombywuf: Mar 29, 2008

Janin posted:

So lets say you're not co-locating, and the user's browsing on a phone, so they have a round-trip ping of 100ms. That means that your server has only 100ms to generate and return a result before the user starts getting annoyed about how slow your site is.

Errrrr. How does round trip time relate to the user's expectation of speed? Also, 120ms is about the speed at which a user will notice a delay, I've rarely seen a phone receive a web page over a 3G network in under 10s, most are over 30. What matters here is data volume, not the speed data is being read from the backend.

quote:

100ms is pretty decent, but it's not infinite. In particular, you do *not* have time to read stuff from platters (time: 10ms per paged-out file) or fork request handlers (time: 5ms per request). To provide a good user experience, you need to be serving out of RAM, or at least SSD.

Most websites would kill for a 100ms response. I've seen people literally drool at that sort of prospect. We have this thing though, a way of preventing requests from hitting the data backend and serving it out of RAM, it's called caching.

Aside from that, what the hell are you doing in that other 95ms? Seriously? Factoring the user's IP address?

quote:

Don't go bitching about costs. You can buy a low-end server (64GB RAM, 1TB SSD) for only a few thousand. This isn't exactly Big Iron we're talking about here.

Well I'm glad for you that a few thousand (which will get you a lovely 1TB SSD that will die and loose all your data) is pocket change to you.

# ? May 6, 2012 19:58

Brecht: Nov 7, 2009

Zombywuf posted:

Errrrr. How does round trip time relate to the user's expectation of speed?

# ? May 6, 2012 20:24

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Zombywuf posted:

Errrrr. How does round trip time relate to the user's expectation of speed

I give up.

# ? May 6, 2012 20:35

Factor Mystic: Mar 20, 2006; Baby's First Post-Apocalyptic Fiction

Zombywuf posted:

Aside from that, what the hell are you doing in that other 95ms? Seriously? Factoring the user's IP address?

The jig is up, Zombywuf, your trolling has now become obvious

# ? May 7, 2012 00:38

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

pokeyman posted:

How does anyone justify using PHP for a new project?

What do you suggest?

# ? May 7, 2012 01:00

Zombywuf: Mar 29, 2008

Factor Mystic posted:

The jig is up, Zombywuf, your trolling has now become obvious

Good point, Chrome's developer tools show that that takes less than 1ms: http://www.secretvolcanobase.org/~zombywuf/cgi-bin/cgi

Anyway, I stand by everything I said about caching being way more important than in-process dispatch.

# ? May 7, 2012 01:01

shrughes: Oct 11, 2008; (call/cc call/cc)

Zombywuf posted:

Good point, Chrome's developer tools show that that takes less than 1ms: http://www.secretvolcanobase.org/~zombywuf/cgi-bin/cgi

Anyway, I stand by everything I said about caching being way more important than in-process dispatch.

In your world of web development. We are not talking about your world of web development. So why are you talking about your world of web development?

# ? May 7, 2012 01:06

hobbesmaster: Jan 28, 2008

Golbez posted:

What do you suggest?

node.js of course! :suicide:

# ? May 7, 2012 01:36

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

Zombiewuf has very limited intelligence and he apparently enjoys making this obvious on the forums whenever he can. Unfurling his web of idiocy does get tiresome after a while though so could we go back to posting horrors rather than watching them unfold in front of us?

# ? May 7, 2012 01:39

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Golbez posted:

What do you suggest?

If you don't mind the whitespace, Python.

If you do mind the whitespace, Ruby, just avoid the hell out of Rails until you understand the language and have braced yourself for DHH.

# ? May 7, 2012 01:48

Threep: Apr 1, 2006; It's kind of a long story.

Jonnty posted:

could we go back to posting horrors rather than watching them unfold in front of us?

Here's the easy target that isn't PHP: Flash

Teaser:

code:

(ternary (false) (integer 15) (integer 15))

# ? May 7, 2012 01:50

Zombywuf: Mar 29, 2008

And continuing the Adobe theme, OMG WTF PDF. The land where remote code execution is a feature.

# ? May 7, 2012 02:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Threep posted:

Here's the easy target that isn't PHP: Flash

Oh yes, ASC has been known to be stupid for a long time. The two major compiler engineers were fired a while ago (before Macromedia became Adobe) and they've been working on a new one ever since. Of course, there have been no fruits of that labor yet. There are tons of terrible compiler bugs.

a[(i++)] += 2 will naively be desugared to a[i++] = a[i++] + 2. If you do f()[(g())] += 2, f and g will both be called twice.

The way they implement constructors is by renaming the method's name to $construct, which is a valid variable name, leading to strange errors when you try to use it a variable name.

For a non-compiler WTF, try their random number generator. See how much dead code you can spot! Also note that this stems from a Graphics Gems entry for generating perlin noise, and has some date marks, 1994, 1997, for clarification on how old this code is. A Flash team member told me that this stemmed back to the first edition of the FutureSplash authoring environment.

# ? May 7, 2012 02:13

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Golbez posted:

What do you suggest?

To start, anything in which you are confident the developers (or you) are able to fix gaping holes within the first three tries. So: Python, Ruby, Perl, JavaScript, Erlang, Haskell, Scheme, Common Lisp, C, C++, Objective-C, Lua, sh. And that's just languages off the top of my head that I've seen web frameworks written in so I'm probably missing some.

# ? May 7, 2012 03:37

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Zombywuf posted:

And continuing the Adobe theme, OMG WTF PDF. The land where remote code execution is a feature.

OMG is loving right. I watched the whole talk and drat. Not only is Acrobat a piece of poo poo but the file format itself is insane. She had one file that was simultaneously the Windows calculator EXE that worked, a PDF that executed JavaScript, and a ZIP file.

PDF itself is ambiguous - you can replace objects by just appending new replacements on the end. But you can specify strings by length first or by end token so you can do fun stuff like have one object at the front of the file with a really long length but embed an end of stream token early, this in one mode allowing you to read the rest of the file as part of that object but when Acrobat renders it it will use the correct data. You can also embed commands that execute arbitrary programs with arbitrary arguments. Only in the most recent version does Acrobat even prompt you first - older versions just blindly execute it when the document is opened.

It gets crazier because PDF and ZIP support deflate so you can hide a malicious payload in the ZIP as a PDF exploit deflated, but then hide the PDF headers and tags in the ZIP file attribute fields so a virus scanner will decompress it and not find any PDF documents to examine. ZIP will ignore the comments/attributes and the ZIP bits are enclosed in a PDF object stream. Parts of the PDF API can only be answered by rendering the document, meaning you can hide your encrypted stuff using a key that is only available by loving rendering the PDF document, including executing other bits of code necessary to properly render it (even including OpenGL calls). You can also have different bits that only apply to Printers, yet another avenue of attack. Did I mention that PDFs can access databases via ADBC and there is no security or restrictions on it? And they can do XMLRPC/Ajax calls?

I am seriously considering never opening another PDF file.

P.S. she took a known two year old PDF exploit, performed a few trivially easy tricks, and it turns out that only two of 30+ antivirus packages identified it. None were well-known names, meaning almost very single computer with Acrobat installed is 100% vulnerable.

Simulated fucked around with this message at 06:08 on May 7, 2012

# ? May 7, 2012 06:00

Opinion Haver: Apr 9, 2007

Golbez posted:

What do you suggest?

The guy who wrote the big 'PHP sucks' post wrote a post about Python webdev that's pretty good.

Comedy option (that might not be so comedy depending on what you're building) is something like Haskell using Snap or Yesod. I actually built a small blog engine in Yesod and it's pretty neat, as long as you don't mind recompiling every time you change the non-CSS parts of the theme.

# ? May 7, 2012 06:37

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

"In every sense I can imagine, MySQL is the PHP of databases." I love it.

(from the above post about Python webdev)

# ? May 7, 2012 07:04

Chopper: Feb 13, 2006

pokeyman posted:

"In every sense I can imagine, MySQL is the PHP of databases." I love it.

(from the above post about Python webdev)

I've only ever used MySQL for projects (webdev is a hobby), please could someone explain why it is so bad? What is the 'best' database to use?

# ? May 7, 2012 10:03

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Chopper posted:

I've only ever used MySQL for projects (webdev is a hobby), please could someone explain why it is so bad? What is the 'best' database to use?

I am not sure what the current list of MySQL's awfulness is, but here is a few: there is no checking on specialized fields, they are just special names for the base primitives (except when there is, and it sets it to zero!); it uses around 4 times the full size of the whole database in RAM sitting still; it doesn't really error check anything, it just does something stupid and unwanted if there is an error; and anything related to foreign keys beyond the most basic case is horrible, and as a bonus ALTER doesn't update anything FK related.

PostgreSQL is the best option I can think of for a RDBMS off the top of my head.

# ? May 7, 2012 10:29

Goat Bastard: Oct 20, 2004

Sinestro posted:

I am not sure what the current list of MySQL's awfulness is, but here is a few: there is no checking on specialized fields, they are just special names for the base primitives (except when there is, and it sets it to zero!); it uses around 4 times the full size of the whole database in RAM sitting still; it doesn't really error check anything, it just does something stupid and unwanted if there is an error; and anything related to foreign keys beyond the most basic case is horrible, and as a bonus ALTER doesn't update anything FK related.

PostgreSQL is the best option I can think of for a RDBMS off the top of my head.

Don't forget the broken GROUP BY which silently picks a row to satisfy it instead of raising a compile error when it doesn't cover all the non-aggregate columns, leading to a depressingly large number of developers not understanding how to use aggregate functions properly.

Edit: actually I guess you covered that with the "stupid and unwanted" thing, but man I hate that so much.

# ? May 7, 2012 12:31

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Goat Bastard posted:

Don't forget the broken GROUP BY which silently picks a row to satisfy it instead of raising a compile error when it doesn't cover all the non-aggregate columns, leading to a depressingly large number of developers not understanding how to use aggregate functions properly.

Edit: actually I guess you covered that with the "stupid and unwanted" thing, but man I hate that so much.

Oh goddammit, this explains why Group By suddenly got annoying in grad school.

# ? May 7, 2012 14:04

epswing: Nov 4, 2003; Soiled Meat

Goat Bastard posted:

Don't forget the broken GROUP BY which silently picks a row to satisfy it instead of raising a compile error when it doesn't cover all the non-aggregate columns, leading to a depressingly large number of developers not understanding how to use aggregate functions properly.

Oh heyyy I noticed this years ago and wondered how they picked the row...

:v:

# ? May 7, 2012 14:27

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 22:24

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Also the broken rear end UTF8 support.

# ? May 7, 2012 14:36

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »