Unicode Explained
June 23, 2006
Jukka Korpela, whose well-researched writings on characters and encodings are standard references to which I frequently turn, has written a book on Unicode that has just been published by O'Reilly. Marvellous. I've been waiting for this one. It's likely to be a few months before I get to it, but I'm very glad it's there.
Coworker in accident
June 23, 2006
I just got word that a coworker and her four children were hit by a car yesterday as they were walking near their home. We don't know their status other than what's in that article, as the family has more important things on their mind than contacting the office with updates.
I've worked closely with Stacy for years (her husband recently joined us here as well), and these are some of the most adorable kids you've ever met. They are in our thoughts and a whole lot of prayers.
OWASP meeting summary
June 21, 2006
I made it to Tuesday night's Minneapolis/Saint Paul OWASP meeting for the first time this year. It's good to be back. There was good information and conversation both during and after the meeting.
Tim must have drawn the short straw to be scheduled first, so he got to deal with the usual projector problems. But once things got rolling, he treated us to a demo of a few free or low-cost scanning tools. He has notes on his blog. From what we saw tonight, what really differentiates higher-priced commercial scanners/pen-testing tools like AppScan and WebInspect is the reporting. It's obviously not that simple, but man it makes a difference. Reading a Still, I'm with Tim: the Burp suite is a nice toolset, I enjoy using it.
Bob Sullivan gave us a quick overview of what's new in WegGoat 4.0, a teaching tool for web application security. One thing that I'm glad to see is moving the documentation to the OWASP wiki. There's also an Eclipse developer environment using WTP, but I haven't investigated to see exactly what that means.
Next Joe Teff gave a quick demo of Fortify's source code analysis tool. He was quick to point out that he wasn't selling the tool, but he had experience with it with his job at Wells Fargo and thought it was worth talking about this type of tool. I don't know if there are open source tools in this space, but it is at least heartening to see more and more commercial tools building on the Eclipse platform. As I understand it, source code analysis tools take a couple approaches. Static analysis is essentially a glorified grep, searching for problematic patterns. In dynamic or runtime analysis, the binary is examined while it is running. Fortify seems to do the latter, and is connected to your static source code to trace problematic data paths through the app. This is simple for small or standalone apps (think jar, war, ear), but it sounds like you have to jump through hoops to make it work with a distributed app. Possible, yes, but SOA will push the limits of these tools, so I expect some movement on that front in the next couple years. Unless I completely misunderstand how they work, which is possible. Either way, interactions at the boundary between two applications/modules/services merit close scrutiny; relying on a tool alone is insufficient.
Gunnar Peterson gave a quick overview of the goings-on at AppSec Europe. Good stuff, I'll have to check out the presentations and watch for video. I really need to attend an OWASP conference. One interesting takeaway is a discussion of whether the open source world is keeping pace with Microsoft on the development and dissemination of secure development practices. Johan Peeters has a summary and interestingirritatingly pedantic discussion in the comments. Note to self: take another look at CLASP.
This meeting came at a very good time, as I actively work on improving how we incorporate security into our development process. Much as I resist generating documentation that does not move us closer to working software (and do like docs that help us get work done), I am cautious about introducing tools that may chew up cycles without sufficient benefit. Penetration testing software has an obvious place in the SDLC, but it comes too late in the process to intervene with a train about to derail. I used to be suspicious of code analysis tools but have warmed to them. I believe that they can help developers learn more about secure coding practice. If they can tie into bug reporting and tracking, all the better. (I'm also becoming a fan of metrics.)
I want to stay clear of the notion that it's all a developer problem, though, which I think a focus on development tools tends to encourage. "Oh, those darn developers, if only they'd just think!" Yes, developers need better security education. So do designers and architects. More on that another day.
OWASP-TC Meeting Tuesday
June 19, 2006
I keep forgetting to mention this. The Twin Cities OWASP chapter is meeting Tuesday night this week at the Minneapolis campus of Metro State (right near MCTC). Directions and details are on the chapter page.
Tim McGuire will be talking about free and open source pen-testing tools, and Joe Teff will talk about Fortify, a commercial source code analysis tool. Looks to be a good meeting. Since I've been unable to attend the last two, I'm looking forward to it. Maybe I'll see you there!
Signing Time Visit
June 12, 2006
Rachel Coleman and her daughter Leah of Signing Time fame performed at the Minnesota Children's Museum last week, so naturally we had to bring Owen and Alec. We all had fun.
You may recall that we've been using sign language with our kids from an early age. Neither Kiara nor I is fluent in ASL, but we could learn enough to help Owen express himself before his verbal abilities took off wildly. He still loves to sign, and I know that he'll have a lot of fun signing with his little brother.
Stages != Iterations
June 12, 2006
A recent conversation made me realize how easily a mismanaged iterative development cycle can become a waterfall.
Break work out in stages, fine. Use those stages as short iterations with scheduled releases, building toward a final release of a "finished" product, good. Build on what you learn during those iterations to progressively refine your understanding of the requirements and your design, good.
Uncover important requirements and/or significant design flaws in early stages, but explicitly label these findings as "new features" that won't be implemented because you didn't know about them during the Big Design Up Front and now you don't have time… not good. You've just missed the point and lost the advantage of iterative development.
It's not enough just to know that requirements will change during development: you should act accordingly and build your process around the expectation of change. When requirements change (and they will), but you respond as if they have not and must not, then your process is broken.
Been out of contact
June 08, 2006
I've got a lot of email the last couple days (a surprising amount of it in response to my Jabber post the other day … gotta enable comments) but haven't been able to respond because I've been dealing with a family health issue. Nothing that massive amounts of antibiotics and painkillers won't help, hopefully, but please know that I haven't been ignoring you. I've just had other things going on.
A sign of things to come?
June 05, 2006
We had a "town hall" meeting today to discuss the MnSCU ITS workplan for the next year. It was only hours later that I realized that it didn't follow an all-too-common pattern of telling us a whole bunch of new stuff that we could have got in email. Instead, a PowerPoint overview was distributed beforehand (the narrative version is being written next, otherwise I hope that's what we would have got), and knowledge of the contents was just assumed during the meeting. This opened up the meeting for discussion.
Marvellous. I am no fan of using meetings to disseminate information, so this is a very welcome change.
Jon Udell: Earth to Google PR
June 05, 2006
Jon Udell shares a sadly amusing anecdote about the sort of thing that gives PR flacks a bad name.
I share this not only because it's sad and funny, but because it means Jon's likely to write about GData. I'm looking forward to that, because I have a hunch that GData will be important. Stephen O'Grady explains why in far more detail than I have time for, so just go read that. Or since they're having problems with their web host, read a cached version. Fundamentally, a relational database isn't always the best solution for storing and manipulating data, and as Adam Bosworth has argued, we need new ways to access/manage our data in its various stores. GData, an Atom-based format, is a step in that direction.
Pushing the job to security
June 05, 2006
I'm taking a more active role in the direction of my career, moving it in new directions, and I think it's time for a retrospective.
Until a few years ago, I worked on a team that supported primarily department web sites (for the Office of the Chancellor at Minnesota State Colleges and Universities). I thought of myself as mostly a backend guy: PHP and mod_perl web development, Apache and MySQL administration. The others on my team did more direct support of department users. Or so I told myself. In retrospect, I did a lot more user support and was more closely connected to the front end than I believed. I was (am!) still the web standards advocate leading the way in CSS adoption. I was (and am) the accessibility guy, leading accessibility instruction for our college & university webfolk and even faculty. I don't say this to toot my own horn, but rather to highlight that even though I thought of myself as a backend developer, I was very closely tied to the user experience. Certainly my Java programming colleagues on the other web team in the office knew this, but they readily admitted to hating HTML, CSS, and JavaScript, so were eager to find someone who gave a rat's ass about that side of the work.
Not much has changed, come to think of it.
When my position got shifted in a reorg and I got moved onto the Java team working on enterprise web apps, I became the UI guy. On a team of Java programmers, most of whom were new to web development, this made sense and it's a role I readily took up. Our web apps look like crap. They could use some updating. The team structure was a mistake: hiring began before our supervisor was brought in to weigh in on skillsets that we needed for web development, so we ended up with a team who all think of themselves as Java programmers instead of web developers. Sure, they're smart people and decent programmers, and maybe web development isn't rocket science, and I mean no disrespect to my coworkers, but geez it makes a difference in the quality of apps you produce. But I've already written about that and will write more.
My role right now is primarily defining the user experience. I work with business analysts and stakeholder groups to spec out the user interface and application flow, and help the developers work out the annoying details like how to do something with JavaScript or CSS. It's fun work. The past year or so I haven't been too involved in much coding — and that's okay, since I'm not a huge one for JSP and my feelings about Java as a web development platform are known and not favorable. :)
Another part of my role that I've been trying to expand is web application security. So far there aren't a whole lot of people pushing very hard to make it part of my job, but that situation is improving.
What's missing is a connection to education. No student contact, although I've been working on software for student services. I don't feel a connection to online learning, to educational technology … I'm privileged to be a part of an educational system: I grew up wanting to teach and still want to be involved in education, but really I'm not. Organizationally we're divided sharply between academic and administrative systems, and I'm on the admin side. I hope that distinction will blur, that we can put development resources more directly toward educational goals, but we'll see.
A recent meeting also made me realize that I feel out of touch with open source software. I've taken it for granted. Almost everything I work with is open source — web frameworks, JBoss, Eclipse, LAMP —. Some of that has been a struggle, and and it's easy to forget the struggle and overlook when open source isn't even on the table in places where it makes sense: data warehousing, content management systems. (Actually, I didn't overlook open source in the CMS question, I threw up my hands in disgusted exasperation after six years of inaction.) Anyway, open source is making inroads into our colleges and universities, and I want to find a way to be a part of that.
I feel like I did in college, when I spent an ungodly amount of time wrestingly to unify courses of study in French, historical sociolinguistics, religion, and medieval history. I want to bring together web standards/user interface/user experience, dynamic languages, agile software development, open source, educational technology, and security, all while still trying to do the day-to-day work necessary to get software out the door.
Which we barely do, but that's another story.
Sometime in the last few months, it struck me that I haven't been taking active charge of my career, I've just been going wherever events have taken me. That's not entirely true, of course, since I did get the hell out of my HR job when I realized that it was being pushed in a direction I didn't like. I don't want to just float along anymore.
I have decided that if I need a focus in my career, it won't be user interface. It will be security. Through everything I've done, that's been a common thread. As I mentioned here a short while ago, software security is a big problem, the elephant in the room that is partly responsible for what Noam Eppel describes as The Complete, Unquestionable, And Total Failure of Information Security. At MnSCU, we're taking steps in the right direction toward improving software security, but we can always do more. I'm running up against a wall in what I can do as a single developer to infuse security into our software development life cycle. I can work from the bottom up, but I'm realizing that we also need to work from the top down. Secure development should flow from and be traceable to policy, to help identify standards and establish metrics. But all the policy and best practices in the world won't help if the developers don't know how to write secure software, and the architects don't know how to, well, architect with security principles in mind. We need to approach the problem from both directions to be successful.
My secret goal over the next few months is to lay the foundation for more of that top-down software security work, while continuing to push more aggressively up from the bottom.
And in terms of professional development, I may well pursue more schooling. I have a lot to learn.
So expect a lot more writing about security here. Along with everything else, of course. Plus ça change…
Jabber and grid computing
June 04, 2006
Bill de hÓra, Using IM for grid computing:
When I look at the OGSA stack I'm fairly sure XMPP is to Grid and JINI as HTTP was to WS and CORBA. Give it a few years - instant messaging is where real commodity grid action will take place.
Yes. I've been poking at Jabber for four or five years now, drawn not only by the idea of open source and open standards for instant messaging, but also what the idea of presence might mean to software. Grid computing is a fascinating problem space, one for which I feel I have an insufficient computer science background to completely grok right now. But from what little I understand (not much more than you get from Tim Bray's explanation), XMPP and something like the Jabber XCP would be a good fit.
From a comment by James Governor on Bill's post, I see that Coté discussed what presence might mean for systems management, well worth reading. I wonder if the Open Management Consortium people are thinking about this. He also gives an example of how presence might be used to facilitate messaging at a transaction or business object level in application programming. That's the sort of thing I've been thinking about on and off over the years. A platform like Java's may have its own messaging framework or three, but cross-platform messaging using something other than SOAP and HTTP would be nice. Coté touched on this, too, with his comments about the web services monoarchitecture. Seems we've been here before… Presence just adds a whole new interesting wrinkle.
Bill also points to ejabberd. Why? Because it's written in Erlang, a language that was designed for distributed, concurrent programming, which seems obviously useful for grid computing. Erlang may well be my next language. I've been thinking that it might be Smalltalk, or Lisp, or Haskell (the latter because I want to work with more and different examples of functional languages) but Erlang is a contender. The problem is that as I have not needed to solve many concurrent programming problems, I may not be ready for Erlang until i've got a few more years programming under my belt, or a really nasty project to work on that fits nicely in its problem space. Like, say, a large, distributed IM and presence messaging network for which I want to use ejabberd.
Tackling the Lawn
June 01, 2006
After just a year of benign neglect, the grass in our front yard has given up and died. If it happens that easily, it tells me that we're dealing with a non-native grass. I'm not one to obsess over my lawn, so I'm not about to fertilize the hell out of it every year for the sake of a grass that doesn't even belong here. No, now we're on a mission to turn our front yard into a native prairie.
Perhaps that's a bit extravagant. (Are prairies extravagant?) It's a small lot; I don't know that it will count as a prairie. But they will be prairie plants.
Over the next several years, we're replacing our front lawn — such as it is — with grasses and flowers that are native to this area, that thrive in medium-dry soil and lots of sun, that will require less maintenance and be better for the environment. We started by going out to Landscape Alternatives, a nursery that specializes in just this sort of project. They're great people who really know their stuff. I heartily recommend them.
We're starting this year by tackling the 4-5 foot hill going down to the sidewalk. We'll lay down six or more layers of newspaper covered with wood chips, to kill the grass and weeds that are there now. Then we'll put in the plants, one every square foot, water it a bit, and carefully weed over the next year or so. After that, the plants should come back happily on their own, and suppress most weed growth on their own.
Over the next few years, we'll move back toward the house bit by bit. We'll have a stone path, a bench, even a hammock and a koi pond! Maybe not the pond. Neither of us is a gardener, so even this year's small step is an ambitious project. But I'm very much looking forward to it.
