Back in August I commented on Microsoft's aggressive moves against Adobe. I also mentioned that Apple could also make a move with it's new Core Image technology built into OS X. But at the time I didn't think it was all that likely. Well I was right that they could but I was wrong because they did.
Apparently Apple wants a piece of that image processing market. They just introduced Aperture. And although they're going to some pains to say it's complementary to Photoshop, I think it's definitely a competitor.
Apple really is becoming quite a software powerhouse... Fortunately for most software companies, they can feel secure that the only software they produce that isn't Macintosh-only is iTunes and Quicktime. But then again once somebody (like me for example) gets a taste of Mac, all that Microsoft stuff just feels like rubbish. With all the Apple stores around the U.S. with their little built in theaters, the brand new Quad PowerMacs will show this stuff off very well.
Thursday, October 20, 2005
Tuesday, October 18, 2005
HD Movie Trailers
Check out the new Movie Trailers page at Apple. A fair number of them are in HD. Normally I have to scale a video several times to fit my entire screen. These trailers fill my screen without any scaling at all.
Saturday, October 15, 2005
Ruby, Ruby, Ruby, Ruby
Remember when Steve Ballmer went all schizo and jumped around like a big Gorilla shouting "developers, developers, developers, developers"? Well I think I'm starting to get infected by a similar disease. I'm not a complete raving lunatic just yet but I'm really starting to dig Ruby. ;-)
After madly writing endless lines of Java code for the past three weeks that does next to nothing (see my previous rant) I'm elated to see that there are others in the world who believe less code is better.
To demonstrate, here are the steps you can take to create a dynamically generated page with Ruby on Rails.
1. > rails ./demo
2. > cd demo
3. > mv public/index.html public/index.html.old
4. > script/generate controller people list
5. modify config/routes.rb and add the line map.connect '', :controller => 'people', :action => 'list'
6. modify app/controllers/people_controller.rb (see listing below)
7. modify app/views/people/list.rhtml (see listing below)
8. > script/server
9. browse to localhost:3000
10. voila!
A couple of important points to notice is that Rails embraces the MVC design pattern. Model and Controller classes are separate while the View is off in its own place. The view is an .rhtml file because it's basically HTML with Ruby embedded within it. While those who've been doing JSP development may scoff at the mere idea of embedding "code" within a page and believe that custom tags is the only way to go, I have to admit that after doing JSF for a few weeks I actually like this a whole lot better. Remembering that Ruby is a 'scripting' language and that Rails uses Controller classes (like "code-behind") may help people get over their prejudice. Finally here a few links I've found very valuable during the last week:
What Is Ruby on Rails
Rolling With Ruby on Rails
Rolling with Ruby on Rails, Part 2
Ruby On Rails Documentation
why's poignant guide to Ruby
Rails Academy (videos)
app/controllers/people_controller.rb
app/views/people/list.rhtml
After madly writing endless lines of Java code for the past three weeks that does next to nothing (see my previous rant) I'm elated to see that there are others in the world who believe less code is better.
To demonstrate, here are the steps you can take to create a dynamically generated page with Ruby on Rails.
1. > rails ./demo
2. > cd demo
3. > mv public/index.html public/index.html.old
4. > script/generate controller people list
5. modify config/routes.rb and add the line map.connect '', :controller => 'people', :action => 'list'
6. modify app/controllers/people_controller.rb (see listing below)
7. modify app/views/people/list.rhtml (see listing below)
8. > script/server
9. browse to localhost:3000
10. voila!
A couple of important points to notice is that Rails embraces the MVC design pattern. Model and Controller classes are separate while the View is off in its own place. The view is an .rhtml file because it's basically HTML with Ruby embedded within it. While those who've been doing JSP development may scoff at the mere idea of embedding "code" within a page and believe that custom tags is the only way to go, I have to admit that after doing JSF for a few weeks I actually like this a whole lot better. Remembering that Ruby is a 'scripting' language and that Rails uses Controller classes (like "code-behind") may help people get over their prejudice. Finally here a few links I've found very valuable during the last week:
What Is Ruby on Rails
Rolling With Ruby on Rails
Rolling with Ruby on Rails, Part 2
Ruby On Rails Documentation
why's poignant guide to Ruby
Rails Academy (videos)
app/controllers/people_controller.rb
class PeopleController < ApplicationController
def list
@names=['Yukihiro Matsumoto', 'David Heinemeier Hansson']
end
end
app/views/people/list.rhtml
<html>
<head>
<title>This is my first Ruby page</title>
<link rel="stylesheet" type="text/css"
href="stylesheets/mystyle.css" />
</head>
<body>
<h1>Ruby/Rails People List</h1>
<table>
<% @names.each do |name| %>
<tr><td><%= name %></td></tr>
<% end %>
</table>
</body>
</html>
Saturday, October 08, 2005
Ruby On Rails
I discovered a new version of the Ruby Development Tools (RDT) plugin for Eclipse yesterday. I hadn't used it in quite awhile, so I downloaded this new version, installed it and was quite pleasantly surprised. I opened an old project I had laying around and rediscovered the simplicity of Ruby. I wrote a Test::Unit subclass and ran it in the RDT test runner. Very nice. Just like running JUnit tests in Eclipse.
So I decided this is cool, lets try this Ruby on Rails thing that I keep reading about. Mac OS X Tiger comes installed with Ruby 1.8.2, the Apache web server and SQLite, so I was more than half way there to getting setup. I followed this little tutorial to install RubyGems, a packaging system for Ruby libraries and tools. After that, installing rails (i.e., "sudo gem install rails") and creating a little sample application was a breeze. My only hiccup was fixing a permissions problem with my sample app (i.e., the public, db, and logs files needed to be readable and writable by apache).
Setting up a rails app involves generating a bunch of files so I can't claim to know what's really going on under the covers, but it's a very cool thing to be able to edit data through a web UI so quickly. Rails has impressed me so far. Now I just need to build something of my own and decide for myself if all these Ruby/Rails productivity claims hold water.
Tuesday, October 04, 2005
LINQ
A friend of mine just sent me a video link to a interview with Anders Hejlsberg talking about LINQ (Language INtegrated Query). Take Java's Hibernate ORM (object relational mapping), mix in contextual type inference and then throw in homogenous query syntax (that has a close resemblance to SQL) across relational databases, XML data and in-memory objects and you get an idea of what LINQ is all about. It sounds very ambitious (and it is) but Anders does a great demo. The comments section on the board makes it sound revolutionary but if you've been playing in the ORM space for any amount of time it seems like a very natural evolutionary step. But I didn't see the "type inference" stuff coming. That's brilliant. Makes the query stuff much more powerful.
Sunday, October 02, 2005
Seam
After yesterday's rant about layers upon layers of code and XML based dependency injection I found Norman Richard's blog about a new web framework called Seam from JBoss. Apparently Gavin King, the guy who brought us Hibernate, is involved in this as well. That's a very good sign. From what I've read it looks like this might be just what I'm looking for. It's brand new and will undoubtedly have rough spots and missing functionality, but it really does seem to be headed in the right direction.
Saturday, October 01, 2005
6 days later
I've been in my new job for six days now and thought I'd post my thoughts about what I've done so far. The short answer is "not much". It's actually pretty amazing to me how little is done to prepare for a new person. And I'm not even talking about this specific company, it's a general problem. Even the most glaringly obvious things like getting ids and passwords for databases, version control systems and even permissions on file servers are almost never set up when I go to a new job. Sometimes the environment is responsive to new requests, other times... not so much.
Secondly, when being inserted into a team of people already madly coding away, nobody has the time to give you the lay of the land. So I spent at least a couple days looking a existing code to figure out what I need to do to make my code fit in with everything else. It all seems highly inefficient and a waste of my time and their money. Maybe when you consider just one developer, it may not seem like much but multiply a week of time for every new developer who walks through the door then it's easy to see a pretty big opportunity to save. Do the math with let's say 20 developers and you soon start to think "I could probably build a lot of stuff in 20 weeks".
Anyway, I did manage to build a single web page this past week. But what really impressed me was the number of files I needed to create/edit to enable this one page. I created:
In my last job, where I made the decisions about architecture and technologies, I had:
Having worked with a variety of people over the years I know there are those who believe that elegance is expressed with simplicity. Look at E=mc² for example. And then there are those who love to wallow in complexity. I love simple, efficient, elegant designs. I'm not sure I've found that here... Not yet anyway. Maybe I'll come to love it over time (my fingers are crossed).
Finally, let me comment on a couple of my statements in earlier posts:
Secondly, when being inserted into a team of people already madly coding away, nobody has the time to give you the lay of the land. So I spent at least a couple days looking a existing code to figure out what I need to do to make my code fit in with everything else. It all seems highly inefficient and a waste of my time and their money. Maybe when you consider just one developer, it may not seem like much but multiply a week of time for every new developer who walks through the door then it's easy to see a pretty big opportunity to save. Do the math with let's say 20 developers and you soon start to think "I could probably build a lot of stuff in 20 weeks".
Anyway, I did manage to build a single web page this past week. But what really impressed me was the number of files I needed to create/edit to enable this one page. I created:
- a domain object with Hibernate XDoclet annotations
- a DAO interface
- a Hibernate DAO implementation
- a DAO unit test
- a Service/Facade interface
- a Service implementation
- a Service unit test
- a JSF backing bean and a JSP page.
- an application resources properties file (despite the fact localization is not a requirement)
- two Spring XML files
- a JSF config XML file and
- added some XML to the tiles definition file.
In my last job, where I made the decisions about architecture and technologies, I had:
- XDoclet annotated domain objects (which included named queries)
- NO DAOs (I felt that the Hibernate abstraction and named queries were a sufficient data access layer)
- Service Objects (typically singletons with explicitly coded session and transaction management)
- XDoclet annotated Struts Action/Form objects + JSPs
- the typical smattering of JUnit test classes.
Having worked with a variety of people over the years I know there are those who believe that elegance is expressed with simplicity. Look at E=mc² for example. And then there are those who love to wallow in complexity. I love simple, efficient, elegant designs. I'm not sure I've found that here... Not yet anyway. Maybe I'll come to love it over time (my fingers are crossed).
Finally, let me comment on a couple of my statements in earlier posts:
- There is a simpler way to integrate Spring and JSF so that you can inject Spring configured beans into JSF managed beans. Using Spring's org.springframework.web.jsf.DelegatingVariableResolver configured within your faces config makes it all transparent. Yay! It may not be as good as using only one dependency injection framework but it's a good runner up.
- Secondly, you can integrate tiles into JSF by configuring org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl in your faces config file.
- Finally, I read Spring's documentation a little more closely and it appears you can use HibernateTemplate's execute method to call whatever Hibernate code you want. So I can now feel free to use that lovely Hibernate API all I want! ;-)
Sunday, September 25, 2005
On JSF, Struts, & Spring Part Deux
After a Saturday of messing around with Spring, JSF, & Hibernate I have a nice little application that does nothing more than retrieve an object from my local PostgreSQL database and display the value in a web page. While the end result isn't very exciting there is a whole symphony of integration going on under the covers.
Hibernate and Spring
I first created a couple business domain classes that use the latest and greatest Hibernate/EJB3 Java 5 annotations to describe how they map to database entities. This is currently supported in Hibernate 3.1 beta 3 so I didn't really expect to be able to use this stuff once I got to integrating it with Spring. I assumed I'd have to either write Hibernate mappings in XML or maybe integrate XDoclet to generate the mappings. Well to my surprise Spring has org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean!! So Spring was good to go! All I had to do was declare the sessionFactory and the transactionManager that I wanted in applicationContext.xml. I still haven't figured out a way to get it to autodiscover the annotated business model so I had to manually list the two classes but that wasn't too big of a problem.
I then moved on to creating a subclass of Spring's HibernateDaoSupport class and configuring it in applicationContext.xml where I learned about the declarative transaction management features of Spring. In this XML file I was able to wire together the DAO, the Hibernate sessionFactory, the transactionManager and indicate which DAO methods require a transaction. This simplified the code in the DAO by injecting the necessary Hibernate Session and Transactions at runtime. But this comes at the cost of using a HibernateDaoSupport method called getHibernateTemplate() whose returned object basically delegates to the injected Hibernate session and turns Hibernate exceptions into unchecked exceptions. This also has the unfortunate side effect of burying the native Hibernate API. I don't really care for that idea too much but it's a tradeoff for not having to manage session and transaction resources manually.
So I then created a little JUnit test, used the FileSystemXmlApplicationContext to start up Spring and then used the context to get the configured DAO from Spring and called a method. Everything worked as expected.
Spring and JSF
Next it came time to integrate JSF. This became a little more time consuming. First of all I needed to figure out how to initialize all the Spring stuff within a web application which in turn initializes all the Hibernate stuff. It was actually fairly simple. I only had to configure a listener in the web.xml file for org.springframework.web.context.ContextLoaderListener. Also by using context-param in web.xml I was able to tell this ContextLoaderListener instance where to find my spring applicationContext.xml files.
Secondly, JSF has its own Dependency Injection framework for configuring backing beans that have request, session or application scope and it was unclear to me how to integrate the two dependency injection frameworks i.e., If my DAO and Facade/Service classes are configured with Spring how would I go about injecting these instances into a JSF backing bean? Well as it turns out I can't. Not yet anyway. There is a little project appropriately enough named "jsf-spring" that aims to transparently aggregate these two frameworks. It's in beta. But Spring has a supporting class called FacesContextUtils which allows me to fetch an instance of WebApplicationContext (with the current FacesContext as a parameter). I can then use that Spring context object to fetch the DAO (or more typically a facade class) to do the work I need. Given all this dependency injection stuff this manual fetching of context objects and service objects seems like a very odd hack and is more like calling a singleton getInstance method. But it works and I was able to tie the business layer to the presentation layer.
Summary
So there you go, a display-only Spring/Hibernate/JSF application. It was a good lesson in making all the pieces work together. In the end I look at all this plumbing and I'm a bit surprised how simple and difficult it was to get everything going. The Spring stuff is well documented on the web and was easy to get going with Hibernate. But answers to my questions about adding JSF to the mix were a little harder to come by. I suspect the future holds a stronger integration for Spring and JSF (perhaps you can just use Spring as a replacement for the JSF injection framework) and I can see Java 5 annotations becoming more prevalent in Spring so that you don't have to write all that XML. Annotations work great for Hibernate so I don't see why they wouldn't work well for Spring too.
Hibernate and Spring
I first created a couple business domain classes that use the latest and greatest Hibernate/EJB3 Java 5 annotations to describe how they map to database entities. This is currently supported in Hibernate 3.1 beta 3 so I didn't really expect to be able to use this stuff once I got to integrating it with Spring. I assumed I'd have to either write Hibernate mappings in XML or maybe integrate XDoclet to generate the mappings. Well to my surprise Spring has org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean!! So Spring was good to go! All I had to do was declare the sessionFactory and the transactionManager that I wanted in applicationContext.xml. I still haven't figured out a way to get it to autodiscover the annotated business model so I had to manually list the two classes but that wasn't too big of a problem.
I then moved on to creating a subclass of Spring's HibernateDaoSupport class and configuring it in applicationContext.xml where I learned about the declarative transaction management features of Spring. In this XML file I was able to wire together the DAO, the Hibernate sessionFactory, the transactionManager and indicate which DAO methods require a transaction. This simplified the code in the DAO by injecting the necessary Hibernate Session and Transactions at runtime. But this comes at the cost of using a HibernateDaoSupport method called getHibernateTemplate() whose returned object basically delegates to the injected Hibernate session and turns Hibernate exceptions into unchecked exceptions. This also has the unfortunate side effect of burying the native Hibernate API. I don't really care for that idea too much but it's a tradeoff for not having to manage session and transaction resources manually.
So I then created a little JUnit test, used the FileSystemXmlApplicationContext to start up Spring and then used the context to get the configured DAO from Spring and called a method. Everything worked as expected.
Spring and JSF
Next it came time to integrate JSF. This became a little more time consuming. First of all I needed to figure out how to initialize all the Spring stuff within a web application which in turn initializes all the Hibernate stuff. It was actually fairly simple. I only had to configure a listener in the web.xml file for org.springframework.web.context.ContextLoaderListener. Also by using context-param in web.xml I was able to tell this ContextLoaderListener instance where to find my spring applicationContext.xml files.
Secondly, JSF has its own Dependency Injection framework for configuring backing beans that have request, session or application scope and it was unclear to me how to integrate the two dependency injection frameworks i.e., If my DAO and Facade/Service classes are configured with Spring how would I go about injecting these instances into a JSF backing bean? Well as it turns out I can't. Not yet anyway. There is a little project appropriately enough named "jsf-spring" that aims to transparently aggregate these two frameworks. It's in beta. But Spring has a supporting class called FacesContextUtils which allows me to fetch an instance of WebApplicationContext (with the current FacesContext as a parameter). I can then use that Spring context object to fetch the DAO (or more typically a facade class) to do the work I need. Given all this dependency injection stuff this manual fetching of context objects and service objects seems like a very odd hack and is more like calling a singleton getInstance method. But it works and I was able to tie the business layer to the presentation layer.
Summary
So there you go, a display-only Spring/Hibernate/JSF application. It was a good lesson in making all the pieces work together. In the end I look at all this plumbing and I'm a bit surprised how simple and difficult it was to get everything going. The Spring stuff is well documented on the web and was easy to get going with Hibernate. But answers to my questions about adding JSF to the mix were a little harder to come by. I suspect the future holds a stronger integration for Spring and JSF (perhaps you can just use Spring as a replacement for the JSF injection framework) and I can see Java 5 annotations becoming more prevalent in Spring so that you don't have to write all that XML. Annotations work great for Hibernate so I don't see why they wouldn't work well for Spring too.
Saturday, September 24, 2005
On JSF, Struts, & Spring
I started a new contract yesterday and got a bit of a taste of what to expect in the coming months. We're building web-based Java applications and the typical J2EE MVC, Facade, DAO, & (evil) DTO patterns are in full effect.
I'm fortunate enough to get to continue to use Hibernate for ORM which is very cool. I still think Hibernate and object relational mapping in general is a very good thing. The biggest "problem" I see is that it looks like people are opting to use the "TopLink" way of doing things by using Criteria objects instead of HQL. What are they thinking? Why anyone would choose to use a non expressive bunch of Java code to write a query is beyond me. HQL is way better and one of the reason I like Hibernate so much better than TopLink. I e-mailed my supervisor about this one and we'll see what kind of response I get.
On the web framework front, we're using JSF (MyFaces specifically) instead of the defacto standard Struts. While fundamentally I don't have anything against Java Server Faces (it does have some nice features) I have to wonder why they made the decision to use it. David Geary (co-author of the book "Core Java Server Faces") once gave a talk at our local Java User Group meeting once and said something to the effect that "JSF was a standardized Struts that IDE vendors could rally around to create JSP visual editing tools". Part of that goal was to compete with ASP.NET. Coding up JSP pages is a bit mundane and who wouldn't rather have a tool write that junk for you? Well apparently the people where I'm working made that decision! It's still all hand-coded. So now we're using a framework nobody understands and I suspect productivity is lower. Where's the logic in that?
MyFaces seems very similar to Struts so conceptually it's easy to grasp but it's the details and the peculiarities of how things work that slow you down. It also seems to be at a higher level abstraction from the lower level request/response and the HTML it generates (the theory is that you can generate something other than HTML). But I think I prefer Tapestry's idea of staying close to HTML and only injecting the dynamic content. Tapestry allows you to use any HTML editing tool and HTML is well understood. JSF on the other hand is this parallel universe of tags that look a bit like HTML but can only be edited in a text editor or a JSF visual editing tool and at the moment there doesn't seem to be any tools that play nice with the MyFaces implementation. Secondly, staying close to HTML allows you to take advantage of advances in HTML like XHTML and AJAX. JSF, like ASP.NET, gives you a component model that will likely adapt to support advances in the underlying technology but there will always be a time lag. Perhaps the other minor benefits will outweigh the losses. We'll see... Right now it looks like change for the sake of change.
They also bought into the whole Spring IoC (a.k.a., Dependency Injection) idea. At first glance this seems like a good idea. You design to interfaces in an attempt to hide implementation details. Theoretically it should enable unit testing and allow us to switch between POJOs, Web Services and EJBs with greater ease. Of course it comes at a cost of greater complexity for questionable gain. For example if you create a DAO interface and then only ever create one implementation of that interface what have you gained? And then you have all the XML gunk to wire everything together. Theoretically, a meta data approach to wiring stuff together is better but not having experienced it before I'm a bit skeptical. The fortunate part about Spring is that they seem to understand that they need to play nice in a bigger community and support all the major Java frameworks out there so integration looks to be pretty straightforward.
My feelings are a bit mixed... Sometimes I believe that the dynamic, competitive, multi-vendor Java community is more vibrant than the MS .NET community and that the variety of tools is our attempt to find the most effective method for developing software. But sometimes I believe that we're all just chasing the next trend and running around in circles and I envy the single voice (Borg like as it may be) leading MS development. Anyway, I have some things to learn and I'll withold my final judgement until I've been using JSF and Spring for awhile. Maybe there are some pleasant surprises to come.
I'm fortunate enough to get to continue to use Hibernate for ORM which is very cool. I still think Hibernate and object relational mapping in general is a very good thing. The biggest "problem" I see is that it looks like people are opting to use the "TopLink" way of doing things by using Criteria objects instead of HQL. What are they thinking? Why anyone would choose to use a non expressive bunch of Java code to write a query is beyond me. HQL is way better and one of the reason I like Hibernate so much better than TopLink. I e-mailed my supervisor about this one and we'll see what kind of response I get.
On the web framework front, we're using JSF (MyFaces specifically) instead of the defacto standard Struts. While fundamentally I don't have anything against Java Server Faces (it does have some nice features) I have to wonder why they made the decision to use it. David Geary (co-author of the book "Core Java Server Faces") once gave a talk at our local Java User Group meeting once and said something to the effect that "JSF was a standardized Struts that IDE vendors could rally around to create JSP visual editing tools". Part of that goal was to compete with ASP.NET. Coding up JSP pages is a bit mundane and who wouldn't rather have a tool write that junk for you? Well apparently the people where I'm working made that decision! It's still all hand-coded. So now we're using a framework nobody understands and I suspect productivity is lower. Where's the logic in that?
MyFaces seems very similar to Struts so conceptually it's easy to grasp but it's the details and the peculiarities of how things work that slow you down. It also seems to be at a higher level abstraction from the lower level request/response and the HTML it generates (the theory is that you can generate something other than HTML). But I think I prefer Tapestry's idea of staying close to HTML and only injecting the dynamic content. Tapestry allows you to use any HTML editing tool and HTML is well understood. JSF on the other hand is this parallel universe of tags that look a bit like HTML but can only be edited in a text editor or a JSF visual editing tool and at the moment there doesn't seem to be any tools that play nice with the MyFaces implementation. Secondly, staying close to HTML allows you to take advantage of advances in HTML like XHTML and AJAX. JSF, like ASP.NET, gives you a component model that will likely adapt to support advances in the underlying technology but there will always be a time lag. Perhaps the other minor benefits will outweigh the losses. We'll see... Right now it looks like change for the sake of change.
They also bought into the whole Spring IoC (a.k.a., Dependency Injection) idea. At first glance this seems like a good idea. You design to interfaces in an attempt to hide implementation details. Theoretically it should enable unit testing and allow us to switch between POJOs, Web Services and EJBs with greater ease. Of course it comes at a cost of greater complexity for questionable gain. For example if you create a DAO interface and then only ever create one implementation of that interface what have you gained? And then you have all the XML gunk to wire everything together. Theoretically, a meta data approach to wiring stuff together is better but not having experienced it before I'm a bit skeptical. The fortunate part about Spring is that they seem to understand that they need to play nice in a bigger community and support all the major Java frameworks out there so integration looks to be pretty straightforward.
My feelings are a bit mixed... Sometimes I believe that the dynamic, competitive, multi-vendor Java community is more vibrant than the MS .NET community and that the variety of tools is our attempt to find the most effective method for developing software. But sometimes I believe that we're all just chasing the next trend and running around in circles and I envy the single voice (Borg like as it may be) leading MS development. Anyway, I have some things to learn and I'll withold my final judgement until I've been using JSF and Spring for awhile. Maybe there are some pleasant surprises to come.
Friday, September 09, 2005
Open Surfin Safari
People seem to give Apple a lot of flak for being a proprietary software company and while it'd be ridiculous to argue the fact that Apple is to a large degree closed source, what most don't realize is that they are a very active user of and contributor to open source projects. The kernel of the OS is based on FreeBSD and the source code is available for download at Apple's OpenDarwin website. It's been like that since the first release of Mac OS X.
Secondly Apple's Webkit, their HTML engine used in the Safari web browser, is based on KHTML from KDE, the desktop environment for Linux. The source code for Webkit is also available for downloading from the OpenDarwin website. And as a matter of fact I followed the instructions in this article to get the source code from the CVS repository, compile it and run the latest code. Very cool. It's even the first (and currently the only) browser to pass the ACID2 test which tests a browser's support of web standards (try that with IE).
So yes Apple is proprietary in many respects but they understand when it makes sense to be part of the open source community.
Secondly Apple's Webkit, their HTML engine used in the Safari web browser, is based on KHTML from KDE, the desktop environment for Linux. The source code for Webkit is also available for downloading from the OpenDarwin website. And as a matter of fact I followed the instructions in this article to get the source code from the CVS repository, compile it and run the latest code. Very cool. It's even the first (and currently the only) browser to pass the ACID2 test which tests a browser's support of web standards (try that with IE).
So yes Apple is proprietary in many respects but they understand when it makes sense to be part of the open source community.
Tuesday, September 06, 2005
Lube, Rods, Scoring, oh my!
I was told by a couple of people who read my blog that it's too "boring" so I figured I'd spice it up a bit and talk about lubing your rod. All your partners will oooOOOOooo and aaaaAAAAAaaaa...
Get your mind out of the gutter...
I'm talking about foosball again! LOL. In addition to the new men on our foos table I had enough money left over from our "foos-aid" office collection to buy a can of 3-in-1 silicone spray lubricant from Canadian Tire for the foosball table rods. What a difference maintaining your uh "equipment" can do for you.
Friday, August 26, 2005
Training and Coaching
I just found an old article that I co-wrote back in 1997 for Computing Canada. The article was really a reader's digest version of a report I wrote for an application audit (a really intensive code review after-the-fact). It was a PowerBuilder app and the article makes reference to some PB-specific technology but reading it again 8 years later I'm surprised to realize that so many of the same things apply to the way we build apps today.
Too often, I see relatively junior programmers unleashed on software development projects with little or no guidance or leadership. As a matter of fact, I've probably spent two thirds of the last year rewriting year-old software that was created by junior resources with no training and no concern for best practices. I can see why companies are lured into using resources like this. They're relatively cheap, they're pretty keen, they work long hours and they really crank it out. But if they don't know what they're doing you end up supporting the old adage "there's not enough time to fix it now, but there's always time to rewrite it later".
The biggest thing that junior software developers don't do, is separate concerns. UI, business logic and data access get all tangled into one big incoherent mess. I stress that there must be some cohesion in your domain model. Generally speaking the closer you get to the users the more your code is exposed to change. In other words, the UI is going to change. Count on it. As you go up through the layers things change less and less. By the time you get to your domain model and the relational model that allows it to be persisted, Things are very stable and any change you must make to them has serious repercussions on the rest of the app. Therefore get that stuff right. You can be forgiven for cheating a bit when you get to the UI but at least build the backend stuff as well as you can. And feel free to use some junior resources, but for crying out loud, lead them.
Too often, I see relatively junior programmers unleashed on software development projects with little or no guidance or leadership. As a matter of fact, I've probably spent two thirds of the last year rewriting year-old software that was created by junior resources with no training and no concern for best practices. I can see why companies are lured into using resources like this. They're relatively cheap, they're pretty keen, they work long hours and they really crank it out. But if they don't know what they're doing you end up supporting the old adage "there's not enough time to fix it now, but there's always time to rewrite it later".
The biggest thing that junior software developers don't do, is separate concerns. UI, business logic and data access get all tangled into one big incoherent mess. I stress that there must be some cohesion in your domain model. Generally speaking the closer you get to the users the more your code is exposed to change. In other words, the UI is going to change. Count on it. As you go up through the layers things change less and less. By the time you get to your domain model and the relational model that allows it to be persisted, Things are very stable and any change you must make to them has serious repercussions on the rest of the app. Therefore get that stuff right. You can be forgiven for cheating a bit when you get to the UI but at least build the backend stuff as well as you can. And feel free to use some junior resources, but for crying out loud, lead them.
Luxury Foosball
I recently took up a collection to replace a couple of foosball men on our Harvard foosball table at work. If you've ever seen one of these tables you know that the original men and the replacements are pretty boring looking. So a few folks around the office had some fun photoshopping, combining the heads of people with men on a rod. Well it appears for a mere $73,000 you too can get a table with tiny little replicas of friends and family.
Monday, August 22, 2005
Target: Adobe
Microsoft is making some moves that look quite threatening to Adobe. Microsoft is building applications to replace Photoshop (PSD) , Acrobat (PDF), and now Flash (SWF). Microsoft's calling it's Adobe-killers Acrylic, Metro, and Sparkle. A little more of that embrace, extend, and extinguish we all love? Maybe.
By the way, with the new Core Graphics, Core Image, and Core Video frameworks in Apple's Mac OS X, I suspect that Apple has laid the foundation for a similar move if they think it's necessary. But Adobe got its start with Apple, and Apple in turn uses PDF everywhere in Mac OS X so I think Apple contributing to Adobe's demise is a much less likely outcome.
By the way, with the new Core Graphics, Core Image, and Core Video frameworks in Apple's Mac OS X, I suspect that Apple has laid the foundation for a similar move if they think it's necessary. But Adobe got its start with Apple, and Apple in turn uses PDF everywhere in Mac OS X so I think Apple contributing to Adobe's demise is a much less likely outcome.
Monday, August 15, 2005
Interviewing
In my current position I'm the lead Java developer because I have the most experience and know as much as, and maybe even a little bit more than, the rest of the people on the team. Part of my strategy to keep my skills sharp, is the routine investigation of other languages and tools. Most recently those languages have been C# and ObjectiveC (and their related frameworks, .NET and Cocoa respectively). Apparently my boss took note of my new knowledge and a few days ago she asked me to conduct technical interviews for a "senior" Microsoft .NET developer.
I was a bit anxious about the request because I don't consider myself a .NET expert. But I approached these interviews the way I've approached all the Java developer interviews in the past. I try to cover a broad range of topics (e.g., Relational Databases, OO, Patterns, Object Relational Mapping, Unit Testing, HTML, insert programming language here , etc.) and just substituted the Java questions for C#/.NET questions. What surprised me is the quality (or the lack thereof) of the people I've interviewed. Maybe I should be looking for a .NET job? ;-)
I was a bit anxious about the request because I don't consider myself a .NET expert. But I approached these interviews the way I've approached all the Java developer interviews in the past. I try to cover a broad range of topics (e.g., Relational Databases, OO, Patterns, Object Relational Mapping, Unit Testing, HTML, insert programming language here , etc.) and just substituted the Java questions for C#/.NET questions. What surprised me is the quality (or the lack thereof) of the people I've interviewed. Maybe I should be looking for a .NET job? ;-)
Wednesday, August 10, 2005
EJB3 Presentation
It seems like EJB3 information is coming fast and furious now. The Server Side is hosting a new EJB3 presentation recorded at the Belgium Java Users Group. One of the speakers is an Oracle Toplink developer. It gives a very good overview of the EntityManager API that I was talking about the other day. Check it out.
Virtual Globetrotter
Google Maps has obviously inspired some people to check out the world from a whole new perspective. Check out the Eiffel Tower or the Great Pyramids. And when you're through with that go check out Sightseeing with Google Satellite Maps or Google Sightseeing. Be careful, just like the real thing, sightseeing this way can waste a lot of time.
Monday, August 08, 2005
EJB3 EntityManager
Since my first post about Entity EJBs with Hibernate, the Hibernate team put out a new beta implementation of javax.persistence.EntityManager. So I wondered what exactly it would take to jettison all the hibernate imports from my class. Well it turned out to be pretty simple. First I substituted the hibernate.cfg.xml file for a META-INF/persistence.xml file that looks like this:
The interesting thing about this is that it autodiscovers the annotated classes. No longer do I have to individually list each persistent class. Secondly, I changed my main method to look like this:
You can see that this code is very similar to the Hibernate code that I posted earlier. Obviously the class names and some of the methods are different (like getSingleResult() instead of uniqueResult()) but at first glance it looks like getting started is pretty easy. It'll be interesting to see some of the differences between Session and EntityManager.
<entity-manager>
<name>manager1</name>
<properties>
<property
name="hibernate.connection.driver_class"
value="org.postgresql.Driver"/>
<property
name="hibernate.connection.url"
value="jdbc:postgresql://127.0.0.1:5432/myDatabase"/>
<property
name="hibernate.connection.username"
value="darcy"/>
<property
name="hibernate.connection.password"
value="darcy"/>
<property
name="hibernate.dialect"
value="org.hibernate.dialect.PostgreSQLDialect"/>
</properties>
</entity-manager>
The interesting thing about this is that it autodiscovers the annotated classes. No longer do I have to individually list each persistent class. Secondly, I changed my main method to look like this:
public static void main(String[] args) {
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("manager1");
EntityManager em = emf.createEntityManager();
try{
Brand b = (Brand)em.createQuery("select b from Brand as b")
.setMaxResults(1)
.getSingleResult();
System.out.println(b.getName());
}finally{
em.close();
}
}
You can see that this code is very similar to the Hibernate code that I posted earlier. Obviously the class names and some of the methods are different (like getSingleResult() instead of uniqueResult()) but at first glance it looks like getting started is pretty easy. It'll be interesting to see some of the differences between Session and EntityManager.
Tiger Development
After installing Mac OS X Tiger, and restoring applications and user data, my next job was to install development tools.
Java
On the Java side: I'm a bit perplexed why Apple doesn't ship their Java 5 implementation with Tiger. As far back as I can remember they've always shipped the latest and greatest. But this time I had to download. No big deal, but it's hidden on their website. I expected to be able to go to connect.apple.com (their developer website) click on "Downloads>Java" and it would be there. But no, only the Java 5 docs are there. Instead I had to go to the general Mac OS X website and go to the downloads section in there and search for it.
Anyway, that was only a minor annoyance. I was able to download it and install it without any trouble. My next problem was that Java 5 wasn't made the default VM. So I had a little more googling to do before I discovered a couple symlink changes would make everything happy. In the end I have all my Java apps and IDEs (i.e., Eclipse) working with the new Java 5 VM and all is well a week later.
Cocoa
Next thing was a move to XCode 2.1. I downloaded it and installed it without any issues (there was a nice big link on the Apple's developer connect website). I was able to open all my Cocoa projects, recompile and run without issue. So then it was time to move onto seeing what's new in Cocoa in Mac OS X. There's quite a bit, but the one that instantly attracted me was the visualization tools in XCode.
I've always been a big fan of modelling tools and the diagrams they create. I always find it easier to express ideas in a picture and it's always easier to look at a diagram rather than gobs of source code to figure out what someone else was thinking. Well apparently Apple feels the same way. XCode now gives you the ability to generate class diagrams from your source code (Java, Objective-C or C++). And these diagrams aren't static either. As you change things in code the diagrams reflect those changes. Fortunately, they look and behave like UML class diagrams so the symbols are pretty familiar.
Apple also uses this new diagram facility in something they call CoreData. Essentially you create an entity relationship diagram that describes the data that your application maintains and then at runtime, the core data framework will use this metedata to store and retrieve user data in an XML file or a SQLite database. Couple this with the Cocoa Bindings framework, which allows you to bind object properties to UI widgets, and you have some great facilities for building data-centric applications. Now that the persistence and UI parts of the application are taken care of by the Cocoa frameworks you are left to concentrate on the business logic. The big limitation in CoreData right now is that it's XML and SQLLite only. That means if you want to create a multiuser application with an enterprise database server you're out of luck. Secondly, even if it did allow you to go against an Oracle or Sybase server I don't think the tools are really designed for fine grained control over the object relational mapping or the queries that are generated. But I don't want to diminish the productivity of this framework in addressing the the single user data persistence problem. If I was developing a desktop Mac OS X application, I'd be all over this. Here's a nice little tutorial that you may find interesting.
There is also a nifty little feature that allows you to drag and drop an entity from the diagram into a window in Interface Builder and generate a default UI. Apple says you can use this feature to quickly create a starting point for your application or to quickly generate an application to exercise your data model. I was impressed that I could create a fully functioning application that maintained data with no code in just a few minutes!
Java
On the Java side: I'm a bit perplexed why Apple doesn't ship their Java 5 implementation with Tiger. As far back as I can remember they've always shipped the latest and greatest. But this time I had to download. No big deal, but it's hidden on their website. I expected to be able to go to connect.apple.com (their developer website) click on "Downloads>Java" and it would be there. But no, only the Java 5 docs are there. Instead I had to go to the general Mac OS X website and go to the downloads section in there and search for it.
Anyway, that was only a minor annoyance. I was able to download it and install it without any trouble. My next problem was that Java 5 wasn't made the default VM. So I had a little more googling to do before I discovered a couple symlink changes would make everything happy. In the end I have all my Java apps and IDEs (i.e., Eclipse) working with the new Java 5 VM and all is well a week later.
Cocoa
Next thing was a move to XCode 2.1. I downloaded it and installed it without any issues (there was a nice big link on the Apple's developer connect website). I was able to open all my Cocoa projects, recompile and run without issue. So then it was time to move onto seeing what's new in Cocoa in Mac OS X. There's quite a bit, but the one that instantly attracted me was the visualization tools in XCode.
I've always been a big fan of modelling tools and the diagrams they create. I always find it easier to express ideas in a picture and it's always easier to look at a diagram rather than gobs of source code to figure out what someone else was thinking. Well apparently Apple feels the same way. XCode now gives you the ability to generate class diagrams from your source code (Java, Objective-C or C++). And these diagrams aren't static either. As you change things in code the diagrams reflect those changes. Fortunately, they look and behave like UML class diagrams so the symbols are pretty familiar.
Apple also uses this new diagram facility in something they call CoreData. Essentially you create an entity relationship diagram that describes the data that your application maintains and then at runtime, the core data framework will use this metedata to store and retrieve user data in an XML file or a SQLite database. Couple this with the Cocoa Bindings framework, which allows you to bind object properties to UI widgets, and you have some great facilities for building data-centric applications. Now that the persistence and UI parts of the application are taken care of by the Cocoa frameworks you are left to concentrate on the business logic. The big limitation in CoreData right now is that it's XML and SQLLite only. That means if you want to create a multiuser application with an enterprise database server you're out of luck. Secondly, even if it did allow you to go against an Oracle or Sybase server I don't think the tools are really designed for fine grained control over the object relational mapping or the queries that are generated. But I don't want to diminish the productivity of this framework in addressing the the single user data persistence problem. If I was developing a desktop Mac OS X application, I'd be all over this. Here's a nice little tutorial that you may find interesting.
There is also a nifty little feature that allows you to drag and drop an entity from the diagram into a window in Interface Builder and generate a default UI. Apple says you can use this feature to quickly create a starting point for your application or to quickly generate an application to exercise your data model. I was impressed that I could create a fully functioning application that maintained data with no code in just a few minutes!
Monday, August 01, 2005
Tiger!
Well I took the leap and bought Mac OS X 10.4 Tiger today. I also followed the recommendations on the web (kinda of a herd mentality) and erased the hard drive and reinstalled "fresh". That second internal SATA hard drive definitely came in handy for backing up applications and the stuff in everyone's accounts. A few hours later I have everything back to normal (I think). My first impressions is that the Dashboard is pretty cute but I'm not sure how useful (although the calculator came in handy once already). Spotlight is definitely nice (and fast too). Searching for anything across the disk is pretty wicked! Well it's late, and time for bed. I'll post info about the ugly stuff once I come across it. ;-)
Subscribe to:
Posts (Atom)