Comments on: The Code That Was Not There and the Badly Fitting Suit http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit Tue, 20 Jul 2010 09:51:44 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: cowbert http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit/comment-page-1#comment-1944 cowbert Mon, 26 Nov 2007 19:46:09 +0000 http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit#comment-1944 First of all, with OO these days, you are never necessarily going to really be able to solve all of your "inefficiencies". The "newfangled" OODBs and ORMs like Zope and ActiveRecord, respectively, will just tell you to throw more hardware at the problem (if there was a problem). But is this really a Bad Thing(tm)? In most cases, people do want the logical schema to be abstracted away by some sort of flexible framework. The expectation is that the end-user *shouldn't* have to know anything about database organization to be able to pick out the data they want to see or analyze, hence the development of the ability to run ad-hoc queries which can be built around metadata-driven interfaces. In essence, worrying about the "underlying representation" ought to be obselete (or heading in that direction). This might even turn out to ultimately be a case of "premature optimization". In terms of automation, the logical extension of Model-Driven Architecture would be autogenerated boilerplate from UML structure and state views. You want the ability to have a tool like Visio able to generate your class definitions straight after you've designed it by drag-and-drop. First of all, with OO these days, you are never necessarily going to really be able to solve all of your “inefficiencies”. The “newfangled” OODBs and ORMs like Zope and ActiveRecord, respectively, will just tell you to throw more hardware at the problem (if there was a problem). But is this really a Bad Thing(tm)?

In most cases, people do want the logical schema to be abstracted away by some sort of flexible framework. The expectation is that the end-user *shouldn’t* have to know anything about database organization to be able to pick out the data they want to see or analyze, hence the development of the ability to run ad-hoc queries which can be built around metadata-driven interfaces.

In essence, worrying about the “underlying representation” ought to be obselete (or heading in that direction). This might even turn out to ultimately be a case of “premature optimization”.

In terms of automation, the logical extension of Model-Driven Architecture would be autogenerated boilerplate from UML structure and state views. You want the ability to have a tool like Visio able to generate your class definitions straight after you’ve designed it by drag-and-drop.

]]> By: gooli http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit/comment-page-1#comment-1906 gooli Sat, 24 Nov 2007 19:27:23 +0000 http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit#comment-1906 Oh, BusinessObjects. That brings back memories. I have worked on a project that used and still uses BusinessObjects extensively to give users the ability to do reports against a whole lot of personnel data. It actually worked quite well for most users, both the novices and the more advanced. The real experts learned a bit of SQL and tinkered with the SQL BO generated to get what they need. But BO was and is extremely expensive. It's quite probable that we could whip up something that allowed users to write and manage SQL queries and dump the results into Excel for the fraction of the cost. Oh, BusinessObjects. That brings back memories. I have worked on a project that used and still uses BusinessObjects extensively to give users the ability to do reports against a whole lot of personnel data. It actually worked quite well for most users, both the novices and the more advanced. The real experts learned a bit of SQL and tinkered with the SQL BO generated to get what they need. But BO was and is extremely expensive. It’s quite probable that we could whip up something that allowed users to write and manage SQL queries and dump the results into Excel for the fraction of the cost.

]]> By: Paul W. Homer http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit/comment-page-1#comment-1896 Paul W. Homer Sat, 24 Nov 2007 00:19:39 +0000 http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit#comment-1896 While your never able to take away the essence of the work, that doesn't mean you can't shift it downstream a bit. There are heavy-weight, medium-weight and light-weight programmers. With a bit of magic, you can make it easy for light-weight programmers to do things like create web-sites. You can make it easier to code in Java then in C or definitely assembler. A lot of the modern IDEs seek to reduce time spent in refactoring. These types of tools reduce the entry point for getting the work done, thus allowing more people to qualify for the job. We all want to believe there is something exceptionally difficult about assembling instructions for a computer that explain how to manipulate some set of data. There is to some degree, but we choose to make the problems harder than necessary. The difficulty doesn't come from the list of steps itself, it comes from trying to extract them from the real world in a way that is general. It is the intelligence that we can't mimic. Paul. http://theprogrammersparadox.blogspot.com/ While your never able to take away the essence of the work, that doesn’t mean you can’t shift it downstream a bit. There are heavy-weight, medium-weight and light-weight programmers. With a bit of magic, you can make it easy for light-weight programmers to do things like create web-sites. You can make it easier to code in Java then in C or definitely assembler. A lot of the modern IDEs seek to reduce time spent in refactoring. These types of tools reduce the entry point for getting the work done, thus allowing more people to qualify for the job.

We all want to believe there is something exceptionally difficult about assembling instructions for a computer that explain how to manipulate some set of data. There is to some degree, but we choose to make the problems harder than necessary. The difficulty doesn’t come from the list of steps itself, it comes from trying to extract them from the real world in a way that is general. It is the intelligence that we can’t mimic.

Paul.
http://theprogrammersparadox.blogspot.com/

]]> By: godispretend.com http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit/comment-page-1#comment-1888 godispretend.com Fri, 23 Nov 2007 14:58:19 +0000 http://www.hackinghat.com/index.php/database/the-code-that-was-not-there-and-the-badly-fitting-suit#comment-1888 While there is no silver bullet, that doesn't mean the tools that are available are always terrible. It's not always about what "mere mortals" can't do either... sometimes it's about efficiency. If I didn't have certain tools to help me write Java, SQL, etc... it would take me far longer to get through an assignment. It's because I know how these tools work that allows me to take advantage of that too. I imagine many of the features I used would be useless to someone who didn't understand exactly what that feature did. Anyhow, tools save my day all the time. While there is no silver bullet, that doesn’t mean the tools that are available are always terrible.

It’s not always about what “mere mortals” can’t do either… sometimes it’s about efficiency. If I didn’t have certain tools to help me write Java, SQL, etc… it would take me far longer to get through an assignment.

It’s because I know how these tools work that allows me to take advantage of that too. I imagine many of the features I used would be useless to someone who didn’t understand exactly what that feature did.

Anyhow, tools save my day all the time.

]]>