Sysconfig's Blog » Software

Why do Twitter clients use Adobe AIR?

admin — Sun, 21 Jun 2009 11:56:50 +0000

@tkramar raised the question on Twitter, why every desktop client for that service seems to be built on top of Adobe Air (here). That’s something, I also was wondering about. And in fact you often hear people complain: “Why AIR? Why not a native application?” Let me try to give the answer while having breakfast.

First we need to look at what Adobe Air is: It is a run-time environment, ported to all common operating systems, which allows to run applications built with Adobe Flex on almost any desktop rather than embedded with a browser (where you can run the same applications with little or no modifications using the well-known Flash Player Plugin).

So, we know that AIR developers use Flex. Why is that? That’s as easy to answer: Flex targets front-end/GUI designers in the first place. Together with Flex, Actionscript, and Flash, you can build quite neat and shiny user interfaces. Most of the “business logic” (I know that sounds funny in this context) is not part of it though. The strength of Flex is to use external data sources like web services. On the one hand, it’s certainly a limitation, but on the other hand that’s exactly why it’s being used for Twitter clients, which don’t do much more than using Twitter’s API (web service) to display tweets, subsets of tweets, search results, friends and stalkers (erm followers, of course).

So if you want to bring a desktop application to the market, which heavily depends on web services, Flex is probably one of the fastest ways to get there. And Adobe AIR brings the application to the desktop — on all common operating systems.

Yes, it’s proprietary software, and closed source. However, anyone can use it free of charge (the Flex SDK is free, the not required Adobe Flex Builder is not). Pretty similar to PDF and Flash. But the licensing policy is another discussion, anyway.

Octopus — Logging Server in C#

admin — Sat, 06 Jun 2009 19:21:21 +0000

I have to admit that I really like C#. The last 4 or 5 months, I’ve hardly touched any other programming language. And so it happened to be my first choice when I was asked to develop a “reasonably fast” logging server.

So what is this Octopus thing about? In a nutshell it’s a server, which takes HTTP requests with a defined set of URL parameters, confirms receipt the client, and then asynchronously stores the request into a database. The interesting bit is the part between accepting the request and storing it to the DB.

Basically, we’ve got three levels of storage: a in-memory queue, a flat file buffer, and the database. The tricky thing was to optimise processing, while still being fault-tolerant. I kind of managed that, I think. Octopus can (depending on the hardware it runs on) easily accept up to 2,000 requests per second, and will store them into either a MySQL or SQLite database at the moment. Please read more about it on the Octopus Website.

PowerDNS w/ MySQL — should have tried earlier

admin — Sun, 14 Sep 2008 21:23:19 +0000

I was quite fed up with BIND (zonefile editing, serial number increasing, master/slave setups), so I was searching for alternatives to run Master/Slave DNS services. More or less randomly, I again came across PowerDNS. Again, because I have heard a couple of times that big providers quite often use it. So I decided to give it a go. On FreeBSD it’s quite easy. You just install it together with its MySQL modules, activate the modules in the configuration files, import the database schemata, and fill it with content. A script to import BIND zone files directly to the DB is also included. Couldn’t be easier.

Once you’ve set it up and got it running, you of course need a slave server as well. So all you got to do is either to install another PowerDNS/MySQL instance on another machine and connect it to the same database (you wouldn’t really want to do that), or connect it to a second MySQL server, which ideally is a replication slave of the first one. Then you have a fully redundant setup and don’t need to worry about failures of either of those. All DNS record changes go directly to the master DB server, which will be picked up by the slave in almost real time. Plus, you don’t need to worry about serial numbers. Change a record in the DB and this change will be published instantly.

If you fancy web interfaces, you can either go for an open source one, or you can write one on your own. As the DB structure of PowerDNS is kept very simple, it’s easy to add/modify records via script also. Do whatever you want and don’t worry about the stupid restrictions and configuration hurdles you used to run into when going for a BIND server.

SPF — Sender Policy Framework

admin — Sun, 25 May 2008 15:31:35 +0000

Did you ever receive spam mails which seem to originate from your own mail address? Or did anybody else complain about you sending those emails? Then you should take a look at SPF. In a nutshell, it plugs the holes in the SMTP protocoll, which does not allow to verify if a sender (or anybody who pretends to be that sender) really may use a particular mail server to transmit their mails. Unfortunately, SPF is not yet very wide-spread. Almost everybody (including me) has come across this abbreviation and/or heard that it might protect misuse of mail addresses. But most people (including me) cannot be bothered to implement it.

But as I took a closer view at it recently, it turned out to be a pretty simple task. Only people with loads of domain names and/or restricted nameserver control might run into problems.

In a nutshell, you only need to do this in order to get SPF running on your own server and to tell other mail servers how to deal with your domain name:

add a policy daemon to your MTA (e.g. postfix-policyd-spf) — pretty easy, really!
add SPF/TXT records to your zonefiles as described here

That’s it, honestly. Assuming, you have successfully finished the two tasks, your mail server will block all mails that originate from domains, which have SPF records set and been delivered through other than the allowed hosts. And your domains will be protected from being misused on all other mail servers which use SPF as well.

Example:

example.com.       IN MX 10  mail
mail.example.com.  IN TXT "v=spf1 mx -all
mail.example.com.  IN A 1.2.3.4

Now, mails from johndoe@example.com must be delivered through the mailserver mail.example.com. All mailservers which implement SPF will refuse to accept mails from other than that server. Especially the big players like Googlemail do make use of SPF. Although some don’t block mails, they at least add a telling header which makes spam-filtering easier:

Received-SPF: fail (google.com: domain of mail@***.co.uk does not designate
85.***.***.*** as permitted sender) client-ip=85.***.***.***
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of
mail@***.co.uk does not designate 85.***.***.*** as permitted sender)
smtp.mail=mail@***.co.uk

So what are you waiting for? The more people make SPF mandatory on their servers, the better is its protection against SPAM.

Syncing calendars on multiple Macs and Nokia N95

admin — Thu, 24 Apr 2008 14:49:19 +0000

Generally it is quite easy to sync calendars between one Mac and a Nokia N95 (or any other model). All you need is iSync and the Nokia iSync Plugin. The setup is quite straight-forward. But as the computers store the synchronisation information, conflicts are very likely to happen. So we need another solution to keep two (or more) computers and a mobile phone in sync.

The answer to this problem is the Google Calendar. It is capable to send/receive data in iCal format (which is necessary for the Mac). More precisely: It is able to send iCal data. To receive it, an external tool is needed. I chose SpanningSync which integrates seemlessly into the System Preferences Panel and automatically keeps the Google Calendars and the iCal in sync. It is safe to do that with a second Mac and the Google Calendar as well. See the web site. It is a very neat tool which costs only US$ 25 p.a. for as many Calendars and Macs as necessary. The final step is exporting the information to the Nokia N95 (or any other model) using iSync from one of the Macs only.

With this setup all Macs and one mobile stay in sync. To be honest, I do not login to the Google Calendar at all. I can add/edit/remove appointments in iCal on one Mac, and after syncing the same information is available on the other Mac as well. Google Calendar is only used as an easy way to automatically transfer the data.