Consider the following BNF grammar rules:

Which of the following strings can be derived from the grammar given above? THE ANSWER IS: STRINGS 1, 2, 4, & 5 CAN BE DERIVED. Below are the derivations:

I was once asked in a job interview as to what is my most preferred Programming Language. If my memory serves me right, my answer was Java. The reason goes beyond my experience developing applications using that language and familiarity on its core codes. It is because the language was then an “in demand” and I heard that Java developers are sent abroad. I got the job. But as I develop more and more projects, the criteria of self-improvement and high salary are not enough to settle on a programming language. There are these criteria which are simple in nature but have direct impact on your output. I once again encountered them here in Graduate School and will reiterate the importance of choosing a language that blends them. These are readability, writability, and ease of use.

The first criterion, readability, is important for huge applications that require group effort and constant code refactors. It is easier to maintain a code which at first glance you can easily understand. This also contributes to your customers as manipulation will be easy for them particularly if the requirement specification states that users should be able to do some editing in the codes. Though this is easier to use, it usually contradicts with the writability as programming languages such as these would require more statements that should follow more syntax and has the greater probability of generating error.

Writability on the other hand primarily focuses on the consistency and simplification of statements. The best part here is the mere fact that most commonly used programming languages now follows a standard pattern in the way statements are designed. Let us consider the code snippet below:

This is how Ruby and Java use the For loop statement to iterate the showing of the value of the variable “i” on the screen. Notice that the syntax may differ but the way it was presented are similar. If you are an experienced programmer, this will be an ease. On the other hand, if you are a neophyte, documentation for Ruby is indeed necessary. That is the reason why writability usually contradicts with readability’s objective. Is there such a programming language that blends the two? That is something that we need to find out. But they say, Ruby was a good example of this as the one who design such programming language considered the blending of these two

Ease of use is a more general criterion. This can be subjective in nature depending on factors such as user experience, familiarization on the language, or even its direct impact to solve the problem. Though, this criterion is usually associated with the user interface and how easy it is to use the language with the development environment. For me, it is a combination of the first two criteria. If you can easily read and write the code then it is easy to use. The developer has a great contribution on this area. If you want to make an effective system that satisfies the customer, be familiarized with the language you use. If you are designing a language, make this as your topmost criteria. Development is a two way street – if the developer enjoys building systems using your language, customers will surely enjoy the developed application

If I will be again asked as to what programming language will I prefer? My answer is this – “I will not name any language. Instead, I prefer a programming language where I can read easily, write with pleasure, and develop applications as if I am browsing my Facebook account”

Reference:

• ALBACEA, ELIZER A (2002). PRINCIPLES OF PROGRAMMING LANGUAGES. University of the Philippines Open University, 30-31.

Is there a programming language that does both interpretation and compilation?

The answer is a big YES.

This was made possible by the Java Programming Language who first compiles a text code in order to represent it to its equivalent code that the virtual machine can understand and then interprets it upon execution. The said sequence is shown in this diagram:

This diagram shows the compilation and interpretation done by the Java programming language. The developer writes a code in a text editor and saves it in a file with an extension of “.java”. The created java file is now compiled to the “machine” code called as “bytecode” for the Java Virtual Machine to understand. The JVM then simulates a processor then executes the bytecode instructions. The java file now is converted into a new file with an extension of “.class”. The class file is now interpreted by the Java interpreter that converts the bytecode into the machine language of the particular computer

Thus, Java does both compilation (for some degree of code optimization) and interpretation (for portability). This kind of implementation is known as “Hybrid Implementation”

Isn’t it great?

Web Reference:

• http://www.particle.kth.se/~lindsey/JavaCourse/Book/Part1/Supplements/Chapter01/interpreterCompiler.html

Reference:

• BALAGTAS, FLORENCE TIU (2005). INTRODUCTION TO PROGRAMMING I Version 1. Java Education and Development Initiative, 22-24.

Structured Programming Languages

I vividly remember the first time I encountered a programming language. It was in high school and the experience was a bit terrible. Not just because of the blue screens and yellow font colors that results to again a plain text but this time with black background color and white fonts but because of the complexity of knowing its rules which we all known to be as syntax. Every assignment was a failure but the lesson I learned is eternal. Why? It was during that time when I get to appreciate structure or modules. It is where I embraced the idea that in order to solve a problem, a procedure should be followed. Well, yes, thanks to Pascal then. I always look forward to the END statement whenever I type in the BEGIN.

This particular experience is just a brief explanation of what structured programming languages are. Programmers tend to focus on the result that the structure of the code and how solutions are implemented are often overseen. This apparently results to a well-known problem of the developers called as “Spaghetti Code”. In fact, when this subset of procedural programming was introduced, they would like to eliminate or reduce the existence of the GOTO statement. This has been brought out to the famous article of Edsger Dijkstra entitled “Go To Statement Considered Harmful”. So therefore, this programming scheme enforces a logical structure on the code being written in order to make it more efficient and easy to understand.

Structured programming presents the following structuring techniques or methodologies which are also basis to determine whether a programming language supports it:

• The logic of the program is a structure composed of similar sub-structure. In short and simple terms, it is a modular programming that subdivides the codes into different modules, procedures, or functions. The JavaScript code snippet below is an example of an example of a function that specifically answers a need or a requirement.
  
  
• It employs top-down design model which developers map out the overall code into different subsections
• Program flow follows a simple hierarchical model that employs looping constructs such as “for”, “while”, or “repeat”. It is then discouraged to use the “goto” statement. There are also flow structures such as sequence for the flow of execution and selection for conditional statements

Most of the programming languages used today applies the structured programming in order to avoid the issues of the unstructured one

What is the result of an unstructured code or if the Programming Language does not support it?

The result of an unsupported structural technique in a programming language is a poorly organized code. Some called it “Spaghetti Code” but I rather call it “Pansit Palabok” The code answers the need of the moment but some other aspects are overseen that even results to a bigger problem. Imagine a code where all the statements are just in the main body. Not just ineffective but the criteria such as readability, flexibility, and maintenance are often violated. Should you want to grow old early? A great recommendation is to make your code unstructured.

Web References:

• http://en.wikipedia.org/wiki/Structured_programming
• http://en.wikipedia.org/wiki/Top-down_design
• http://en.wikipedia.org/wiki/Procedural_programming_languages
• http://searchcio-midmarket.techtarget.com/definition/structured-programming

What is Block Structure Programming?

Programming languages are developed in order for the user, called as programmer, to tell the computer what to do in addressing a need or a requirement. These instructions are usually in a form of statements that should conform to a set of rules in defining and constructing it. It is called syntax and is unique in every programming language. The construction of these instructions depends on the language you use. There are some who follows a procedural approach where step by step implementation is done. While some are focusing on certain objects in order to come up with a complete solution. Among these, the most common and used technique is what we called block structure programming where declarations and statements are grouped together in a form of a block.

Block structure programming allows the programmer to create blocks that may also include nested block so that statements or codes can be grouped together. The idea of such was introduced when the simplified coding system or also known as “autocodes” were formally presented in Algol 58 and Algol 60 reports. The grouping is done by placing all related declarations and / or statements inside a block and is delimited by a begin and end statement (may be BEGIN or END, an opening or a closing curly braces {}). Blocks allow the programmer to treat a group of statements as a unit, and the default values which had to appear in initialization in this style of programming can, with a block structure, be placed closer to the decision. This technique does not only simplifies the code but also contributes to its readability and maintainability. Here is an example of a block structured code:

Using JavaScript

The for looping statement uses the block structure in this code snippet. It is easier to determine that the dropVal variable will change as it passes to the loop and if the condition is met.

Implementation of Block Structure in Programming Languages

Here is the implementation of the block structure programming in the following well known programming languages:

ALGOL

The idea of the block structure in ALGOL is to create blocks of statements for the scope of variables and the extent of influence of control statements. In this code snippet, it is clear that whenever the for loop is implemented, the array Data[] is populated with the entered value in val variable.

PASCAL

The block structure in this example is implemented in a conditional statement. Notice that is easier to determine the result of the condition by just checking on the inner blocks. Changes can also be integrated with ease in this case without affecting the other blocks. This blocks can also be implemented on looping statements.

C

This C code snippet uses block structure for the looping statement for. Notice that whenever the code passes by the loop a block of conditional statement is implemented to determine if the entered value of the n variable is a prime number. It is easier to maintain and refactor such code with the block structure technique.

BASIC

In this code snippet, the block structure is used in the conditional statement with the IF-ENDIF delimiters. It is easier to determine the codes to be executed whenever the name entered is “Ron”.

Web References

• http://en.wikipedia.org/wiki/Block_(programming)
• http://en.wikipedia.org/wiki/Autocode
• http://www.csse.monash.edu.au/~lloyd/tildeProgLang/PL-Block/
• http://en.wikibooks.org/wiki/C_Programming/Structure_and_style
• http://www.cplusplus.com/doc/tutorial/program_structure/
• http://groups.engin.umd.umich.edu/CIS/course.des/cis400/algol/algol.html
• http://www.augustana.ab.ca/~jmohr/courses/common/csc370/lecture_notes/algol2.html
• http://www.cis.temple.edu/~ingargio/cis71/code/factors1.c
• http://home.cmit.net/rwolbeck/programmingtutorial/index.htm

INTRODUCTION

“When Compliance and Lesson Learned Converged In a Paper”

This is a compliance.

Among the ways to start a paper’s introduction, the above statement is “inappropriate” in nature and specifically “direct” in approach. But it only shows what this paper is all about. This is indeed a compliance that needs to be submitted on time and would require a lot research effort in order to showcase the author’s intent and ideas. It is called “reality” and more often than not, the truth is painful.

Frederick P Brook’s essay dubbed “the Surgical Team” exposes such reality through an analogy of a “surgical team” in order to address an impeding problem in developing software systems as a team. It is an eye-opener and a lesson learned particularly if you were able to experience working with a group of programmer enthusiasts eyeing to deliver a “working” system. It presents collaboration, effective distribution of work, responsibility, and most importantly the trust that the whole group will be able to make it.

This paper is just a commentary written in words but the lesson you can get goes beyond that. It might be a compliance but when converged with real life’s insights becomes a sound that knows no end, knows no bound.

Sit back and relax. Let me unravel what Mr Brooks wants you to learn when he wrote the book 10 years ago.

THE “DILEMMA”

Mr Frederick Brooks called it the “problem” but I prefer calling it the “dilemma”. The issue raised on the initial statements of “the Surgical Team” essay talks about two major concerns – first is the need to deliver a large-scale project (the requirement) and second is the number of people who will do it (the performers).

The requirement has been identified in an exaggerated way to showcase the extremity and the possible complexity of the client’s expected system. What if your company is to develop a huge and critical system in a small span of time, limited budget, and only a number of people? Added to the agony is the diversity of your group that consists of good and bad programmers. Since you have to deliver immediately and with quality, you certainly have the option to play around with your members – to either allow all of them to work and embrace the possibility of mediocrity plus high cost or to just choose those performing programmers who can really deliver but will jeopardize delivery time.

This problem is not new mostly in a software development setup. A research conducted by Roger D Pendharkar in 2009 stated that project managers tend to increase the team size due to the following:

A) Pressure to meet the schedule, as competitive advantage of the technology decreases with time.
B) Assigning one person to a project does not mean linear completion time.
C) Dividing work into small sub-projects allows many people to work on a project simultaneously.

Yet like what Mr Brooks mentioned that this setup will lead to high cost of communication and ill effects of correcting miscommunication. On the contrary, if the “small sharp” group will remain and as mentioned if the development will utilize the “brute force” approach, the number is too small for large systems. This is now a crossroad between efficiency plus conceptual integrity and bringing considerable manpower for the project to be timely.

Now the big questions are – How are we going to combine these options? If not, what are we going to choose?

A Computer Science professor at the Florida Institute of Technology named “Harlan D Mills” had a fresh and creative solution. What if instead of giving the task to all the members that leads to expected undesirable results, we segregate the large tasks to separate team where one does the work while the others support him. The analogy used is a “surgical team” but in the real world they called it the “development team”.

WHEN A SURGICAL TEAM STARTS TO CODE

Mr Harlan D Mills suggested a way in order to address the problem in the timely delivery of the system and maximizing the available people in a team. He proposed that each segment of a large job be tackled by a team but that team be organized like a surgical team. One will be “main implementer” while the others give him all the support that will enhance his effectiveness and productivity. They call this technique the “chief programming concept”.

This approach, ideally, consists of ten people (seven of which are professionals) where each member will be given a specific role. Metaphorically, Brooks explained the functions of each member by using its analogy to a surgical team:

The Surgeon is also called the “chief programmer” where he does most of the critical tasks – defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation. He is the major player in the team where other tasks are inline to his plans and execution, making programming as Brook relates a “public practice instead of a private art”. This is still being applied in the current software development team set-up though the “one-man show” approach is not always the case. The roles of the chief programmer currently is divided into four other personalities or groups – System Analysts (design), Programmer (coding), Quality Assurance (testing), and Documentation (documents). If this approach will be explicitly followed, though armed with other support co-team members, might also lead to undesirable results knowing the flexibility, dynamism, and fast-paced requirements of current systems.

The Co-Pilot is the assistant of the chief programmer. He is an evaluator of what the chief does and also thinks of designs for the system. He knows the code intimately and might do coding but not as a primary duty. In current implementation, this one plays the role of assistant technical lead.

The Administrator is the one responsible for the management of other the team’s other operational aspects such as money, people, space, machines, and other administrative duties. In the current implementation, the roles played by this person are assumed by other personalities such as – CEO, Human Resource Manager, Accountant/Finance, Facilities and Equipment. Again, it would be cumbersome in the current setup for one person or group to do all these tasks mostly if the personnel number is quite huge.

The Editor is the one who scrutinizes and improves the documentation done by the chief programmer. A company editor or team editor is what this person plays in the current set-up. Though, again, everything is being done initially by the chief.

Two secretaries for administrator and editor which is also currently being applied.

The Program Clerk does all the archiving of technical records of a team in a programming-product library. This role is beneficial to the team mostly when codes are to be re-used and project archiving is necessary. Though current implementation makes this role an automated one with programs such as Online Archiving or the CVS. This allows the programmers or even QA and Documentation to archive and manage their files individually, at their own convenience, and real time. This also includes logging capability, continuous status update, and easy file retrieval.

The Toolsmith develops online and interactive special tools such as specialized utilities, catalog procedures and macro libraries that will allow the team to focus on their specific tasks. There are some software development companies who hire and maintain people who dedicatedly develop utilities or tools for the consummation of the organization. It does not only simplifies the task but it also introduces innovative ways on dealing with repetitive and manual manner of doing things.

The Tester is the one who assures quality by creating test cases based on functional requirements and creating data for the chief’s day-to-day debugging. This is still being applied in the current setup though the bulk of testing work is now assigned to the QA team instead of just by the chief programmer.

The Language Lawyer is the “expert” or “consultant” as what the current software development teams call them. They mastered the programming language being used by the chief programmer and advise on certain scenarios.

These are the people that compose the whole “surgical team”; each of which has a function to perform and an expected deliverable. Implementation of such approach according to Brooks will lead to the following results:

A) As compared to conventionally organized programmers where tasks are divided to different developers and design/implementation are different, the chief and the co-pilot are both aware of the design and code. This saves the labor of allocating space, disk access, and ensuring of conceptual integrity of work.

B) Since in a conventional team partners are equal, differences in judgement must be talked about or compromised. In the surgical team, the chief solves the differences unilaterally and specialization of the remainder team permits a radically simpler communication pattern among members.

Though if we are to apply such concept in the development of current software systems, it is still safe to say that such approach may seem inappropriate. Here are some of the considerations:

A) In a research entitled “The Role of Motivation and Risk Behaviour in Software Development Process” by Kenneth R Walsh and Helmut Schneider, they raised the concern on implementing such concept in ERP systems. According to them, a chief programmer may push a technical solution rather than a business solution. The responsibility for ERP projects rest with the line management because a successful implementation requires reengineering of business processes that are the responsibility of the respective managers. However, line managers often lack the understanding of information technology, and may take higher risks than appropriate.

B) It will be quite tedious for a chief programmer (or at most two programmers) to do the critical tasks of analysing to testing. Though supporters might verify, this might lead to a monopolized decision.

SO WHAT NOW?

So, what now?

This question poses the challenge to you, the reader. The beauty of software development does not only depend on the outcome of each project but primarily on how it is being done. We can follow a well-proven and well-tested approach or we take the risk of implementing a new one to see what happens. The “Surgical Team” approach may be appropriate to answer the need of doing large systems with a number of people and other factors or otherwise. Nonetheless, this option has been introduced to give you a wide array of possible approaches on a certain problem.

Once again, what now?

The answer lies in your hands.

REFERENCES

Details of this reaction paper are taken from the following resources:

BROOKS, F. (2009). The Mythical Man-Month – Anniversary Edition. 29-35.

PENDHARKAR, P., & RODGER, J. (2009). The Relationship between Software Development Team Size and Software Development Cost. Communications of the ACM, 52(1), 141-144. Retrieved from Business Source Elite database.

SAWYER, S. (2004). SOFTWARE DEVELOPMENT TEAMS. Communications of the ACM, 47(12), 95-99. Retrieved from Business Source Elite database.

WALSH, K. (2002) The Role of Motivation and Risk Behaviour in Software Development Process. 1-5.

http://en.wikipedia.org/wiki/Harlan_Mills

QUESTION 1:
Are system models readable or usable by/to users and clients?

This question can be answered directly by either YES or NO. Looking at the benefits this particular model can bestow, it is easier to say that the answer is the former. But checking its details particularly on aspects such as who is the intended user, what a specific model is for, and how it is used will show us the possibility of the latter.

THE CLIENTS
Let us first take a closer look on the group of people who will use and read these models – they are the clients.

In the real world, clients are diverse group of people who came from different walks of life but with one purpose – they asked to developed or purchased a software in order to answer a need , a requirement. More often than not, these people are just “end users” who know the basics of computing and would want a non-complicated, user-friendly, and easily accessible software for their everyday or specific use. Though, there are clients who are also technologically inclined whose professions are in line with software development. These people are expected to understand our language and lingo. They asked to develop or purchased the software beyond the conventional usage as it might be used as an integrating component to an existing application, an OEM that can also be sell to other customers, or just a plain research and development application.

WHAT A SPECIFIC MODEL IS FOR
If that is the case, we can derive to the fact that clients use or read the different system models based on their need. That is, if you are just an end user who wants to know how the system works, you use and understand basic models such as Context Models, Process Models in a High Level approach, or even just the Use Case. But if you are a type of the user who intentionally wants the system for purposes beyond the conventional usage and you have a solid background in systems development and programming then the other models or even all the models can be utilized.

Just imagine a real estate manager who just want a web application that showcases and transacts for their for-sale-properties, will you as an analyst provide the details such as Data Dictionary and Object Models showing the details on how your codes work from one class to another? It might be helpful but is unnecessary. These details are also classified to a software development company as what we usually provide the typical users the basic context and processes of the system and the software product itself.

HOW MODELS ARE USED
System Models are used primarily to understand the system. Like what Ian Sommerville said that these are used for the system’s different perspective – External, Behavioral, and Structural. The usability of a particular model as I reiterated in the earlier paragraphs depends on the user and his needs. This also conforms on how a particular model is used in a chosen software development model such as Rapid Development, Prototyping, or Waterfall. This is because of the possibility that a chosen software development model, may it be homogenous or hybrid, will depend on the user or client itself. Thus, if the client works closely to the developer like what is used in the Rapid Development and Prototyping, it is expected that most of the system models are understandable and usable to the client. But for the others such as Waterfall where user interaction comes in the initial requirement analysis, not all models are necessary.

In conclusion, are “all” system models readable and usable to the users or clients? This article clearly showcases that “IT DEPENDS”. Its readability and usability depends on who are the clients, what specific model is for, and how these models are used.

QUESTION 2
Would textual descriptions suffice to capture system requirements?

In a world where “instant” is becoming a fashion or a trend in order to acquire what a person wants, it is then inevitably true that describing a requirement in a textual form does not always make sense. A complex system that requires tedious processes might be textually described but alternatives could be a great contributory factor. Let us take for instance this article:

In an article dubbed “Integrating usability requirements that can be evaluated in design time into Model Driven Engineering of Web Information Systems”, Fernando Molina and Ambrosio Toval showcased the importance of Model Driven Engineering in order to produce quality and expected output based on the user requirements in a web based approach. An example is explicitly illustrating how the approach can be used.

But we still cannot deny the power of explaining system requirements in a textual way as this is a more convenient mechanism in some cases. Here are those:

a) Functional and Non-Functional Requirements are Well Defined in Textual Form
To avoid ambiguity amongst team members on a particular requirement, usage of text in order to clearly define a requirement is necessary. It is also easy to explain a non-functional requirement in a textual form than to use alternatives such as charts that needs more interpretation and complex representation. That is why a requirement document such as Software Requirement Specification (SRS) is used.

b) It Is Easier For A Developer
A straightforward need entails a straightforward instruction. Clearly, textual description is of great help.

c) Details are Presented Clearly
Though this is possible in the alternative way such as models but textual description can clearly explain what the user wants. Even the end client will not initially give the analyst a chart of what he wants. Textual description still is useful.

At the end, what really matters is the fact that the client was able to clearly explain his requirement; the analyst understood and described it clearly; and the developers created a system that specifically addressed the need. Textually done or not or both can be used in order to achieve this.

References:

Molina, F., & Toval, A. (2009). Integrating usability requirements that can be evaluated in design time into Model Driven Engineering of Web Information Systems. Advances in Engineering Software, 40(12), 1306-1317. doi:10.1016/j.advengsoft.2009.01.018.

Sommerville, Ian. (2007) Software engineering / Harlow, England ; Addison-Wesley, MLA Citation. Sommerville, Ian. Software Engineering.

ARMAN

Yes! It is been a while since the last time I posted an entry here. If I am not mistaken, I was then engaged in a company where web applications were our concern. Deadlines caused our sleepless nights and we have to cope with the technological change in order to develop a state-of-the-art applications for our clients.

But it is already a part of history – my history. I am in a different environment now doing a really new stuff. Still in computers but this time developing both applications and human beings. I develop applications for the purpose of addressing the immediate needs of my organization, friends, and even myself. This is also my way of learning new things and injecting something that would challenge my “know-how” on a certain approach. And from this learning, I develop human beings by being an educator. Sharing what I have learned and promoting the use of the technology for the betterment of life. Though the teaching process and its expected output is quite challenging as they come in a non-conventional way. Leaders are being molded – our country’s leaders to be more specific.

I am alive and kicking but this time going up a notch. Entries will be focusing on projects that I am currently developing plus the techniques that I have acquired from them (from simplest to biggest). This will also utilize the latest craze named “cloud computing” and might be a start of something big for that technology. Most importantly, this message threads, I firmly believe, will greatly contribute to the desire of injecting something “new” into a system that needs to be revitalized. A part of our lives where “what-ifs” comes more often. A dream that has yet to realize.

ARMAN

- INTRODUCTION -

I am currently working on a huge web-based application project for our customer in the United States. It is a customer (client) – company (server) end to end solution that tends to ease their business transactions by making them online – in short accessible anywhere. We are using the MVC pattern but haven’t implemented any of the existing Java Frameworks. Subdivided into three layers, Front End-Business Delegate-DAO, the said application runs on Tomcat Server (Web) and JBoss Server (Application)

Focusing on the Front End (client views), we have used the AJAX technology to asynchronously connect our JSP’s to our Servlets and do the necessary end to end processing of data (both request and JSON objects).

Now the big question is – how does our JSP sends and receives data to and from the server? Is it possible that a simple JSP could dynamically execute AJAX calls, form data and event handling, and present the result in an expected format?

Apparently, the answer is a big YES! And this is because of the javascript framework that we are currently using. It is, without further ado, called “PROTOTYPE”.

This Javascript framework allows you to develop dynamic web applications with ease at it provides functions that are of great help to dynamic content pages. Such functions are the following:

- Document Object Model Manipulation
- Object Oriented Programming in Javascript
- Data Manipulation
- XML and JSON data format support
- AJAX calls with ease

All you have to do is to import the prototype.js file in your page/application and its functions are ready for your usage.

This series will guide you on how to use the Prototype Framework. Actual web application examples are also given in order for you to use them on the go. Most of its contents are taken from the Prototype guide as well as from the consolidated examples on the web and on my actual work.

- UTILITY METHODS (PART 1) –

These might be the most useful methods of Prototype framework. If Java has core syntax and commands, these are the Prototype counterpart. You might see yourself using these methods over and over again as it acquires, manipulates, and presents data in your web document dynamically.

Note: DOM knowledge is a prerequisite on this part as these methods are well used on Form elements manipulation.

————————————————————————
$
Syntax: $(id/element)  HTML Element
————————————————————————

The conventional DOM way of acquiring an element in a web document is through the document.getElementById() syntax. Apparently, Prototype simplifies it by just using the dollar ($) sign and the id of the expected element to manipulate. Thus, this statement will return the actual element for further manipulation.

DOM: document.getElementById(‘username’);

PROTOTYPE: $(‘username’);

After acquiring the element, you can do the manipulation:
1) Alerting the value of the textbox:

var tBox = $(‘username’);
alert (tBox.value);

2) Changing the class name of the textbox

var tBox = $(‘username’);
tBox.className = ‘myTextBox’;

————————————————————————
$$
Syntax: $(css Rule)  Array of HTML Elements
————————————————————————

This is a great way to acquire multiple elements based on a rule. A replacement on either document.getElementsByTagName() or document.getElementsByClassName(). It will return an array of HTML Elements which you can iterate for manipulation.

DOM: document.getElementsByTagName(‘input’);

PROTOTYPE: $$(‘input’);
After acquiring the element, you can do the manipulation:
1) Alerting the value of the textboxes:

var tBoxes = $$(‘input’);
tBoxes.each(function(e){
alert (e.value);
});

Note: The .each() function is the Prototype way to iterate objects. It is an alternative for looping statements.