## Quickly determine the day of the week or the day of the month

I often need to know the day of the week for a recent date, or more often, the day of the month today when I know what day it is today. You can find a good amount of information on Wikipedia. I’ll share my version here, which is the basic method on Wikipedia with my own tweak. I’m not interested in complex methods or showing off the ability to instantly determine the day of the week for a date far away. I just want to solve the little annoyance in my daily life.

The formula is simple:

(y + m + d) modulo 7

The result is:

0=Sunday, 1=Monday, 2=Tuesday, … 6=Saturday

In the formula, d is the day of the month, m is the month number and y is the year number. You need to memorize m and y, which is the only tricky part. My month table is offset +2 to the one on Wikipedia, and use -2 instead of 5. I felt mine is easier to memorize, but you can pick your own version, too. (There are 7 possible versions.)

Month Month number Memorization tip
Jan 2 1-2 (one, two)
Feb -2 2–2 (two, minus-two)
Mar 5 3-5 (paired with May); 5 letters in March
Apr 1 *
May 3 5-3 (paired with March); 3 letters in May
Jun 6 6-6 (six, six)
Jul 1 *
Aug 4 8-4 (half of 8)
Sep 0 *
Oct 2 *
Nov -2 *
Dec 0 *
Leap years:
Jan 1 1-1 (one, one)
Feb 4 2-4 (double of 2)

* To memorize (or understand) the month numbers of April, July and September through December, you should notice that April and July share the same number, and same with September and December. Why? Because there are 30, 31 and 30 days in April, May and June (or September, October and November), which map to 2, 3 and 2 after modulo 7, and 2+3+2=7. So after 3 months, July repeats the day-of-the-week pattern of April. That also explains why the month number of October is 2 and November is -2.

Year Year number Year Year number
2011 3 2021 2
2012 -2 (or 5) 2022 3
2013 -1 (or 6) 2023 4
2014 0 2024 -1 (or 6)
2015 1 2025 0
2016 3 2026 1
2017 4 2027 2
2018 -2 (or 5) 2028 4
2019 -1 (or 6) 2029 -2 (or 5)
2020 1 2030 -1 (or 6)

You actually need not memorize the year table, because it changes so seldom. After a few applications, you’ll be very familiar with recent year numbers.

Let’s see some examples:

• 2014-07-22: y=0, m=1, d=22; (0 + 1 + 22) mod 7 = (0 + 1 + 1) mod 7 = 2 mod 7 = 2
• 2014-11-22: y=0, m=-2, d=22; (0+ -2 + 22) mod 7 = (0 + -2 + 1) mod 7 = -1 mod 7 = 6
• 2013-12-31: y=-1, m=0, d=31; (-1 + 0 + 31) mod 7 = ( -1 + 0 + 3) mod 7 = 2 mod 7 = 2

To determine the day of the month is similar, but you use subtract instead of addition in the formula:

d – y – m

The result is the day of the month modulo 7, so there are quite a few possibilities, but since you usually know the rough range, you can usually determine the day of the month for today. For example, today is Wednesday, this month is July 2014, and you know the day of the month is twenty-something. We have:

d=3, y=0, m=1; 3 – 0 – 1 = 2

So today is 23 (23 modulo 7 = 2), or 16, or 30. You pick one.

Hope that helps.

Posted in Daily Life | Comments Off on Quickly determine the day of the week or the day of the month

## JavaScript, a rising star

I didn’t notice the JavaScript phenomenon until recently. Although I started using JavaScript on Netscape4/IE4 when web was still new, and did some Ajax for a while, JavaScript has always been a supporting role in my mind, some auxiliary tool to enrich user experience and cope with browser deficiency.

I’ve written production code in C/C++, Perl, Python and Java programming languages (plus HTML/CSS/JavaScript/ActionScript) for years. To me, JavaScript could never be at the center of the stage. It looked so unstructured, unpolished and ad hoc. However, after digging further recently, my view changed completely. I not only realized its merits, but also considered it a rising star: it could play a central role in the years to come.

Firstly, the language itself is very expressive if we avoid its “bad parts”. (Douglas Crockford talked it quite well in JavaScript: The Good Parts.) Some good things include first-class functions, powerful dynamic objects, terse object/array literal, and the event-driven (asynchronous) nature. The last thing is particularly important IMO and makes JavaScript prominent among popular programming languages. If it prevails, that could be the main cause.

Secondly, its sever-side development momentum triggered by node.js is growing fast. For a long time, JavaScript is limited to web browser environment. Server-side JavaScript existed but never aroused enough interests. It has changed. Some companies are building serious node.js applications. For example, Rackspace switched from Python to JavaScript in their new project (link); Yahoo! is moving toward node.js through its Mojito initiative. Combining the asynchronous nature, JavaScript is very competitive as a server-side language.

I didn’t really get the significance of asynchronous/event-loop/non-blocking until I read across a good blog post: Why node.js is cool. It reminds me the pains I experienced in my earlier Python project, a distributed job dispatcher to do massive text data processing on 100+ Linux boxes. Basically, for tasks involving external coordination where JavaScript shines, traditional synchronous programming languages are cumbersome. As the internet marches toward a more interwoven world, JavaScript fits well at both the browser and server sides. Another sign of the JavaScript momentum is GitHub Top Languages page.

I just watched Crockford on JavaScript – Scene 6: Loopage again, and comprehended better than last time. (BTW, it’s a pity this great guy left Yahoo!.) Though it takes a short while for server-side JavaScript to mature, it is very promising.

JavaScript, a rising star!

Posted in JavaScript, Software | Tagged , | Comments Off on JavaScript, a rising star

## The abstract nature of software makes coder’s life hard

Is software a science or engineering? To coders, I think it’s engineering because we build something to ship.

On the other hand, unlike most engineering disciplines, software is abstract. The things we build are computer instructions – no flavor, no shape. Car is complex, but open the engine hood and you see something real. When the complexity gets higher, the difference between abstract and physical form is amplified exponentially. Physical existence forces engineers to build objects in a logical way, preventing you from going astray. The kitchen needs a sink; the door needs a knob. Craftsmanship (quality) is also tangible in the final product. However, software is as abstract as mathematical formula. Who can easily understand multiple pages of mathematical formula? Who may quickly see through the quality of numerous symbols? That’s why coders tend to rewrite others’ code (and why we should strive for code readability).

Coders may write programs in virtually any form. Common sense does not apply because software does not “exist” in the real world. After reading a beginner’s guide, anyone can write some code, while it takes years for a coder to realize how to write good code. Two programs may behave the same, and you feel the difference only when you work closely on them. Coding is a process of myriad free decisions ranging from variables, statements, functions, classes, modules to architectures as long as it runs correctly. The code reflects the author’s mind. No wonder working on the existing code is painful! Because you have to read someone’s mind, or your mind months/years ago.

The abstract nature of software results in another big challenge: its real complexity is too difficult to comprehend with common sense for non-engineers. Even you are a coder, unless you do related hands-on work day-to-day, you can hardly realize all the issues and complexities behind the scene. Hence software-related decision makers often have to base their decision on a small, vague fraction of the truth from what they’ve been told. This may lead to inferior decisions and engineers’ frustration.

We cannot change the abstract nature of software. Even worse, the software industry moves so fast that the technology you acquired a few years ago become obsolete. Coding is hard. Face it! That’s why we got paid.

That said, you can do your code reader (yourself and/or your colleague) a favor: write good code. Be conscious when coding; measure twice, cut once.

Posted in Software, Trait | | Comments Off on The abstract nature of software makes coder’s life hard

## Software complexity is software entropy

Entropy is a thermodynamic term, and I regard it a very profound insight applicable outside physics. For example, things in the world get worn over time. I’d describe that as a process of increasing entropy, which is basically irreversible unless some external, accurate force (such as repair) is applied.

Clothes wore out as its “entropy” accumulated. Well-made clothes are more durable, but it’s still a matter of time. Buildings, paintings, televisions, cars or batteries are all the same. So are your household chores – it takes a lot of energy to keep the house clean and organized. Have you ever sorted the LEGO bricks for kids? My son can mess up all the LEGO bricks in seconds, and it takes way longer to undo that. Generally, it’s very arduous to decrease the entropy of a system.

Low entropy – fresh, ordered, fully charged, …
V.S.
High entropy – worn out, chaotic, dysfunctional, …

Back to software. Software complexity is more like the entropy in the second law of thermodynamics. Changes made to the software usually increases its complexity as we add new features or fix bugs. When checking in new code, unless it’s really one-off, ensure its good quality otherwise you’ll pay higher total cost in the long run. All our software engineering endeavors and disciplines are centered around managing complexity, or decreasing entropy.

You know it’s such a pain to work on a high entropy system. When a software component becomes too complicated, fragile that everyone avoids to touch, it’s probably coming to an end.

Solution? Like our house, constantly cleans it before it buries you.

Posted in Software, Trait | | Comments Off on Software complexity is software entropy