Modularity as a Prerequisite for Scalability

In an excellent article Distinguished Architect Randy Shoup outlines scalability practices accepted at eBay.

My top 3 list looks like this (bottom to top):

3. Best Practice #6: Virtualize At All Levels

Yes, there's a lot of buzz around VMware and no, this is not what the author is talking about in the article. The abstraction is the right keyword. Correctly chosen layers of abstraction are immensely important for a scalable architecture. Splitting your application into many tiers does not necessarily make it scalable. The problem of choosing application tiers and abstraction layers should be considered in the context of execution nodes (reads physical machines) that will be assigned the load at runtime.

2. Best Practice #3: Avoid Distributed Transactions

The main point here is that with rare exceptions data consistency should not be taken too literally. This simple and very important idea somehow proves to be very difficult to convey to the masses. Too many times I had to face people religious about data integrity in the ACID sense. Several hundred of tables dispersed over a couple of schemas with tight referential integrity constraints between the tables... The result? A system that is hard to extend, upgrade, and service.

1. Best Practice #1: Partition by Function

Modularity is paramount for a sound software system. Decouple all the way down to the database. The benefits are many: the modules can be developed, upgraded, and phased out independently on one another by independent teams on independent schedules.

SpringSource Application Platform: First Impressions

1. Comprehensive and comprehensible documentation
2. Works as advertised
   
3. Everything deploys fine judging by the console output
4. You have to look into the application trace log (serviceability/trace/your-app/trace.log) to find out why your application does not work
5. The configuration directory is called config, the configuration files have .config extension (why not use Linux-standard /conf(.d) and .conf?)
6. The configuration file format is some sort of proprietary flat file thing
7. Couldn't make it run behind Apache web server for some reason
8. I'm back to notepad/vi for my bundle configuration tasks - waiting for S2AP support in MyEclipse
   

How to Connect from a Windows Box to a Linux Box via Serial Port

The note is based on the content found here.

Configure the Linux box to accept logins via serial console:

1. vi /etc/inittab:
# Run agetty on COM1/ttyS0
s0:2345:respawn:/sbin/agetty -L -f /etc/issueserial 115200 ttyS0 vt100
2. vi /etc/issueserial:
Connected on \l at \b bps
\U
3. init q to activate changes without reboot
4. ps -ef | grep agetty to verify the process is running
5. To be able to login as a root, vi /etc/securetty and add the following line right after the console line:
ttyS0

To change agetty settings:

1. vi /etc/inittab
2. init q
3. pkill agetty

Connect your boxes with a serial cable such as this one.

Connect to the Linux box from a Windows box via the serial port:

1. Download and unzip/install putty
2. Start putty and connect to your serial port, select the following connection parameters:
Serial line: COM1
Speed: 115200