December 2013 Trip to Nicaragua

Went to Nicaragua with friends last December. Here are links to the various (incomplete) photo albums. One more will be added soon.

• Nicaragua Day 1: BWI and León's Parque Central 
• Nicaragua Day 2: León 
• Nicaragua, Day 3, León, León Viejo, and Las Peñitas 
• Nicaragua Day 4, Granada & Baseball 
• Nicaragua Day 5: Lago Nicaragua 
• Nicaragua Day 5: Parque Nacional Volcan Masaya 
• Nicaragua Day 5: Apoyo Lagoon and Evening in Granada 
• Nicaragua Day 6, Granada and Butterfly Preserve 
• Nicaragua Day 7, Convent San Francisco and Granada Waterfront
• Nicaragua, Day 8, Managua

HTTPS Everywhere Rule Sets for UMBC, tools.ietf.org

The server tools.ietf.org supports TLS, but my browser's HTTPS Everywhere seems unaware of this fact. So I wrote a rule set for that server. I have previously posted here an HTTPS Everywhere rule set for an oft-used (by me) server at UMBC; for convenience, this is reproduced below.

<ruleset name="tools-ietf">
  <target host="tools.ietf.org" />

  <rule from="^http://tools\.ietf\.org/" to="https://tools.ietf.org/" />
</ruleset>

<ruleset name="userpages-UMBC">

  <target host="userpages.umbc.edu" />

  <rule from="^http://userpages\.umbc\.edu/" to="https://userpages.umbc.edu/"/>

</ruleset>

Where do these rules go? See the EFF docs or my prior description.

Geek Clock: They can do Better

Let's start at 1 o'clock and work our way around in a clockwise fashion.

• tan π/4 would be cleaner.
• round(∏) is fine, but how about ⌊π⌋ instead?
• Log 55 is ambiguous, misleading, and inexact--and who capitalizes a log function? Most people will assume the base is 10, except computer scientists might first think 2. But clearly this is intended to be natural log. So, why not say what you mean? ln 55.  For precision, this could be wrapped in a floor function. So, my suggestion: ⌊ln 55⌋
• 16/2 is boring. How about 2³ instead?
• Similarly, 3x3 would be better-written 3².
• g? Do they mean 9.8 m/s/s? How about 12₈?
• For 11, is that 0b? 06? Make it clear: 0xb or b_16. Add a leading zero if you want--I don't care.
• 1100₂ is fine for 12.

Java's java.util.Date Class

Teaching Java programming to novices forces me to sometimes revisit the basics in my own understanding, or the edges of what I understand.

java.util.Date has come up a couple times this semester, and I thought I would verify the behavior of Date for dates at and before 1970-01-01. Here's my simple test code:

//Time-stamp: <2014-02-17 11:14:34 jdm>

import java.util.Date;

public class TimeZero {

  public static void main(String[] args) {

    final int yearsAgo = Integer.parseInt(args[0]);

    final double msAgo = yearsAgo

      * 365.25 // days per year

      * 24     // hours per day

      * 60     // minutes per hour

      * 60     // seconds per minute

      * 1000;  // ms per second

    final Date d = new Date((long) -msAgo);

    System.out.println(d);

  } // main()

} // class TimeZero

I'm neglecting leap seconds in my calculation of ms before 1970-01-01 (called msAgo). Assuming that a year averages 365.25 days is also not quite right, but since 2000 was one of those leap years divisible by 400, it's pretty close for recent years. Providing zero as input acts as expected (once one takes the time zone difference between here and Greenwich into account):

> java TimeZero 0

Wed Dec 31 19:00:00 EST 1969

Three years earlier seems to be about right, given that 1968 was a leap year:

> java TimeZero 3

Sun Jan 01 01:00:00 EST 1967

1000 years before 1970 looks good:

> java TimeZero 1000

Sat Dec 18 19:00:00 EST 969

Let's look around near the beginning of CE and the end of BCE (boundary conditions):

> java TimeZero 1967

Tue Dec 19 01:00:00 EST 2

> java TimeZero 1968

Sun Dec 18 19:00:00 EST 1

> java TimeZero 1969

Sat Dec 18 13:00:00 EST 1

This seems odd, but the Gregorian calendar does not have a year zero (see https://en.wikipedia.org/wiki/Gregorian_calendar) and Date.toString() does not include CE/BCE indication. I played around with calendars in my locale to get the era, but cal.get(Calendar.ERA) returns an int, which makes no sense whatsoever, and the problem isn't interesting enough to spend more time on.

However, I am willing to say the Java Date and Calendar hierarchies are entirely too complicated for day-to-day uses. This is one of the few places where I endorse using non-standard class libraries.