Dan Ciruli and Nathan Trueblood will be running a webinar on the Digipede Network, showing how to speed up applications. They do a great job of giving an overview of its power and functionality. The focus of this webinar will be financial applications.
Sign up to find out how our product can help you do more. Faster.
Go here for details on what will be covered and to sign up. It is scheduled for 10AM Pacific and will be about 30 minutes.
Comments off
Now that I am finished with the port to VS2005 / .NET 2.0, I wanted to point out a few final issues I came across. Note that we use the Preemptive Dotfuscator v3.0 here, but the obfuscation issues likely apply to other obfuscators as well:
New files in ASP.NET 2.0
As the compilation model for ASP.NET has changed a great deal, there are also some new files that you must deploy. Of course, this is not an issue if you use VS2005 to deploy directory to a web site, but if you are packaging up all of your files into an installer then make sure you include these new files:
In particular, I have found that if the *.compiled and PrecompiledApp.config file are not in place, your global events will not get raised.
Obfuscation Issue #1: Don’t rename __ASP
Exclude the __ASP namespace from the renamed. This is a new namespace that is generated by the compiler, so you need to exclude this in your Dotfuscator project file:
<renaming>
<excludelist>
. . .
<namespace name="__ASP" regex="false" />
. . .
</excludelist>
</renaming>
Note that there is also a new ASP namespace, but I did not have to exclude this one because I was already excluding class names that are automatically placed under this namespace. Obfuscation Issue #2: Don’t obfuscate multiple Web projects at once
Before ASP.NET 2.0, it was possible to obfuscate multiple Web projects at the same time (as long as all of the namespaces are unique across projects). The new namespaces that are generated by the compiler (i.e., ASP and __ASP) will cause a conflict during obfuscation. To solve this problem, you need to break up your obfuscations into multiple projects.
This last part is somewhat non-trivial (or at least a real hassle). I have written many nant scripts that take build output and assemble them into a directory for obfuscation, breaks up the Dotfuscator configuration file, runs multiple obfuscation runs, and finally reassembles the files into individual folders for release.
I am not going to blog on those specifics, but if you are interested in my solutions to these problems, feel free to contact me.
Tags: .NET, asp.net, dotfuscator, vs2005
Comments off
I have posted a bit on merging ASP.NET 2.0 (without aspnet_merge) and also on renaming ASP.NET 2.0 auto-named assemblies. My first solution on renaming was incomplete in that it would only work when there were no dependencies between the renamed assemblies.
This solution is correct and produces assemblies that properly get through Dotfuscator 3.0 / and actually run! All of the code below are either nant targets or nant tasks. These should be generally applicable (with the right properties assigned).
These targets assume the following properties are set:
- ProjectPath
- the path to your build project directory
- ildasm
- the full path to the ildasm executable
- ilasm
- the full path to the ilasm executable
The first part is disassembly (the most straight-forward part):
<!-- disassembles all App_Web assemblies to il -->
<target name="disassembleAspNet20Assemblies" >
<foreach item="File" property="assembly">
<in>
<items basedir="${ProjectPath}\bin">
<include name="App_Web*.dll" />
</items>
</in>
<do>
<exec program="${ildasm}"
workingdir="${ProjectPath}"
commandline=
"/out=${assembly}.il /nobar /raweh /utf8 /quoteallnames /linenumbers ${assembly}" />
</do>
</foreach>
</target>
The second part is to change the files to point to the new name:
<!-- Renames a generated-assembly for ASP.NET 2.0 -->
<!-- 'page' property is a representative page or control in the folder -->
<!-- 'fixedAssemblyName' property is the new desired name of the assembly -->
<target name="renameAspNet20Assembly">
<loadfile property="loadedPage" file="${ProjectPath}\${page}" />
<!-- get the assembly name from the representative page -->
<regex pattern="(?'assembly'App_Web.+\s*)\042" input="${loadedPage}" />
<!-- store the assembly name to fixed name mapping -->
<property name="${assembly}" value="${fixedAssemblyName}"/>
<!-- copy all of the pages (and il), replacing this
assembly name with the fixed name. -->
<copy todir="${ProjectPath}/tmpBak" overwrite="true">
<fileset basedir="${ProjectPath}">
<include name="**\*.as?x" />
<include name="**\*.dll.il" />
<exclude name="tmpBak\**" />
</fileset>
<filterchain>
<replacestring from="${assembly}" to="${fixedAssemblyName}" />
</filterchain>
</copy>
<!-- copy them all back -->
<copy todir="${ProjectPath}" overwrite="true">
<fileset basedir="${ProjectPath}/tmpBak">
<include name="**\*.as?x" />
<include name="**\*.dll.il" />
</fileset>
</copy>
</target>
Finally, the assemblies must be reassembled:
<!-- Reassembles all the App_Web*il into a new fixedAssembly. -->
<!-- This requires that the il's assembly name exists as a property that maps to the new fixedAssembly name.-->
<target name="reassembleAspNet20Assemblies" >
<foreach item="File" property="assembly">
<in>
<items basedir="${ProjectPath}\bin">
<include name="App_Web*.dll.il" />
</items>
</in>
<do>
<!-- get the old DLL name -->
<property name="dllName" value="${path::get-file-name-without-extension(assembly)}"/>
<!-- get the old assembly name -->
<property name="assemblyOnly" value="${path::get-file-name-without-extension(dllName)}"/>
<!-- get the new, fixed assembly name -->
<property name="fixedAssemblyName" value="${property::get-value(assemblyOnly)}"/>
<!-- reassemble -->
<exec program="${ilasm}" workingdir="${ProjectPath}"
commandline="/out=${ProjectPath}\bin\${fixedAssemblyName}.dll /dll /res=${ProjectPath}\bin\${dllName}.res ${assembly}" />
</do>
</foreach>
</target>
Then, for each folder, I call the target like so:
<!--Dissasemble the assemblies-->
<call target="disassembleAspNet20Assemblies"/>
<!-- use Administration.aspx as a proxy for the site's root directory -->
<property name="page" value="Administration.aspx" />
<property name="fixedAssemblyName" value="App_Web.ControlRoot" />
<call target="renameAspNet20Assembly" />
<!-- use Login.aspx as a proxy for the site's Secure directory -->
<property name="page" value="Secure\Login.aspx" />
<property name="fixedAssemblyName" value="App_Web.Secure" />
<call target="renameAspNet20Assembly" />
<!-- use Headers.ascx as a proxy for the site's Control directory -->
<property name="page" value="Controls\Header.ascx" />
<property name="fixedAssemblyName" value="App_Web.Controls" />
<call target="renameAspNet20Assembly" />
<!--reassemble the assemblies-->
<call target="reassembleAspNet20Assemblies"/>
Comments off
After much speculation by many (on whether or not it would be before the 7th), it is available.
This is good news for those of us exhibiting at the VS launch — we will be able to show off the Digipede Network from the final Visual Studio.
Comments off
Last night, Dan and I went to the geek dinner Dave Winer hosted for Robert Scoble. While I’ve been to many parties and dinners full of geeks, this was my first “geek dinner.”
There was an interesting mix of people: entrepreneurs from Web 2.0 startups, various software developers, many bloggers, and other assorted geeks.
The highlight of the evening for me was the discussion that started just before the restaurant closed. We adjourned to the parking lot to continue until it became too cold and too late (although, apparently Robert and Steve Gillmor kept it going for another hour and a half, see Geek dinner Gillmortastic). It was a little challenging to get Steve Gillmor’s entire point, although I guess Robert finally got it after we all left.
The conversation was, I think, a typical one: why Microsoft doesn’t get Web 2.0 (i.e., how Google will beat Microsoft). Steve Gillmor has some pretty strong views about the mind share that Google has regarding applications. Yet he believes that Office will lose (or has lost) the battle. It appears that he wants to see AJAX-enabled interfaces to everything. All browser-based, all thin-client.
I think the major point of disagreement between Gillmor and many others in the crowd had to do with the utility of browser-based software models. For example:
If Gillmor prefers Web-only, then more power to him. And he is right, there are many like him who feel the same way. But there are also a huge number of people (and these are not just corporate users) that prefer the installed-software model.
Google has enjoyed a great deal of popularity as an answer to Microsoft’s dominance. They have a stockpile of goodwill and trust from people simply because they are not Microsoft. This is not permanent. The bigger they get, the more profitable they are (if that’s possible), the more people they piss off with their own kind of over-reaching, the more this is going to wane.
And Microsoft is not standing still. Certainly, they’re concerned about Google (and I hope more concerned about supporting different models of user interaction than just Google). Next year is going to be a big year for Microsoft. I am not ready to count them out of this “Web 2.0″ market.
Tags: ajax, Gillmor, Microsoft, office, office12, Web2.0
Comments off
Dan is off to Code Camp in Seattle this weekend. He’ll be talking on Sunday @ 3 about grid-object oriented programming (what he calls GOOP). He’ll be talking about that and showing the Digipede Network at the same time.
If you are going to be there drop by and see him.
Comments off
Where, I don’t know. It isn’t yet on MSDN. Robert Scoble said that it (and SQL Server 2005 + BizTalk 2006) are done in Three VPs on Channel 9. Tonight is the shipping party.
Congratulations to all of the teams at Microsoft that have been working on this!
Comments off
Apparently Microsoft will be releasing a tool called aspnet_merge that will help resolve some of the shortcomings in the deployment options when precompiling ASP.NET 2.0 projects. This is supposed to be available on November 7th, but I don’t feel like I want to wait. Thanks to the DotNetNuke guys for working with Microsoft on this. I’m really surprised that it got to be so late in Microsoft’s development cycle before they figured out this was a problem.
I thought I’d try ILMerge to do it. Searching to see if someone else had, I came across this post by K. Scott Allen: Using MSBuild and ILMerge to Package User Controls For Reuse. Similar problem, different goal.
I went ahead and did this with nant as that was the quickest way for me to get this into my release process. I admit this is all a kind of a hack. First, I search for all App_Web*.dll files. Then I replace all references in the aspx and ascx files with a reference to my new merged dll. Finally, I use ILMerge to merge to the new dll. Note that I’m not merging everything, just the assemblies that have seemingly random names.
The nant code follows. It is a bit clumsy, but it works.
<property name="ProjectPath" value="${BuildRoot}\PrecompiledWeb\${ProjectName}" />
<property name="ilmergePath" value="c:\Program Files\Microsoft\ILMerge\ILMerge.exe" />
<property name="mergedAssemblyName" value="ControlMerged.dll" />
<target name="deploy">
<property name="assemblyFiles" value="" />
<foreach item="File" property="assembly">
<in>
<items basedir="${ProjectPath}\bin">
<include name="App_Web*.dll" />
</items>
</in>
<do>
<property name="assemblyFiles" value="${assemblyFiles} ${assembly}" />
<copy todir="${ProjectPath}/tmpBak" overwrite="true">
<fileset basedir="${ProjectPath}">
<include name="**\*.as?x" />
<exclude name="tmpBak\**" />
</fileset>
<filterchain>
<replacestring from="${path::get-file-name-without-extension(assembly)}"
to="${path::get-file-name-without-extension(mergedAssemblyName)}" />
</filterchain>
</copy>
<copy todir="${ProjectPath}" overwrite="true">
<fileset basedir="${ProjectPath}/tmpBak">
<include name="**\*.as?x" />
</fileset>
</copy>
</do>
</foreach>
<exec program="${ilmergePath}" commandline="/out:${mergedAssemblyName} ${assemblyFiles}" workingdir="${ProjectPath}/bin"/>
Comments off
I probably have not been clear in my previous posts about the overall methodology I’m following in our port to VS2005. I have split my porting process into several different steps to isolate the effort into manageable slices. These include:
Wrapping up the Development portion
In addition to issues I brought up in my previous post (2.0 Port Update: Mixed Progress), I have come across a few more:
On to Release builds
The release engineering process has gone fairly smoothly. I have been able to remove the hanging reference problem that is a bug in Dotfuscator (I blogged on that previously here).
I have come across a somewhat major problem regarding the new ASP.NET 2.0 compilation model (K. Scott Allen has a good article here on this subject). I like the idea that multiple assemblies are now supported by the compiler; however, the way that the assemblies are named presents a problem for anyone who has automated the obfuscation (and possibly the building of installs). My biggest issue right now is getting the three Web site projects that encompass our solution into a state where I can reliably send them through our obfuscator. I will definitely blog on the solution I come up with.
Tags: .NET, ccnet, grid, vs2005, wse3
Comments off
After spending most of the day yesterday writing specifications for version 1.2 of the Digipede Network, I spent the afternoon continuing to migrate our projects over to VS2005. This went a little slower than expected, as I fell into a trap regarding upgrading ASP.NET projects.
The Gotcha
ASP.NET 2.0 projects are organized somewhat differently from their predecessors. One major change is that the project file is gone. This makes sense considering there has been much effort to make the Web site synonymous with the project itself. This means that every web page in a folder is a part of the project. Upgrading the project is simple: locate and open the old project file (.csproj in our case). VS2005 takes care of the rest.
But what if you attempt to upgrade it directly from source control? This works as expected for non-ASP.NET projects: simply select the project folder from source control. The project and related files are checked out from source control, and the project file is upgraded. But what happens for ASP.NET?
If you open an old ASP.NET project directly from source control, VS2005 doesn’t even look at the old project file (presumably it determines it is a Web project by the existence of web.config). It assumes that the project is in the new format. You do get prompted to upgrade to ASP.NET 2.0, but you don’t end up in the Upgrade Wizard. As a result, you get an application that has not been reorganized for ASP.NET 2.0.
So, don’t make this mistake! Get your files first and then upgrade from her whole project file.
ASP.NET 2.0 Reorganization re:Source Control
Another related issue is actually a slight beef I have with the Upgrade Wizard (OK, with the decisions made regarding it).
After upgrading your ASP.NET 2.0 project, you will likely get a message that says your project has been disconnected from source control. This is due to the project being reorganized. For example, shared source code files will have been moved into the App_Code folder. The solution suggested by the Upgrade Wizard is to add your project back into source control. Yes, that is a solution.
But what about file history? I take great pains to retain file history in source control. I don’t need to go into the reasons why (as I think they are obvious). It is important enough that I have manually tweaked the source control projects to retain the file history.? This is a bit of a time sink, but again well worth it.
Why doesn’t the Upgrade Wizard offer to move these files in source control? VS2005 does support source control file move (even with a VSS 6 source control provider). It would have saved me some hassle if this was taking care of automatically.
Inconsistency with Source Control
I found an inconsistency in the way the upgrade process deals with deleted files. In at least one case, the user is prompted to automatically remove the deleted file from source control. In another case, it is left to the user to go through the upgrade report and determine which file should be removed from source control:
Tags: .NET, asp.net, grid, vs2005
Comments off
Our main push right now (aside from getting our Professional version out the door) is to finalize the specs for the next release of the Digipede Network: version 1.2.
There will be a few API improvements, many performance enhancements, native support for .NET 2.0, and more.
You might ask, what happened to version 1.1? Version 1.0 of the Digipede Networkis built on .NET 1.1. The next version will be built natively on .NET 2.0. Naturally, this version would have been version 1.1, but we felt this might confuse people. As the change from .NET 1.1 is a significant one to our customers, we felt that it might be easier just to skip 1.1.
Less confusing? I hope. Still confusing? Maybe. Misleading? I hope not.
I have always been very strict about proper use of version numbers and skipping a minor version could be perceived at a marketing ploy. That isn’t why we’re doing it, although I hope that our decision is viewed as slightly whimsical, if anything.
BTW: I was really hoping that the Visual Studio RTM would have been out last week. I need to get my development team using all of the new tools and would just as soon avoid an unnecessary tool install/upgrade cycle.
Comments off
Update: I think that Channel 9 is jumping the gun. I hear now that the RTM date is as of yet unknown.
2 more days to the RTM:
Channel 9 says the RTM will be available on MSDN Subscriber Downloads this Friday (October 14th).
And 26 more days to the launch:
We’ll be at the November 7th launch in San Francisco to show off our product with VS2005 and .NET 2.0!
This product launch has been eagerly awaiting by a very large group of people. We’re excited too. Drop by our booth at the SF launch and see us.
Comments off
I have completed my first litmus test for my planned approach for our .NET 2.0 port: that it is possible for a .NET 1.1 WSE 2.0 Web services client to interact with a ASP.NET 2.0 WSE 2.0 Web service. I am happy to report that this has worked with no trouble; however, there is a gotcha here for those intending to support VS2003’s “Add Web Reference” feature:
By default, ASP.NET 2.0 generates WSDL based on the SOAP 1.2 specification. VS2003 can only interpret the WSDL based on the SOAP 1.1 specification. I say “by default” because I assume this can be overridden; however, I may be wrong.
In terms of my overall progress, I have converted libraries, WSE clients and services, ASP.NET projects, ADO.NET clients, and Windows Services. There have been no real stumbling blocks, though I expect that the greater work will be integrating all of these new tools into our release processes.
One issue is that ASP.NET 2.0 assemblies are all compiled into an App_Code.dll. Anywhere that static references to ASP.NET assemblies exist (e.g., in the web.config file) need to be changed. This was the case for us in two sections: custom configSections and a WSE securityTokenManager. In both cases, I simply needed to change the 2nd argument in the standard full assembly name from the old simple assembly name (e.g., MyWebServices) to App_Code.
The other issue was that I had to #if out references to the PreEmptive.Dotfuscator.ObfuscationAttributes namespace as these attributes are built-in to .NET 2.0.
Other than that, everything is AOK.
BTW: I’m sticking with VSS 6 and not getting into Team System for now. I consider this a completely separate porting issue that I’ll get into later this year.
Comments off
Dan’s post (Grids? Clusters? Distributed Computing?) explains why we refer to the Digipede Network as “Grid Computing for Windows“.
Several speakers at the recent Microsoft eScience Workshop defined Grid as well and many others steered away from the term altogether. As Ian Foster and Carl Kesselman are generally credited with the definition of this term (from his book), there are many people who think of Grid as being exactly Globus. To these people, Grid means large, complex, multi-organizational, cross-platform (mostly Unix and its pretenders) computing systems that integrate sensors and visualization with distributed computing power.
As we are trying to bring simplification to this kind of computing, I wanted to steer away from calling our product a “Grid“. I truly thought it would be more confusing if we did so; however, I was wrong.
We found again and again that when we described our product we often ended with “you know, like a computing grid“. That was when people began to get it.
So, we decided to go directly to the punchline.
Of course, we have also had a few people ask us: your whole company is based on a grid (i.e., tabular UI) control? 
After some discussion about the timing of a move to .NET 2.0/VS2005, we have decided to take the plunge and natively build for .NET 2.0 for (a currently planned) release in November. The main reason we have delayed in this decision is that we need to continue supporting current and prospective customers who, for various reasons, are not ready to move from .NET 1.1.
There are a couple of things about our product that make this a bit more complicated than simply upgrading all of our VS2003 projects.:
1. We offer a .NET API to our product. Since we are committed to supporting .NET 1.1, we will have to continue maintaining a 1.1 version of the API’s main assembly.
2. The Digipede Network can instantiate distributed objects, serialize them, and return them to the caller of the API. If the caller is using the .NET 1.1 CLR then the serializing assembly cannot be running in a newer CLR; otherwise, deserialization errors will occur. To solve this problem we need to select the proper CLR based on characteristics of the caller (or, more practically, on configurable requirements).
These details are worked out (and basically functional), so what is left is integrating the new tools into development, build, and test. We have already tested it all against .NET 2.0, so there is little concern there. The CLR team has done a great job on compatibility.
Integrating the tools is (mostly) straightforward, but includes nant, NDoc, ResHacker, FxCop, Dotfuscator, NUnit, NCover, XHEO, Infragistics, NDepend, and Resharper.
Some of these are critical for our commercial release and some can be dealt with later.
I’ll continue to post about this port with any gotchas I come up with.
Savas Parastaditis gave a talk on his White Dwarfs application and the WS-GAF work he did while at University of
I chatted with him for a few minutes about MEST: like many, I am eager to read his coming paper (or book?). He has gotten me thinking about a mechanism that we use to simulate MEST-like behavior in a world where the clients are not services (nor are they assumed to be reachable from the service). Unfortunately, I can only guess if such methods for simulation are MEST- or XEST (i.e., something else altogether). I will blog my thoughts on this and see what Savas as to say about it.
I am getting behind in my blogging: I missed the second day of the eScience event, took most of Friday off and went camping with my family. What a beautiful weekend!
Here is the start of my (short) wrap-up to the event.
I think this is a reasonable place for them to focus: there certainly is a market for this pre-packaged hardware / software solution.
Patrick Hogan showed off the work his group is doing at NASA: World Wind. Think Virtual Earth and Google Earth packaged in a slick smart client layered with scientific data fetched from data warehouses from around the world. Check it out here: http://worldwind.arc.nasa.gov/download.html
He really wowed the audience with:
And more, all in a zoomable 3d view off the earth.
Plus a version of it is available for Windows Mobile!
Probably the most impressive part was that it was all done in one year by one programmer straight out of college. That says a lot about the productivity one can achieve with the Microsoft tools (it is all .NET and DirectX).
Apparently the CEO of Google praised the NASA group for the accomplishment. It took them 30 programmer years to achieve the same result.
Dan Werthimer talked a bit about SETI@Home and BOINC.
This is a very well-known project run from my alma-mater.
He talked about several ways over time that people have tried (or suggested trying) to tell extra-terrestrial life that we are here. None of these were funded. He makes the point that there was no funding until Voyager, which he called “Porno in space”. If you don’t get this, look for the plaque on the side of Voyager (or recall V’ger).
His whole talk was pretty amusing. A mix of SETI science and humor.
Tags: grid
David Lifka leads the Cornell Theory Center (i.e., the CTC). If you are (still) questioning the viability of Windows for cluster computing, you should check out the work they have done. They offer a free workshop – I went last year. Interesting content plus you get to check out their visualization cave!
He spoke about what they do there and more of the story: Windows, IIS, SQL Server, Web services, Visual Studio, . . . All together this makes an excellent platform for computing.
David brought up the problem with network load balancing (NLB) applied to distributed computing. It is transaction based. If transactions/second go down, then the server is loaded higher. Long running tasks (e.g., a large BLAST search) will have a low t/s resulting in more tasks assigned to that machine. Then you get a grinding halt. This approach works well for short transaction-based requests (think Web-sites) and poorly for computation-intense applications.
He brings this up for a good reason: many people think that application distribution can be achieved by simply implementing NLB across a set of Web servers. The answer, as is often the case, is: “well, under some circumstances, maybe.”
He also uses an alternate to the term “grid”: “Heterogeneous Wide Area Distributed Computing”. Meaning, a Grid that isn’t necessarily based on Globus.
Marty Humphrey directs the group that builds WSRF.NET.
WSRF.NET is both an alternative to the Globus reference implementation (built on Java / Tomcat) and a toolkit for developing WSRF-compatible Web services using ASP.NET. See this paper for a good overview of WSRF/WSRF.NET (note that isn’t the purpose of this paper, but it does it just the same).
The grid-standards community owe these UV guys a big thanks for taking the standards and building an alternate implementation – further validating the standards work. This proves (again) that the standard can be implemented, that it is functional, that it works and is not biased towards a specific language, application server, or OS. Of course, the implementation also provides feedback into future standards efforts.
It also validates a basic tenet of our approach: .NET is a terrific platform for distributed computing.
A great challenge for this industry is to take the excellent work done by computer scientists (and other domain experts) to solve these greatly hard problems and distill them down into something that is accessible to/by “normal” people to solve their real problems.
The standards are definitely helping make this a reality, but the tools built on these standards will really make the difference.
Robert Scoble posted some things he would consider when evaluating an acquiring company. I read his post with interest as in the past I was actively involved in the sale of a company I cofounded.
He asks if anyone else has any good advice for entrepreneurs considering a sale.
Here’s mine – I’m sure this isn’t complete, but it is a start:
My motivation for some of these questions comes from my own experience. For example, we were bought to give credibility in a new market as well as to infuse our entrepreneurial spirit across the greater company to affect more ASP-related business. We had a brand, products, and credibility that supported the acquisition. But when it came down to it, we were bought by a “numbers” company. What mattered more than anything else was that we hit our revenue targets. Strangely enough, receipts, costs, and cash, didn’t really matter. Just revenues.
That said, our acquisition was a success by the most important measure: that company (Energy Interactive) and the core personnel (outside of the founding executives) continues to this day as a somewhat independent group, selling the same / similar products into the same industry.
Now, I don’t mean to imply by any of my suggestions that I believe that these criteria particularly apply to Microsoft; however, I do think it is a good thing for the entrepreneur to investigate these (and many other) issues when evaluating an acquisition.
Tags: acquisition
Here at the Microsoft eScience event – my special thanks to the organizers. Apparently I wasn’t registered! No problem – they will get me a badge during the break.
Jim Gray kicked off the event with a historical view of science – that we have now gone into the era of data analysis. This is clearly the case in many different scientific domains: the sheer amount of measurements being taken, collected, and stored is phenomenal. Analyzing this data.
He described how on a 15-20M astronomy project (I think he was talking about the Sloan Digital Sky Survey (http://Skyserver.sdss.org), up to a 1/2 of that is spent on software development. This doesn’t count the programming done by the astronomers! Certainly, some of this software development includes that related to the science, but most of it is the development of an entire distributed computing system to support this one project.
His point: the tools aren’t good enough yet. I agree that this is true across the grid/distributed computing domain. There is too much computer science and IT skill necessary to build and maintain these systems. We are trying to make this easier in our own domain.
I hadn’t heard Jim‘s pragmatic side: He talked a bit about how we computer scientists need to engage the domain experts in science:
Replace “domain experts in science“ with customer, and Jim Gray sounds like a sales manager! Maybe we can get him hawking the Digipede Network!
FriendFeed Status
About me
Main feed
Email subscriptions
