OK it's been a while since I did any real blogging lately, here's a sum-up:

• I've still forgotten how to blog. While this is my blog and I can post whatever I want, this blog has become a high-level geek toy discovery dump rather than a software development blog. While I make no apologies for this--I can do whatever I want here--I'm trying to figure out if I should fork my blogs, one for serious software development discoveries and one for shallow geek discoveries. I've already been wishing I could add a personal blog somewhere, not here, and post thoughts and feelings about non-tech stuff. (This is something I used to do but it got carried away so I boycotted it and focused on purely geek speak here. I miss doing personal blogging though, and I feel like it would be good for me to do it again, if I'm just a bit more careful.)
   
• I keep mentioning the LION Search Service, how we intend to open source it, and how it's been cancelled, and then I deleted that cancellation post, etc. It keeps coming back and going away and coming back again. Well part of that is just the reality of how it's being treated at the office; open sourcing LION required all-or-nothing support on the part of my teammates at the office, and I was getting really pointless "I'm building my own search service instead of yours but I'm gleaning ideas from yours" feedback from others on the team. Lately, though, they've discovered that what they were doing was accomplishing the same tasks as what I had already implemented, and in the absence of time availability they reverted and have adopted LION. So LION is back, the team has adopted it, and we're about to go live with our first faceted-searching web site using LION (a couple other web sites were already using it but without the new faceted searching). It's now a lot more official, LION is our exciting new search platform going forward.
  
  So,
  • LION is a nearly-sort-of-enterprise-class search engine, written in C#, currently in development, built on Lucene.NET, and its continued development is being inspired in part by the Apache Solr project (but was conceived and put into production before Solr was discovered).
    • It currently offers
      • rich, paginated queries with field and index selection,
      • Lucene.NET break-neck speeds,
      • faceted searching,
      • strong document modeling, and
      • dynamic updates (currently limited to index A/B switching but that will be improved soon).
    • It currently runs on WCF (.NET 3.0). Not BizTalk or anything otherwise weird or expensive to support. It currently does not have, but will soon have, REST and AJAX support.
    • It does not have and might not ever have the high availability "server farm" feature set that I believe Solr offers. Service stability and uptime has been a constant thorn in our sides, so rethinking and possibly rewriting portions of the service itself is going to be necessary before we put it out there for the world to consume in open source.
    • It is currently not, but soon will be, built around IIS 7. Right now it's just a standalone console application, wrapped in a Windows service.
  • We will still be open-sourcing LION, eventually. Right now it's looking like a late-summer or fall time frame.
  • LION will be "internally sourced" first, to be shared to other departments in our large and disperate company, to be evaluated and discovered first. (I think this is very wise, just something I didn't think about until the boss said to do it that way.)
  • LION has been made a team-shared ownership; since I built it on the job, there's little I can do to stop the boss from handing it to a certain other team member and telling him to own it, which would be totally unsurprising. While I wouldn't agree with the situation (I've only put my heart and soul into LION, and I'm also the oldest and most experienced person on the team, even if I have a couple areas of technical weaknesses), a situation like that is not something I can change without throwing the baby out with the bathwater, and I'll live.
      
• I've been thinking about engaging in one or more side projects I would wholly and independently control. Given the big ideas I have, I'm still not sure I want to do one, though, as it's all a lot of work, some of it very tempting to try to bring into the workplace, and I don't want my authortitative work to be disrespected in the workplace like LION has been. Even so, the ideas are still on the table for consideration
    
  • BlogObjects - I registered BlogObjects.net back when I registered PowerBlog.net (I wrote in VB6 and rewrote in C# a commercial blogging desktop client application about five years or so ago, with zero commercial success but significant personal/professional technical growth for myself) and was considering making PowerBlog's development API a set of open-source blogging tools. I'm thoroughly persuaded that this will never be commercially viable as blogging APIs are a dime a dozen, but, like PowerBlog was five years ago, starting from scratch on a client/server blogging API would be a good refresher on technology in general. This is something that, if I do it, it will be not only open source, it will also be cross-platfom to Mac and to Linux, and will also be complemented with a PowerBlog resurrection or else PowerBlog-like alternative with fewer feature (no Active Scripting [VBScript, Javascript], no team synchronization support).
      
  • CMSObjects - Taking BlogObjects to another level, CMSObjects would build upon BlogObjects's idea (but not the codebase) and add:
    • An enterprise class CMS service
    • Rich support for the Atom Publishing standard API
    • Content typing (for example, a "Story" article type, a "Video browser", a "Photo gallery", a "Product Detail" page, etc), with scripted or compiled coded definitions that support inheritence
    • Rich templating both per content type and per content instance
    • Workflows
      • Team member security (user can post, user can only read, user can only post to a particular category or to a particular URL prefix, etc.)
      • Team members' posts can be flagged for approval, and then approved by a senior editor
      • Content can be annotated, seperately from the publshed output -- ideally, the annotations can be made inline, directly inside of the content
      • Content publishing to the web can be postponed to a digital publish date
    • Content versioning 
    • Again, completely open-sourced, but more web service oriented, possibly web-driven, and much less GUI-driven (so no PowerBlog for CMSObjects except for basic blogging to a CMSObjects service)
        
  • CRMObjects - Yeah the "Objects" suffix is getting a little silly, but my short experience with Sage Software's SalesLogix exposed me to another facet of software and business technology that reflects the genuine needs of businesses in general, which is using technology to support sales and support staff. CRM can be painfully messy and awkward, but tossing together some basic building blocks might be a fun and rewarding experience, even if it is not commercially viable (way too much competition, as with blogging). Who knows, though, businesses might actually use it, and supporting it could actually become lucrative.
      
  • ERPObjects - I'll do that by myself, in my spare time. Just kidding.
      
• I have a book here on Cocoa programming. I'm curious about Objective-C, how it's a weakly typed, object-oriented C language superset, which just sounds weird (C being object oriented and weakly typed?! .. weird! .. but cool!!), I can see why the book comes right out and says that it can be extremely dangerous, I saw enough of this with VB6 programming's suport for weak typing and evil Variants in my past, but keeping in line with C linguistics and C power, I'm very curious about it. I'm guessing that Microsoft's answer to Objective-C is C++/CLI, but the CLI in itself is still strongy typed, so you have to look at integration points with JScript.NET or something (but then there's Lua, Python, etc., which the non-Microsoft community also has). I watched an introduction to Objective-C video amongst the iPhone SDK videos recently and, while it does look different, I can see how it as been used to give Mac and iPhone developers a lot of shortcuts into fast and efficient software development.
    
• Over the last two or three weeks I've become less and less excited about cross-platform development libraries and APIs, such as Mono, Java, wxWidgets, Qt4, and SDL, for a few reasons:
  • While cross-platform GUI APIs pretty actually do work across platforms like they promise, their end output is a bit less predictable and/or desirable than one might expect.
    • Choosing a GUI API that uses its own UI rendering results in software that can be predicted by the developer, but it is not predictable by the user in the context of other software. Java Swing apps traditionally demonstrated this a long while back with is blueish, proprietary look and feel, and that's not what users want. Users want software that looks and feel like the software already installed on their systems. Sometimes these cross-platform APIs, like Java, come bundled with visual schemes that simulate these operating systems, but they are clearly faked and do not take advantage of the rendering APIs already offered by the core operating system.
    • Choosing a GUI API that uses the operating system's rendering and layouts (such as how the Mac uses the Aqua scheme but also puts the main menu up on the top of the screen) does not always result in predictable rendering output. Sometimes, for example, the borders or clickable "handles" of a drop-down list sticks out further to the right, above, or below the dimensions specified by the developer, or else the text rendering inside becomes unreadable because the internal padding or inner/inset "border" that contains the content is too small on one operating system while on the developer's operating system it appears fine. Sometimes there is somehow a mismatch of pixels to DPI, and the GUI code is using one unit of measure while the OS has adopted another, and so some "defensive layout programming" needed to have been written but wasn't because the developer's operating system didn't have this or that feature. And so on.
  • Java and C# are both still too slow for my liking, and other non-native languages are not mainstream enough to feel confident in building around with the knowledge that others can help carry the torch.
  • I've found that some cross-platform software applications that use generically cross-platform dependencies such as SDL are actually quite unstable. This doesn't mean that SDL et al are unstable, it just means that it is too easy for developers to build upon such a framework and not hash out platform-specific causes to application failures. There is no such thing as a silver bullet, SDL/wx/Qt/etc notwithstanding.
  • Ultimately, C and C++ (but not Objective-C) are themselves cross-platform languages, with platform-specific dependencies (and, of course, CPU-specific machine code compilation). The best thing to do, I think, is to get a handle on building C++ applications for one platform, but build things out generically enough so that platform-specific dependencis are broken off into libraries. Then, when porting the applications, you only need to port the platform libraries. This is what most cross-platform software I've seen ends up doing when they also take advantage of the features of the operating system like DirectX.
  • Another approach might be to build upon a cross-platform API first, or perhaps even a cross-platform non-native language like C#, and then port each component, piece by piece, to C++ on behalf of the native patform.
  • None of this is to say that I think wx, Qt, SDL, et al, are worthless or that I won't use them on a regular basis (if indeed I can get myself coding C/C++ apps to begin with), I'm just trying to say that there is no silver bullet and use of these libraries, rather than native Cocoa (for Mac) or MFC (et al, for Windows), would be a slight compromise for time and resources, not a magical, perfect answer for excellent software that "just works".
      
• At the end of the day, I'm still scratching the surface and barely finding time enough to sleep, much less write the software I'm envisioning. Ugh.

Today at Desert Code Camp I presented a session called A Perusal of Game Engines and APIs.  This was totally just for fun (I'm not a game developer! .. but I tinker ..)

Fun as it was supposed to be, I took some vacation time to make it happen, and I got through it (and did a moderately decent job I suppose, for getting only two hours of sleep due to cramming), but not without some hair-pulling and the near-shedding of tears.

I covered mostly open-source stuff but also the obvious stuff (including commercial bits) one can find right off the Internet. Here is my PowerPoint 2007 presentation:

http://www.jondavis.net/misc/A_Perusal_of_Game_Engines_and_APIs.pptx

One minor error I made is that I forgot about XInput (which in XNA deprecates DirectInput). I also was not certain about XACT as to whether it complements DirectSound or obsoletes it outright, but I did give a nod to XACT's asset management tool.

Now if you'll all excuse me, I need to get some sleep and prepare for tomorrow's session, An Introduction to Microsoft XNA. (More cramming...  *sigh* )