This page contains the most important details of this project. If you find the information on this project inaccurate or inappropriate, please let us know by contacting us.
Submit Audition/Proposal on this Project
Rate this Project
Invitation Inbox
Project Main Details
3108678
3108678
Corporate Web Demo (online use only)
12min (6pages)
Male Professional
English
I will need the audio sent via ftp
Please let me know the following:
-the system your record on
-the microphone/s you have and use
-the preamp you use
Please read the first paragraph and email to me.
below is the complete script (disregard the time code):
Approx. total combined running time: 12 minutes
[Cut 0:00.00 to 0:25.72 from the JavaALM.avi file]
Mar 17, 2005 16:19:24 (GMT -05:00) Eastern Time (US & Canada) Mar 17, 2005 00:00:00 (GMT -05:00) Eastern Time (US & Canada) No (click here to learn more about
)
Closed
56
28
0 direct invitation(s) have been sent by the voice seeker resulting in 0 audition(s) and/or proposal(s) so far.
12min (6pages)
Male Professional
English
I will need the audio sent via ftp
Please let me know the following:
-the system your record on
-the microphone/s you have and use
-the preamp you use
Please read the first paragraph and email to me.
below is the complete script (disregard the time code):
Approx. total combined running time: 12 minutes
[Cut 0:00.00 to 0:25.72 from the JavaALM.avi file]
Mar 17, 2005 16:19:24 (GMT -05:00) Eastern Time (US & Canada) Mar 17, 2005 00:00:00 (GMT -05:00) Eastern Time (US & Canada) No (click here to learn more about
)
Closed
56
28
0 direct invitation(s) have been sent by the voice seeker resulting in 0 audition(s) and/or proposal(s) so far.
Project Parameters
None
To be defined
Promos
English - British AND English - North American
Not defined
Young Adult Male OR Middle Age Male
Not defined
There are no special pre-, post-, or production requirements for this project.
Not defined
Not defined
No
Not defined
Script Details
Yes
N/A
Slide 1, “JBuilder: The First Choice in Java Development”
For over 20 years, Borland has been focused on providing developers with the tools and technologies they need to do their jobs efficiently. As a result, Borland JBuilder is recognized as the first choice for Java development, improving the productivity of both individual Java developers and entire development teams.
Slide 2, “JBuilder: The Developer’s Window into the Application Lifecycle”
However, in the world of software development, success is measured not only on the productivity of individuals and development groups, but on the effectiveness of the entire software development organization, from requirements analysts and architects to coders and testers. That’s why Borland has continually enhanced its products to improve collaboration and communication between members of distributed and cross-functional teams throughout the application lifecycle. Now, with award-winning JBuilder 2005,developers have a window into the entire development lifecycle, including requirements that link to source code, distributed refactoring, code-model synchronization, and integrated audits and metrics.
[From jbalm2.avi file, 0:00.00-2:35.50]:
In this demo, we will go through some of the new features in JBuilder 2005 to support development organizations across the application lifecycle.
We're going to start with requirements. In this latest version, we've added a CaliberRM plug-in to view and manage requirements from directly within the JBuilder IDE. You can go to the menu under Tools->CaliberRM to configure connections to any Caliber server. I'll give this one a logical name like ‘local’ and then login to the server. After I connect, I can choose any particular project – in this case bookstore. Now I can add the connection to this caliber server directly into the project I'm working in by clicking ‘add to project’ – and now I see any caliber server I’m connected to within my project tree. By right-clicking and selecting ‘open’, I now have a complete requirements browser embedded in my IDE. I can then browse those requirements to view and understand them. I can also apply filters to this – for example, I can choose a common filter like 'my requirements', and that will gray-out any of the requirements that are not owned by me. I can also edit and create new filters to select for other criteria such as only displaying recently updated requirements.
In addition, I can also link a particular requirement directly into the source code, to something like a java class or a java method. What I can do here is take this particular requirement and drag it onto the 'Shipping Info' method. As you can see, the details of the requirement show up directly within the source code as a comment.
If I now go off into the stand-alone caliber client that I might use when I'm working with business analysts or customers, they can directly enter changes, such as this very well-defined requirement: "make it look really cool!", and commit those changes. I can then go back into the IDE and refresh all of the changes into my requirements browser. What’s more, when I refresh the code view, the changes are reflected in the source code as well, so I know the requirements I am working from in my JBuilder project are always in sync with those on the caliber server.
I can also link to any HTML file; for example, here I have the documentation for this project, and here's the source code for the HTML file. I can go and drag a requirement into the HTML editor view and create an HTML comment that again creates a live link from the requirement directly into the project.
[stop at 2:35.50 before “so the 3rd requirement…”]
[From JavaALM.avi file, 0:25.72 to 2:21.47]:
Now let’s take a closer look at Borland CaliberRM, the collaborative requirements management system. As you can see we have the pet store project open. In pet store, there are a number of requirement types. Specifically, business requirements, functional requirements, and technical requirements. These are customizable to suit your needs. I gathered the information inside of these requirements from the Java pet store blueprints website. So if we look at this pet store project which is opened we can see there’s only one baseline, but note that there is the ability to have multiple baselines as well as multiple projects in CaliberRM.
1:00
On the details tab you can see a number of standard requirements information. The name of the owner, its status and the version are all configurable here. The description pane below has some text that outlines the requirements for the silent registration part of pet store, but this list could also contain information such as a use case or feature set.
1:25
The responsibilities tab has a list of the people responsible for this requirement and who will be notified when changes are made, as you can see here. And the references tab has a list of files – in this case, gif images with the mock up of the login screen for Pet Store, but it can also be a web page or any other document type.
1:48
The traceability tab is key and it contains information on what other requirements trace to this requirement as well as what this requirement traces to, and in this case you can see for example, there is a sign on and off use case.
2:00
Discussion threads are also part of the requirement and can be added here. And note also at a project level there are discussion threads as well. Not a lot of content here right now, but you can imagine the discussion threads growing significantly throughout the life of the project.
2:14
The history tab contains a list of version numbers that have been applied due to changes in this requirement over its lifetime.
[From jbalm2.avi file, 2:38.03-6:16.00]:
So let’s go back to JBuilder 2005 and take a look at what happens if, for example, I’ve been asked to change this bookstore project to just be a generic store, so I'll do one of the common things developers do these days, and refactor – I'll go in to the bookstore class and change the name of that class to something more generic, like ‘store’, now that we're not going to be just selling books, we’re also going to be selling pets and who knows what else.
In the past, JBuilder would just rename all of the Java artifacts that refer to bookstore, but with JBuilder 2005, we now have a distributed refactoring engine that allows us to do things like automatically refactor the reference in the faces config deployment descriptor for this JSF application we're working on. We'll also fix up any references that are embedded in breakpoint descriptions or runtime configurations or anything else that refers to this class. So I'll go ahead and do the refactoring now.
3:27.80
But another common problem we have is if some other project uses this, say our QA is running test suites on this, or this would be a jar file I distribute to my customers and they would need to update the changes, I can now go off to dependent projects any time later. Here I have a simple JUnit test case that refers to the changed class and I can see that it has dependencies on this project that I just refactored, and it needs to rename the bookstore class as well. So I can go ahead and apply that, and I can do this at any later time, it also doesn't have to be on the same machine, it can be anywhere – it's a complete, well-structured message passed between one project and another – between one jar file and the consumer of it – indicating that something has changed.
4:14.55:
When I go to check-in my original project, I can go to my embedded StarTeam view of this project – Borland StarTeam is an automated configuration and change management system. Here I have a particular active process item, a change request that came from our QA pre-production team that shows that the application was running out of resources. I can double-click on that to bring up the ServerTrace analyzer to understand what was going wrong. I can drill down on any particular component of this J2EE application and understand directly where it was coming from in the source code. For resource leaks, I can look at our automatic quality analyzer and go directly to the line in the source code where the problem was occurring and in this case we can see that I had opened a connection but failed to close it, because I had commented-out that line.
5:00.01
When I view this file in JBuilder now, I can go to the offending line and immediately see who last changed it, and down on the status bar here I can see that it was last changed by Frank Borland without comment. If I want a more detailed view of the file, I can go to the annotations tab on the history view now and scroll through the entire file and for every version of every line of code, I can see who changed it and what comments, if any, were made.
5:32.01
If you take a look at the project view now, you notice that I have a 'live view' of the project -- I can filter the files to view, for example, only those files that have been modified by me, or modified by others, while I was working on this. And if I don't want the chatter from the rest of the team, I can turn that off. But if I want to understand when I'm working on something that might be changing while I am working on it, and I want the immediate feedback through annotations in the project view, I can get that also.
When I create a new project, also notice we have additional team support, I can now select Subversion as our project version control system in addition to the ones we have supported in the past such as ClearCase, CVS, StarTeam, and
Visual SourceSafe.
[Stop at 6:16.00, before “so that’s a quick overview…”]
[From JavaALM.avi file, 21:08.00 to 23:46.00]:
Let’s shift gears now and do a little bit of run time analysis. We did some auditing but now we’re going to take a look at request analyzer which is part of OptimizeIt Enterprise Suite, which ships with JBuilder 2005.
21:23
If I open up the index for pet store, we’re going to shift our workspace to a testing workspace which gives me a file view in the top half and the message pane containing, in this case, request analyzer in the bottom half. We can see that request analyzer is able to give us a broader overview of the runtime characteristics with a J2EE application, or any distributed application for that matter.
21:47
The focus here is going to be on the breakdown between JDBC, JNDI, Servlet and JSP, EJB, et cetera, the components within our pet store application. As we click through you’ll be able to see changes in the percentage of distribution that these components are being used. As you’d expect as we click through more pages, we’re going to see our Servlet and JSP percentage increase accordingly.
22:15
Then we’ll be able to drill down at a later point to find more detail on what precise actions are being taking place in these component distributions so we can further understand how the runtime characteristics of the pet store application look.
22:32
So I’m going to sign in. Right now this is running on the J2EE reference implementation which I configured the audit system for, optimized to run on the request analyzer data, which is what you’re looking at in the bottom frame.
22:52
This request analyzer can also be configured to provide the exact same functionality on other J2EE application servers such as Borland Enterprise Server, IBM WebSphere, BEA WebLogic, and JBoss and you can even rerun the request analyzer for each configured server and compare the runs to investigate any server-specific performance issues. Right now I’m just clicking through the different components so JMS for example as well as the RMI calls that are being made and we can always drill down and get more information about the exact calls that are being made and their percent utilization in the runtime environment. Also if we look at the quality analyzer we can see that for example there are result types that are never closed and exceptions that are thrown and that information is also provided in detail.
22:32
So request analyzer is a very useful feature included with JBuilder 2005, and a great abstraction of some distributed computing concepts particularly with regard to j2EE that you can use to better understand how the runtime characteristics of your application impact its performance.
[End at 23:46.95, BEFORE switching screens from the Java Pet Store web page to the JBuilder page]
33:23
[From JavaALM.avi file, 33:42.00 to 35:07.27 (approx. 1.5 mins) – use this as the intro or the wrap-up to touch on some things we didn’t show?]
Today we’ve taken a look at some of the new features in JBuilder 2005 including integration with Caliber RM providing you with the ability to refine your requirements for application development and then provide traceability from requirements through to design and implementation artifacts all embedded within the JBuilder IDE. From there, you can analyze source code that is generated within JBuilder with a set of audits to ensure adherence to best practices.
34:37
Add to that the ability to define your deployment archives visually with an EJB designer provided with JBuilder. And then at run time analyze the characteristics of your application on any J2EE application server.
34:57
With all these capabilities in one development environment it is easy to see how JBuilder 2005 can help you and your entire organization produce better software, faster.
For over 20 years, Borland has been focused on providing developers with the tools and technologies they need to do their jobs efficiently. As a result, Borland JBuilder is recognized as the first choice for Java development, improving the productivity of both individual Java developers and entire development teams.
Slide 2, “JBuilder: The Developer’s Window into the Application Lifecycle”
However, in the world of software development, success is measured not only on the productivity of individuals and development groups, but on the effectiveness of the entire software development organization, from requirements analysts and architects to coders and testers. That’s why Borland has continually enhanced its products to improve collaboration and communication between members of distributed and cross-functional teams throughout the application lifecycle. Now, with award-winning JBuilder 2005,developers have a window into the entire development lifecycle, including requirements that link to source code, distributed refactoring, code-model synchronization, and integrated audits and metrics.
[From jbalm2.avi file, 0:00.00-2:35.50]:
In this demo, we will go through some of the new features in JBuilder 2005 to support development organizations across the application lifecycle.
We're going to start with requirements. In this latest version, we've added a CaliberRM plug-in to view and manage requirements from directly within the JBuilder IDE. You can go to the menu under Tools->CaliberRM to configure connections to any Caliber server. I'll give this one a logical name like ‘local’ and then login to the server. After I connect, I can choose any particular project – in this case bookstore. Now I can add the connection to this caliber server directly into the project I'm working in by clicking ‘add to project’ – and now I see any caliber server I’m connected to within my project tree. By right-clicking and selecting ‘open’, I now have a complete requirements browser embedded in my IDE. I can then browse those requirements to view and understand them. I can also apply filters to this – for example, I can choose a common filter like 'my requirements', and that will gray-out any of the requirements that are not owned by me. I can also edit and create new filters to select for other criteria such as only displaying recently updated requirements.
In addition, I can also link a particular requirement directly into the source code, to something like a java class or a java method. What I can do here is take this particular requirement and drag it onto the 'Shipping Info' method. As you can see, the details of the requirement show up directly within the source code as a comment.
If I now go off into the stand-alone caliber client that I might use when I'm working with business analysts or customers, they can directly enter changes, such as this very well-defined requirement: "make it look really cool!", and commit those changes. I can then go back into the IDE and refresh all of the changes into my requirements browser. What’s more, when I refresh the code view, the changes are reflected in the source code as well, so I know the requirements I am working from in my JBuilder project are always in sync with those on the caliber server.
I can also link to any HTML file; for example, here I have the documentation for this project, and here's the source code for the HTML file. I can go and drag a requirement into the HTML editor view and create an HTML comment that again creates a live link from the requirement directly into the project.
[stop at 2:35.50 before “so the 3rd requirement…”]
[From JavaALM.avi file, 0:25.72 to 2:21.47]:
Now let’s take a closer look at Borland CaliberRM, the collaborative requirements management system. As you can see we have the pet store project open. In pet store, there are a number of requirement types. Specifically, business requirements, functional requirements, and technical requirements. These are customizable to suit your needs. I gathered the information inside of these requirements from the Java pet store blueprints website. So if we look at this pet store project which is opened we can see there’s only one baseline, but note that there is the ability to have multiple baselines as well as multiple projects in CaliberRM.
1:00
On the details tab you can see a number of standard requirements information. The name of the owner, its status and the version are all configurable here. The description pane below has some text that outlines the requirements for the silent registration part of pet store, but this list could also contain information such as a use case or feature set.
1:25
The responsibilities tab has a list of the people responsible for this requirement and who will be notified when changes are made, as you can see here. And the references tab has a list of files – in this case, gif images with the mock up of the login screen for Pet Store, but it can also be a web page or any other document type.
1:48
The traceability tab is key and it contains information on what other requirements trace to this requirement as well as what this requirement traces to, and in this case you can see for example, there is a sign on and off use case.
2:00
Discussion threads are also part of the requirement and can be added here. And note also at a project level there are discussion threads as well. Not a lot of content here right now, but you can imagine the discussion threads growing significantly throughout the life of the project.
2:14
The history tab contains a list of version numbers that have been applied due to changes in this requirement over its lifetime.
[From jbalm2.avi file, 2:38.03-6:16.00]:
So let’s go back to JBuilder 2005 and take a look at what happens if, for example, I’ve been asked to change this bookstore project to just be a generic store, so I'll do one of the common things developers do these days, and refactor – I'll go in to the bookstore class and change the name of that class to something more generic, like ‘store’, now that we're not going to be just selling books, we’re also going to be selling pets and who knows what else.
In the past, JBuilder would just rename all of the Java artifacts that refer to bookstore, but with JBuilder 2005, we now have a distributed refactoring engine that allows us to do things like automatically refactor the reference in the faces config deployment descriptor for this JSF application we're working on. We'll also fix up any references that are embedded in breakpoint descriptions or runtime configurations or anything else that refers to this class. So I'll go ahead and do the refactoring now.
3:27.80
But another common problem we have is if some other project uses this, say our QA is running test suites on this, or this would be a jar file I distribute to my customers and they would need to update the changes, I can now go off to dependent projects any time later. Here I have a simple JUnit test case that refers to the changed class and I can see that it has dependencies on this project that I just refactored, and it needs to rename the bookstore class as well. So I can go ahead and apply that, and I can do this at any later time, it also doesn't have to be on the same machine, it can be anywhere – it's a complete, well-structured message passed between one project and another – between one jar file and the consumer of it – indicating that something has changed.
4:14.55:
When I go to check-in my original project, I can go to my embedded StarTeam view of this project – Borland StarTeam is an automated configuration and change management system. Here I have a particular active process item, a change request that came from our QA pre-production team that shows that the application was running out of resources. I can double-click on that to bring up the ServerTrace analyzer to understand what was going wrong. I can drill down on any particular component of this J2EE application and understand directly where it was coming from in the source code. For resource leaks, I can look at our automatic quality analyzer and go directly to the line in the source code where the problem was occurring and in this case we can see that I had opened a connection but failed to close it, because I had commented-out that line.
5:00.01
When I view this file in JBuilder now, I can go to the offending line and immediately see who last changed it, and down on the status bar here I can see that it was last changed by Frank Borland without comment. If I want a more detailed view of the file, I can go to the annotations tab on the history view now and scroll through the entire file and for every version of every line of code, I can see who changed it and what comments, if any, were made.
5:32.01
If you take a look at the project view now, you notice that I have a 'live view' of the project -- I can filter the files to view, for example, only those files that have been modified by me, or modified by others, while I was working on this. And if I don't want the chatter from the rest of the team, I can turn that off. But if I want to understand when I'm working on something that might be changing while I am working on it, and I want the immediate feedback through annotations in the project view, I can get that also.
When I create a new project, also notice we have additional team support, I can now select Subversion as our project version control system in addition to the ones we have supported in the past such as ClearCase, CVS, StarTeam, and
Visual SourceSafe.
[Stop at 6:16.00, before “so that’s a quick overview…”]
[From JavaALM.avi file, 21:08.00 to 23:46.00]:
Let’s shift gears now and do a little bit of run time analysis. We did some auditing but now we’re going to take a look at request analyzer which is part of OptimizeIt Enterprise Suite, which ships with JBuilder 2005.
21:23
If I open up the index for pet store, we’re going to shift our workspace to a testing workspace which gives me a file view in the top half and the message pane containing, in this case, request analyzer in the bottom half. We can see that request analyzer is able to give us a broader overview of the runtime characteristics with a J2EE application, or any distributed application for that matter.
21:47
The focus here is going to be on the breakdown between JDBC, JNDI, Servlet and JSP, EJB, et cetera, the components within our pet store application. As we click through you’ll be able to see changes in the percentage of distribution that these components are being used. As you’d expect as we click through more pages, we’re going to see our Servlet and JSP percentage increase accordingly.
22:15
Then we’ll be able to drill down at a later point to find more detail on what precise actions are being taking place in these component distributions so we can further understand how the runtime characteristics of the pet store application look.
22:32
So I’m going to sign in. Right now this is running on the J2EE reference implementation which I configured the audit system for, optimized to run on the request analyzer data, which is what you’re looking at in the bottom frame.
22:52
This request analyzer can also be configured to provide the exact same functionality on other J2EE application servers such as Borland Enterprise Server, IBM WebSphere, BEA WebLogic, and JBoss and you can even rerun the request analyzer for each configured server and compare the runs to investigate any server-specific performance issues. Right now I’m just clicking through the different components so JMS for example as well as the RMI calls that are being made and we can always drill down and get more information about the exact calls that are being made and their percent utilization in the runtime environment. Also if we look at the quality analyzer we can see that for example there are result types that are never closed and exceptions that are thrown and that information is also provided in detail.
22:32
So request analyzer is a very useful feature included with JBuilder 2005, and a great abstraction of some distributed computing concepts particularly with regard to j2EE that you can use to better understand how the runtime characteristics of your application impact its performance.
[End at 23:46.95, BEFORE switching screens from the Java Pet Store web page to the JBuilder page]
33:23
[From JavaALM.avi file, 33:42.00 to 35:07.27 (approx. 1.5 mins) – use this as the intro or the wrap-up to touch on some things we didn’t show?]
Today we’ve taken a look at some of the new features in JBuilder 2005 including integration with Caliber RM providing you with the ability to refine your requirements for application development and then provide traceability from requirements through to design and implementation artifacts all embedded within the JBuilder IDE. From there, you can analyze source code that is generated within JBuilder with a set of audits to ensure adherence to best practices.
34:37
Add to that the ability to define your deployment archives visually with an EJB designer provided with JBuilder. And then at run time analyze the characteristics of your application on any J2EE application server.
34:57
With all these capabilities in one development environment it is easy to see how JBuilder 2005 can help you and your entire organization produce better software, faster.
Please note that you should only use the script or your recording of it for auditioning purposes. The script is property, unless otherwise specified, of the voice seeker and it is protected by international copyright laws.
Voice-Seeker Details
Voice123 Team Comments
Voice123 consultations with this voice seeker regarding this project and/or other projects by this voice seeker, via phone, chat, and/or email.
This project - phone.
Previous projects - phone.
This project - email or chat.
Previous projects - email or chat.
Corporate web site for this voice-seeker confirmed by Voice123
Note: Voice123 strives to establish the legitimacy of all projects posted. However, Voice123 subscribers and users are responsible for confirming information stated by prospective voice seekers, agents and/or clients. Voice123 subscribers and users assume all liability for use of any information found through Voice123, LLC, or any of its publications.
