Jimmy Sole the Renown PHP Programmer is Back Online

Check out this great post from DIGG:
[Jimmy Sole had decided to take a break from blogging for a while. Now he is back and beginning to blog about PHP and will soon be blogging about many other web related programing tasks and perhaps some gaming and photography. Check out JimmySole.com today.]

Apparently Jimmy Sole changed his mind and for some reason he's not going to post any great PHP article in the near foreseeable future.

.NET Butchering is trying to launch an initiative to convince him to change his mind. If you're not sure just yet wether you wanna support the initiative or not my advice would be to go have a look at Jimmy's website and you'll make up your mind soon enough. If you decide to endorse Jimmy Sole please leave a comment on his blog.

read more | digg story

[.NET] Generics Perfomance Myth (and Tony Northrup VS Wendy Sarret)

According to Microsoft, Generics are faster than casting (even in absence of boxing/unboxing).

Tony Northrup - co-author of MCTS 70-536: Application Development Foundation (which BTW totally sucks, a review will probably follow) - states in the same book the following:

I haven’t been able to reproduce the performance benefits of generics; however, according to Microsoft, generics are faster than using casting. In practice, casting proved to be several times faster than using a generic. However, you probably won’t notice performance differences in your applications. (My tests over 100,000 iterations took only a few seconds.) So you should still use generics because they are type-safe.

I haven't been able to reproduce such performance benefits myself (and I am, as a Certified .NET Butcher, way more reliable than MCTS books) - so I'd say the performance gain is "supposed" more than "significant", unless someone is able to prove it. Until that moment .NET Generic amazing performance will remain a myth.

If you know something more than me about this - please share.

P.S. BTW - isn't Tony Northrup real HOT (I'd rather date him over Wendy Sarret)?

[.NET vs Java] Event Handling: Are you sure pure OOP is always the simplest?

After a long time I'm again here for another post!
I will talk about event handling, focusing at first on .NET way to supply it, and then spending 2 words about the Java style.
What I want to talk about is delegates and how are they used...I know old good Giovacchia has already spoken about them in a previous post (here) but I wanna talk about them again.
Why?
I'm leaving for a while the Java world and walking through the .NET Framework (I have to take some Microsoft Certifications, 2 or maybe 3 exams in just 1 month and a half...sounds crazy but it's my task in the short term): this means I have to study, as for now, 2 book of about 1000 pages each one.
I'm not taking part in the war between Open Source Multi Platforms Java Conding and Mama Microsoft Windows-Platform Framework yet, but in this path toward the MS certifications I will try to catch what's good and what's not in both frameworks.
At a first sight (I'm about at the half of the first book) 2 years of experience in Java programming has helped me a lot, but I stopped a while learning about delegates.
I don't want to explain what actually they are (Giovacchia in his post said it perfectly), let's just say delegates are a kind of function pointers, and you have to subscribe a delegate to a particular event in order to make it running when that event is raised.
Because my memory is so short term (could it be Google's fault?), during the reading I made a simple schema to remember which key words to use when declaring a delegate and rasing your own event.

namespace HereIsMyDelegateNamespace{
 . . .

 public delegate void MyEventHandler(object o, System.EventArgs ev);

 . . .

 public class MyClass{
    . . .
    public event MyEventHandler MyEvent;
    . . .
 
    /* this method raises an event */
    publlic ReturnType RaisingMethod()
    {
        System.EventArgs ev = new System.EventArgs();
        . . .
        MyEvent(this,ev);
        . . .
    }
 }
}

namespace ConsumerNamespace{

 public class Consumer{

      public static void Main(string[] args)
      {
          . . .
          MyClass m = new MyClass();
          m.MyEvent += MyEventHandler(m_MyEvent);
         . . .
         /* from now on we can call a method
         *  or make an action which causes MyClass to
         *  raise the MyEvent event */
         m.SomeMethodThatRaisesTheEvent();
         . . .
      }

      public static void m_MyEvent(object o, System.EventArgs ev)
      {
          . . .
          /* handles the event */
      }
 }

}

You have to remember few things:

• The signature of the delegate has to be the same of your own handling method


• The signature of the delagete has to contain 2 parameters: the first one is an object reference, that refers to the object that launches the event, and the second one must be a subclass of System.EventArgs (there are a lots of them implemented for the common events)


• You can subscribe to an event using the overloaded operator += but you can also unsubscribe by using the -=


• For common applications, you won't need to raise yourself an event, but just supply a method and subscribe it to the event (the method, as said, has to have the same signature of the needed delegate)

And what about Java?
Learning Java I actually never had the need to write down some code to remember how Event Handling works.
Why? There are no delegates, in the sense you need to specify an entire class as the delegate for that event. What does it happen when you need to subscribe to an event?
In that situation Java is more OO then .NET, indeed you only use your Handler Class (such as MouseListener class, but for the common events, e.g. such as Mouse and Keyboard, you have at your disposal tons of ready-to-use classes) to manage the event. In this scenario you call directly by the object that throws the event, an addXXXListener() or removeXXXListener(), and inside your class, in which you surely have an array of potential listeners, when you want to raise the event, you have to iterate manually by calling all the needed methods of the listeners subscribed.
IMHO Java is straightforward to the OOP, but you need more code, and .NET allow you by using delegate and event keywords not to think to the propagation of the event. Moreover, in .NET you won't need to specify an entire class to handle the event, bringing to a more concise code style.

I'm not as experienced in .NET as I'm in Java, so maybe in few weeks I will post the exact opposite kind of opinion, but as for now I'm feeling better using C#, as it seems it has taken the good in Java and brought it to a more powerfull level (I'm refering to the whole framework ofcourse and not to the language itself).

[.NET] How to send debug text to output (or file)

If you landed here because you want to send debug text to the output console do not worry, it's piss-easy:
//////////////////////////////////////////////////////////
// you can choose between this:
// first par: "a description of the importance of the message"
// second par: text 'category'
Debugger.Log(2, "Test", "this text in the output console - 1");
//or this

Debug.Write("this text in the output console - 2");

//or this

Debug.WriteLine("this text in the output console - 3");

//or this
Trace.Write("this text in the output console - 4");
//////////////////////////////////////////////////////////

Obviously you have to build in debug mode to see any output (if you do not know this you're a really lousy developer && human being).

If you feel sophisticated of you have some obscure reason to send your debug text not only to the output console but to a log file, you do like the following:
//////////////////////////////////////////////////////////
// clean-up the mess
Trace.Listeners.Clear();
//create new listener
DefaultTraceListener yourListener = new DefaultTraceListener();
//add new listener to trace
Trace.Listeners.Add(yourListener);
//set log file path
yourListener.LogFileName = @"log_test.txt";
//send text to console && log file like this

Trace.Write("butchers will be butchers"); 

//////////////////////////////////////////////////////////

In the case above you can use the Debug class the same way you use Trace (so you could write Debug.Write instead of Trace.Write and so on). Difference between the two is that Trace is implemented in Release build as well while Debug only in Debug mode (will be ignored if you build in Release).

P.S. Lately I've been to lazy to properly format the code - suck it up

How long can a developer survive without Google?

How many times did your boss come up with "can we do X?" and you didn't have a clue about it but answered "Yes, no probs at all - consider it done"? You were probably thinking "WTF - I have no idea about this", and first thing you do when you're back and safe at your desk is googling the damn thing up. We can do stuff like that only because developers are merging into a collective intelligence through internet + Google.

Mortality rate (= getting the axe = being let go = being fired) would be dramatically higher between developers if Google wasn't there to keep them from falling apart (or reverting to slow and painful alternatives) every time they have to learn something new (meaning almost every day unless you are a Reporting Engineer - if so good luck with that).

I am not saying nothing new here, just that today being able to quickly find answers on Google is - if not the most important - at least the second or third most important skill of a developer/software engineer.

Said so, I tried a little experiment: I kept track of how many times I look up work-related stuff using Google during an average day of work (9 to 5 let's say):

10:05 - looked up C# 'as' operator to refresh a few concepts

10:48 - looked up COM on C# sample (there's always something wrong - if you do suck)

12:30 - looked up CoCreateInstance COM function

14:30 - looked up Abstract Factory Pattern sample (no good - Factory is enough for me)

15:55 - looked up T-SQL reference for 'collate' statement

16:40 - looked up osql to run .sql scripts from SQL through xp_cmdshell (BAD idea!)

So turns out on an average day I looked up 6 times on Google - none of those things were crucial for what I was doing but I needed to shed some light on some doubts or explore possibilities I wouldn't have had otherwise. To answer the headline, I start craving for Google after a couple of hours. After a day I would probably start to freak out. After a week or two I'd probably quit (OK , maybe not, maybe I'd switch to Yahoo before quitting). I am not able anymore to count all the times Google really made my day- and I have to say that this is the reason why I opened this blog, to participate in this awesome process of merging my experience based knowledge with the average guy out there who's probably doing the same.

In my experience sometimes people are ashamed of looking up stuff on Google - well they shouldn't be since today is more the 'look up on google skill' is more valuable for a developer than any other static skill and you don't have to waste your time trying to memorize APIs or looking for perfect references 'cause google is the perfect reference (if you know how to filter all the crap - obvious). Sometimes it is astonishing to see people that revert to Google (or the web in general) only if all other means fail after a few days of blood-sweating quests (meaning all the books on the shelves and everyone in the company have been consulted) - it is (most of the times) the other way around guys.

I won't go as far as saying that I couldn't do my job without google (did I already do that?) - but certainly I couldn't be as productive without.

OK - enough boredom for today.

P.S. if you don't agree I'd like to hear why.

[.NET] How to create a shared folder in C#

To cut a not so long story even shorter, this can be done with the following snippet: 

//////////////////////////////////////////////

using System.IO;

using System.Management;

//...

//First create your directory

DirectoryInfo myDir = new DirectoryInfo(@"C:\shared");

myDir.Create();

//...

// Create an instance of ManagementClass

ManagementClass managementClass = new ManagementClass("Win32_Share");

// ManagementBaseObjects reference for in and out parameters

ManagementBaseObject inParams;

ManagementBaseObject outParams;

inParams = managementClass.GetMethodParameters("Create");

// Set input parameters

inParams["Description"] = "Shared directory";

inParams["Name"] = "shared";//this needs to match with folder name!

inParams["Path"] = @"C:\shared";

inParams["Type"] = 0x0; // Disk Drive

// InvokeMethod call on the ManagementClass object

outParams = managementClass.InvokeMethod("Create", inParams, null);

// Check outcome

if ((uint)(outParams.Properties["ReturnValue"].Value) != 0)

{

   //Unable to share directory

}

////////////////////////////////////////

The above solution is quite sweet and seems to work perfectly - for further details see the article where I originally found the snippet to share the directory: http://www.sarampalis.org/articles/dotnet/dotnet0002.shtml

Man - do I suck!?!

[.NET] C# 'is' operator

The C# 'is' operator looks like a boring little fella at first, but once you get to know it you will eventually appreciate it - it checks if you can safely cast an instance of an object to a type:
///////////////////////////////////////
//example 1
string testStr = "";
object obj = testStr;

//..somewhere else in your code
string newStr;

if (obj is String)
{
   newStr = (string)obj;
   //go nuts with your string
}
///////////////////////////////////////

It is important to understand that since the 'is' operator is just checking if it is safe to cast the following expression will always be true for any type:
///////////////////////////////////////
//example 2
string var = "whatever";

if(var is object) //<-always true (for var of any type)

{

    //always executed 

}

 /////////////////////////////////////// 

The above is always true for any type because everything in .NET inherits from object. This means you can safely cast to object (box) value types for example, and even if quite obvious it helps understanding how the 'is' operator works. 

You can obtain a result similar to example 1 using GetType and typeof if you're resolving types down to an inheritance line with this code: 

/////////////////////////////////////// 

//example 3 

string testStr = ""; 

object obj = testStr; 

//..somewhere else in your code 

string newStr; 

if (obj.GetType().Equals(typeof(String))) 

{ 

   newStr = (string)obj; 

   //have fun with your string 

} 

/////////////////////////////////////// 

But here you're just checking for equality and not for safe casting in general, as you do with operator 'is' (i.e. example 2 with GetType Equals typeof returns false - because GetType returns string does not equal object). For an insight on GetType and typeof see this post.

Closing - a probably more efficient way - depending on your taste - to check if casting is safe is to go ahead and cast using the operator 'as', like this:
///////////////////////////////////////
//example 4
MyClass test =  new MyClass("read between the lines");
object obj = test;

//..somewhere else in your code
MyClass newTest = (obj as MyClass);

if (newStr != null)
{
   //do CRAZY stuff with YourClass
}
///////////////////////////////////////
For more details about the 'as' operator have a look right here.

[SQLServer] SQLServer2008: Workgroup VS Standard

You might be in doubt when choosing between SQLServer2008 Standard or Workgroup edition (most people rule out the Enterprise edition since it's 7500 € or so) - here's a list of the differences bewteen the two (in red most relevant).

Reporting Services memory limits : unlimited for Standard - 4GB for workgroup

Standard features not supported by workgroup:

Standard algorithms
Data mining tools: wizards, editors, query builders
SQL Server Analysis Services service
SQL Server Analysis Services backup
General performance/scale improvements
SSIS Designer including VSTA scripting
Integration Services service, wizards, and command prompt utilities
Basic tasks and transformations
Log providers and logging
Data profiling tools
Additional sources and destinations: (Raw File source, XML source, DataReader destination, Raw File destination, Recordset destination, SQL Server Compact destination, SQL Server destination)
Business Intelligence Development Studio
MDX edit, debug, and design tools
Standard performance reports
Plan guides
Plan freezing for plan guides
Policy-based best practices
Multi-server policy-based management
Heterogeneous subscribers
Database mirroring (witness only)
Failover clustering (very limited in workgroup)
Dynamic AWE
Failover without client configuration
Automatic corruption recovery from mirror

The Workgroup edition apparently includes 5 CAL licences (a license is around 130 €) - I see that as the only possible reason you might go for it since the price of the piece of software itself is very similar (around 600 € for the workgroup against 750 for the standard).

For more details http://msdn.microsoft.com/en-us/library/cc645993.aspx

Google Chrome Drawbacks (for lazy developers)

If as a user and software engineer I am nothing less than aroused by Google Chrome release after reading the brilliant comic (Google Chrome Comic) they are using as presentation, as a mere nitty-gritty developer I am somewhat worried about the fact that we'll have to bitch with yet another browser in order to produce cross-browser web apps.

It might seems a little obtuse (or plain lazy) - but yet at the moment if you are developing a ASP.NET application and you set as a system requirement IE x - no one complains.
On the other end we all now that if you start requiring something different than IE (i.e. Firefox or Google Chrome now) complaints will flood back like crazy.

Hence you have two possible ways to go:

1) develop your ASP.NET web-app optmized for IE (short for 'we didn't even bother running it even once on Firefox or anything else, so if it breaks it is YOUR problem')
2) develop a cross-browser application (short for 'we developed it on Firefox and que serà serà')

Option 2 could now assume a hell of a new meaning (I am talking stuff like adding yet another 'if' to all your javascripts) - possibly nothing will change since the google guys are sound guys and the webkit blah blah blah and the new javascript virtual machine (V8 - that has a specific API which can be included by other browsers and so forth) hell yeah.

Anyway apart from complaining regardless (I am a developer - it's my nature), I am looking forward to put my hands on the thing and assist to a new chapter of Browser Wars (coming soon on your machines and portable devices).

[.NET] Difference between GetType and typeof

GetType and typeof come in useful when you need to mess with objects types before casting and so forth.

The difference between the two is the following:
GetType is a method of the object class - from which everything inherits in .NET - while typeof is an expression that operates on a type (same as you declare variables with).
While GetType takes into account inheritance and gives you back the actual Type of your instance at runtime - typeof just resolves the type into a System.Type object (jeez) at compiletime.

To cut a long story short: GetType extracts the Type from the object - typeof extracts the correspondent System.Type object from a type (declaration).

Have a look @ an example and it will be clearer:
////////////////////////////////////////////////
Type myType;
//the following blocks of code are equivalent
{
myType = typeof(int);
}

{
int i;
myType = i.GetType();
}
/////////////////////////////////////////////////

Good stuff - ain't it? No, it ain't - this post is child of absolute boredom.