This podcast focuses on a quick intro to Spring and how it affects your code dependencies.
If don’t want to listen to it with the player above, you can download Spring and Dependencies podcast.
Here’s the outline I worked from while recording the podcast. It’s sketchy, so don’t take it for hard information. I’ve woven in a couple links, though.
- Who I am
- Java developer since 90’s
- J2EE since Struts 0.5
- Worked as programmer for university, .com, government
- What the show format is
- Cover interesting topics, many of them as they’re emerging
- Mainly my own experience and my reading: get what I think is a decent overview
- I wanted something substantive to listen to on the way to work or somewhere else
- 10-20 minutes
- Split topics across shows often
- Perhaps have a basic theme for week
- EJ classes
- 90 minutes, 3 times per week
- Spring IoC: Basic bean factory
- Allows for creation and wiring up
- Gives you home theater components instead of an all-in-one
- Encourages interface programming
- Can/should replace config file
- Eliminates creation and relationship code, allows object to focus on its reall purpose
- Moves dependency definitions to configuration
- Variable type (Comcast comcast)
- Constructor choice (new Comcast())
- Variable methods used (comcast.connect(), comcast.sendSpam())
- Getting rid of dependencies
- Change variable type from concrete class to interface (Isp isp)
- That eliminates dependency on variable type
- That also standardizes the methods used — (isp.connect(), isp doesn’t have sendSpam() call). This may require changes to your code. You see this recommendation when using Map vs. Hasmap.
- Remove constructor call and replace with set method.
- Lets object creation be someone else’s problem
- Your object is now dealing simply with how to get its work done and collaborate with other objects.
- This has a really cool side effect: you’ve now made it really easy to use mocks of your Isp during testing instead of a real implementation.
- Check out the sample chapter of Pragmatic Unit Testing.
- Back to Spring
- Read the configuration file
- Instantiate the objects
- Resolve all the dependencies and relationships
- Call the correct set methods
- Left with all your business objects created, initialized, and connected
- All creation and relationship info is in one spot, instead of scattered in classes
- When something must be changed, there’s just one place to go to
- If your code relies on the interface, then you can choose which implementation in the config, and no code changes are needed.
About a year ago, we were using jWebUnit, which is an API built on HttpUnit — which in turn is very similar to HtmlUnit. We used it in conjunction with DbUnit to load the database tables before the test and verify them after. It worked really well. We had tests that could verify the operation properly manipulated the database, and could check the structure of the HTML returned.
We went away from it mainly because functional tests could only be written by programmers with that method, and with JMeter we could have someone a systems analyst or a tester write the functional tests. Using the proxy recorder available in JMeter let a user click through the test and replay it. JMeter could load the DB and check it based on CSV files, instead of XML. In the end I think the flexibility is a little less, but the number of people who can help get the work done has increased.
We’ve been doing a bit of research lately on the “Buy vs. Build” argument in application development. As a survey of what’s out there, one of my colleagues collected a number of articles on the issue. Many of these are on the web, so you can check out his Furl archive in the “Buy vs. Build” area. If you’ve got any other sources, drop in a comment!
I find it really convenient to turn many of my documents into PDF. It lets me easily send stuff to people that don’t have a particular program, like a UML diagramming tool. I’ve poked around for the last little while, and these are the most useful solutions I’ve come across:
- Adobe Acrobat. Obviously this is the most authoritative source of creating PDF files. I used Acrobat at two different companies. Acrobat has two options: Acrobat Writer and Acrobat Distiller. As I understand it, Distiller is better for complex documents. I never really needed anything but Writer. Personally, I don’t want to pay to create PDF files, and my needs are simple, so I’ve always skipped this option for personal use.
- OpenOffice. This is the famous open source word processing suite. There’s a button for “Export to PDF”. It’s easy to use, but it’s pretty heavyweight to install if all you want is to turn your TXT file into a PDF document.
- PDF995. This is a very simple, and easy to use PDF creation tool. It looks like a printer, so anything you can print you can make into a PDF. It’s supported by ads, so each time you print a browser opens to an ad. My biggest annoyance with this is that it would sometimes change my receipt page into an ad. If anything out of the ordinary happened (USB keychain not plugged in, network permissions wrong), then I lost my receipt. Besides that, it was good quality. Just ad-supported.
- PDFCreator. This is an open source PDF converter that I ran into just the other day. It appears to act as a PostScript printer, and then rely on a PS2PDF converter like GhostView to finish the conversion process to PDF. I never actually got a PDF out of this, but many people reported being able to set it up on a central server as a network printer and have a way that anyone in the organization could create PDFs. It was more complex than I wanted.
- PrimoPDF. I just found this one tonight. It seems like the ideal solution. It’s completely free to use. It’s simple, and is just a printer, like PDF995. It also allows you to optimize the PDF for either screen or print. I don’t know what the difference is . I’m also not sure how output differs from PDF995, but here are two samples. Both are of this web page. One is optimized for screen and the other is optimized for print.