Updates and Announcements
Advice to Young Programmer
In response to a Google+ group question, "Hey guys! Does anyone have an tips on how to pre-plan a library or a program in general?"
, I wrote the following:
Just some general ideas:
Consider what you want it to provide
Consider best architecture/language/audience for purpose
Develop use cases
Abstract from the concrete as much as possible
Consider objects, properties, methods
Consider the relationship between objects
Consider the limitations of your choices
Build logging/debugging/messaging in from the beginning
Prototype and validate your ideas before implementing
For myself, I like to head out to a coffee shop and draw my app, the UI, the classes and relationships, and messaging between components. It looks a bit like a UML diagram.
I recently built a first release Excel add-in for a portfolio manager to retrieve somewhat large data sets (50K rows by 85 columns). The PM's requirements were speed, query flexibility, and small UI footprint. This size is not normally a problem, but there are limitations in .NET when dealing with Excel. I have separate libraries for threaded SQL execution, desktop logging - there are better off-the-shelf products like Log4Net - , and query table management. The architecture is Model-View-Presenter since that both works well for this kind of app, but also provides an upgrade path to a Web UI. The Excel UI is a mixture of Ribbon groups and a separate task panel.
I searched to find best methods for dynamic SQL that avoided SQL injection, as well as experimented a bit to find a fast method for retrieving large data sets to Excel via .NET. I used a query table, native to Excel, which provided several requirements natively.
OpenXML Document Cache for Office Apps
Working in either VB, C#, or VBA, you can add hidden data to Excel workbooks, which I am finding useful to store information about queries executed for PM's/traders. An MSDN article
Additionally, here is some >helper code in VBA
and in C#
I have created to read and write the XML.
VBA versus .NET
During a LinkedIn discussion on the value of VSTO add-ins, I wrote about a recent experience choosing between .NET and VBA for Excel:
Some recent reasons I decided to use .NET over VBA:
Asynchronous operations and threading
Version control, both via TFS and on users' desktop
Developer understanding - many shops know C#, not VB (VBA)
One recent reason I needed to revert to VBA:
A portfolio manager needed over 49,000 rows executed and returned to a sheet. When using .NET I could easily uses events to have data retrieved off-hours, execute multiple queries simultaneously and asynchronously, cache the data, and use LINQ to filter it, but VSTO took 40 seconds to write the data, while VBA took seconds. Even though I had all that power with .NET, that slow worksheet dump killed the use of .NET.
: I eventually found a solution in .NET.