|
Bhaal posted:You laugh, but I once had to do a data import for a client where their previous "database" was a collection of enormous excel spreadsheets. Spotty consistency, non-normalized, etc, but in particular they had several date fields and it was painfully obvious that the dates had been hand-entered over time so the format differed all over the place. The instant I read this the first thing my mind jumped to is "How many ways can someone misspell "Wednesday" and "February", I wonder?" That said, yes, I've come across many and many-a varchar(255)-filled database in my time. I'm surprised I haven't seen it used as a primary key field yet.
|
#
?
Oct 15, 2011 01:16
|
|
|
|
| # ? Jun 6, 2024 03:12 |
|
|
zokie posted:Just say no? Yeah, I don't get that say in anything. The company that contracts us lives off of mangled excel sheets and piss poor grammar, so I can only imagine the people they have working on their other website.
|
|
#
?
Oct 15, 2011 02:19
|
|
|
OriginalPseudonym posted:The instant I read this the first thing my mind jumped to is "How many ways can someone misspell "Wednesday" and "February", I wonder?" I enjoy the varchar date fields people use, and then discovering the things people consider dates. Like February 31st.
|
|
#
?
Oct 15, 2011 02:21
|
|
|
PhonyMcRingRing posted:I enjoy the varchar date fields people use, and then discovering the things people consider dates. Like February 31st. There was a secretary at my job that happened to be fond of "Today", "Yesterday", and "Last Thursday" when doing certain report types. And because I was brought in when there was a "coverage hole" (Last guy in my position quit, software for doing these reports were broken between then and when I was hired), she was doing this for something like 4 months worth of input. I can't make this stuff up.
|
|
#
?
Oct 15, 2011 02:24
|
|
|
tef posted:edited to add: if anything I know I'm not that terrible a coder any more because after being exposed to so much tragedy, I can't bring myself to inflict such damage upon others Only you can prevent poo poo code.
|
|
#
?
Oct 15, 2011 08:53
|
|
|
I inherited a medium sized web app that internal and outside 3rd party folks login to do daily work. There was a link that assigned someone for a unit of work and sent an email. Problem was, there is no visual feedback that clicking the link did anything until the page came back due to that lame asp.net update panels, so the people would click the link a dozen times, and the assigned person would get 6 assigned emails and 6 unassigned. Not terribly difficult to fix. The fun part though, came during QA review. The tester reported that sometimes when he attempted to login to an admin account, but forget the password, so switched to his normal login, and noticed that it said "Welcome <admin name>" in the corner. 20 minutes later I had the answer! The login process: 1. Get the name and password from the form 2. If the "logged in user" bucket is empty, Query the login table and retrieve the associated account based on the given user name, and stash it in the. If it has anything, do nothing 3. Query the login table, and verify the username/password matches a record 4. Repeat step 2 5. Redirect to main work page So yeah. Anyone could login as anyone else with just the login name, and any other working login. The only time in my life I've literally had that "blood runs cold" type feeling people talk about. It also uses the aspnet logins with salted/hashed passwords........ and the entire company uses the exact same password. Edit - That reminds me. A year ago, same place different web app, I discovered that the only thing the login page did was add a ?sid=<userid> to all query strings, and the entire "security" layer of the app was to check for the existence of this querystring value. It didn't even check to see if it was a valid id, so anyone could bypass the login and go anywhere in the application just by adding ?sid=123 to the end. This was a forward facing LOB application. Atimo fucked around with this message at 21:07 on Oct 15, 2011 |
|
#
?
Oct 15, 2011 21:03
|
|
|
I've since moved onto another job and with it another hulking mess of code. It's PHP again, but this time there's more fun: - No version control (this is a given) - Development environment is on the same server as production - Some bizarre resource monitor that randomly restarts Apache for going over a "resource limit" (other monitoring tools reveal nothing of note) - 4 different sections of a large product that were developed independently by 3-4 people - Database "structure" consisting of legacy field names (e.g. "phone", which contains an e-mail address) - Said database structure has no consistent field names ("userid", "user_id", "id", "user", etc) - Use of CSV in fields instead of proper relations - Random mishmash of MyISAM and InnoDB - No proper code storage; files are more or less completely independent thanks to the wonders of copy and paste - So many scope changes, gear shifts, and other project mismanagement excellence that it's hard to tell what you can even edit without breaking something else entirely  The only positive thing about this mess is that they're at least a bit more receptive to actually fixing the mess... The problem is that they won't stop adding new "features" to get to a stable, releasable point so that we can move on to making it less of a hairball. Oh, and you can log in with ' OR 1 --. 
|
|
#
?
Oct 16, 2011 07:43
|
|
|
Zamujasa posted:The only positive thing about this mess is that they're at least a bit more receptive to actually fixing the mess... The problem is that they won't stop adding new "features" to get to a stable, releasable point so that we can move on to making it less of a hairball. Get used to that. I have yet to run into an organisation that's keen to fix "working" code. Even after extensive security audits and whatnot. "Just patch it" seems to be the regular attitude, until it bites them in the arse. Which it rarely does.
|
|
#
?
Oct 16, 2011 14:54
|
|
|
I just found out that the project I'm working on is contractually obligated to have 100% unit test coverage.
|
|
#
?
Oct 16, 2011 16:53
|
|
|
Do they specify a level of granularity? Public methods (easy and a good idea), Lines (arbitrary), Code paths (gently caress)?
|
|
#
?
Oct 16, 2011 17:08
|
|
|
Even if it's "a test for each public method" it's still stupid to have it as part of contractual obligation because you get things like:code:
|
|
#
?
Oct 16, 2011 17:47
|
|
|
Internet Janitor posted:Do they specify a level of granularity? Public methods (easy and a good idea), Lines (arbitrary), Code paths (gently caress)? If you break up your methods into small logical pieces, it's normally not _that_ hard to test all the code paths for each small piece. I mean that's basically unit testing. If you have to have 100% code coverage on every code path that the app could possibly take then I don't know what the gently caress.
|
|
#
?
Oct 16, 2011 21:22
|
|
|
geonetix posted:Get used to that. I have yet to run into an organisation that's keen to fix "working" code. Even after extensive security audits and whatnot. "Just patch it" seems to be the regular attitude, until it bites them in the arse. Which it rarely does. Yeah, I know. I'm trying not to get my hopes up, but given the kind of service this application will eventually provide, patch-patch-patch isn't something that can really be done and still have it run fine.
|
|
#
?
Oct 16, 2011 22:02
|
|
|
Steampunk Hitler posted:If you break up your methods into small logical pieces, it's normally not _that_ hard to test all the code paths for each small piece. I mean that's basically unit testing. If you have to have 100% code coverage on every code path that the app could possibly take then I don't know what the gently caress. SQLite claims to have 100% branch coverage. 
|
|
#
?
Oct 16, 2011 22:47
|
|
|
And it only took them 91 million lines of code!
|
|
#
?
Oct 16, 2011 23:49
|
|
|
Meanwhile, RIM (at least, according to a friend who works there) doesn't have test code at all, at least for BBOS.  Instead, they have ~2000 QA workers tasked with testing each new build by manually going down a checklist and interacting with the blackberry. They estimate this gives them about 30% code coverage. Granted, "my friend who works at RIM" isn't exactly a citable source, but given what an incredible shitheap Blackberry Java is, I can believe it.
|
|
#
?
Oct 17, 2011 02:10
|
|
|
ToxicFrog posted:Meanwhile, RIM (at least, according to a friend who works there) doesn't have test code at all, at least for BBOS. That explains a lot. Not so much the lack of tests as the mindset that thinks they're unnecessary.
|
|
#
?
Oct 17, 2011 05:16
|
|
|
ToxicFrog posted:Granted, "my friend who works at RIM" isn't exactly a citable source, but given what an incredible shitheap Blackberry Java is, I can believe it. quote:Using static variables for Strings
|
|
#
?
Oct 17, 2011 05:47
|
|
|
Bhaal posted:I don't do consulting anymore but "Data imports are trivial and quick" depends entirely on the circumstances and while they often can be trivial and quick, anyone who insists they always are is either trying to sell you something or is just naive. If I started doing consulting again I'd steer clear of firms so I could have the ability to either just say "no" to those companies whose IT department needs to be dragged kicking and screaming into the 21st century. Or at the least I can give them the real quote up front instead of the optimistic sale-closer quote that is often pitched by those who aren't actually doing the work.
|
|
#
?
Oct 17, 2011 11:35
|
|
|
Aleksei Vasiliev posted:Reminder: http://docs.blackberry.com/en/developers/deliverables/9095/BP_Writing_efficient_code_446999_11.jsp Why Sun ever let RIM call that shitheap VM "Java" is beyond me.
|
|
#
?
Oct 17, 2011 14:16
|
|
|
Primpod posted:Our main product has a large CAD component. We have had to import floor plans of supermarkets mocked up in Excel. This is apparently surprisingly common in retail. how. what the gently caress.
|
|
#
?
Oct 17, 2011 17:27
|
|
|
Well you see Excel has a grid and our aisles are rectangular and I already know how to use Excel so
|
|
#
?
Oct 17, 2011 17:31
|
|
|
Internet Janitor posted:Well you see Excel has a grid and our aisles are rectangular and I already know how to use Excel so Ahaha please tell me they change the width and height of cells so as to reflect the dimensions of the aisles. And the cell background colours to reflect whether a cell represents floor space or shelving. I have a friend who works with AutoCAD, I bet she will get a kick out of this anecdote.
|
|
#
?
Oct 17, 2011 18:02
|
|
|
People use Excel for everything because no-one tells them not to. Eventually you reach a limit whereupon even the suggestion of using a purpose build tool for the job marks you out as a trouble maker who should probably be fired.
|
|
#
?
Oct 17, 2011 18:04
|
|
|
code:
|
|
#
?
Oct 17, 2011 18:08
|
|
|
Don't forget the endless potential if you cells. Also pivot tables.
|
|
#
?
Oct 17, 2011 18:17
|
|
|
Just keep in mind that excel spreadsheets are like asbestos: just leave them alone and let them die peacefully, and nobody has to get hurt. The last thing you ever want to do is become in charge of writing an application to replace a bunch of BELOVED SPREADSHEETS. Bonus misery if the people using them are barely computer literate except for their 20 years of experience working with said spreadsheets.
|
|
#
?
Oct 17, 2011 18:45
|
|
|
SlightlyMadman posted:Just keep in mind that excel spreadsheets are like asbestos: just leave them alone and let them die peacefully, and nobody has to get hurt. The last thing you ever want to do is become in charge of writing an application to replace a bunch of BELOVED SPREADSHEETS. Bonus misery if the people using them are barely computer literate except for their 20 years of experience working with said spreadsheets. Yep. Used to work in a school district, the number of things that were done entirely with excel and "this macro that my nephew put together, he's in school for CS and he's really good at this stuff" was surpassed only by the "application" that the Athletics department had, which was some unholy merging of Excel and Filemaker Pro v7.
|
|
#
?
Oct 17, 2011 19:11
|
|
|
Aleksei Vasiliev posted:Reminder: http://docs.blackberry.com/en/developers/deliverables/9095/BP_Writing_efficient_code_446999_11.jsp Do they run BES off of this, uh, thing they built? That would also explain a lot. TRex EaterofCars posted:Why Sun ever let RIM call that shitheap VM "Java" is beyond me. If Sun sued them, they would have risked associating it with the legit VMs, thus sullying them all.
|
|
#
?
Oct 17, 2011 19:35
|
|
|
quote:If the order in which you iterate through items is not important, you can iterate backward to avoid the extra local variable on the stack and to make the comparison faster. if this "optimization" actually matters then god help all blackberry developers
|
|
#
?
Oct 17, 2011 19:42
|
|
|
Uuuhhhhgggggggg excel. One of out clients at my last workplace spent about $200k-$300k on getting us to build them a massive system to take over management of their business (so they weren't running out of excel spreadsheets). After about 2 years of working on it and fighting with them over features which they kept changing their minds about, we eventually sent it live. They used it for a whole two months before they hired someone new who took one look at it, and made her own version in excel. Of course it had none of the accountability, automation, or any accessibility of the system we had built, but she knew excel. In a month, the system we had built was almost dormant again because everyone in the office decided they liked excel. 2 years of custom-building an application to meet their business needs and processes exactly, and it's all undone because a new hire preferred excel to learning the system. The real kicker was when they started sending us excel spreadsheets so that we could put in the "difficult formulas" that would actually track everything the system we built we already track.
|
|
#
?
Oct 17, 2011 19:48
|
|
|
Yeah, that's the problem in a nutshell. I've been in two situations so far in my career that were similar to that. I used to blame the users for being total idiots who irrationally preferred a piss-poor solution just because it was more accessible, but in retrospect it was all my fault. The golden rule I go by now is that if I can't replace an existing solution with one they'll find easier to use then it should just be left alone. Sometimes the best solution actually is excel, if it's what everyone there prefers and knows how to use. Eventually enough people will retire or get fired and somebody with a clue will be hired who has the clout and intelligence to coordinate a replacement, but until then there's nothing you can do as a mere developer. If you make them use a new system, they will hate it and intentionally sabotage it every step of the way.
|
|
#
?
Oct 17, 2011 20:10
|
|
|
SlightlyMadman posted:The golden rule I go by now is that if I can't replace an existing solution with one they'll find easier to use then it should just be left alone. The trick is to find a pain point they don't even know exists and fix that. With most Excel based solutions this is version control and merging. Make the joy of never having "User X has opened this file for editing" very apparent to them.
|
|
#
?
Oct 17, 2011 21:01
|
|
|
Zombywuf posted:The trick is to find a pain point they don't even know exists and fix that. With most Excel based solutions this is version control and merging. Make the joy of never having "User X has opened this file for editing" very apparent to them. I have no idea what you're talking about. We've always saved our spreadsheets in folders named "Week of Month nth", in the format "Report-username-date-time", and we've never run into that issue! 
|
|
#
?
Oct 17, 2011 21:21
|
|
|
It's pretty tricky because often a business will have a few clever ones who fix those problems for excel on their own. A Gatekeeper role who aggregates everyone's changes, a scheduled time (end of month, etc) for when the Master Spreadsheet Updating ritual takes place, version control via "save as..." => "filename_<date>.xls", etc. And those informal systems built around it become part of their daily business operations and thus are associated as being vital to their operations. That turns it into an uphill battle when you try to introduce a new system that seemingly has none of these vital constraints in place. To them it's gonna feel like you're advocating they trade in their sensible family car for a flashy new rocket sled with no seatbelts. And that's fine and all, but I just hate how you can't easily itemize an allotment for "habit-break and reeducate client to accept the changes they came to me for in the first place" on the SOW. It's either that or do exactly as they say without input on your part and leave them with an even larger frankenstein horror system, which to me is "consulting without the consulting" and in addition to leaving you with that unclean feeling, it also will work against you in the long run. Bhaal fucked around with this message at 21:31 on Oct 17, 2011 |
|
#
?
Oct 17, 2011 21:21
|
|
|
One of my coworkers told me a story about a customer he worked with who used Excel as a mental model for understanding the world. My coworker was in charge of managing a database that was used as a source for a series of reports which ultimately came in the form of Excel spreadsheets. The customer insisted that there be a 1:1 correspondence between tables in the database and the resulting spreadsheets. Column names in the database had to match the column headings in the spreadsheet. Change the capitalization of something in the report? Change the database table. Joins? "You don't use joins in the industry." In one infamous case, a report had to display rows of data as columns in the spreadsheet. Naturally, this meant it had to look that way in the database- every time an entry was added a new column would be added to the table.
|
|
#
?
Oct 17, 2011 21:29
|
|
|
Internet Janitor posted:"You don't use joins in the industry." This thread seems to be proving that 
|
|
#
?
Oct 17, 2011 21:34
|
|
|
Found this in the backend for our CMS:php:<?
$current_event_id = "";
if(file_exists("../site/config/config.txt")){
$config_file_lines = file("config/config.txt");
foreach( $config_file_lines as $config_file_line ){
if( trim($config_file_line) != "" ){
$current_event_id = trim($config_file_line);
}
}
}?>This was written by the dudes who manage my work's servers. Those same guys also wouldn't give me the source code to something they wrote (just so I figure out which objects it was referencing and replicate easily) because they didn't want me stealing their code. And the way these files our laid out that bit of code actually gets called like 4 times per page. And then there's this gem on the same file as above (this is the way they had it formatted as well): php:<?
if( $row['field_options'] != "" ){
$field_item['field_options'] = array();
$field_item['field_options'] = explode("|", trim($row['field_options']));
}?>
Optimus Prime Ribs fucked around with this message at 22:37 on Oct 17, 2011 |
|
#
?
Oct 17, 2011 22:33
|
|
|
Since they neglected to put a break in that loop, just add 1,000,000 blank lines to the end of that config file. The site will mysteriously slow down and you can blame it on lovely hosting.
|
|
#
?
Oct 17, 2011 22:36
|
|
|
|
| # ? Jun 6, 2024 03:12 |
|
|
SlightlyMadman posted:Since they neglected to put a break in that loop, just add 1,000,000 blank lines to the end of that config file. The site will mysteriously slow down and you can blame it on lovely hosting. I would say "Use \r so that it's non-obvious (depending on their text editor) that there's newlines", but it doesn't appear that PHP recognizes those as newlines unless it's explicitly enabled. Oh well.
|
|
#
?
Oct 17, 2011 23:07
|
|