At well over 350 pages, the book starts with a gentle introduction to web development with Wicket, introducing concepts in relation to well-worn existing paradigms. The pace rapidly builds into the primary discussion of the domain and component models, giving the reader everything they need to know about how to be incredibly productive with it. Along the way, entertaining examples with real-world applications are presented, employing all of the essential foundational elements and display components your Wicket application will want to be a success. Wicket is an innovative evolution of MVC programming with simple roots, but without a primer such as this, it can be more challenging than it needs to be.
Developing an for a component-oriented web framework without sacrificing expressiveness is a challenging task. This is evidenced by the constant changes that are made in many different frameworks, some of which are painfully incompatible with previous releases. There was a time that a major overhaul to the Wicket API was envisioned, and in an effort to meet that challenge, this book was exhaustively overhauled. For very good technical reasons, that branch was considered undesirable, but many valuable lessons were learned from it and over time, those were integrated back into the core of the project.
What I think is interesting about this book, and the Wicket team in general, is that they didn't just rush that existing manuscript to market. Nor did they accept undesirable changes to the framework because so much effort had already been put into the book. Instead, the changes were made to the framework as they should have been, and the manuscript evolved in turn to reflect the current reality. This took more time than anyone probably realized it would, but it was well worth it.
The result is that the framework has reached a level of stability that would be impossible if there was any concern that the premiere documentation source for it would be put further out of date with a change under consideration. And in the process of reaching that level of stability, the reader is thus ensured that their investment in learning through it will be preserved as long as possible.
I'm obviously really pleased that Martijn and Eelco are finally going to press. Wicket is one of the first tools I talk about when I meet other Java programmers with an interest in presentation technologies, and now I have a great tome that I can suggest so they can get started with it quickly and easily.
Congrats, guys!
]]>Lo and behold, Perforce was acting stupid and was reporting the latest files had been checked out when in fact they were not. Hours were wasted. How could this happen?
The data about file version status (file metadata) is stored on the server. The Perforce server remembers that a certain directory on the filesystem of your machine has a certain combination of files in a specific directory. The *server* cares about *specific files* on *your machine*. Somehow, things happened to those files on my disk, old versions overwrote new ones. The server refused to acknowledge this until I forced it to overwrite all the files (which certainly defeats the reason to have source code control in the first place).
Imagine this analogy. Consider fifteen directories on your hard disk, all under source control. Think about these directories as rooms in your luxurious McMansion in the 'burbs. All the rooms have lights in them. Where are the lights controlled from? Switches near the door, naturally.
Now imagine a house where all these switches to all the rooms are all near the front door of the house, not in each room. If you want to go to the bathroom without peeing all over the wall in the dark, you need to go downstairs to the front door, turn on a light, go back to the bathroom, take a leak, then go back downstairs to turn off that light.
Now let's have a party. Besides the incredible congestion at the front door as everyone tries to find the switches for the rooms, they can't tell if they are changing the lights improperly because they can't really tell what the state of the room is (such as whether there is anyone in there).
The fix is simple. Put the damn switch inside the bathroom, on the wall near the door.
Does it make sense now why metadata belongs next to the files it serves? And why the server is a dumb place to put file status data for local machines?
]]>On to the subject of this entry. Perforce sucks rocks through straws.
We've been porting a project to Maven, an Ant project stored in Perforce. Having done this once with an Ant project stored in Subversion, the process was simple: Create a branch, issue the svn copy commands to populate the branch (copying groups of files as needed to the new directory layout), then when the branch is working satisfactorily, push the branch back to trunk.
Perforce, in it's infinite wisdom, has the broken concept of "integrate" with two variants: So called "file spec" and "branch spec". If you read the Perforce docs, the difference is about as transparent as roofing asphalt, but when you get down to it, you find that a branch spec is essentially a record of all the file spec used to create the branch. The problem is you have to do this completely correctly before you use it, or you have to blow away all your files and start over, every time you change the location of the destination.
The Subversion user will casually say "duh, well, use a file spec". Unfortunately, file spec (instantiated via direct 'p4 integrate' commands in a CLI or dragging files in the GUI) are not persisted. One can look at the history of a file and see that it was branched, that the corresponding file in trunk has lots of changes that you want to grab, but you can't *do* anything with the information. It's just metadata.
Fools! People are still working on the trunk, and I need their changes. WTF good is branching in SCM if I can't have the tool use the metadata to grab changes on the trunk and apply them to the branch? As best as anyone here can tell, that's not an option unless you excruciatingly visit each branched file and ask Perforce to kindly move the change across.
Or use the aforementioned branch spec. There are about seventy distinct moves of files needed for it to recreate the new (saner) structure required for Maven. Generating that list would be impossible as some kind of stream-of-consciousness blurted out into a ten-line window in the GUI.
This is insane.
Arguably, this is a minor inconvenience compared to the next problem. Imagine we've got our branch working, we're ready to adjust trunk to match. Is it even possible? No. All it appears we can do is push the contents of the files in the branch back into the existing structure of the trunk, since a "reverse integration" simply means use the contents of the filespec in reverse. Or am I expected to write scripts to do this? It's certainly not outlined in the Perforce User Manual, but if I go to http://svnbook.red-bean.com/ I find these exact use cases outlined with clear steps.
It's been said that there are a lot of commercial software projects that have been made irrelevant by superior open source projects. I remember being fond of Perforce a decade ago. Today, I am spoiled by Subversion. I feel bad wishing that Perforce would go out of business soon, but I can't help but wish this scourge of an SCM finds the dustbin of history as soon as practical.
]]>Well, I learned my lesson. I called the next store. They had it. She said I could pick it up. I put the machine in the trunk anyway and drove 30 miles to the further store. She was at lunch. I told them I drove from Oakland, that I couldn't leave with out it, and a big smile. Eventually, one of the guys behind the genius bar figured out that he wasn't really doing anything and graciously offered to put it in for me. I knew what to do but they insisted on doing it anyway.
Moral of the story is that they spent a lot of time for a $25 part that comes with free installation, probably 90 minutes over the course of the several people that were a part of the exchange. If someone messes up a $25 part, it's their own fault. I can dig that Apple will warrantee the machine for just about anything that someone does to it and they don't want fumblefingers roaming around in the case, but really, if someone walks into the store wearing a Java t-shirt and knows about MythTV, they ought to be able to make an exception for that.
]]>What is it? Lou Cipher and the cronies on capitol hill that he buys with lobbying money have decided that DMCA is quite complimentary to just simply getting rid of pesky analog signals. Analog, as you know, is a bit more difficult to encrypt, and well, we already *have* legislation protecting digital.
The fact of the matter is that I have very little time to go cracking signals. I really have done about zippo cracking. And I write software. Here's what I know:
I got my start in this industry without the financial werewithal to purchase the tools that were necessary to create with. I purchased what I could as a good citizen of the karma, borrowed the rest, and in turn contributed back to the industry. It ended up working well for everyone involved.
But these kinds of proposals will make it next to impossible for people who are truly creative to get their hands on the tools that they could use to rise up and provide. What's next? When hacking is outlawed, only outlaws will be hackers. The rest? Sit at your desk and obey young man! It's going to be like joining the "defense" establishment because your other options were strategically removed some time ago.
Look at the people behind this bill (and others like it). Are they the small developers that provide the creativity to the industry? (Are there any developers at all behind this bill?) Or is it just a bunch of Orwellian shenanegans?
Let's not force the remaining talent we have to a better life offshore. I already know a few people that have found a better life in New Zealand.
]]>I bet the claims for this keyboard are probably accurate. Before I got a split keyboard a decade ago, I couldn't type super fast because I didn't use all my fingers. That changed with a split keyboard. I still don't use my left pinkie or thumb, but eight fingers isn't bad. Forcing yourself to "go intuitive" really does work.
Cool!
]]>But what you might not be reporting as much on is the reason that those trains aren't so popular. Because the federal highway system is bankrolled by general treasury rather than user fees. In other words, the gas tax is an order of magnitude too low.
What I would like to know is why someone that doesn't drive at all (like the blogger above, as a New Yorker) is paying for the federal highway system. What does he get out of it? I would argue nothing that couldn't be paid for elsewhere. The (powerful) trucking lobby will tell him that everyone benefits from highways, that if gas taxes are too high, the trucks will not feed the country, and commerce will stop.
Of course that is not true, the market will adjust. Goods that require extensive energy to deliver or are not produced locally will either not be available, will be produced closer to where they are consumed, or will not be available at all in certain areas. Is this a bad thing? I would argue not. Demand for these goods will not disappear, and the production of them will be geographically dispersed. I could go on, but you get the picture.
It could also be argued that the costs of goods will rise. Indeed they will, but if this a zero-sum game, they will not rise any more than your taxes will fall from not paying for highways that you do not use. If you are a smart consumer that purchases locally made goods, you will probably be able to beat the averages even. This is the _ultimate_ form of letting the markets work to balance the means of production and consumption.
The only people that user-taxes injure are those that are (literally) getting a free ride by driving hundreds of miles to work on a daily basis. Artificially low gas prices that do not pay for the total costs of the miles that are driven encourage these people to move to these remote suburbs and waste precious resources on their daily drive to work.
In the end, we can talk all day about conservation, carpooling, and public transportation, but these changes will never happen unless the markets are left to do what they do best.
]]>-Richard Feynman
]]>