EBS FSG metadata

Row Set
A row set consists of multiple rows.
The rows in a row set can be ordered by Line, which is the row number.

A row shows the result of a group by.  The row definition describes the group by criteria.
A row can be defined by the account assignments or by calculating the data across other rows.

Row: Account Assignment
When the Display Type is T (Total) and a range is specified, this is a filter criteria for the aggregated result.
When the Display Type is E (Expand), the given account segment is used a grouping attribute. 

Column Set
A column set includes one ore more columns.
Typically the account balance is the column.

Access MySQL database in Ubuntu VM from Macbook

It is handy to have a MySQL database VM.   I can use it to build the demo data in the database and can carry it on my laptop.  I can even share it between the Window laptop and Macbook.

I am using Ubuntu linux and Virtualbox.

Here is how to enable MySQL to be accessible from the host laptop:

1. Install MySQL

2. Access MySQL locally
mysql -u<user> -p<password>

3. Add the host-only network into the VM

4. Use ifconfig to get the IP address of the VM
The value must be something like 192.168.*.*.

Enable the ssh access to the Ubuntu VM running on Virtualbox from MacBook host

I have created a Ubuntu 64 bit VM on my macbook.  I enabled the ssh and sftp access to it.

The configuration involves the virtualbox VM setup as well as configuration within the linux.

Here are the steps:

Enable ssh and sftp access to Macbook

Sometime, it is useful to copy files from macbook or run the command line remotely or even from the VM.

I setup ubuntu VM using Virtualbox and use NAT network.  How to I access the host macbook?

Query Derby DB

Derby is an embedded database.  You can use derby within a Java program.

It does not support multiple user sessions.  Otherwise, it is very good to organize the configuration data in a database, instead of using a file.

Idea, Discussion, Directions are not Enhancement Requests

A software enhancement request should be clear on what the feature will look like.

We do not need to define the solution and design yet, but we need enough information to work on them.

  • Use Case - How the users will use the feature.  Who are those users?  When will the users need this feature?
  • Justification - Why do you need it?  What happen if you do not have this?  Is there a workaround available?

Sometime, the request is too specific and does not include why.   We should not let a single customer/user define the product.  Even a request that is already defined specifically may need to be analyzed.

An idea may need to broken down into smaller pieces in order to be implemented.  The idea, the direction of the products should be captured separately from enhancement requests.

Bugs and Enhancements

Bugs and enhancements should be tracked separately.

If you put them in the same repository, you need to ensure that they are correctly labeled.

If you do not put them into the same repository, you may find a lot of duplicates and found the disputes over whether an issue is a bug or an enhancement, and the filers may be confused.

When an issue come first, the people who file the issue may not know if it is a bug or an enhancement.  For them, an issue is an issue.  It requires the review and categorization by someone know the product to determine how the development organization should treat them.  If you delay in categorizing the issues, especially for those are not clear, developers are confused and do not know whether they should work on them.  On the other hand, if developers need to wait for the issues to be labeled as bugs to start fixing, you add extra process and extra time to the overall cycle.

Git Large File Storage

Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.

After installing, run this command:

git lfs track FILE_PATH

Backport Bugs

The concept of Back Port exists since we have multiple releases, which are available on the market.  A customer may be using an old releases of our codes.  Back Port means making the code changes on top of the old release and make the code available to the customer.

The new release, of course, is also on the top of the old release.  In theory, if the customer can use the new release, you do not need to provide a back port.

The reason why we have to back port because
  • The new release has not been available since it is not ready.  The customer cannot wait for it.
  • The customer may not want to take the new releases.  
    • It may require efforts to upgrade.  
    • The customization may got lost.  
    • There may be risks due to other bugs or non backward compatible changes
    • They are happy with the existing software as you have done a great job, except the issue they are running into
    • They already have a lot of other backports
  • The issue is blocking and the customer cannot continue using the existing software without having the fix.

How to avoid providing back ports:
  • You release codes often.
    • The new release is available soon, so the customers do not have to wait.
  • Upgrade from an old release to a new release is painless.
    • Each upgrade only introduce small changes
    • The changes are reversable
    • You always have good quality of codes
    • You always keep backward compatible
  • You are able to unblock the customers without providing a backport or upgrade the customer to a new release.
    • Your software is customizable and flexible
    • The customer is willing to get the hot fixes

Why providing a backport is costly?
  • You have to shift the focus
  • A backport may not work for a old release and special fix is required
  • You may need to provide a fix on top of other fixes.  Testing become complex