Dr. Neelima Shrikhande is a professor of computer science at Central Michigan University. At the time I was working on my MS, she was the only female professor in the department. I never had an indication that she views herself as a role model for the few women studying computer science there, but she is definitely a role model.

She's a super intelligent and focused woman for whom I have a lot of respect. According to the cmich.edu website, she "is an authority on computer vision and artificial intelligence. She studies how to make computers capable of seeing things and understanding pictures."

I had her for only one class, my compiler class, but she really opened up the world of computer science for me with that class. It was a hard and life-consuming class, but I loved it more than any other class and even used what I learned for my thesis. I now have a life-long fascination with compilers and virtual machines because of that class and I still have my dragon book. At the time, I never thought about this, but I imagine that class was at least as hard to teach as it was to take, but she held up to the challenge seamlessly.

Thanks, Dr. Shrikhande, for being such a sharp, successful role model in computer science.

Shameless plug: the CMU CS department is a great place for an education!

I've not paid much attention to her aside from being aware of her and knowing she's the namesake of the Ada programming language, but I've benefited tremendously from her contributions and the contributions of other women in technology for most of my life.

I read up on Ada at Wikipedia and learned this bit of trivia today, "she was the only legitimate child of the poet Lord Byron and Anne Isabella Milbanke."

I won't spend a lot of time dwelling on her interesting life, because Wikipedia does that far better than I could, but I'll take this opportunity to make mention of some current-day pioneering women in technology, the women who are advocating and teaching other women about Linux, computers, and other free software via LinuxChix.

LinuxChix is a community for women who like Linux and for anyone who wants to support women in computing. We are an international group of Free Software users and developers, founded in 1999 with the aim of "supporting women in Linux." Founder Deb Richardson described it as an alternative to the "locker room atmosphere" found in some online technical forums and gave LinuxChix two core rules: "be polite" and "be helpful." LinuxChix is now many things to many people, but it remains primarily a group for supporting women in computing, specifically in Open Source/Free Software/Software Libre computing.

If you're a woman in need of help or able to offer some help to others, check out LinuxChix!

After a review and comparison of various IaaS, PaaS and SaaS services, the talk then focused on details of Amazon's overall cloud offering. Finally he finished out the presentation with a discussion of software developer best practices - the primary reason I attended. More time spent on software development would have been a big plus in my view, but I can understand that he felt the need to get everyone in the room up to speed on Amazon's platform. It was a big crowd.

Cloud Computing Development Best Practices

The ten best practices Jorge espoused were:

1. Build cloud apps, not apps in the cloud
2. Virtualize the application stack
3. Design for failure and nothing fails
4. Design for scalability
5. Loose coupling lets you maximize plug and play
6. Design for dynamism
7. Build Security into every component
8. Leverage native cloud storage options
9. Leverage best cloud Management Tools
10. Don't fear cloud constraints

Of those ten, the two points that gave me the most pause for contemplation were to "build loosely coupled systems" and to "build security into every component."

Build Loosely Coupled Systems

"Build loosely coupled systems" brought a flash from the past, triggering a memory of a distributed operating systems class I had in the 1990s. The concept of loosely coupled systems was new for me back then and made a big impression, so I dug out my old textbook (yes, I kept them all!) to refresh my memory. The textbook was "Modern Operating Systems" by Andrew S. Tanenbaum.

Skimming through the material, even though it's dated, it's still relevant to today's cloud environment. While the Tanenbaum book was focused specifically on operating systems, Jorge's cloud development recommendations of "use independent components", "design everything as a black box" and "load-balanced clusters of black boxes" have much in common with a distributed OS design.

Tanenbaum offers much more detail in his section on design issues of distributed systems that seems relevant in this context, with the first being transparency.

• Location transparency - we want to design software so that the actual location of other resources is irrelevant. They could be in the same local Amazon zone, or they may be halfway around the world - it should not matter
• Migration transparency - not only must we not care where the resources are, we also must allow resources to move about seamlessly
• Replication transparency - we must be able to make additional copies of resources without side-effects
• Concurrency transparency - we should be able to share resources concurrently
• Parallelism transparency - Tanenbaum points to this as the most difficult to achieve, the ability to process in parallel seamlessly without the need to explicitly cause that to happen

We may be designing black boxes, but they need to be black boxes that can operate transparently with one another.

The other important design characteristics that Tanenbaum discusses are flexibility, reliability in terms of availability and fault tolerance, performance, and scalability. I think these points are a bit more obvious and won't add any further explanation.

Cloud Computing Security

The other main point I've been contemplating since the talk is in the area of security. Being the development security evangelist at my company, it was natural that I'd focus in on the brief security portion of the talk. I'm sure that an entire meet-up could easily be filled just on the topic of security, so the single slide on the topic rubbed me the wrong way.

Jorge's bullet points were as follows:

• Use de-perimiterized security model
• Create distinct network Security Groups for each Amazon EC2 instance cluster
• Use group-based network rules for controlling access between components
• Restrict external access to specific IP ranges
• Encrypt data “at-rest” in Amazon S3
• Encrypt data “in-transit” (SSL)
• Consider encrypted EBS file systems for sensitive data

While these seem like a good starting point, I want to delve into a little more detail on some of the points.

De-perimiterization, as I understand it, means moving the burden of security onto individual machines and applications. While this pushes the security to where the threat is, it seems to me that it also raises the maintenance overhead of security and I would think that could lead to a higher risk of not keeping all of the instances in-sync and current in terms of their security footprint. I suppose the next two bullet items are meant to address that issue to some extent by using security groups, but then doesn't the group somewhat defeat the idea of de-perimiterization? In a smaller network, relying on groups seems reasonable, but I wonder how well it scales unless a hierarchy of groups is introduced, but then it's no longer de-perimiterized. This isn't my area of expertise and I'm just speculating. I tried to find some writings on this topic by people more knowledgeable than me, but haven't found anything relevant yet. I'll update this post if I do.

The three encryption-related bullet points, "encrypt data 'at-rest' in Amazon S3","encrypt data 'in-transit' (SSL)" and "consider encrypted EBS file systems for sensitive data," all bothered me. I don't necessarily feel safe just because something is encrypted, especially if the storage device it's encrypted on isn't under my control. As Bruce Schneier wrote very eloquently, "As soon as you give up physical control of your computer, all bets are off." Always a good read, he further writes,

In the meantime, people who encrypt their hard drives, or partitions on their hard drives, have to realize that the encryption gives them less protection than they probably believe. It protects against someone confiscating or stealing their computer and then trying to get at the data. It does not protect against an attacker who has access to your computer over a period of time during which you use it, too.

Since Amazon's entire AWS infrastructure is basically a black box to us all, I'm skeptical that we should rely in any way on encryption for very sensitive data.

Closing

Overall, I really enjoyed the talk and wish the development points could have been discussed in much further detail.  It definitely gave me much to think about and highlighted topics for further reading. Hopefully, more meet-ups will be scheduled to delve into development issues for the cloud.

After several years of experimenting with css rounded corners and transparency and the various perplexing cross-browser issues, I've redesigned this website and even moved it over to a new platform. Gone are the strange hoops I needed to jump through to add new stories to this site.

Here's one last glimpse of the original Geek on the Loose:

I've also put a lot of effort into trying to follow good SEO principles on the new site. It may not have been obvious, but the old site was created before I had studied up on SEO and probably violated every major principle. It was a real SEO train-wreck. It will be very interesting to find out if I've learned anything or not.

The discussion focused on efforts to separate Java programming from the nitty gritty details of threads. This separation allows a greater number of developers to successfully program for parallel environment by removing focus on the technical details, and thus reducing the knowledge required to write the code. There's also some coverage of the benefits of the higher level of abstraction of functional programming and how the functional programming style is being incorporated into the Java concurrency model. The text has this:

The future will be functional programming or won't be at all.

Intellectually, I applaud these efforts. Emotionally, I feel some loss.

My first introduction to threads was in a systems programming class, using the C language and Pthreads library. Pthreads blew my mind, or maybe it was lack of quality in the lectures. Either way, determined not to be defeated by Pthreads, I went out and bought a stack of books on Pthreads and threads in general and set out to wrap my mind around threads. It worked, but along the way, I learned that I loved the challenge and so I embraced concurrency and parallelism with much enthusiasm. This knowledge that I've accumulated will always be of great value, but as I move toward programming threads at further and further abstractions, I'll lose that close connection to the internals, and I'm a little saddened by that.

From the announcement email:

Professor Martin Odersky is the director of the LAMP group at EPFL, the creator of the Scala programming language, and author of Programming in Scala.

Josh Suereth hosted the first Scala Lift Off East in Reston, VA and has been involved with lots of Scala projects including scala-tools.org, scala-arm, scala-io, scala-jigsaw, and scala-lolz.

Here's the current OWASP 2010 Top 10 list (this is release candidate 1, so it could change):

1. Injection
2. Cross Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Failure to Restrict URL Access
8. Unvalidated Redirects and Forwards
9. Insecure Cryptographic Storage
10. Insufficient Transport Layer Protection

If you are a developer and you don't know what some of these security risks are and how to avoid them in your code, then you should be reading this: OWASP Top 10 2010 RC1 (pdf).

Today, via DZone, I discovered this super nifty HTML5 sketch pad demo.

I'm really looking forward to the widespread use of HTML5, especially since Adobe can't be bothered to make their Flex Builder work in Linux.

A tale about iteration, unexpectedly large data sets, and time...

About a month ago, a large file of data unexpectedly needed to be processed, using some pre-existing code written several years ago. This code happened to be written in Java, but this story could apply to most any commonly used programming language. It was a batch process, so speed wasn't of the utmost essence, but at the same time it shouldn't run on and on and one because other files also needed to be processed. The data set was 500K records, whereas the larger data sets normally are in the 20-30K range, so this was more than 10x the norm.

Everything seemed to be going fine. The file was read into a database and some processing had been done on it and the time had come to write out a result file. Along with results, the original programmer had wanted some statistics, so there was a quick iteration through all of the records to gather the statistics and then the results would be written into the file. It seemed straightforward and I didn't expect anything to go wrong. When things go wrong on files, my experience has been that they usually go wrong earlier on.

Time...

I waited for the file, and then waited some more. One hour passed, and then another. Where was the file?

Normally, this process will update a status table in the database to indicate what it is currently doing, but it hadn't updated that record since the file writing phase had supposedly begun. Starting to worry that it was hung or deadlocked, I set off to investigate. The CPUs on the server showed that something was going on and it certainly wasn't idle, but they were only 35-45% busy. The memory was not paging. I checked the database and couldn't find any sign of deadlock.

Being a true lover of code, I did the next obvious step from my point of view – I read the code. I found the relevant bit of code and started tracing through that file writer step-by-step. What I discovered was that the statistics gathering phase wasn't written in a particularly optimal way. The developer had probably never imagined that such a large file would ever be processed.

Loop de doop...

What had been coded was a single loop through the records that were stored for the original file. Each record would be read, then another lookup of related data was made, and then a third lookup to map a simple translation was made. All three queries were very simple and used primary keys or indexes, so individually, they all ran very fast. Each lookup resulted in some statistics being updated, and the mapping applied nice text labels to the numbers so that humans could make sense of them. The code was O(n), so not O(1), but not so bad for the usual case.

It took almost 4 hours for the statistics to be gathered for all 500K records, for a total of 1.5 million queries, which worked out to about 0.48ms for each set of three queries. For 25K, that would be about 12 minutes. Unless someone was watching carefully to see the progress, in normal batch processing, 12 minutes would not usually be enough to send up red flags and catch anyone's attention.

Of course, this discovery was just the beginning. Naturally it had to be fixed. That's where the events of this week come in to play. I had some time set aside to look at improving the code this week, so I immediately set about finding a way to let the database do the work. After a few hours of composing and testing queries, I had it! A single query that could gather all of the statistics on the 500K records including the text labels, and do it in 1 minute 41 seconds. That felt good, really good!

These are the six books I received:

1. The Code Book, The Science of Secrecy from Ancient Egypt to Quantum Cryptography, by Simon Singh
2. Train Man, the novel, by Hitori Nakano
3. Zero, The Biography of a Dangerous Idea, by Charles Seife
4. The Geek Atlas, 128 Places Where Science & Technology Come Alive, by John Graham-Cunningham
5. The Annotated Turing, A Guided Tour through Alan Turing's Historic Paper on Computability and the Turing Machine, by Charles Petzold
6. e: the Story of a Number, by Eli Manor

I haven't had time to read any of the books yet, but have thumbed through all of them enough to give a brief overview and my first impression of the quality of the book. It should be noted that these books were all on my Amazon.com wish list (thanks to Amazon for suggesting them for me) and I've read the reviews and any excerpts that were available.

The book that I've given the most attention to so far is The Code Book, and that's because I have three puzzles to solve. After my brother-in-law saw that I'd received a cryptography book, he asked if I like that sort of stuff and then promptly produced printouts for three puzzles he needs to solve to be able to locate geocaches. (I've solved two so far and one is partially solved)

The Code Book is a pleasure to flip through because it's packed with illustrations, examples, photos and more. I find it impossible not to stop on pages with interesting graphics to read a little and what I've discovered so far are troves of ciphers and codes interspersed with interesting stories about the circumstances and people involved in those discoveries. Case in point, the curious turn of circumstances that lead Whitfield Diffie to spontaneously hop in his car and drive 5,000 km "to meet the only person who seemed to share his obsession," Martin Hellman, thus setting the stage for the Diffe-Hellman-Merkle key exchange.

The pages I've read in this book have been engaging and educational, and the math is minimal so as not to off put the less mathematically-inclined reader. I happily give a hearty thumbs up to The Code Book.

Train Man is a very unusual novel. This is the only book on the list that Amazon didn't suggest for me. Instead, this suggestion came from a fellow Twitter user named @rodet . What makes Train Man different from standard novels is that it takes place as an online conversation between Japanese Internet chatroom participants. It follows the story of a geeky young man and a young woman he meets, charting the progress of their relationship. The Asian emoticons and ascii art used throughout the chats are nifty and will require some deciphering. This book would definitely not be for everyone because of the unusual format, but I'm pretty sure I'll enjoy it.

On the back cover of Zero is written, "The Babylonians invented it, the Greeks banned it, the Hindus worshipped it, and the Church used it to fend off heretics." I never realized that the number zero had such a history. This book looks at the uses and misuses of the number zero throughout history and the current controversy surrounding it. The book has quite a few illustrations and some math, but not too much. I think it will be an interesting read. The last appendix is titled "Make Your Own Wormhole Time Machine."

The Geek Atlas is a fun book highlighting "128 destinations around the world where breakthroughs in science, mathematics, or technology occurred - or are happening now." The book gives a few pages of information about each site with a web link or other source for more information and when to visit. There are a lot of places included that I'm not likely to visit, such as the Chernobyl Exclusion Zone in Ukraine, but many others that would definitely be worth some time and effort to see. It looks like a fun book.

I wasn't expecting The Annotated Turing to be a big page-turner, but am pleasantly surprised at the extensive annotations contained within this book and am thinking my preset notions about annotated works need to be re-evaluated. In quickly flipping through the book, the casual observer might think it's filled with more of the elaborate Asian emoticons as in Train Man, but no, that's math, and a lot of it, and it looks a bit daunting, but it will be great for keeping my brain spry and young.

I'm expecting to particularly enjoy the final book, e: the Story of a Number, in part because I recently finished reading a terrific book, Prime Obsession: Bernhard Riemann and the Greatest Unsolved Problem in Mathematics, by John Derbyshire. In thumbing through the book, I discovered a fun section on e and its relationship to music that confirmed my expectations that I should enjoy this book thoroughly. As would be expected, this book contains quite a lot of math and is not for the faint-hearted.

That's it for new books to read. They should keep me busy for quite a while.