Bring a List of Questions

From the very first day, you should start thinking of questions to ask the customer to get a better idea of the project’s goals and scope.


These questions deal with what the system is supposed to accomplish and, to a lesser extent, how.

  • What should the system do?
  • Why are you building this system? What do you hope it will accomplish?
  • What should it look like? Sketch out the user Interface.
  • What response times do you need for different parts of the system? (Typically, interactive response times should be under five seconds, whereas reports and other offline activities may take longer.)
  • What reports are needed?
  • Do the end users need to be able to define new reports?
  • Who are the players? (ties to previous section)
  • Do power users and administrators need to be able to define new reports?
Data Needs

These questions help clarify the project’s data needs. Knowing what data is needed will help you start defining the database’s tables.

  • What data is needed for the user interface?
  • Where should that data come from?
  • How are those pieces of data related?
  • How are these tasks handled today?Where does the data come from?
Data Integrity

These questions deal with data integrity. They help you define some of the integrity constraints that you will build into the database.

  • What values are allowed in which fields?
  • Which fields are required? (For example, does a customer record need a phone number? A fax number? An email address? One of those but not all of them?)
  • What are the valid domains (allowed values) for various fields? What phone number formats are allowed? How long can customer names be? Addresses? Do addresses need extra lines
    for suite or apartment number? Do addresses need to handle U.S. ZIP Codes such as 12345? ZIP+4 Codes such as 12345-6789? Canadian postal codes such as T1A 6G9? Or other countries’ postal codes?
  • Which fields should refer to foreign keys? (For example, an address’s State field might need to be in the States table and a CustomerID field might need to be in the Customers table. I’ve seen customers with a big list of standard comments and a Comments field can only take those values.)
  • Should the system validate cities against postal codes? (For example, should it verify that the 10005 ZIP Code is in New York City, New York? That’s cool but a bit tricky and can involve a lot of data.)
  • Do you need a customer record before you can place orders?
  • If a customer cancels an account, do you want to delete the corresponding records or just flag them as inactive?
  • What level of system reliability is needed?
    • Does the system need 24/7 access?
    • How volatile is the data? How often does it need to be backed up?
    • How disastrous will it be if the system crashes?
    • How quickly do you need to be back up and running?
    • How painful will it be if you lose some data during a crash?

These questions focus on the application’s security.

  • Does each user need a separate password? (Generally a good idea.)
  • Do different users need access to different pieces of data? (For example, sales clerks might need to access customer credit card numbers but order fulfillment technicians probably don’t.)
  • Does the data need to be encrypted within the database?
  • Do you need to provide audit trails recording every action taken and by whom? (For example, you can see which clerk increased the priority of a customer who was ordering the latest iPod and then ask that clerk why that happened.)
  • What different classes of users will there be?
  • How many of each class of user will there be? Will only one person need access to the data at a time?Will there be hundreds or even thousands (as is the case with some Web applications)?
  • Is there existing documentation describing the users’ tasks and responsibilities?

These questions deal with the project’s surrounding environment.

  • Does this system enhance or replace an existing system?
    • Is there documentation describing the existing system?
    • Does the existing system have paper forms that you can study?
    • What features in the existing system are required? Which are not?
    • What kinds of data does the existing system use? How is it stored? How are different pieces of data related?
    • Is there documentation for the existing system’s data?
  • Are there other systems with which this one must interact?
    • Exactly how will it interact with them?
    • Will the new project send data to existing systems? How?
    • Will the new project receive data from existing systems? How?
    • Is there documentation for those systems?
  • How does your business work? (Try to understand how this project fits into the bigger picture.)

Source: Beginning Database Design Solutions, Stephens, R., pp. 67-69

EJB 3.0 with ADF Faces UI

An ADF Faces client is well suited for creating/retrieving database table rows in combination with an EJB 3.0 model. In a Model-View-Controller application in which the EJB 3.0 database persistence constitutes the model, the ADF Faces framework may be used for the view and controller components.

I have learned mapping a database table to an entity bean, wrapping the entity bean in a session bean, creating an Oracle ADF faces client user interface and testing the ADF Faces client user interface.

I highly recommend this book:


Symfony2 Framework – Introduction

Symfony is built to get back to basics: to develop tools that let you develop faster and build more robust applications, while staying out of your way.

You now know that the goal of any app is to interpret each incoming request and create an appropriate response. As an application grows, it becomes more difficult to keep your code organized and maintainble. Invariably, the same complex tasks keep coming up over and over again: persiting things to the database, rendering and reusing templates, handling form submissions, sending emails, validating user input and handling security.

So then, what is the Symfony Framework? The Symfony Framework is a PHP library that accomplishes two distinct tasks:

  1. Provides a selection of components(i.e. the Symfony Components) and third-party libraries (e.g. Swift Mailer for sending emails);
  2. Provides sensible configuration and a “glue” library that ties all of these pieces together.

The goal of the framework is to integrate many independent tools in order to provide a consistent experience for the developer. Symfony provides a powerful set of tools for rapidly developing web applications without imposing on your application.

For now, have a look at how migrating the blog from flat PHP to Symfony has improved life:

  • Your application now has clear and consistently organized code (though Symfony doesn’t force you into this). This promotes reusability and allows for new developers to be productive in your project more quickly;
  • 100% of the code you write is for you application. You don’t need to develop or maintain low-level utilies such as autoloading, routing or rendering controllers;
  • Symfony gives you access to open source tools such as Doctrine and the Templating, Security, Form, Validation and Translation components (to name a few);
  • The application now enjoys fully-flexible URLs thanks to the Routing component;
  • Symfony’s HTTP-centric architecture gives you access to powerful tools such as HTTP caching powered by Symfony’s internal HTTP cache or more powerful tools such as Varnish. This is convered in a later chapter all about caching.

Instead of the Welcome Page, you may see a blank page or an error page. This is caused by a directory permission misconfiguration. ❓ Watch the video to fix it.

Source: The Book, pp. 4-33

BleagleBone Black

Unlike the Arduino Uno, the microprocessor on the BBB cannot be replaced. If you damage the microprocessor, you will have to buy a new board! Here are some things that you should never do:

  1. Do not shut the BB down by pulling out the power jack/USB power. You should shut down the board correctly using a software shutdown (e.g., by pressing the power button once) or by holding the power button for about eight seconds for a “hard” power down.
  2. Do not place a powered BBB on metal (e.g., aluminum-finish computers) or on worktops with stray/cut-off wire segments, resistors, etc.
  3. Do not connect circuits that source/sink other than very low currents from/to the P8/P9 headers.
  4. The GPIO pins are 3.3V tolerant (the ADCs are 1.8V tolerant).
  5. Do not connect circuits that apply power to the P8/P9 pins while the BB is not powered on.

Here are two steps that you should always follow:

  1. Carefully check the pin numbers that you are using. There are 46 pins in each header, and it is very easy to plug into header connector 21 instead of 19.
  2. Read the SRM in detail before connecting complex circuits of your own design to the BBB.

If your BBB is dead and it is your fault, then I am afraid that after you perform all of the checks at, you will have to purchase a new board.

Source: Exploring BleagleBone, Molloy D., pp. 21-22