2009-11-23T13:34:16Z Lyceum http://blogs.jhu.edu/feed/atom.php/ blawler http://blogs.jhu.edu/blawler http://blogs.jhu.edu/blawler/archives/3422 2009-11-19T03:25:11Z 2009-11-19T03:25:11Z Here is the course outline. Download: uml_introduction_course_outline.pdf]]> blawler http://blogs.jhu.edu/blawler http://blogs.jhu.edu/blawler/archives/3421 2009-11-14T04:14:48Z 2009-11-14T04:16:43Z

UML Course Intro.

UML Course References

UML Course Student Survey

UML Tool Intro.

UML Notation Intro

UML Diagrams Intro

]]> blawler http://blogs.jhu.edu/blawler http://blogs.jhu.edu/blawler/archives/3414 2009-11-14T04:06:38Z 2009-11-14T04:08:19Z Google Docs for most of my course materials.  That is working out pretty well.  Some slides from PowerPoint didn't covert to Google Docs perfectly; some of the things I'm used to doing in PowerPoint can't be done or are difficult in Google Docs.  However, overall Google Docs is working out pretty well. Main advantage is being able to work on the slides from anywhere - very convenient. I also like be able to create PDF versions to use in blog posts or send as email attachments... and being able to share my files froms Docs as read-only version.]]> phf http://blogs.jhu.edu/phf http://blogs.jhu.edu/phf/2009/threads-and-sqlite/ 2009-11-05T19:45:02Z 2009-11-10T08:24:11Z Unix Systems Programming about multi-threaded producer-consumer systems and how to use queues to coordinate them. While going through some examples, I noticed that I had made a really bad call some time ago when I integrated an SQLite database with a multi-threaded web application. Some background? I have a web application written in CherryPy, a very nice but also very multi-threaded Python framework. I decided to use SQLite as the database for my application because I didn't want to deal with the complexities of setting up MySQL or something similar. You may say "That's your mistake right there!" but hey, it's what I did and I don't want to change databases right now. (I also don't want to switch the application to some ORM at this point, but of course I should probably have used SQLAlchemy from the beginning.) In case you don't know: SQLite doesn't like multiple threads to begin with as it uses a global lock for the whole database. Also, the Python interface to SQLite doesn't like multiple threads: You can't share objects created through the interface among multiple threads. So I had to do two things:

1. Get each CherryPy thread its own database connection (the only way to generate more SQLite objects).
2. Handle the (inevitable) case that two threads want to access the database concurrently.

The first was easy to solve: I maintain a dictionary of database connections indexed by thread. When a thread wants to execute a query, I open a connection for it if it doesn't have one already. The only "problem" here was that I had to close and re-open connections once an exception occurred, but this wasn't too hard. The second gave me more trouble: The Python interface to SQLite responds to concurrent accesses by throwing an exception. So if some transaction is in progress and another thread tries to start one, that thread fails. Obviously that's not acceptable, so I had to somehow handle the exception and retry the "failed" transaction. For some reason I got inspired by the Ethernet protocol and the idea of collision handling by exponential backoff. I added a pinch of randomness and limited the maximum timeout to two seconds after lots of performance experiments, but that's what I did. Yes, it may seem like a dumb idea in retrospect, but of course it didn't seem all that dumb at the time: I didn't have much experience with Python threads, I needed to get the application done, and all this actually worked. Amazing. :-D Back to my lecture epiphany: General producer-consumer systems assume n producers and m consumers, but what do we get for m=1? A beautiful special case that solves my problem:

1. If only one thread talks to the database, I only ever need a single database connection.
2. If only one thread talks to the database, all transactions will be completely serialized and there will never be an exception due to concurrent access.

Perfect! Of course this seemed too good to be true, so I didn't really believe I had seen all of the issues yet. Yesterday I finally had the time to re-implement the concurrency handling using a producer-consumer model. And guess what? Learning all I had to about threads was a breeze, the code is less complicated than the previous version, and the whole thing performs better too. Lessons? First, lecturers are people too, so we make bad decisions all the time. Second, think carefully about concurrency issues before you start hacking your next web application. Third, don't be afraid to re-factor an essential part of your application. Fourth, don't get too attached to cute ideas, once you have a better albeit more bland approach, throw out the cute one. And finally, learn what I don't seem to be able to: how to write concise blog posts. :-D Update 2009/11/10: Three things to point out: First, I am still not using the new interface in production, but that's mostly because I changed a lot of other features in my app and I don't want to release too many at once. Second, I had three processes running before, the web app and two "helpers" that would work on the database every now and then. This worked because each process used the same database interface which would retry transactions if they failed. However, the new database interface doesn't retry, therefore I can't have multiple processes running on the database: I had to rewrite my processes as threads of the main web application. That actually worked out well, especially since I now have more control over them since I get configuration and logging support for free from the web framework. Third, in all my excitement about not having to catch database exceptions and retry transactions, I forgot that there are exceptions that I do want to let the caller know about, for example if an integrity constraint is violated. Since the exception now happens in the worker thread but I have to tell the calling thread about it, a brief moment of hilarity followed. I was actually thinking I had finally found The Problem with the new worker thread approach. Alas, Python to the rescue. :-D I simply catch the exception in the worker thread and stuff it into the request object before waking up the calling thread. In the calling thread I check the exception entry in the request before I check the result entry, and if I find an exception, I (re-)raise it in the calling thread. And that works! :-D So far I am still very happy with the new approach. I will deploy it sometime next week for general use, and if something goes wrong then I'll update the post again. I hope nothing bad happens of course, this cost a lot of time already...]]> roseburt http://blogs.jhu.edu/touchy http://blogs.jhu.edu/touchy/2009/followup-meeting-next-week-same-time-and-place/ 2009-11-05T18:44:49Z 2009-11-05T18:44:49Z Next meeting Weds 11/11/09 4PM DMC Game Lab -- we'll go over the grant proposal draft, make any last edits and get it ready to submit. Hope to see you then!]]> roseburt http://blogs.jhu.edu/touchy http://blogs.jhu.edu/touchy/2009/meeting-this-wednesday-nov-4th-4pm-in-the-dmc-game-lab/ 2009-11-02T21:39:04Z 2009-11-02T21:39:04Z roseburt http://blogs.jhu.edu/touchy http://blogs.jhu.edu/touchy/2009/tentative-budget-info-old-needs-to-be-updated/ 2009-10-28T19:44:46Z 2009-10-28T19:51:59Z (most of this comes from the link http://arbi.trario.us/2008/11/02/diy-laser-multi-touch-table/ parts sourced from aixiz.com) the known ($44 total) for the IR lasers:

• 4 x "780nm 25mw laser modules" @ $8 per
• 4 x "89° line generator lenses that fit the laser modules" @ $3 per (this is getting pricey! ;)

the unknown but probably cheap:

• Power supply - probably $10
• wiring/resistors - cheap or we have
• camera with IR filter - we have wiimotes, for more resolution we could slap a filter on one of the mini HD cameras.

That's all you need for the core of the touch stuff, the rest is for a dedicated surface/enclosure:

• Acrylic touch surface @ ? any sufficiently large Acrylic slab that doesn't bend, shouldn't be expensive
• rear projection applique - CAN be expensive, but we can totally find a cheap way to do it. My coworker suggested sandblasting one side of a thick piece of acrylic with almond skins (?!?) instead of an applique, he has the gear to do it.
• frame/enclosure - varies depending on design, we can probably easily cheap out on this part

For installation/mobile use, things get a bit more complicated:

• mirror/prism mountings for the lasers so the light plane can be projected sufficiently close to the surface - might be pricey, might not.
• a large rear-projection screen or improvised solution with translucent plastic

To build a working demo I would be surprised if it is more than $100. other things I think we might want to spec, so that the project can be a standalone unit:

• computer
• projector
• camera (and IR filter)

]]> roseburt http://blogs.jhu.edu/touchy http://blogs.jhu.edu/touchy/2009/3409/ 2009-10-28T19:44:10Z 2009-10-28T19:44:10Z roseburt http://blogs.jhu.edu/touchy http://blogs.jhu.edu/touchy/2009/meeting-tomorrow-oct-28-4pm-dmc/ 2009-10-27T20:44:40Z 2009-10-27T20:44:40Z saya http://blogs.jhu.edu/urchon http://blogs.jhu.edu/urchon/2009/background/ 2009-10-19T17:01:44Z 2009-10-19T17:02:14Z made the background more 2-d to better complement the stick-figure pieces]]>