But I really wish I could.
Enter TechShop. I wish there was a place where I could learn how to do stuff as well as do stuff like this; maybe someday they'll open a facility here in Minneapolis.
Wednesday, December 26, 2007
Monday, December 17, 2007
Petra Haden
I have a record she did a couple of years ago where she covered The Who's "The Who Sell Out"
. Here's a version she and her band did of Journey's Don't Stop Believing.
. Here's a version she and her band did of Journey's Don't Stop Believing.
Tuesday, December 11, 2007
I'm posting from the future....
Yes, as you can see I've joined the smartphone revolution.
--
Sent from my T-Mobile Sidekick®
--
Sent from my T-Mobile Sidekick®
Monday, December 03, 2007
JBoss Seam is a s(t)eam(ing) pile
For the last 6 months at work, I've been using JBoss Seam. It's a framework that integrates JSF with EJB. Stateful session beans serve as controllers and JPA entities or hibernate entities serve as domain objects.
What attracted me to the platform was that it (appeared) to solve a number of problems:
The Object-Form element problem. That is, if you had a drop down in a page where a user had to select a product, the framework itself would generate the code necessary to tie the value of the dropdown in the HTML form to the live Java object representing that product, sitting on the server. This, based on past experience, would be a huge time saver.
The variable length field or set of formfields. This is where a user can essensially "grow" a form. One example at my last place was an application where a user had to provide a list of schools they had attended in the past. For each school, they had to provide a bunch of data: dates of attendance, city, and state. Within the framework I was using at that time(Struts) this was a VERY difficult task. Seam and JSF in general seemed to provide an easier way to accomplish this.
Ease of offering many different functions on the same page. Sometimes on a page, you'll want to present a user with multiple functions based on the same data: "Save and Continue" and "Save and Exit." While you can get Struts to do this, it's very ad hoc and repetitive(thus error prone). You've got to build a little controller into each action you want to do this in. With Seam and JSF in general, this is cake. It's just a different button with it's action attribute set to that other method.
In all but the last case, Seam was a failure. Sometimes, for no apparent reason, Object-Form stuff would break..and was not debuggable. Because there was no way to define a smaller "validation area" within a subset of the form, the variable length formfield really didn't work. On every submission, JSF forces the validation of every field on the page thus making shit weird.
In summary, Seam is like a 3 legged Greyhound: It looks good from far away and the right angles, but once you need it to run, it's simply lame.
So today I bought my second and third Ruby book.
What attracted me to the platform was that it (appeared) to solve a number of problems:
The Object-Form element problem. That is, if you had a drop down in a page where a user had to select a product, the framework itself would generate the code necessary to tie the value of the dropdown in the HTML form to the live Java object representing that product, sitting on the server. This, based on past experience, would be a huge time saver.
The variable length field or set of formfields. This is where a user can essensially "grow" a form. One example at my last place was an application where a user had to provide a list of schools they had attended in the past. For each school, they had to provide a bunch of data: dates of attendance, city, and state. Within the framework I was using at that time(Struts) this was a VERY difficult task. Seam and JSF in general seemed to provide an easier way to accomplish this.
Ease of offering many different functions on the same page. Sometimes on a page, you'll want to present a user with multiple functions based on the same data: "Save and Continue" and "Save and Exit." While you can get Struts to do this, it's very ad hoc and repetitive(thus error prone). You've got to build a little controller into each action you want to do this in. With Seam and JSF in general, this is cake. It's just a different button with it's action attribute set to that other method.
In all but the last case, Seam was a failure. Sometimes, for no apparent reason, Object-Form stuff would break..and was not debuggable. Because there was no way to define a smaller "validation area" within a subset of the form, the variable length formfield really didn't work. On every submission, JSF forces the validation of every field on the page thus making shit weird.
In summary, Seam is like a 3 legged Greyhound: It looks good from far away and the right angles, but once you need it to run, it's simply lame.
So today I bought my second and third Ruby book.
Subscribe to:
Posts (Atom)