Tuesday, November 13, 2012
is coming to an end at the end of the current Mayan Great Cycle.
And to demonstrate our optimism that we'll still be here after
December 21st of this year, we are finally releasing the first
version of our Mayan calendar generation program (written in
Clojure, of course). Version 1.0.0 is available on GitHub at
The Mayancal program generates a PDF file containing an illustrated
Mayan calendar for the specified year (the default is 2012...just in
case). The earliest year available is 1900, but this should allow
most users to generate a calendar for their birth year.
The Maya developed a sophisticated calendar based on the
intersection of various cycles, especially the 260 day Tzolkin
(ritual calendar) and the 365 day Haab (a rough solar calendar). The
Tzolkin named each day; like our days of the week. There were 20 day
names, each represented by a unique symbol. The days were also
numbered from 1 to 13 (Trecena cycle). Since there were 20 day
names, after the count of thirteen was reached the next day was
numbered 1 again. Since 13 and 20 have no common divisors, this
system uniquely represents all 260 (13*20) days of the sacred year
with a unique number and day-name combination.
The Haab was a rough solar year of 365 days. The Haab year contained
named months called Uinals. These were 18 regular months of 20 days
each and one special five-day month called Uayeb. Days of the Haab
months were numbered 0 to 19. Each day had a number and day name
from the 260-day Tzolkin as well as a number for each day of the
Haab month (Veintena cycle). Using the intersections of these
cycles, each day can be identified by a four-tuple:
[Tzolkin number, Tzolkin day, Haab number, Haab month].
Using Clojure's infinite lazy sequences these interacting cycles can
easily be generated and combined together with an infinite Gregorian
date sequence (see the mcal.clj file in the source code). To
simplify the program, all sequences are synchronized to start at the
Gregorian date of 1/1/1900. Any given point is then found by
dropping the appropriate number of elements from the heads of the
Some miscellaneous notes: Because of the many great public domain
images and icons used to illustrate the calendar, the output PDF
file tends to be rather large so you probably don't want to email
calendars to all your relatives for Christmas. Also, we've tried
viewing the calendar in Preview 5.5.3, Adobe Reader 10.0.1, Skim
1.3.22, and GoodReader for iPad 3.18.6 and we've seen a few
differences between these viewers. Only Adobe and GoodReader, for
example, were able to follow the embedded links and GoodReader had
trouble displaying the links on the last page.
As I said, this is version 1, so if you encounter any issues please
let us know. We hope that this toy provides you with some fun and
diversion from the more serious, real-world uses of Clojure.
Thursday, September 6, 2012
Friday, March 9, 2012
<verb type="gerund" subject="true">Programming</verb>
<noun type="proper" acronym="true">XML</noun>
<determiner singular="true" indefinite="true">a</determiner>
Friday, May 27, 2011
I'm reposting this post from Cosmin Stejerean (offbytwo.com) as a reminder to myself about how to solve this problem that's plagued me for years when connecting to the U via SSH.
'If you are having problems with your SSH connection getting dropped after a certain amount of time (usually caused by NAT firewalls and home routers), you can use the following setting to keep your connection alive
You can place this either in
~/.ssh/config for user level settings or in
/etc/ssh/ssh_config for machine level settings. You may also replace * with a specific hostname or something like *.example.com to use on all machines within a domain. This is the cleanest way of making sure your connections stay up and doesn’t require changes to the destination servers (over which you may not have control)."
Monday, May 16, 2011
Given this photo, I'd say that "small pharmaceutical company" must be one of those medical marijuana boutiques in California.
Wednesday, June 16, 2010
Saturday, May 22, 2010
Obama and the Oil Spill
Thursday, April 22, 2010
Lately, however, I've noticed that their book times are greatly increasing, author quality is decreasing, authors are unknown in the community, books are being threatened with cancellation, there is more and more advertising of "vaporware" (books with only 1 or 2 small chapters), and eBook releases are poorly screened for even minimal formatting quality.
Just days ago I received an email from Manning describing how the authors of Couch DB in Action have fallen so far behind in their progress that the content is already out-of-date. Manning is debating whether to proceed with the existing content, entirely rewrite it or cancel it. There is no mention of what happens to customers who purchased the early access (MEAP) version (as I did) if the book is cancelled.
Then this morning, I received an update to Spring Integration in Action, usually a good and welcome thing. Unfortunately, the formatting of this version has some serious problems that were not present in the previous version. The text size varies wildly from chapter to chapter and, in those chapters were it is greatly increased, many of the figures are obscuring adjacent text and several of the figures are just not visible at all.
Now, of course, it must be acknowledged that this is an Early Access version of the eBook and various formatting, font, and figure problems must be expected for these drafts. However, to be useful at all, there must be some minimal standard of readability; which there was in the first MEAP version of the eBook that I received. The loss of this basic readability in the update gives the impression that no one is even reviewing the product before releasing it.
And, finally, to add insult to injury, Manning sent me a link to an online survey asking frequent customers for feedback. I patiently and completely filled out the form but when I tried to submit it, it claimed that I had not answered a couple of questions and refused to take my submission. Rechecking the form showed that all questions had been completely answered! Manning remains completely oblivious to my disappointments with them.
Manning used to be great but, in my opinion, they are going downhill fast!
Sunday, February 7, 2010
Like wmacgyver, I played with the first 17 (or so) exercises and have posted a gist of my answers here. I intend (hope) to continue working on the rest whenever I can get some time.
wmacgyer's blog with the exercise post can be found here.
Sunday, January 24, 2010
There are many reasons why Clojure has really caught on in the last year or so. For me, it's a well-designed and pragmatic amalgam of Lisp, concurrent techniques, and functional programming built on the JVM. It also helps that there's a great book, a friendly and helpful community, and dozens of enthusiastic side projects.
My slides (as a PDF file) are available in the Tucson JUG's Google group area:
Note that my presentation relied on material from the Clojure community, including the website, forums, and the terrific book "Programming Clojure" by Stuart Halloway.
Wednesday, December 31, 2008
Just look around you when you're at your office, favorite coffee shop, in an airplane seat, a classroom, or even a library. There are almost always glaring light sources above and behind you. What were Apple's designers thinking? Don't they use their own products?
Monday, October 20, 2008
A RESTful Core for Web-like Application Flexibility - Part 4
The final article contains links back to the previous articles in the series. Just scroll down the the References section at the very bottom of the article.
The accompanying poll question, however, (which asks if easily readable code is important) begs the deeper question...of course easily readable code is extremely important but the real question is how to achieve it.
For example, using abbreviations in identifier names is a poor way to make the names shorter and more concise.
Abbreviated names suffer several problems including:
1) ambiguity: is 'getReq' short for getRequest, getRequirement, or getRequisition?
2) cognitive burden: abbreviations requires much more mental effort to remember which fragment of a word is being employed. This "ideolexical" design makes the API seem much more complex and daunting than it should.
As an example, is the abbreviation for 'declareDescription' going to be:
3) lack of consistency: even with only one programmer creating the abbreviated identifier names, it seems highly probably that inconsistencies will creep into the naming scheme, making it harder to use.
4) loss of readability and documentation: longer names are often clearer and document the code better than abbreviations (or shorter names).
In these days of IDEs there is little reason not to use longer, clearer, self-documenting names: it is trivial to start a name and then hit the appropriate completion key. Even if you program in a non-IDE (as I do....I use Emacs a lot of the time) the importance of good names as documentation cannot be over-emphasized and is well worth a tiny bit of extra typing.
Thursday, October 9, 2008
Thursday, September 11, 2008
what most Americans already know in their hearts: that the
terrorists fully achieved their objectives, even beyond
their own wildest dreams. And, since then, unscrupulous men,
corporations, and our own government have helped the
terrorists to continue their success.
Seven years after 9/11, our country has turned against its
own ideals and principles in the name of security, while
ironically justifying its actions as preserving "freedom".
Seven years after 9/11, We are saddled with a costly and
pointless war against a country which had nothing to do with
the attacks. We have a massive new homeland security
bureaucracy which is hard at work trying to impose a
mandatory national ID system. The privacy of millions of
American phone conversations and emails have been secretly
and illegally violated by the government and submissive
corporations. Citizens of other countries have been
arbitrarily labeled as terrorists and jailed for years
without formal charges or a trial. Freedom of travel has
been restricted by secret and erroneous government "watch
lists", to which there is no judicial appeal. And through it
all, government agencies, such as the INS and DHS, have
simply declared themselves to have sweeping new powers.
Joseph Stalin is reputed to have said "When we hang the
capitalists they will sell us the rope" but the terrorists
of 9/11 have turned us against ourselves in a much more
insidious manner; they played upon our fear of death. And
the possibility of death by terrorism is being exaggerated
by those within our country who seek to maintain or expand
their power. The truth is that you are thousands of times
more likely to be killed by a traffic accident than by a
swarthy foreigner with a bomb. Over a quarter of a million
people have died in traffic accidents in the U.S. since 9/11
and yet there is no massive new Department of Automotive
The terrorists of 9/11 won by instilling fear in the
populace, causing us to give up some of our fundamental
freedoms and rights. It is time to awake from our long
national nightmare and to put our fears into perspective.
It is time to stop being overly afraid and to reject the
erosion of our hard-won liberties. It is time to stop
letting the terrorists win.
Saturday, August 16, 2008
When I thought about this approach, I realized that it is duck typing for data. In object-oriented programming, the use of duck typing means that an object's behavior, rather than its class or inheritance structure, determines its interpretation and usage. The application of rule-based systems to categorize a data file or message is a data-oriented form of duck typing. Using "data duck typing", data is categorized (in this case validated) by having the right elements in the right locations.
Data duck typing means that a data file does not have to fully conform to a specific, rigid grammar as long as some of its parts meet the requirements of the particular rule set used for categorization. Thus, data messages for an application can come in all shapes and sizes as long as they contain the essential required elements with the right structural relationships. Applications which use this approach embody the design principle which says "be lenient in the messages that you accept" and will be much more flexible than applications based on rigid adherence to formal grammars.
"5 reasons you don’t really want a jack-of-all-trades developer".
Saturday, July 26, 2008
"A RESTful Core for Web-like Application Flexibility - Part 1"
Perhaps this title was somehow misleading since the article immediately engendered a passionate (and not always civil nor complementary) debate on various aspects of REST. Most of these were off-topic from the article. As a long time reader of TSS, I expected that something like this could happen. My attitude toward this is to encourage rational discussion, clarify misunderstood points, and ignore misbehavior. This is, BTW, an approach used successfully to deal with patients at mental hospitals.
Friday, July 18, 2008
"Interesting", I thought, "but why didn't you guys just use CORBA and get it over with?"
A snippet in the blog post seems to have anticipated that question:
"OK, I know what you're thinking: "Yet another IDL?" Yes, you could call it that. But, IDLs in general have earned a reputation for being hopelessly complicated."Complexity sounds like a strawman here.....the major problem with IDLs is that they are built upon a shared definition, which requires all parties to update and recompile when the definition changes. And once you recompile, you've lost the ability of the system to handle the old message format (so versioning is a serious problem unless you plan for it from the beginning).
Of course, these problems are ameliorated when:
1) the IDL is for internal use only and,
2) you control both ends of the conversation,
as Google does...er...did up until now.
I also wonder why Google didn't just use an existing protocol like Hessian:
Perhaps a case of NIH syndrome? (http://en.wikipedia.org/wiki/NIH_syndrome)
Update - 7/20/2008:
Nick responded with these comments:
Google does tend to favor technology we invent ourselves ...[snip]... OTOH, some of the systems we've built ourselves have been blockbuster hits that enable much of what you know as "Google" today.
In response to your comment about backward compatibility, Protocol Buffers are actually explicitly designed so that you can add fields and whatnot and still be able to read in records stored in the old format.
I have to admit, the "WOW" factor on some of Google's software has inspired competition and innovation. So, the next time I'm looking for a binary wire protocol, I'll take a harder look at Protocol Buffers.