Archive | Tech
A friend of mine just planted a geocache in which you needed to use polyalphabetic substitution to solve it. This was a kind of cipher I wasn’t familiar with and I have to admit — I was intriqued.
Like most lazy computer guys, I wrote a program to encrypt the puzzle instead of solving it manually. It was an interesting excersise — the code wasn’t hard, but you had to have a good understanding of arrays and how they work in your language of choice. I chose Python, and I had to think a little about lists before getting things quite right.
Implementing a polyalphabetic substitution may be a decent excercise in learning a new language.
The other day I was installing a CPAN module and I was doing it the normal way:
sudo perl -MCPAN -e "install ModuleName"
And it didn’t install — I got a GPG permission error. It seemed odd. I tried it a few times and that didn’t work. So I tried to upgrade CPAN. And I got the same error! I was bedudled. So then I downloaded and compiled the latest GnuPG. But I got the same thing!
And then it hit me. I was running Perl under
sudo. So when it ran
gpg it was running it as root but still trying to get to my keystore under
~/mikeh/.gnupg, where it didn’t have permission to read. So this time I did:
sudo su - perl -MCPAN -e "install ModuleName"
And it worked like a charm.
sudo a lot to install CPAN modules before, but I guess I never tried installing one that required a gpg signature check.
 Sorry for not having the exact error. That’s what happens when I don’t blog right away.
Some of you may be surprised that I haven’t actually used Struts before. Because of all the J2EE projects I’ve worked on, Struts was not part of the picture (it’s what our customers used to build their applications with our middleware product). Well, it’s high-time I start filling in the blanks in my experience.
I started with another Struts book, but that started out with, “Hey, look what I can do with Struts!” And that doesn’t help me. I wanted a book that will take me step-by-step through an application and that it what this book does. Is that application contrived? Of course. But I don’t think that any other book would be any different.
The app that you build starts off slowly — he reviews something in the chapter, and at the end of the chapter has you do it in the application. He almost shows you exactly what you need to do the narrative — the parts he leaves out helps me to grapple with why I need to do something. That is how I learn – by making mistakes and/or playing around with something.
So that’s what I did like — the pace, the little pieces at a time, and the fact that he knew what he was talking about. Other things I liked was how Struts is connected to MVC, some best practices at building a Java web application, and some things that he led you to figure out yourself.
Some things I didn’t like:
- The application you download is built via a Windows .bat file each time, even though he recommends Eclipse. So I installed Eclipse with the Tomcat plugin, which worked wonderfully. I don’t know what I would have done having to build with his batch file each and every time. But he could have had at least an appendix on how to setup a project in Eclipse.
- Some of the reference material in the back was almost worthless, like on the methods in some of the standard Java objects.. Not enough content there, although I realize that this isn’t meant to be a reference book
- I did have to go in a tweak some of his DB wrapper code to get it to play nice. Maybe it was because he wrote it with JDK 1.4 and I had JDK 1.5. No matter — throwing in a couple of generics made it much easier.
Would I recommend this book? Yes — for someone who really doesn’t know anything about Struts, it’s a very good book. If you know a little about Struts, you should look elsewhere. But you should know that by looking at the word Beginning in the title.
So I give is 3.5 out of 4 stars
One of the most important things in testing is keeping track of the defects you find. That way, everything is in one in place, and you can easily pass issues back and forth. This week I’ve been evaluating Trac and I have to say that I’m impressed, and I haven’t gotten to all the functionality yet.
Trac is a combination wiki, defect tracker, and svn watcher. I’ve setup and used wikis and Bugzilla before, but the combination is really quite ingenious– you can have a wiki-link from inside an issue summary or in a case. That wiki link could be to anything — more detailed docs, a setup document. I didn’t mess with the wiki very much or the svn watcher (because our svn respository isn’t up yet) but I spent a lot of time with the ticketing system (i.e. defect tracker).
I’ve setup and used Bugzilla before. And it’s nice, but building a query can be overwelming and you can’t build your own reports. Adding custom fields is a pain as well. But Trac makes all of this easy. You can build reports going against their database, even though they are deprecating it. Too bad — I understand the reason, but I was able to build reports with it that I couldn’t do with the query module. Oh yeah, the query module – it’s what they recommend to use now. You choose new filters and it just drops down. Pretty easy to build an ad-hoc query, and you can easily create links to save your query.
Make custom fields is the easiest part — you just put them in the trac.ini file and Trac loads them automagically. You can make them drop-downs or text fields, etc., depending on how you put it in the .ini file.
So if you are thinking about getting a tracking system setup, you really should give it a look.
Matt’s thoughts on Spring came on the same day I just started looking at it. When I mean looking, I literally mean just that. All I did was think “What’s this Spring thing people are asking me about?” So I found this ServerSide article that gives a 1,000 ft overview of Spring. My first thought was one of Matt’s gripes: Programming in XML? No thank Eww. My second: When this abstraction leaks, it probably leaks badly and in insidious ways.
You see, for business reasons I could really rant and rave about, we did J2EE the ol’ fashioned way — EJB’s,direct calls to the database (i.e. no Hibernate), and scriptlets in our JSP’s. We didn’t even bother with custom JSP tags — just put the code in the JSP’s! And we liked it!
Okay, we really didn’t. But it was what we had to do. No Spring. No Struts. No Hibernate. Just POJ2EE. It was painful.
I’ve never used Spring, or any of the tools above, but it seems the choice is between XML config files or code with no happy medium. No wonder why things like Ruby on Rails, Django, and Grails are taking the world by storm.