| |
If you have a raw text data with formatted HTML tags that come from search engine crawler or specific data sources and you need the text data without html tags, this method will do striping html tags from your string data type.
// remove html tage from string
public string RemoveHTML(string strText)
{
string TAGLIST =
";!--;!DOCTYPE;A;ACRONYM;ADDRESS;APPLET;AREA;B;BASE;BASEFONT;" +
"BGSOUND;BIG;BLOCKQUOTE;BODY;BR;BUTTON;CAPTION;CENTER;CITE;CODE;" +
"COL;COLGROUP;COMMENT;DD;DEL;DFN;DIR;DIV;DL;DT;EM;EMBED;FIELDSET;" +
"FONT;FORM;FRAME;FRAMESET;HEAD;H1;H2;H3;H4;H5;H6;HR;HTML;I;IFRAME;IMG;" +
"INPUT;INS;ISINDEX;KBD;LABEL;LAYER;LAGEND;LI;LINK;LISTING;MAP;MARQUEE;" +
"MENU;META;NOBR;NOFRAMES;NOSCRIPT;OBJECT;OL;OPTION;P;PARAM;PLAINTEXT;" +
"PRE;Q;S;SAMP;SCRIPT;SELECT;SMALL;SPAN;STRIKE;STRONG;STYLE;SUB;SUP;" +
"TABLE;TBODY;TD;TEXTAREA;TFOOT;TH;THEAD;TITLE;TR;TT;U;UL;VAR;WBR;XMP;TODAYSYSTEM;";
const string BLOCKTAGLIST = ";APPLET;EMBED;FRAMESET;HEAD;NOFRAMES;NOSCRIPT;OBJECT;SCRIPT;STYLE;";
int nPos1 = 0;
int nPos2 = 0;
int nPos3 = 0;
string strResult = "";
string strTagName = "";
bool bRemove;
bool bSearchForBlock;
nPos1 = strText.IndexOf("<");
while (nPos1 >= 0)
{
nPos2 = strText.IndexOf(">", nPos1 + 1);
if (nPos2 >= 0)
{
strTagName = strText.Substring(nPos1 + 1, nPos2 - nPos1 - 1);
strTagName = strTagName.Replace("\r", " ").Replace("\n", " ");
nPos3 = strTagName.IndexOf(" ");
if (nPos3 > 0) strTagName = strTagName.Substring(0, nPos3);
if (strTagName.Substring(0, 1) == "/")
{
strTagName = strTagName.Substring(1);
bSearchForBlock = false;
}
else bSearchForBlock = true;
if (TAGLIST.IndexOf(";" + strTagName.ToUpper() + ";", 0) > 0)
{
bRemove = true;
if (bSearchForBlock)
{
if (BLOCKTAGLIST.IndexOf(";" + strTagName.ToUpper() + ";") > 0)
{
nPos2 = strText.Length;
nPos3 = strText.IndexOf("</" + strTagName, nPos1 + 1);
if (nPos3 > 0) nPos3 = strText.IndexOf(">", nPos3 + 1);
if (nPos3 > 0) nPos2 = nPos3;
}
}
}
else bRemove = false;
if (bRemove)
{
strResult = strResult + strText.Substring(0, nPos1);
strText = strText.Substring(nPos2 + 1);
}
else
{
strResult = strResult + strText.Substring(nPos1);
strText = strText.Substring(nPos1 + 1);
}
}
else
{
strResult = strResult + strText;
strText = "";
}
nPos1 = strText.IndexOf("<");
}
strResult = strResult + strText;
strResult = strResult.Replace("\r\n\r\n", "\r\n");
return strResult;
}
When you loop through a DataTable object in order to find the match records and delete the rows, it can generally be achieved as below.
foreach (DataRow dr in oDataTable.Rows)
{
if(dr["Name"]) == "ChristopherThant")
dr.Delete();
}
However, after you've called the Delete() method from DataRow object, the index in DataRow collection was changed and it makes your looping breaks and thrown an error. Collection was modified; enumeration operation might not execute.
Some people suggest to commit the DELETE transaction out of the loop by calling AcceptChanges() method.
foreach (DataRow dr in oDataTable.Rows)
{
if(dr["Name"]) == "ChristopherThant")
dr.Delete();
}
oDataTable.AcceptChanges();
After I have tried all the possible methods, I finally come up with the decent solution which I've been using whenever I encounter into this situation.
Basically, you will need a method to repopulate the collection index of DataRow.
//With the DataRow[] ToArray(DataRowCollection collection) create a collection-object of datarows and so make sure that there won't be any errors
public static DataRow[] ToArray(DataRowCollection collection)
{
DataRow[] result = new DataRow[collection.Count];
collection.CopyTo(result, 0);
return result;
}
And just apply that method to your DataRow Collection.
foreach (DataRow dr in ToArray(oDataTable.Rows))
{
if(dr["Name"]) == "ChristopherThant")
dr.Delete();
}
XHTML pages can be read by all XML enabled devices and while waiting for the rest of the world to upgrade to XML supported browsers, XHTML gives the opportunity to write "well-formed" documents which work in all browsers and are backward browser compatible. Follow the rules below to write XHTML 1.0 Transitional compatible code. All pages can be validated against the official W3C DTD with this link: http://validator.w3.org/check/referer. Go http://www.w3schools.com/xhtml/ for complete XHTML reference.
Open with the Proper DOCTYPE & Namespace
XHTML documents must begin with tags that tell the browser how to interpret them. All library web pages must begin with the following DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
The declaration above should be typed (or cut and pasted) into the very top of every XHTML document, before any other code or markup.
The XHTML 1.0 Transitional DOCTYPE must be followed by this XHTML namespace declaration:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
If you’re working on an international site and your page will include non–ASCII characters, you can get by with a simple meta tag such as:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Note: Many XHTML pages begin with an optional XML prologue (<?xml>) that precedes the DOCTYPE and namespace declarations. Unfortunately, this XML prologue causes problems in many browsers and must be omitted from XHTML web pages.
Write all Tags in Lowercase
Unlike HTML, XML is case–sensitive. All XHTML tags and attributes must be typed in lowercase, e.g. <title>…</title>, <body>
Quote all Attribute Values
In HTML, you needn’t put quotation marks around attribute values. In XHTML, they must be quoted, e.g. height="55".
Close and Nest all XHTML elements Properly
In XHTML, every tag that opens must close, for example:
<p>This is valid XHTML.</p>
In XHTML, even “empty” tags such as <br> and <img> must close themselves by including a forward slash /> at the very end of the tag:
<br />
<img src="library.gif" />
In XHTML all elements must be properly nested within each other like this:
<b><i>This text is bold and italic</i></b>
Example: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd "> <html> <head> <title>Page Title</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <meta name="Keywords" content="…" /> <meta name="Description" content="..." /> <link rel="stylesheet" type="text/css" href="….css" /> </head> <body> <p>…</p> </body> </html>
Avoid Minimizing Attributes
Minimized attributes is valid in HTML, e.g. <input checked>.
Minimized attributes is invalid in XHTML, following is correct:
<input checked=”checked” />
Following is a list of the minimized attributes in HTML and how they should be written in XHTML:
| HTML | XHTML | | compact | compact="compact" | | checked | checked="checked" | | declare | declare="declare" | | readonly | readonly="readonly" | | disabled | disabled="disabled" | | selected | selected="selected" | | defer | defer="defer" | | ismap | ismap="ismap" | | nohref | nohref="nohref" | | noshade | noshade="noshade" | | nowrap | nowrap="nowrap" | | multiple | multiple="multiple" | | noresize | noresize="noresize" |
Use id Attribute to replace the name Attribute
HTML 4.01 defines a name attribute for the elements a, applet, frame, iframe, img, and map. In XHTML the name attribute is deprecated. Use id instead.
This is wrong:
<img src="picture.gif" name="picture1" />
This is correct:
<img src="picture.gif" id="picture1" />
To interoperate with older browsers for a while, you should use both name and id, with identical attribute values, like this:
<img src="picture.gif" id="picture1" name="picture1" />
Make JavaScript Compatible with XHTML
XHTML is subject to the same syntactical rules as XML. Because of this, an XHTML processor treats the characters < and & as markup, even if they reside inside a <script> block. When an XHTML processor sees these characters within the JavaScript code of a <script> block, it attempts to parse the JavaScript code as if it were markup, which causes the XHTML parser to fail.
To make all JavaScript code compatible with XHTML, if JavaScript code is written within XHTML page, you must place the JavaScript code within a CDATA section. A CDATA section in XML/XHTML starts with the characters <![CDATA[ and ends with the characters ]]>. Any characters within the starting and ending element of a CDATA section are not treated by the XML/XHTML processor as markup, thus preventing a conflict.
Here is an example of how to declare JavaScript code within a CDATA section:
Example:
<script type="text/javascript">
//<![CDATA[
alert("<This is compatible with XHTML>");
//]]>
</script>>
Note that JavaScript source code must be placed within the opening and closing elements of the CDATA section. The CDATA section itself should be commented out with a JavaScript single-line comment // as in the example above. This is so that the JavaScript interrupter does not interpret the CDATA markup as JavaScript, which would cause a JavaScript error.
Note: JavaScript code that is imported into an XHTML document from an external source file is always compatible with XHTML. Thus, any JavaScript code that place into an external JavaScript file and import into an XHTML file via the src attribute of the <script> tag will be valid. Here is an example:
<script type="text/javascript" src="external.js"></script>
download : Secure Software Development Life Cycle DocumentSecure Software Development Life CycleSecure software development life cycle describes phases of the software cycle and the order in which those phases are executed according to business requirements. In order to implement the applications that are required to provide secured processing, the following high level SSDLC model has been carefully adopted within software development team and exercise together with business management. 
Security measurement is upmost important to the services provided by e-commerce industries. And so software development team takes serious security measurement of each development phases and integration into standard software development processes. It also helps developers and managers looking for information on existing software development life cycle (SDLC) processes that address security.
The SSDL represents a structured approach toward implementing and performing secure software development. The SSDL approach mirrors the benefits of modern rapid application development efforts. Such efforts engage the stakeholders early on, as well as throughout analysis, design, and development of each software build, which is created in an incremental fashion.
Infrastructure security, such as firewall, DMZ, IDS management, Backup/recoverability and availability plans shall be in place. The focus of the SSDL described is to address secure development processes. No matter how strong the firewall rule sets are or how diligent the infrastructure patching mechanism is, if Web application developers haven't followed secure coding practices, attackers can walk right into the systems through port 80.
The following attack patterns must be applied through the SSDL
1. Define security/software development roles and responsibilities.
2. Understand the security regulations the system has to abide by, as applicable.
3. Define a security policy if none exists.
4. Define documented security requirements and/or attack use cases.
5. Develop and execute test cases for adherence to umbrella security regulations, if applicable. Develop and execute test cases for the security requirements/attack use cases described throughout this article.
6. Define secure coding guidelines, and train software developers and testers on them.
7. Test for adherence to secure coding practices.
8. Participate in threat modeling walkthroughs, and prioritize security tests.
9. Understand and practice secure deployment practices.
10. Maintain a secure system by having a patch management process in place, including evaluating exploitability.
As expanding demand of business practices, the framework of adopted SSDLC model shall be enhanced and adjusted accordingly as long as each phases are executed properly.
Software Development
Software development team exercises the proven software development model framework such as Microsoft’s The Trustworthy Computing Security Development Lifecycle, and the methodology that can leverage robust online applications and services.
The following Microsoft’s technology, servers and applications are utilized by the development team, but not limited to explore different technologies and platforms that can provide the best business solutions.
1. Microsoft .Net framework 2.0 and AJAX library
2. Visual Studio Professional Edition 2005
3. Visual SourceSafe 2005
4. Microsoft Office 2003
5. Microsoft Project 2003
6. Microsoft Visio 2003
7. SQL Server 2000
8. SQL Server 2000 Reporting Services
Requirement Gathering
During the requirement gathering phase, all the business requirements must be gathered and finalized the project scope by project manager, business analyst and stake holders. It is also important to bring in, as earliest as possible, every stake holders who can influence the project scope. The development team shall only involve determining the functionalities that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work.
If the requirements are similar to previous projects or may be exactly the same but different client, the development team can provide instant judgment for project timeframe based on previous project experience, historical data, design and architecture.
Specify Security Needs
As part of Secure Software Development Life Cycle (SSDL) model, it is required to specify security needs for the development during or after business requirements gathering phase. During the specifying security needs, development team shall discuss with a security advisor, infrastructure manager or network administrator (“security buddy”) to consider how security will be integrated into the development process, identify key security objectives, and otherwise maximize software security while minimizing disruption to plans and schedules.
The security advisor assists the team by reviewing requirements, making recommendations, and ensuring that the existing infrastructure and resources to support the project development team. Every application developed by the development team must be compliant with PCI standard and include all the potential security elements in the project to avoid security-related surprise late in the process.
The security specification is geared toward ensuring successful implementation of secure software. It has six primary components:
1. Security guidelines, rules, and regulations
2. Security requirements: attack use cases
3. Architectural and design reviews/threat modeling
4. Secure coding guidelines
5. Black/gray/white box testing
6. Determining exploitability
[Reference to PCI Security Enhancement and Guideline for more detail]
Design & Prototyping
SSDLC design phase involves two major parts; designing interface and designing application architecture. Basically, interface design is a very effective way of understanding all the user interface behavior while designing application architecture provides an overview of high level object models to the development team.
Graphic design team and system analyst shall work together in order to produce an interface design of the application based on the requirements and project scope discussed during the requirement gathering phase.
Prototype model of the application can be produced by using graphic and interface designs. Prototyping is also very beneficial for getting the end-user approval about what the final system would look like. Prototyping shall contain mock-up designs of items such as application screens, database layouts, and system architectures. End users, designers, developers, database managers, and network administrator shall review and refine the prototyped designs in an iterative process until they agree on an acceptable design. Audit, security, and quality assurance personnel should be involved in the review and approval process. Prototyping can enhance the team’s ability to design, test, and establish controls.
In addition to interface design & prototyping stage, use case analysis shall be initiated during this phase. Use case analysis is a technique for developing system specifications and design by analyzing the system from the user's point of view.
The results of use case analysis are:
- The system requirements will describe the system according to how the user will use the system.
- Customers will easily understand the system requirements document, so they can help review it to find errors.
- Designers will add to the system only what the system needs to satisfy its requirements, so the system will be as simple as possible
After finishing use case analysis and prototyping, the next activity is to do a high level design. The application architecture design is produced from the results of requirement gathering phase. This involves various UML methodology activities including the preparation of high-level object models, sequence diagrams, collaboration diagram, and data models. The end goal is to come up with a software architecture that can break the entire system into well-defined subsystems. All the subsystems, their public interfaces, and any subsystem interactions and dependencies are discussed in detail. This is the guiding light for all further design and development of the project. Application architects and senior members of the development team will have to play a vital role during this stage and this is the phase in which their focus lies.
The output of design & prototyping phase should carefully be documented. Detailed documentation enhances the development team’s ability to develop the programs and modify them during implementation phase. The documentation also helps management and QA team ensure final programs are consistent with original goals and specifications.
The whole team shall create initial testing, conversion, implementation, and training plans during the design phase. Additionally, the team shall draft user, operator, and maintenance manuals.
Application Control Standards: Application control standards enhance the security, integrity, and reliability of automated systems by ensuring input, processed, and output information is authorized, accurate, complete, and secure. Controls are usually categorized as preventative, detective, or corrective. Preventative controls are designed to prevent unauthorized or invalid data entries. Detective controls help identify unauthorized or invalid entries. Corrective controls assist in recovering from unwanted occurrences.
The standard shall be in place to ensure end users, network administrators, auditors, and security personnel are appropriately involved during initial project phases.
Input Controls
Automated input controls help ensure users accurately input information, systems properly record input, and systems either reject, or accept and record, input errors for later review and correction. Examples of input controls include:
+ Check Digits – Check digits are numbers produced by mathematical calculations performed on input data such as account numbers. The calculation confirms the accuracy of input by verifying the calculated number against other data in the input data, typically the final digit.
+ Completeness Checks – Completeness checks confirm that blank fields are not input and that cumulative input matches control totals.
+ Duplication Checks – Duplication checks confirm that duplicate information is not input.
+ Limit Checks – Limit checks confirm that a value does not exceed predefined limits.
+ Range Checks – Range checks confirm that a value is within a predefined range of parameters.
+ Reasonableness Checks – Reasonableness checks confirm that a value meets predefined criteria.
+ Sequence Checks – Sequence checks confirm that a value is sequentially input or processed.
+ Validity Checks – Validity checks confirm that a value conforms to valid input criteria.
Processing Controls
Processing controls help ensure systems accurately process and record information and either reject, or process and record, errors for later review and correction. Processing includes merging files, modifying data, updating master files, and performing file maintenance. Examples of processing controls include:
+ Batch Controls – Batch controls verify processed run totals against input control totals. Batches are verified against various items such as total dollars, items, or documents processed.
+ Error Reporting – Error reports identify items or batches that include errors. Items or batches with errors are withheld from processing, posted to a suspense account until corrected, or processed and flagged for later correction.
+ Transaction Logs – Users verify logged transactions against source documents. Administrators use transaction logs to track errors, user actions, resource usage, and unauthorized access.
+ Run-to-Run Totals – Run-to-run totals compiled during input, processing, and output stages are verified against each other.
+ Sequence Checks – Sequence checks identify or reject missing or duplicate entries.
+ Interim Files – Operators revert to automatically created interim files to validate the accuracy, validity, and completeness of processed data.
+ Backup Files – Operators revert to automatically created master-file backups if transaction processing corrupts the master file.
Output Controls
Output controls help ensure systems securely maintain and properly distribute processed information. Examples of output controls include:
+ Batch Logs – Batch logs record batch totals. Recipients of distributed output verify the output against processed batch log totals.
+ Distribution Controls – Distribution controls help ensure output is only distributed to authorized individuals. Automated distribution lists and access restrictions on information stored electronically or spooled to printers are examples of distribution controls.
+ Destruction Controls – Destruction controls help ensure electronically distributed and stored information is destroyed appropriately by overwriting outdated information or demagnetizing (degaussing) disks and tapes.
Implementation & Integration
The development implementation phase involves converting design specifications into executable programs. Effective development standards are included that programmers and other project participants discuss design specifications before programming begins. The procedures help ensure programmers clearly understand program designs and functional requirements.
To avoid programmers using various techniques to develop computer programs, development standards must be in place to address the responsibilities of application and system programmers. While application programmers are responsible for developing and maintaining end-user applications, system programmers are responsible for developing and maintaining internal programs that link application programs, web sites to system software and background service processes.
Web sites and application programs developed by the team are mostly large transaction-oriented programs associated with financial institutions and have been developed using different components and break-down programming techniques. The team primarily practices the concept of “object-oriented programming”. It centers on the development of reusable program modules and classification of data types (numbers, letter, dollars, etc.) and data structures (records, files, tables, etc.). Linking pre-scripted module objects to predefined data-class object reduces development times and makes programs easier to modify.
The most fundamental components are
-Data Object component
-Data Access Layer component
-Business Layer component
-Module Layer component
-User Interface component
Break-down programming technique requires each individual programmer to write and review program modules or components. Completed components are integrated with other components and reviewed again, often by senior developers or system analyst, to ensure the results properly interact.
Development Standard: The applications and web sites always contain sensitive information of credit card data, client profile and financial transaction data. Because of the sensitive nature of business data, development standard shall prohibit a programmer’s access to data, programs, utilities, and systems outside their individual responsibilities. It also establishes standards requiring programmers to document completed programs and development test results thoroughly. Appropriate documentation enhances a programmer’s ability to correct programming error and keep track of modification to the each program modules.
The following two documents are suggested to be produced by each developer after they have implemented their modules.
Development test(Unit test)
Development test ensures the application that it has been integrated successfully into release version and produces high-quality, scalable result. The result of development test can also bring more confidence level to the Management and QA team that the quality of development codes has been tested by the developers.
Change log
The advantages of making change log are to control every modification make to the source codes. If developers are required to make changes to the existing code modules in order to release for next the production turn, QA team will have to retest the application through out the whole QA process cycle. So, the development team will have to consider what the potential impacts are by making changes to the existing code modules and provide the necessary test scenario to the QA team.
In financial-oriented software applications, unnecessary changing to decimal point value can impact the significant amount of company revenue. In order to prevent such unnecessary changes to the existing application, change log will keep records of every single modification made. In addition, change log will also keep track of the every built produced by development team and control the application version.
Coding Standard: The team is using Microsoft .NET framework 2.0, and so coding standards must be documented properly according to Microsoft proven patterns. The document should be distributed among the team and make sure that every team members understand the coding practice and follow the standard patterns. The standardized, yet flexible, coding standards will enhance significantly the development team’s ability to decrease coding defects and increase the security, reliability, and maintainability of application programs. Coding reviewers or examiners shall evaluate the team’s coding standards and related code review procedures. To avoid the hidden security holes in the source codes embedded by the programmers for them to access the applications in production environment, code reviewers also make sure that there are not hidden security holes in the source codes before application is released for production environment.
Security Control
Management shall always maintain an up-to-date inventory list of membership account profile for each applications and web sites in production environment and also statistic report that shows how often member user access to the system and what modules most likely be used. It will help management to hold the security control over each individual member roles and account management.
Version Control
Development version control systems, sometimes referred to as concurrent version systems, assist the development team in tracking different versions of source code during development. Every application system built shall be recorded with related change request form. The frequency of change request form will reflect to the number of application built in order to release to the production environment. The more frequent of the change request, the higher of the built frequency. Management shall look up the frequency of application built as it reflects to the development time, testing time and manpower.
Testing and Quality Assurance
The testing phase requires the team to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components. Thorough testing is critical to ensuring systems meet the standard and end-user requirements.
Testing phases will be conducted by different teams into each level of development stages. The following diagram will demonstrate how the team conducts the each testing processes.
As preparation for test plan is coming down from top to bottom sequentially according to the software development life cycle, each testing phases shall go up from bottom to top and the quality of the product shall be certified by each team.
Basically, code review and unit test shall be conducted by the development team. System tests, Link testing, security testing and over all testing can be completed by the QA team. When QA team certified that the product is ready for the user acceptance test, then BA, PM and the client shall carry out the UAT. If UAT is completed, and then the client must sign off the approval and so the product can be considered to release into production environment.
The following test phases shall be executed by each appropriate team members.
Testing performs by Client Business Analyst, Project Manager
+Acceptance Testing – End users perform acceptance tests to assess the overall functionality and interoperability of an application.
Testing performs by QA Team
+End-to-End Testing – QA Team performs end-to-end tests to assess the interoperability of an application and other system components such as databases, hardware, software, or communication devices.
+Functional Testing – QA Team performs functional tests to assess the operability of a program against predefined requirements. Functional tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature’s code.
+Integration Testing – QA Team performs integration tests to assess the interfaces of integrated software components.
+Parallel Testing – QA Team performs parallel tests to compare the output of a new application against a similar, often the original, application.
+Regression Testing – QA Teams retest applications to assess functionality after programmers make code changes to previously tested applications.
+System Testing – QA Teams perform system tests to assess the functionality of an entire system.
Testing performs by Development Team
+Stress Testing – Development Team perform stress tests to assess the maximum limits of an application.
+String Testing – Development Team perform string tests to assess the functionality of related code modules.
+Unit Testing – Development Team perform unit tests to assess the functionality of small modules of code.
As part of secure software development life cycle, the following test scenarios must be carefully checked and tested for secure purpose.
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
[Reference to the Software Test Case Document for more detail]
Deployment
The deployment phase involves installing approved applications into production environments. Primary tasks include announcing the deployment schedule, training end users, and installing the product. Additionally, the team shall input and verify data, configure and test system and security parameters, and conduct post-deployment reviews. Management should circulate deployment schedules to all affected parties and should notify users of any deployment responsibilities.
Deployment can be performed with the approval of release management. Release management aware of what changes need to be included in the product release, product release request form will be provided with the detail description of change request.
Every product release or update in the production environment, the team must strongly exercise to have backup copy of existing system before new system actually replace it. After a system or an application is deployed in production environment, pre-existing data is manually input or electronically integrated to a new system. Verifying the accuracy of the input data and security configurations is a critical part of the implementation process. It can often run a new system in parallel with an old system until they verify the accuracy and reliability of the new system. Each team should document any programming, procedural, or configuration changes made during the verification process.
Maintenance
The maintenance phase involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements. To ensure modifications do not disrupt operations or degrade a system’s performance or security, the team shall establish appropriate change management standards and procedures.
Change management requires establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated.
Emergency changes may address an issue that would normally be considered routine, however, because of security concerns or processing problems, the changes must be made quickly. Emergency change controls should include the same procedures as routine change controls. Management shall establish abbreviated request, evaluation, and approval procedures to ensure they can implement changes quickly. Detailed evaluations and documentation of emergency changes should be completed as soon as possible after changes are implemented. Management should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes. If management is unable to thoroughly test emergency modifications before installation, it is critical that deployment team appropriately backup files and programs and have established back-out procedures in place.
Without having appropriate change request form, the development team shall not make any modification to the existing applications.
Maintenance Models
The quick fix model is an ad-hoc approach. Its goal is to identify the problem and then fix it as quickly as possible. Due to time constraints, the model does not pay attention to the long-term affects of the fixes. The advantage of this model is that it gets work done quickly with lower cost. For example, if a system is developed and maintained by only one person, then that person will know the system well enough to make changes in a short time without the need to manage detailed documentation.
The reuse oriented model assumes that existing program components could be reused. The steps for the reuse model are identifying the parts of the old system which have the potential for reuse, fully understanding the system parts, modifying the old system parts according to the new requirements, and integrating the modified parts into the new system.
Reuse Oriented Model
The iterative enhancement model considers that changes made to the system during the software lifetime make up an iterative process. This model was adapted from development to maintenance. The model has three stages. First, the system has to be analyzed. Next, proposed modifications are classified. Finally the changes are implemented. This model is not effective when the documentation of the system is not complete, as the model assumes that a full documentation of the system exists.
Iterative Enhancement Model
Addition to Software Development Life Cycle
Research & Innovation
In order to keep up with fast pace technology trend, the development team must always look into the new technologies, useful applications and tools, and then constantly research on what technologies and methods are adoptable for the growth of business.
Technical discussion and knowledge sharing among the team, and the result from technical research can speed up the development process and overcome the technical burden.
By bringing the innovated ideas into the development team can make smooth of process and enhancement to the existing system and application.
Code Analysis
Code analysis ensures the system that it has been written by following the standard development methodology and certain rules of coding style. If one developer is not available, another developer can simply take over the developing process as long as the codes have standard writing practice.
It is also easy to maintain the source codes, have version control and remove unnecessary files included into the project.
Without having proper in-depth code analysis, the application is also vulnerable to the developers who implement the system.
Code analysis procedure can keep track of application version that how many time system has been deployed and what changes has been made from previous release.
The following list should be carefully checked as part of standard secure coding guideline.
1. Authentication
2. Session Management
3. Access Control
4. Input Validation
5. Encoding
6. Data Protection
7. Using Services Securely
8. Error Handling
9. Logging and Intrusion Detection
10. Secure Configuration and Deployment
[Reference to the Technical Guideline for more detail]
Documentation
Software Documentation
The team should maintain detailed documentation for each application and application system in production. Thorough documentation enhances the team’s ability to understand functional, security, and control features and improves its ability to use and maintain the software. The documentation should contain detailed application descriptions, programming documentation, and operating instructions. Standards should be in place that identify the type and format of required documentation such as system narratives, flowcharts, and any special system coding, internal controls, or file layouts not identified within individual application documentation.
The development team must maintain documentation for developed programs and technical references.
The management team must consider access and change controls when assessing documentation activities. Change controls help ensure the team appropriately approve, test, and record software modifications. Access controls help ensure individuals only have access to sections of documentation directly related to their job functions and applications.
System documentation should include:
System Descriptions – System descriptions provide narrative explanations of operating environments and the interrelated input, processing, and output functions of integrated application systems.
System Documentation – System documentation includes system flowcharts and models that identify the source and type of input information, processing and control actions (automated and manual), and the nature and location of output information.
System File Layouts – System file layouts describe collections of related records generated by individual processing applications. For example, personnel may need system file layouts to describe interim files, such as sorted deposit transaction files, in order to further define master file processing requirements.
Application documentation should include:
Application Descriptions – Application descriptions provide narrative explanations of the purpose of an application and provide overviews of data input, processing, and output functions.
Layouts – Layouts represent the format of stored and displayed information such as database layouts, screen displays, and hardcopy information.
Program Documentation – Program documentation details specific data input, processing, and output instructions, and should include documentation on system security. Program listings/source code and related narrative comments are the most basic items in program documentation and consist of technical programming scripts and non-technical descriptions of the scripts. It is important that developers update the listings and comment documentation when they modify programs. Many software development tools are available that automatically create source listings and narrative descriptions.
Traditionally, designers and developers shall user flowcharts to present pictorial views of the sequencing of procedural programs. Flowcharts provide a practical way to illustrate complex programs and routines.
Programming techniques, such as object-oriented programming, have contributed to the use of dynamic flowcharting products. Maintaining detailed documentation of object-oriented code is particularly important because a primary benefit of the programming technique is the reuse of program objects.
Naming Conventions – Naming conventions are a critical part of program documentation. Software programs are comprised of many lines of code, usually arranged hierarchically into small groups of code (modules, subroutines, or components), that perform individual functions within an application. Programmers should name and document the modules and any related subroutines, databases, or programs that interact with an application. Standardized naming conventions allow programmers to link subroutines into a unified program efficiently and facilitate technicians’ and programmers’ ability to understand and modify programs.
Operator Instructions – The team should establish operator instructions regarding all processing applications. The guidance should explain how to perform particular jobs, including how operators should respond to system requests or interrupts. The documentation should only include information pertinent to the computer operator's function. Program documentation such as source listings, record layouts, and program flowcharts should not be accessible to an operator. Operator instructions should be thorough enough to permit an experienced operator who is unfamiliar with the application to run a program successfully without assistance.
End-User Instructions – Organizations should establish end-user instructions that describe how to use an application. Operation manuals, online help features, and system error messages are forms of instructions that assist individuals in using applications and responding to problems.
download : Secure Software Development Life Cycle Document
Naming Conventions- Use Camel case for function name which begins with a lowercase letter, and the first letter of each subsequent new word is uppercase with all other letters lowercase. - Use Pascal case for class name which begins with a capital letter, and the first letter of each subsequent new word is capitalized with all other letters lowercase. - Use Camel case for variable name which begins with a lowercase letter, and the first letter of each subsequent word is uppercase with all other letters lowercase.
- Use Upper case for constant or enum values.
- Use Hungarian notation for variable names to indicate the data type with a consistent prefix (bln – boolean; flt – floating point; int – integer; obj – object; str – string; img – image; arr - array).
- Variable names should demonstrate their purpose.
- All variables should be declared using the “var” keyword in first lines of code. In addition, all variables must be declared in functions to keep them local.
- Avoid using single character names, except the use of “i, j, k” as counters in “for” constructs.
-"is" prefix should be used for boolean variables and methods, for example isEditEnabled().
- The term "find" can be used in methods where something is looked up.
- The terms "initialize" or "init" can be used where an object or a concept is established.
Javascript Tag
- All Javascript tags should be in upper case.
- The Javascript text within the LANGUAGE=“ ” quotes should be spelled with an upper case J, the rest will be in lower case.
Example:
<SCRIPT LANGUAGE="Javascript">
<!--
// -->
</SCRIPT>
Indentation
All statements within a function will be indented with 1 hard tab (default tab size=8 spaces).
Example:
function setFocus(textObj)
{
textObj.focus();
textObj.select();
return true;
}
Functions
- All functions should have an open curly bracket on the next line, aligned immediately below the letter “f”.
- The close curly bracket should also align with the letter “f” and the open curly bracket.
- If a parameter is to be passed into the function, the ( ) brackets should be immediately after the function name with no spacing in between.
Example:
function setFocus(textObj)
{
textObj.focus();
textObj.select();
return true;
}
If Else Statements
- For single “if” statement, they should be placed in separate lines, indented with 1 hard tab. No curly brackets “{ }” should be used.
Example:
if (!checkNum(formObj.PIN0))
return false;
-In cases where more than one statement follows, the open curly bracket should be at the same line as the “if”, with a single space in between.
-The closing curly bracket should be aligned directly below the ‘if”.
-The “else” statement should be aligned immediately below the close curly bracket.
-Text within each bracket should be indented with 1 hard tab.
Example:
if (!checkNum(formObj.PIN0)) {
alert("Sorry, please enter numeric characters only.");
return false;
}
else if(someOtherCondition) {
doSomething();
return true;
}
else {
doSomething();
return true;
}
-In cases where the “if” statement is very long (rough guide 80 characters), it should be separated into another line indented with 1 hard tab.
Example 1:
if (valid_alpha.indexOf(aChar) == -1 &&
Upp_valid_alpha.indexOf(aChar) == -1)
return false;
Example 2:
if (valid_alpha.indexOf(aChar) == -1 &&
Upp_valid_alpha.indexOf(aChar) == -1) {
alert(“hello”);
return false;
}
For / While loop
Should follow the same style as “if else” statements.
Example 1:
for (var i=0; i<textObj.value.length; i++) {
var ch = textObj.value.charAt(i);
if (ch != ' ' && ch != '\t') {
alert(“hello”);
return false;
}
}
Example 2:
while(!isDone){
doSomething();
isDone = moreToDo();
}
Example 3:
do{
doSomething();
}while(isValid);
Switch Statement
Should follow the style below for Switch statements.
Example:
switch (condition){
case ABC:
statements;
break;
case DEF:
statements;
break;
default:
statements;
break;
}
Try Catch Statement
Should follow the style below for Try… Catch statements.
Example:
try (condition){
doSomething();
}catch(ex){
doSomething();
}finally{
doSomething();
}
Comments
- All classes and functions should contain comment sections that provide a description, parameters (if any), return value (if any), and change history.
- Any major sections of code should include comments to parlay its purpose.
- If possible, all variables should include a short comment describing their purpose; this utilizes the double forward slash (//) comment syntax.
Example:
function checkNum(textbox)
/*Description:
* Parameters:
* Return Value:
* Change History: Author/DateTime, Description
*/
{
if (!isNumeric(textbox.value)) {
alert("Sorry, please enter numeric characters only.");
textbox.focus();
textbox.select();
return false;
}
else
return true;
}
download : MembershipProvider Web Service Project with WSE(Web Service Security Enhancement)After I have created a generic WSE MembershipProvider web service that can generally be used by membership registration pages, I checked the codes and compiled it. Everything looked fine but when I started making a web service call from client side, it run into the error: The type System.Collections.Hashtable is not supported because it implements IDictionary.
I just realized that data travelling across between web service call and web services must be in the form the serialized XML structure. In my web service case, I used Hashtable data type as a parameter at one of the web service methods. Obviously, Hashtable datatype can not be serialized because it is not a zero-based numeric collection unlike ArrayList that implement IList interface.
In fact, Hashtable data type is a key collection that implement IDictionary interface. It contains items that can be retrieved by an associated key value of some kind. The contents of IDictionary collections are also usually sorted in some fashion based on the key value and can be retrieved in sorted order by enumeration.
I have found a solution created by Mark Richman and I thought I should also share at my site.
Passing an IList
Collections that can be converted into single dimensional arrays can be passed directly in a Web Service. For
example, an ArrayList of type string serializes to the following XML:
<?xml version="1.0" encoding="utf-8" ?>
<ArrayOfAnyType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<anyType xsi:type="xsd:string">MyString</anyType>
</ArrayOfAnyType>
Serializing an ArrayList referencing anything else than objects of type object raises an exception. That is the
reason for the restrictions on passing collections in the XML Serialization docs.
Passing an IDictionary as a Jagged Array
we can convert a name/value collection into a two column jagged array in which one column contains the key and the other contains the value. It’s pretty easy to write a two helper methods that convert between Hashtables and jagged arrays:
public object[][] ToJaggedArray(Hashtable ht)
{
object[][] oo = new object[ht.Count][];
int i = 0;
foreach (object key in ht.Keys)
{
oo[i] = new object[]{key, ht[key]};
i++;
}
return oo;
}
public Hashtable ToHashtable(object[][] oo)
{
Hashtable ht = new Hashtable(oo.Length);
foreach(object[] pair in oo)
{
object key = pair[0];
object value = pair[1];
ht[key] = value;
}
return ht;
}
To make use of these methods, simply change your WebMethod signatures from Hashtable/IDictionary to the jagged array. For example:
[WebMethod]
public Hashtable GetHashtable()
becomes:
[WebMethod]
public object[][] GetHashtable()
Serializing an IDictionary using XSD Types
we have exposed our WebMethods using types that can be serialized as XML, ASP.NET can
construct a proper SOAP envelope for our call:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetHashtableResponse xmlns="http://markrichman.com/webservices/">
<GetHashtableResult>
<ArrayOfAnyType>
<anyType/>
<anyType/>
</ArrayOfAnyType>
<ArrayOfAnyType>
<anyType/>
<anyType />
</ArrayOfAnyType>
</GetHashtableResult>
</GetHashtableResponse>
</soap:Body>
</soap:Envelope>
As you can see, the CLR object type is represented as the XSD type anyType.
The following codes are part of membership user create method for WSE MembershipProvider web service. You can also download the whole sample Visual Studio Project file at
download : MembershipProvider Web Service Project with WSE(Web Service Security Enhancement)
Cascading Style SheetsUsing CSS as part of standards-based web design helps develop sites that are both beautiful and widely accessible. We should strive to keep the styling of our sites as separate from content as possible. CSS should be used as the main basis for the layouts as well as styling of the content. Whenever possible, CSS code should validate.
Naming Conventions
Name the CSS classes according to the function of the element, and not the resulting appearance. Following are the recommended element names for main structural divs:
- Page container: container
- Branding/header section: branding
- Main navigation: nav-main
- Next navigation: nav-sub
- Alternate navigation levels: nav-sub1, nav-sub2
- Main content: content-main
- Columnar content: content-col1, content-col2
- Supplementary content: content-sub (such as related topics, a quote, etc)
- Footer section: footer
- Copyright/legal: legal
- Search: search
- Search results: search-results
Example: #branding Used for a header or banner to brand the site. #branding-logo Used for a site logo #branding-tagline Used for a strapline or tagline to define the site's purpose #nav Used to contain a navigation device. #nav-main Main or primary navigation #nav-section Navigation to pages within the current site section #nav-external Navigation to pages outside the site #nav-supp A supplementary list of links, perhaps in a footer. #nav-(whatever) A list of links named at a designer's descretion #search Related to search interface and search results. #search-input A search form #search-output Search results which could include a <div> or other markup including definition lists #content Used for content rather than for another purpose such as navigation #content-main The main content area #content-news News related content #content-(whatever) Could include any form of content, including #content-related, #content-quote etc. #siteinfo Used for various site related information #siteinfo-legal Copyright information etc. #siteinfo-credits Designer or other credits
General Guidelines
Keep CSS light to minimize download time. To accomplish the goal:
o Group selectors.
o Rely on inheritance.
o Reduce redundancy by using shorthand.
o Name selectors logically. For example, #container, #branding, #footer.
o Define property values using shorthand and optimized values when possible. For example {font:400 12px Lucida Grande, Arial, sans-serif;color:#f09;}.
- Use div layers and CSS to determine layout instead of tables. If tables must be used, avoid "nesting" tables and use a colgroup to define the width of columns. Of course, tables are appropriate for displaying tabular data.
- Do not create new, custom selectors if there are existing selectors in the base style sheet that will suffice.
- Avoid inline formatting, use classes and ids instead.
- Avoid classitis. Use divs containing semantically marked code over creating several classes.
Example: <div id="sidebar"> <h1>News and Events</h1> <p>Our .org has been <strong>In the News!</strong></p> <ul> <li><em>State of the Market Report</em><br />Byte and Switch<br />27 Oct 2005</li> <li><em>Org Rolls out Specs</em><br />GCN<br />05 Sep 2005</li> <li><em>Standard in the Works</em><br />Computerworld<br />14 Apr 2005</li> </ul> <a href="/more/">Read more</a> </div> Instead of <h1 class="smallblueheader">News and Events</h1> <p>Our .org has been <strong class="bluebold">In the News!</strong></p> <ul class="bluebulletlist"> <li><em class="title">State of the Market Report</em><br />Byte and Switch<br />27 Oct 2005</li> <li><em class="title">Org Rolls out Specs</em><br />GCN<br />05 Sep 2005</li> <li><em class="title">Standard in the Works</em>><br />Computerworld<br />14 Apr 2005</li> </ul> <a class="bluelink" href="/more/">Read more</a>
- Avoid specifying font heights in pixels. Give preference to relative sizes and em units, so that layouts scale to fit larger and smaller fonts. Font heights in pixels prevent IE users from resizing the text, which may render your site unusable for many visitors. Test the scalability of the pages with different fonts and sizes.
- Hacks: Use of CSS hacks, such as box model hacks to accommodate IE is acceptable. However, all "hacks" (ie IE5 only code) should be kept separate so it can be easily removed at a later date.
- Ordering Content: When possible, order content in the source by level of importance. This is a great for both accessibility and SEO.
Guidelines to Use Different CSS for Different Browsers
Follow the CSS Standards First
It is far easier to develop the CSS code for a highly standards-compliant browser like Mozilla and Opera first, and then only later add the workarounds to make the code work on IE.
It is also logical to write for a more standards-compliant browser first: sooner or later, Microsoft is bound to issue a newer version of IE that will have the existing CSS bugs fixed. When they do so, all you have to do is to remove the workarounds which you created and you're done. If you write your main style sheet with styles that are coded in a non-standard way to deal with IE bugs first, you will wind up having to rewrite everything when Microsoft fixes the bugs.
Use External Style Sheets and Take Advantage of the "Cascading" Aspect of CSS
Put all the standards-compliant CSS code in a separate (external) style sheet file that is loaded by every browser.
Then, when you find that a specific browser requires a workaround, use the methods listed below to load an additional style sheet designed specifically for that particular browser. The beauty of CSS is that you can redefine a different style for the same selector and have the last-defined style override all preceding definitions.
Placing the main standards-compliant style sheet and the browser-specific style sheets in different external files allow you to simply remove a particular file in the future should that version of the browser cease to be used.
Include or Exclude Style Sheets for different IE Browsers
One of the easiest things to do is to specify that a certain style sheet be loaded only by IE 5, 5.5, 6 (and later versions) and be excluded from those versions of IE.
Microsoft provides a non-standard extension that allows you to detect those versions of IE, and include or exclude code depending on those versions.
To cause a CSS file to be loaded by IE 6 and not other browsers, use the following code in the HEAD section of the web page:
Example:
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="iespecific.css" />
<![endif]-->
Likewise, for any version of IE 5 (including 5.0, 5.01, 5.5, etc), use the following:
Example:
<!--[if IE 5]>
<link rel="stylesheet" type="text/css" href="iespecific.css" />
<![endif]-->
To test for a whole range of versions of IE, you can use the comparison operators "lt" (less than), "lte" (less than or equal), "gt" (greater than), and "gte" (greater than or equal); and “!” (not equal) to exclude a certain style sheet.
Hide CSS from IE 5 and Below for Windows
If you place a comment immediately after a selector in a style sheet, IE 5 and earlier on Windows will ignore that selector.
In the following example, "Large text anyone?" will not be enlarged in IE 5 and earlier.
Example: <style type="text/css"><!-- p.largetext/* */ { font-size: 200% ; } --></style> … <p class="largetext"> Large text anyone? </p>
Hide CSS from Netscape 4
- Using the @import Rule
Use the @import rule to load an external style sheet will cause that style sheet to be ignored in Netscape 4.
For example, "not-netscape4.css" will not be included in the following rule:
Example:
<style type="text/css"><!--
@import url(not-netscape4.css);
--></style>
- Using the Media Attribute in the Link Tag
If you link to your style sheets with a media attribute other than "screen" using a line like the following, Netscape 4 will not load them.
Example:
<link rel="stylesheet" type="text/css"
href="not-netscape4.css" media="all" />
Even the following line will not work in Netscape 4:
<link rel="stylesheet" type="text/css"
href="not-netscape4.css" media="screen,print" />
After Microsoft had introduced the common language runtime (CLR) with .Net technology, all the developers are now able to implement different version of DLL files with the same file name in window platform. Most people says they have finally overcome the DLL hell. But, the question is how does an application really work having different DLL version? Some experienced .Net developers still don't know about the actual underlying process in the .Net platform.
When you develop an application on the .Net platform, you have your managed .Net codes and then compile it into assemblies. In fact, these assemblies are not directly tied or registered to a window process. Instead, the common language runtime (CLR) isolates this managed code by creating separate logical partitions within a process called an application domain. A single process may contain multiple application domains, each of which is hosting distinct pieces of code encapsulated in assemblies. This subdivision of a traditional Windows process offers several benefits provided by the .NET Framework.
The main benefits are as follows:
- Application domains provide the operating system–neutral nature of the .NET platform by abstracting away the concept of an executable or library.
- Application domains can be controlled and (un)loaded, as you want.
- Application domains provide isolation for an application or within a process where multiple application domains live. Application domains within a process are independent of each other and as such remain functional when one fails the other.
A .NET application requires a hosting Windows process. Inside that Windows process, you can host multiple .NET application domains. An application domain is the means for the .NET CLR to isolate the managed code from Windows. The CLR automatically creates one default application domain in each worker process where it is initialized in a process. The default application domain is not unloaded until the process in which it runs shuts down. The CLR controls the shutdown of the default application domain.
After I had worked, as a Technical Lead with MediaCorp Co. Ltd, in the Web Garden environment where Window 2003 Servers run load balancing to host multiple news web sites, I had come across to setting the multiple web applications under IIS 6.0. The coolest thing of IIS 6.0 is you can have application pools that can shared among sites and applications, where each application runs in its own application domain.
An application pool is a separate Windows worker process called W3wp.exe and is started only when it needs to start. In other words, IIS comes with an application activation model that allows IIS to start-up an application pool when it receives a request for a particular application that is bound to that application pool. This enables IIS to host several thousands of applications on one server without keeping several thousand processes running.
When you are hosting multiple web sites under IIS 6.0, you definitely don't want to use DefaultAppPool for each web sites. Because when changing the Web.config file or assemblies in the Bin folder, the application domain will be recycled. It means the application pool and associated processes under that application domain will be reset. Any modification made to one web site will effect to the other web sites if it is sharing the same application pool.
So, be sure to have separate application pool for each web sites and let them run under its own processing domain.
Demo:
I have created the two web sites and two application pools for each web site.
Right click the web site and select the property.
Configure the application pool at web site property window as below
download : 1) Preparing For the Project Management Professional PMP Certification Exam.pdf2) PMP Exam Cram Second Edition.chm3) The Art Of Project Management.chm4) IT Project Management On Track From Start To Finish Second Edition.chm5) A Guide To The Project Management Body Of Knowledge PMBOK Guides.chm6) Passing The PMP Exam How To Take It And Pass It.chm7) PMBOK Third Edition.pdfAfter having studied the project management subject as a scholar, I have come to understanding the fact that the culture of functional project management is completely different from the mindset of technical leadership. While technical leads are focusing on application infrustructure and following the software development life cycle, project manager's aim is to achieve the project objective within specific time frame. 90% of project manager's tasks are opening the communication channels and making sure all the stakeholders are involved in the project.
It wasn't bad at all to study project management even if you are a hardcore software engineer. I know most of the application developer do not want to sit in the meeting room while management and HR are trying to explain company objectives, rules and regulation. Those are the kind of hardcore developers who do not want to deal with people and meetings, but only wants you to tell what functionalities you want, what layout and interface you like. They will put earphone on and start working until their brains are exploded. Believe me, I used to work until 6 o'clock in the morning the whole week when I was in Japan. Work ethic in Japan is really strong.
But after ten years being a hardcore programmer, constantly believing that the creating of programming codes is an art form, I've come to the point to realize that I need to slow down my paces and manage my own tasks and schedule. Perhaps, I am getting older. :-)
Project management really helps managing the stressful tasks by breaking down into smaller pieces and boost your ability to do proper documentation, communication skill to response and feedback immediately. It will also give you healthier and smarter working style. Right now, I am popping out to gym for 1 hour during my lunch break and still maintain my work schedule.
Here, I have a collection of references for those who want to study project management subject. It can also be a big help if you are planning to sit PMP certificate exam from PMI.org (Project Management Institute). I was a member of PMI and have a certificate of PMP courses.
download :
1)Preparing For the Project Management Professional PMP Certification Exam.pdf
2)PMP Exam Cram Second Edition.chm
3)The Art Of Project Management.chm
4)IT Project Management On Track From Start To Finish Second Edition.chm
5)A Guide To The Project Management Body Of Knowledge PMBOK Guides.chm
6)Passing The PMP Exam How To Take It And Pass It.chm
7)PMBOK Third Edition.pdf
Sometime you find it quite tedious and difficult using CSS style sheet to position and align the images and other set of HTML blocks to layout into more than one column. Although it is not recommended to use TABLE tag to layout content columns, some developers are still using it. Most people say using TABLE is cumbersome and not very semantic, but I have to put some TABLE usages for those who couldn't get away with it.
Before you design your web page, try to visualize it in a form of rows and columns to position the contents of your page into different location.
Take a look at the example below.
<table> tag is a set of rows and columns
<tr> tag represents rows
<td> tag represents columns
Of course, every opening html tag must end with closing end tag;
i.e <td> </td> forms one column which MUST reside within <tr> and </tr> tag.
<tr> </tr> forms one row which MUST in turn reside within <table> and </table> tag.
| 1st Row, 1st Column | 1st Row, 2nd Column | | 2nd Row, 1st Column | 2nd Row, 2nd Column |
| | <table border="1"> | | <tr> <td>1st Row, 1st Column</td> <td>1st Row, 2nd Column</td> </tr> | | <tr> <td>2nd Row, 1st Column</td> <td>2nd Row, 2nd Column</td> </tr> | | </table> |
|
You can create multiple rows and columns as many as you want. And you can even create another table into a column cell.
Let's look at the another example.
| 1st Row, 1st Column | | 1st Row, 1st Column | 1st Row, 2nd Column | | 2nd Row, 1st Column | 2nd Row, 2nd Column |
| | 2bd Row, 1st Column | 2nd Row, 2nd Column |
I just put the another table into 1st Row, 2nd Column cell between <td> and </td> tag.
| <table border="1"> | <tr> <td>1st Row, 1st Column</td> <td>| <table border="1"> | | <tr> <td>1st Row, 1st Column</td> <td>1st Row, 2nd Column</td> </tr> | | <tr> <td>2nd Row, 1st Column</td> <td>2nd Row, 2nd Column</td></tr> | | </table> |
</td> </tr> | | <tr> <td>2nd Row, 1st Column</td> <td>2nd Row, 2nd Column</td> </tr> | | </table> |
Sometime you will need to have the different layout.
Layout I.
| 1st Row, 1st Column | | 2nd Row, 1st Column | 2nd Row, 2nd Column |
| | <table border="1" > | | <tr> <td colspan="2">1st Row, 1st Column</td> </tr> | | <tr> <td>2nd Row, 1st Column</td> <td>2nd Row, 2nd Column</td> </tr> | | </table> |
|
Layout II.
| 1nd Row, 1st Column | 1st Row, 2nd Column | 1st Row, 3rd Column | | 2nd Row, 1st Column |
| <table border="1" > | | <tr> <td>1st Row, 1st Column</td> <td>1st Row, 2nd Column</td> <td>1st Row, 3rd Column</td> </tr> | | <tr> <td colspan="3">2nd Row, 1st Column</td> </tr> | | </table> |
Layout III.
| 1st Row, 1st Column | 1st Row, 2nd Column | | 2nd Row, 1st Column |
| | <table border="1"> | | <tr> <td>1st Row, 1st Column</td> <td rowspan="2">1st Row, 2nd Column</td> </tr> | | <tr> <td>2nd Row, 1st Column</td> </tr> | | </table> |
|
Layout IV.
| 1st Row, 1st Column | 1st Row, 2nd Column | | 2nd Row, 2nd Column |
| | <table border="1"> | | <tr> <td rowspan="2">1st Row, 1st Column</td> <td>1st Row, 2nd Column</td> </tr> | | <tr> <td>2nd Row, 2nd Column</td> </tr> | | </table> |
|
download : library files with demo codesThere are a lot of method available for creating custom attributes in your app.config or web.config configuration file but every method must implement IConfigurationSectionHandler interface. By categorizing the different attributes in your project configuration file, it makes your project more easier to handle different group of configuration setting.
For example if you don't want to mix database configuration setting with ftp configuration setting, you can try as below.
<!--DB Provider Type OldDB=0 MS SQL=1 Oracle=2-->
<DBType>
<add key="MS ACCESS" value="0"/>
<add key="SQL Server" value="1"/>
</DBType>
<FTP>
<add key="FTPIP" value="1.1.1.1"/>
<add key="FTPPort" value="21" />
<add key="FTPUser" value="xxx"/>
<add key="FTPPW" value="xxx"/>
<add key="FTPTransferType" value="1"/>
<add key="FTPChDir" value=""/>
</FTP>
<appSettings>
....
</appSettings>
But in order to access your own custom attributes, DBType and FTP, you need to create your own handler by implementing the IConfigurationSectionHandler interface and it's methods.
Create a AppSettingHandler.cs file and generate a dll file.
Add your AppSettingHandler into your configuration file. App.config or Web.config
Reference an assembly dll file generated with AppSettingHandler.cs.
Now, you can access your own custom attribute "DBType" with ConfigurationManager class.
The code will be as below.
Hashtable dbList = AppConfig.GetAppValueList("DBType");
AppConfig is a class that allow you to use GetAppValueList static method.
download : library files with demo codes
download : 1) Christopher Thant's Application Architecture (PDF)2) Ready to use sample project (Visual Studio 2005)3) Microsoft's Application Architecture (PDF)Application ArchitectureThe core architecture of my web applications is designed based on layer model which can also be adapted to all kind of web and window applications. In approach to engineering the core architecture, Microsoft’s proven theory of pattern and practice factory class models are constructed and molded on top of the existing layer model. 
By having different layers in implementing the core architecture, it provides the advantages of
- Flexibility to reuse the existing controls, modules and codes
- Easy Maintenance
- Rapid Development
- Security Enhancement
Data Object Layer
Namespace : CHRISTOPHERTHANT.WEB.DO
Data object layer represents a logical presentation of physical database tables. One data object can represent one database table and map all the database table fields with appropriate .Net data types. Relational model between multiple database tables can also be desingned in each data objects by embedding one data object into another and relating different data objects.
Relational model of data objects in data object layer also decides capability to providing business requirements. If necessary, logical data object can be created without needing to create a new database table, and then defined appropriate relationship with other data objects.
Example : the following data object relationship can provides multi shipping and multi merchant.
All the data object classes are inherited from BaseDO class in which fundamental methods are defined. The definitions of enum data type can also be defined in BaseDO class.
The most fundamental methods defined in BaseDO class are
1. IsDirty
IsDirty method determines whether inheriting data object is currently in use or not.
2. ModifiedBy
ModifiedBy method is a basic data field for every data object to accept the name of user who modified the data.
3. ModifiedDate
ModifiedDate is the date that data is modified
4. Clear
Clear method clears and reset the currently existing data value from IsDirty, ModifiedBy and ModifiedData method.
Data Access Layer
Namespace : CHRISTOPHERTHANT.WEB.DAL
Data access layer is a place where actual database store procedure calls take place. Basically, each potential business modules can have one or more data access files, and those data access files can reference to one or more data objets from data object layer.
For example:
Order module has OrderInfoDA and OrderDetailDA data access file.
OrderInfoDA data access file references to OrderInfoDO, OrderInquiryDO.
OrderDetailDA data access file references to OrderDetailDO, ShipDetailDO, MessageDO.
Business Layer
Namespace : CHRISTOPHERTHANT.WEB.BL
Business layer provides data returned from data access layer and has only standard data sources and raw data for business needs. Data in business layer are unclean, unformatted and not ready yet to easily plug into the application layer, but all the data required for application layer are loaded into business layer.
Suggested practice in business layer is to have one business layer file for one business module in order to avoid complication but maintain the standard business rules.
For example, order module should have only one business layer file, i,e OrderInfoBL. One business layer file can call methods from multiple data access layer files and also reference to multiple data objects.
Module Factory Layer
Namespace : CHRISTOPHERTHANT.WEB.ML
Module factory layer is an application oriented layer and designed to minimize the codes required to include in the application layer. Instead of application layer directly access to data object layer, data access layer and business layer, module factory layer intercepts between application layer and business layer, and guarantee the application layer that if only the provide clean, secured and reliable data sources for the whole application.
Module factory layer is also tied to the application and only necessary business modules shall be included in the module factory project library. Each business modules can be accessed through proper factory class model. The purpose of having factory classes to access to the required data source is that if the data object is already crated for the requested data source in the memory, it won’t create the duplicated same data object in the memory again and return the existing data object.
Physical file structure of module factory layer
Classes in module factory layer are inherited from BaseObject static parent class. All the potential common methods shall be defined in BaseObject static class, and so it can be called from either inheriting class or call the method independently as BaseObject.MethodName().
As module factory layer is application oriented, it is required to have the ability to access to the application configuration setting which is defined in different application project. In order to obtain the necessary configuration data from another application project, interface for site configuration class is defined and cast the methods from inheriting site configuration class.
Application Layer
Namespace : CHRISTOPHERTHANT.WEB.UI
Application layer has the following group of functionalities
- GUI layouts
- Graphics
- Animation
- Control components
- Events
- Manipulation
- Business logics
and each functionality has to specifically implement stage by stage.
Model-View-Controller (MVC) structure in the application layer is
.Net 2.0 web application will have three fundamental built-in primary level controllers; MasterPage, UserControl, and Page. Each controller should also reproduce second level BaseMasterPage, BaseUserControl and BasePage custom classes. Having those base custom classes ensures the application that certain type of methods, objects, and business rules are in one single place, and it can be used by all inheriting classes.
Those base classes also have interaction with module factory layer, and create module factory objects.
Sample for BasePage class:
download :
1) Christopher Thant's Application Architecture (PDF)
2) Ready to use sample project (Visual Studio 2005)
3) Microsoft's Application Architecture (PDF)
|