| « Space: The Final NOP | Confessions: Hacker Proof Boolean » |
"If I told you that I work for a primarily Microsoft coding shop that hires on non-Microsoft developers, you'd think that it would be an unending, seething mass of WTF code," writes Hank, "but really, it isn't."
"The new hires that the company brings on are usually eager to learn and their diverse backgrounds and experiences make our team more well-rounded overall."
"Usually."
"From a technical perspective, Paul was alright. He came from a 'Jack of All Trades' background with a heavy lean toward Java and Oracle technologies, but that didn't make him stand out among his peers. I cut my post-college teeth on a J2EE system before jumping ship to my current employer."
"What set him apart from everybody else though was his attitude. Basically, if something wasn't perfect, it was a disaster. Also, he failed to mention his anti-Microsoft tendencies."
"Case in point: After he finally 'gave up' and left the company, I was given the task to review his most recent check-ins and the one below is representative of his final contributions, edited to make more safe for work."
private void GetBulkUploadExcelData(string sourceFileName) { using (var cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + sourceFileName + ";Extended Properties=\"Excel 8.0;IMEX=1\"")) { cn.Open(); var XLInfo = cn.GetSchema("Tables"); var SheetName = XLInfo.Rows[0]["TABLE_NAME"].ToString(); //Q:Why am I replacing the '$' with nothing, only to put it right back on? //A:Excel is full of FAIL. It is a demonic joke foisted on programmers that are forced to try to // pull data out of it. The writers of Excel are demons from the 7th circle of Hell, and they // subsist on rage, dead puppies, and the tears of orphans. // Proof: Excel 2003, when querying the schema to get the worksheet name, leaves off the '$' // from the end of the name, forcing you to stick it back on there. Well, it appears that files // created by 2007 and saved as "97-2003 .xls" will NOT have the damn '$' removed. So, we are all // forced to remove the '$' ourselves, and then put it back, because we are never sure if it's // going to be there or not. // One could also draw conclusions about Microsoft changing it's devilry (Excel) so that programmers // are forced to go through and remove all the '$'s and replace them with their own '$'s. using (var cmd = cn.CreateCommand()) { // 2012-01-03 PBC: Added replace apostrophe with nothing. For some // reason files saved from CSV into XLS format are adding an // appostrophe between the end of the sheet name and the $ // in the TABLE_NAME field, but this is not the name // that can be used. cmd.CommandText = "select * from [" + SheetName.Replace("'", "").Replace("$", "") + "$]"; using (var dr = cmd.ExecuteReader()) { bulk_lines_data.Load(dr); } } cn.Close(); File.Delete(sourceFileName); } }
Re: Not Good Enough for Paul
2012-10-26 19:19
•
by
gnasher729
(unregistered)
|
|
When the Macintosh 2 was released, it had a 68020 processor with a maths coprocessor. To make Excel fast, Microsoft called an OS function that returned which processor and which maths coprocessor your computer had. Then they checked that your computer had a 68020 processor, and if it had one, they used the faster coprocessor. Great, Excel ran faster.
One year forward, Apple released an improved Mac with a better 68030 processor. Guess what: Micosoft checked whether you had a 68020. A 68030 is not a 68020. Excel ran slow because it didn't use the maths coprocessor. Microsoft changed their code to check for "68020 or higher". Two years later, Apple released a cheaper model that had a 68040 without maths coprocessor. Microsoft checked for "68020 or higher". 68040 is higher than 68020, so they used the maths coprocessor. Which wasn't there. Excel crashed. And all the time, the OS function they called returned the processor version _and_ the maths coprocessor version. |
| « Space: The Final NOP | Confessions: Hacker Proof Boolean » |