13. November 2008 by Monkk.

This post has no basis in advice or analysis, I just was documenting an existing SharePoint site I sadly must maintain at work. If you’ve read my posts in the past, you’ll remember that I am not a big SharePoint fan. Well, this isn’t really SharePoint related (I just wanted to kick an app while it was down with that last comment) aside from a demonstration of how things can go horribly awry when one tries to mix development methodologies for SharePoint…

The application in question is a corporate use Room Reservation system. Oddly, the company uses Lotus Notes which has an ugly (though quite functional) room reservation system built right in. In my opinion, this never should have been created. The company is trying to get away from Notes but until they migrate the 1500 - 2000 custom lotus notes database applications to SharePoint, Notes is not going anywhere. It should have been one of the last items migrated and it should have just been migrated to Microsoft Exchange as it also has a good meeting scheduler.

At any rate, the reason for the post. Check out this code snippet from a C# 2.0 Web Service which runs under SharePoint. To be honest, until I saw this, I didn’t even know C# supported "goto" *slaps head*

And sadly that’s one of the more clear-cut code chunks up in there. This my friends is why we have Coding Best Practices and Code Reviews… DON’T LET THIS HAPPEN TO YOU (and you better pray I don’t ever catch you writing something like this, you will be flogged!)

            double num = -41.0;
            double num2 = 39.0;
            string str22 = str10;
            if (str22 != null)
            {
                if (!(str22 == "week"))
                {
                    if (str22 == "day")
                    {
                        str12 = "<Where><DateRangesOverlap><FieldRef Name=\"EventDate\" /><FieldRef Name=\"EndDate\" /><FieldRef Name=\"RecurrenceID\" /><Value Type=\"DateTime\"><Today /></Value></DateRangesOverlap></Where>";
                        goto Label_01A5;
                    }
                }
                else
                {
                    str12 = "<Where><DateRangesOverlap><FieldRef Name=\"EventDate\" /><FieldRef Name=\"EndDate\" /><FieldRef Name=\"RecurrenceID\" /><Value Type=\"DateTime\"><Week /></Value></DateRangesOverlap></Where>";
                    num = -8.0;
                    num2 = 15.0;
                }
            }
            goto Label_01BB;
        Label_01A5:
            num = -1.0;
            num2 = 1.0;
        Label_01BB:
            time2 = time.AddDays(num);
            DateTime time3 = time.AddDays(num2);
            string roomid = "0";

Posted in Programming Related | Print | 2 Comments »

26. September 2008 by Monkk.

First let me say, if you’re looking for some tutorials or samples related to Sharepoint, this post isn’t for you but feel free to read on.

At my new employer’s, I have to do a fair amount of Sharepoint development. Well that phrase right there is just ridiculously large in scope. Allow me to elaborate.

I like to say, Sharepoint is to Web Sites as Microsoft Access is to Databases. Great great tools when used for their intended purposes. Very bad when attempting to stretch them to do things they just weren’t intended to do. Yeah, you can make a front end to your database with Access, but if you need scalable deployable solutions for an enterprise or mass user base… Well, that just isn’t how it’s done. When Sharepoint is used as a collaboration site, it is awesome. Easy to set up and perform basic customizations. It can be styled very nicely by graphic artists and web design folks but when you try to stretch it with configuration settings alone, you end up with hard to maintain ugly solutions.

There are two flavors of Sharepoint. One is Windows Sharepoint Services (WSS) and the other is the Microsoft Office Sharepoint Services (MOSS). WSS is a free "Sharepoint Server" (the SS in WSS and MOSS) [ download: http://www.microsoft.com/downloads/details.aspx?FamilyId=D51730B5-48FC-4CA2-B454-8DC2CAF93951&displaylang=en (requires Windows Server 2003 (you can grab a Sharepoint Virtual Machine for the Microsoft Virtual Server as well), search the download site for Sharepoint VHD] MOSS is built on top of WSS and contains many additional webparts (I’ll explain a little later) as well as the additional services and administration applications to create and manage web farms and multiple site collections. The webparts are the value-add. One such webpart is the Business Data Catalog which auto-magically allow various data sources (web services, databases, etc) to be used as a Sharepoint list while Sharepoint and the BDC do the heavy lifting of getting, caching, updating. etc.

Sharepoint has a few intrinsic "types" that one can work with on a SP site: Lists, Libraries, and Webparts.

A list is simply that, a list of "things". You can best think of these lists as database tables, though they are not stored as such. Each one comes stock with a few default columns such as created by, created date, last modified, that sort of thing. You then can add as many additional columns as you require to more properly define the "thing" in the list. Such as a list of customers, or regions, or support staff members, etc. These are all stored in a content database behind the scenes. If you modify this content database outside of using the Sharepoint provided tools and applications, you will void your support contract on that installation (which considering the MOSS retail server for enterprises in the tens of thousands of dollars in licensing, not something you want to void your warranty with!) These lists automatically have generated Create, Edit, and View pages which can be customized to further enhance working with them. And Sharepoint manages all this for you.

A Library is one of the default "applications" it provides. At it’s heart it is a list, but it has special coding to in the support pages for the list that allow it work with special types of lists. Sharepoint comes with a few built in libraries, such as a Document Library and a Picture Library. As I mentioned these lists are persisted in a database and since images and documents (such as word files, or pdfs) are binary files, you need to store them, retrieve them, and view them in special manners, depending on what type it is. The libraries isolate that and do it for you and provide you with thumbnails in the picture library views and open up word to edit word documents, and excel to edit spreadsheets. All very integrated with office (hence the MO in MOSS, though WSS has these libraries as well.)

A Webpart is essentially a WebControl (in asp.net terms). They are custom web controls that implement various Sharepoint API interfaces. Calendar Control? That’s a webpart.Ghant Chart? That’s a webpart. Anything you can code as a web control can be a webpart. Sharepoint comes with a lot of different ones and they are all pretty useful for their purpose.

The sticky wicket is that you can do a helluva lot without needing to write a webpart. If you’re doing Sharepoint development and not coding webparts, you are using MS Sharepoint Designer, a must have and of course, it is not free. But it does have a fine configurator for the DataView webpart. In a nutshell, the dataview interacts with some external source of data (web service, database, xml file on the files-ystem) and renders it to a list with a customizable XSLT. With something like that you can completely render the data with html markup to the page any damn way you want. You can even pass querystring parameters into it, pretty flexible and you can accomplish a lot of simple-ish apps this way)

I strongly suggest that anytime you discard all the other Sharepoint webparts and libraries to use dataviews and custom xslt, you INSTEAD develop your own custom webpart!! It will be far more maintainable in the end. And if it’s a really complex application that needs to interact with a lot of systems around the enterprise, make a standard asp.net application and host it in a iframe webpart. That is what Microsoft intended. However, most IT managers just want everything in Sharepoint and they want it in there now because Jim in accounting made his group’s Sharepoint site by himself in 2 days. Of course it’s just a few custom lists and no theming or workflows. And that’s great! But they don’t understand the nuances in the differences of the applications they want, it just gets lumped under Sharepoint and that is a MISTAKE!

More later, cross your fingers boys and girls, the rabbit hole goes pretty deep on this one I suspect!

–Regards!

Posted in Programming Related | Print | No Comments »

27. July 2008 by Monkk.

So it’s all the rage to talk about how comments are bad to use, bad to rely on, and should only be used to describe why something is being not done, not how. And for the most part I agree. As soon as a comment is written it becomes stale. It’s hard enough to get the time to update the code, much less updating the comment. With today’s integrated development environments with name completion and the like, there is no excuse for using abbreviated variable or function names in your code. This is not to say that variable names should go on forever, they should be as long as they need to be to express their purpose and NO LONGER!

 ’Fair nuff, no real problems here. Now, the Single Use Principle states that some “thing” should have exactly One purpose.  This “thing” is either an object, class, function, some item of encapsulation.

Again, who can argue with that, makes sense.

Now, my annoyance (c’mon you knew it was coming) So ok, we have these functions which end up being relatively small and easy to read as we’ve emplopyed single use and descriptive variable/function names this is a good thing. The downside is, you now have class files with many many many small functions and getting a big picture view of what is actually happening becomes impossible… Instead of spending all your time figuring out what code does, you end up diagramming the call mapping of your functions so you can find out what is really being called, in what order. All these small almost atomic functions become more time wasting to follow then before we employed our “Best Practices” …

 Very disappointing folks. Got a good solution? Neither do I, but I suspect it comes in the form of more advances to the development environment. I would love to see expandable function calls in code so a simple expand click would show you whats actually going on without having to diagram it all out. I know visual studio has a code declaration window which is great but not quite what the doctor ordered.

At any rate, the best practices are worth it, but let’s not pretend they aren’t causing another, and perhaps larger, maintenance issue.

Regards!

Posted in Programming Related | Print | 2 Comments »

3. July 2008 by Monkk.

So, you’re writing an application, and you break down the functional parts to more base layer services and utility assemblies, and now you want to create a new application and re-use some of your code.

My “go to” answer has always been separate assemblies copied to a global project bin and then adding references to the bins in whatever application needs them. For example:

“Application 1″ and “Application 2″ represent two applications that are re-using logic. The “Libraries”directory off the root represents the project directory housing “Library 1″ and “Library 2″ which are the assemblies being re-used, they build to their respective bin directories. The “bin” directory off the root is the global bin where the binaries from “Library 1\bin\” and “Library 2\bin\” are copied to for re-use by the applications.

In the above scenario, the Applications reference the libraries from “monkk.com\bin” and as new versions of Library 1 and Library 2 are released, they can replace the existing ones when required.

The problem with this type of solution is that often times your libraries end up building on each other to create more complex libraries and soon you find yourself in an endless series of updating the various libraries for any new feature necessitated by the applications and so can lead to updating Application 2 because Library 2 had a for Application 1… Not Ideal!

So, what to do, what to do?!?

Well a technique I’ve now come to employ for just such scenarios is project references. I know, simple how could I not have thought of this? Well I had, but for some reason I’ve been ignoring them because it just didn’t seem “right” because of how intimately coupled the assemblies and projects can become but truth be told, it’s so natural (after being forced to use it) I don’t know how I ever got along without it. I suppose the problem has been, when you use 3rd party assemblies, it’s just not an options, and if all your library assemblies are supposed to be stand-alone assemblies, shouldn’t referencing them both be the same?

Well no, it makes complete sense to modify various Libraries while working on Application 1, and likewise for 2. There are some areas for concern, such as not breaking Application 2 while modifying Application 1 and it’s Library 2 use. But with a good set of Unit tests for both applications and the libraries themselves, you can do this with less risk. And of course best practices for published assemblies come into play such as adding new function signatures instead of changing existing ones (of re-factoring the internals in the process.)

This obviously applies more to companies writing their own frameworks where the libraries stay internal. My point is this doesn’t really scale to mass consumer use due to support issues. In that case, as I’m sure you are, each binary is it’s own and the extra work of version management of the application used assemblies, but such is life and it’s what we’re paid for so, enjoy!

–
Regards!

Posted in Programming Related | Print | No Comments »

6. May 2008 by Monkk.

Well a third TDD post and with mixed emotions I am here. On the one side, I have found BDD which (in my opinion) is far better then TDD.

What the h#ll is BDD you ask? Behavioral Driven Design. So what does that mean? It is development that is driven by the required behavior of your application(s). For example, if you need to write a online slot machine game, and the app you write behaves as an online slot machine game, you have successfully developed an online slot machine game. Ok, no duh! So what? How is that better then TDD where you would have written tests that would pass when you successfully written an online slot machine game?

Oooh, so go ahead and re-read that last question. Notice how it suggests that your artifact of the entire development process is a set of tests (and the implied working application), whereas the BDD version leaves you with a working application (and the implied tests).

That is the difference my friends, they are essentially the same but their terminology differs to emphasize what truly is important in the development process. The creator of BDD states that BDD is just TDD done right. And that’s relevant to the effect that when using TDD it is too easy to fall into the trap of focusing on the tests. Not to imply testing isn’t important, but they are a required evil in that if we never made mistakes, we would never need to write a single line of test code. As that’s pretty much impossible (being human) testing and QA aims to mitigate the risk of the human factor.

So I still haven’t really explained what the deal with BDD is, so here goes (and I apologize, an expert on the topic I am not.) To cite http://behaviour-driven.org/GettingTheWordsRight:

As far as using it, there are a few implementations ( http://en.wikipedia.org/wiki/Behavior_driven_development) for writing tests using BDD. The most popular is rSpec ( http://rspec.info/ ) for the Ruby platform. There are severl for Java, two (mostly dead) for MS .Net Framework, and vaious others (python, PHP, scala). There is a Google Video by the rSpec creator which is quite interesting: http://video.google.com/videoplay?docid=8135690990081075324&q=behavior%20driven%20development&total=27&start=0&num=10&so=0&type=search&plindex=1

I haven’t had the opportunity to do anything with BDD, nor does it look like I will with the state of BDD as it stands today. I believe what has happened is that TDD ate it and we just have to make due. The tests we write should be behaviorial based even if the syntax of the testing domain language leaves us asserting like we’re writing procedural code instead of the OO stuff us enterprise type developers eat all day :-/ Please rSpec guys, port your code to .net :-))

Posted in Programming Related | Print | 2 Comments »

5. April 2008 by Monkk.

So, as you may have read in my previous rant regarding Test Driven Development, I am one of two developers participating in a test of TDD. The project is relatively small in scope and is mostly in a stand-alone “engine” so really, I think it’s a pretty ideal test subject. If you were paying attention, your spidey sense started tingling when you read “…an is *mostly* in a stand-alone engine…” Yes, well, as one might guess the mostly is now causing us some grief. The subsystem I am working on interfaces with the main application so that it knows when it has work to do. In the final design of the subsystem, it is a stand-alone windows service consuming application events from the event queue. Now, not only is this a test TDD project, but also trying to incorporate some Agile/Scrum techniques. I think maybe this was a mistake. Agile makes more sense when you have a team of greater then two. So really I think we are suffering an issue stemming from Iteration grouping. Our 1st iteration is quite large and provides the framework for the rest. However, we are not able to take advantage of smaller implementation items that can be pushed to later interactions. Which causes us to call my sub-system from within the application that writes to the event queue, instead of just reading the event queue.

Now, here’s where it really gets ugly. Due to how we have our name-spacing and library hierarchies, I have to move my subsystem completely out of the main project library and add it to the library code it interfaces with. And later I will have to move it back. The sub-system isn’t huge, but that’s a pain. 

And why didn’t we see this coming? Because we are implementing from what the tests dictate we need, not what we will need for the entire project. Some may argue that the tests apparently were not complete and I agree. But I think it’s a little unreasonable to know that from the test perspective until it’s discovered by actual implementation. And these happen late in the game so a change is not only a change to the implementation but to the entire underlying tests which defeat the purpose of starting with the tests.

I guess one might further argue that TDD is not a replacement for detailed design. But I have to wonder, if the design is indeed so detailed as to reveal this issue before any coding (and I have seen designs that would fit the bill, as well as designed some of that ilk for prior employers) that one would not need to start with the tests as testing techniques would have been built into the requirements and design. Of course if you can , why not as it prevents people from getting time crunched and not implementing tests at all. But isn’t the point of TDD to speed up and allow for iterative design (as well as pushing testing to the forefront, which I praise it for) ?

Regards!

Posted in Programming Related | Print | No Comments »

24. March 2008 by Monkk.

Well folks, I’m here today to gripe about Test Driven Development (TDD if you can’t live without an acronym). For those unfamiliar with it, the concept is (and feel free to correct me folks), one starts coding the unit tests firsts and implements the various classes/structures one needs to make the unit tests function. By the time all is done, you have a completed, working, and unit tested application. Re-factoring is embraced, heck there’s even the TDD mantra: “Red, Green, Re-factor” (which comes from the Nunit paradigm of failed unit tests show up in red, running one’s show up in green, and the re-factor refers to moving code around / renaming classes functions, etc to make more sense in one’s project domain. Essentially it means, when just the test is written, it will fail as there is no concrete things to actually perform the tasks the test requires. Once you right just enough to make the tests pass, it passes (green) and is now ready to be “integrated” into the rest of the project with minor corrections).

Sounds good in theory doesn’t it? Unfortunately, I don’t live in Theory (houses are far too costly…) Why only in theory you ask? Well, as I sit here writing some tests so I can actually code the logic at some point, I’m looking at some diagrams of system interaction and whatnot and I frankly have no idea what the hell the tests are supposed to do… I have nothing to test, and using TDD, at best, I’ll have tests that work and they will dictate what I build, unfortunately, the business wants me to build something particular. Depending on how well I do it, I could end up with something that is what they asked for, OR I could end up somewhere completely different if my understanding is off or I get pulled into the cadence of test code (vs. application logic which may be optimized for performance or maintainabililty, or whatever).

Basically, what I am getting at is, TDD is helpful when you don’t know what you are building. However, if you don’t know what you are building, why the hell are you building anything? Your time would be better spent fleshing out the requirements and the design. And before you say it (because I KNOW you’re thinking it), “But the business doesn’t know what they want, just what they think they want and I need to deliver what they NEED!” Well, I agree, so wouldn’t expectations be better managed by working through requirements with the business so everyone is on the same page, wouldn’t you know better what you are trying to build? I think so.

So where did it all go wrong? To put it bluntly, <flameShield on=”true”>Inexpereienced Developers are the majority of the workforce, and they often make mistakes (as doing is the only way to build experience, this is expected, and natural (albeit problematic)) TDD is just another way to homogenize the programming workforce to reduce the negatives.</flameShield> The downside is it also reduces the positives of having an “All Star” team. People also cite “quicker to market” reasons as by the time development is done there is something to deliver. This is just slight of hand to avoid the problems of managing business expectations. Cough up more frequent milestones and vi’ola, it looks like things are getting done. Unfortunately in reality, the same time is spent, and I propose, MORE time is being spent with TDD refactoring every pass and of course the final refactoring to align the new code with the existing code (which to be fair mostly amounts to renaming of classes, functions, etc, not so much new coding)

To me it just sounds like an excuse to not have to learn more formal documentation and requirements skills. I think knowing what you have to build is far more important then delivering it quickly. The old adage goes, “You can have it done Fast, Right, and Cheap. Pick any two.” This technique addresses the disconnect between the developers and the business that employs them who know very little about software development (think Business Programming here, not so much Software Development shops ) I firmly believe a much better approach is to teach the business what they need to know to manage software development projects, because we as developers don’t have that skill, our magic is programming and archetecting, management is for the pointy haired boss types.

 Ok, I’m done. My apologies to anyone I’ve offended! Please feel free to correct me, I’d love to hear your thoughts!

I should probably mention Martin Fowler’s book, “Refactoring. Improving the Design of Existing Code” as it’s pretty good, although seasoned developers will likely know a lot of the items in the book, other books seem to reference this one (for example, “Refactoring to Patterns” by Joshua Kerievsky”)

-Regards!

Posted in Programming Related | Print | 1 Comment »

11. November 2007 by Monkk.

Evolution and the Quake Revolution crew have *officially* released their source code for their Quake3 mod. Hop on over to http://www.quake-revolution.com/

In two convenient ways, download the source .rar archive, grab it with svn or simply just browse the code-base via web browser.

RAR archive
http://www.quake-revolution.com/downloads/source/Revolution-1.38-source.rar

Subversion
http://quake-revolution.googlecode.com/svn/trunk/quake3/

Ah nastalgia, if you look hard enough you can find some code I wrote up in there And I will cop to thefting the unlag railjump concept from t3h Evolution, just made good sense.

As always, mad props for your efforts and releasing the source instead of just letting it die on the vine (*cough* IU1.2B *cough*), plus who knows what Quake:Zero will cause?

Regards!

Posted in Gaming, Programming Related | Print | 1 Comment »

11. November 2007 by Monkk.

Oh the shame! My most humble apologies to Evolution and the Quake-Revolution.com crew. I inadvertantly forgot the hyphen in the URL in the blogroll link list on the right-hand section.

This has been fixed, if any of tried to stop by, please try again ;-)  [http://www.quake-revolution.com]

Posted in Gaming, Programming Related | Print | 1 Comment »