Man, this blog has gotten a little musty! Time to freshen things up with some more frequent posts and an maybe a re-skinning if I'm feeling bold. I'm working on my first new post in what seems like ages, but I'm going to be holding it for Monday cause that seems like when the most people hit my site or click through from coldfusionBloggers.org/. To give you a hint: I think I've found legit reason to use Evaluate()! Given how much I hate Evaluate() and all of its degenerate ilk, you'll want to tune back Monday to see if I've found a crazy corner case, or if I'm just nuts.
Last time I posted a "Code I Found" entry some people got upset... well I'm doing it again, but I'm pairing it with an actual warning about object value comparisons in strongly typed languages. This example shows both a valid problem and some dumb coding that complicates it.
Its time for a new category here on my blog... I've been working through a good bit of older code at work and trying to update it to something like modern developer standards. Part of the fun of this has been finding weird, pointless language constructs. Check out this C# example:
Neat! This developer was able to use 4 lines of code to do one line of code:
Do you have any good examples of code that just shouldn't have been?
The EnableEditButton() function from the last example is worth a look too...
if (Value == false)
buttonAdd.Disabled = true;
buttonDelete.Disabled = true;
buttonAdd.Disabled = false;
buttonDelete.Disabled = false;
Could be wrapped up as:
buttonAdd.Disabled = buttonDelete.Disabled = !Value;
My recent job change has not only meant that I'm coding C# .Net rather than ColdFusion these days, but also brought with it a whole host of tools and concepts that I've been trying wrap my brain around. Case in point: UML. I learned basic UML back in college, but then spent 3 years in a development environment that was actively hostile to requirement gathering, so what little I knew was lost along the way. Now I'm trying to get caught up, and I'm finding that learning UML is a tricky thing.
I've searched for just about every phrase, keyword, or concept I could think of that would yield a decent guide to crafting UML diagrams, and all what I got back were pages and pages of explanations of the symbols on a given diagram. I can tell you what a Use Case looks like, and what things are on it, but I can't tell you how to get form a Use Case to an Activity diagram. I finally found a quote that enlightened me as to what was going wrong:
As a UML instructor, I find that learning UML presents a paradox: UML is not a process, but rather a notation that can be used in a process; and yet without a process, students don't know where to start with UML.
Thats from this random page that references a "Five Step UML" process for teaching the use and power of UML in software development. Unfortunately, like most old pages on the net, the link to the full text is broken, and I've been left without a process on which to base my attempts at learning UML.
Any one have any good recommendations on a simple process that would help illuminate the gaps between UML diagrams?
While searching up additional resources on WPF, I stumbled across a neat little article on Philosophical Geek titled "How to learn WPF (or anything else)". Its a short read, and it perfectly matches my own feelings about learning a new language, technology, or piece of software: I've always found that its your own interest in something that can make or break your ability to learn about it. If you need to learn a new language, do the following: get an idea about what you can do with the language from examples, pick something that you would like to see done with it, and figure out how to make it happen.