tcepsa: (Computation Suspended)
Fantastic opportunity--I promise, if you are able to complete this job, it will take your career to new heights:

(Before entering a competing bid, however, I strongly recommend you look at the other bids and consider who you'd be going up against ^_^)
tcepsa: (iSquared)
With the current project I am on, the build consists of a couple of steps:
1) Shutdown Tomcat
2) Run an ant script that does the actual compiling and putting things where they go
3) Startup Tomcat

(When I want to deploy changes that I just made to relatively static things, like Javascript files, I can just do step two)

Cut for excessive geekery )
tcepsa: (Computation Suspended)
One by one the unit tests steal my sanity...
tcepsa: (Inconceivable!)
Actually, at this point it has been somewhere between one year and two since I encountered the programming concept of "closures". When I first encountered closures it was in the context of Javascript, and someone had told me that I should be careful with the toolkit that I was using at the time (Dojo 0.42) because it apparently used them and they have a propensity for causing memory leaks. I did a little bit of exploring but was unable to come up with a satisfactory explanation of what they were or why they would have this effect. The result was that I had a sort of nebulous impression that a closure was something that happened--not something that was--when a newly created object ended up with a reference to one or more of the local variables back in the method that called it.

That was pretty much my understanding--and I knew it couldn't be right but at the same time I was keeping an eye on my memory usage and it didn't seem to be getting gobbled up too quickly, nor did it seem that it was never being released. So at the same time it wasn't really a pressing enough issue for me to pursue it terribly deeply. Then, last Autumn, I went to the No Fluff Just Stuff consortium and learned of a language called Groovy. One of the things that makes it so powerful is that it has fairly extensive support for these closure thingies. I got a slightly refined understanding of closures (at least Groovy closures) during the conference and figured that maybe they had decided to use the word (which I still thought was more of a verb) to refer to these somewhat magical functions that could be passed around like variables and have properties like objects and retained references to the local variables that were in scope when they were created.

And now today, about four months later, I was reading the appendix to this article and came across a parenthetical statement that finally tied everything together: "In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) [...]"

It's like there's this lightbulb in my brain that I screwed in back when I first heard the term, and it's been sort of glowing dimly off a trickle current this whole time, and when I read that finally it flared into brilliance! It's called a closure because, for all practical purposes, it's enclosed!! And therefore it can see all of their variables! And furthermore it can screw up garbage collection because it has a reference back to the enclosing object and garbage collection only happens on objects that aren't being referenced by anything that is, or is being referred to by, something on the stack! It doesn't actually screw up garbage collection--GC continues to do its job just the way it is supposed to--but it can trip you up, and that's what they were talking about when I first heard the term.

EUREKA!!! ^_^

(while my understanding may still be less than complete, it is a quantum leap better than it had been before reading that sentence ~grin~)
tcepsa: (iSquared)
I have begun combining my love of (and desire to become better at) music with my computer geekery and developed a Java application that turns any standard 101-key keyboard into a MIDI musical keyboard (actually, I should double-check that...especially since I use certain keys such as '\' that aren't always in the same place).

For those of you who are familiar with Tracking, this uses a slightly different layout (though similar concept) for the keyboard arrangement. Instead of starting with C4 at 'z', I put it at 'v'. This results in the overall range of the keyboard being from F#3 (assigned to 'a') up to A6 (assigned to '\') and also means that I can play certain songs where they were written to be played, instead of having to transpose up an octave to get at all the notes.

As an example, here's how to play a slightly simplified arrangement of Ashokan Farewell in the key of D (with spaces to approximate most of the sustained notes ~grin~):
.2w 2/.k nk, knbcb cxbk.w55t5e .2w 2/.k nk, knbcb cxbk.w5.2ew k,. kbw ./2w.k nk nbc zx . knbk.q w/ 2w.k bxbk.w knbgb

And, as a bonus, here's Simple Gifts:
bb, ,./, /qw wq/ .,. . . , ./.,b b ,k,./ ../qw q/. ../ /., ,., w / ./q/., ./ /qw q/. ./. b, , ././qw q/. . / / ., , ,

And further extra super bonus, here's Prologue from some of the early Final Fantasy games:
b,.bq /.,k,.,,k n./nw q/.l/.n/. b,.bq /.,k,.,,k n./nw q/.l/.n/. e ew /qq/.l./qw r re qw w3w w3wq/.

(Oh wow... these are so much easier to read than notes on a staff... too bad there's no good way to indicate length of note this way ~wry~ Then again, I've spent a lot more time doing things involving sight reading text--even with weird punctuation--into a computer keyboard than I have involving sight reading music into an instrument, so it's not terribly surprising that it is easier (though I am still a little surprised at the degree to which it is easier...))

... and I should probably actually figure out some way to post the program, so if someone who reads this wants to actually try it they can ^_^


tcepsa: (Default)

April 2015

   12 34


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 04:20 pm
Powered by Dreamwidth Studios