I know the first part of the title sounds exciting. But what I meant was to eat more often in smaller portions rather than having 3 large meals a day. Many people try the opposite – sticking to strict diets and doing lots of cardio trying to shed that extra pound of fat. The problem with starving diets is that you are losing your body’s perfect composition and lose your muscles in the process. This also affects your metabolism and your body tend to conserve as much fat as possible.  A carb-low diet is also proven to be damaging to the proper functioning of brain. 

The focus, instead, should be on increasing your metabolism – the rate at which your body burns those calories. And the best way to improve your metabolism is to split your meals into 6 small meals in day instead of 3 large meals.  One should also be careful about what you eat.  Any food is a mixture of three types of caloric sources – fat, carbohydrates and proteins.  One gram of fat provides 9 calories, and 1 gram of protein or carb gives you 4 calories each.  So it is important to look at the composition of these 3 sources in the food that you take in.  An average active person need 1 gram of protein per 1 pound of body mass per day, based on a 2000 calorie diet.  So if your lean body mass is 150 pounds, you need 150 grams of proteins per day which gives you 600 calories out of your 2000 calorie daily need.  Similarly you need 1-2 grams of carbs per day 1 pound of body mass.  The key is to have the right mix of protein, carbs and fat in your 6 meal per day plan.  Having small and healthy meals every 3 hours keeps the glycogen levels in your cells at a constant rate.  The body will burn any additional intakes instead of converting and storing glycogens as fat, as your body knows that it is getting another feed within next 3 hours.  This is the same reason why it is said that  you should never skip your breakfast.  When you skip the breakfast everyday, your body will tend to store everything that you eat the previous night, as its own intelligence thinks that the next feed is only at lunch the next day.  Hence the body will try to conserve as much energy as possible, thereby reducing your metabolic rate.

The second best method for increasing your metabolic rate is by increasing your lean muscle mass using moderate levels of weight lifting or resistence training.  Building muscles is proven to be much more effective in burning fat compared to hours of cardio training (Note: muscle building should not be confused with body building).  Muscles need energy to maintain; so the more lean muscle mass you have in your body composition, the more energy it requires to maitain itself.  This increases your metabolism and burns your fat storage.  Your muscles are burning calories even when you are sitting idle.  When compared to this, a cardio training burns energy only during your period of training.  You would need hours of cardio to burn fat compared to the time you spend on resistence training.  Moreover, your body becomes more efficient over a period of cardio training.  If you burn 200 calories during a 30 minute jogging today, your body would probably burn only 175 calories the next month if you continue your cardio on a daily basis.  Your body becomesefficient in utilizing energy stores, thereby reducing your metabolic rates.  I’m not saying you should quit cardio.  Cardio is the only way to train the most important muscle group of your body – your heart.  But instead of just cardio, your training program should include more resistence training along with low intensity cardio.

Another suggestion for burning those excess calories is to drink enough quantities of cold water during the day (note:  this method has mixed reactions; so don’t take my words for it).  Water helps to hydrate your body and also helps to avoid cravings for those junk snacks.  When your stomach is full, your body stops sending signals to your brain that triggers those cravings.  Also, when you drink the water cold, the body has to increase the temparature of that water to your body’s internal temperature level, thereby spending those unused glycogens lurking around in your cells waiting to be pushed to those deadly fat stores!!! :)

Completed the SF marathon again on August 3rd.  Was not planning on running this year as I had not trained like last year.  But as the date came closer, I couldn’t resist.  I did a trial run of 8 miles to gather some confidence and finally registered a few days before the event date.  The goal was to complete in 5 hours and so I joined the wave group that had the EFT of 5:00 – 5:15.

My wave started at 6:30 am in the morning.  It was the same route – starting near the ferry building at embarcardero, running along the bay, through the beach near Chrissy field, climbing the hill towards golden gate bridge and return to the golden gate park and to the hilly streets of SF, along the baseball park to the finishing line. 

The first 10 miles were ok and I ran at a moderate pace with the pace group.  At mile 13, when the half- marathoners were finishing their race, I was cursing myself on signing up for the full.  I could hear one of the volunteers cheering and saying “…you are half way there.  Only 13 more miles to go…”.  I think this is one of their standard lines for cheering the runners at half-way point.  But unlike last year, I didn’t find those words encouraging.  My legs had started giving up on me.  Waves of cramps were sweeping all over the body.  From mile 18, it was a struggle.  I had to stop and stretch at every mile to release the lactic acid build up and relax the cramps.  This was an expereience that helped me realize the importance of proper training.  I finally crawled through the finish line in 5:25:29.  I was glad that I was able to finish it within the cut-off limit of 6 hours.  But I will never run again without proper training.

Many ISVs have started migrating their RPG/iSeries applications into the web-based architecture.  The first step involved in this transition is always the conversion of the presentation layer of existing applications from RPG/System i (IBM iSeries/AS400) into a web-based interface while maintaining the core business logic and DB I/O in RPG.  This document gives an overview of the classic iSeries programming model, discusses the various options available for web-enabling the current iSeries/RPG applications and focuses on WebFacing – one of the technology approaches for web-enabling iSeries applications.

In the classic iSeries program model, the application performs READs and Writes to the terminal workstation.  The workstation data manager merges the application data with the display file and generates a 5250 data stream that is sent to the display.  The following figure shows the data flow in an RPG application in the iSeries programming model using RPG:

 

In this model, there is typically one model object and multiple views on that object.  Presentation logic typically goes in the view and business logic goes in the model. 

The following are some of the available options for converting green-screens into a web-based architecture:

 

Host Access Transformation

There are several third-party solutions available that dynamically convert the green-screens into a web-based UI during runtime.  These solutions are based on a screen-scraping architecture which interfaces directly with the 5250 data stream.  HATS and Host-On-Demand APIs from IBM are some of the sample solutions:

Pros:

  • No changes required to RPG applications
  • Easy to deploy

Cons:

  • Licensing costs involved in implementing the solution
  • Less flexibility in customizing the UI
  • Not very scalable as each client requires a 5250 data stream

 

CGI Web Development Toolkit

CGIDev2 is a web development toolkit for iSeries that facilitates the development of web-based programs using RPG or COBOL.  The gateway interface is implemented using an RPG ILE service program that contains all of the procedures required to read input from a browser, generate and send the appropriate response back to the browser.

Pros:

  • Avoids 5250 data streams and reduces the load on the system
  • Better design in separating HTML templates from RPG/CGI
  • Open Source

Cons:

  • Doesn’t always scale well
  • HTTP server and web application must be in the same tier and locks you into using iSeries as your webserver and backend.
  • Requires good knowledge of RPG for extending it into the CGI framework

 

WebFacing

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  WebFacing converts RPG display files to JSPs and JavaBeans, which in turn access the core business logic residing in RPG/System i.  This conversion allows host application to act as a web application.

Pros:

  • Minimal changes to underlying RPG applications
  • Better architecture using MVC design pattern with Struts framework
  • Conversion done at development time making runtime faster
  • Runtime is part of OS/400 and the tools are fully integrated with WebSphere Development Studio
  • Highly Scalable

Cons:

  • Requires DDS source files for RPG applications. If there are no DDS source files, it requires advanced edition with HATS support.
  • Cannot change the screen to screen navigation.

 

Comparing the benefits and drawbacks of these solutions, an IBM WebSphere based solution using WebFacing tools provides a cost effective approach for converting the presentation layer of the current system into a web-based architecture. 

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  The development toolkit allows conversion of RPG display source files to Web UI easily.  The application is converted during development time and thus increases the efficiency during runtime.  The following figure shows a typical e-business program model using MVC framework:

 

 

The e-business program model used in WebFacing architecture follows the Model-View-Controller paradigm, organizing the application into three separate components:

  • Model: the application model with corresponding data representation and business logic
  • View: data presentation, providing views for user input
  • Controller: to dispatch requests and control data flow

 

The controller handles the interactions between the view and the model. When the model changes it updates the view, when the user does something with the view the controller informs the model.

Using the WebFacing toolkit that comes with IBM WebSphere Development Studio, the application is first converted to create JSPs and Java Beans for each record format. When the program performs a READ on a record format, control as well as the application data is sent to the controller.  Because the job was started by the WebFacing server, the controller knows this is a WebFacing request and passes the data and control to the WebFacing server which runs on the iSeries.  Control returns to the WebFacing runtime servlet that runs in WebSphere Application Server. The WebFacing servlet locates the appropriate JSPs and Java beans. The WebFacing servlet tells WebSphere Application Server to return the JSP back to the browser. The JSP is compiled and the resultant HTML is returned to the browser.  Note that no 5250 datastream is generated in this flow.  The following figure depicts these data flows in a WebFaced application: 

 

 

WebFacing is part of the WebSphere Development Studio for iSeries.  The studio includes all the compilers and tools to support WebFacing and includes the development environments Code/400 and VisualAge for RPG.

WebFacing tools help to quickly convert existing RPG applications into web UI with minimal changes required to the underlying applications.  It introduces very less additional costs to the application stack price and requires no user enablement licenses.  The architecture also eliminates the interactive (OLTP) workload and improves the efficiency of the web application during run time.

Targeted advertising and local ad insertion enables cable and telecom service providers to generate additional revenues by delivering targeted ad campaigns and promotions to IPTV-based interactive applications.  In a typical IPTV application, the content that flows from the service provider to the end user takes the form of a live broadcast video stream, an on-demand video stream or non-video interactive user elements (e.g. images, banners, EPG information, Asset Catalogs, System Messages, interactive games etc).

 

IPTV Architecture
In a typical IPTV deployment, live TV channels are encoded in real-time, into MPEG video streams and broadcasted over the network, which is accessed immediately by the user.  On the other side, on demand content like movies and music are aggregated from content providers, encoded into MPEG transport stream videos and stored in a cluster of on-demand video streaming servers at the service provider’s network available for the users to purchase and playback.  The subscriber management server or the middleware server provides the user interface elements, asset catalogs, electronic program guide and all the required client-side applications for a subscriber to access these contents.  The content is accessed by the end user using a media center PC or a TV with a digital set-top box.  The following figure shows various components of an IPTV and VOD architecture:

 

 

Traditional Advertising Model
In the traditional advertising model, the ad content and the program content are assembled, encoded and streamed to all the users, with everyone receiving the same advertisement.  Programs and ads are encoded using transport stream mixers and broadcasted live or stored in video streaming servers.  Banner ads and static contents are pushed to the users using tight integration techniques with the middleware applications.

The following figure shows the advertising components in a traditional advertising model:

 

 

Targeted Advertising Model
The interactive nature of IPTV enables targeted advertisements towards subscribers, thereby increasing revenues per viewer and enhancing the user experience with highly personalized content.  The advertisements that are pushed to a subscriber can be varied according to demographics, geography, viewing habits, content, context and subscriber based campaigning rules.  Because of the in-built addressability of IPTV, ads can be targeted towards large groups, small groups or even single television sets within a household.  The following figure shows the various components in a traditional advertising model:

 

 

The ad management server interacts with the subscriber management or middleware server to deliver targeted ad campaigns to the consumer.  Typical features of an ad management server include:

·      Campaign Management for managing session based rules and ad campaigns for targeting ad banners, ad videos and promotions.

·      Inventory Forecasting for summary of available inventory, projected campaign, delivery and progress.

·      Reporting Module for campaigning and delivery reports.

·      Pricing Module for supporting different pricing models

·      Billing and Sales Modules for integrating with existing billing and sales support systems.

·      Ad Content Management for managing associated ad banners, videos and promotions with related rules.

·      Purchasing Module for advertisers to buy ads and manage their ad slots.

 

The Ad content server is responsible for managing all the advertising media with optional caching feature for instant delivery of the advertisements in real time.  It is also responsible for a highly automated digital ad insertion into the streaming content at the scheduled point.

Typical features of an ad content/insertion server include:

·         Content Management

·         Content Caching

·         Transport Stream Insertion

·         High-Definition Insertion

 

Digital Ad Insertion
Inserting digital ads to the live streams involves two components – a splicer and an ad server.  A splicer is typically a switching device which can generate an output video stream from one or more inputs.  In addition, it can also look for the video splice points from the digital cue tones and insert the ad content at these points from the ad server.  The following picture shows a typical ad insertion process in a broadcast video stream:

 

 

Broadcast streams from the live encoders come in to the splicer and when the ad isn’t being shown these are just re-transmitted as separate but identical streams to the different target groups.  Embedded in the incoming streams are the digital cue tones that signal the location of the “ad avails” and these are detected by the splicer and passed as triggers to the ad server.  At the start of the ad avail the ad server starts playing out the separate ad streams.  These are then fed back into the splicer which inserts them into the outputs sent to the target groups. When the ad avail is completed, the splicer reverts back to the live content and so on; generally acting in a much more interactive manner.  The ad content server is also responsible for static campaigns like banner ads, images, coupons and promotions which are pushed to the end user based on the session parameters.

Targeted ad insertion provides huge opportunities and potential returns for IPTV service providers.  From a marketing perspective, it would become easier to target end users with customized campaigns and increase revenues per consumer.  From a service provider’s perspective, providing such an advertising solution could be a big challenge.  A combination of targeted ad campaign manager and ad insertion technology could provide the necessary advertising solution to meet the needs of advertisers for simplified ad buying.

I ran my first marathon on 29th, July 2007 and completed the 26.2 miles in 4 hours and 42 minutes.  Finally, a fruitful end to 4 months of training I had been following from www.halhigdon.com.

SF Marathon is known for its scenic route and touted as the only race that runs on the road bed of Golden Gate bridge.  It is also the coolest summer marathon in the country.  I was in the wave that started at 6:00 am in the morning.  More than 15,000 runners register every year and due to the huge turnout, runners are grouped into waves based on their estimated finishing time (EFT). 

The race started near the ferry building situated along the San Francisco Bay.  Our pace for the first 5 miles was carefully controlled by our pace setter.  I still remember her words – “The first 10-15 miles – you run with your brain; not with your legs”.  All the excitement, the initial energy (both physical and mental) and the energy that you draw from the crowd would really tempt you to run faster.  An important tip was to use only 50% of your energy for the first 20 miles and the rest on the final 6.2 miles. 

The first 5 miles were along the bay, through the fisheman’s street.  The sky lighed up as we ran past the beach at Chrissy Field.  At mile 5, the climb towards the Golden Gate bridge started.  We could see only one of the suspension towers of the bridge, covered in thick fog, from the distance.

The bridge was the best part of the race.  I broke out from my pace group after we completed the bridge as I couldn’t control the temptation to run the down hill from the bridge towards the golden gate park.  We entered the park at mile 13 where the first half mathoners were finishing their race.  One of the volunteers was cheering - “you are doing good….you are half way there”!!!

Miles 13 – 18 was inside the park, looping through various paths inside the park along rose garden, Young museum, stow lake etc.   You could see all kinds of runners – a runner on bare feet with blood dripping from his feet, a newly wed couple running in their wedding dress, an 80 year old veteran whizing past you, a runner with only one leg  – everything around you was motivational.  This is also the segment of the race that the endurance you build during your training really helps you.

We exited the park to Haight street at mile 19 and the next few miles were through the crowded and hilly streets of San Francisco.  At mile 22, I kind of hit the wall.  The legs were sprained and I had to stop and stretch before continuing.  Our pace setter’s words came to mind again – “This is the part of the race that the thoughts about your family help you”.  Didn’t know what to think.  I was literally counting my steps during the last couple of miles, and chanting the names of my daughters at every step.  Left leg was “Diya” and the right was “Megha”.  I know it sounds funny, but it helped to distract the pain a little bit.  Had I known that the beer and wine they were serving at one of drink stops were to reduce the pain in your legs, I would have stopped there and gulped a whole keg.  I was wondering why they were serving a dehydrating drink during a marathon and came to know the reason only after the race.

The last two miles were again along the bay, past the SBC park.  There was a Giants game going on and we could hear the cheering from the park as we ran past the home of Giants.  The last .5 miles were never ending.  As I ran past the finish line, I remembered to look above, lift my arms and smile at the camera.  The timer on my GPS read 4:42:18.