free geoip Jayson's Blog -
A conduit to the voices inside my head.

Jayson's Blog

  • age old debate

    i wanted to touch on the age old debate between Java and .NET (and just Microsoft in general). java was originally devoloped as an applet language for the web, and for small compact devices that needed to run small applications in a minimal footprint (such as cable boxes, cell phones, etc). this was back around '95 when your only other options were either C++ or VB, perl, python, and other similar languages. what has happened to java along the way is probably the most severe example of code bloat that the industry has ever seen. Over the past 8 years, at least a dozen layers have been bolted on to java to make it do things such as CORBA, native method invocation (JNI), dynamic web page rendering (JSP), database communication (JDBC)...and the list goes on and on and on. Microsoft isn't exempt from attempting similar things w/ their database programming centric language, VB. who doesn't want to try and forget about ActiveX Documents, and the dreaded Declare statement for native DLL invocation. they even took it a step further by using VBScript for Active Server Pages, which was actually a decent bridge to where we are now with .NET and web programming...but it quickly outgrew itself as a viable internet programming solution. the Java platform itself has remained relatively unchanged since its' inception 8 years ago, aside from all of the bolt ons mentioned above (which really aren't a part of the jave platform itself). Microsoft realized that the entire Win32 programming model needed an overhaul to make ANY kind of programming consistent across the board, hence the advent of .NET. virtually any kind of application you want to develop, and the API's are there. they were quickly heading torwards the same kind of fragmentation that now plagues java, and i suspect that the java crowd will get a revamped platform sometime in the near future, and will be exposed to the same learning curve that VB programmers faced when .NET first appeared on the scene. java isn't a programming language, it's a platform, just like .NET is a platform. if one were so inclined, you could easily write another programming language to program against the java platform. the 2 camps (Sun and MS) each preach different advantages to the 2 platforms, and they are both somewhat viable. sun speaks of code portability (more on this later in this post), and MS preaches multiple programming languages targeted to the .NET platform. quite honestly, i agree with sun's approach much more than i believe in MS's approach, however with the coming of MONO, .NET will be just as portable (so they say). while i agree that language independence is a great sounding feature, the language itself is the easiest part to learn, all you have to do is pick up the syntax (there is a peculiar language called Eiffel that has been ported to .NET, eiffel forces a methodology known as coding by contract, which makes it a bit tougher to just spend a weekend reading a book to learn as you really need to learn this methodology to get the most of the language)...but i think you see my point. regardless of what language you learn, you MUST learn the .NET platform and API's which is definitely no trivial task. at last count, there were over 2000 base classes and types in the .NET framework, perhaps significantly more. so in my opinion, that defeats language independence. on to sun's promise of code portability and platform independence. that statement alone is a paradigm, and almost an are indeed tied to one! java has been ported to almost every type of OS out there, so you do get some independence there...but any reasonable java programmer knows that true code portability is a myth in the java world. what has happened is all the vendors (BEA, IBM, even Sun themselves) have bolted on vendor specific features, and this has led to a SEVERELY fragmented platform, any non-trivial application will need to be rewritten somewhat (and perhaps completely if you change out app servers)...that is not portability, and not an example of thier "write once, run anywhere" slogan. Sun has lost control of the platform, and it's up to the vendors themselves to sort it all out. the vendors ultimately would like to keep customers on their specific implementations, so the likelyhood of that happening is pretty slim. as i say that, i've read that BEA and IBM are forming an alliance to address just perhaps the vendors will end up playing nice with each other. it could be a little too late though as again, any changes they make to thier specific implentations will need to be propogated throughout current application already written (which is a substantial amount).

    so, more about code portability and sun's implementation (through my warped .NET eyes at least). sun really does have a vision w/ the prospect of platform independence, however by virtue of this, the java platform suffers from HUGE perf issues. having that extra layer of abstraction from the OS warrants that, plus java is an interpreted language, similar to how a parser sorts through a scripted language. nothing is compiled down to machine level code until the last second...reports have shown java bytecode to be up to 20% slower than native code. this is something that will be quite dificult to overcome as sun would have to target a compiler for each platform they wish to run java on...this would be a maintainability nightmare from their end, and is certainly not a feasible solution. microsoft has the advantage here by being able to target their native platform (windows and win32), code is compiled down to a near native byte set. herein lies another key difference between the two platforms: sun licenses the java runtime (leaving vendor specific modifications wide open), whereas microsoft has published the CLR as an open spec, making it easy for anyone who wishes to author a compiler to run against .NET...they are tied to the .NET framework guaranteeing a consistent programming model across the board (so long as the implementor wishes to remain CLR compliant).

    it's a matter of choice, as it's always been. sun definitely beat everyone to the punch when it comes to a simplified programming model, however it was too little too soon, there is simply no way they could have ever planned that java would have to morph into what it's become today. microsoft had the advantage of being able to learn from java's mistakes, and to be able to bake in new technologies that weren't even dreamed of when java made it's debut. it's my opinion that web services and SOA (service oriented architecture) will be the true definitions of platform independence. true independence results in the underlying workings being completely hidden from the consumer...web services definitely are a first class citizen for this type of behavior.

    this post has gone on long enough (for now...), so i will conclude it with this: THERE IS ALWAYS MORE TO COME!!!

  • cup of cobol anyone?

    lmfao so, here we are at the end of the year...for financial institutions that means tax time. the company i work for has a parent company...apparently a large company by the name of "Regions Bank"...their tax system is written in COBOL (Can Only Be an Obsolete Language?)'s based on a *very* fixed field file. 2071 bytes wide, it is my task to translate this to a .NET string parsing app...let the games begin! gonna be a whole lot of messy string concats, stringbuilder is my friend!

    more to come
  • Common .Net Interview Questions

    Here is a list of some common questions I ask potential candidates when screening for interviews (and no, I don't expect answers as in depth as I've listed here):

    What are some of the objects exposed by the .NET framework that lend themselves to asynchronous method invocation, and what are a few ways architecturally to use these objects? What is the name of the interface used primarily as a way to check on an asynchronous method call?

    The simplest way to execute a method asynchronously is to start it with BeginInvoke, do some work on the main thread, and then call EndInvoke. EndInvoke does not return until the asynchronous call completes. This is a good technique to use with file or network operations, but because it blocks on EndInvoke, you should not use it from threads that service the user interface.
    Waiting on a WaitHandle is a common thread synchronization technique. You can obtain a WaitHandle using the AsyncWaitHandle property of the IAsyncResult returned by BeginInvoke. The WaitHandle is signaled when the asynchronous call completes, and you can wait for it by calling its WaitOne. If you use a WaitHandle, you can perform additional processing after the asynchronous call completes, but before you retrieve the results by calling EndInvoke. Bear in mind that the call to EndInvoke will block the calling thread unless the asnychronous method call has completed.
    You can use the boolean IsCompleted property of the IAsyncResult returned by BeginInvoke to discover when the asynchronous call completes. You might do this when making the asynchronous call from a thread that services the user interface. Polling for completion allows the user interface thread to continue processing user input, thus this is the preferred way for a GUI to call an method asynchronously.
    If the thread that initiates the asynchronous call does not need to process the results, you can execute a callback method when the call completes. The callback method is executed on a ThreadPool thread. To use a callback method, you must pass BeginInvoke an AsyncCallback delegate representing the method. You can also pass an object containing information to be used by the callback method. For example, you might pass the delegate that was used to initiate the call, so the callback method can call EndInvoke. If a callback has been specified on the BeginInvoke, it will be called when the target method returns. In the callback, the EndInvoke method is used to obtain the return value and the in/out parameters. If the callback was not specified on the BeginInvoke, then EndInvoke can be used on the original thread that submitted a request.
    Name a design pattern you've used on a regular basis, and explain why you've used it and how it lent itself to accomplishing the programming task you were trying to accomplish. (there are numerous answers, if they name one and can talk about it for a minute or 2, that should suffice). Common ones will be Singleton, Factory, Observer, Asynchronous, Disposable, and Controller.

    What are the similarities/differences between interfaces and abstract classes? When and why would use either one, and name a specific instance when you would use one and not the other?

    Interfaces support multiple inheritance, whereas you can only inherit from one abstract class.
    Abstract classes support partial to full implementation, whereas interfaces only define a contract with no implementation.
    If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
    If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
    If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
    If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

    What are 2 ways to facilitate the passing of objects across application domains via reflection? IE, there are 2 seperate programming constructs that can be used to enable objects to passed across application domains, a default class by itself cannot be passed across app domains. HINT: one is an attribute, the other is a base class.

    You can mark the object with the Serializable attribute. Bear in mind that this will in turn make each and every member of the class serializable as well. If you need to implement partial serialization, inherit from ISerializable and just serialize the members you need to...or use the NonSerializable attribute on those members. An object that is serialized across application domains is done so as a copy of the object (similar to ByValue), so this can be an expensive proposition with larger objects.
    If you inherit from MarshalByRefObject, you will get the same desired end result, however instead of a copy of the object being transported to the remote application domain, a proxy will be created that facilitates communication between the objects. When an object derives from MarshalByRefObject, an object reference will be passed from one application domain to another, rather than the object itself.

    What are the 2 transport protocols that can be used in .NET remoting? What are the 2 transport payload types? What network scenarios are each combination best suited for?

    SOAP payload via HTTP protocol. The HTTP channel uses the SOAP formatter by default and hence can be used in scenarios where clients will access the objects over the Internet. Since this approach uses HTTP, accessing .NET objects remotely through a firewall is enabled by this configuration. Objects exposed in this way can easily be configured as Web Services Objects simply by hosting these objects in IIS. Clients can then read the WSDL files of these objects to communicate with the Remote object using SOAP. There is an associated performance hit as SOAP payloads are quite a bit larger than their binary counterparts.
    Binary payload via TCP protocol. The TCP Channel uses the binary formatter by default. This formatter serializes the data in binary form and uses raw sockets to transmit data across the network. This method is ideal if your object is deployed in a closed environment within the confines of a firewall. This approach is more optimized since it uses sockets to communicate binary data between objects. Using the TCP channel to expose your object gives you the advantage of low overhead in closed environments. This approach cannot be used over the Internet because of firewall and configuration issues.

    Last one...what are some of the key fundamental differences between C# and VB.NET?

    VB.NET doesn't support operator overloading.
    C# is case sensitive.
    C# instrinsically supports code comment sheets via XML tags.
    You can write unsafe (C/C++ style) code in C# code blocks.
    More explicit casting is necessary when writing in C#.
    VB.NET supports optional parameters.
    In VB.NET, parameters are passed by reference by default, whereas in C# parameters are passed by value.
    Method level vars must be initialized in C# (even if it's with a null type), whereas in VB.NET there is some leniency with this.
    VB.NET supports the With [typeName] construct, allowing for multiple actions to be performed on a type in one block.
    VB.NET does not support unsigned numeric primitives.
    VB.NET supports re-allocating an array (ReDim).

    Nothing too too complicated, but i feel they are .NET fundamentals.  Comments are welcome!

  • First thoughts on C# Generics...

    as i'm sure everyone has seen, the next version of C# will include compile time support for super late binding...also known in the OO world as Generics. since even the early VB days, in order to achieve this type of functionality (albeit at run-time), we would use variant types, or in the .NET world, object types...then just supply several overloaded methods based on the actual type of object passed in. not only does this lead to severely repetitious coding, there is a severe performance penalty involved w/ casting, and in a lot of cases, boxing/unboxing. there is a really cool tool dev'd by MS at this link: this will show you just where the perf penalties are. in most cases, next to casting from object types, string concat's are 2nd in the performance hit category (see my earlier post on the StringBuilder object). this tool is basically a query analyzer type tool, but for managed code.

    anyway, on to generics. it's quite the buzz in the managed world of .NET right now, and for good reason. instead of expensive runtime checks, and the associated non-type safety associated w/ those checks, we can now define methods that in effect supply the same runtime functionality of supplying object types and casting to the correct type...AT COMPILE TIME! this is a godsend to component developers, and the amount of redundant code this will save is pretty incredible, this will have a HUGE impact on polymorphism. i can think of literally hundreds of classes i've written that could benefit from generics, and code bloat would shrink dramatically.

    take for example the framework i wrote for tricking class libraries into thinking that they have a .config file. there are several way to let this class lib know where it lives so that it knows where to search for a .config file (path reference, assembly reference, etc), however each one of these requires a seperate cast from a type of object to the desired type. you can write overloaded methods for each type, or write a generic method accepting an object ref, then testing whatever is passed in to see exactly what the heck it is (and truth be told, there is probably some way that someone would want to pass a reference in that i haven't thought of), then perform the appropriate cast to the type you need. that is very tedious work, trying to predict what other coders are going to why even attempt it? generics to the rescue! :-) in a future post i will re-write my .config class library to take full advantage of will have to wait for my copy of whidbey to get here though. i will also be posting soon on the other additions to the C# language...

    more to come...
  • longhorn pt 2...

    I managed to dig up an old HDD, wiped it clean, and got longhorn installed on it. at an idle after a clean boot, it sits at over 600 mb of RAM (though i am sure there is plenty of debug code in this release). first impressions are pretty good, though i can't seem to find the option of having an address bar displayed in windows explorer, which is definitely NOT a good thing as i cut and paste path names on a very regular basis, especially when trying to use MSBuild. i successfully wrote and built my first XAML app (an obiquitous "Hello World" application), and then built it using MSBuild. at this point, one of the advantages i see to using MSBuild and external build configuration files is that it moves the AssemblyInfo class out of code and into a common XML format. other than that, it's just one more file i have to keep track of, though i am sure some more benefits will reveal themselves to me. i am not a huge fan of command line building, so i will hold off on more coding until i can get my hands on Whidbey. i am extremely excited about the "reclassing" of the Win32 API though, from what i can tell Longhorn will be one of the first truly OO OS's ever produced, the .NET framework will no longer be just a wrapper around the arcane Win32 API's, they will all be promoted to first hand .NET classes. i would expect that code performance will increase substantially b/c of this as well. a question i have is will further updates to the new .NET Win32 API be realeased as new versions of the .NET framework for backwards compatibility, and for code portability (MONO is becoming more and more of a reality every day, and MS isn't objecting to it at all). i have read that indigo will be released as a seperate download for prior OS's, which is a good thing, however will it just be a wrapper in itself? all in all, it seems pretty stable for a pre-alpha release...but i haven't really banged the OS too hard yet.

    so i sit here blogging on an OS that won't even be released for at least 3 more years (if it ships by 06 we will all be pleasantly surprised).

    more to come...
  • longhorn...

    So i've been attempting to get the pre-alpha longhorn installed to no avail. don't attempt to install it on virtual PC, it doesn't pick up any of the host's hardware.

    more to come...
  • Late night ramblings...

    Been gone for a bit, very busy building some prototypes, mockups, etc. and trying to learn everything i can about longhorn. it's pretty amazing that this many people are this hyped up about technology that won't even be available for at least 2 years. a friend of mine is getting a pre-beta of longhorn, whidbey, and yukon. i cannot freakin' wait to take it for a test drive! apparently the push from the boys in seattle is going to be one markup language for any front end GUI...which sounds great and all, but i hate GUI stuff so i don't really know how much that will impact me. they call it XAML and it looks quite impressive. what is grabbing my attention more than that is WinFS and Indigo. more on that later...

    one of the things i have noticed in ASP.NET apps is a severe lack of intrinsic ability to provide users a look at what's going on for long running processes...status notifications, etc. given of course that anything over 30 seconds running shouldn't be GUI based, however the need will arise occasionally to do some sort of long running query or whatnot from an ASP.NET page. have a look at the prototype i am working on here:

    it's 1AM, long day tomorrow. i am still fighting w/ autobell about them killing my porsche :-|

  • doh...

    So, there you are...sitting somewhere with the woman of your dreams...or perhaps about to win your the game you've been playing for 48 straight, whatever...just plug in your dream situation. then it hits you...FUCK, I WROTE THAT CLASS WRONG!!! that is just what happened to me, except i was in the middle of a seinfeld episode i had never seen before (yeah, i am lame)

    so, i wrote that singleton object that exposes all the elements of a config file via static properties...DOH! that was the wrong way to do it! erase all of the static keywords in AppConfiguration, and replace any calls to the singleton class w/ AppConfiguration.Getconfig (the previous way was simply AppConfiguration.[whatever]...

    live and die by the code
  • Ramblings...

    how are we american programmers getting displaced by thousands by foreigners? if they program in VB, they almost have to learn the entire english language just to use it! ok, that was a cheap shot...but still...

    come on america...step it up! where else can you not work for pennies a day living in a shanty and be grateful for every second of it!

  • T-SQL nightmares...

    So, i've been given the task of scrubbing some data for a group at my work. apparently they have about 50 records w/ either invalid zip codes or invalid SSN's. writing regular expressions in C# is a snap, however i have to load this data into an excel spreadsheet, so it would be a lot easier to try and validate the data on the server with T-SQL. have you ever tried to do string parsing with T-SQL? there is absolutely no way to check and see if it's going to work until you hit the little green play button in SQLQA...

    this is gonna be a fun one...

Copyright © ::
External Content © :: Respective Authors

Terms of Service/Privacy Policy