Get Weather from the commandline

This is a program written in python that gets the weather from the command line.

The usage is like:

$ weather.py 83204
5-day Forcast for  83206
---------------------
       Monday Tuesday Wednesday Thursday Friday
High:  74       68       47       49       58
Low:   43       34       29       27       32

It breaks occasionally, most likely because wunderground’s output isn’t consistant.  but the whole point of this program is to figure out urllib and urllib2 to the networking class, so it’s no big deal to me.

Here’s the code:

#!/usr/bin/env python

"""
This is the most useful program ever
Because it tells you all about the weather

I'm a poet
and I didn't
even realize
that I was one

Actually, this program is at the mercy of wunderground's output,
so it can break very very easily - but seemed to work for me in
the handfull of cases I tried it on.  The point is to demonstrate urllib
to my network class
"""

import sys, re, urllib2, urllib

def numError():
   """Exits with a usage note"""
   print "Usage: weather zipcode"
   sys.exit(1)

def addGETdata(url, data):
   """Adds the get data to the url.  data should be a tuple"""
   return url + '?' + urllib.urlencode(data)

def printToScreen(areacode, high, low, days):
   print "5-day Forcast for ", areacode, "\n---------------------"
   print "      ",
   for i in days:
     print i,
   print ''
   print 'High: ',
   for i in high:
      print i,"     ",
   print ''
   print 'Low:  ',
   for i in low:
     print i,"     ",
   print ''

#Check that the user passes a 5-digit zip
try:
  zip = int(sys.argv[1])
except:
  numError()

if (len(sys.argv[1]) != 5):
  numError()

#make the get request
fullurl = addGETdata("http://www.wunderground.com/cgi-bin/findweather/getForecast", [("query",sys.argv[1])])
req = urllib2.Request(fullurl)
fd = urllib2.urlopen(req)

high = []
low = []
days = []

while 1:
   data = fd.read(2056)
   if not len(data):
      break

   """this is not efficient, but works
      and in reality, the bottleneck is fetching the website"""

   #find what the next 5 days are
   m = re.findall('<td class="taC" style="width: 20%;">.*y', data)
   for i in m:
     #append the days
     days.append(i.rsplit('<td class="taC" style="width: 20%;">')[1])

   #find the high for the next five days
   m = re.findall('<span style="color: #900;">.*F', data)
   for i in m:
     #append only the integers of the weather
     high.append(i.rsplit('<span style="color: #900;">')[1].rstrip("&deg; F"))

   #find the lows for the next five days
   m = re.findall('<span style="color: #009;">.*F', data)
   for i in m:
     #append only the integers of the weather
     low.append(i.rsplit('<span style="color: #009;">')[1].rstrip("&deg; F"))

printToScreen(sys.argv[1], high, low, days)

Simple Beauty Website Baker Template

This is a port of simple beauty found at oswd.com to websitebaker with some modifications.

You can download the template here.

Here are some Screenshots

First – this is what you get with a simple install. I made it so you don’t need a banner – though it certainly looks better with one I think.

Here it is with a banner.  Though I suppose you don’t need a screenshot for this.  OTOH maybe I’ll change the template again so…

syn cookies

An interesting cryptographic  way to deal with syn floods is syn cookies.  SYN floods are simply a bunch of syn packets from spoofed ip addresses, and are a fairly common dos attack.   Some other ways to deal with these include increasing the syn queue size and decreasing the wait  for reply time, but these don’t really solve the problem.

SYN cookies are built into the Linux kernel by default (though usually not enabled by default).  You can find and configure this feature in proc/sys.  For example, to enable them you could

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

syn cookies provide a way to build the syn number in a tcp handshake so that it can be used to reconstruct initial syn numbers of legitimate clients after they return the final ack (it checks it using a function and rebuilds the syn queue).  This allows kernel resources to be reused that would normally be waiting on the connection after receiving the first syn.

A normal tcp handshake looks like:

syn
syn-ack
ack

Under a syn attack, most syn-acks sent by you (the target of the attack) will never respond with that final ack since they were falsely generated. syn cookies are an effective defense against this. A server that uses SYN cookies doesn’t have to drop connections when its SYN queue fills up.

For more information about syn cookies, see http://cr.yp.to/syncookies.html

For why it might not be enabled by default see: http://www.mail-archive.com/netdev@vger.kernel.org/msg61116.html

Despite this, it probably make sense in many environments.

sizeof()

This function in the stdio library allows you to view the size of different data types in C. This infomration can be important because the size of the various data types in C can vary depending on your hardware, compiler, and os.

For example, take the example program.

#include <stdio.h>

int main() {
  printf( "bool = %u\nshort = %u\nint = %u\nlong = %u\n",
              sizeof(bool), sizeof(short), sizeof(int), sizeof(long));
  return 0;
}

When run on my office machine, an amd64 with a 64 bit linux os, it produces the following:

bool = 1
short = 2
int = 4
long = 8

When run on the macbook I’m on now running macosx (note that it has a core 2 duo, which is also 64 bit architecture) it produces the following:

bool = 1
short = 2
int = 4
long = 4

Another common thing – on some windows compilers int will be set to 2 bytes which seems fairly weird to me, but I guess if you lived in that day and age… whatever.

 

Follow

Get every new post delivered to your Inbox.