A very good article by Paul Thurrott on licensing Exchange ActiveSync to Google.
Especially apposite for as at the moment as I think about moving away from Exchange and moving our e-mail platform over to Gmail.
What’s particularly interesting about the way that Microsoft has done this is that they have licensed the technology to allow Google to plug into Exchange on the back-end, cf. to most licensees of this technology who look to get their devices to talk to Exchange.
Pretty impressed with the data that you can get out of DomainTools – e.g. http://whois.domaintools.com/mbrit.com.
We just took “delivery” of another dedicated server for a project we were doing and this time used a differnet hosts to the ones we usually use, mainly because for this project we needed cheap. (I’ll post who they were once I have some confidence they are any good!) The install ClamWin free-of-charge, which I had never heard off.
ClamWin bills itself as “open source anti-virus”. For me, anti-virus seems like the sort of thing that *needs* to be commercial because surely you need to pay a team of developers to research and build fixes for new malware. I wasn’t, and am not, immediately sure how you do that on a free model. Googling around for them I came across their Wikipedia article.
At the bottom they provide a link to Virus.gr (http://www.virus.gr/portal/en/), which runs a comparative test of the different products. ClamWin comes in 37th with a 55% detection, which I guess is better than 0%, but still… not good.
What surprised me more was the rest of the list. The Top 10 were:
1. G DATA 2008 version 18.2.7310.844 – 99.05%
2. F-Secure 2008 version 8.00.103 – 98.75%
3. TrustPort version 2.8.0.1835 – 98.06%
4. Kaspersky version 8.0.0.357 – 97.95%
5. eScan version 9.0.742.1 – 97.44%
6. The Shield 2008 – 97.43%
7. AntiVir version 8.1.00.331 Premium – 97.13%
8. Ashampoo version 1.61 – 97.09%
9. Ikarus version 1.0.82 – 96.05%
10. AntiVir version 8.1.00.295 Classic – 95.54%
But, wow, basically what’s the target here? I would say that a 2% miss rate was too high for this problem. Now, most of those I had not heard of, but what really surprised were:
20. McAfee Enterpise version 8.5.0i – 86.57%
23. Norton 2008 – 83.34%
…and Trend, which we use in the office:
33. Trend Micro Antivirus+Antispyware 2008 version 16.10.1079 – 67.28%
…and seeing as Trend have just started nagging me about our yearly subscription being elapsed, goodbye to them. Oddly on our production servers we use Kaspersky, mainly because I found Trend a nightmare to manage and irritating and Kaspersky not so.
The latest Virus.gr tests are here:
http://www.virus.gr/portal/en/content/2008-06%2C-1-21-june. Others can be found from the top navigation. Digging around, Kaspersky has been around the top in previous years.
Makes you think thought, because you assume AV from the big name providers would perform the best…
Most of the projects that we undertake at MBRIT involve integration of some sort between two systems. Whenever I write up the technical proposals for the systems, I’m always faintly embarassed to recommend hooking the two systems together using XML documents submitted over HTTP/HTTPS. It always *feels* like the wrong way of doing it, which I presume is way back in 2001 when .NET was getting started Microsoft pitched it primarily as a way of building Web services. That primal part of my brain that remembers that early history has a reaction that using non-SOAP methods for moving data about in that way is unprofessional.
However, given that almost eight years of water has passed under the bridge, and actually a lot of end-points are very non-SOAPy. I can’t remember the last time I came across a non-Windows end-point that uses SOAP. Most of them use what I have recently discovered is called a REST interface – i.e. post a document over HTTP/HTTPS.
I also happened across this article with Tim O’Reilly on Web services cf. REST. Worth a read… http://www.theregister.co.uk/2006/04/29/oreilly_amazon/.
So there I am, gone midnight, trying to fix a showstopper bug for a customer dem tomorrow.
What comes to my rescue *again*, Fiddler – http://www.fiddlertool.com/fiddler/.
If I had to pick the best developer tool out there, I would absolutely pick Fiddler as my number one choice.
The SANS Institute has released a list of the 25 most dangerous programming errors – here: http://www.sans.org/top25errors/.
What’s interesting about the way they have produced this list is that they are not pitching it as “these are bad, so don’t do them” rather they are pitching it as being a helpful list from four perspectives. The first perspective they pitch is that it gives customers of software intelligence about how to select software that is likely to be more robust. Personally, I think this is quite an interesting way of looking at the problem as I sit on both sides – i.e. I’m generally interested in how people build software, but I am also interested in how people buy and sell software as that’s my day job.
The other perspectives are more classical – i.e. help developers build better software, but also help people coming into the industry know how to build better software from the get-go.
In my time as software developer, I have ended up building a lot of strange esoteric applications, but a requirement received from a customer meant I spent some time last night building a DNS server.
The requirement from the customer was that they operate two servers, and each of their customers (”end-customer”) is “homed” to exactly one server. From time-to-time they need to move a customer from Server A to Server B. At the moment each end-customer connects to a URL like http://servera.foo.com/application/customera/default.aspx. The problem is that should an end-customer need to move to a new server they have to change the configuration in an application running on the customer’s site. This can almost certainly never be done in a hurry – sometimes it can take weeks.
The requirement from our customer was that the application installed on the end-customer’s computer would call into a Web service which would return the IP of the server to connect to, update the local configuration and away you go. Basically the “switching” server would always stay in one place.
And as I was thinking about that I thought that there was already an established technology that takes a name and turns it into an IP… DNS. This would mean that customers could configure themselves as http://customera.foo.com/application/customera.aspx and obviously the physical location of customera.foo.com would be transparent and could change. This approach removes the need for any weird or complex code and allows the right protocol to do the heavy lifting.
Not knowing off the top of my head any DNS servers that allowed queries to come out of a database, I wondered how hard it would be to build one. The answer was “not hard to do, but hard to come across the information required”. RFC1035 was *eventually* discovered offered the required information and I was somewhat blown away by the fact this RFC is 22 years old. I started by building a DNS client that would do “A” lookups against our in-house Microsoft DNS. Once I broke the back of building the client, a DNS server that only answered “A” queries for a known domain was relatively straightforward.
That said, driving back home it did occur that running BIND and creating a utility that dumped a new configuration file periodically would probably be a more robust, production-ready solution! But at least I got to build something I had never build before…
A perennial problem that I have in the office is worrying about backups. It of course doesn’t matter how many copies of something you physically have in the office, you can only solve the burglary/fire/flood problem by getting a copy of the data offsite. And you would think that with bandwidth being as cheap as it is these days that would be easy – but it isn’t as our data is too “chunky” to get offsite each night. What I want is one snapshot of a point in time of the operational databases that we run (one for source control, one for project management, one for invoicing and finally Exchange) copied offsite each night, but the reality is that we cannot get one of those databases offsite in a single night because they are all too big. In addition you have the problem of where to put it – i.e. where do you put the backups so that you can get them back easily should the office burn down.
We have solved one aspect of this problem using Jungle Disk and Amazon S3. For those who do not know, one of Amazon’s strategies is to expose its own IT infrastructure to the IT community in general as a paid service. One aspect to this serviceis Amazon Simple Storage Service (S3). For virtually no money, you rent space on Amazon’s servers.
We use Vault for our source control, and we have a separate application that monitors the Vault database for new labels. When a new label is found, the code under the label is retrieved and written to a folder. This means that we can go to our file server and see a list of every project and every build and grab the source when we we need it.
So, the problem with S3 is that you can’t just expose it as a fileshare, which seems to me to be a missed opportunity, but then again it is supposed to be a Web-based resource so you can understand that. What Jungle Disk does is exposes your S3 account as a network fileshare. This means that you can access it directly in Windows Explorer. What we did was modify our utility so that when the label was “got” from Vault, it would create a zip file (using #ziplib) and copy the zip file over to the file share and dump it straight up on Amazon’s servers. This means that customer source code is copied safely offsite the moment the developer sets up the label within Vault.
The only caveat is that Jungle Disk’s developers for some reason have not implemented it as a Windows service, which means that the shared network drive is only available whilst the user is interactively logged in. Whilst there are many utilities out there for hosting a regular executable as a Windows service, frankly I could not get any of these to play nicely with Jungle Disk and so we have a machine setup to logon as a local user and lock the console immediately.
The other nice thing about Jungle Disk is the licensing. For “desktop” use, you can install it on as many machines as you like providing it accesses a single S3 account. They also offer a “workgroup” option, which is something like $2/user/month which is more “proper” for corporate use.
My next objective is to stream SQL Server log files over to S3 to create a log shipping/offsite incremental backup of our databases. Then it’s just offsite Exchange to solve – although really I wonder whether some cloud-based solution for that is a better long-term plan.
