Monthly Archives: December 2019

Different ways of supplying arguments

Posted on by

There are 3 ways to supply argument to Cloud app

  1. Command Line during app startup
  2. using gradle.build
  3. manifest.yml

How to supply Argument to Spring Controller during application startup in Gradle Wrapper 

gradlew bootRun --args='--welcome.message=Mugil'

WelcomeController.java
In the below code welcomeMsg variable is assigned value during application startup. In similar ways environment variables could be setup
by supplying arguments as parameters while executing gradlew bootrun 

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WelcomeController {
    public String welcomeMsg;

    @Autowired
    public WelcomeController(@Value("${welcome.message}") String message) {
        welcomeMsg = message;
    }

    @GetMapping("/")
    public String sayHello() {
        return welcomeMsg;
    }
}

How to supply Argument to Spring Controller using gradle.build
build.gradle

.
.
.
bootRun.environment([
        "WELCOME_MESSAGE": "A welcome message",
])

test.environment([
        "WELCOME_MESSAGE": "Hello from test"
])

supply Arguments using manifest.yml
(works only in cloud env since manifest.yml is way of supplying argument from app to cloud env)

---
applications:
  - name: pal-tracker
    path: build/libs/pal-tracker.jar
    random-route: true
    env:
      WELCOME_MESSAGE: Hello from Cloud Foundry
      JBP_CONFIG_OPEN_JDK_JRE: '{ jre: { version: 11.+ } }'

Cloud Foundry CLI Commands

Posted on by

Cloud Foundry Command Line Interface (cf CLI) is your primary tool for deploying and managing your applications and tasks.

Following are the Steps in Deploying Pivotal App

  1. Clone the App 
    git clone https://github.com/cloudfoundry-samples/cf-sample-app-rails.git
  2. Log in and Target the API Endpoint

    cf login -a YOUR-API-ENDPOINT
  3. Create a Service Instance

    cf create-service SERVICE_NAME
  4. Creating a Route
    Before deploying an app we need a route(API url) which tells where the app would be deployed.Now when creating a route, you need a route which may or may not available. You can opt for random route as below if the route is not available during time of push

    Custom Route

    cf create-route SPACE_NAME DOMAIN_NAME DESIRED_ROUTE_NAME 
cf create-route cloudnative cfapps.io pal-tracker.cfapps.io

    Random Route

    cf push APP_NAME -p APP_LOCATION/APP_NAME.jar --random-route
  5. Deploy the App 
    cf push APP_NAME
  6. Bind the Service Instance 
     cf bind-service APP_NAME SERVICE_NAME
  7. Verify the App – by browsing URL 
     
APP_NAME.cfapps.io
  8. A droplet is an archive within Cloud Foundry that contains the application ready to run on Diego. A droplet is the result of the application staging process.

    cf restage APP_NAME
  9. Use cf restage to refresh the environment variables and cf services to get the list of services
    Viewing Recent Logs in CLI

    cf logs APP_NAME --recent
  10. Viewing List of Environment Variables Available

    cf env APP_NAME
  11. Set environment from Command Prompt
    In the below example welcome.message is a variable created by user in gradle.build to be available at environment level.You can override it by supplying value in command prompt

    cf set-env APP_NAME ENV_VAR_NAME ENV_VAR_VALUE
cf set-env pal-tracker welcome.message "Hi There"
  12. Unset environment from Command Prompt

    cf unset-env APP_NAME ENV_VAR_NAME
  13. Viewing app info 
    cf app APP_NAME
  14. Scaling app – Vertical Scaling app instance has more memory or disk space
    -m allows to set memory space for app
    -f forces the app to restart

    cf scale APP_NAME -m 768Mb -f
  15. Scaling app – Horizontal Scaling more app instances serving requests
    Allows to set no of Instances

    cf scale APP_NAME -i 2

Mob Programming

Posted on by

Everything you want to know about Mob Programming

What is Mob Programming?
“All the brilliant people working on the same thing, at the same time, in the same space, on the same computer.” – Woody Zuill
“Mob Programming is continuous integration for ideas.” – Joshua Kerievsky
There are many ways to successfully mob. In general, there is one computer, a keyboard and mouse, one or more monitors, a whiteboard, one Driver and one or more Navigators sharing a work environment like the one below:

Ideal Mob Size The whole team, although teams of 3-6 people is ideal. Beyond 6 people, a Mob may have difficulties keeping everyone engaged. You can counter this with quicker rotation times.

Driver’s Role – The Driver operates the computer to input/implement ideas made by the Navigator(s).

Navigator(s) Role – Navigators direct the Driver. Usually it works to allow everyone in the Mob to interact directly with the Driver. If that causes too much chaos, have one Navigator give directions to the Driver and the Navigator serves as the voice of the Mob. Newbies to mobbing can ask for help on how to navigate.

Driver Dos & Don’ts

  1. Drivers don’t navigate. If the Driver is the only one who knows what to do, they can relinquish their role as Driver to the next person in the rotation.
  2. Each Driver can share how they prefer to be directed, including asking questions about intent, location and details. Ultimately, navigators must communicate in a way that allows the Driver to understand and take action.
  3. If no one is navigating, the Driver must stop typing.

Navigator(s) Dos & Don’ts

  1. Navigator ideas can only be programming by going through the Driver’s hands.
  2. Navigators must pay attention to the Driver’s skill level. If the Driver needs word-by-word instructions, the Mob must explain in detail what the Driver needs to do. If the Driver is more advanced, Navigators give higher-level instructions, like “commit it” or “move that method to the parent class”. Over-navigating entails too much direction, under-navigating too little.
  3. Don’t sit and watch the Driver work. Everyone learns and contributes in a productive Mob.

Mob Responsibilities

  1. Treat everyone with kindness, consideration, and respect
  2. Plan, discuss, research, and work out ideas on the whiteboard
  3. If a Driver begins to navigate and drive simultaneously, someone else in the Mob can call them out on it.
  4. Keep the Mob going as people join or leave
  5. Stakeholders, Managers, Subject Matter Experts, etc. are welcome to join a Mob, but are not required to drive or navigate.

Leaving/Joining the Mob – It is fine for someone to leave or join the Mob for whatever reason. If they are a Driver, they relinquish that role to the next person in line. The person leaving should tell the team when or if they’ll return so that the team can adjust the rotation schedule.

Switching Drivers – The Driver switch over shouldn’t take more than a few seconds. The teams should determine the best way to accomplish that goal. Switching Drivers is easiest when the Mob shares a single station and settings. If individuals in the Mob have their own preferred tools and settings, consider switching machines using a hardware HDMI switch, or use a system like WebEx or Zoom.

Physical Space – Here are some suggestions for the physical space and equipment setup:

  1. At least one large screen (big enough so that people can easily read code at a distance) is necessary. Some teams use two or more screens. Projectors can work, but are less desirable.
  2. Consider using wireless keyboards and mice to make it easier to switch Drivers.
  3. Mobbing can be noisy. Ideally, the team is in a room with a door that closes or is somewhat apart from other’s work areas. Conference rooms are usually suboptimal. They are designed for people to sit around a table and talk, not to program. You need to face the screen (without turning your head) as you work, and it’s best if participants can sit side by side to facilitate discussions.
  4. You need chairs or couches that are comfortable for longer than an hour.
  5. You need a large whiteboard and plenty of sticky notes.

Mob Timing and Breaks

  1. Use an automated timer (e.g., Dillon Kearns’ Mobster App) to initiate role changes and breaks.
  2. Switch roles every 7 minutes on average (beginners should switch every 2-4 minutes).
  3. The whole Mob should take regularly scheduled breaks. The pomodoro method, a proven method of taking regular breaks to increase efficiency, suggests taking breaks every 48 minutes.

Bias for Action – When discussing how to solve a problem, get out of the abstract as soon as possible.

  1. Do not argue for more than 10 minutes.
  2. If there are 2 ideas, try both, then decide which the Mob likes better.
  3. Keep the Mob moving with this quote from Brian Marick: “An example would be handy right about now”.

The Value of Mobbing – When done well, mobbing helps a team:

  1. Deliver solutions faster by increasing focus, building skills and sharing knowledge.
  2. Produce better quality code because the entire team reviews the code as it is being written.
  3. Feel the pain of tedious tasks. This is good, as it biases you toward fool-proofing and automation.
  4. Cross train it’s members and remove knowledge silos by learning together.
  5. Deliver results faster by reducing the team’s “work in progress” and by eliminating delays from handoffs with the whole team present.

Mobbing Pitfalls – A poorly functioning Mob will produce value slowly. The following are some signs of poor mobbing and what do to if you observe these behaviors:

  1. Excessive discussion or arguing – Run some experiments, then decide which the Mob likes better.
  2. Zoning out – Take a break from the Mob
  3. Ignoring Mob roles/timers – Team members should hold each other accountable
  4. Producing poor designs or not valuing good design – A Mob that lacks people with good design skills won’t magically produce good designs. To improve the design, the Mob should get expert help.
  5. Conflict between team members – In order to be a well-functioning Mob, everyone must be treated with kindness, consideration, and respect.

Don’t Stop the Mob – The Mob can temporarily delegate a member as a researcher, to find solutions to something they cannot easily figure out. Meanwhile, the Mob can work elsewhere in the code. It is important that people feel comfortable enough to ask questions, but if the Mob is moving slowly due to a lot of questions, it is better to set aside some time outside of the Mob for someone to have questions answered. Fast throughput is an important goal.

Invite Experts – If a Mob gets stuck, they may invite an expert to join them to help resolve a problem. Be sure it is an invitation and not a demand (they are not required to drive).

Holland Trip 1

Posted on by

Holland Trip 1
Learnt from Own Mistakes

  1. Don’t buy SIM Card without receipt and Proper Investigation on Plans at Airports
  2. Keep Track of Expenses and Bill amount since saving small amount may make big change in native currency
  3. Prefer Flight which offers more baggage space. Ethiad over Emirates
  4. When staying at Hotels always ask for Emergency Contact no at reception incase of unforeseen circumstances
  5. While Taking Monthly Pass or Weekly Pass, do R&D before applying to get the Best Plan
  6. Things Missed – Net Bag to put Old Cloths, Vadagam, Tea Powder, Coriander Powder, Garam Masala, Spices, Apalam, Detergent, Dish wash liquid
  7. Things likely to have more – Dal Power, Thoor Dal(Atleast 2 kg), Socks(Atleast 4 pairs), Cooker Belt
  8. Things likely to have less – Turmeric Powder, Sambar Powder, Rasam Powder
  9. If possible carry Tiffin Box with Thermal Insulation, Small vessel to boil milk and Small Mixer
  10. Come up with a ball park figure of total before going to counter – Albert Heijn Chocolate Exp
  11. Start Cooking before two weeks from start date of onsite
  12. If you have too much of weight and not sure whether the baggage would incur more charges during checkin, keep extra space in hand baggage since they are mostly not weighed and things from overweight baggage can me moved to hand baggage. 32 Kg of weight where 2 kg could be charged could be moved to hand baggage incase there is only 5 Kg worth of things added to it
  13. Things you buy in duty free are not weighed
  14. Carry Long wallet from Infy in order to avoid tearing of Bills

Learnt from Other’s Mistakes

  1. Never opt for room with 6 people rather go for people with 4 people. Always get mail confirmation for changes in bill amount without fail. Maintain all bills in a pouch
  2. Dont speak native language with some words in language others speak. Even if you do so dont laugh since you may end up in different understanding(Swiss Incident while stainding for Bus)
  3. Dressing Cloth in case you have suffered cuts while cutting vegetable

Learnt from Others

  1. Smiling at Others, Greeting People and Saying Thank you at end of receiving service
  2. Patience in Road and letting others
  3. Time Keep up from NLD Transport
  4. Have Secondary Wallet with Anonymous Card and Money with Friends contact no. Incase the primary goes missing you wont end up helpless.
  5. Pappu and Moore Kuzhambu

Skipping Tests across Multiple Child Modules in Maven

Posted on by

There would be scenarios where you need to skip few modules when building parent project because the unit test fail in child project. In such scenario we should define the surefire plugin at parent pom.xml and include and exclude the child modules for which the unit test should be executed.

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.4.2</version>
        <configuration>
          <skipTests>true</skipTests>
        </configuration>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

Rather than defining plugin(in our case surefire plugin), we can create a profile and define the behavior of plugins within the profile.

<project>
  [...]
  <profiles>
    <profile>
      <id>noTest</id>
      <activation>
        <property>
          <name>noTest</name>
          <value>true</value>
        </property>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.4.2</version>
            <configuration>
              <skipTests>true</skipTests>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
  [...]
</project>

Now lets include and exclude child modules for which unit test should be carried out

Including Unit Test
Only the following(ChildModule3.java) file would be included and others would be excluded

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M4</version>
        <configuration>
          <includes>
            <include>ChildModule3.java</include>
          </includes>
        </configuration>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

Excluding Unit Test
Only the following(ChildModule1.java, ChildModule2.java) file would be excluded

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M4</version>
        <configuration>
          <excludes>
            <exclude>**/ChildModule1.java</exclude>
            <exclude>**/ChildModule2.java</exclude>
          </excludes>
        </configuration>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

How to activate profile in command prompt

>>mvn clean install -PnoTest

How to see list of active Profiles

>>mvn help:active-profiles

If you want to know what version of an specific plugin you have installed you can do this:

mvn -Dplugin=org.codehaus.mojo:wagon-maven-plugin help:describe
mvn -Dplugin=groupId:artifactId help:describe
mvn help:effective-pom

How to execute life cycle task using specific plugin

>>mvn groupID:artifactID:version:goal
>>mvn org.apache.maven.plugins:maven-checkstyle-plugin:2.5:checkstyle