Friday, November 02, 2007 |
|
|
Those without an investment in other editors would do well to investigate Open Komodo, a free as in speech editor based on the good as in good Komodo editor. |
|
|
|
|
Saturday, October 20, 2007 |
|
|
With the release to public beta of Popfly, Microsoft's mashup editor, I'll reiterate my theory that mashups are the UNIX shell of the Internet. The corollary is that we need a suite of command equivalents: | Command | Mashup Alternative | | cd, mkdir, rmdir | facilities for manipulating "current URI"; REST principles, etc. | | mailx | messaging transformations and transports: mail, IM, SMS, twitter, etc. | | man | ? | | jobs, ps, kill, sleep, etc. | facilities for multiple mashup control | | ls | spidering facilities / robust HTML parsing, etc. "Get-ChildItem" in all its polymorphic complexity. | | who | FOAF | | finger, chfn | blogging | | cat, sed, sort, grep, wc, tail, etc. | All sorts of facilities for transformation of source to sink | Right now, everyone's concentrating on what output the mashup editors can produce or what the component manipulation looks like. I think the winner of the mashup evolution will be the one that provides the most flexible suite of components. |
|
|
|
|
Friday, October 19, 2007 |
|
|
I'm tempted to label as "shocking" the announcement that F# will become a product fully integrated into Visual Studio, but I suppose it would be hard for anyone to ignore stuff as compelling as this. F# is a derivative of OCaml and is a functional programming language. Those who delve into my language-related or concurrency-related posts will be familiar with the concept that one of the great advantages of functional languages are characteristics that lend themselves to automatic parallelization. Microsoft is making more and more noise about functional approaches (Eric Lippert's "aside" that "Immutable data structures are the way of the future in C#." is telling.) and this endorsement of F# is another sign that Redmond is throwing its weight pretty heavily behind this approach. F# has been well-received among the hardcore language nerds but you have to give Microsoft credit for getting out ahead of the market on this one. F# is a very different beast than the Iron* languages (Python and Ruby). This isn't Microsoft reacting to market demands, it's Microsoft putting a not-at-all-well-known language into the spotlight. |
|
|
|
|
Friday, September 21, 2007 |
|
|
Intel's announced the availability of a prototype C++ compiler implementing Software Transactional Memory, one of the central topics of this brilliant .NET Rocks show. That's exciting, although I suspect that on just two cores STM will be disappointing. |
|
|
|
|
Friday, July 27, 2007 |
|
|
Huh. I just received a link in email to "my" August issue of Dr. Dobb's Journal. I'm not going to post the link I got, since it's undoubtedly linked to me, but can anyone access http://www.nxtbook.com/nxtbooks/cmp/ddj0807/index.php? It's a Flash-based interface, but even when viewed in profile, full-screen (1050 x 1680), it's annoyingly fuzzy: Which zooms in as: There doesn't appear to be any way to control the antialiasing within the Flash interface. Blech. |
|
|
|
|
Tuesday, July 24, 2007 |
|
|
John Lam details the first public availability of IronRuby. Couple reasons why I'm interested in this: - It's Ruby
- It's the CLR
- It's a second data point for how to code for the DLR
I don't think I'm going to be able to resist the temptation to write a compiler for the DLR. I know I should resist, but I spend so many cycles thinking about programming languages and the DLR seems to have so much promise to language implementors. Argh, I can't believe I have such a busy week in front of me. |
|
|
|
|
Saturday, July 21, 2007 |
|
|
Wesner Moise's NStatic static-analysis tool for .NET appears to be approaching its initial beta. Moise has made a number of exciting claims for this technology since he began discussing it about 18 months ago. If I understand correctly, NStatic involves considerably "deeper" analysis than most quality-assurance tools; it almost seems it applies the field of constraint-based programming to parsed program structures. At least, that's the only way I can get my head around this post. |
|
|
|
|
Thursday, July 19, 2007 |
|
|
You know I love my homeys at SD Times, but ought not the headline read: "Study states obvious, costs money"? 
|
|
|
|
|
Wednesday, July 18, 2007 |
|
|
I've fiddled around with the examples of GLEE, Microsoft's layout engine for graphs and wish I'd had it for some visualization projects I did a few years ago. Looks like a nice library to add to your collection. |
|
|
|
|
Thursday, July 12, 2007 |
|
|
Alan Zeichick, commenting on the release of Oracle DB 11G Beta ranks the major databases as: - Oracle
- DB2
- SQL Server
- MySQL
I've never been a fan of DB2, but Oracle DB is a rock and I would never hesitate to recommend it. (This despite my involvement with Oracle's abysmal XML-based file-system (FS? FX?) ). Of course, many .NET shops use SQL Server and I've yet to experience a real problem with that. MySQL is preferred for Rails development and, again, I've never had a problem using it. |
|
|
|
|
Monday, July 02, 2007 |
|
|
Based on comments to my earlier post, I put further work into Crystal Reports XI and SQL Server Reporting Services. Both seem capable-enough in terms of handling the data volumes and seem to have similar ease-of-use as far as the ultimate end-user goes (the inexperienced programmers who will be charged with writing reports). My take is that Crystal has more flexibility in terms of output formats, which might influence my choice. However, there's another wrinkle. The data is stored as an XML blob in the database. These are fairly hefty documents, 1-4MB apiece, with quite complex schema. But I don't want to report on a single one of these blobs, I want to report on all of them. So my data model is not-quite-XML and not-quite-relational. For instance, to use the cliched example, every record in the database contains data such as: <?xml version='1.0' encoding='utf-8'?> <book> <authors> <author>Arnold Aarnison</author> <author>Bob Billson</author> </authors> <sales>23</sales> </book>
And the reports we're looking for might be "Total number of sales of books by author" which would seem to necessitate either:
- Joining the data in multiple database rows (i.e., make a new XML document that wraps the per-database-row <book> element in a root element called, say, <books>); or
- Mapping the XML schema into a relational view (i.e., create tables for Books, Authors, and Sales); or
- Reporting that can somehow combine SQL and XPath in a single query (e.g., "Select count(myXmlColumn.Xpath(/book/sales/text()) from myTable group by myXmlColumn.Xpath(/book/authors/author/text()")
Option (1) is easy enough, but the resulting document is going to be massive -- gigabytes. I've never worked with XML documents of that size and worry (prematurely?) about the capacity / performance of feeding a report generator such a volume of XML.
Option (2), which is essentially the reverse of (1), would solve the reporting problem (since once it's in a relational structure, any reporting tool will work) and is do-able using Altova's XMLSpy "Create DB Structure from XML Schema" but I'm concerned about the amount of manual labor required (I have to define dozens of foreign keys relationships by hand -- but is that a one-time cost that's no big deal?).
Option (3) would be the ideal, but I don't think there are any reporting tools that work that way.
Any real-world experiences with similar challenges would be appreciated... |
|
|
|
|
Monday, June 25, 2007 |
|
|
eWeek is quoting an Evans Data survey in which Borland's StarTeam was rated the best source control management (SCM) software, beating out CVS, IBM ClearCase/ClearQuest, Microsoft Visual SourceSafe, Microsoft Visual Studio Team System, Perforce, Serena/PVCS, and Subversion. It's an interesting result, because surveys have a strong tendency to correlate with marketshare, but surely StarTeam does not have dominant marketshare. Meanwhile, SCM tends to be a "good enough" solution, where people generally stick with what they already have. Is StarTeam so exceptionally good that it can overcome those tendencies? Update: Evans' methodology is to survey users of the tool in question, which ought to overcome the "marketshare == survey results" problem that one gets in most "reader's choice" surveys. On the other hand, it may inflate the influence of cognitive dissonance; people invested in niche products (StarTeam has about 9% marketshare, according to BZ Research) have a psychological pressure to praise them more than do people invested in market leaders (who, after all, know the market has endorsed their decision, making criticism come a little easier to the tongue). I don't have deep opinions about SCM tools (except about Visual SourceSafe, which I despise), but I asked one of the judges in that category for the Jolt Awards his opinion. He recalls Evans "finding that among Java IDE users, the preferred IDE belonged to Rational. This struck me (and others) as being implausible, but not impossible. This survey result, however, does strike me as quite impossible." Having said that, I solicited Eric Sink (of SourceGear, a competitor of Borland's) for his thoughts and he responded in the comments section. Sink characterized StarTeam as a product that is in the category of SCM tools that are "mostly or somewhat liked" by their users. I've only used StarTeam momentarily, quite awhile ago, so my skepticism about the results may be sheer ignorance of a great product. |
|
|
|
|
Monday, June 11, 2007 |
|
|
I agree with Alan Zeichick's analysis of IBM's acquisition of modeling tool vendor Telelogic: the overlap with IBM's Rational product line is high, the acquisition "is a bid to buy market share....we’ve taken a powerful innovator and strong IBM competitor out of the market." The software development industry typically pendulums on modeling tools: excess, backlash, abandonment, code is king, frustration, some modeling helps, we can model everything, excess ... Right now, modeling is not popular. But I think it's actually passed its nadir and, if history holds, we should see modeling increase in popularity. The problem for IBM and Rational is that part of the pendulum is the embrace of new modeling graphics/languages. |
|
|
|
|
Thursday, May 03, 2007 |
|
|
Is there a product in the "cheaply deployable" range (say ~$100) that you can point at a significant SQL Server database and it parses the foreign key relationships and presents a table viewer in which the values in the foreign-key column automatically hyperlink to the relevant table? And this tool allows basic CRUD editing, searching, and sorting? Just like Access, but with navigation? (Or do I have to create a Rails app for a db that has several hundred tables? Given that Rails doesn't automatically generate the FK relationships, you're talking about days of work.) Update: I'm not talking about a tool for me, necessarily -- have SQL, can travel and all that. And, sure, with Rails I can probably turn out a dozen or so forms (maybe more) in an 8-hour day. But, with a database with ~200 tables, you're talking about me charging my clients thousands of bucks just to make simple Web pages. My requirement is ad hoc navigation through a database, with CRUD at the table level and a "development time" of no greater-than-a-day for a 200-table database. Really, very close to Access, but when there's an FK in the table the person doesn't have to say "Oh, okay, this line item has InvoiceID 256 -- open the Invoices table, search for 256 -- Oh, okay, that has a CustomerID of 538 -- open the Customers table -- let's see, OrganizationID 23 ... " Just: | LineItemID | InvoiceID | LineItemColumn | LineItemColumn2 | | 1 | 256 | foo | bar | ...where that link leads to... | InvoiceID | CustomerID | InvoiceColumn | InvoiceColumn2 | | 256 | 538 | foo | bar | ... etc ... Update: I solved the problem using Rails |
|
|
|
|
Wednesday, May 02, 2007 |
|
|
The preliminary documentation for the DLR is included in the IronPython-2.0A1-Doc.zip download at http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=438 : We're leveraging the learning we did on IronPython to extract elements that could be common amongst languages (dynamic type system, hosting APIs, cached method dispatch, symbol tables, ASTs, codegen, etc.), and we currently are working on IronPython 2.0, JScript, VBX, and Ruby to vet the common designs. We'll eventually do (or recruit people to do) PHP, scheme, and maybe one more to believe we really can move language+1 with ease to the DLR. .... Another juicy quote ... That runtime needs a great scripting story and UIFx story to compete with the virtuous cycle Flash/EcmaScript enjoy. We also watn to work with a partner on an IDE to eventually make a play for the MS app programmability story so that you can have your choice of dynamic language on a little runtime for scripting, say, Office or VS. |
|
|
|
|
Monday, April 30, 2007 |
|
|
That Microsoft was going to increase support for dynamic languages is no surprise: they've been talking about that since (at least) PDC '03 and various hires and initiatives have clearly been in the works. I haven't seen the DLR yet, but my big question is: what version / runtime / patch level of the CLR and libraries becomes the lowest-common denominator for Silverlight (i.e., cross-platform, in the browser)? Because for better or worse, that becomes the platform for dynamic languages in the .NET world. I am surprised by the IronRuby announcement (and officially bestow the He-Man Programming Award to John Lam). I really thought we were going to see some form of Ruby#:Ruby::C#:Java. Although I'm happy (Ruby is now my #1 administrative programming language), I was actually hoping to see a new language. Ruby's a fine language, but it doesn't have a good story for concurrence, it has a boring model of XML (unlike VB), it has some unattractive Perl-isms. Most importantly, I think MS does a good job when they have the flexibility to evolve the language and, simultaneously, can devote the resources to developing the compilers, libraries, and toolsets. |
|
|
|
|
Thursday, March 22, 2007 |
|
|
The easiest Jolt vote I've made in years was for stpBA Storyboarding, a product which every architect and team lead owes themselves to evaluate. I would say it is revolutionary, but it is better than that -- it simply makes the way you probably already work vastly more efficient. Essentially, it is a product that transforms screen-based storyboards into requirements and work-items. Based on (and in) Microsoft Office, you mock up screens using Visio and link them together using arrows. And then it transforms that into work-items. That's it. Simple. Obvious. Just works. I could say that storyboards are one of the few diagrams that are universally comprehensible and producible by designers, users, and developers. I could say that usage-centered design, as laid out by Larry Constantine & Lucy Lockwood, is the most efficacious way I know to elicit requirements. I could say that the downside of storyboards has always been tracing their detail to and from work-items, and so they've traditionally been a "write once" work product. But I don't need to say that, because it's all so obvious. It's really an eye-opening product -- download it, install it in a VM, you'll be happy. The only rub being that I really do mean "install it in a VM." That it is essentially a Visio plug-in is both a strength and weakness of Storyboarding. Today, it only works with Office 2003. An Office 12 version is in development, but this is the type of product that, once you've tried it, you don't want to be without. Like all Jolt judges, I make extensive use of virtual machines (the awarding of a Jolt to VMWare Lab Manager was no shock) but Storyboarding was one where I felt that tuning up a dedicated virtual machine was very much the "way to do it." Perhaps due to the opaqueness of Office as a plug-in host, getting Storyboarding up and running took a little tweaking. If I recall correctly, before I attached the VM to the Internet to register/validate Office, there was some silent error that led to features not being enabled. Also, the workflow within Storyboarding was not immediately obvious, since it relies on its own pane within Visio and the potential is not quite unleashed by "press the buttons left to right." It's not a long learning curve, but it's longer than learning Peggle. Highly recommended. (Storyboarding, not P | |
| | |