Friday, April 01, 2005

Feb 11--Apr 01

  • Implemented class library and server.

posted by Greg @ 12:56 PM 3 comments

Friday, February 11, 2005

2.11.2005: 1:00pm--4:00pm

  • Met with team, discussed many issues:
    • Got down to detail level of the system components.
    • Defined user experience flow diagrams in Visio.
    • Wrote out pseudo-code for much of the client code.
    • Begin laying out the class library and the various DataObjects.
  • Returned James's notebook.
  • Returned Jon's pen.

posted by Greg @ 3:05 PM 0 comments

2.9.2005: 5:00pm--7:00pm

  • Met with team and discussed this and next week's work.
  • Figured out the whole DataObject system with Peter.
  • Stole James's notebook.
  • Stole Jon's pen.

posted by Greg @ 3:03 PM 0 comments

Saturday, February 05, 2005

2.5.2005: 12:00pm--3:45pm

  • Went through some tutorials and refreshed memory on JDBC.
  • Read about Java RMI, this will probably be the best technology to use for our network component.
    • Easy to pass serializable objects.
    • Easy to make objects serializable.
    • Easy to implement; much simpler than using straight sockets, but we might want to still do that due to the next point...
    • Only drawback is the very complex security structure.
      • It took me almost two hours to get a simple example to run due to all the security configuration.
      • There is still a lot to figure out here.
    • Overall, I have a pretty good idea on how to go about implementing our network component using RMI.
  • Thought some more about the extensible class library stuff, this is what I think we should do (I haven't tinkered with this yet, but when I get a database installed I will).
    • Have everything in the class library implement an abstract class or interface called DataObject.
    • All DataObjects must expose static methods that will be used by the server in interacting with the database.
    • For example, a class Person would have:
      • A static method GetAll which takes a JDBC Connection object and returns an ArrayList of all Persons in the database associated with the connection.
      • A static method Insert which takes a JDBC Connection object and a Person object and inserts that Person into the database associated with the connection.
      • A static method Update which takes a JDBC Connection object and a Person object and updates that Person in the database associated with the connection.
      • A static method Delete which takes a JDBC Connection object and a Person object and deletes that Person from the database associated with the connection.
    • Furthermore, we could define a class Filter which could be used to create filters when retrieving data, and the objects' GetAll method could take it as an argument and construct the appropriate SQL query (WHERE clause).

posted by Greg @ 2:33 PM 0 comments

Friday, February 04, 2005

2.4.2005: Meeting Day

  • Met with team, laid out the general package namespace structure.
    • I will take what we have and formalize it into a document that all can refer to during implementation.
  • Each of us will go educate ourselves this weekend on our respective areas:
    • I will start playing with Eclipse.
    • I will set up a CVS depository for us and look into using Eclipse with CVS.
    • I will explore my ideas for setting up the class library and server/database code in a very extensible way.
      • Basically, my idea is to have all objects in the class library implement an abstract class called DataObject, which has certain fields and methods that will make it possible for the server to populate objects from the database and update the database from an object in a uniform manner, so that the server code doesn't have to be updated every time the class library is updated.
      • I will need to look into standard practices for using databases with java.
    • I will also start to play around with the networking component of the system.
      • I will learn about serializing objects and sending them over TCP/IP.
    • Finally, I will look at creating a general method for saving project data to a file that the client applications can exploit (again, the client apps should be ignorant to how this is actually done).
      • I am thinking that every DataObject will also have a SaveToFile method that will exploit the object serialization (which will already be present for the networking stuff) in order to save to a binary file. Then to save a project, the client application can just call its SaveToFile method, and that will in turn recursively call its fields' SaveToFile methods to save everything.
  • Met with upper management (haven't actually gone yet, but I assume there won't be any problems to write about).

posted by Greg @ 1:51 PM 1 comments

Monday, January 31, 2005

1.31.2005: 7:30pm--8:45pm

  • Missed a team meeting today due to work.
  • Went over what was discussed via teammates' blogs.
  • I will work on the sections of the SDS assigned to me on James's blog and have them done by Thursday night.
  • Read up on Java XML serialization and weighed the options of using an existing webservice server (such as AXIS) or developing our own light-weight, TCP/IP + HTTP + XML server.
    • Peter has pointed out the simplicity of the latter option.
    • Also, given that all of our system will be implemented in Java (at least for this go 'round), it may be beneficial to implement our own server as per Peter's original vision, instead of including a large web-server with the system (which may be overkill and may interfere with a customer's existing web server).
    • Finally, I think it will be very possible to keep platform independence as a possibility if we utilize XML serialization and are careful in the design of the network layer.

posted by Greg @ 7:47 PM 0 comments

1.29.2005: 3:00pm--6:30pm

  • Met with team and discussed many issues related with the overall system design.
  • Hammered out a high level specification to be formalized in the SDS document.
  • Considered many issues related to how the user will interact with the product and how the backend system will be organized.
  • We kept extensibility, scalability, and simplicity at the forefront of all discussion. I think this will be very important.

posted by Greg @ 7:43 PM 0 comments

1.28.2005: 1:00pm--3:15pm

  • Met with team to discuss various issues with the product, including:
    • Synchronization
    • Project organization and ownership
  • Met with "upper management," everything seems to be in order.

posted by Greg @ 7:41 PM 0 comments

Tuesday, January 25, 2005

5:30pm--8:30pm Project plan meeting

  • Discussed overall system design.
  • Decided the system would be divided into two basic components, server and client:
    • Server:
      • Solely interacts with database server (probably running on same machine).
      • Hosts an XML web-service which provides the following basic services:
        • Retrieve a project from database, send it to client.
        • Retrieve a project from the client, update the database.
        • Create new project.
        • Generate reports, return the URL.
    • Client:
      • PC:
        • Get project data from server.
        • Provide user interface.
      • PocketPC:
        • Get project data from server.
        • Provide user interface.
  • I will read more about Jasper reports and XML web-services hosted by an Apache/Java framework, since those are going to be my main areas of development.

posted by Greg @ 7:28 PM 0 comments

Thursday, January 20, 2005

9:00pm--9:20pm: Bid 1 Proof-reading

  • made minor grammatical corrections and clarifications to the bid 1 documents, most importantly adding the "total" column to the team vote page.
  • submitted to james.

posted by Greg @ 8:21 PM 0 comments