Abstractions-R-Us

Just Use a Saw

2011-09-13T18:18:00.000-07:00

I discovered something profoundly usesless today: When you combine a square wave at amplitude 2x, pitch y with a sawtooth at amplitude x, pitch 2y, the result is a sawtooth at amplitude 2x, pitch y, when the two waves are in phase with each other.

square(2a,p) + saw(a,2p) = saw(2a,p)

I can prove it using the harmonic series, but first I should warn that I am not a good mathematician, and there may be errors here, and the above proposition may be false. Please let me know if you see any errors; children will starve if any flaws go unnoticed.

A square wave (http://en.wikipedia.org/wiki/Square_wave) contains every odd-integer harmonic n at amplitude a/n where a is the amplitude of the fundamental (the first harmonic). (Please pardon the infinitely recursive definition... the fundamental is at volume a.)

A sawtooth wave (http://en.wikipedia.org/wiki/Sawtooth_wave) contains every integer harmonic n at amplitude a/n where a is the amplitude of the fundamental.

Now, to sum the amplitudes of the harmonics of the 2 waves, we can express one wave's harmonics in terms of the other wave. Since the square wave in this proposition is lower in frequency and double the amplitude of the sawtooth, I will call its frequency the fundamental (first harmonic) for this example. (After all, it _is_ the fundamental if both are played together anyway, but that's irrelevant to this proof.)

Since the frequency of the sawtooth wave is double that of the square wave, its nth harmonic is the (2n)th harmonic of the square wave. Therefore, it will provide all the even-numbered harmonics. Since its amplitude is half that of the square wave, its fundamental (the 2nd harmonic of the square wave) will sound at 1/2 the amplitude of the square wave, its 2nd harmonic (the 4th harmonic of the quare wave) will sound at 1/2 _that_ amplitude, its 3rd harmonic (the 6th harmonic of the square wave) will sound at 1/3 its amplitude (1/6 that of the square wave), etc.

So, the square wave provides all odd-numbered harmonics n at amplitude 1/n, and the sawtooth provides all even-numbered harmonics _of our resulting wave_ at 1/n. Therefore, by combining a square wave and a sawtooth at twice the frequency and half the amplitude, we have all integer harmonics at volume 1/n, which is a sawtooth at the pitch and amplitude of the contributing square wave.

I guess there is one application to this: On a synthesizer, using a sawtooth oscillator combined with a square oscillator one octave lower at the same volume is useless. One octave lower because that's half the frequency, and the same volume because that's twice the ampltidue and frequency times amplitdue equals volume. So the moral of the story: Just use a saw!

Small World Technologies

2010-11-12T16:02:00.000-08:00

I now have a side job working at Small World Technologies to make mobile apps.

2010-08-05T07:13:00.001-07:00

Just got an email from Amazon that says "Save up to 50% on Summer and Back-to-School Toys". Somehow, I think the category was pieced together by a bot, since I don't know what a back-to-school toy is.

Windows Command Prompt Keeps Up with One Current Directory Per Drive

2010-07-14T09:03:00.000-07:00

Or so it seems. This is copied from a console window on a machine running Windows Server 2003:

C:\Documents and Settings\jyoung>cd E:\InetPub\web sites

C:\Documents and Settings\jyoung>cd "E:\InetPub\web sites"

C:\Documents and Settings\jyoung>cd e:
E:\InetPub\web sites

C:\Documents and Settings\jyoung>e:

E:\InetPub\web sites>

Very strange. It seems that the command prompt keeps up with the “current directory” on a per-drive basis, so that when you cd to some drive that you’re not on, it changes the “current” directory for that drive rather than _the_ current directory. Then when you change drives, it remembers what drive you changed it to previously. I did not know that.

Oddly, using the /d flag is required to change directories across drives [reference].

Do your work, or throw an exception - example

2010-06-25T08:11:00.000-07:00

The last post gave an illustration of a employee telling his manager if he cannot do his work as usual instead of requiring his manager to ask him if he will start doing what is expected of him every time she asks him to.

Below is a code example of this idea that I posted on StackOverflow:

class GoodEmployee {
void DoWork() {
if (CarIsInTheShop)
throw new CantDoWorkException();
else
_DoWork();
}
}

class BadEmployee {
bool DoWork() {
if (CarIsInTheShop)
return false;
else
{
_DoWork();
return true;
}
}
}

Imagine using each of these. Using GoodEmployee means that client code can operate as normal. Wherever appropriate, _if_ appropriate, a try/catch _may_ be used to properly handle the exception, if that is even possible. The most appropriate try/catch may be in place already in a form something like this:

// main loop:
while(!timeToQuit) {
try {
REPL(); // read eval print loop, for example
}
catch (TransientException e) {
TellUserHeCantDoThatRightNow(e);
}
}

Meanwhile, client code of GoodEmployee may look like this:

myGoodEmployee.DoWork();

Contrast this with proper usage of BadEmployee:

if (!myBadEmployee.DoWork) {
return false;
}
...
return true;

Not _so_ bad. But what if we call DoWork in lots of places? What if there are not 1 but many different methods like DoWork that have to be called? Worst of all, what if we want to have N layers of indirection that must exit when the employee cannot do his work? What if we apply this same pattern (return error codes instead of throwing an exception) to those methods? Then we have something like this:

A() {
if (!B())
return false;
// do some other work;
return true;
}

B() {
if (!C())
return false;
// do some other work;
return true;
}

C() {
if (!myEmployee.DoWork1())
return false;
if (!myEmployee.DoWork2())
return false;
if (!myEmployee.DoWork3())
return false;
// do some other stuff
return true;
}

YUCK!

I have worked on an application like this. Making any minor little changes to it is an absolute pain because it employs the above pattern throughout. Contrast that with otherwise comparable apps that throws exceptions and allows exceptions to be thrown--the latter group of apps not only have less code, cleaner code, and fewer bugs, they also have _more robust_ exception handling.

I hope these clearly examples show how exception-phobia and speculative catch blocks are destructive and literally multiply the amount of code you have to maintain, as well as hide and even introduce bugs.

Do your work, or throw an exception

2010-05-13T12:33:00.000-07:00

Imagine this: My car breaks down, and I cannot make it to work. Should I inform my boss that I will not do my work as usual, or wait until she asks me if I will come to work? Should she ask me every day if I will do my work as usual?

If there's something wrong with my car, should a light on the dashboard tell me, or should the engineers that designed it require me to check everything to make sure it is in working order every day before I start driving?

I think you would agree that, when something or someone does not behave as expected, a notification that he, she, or it did not do its job would be nice. In many cases, we have a right to expect this sort of behavior.

Likewise, every method you ever write should either do what it says it will do or throw an exception. E.g., myObj.Save() should either save myObj or should throw an exception. It should not return a value indicating if it was successful or not, as that would require client code to check for success.

If there are multiple occasions where you would catch an exception thrown by a method immediately in order to do something with it, then (and only then) you can create a tryDoSomething method, such as myObj.TrySave(), and use it where applicable. (Of course, catch only exceptions that you know are caused by specific things; let the exception go if it is due to a bug.) TryDoSomething() methods should be the exception, not the rule.

Dynamic and static typing are not entirely mutually exclusive

2010-03-12T07:42:00.000-08:00

Most programming languages are classified as being statically typed or dynamically typed. I think of static and dynamic typing as features (which can be used together in a single language, if desired), and weak typing as lack of either.

Static typing is a feature where the compiler checks for type mismatch-related errors.

Dynamic typing is a feature where the compiled program checks types. The compiler is involved only in generating executable code that does the check at runtime. In this scenario, trying to call aPig.Quack() compiles, but throws an exception at runtime.

Weak typing is lack of type checking--e.g., calling aPig.Quack() will run with undefined behavior.

In this view, polymorphism is a dynamic typing feature that works well with statically-typed languages: The compiler may ensure that all aDuck really is a Duck, but the runtime environment will check to see what kind of Duck aDuck is--Mallard, WoodenDecoy, or something else--to know which implementation of the virtual method Quack() to call. Hence we have an example of static and dynamic typing working together.

Bass Tip

2009-10-09T09:01:00.001-07:00

This is in response to Gio Benedetti's bass tuning tip (http://www.emginc.com/videos/emgtv/7), where he demonstrates some useful tips for playing chords on bass. Be careful tuning any string up what it is normally meant to be tuned to, e.g. tuning a B up to a D. Doing so not only causes more wear on the string, but also is bad for the neck. One should either:
-use a capo, or
-use a string designed for that tuning (e.g., tun a heavy E string down to a D).

Tuning lower is generally fine, although some setup work may be necessary to prevent fret buzz and improper intonation.

One advantage to a standard bass tuning (i.e. in fourths) is that it simplifies improvising and planning one's part. Retuning generally makes these harder.

On the other hand, myriads of guitarists have learned to play a variety of complex or "alternate" tunings for ages. Though most (amateur) guitarists may memorize from a book how to play each and every song without ever thinking about the notes they are playing or how to create different chords, many others do take the time to understand (from some lower level of abstraction) what they are playing and why it sounds the way it does--they think about the individual notes that make up the chords, and decide how they will play a chord at a given point in a song based on sound and voicing. So bassists certainly can learn to do the same if they wish, but they will usually be breaking new ground to do so.

In my opinion, controlling the pitches of droning open strings is the primary advantage of various guitar tunings (excluding open chord tunings), as they contribute wonderful complexity to the chords with little effort from the guitarist. The drone provides a comfortably familiar baseline while simultaneously adding dissonant, complex intervals to any chords straying from that baseline. Open strings also have a slightly less muted sound than that of fretted strings. The disadvantage of complicated guitar tunings (excluding open chord tunings, again) is that figuring out how to play a riff, melody, or chord can be more difficult.

Using a capo will add some control over the open string tuning (though not total control) without requiring the bassist to re-learn scales and arpeggios (as would alternate tunings). Hence, I would try a capo before retuning.

in reference to: Electric Guitar Pickups & Accessories - EMG Pickups | EMGTV (view on Google Sidewiki)

Joel Spolsky Has an Interesting Idea of Duct Tape

2009-09-28T12:55:00.000-07:00

Joel's recent post reveals a strange notion of what a "duct tape programmer" is.

His first description is of someone who uses C++ templates and multiple inheritance to describe has-a or does-a relationships--someone who knows just enough about inheritance to see how type inheritance can save time, but not enough about contracts to foresee the brokenness of this design. He then goes to a design patterns meeting. I am glad he is going to a design patterns meeting to learn about object composition, and all that's wrong with this lazy, hacky implement-via-inheritance antipattern. I say this template-abuser is a duct tape programmer. Mr. Spolsky calls this kind of programmer an astronaught, and says the duct tape programmer does _not_ hack in this way.

Next, Mr. Spolsky says, "You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us."

Multiple inheritance per se is simple; the complexity is in actually using it. Templates (in general) are the mainstay of the copy-and-paste abuser--the extremist duct tape programmer--but I think Joel is speaking here of C++ templates. A practical and effective programmer will make effective and proper use of generics (assuming static typing is also being used). Therefore, even with all their problems, C++ templates are a necessary part of good C++ programming if you insist on using C++ to begin with. Who would use COM for anything other than working with legacy code? Multithreading is a fact of life sometimes, but should not be used for performance alone without sufficient reason. What "faddish programming craziness" do practical programmers "sheepishly go along with"? No answer to this question is explicitly given in the original article, but Joel does proceed to tear about ideas that have passed into common usage.

Finally, the portrays unit tests as an enemy to releasing on time. First he quotes Zawinsky, saying unit tests "sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that." Then he says "we’ll forgive [duct tape programmers] if they never write a unit test."

Technically, you can ship without unit tests. There are 2 alternatives:
1. Don't test. This way, when you accidentally encounter a bug, it is harder to find the source. Also, you risk the customer complaining about bugs that are shipped. Worse yet, you spend all that time to build a piece of crap. Such a waste of time is both immoral and unfulfilling.
2. Test manually. The disadvantages here are more time spent testing (not less!) and having a harder time finding bugs.

Skipping unit tests is like using duct tape. Using unit tests is _wise_.

Apples on Pasta?

2009-08-25T13:51:00.001-07:00

Apples have a sweetness similar to that of tomatoes. "Self," I thought to myself one day, "if I add an apple to this tomato sauce, will it round out / complete the flavor of the tomato?" So I tried adding an apple to a simple pasta sauce, and replied to myself "Self, this isn't quite right... but you're on to something!"

After a few iterations, here's what I have come up with: Saute the following to the desired doneness and serve over pasta:
-diced apple. Golden delicious has worked well so far, but something less sweet might be more desirable.
-some onion. Red and white work well. I do recommend one of the more "onion-y", less sweet onions to contrast with the apples.
-some green bell pepper. Again, contrast with the sweet apples.
-just a little diced tomato. Remember, apples are the star of this show.
-sea salt, red pepper, and oregeno to taste.
-Optionally, also add red wine vinegar and/or olive oil.

Apple on pasta is as easy as any other pasta dish, but offers a very different flavor and texture.

eventId's 1334, 1089, and 1000

2009-05-07T09:26:00.000-07:00

Today, I encountered a problem where my ASP.NET app would not run on my machine. I would get "Server Unavailable" in my browser, and eventId's 1334, 1089, and 1000 in the Application Event Log. The same application ran smoothly on a fellow developer's machine.

Many Web resources suggest using aspnet_regiis.exe enable ASPNET to access the GAC, but that was not my particular problem.

Instead, we have a legacy Visual Studio 2005 Web Application Project (not to be confused with a "Web Site") with unusual configuration requirements: It has to run in a virtual directory located at the root of the Web site. Something tells me this is redundant.

Anywho, steps to make it work included:

Publish to the desired folder (C:\inetpub\wwwroot for example).
Set both the Web site root and the virtual directory root (in IIS) to that folder.
In VS, on the Web section of the WAP's properties, under Servers, select "Use IIS Web server".
In the project URL, put "http://localhost/MyVirtualDirectory".

I hope this helps someone.

First Project with NHibernate 1: Lessons Learned

2009-05-01T16:10:00.000-07:00

The ministry where I work recently completed the first revision of our new Money And Marriage Web site, which we built using several new methodologies and tools, one of which was NHibernate. The team put me, the still-green associate developer, in charge of creating a Data Access Layer (DAL) to house the great ORM beast, taming it if you will. One of the interesting requirements of this DAL was that it should completely protect the app-at-large from all persistence concerns, as well as _not_ expose NHibernate in case we decide to use a different ORM instead. Therefore, the app-at-large would not know of NHibernate, but the person writing the app-at-large would have to refer to the *.hbm.xml (NHibernate mapping) files to understand what MyUnitOfWork.Get(id) would do, precisely.

Because we are still new with NHibe, our code is probably not as useful of a solution as you will find elsewhere; thus I will not misguide the reader with such, but will instead share what we learned:

For any database, no matter how "legacy" it is, an ORM tool is far better than no ORM tool, even if you still find yourself hand-coding some methods to custom-massage Buisness Objects between the BL and the ORM.
For new or (or perfectly kosher old) databases, you can simply use ISession.Get(id), Set(obj), etc. without customizing anything on a per-type basis. Yes, this simplifies your DAL by an order of magnitude! That is, if you have n types in your BL, the number of methods in your DAL goes from O(n) to O(1).
NHibe is rather awkward for working with legacy databases. Be prepared to massage data yourself (unless you simply know more NHibernate tricks than I do and can handle insane / exotic situations).
Before committing to NHibernate (or any other complex tool for that matter), hold some tech talks / lectures with all techies involved to not only get everyone on board, but also to brief everyone in how to properly use the tool. There are a few instances in our code base where we did certain things like handling relationships between entities the manual way, using ID's of related entities in our BO's rather than using references to those entities and letting NHibernate work its relationships magic. Most of these instances were my doing in working with a legacy database. More knowledge of NHibernate would have helped.
Unless you are an uber-brilliant programmer who can simultaneously keep client code from caring about persistence concerns like transactions while still providing a DAL API allowing client code to express persistence requests at the domain level, you should let the app-at-large control transactions. I see no way around it.
You can let the app-at-large be blissfully ignorant of connections, and maybe even caches, except that it should keep track of what objects are and are not attached (persisted).
Some ORM-related concerns, such as the fact that you cannot attach two different instances representing the same entity to the same session at the same time, will still percalate up to the client code, unless you invent an ingenius scheme to prevent that.

Pictures Are Worth More Than Words

2009-04-11T11:45:00.000-07:00

When desiring to open a door, if it has a handle, I pull. If it has a panel, I push. This is true regardless of any sign that may be on the door that says "Pull" or "Push"--I obey the real-world object before I even read the sign.

I find it funny that most hole-in-the-wall stores that have a door with a handle and a sign that says "Push" also have 1,000 other signs and posters and other information that I will not see as I walk in. If there was just one big, obvious sign that said "Push" and no other distractions, I might push on the door to walk through. But I will always pull the handle otherwise. Then one of the store employees comes to open the door for me and says "You have to push on it," and I feel stupid.

Resulting lessons include:
1. Real-world objects, images, and conventions trump any amount of text warning users of exceptions to rules, unconventional behaviors, and other gotcha's and pitfalls.
2. Every bit of text is a distraction from something, or itself will be overlooked. Less is more. Words and phrases > complete sentences.

Take your car, for instance. Does your panel read:

You are travelling at approximately 57 miles per hour. The current engine temperature is approximately 120 degrees Fahrenheit. Your lights are on. ....

Obviously, this would cause problems.

I hope most people know this already. This post is for those who do not. Please, for the love of your fellow humans, make extra effort to make things easy to use, removing the need for long text to read through. Usually, this will save both you and your users time, and keep your users from feeling embarrassed because they don't know how to open a door.

2009-04-11T11:38:00.000-07:00

For archival purposes, my former blogs were:
my personal blog - deprecated by facebook notes.
not-so-daily-devotionals - replaced by this more general-purpose blog.
discoveringsharepoint - my poorly-named SharePoint blog, which I will no longer update because we will be switching from SharePoint to some other product TBD where I work.

2009-04-08T14:25:00.000-07:00

I have created this blog to share information that might be helpful to others. Likely topics include theology, software development, programming languages, user interfaces (including HCI), games (especially video games), and food recipes.

Soli Deo gloria!