Like good discoveries, I just found out by accident that the Mail application in the iPod touch does support Microsoft Excel and Word, so I decided to investigate further.

I did few test with Microsoft Office 2003 and the three most common Office applications: Word, Excel and Powerpoint. Here are some of my findings:

• 
• Can read Excel and Word documents as read-only.
• Powerpoint presentations are not supported.
• In excel, graphics and themes are supported.
• No Excel macros work. Filtering is not supported.
• Formulas seems to work but I haven’t tested which ones are supported.
• Word styles are supported.
• Support Office 97 and 2003 formats.
• Does not support meta-data inside Office documents like hyperlinks or other attachments.
• Supports multi-touch zoom and tap-and-drag features just like pictures.

For reference, I am using a 1.1.1 jailbroken firmware but I think this is a standard feature for the mail application available for the iPhone.

If you have an iPhone or an iPod touch with a different firmware, please test this functionality and send me your comments.

Japan is a country where technology plays an important roll in service convenience and a good example of this are the RFID machines for the suburban train.

In Tokyo, you can always buy a common magnetic ticket for everyday’s trip or you can also use one of the many RFID solutions available.

Every gateway machine has an RFID reader (the blue circle shown in the picture) that works with common RFID cards (Suica and Pasmo) or even your mobile phone.

 
In the case of the mobile phone, the included RFID is a general tag that servers multiple purposes like electronic wallet (EDI) or user profile in stores (like Tower Records).

Just in case you are wondering what happen if you lost your phone, there is a way to disable it, lock every functionality and to auto-backup your data on the carrier’s servers by simply calling back your phone number with a pre-defined code.

I don’t know about you but in the company I am working there are many Unix system administrators like me but really few of us can really script.

Scripting is really convenient when working in big distributed environments like mine one. Is a life saver for data collection, implementation automation, error notification, etc.

But what to do when you are the only ex-programmer in your team and want to automate many activities while you need to work in daily activities like keeping the servers alive and updated?

Some practices and experiences I have learned if you are the only programmer in the front line are:

– Design and document like a pro: The fact that you don’t have to interact with other fellow programmers on the same code doesn’t mean that you shouldn’t document and design as much.

Most likely if you are the only coder means that you will likely have many of your creations wondering around in your environment. If you don’t follow best practices, eventually you will forget how certain scripts work and interact and you might even be scared of opening the source code ever again.

– Explain to other users about the options and limitations of your code: If you are the only coder, chances are that your colleagues do not quite understand the limitations of scripting and they expect that you (and your apps) can do everything they ever imagined not knowing the complexity of their request.

If you have been a programmer for a small-medium company, you probably already know this.

– Think before you start a new project: for every creation, you will be responsible of supporting, securing and upgrading your code.

If it is possible, try to centralize the multiple scripts in a single applications. A real example is that I created a script that executes other small segments of code stored in segments in a XML document, collects the output on a ore-defined and unified XML format and provides its own channel to send the information back to the collector server to be processed.

In this way I don’t have to worry anymore to open new channels of communication with my collector(s) server(s) or to worry about creating an special and different output for everyone of my scripts and I just have to maintain a single application.

NOTE: If you don’t get what does my application does, it is just like Nessus. An application that performs customized security checks by adding/removing Nessus rules. Nessus provides an unified engine to process all those rules and generates a single report from the output.

– Keep an uniform version control: In horizontal platforms it is very simple to forget which machine has each version of your script.

– Express programming is not an standard: The biggest temptation is that if you are the only coder, you head straight to the keyboard and start programming something.

Follow the best practices of a normal development environment. Just hitting the keyboard will lead you to have many bugs and unexpected changes wasting your scarce time.

Use express programming only if you are a seasoned programmer and/or if the script to be developed is very small and simple.

Comments and suggestions are welcome.
Victor.

At work, scripting takes a big part of my time and when you script for a mixed Unix and Linux environment there are a couple of tricks here and there to help you in deploying, debugging ad expanding scripts with the least pain possible.

– Keep a good documentation

This is simply common sense. The great difference between scripting and  programming is that you spend less time with the first option. For this reason is easier to forget what you have done.

A good documentation has easy to read comments with general instructions of which module does what and where to customize option.

Not less important is to include a comment header with information like: version, usage, options, author, company and license, known issues, etc.

Good documentation will really help you when troubleshooting or when  upgrading the script. Never underestimate this power.

– Make it look good

There is an important reason behind making a script look good: it is easier to read when you go back and review it.

- Keep a proper indentation (camel indentation is good to read loops)
- Use variable names that make sense.
- Limit your abstraction! There is many people who script with the maximum abstraction possible and later they find their scripts difficult to read. Abstract your script to the point is still legible at least by you.

– Variables are everything

Make everything a variable. Nowadays memory is not as scarce and making everything a variable will facilitate customization and legibility.

– Segment into modules.

Dividing your script into modules will turn debugging into a much easier task and over the time you will discover gold nuggets in functions you have developed before, therefore the only thing you will have to do is to go back to your script and simply extract and customize that specific piece of code.

– Standardize your input and output

This one is really a life saver. Create a single format for all the input and output files whenever is possible.
In my case I use space separated document for configuration files; for output files I always have XML documents. This makes it much easier to interact with other scripts an applications

– Define a standard for filenames

This is probably the most common problem in my working place. There is no convention for filenames an everyone end of using a very generic filenames such as [server-name].[date]

Whatever your convention is, make sure it implies the contents of the 
file, the format, if it is required also the date or range.

– Script for everyone and for everything

Always remember that when you develop a script, in most cases you will be responsible and the main point of contact in case it fails. I strongly recommend you spend time in evaluation.

Evaluation is very important to prevent human errors during user input and it also plays a very important roll when the script will be ported to a distributed environment.

In my company I am responsible for more than a hundred servers including Linux, Solaris, AIX and HP-UX. I develop dozens of scripts to perform administration and data mining tasks and I learned from the first implementations that the file locations are not standard in all these servers.

Evaluating for the existence and versions of the file I use increasingly reduces the chance of bugs and the requirement to re-implement a new script version or a hotfix.

- Evaluate every file you will use: ensure it exists and that it has the right permissions to interact with your script.
- Evaluate EVERY user input.
- Evaluate your running processes. Estimate their maximum execution time and kill the process if they take longer. This will prevent infinite loops to fill the memory.
- Evaluate script requirements.
- Evaluate communication channels if you script connects to a network.

– Throw exceptions

The last recommendation for today is to throw exceptions. Include a verbose mode of your script which provide useful information for troubleshooting.

If this is a scheduled script (e.g. running from Cron), make sure to save a log with the exceptions thrown and a timestamp. This will prove incredible useful when you want to identify problems in scripts that have to execute only on certain timings.

– Conclusion

These recommendation are just some best practices and common sense.

I would like to add that if you have other colleagues developing scripts in the same environment as you do, organize yourselves. Create a convention for variable names, modules usability, file input and output and documentation. If it’s possible, create a development API (like I do) to perform common scripting tasks like specific database queries, file transfers, user input validation and whatever else you require. If you really think about it, this is a life saver.

Let’s say that you find a vulnerability in a module or the database port changes, in these cases you will only need to update that specific module rather than identifying all the dependent scripts.

Best wishes and happy coding.
Victor.

Interestingly, they want to make people happier and this campaign is gaining popularity in the populated cities in Tokyo.

What do you think?

1. Security Now — with Steve Gibson and Leo Laporte — This podcast is part of the TWIT family and discuss about the latest news in security as well as explanations on internals of security topics.
   Steve Gibson, a seasoned security insider offers good and easy to follow explanations for people who is not a Security Professional, and for the rest of us we still have his geek-peak moments when he explains byte-by-byte of a topic.
2. Net@night — with Amber MacArthur and Leo Laporte — This clicking couple discuss about the advance in Web 2.0 technology and it’s adoption. Fun, comic and with good content, it is a perfect heads up about what is happening in this conspiration for the perfect social network.
3. WebbAlert — with Morgan Webb — provides a daily video feed of what is going on in the triple “W” with just the right touch of satire. Highly recommended and you can find a daily video feed.
4. Geek Brief – with Cali Lewis — Cali provides a very relaxed video podcast specially dedicated to wanna-have gadgets.
5. Systm — with Patrick Norton — this is a good quality podcast of the do it yourself type. What I particularly like about this podcast is that Patrick Norton tends to show you un-assembled gadgets and he is a hands-on-tools guy.

I know there are many other amazing podcasts out there and probably (only probably) I haven’t heard about them yet. If you have a recommendation, please send me your comments.

With a good design to be expected from the fellows in Cupertino California, this beautiful piece of multi-touch hardware still lacks some desired capabilities as SD memory slot or GPS device, but in general it earns my thumbs up.

I really don’t think that the iPod touch makes a good productivity tool as the Blackberry does but this is not it’s main purpose, but to keep me happy on the hours I spend packed in a Tokyo train.

Applications I have installed

• VT100 – Now I have local access to the Unix (Darwin) inside, and let me tell you that it really looks like a full OSX to me.
• OpenSSH – So I can connect and transfer files from my PC. But please change the default root password (alpine) for something more creative.
• VNC Client – Yes, I just installed this because I can! And because I can remotely manage my downloads on the go.
• Mail App – It is very convenient for writing mails in the train.

My wish list for future iPods

As many people have realized, this piece of hardware has an incredible potential. If I might suggest, my perfect iPod touch (hopefully by 2010) would have:

• Digital Camera (as the iPhone but with video capabilities).
• GPS device and navigation system (with Google?).
• e-wallet RFID – It is very useful here in Japan to pay the train, restaurants and convenient stores.
• WiMax support – Once available
• Memory Card – Come on, it’s just common sense.

The most interesting characteristics of the new iPod are the possibilities it brings. I really recommend it to you if you can “jailbreak it”, only then you can utilize it properly.

My experiments on the iPod touch.

The iPod makes an excelent stumbler for war-driving or drive-by-pharming. With Darwin capable to support Perl and Ruby, I am trying few scripts to store wireless logs and later I am planning to add a WEP cracker on it just to see how capable is this device.

For more information on third party applications, please visit www.jailbreakme.com. This guys have done an excellent job with the InstallerApp.

Last year my resolution was about writing more. I spend a lot of time reading but not much time writing, and there are many ideas I wanted to share.

This year I want to improve this by adding quality to my previous resolution. I would summarize as follows:

My resolution for 2008

1. Dedicate more time to my blog.
2. Be concise, precise and objective as possible.
3. Let my blog be known.

I want to thank to my friends and family for supporting me last year and I hope 2008 becomes a great year for us all.

This moment in life is when time is an scarce resource and have to be used wisely. Time to get the work done with the least effort. For that reason and with this nostalgic feeling I have to say that the domain www.victor-serrano.com will be down by the beginning of 2008.

Now a days the public blogging services have improved a lot since two years ago. I think I am ready to move to the free-public sector of blogging. For this reason, I will make this site my main resource for the time being.

This does not discard the idea of having a new domain in the near future, but if that is the case, it will finally be dedicated for dedicated experimentation and to share resources.

As always, your comments are very welcome and I hope to see you in the near future.