Can't connect to MySQL from remote computer

I recently started using Uniform Server, a WAMP package, for creating a database for my test team.  I really like the convenience and ease of use of this package.  For example, port changes for Apache can be made from the Uniform Server dashboard application, rather than having to hand-edit configuration files.  But Uniform Server is meant for local development and by default, remote connections are not accepted.  For example, attempting a connection using the MySQL JDBC driver, remote users will get a "Connection refused" error.

To fix this, using the dashboard application, "Stop MySQL".  Then run the "MySQL Console".  From its command-line, run "mysqld1".  This starts up MySQL without the "--skip-networking" parameter and thus allows remote connections. 

Notes on "What is Hadoop? Other big data terms like MapReduce? Cloudera's CEO talks" video

• Map reduce - spread processing of data over many computers so data can be processed in parallel with cheaper hardware.  No transactions or schema.  Aimed more at analysis (Reads) rather than full CRUD?
• Relational databases not good for unstructured free text  
• Hadoop - open source, consists of (1) distributed file system to spread out data (HDFS), (2) way to push code down to do data analysis on the data 
• Scalable because can just drop in more servers 
• Memcached - in memory cache of relational database, push through writes "incrementally"? 
• NoSQL - distributed hash tables
• Sharding (not discussed in video) - taking rows of a relational table and distributing across computers

Altova MapForce review and tips

Altova MapForce is an interesting tool for creating XSL transformations visually.  Looking past the obvious drag-and-drop nature of the tool, here's my review:

What I liked:

• Promotes the creation of libraries of re-usable functions.  
• Flexible:  Can swap in another XSD without losing mappings, by editing MFD file directly.  The invalid mappings will be highlighted in red for correction

What I disliked:

• Generated XSL is not meant to be tweaked, and it would be very difficult to do so
• No built-in debugging facilities
• No support for non-function-based facilities (e.g. xsl:analyze-string)

Hard to say whether good or bad:

• Everything that is re-usable is function-based, that is, consisting of input (optionally) and an output.  It reminds me of Lisp programming.   

 Tips:

• do not copy and paste functions between MFD files using text editor
• make higher-level functions if find repeating mapping
• If parsing the text of a node which has embedded tags (e.g. <addr>PO Box 123<delimiter />c/o Dave<postalCode>90210</postalCode></addr>), in this case, addr and delimiter, respectively, use the MapForce distinct-values function

The container 'Maven Dependencies' references non existing library

If you copy an Eclipse-Maven project from one computer to another, you may get a Build Path Problem resembling:  "The container 'Maven Dependencies' references non existing library 'XXXXXXXXXXXX'".  This is obviously due to a difference in the location of the local Maven repository from one computer to the other. 

To fix this, right-click on the project > Maven > Disable Dependency Management.  Once Eclipse has finished rebuilding the project, right-click on the project > Maven > Enable Dependency Management.  This error should now be gone.  

Maven error "Cannot find wagon which supports the requested protocol: ftp" and Hudson

It is important to understand that Hudson comes bundled with Maven but you can also configure Hudson to use an external installation of Maven (Manage Hudson > Configure System > Maven 3 section).  When you add a Maven build step to your Job, you have the option to use the bundled Maven or your external installation.  However, the default is the bundled Maven. 

This can cause problems if you need additional classes required by your Maven plugins that are not automatically downloaded, e.g. FTP support for the Deploy Plugin or Wagon Plugin (http://mojo.codehaus.org/wagon-maven-plugin/).  That is, if you have dropped the required JAR into the "lib" sub-folder of your external Maven installation but the Job is configured to use the bundled Maven, you will continue to get "Cannot find wagon which supports the requested protocol: ftp" (in this case).

Key to OO design

I use to agonize how to organize code into classes, that is, how granular to make classes, should this class know how to entirely do X operation, what variables to expose and how to expose them, try to see how various class design patterns might fit (or not). 

In the last 3 years, class design has suddenly become a lot easier by focusing on test-driven design, how to make sure my classes can be tested in unit tests.  Everyone wants a well-designed class with well-designed methods to consume, and a well-designed class is also easier to test and verify as working properly.  But does a class that is designed with being testable in mind make for a well-designed class?  In my experience, strikingly yes.

If so, what supports test-driven design?  Dependency injection like implemented by the Spring framework supports test-driven design because together with interface-focused design, mock implementations can be substituted for real implementations in unit tests.  This alternative way of looking at how to "compose" together classes to do something useful has revolutionized my class design habits, buried bad practices and further made me a believer in test-driven design/development.  In general, I still don't write automated test cases first but I do sometimes (a third of the time?) begin with them now.

Converting legacy Java project to Mavenized project

For the majority of Eclipse-based projects, the most time-consuming part of converting to Maven is (a) determining which JAR files are actually used (compile and run-time), (b) determining their Maven GAV coordinates, (c) hosting the JAR files that are not stored in any public repositories.  Here are the steps I am currently following:

1. Some currently included JAR files may not actually be used.  These steps weed out those extraneous JAR files
2. From the existing files in the lib directory, determine which of them are actually needed by eyeballing.  You should have a pretty good idea of the major dependencies (e.g. core Spring, web service libraries).  Add these dependencies to POM; get GAV coordinates using something like determine-maven-dependencies-tool, a custom Groovy script I wrote that is now on Google Code
3. What are remaining compilation errors?  Look for the specific JARs in which missing classes live, using a tool like JarScan). Add these dependencies
4. What to do about JARs that are not found in publicly available Maven repositories?  
1. If found in non-standard repository, add repository to your Nexus server
2. If not found in any repository, upload JAR to your own Nexus server.  
1. Is it one already in your Nexus repository?  Verify by calculating sha1 hash of JAR contents:  File Checksum Integrity Verifier utility
2. What GAV coordinates to use for these unique JARs?  This is a question I am still seeking convention/guidance on.