Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Tuesday, January 22, 2008

Perl: Convert epoch seconds to readable time

As a system administrator, It's not uncommon to run across time stamps represented in Epoch Seconds, that is basically the number of seconds that have passed since the start of Jan 1, 1970 UTC.  I most often run across these time stamps stored in database records, but you'll see it elsewhere, too.   An Epoch time stamp for any fairly recent date looks like a huge string of digits, such as "1201017672".  Obviously, time stamps closer to the beginning of the 1970 Epoch are significantly smaller.

To make some kind of sense out of that stamp, you can use perl's localtime() function right from the UNIX command-line.
$ perl -e 'print scalar localtime('1201017672'); print "\n";'
Tue Jan 22 10:01:12 2008

Saturday, December 15, 2007

December KC PHP User Group meeting

Usually, KCPUG's December meeting is either non-existent or of sparse attendance. The third Saturday of December is pretty close to the holidays, and many people have other plans. As such, I hadn't prepared anything to discuss, and neither had anyone else. I was pleasantly surprised when -- despite a snow storm -- we gathered more people than I'd expected. 2 of them came all the way out from Clinton, MO. It was nice to see some new faces among the regulars.

I demonstrated my Spreadsheet browser, and we all discussed some other projects we're working on. After that, it was mostly a discussion of various server platforms, web design software, and programming languages, both viable and not. This included Microsoft IIS, Apache, DreamWeaver, Front Page, PHP, ASP.NET, LOLCode, and BrainF---. Sometimes, a meeting without a lot of structure can be a great one.

Saturday, December 1, 2007

Zend Framework and Google Spreadsheets

I've been tinkering with Zend Framework specifically for the purpose of dealing with Google Spreadsheets for the past couple of days. I know that most of my code is a complete bastardization of PHP. The examples I saw were using classes and objects. I'll be frank with you: I am not a developer, and I haven't taken the time to really wrap my brain around that stuff. The ZF Google Data tools return objects, and I worked my way through those enough to get the data out that I wanted, just in order to make this little project work.

I may build on this a little bit later, but for now I'd like to show you what I threw together, then how it works. Sorry, this is kind of big for a blog post so I put it in a scrolly iframe. Each little block of code has some documentation. It's worth reading my comments.



You can also download it here: Google Spreadsheets Explorer (php source, 4kB)

I don't actually have Zend Framework on any production servers right now, so I did a fresh install of PHP5 and Zend Framework on my OpenBSD virtual machine. If you want to test this yourself, you can easily get Zend Framework up and running easily if you have PHP 5.1.4 or newer running anywhere. Currently, PHP is up to 5.2.5.

When you first fire it up, there's no session, so it displays the login screen. You login with your google account information:




After logging in, a session is established. How this session information is stored varies from one PHP installation to the next. It might be in a client side cookie, a server side database, etc. Behind the scenes, the script is authenticating your stored session information to Google and creating the $client construct, which is what we'll use to bounce queries off of the mothership.

Once authenticated, its default action is to fetch a list of spreadsheets. This is an XML feed that Zend Framework essentially makes into an object. It contains one entry per spreadsheet. Spreadsheets are called by the key, which is a string unique to the creator of the spreadsheet, a period, then a string unique to the sheet itself. These are all properties of the "entry" within the feed object. I made a quick function that returns a basic array. Each element contains the URL to pull up the spreadsheet in my GS Explorer script, and the title of the spreadsheet. This gets displayed to the user.


function getsss($client) {
# Gets a list of spreadsheets; Returns an array.
$spreadsheet = new Zend_Gdata_Spreadsheets($client);
$feed = $spreadsheet->getSpreadsheetFeed();
foreach (
$feed->entry as $entry)
{
$id=split("/",$entry->id->text);
$key=$id[5];
$url="http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']."?key=$key";
$availss[$url]=$entry->title->text;
}
return(
$availss);
}








Clicking on one of the spreadsheets will give you a list of the sheets (or pages) within it. The code for getting the list of sheets is very similar to the code for getting the list of spreadsheets, so you can reference the source if you're interested.




I threw something together that just rips through the sheet and pulls the cell data out, dumping them in order, left to right, top to bottom. I could clean it up a bit, but this demonstrates reaping data out of Google Spreadsheets. Obviously, you could automate this to pull data down.




Unfortunately, the GData API, while slick, can be a bit sluggish. You probably wouldn't want to run a production site using live data from Google Spreadsheets. I'll cover writing to GS at a later time. That could come in handy, as you could use a web front-end or scheduled PHP script to occasionally update the values of a spreadsheet.

Sunday, November 11, 2007

The MBR Love Letter

First, this was Friday's XKCD comic:
And she put sweet nothings in all my .conf files.  It'll take me forever to get X working again.

Then today, I ran across someone who decided to actually pull it off, with a nifty how-to. Obviously, tweaking the MBR can render your system unbootable, so it's not recommended to do it unless you really know what you're doing, or if you're going to format and re-install anyways.

I laughed, which is always a good way to get an early start to the work week.