Thursday, April 30, 2009

Big (D)esign conference

I signed up for the Big (D)esign conference that will be held May 30th at SMU. It looks like betwen this conference and the ones that I'm attending in June it's going to be a great next few months. First is this Big (D)esign conference then NFJS Dallas June 5-7, then Dallas Techfest June 19th in Frisco...

I've ready been to the Houston techfest this year so what other conferences can I attend in 2009 that don't break the bank?


Brian

Tuesday, April 28, 2009

I just read....

I was just reading Chris' blog about the right way and the wrong was to do things. We read many posts every day about the "best" way to write java, or the best way to use ORM or the best way to design a database schema. However, not all co-workers are always in agreement with anything that has the word "best" in the sentence.

Let me highlight a discussion that I had yesterday about a database schema design. (names have been changes to protect their stupidity).

Overview: I found that during the initial database design that I was not involved with some items was left out. For instance foreign keys, check constraints, First normal form, etc. (Small things...) <--- scarsam... During the meeting where I found that a table is not available to hold the attachments for some data since the data relates to another part of the application. I suggested that we create another table and tie in the FK back to the original table that this data will be attached. However, the conversation when a little like this... Person 1 = Boss Person 2 = project owner and BA Person 3 = business expert and technicial architect Person 4 = team member, (Java Programmer) Me = Me, team member, (Java programmer and 12 years experience in Database design) <Me> I'd like to add in this table and then relate it back to the master table with a FK
<Person 4> We don't need FK's since the application takes care of it.
<Me> We had this conversation before and we agreed that FK's are good for the relational integrity of the data. Are you saying that we should use the current table that relates to (this other table).
<Person 4> Yes, because why have another table to store the attachments?
<Me> Because of data integrity...
<Person 2> We could create the table that links the current attachment table to the master data table.
<Me> But we cannot enforce the integrity of the attachments that way because two link tables would be related to the attachment table.
<Person 4> (calls person 3 name) what to you think?
<Person 3> I don't know about databases so it's up to you.
<Me> So we are not going to worry about data integrity on this project?
<Person 4> The application will take care of it.
<Person 2> (referring to me), can you create the table like I showed and let the rest of the team know?
<Me> Are you sure?
<Person 2> Yes


Ok, I'm sure that someone will point out that maybe I caved in too soon. However, this is not the first time that I've had this conversation about database integrity with someone. Most of the time I do convence the other side that we should use the relational database (Oracle in this case) to manage the integrity of the data. Some of the checks can be in the application but it is my belief that the database should be the last line of defense for the data. If there is something that the database can make sure is related or helps to keep the data clean why not do it. In this case there is no concern about space differences. We are adding a table either way so why not do it where the database can make sure that the data from one table can relate to the other table.

I could go on and on about this but I'll start to ramble at some point if I haven't already. I guess my question is how do you convince people to use the best practices when it seems like they are not willing to accept suggestions to make current designs better?


Brian

Thursday, April 23, 2009

Comming this June!

It looks like June is going to be an incredible month in Dallas for Java. First we have the NFJS conference coming June 5th - 7th. Then just a few weeks later we have the Dallas TechFest conference on June 19th.

I'm counting the days!

Brian


Wednesday, April 22, 2009

Time for a Post

I've been thinking about what to post about for a while now. I have come up with an answer. Since I'm now heavily involved in JavaMUG.org and have attended several conferences about java related issues I think that it's about time that I start to post about Java? Hmmm sound good?

Ok keep looking here over the next few weeks and you will start to see posts about my idea of best practices for developing Java, Spring, IBatis, apps.

Brian

Friday, January 30, 2009

Dynamic PL/SQL and Bulk Collect

Today was the first time that I needed to use dynamic sql with BULK COLLECT. It was due to a distributed database system that used dblinks from a master reporting database. I programmed this on Oracle 10g but it should work on 9i or later.


declare

TYPE table1Type is TABLE OF table1%ROWTYPE
index by binary_integer;
v_results table1Type ;

begin
v_sql := 'SELECT *
FROM table1@' || v_dblink || '
WHERE mydate_dttm > sysdate - 1';

EXECUTE IMMEDIATE v_sql BULK COLLECT INTO v_results;
end;



That's it... This loaded all of the records into the v_results PL/SQL table and you can loop through the results like a array.



Saturday, January 24, 2009

Notes from Houston Techfest, Part 2

After lunch we had three more sessions.

Darin Marple
Topic: Using java to solve capacity issues


What can we do from a design perspective to identify or prevent capacity issues.

Transaction Model: Move transactions to as low of level as possible. Avoid two phase commits. Consolidate transactions at the db layer with stored procedures or DAO patterns.

Dependency Management: primary concern is dependency is not available at the time its needed Solutions caching dependency using any of the caching methods Workflow management: Provide alternative business path to using the data using possible older data.

Application Metrics:
Metrics via JMX: Monitoring with logging, JMX can publish metrics for mbeans

Persisting Metrics: Save metrics for analysis over time. Preferably to a database for persistence. Watch for extra load on database. Can output logs to file then batch load them into the database.

Validation: Load testing with LoadRunner: Validates application will work on a test system. Allows capture of true SLA and ability to tune and retest. Try to simulate real load as close as possible.

Deployment
Horizontal Scalability. Use JMS Distributed Batch. Use singleton at low level and workers at a higher level to pass information to the lower level.

---------------------------------
David Neal
Topic: Coding Considerations for Production Support: Instrumenting your code to reduce your support headaches

Carnegie Mellon University's Software Engineering Institute
Capacity Maturity Model

Avoid the standalone application mindset. Use useful error message. Dynamic adjusted diagnostic levels, Use progressive level of detail. If your using threading applications make sure that you include a key to be able to get the output back out of the logs for that one. Check log4j to output thread information. Log4j can also watch the logging level and if it changes in the properties it will update.

Aggregate the data from the method level to the caller level. Make sure that the context of the work is logged. If you return 100 records or 1M records put that in the logging so another user will know what the context of the results are.

Recoverable: Make sure the processing has the ability to recover preferably in stages especially for the larger jobs that need to be completed. Fuego is used for common recovery procedures.

JP Morgan uses a dashboard system to aggregate the data from the monitoring systems and that needs to demonstrate SLA. That also gives the ability to drill down into various problems.

--------------------------
John Teague
Topic: Principals of Object Oriented Design

Principals based on Robert's Martin's book.

High Cohesion and Low Coupling helps to make a solid OO design.

Makes code: Maintainable, Easier to test, Less resistant to change, reduce repetition, allows for continuous improvement, allows for agile development with vertical design.

If your going to mock it put an interface around it.






SOLID

Notes from Houston Techfest, Part 1

Notes from Houston Techfest:

Keynote Sang Shin from Sun Microsystems
Topic: Having fun in building Web applications with Ruby/JRuby/Rails

Notes: Not real instested in Ruby or JRuby. My Personal feelings is this is a fad language and will disappear the way of cobol in a few years. However, Sang gave a good presentation about the Ruby basics and how to get started doing web development. His web site http://www.javapassion.com/ looks like it has jump start guide. I just don't see this as mature a development framework as Spring or other DI design patterns.

--------------------------------------------
The next session that I attended was by Brian K Oxley from JP Morgan
http://binkley.blogspot.com/
Topic: Fluent Interfaces for testing in Java

Basically this shows how to add testing to Java code using code that look like english sentences. Proponent of static imports.

org.hamcrest.matchers testing library looks promising. Need to check into that library more.

Building fluent interfaces promotes the Builder Pattern to implement a testing interface for the code. So this creates an additional layer between the use case test and the code to be tested. This layer abstracts the test building so more syntactically correct English can be used to create the tests.


Even though I can understand the benefits for creating a more English like structure to create the tests it looks like with this additional layer of code that there is more code to test. What tests the test interface and what if the test interface is wrong or introduces a new bug that hides a bug in the code. This can happen in single level testing also but I'm not convinced that adding an additional layer to the testing will streamline code testing.

Brian also plugged Ron Coffin from Improving Enterprises


---------------------------------

William J Ferris
Topic: Topics in ava Concurrency

Recommended:
Brian Goetz, Java Concurrency in Practice
Herb Sutter, DDJ March 05: Free Lunch is Over

Why do we need to work on concurrency. Increasing need for threading because of multiple cores. Biggest threat to programming concurrency race condition when you expect one thread to finish first all the time or one thread accesses a object after another thread read it but before it writes to it. Other threats are deadlock and starvation. Deadlock is when two or more resources are waiting on resources. Starvation is when a thread cannot get cpu time.

To fix race condition: Concurrent Solutons
1. Elimination: Don't share the object if possible
2. Dynamic Exclusion: Use locks and barriers
3. Structural Exclusion: Code with immutable objects and confinement,isolate variables to specific threads

#2 Locks Intrinsic use synchronized keyword, Synchronized locks on getter and setters doesn't work!

Explicit locks java.util.concurrency.locks

Atomic new in java. Creates thread safe objects. Uses new methods to access the object.

Atomic best preforming, then explicit locks. Synchronized and fair share model are the slowest when more threads are added.

Maps are not thread safe, ConcurrentMap is threadsafe.




---------------------------------
Next was lunch -> See part 2....