...sometimes I hear people talk about not writing any code to get something accomplished, particular in respect to binding a control to a datasource. They say something like, "...and it took no code to write". For the longest time I was very leery of this particular statement because, often, code is still required. The idea of simply dragging and dropping something and simply expecting it to work seemed bad to me. But, I'm starting to see things a bit differently (but not as I thought I would have had to in order to completely agree with these people).
...first, let's re- (or more clearly) phrase "...and it took no code to write" to "....and it took me, personally, no code to write", and even more precisely "...and it took me,personally, less code to write". There will always be code whenever there is a need to specialize something; and regardless - somebody, SOMEWHERE had to write code (which, again, means bugs). The benefit, however, is that it was written and tested many, many times over - your code, however, rarely is.
The reason why you can never say NO code is because, even when you're jumping through a wizard, you still are required to insert SQL statements, or piece together various statement fragments that eventually combine to offer the solution. This, in a sense, is still code - just declarative and not VB.Net or C# or whatever. It lacks algorithmic fortitude, I guess - but there is still CODE.
Anyway, I'm sure you've read through it before, but check out this article by Dino. Try doing some of this stuff and see how it doesen't prevent code, but simply forces you to think more about the code that you do, eventually, write.
....okay, I'm not sure what was leaking on this damn thing now. I pulled the entire pump assembly apart now, and have all the pieces strewn apart and inspected all the seals I could find - only one looks as though it is cracked and might otherwise cause problems - so I'll have to check to see if I can get a replacement (if you look on the previous blog post at the picture there, you'll see a large rubber ring on the left hand portion of the picture - that's the seal). If that's the problem - then I'm done, if not, then I have no freakin' clue what's going wrong. The seal is large and goes around the entire pump base, preventing water from seaping out between it and the cover (both of which combine to produce the large plastic case the entire pump assembly sits within). The bad part is that I don't recall water leaking from that particular part of the device - so unless it was trickling down the side unnoticed, I'm still screwed (I seem to remember the leak occuring near the base). In either case, I took some interesting pictures of the inside of this thing. Two things really struck me as interesting - first was the size of the electromagnetic motor; all of the wiring impressed me:   ....and finally I was really struck with the reality that the dishwasher is also a mini garbage disposal. This makes sense as pieces of food and debri fall into the thing, but for some reason I was interested that there was something called a "chopper" inside it:  ....hopefully I'll have the replacement part by tomorrow and can find time to put it all back together again......
It seems as if it's not software giving me problems, it's hardware. Lo and behold, the pieces to my dishwasher:  I can only guess at what's wrong with it - but it leaks when it runs. My assumption is that one of the O-rings inside the pump (seen above) is dried out/cracked/messed up or otherwise f*cked, thereby leaving me with no choice: either replace the whole thing and spend lots of money, or possibly find the couple of two dollar O-rings and replace them via my local and friendly appliance store. The first task I had was to find out how in the hell the whole thing came apart in the first place as I had never done any kind of repair on a dishwasher before. I discovered that you can remove the bottom face-plate with relative ease. You're then presented with many, many nasty looking cables which inspired me to turn the electricity off to the kitchen (the reason it appears so dark in the picture). Aided by some work lights I bought at Menards I started thoughtless sticking my hand in and amongst the wet, dark electrical underbelly of this damn thing (yes, sounds safe doesn't it?), found the clamp that removes the whole pump unit, unattached the hoses and the electrical wires and voila - had the whole thing in hand. I then pulled it off to the side, and started disassembling. Currently I'm stuck as I don't have the right sized wrench to remove a particular screw (I'll get the wrench tomorrow). Stay tuned and find out how damaged this poor thing can get in the hands of a software developer (and a hacker, no less)..... ....as an interesting yet meaningless side-note, I also know how to put in ceiling fans now....
Two major traps hit me today - both of which were caused by me, but aided by the compiler (in my opinion). The first is the issue you can see below (the previous post). The one I'm about to blog about here is slightly more idiotic than the previous, but something about the compiler is making it actually work sometimes - which makes absolutely no sense (and aided to the overall confusion of hunting the problem down). Here's the scenario (in case you couldn't gather) - I'm migrating a huge group of pages over to master pages, which is quite time consuming and grueling. In an attempt to be clever (which shot me in the end), I simply renamed the old page to <page_name>2.aspx, and added a new page called <page_name>.aspx - that way I could toggle back and forth in the browser and see my new page and my old page side-by-side. Seems good? Well, it's not - in fact, it's quite evil. For all the pages that existed, there also exists a code-beside file which has actual VB code in it. The classes are placed inside a namespace and so when I copied the page, I also copied the classes - and so created two code files which compile the same class scoped under the same namespace. The freaky part - it actually works sometimes whereas other times I get strange, bizarre-o compiler errors that seemingly point me in hundreds of desparate directions (literally hundreds). After tracking down a handful of pages (the ones named <page_name>2.aspx) and excluding them from the project - it suddenly started working again, only to find, a little while later, that the errors started coming back and I was forced to remove the several more pages. The ONLY thing I can think of is that this only becomes a problem when I visit a page, cause the page to be compiled, and therefore clutter my namespace (at runtime) with two classes that (somehow) the IDE catches at compile time. Therefore, if I continue browsing through these pages, eventually I'll have to fix each and every one. I just don't get it yet - but I'm hoping I'll remember this issue and, when I have more time, come back to it and figure out what's going on....but, for now....I know how to fix it.
When you're fooling around with master pages, occasionally you'll run into a situation where you must change the master of a content page from one to another (masterA.master ---> masterB.master). The problem you'll sometimes encounter when doing this is that your <asp:Content> controls do not match up (they are named differently or there is a different number of them) between one master page file and another: your content pages will then be hosed with improperly assigned ContentPlaceHolder properties on the <asp:content> controls. For example, say you have the following <asp:content> controls already on your page (because of the master page the content page is assigned to): <asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder_Etc" Runat="Server"> </asp:Content> <asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder_ActionsTitle" Runat="Server"> </asp:Content> <asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder_ActionsSubTable" Runat="Server"> </asp:Content> You then swap master pages and this master page has two more ContentPlaceHolders on it; and sometimes the IDE will do the following: <asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder_Etc" Runat="Server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder_ActionsTitle" Runat="Server">
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder_ActionsSubTable" Runat="Server">
</asp:Content> <asp:Content ID="Content4" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
</asp:Content>
<asp:Content ID="Content5" ContentPlaceHolderID="ContentPlaceHolder2" Runat="Server">
</asp:Content>
Note how the final two are given generic ContentPlaceHolderX values to the ContentPlaceHolderID property. In my master page file, however, they are (specifically): <asp:Content ID="Content4" ContentPlaceHolderID="ContentPlaceHolder_Graphic" Runat="Server">
</asp:Content>
<asp:Content ID="Content5" ContentPlaceHolderID="ContentPlaceHolder_TitleIntro" Runat="Server">
</asp:Content>
Be mindful that just because it "looks" right, it still may not function right. My recommendation? Go through and make the change globally and then do a global name replacement of ContentPlaceHolder1 ----> ContentPlaceHolder_Graphic, or whatever you choose.
|