Sunday, January 31, 2010
On the surface it seems like a simple task. Microsoft has provided some fantastic tools and capabilities with XP, Vista and Windows 7 Media Center. To maximize the functions that you will most likely want to leverage I highly recommend connecting your Media Center to an XBox 360. If you are only wanting to leverage the out of the box features of Media Center then any media extender will work fine. However, if you are looking to stream video from the internet using a service like PlayOn you will need the XBox 360.
Generally all of your set up will go according to the documentation provided from Microsoft. The primary hurtle that I had to overcome was bandwidth. I tried numerous flavors of wireless and routers to no avail. I was able to stream small wmv files but not live television of heavy video full screen mp4 or mv4 format. Which by the way you need a patch from Microsoft for and a constant live internet connection to receive. I finally found my solution in a small relatively inexpensive device from Netgear. I really wanted to avoid running Cat 5 or Cat6 through the house and it was obvious wireless was not going to make the grade. The ingenious device I found was a device that allows you to re-stream your internet traffic through the Coax cable already in your home. Note this device only works with broadband and cable delivered by cable not DSL or Satellite.
MCA1001
MoCA Coax-Ethernet Adapter
This adapter allows me to achieve up to 200 mbs speeds and the XBox reported immediately full support for 1080P HD signal. I leveraged this to essentially turn every cable connection in my house into an Ethernet port to deliver high sped internet access in every room of the house. No worries about QOS, interference or performance. I can report that I currently support four flat screen televisions streaming live television/ and or steaming video from the internet from a single Media Center PC.
In my next post I will tell you more about how I am getting television from hulu.com, crackle.com ABC.com and NBC.com as will as several other networks streamed over the internet for free instead of paying the cable company for those channels
Wednesday, January 27, 2010
Over the last few months I have been looking for opportunities to reduce the overall cost of receiving television in the home. Several factors got me thinking seriously about this:
1) I actually looked at my cable bill..- by the time I paid for internet service, basic cable, extended cable premium cable, HD signal digital signal set top boxes, digital boxes, and DVRs I could have gone to the movies every night and still had money left over.
2) Advances in internet speed continue to leapfrog 10-20 MG broadband speeds are no longer uncommon as standard offerings
3) Streaming technology have grown a booming industry in cheap and/or freely available next day media content. Sites like Hulu.com and Crackel.com provide aggregation services. CBS, NBC, ScFy, HG TV and others provide content
4) Continued price drops in Gaming systems such as the XBox360 
, PS3 
, and Wii that are becoming common place in the home and their DLNA compliance makes the opportunity to stream live media from a home computer directly to your television a reality.
5) The introduction of several varieties of media server/services that aggregate that include services like Play On 
The convergence of these four key technical innovations along with the general overall costs rising from Cable and Satellite provides has produced a unique situation where centralization of your video feed and aggregation on a ”Media Server” is not only possible but has now become a profitable proposition. In my next few posts I will discuss the process and final configuration along with the costs to build out my centralized media home server/service along with my expected break even point. As a teaser I will tell you now that I achieved amore than 70% reduction in monthly costs for services provided by my cable provider and expect to see an return on investment (ROI) in less than 3 months essentially on quarter. I do not expect that these savings can be achieved by everyone it is simply my personal experience.
There is no doubt that this technical approach to media consumption is still in its infancy and may very well evolve in an entirely different direction that the one I have taken it to. Are there problems you bet. Occasional lag time, bandwidth constraints, quality of service(QOS) contention for CPU and port access. Is it worth the occasional wait , lag or load time ??? Well let me just say that when it happens I take a breath and start counting the money I am saving . the answer – Defiantly yes a little patience for a savings of almost $200 a month I am on board.
In my next post I will elaborate on my design and equipment in use to deliver media to my home on demand without the Cable Company’s media signal.. yes I still need them for broadband but even that could change someday.
Friday, September 12, 2008
If you have ever had the need to isolate a task because it might bring down your applciation? You want to execute a task that needs a specific security context. You want isolate the task and its data. Well the AppDoamin is your new best friend.
Beginning at the beginning
To better understand .Net's AppDomain and how they affect the programs we create and work on, it'll be a good idea to start ground up. So let's start from the point we button click an application. Whenever we start an application, we're actually starting a Win32 process and running our application inside it. These processes use resource such as memory, objects, kernel so on and so forth. All processes process contains at the least one thread and if we are to run other tasks or open up other applications through our application, these tasks will belong to our particular Win32 process running on a collection of multiple threads. For WinForms applications the effect of this when executing on the UI thread can be seen when we make direct calls to long running processes. In that cause the screen to appears to lock up or become non responsive (enter the hourglass), this is also symptomatic of pre AJAX enanbled web applications. One of the cornerstones of a Win32 process is that it is very much like a closed room in your house. It's pretty easy to communicate within the room but the ability to communicate with those inthe room next to you or down the hall is problomatic. To interact with other Win32 processes, we would require some special mechanisms to work on as there are a couple of security contexts we would have to take into consideration and also the need to restrict what a Win32 process can and should given a particular set of circumstances.
Scenario
Consider the lowly desktop/ laptop in any given session at our workstations we are hosting 10's or hundreds of processes. Often we are not even aware of the wide array of processes that are working diligently on our behalf to keep the system running. Lets break down exactly what's happening in the scenario. Stepping away from the concerns of what variables are being used and how many may have the same name and who writes efficient software vs.... well enough said what are we really talking about to keep the engine running. At the crux of the issue what we're actually dealing with and what we would have to provide to these applications - Resources, resources and even more resources! The primary resource we are talking about is memory running a close second are security issues; therefore it is imperative that we force absolutely no communication of any sort between the processes of these applications. Wait what's the point of having a computer and all these applications if they can talk to each other. Ah the exception to the rule, there are frequent exceptions based on requirements, so many exceptions that perhaps that should be the RULE. Invoking these exceptional cases can and often does lead to frequent crashes. the instance where one process using up the memory allocated to another process can lead to unstable environments that eventually CRASH! I hate it! Everyone hates it! Especially customers. Anyway, our process dies,blows up, dies an unnatural death ect.. Nothing new it happens we are human after all not machines. These frequent crashes and run-time errors are usually caused due to inefficient use of memory leading to memory leaks, null object referencing, out of memory bounds you get the idea. From this example it becomes clear that running and maintaining processes are VERY expensive on a single workstation not to mention the effect this would have on oh say an App server or a Web server serving up several thousand web sites. Hence, It just isn't a good idea to use a large number of processes since they simply do not scale pretty well. So here's a pretty neat solution that was employed for the above situation. Running a host of multiple applications within a single process will enable us to use fewer resources enter the Web Server code name IIS. This would even result to faster execution. But here's another everyday scenario: in the case where one application crashes, every other application within this process goes down like a deck of cards! OUCH !! Who did that. And we wonder why system administrators are so protective of their servers?
A New Paradigm
Enter the .Net AppDomain. The main purpose of an Application Domain is to isolate our applications from other applications. Application domains run on a single Win32 process. The same solution that we just mentioned above can use an application domain and at the same time, limit the possibility of errors and crashes due to memory leaks while providing isolation, security context and protection of our application from other applications.
Hence we're running an application within an application domain and we further run multiple application domains within a single Win32 process. With the CLR's ability to run managed code, we're further cutting down on leaks and crashes. Objects in the same Application Domain communicate directly while Objects that exists in different Application Domains interact with each other by transporting copies of objects to each other or by using proxies for message exchange (by reference).
So that's the crux of an Application Domain.
Ah but theres more - It's actually a pretty neat light weight process that runs within a single Win32 process. Infact, as previously noted, we can run multiple Application Domains within a single Win32 process and much like Russian Nesstign Dolls 
Domains inside of Domains.
Why would I want to do that? Another advantage of using an Application Domain is that we can destroy it through the parent without affecting other Application Domains that exist within that Win32 process. Therfore we can extrapolate that any work occuring in that Application Domain can be independent.
Bonus Features We can also use Application Domains to unload types by destroying the Application Domain that we have loaded it into- support for dynamicloading and unloading . The amazing .Net runtime enforces Application Domain isolation by ensuring control over memory use and therefore all the memory that is used by the Application Domains within a Win32 process is managed by the .Net runtime. (Read no heavy lifting on your part) We are avoiding almost all the problems that we mentioned initially such as one application accessing another application's memory and hence avoiding runtime errors followed by crashes. What we have actually done is provide a secure execution context that isolates current applications from talking to other applications. Practically speaking, Application Domains play a critical security and functional role especially when we're creating applications that do remoting like running web services.
Now how do we create a basic application domain?
A basic AppDomain issimplicity itself. The .Net framework provides a beautiful base class that exists within the System namespace so that we can explicitly create an AppDomain. Inheriting the System.MarshalByRefObject base class into our applications, we can create objects that communicate between and across different application domains.
Here is a simple application to create an AppDomain in C#.
The output the program creates is shown below
Better Known Framework
Sunday, June 29, 2008
A short post this time on a better known framework feature in .Net 2.0 +. A funny thing happened on the way to the demo today. I was preparing to demo some code to a group of developers and needed a function I had written back in the 10 .net days. This was a thin wrapper that allowed one to read configuration information out of the web or app config or a database. Being a careful programmer instead of just including the class and moving on to the demo even though I knew the code worked I thought I better compile this just to make sure.
Low and behold it compiled but I got some warnings well .... really one. You may have seen it before [ 'System.Configuration.ConfigurationSettings.AppSettings' is obsolete: 'This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings' ]. Not wanting to look dated or to have warnings or errors displayed in the demo I decided to get rid of the deprecated method and use the new ConfigurationManager. So off to the web I went Google -ConfigurationManager , MSDN - ConfigurationManager great documentation but still I could not get it to work. What was I doing wrong.... I had a reference to the system.dll assembly I could see the configuration namespace but no ConfigurationManager. Finally, just as I am about to give up and reinstall studio 2008 assuming I have a corrupt install I had not previously noticed the solution popped up in front of me. I searched msdn for the entire error message instead of just the new class I wanted to use.. There it was http://forums.msdn.microsoft.com/en-US/vblanguage/thread/d61a57ef-552d-45cc-8326-3ca3bc113699/ just add a reference to a new assembly System.Configuration. So there you have it; that's how you gain access to the ConfigurationManager class in the .Net 2.0 and above namespace.
Best Practice Better Known Framework
Monday, June 09, 2008
A friend of mine Denny Boynton and I were talking at TechEd last week about green computing and it started me thinking. He mentioned that he and some other architects were discussing green computing platforms (server vitalization, cloud computing,etc...). That started me talking about: What is the responsibility of the software developer in this emerging green computing grid? Many infrastructure groups over the last few years have been moving to virtual servers and environments initially to save on capital expenditures slow the ever growing demand for data center real estate.
Now after establishing the foundation for vitalization operations groups are seeing tertiary benefits form this process. Additional, justifications now include floor space reduction, reduced energy consumption, and energy savings from cooling requirements for data centers. Operational support teams are encouraging app dev teams to move their custom applications to these virtual instances and if necessary to modify applications that are not compatible to leverage this ROI for the company. The primary sales points given to App Dev teams are assurance that all servers are identical and the added speed that operations groups can scale out to support. Generally there are significant advantages to this trend towards vitalization, reduced surface space, reduced capital expense, lower maintenance cost, lower energy costs, higher reliability and scalability definitely a WIN WIN. That said how do we ensure that this continues to be a wining proposition.
What is the responsibility of the software developer in this new landscape? How can we ensure that this trend continues. I have developed and designed architecture for software for the last several decades. Over that time period I have increasingly heard comments like "we will just get more servers" and "memory is cheap" have become all to common. That along with approaches to application development that involve wide and deep data structures because "we don't want to go back to the server" for the data later, because we are lazy and don't want to make the extra call bloat our applications. Approaches and architectures like this will never preserve these new found savings we have found. We must change our approach to applications development. We should not avoid taking the extra steps necessary to ensure that we minimize our server footprint. Thoughtful design and architecture that ensures features are delivered to applications without excessive round trips to servers or the transmission of additional unnecessary data overhead are initial steps we can take. As developers should actively look to new technologies to improve user experience and reduce custom and non standard communications channels. In the .Net development space we should pursue WPF, WCF and Silverlight technologies to reduce the complexity of future applications. We should also actively review and seek opportunities to exit from legacy non mainstream Microsoft platforms. Finally, we need to proactively lobby vendors to include the features that support that enables developers to concentrate on productive business functionality and less of plumbing applications and injecting potentially faulty, difficult to maintain code that tightly ties applications to their deployment paths and infrastructure.
Architecture Best Practice Programming Design