In no particular order
* I’m not maintaining a web site on http://www.hyperoceanic.com at the moment.
* All the Groove related stuff should be considered to be of historical value only
* I got a new job at the British Library, leading an Agile team that builds the systems that import the digital media (eJournals, eBooks, web archives etc) into the Digital Library System. C#, SQL Server, MSMQ being the chief skills.
I’m selling a couple of big boxes of technical books over the coming months. If you’re looking to pick up some well kept books on object-oriented programming, design or project management, please have a look.
Groove support forums user AdamK might have found the reason why Groove sometimes stops synchronizing files in shared folders – a hidden “Temporary” setting for files on your hard drive. When Groove sees this setting, it decides to skip the file, but the error message displayed does not make it clear why the file is being skipped.
Right now, Adam doesn’t know what causes the files to be marked Temporary, but he’s found a commercial utility that will reset his files, and more. Snag is, it costs $24.99, which you might not want to pay- especially if you’re planning on migrating away from Groove anyhow.
Licensed Bambuco users can email me for a script that will turn off this setting for you automatically, free of charge.
I’ve spent some recently on rebuilding Bambuco, the scripting engine for Groove that allows organisations to easily move information into and out of Groove.
If you are evaluating your investment in Groove and are looking for options for migrating your data out of Groove, we are probably the strongest-placed organisation for you to talk to. We could, for example help you
- move your documents out of a Groove files tool into a SharePoint Document Library, or into a corporate document repository, or even just a network share
- Copy your data from Groove Forms into a database or SharePoint List,
- Extract your list of Contacts and import them into Outlook.
More details here: http://www.hyperoceanic.com/services.aspx
After a brief family break, I’m back on with Brimham. The first task is to configure a new virtual machine for development – I like a separate Virtual PC install for every project so I can guarantee no version conflicts between third party stuff.
Windows 2003 Enterprise
SQL Server 2008 with all the options
MVC Contrib Release and Extras
Castle Project 1.0 RC3
I’ve been mulling over the my use of use of a third-party libraries, both long term and on my last project. On the former, a core library I use has made a disastrous UI decision that needs fixing before I can release the next version of Toucan Reporter. On the latter, the client had pre-selected a well known, mature and comprehensive looking component library that they wanted to use for both web and Winforms applications. The demo applications make it look easy to develop fantastic looking line of business applications.And its this library I want to talk about today.
It sucks. Here’s why:
1: Unmet promises. In several areas of the product, there are features that just plain don’t work in the real world. In particular, there’s a designer for quickly laying out Winforms pages. In this designer is the ability to add tabs. If you are going to use this feature, the chances are that you’re going to use it to build a form with a good number of controls on it. Problem is, that as the number of controls increases, performance goes down rapidly. If you have more than a couple of dozen fields, then you’re looking at a wait of tens of seconds as you move controls around. Part of the problem is the management of undo/redo operations. Rather than use the one built into Visual Studio, they’ve created their own, and the performance is terrible. You can turn off undo/redo, which improves things a bit, but its a hack. At some point you’ll be even more committed to this approach and you’ll be having the same performance problems. At run time, performance is great, by the way.
2: Unwanted Complexity. Controls are objects. Objects have properties, and in the .net world, there’s a bunch of standard controls with consistent properties, provided as the .net framework. The implementers of this particular library, however, used different names or different properties or different enumerations throughout their library. A stand out feature was the use of a property called ‘Properties’ that happened to have most of the useful properties for the control in it. Almost every time you needed to set something in the designer, you have to go through an unwanted step of opening up this Properties property to see the property you wanted.
3: Locked in or Locked out? The implication of having an unnecessarily complex component library is that the hapless line of business developer using the package (me) is simultaneously locked in and locked out: Locked in to the bad decision to use this library, and simultaneously locked out of the chance to make meaningful changes to the libraries behaviour. Its impossible to re-do the UI of the application to exclude the complex UI library, and at the same time its almost impossible (given the deadline for the project) to fix the library in places where the behaviour on offer differs from what is required. You’re further locked out of using other component libraries as they won’t share the same styles, making your app look a mess.
Summary: Component libraries offering increased productivity for line of business applications should never deviate from the norms for that environment. Software should be written such that any developer who knows the base technology should be able become effective with the library as soon as possible.