Premise
In this entry, I'll describe my experience in installing, configuring and applying of both database management systems, including Apache Derby and Oracle (SleepyCat) Berkeley DB.
Background Info
Derby
Derby is one of Apache's many successful entities known in the community of Java developers. It is a Java-based, embedded, JDBC driven SQL database. It also includes a client and Network Database server for client/server implementations.
Berkeley DB (BDB)
SleepyCat's Berkeley DB is Oracle's attempt at a fully embedded non-SQL database, including no ad hoc queries, but many quick indexing remedies for querying records. It's targeted for application environments that want to quickly implement an object-relational database management system with very little footprint and less dependent on DB administration. It has everything that you would expect of a database system and promises optimal solutions to retrieval and transactional operations.
Installation & Configuration
*Both platforms require some form of JRE ~v1.5 or above.
Derby
The retrieval and installation process of Derby was easy, simply download the tar/zip file, extract it to the location you want, then update your environment variables to include DERBY_HOME, and add a path to the executables (DERBY_HOME/bin). more
BDB
The download and installation process of BDB wasn't difficult either. It only required an additional environment variable (JE_HOME) pointing to the path of the downloaded package. more
Comparison
Derby
Derby provides an internal interactive SQL scripting tool, called 'ij' used to connect to an existing database, or create a new database. Coding in Derby is very SQL scripting heavy and it requires a planned out schema. Loading and connecting to Derby DB is simple, you just load the appropriate embedded or client driver (depending on your application). You can also pass ad hoc queries, basic SQL statements for creating, updating, or deleting (all fundamental CRUD). Derby is a great RDBMS for settings that require ad hoc queries, and for optimal access to SQL databases.
BDB
BDB is a whole different approach, in that it implements a Java DB without the need of SQL. This object-relational database approach offers more direct interactions of object based models. Actually BDB is stored by object values, rather than by traditional object reference which models similar benefits from EJB persistance APIs. Programming in BDB is quite intuitive and requires that you have strong knowledge in manipulating Java objects via understanding of Java APIs, especially with the Java Collections framework (since this applies to 'Cursor ' iterations through records stored in BDB). I have to agree, in theory with BDB's storage and indexing approach, since it does provide a low cache way of retrieving raw data and instantiating objects seem seamless. I wonder how BDB memory caching features perform once it goes against more storage data input. If I do decide to use BDB, I hope that I won't need to roll out my own solution for tuning the cache. Of course, this over bloating of memory depends solely with the complexity of the application and my usage of BDB. After coding a little in BDB, I also noticed some similarities to Hibernate since they have similar implementations using EJB and Java's Persistence APIs. Although BDB isn't a standard with most developers, since its approach to an embedded database requires no SQL seems unorthodox; I feel that its structural aspect and its targeted purpose of increasing performance in object relational coding feels much more natural.
The Verdict
At this point in time, I'm falling towards using BDB since the solution is quite simple and unobtrusive to the network environment setting. It will require less configuration on the administrative side, yet it gives more control over the configuration directly through the application itself. The other reason is that the class file structure is already in good standing for a BDB implementation. There will be no need for creating a client driver connection or bringing up a Network Server, as I previously planned on doing by using Derby.
The 'Vision' Document (unofficial)
The vision hasn't changed much since my first entry about Devcathlon. We are still pushing for a workable application that can be used by developers as an interactive assessment tool to better software project environments. At the moment no changes have been made to the current code base, rather more planning and testing have occured locally for assurance. Right now, deciding on a preferable DB is the question at hand. Considering my research and tests, I would recomend using BDB as a possible DB implementation for Devcathlon. The DB implementation is pretty much a way of incorporating a persistent back-end for Devcathlon. I've yet to apply any specifics on future improvements, but I feel the need to get most of the targeted functions to work first in Devcathlon v1.0.
Plans
I'll need some time to develop a 'spike solution' of BDB with our current implementation of Devcathlon. This shouldn't be difficult considering that most of our models built in Wicket for Devcathlon are neatly separate object entities, so it makes for a perfect setting for using BDB.
I'll also be revising my vision document, since little has been put into making this a 'viral' record.
Also, since I'll be revising the application many times over, the use of a review (summary) at this time will not be committed until after a DB solution for Devcathlon is released.
*Notes on development environment: Since the project code base is housed via Google's Project Host, I've decided that we should create a branch for our DB solution. In addition to our branch, we should have a live development box that mimicks a production environment for shared consistency and remote testing.
Thursday, May 21, 2009
[GSoC09-Devcathlon] Tentative Plans
Welcome to GSoC
Hello, GSoC!
I'm glad to announce my induction to Google's 2009 Summer of Code. This is a belated entry about my pre-dated acceptance back in April. I've yet to talk much about it, but it's never too late. This series will be targeted for people interested in the progress of Devcathlon and my personal experiences along the way. Each title in this series will be prefixed with "[GSoC09...]" as a convenient indication to you, myself and to my fellow, GSoC mentors. In this entry I'll refresh about the project Devcathlon and outline my plans for this summer.
About Devcathlon
Devcathlon is a web application to help better software engineering practices and to assist in improving project management settings. Devcathlon was a three month project started by 8 students and 1 professor from the University of Hawaii at Manoa. This project is intended to simulate a software engineering environment along with the benefits of a game. If you're looking for a place to compete with other software development teams, or to see where you stand as a developer, then Devcathlon is the place to be. The motivation behind this project was spawned from the possibility of creating a fun and easy to use game, targeted towards software developers who feel the need for a competitive edge or want to be recognized by their community of peers. Besides having to see where you rank amongst your colleagues, this application also looks to help improve the ethics and recommended practices of an ideal software development environment. Devcathlon encourages continuous development procedures that should come second nature to most developers, such as commit early and often, separate but equal ownership, and test before you drive.
Below are my summer plans and related responsibilities for this year's GSoC.
Summer outline
1. Fix any discrepancies on the Devcathlon v1.0 release.
2. Design Database schema
Hello, GSoC!
I'm glad to announce my induction to Google's 2009 Summer of Code. This is a belated entry about my pre-dated acceptance back in April. I've yet to talk much about it, but it's never too late. This series will be targeted for people interested in the progress of Devcathlon and my personal experiences along the way. Each title in this series will be prefixed with "[GSoC09...]" as a convenient indication to you, myself and to my fellow, GSoC mentors. In this entry I'll refresh about the project Devcathlon and outline my plans for this summer.
About Devcathlon
Devcathlon is a web application to help better software engineering practices and to assist in improving project management settings. Devcathlon was a three month project started by 8 students and 1 professor from the University of Hawaii at Manoa. This project is intended to simulate a software engineering environment along with the benefits of a game. If you're looking for a place to compete with other software development teams, or to see where you stand as a developer, then Devcathlon is the place to be. The motivation behind this project was spawned from the possibility of creating a fun and easy to use game, targeted towards software developers who feel the need for a competitive edge or want to be recognized by their community of peers. Besides having to see where you rank amongst your colleagues, this application also looks to help improve the ethics and recommended practices of an ideal software development environment. Devcathlon encourages continuous development procedures that should come second nature to most developers, such as commit early and often, separate but equal ownership, and test before you drive.
Below are my summer plans and related responsibilities for this year's GSoC.
Summer outline
1. Fix any discrepancies on the Devcathlon v1.0 release.
2. Design Database schema
- Build relational model using a DBMS (MySQL, SQL Server, or the critically acclaimed Apache's Derby)
- Integrate Wicket with Spring's application framework and Java-based persistent object-relational model framework, called Hibernate. Apply questions about using such a framework, like What is AOP? DAO? DI & IoC? How does applying a multi-tiered or layered application benefit from traditional coding styles in its robustness, simplicity, etc.?
Friday, May 15, 2009
[ICS 499] It's Only the Beginning
This semester was surely an exciting roller coaster ride full of many bent turns, unexpected loops, and some worthwhile air time. The goal of this project was to gain minimal insight into electronic health record systems (EHR), and to explore the possibilities of developing an open source component to enable greater extensibility and interoperability for development platforms. It turned out that a big competitor in the medical health record industry, Medsphere had developed just that tool for creating a Java-based linker solution, called OVID (OpenVistA Interface Domain). The OVID project is still very young, yet they've pushed through great lengths recently to have it on a fully open repository. Medsphere also released a front-end patient record dashboard along with OVID, which was built using OpenLaszlo, called lzVistA. After realizing the potential of building such a dynamic front-end GUI using such expressive component based and XML driven-development of RIA's, I started looking for alternative RIA's that could help shape my own patient dashboard. This began the exploration of finding the right RIA that I'm most comfortable with. After giving OpenLaszlo a try, I thought to myself, "Yes, I'm impressed." Then I realized the hassle of not having a dedicated IDE for editing and building OpenLaszlo applications. This led me back to the road, where I would eventually reunite with my all time favorite Flash platform. It's been a long time since the Macromedia days, and Adobe's done a great job in marketing the trend of Flash now being used on practically every browser. Adobe is also well caught up with the open source community, since they recently released a full open source version of their XML/MXML development language kit, called Flex. Flex serves as an innovative way of producing web-based applications in a much more rich and multi-platform environment. In my recent discoveries, I mentioned that Flex provides many different ways to capture and retrieve data via data services, such as web services, HTTP and remote objects (including server-based Java objects). Flex is also accompanied by an IDE built on Eclipse, called Flex Builder. This makes for an easy migration, since I'm able to switch between developing environments with ease.
It's interesting as to how large the scope of the project has become since the introduction of OVID. I'm now hoping to build a web-based EHR client using Flex and Java's back-end server connection to OpenVistA via OVID. I'm glad to say that this has been a progressive project, including the immense time spent on getting used to Flex's component-based development, and refreshing my skills in the new ActionScript v3.0. The experience was well worth it, but I've yet to close this road permanently. I'm simply putting this project on hold in promises that I'll be able to continue down this path with more added time and consistency. I'm still actively supportive in the project and I've taken the necessary steps in order to keep up-to-date. Since OVID isn't a perfected system yet, I hope to give my helping hands on their development team. This would mean that MUMPS is back to haunt me again, but at least I'll have Java to accompany me along the way. As far as this semester goes, I'm probably more satisfied with what I've learned rather than what I've produced. Along with understanding how to self-manage myself, I've also learned to become more engaging as a programmer. This has opened me up to the possibilities of how many things still need to be invented, or needs improvement in this world. I'm thrilled to know that I'm stuck somewhere in between having thought of something with the right resources to do it, and realizing the proximity of a real-life product.
It's interesting as to how large the scope of the project has become since the introduction of OVID. I'm now hoping to build a web-based EHR client using Flex and Java's back-end server connection to OpenVistA via OVID. I'm glad to say that this has been a progressive project, including the immense time spent on getting used to Flex's component-based development, and refreshing my skills in the new ActionScript v3.0. The experience was well worth it, but I've yet to close this road permanently. I'm simply putting this project on hold in promises that I'll be able to continue down this path with more added time and consistency. I'm still actively supportive in the project and I've taken the necessary steps in order to keep up-to-date. Since OVID isn't a perfected system yet, I hope to give my helping hands on their development team. This would mean that MUMPS is back to haunt me again, but at least I'll have Java to accompany me along the way. As far as this semester goes, I'm probably more satisfied with what I've learned rather than what I've produced. Along with understanding how to self-manage myself, I've also learned to become more engaging as a programmer. This has opened me up to the possibilities of how many things still need to be invented, or needs improvement in this world. I'm thrilled to know that I'm stuck somewhere in between having thought of something with the right resources to do it, and realizing the proximity of a real-life product.
Sunday, May 10, 2009
Devcathlon Evaluation
Premise:
Devcathlon has been a three month project intended to simulate a software engineering environment in hopes to improve development team practices, and to promote overall project health. In this entry, I'll evaluate the application through my personal perspective as a developer, along with the evaluations of outside testers. I'll also mention about my experiences in building this project, and the future of this application.
A programmer's perspective:
The journey through markup...
Most of my development time was spent on building the profile section of Devcathlon. It wasn't difficult, but there's still room for lots of improvement. I kept this first version of Devcathlon's profile page simple, in order to focus on the teams, matches and scoreboard pages. Devcathlon underwent through many physical and functional changes since its first conceptual designs. We started out with basic HTML mock-ups which looked and felt very web 2.0-ish; considering that it had some Javascript, some signs of pagination and an array of CSS layouts. By separating ourselves into three separate teams of three, we were able to generate some very inspirational designs and structures that would eventually be inherited into the "final" product. Although some design elements were put away as future enhancements, due to being labeled as aesthetic gains rather than functional gains, we did provide, in this version, an intuitive, yet simple user experience. The gains of taking this conservative approach would rather benefit ourselves in the long-run, since we built a strong foundation of our application and left plenty of room for advance UI's to take place later. Of course, we've only scratch the surface of Wicket's abilities to render some "pretty," and dynamic markup, but I'll see to it in our future implementation that we have an eye-candy application. At this point, I'm very pleased with what we have, as far as the look and feel goes. The application has a conformed look and layout; we made good use of our CSS to standardize our information in reusable "panels," and we also preserved colors and fonts similar to Hackystat's UI. I'm willing to put energy during this summer to make improvements in this area by incorporating more AJAX-y alternatives to necessary parts of the web application.
Functionality in design...
Below is a list of my likes and dislikes, and some possible way of improving each portion of the web application. I'll also mention the difficulties and challenges in making these sections possible.
Front page review:
The front page contains a basic login and password form, along with a preview version of our scoreboard. Although, this idea of putting the scoreboard on the front page came late in the game, we found it useful to help advertise the current status of our application with regards to providing evidence of user traffic and ratings. The front-page version of the scoreboard is not all that different from the actual scoreboard, except that some links are not featured unless you have logged in with an account. The gray panels and use of reusable components makes the composition of this page very useful in context, by providing information on match events, teams events and individual player's scoring. A future improvement would be to provide a live scoring data provider that would emulate statistics on the fly through 5 minute increments or whenever it spots a new change in the system. This would be beneficial by reducing the number of whole-page refreshes and enhancing the user experience by providing a persistent way of retrieving data.
Profile page review:
The profile page went through minimal amounts of change due to its limited usages other than finding out more about the player participating in the game. Although, the profile page makes for very little use, I've come to find that there are many ways of approaching this section. I looked around on mostly social networking sites, including TechHui, Facebook and Twitter to gain some inspiration and possible commonalities. I narrowed down some details of a user profile to only include, the user's first and last name, location, contact number, email address and biographical information. The only required field is the email address, since it serves the purpose of your login name and our source of sending out game match invitations and updates. The main profile page also replicates information regarding a listing of user's team affiliates and current team events. The profile page successfully makes use of the qualified standard gray panels, and a simple-to-read 3-column layout. The profile section also includes "manage" and "browse" sub-pages. The Profile Manage section gives the player the ability to make changes to their profile information. The only ability that it lacks at this point is a way to add additional social networking aliases, modifiy email address, and the choice of choosing a different profile avatar. The addition of other social networking aliases is as simple as creating a textfield. At this point, there is no "right" way of changing a user's email address since the user's account information is dependent on it as an identifier in the system. Hopefully in future enhancements, we'll incorporate an interface to attribute to this feature of changing a user's email, and getting a email notification of the account being modified. Of course to preserve the integrity of our system, we'll need to require a primary email address to send that account modification. Another neat enhancement would be to enable a user the ability to modify their avatar on the system by providing a local image upload. This would require a persistent storage location on our public servers and a limited file size.
Team page review:The team management section is in itself very functional and simple to use. The team creation process is straightforward, users will not have very much difficultly in getting the hang of things here. I could only point out certain enhancements rather than any noticeable flaws in this section. Although, the co-creator of this section did indicate in the issues listing about a potential "weakness" to the user-to-team invitations handling. This may be a confounding factor that needs to be addressed in the next implementation stages of Devcathlon, but as for now, it sits deep under the covers.
Match page review:The match management section gives a listing of all involving team matches. It gives you the ability to create, update and destroy matches. The only disadvantage is through the ease of finding an existing match. There is no mechanism to browse for matches, but it would help to supply a way to immediately find a match rather than scrolling through a large column listing. Maybe we can incorporate similar pages implemented by the user profile and team management sections. This would require two additional pages, called "Match Browse" and "Match Profile." The match browse page will include a table listing all matches, and on each row a link to its respected match profile page.
Scoreboard page review:The scoreboard page includes a listing of all matches, team line-ups and their respective members, match events, comments, and top developers for that match. This page did a good job of portaying that information in a clear way. My only problem is that it would be difficult to display multiple team match line-ups, where matches can consist of more than one participating team. The Hall of Fame page is included as a scoreboard sub-page that gives an overview listing of wins, losses, points accumulated per match, and most valuable players. I only wished that this page had more visual references rather than just plain-old text and links.
Top 5 lessons learned:
Now, for some people, this is the time to put up their hardhats and salute to a good year of eventful meetings, to staying up late coding, and to enduring all those emails with the subject line starting with "[Devcathlon] ..." I'm not sure about others, but I'll sure be missing that feeling of being needed for a project and looking forward to just doing something the next day. This project brought in a mixed set of individuals with different skills and backgrounds, but with one common goal of making this project the best it could be. I could not have asked more from these group of highly talented people. Their dedication and hard work has paid off, and I hope that everyone takes something from this into their own personal endeavors in life. I know that I'll take this experience and be able to apply what I've learned into any setting. The time we sacrificed; those bloody hours at the keyboard; those late nights sipping on energy drinks, and those times when all you could think about was "Devcathlon" will now become a memory. Even as unfortunate as that may sound to a few, it has made a profound impact on what I see in a large team setting. The beginnings were difficult, but over time we progressed from novices to experts in our own way. This experience has challenged myself and others mentally and somewhat physically. This project has given me ways to express myself more freely than I usually do in any other class related setting. It has taught me to be ethical, respectful, resourceful and passionate about goals. It has also taught me to become a better person by encouraging me to open up to all sorts of people. I'll honestly miss that energy, and all those who made this project what it is today. I hope to find that same spark during my attempt at enhancing this project for this year's Google Summer of Code. I'm sorry that not all original members of the team will be participating, but I am grateful for their respectful input and support. Good luck to everyone, and thanks for all the hard work!
Devcathlon has been a three month project intended to simulate a software engineering environment in hopes to improve development team practices, and to promote overall project health. In this entry, I'll evaluate the application through my personal perspective as a developer, along with the evaluations of outside testers. I'll also mention about my experiences in building this project, and the future of this application.
A programmer's perspective:
The journey through markup...
Most of my development time was spent on building the profile section of Devcathlon. It wasn't difficult, but there's still room for lots of improvement. I kept this first version of Devcathlon's profile page simple, in order to focus on the teams, matches and scoreboard pages. Devcathlon underwent through many physical and functional changes since its first conceptual designs. We started out with basic HTML mock-ups which looked and felt very web 2.0-ish; considering that it had some Javascript, some signs of pagination and an array of CSS layouts. By separating ourselves into three separate teams of three, we were able to generate some very inspirational designs and structures that would eventually be inherited into the "final" product. Although some design elements were put away as future enhancements, due to being labeled as aesthetic gains rather than functional gains, we did provide, in this version, an intuitive, yet simple user experience. The gains of taking this conservative approach would rather benefit ourselves in the long-run, since we built a strong foundation of our application and left plenty of room for advance UI's to take place later. Of course, we've only scratch the surface of Wicket's abilities to render some "pretty," and dynamic markup, but I'll see to it in our future implementation that we have an eye-candy application. At this point, I'm very pleased with what we have, as far as the look and feel goes. The application has a conformed look and layout; we made good use of our CSS to standardize our information in reusable "panels," and we also preserved colors and fonts similar to Hackystat's UI. I'm willing to put energy during this summer to make improvements in this area by incorporating more AJAX-y alternatives to necessary parts of the web application.
Functionality in design...
Below is a list of my likes and dislikes, and some possible way of improving each portion of the web application. I'll also mention the difficulties and challenges in making these sections possible.
Front page review:
The front page contains a basic login and password form, along with a preview version of our scoreboard. Although, this idea of putting the scoreboard on the front page came late in the game, we found it useful to help advertise the current status of our application with regards to providing evidence of user traffic and ratings. The front-page version of the scoreboard is not all that different from the actual scoreboard, except that some links are not featured unless you have logged in with an account. The gray panels and use of reusable components makes the composition of this page very useful in context, by providing information on match events, teams events and individual player's scoring. A future improvement would be to provide a live scoring data provider that would emulate statistics on the fly through 5 minute increments or whenever it spots a new change in the system. This would be beneficial by reducing the number of whole-page refreshes and enhancing the user experience by providing a persistent way of retrieving data.
Profile page review:
The profile page went through minimal amounts of change due to its limited usages other than finding out more about the player participating in the game. Although, the profile page makes for very little use, I've come to find that there are many ways of approaching this section. I looked around on mostly social networking sites, including TechHui, Facebook and Twitter to gain some inspiration and possible commonalities. I narrowed down some details of a user profile to only include, the user's first and last name, location, contact number, email address and biographical information. The only required field is the email address, since it serves the purpose of your login name and our source of sending out game match invitations and updates. The main profile page also replicates information regarding a listing of user's team affiliates and current team events. The profile page successfully makes use of the qualified standard gray panels, and a simple-to-read 3-column layout. The profile section also includes "manage" and "browse" sub-pages. The Profile Manage section gives the player the ability to make changes to their profile information. The only ability that it lacks at this point is a way to add additional social networking aliases, modifiy email address, and the choice of choosing a different profile avatar. The addition of other social networking aliases is as simple as creating a textfield. At this point, there is no "right" way of changing a user's email address since the user's account information is dependent on it as an identifier in the system. Hopefully in future enhancements, we'll incorporate an interface to attribute to this feature of changing a user's email, and getting a email notification of the account being modified. Of course to preserve the integrity of our system, we'll need to require a primary email address to send that account modification. Another neat enhancement would be to enable a user the ability to modify their avatar on the system by providing a local image upload. This would require a persistent storage location on our public servers and a limited file size.
Team page review:The team management section is in itself very functional and simple to use. The team creation process is straightforward, users will not have very much difficultly in getting the hang of things here. I could only point out certain enhancements rather than any noticeable flaws in this section. Although, the co-creator of this section did indicate in the issues listing about a potential "weakness" to the user-to-team invitations handling. This may be a confounding factor that needs to be addressed in the next implementation stages of Devcathlon, but as for now, it sits deep under the covers.
Match page review:The match management section gives a listing of all involving team matches. It gives you the ability to create, update and destroy matches. The only disadvantage is through the ease of finding an existing match. There is no mechanism to browse for matches, but it would help to supply a way to immediately find a match rather than scrolling through a large column listing. Maybe we can incorporate similar pages implemented by the user profile and team management sections. This would require two additional pages, called "Match Browse" and "Match Profile." The match browse page will include a table listing all matches, and on each row a link to its respected match profile page.
Scoreboard page review:The scoreboard page includes a listing of all matches, team line-ups and their respective members, match events, comments, and top developers for that match. This page did a good job of portaying that information in a clear way. My only problem is that it would be difficult to display multiple team match line-ups, where matches can consist of more than one participating team. The Hall of Fame page is included as a scoreboard sub-page that gives an overview listing of wins, losses, points accumulated per match, and most valuable players. I only wished that this page had more visual references rather than just plain-old text and links.
Top 5 lessons learned:
- Time management - Time is the quintessential factor in everyone's life. I found it difficult in many cases, but had to ground myself to accepting the fact that I do have issues in this area. I have learned through this experience to be patient and better plan out ahead of what needs to get done. This holds a large part in my leadership skills too, since managing other people calls for good planning and time management skills.
- Leadership skills - I think that I've become a better person from being given the title of a "leader." In many ways, it has improved my outlook of managing a small team in such a large setting. At first I was somewhat doubtful that I could accomplish it, but I eventual grew out of the fear and simply started to care. I started to care for the project and its respected team members. This helped bring me closer to the individuals in my team as well as other project members.
- Control - I think that controlling that programmer's ego is a must in a large project setting. It's very different from critiquing your own work as oppose to being able to endure criticism from others. I've learned to respect others opinions to find a common solution. Eventually once you've set aside your ego, you'll notice a difference in the mood that you bring to the atmosphere. I learned to control that atmosphere through just being lightly assertive, but straight to the point.
- Collaboration - Collaborating with my team members weren't very difficult, but it had some confounding factors such as its frequency and effectiveness. The effective route is to meet as often as possible. It's very simply stated, but it turned out to work in our situation with a group of eight people. We also incorporated pair programming as a way to keep each individual on their toes.
- Forgive and forget - Sometimes you just gotta forgive and forget. Its difficult already that this project posed a challenge for many of us, but adding to that tension could have led to some adverse effects. I'm glad that this group had that notion of forgiveness. It was quite evident during those milestones that just did not work out as we planned. We would rarely hold personal grudges towards another individual. It was sometimes nice to just talk about it rather than tuning out the whole problem.
Now, for some people, this is the time to put up their hardhats and salute to a good year of eventful meetings, to staying up late coding, and to enduring all those emails with the subject line starting with "[Devcathlon] ..." I'm not sure about others, but I'll sure be missing that feeling of being needed for a project and looking forward to just doing something the next day. This project brought in a mixed set of individuals with different skills and backgrounds, but with one common goal of making this project the best it could be. I could not have asked more from these group of highly talented people. Their dedication and hard work has paid off, and I hope that everyone takes something from this into their own personal endeavors in life. I know that I'll take this experience and be able to apply what I've learned into any setting. The time we sacrificed; those bloody hours at the keyboard; those late nights sipping on energy drinks, and those times when all you could think about was "Devcathlon" will now become a memory. Even as unfortunate as that may sound to a few, it has made a profound impact on what I see in a large team setting. The beginnings were difficult, but over time we progressed from novices to experts in our own way. This experience has challenged myself and others mentally and somewhat physically. This project has given me ways to express myself more freely than I usually do in any other class related setting. It has taught me to be ethical, respectful, resourceful and passionate about goals. It has also taught me to become a better person by encouraging me to open up to all sorts of people. I'll honestly miss that energy, and all those who made this project what it is today. I hope to find that same spark during my attempt at enhancing this project for this year's Google Summer of Code. I'm sorry that not all original members of the team will be participating, but I am grateful for their respectful input and support. Good luck to everyone, and thanks for all the hard work!
Friday, May 1, 2009
[ICS 499] Java + Flex Hybrid
Premise:
In this blog entry, I'll discuss my experiences of hybridizing Java, Actionscript, and Flex into forming what could possibly be a perfect ingredient for success. Well not absolute success, since I will not be building anything in this entry, but it will leave you with some ideas that could work in your setting. I'll also mention the ease of migrating between Java and Actionscript, and give you some insight into the possible technologies that surround Flex.
Contextual definitions:
Flex - front-end client-server application
Java - back-end object oriented language for building an enterprise server for channeling data
Actionscript - object oriented and script-base language used to construct logic in controlling our Flex client application.
Actionscript & Java:
Actionscript is an object oriented, free form, functional language used to build logic into creating Flash rendered content. The language follows the standards of ECMAScript and recently, in version 3.0 has been enhanced to support E4X for ease of processing XML.
Java is an object oriented language that has been widely accepted for its cross-platform, and strong emphasis in creating server-side technologies.
ActionScript 3 is different from Java when it comes to properties, dynamic behavior, and some very convenient aspects of functional programming. However, the move between Java to Actionscript was not all that difficult and it makes for a beneficial switch once you get the hang of things.
If you need a quick comparison chart between Java & Actionscript, then check out this posting.
Java & Flex:
Java and Flex provides the perfect marriage between two things that just mix well. One, you have a strong server-side back-end and two, a simple, near real-time data rendering front-end with very high refresh rates on large data sets and almost 100% deployable on any browser.
How it all fits together?
Figure 1.
Figure 1: http://learn.adobe.com/wiki/display/Flex/Flex+and+Java
A successful marriage calls for good communication:
Flex's ability to communicate with a Java EE back-end using HTTP or SOAP-based Web services is highly useful, but you're not limited to those communication approaches.
Adobe provides an open source alternative, called Blaze DS -- a server based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex and Adobe's Air application front-ends. BlazeDS lets you use Java Messaging Service JMS for communicating through XML-based transactions and allows you to use object remoting with Java. BlazeDS also adds potential performance benefits because it uses the binary AMF3 format for faster communication than is normally experienced with XML.
Conclusion:
Sorry to leave you with such limited content. I'm just excited now to test out the logic and theory, in order to get one step closer into hybridizing Java with Flex. In my next posting, I'll be concluding my research into a report that summarizes what I've accomplished and my experiences during the course of this study.
Resources:
Java & Actionscript 3 (Part 1)
Java & Actionscript 3 (Part 2)
Java & Flex Integration (Part 1)
Java & Flex Integration (Part 2)
In this blog entry, I'll discuss my experiences of hybridizing Java, Actionscript, and Flex into forming what could possibly be a perfect ingredient for success. Well not absolute success, since I will not be building anything in this entry, but it will leave you with some ideas that could work in your setting. I'll also mention the ease of migrating between Java and Actionscript, and give you some insight into the possible technologies that surround Flex.
Contextual definitions:
Flex - front-end client-server application
Java - back-end object oriented language for building an enterprise server for channeling data
Actionscript - object oriented and script-base language used to construct logic in controlling our Flex client application.
Actionscript & Java:
Actionscript is an object oriented, free form, functional language used to build logic into creating Flash rendered content. The language follows the standards of ECMAScript and recently, in version 3.0 has been enhanced to support E4X for ease of processing XML.
Java is an object oriented language that has been widely accepted for its cross-platform, and strong emphasis in creating server-side technologies.
ActionScript 3 is different from Java when it comes to properties, dynamic behavior, and some very convenient aspects of functional programming. However, the move between Java to Actionscript was not all that difficult and it makes for a beneficial switch once you get the hang of things.
If you need a quick comparison chart between Java & Actionscript, then check out this posting.
Java & Flex:
Java and Flex provides the perfect marriage between two things that just mix well. One, you have a strong server-side back-end and two, a simple, near real-time data rendering front-end with very high refresh rates on large data sets and almost 100% deployable on any browser.
How it all fits together?
Figure 1.
Figure 1: http://learn.adobe.com/wiki/display/Flex/Flex+and+JavaA successful marriage calls for good communication:
Flex's ability to communicate with a Java EE back-end using HTTP or SOAP-based Web services is highly useful, but you're not limited to those communication approaches.
Adobe provides an open source alternative, called Blaze DS -- a server based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex and Adobe's Air application front-ends. BlazeDS lets you use Java Messaging Service JMS for communicating through XML-based transactions and allows you to use object remoting with Java. BlazeDS also adds potential performance benefits because it uses the binary AMF3 format for faster communication than is normally experienced with XML.
Conclusion:
Sorry to leave you with such limited content. I'm just excited now to test out the logic and theory, in order to get one step closer into hybridizing Java with Flex. In my next posting, I'll be concluding my research into a report that summarizes what I've accomplished and my experiences during the course of this study.
Resources:
Java & Actionscript 3 (Part 1)
Java & Actionscript 3 (Part 2)
Java & Flex Integration (Part 1)
Java & Flex Integration (Part 2)
Subscribe to:
Posts (Atom)