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

Jayson's Blog

  • 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?)...it'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 do...so 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 generics...it 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...
    j
  • 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...
    j
  • 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: http://jaysonknight.com/asyncwaitstate

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

    cheerio
  • 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
    j
  • 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!

    whatever
    j
  • 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...
    j
  • Follow up for a previous post...

    I had previously posted a blog on 10/28 about how to get a class library to dynamically find it's own config file...then i realized that i didn't give any instructions on what to do next as far as loading that config file into some sort of object so that your application can use it!

    Personally, i would load the configuration file into a singleton object. per msdn documentation, the C# code for this would be:

    class Singleton
    {
    public static Singleton Instance() {
    if (_instance == null) {
    lock (typeof(Singleton)) {
    if (_instance == null) {
    _instance = new Singleton();
    }
    }
    }
    return _instance;
    }
    protected Singleton() {}
    private static volatile Singleton _instance = null;
    }

    i personally find this a bit wordy and complex for what we are really trying to accomplish here. we need one object to share common properties with any subscribing assemblies, for the most part this information isn't going to change, so why waste round trips instantiating a new object each time your assembly needs a property! then i remembered that static types are guaranteed to be type safe, so why go through all that tedious locking code when you can simply do it all in one line, like this:

    public sealed class AppConfiguration
    {
    public static readonly AppConfiguration GetConfig = new AppConfiguration();

    ...

    voila! it's as easy as that, you now have a shared instance of your object. bear in mind that all member vars and methods/props will need to be static as well. so now it's time to load our configuration settings. there are numerous ways to parse through an XML document, but again for simplicity (and avoiding looping through the document and storing values in arrays of strings), XPath queries seem to be the easiest way to query for your settings. We go on in our code to creat a *private* constructor (so no one can instantiate your singleton), this will only get called once for the lifetime of the object...

    private AppConfiguration()
    {
    ... [code to load the config file into memory, see my previous post on the 28th...

    XmlDocument getConfig = new XmlDocument();

    try
    {
    getConfig.Load(_configFileName);
    _someMemberVar = getConfig.SelectSingleNode(
    "configuration/appSettings/add[@key='ValueYouWantToLoad']/@value").Value;

    ...repeat for all elements
    }

    now simply expose the member vars as readonly properties, now all calling code can easily read configuration settings.

    more to come, it's 6:05PM and i am still at work :-( friggin' long running queries keeping me here late again.

    cheerio
    j

Copyright © :: JaysonKnight.com
External Content © :: Respective Authors

Terms of Service/Privacy Policy