What if there was a monetary charge for inefficient code or software?

I was briefly looking at yet another JavaScript framework this morning. It was backed by a Ruby engine for optimal “MVC goodness.” Having never measured the performance of Ruby, I’m not going to claim Ruby’s fast or slow; but I will say that it’s unlikely that it’s as fast as a compiled language.

It got me to thinking — as more and more people (from big IT to homeowners) try to save energy as the costs of energy continue to rise, …

What if the act of running an (installed or web) application incurred a precise monetary fee for the amount of energy it consumed (possibly measured as CPU time)? Certainly, there’s already a charge for electricity today, which is not precisely measured …

Poorly written applications, CPU burners and I/O thrashers bug me the most when using a laptop with only a battery. But what if web hosts charged that way, or applications you “rented” as software as a service charged for “use.” The more unreasonable the charge, the more likely users will complain about performance.

(Thinking to my self about how FAST my PC is sitting under my desktop, but how fast Windows 3.1 would boot on it vs. Windows or Mac OSX).

Are applications just becoming more and more bloated, or truly better?

Why Opera 9.5 still isn’t my default browser

Using this page as an example:

http://msdn.microsoft.com/en-us/library/aa973757(VS.85).aspx

(Powershell)

Internet Explorer 7:

image

Firefox 2:

image 

Opera 9.5:

image

Note how the library tree is not open in Opera — which in the example of MSDN makes browsing the content very difficult. Alas, I don’t know why it’s broken — but it is and I won’t use it. Maybe version 10? :)

Shout out if there are reasons you use Opera…

An amazing (incredible!) Javascript achievement

From 280slides.com… another web-ized PowerPoint wannabe.

image

Definitely an impressive Javascript only application — broadband definitely recommended:

image

They’re using Amazon S3 for PowerPoint conversion (it’s funny that they have this feature, but they need it as users may not always have access to a reliable web connection when doing a presentation):

image

The developers have written a layer which abstracts browser rendering into a unified language, Objective J. For former Apple employees, it’s providing an Objective C like layer for Javascript (source here). The abstraction layer is useful — but at what cost for a new language layer on top of Javascript? There’s a lot more detail here in an interview/podcast.

Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C). Lots of square brackets. When the browser gets served .j files, it preprocesses them on the fly. This means that you can do things like, use standard JavaScript in places.

Cappuccino is the port of the Cocoa framework.

The market is becoming saturated with these products. Are you willing to pay? What if there are ads? Will you use it? For me – they’re fun to use — but if I’ve got PowerPoint installed, I’m going with that option. I might consider a service if they provide a reliable import.

(via Download squad)

Velocity — a rockin’ distributed in memory cache for ASP.NET

Velocity, the code-name for a new in-memory distributed caching system for ASP.NET was released as a Community Tech Preview today.

What is it? It’s described in the documentation:

Microsoft project code named “Velocity” provides a highly scalable in-memory application cache for all kinds of data. By using cache, your application performance can improve significantly by avoiding unnecessary calls to the data source.

By using distributed cache, your application can scale to match an increasing demand with increasing throughput. “Velocity” distributed cache is provided in the form of a cache cluster, simplifying your application code by managing the complexities of load balancing behind the scenes.

When you use “Velocity,” you can retrieve data by using keys or other identifiers, called tags.

Download for CTP 1 is here.

Run the installation — and at the end you’ll be asked a few simple starter questions:

image

The settings above can be adjusted later if you don’t like them. Unblock the EXE in your firewall settings if needed (I didn’t need to when using localhost as my destination server as shown below).

image

Installed. Create a new web site in Visual Studio 2008:

image

Add a reference to pull in the necessary settings into your web site:

image

You’ll need to reference a few assemblies. The simplest way to get them all is to reference them directly (rather than copying them as the instructions say). VS 2008 won’t complain.The following files are needed:

CacheBaseLibrary.dll, ClientLibrary.dll, FabricCommon.dll, CASBase.dll, and CASClient.dll

 

image

Next, adjust the web.config file per the instructions.

I tweaked the dcacheClient settings to match those I set when the first installed Velocity.

<dcacheClient deployment="simple" localCache="false">
    <hosts>
        <!--List of hosts -->
        <host name="localhost" cachePort="22233" cacheHostName="MyCluster"/>
    </hosts>
</dcacheClient>

I added the required sections to the configSections in web.config, and also the “fabric” section:

<configuration>
    <configSections>

        <section name="dcacheClient" type="System.Configuration.IgnoreSectionHandler" allowLocation="true" allowDefinition="Everywhere"/>
        <section name="fabric" type="System.Fabric.Common.ConfigFile, FabricCommon" allowLocation="true" allowDefinition="Everywhere"/>

    </configSections>

    <fabric>
        <section name="logging" path="">
            <collection name="sinks" collectionType="list">
                <customType className="System.Fabric.Common.EventLogger,FabricCommon" sinkName="System.Fabric.Common.ConsoleSink,FabricCommon" sinkParam="" defaultLevel="-1"/>
                <customType className="System.Fabric.Common.EventLogger,FabricCommon" sinkName="System.Fabric.Common.FileEventSink,FabricCommon" sinkParam="CacheClientLog" defaultLevel="1"/>
                <customType className="System.Fabric.Common.EventLogger,FabricCommon" sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary" sinkParam="" defaultLevel="-1"/>
            </collection>
        </section>
    </fabric>

</configuration>

Added some code, then run (the code I used is shown below).

 

Unfortunately, this is the first error I encountered:

Access to the path ‘C:\Windows\system32\CacheClientLog.log’ is denied.

Since I’m using the ASP.NET Development Server, I started an administrative instance of notepad and created a blank CacheClientLog.log file in the directory. I then set full permissions on the file for my user account (aaron in my case).

Next, I discovered that the service EXE hadn’t been properly installed. After some false-starts, I rebooted, and again, as an admin user, used the installutil.exe utility from the .NET SDK to install the service (as I had uinstalled it). Using the Services management console, I started the service, “DistributedCacheService.”

Using the Velocity Administration tool, I verified that the host was now running:

image

(Silverwindow is the name of my laptop, a MacBook Pro running Windows Vista).

For reasons I don’t understand, after rebooting, the location of the CacheClientLog.log location changed to here:

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE.

So, I repeated the task of creating the empty file and associating the proper permissions as described above (again).

Here’s what my sample application looked like.

image

In the default.aspx page for my web site, I added a few controls:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <
html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <asp:TextBox ID="txtToSet" runat="server"></asp:TextBox> <asp:Button ID="btnSetIntoCache" runat="server"
onclick="btnSetIntoCache_Click" Text="Set" /> <br /> <asp:Label ID="lblValue" runat="server"></asp:Label> <asp:Button ID="btnGet" runat="server"
onclick="btnGet_Click" Text="Get" /> </div> </form> </body> </html>

And, then in the code-behind:

using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.Caching;

public partial class _Default : System.Web.UI.Page 
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }
    protected void btnSetIntoCache_Click(object sender, EventArgs e)
    {
        CacheFactory CacheCluster1 = new CacheFactory();
        Cache cache1 = CacheCluster1.GetCache("default");

        cache1.Add("cacheThis", txtToSet.Text);

    }
    protected void btnGet_Click(object sender, EventArgs e)
    {
        CacheFactory CacheCluster1 = new CacheFactory();
        Cache cache1 = CacheCluster1.GetCache("default");

        lblValue.Text = (string) cache1.Get("cacheThis");
    }
}

 

The default cache I referred to in the test code is called default — as that’s the name that is specified in the ClusterConfig.xml file that was created during the installation. 

    <caches>
      <cache name="default" type="partitioned">
        <policy>
          <eviction type="lru" />
          <expiration isExpirable="true" defaultTTL="10" />
        </policy>
      </cache>
    </caches>    

The location of the ClusterConfig.xml file is currently specified in the DistributedCache.exe.config file, which is installed here by default:

C:\Program Files\Microsoft Distributed Cache\V1.0\DistributedCache.exe.config

Run the web application. Set some value into the cache (using the “Set” button). Get it back out (“Get” button). Shut down the ASP.NET development server. Run the application again — you’ll see how the cached value is still there (assuming you haven’t waited too long). Cool.

The cache can also store any .NET serializable object — not just strings.

Microsoft project code named “Velocity” provides a highly scalable in-memory application cache for all kinds of data. By using cache, your application performance can improve significantly by avoiding unnecessary calls to the data source.

By using distributed cache, your application can scale to match an increasing demand with increasing throughput. “Velocity” distributed cache is provided in the form of a cache cluster, simplifying your application code by managing the complexities of load balancing behind the scenes.

When you use “Velocity,” you can retrieve data by using keys or other identifiers, called tags.

Check it out for yourself. This is a great addition to ASP.NET and truly puts ASP.NET into the competitive ‘big-scale’ enterprise application market without the need for expensive third party products.