One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
Increasingly, I feel like a lot of my tools are dressing-up as tools, because they donโt offer any savings in time or effort, just slightly different methods to mindlessly shift information from one bucket to the next. And if one bucket has a hole in it, you get another, smaller bucket to catch anything coming out of the hole in the first bucket. This goes on and on with more holes and buckets, and before you know it, you have an intricate network of buckets whose reason for existance [sic] is to catch the information you canโt manage in the first place. You are stuck in bucket recursion, adding tools to patch the shortcomings of other tools. Those patches are how you know you have dress-up tools.
The original is specifically targeting design tools, but I think we could easily forward that to third party libs as well. We use NHibernate at work. It's neat. But I just edited seven files so that I could query a database with complicated logic like...
SELECT * FROM MonsterLocations WHERE Zip IN (10001, 10002, 10003)
So to do the same thing as that simple SQL statement, I had to create an entity based on the table, a repository to handle all the sorts of WHERE statements I might want to run, a map of the entity to the table, etc etc. I don't begrudge the tests, much, though they're really simple stuff like, "Can I inject really conventional values into each field?" which isn't where the real value of TDD is. And I'm missing a few of those overly simplistic tests right now.
Further, there "should" have been more files, as I've stopped using ViewModels by rote and instead usually return anonymous classes based on good LINQ selects. If you're passing huge ViewModels to the client and then processing them fully on the server, be careful that you haven't created too complex a client model.
It's nice to have tools, and I understand why folks enjoy ORMs. The usual argument is that if we ever change database engines, NHibernate means we're already 80% there, but was it really worth the extra hours on hours of overhead just in case we want to swap engines later? It's been years of extra code and no change so far.
Code based on NHibernate is, by definition, lightyears away from being a minimally viable product. Enough tools/libs. Keep it simple.
It's help doc time at the end of a project, boys and girls, and reading through our existing docs after adding pages for the stuff I'd just programmed I found a page where an image was described in the text as an imagemap, but it wasn't.
After the requisite Googling for an html imagemap on OS X and only finding a few pay-to-play examples, I thought, "The GIMP should do this, right?"
I should make a video tutorial that's a little more straightforward than this written one, but it's a great tool. GIMP as a whole is a little slow on OS X imo, but this tool is complete money. Make circle, quadrangles, or any multipoint poly, save your imagemap to a text file, edit points easily, and load and reedit the thing later.
Filters >>> Web >>> Imagemap. Voila.
It's essentially perfect. Thanks Maurits Rijk, and yes, I left the HTML comment in the page.
I've recently picked back up a small project I had to put down for a, um, more regular paycheck, and the owner had hired another programmer to hack on it for a while, which is fine except that he didn't involve me when he did it. No serious problem, but the new guy not only doesn't understand when to use UNIONs in his SQL, but also went hog wild with OO php. "When the only tool you have is a hammer..."
There's certainly nothing wrong with OO php. It's often The Right Thing to use, and makes MVC a lot easier to set up my old skool $myrow['fieldName'] calls in the page creation code. For me, a gvim user, I just prefer to keep it all in the recordset, ASP style. I usually separate larger pages into "engine" files/includes that create the dynamic html or at least set up variables to spit into the page, which is close to the same thing as moving the SQL into an object.
But OO php + old skool php == one f'n mess. At times, the temp dude wrote a few lines into my old code, or wacked the SQL into something that's hardly normalized, and for others he wrote brand new OO code and replaced a page or two at random. It's a real amalgam of style now, without any docs explaining the changes, and is a real b!tch to debug.
Now I could probably be convinced to go to OO if my tools were OO savvy. PHPStorm, a crossplatform Java editor for PHP, seems to do code completion based on your own objects, Visual Studio style. That's pretty kewl, and much easier than typing it all in by hand with VIm.
Why can't we have a good JTextPane extended with VIm shortcuts? Honestly, I'm more than sold on VIm (and have tried some VIm code completion extensions with varying degrees of FAIL). Not using the mouse means you're faster. Perhaps I should give PHPStorm a shot. I don't do large Java projects in VIm, for instance. I use Eclipse. I love using Visual Studio for C# and VB. At some point, I guess there will be a good enough editor to pull me away from VIm for php too...
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author
