Move Over .NET and Java, Here's PHP

Zend Technologies has just released version 0.1.1 of its new PHP framework called the PHP Collaboration Project. This framework was designed to rival the .NET and Java frameworks and rise PHP to the same level as those same languages.

The PHP framework takes advantage of many of the new PHP 5 features, including XML, RSS, and WebService API's.

KPL - Kids Programming Langauge

Kid's Programming Language, KPL, is a programming language designed to make programming fun and exciting for kids. In fact, it was designed to make computer games. Well, not soley computer games, but it makes it easy to make games. If you think about it, kids would really enjoy programming a lot more if they were designing a game instead of a email client or something.

At first glance, it looks very simliar to Visual Basic, and for good reason. It was modeled after VB.NET. The IDE was also modeled after Visual Studio.NET. Now, for you .NET haters out there, please don't let that discourage you. Remember, this is a programming language for kids with the main objective of teaching young kids the basic concepts of a computer language.

Microsoft has started officially supporting and promoting KPL since September of 2005 and has since integrated it into it's Coding4Fun site on MSDN. Their site includes games, articles, and challeges.

For an example of a "Hello World!" application, you just need 5 lines of code:

Program HelloWorld
   Method Main()
      Print("Hello World!")
   End Method
End Program

There is so much more you can do with KPL, but you can visit their site for a complete list of functions.

Why I Hate Frameworks

I came across this posting on the net and thought it was amazingly brilliant. So, for your entertainment pleasure, "Why I Hate Frameworks", by Joel Spolsky:

I'm currently in the planning stages of building a hosted Java web application (yes, it has to be Java, for a variety of reasons that I don't feel like going into right now). In the process, I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks.

And after spending dozens of hours reading through feature lists and documentation, I'm ready to gouge out my eyes.

Let's pretend I've decided to build a spice rack.

I've done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.

If I were going to build a whole house, rather than just a spice rack, I'd still need a tape measure, a saw, a level, and a hammer (among other things).

So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.

"A hammer?" he asks. "Nobody really buys hammers anymore. They're kind of old fashioned."

Surprised at this development, I ask him why.

"Well, the problem with hammers is that there are so many different kinds. Sledge hammers, claw hammers, ball-peen hammers. What if you bought one kind of hammer and then realized that you needed a different kind of hammer later? You'd have to buy a separate hammer for your next task. As it turns out, most people really want a single hammer that can handle all of the different kinds of hammering tasks you might encounter in your life."

"Hmmmmmm. Well, I suppose that sounds all right. Can you show me where to find a Universal Hammer."

"No, we don't sell those anymore. They're pretty obsolete."

"Really? I thought you just said that the Universal Hammer was the wave of the future."

"As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn't very good at any of them. Driving a nail with a sledgehammer isn't very effective. And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer."

"That's true. So, if nobody buys Universal Hammers anymore, and if you're no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?"

"Actually, we don't sell hammers at all."

"So..."

"According to our research, what people really needed wasn't a Universal Hammer after all. It's always better to have the right kind of hammer for the job. So, we started selling hammer factories, capable of producing whatever kind of hammers you might be interested in using. All you need to do is staff the hammer factory with workers, activate the machinery, buy the raw materials, pay the utility bills, and PRESTO...you'll have *exactly* the kind of hammer you need in no time flat."

"But I don't really want to buy a hammer factory..."

"That's good. Because we don't sell them anymore."

"But I thought you just said..."

"We discovered that most people don't actually need an entire hammer factory. Some people, for example, will never need a ball-peen hammer. (Maybe they've never had ex-girlfriends. Or maybe they killed them with icepicks instead.) So there's no point in someone buying a hammer factory that can produce every kind of hammer under the sun."

"Yeah, that makes a lot of sense."

"So, instead, we started selling schematic diagrams for hammer factories, enabling our clients to build their own hammer factories, custom engineered to manufacture only the kinds of hammers that they would actually need."

"Let me guess. You don't sell those anymore."

"Nope. Sure don't. As it turns out, people don't want to build an entire factory just to manufacture a couple of hammers. Leave the factory-building up to the factory-building experts, that's what I always say!!"

"And I would agree with you there."

"Yup. So we stopped selling those schematics and started selling hammer-factory-building factories. Each hammer factory factory is built for you by the top experts in the hammer factory factory business, so you don't need to worry about all the details that go into building a factory. Yet you still get all the benefits of having your own customized hammer factory, churning out your own customized hammers, according to your own specific hammer designs."

"Well, that doesn't really..."

"I know what you're going to say!! ...and we don't sell those anymore either. For some reason, not many people were buying the hammer factory factories, so we came up with a new solution to address the problem."

"Uh huh."

"When we stepped back and looked at the global tool infrastructure, we determined that people were frustrated with having to manage and operate a hammer factory factory, as well as the hammer factory that it produced. That kind of overhead can get pretty cumbersome when you deal with the likely scenario of also operating a tape measure factory factory, a saw factory factory, and a level factory factory, not to mention a lumber manufacturing conglomerate holding company. When we really looked at the situation, we determined that that's just too complex for someone who really just wants to build a spice rack."

"Yeah, no kidding."

"So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory. The factory factory factory will produce only the tool factory factories that you actually need, and each of those factory factories will produce a single factory based on your custom tool specifications. The final set of tools that emerge from this process will be the ideal tools for your particular project. You'll have *exactly* the hammer you need, and exactly the right tape measure for your task, all at the press of a button (though you may also have to deploy a few *configuration files* to make it all work according to your expectations)."

"So you don't have any hammers? None at all?"

"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."

"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"

"Yes."

"Well�All right. I guess that's what I'll have to do. If this is the way things are done now, I guess I'd better learn how to do it."

"Good for you!!"

"This thing comes with documentation, right?"

New C# 3.0 Features

While .NET 2.0 has just recently been released, Microsoft has been active in .NET's next release. The C# 3.0 specification was released in September 2005, and their C# 3.0 site has many examples of it's newest features.

Implicitly Type Local Variables

(The var keyword)

One of the new features in 3.0 is the "var" keyword.

Example:

var i = 5;
var s = "Hello";
var d = 1.0;
var numbers = new int[] {1, 2, 3};
var orders = new Dictionary<int, order>();

Once the var variable is assigned, it implicitly converts it to the assigned data type. So in the var i = 5; line, i then becomes an int. Also, in the example of above, the s variable becomes a string, etc.

There are a few restrictions however:

1. The declarator must include an initializer.


2. The initializer must be an expression. The initializer cannot be an object or collection initializer by itself, but it can be a new expression that includes an object or collection initializer.


3. The compile-time type of the initializer expression cannot be the null type.


4. If the local variable declaration includes multiple declarators, the initializers must all have the same compile-time type.

For example, the following code examples are incorrect:

var x;
var y = {1, 2, 3};
var z = null;

Extension Methods

Extension methods extend existing types by allowing you to add additional methods.

Note: Microsoft recommends that extension methods be used sparingly as they are less discoverable and more limited that instance methods.

Creating the Extension Methods

To declare an extension method, you specify the this keyword in the first parameter of the method.

For example:

namespace MyApp.Utilities
{
   public static class Extensions
 {
      public static int DivideByTwo(this int Number)
     {
         return Convert.ToInt32(Number/2);
     }
  }
}

Importing the Extension Methods

To import this extension methods from you Extensions class, use the using keyword to include in the namespace:

using MyApp.Utilities;

Once you include the namespace into the file, you can call the DivideByTwo method from any int variable you create.

For example:

int i = 100;
int halfOfi = i.DivideByTwo();   //Divides i in half

Object Initializers

Yet another added feature in 3.0 is the concept of an object initializer. With object/member initializers, you can set the object's properties while initializing it, thus saving many lines of code.
For example:

public class Car
{
   string make, model, color;
   int modelYear, doors;

   public string Make { get { return make; } set { make = value; } }
   public string Model { get { return model; } set { model = value; } }
   public string Color { get { return color; } set { color = value; } }
   public int ModelYear { get { return modelYear; } set { modelYear = value; } }
   public int Doors{ get { return doors; } set { doors = value; } }
}

You could then create a new instance of Car as follows:

var c = new Car {Make = "Ford", Model = "Mustang",
 Color = "Red", ModelYear = 1967, Doors = 2};

Not only can you initialize classes this way, you can initialize classes anonymously this way. These are called Anonymous Types. So for instance, you could create a new class like:

var person1 = new { Name = "Bob", Age = 31 };
var person2 = new { Name = "Jane", Age = 37 };

If you wanted to, you could then use:

person1 = person2;

The reason you can do this is because they are the same anonymous type.
There are a few more features in C# 3.0, but I will discuss them more later.

Visual Studio 2005 Web Deployment Options

You'll have to forgive me because I'm a little slow sometimes. But, a little while ago I noticed that my web project didn't have any .dlls associated with it whenever I compiled it. I also couldn't figure out where the bin folder was anymore. Then I thought to myself, what if I just upload the code behind file (.cs or .vb) and try to run it. It ran great. I didn't even have to compile it. Granted, it's probably smart to compile it just to make sure that there are no errors, but still.

By default, the compilation is now done on the fly, called just-in-time compilation. However, there are several different compilation options you have in 2005.

Just-in-time Compilation

As I mentioned earlier, this is the default compilation type for Visual Studio 2005. You write your .aspx page and code behind files like normal and compile to make sure there are no errors. Then, you just upload the files to your web server and voila! You're set. Not .dlls to worry about. If you need to make a change to one code behind file, make the change and upload it. It won't restart the application, it won't end all sessions, and it doesn't bog down the machine having to recompile the whole application on the first hit. However, the page needs to recompile, so when it gets called the first time, that page will take a little longer to execute so that it can compile. This seems to be the preferred way Microsoft wants us to do it now.

Pre-Compilation

Another type is In Place Pre-Compilation. The .NET framework comes with a tool called aspnet_compiler.exe located in the %WINDIR%\Microsoft.NET\Framework\v2.x.xxxx directory. There are several different parameters you can pass this tool, but when run, it will pre-compile the site for you. This pre-compiler will make .compiled files for each of your code behind files. Though there is only a slight performance advantage for the startup/compile time, it's mainly to make sure your code is free of errors.

There is also the option called Pre-compilation for Deployment. This option uses the same tool as before, the aspnet_compiler.exe tool, however we pass it the "-p" parameter and the "-v" parameter to replace all the code in the all your pages (.aspx, .ascx, .master, etc) and puts the code into one or more assemblies in the bin directory.

For a much more in-depth look at these pre-compilation option, visit the OdeToCode article, "Precompilation In ASP.NET 2.0".

VS 2005 Web Development Project

Microsoft has an add-in called Visual Studio 2005 Web Development Projects (Beta V2 Preview). This tool will offer several different compiling options, including the ability to compile to a single .dll in the bin directory like Visual Studio 2003 does. Once you download it and install it, you will have a new option available when you right click on any of your web projects. This new option is called "Add Web Deployment Project." This option is not available from the Create New Project menu. You can only add it to an existing web project by right clicking the web project in the Solution Explorer and selecting it.

Once added, right click on the new deployment project and click on the Property Pages option. You'll notice that there are four Configuration Properties to configure: Compilation, Output Assemblies, Signing, and Deployment.

Compilation

The compilation property let you dictate where your "Output Folder" will reside. This output folder holds all the .dlls generated by this tool.

You can also choose whether or not to "Generate Debug Information" when it is compiled. Since there is some overhead in generating the debug information, it is recommended to only select it if you are in a development environment. Once you release the project, it is advised that you uncheck this option.

The third option is "Use IIS metabase for source input." This specifies the full IIS metabase of the source Web site application. For example, a metabase path might be /LM/W3SVC/1/ROOT/MyWeb/, where MyWeb is the virtual directory. If there are sub-Web sites, this will result in build errors. To avoid these errors, you can specify the IIS metabase path of the Web site you are compiling, which causes the ASP.NET compiler to skip any sub-Web sites defined in the IIS metabase.

The fourth option is "Allow this precompiled site to be updatable." This is a nice feature that, if selected, will compile all your code behind files into .dlls, but will keep the HTML and server code in your .aspx and .ascx files. This is nice if you want to update the page after you compiled it without having to recompile the whole page. This is similar to the VS 2003 way of compiling. If unchecked, the HTML and server code inside of the .aspx and .ascx page will compiled into the assembly output. If you need to make an HTML change, you will need to recompile it and upload the new .dll.

Note: If you uncheck this option, you still need to have the .aspx and .ascx pages there. This is for directory structure. If you do not have it there, you will get an error saying the page does not exist. Even though the page is empty, it still has to be there! It would be nice for .NET to have something similar to Java's .war files, where you could just upload a single file that contains the whole site, but as far as I'm aware, there is nothing like that yet.

Output Assemblies

There are four different types of output assemblies you can choose when compiling.

The first is to "Merge all outputs to a single assembly." This option, combined with checking the "Allow this precompiled site to be updatable" option from the Compilation property page, will compile your web project exactly the same as Visual Studio 2003 does. This option does exactly what it sounds like; it compiles all the code behinds into a single .dll file. However, in VS 2005, you give it the assembly name.

Under this option is the "Treat as library component" check box. If checked, it will remove the App_Code.compiled file which allows you to add the App_Code.dll to another site with conflicting with the App_Code.dll assembly in the other site.

"Merge each individual folder output to its own assembly" is the second choice available. This option creates a seperate output assembly for each folder. This is nice since you can make updates to a folder and only have to recompile that folder's contents. You also have to choice to provide an "Option assembly prefix" when you choose this option. This option will prefix any name you choose (ie: MySite) to your folder's assembly output (ie: MySite.subfolder_

"Merge all pages and controls to a single assembly" is the third option in choosing what type of output assembly to create. While it sounds similar to the first option, it is different in that special folders such as App_Code, App_WebReferences, etc are each compiled into a seperate assembly.

The last option is to "Create a separate assembly for each page and control." This option compiles each page into a separate assembly. However, in doing so, it disables the compiler's batch optimizations and can result in longer compile times for larger web sites. This option is useful for granular updates of your deployed web site.

Signing and Deployment

While these are on the topic of web deployment options, they are a little out of the scope of this article. For more information, visit Microsoft's Visual Studio 2005 Web Development Projects site for more details.

Unexpected Surprise

Well, I never expected it, but my HP Printer Hack has been somewhat of a hit. I am using the code I found off of an article from OdeToCode. Their example was in a console, so I decided to make it a .NET GUI interface instead. Out of all my programs available for download, I figured Diggaz With Attitude would be the most requested. Just goes to show that it's not the size of the program that counts, it's how you use it.