In stark contrast to the Sauce Reader sale that I blogged about yesterday, today I found out that meta-search engine Jux2 is for sale on eBay and bidding was over $27,000 with 5 days remaining in the auction:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7554979251
Jux2 was voted Best Meta Search Engine by Search Engine Watch in 2005. According to the eBay listing, the seller sees a lot of business opportunity with Jux2 in the meta search segment of the search industry. Bidders seem to agree. I would be concerned about why the seller was willing to let the technology and brand go in a no-reserve auction. And now that the bidding is climbing, I am concerned that the winner might be sorely disappointed. Unlike Sauce Reader, I suspect that Jux2 could be built for less than what it is going to sell for (seller says one person-year of development time went into it). I hope the brand is worth it.
I have posted before about Sauce Reader. It used to be my preferred feed reader and blogging tool (then I got slack about reading blogs and started using IE7 for reading and the .Text Web interface for posting). Sauce Reader is a nice 2-in-1 piece of software with a well-designed interface and compelling features. A while ago Synop, maker of Sauce Reader, closed for business and put the Sauce Reader brand and source code up for sale. As of this posting (Oct 20, 2005) it still has not sold.
Frankly I'm a little surprised that no one has snatched it up for $10K, which was the starting bid when it was posted for sale on eBay. I've seen posts that claim the price is much too high in a software category where people expect things for free (or at least very, very cheap). But Sauce Reader does a boatload of good stuff and has a number of inspired features. If you were to hire a high quality professional developer and pay $75K per year, you would get about 7 weeks of effort for $10,000 (assuming no other costs, which is absurd). I don't think many developers could build, stabilize, and fully test a Sauce Reader clone in 7 weeks (certainly not C# AND Delphi versions).
Of course I will concede that blogging software is generally a labour of love. There are not that many people out there hiring developers to write blogging tools for the desktop (as far as I know). But Sauce Reader also had some degree of brand recognition and good will. I guess I'm just a little surprised that nobody has looked at the Sauce Reader offering of code + brand and had a lightbulb moment about how to cash in on it.
That being said, I'm not ponying up $10K for it. But my plate is full running a consulting company and pursuing Project Elm, The Vortex Project, and a Web-based church software suite that does not have a name or codename - we just called it "the church software" (we're open to suggestions).
The recent Atlantic Canada Code Camp was a success. Although attendance was lower than what I had hoped for, the end-of-day evaluation forms were quite positive. A big public THANK YOU to the speakers. They were:
- Dan LeClair (Multi-lingual Web Applications)
- Sebastien Aube (ASP.NET 2 Membership, Profiles, and Roles)
- Mike Mullen (Creating a Single Sign-On System with PHP)
- Jordy Lutes (Using Interfaces to Unleash the Power of .NET)
- Anthony Greene (Increasing Confidence with NAnt and NUnit)
At the Atlantic Canada Code Camp I was talking with a gentleman who wanted to iterate through the MenuItem controls in his form (WinForms) so he could act on specific menu items that followed a certain naming convention (I believe it was to provide English and French versions for the menu text – but it might have been so he could change certain labels to “Mystery Meat”, I don’t recall). The scenario as I understood it was that varying subsets of standard menus would be used on many forms. Hand coding the label lookup operation for each MenuItem on the form would be tedious and prone to human error.
Everyone’s first instinct is to loop through the Controls collection and look at the Name property of each control that is a MenuItem. But the MenuItem class does not expose a Name property. A proposed solution from an online forum was to inherit from MenuItem and expose a property that could be used in lieu of Name (like a Tag property – the MenuItem class is a grumpy old miser so it does not have one of those either). Of course the inheritance approach would require everyone on your team to use the derived control and manually set a special property for every menu. Yucky. Not to mention that the true Name of the control might be different from the “name” someone provides.
Hopefully everyone on the team is already giving their menu items a meaningful name: mnuEditCut instead of MenuItem16. If you can get everyone to follow a naming convention, you should be able to loop through the menu items and use the name to lookup the appropriate text value for the menu. But I just said that the MenuItem class does not expose a Name property. Holy shatner! They’re not making this easy on me.
We know that the form (let’s call it JimmyForm) has member variables holding references to all of the MenuItem objects:
Private Sub InitializeComponent()
Me.MainMenu1 = New System.Windows.Forms.MainMenu
Me.mnuJimmyFile = New System.Windows.Forms.MenuItem
Me.mnuNewJimmyLegs = New System.Windows.Forms.MenuItem
Me.mnuOpenMouthInsertFoot = New System.Windows.Forms.MenuItem
Me.mnuGetMeOutOfHereJimmy = New System.Windows.Forms.MenuItem
Me.mnuHelpTopMenu = New System.Windows.Forms.MenuItem
Me.mnuHelpMeJimmy = New System.Windows.Forms.MenuItem
Me.mnuAboutJimmy = New System.Windows.Forms.MenuItem
Me.ListBox1 = New System.Windows.Forms.ListBox
Me.Button1 = New System.Windows.Forms.Button
Me.SuspendLayout()
The information we want is there but we aren’t provided an easy way to get it. We need some way to get a list of the member variables of our JimmyForm. We want our JimmyForm to be introspective – to look upon itself and ask, “Of what do I consist? From what am I made?” We want JimmyForm to reflect upon its inner workings. Wait, did I just say “reflect”? That’s interesting. There is a System.Reflection namespace that I’ve noticed in my Intellisense dropdown when I’m instantiating System.Random to decide how many hours to work each day.
You can use reflection to find out all kinds of things about classes and objects. The code below uses reflection to get all the declared instance properties of the JimmyForm type. Then it loops through each property and retrieves the value of that property for the current instance of JimmyForm (p.GetValue(Me, Nothing)). If the object we get back is a MenuItem then we have a menu and we know its name (p.Name). We’re cooking with propane now!
Dim typeOfThisForm As Type
typeOfThisForm = Me.GetType()
Dim props() As System.Reflection.PropertyInfo
props = typeOfThisForm.GetProperties( _
Reflection.BindingFlags.NonPublic + _
Reflection.BindingFlags.Public + _
Reflection.BindingFlags.Instance + _
Reflection.BindingFlags.DeclaredOnly)
For Each p As System.Reflection.PropertyInfo In props
Dim menuCandidate As Object
menuCandidate = p.GetValue(Me, Nothing)
If TypeOf menuCandidate Is MenuItem Then
Dim menu As MenuItem = DirectCast(menuCandidate, MenuItem)
ListBox1.Items.Add(p.Name)
menu.Text = menu.Text.ToUpper()
End If
Next
Disclaimer: If I was building this type of app from scratch I would dynamically generate all of my menus programmatically instead of creating them in the Forms designer.
Just a brief follow up on my experience with Tom Bihn (http://weblogs.asp.net/derekh/archive/2005/08/19/423035.aspx). I decided to buy a Brain Cell and I am so thoroughly pleased it isn't even funny. I love this thing. It perfectly holds my Toshiba M200 tablet PC, power adapter, and Logitech V500 mouse that I tote back and forth between home and work. Money well spent. And the Tom Bihn customer service folks were excellent. Great stuff!
Microsoft is FINALLY going to build PDF support into Office. It's about time... I've been using the PDF995 virtual printer driver for several years now and it does everything I need but it doesn't support (as far as I know) a number of features that make the PDF format really interesting. Microsoft is promising Office "12" PDF support will be better than what I can get with PDF995. Frankly I'll be happy to not have to install the PDF995 driver every time I repave my laptop or desktop machine (don't even get me started on why my DriveImage image is failing on my desktop machine this week. grrrr....).
I'm sure this is not great news for the PDF995 folks as Office-users-wanting-a-cheap-way-to-export-to-PDF was probably a major part of their customer base. But like we say around ArdentDev, if you target the masses you are just testing out the market for Microsoft or Google. Anyway, here's a snippet from the Microsoft Press site about the Office "12" PDF announcement:
PressPass: Will Office “12” PDF documents support any features other than the “printed page?”
Sinofsky: Office “12” will output PDF documents compatible with any PDF viewer that supports version 1.4 of the specification, such as Adobe Acrobat 5.0 or later. PDF documents created with Office “12” can contain live hyperlinks. Office “12” PDF documents will be accessible to screen readers as well. In addition, PDF documents produced from Microsoft Office Publisher “12” will include support for pre-press specific functionality, such as CMYK color models and printing page marks. PDF documents created with Office “12” will not support Adobe DRM or password systems. Microsoft SharePoint Products and Technologies will be able to index PDF documents for use in enterprise content management scenarios. As we are still planning on shipping Office “12” in the second half of 2006, some features may still change.