@Sutherlands said:
Except when it doesn't. Like using a simple C# property.
Yeah, using even the simplest of C# properties in Java has HUGE performance implications.
@Sutherlands said:
Except when it doesn't. Like using a simple C# property.
@KrakenLover said:
"Cannot reproduce."
Thank gods! Eventually, they'll die out and a more adaptable species will take over.
@TheCPUWizard said:
Where did I ever say anything about a single line? or even "block of logic"?
Nowhere. It was not your message I was replying to.
It might be a shock to you, but this is not a private conversation just between the two of us.
Whatever. I just remembered why my post count on here is so low. Pretend I wasn't here.
@TheCPUWizard said:
For the type of comments you posted (inline with the code) you are 100% correct. But that is NOT the purpose fo the XML code comments being discussed here.
Urr, the post I was replying to was "+1 clarity" on a single line of comment preceding each block of logic, documenting what it does. I have yet to see any meaningful XML comments in a single line, let alone preceding every single block of logic.
Oh well, live and learn.
Hmm...
Am I the only one around here that comments WHY the code does what it does, rather than WHAT it does?
The code clearly states what it does (or so help me, I shall bring the Peer Audit Hammer), so why repeat it in a comment?
print $foo; # Print the variable $foo to standard out.
NO REALLY?!
print $foo; # Debug output to check the state of $foo TODO: Remove at end of testing
@Cat said:
TRWTF is that you're making it so hard to change the business logic as to require your customers to bring in Perl experience to code their own. Honestly, it sounds like a deployment and maintenance nightmare, which will grow exponentially with the number of customers you have.
Well, we don't sell the software. We sell a service, and use this software internally to help provide that service.
This service currently has a single customer, but this customer is so incredibly huge that it warrants an entire in-house software suite to keep them happy.
If the needs change, so will the software.
For example, the "rules parser" could be hooked up to parse the rules into some elaborate database table layout, and we could write a nice front-end to manage that.
For now, however, it's far more cost-effective to just use vim.
Also, if the software was for customer eyes, I certainly would have sacrificed the near-instant performance of "pre-compiled configuration" for actual usability by the customer.
I mean, I wouldn't dream of making it this way in any of the open source stuff, for example.
@angelchen said:
Hello friends, <spam/>
I agree, that is TRWTF!
@trwww said:
and it only takes 5 minutes to spot that bug, not 5 days.
Especially considering this little peice I found just before where the finished SQL statement is returned:
# $this->debug->out("Full SQL Statement:\n $SQL");
...which means that spotting the problem is one # away.
Oh well, in all fairness git blame blames me for that #, so I have to take some of the blame for the whole thing
@vyznev said:
Obviously, you should change the format to replace those curly brackets around the "where" part with square brackets. That'll fix it.
(That actually is at least a half-serious suggestion. It will work, provided that you change the backend to accept an arrayref instead of a hashref.)
First, this is only a very small part of it. There is A LOT more to the business rules handling than the SQL part, such as priorities listing and weighing, etc etc, which is what I referred to as "classic line-noise-style Perl".
Secondly, he had absolute and full access to change this around as he saw fit, and rearrange anything in the backend/parser to do whatever, as long as the change was either compatible with my stuff or he changed my stuff to match.
I would have accepted a change like...
if (ref($rule) eq 'ARRAY'){ # Do his stuff } elsif (ref($rule) eq 'HASH'){ # Do my stuff }@trwww said:
Well, the API that is provided is pretty limiting.... SQL::Abstract has been around for 5 years now:DBIx::Class and SQLA quality is so impressive that I have to raise an eyebrow when something else is being used.
I'm quite familiar with SQL::Abstract, Ima::DBI, Class::DBI and most of the other even remotely relevant stuff.
They are all either massive performance killers or don't support the "removed for simplicity" stuff. :-)
They are also massively beside the point. He should still have spotted why it didn't work, and if not 9 days ago, then 8.
@Medezark said:
if he KNOWS that some of the conditions won't be
He sees the code, and the produced result, and can't figure out why that code produces that result.
Until the epiphany, that is.
So, today I was going about my business, working on a fairly complex piece of reporting code that is intended to [blah blah blah irrelevant], when my dear counterpart at another site, working on a different part of the same application, has an epiphany.
First, a little piece of back-story:
Many moons ago, this other site saw what we were doing with this software we're writing, and wanted in. They wanted some customizations for their site, and of course, implementation of their own, separate business rules.
So we did what any sane developer would, and adapted the application to accept more than one set of rules so you simply give a parameter at initialization, and the application magically behaves as Site2 in stead of Site1.
In hindsight we probably should have forked, but pooling our developer resources gets things done faster and possibly even better, right?
Their resident PHP guy, that also knows Perl since he has a Bachelor's Degree in Software Engineering, got the job.
Since this "configuration" isn't likely to change any century soon, and it's trivial to recompile if it does (mod_perl2), it's hard-coded in a class/object.
Anyone familiar with Perl will know that a class, or an object, or whatever you might call it, is essentially a glorified hashref, or "a pointer to an associative array".
A business rule might look a little like this (simplified since the real stuff is classic Perl line-noise-style suff):
{ set => { databaseColumn2 => 'some value', }, where => { databaseColumn2 => ' IS NOT NULL', databaseColumn3 => ' NOT IN (1,5,6)', }, }As you no doubt figured out, this will be parsed into SQL statements that are executed in the SQL server. So far, so good.
The rules they wanted for Site2 is a lot more complex than the rules we have here ate Site1, as they deal with a whole lot more data from a whole lot more sources.
That's why I didn't really react all that much when it took a very long time for my Site2 counterpart to implement their rules, and it kept clogging up the SQL Test Server. These rules are, after all, fairly hard to implement:
Non-technical people fill in what they think they want in an Excel sheet based on column names from another Excel sheet that very loosely matches the data in the database. We programmer-types are then left to decipher what they really want, and how to make it happen.
(This is SOP in the software world, from what I gather, so one does what one can.)
His problem, for the last 8-9 days, has been that rules like this won't work:
{ set => { databaseColumn127 => 'some value', }, where => { databaseColumn2 => ' IS NOT NULL', databaseColumn2 => ' != 31', databaseColumn2 => ' != 43', databaseColumn3 => ' != "some condition" ', databaseColumn3 => ' != "some other condition" ', databaseColumn4 => ' > CURDATE() - INTERVAL 1 DAY', databaseColumn4 => ' < CURDATE()', }, }It'll change stuff when databaseColumn2 is NULL, and ignore the check for "some condition" in databaseColumn3. It will even ignore the minimum date for databaseColumn4! BUT WHY!?!
Now for my counterpart's epiphany!
Hashes have unique keys! Use the same key twice, and it'll redefine.
Morale of the story: Peer review a whole lot more than I do, and just because it compiles cleanly it doesn't have to run right.
<troll>In his defense, he is a PHP-guy, and there are no hashes in PHP. </troll>
@Medezark said:
ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.
It works very well here, but it might not work everywhere. Have they tried? SRSLY, give that program a twirl and see what it does. I love it.
@b-redeker said:
@HighlyPaidContractor said:
If possible, I always try to make friends with the end-user. You get much more useful input, and produce a better product in the end.I sincerely believe that user involvement is the main key in running an efficient and effective project. Also, typically the user you want for this is the user that can't be missed.
QFT
I've come up with a very good way to design interfaces lately, and I'd like to share.
Roughly 90% of my interface has been quickly scribbled in Balsamiq Mockups, and distributed to the users for input. They make their coments either in text or by editing the pictures in Paint (or whatever) with the same roughness as Mockups produces, so everyone understands all the way that these are just ideas and drafts, nothing definitive.
I then sit down with all the edited versions, and the feedback, and use that to make another mockup, which is then distributed for the same process over again.
This is done a couple of times, or as long as we have time for. The three times this has been done so far it has been a HUGE success!
Users feel involved in the application they're using every day ("Oooh, I got my suggestion for bigger spacing between the tabs in!") and those that don't care or don't have time can simply ignore the involvement request when it comes.
That takes care of the interface.
The "business needs" are (thankfully) pretty well defined, but still sort of abstract. I'm especially free when it comes to what kind of reports and stuff the system will produce, as they've come to trust my innovations in the past. Legacy compatibility, however, is an absolute, so I've got about a gazillion lines of legacy reporting code in my current project.
One of the users came up with a "Legacy mode" checkbox, along with a rather detailed explaination of how it'd be neat if it worked with/without that checked, so a bright head solved that for me before I even had time to mutter to myself about it.
In the end, this very tight cooperation between programmers and users is very fruitful here, and in the end we have an application we all love.
@serguey123 said:
If they don't suck there are not for me, getting sucked is the number 1 need of man and the reason for pretty much anything
OH MY GOD!
The wit! The comedy! I think I have a new hero!
@crippledsmurf said:
Was this the beginning of what is now Bugzilla?
Haha, no, not even close.
This is an in-house-only app for logistics issue tracking. The company I work for is not a household name, but the one we do tracking/followup for certainly is.
That said, I'm not comfortable telling you the client's name on here, so there is no need to ask.
@Xyro said:
To ask more directly, does your title actually mean anything?What, Mentor or Lead Developer?
"Mentor" means "Trainer that also walks around and is available to answer questions on his/her subject outside trainings, and does side-by-side monitor and one-on-one training when needed", but that didn't fit on the company standard contract's "Title" field.
Lead Developer means I get to make the decisions as far as implementation of the software goes, and I get to say when it's ready for QA.
It also means my phone rings at odd times, and that I'm the one that has to deal with all the red tape so the rest can Just Write Codetm.
Oh, and it means I get to do battle with the Dark Knights of ASP and the Beast of the PHP Wasteland to defend The Holy Ways of Larry Wall and Tim Toady.
@Xyro said:
Chewie, what does your manager think about your title?
It's not likely to be changed any time soon anyway.
@Xyro said:
Is it tied to your compensation?
The forums over at [url=http://forums.devshed.com/]Devshed[/url] hardly suck at all!
@Zecc said:
This was a good read.
@Zecc said:
Good thing you posted it to the Sidebar. I shudder to think what it would have become had Remy Porter gotten his hands on it.
I, for one, feel like I'm getting my money's worth.
@millimeep said:
(don't think there's much demand for pancake shaped organs)
Nope! Having "a big heart" is about volume, not area.
@b-redeker said:
Predicting... tits-all?
Yeah, that, or I typo'd on "tidal". I guess we'll never know, because when I happened to accidentally google "tits" I sort of got sucked in.
@DescentJS said:
how could you leave out the moon phase you fool?
It already has a complex system for tital prediction and day-of-year, which amounts to the same thing, really.
Come to think of it, I might actually have to implement day-of-lunar-year, seeing as there is a remote possibility it might be used in China. Tacking moonphase on that would be easy.
@b-redeker said:
Wow! And what did you do in that week so you didn't end up with a steaming pile of Perl? How many pages/LOC were involved? Sounds pretty impressive anyway.
Haha, please don't be impressed.
The application was three MySQL tables: users, cases and (added by me) events
User logs in (matched against users table).
User clicks "next", gets a "case" according to some very simple rules, and then logs "events".
When done, the user clicks "next" again. Rinse, repeat.
Stuff gets into the cases table by reading an uploaded CSV file.
Now that I lay it out like that, I sort of miss the simplicity of the application back then. I don't know the size in terms of LOC, but it was very simple, and it was contained in three .pm files.
(mod_perl2, btw)
These days, it's hugely more complicated, with support for everything under the sun, like auditing, reporting, reviews, two gazillion different types of cases all with different rules etc etc. The logic behind "new" alone is about 1k LOC now, with advanced priorities based on everything but the moonphase...
@hkolek said:
Only as of 5.3 but I very much doubt that's the version that was used for this app. Please clarify. http://php.net/goto
function foo () {
include(somefile);
if ($someVarIHaveNeverSeenBefore == 3)
include(someotherfile);
else
include(somethirdfile);}
Not exactly GOTO, but just as funky.
Each file would have maybe 10-12 statements, and would sometimes be used only once.
A lot of them would have more include() statements, or sometimes require(). Infinite loops were common in the more obscure places of the application.
Randomly, some would have exit statements, or conditionals on variables not set in that file.
I don't think I'm exaggerating much when I say there were about one twentieth as many files as lines, if you don't count require() and include() lines.
No error checking. Ever. Basically, it was always assumed that all went according to plan.
Back in the day I inherited an application, and was asked to "fix" it. I was a trainer/mentor at the time, and coding wasn't really in my job description, but being interrested in making the move into professional software development I jumped at the chance.
I already had a lot of experience from hobby projects, and I was fairly confident in my ability to read and understand code, and even write some pretty maintanable stuff myself.
After looking at the PHP code for a while, I decided that this unmaintanable heap of spaghetti would need to be rewritten if there was to be ANY hope of "fixing" it, and ever adding any features to it.
It was developed by a friend of the IT Manager. Said friend, who is not a software developer by trade, clearly had even less experience with code than me, and it was truly horrible.
Mind you, I said it then and I still stand by it: "This is clearly the work of someone very smart, as the logic is flawless, but there is nowhere near the experience behind it needed to build a production application."
A short list of the worst WTFs:
Generally speaking, it had a vibe of "Teach yourself PHP in 21 days" over it.
I went to my (new/temporary) boss and told him the sorry state of the project, and that it would probably need to be rewritten completely.
He said that this was absolutely out of the question, as they needed this in production, and fixed, RIGHT NOW.
I explained that as my PHP is a little ... lacking, I might have better luck "fixing it" if I "translated it into Perl", and said that would only take about a week.
I got the go-ahead on that, and starting rewriting it translating it into Perl.
Fast forward about a week, and I had a pretty good feature-equal Perl script, but I had sinned on the documentation due to time constraints.
Everyone was happy now that the poor souls using the software did not all end up with the same "case" if they clicked "Next case" within a minute of each other, and that performance was way better. It even looked better, and the users could now log more than three "events" per "case", seeing as they were saved to a separate table rather than being CaseLog1, CaseLog2 and CaseLog3 in the cases table.
Fast forward again, but this time to the present date.
The software in question is still my job, and I'm named as "Lead developer" on it. While it is documented, it's always in a constant state of adaption to business needs, so if I (or any member of the team, really) get hit by a bus we'll have a rather frustrating time picking up the peices worked on for the last week or so.
Still, we're successfully rolling out the third generation of the software across Europe, and next year it's going to be set up in one of our sites in Africa as well.
Let's just say the scope of the software has grown slightly...
So, what's the title on my contract, then? It's still "Mentor".
@dcardani said:
So he wants me to take a survey via email later (which he never sent), but then asks me how I'm going to fill it out now.
This is called a "survey prep", and I'm pretty sure it's absolutely forbidden by his employer. I work for a callcenter company, and if anyone did that here they'd be fired pretty damn quick.
The only thing more forbidden than a "survey prep" is a survey not actually filled in by the customer but a co-worker does it, or you do it yoursefl, which will get you fired upon it being discovered, no exceptions.
Why? Because oftentimes salary (or at least some part of it, call it a "bonus") is based on survey returns. The reason you never got the survey is because he didn't want you to drag his average down.
@dcardani said:
WTF? Has anyone else run into this?
Only about every single day... If I could get away with murder, I have a few candidates.
@dcardani said:
"Please keep in mind that on our scale, a 7 is like a 0."
Usually it's a "B5T2" system, where the bottom 5 are "poor" and the top 2 are "good".
That means 0-5 = "YOU SUCK!", 5-8 = "C'mon, do it right, plx" and 9-10 = "Nice jorb there, Homestar"
Of course, I have no idea how they operate, it just seems to be an unofficial trade standard for callcenters. Generally speaking, yeah, a 7 wold be enough to get you by without being yelled at, but a 6 might earn you a little slap on the wrist if you accumulate a lot of them.
Oh boy, I'm so happy have absolutely nothing to do with that crap any more. I just keep my head down, write my software and try not to get too involved in office politics.
@dhromed said:
Also, 7zip is easier to install and use than nagware winzip, and windows doesn't support creating zips, AFAIK (I might be wrong).
You are. Ever since XP you can right-click on a direc... urr.. Folder, and select Send To -> Compressed (zipped) Folder.
Still, that's beside the point. The point is target audience.
Something like 99.99% of all (potential) users out there can open standard .zip files, and you can create them just as easily, so why save the 20% if it's wasted in trying to open your file?
I'd much rather spend several minutes more downloading the file than installing every odd compression/decompression tool people might suddenly want to use.
That said, I do own a WinRAR license, and WinRAR handles pretty much everything (even .iso O.o), but I'd never distribute anything but .zip (or .tar.gz for Linux-y stuff).
Why? Because it's STANDARD, and standards are good.
[edit] Dammit, got beat to it while I ranted :-P
@renalexam said:
I already pay for 250gb data transfer/month (Oh, I mean "unlimited").
Holy macron, 250GB/month is "unlimited"?! I got a "could you pretty please not rape us" letter from my ISP when I passed 5TB throughput one month, and even then they included a "We realize you do pay for the right to use this bandwidth" and phrased it as a pollite request!
Move to Sweden, where the girls are pretty, the bandwidth is cheap, and wookies tear the ears of your gundark!
@renalexam said:
Charging for individual e-mails is one of the most retarded ideas I've had to read about today.
What's fun about it is that it's nowhere near a new idea. This comes up from time to time in most spam discussions, but die out as soon as someone points their finger at it and brings up the enformcement issue, except when the person suggesting it doesn't have a clue how the internet works and suggests the US government just puts a tax on it, since they own the internet.
Yes, well, it sort of makes sense.
I mean, none of us really believe that sending e-mail does not use electricity...
Stil, there is no way in hell two 12KB e-mails use measurably more than one 24KB e-mail.
Also, having my monitor on for my entire working day is probably less "green", so I should turn it off during breaks! That way I can send all the e-mail I want and "Al Gore" it off by turning off the monitor.
I also have to use Lotus Notes all day, so if I turn off the monitor while waiting for Notes to get done with whatever it's doing behind the scenes for about a half-hour of I/O lock per day I can offset even more e-mails!
I'm starting to think I can make a bundle on inventing head-tracking device that turns off your monitor when you're not looking at it, and sell it as an "energy saver".
@blakeyrat said:
Time to take the mood stabilizers...
...or I got over it really quickly because I have you nice folks to vent to.
@svm_invictvs said:
Why bother getting upset over it? Fix it, move on, and stop being petty. You probably spent twice the amount of time complaining as it took you to fix the issue.
Well, that's what I thought, too. I just wondered what other people think about this sort of thing, hence the thread.
I would probably have already forgotten about the thread if it wasn't for the friendly e-mails from thedailywtf.com ^__^
@toth said:
I'm not sure I understand the scenario. Do you mean something like this?
foreach($value in $collection) {
$dateReader = new DateReader($value)
$dateWriter = new DateWriter($dateReader.readDate())
}
Because I don't see what's wrong with that. I'm sure I'm missing something...
More like...
foreach my $element (@vast_array){
my $dateReader = new DateReader(Foo => 'Bar',Boink => 'Oif');
my $dateWriter = new DateWriter(Foo => 'Oif',Boink => 'Bar');
$dateReader->read($element->[219]);
$element->[219] = $dateWriter->write($dateReader);
}
Which I changed to ...
my $dateReader = new DateReader(Foo => 'Bar',Boink => 'Oif');
my $dateWriter = new DateWriter(Foo => 'Oif',Boink => 'Bar');
foreach my $element (@vast_array){
$dateReader->read($element->[219]);
$element->[219] = $dateWriter->write($dateReader);
}
Don't get me started on the "two objects?!" thing. I don't have time to write that rant this century. It basically comes down to $dateWriter reading $dateReader's UNIX time representation.
[edit] I can't believe I'm debugging non-existant code. Yes, I'm a pedant.
Yep, this is a workaround for a problem cought at the very end of QA tests, where the data would very rarely have a different date format.
Rather than testing every line for this deviation, we pull everything through this pair of "conform to this format, dammit" objects.
Just did some benchmarking on our set of test-data, and creating/destroying the object seems to be optimized away by the enterpreter anyway.
Just some more irrational raging from me, then ^__^;
Well, of course there are other things to do than code, but he was specifically assigned an already designed and thought-through part of the application, to implement a specific fix/workaround (the 12 lines), and it took all week.
**shrug**
Edit:
To be fair, he only works three days of the week, so make that "..., and it took three whole days".
All this, of course, is not the point. Am I being an ass for nitpicking about where/when objects are being constructed?
Yeah, I know this is nitpicking, and all that, but it still pushes my buttons.
My coworker produced a staggering 12 lines of code last week, and 10 of them was initializing a pair of date format conversion objects.
The objective was to go through about 20.000 items of Excel-imported data, read one of the columns, convert it to a sane date format, and pass the data on.
A whole lot of other stuff is going on in this "filter" at the same time, but that was his part of it.
What he did was pretty good code, except the creation of said object pair (one for reading the date as-is, one for returning a sane format) was created inside the foreach loop.
I'm not sure what the object creation and destruction overheads in Perl are, but if they are more than zero this is silly, so I moved the creation outside the loop, left a friendly little comment about it and committed back in with a vague "Slight object creation optimization" commit message.
Am I being an ass for RAGEing over this kind of silly little stuff?
Is my RAGE better focused on team-members producing 12 lines of code in a week?
Not long ago I got an e-mail from our IT Admin stating that the e-mail server is now back and fully functional again.
Of course, the timestamp of when it was sent, and when I actually got it, was about 3 hours apart, and during that time I had gotten no e-mail what so ever.
Turns out he sent that mail as the first thing he did when the server went belly up, so it was pretty much the first mail everyone got when it was back.
I lol'd.