Shifting Bits

One Language to Rule them all, One Language to Bind them....

As a computer scientist, I often hear buzz about some new language that has just come out and does this and that differently and is all the rage. Upon closer inspection I find the usual poorly implemented, badly designed linguistic heap of bull feces that seems to be popular. As a good reader you should be asking yourself: "Why is this guy so jaded about the leading edge?"

That reason I'm jaded is simple: I have found much to my dismay that most if not all of these new and upcoming languages are essentially clones of each other with minor differences based on the idiosyncrasies of that particular languages creator. Most if not all of these languages were created because of some minor dissatisfaction with an existing clone language; these complaints range from how variables are typed, to the scoping of those variables, and all the way to the minor obscure details. Nevertheless, I find that most, if not all of the creators of these languages did not understand completely the results of their actions. While I cannot quote bogus statistics or otherwise made up numbers that say nothing, I would be willing to bet that most of theses dissatisfied language designers did not understand the reasoning behind the very thing that drove them to create their own language anyway.

This assertion comes out of many conversations with my peers concerning object oriented programing and in particular C++, Java, and C#. Many of my peers either live in a world of managed languages (Java, C#) or in the world of C. The Managed camp decries the complexity and inherent dangers of programming at a low level, while the C camp agonizes over garbage collection, objects for objects sake, and a lack of access to hardware. At this point one would expect me to raise my colors and choose a camp.... I refuse. As far as I am concerned they both are wrong, and right.

Both camps, at least in my humble opinion, share one thing in common, they have no appreciation for the other camp's elegance because the do not fundamentally understand or see the bigger picture. The systems programmers are stuck at such a low level that they cannot see that they are uselessly duplicating code all over the place, while the Object oriented junkies are flying so high they cannot see the congestion their superfluous object creation has created.

So where does that leave us...
Oh right, on this: There is no such thing as the one true language.
However, we have a nice tool chest of languages that exist already, creating another superfluously is foolish a language should only be replaced when it is fundamentally flawed. Would be creators of new languages should take this to heart before creating a new language, most often the construct that seems most annoying exists for a very good reason, if not it shows that the language designer did not understand the fundamentals of languge design before they created their languge

Using PowerShell with Microsoft's SharePoint Server and Windward Reports

Many companies have SharePoint servers that they use to manage their documents, so why not manage templates too? The short answer has always been that it meant that the template had to be manually checked out before it could be used thus making it an annoying and tedious process.

Enter PowerShell, Microsoft's answer to the well known bash shell and the functionality that it provided UNIX and Linux sysadmins. PowerShell allows us to call the .Net assemblies for the Windward .NET engine directly as well as the managed assemblies for SharePoint.

Setting it all up

To reference the code in the SharePoint or Windward assemblies we have to load them:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[System.Reflection.Assembly]::LoadWithPartialName("WindwardReportsAPI")

Now that the assemblies are referenced we can go to work:

$sharepointurl="http(s)://mysharepointsiteURL"
$mysite=New-Object Microsoft.SharePoint.SPSite($sharepointurl)
$documentsite=$mysite.OpenWeb("SubSiteName")

Ok we've opened the SharePoint Site, it is important to note at this time that only users with read permissions on the WSS_content will be able to successfully complete the above steps. Our next step will be to get the document we want

$myfile=$rootsite.GetFile("DocumentLibraryName/TemplateName.docx")
$template=$myfile.OpenBinaryStream()

So we now have our template in hand, now for the engine. From this part forward this is going to look like the Standard RunReport Sample app that ships with the Windward .NET engine

$output=New-Object System.IO.FileStream("OutPutPath\output.pdf",
	[System.IO.FileMode]::Create,
	[System.IO.FileAccess]::Write,
	[System.IO.FileShare]::None)
$myreport=New-Object net.windward.api.csharp.ReportPdf($template,$output)

$myreport.processSetup()
#The public test datasource
$datasource=New-Object net.windward.api.csharp.AdoDataSourceImpl(
		"System.Data.SqlClient",
		"Data Source=MSSQL.windwardreports.com;Initial Catalog=Northwind;User Id=demo;Password=demo;")
$vals=New-Object net.windward.api.csharp.KeyPairDictionary
$vals.Add("variable", A_Value)
$datasource.Map=$vals

$myreport.processData($datasource,"")
$myreport.processComplete()
$output.flush()

A few things you'll need to know...

To use the Windward .Net Engine with PowerShell you will need to create a powershell.exe.config, I suggest modeling it off the one in the RunReport Sample app, and copy it to the PowerShell directory, this will allow the engine to properly validate your license when you run it, otherwise the engine will fail every time. Furthermore you can do more than just SharePoint with PowerShell and the engine, anything that you would right a .Net app for you can do with PowerShell. So for a simple run script PowerShell is ideal.

Abusing References In Java

The Java programming language is reference based, which given the original goal to have a completely object oriented language makes sense because objects are heap explicit. However this has some unforeseen side effects. It is common to see code like this:

public class Foo{
 private FooBar fooBar;

 public FooBar getFooBar(){
 return fooBar;
 }
}

Where this causes unforeseen issues is that line return fooBar; since java is a reference based language, rather than return a copy of the object fooBar like you might expect it returns the actual object fooBar! This is easily verifiable with debugger. So what does this mean... It means that the code above is (almost) semantically equivalent to this:

public class Foo{
 public FooBar fooBar;


}

Now I did say almost semantically equivalent... because they're not exactly the same. In the first you can modify the private object but you cannot assign to it, in the second one you can because the code access permission is public.

This clearly is not what most people think of when they create a getter method, however it is critical that they do! In a reference based language all objects are on the heap, thus to access them you must resolve a pointer, java hides this, however it is still there and is very apparent in this situation. To pass a clone of the object the programmer must either call the clone() method or use a copy constructor.

However there are advantages both ways, a programmer can use referenced based passing to expose functionallity that would otherwise be denied for encasulation reasons, or they can save memory and time by recycling the reference.

Friends don’t let friends use Crystal Reports – Windward