Sunday, April 24, 2011

Inheritance vs compositon

Why Inheritance and Not Composition?
Whenever a design pattern uses inheritance as a key element instead of composition, you need to consider the reason. To understand the reason, you need to fully understand the principle of favoring composition over inheritance as a general principle in good OOP. The principle’s established because of certain advantages of composition over inheritance, especially the composition advantage of not breaking encapsulation. However, Gamma, Helm, Johnson and Vlissides (GoF) note that inheritance also has certain advantages. One such advantage is that when using subclasses where some but not all operations are overridden, modifying the reused implementation is easier.

reference: Oreilly Actionscript 3.0 design patterns p.335

Sprite vs MovieClip

http://www.theflashstudio.net/articles/movieClips.php

Movie Clips

MovieClip merely adds the timeline capability to the Sprite class, and are reusable pieces of flash animation - consisting of one or more graphic/button symbols - thus they are flash movies within your flash movie. They have their own non-restricted Timeline (any number of layers and frames - just like the main timeline) that plays independent of the main movie's Timeline. The best thing about using movieclips is that you can control them from actionscript - you can change their dimensions, position, color, alpha, and other properties and can even duplicate and delete them.

Sprites

The Sprite class is new in ActionScript 3.0. It provides an alternative to the functionality of the MovieClip class. Sprites and Movie Clips are virtually identical in what they can hold and what they can do. Sprite is a type of DisplayObject and it is the class that MovieClip directly extends from, (so all MovieClips are Sprites). Use Sprites when you want to draw shapes with ActionScript. Sprites are generally the display object to use as they are highly functional and take little memory. Sprites do not have timelines so if you would like to create an animation contained within the display object, a Movie Clip is the display object to use.



Thursday, April 21, 2011

Flex - TileList vs Tile

The DataGroup and SkinnableDataContainer, using a TileLayout class, replace the Flex 3 technique of using a repeater and the Tile container. A repeater in Flex 3 was a simple mechanism for looping over a collection of data (such as an array), which could be used to dynamically create child display objects in a container such as a Tile.

As a general guideline, TileList is usually the more logical way to go. Using a TileList consumes less memory and produces a faster initial response, because it renders only the viewable portion of the data. As you scroll to bring more items into view, they must be rendered on the fly, causing a momentary blank spot in their place (hint: one way of mitigating this is to display a little swirling loader icon until the item is rendered), increasing the lag time between scroll movement and a repainted window.

In contrast to the way item renderers are handled by List-based components, a Tile renders all children at once, whether it’s within the dimensions of the stage’s current viewport or not. If you have a decent number of items to be rendered, be careful if you go this route, because the stage won’t paint itself until every display object (including all those renderers!) has completed the component lifecycle (see Flex in Action chapter 17 for more on this) and is ready to be displayed. On a slower connection, this could take a long time. On the plus side, once the render is complete, scrolling is seamless, with the only real limitation now being the hardware resources available (for example, scrolling fast will make CPU usage go up a lot because graphics rendering unfortunately can’t be offloaded to the graphics processor, and so the Flash Player is limited to a single thread on the main CPU to render everything on the stage).

Monday, April 11, 2011

How to run a command/script as other users ?


> runuser -s /bin/bash - ttt -c /usr/bin/top

This is also the way how daemon use to call runuser in /etc/rc.d/init.d/functions


How to run a batch as service/daemon ?

Since you are using Redhat you have a script handy which will launch a process as a daemon. The script is /etc/rc.d/init.d/functions and you could source that in your script and launch the process like this:

> . /etc/rc.d/init.d/functions
> daemon /path/to/my/script

you can use /etc/init.d/xfs as an example
/etc/rc.d/rc5.d/S90xfs is actually a soft-link to /etc/init.d/xfs

lrwxrwxrwx 1 root root 13 Jul 6 2009 S90xfs -> ../init.d/xfs

> cat /etc/init.d/xfs
...
start() {
...
daemon xfs -droppriv -daemon
...
}

Friday, April 8, 2011

Tuning IDE Hard Disk Performance

Reference: http://www.faqs.org/docs/securing/chap6sec74.html

Putting your swap partitions near the beginning of your drive, see This chart to get a better idea, may give you some acceptable improvement. The beginning of the drive is physically located on the outer portion of the cylinder, and the read/write head can cover much more ground per revolution. We typically see partitions placed at the end of the drive work 3MB/s slower using the hdparm -t command.

Performance increases have been reported on massive disk I/O operations by setting the IDE drivers to use DMA, 32-bit transfers and multiple sector modes. The kernel seems to use more conservative settings unless told otherwise. The magic command to change the setting of your drive is hdparm. To enable 32-bit I/O over the PCI buses, use the command:

[root@deep] /# /sbin/hdparm -c1 /dev/hda or hdb, hdc etc. 

This will usually, depending on your IDE Disk Drive model, cut the timing buffered disk reads time by 2. The hdparm(8) manpage says that you may need to use -c 3 for some chipsets. All (E)IDE drives still have only a 16-bit connection over the ribbon cable from the interface card. To enable DMA, use the command:

[root@deep] /# /sbin/hdparm -d1 /dev/hda or hdb, hdc etc.

This may depend on support for your motherboard chipset being compiled into your kernel. Also, this command will enable DMA support for your hard drive, it will cut the timing buffered disk reads time and will improve the performance by 2. To enable multiword DMA mode 2 transfers, use the command:

[root@deep] /#/sbin/hdparm -d1 -X34 /dev/hda or hdb, hdc etc.

This sets the IDE transfer mode for newer (E)IDE/ATA2 drives. check your hardware manual to see if you have it. To enable UltraDMA mode2 transfers, use the command:

[root@deep] /# /sbin/hdparm -d1 -X66 /dev/hda or hdb, hdc etc.

You'll need to prepare the chipset for UltraDMA beforehand. Also, see your manual page about hdparm for more information. Use this with extreme caution! To set multiple sector mode I/O, use the command:

[root@deep] /#/sbin/hdparm -m XX /dev/hda or hdb, hdc etc. 

Where XX is the maximum setting supported by your drive. The -i flag can be used to find the maximum setting supported by an installed drive: look for MaxMultSect in the output.

[root@deep] /#/sbin/hdparm -i /dev/hda or hdb, hdc etc.

/dev/hda: Model=Maxtor 7540 AV, FwRev=GA7X4647,
SerialNo=L1007YZS
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs FmtGapReq }
RawCHS=1046/16/63, TrkSize=0, SectSize=0, ECCbytes=11
BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=8
DblWordIO=yes, maxPIO=2(fast), DMA=yes, maxDMA=1(medium)
CurCHS=523/32/63, CurSects=379584528, LBA=yes, LBA=yes, LBAsects=1054368
tDMA={min:150,rec:150}, DMA modes: sword0 sword1 *sword2 *mword0
IORDY=on/off, tPIO={min:240,w/IORDY:180}, PIO modes: mode3

Multiple sector mode aka IDE Block Mode, is a feature of most modern IDE hard drives, permitting the transfer of multiple sectors per I/O interrupt, rather than the usual one sector per interrupt. When this feature is enabled, it typically reduces operating system overhead for disk I/O by 30-50%. On many systems it also provides increased data throughput of anywhere from 5% to 50%. You can test the results of your changes by running hdparm in performance test mode:
             [root@deep] /#/sbin/hdparm -t /dev/hda or hdb, hdc etc.