Loading ActionMailer SMTP settings from the database

Here is a simple way to load your SMTP settings from the database instead of having to call ActionMailer::Base.smtp_settings= in environment.rb, development.rb or production.rb. Using the database to store these setting, while a bit slower, allow one to easily allow an administration to change the configuration without having to restart the Rails application.

The first approach I used was to just override the self.smtp_settings method in my ActionMailer::Base subclass. But that didn't work due to cattr_accessor not working as expected. So I had to also add class_inheritable_accessor :smtp_settings.

So I did the following :

class StuffNotifier < ActionMailer::Base

class_inheritable_accessor :smtp_settings

def self.smtp_settings

Hash.new {|h, k|

Preference["smtp.#{k.to_s}"]

}

end

end

I use Hash.new with a Proc because the stuff the Preference[] method access the database, if I construct an Hash with all the value loaded from the database, then the Hash will be constructed many times as ActionMailer::Base access self.smtp_settings many times when sending an email. Using an empty hash with a default Proc solved my problem. I also prepend "smtp." so it retrieves the "smtp.host" value from my system preference table.

If somebody knows of a better way to do it, feel free to add a comment or a link.

Storing System Preferences in the Database

Here is a simple way to store system preferences in the database for a Ruby on Rails application. This simple solution offers no caching, so accessing the same preference many times will result in many database request. Suggestions for per request caching are welcomed.

Using the code bellow, one can access preferences like this :

admin_email= Preference["admin_email"]

First, let's start with a migration that will create a table in which we can store many types of preferences :

class CreatePreferences < ActiveRecord::Migration

def self.up

create_table :preferences do |t|

t.column :setting, :string
t.column :type, :string
t.column :value, :string

end

end

def self.down

drop_table :preferences

end

end

Now, we create the model. Because we want to be able to get many types of preferences (and eventually validate their value in different ways), we create a base Preference class and many subclasses for all the types of preferences we want to have. Some subclass will override the value and value= methods to convert the value to the proper type :

class Preference < ActiveRecord::Base

validates_presence_of :setting

def self.[](setting)

setting= self.find_by_setting(setting)
setting.nil? ? nil : setting.value

end

end

class UrlPreference < Preference
end

class EmailPreference < Preference
end

class StringPreference < Preference
end

class IntegerPreference < Preference

def value()

self[:value].nil? ? nil : self[:value].to_i

end

def value=(v)

self[:value]= v.nil? ? nil : v.to_s

end

end

Note that we could add validation for the value attribute in UrlPreference and EmailPreference to validate the format of the value.

More on the continuous tax

Cedric post on the continuous tax triggered what it seems as another debate between dynamically types language versus statically typed language. This funny thing that even if Java and Ruby are not always mentioned, it seems as this debate is more about who prefers to code in Java or who prefer to code in Ruby.

Eric Burke took my comment (calling it bullshit) on Cedric post to talk a bit on how he did pay this so-called tax once or twice.

While I do not really appreciate it when someone compare what I say with shit, the debate has a bit too much flames for me to add oil to it.

I find this debate to be much like flame wars that the young Java community endured with the C/C++ community a not so long time ago. Much of the debate revolve around one particular aspect of the newcomer without any substantial facts. In the early days of Java, it was performance (which was partly true, but even when we got Hotspot, naysayer were still saying that Java was interpreted). Now with the rise of dynamic language (yes I'm thinking Ruby but also Javascript), we have the Java dinosaurs arguing that you cannot do re-factoring or code completion with these language because they are dynamically typed. But these things can now be done with the latest IDEs. Maybe not to the extent that we can achieve with Java IDE but it is evolving rapidly.

Today dynamic language naysayer are no better that yesterday Java naysayers, they hold onto the same argument over and over without clearly substantiating them (I'm sorry when you loose 5 minutes, because a method does not really return the type you are expecting while acknowledging that you still have some miles to put behind you using the language, does not count as paying a continuous tax).

I use both Java and Ruby on a daily basis. While sometimes I may miss the righteousness of a statically typed language, I cannot say that I pay a higher tax when I use Ruby. Nor I can say that I pay a lower tax when programming in Java and having to write useless catch statements, having to write a freaking Comparator to sort object based on multiple attributes, having to check for nulls all the time (yes I know about the Null object idiom) or waiting for my application server to restart.

Both type of language have distinct advantages and inconvenients. I try to keep an open mind about it and use the best language/platform for the task at hand.

No dev kit for Apple iPhone

It looks like Apple choose the only way they know to squash software developer complains about the iPhone... Marketing spin!

When the iPhone was first announced, Steve Jobs told everyone that the platform was closed to software development because he does not want 3rd party to crash your (or soon to be) shiny iPhone. Rightfully, software developer complained about this. Today, you can install new applications (J2ME) on most cell phones. It made no sense to have a phone as advanced as the iPhone not allowing one to install new applications.

So I guess, that Apple felt a bit of steam and needed to fix the situation. So we will be able to develop application for the iPhone... But Apple will still not gives any dev kit to do so. No, you will have to... write web applications! Yeah! The iPhone comes with Safari, so you can write web application (putting in a bit of Ajax would be better in Steve Jobs perspective) that will "run" on the iPhone. As we did not already knew that! I guess the greatest feature in the iPhone would be for the user to add a shortcut to your application so he can have a quick access to it. How innovative!

If only they were announcing that Google Gears was bundled so you can run you apps offline (or cache data on the iPhone to stay responsive), they it would be a nice announcement. I know that Apple can make any product look great, thanks to their marketing department, but this is really underwhelming! I'm sure they can do better than that!

A sad day

Today is a bit of a sad day for me. I deleted two comments I had on two different posts related to Ant. Some anonymous troll from coderslog.com posted comments on these two entries just to link to his web site. Beside the fact that the comments were related to Ant and Maven, they added nothing to the actual post. They were just links put there by a troll.

I do not accept trolls on my blog, period.

This is the first time I delete a comment. I hope this will be the last. I don't care if people don't have the same opinion as I comments on my blog. But people who try to get higher ranking or some publicity for they own site are off limit. If you want to link in a post to your own site, it's OK with me as long as your comment provide something meaningful to the conversation.

RE: If Agile is So Good, Why Isn't Everyone Doing It?

InfoQ asks "If Agile is So Good, Why Isn't Everyone Doing it?"...

Its a well know fact that most people don't like change. This is why we have change management consultants! However this doesn't really explain why people seems to resist more to agility than when we impose a heavyweight process upon them.

When we add to an existing process, people will complain about having to do more stuff. But they don't feel threatened by the new tasks they have to do. If the process becomes more heavyweight, they will just ask their manager to hire someone and after asking again and again, somebody will be hired to take the load. Manager just love this way of doing things. They can ask for more budget (which they'll get after asking a few times) and they ends up managing more money and more people. The manager just got closer to his nirvana.

Now, when we are talking about Agile Software Development, we are not talking about more, but we are talking about less. Because agility is about being more efficient, we need less people, less time and less budget to achieve the same result. If we think rationally, then we feel good about this. However most people don't think rationally. Because we have a smaller and multi-disciplinary team, some people will fear to loose their job because there is less work. Some people will fear that they'll be less relevant. Some will not want to take new roles or change their existing one. Managers will fear that their budget or workforce will be lowered...

But it does not have to be this way... Being more efficient is not about firing employee or decreasing budget! It's about doing more with the same workforce and budget. It's about bringing more quality. It's about having more fun doing what we do.

On a final note... More heavyweight process mean more finger pointing when things go wrong (and in last resort, the process itself gets finger pointed). More agility, means being successful as a team or failing as a team! No finger pointing required (this do not mean that we should not have a post-mortem). Even failing as a team is fun... compared to being alone getting the blame.

Beware iPhone... Here is the fxPhone!

Sun just announced the JavaFX Mobile software... This looks like cool software that promise to allow any manufacturer to produce iPhone look-alike! Let's just hope that they'll have the same multi-touch screen support and that consumer will be able to load the software they want on it!

RE: To Groovy or to JRuby

Shay Banon ask the question : To Groovy or to JRuby?
It seems that these days, whenever we see Groovy mentioned in blog post, it must be compared to Ruby or more specifically to JRuby. Then, in the comments, we have some Groovy lover express that Groovy is better than JRuby for the Java developer. What is funny is that people who are working on JRuby suggests that you try both and see for yourself.

Now that Groovy achieved to deliver a 1.0 version (and now a 1.1), it seems that this trend is increasing... Groovy advocate are becoming more vocal about their stuff. Instead of pushing Groovy/Grails for what it's worth, they are pushing it by saying how easy it is to learn compared to Ruby/Rails for a Java developer perspective. This is the argument that's being repeated over and over! And, as we see in some post comments, this makes some manager feel better.

This makes me feel sad!

Now this argument has some truth in it, but this does not necessarily make Groovy a better alternative than JRuby for scripting the Java platform. Learning a new language is always a good thing... Be it Groovy, Ruby, Python, etc. You never really loose by learning a new language... You never really loose by learning a new API, a new framework. Learning new things makes you a better programmer.

This is why I prefer Ruby/Rails than Groovy/Grails... It's not because Ruby/Rails is superior, it's just that learning a completely new language/framework help me open my mind to new ways of thinking. Learning Groovy will also do that, but to a much smaller extent. This will help me become a better programmer... Even better it will keep my mind awake enough to not become a dinosaur who know only one language/framework.

And to the manager that may read this... Having developers who have an open mind and bring new ideas is way better than having developers that will not stray away from their main comfort zone. It cost less in training and allow you to get advantage of new technologies as they become mainstream instead of missing the boat.

Don't take this post as telling you to choose JRuby, like Charles Nutter said, "don't let anyone make the choice for you."

Grails vs Rails... The number game just started!

A first Grails vs Rails Performance benchmark has just been published The benchmark shows that Grails is faster than Rails. Rails developer Jared Richardsons commented on some flaws with the benchmark (aren't all benchmarks flawed in some way? And as the benchmark author said, the benchmark is not about scalability).

But looking at these numbers, I found that Rails is not far behind Rails. And I find that very encouraging for the Rails community. Yes, I would expect much better performance on the Grails side... Most of Grails is Java code. Java code running inside a modern JVM should run pretty fast. But beside the insert test (which I guess is significantly slower due having just one Mongrel instance running), Grails is not very far ahead Rails. Rails is mostly Ruby code. The Ruby interpreter is just that, an interpreter. There is no just-in-time compilation, no enhanced optimization for often used code in Ruby.

I can't wait till we have Ruby running on some VM (maybe the JRuby team will run the same benchmark and give us their numbers) and I guess we will see some great improvement on the Rails side (I guess that just rerunning the benchmark with multiple Mongrel instances will close much of the current gap).

This may be the very start of the Grails vs Rails number game!

Oracle acquire Tangosol

It looks like Oracle just acquired Tangosol! This must be great new to Cameron Purdy... I guess it was a long deal in the making.

I always feel kinda mixed up when I see great small Company acquired by huge companies. The vision of the Davids is often being blurred by the Goliath's. Can't wait to see Cameron's post on his blog to get some more details on this acquisition and what it'll mean to Tangosol.

JRuby on Grails?

There is a small ongoing debate about Ruby on Grails... Graeme Rocher, the Grails founder, posted in thoughts on the topics too.

I don't know were Graeme takes it's numbers about Grails apps that are in production, but I guess that Ruby on Rails numbers are much higher. He argue that for a Java shop, Grails is much better framework than JRuby on Rails. His main argument to support this is that it will take less training. He seems to forget that to learn Grails (even if it's closer to Java than Ruby) also require some training. I would even add that learning the convention for framework like Rails or Grails is where most of the training is required... Learning the language is easier than learning the conventions.

In my point of view, JRuby on Rails has much more potential than Grails. First, Grails is playing catchup with Rails (still waiting for Migration in Grails). Second, Grails biggest strength reside on the integration layer between well know frameworks. However, these same frameworks are Java based and they come with the same limitations that the Java language has. Limitation that are not present in Rails because of the dynamic nature of the language it's build on.

Why would it be a good idea to run Rails on JRuby? Yes, integration with Java is a plus. But performance may be part of the answer. Ruby is not very fast (but it should get a lot faster very soon with the use of a Ruby VM), Java is quite fast. So running Rails on Java can make it faster. Even with Ruby VM coming along, JRuby may be faster because Java VM had a lot more work done in the VM performance than Ruby will have when it get it's own VM. If I'm able to run a Rails app in Tomcat or Weblogic, it will also have more appeal for existing Java shops. It could also give you the benefit of having access to existing Java libraries that have no equivalent in the Ruby world.

Instead of working on making JRuby as a language to run on top of Grails, if integration with existing libraries (like Hibernate) is desired, I think that Integrating the existing library in Rails would be much better. One could easily write a simple layer around Hibernate so one could have model objects inheriting something like HibernateRecord instead of ActiveRecord. The dynamic nature of Ruby could make this HibernateRecord behave the same way as an ActiveRecord. As for presentation framework, I don't think that component-based framework are such a good idea anymore. So there is no need to ever want to integrate them in Rails.

Graeme argue that Sun should not longer put resources in Phobos because the project is unpopular... I could argue that same thing about Grails... Compared to Rails, Grails looks like the unpopular guy in the schoolyard. But I won't do that... While I personally don't see why would someone would choose Grails over Rails, I thing that competition between frameworks is good. And when Grails will start to innovate (instead of playing catch-up) then it may become really interesting. The unpopular guy of today can always become the most popular guy of tomorrow (this is the Ruby and Java story).

Running application instead of application servers

Most of the time, Java web application are deployed on their own instance of an application server. Within shops that uses server virtualization, this approach is extended to have one virtual server per application. This is done to ensure that an application will not adversely affect another one running on the same physical server.

However, application server products always assume that you may deploy many application on the same server. Configuring the application server is then a lot more complicated than what would be required to configure just one application.

If most of the time we deploy only one application per application server, why do we not bundle application server in our application instead of installing application server and then configuring our application on top of them?

Here how I would see how it would work :

1. Develop the application as usual (deploying the application on an application server),
2. Use some tool provided by the application server product to create an installation/update package :
1. The tool would have a Wizard like interface (but you would also be able to run from the command-line after saving the settings from the Wizard),
2. It would ask for which application to deploy,
3. Based on the application deployment descriptor, it would preselect application server features that needs to be available,
4. Provide an interface to select additional application server features to activate,
5. Ask for default configuration parameters for the application (datasource, ...),
6. Generate an interface (web, fat, console) to configure that application when installing/updating it,
7. Generate the necessary installation script,
8. Package the whole thing into a platform specific package (DEB or RPM for Linux, MSI for Windows, ...),
3. Install/update the application on the targeted environment using the generated package.

Using this approach has the following benefits :

1. Smaller installation footprint. If the application server does not need to be installed with all it's feature activated, then they should not be installed,
2. Easier installation/update process for those who have to maintain the system,
3. Easier configuration has only configuration options required for the application will be exposed.

Food for thoughts...

Geronimo First Impression

I just installed Geronimo for the first time. I wanted to run Hudson and I'm a bit tired of Tomcat for many reasons. I could have used Jetty but I really wanted to try Geronimo.

Installation was quite easy. You just decompress the installation package in a folder and they you run it. First thing first, I changed the password of the system user (the default admin user) to something other than manager. It's still amaze me, that the default installation uses a default user/password for administration purpose.

The next step was to deploy the Hudson WAR file. So I went to Geronimo admin console and I click on the Application/Deploy New. There your are presented with a simple screen asking you for an archive to deploy and a plan. The plan is optional. So I put my hudson.war in there and click Install (shouldn't it say Deploy?). Bang! I got back an error message with some stack trace. It seems like I need a deployment plan to deploy (or is it install) this application. But there is no hint whatsoever as to what I should put in there.

My guess was that I needed to specify some security-role mapping and configure one of the environment entry for Hudson.

After some search in Geronimo documentation, I found out that I needed the following deployment plan to successfully install Hudson :

<?xml version="1.0" encoding="UTF-8"?>
<web-app

xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1">

<security-realm-name>geronimo-admin</security-realm-name>
<security>

<default-principal>

<principal name="anonymous" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</default-principal>
<role-mappings>

<role role-name="admin">

<principal name="administrators" designated-run-as="true" class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
/>
<principal name="root" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</role>

</role-mappings>

</security>

</web-app>

This is not what I call something that is obvious, especially for the <principal .../> thingy.

And by the way, there is no way to configure any <env-entry> in your wen.xml with some other value. So you have to edit your web.xml before deploying your application if you want to change these.

Now, how could this be improved? First, if the administrative console does not provide a wizard or something to specify what is needed to properly configure the application (like it is on Geronimo), then the application server should first report meaningful error messages (instead of meaningless stack trace). Another proper of handling this kind of things would be to provide a sample deployment plan with all the elements that must be specified for the application being deployed.

Even with the EJB 3.0 specification, it seems that we are far from escaping the XML configuration hell of J2EE.

Better, I believe we should reverse the roles of application servers. Instead of deploying an application on an application server, we should bundle the application server with our application and run it like any other application. I will expand this thought in a soon to be published blog entry.

So my first impression of Geronimo? It's not most difficult to install than Tomcat but could provide better error reporting when deploying application. The deployment plan should also be simpler and more intuitive or else provide a configuration wizard.

Raven + JRake == Raven

It looks like the Raven and JRake are merging! New name is... Raven. This is really good news. It looks like one of my 2007 prediction is getting shape :-D

Congratulation to Matthieu Riou and Matthew Foemmel who are merging their effort to bring us what may become the best build tool in the near future.

An Invitation to Give away Your SSN and Credit Card Number

StolenIDSearch

It looks like a new service from TrustedID came out recently. This service allows you to check if your social security or credit card number have been compromised.

I understand that many users will be interested is such a service. But I have a also some problem with it :

1. If your credit card or social security number has been stolen, there is a good chance that you will find out quite quickly. Most of the time, people who stole this information will not wait a long time to use it. So sooner than later, you will get a call from you bank of credit card company about some weird activity in your accounts.
2. This is an invitation for criminal to setup similar looking sites and send out spam to invite people to verify if their SSN or credit card number have been stolen. Victims will easily fall for it and will give their numbers to criminals.

While we may trust TrustedID not to store nor use the information we input on their site, they do have a database with all the compromised information. So if someone stole that database from them, they get more than a handful of information that can be use to steal someone identity.

I believe that these kind of services should not be available online but through you banking institution. My bank already offer me, for free, a service that notify me of any activity on my credit report. So if anyone try to get credits in my name, I will now it very soon. My bank already have these information, so I don't have to give it to someone else to benefit for such a service.

j2ee_util.rb public release

I just released my first public version of j2ee_util.rb : Simple tool to manage your J2EE archives (war, ear, jar, zip). Not long ago, I had to make quick changes in a web.xml file contained in a WAR file contained in an EAR file. To do that, I had to extract the EAR that extract the WAR then edit the file then repackage everything.

The process is a bit cumbersome and prone to errors. Yet, I never saw a command-line utility that allows one to do that. So I decided to write my own and j2ee_util.rb was born.

With this command line tool I can now type this to edit the web.xml file :

ruby j2ee_util.rb --edit my-application.ear:webapp.war:WEB-INF/web.xml

And when I exit the editor, the file is automatically repackaged in the WAR file which will be repackaged in the EAR file. The tool also only extract the specified files instead of the whole archive.

I plan to add a few features to be able to edit stuff directly from the command-line (like replacing a value in an XML file) without having to fire-off an editor.

If you use the tool and have any comment/idea/issue with it, fell free to leave a comment on this post.

Groovy Ant Builder

The other day, I was tasked to modify a Java web application. However, after checking out the source code from CVS, I found no build script. It looks like I'm expected to use WSAD to compile and package the application. This is a direct hit in my one of my software development principle: Never rely on an IDE to build an application. Anybody should be able to check out the code and build it with some non-GUI build tool.

The client already use Maven for other projects. However, the application I needed to modify did not have the Maven standard directory layout. The CVS repository also contains the library this application depends on. Because of firewall restrictions, it is not easy to use Maven dependency management (jar download are not permitted by the proxy). They run their own Maven repository but adding stuff in it is no easy task.

The easiest solution to quickly get the job done, would have to create an Ant build script. However, I did not have Ant installed and the proxy would not allow me to download it.

I did have Groovy installed on my portable hard-drive. Since Groovy comes bundled with Ant jars and the Groovy Ant Builder, this was now the fastest path to creating my build script.

And it fact, it was quite easy to get the job done. Task are easily defined and the builder syntax remove all the pain of XML build script. Here is an example of my compile task :

void compile() {

ant.mkdir(dir: "${classes_dir}")
ant.javac(destdir: "${classes_dir}",

srcdir: "${src_dir}",
classpath: "${compile_classpath}",
target: "1.4",
source: "1.4"
)

ant.copy(todir: "${classes_dir}") {

fileset(dir: "${src_dir}") {

exclude(name: "**/*.java")

}

}

}

The thing that seams to be missing is the proper declaration of task dependencies. It seems that the only way to do dependencies is to call another task from a task :

void war() {

compile()
ant.mkdir(dir: "${dist_dir}")
...

}

This seems a bit backward. And I don't know if dependencies will be called many time if they are referenced my many tasks (I will have to test it).

I did consider using Raven, but right now, it lack customization when you want to exclude stuff from the build or if you do not want to use dependencies (but prefer to specify your own compilation classpath).

I also looked at Gant but did not use it for two reason. First, I was not able to download it (proxy restriction) and second, for some reason, when I look at their example, I find them a bit ugly and it seems that you have two ways of doing stuff.

For my particular problem, Groovy Ant Builder allowed me to get the job done quickly and easily. It reminded of things I dislike about Groovy syntax like have to use def to define variable (but not to define methods) and having to specify void as a return type when my methods does not return anything. I much prefer Ruby syntax.

Sony-Ericsson PSP

Rumors abound about the next version of the Sony PSP game console...

Maybe Sony could kill the the iPhone before it launches by delivering a Sony-Ericsson PSP! Allow with a slimmer design and GSP receiver, they could put a touch screen and add GSM phone capabilities to the device.

As a PSP owner, I would be really interested is the new device!


UPDATE : It looks like there are already rumors about a Sony-Ericsson PSP.

Improving the Java Specification Request Process

The JSR process is know to take a lot of time produce an actual specification. On top of that, it often produce overly complex specifications that are way too overkill to solve the problems they intend to solve. It is also a process that is driven by the main vendors desire with little thoughts for developers.

We could probably shorten the process and increase the usefulness of JSR by bringing a bit more agility in the process. Here is what I think we could do to make things a bit better :

1. Create the reference implementation first. Then produce the specification. A working implementation offer greater value than just having a specification. It allows the community to use it and comment on real life issue. This is way better than commenting on a theoretical document.
   Groovy is a good example of creating a reference implementation before a specification. Granted, it took a lot of time (lack of resource availability) to achieve, but in the end, we have a better Groovy than if we produced a specification first and then implemented it. Once a specification is voted, there is little coming back (beside repeating the complete JSR process). Voting on a working implementation mean voting on the real thing!
   
2. Make the sponsors of the JSR provide full time resources to work on the reference implementation. There is nothing worse than only having resources working part time on a JSR. Things go slower and communication suffer when the team members have other responsibilities.
3. Make the reference implementation Open Source from day 1. Make the code public as soon as basic functionality is built in. This allow the community to participate early and provide early comments.
4. Make all communication related to the JSR public from day 1. Public forum and/or mailing list increase the diffusion of the information. Issue/feature tracking should be readily available and every decision made on issues/features should be made public. Having public communication will again increase the community involvement and at the same time decrease the sentiment that the JSR driven by the vendors secret agenda.
   
5. Have the JSR team produce workable software at regular intervals (every months for example). These content of each iteration should be determined at the beginning of the iteration based on the issue/feature backlog. Each iteration should have a specific goal to make sure that the team focus on the right thing for the iteration.
6. If the JSR address something that is already available in an Open Source project, it should review the project and base it's work on it. If something exists there is no reason to start from scratch.

Doing all of this will ensure that at even if the JSR is voted off,the community will gain working software. It will then be its choice to use it or not. But I believe that with these kind of changes, most JSR, will either fail early (which is good as less time will be spent on it) or either succeed when they attain the voting stage (aka version 1.0).

iPhone

Apple finally announced the much rumored iPhone . The device really look nice and follow the thin is in concept launched by Motorola .

What's being announced is really cool. But I wonder about what's not being announced :

• Java support : not a word on that. Granted, it run OS/X and Widgets but most phone today ships with Java. It certainly has the power to run Java,
• What kind of CPU in inside this thing. If it runs OS/X it may be an Intel or a PowerPC... XScale like many other devices uses a different instruction set than Intel Pentium CPU AFAIK. So will I be able to run any OS/X applications? Guess not. No word on CPU speed either,
• How much memory (beside storage which will be 4G or 8G)?

I also guess that the various sensors that are in the device will eventually have more uses that just dimming the screen, detecting rotation, etc. Will they be easily accessible by application developers?

I guess we will have to wait until this summer to get more details.

One last thing! Which carrier will they choose for Canada? The device is GSM which mean the only choices are Fido and Rogers (which are just two brand for the same carrier). Most of the time Rogers has the coolest phones, but I hope it will also be available on Fido.

Anyway at 499USD, I cannot say that's it's cheap. But it does seems to be a nicely done convergence device.


UPDATED: I forgot to talk about GPS functionality. Adding this would make it the ultimate convergence device. Maybe they'll announce that next year!

It is also kind of funny that they waited for the iPhone to put Bluetooth in their iPods.

It's NOT the code NOR the process, stupid!

It looks like some people think that focusing on a process and having a high level view will yield more successful projects.

I have to disagree with this statement. While a process may be a good thing, in most cases the process is the cause of failure. The reason is simple, processes are often put in place for one reason. To reduce the per resource cost. It seems that executive believes that having a process will allow them to hire less skilled individuals (this really mean cheaper) and to still be able to deliver a project on time and on budget. Since the birth of software development, we have people who champion processes to executives to reduce their costs and increase the rate of success. They will often use the quality argument to support their point of view. However, even if more people use processes, the rate of successful software projects has not increased throwout the years nor the cost has decreased.

I have yet to see a project that is so trivial that it will succeed with unskilled people using a well defined process. Choosing the appropriate technology, creating an appropriate architecture and design are no trivial tasks. No process will ever make these task easier to do or more predictive. Only having the right people for the task will increase the chance of success. A process can help them, but never will replace them.

Focusing on code or focusing on processes are both wrong. Get good people on your team and focus on what really matter... What needs to be delivered! Focus on what is going to add value for the client/user. A working application will give more value than a well defined process. A process can help in achieving this as long as it's a mean but not an end.



It's NOT the code NOR the process, stupid! It's the right people focusing on the appropriate objectives!