Inversely Proportional

Inversely Proportional

Some time ago I was reading www.caffeinatedcoder.com/book-review-the-c-programming-la…

[…] Since a good portion of the C# books are between the 500 and 1000 page range, it was refreshing to read a book that was less than 200 pages. Partly this is because when the book was published the surface area of the reusable API was a small fraction of what it is now. However, I also wonder if there was an expectation of disciplined conciseness in technical writing back in the late 80’s that simply no longer exists today. […]

I think this is a very important point. But then, again, it was no secret – this was written in the Preface to the first edition of that book:

[…] is not a “very high level” language, nor a “big” one, and is not specialized to any particular area of application. But its absence of resrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages. […]

I think it all boils down to simplicity, as Glenn Scott says in glennsc.com/start-a-revolution-with-confident-simplicity

[…] To master this technique you need to adopt this mindset that your product is, say, simple and clean, and you just know this, and you are confident and assured of this. There is no urgent need to “prove” anything. […]

Another similar book on a (different) programming language, is “Programming Ruby, the pragmatic programmer’s guide” which starts with

[…] This book is a tutorial and reference for the Ruby programming language. Use Ruby, and you’ll write better code, be more productive, and enjoy programming more. […] As Pragmatic Programmers we’ve tried many, many languages in our search for tools to make our lives easier, for tools to help us do our jobs better. Until now, though, we’d always been frustrated by the languages we were using. […]

Of course that language is simple and sweet, very expressive, and programmers are seen as having to be “pragmatic”. No nonsensical, incredibly complex cathedrals (in the language itself and in the documentation) – but quick and dirty things that just WORK.

But way too often, the size of a book is considered a measure for its quality and depth.
I recently read on Twitter about an upcoming “Programming Windows Phone 7” book that would be more than a thousand pages in size: twitter.com/#!/MicrosoftPress/status/27374650771

I mean: I do understand that there are many API’s to take a look at and the book wants to be comprehensive…but…. do they really think that the sheer *size* of a book (>1000 pages) is an advantage in itself? it might actually scare people away, for how I see things. But it must be me.

In the meantime the book has been released and can be dowloaded from here blogs.msdn.com/b/microsoft_press/archive/2010/10/28/free-…

I have not looked at it yet – when I will have time to take a look at it I’ll be able to judge better…

for now I only incidentally noticed that a quick search for books about programming the iPhone/iPad returns books that are between 250 and 500 pages maximum…

And yet simplicity CAN be known to us, and some teams really “Get it”: take Powershell, for example – it is a refreshing example of this: the official powershell blog has a subtitle of “changing the world, one line at the time” – that’s a strong statement… but in line with the empowerment that simplicity enables. In fact, Bruce Payette’s book “Powershell in Action” is also not huge.
I suppose it must be a coincidence. Or maybe not.

Backup or Store stuff to GMail via IMAP in Ruby

Once upon a time, I used to store some automated small backups into GMail just by having the scheduled backup send an email to my GMail account. At one stage they blocked me from doing so, marking those repeated email as SPAM.

After that, I took a different approach: I kept sending the mail on the SAME server as the backup, and using IMAP I could DRAG-and-DROP the backup attachment from the mailbox on one server to the mailbox on another server (=GMail). They did not mark me as a spammer that way, of course.
So that worked for a while, but then I got tired of doing this manually.

So the following ruby script is the way I automated the “move offsite” part of that backup.
For completeness, I will give the due credits about who set me on the right track: I started off by this example by Ryan.

#!/usr/bin/env ruby
begin_ = Time.now

#includes
require 'net/imap'

##Source Info
$SRCSERVER="mail.muscetta.com"
$SRCPORT=143
$SRCSSL=false
$SRCUSERNAME="daniele"
$SRCPASSWORD=""
$SRCFOLDER="INBOX.Backups"

##Destination Info
$DSTSERVER="imap.gmail.com"
$DSTPORT=993
$DSTSSL=true
$DSTUSERNAME="muscetta@gmail.com"
$DSTPASSWORD=""
$DSTFOLDER="Backup"

#connect to source
puts "connecting to source server #{$SRCSERVER}... nn"
srcimap = Net::IMAP.new($SRCSERVER,$SRCPORT,$SRCSSL)
srcimap.login($SRCUSERNAME, $SRCPASSWORD)
srcimap.select($SRCFOLDER)

#connect to destination
puts "connecting to destination server #{$DSTSERVER}... nn"
dstimap = Net::IMAP.new($DSTSERVER,$DSTPORT,$DSTSSL)
dstimap.login($DSTUSERNAME, $DSTPASSWORD)
dstimap.select($DSTFOLDER)

# Loop through all messages in the source folder.
uids = srcimap.uid_search(['ALL'])
if uids.length > 0
	$count = uids.length
	puts "found #{$count} messages to move... nn"

	srcimap.uid_fetch(uids, ['ENVELOPE']).each do |data|
		mid = data.attr['ENVELOPE'].message_id

		# Download the full message body from the source folder.
		puts "reading message... #{mid}"
		msg = srcimap.uid_fetch(data.attr['UID'], ['RFC822', 'FLAGS', 'INTERNALDATE']).first

		# Append the message to the destination folder, preserving flags and internal timestamp.
		puts "copying message #{mid} to destination..."
		dstimap.append($DSTFOLDER, msg.attr['RFC822'], msg.attr['FLAGS'], msg.attr['INTERNALDATE'])

		#delete the msg
		puts "deleting messsage #{mid}..."
		srcimap.uid_store(data.attr['UID'], '+FLAGS', [:Deleted])
		srcimap.expunge

	end

	#disconnect
	dstimap.close
	srcimap.close
end

total_time = Time.now - begin_
puts "Done. RunTime: #{total_time} sec. nn"

More on Ruby and IMAP

I’ve written here of a Ruby IMAP Script.

The script is INCREDIBLY simple (but it had to do a simple thing nonethless):


#!/usr/bin/env ruby
begin_ = Time.now

require 'net/imap'

if !ARGV[4]
puts "USAGE: ruby imapcheck.rb [server] [username] [password] [folder] [flag]"
exit
end

##### Variable Section
## your imap mail server
$SERVER=ARGV[0]
## your imap/smtp mail username
$USERNAME=ARGV[1]
## your imap/smtp mail password
$PASSWORD=ARGV[2]
## your mail folder (for example, INBOX)
$FOLDER=ARGV[3]
## flag to use (as per RFC 2060)
$FLAG=ARGV[4]
##### End Variable Section

imap = Net::IMAP.new($SERVER)
imap.login($USERNAME, $PASSWORD)
imap.select($FOLDER)
count = imap.status($FOLDER,[$FLAG])[$FLAG]

puts "#{count} messages with flag #{$FLAG} \n\n"
total_time = Time.now - begin_
puts "RUNTIME: #{total_time}"

There is another interesting example about this at Will’s Blog. It’s funny how people try to do the same things at similar times 🙂

Of course official doc for this is here.
But If you want to snoop at a more complex webmail application using IMAP from Ruby/Rails you should seriously check out Mailr.

Java… oh Java… (aka “High vs. Low level languages rant”)

I said here (and someone else said that too) that “Java is the new cobol”.
When saying so, I mentioned that En3pY hates Java, here it is another post by him written after I forwarded him this Joel Article (which I read from Scoble, in turn).

All in all, in this case, I tend to partially agree on some points but slightly disagree on others with Joel.

In fact, while I do acknowledge the need of “hardcore” developers to fix and build lower level things and mantain current code (and know WHAT they are doing), there are also many cases where coding in a high level language which abstracts complexity IS actually more efficient and cost effective, not having to reinvent the wheel every time.
So there are a lot of useful and nice programs written by people who DO KNOW what happens under the hood (as good in C as in Assembler), that for simplicity and flexibility run in sandboxes, high level languages, even interpreted ones! An example is Dave Aitel’s CANVAS, written in Python. But that’s just an example.

But I do agree with En3pY that I don’t like Java myself, and I consider it being too “heavy”, in general.
Solution on my side, tough, is that you don’t need C or assembler to get cleaner, smaller, more efficient code, you just need better languages. An example of this is a situation I have been involved in some time ago: in that case a colleague (that works with a very large customer who has a very large exchange deployment) needed to do some performance testing of this Exchange system. He had done the testing from some Windows IMAP clients, but the customer also wanted to see the same performance values measured from a Linux box accessing the same exchange via the very same IMAP protocol.
So I wrote a nice and sweet Ruby script – and at the same time another colleague developer a similar application (in Java).
Result: 45 kilobytes of .JAR to do the same things I did in 20 lines of Ruby (20 lines – including comments!).

On this website we use first or third-party tools that store small files (cookie) on your device. Cookies are normally used to allow the site to run properly (technical cookies), to generate navigation usage reports (statistics cookies) and to suitable advertise our services/products (profiling cookies). We can directly use technical cookies, but you have the right to choose whether or not to enable statistical and profiling cookies. Enabling these cookies, you help us to offer you a better experience. Cookie and Privacy policy