Thoughts about Apple and iPad

A friend of mine and I were discussing the iPad virtually over coffee and tea and as the buzz discussion progressed (and I fell behind, quite the prolific author is Ted), I realized that I wanted to work it out so I could just get this all down as a blog post.  Not sure if it will really increase the readership of the debate any (1), but it just seemed better for a blog post then a buzz comment.

So the events that took place roughly follow the following:

I got a tweet that said, hey everyone read this (paraphrased to protect the innocent):


http://www.boingboing.net/2010/04/02/why-i-wont-buy-an-ipad-and-think-you-shouldnt-either.html

So I read that and enjoyed it and posted it to buzz.  I got a reply or two (which is really more than I ever get) so I found this all very engaging.

One of the comments said this:

actually, john gruber has a phenomenal response to this:

http://daringfireball.net/2010/04/kids_are_all_right

In response to the article.  It is an interesting read.  And I'm going to start with a huge digression before I continue (might even be in response to some other stuff that was written ;-)).  I have loved writing software since I got my Sinclair 1000 back in 1980 (or was it 79).  I loved it so much more than playing games on the Atari 2600.  As a matter fact I then got and programmed on the Commodore Vic 20, the plus 4, the 128, then started into the PC era with a 486 and have then bought or built several PCs since then.  You know what?  I never bought another gaming machine until the PS3 -- which I could install Linux on.  Now as it turns out that was really a farce because you can't access the graphics chip to any extent and now they are removing the support so they have now lost me as a customer.  Except that its still a great BluRay player oh and I can download games for it.  The game I play most?  Sudoku...

But back to the article.  There is no valid comparison between wanting to be able to install any software that you want on the computing device you just bought and and buying a car and not wanting to work on it.  There just isn't.  Its an invalid comparison.  Now I'm not talking about what I prefer here, I'm just pointing out the whole issue -- the whole comparison is based on a fallacy.  It's a trickery of words.  Just because the comparison was made and sounds reasonable, does not make it so.

Anyone making the argument is basically equating having to work on the car with the ability to do what you want with the device for which you just shelled out hundreds (thousands, etc.) of dollars.  They are not equal.  In fact, you can buy the car and choose to work on it yourself or chose to pay someone else to work on it.  You don't even have to take it to the dealership!  The comparison breaks down in so many ways.

If you were to really want to make the comparison valid, it would be that you couldn't go buy a cup holder and add it to the inside of your car.  Or replace the mats yourself.  Or go to your favorite car audio shop and have them install the coolest stereo that money can buy.  These are things that you simply would not accept from a car manufacturer but some how are being accepted by the iLoveApple community.

Okay I'm done with that one, but its really important that people do not read those comparisons and think that they are valid.

Okay next we get to another point that is really good, but just not valid.  And this is because the point it makes is so clean and "of course I want the world to be that way," and it is only upon further inspection that we realize that yes it should be that way and it has nothing to do with the freedom that we should have with our devices.

but i don't want all possibilities open. lets say there are 3 groups of tasks i break the computing world up into... group A are those tasks i want/need to do. group B are those i might want/need to do in the future. group C, which is by far the largest group, are things i don't care or want to do, ever. when i pick a device that is intentionally limited or constrained in some way, i ask myself in which of the groups of tasks do the limitations fit. the limitations cory pointed out are pretty much all group C, and this is the important point, to me.

So first lets just start with: you don't want to be able to put a media player on your device and use your own media library?  You don't want to be able to run software just because Apple says you can't because it competes with them or Steve's in a bad mood?  That really falls into category C?  Come on, you drank the cool aid and now you're just rationalizing :-). 

The real issue is you just want things to work.  And I get that.  When I write software I want it to work for everyone, perfectly, everytime, period, period.  But once again there is an illusion of words going on here.  Having things working perfectly is not at odds with having the freedom to work on your computer any way you see fit.  In fact in my case they go hand in hand.  My computer wouldn't work for me near as well if I didn't have the ability to put scripts on it that automate so many things that people spend countless hours doing.  So justifying that its okay for it not to be free because you don't want to work on it is just drinking the coolaid.  They are unrelated.  It is being preached to mask the control.  Don't buy into it!  Use their products all you want, but don't act like the comparison is between it working well and being locked in, or it not working well.  For one that is the arrogant trash that is being spewed [by we know who], and two its just ridiculous.

Next there was another really good point, but again it just doesn't really apply to freedom -- it applies to software in general and has nothing to do with freedom.  I must applaud the points because they are so true and so important to the computing industry today that they deserve praise and blogs about the points.  I just feel like they are great points that really do not pertain to whether consumers deserve to have some freedom on the devices we buy.

...with the ability to anything you want, comes the responsibility to maintain all of that. that responsibility is a HUGE chain to me, and thus a limit on my freedom to simply get done the tasks i need/want to get done.

So with the ability comes nothing but ability.  Ability doesn't imply any responsibility.  They are totally separate.  In fact, even if you use the ability to do lots of fun stuff to the computer and mess it all up,  you roll it back to the state that was good and you keep do the tasks you want / need to get done like nothing ever happened.  The ability to mess it up to learn more about it and then roll it back may even help you do what you need to or want to get done.  In fact, this has been the basis of research and learning for thousands of years has it not (minus the rollback part -- that is new to the last decade I think ;-)).

So in summary it is very important not to confuse freedom to use a computer with any potential issues that computers have today.  They just can't be equated, and shouldn't be equated, because the sheep will follow.  It is not correct to link the right and ability to be able to do something and the responsibility to have to do it -- that in fact is taking away the freedom is it not?  So everyone, use whatever platform you like.  But do not drink the coolaid if it is telling you that you should trade off freedom for things to just work.  Everything should just work.  And everything possible should be based on open standards so you are not locked in.  That is what we should be focused on and not how do we rationalize getting locked in to another vendor's product line.

Just by 59900 cents worth ;-)

How to provide settings to your applications part two

How to provide settings to your applications
part two
using your database

This is a second look at providing access to settings.  For the original please see http://gcruscoe.blogspot.com/2010/01/how-to-provide-settings-to-your-web.html

Overview
Please read the original article and then come back.  I'll wait, I promise.

Okay, great, glad you're back.  We are now going to supplement the previously described procedure to make the system more robust.  In order to do so we will need to look at what drawbacks there are to the method and how we can overcome them.  The description here is going to describe using a database for this approach although with a little imagination, we could come up with many different ways to get these settings.


Details
The rest of this article will focus on the setting up application servers, applications, and databases to handle settings that can change in different environments.  There are many aspects of this that will stay outside the scope of this article, like setting up the databases, proper naming conventions, etc.

So after our last look into property files, we have decided not to hard code the settings into the applications, and not to make a build specific to a particular environment.  But we still need all of the information in the application when it is built.  So what happens when a new environment is setup or an existing one changes?  This will require changing the properties files and redeploying the archive to all of the machines.  There has got to be a better way we must all be thinking right now.  And of course now we now that putting these settings in the database can offer us many benefits.  Most importantly all we need to do is change the settings in the database and the app will automatically get these new changes.  No deployment necessary.  It does has the drawback on requiring a database, but if the application already has that requirement then this is a non issue.  If it is an issue then there are plenty of other ways this can be handled.  A JNDI look up to an LDAP server, a web service call, etc.

For now we are going to focus on setting up our application to use the database.

Lets look at this in more detail...

Because you can setup a datasource at the container level, we have to question whether we even need the aforementioned, ServerEnv variable at all.  Each application server is setup to talk to a database in its environment (DEV, TEST, PROD, etc.) -- so why do we even need a setting?  You might not.  However there are situations where different types of servers may talk to the same database so in this case you will still need the ServerEnv variable.  We want the container to know what environment its in just in case.  The implementation of this is app/web server dependent but in general it will be something along the lines of edit the server.xml for your container or domain and add a system property ServerEnv pointing to the appropriate Environment.

e.g.
<jvm-options>-DServerEnv=DEV</jvm-options>

Okay now that that's set (and the app server is restarted), what else do we need?  We need a way to talk to the database -- again this is out of scope but we are going to assume there is a datasource setup for the app server and our application will be able to talk to it without knowing where it came from (this is of course a very common and highly recommended way to set up a system).

So our application needs at least one piece of information to be deployed with it -- the application name.  You can expand on what information is required as needed for security but we'll keep it simple here.  So the application will have a small property file that will contain its name and for fun you may want to add a version number.

When the application wants to get its settings, it will get them from the database that is linked up with the (or one of the) data source(s).  Okay so then the application gets all the properties using the getProperties(filter) library command that is included in every new application.  This only needs to be written once and everyone gets to benefit. 

What goes into the filter?

• app name
• version
• environment

So the database has everything it needs to find properties.  Of course it can be normalized or just a string concated together, but the idea is that each key contains

appname.version.environment.propertyname = value

and you get all the properties from the database and then in the application you have your hashmap of just

propertyname = value

So now the archive can be deployed anywhere -- even in environments that were not thought of when the application was made.  All that is necessary is to create the appropriate settings in the database for each application.


Summary
So in summary, the ServerEnv needs to be in every server so that each server can fine tune what information it needs from the database.  The application only needs to know its name and version.  One build can go to any environment, even if it doesn't exist yet.  Each database connection is setup for the app server so the app doesn't even need to know about that.


Happy Coding!

How to provide settings to your web a...

How to provide settings to your web applications

Overview
An app shouldn't need to know what environment its going to be deployed into, however the maker of the app should know about the resources that are going to be required.  So there are [at least] two good ways to do this.  Store all the settings for an application in the database and then the only thing that is required is the database configuration for each environment -- which is usually handled by the container.  Or you can have all of these settings in in property files with an extension that indicates which environment (DEV, PRD, etc.) that the setting is for.

The down side to the database is that anyone can change a setting that they think is only for their app and it will change all of the apps that are using it.  The downside of having the settings in a property file for each app is if the resource does need to change it requires the change to be made in all of the applications.  It is similar to the battle between deploying dependent libs where they are accessible to everyone all at once or deploying the dependent libraries with each application.


Details
The rest of this article will focus on the later approach.

So we have decided that we want all of the settings in property files.  And we want each container to know what environment it is in.  Then we will have a library that will pull the correct setting for the property depending on the environment.  This library will be reused between all applications as part of the common framework.

Lets look at this in more detail...

We want the container to know what environment its in.  The implementation of this is app/web server dependent but in general it will be something along the lines of edit the server.xml for your container or domain and add a system property ServerEnv pointing to the appropriate Environment.

e.g.
<jvm-options>-DServerEnv=DEV</jvm-options>

Okay now that that's set (and the app server is restarted), we need to create our newly styled property file.  Oh but what does that look like?

Create a file myApp.properties and it would contain this:

# First we have LCL (Local)
theOtherServerLCL=192.168.1.1
theUserIdLCL=dev_user

# Now for DEV (Dev :-))
theOtherServerDEV=192.168.1.1
theUserIdDEV=dev_user

# Now for FT1 (Test)
theOtherServerFT1=16.32.64.128
theUserIdFT1=test_user

# Now for PRD (Production)
theOtherServerPRD=10.20.40.80
theUserIdPRD=prod_user

Now for more information about the available environments.  This really depends on the system architecture for the application or department but probably something like this:

LCL, DEV, FT1, FT2, TRN, PRD

Note that local (LCL) should probably have the same settings as DEV, but we can do additional optimizations like not combining resources so the build time is less, but by the time it goes to DEV it is the integrated build.  We'll talk more about those another time.

Next is the important decision of how to split up property files, but we'll also leave this for a different post.


Summary
So in summary, the ServerEnv needs to be in every server so that each server can indicate to the applications what environment it's in.  Each application should include all of the settings that it will need for all environments stored in its property files.  One build can go to any environment, and each environment doesn't need to know about all the possible configuration settings needed for the applications.


Happy Coding!