How to avoid Conflict in jQuery

Many JavaScript libraries use $ as a function or variable name, just as jQuery does. In jQuery's case, $ is just an alias for jQuery, so all functionality is available without using $. If we need to use another JavaScript library alongside jQuery, we can return control of $ back to the other library with a call to $.noConflict():

Creates a different alias instead of jQuery to use in the rest of the script.

var $j = jQuery.noConflict();
// Do something with jQuery
$j("div p").hide();

// Do something with another library's $()
$("content").style.display = 'none';

404 Page on a Static Site

Here's a very quick, but very useful trick. You can catch 404 errors (page not found) on a static site and serve up a custom 404 page with a one-liner in your .htaccess file:

ErrorDocument 404 /404.php

The "/404.php" part is the path to whatever file you want to serve up as the error page.

Remember that the .htaccess file works on Apache servers only. I say "static" sites, because if you are using a CMS system already (like WordPress), there is already a system in place for catching 404 errors and this is unnecessary.

create windowed applications with no system chrome

To  build a AIR application with custom window(which has your own shape), try the fallowing:

In the <project_root>/src folder, open the XML file named "<your_project_name>-app.xml" and modify the two lines:

<!--<systemChrome>none</systemChrome>-->
to
<systemChrome>none</systemChrome>

and

<!--<transparent></transparent>-->
to
<transparent>true</transparent>

Then in your main page,

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" showFlexChrome="false">

<mx:Script>
<![CDATA[
public function startMove(event:MouseEvent):void {
stage.nativeWindow.startMove();
}
]]>
</mx:Script>

<mx:Image id="mainPanel"  mouseDown="startMove(event)"  x="10" y="10" width="300" height="200"
source="myBg.gif /*path to a transparency image*/" scaleContent="true" />

Data Storage and Data flow

Data Storage and Data Flow 

SAP NetWeaver BI offers a number of options for data storage. These include the implementation of a data warehouse or an operational data store as well as the creation of the data stores used for the analysis.

Architecture

A multi-layer architecture serves to integrate data from heterogeneous sources, transform, consolidate, clean up and store this data, and stage it efficiently for analysis and interpretation purposes. The data can be stored with varying granularity in the layers.

●      Persistent Staging Area

After being extracted from a source system, data is transferred to the entry layer of the Enterprise Data Warehouse, the persistent staging area (PSA). The data from the source system is stored unchanged in this layer. It provides the backup status at a granular level and can offer further information at a later time in order to ensure a quick restart if an error occurs.

●      Data Warehouse

The way in which data is transferred from the PSA to the next layer incorporates quality-assuring measures and the clean up required for a uniform, integrated view of the data. The results of these first transformations and cleanups are stored in the data warehouse layer. It offers integrated, granular, historic, stable data that has not yet been modified for a concrete usage and can therefore be seen as neutral. The data warehouse forms the foundation and the central data base for further (compressed) data retentions for analysis purposes (data marts). Without a central data warehouse, the enhancement and operation of data marts often cannot be properly designed.

●      Architected Data Marts

The data warehouse layer provides the mainly multidimensional analysis structures. These are also called architected data marts. Data marts should not necessarily be equated with added or aggregated; highly granular structures that are only oriented to the requirements of the evaluation can also be found here.

●      Operational Data Store

An operational data store supports the operational data analysis. In an operational data store, the data is processed continually or in short intervals, and be read for operative analysis. In an operational data store, the mostly uncompressed datasets therefore are quite up-to-date, which optimally supports operative analyses.

Data Store

Various structures and objects that can be used depending on your requirements are available for the physical store when modeling the layers.

In the persistent staging area (PSA), the structure of the source data is represented by DataSources. The data of a business unit (for example, customer master data or item data of an order) for a DataSource is stored in a transparent, flat database table, the PSA table. The data storage in the persistent staging area is short- to medium-term. Since it provides the backup status for the subsequent data stores, queries are not possible on this level and this data cannot be archived.

Whereas a DataSource consists of a set of fields, the data stores in the data flow are defined by InfoObjects. The fields of the DataSource must be assigned with transformations in the SAP NetWeaver BI system to the InfoObjects. InfoObjects are thus the smallest (metadata) units within BI. Using InfoObjects, information is mapped in a structured form. This is required for building data stores. They are divided into key figures, characteristics and units.

●      Key figures provide the transaction data, that is the values to be analyzed. They can be quantities, amounts, or numbers of items, for example sales volumes or sales figures.

●      Characteristics are sorting keys, such as product, customer group, fiscal year, period, or region. They specify classification options for the dataset and are therefore reference objects for the key figures. Characteristics can contain master data in the form of attributes, texts or hierarchies. Master data is data that remains unchanged over a long period of time. The master data of a cost center, for example, contains the name (text), the person responsible (attribute), and the relevant hierarchy area (hierarchy).

●      Units such as currencies or units of measure define the context of the values of the key figures.

Consistency on the metadata level is ensured by your consistently using identical InfoObjects to define the data stores in the different layers.

DataStore objects permit complete granular (document level) and historic storage of the data. As for DataSources, the data is stored in flat database tables. A DataStore object consists of a key (for example, document number, item) and a data area. The data area can contain both key figures (for example, order quantity) and characteristics (for example, order status). In addition to aggregating the data, you can also overwrite the data contents, for example to map the status changes of the order. This is particularly important with document-related structures.

Modeling of a multidimensional store is implemented using InfoCubes. An InfoCube is a set of relational tables that are compiled according to an enhanced star schema. There is a (large) fact table (containing many rows) that contains the key figures of the InfoCube as well as multiple (smaller) surrounding dimension tables containing the characteristics of the InfoCube. The characteristics represent the keys for the key figures. Storage of the data in an InfoCube is additive. For queries on an InfoCube, the facts and key figures are automatically aggregated (summation, minimum or maximum) if necessary. The dimensions combine characteristics that logically belong together, such as a customer dimension consisting of the customer number, customer group and the steps of the customer hierarchy, or a product dimension consisting of the product number, product group and brand. The characteristics refer to the master data (texts or attributes of the characteristic). The facts are the key figures to be evaluated, such as revenue or sales volume. The fact table and the dimensions are linked with one another using abstract identifying numbers (dimension IDs). As a result, the key figures of the InfoCube relate to the characteristics of the dimension. This type of modeling is optimized for efficient data analysis. The following figure shows the structure of an InfoCube:

You can create logical views (MultiProviders, InfoSets) on the physical data stores in the form of InfoObjects, InfoCubes and DataStore objects, for example to provide data from different data stores for a common evaluation. The link is created across the common Info Objects of the data stores.

The generic term for the physical data stores and the logical views on them is InfoProvider. The task of  an InfoProvider is to provide optimized tools for data analysis, reporting and planning.

Data Flow

The data flow in the Enterprise Data Warehouse describes how the data is guided through the layers until it is finally available in the form required for the application. Data extraction and distribution can be controlled in this way and the origin of the data can be fully recorded. Data is transferred from one data store to the next using load processes. You use the InfoPackage to load the source data into the entry layer of SAP NetWeaver BI, the persistent staging area. The data transfer process (DTP) is used to load data within BI from one physical data store into the next one using the described transformation rules. Fields/InfoObjects of the source store are assigned to InfoObjects of the target store at this time.

You define a load process for a combination of source/target and define the staging method described in the previous section here. You can define various settings for the load process; some of them depend on the type of data and source as well as the data target. For example, you can define data selections in order to transfer relevant data only and to optimize the performance of the load process. Alternatively, you can define if the entire source dataset or only the new data since the last load should be loaded into the source. The latter means that data transfer processes automatically permit delta processing, individually for each data target. The processing form (delta or entire dataset) for InfoPackages, that is the loading into the SAP NetWeaver BI System, depends on the extraction program used.

Fixing libmysql.dll issue in Rails

While working on rails with mysql as database you may got error like this "This application has failed to start because libmysql.dll was not found. Re-installing the application may fix this problem" while executing the code 'rake db:create'. If that so, then fallow the fallowing steps:

1. type the command in the console

gem install mysql

(this is for windows, if you are  using linux os add sudo at the beginning)

2. Copy the libmysql.dll found in the mysql installation directory (mysql\bin) and paste it in your ruby installation directory (ruby\bin).

3. Restart the server.

thats all, it will work now.