Did you know that:

• You can format (underline, bold, italic, etc) a word in MS Word without having to select it? Just have the cursor there, then CTRL+B/I/U
• To return to the location of the last edit in Word, you just need to press SHIFT+F5? In Visual Studio, it's CTRL - (control + dash).
• You can download arcade game resources (art, sounds, etc.) at http://themushroomkingdom.net?
• http://www.wordle.net/create enables you to create your own tag clouds?
• MS will donate to a hunger-relief organization for every download of IE8 from the site www.browserforthebetter.com?

Those are a sample of tips (plus personal thoughts, opinions and news) I’m sharing on twitter: www.twitter.com/awfurtado. See you there.

BR,
-- AFurtado

[This post is part of a series. To see the previous, click here. To understand the context, click here]

The Bing search decision engine got lots of attention these days, as being able to double Microsoft’s market share in the search business even weeks after its original release. Personally, I finally got excited by a Microsoft product in such a domain.

Other release that had some attention in the search area was WolframAlpha. As you might know, while you can use Bing or Google to do some simple computations such as measurements conversions and calculator operations, WolframAlpha is a “computational engine” by default (i.e., it computes your input towards a result rather than searching for web pages).

WolframAlpha is cool, giving interesting data as results that Bing and Google do not provide (yet?). Try “Seattle to Recife” there and you will understand what I’m talking about. For example, it can show nice mortgage graphs based on your input (loan amount, interest per year, loan period, etc.). Check it out:

As any other Software Development Engineer in Test, I tried running a couple of “unexpected” queries to check out the application behavior. What about a negative value for the total number of years for my loan period? There you go:

Effective interest rate is now screwed. Graphs and tables in such a scenario are not good either: data get collapsed to the center of the graph, or $Fail!

Since one of the coolest features in WolframAlpha is to combine multiple computations (such as “Weather in Seattle when Obama was born”), let’s go a step beyond and assign the square root of -1 as the total number of years for my loan period:

The loan period is now the imaginary number (“i”)! Isn’t it awesome? Only your imagination can tell now when you’ll be done with your mortgage! :) The computation of graphs and other stuff now takes a while and fail as a timeout. Export to PDF feature is also broken. Yay, we found another bug!

Fortunately those are minor errors which won’t avoid me from keeping using WolframAlpha. In fact, I’d love to see Bing moving (actually extending) into such a direction, i.e., computational engines. And what about enabling people to add their own computational logic, formulas and conversions to the engine? I mean, creating a computational engine leveraged by the power of Web 2.0? For example, extending Wolfram or Bing towards a universal slang translator?

PS: Using imaginary numbers to explore other interesting WolframAlpha scenarios is left as an exercise to the reader. :)

BR,
-- AFurtado

The statements or testimonies I offer in this post represent my own personal views.
I am speaking for myself and not on behalf of my employer, Microsoft Corporation.

The panel “DSLs: The Good, the Bad and the Ugly” that happened at the OOPSLA 2008 conference discussed the advantages, disadvantages and challenges from the industry and academia on the use of domain-specific languages (DSLs).

While the advantages brought by the panelists were somewhat expected (more productivity, more abstraction, etc.), the disadvantages and challenges were quite interesting and not that obvious. Here you can find a compilation of them:

• Composition (integration) among multiple DSLs (this was mentioned several times).
• Interoperability with mainstream languages.
• Key challenge: understanding the domain and defining its scope. Designing a DSL requires strong customer-driven effort. DSLs targeted at too broad domains are ineffective.
• Common error: DSLs based on solution domain (code), instead of the problem domain, therefore becoming low level languages.
• Lack of domain analysis tools and processes.
• Lack of tool support in general. Knowledge in DSL engineering was not transferred to tools yet. The engineering knowledge is out there, many times ad hoc, but it still had not come together.
• Tools are immature for iterative development and use of DSLs.
• A new language implies at reluctant customers. Although they are generally able to understand the return of investment after the using the language for a while, lowering the entry barrier is still a challenge.
• Users cannot benefit from a DSL if it has poor documentation or they are not properly trained.
• Planning and assessing the return on investment (cost-benefit analysis) is hard to perform (some panelists argued that a DSL with a generator pays off if used more than once).
• Lack of systematic approach to replicate processes related to DSLs design and implementation.
• Manually edition of generated code should be avoided. [IMHO, extensibility through other means such as partial classes, inheritance, dependency injection, etc. are still welcome]
• Programming concepts (conditional branches, loops, etc.) might be expected by the DSL users but may not make sense to the domain.
• Backward compatibility: it is hard to evolve the language when model (specs) created with it are already in place.
• Internal DSLs have a couple of additional challenges: (1) users may move out from the DSL abstractions to the host language and (2) compilers for internal DSLs have to process host language code.

BR,
-- AFurtado

Problem when deploying a ASP.NET app from Visual Studio: Unable to create the Web site ‘XYZ’.  The Web server does not appear to have FrontPage Server Extensions installed.

Solution: http://www.rtr.com/fpse/

BR,
-- AFurtado