Vaughn Bullard

All things that keep my interest

Category Archives: Technical

Added a new Sharing Feature

September 28th, 2009

OK,

So I was looking for a simple way to add a sharing capability without minimal coding, stuff like that. So I found a service called ShareThis. The steps for the publisher were pretty easy to do. It took me all of five minutes to create a publisher’s account, grab the WordPress plugin and install, configure and enter the code snippet. I would highly recommend ShareThis.

Now at the footer of every blog post, one will see a ShareThis icon. One can click it and then a popup will appear giving the reader many options to share that post.

:Vaughn

Tags: Feature, popup, icon, click, reader

Tuning MySQL – modifying optimizer_search_depth

December 28th, 2008

OK,

Since I am no MySQL master, I took a while to figure out how to modify the optimizer_search_depth for a running MySQL instance. I am running Ubuntu 8.x Server on my box. The reason I needed to do modify the optimizer_search_depth is that I didn’t want to do long drawn out searches across my database from my applications. So I read up on this variable called optimizer_search_depth. Finding in-depth documentation on it was not easy. I am however documenting here for my and others’ future reference.

To modify the optimizer_search_depth, you need to modify the /etc/mysql/my.cnf file. This is the main MySQL configuration file. It doesn’t matter where you put it, just that it isn’t commented out. The default installation on Ubuntu seems to be 62 for optimizer_search_depth. I tuned it down to 4. It runs incredibly fast compared to before. If the variable isn’t there already-which in the my.cnf on Ubuntu is not, just insert in the typical name/value pair association like so: optimizer_search_depth = 10 . Restart your MySQL server and/or box and the config should take just fine. To check type in the command ‘mysqladmin variables’ and check for ‘optimizer_search_depth’.

:Vaughn

Tags: config, Vaughn Tuning, default installation, command, variables, depth, file, check

ResourceBundles, Preferences API or JNDI references

December 20th, 2008

OK,

So I was recently on a project where deployment of the database connection information became a concern because they were in properties and loaded by a ResourceBundle. There’s no one reason I could find to use one over the other and I think at this point time, strictly a design time decision. Obviously certain things will be deprecated over time, but below I provide sort of a pros and cons for each component.

ResourceBundles
Pros:

  • lightweight file readers
  • More of use when a lot of localization must occur for one’s application – extremely useful when the programmer has more control of the application and its deployment.
  • Useful for backporting to previous JDKs
  • Programmer has a lot more control
  • Maintenance of code-drop once to the customer, provided no settings change between drops, the customer does not have to modify the properties files

Cons:

  • If deploying there tends to be issues on where the properties file can exist, how the class loader loads those files for usage in code, how the systems administrator modifies those files in case of changes, etc.
  • Properties files can become corrupted. Question becomes “How does one maintain that persistence store so it does not become corrupted?”
  • Properties files do not scale well at all.
  • Properties files are strictly name/value string pairs and provide no capability to datatype them

JNDI API
Pros:

  • Easier to develop to
  • Easier to maintain from a systems administration point of view
  • Harder for the programmer to programmatically modify the settings from the application perspective.
  • Useful for backporting applications to previous JDKs

Cons:

  • Heavyweight – very large consisting of 5 packages and 83 classes.
  • Provides no policy as to where in directory name space the preference data should be stored, or in which name space

Preferences API
Pros:

  • Back-end Neutral
  • Policy and Data Driven
  • Provides “atomic-like” updates to preferences
  • Is the API that will be used in future JDKs from 1.4 on
  • Has a backing store capability in case of failures

Cons:

  • Is not a substitute for database, for like guarantees of transactional capabilities
  • Is not backward compatible to JDKs to JDKs under 1.4 but then again if you’re using 1.4 you’ve already got one foot in the tar pit.

While it’s simply a comparison, it really boils down to how the application is controlled, deployed and maintained. There is no one way better than the other that I can see other than the potential deprecation issues of the old APIs in the future. I’d definitely be interested in seeing what other developers and architects are doing. Just because it’s old doesn’t mean it isn’t a useful or even better API.

:Vaughn

Tags: application, loader, information, time, Useful, concern

I’m Back…

December 18th, 2008

Ok, after much debate over where I’ve been, I can finally say I’m back from my hole. I’ve been focusing on building business to business partnerships with my federal consulting division and eCocoMarket.Com. While there doesn’t appear to be a lot going on with eCocoMarket.Com, there actually are a bunch of things going on behind the scenes. At the appropriate time, eCocoMarket will be re-launched with some brand new features and some things that just might amaze the general public. It will be killer! As far as eCocoModo Federal Consulting, we are doing some really killer SOA work. I’m very busy with these ventures but I promise to update the blog once a week at least.

:Vaughn

Tags: Business, brand, division, bunch, killer, week, building, building business, lot, work

Problems importing to Subversion

December 18th, 2008

Ever got this “svn: No such revision ” error? Well I recently got this error on a NetBeans-based IDE project I was doing. Had to completely blow away a module in Subversion. This was because I had to do a complete package restructure of the application.

When I created a new module, I then tried to import the NetBeans project from a folder I had backed up. Well, the problem is that Subversion has its configuration in .svn directories throughout each repository module. So it imported fine to the module with a different SVN client.

The problem is that when I tried to check it out, I got “svn: No such revision 12″-with 12 being the latest module revision I was trying to check out. I solved it by deleting all the .svn directories in my module directories and subdirectories. I then imported the module backup folder into the Subversion module. Checked it out using NetBeans and was completely squared away.

Tags: folder, problem, Checked, NetBeans, project