Mobile applications have taken a center stage for the past few years, and with the continuous improvements in mobile technology, we will see more and more applications embracing the mobile platform. However, as an Architect and a developer, building a mobile application that will work across multiple platforms, and yet keep the code as sleek as possible is a daunting task. This was the challenge I faced when designing the Shopping Guru app that helps in making the most out of your online purchases. In this article, I will cover how I went about making this cross-platform app with a high amount of code reusability.

Cross-Platform Mobile Application Key Challenges

For the sake of discussion, I’m summarizing the two core requirements for the Shopping Guru app so that we can understand the challenges and the key aspects of the design better.

• Do periodic checks to generate price drop and product availability alerts.
• Facilitate goal-driven purchases by organizing these into projects. For example, create a project to set up a home theater.

We briefly touched upon a couple of challenges in the introduction. But, let’s highlight the key challenges keeping the 2 dominant mobile platforms – iOS and Android.

• How to improve the code reusability? A big part of this question is how to use the same programming language? As we know, iOS supports Swift and Objective-C. Whereas, Android supports Java and Kotlin.
• How to manage the app data in the cloud? For example, iOS offers iCloud functionality to store data. But, the moment you add Android into the mix, you do not want to have multiple ways of managing data in the cloud, especially, if your app has cloud-based processes that need access to this data. In the case of Shopping Guru, we needed access to the data to generate price drop alerts and to check whether a previously unavailable product is now available.
• How to handle platform-specific interactions that originate “from” the common code? For example, when a price drop occurs generate a notification. The price drop check can be done in a platform-independent reusable code. However, the notification has to be generated using platform-specific features.
• How to handle resources, such as externalized text and images?

As you can see, if we don’t get hold of these aspects early on, the code could get quite messy.

Application Architecture

After doing a few prototypes, I decided to split the application into 2 parts.

1. Mobile App: This is the app itself that contains primarily the user interaction code with basic logic.
2. Cloud-based REST API: This handles the core business logic and provides additional capabilities to improve performance, such as caching and throttling calls to the Vendor API. The Vendor API is used to search and retrieve items.

Mobile Application Design

The app comprises the following key components.

• UI: The user interface and associated code. This layer is implemented separately for iOS and Android. The majority of the application code is written in Java. For Android, that’s pretty straight-forward. And, for iOS, I used Multi-OS Engine, which provides a Java runtime on iOS and makes it possible to write pretty much all of the code in Java. You still need to use Xcode to create the storyboard and generate the skeleton code (such as the controller header and implementation files). From that point, you can use Multi-OS Engine’s IDE plugins to generate Java artifacts. It’s free and the app performance was reasonable.
• Core: This component provides common business logic and maximum code reusability. It also handles common resources, such as externalized text, images, and configuration files. For outgoing calls from the Core module to platform-specific implementation, I decided to have specific interfaces that will be implemented by the respective platform-specific module. For example, both Android and iOS modules implement a NotificationManager interface to provide notification management functionality. The UI code passes these module instances to the Core module at initialization time.
• Data Refresh: This component helps in fetching prices periodically, especially when the app is running in the foreground. Again, this is a reusable component.
• The app uses the following custom libraries.
  • NetworkMonitor: This is used for monitoring the network status, such as when the device is connected to WiFi versus when its connected to the cellular network. Depending on the type of connectivity, the app automatically switches network usage to avoid/minimize cellular data usage.
  • AnalyticsManager: This is used to publish opt-in app usage metrics with user consent.

With this approach, I could significantly improve code and resource reusability.

REST API Design

The REST API acts as the brain of the solution and comprises the following key components.

• The API Gateway + Lambda combination provides the REST API layer that the app would use for needs like searching items and retrieving item prices. It interacts with the Vendor API behind the scenes on a need basis to fetch the latest data. Also, it can do price drop and product availability checks periodically.
• DynamoDB is used to cache the frequently accessed data.
• It also offers a platform-agnostic way of managing app data. In fact, for the most part, the cloud-based components do not even care about the device’s actual platform.

Apart from resolving some of the challenges cited earlier, cloud-based components provide additional flexibility to add improvements and enhancements that do not require changes to the mobile app. This saves significant time to deliver enhancements to the end-users.

Development Setup

• I chose Android Studio as the core IDE since it is quite convenient for Android development. Besides, Multi-OS Engine offers a neat plugin to generate Java artifacts.
• Xcode is used on a need basis when editing the storyboard and creating initial files. Also, it is used to publish builds to App Store Connect.
• The build uses the gradle framework. Each module has a build.gradle file.
• For cloud deployment, I am using the AWS CloudFormation templates. This makes it easy to add more regions, as needed, literally in a matter of minutes!

Resources

• Multi-OS Engine Getting Started Guide
• How To Design Applications For Cloud (SaaS)?
• How To Create a Multi-Tier Stack Using AWS CloudFormation?

Developing a cross-platform mobile application requires a focused approach to consistently identify platform-specific versus reusable code. Once you establish this basic rule of thumb, you can extend it further to identify components that can be reused across multiple applications (like the NetworkMonitor and AnalyticsManager in this article). And, I hope this article gives you a good enough starting point to build a prototype for your mobile application and see if it would meet your needs.

Happy developing!
– Nitin

If you liked this post, you will find my AWS Advanced For Developers course helpful that focuses on many such best practices and techniques to design and deploy real-world applications in AWS.

The post How To Design A Cross-Platform Mobile Application? appeared first on Cloud Nine Apps.

Many Software Architects, Developers, and Leads face this question for their projects – whether they should document their projects? If yes, how much? No, we are not talking about the required documentation that almost every software project needs, like the customer-facing documentation. By “internal documentation”, I am talking about technical documentation like Architecture and Design documents. In this post, we will discuss how to approach such internal documentation.

Why Document Your Project?

This is the most important question. Simply put, what is your intent behind documentation? Are you planning to use it as a tool that can help you build more quality software or are you simply putting together some artifacts for the sake of it? And, this is not just a question for the Architects and Designers, but also the entire team. After all, when you are investing time and effort in the documentation, most of the team should benefit from it. Projects that take the approach of using documentation as a tool to build more quality software not only benefit from it, but these have more useful documentation.

Pros of Technical Documentation

The following are some of the common benefits of having technical documentation.

• It helps validate the approach, design, and implementation.
• It can help establish the core concepts and avoid common misunderstandings.
• The same artifact can benefit multiple aspects of the software life cycle. Remember that the same document may be consumed in different ways by different team members. For example, while a developer may look at it for their implementation, a quality assurance team member can use it for writing their test cases.
• It can significantly help in ramping up new team members who join the project later.
• It establishes transparency in sharing information that could benefit the entire team.
• By keeping it up-to-date, it can help avoid redundant communication.

Cons of Technical Documentation

Of course, documentation comes at a cost. These are not necessarily cons of documentation but are associated with it.

• It requires a time investment.
• It runs the risk of getting outdated as the project progresses. This is often the case when documentation is produced for the sake of it but is not being used for anything meaningful.

So, as you can see, it all boils down to the point about the purpose of the documentation.

How To Approach Technical Documentation?

I am a big believer in using documentation as a tool to deliver quality software. Hence, I like to invest time to make it more meaningful. Here are some useful tips that I like to consider for the documentation.

• Establish the core concepts: Having a simple section like glossary is good. But, often you, as a designer, may have some core concepts that you would like the team to understand. Just like in the business world, there are key driving factors, there are certain core concepts that are key to the functioning of your application. For example, specific data model elements, algorithmic constructs that can help the team understand how the system is architected and what was the thought process behind it. It is interesting to come back to this section a year later and find whether these are still applicable!
• Organize effectively: Avoid clubbing multiple types of content in the same section. It not only makes it harder to understand, but it could create confusion and make it difficult for other team members to extract information. For example, instead of including data model, deployment, performance altogether, consider splitting these into separate sections. For more complex projects, it may be worth having dedicated documentation for certain components/services and having links to these from the overall project-level documentation. This way, team members focused on those components can find information more easily. It would also make it easier to delegate ownership of maintaining this documentation.
• Be concise: The good thing when you write is you can try to articulate your thoughts as concisely as possible. I like to use bullets over paragraphs especially when the topic is dense.
• Keep it simple: That goes without saying. Avoid the use of complex words and jargon that are not helpful. Of course, if some complex terms are vital from an understanding perspective, use these, but make sure that these have been clarified.

What Should I Include In My Software Design Document?

A Software Design Document (a.k.a. SDD) is a living commentary of your project. The following are some key pieces of information that I would like to include in an SDD.

Note: I talk about multiple diagrams as each diagram helps in analyzing the application differently, and collectively these help in gaining a more complete picture.

• Glossary: This captures the key terms that consumers of the documentation should be familiar with. For example, any important abbreviations you are using throughout the documentation.
• Architecture Overview: An overview of the System Architecture. This is a very high-level blueprint of your application, such as an n-tier architecture that will typically not change much over the life span of the application.
• Key Concepts: We talked about these earlier in this post. This section should cover the key concepts and how these work together to make your application function. Also, coming up with meaningful names for these concepts can often help you convey a specific point easily as opposed to always explain what you are talking about.
• High-Level Design: This should capture the overall system design, key components, and their dependencies. Often a UML Component Diagram can come in handy here. The idea here is to give sufficient guidance to individual components’ leads to understanding how they fit in the overall picture. At the same time, giving them at least some level of flexibility in their specific component design, as appropriate.
• Deployment Diagram: If there is one diagram you must-have in almost every SDD, then this is the one. It helps in establishing key details like deployment nodes, which components will run on these, ports exposed, protocols used, and the direction of communication. This is often accomplished via a UML Deployment Diagram.
• Data Model: This is at the heart of many enterprise applications. At a minimum, this should include key entities and their relationships. Often, this will be the input for the database implementation. Entity-relationship Diagrams or ER Diagrams are often used to capture this.
• Class Diagrams: Having one or more Class Diagrams that cover the key classes and their relationships can help the team members build a better understanding. Here, you should focus on core classes that contain business logic and avoid cluttering with classes that are only relevant from the data perspective. Those would typically have been covered in the Data Model anyway.
• Interaction Model: This helps in understanding component interaction in chronological order. This is often captured via UML Sequence Diagrams.
• Compatibility Matrix: If your application has specific compatibility requirements, such as operating system version, library versions, etc it is worth capturing these. These details are extremely important for testing as well as for customer documentation.
• Dependencies: Any third-party libraries or other dependencies that your application requires. This is important for technical aspects like builds. It is also important for legal because, at times, developers may pick up a library that may not be the best choice from a legal standpoint. So, the sooner you can jot down this list and get clearance from stakeholders, the better.
• Performance and Sizing: What are the sizing recommendations and what performance objectives and criteria do the design cater to? The answer may not be always simple and may require a few iterations. However, the point is to have at least some level of guidance and tweak it based on learnings.
• Security: Although other sections may touch upon it, it is important to make this section and address any specific security measures implemented in the application. This could be the use of secured protocols, network configurations, even some operational aspects like regular scanning and detection. This is not an operational document but should give guidance to the Operations team so that they know what measures they should have in place to secure the application.
• Enterprise Readiness: This covers various other aspects like high availability, accessibility, etc.
• Install and Upgrade: This section should cover considerations for fresh installation and upgrades. It is worth including any specific design considerations, such as the backward compatibility of the data model.
• Revision History: Finally, a section that contains the timestamp, the change author and a quick comment describing the change.

The following are some not so commonly used sections. But, I like to use these in my SDDs as this helps bring in a lot more clarity and enabling various teams (including the support teams).

• Developer Notes: This section contains useful tips and information on the code-level information. For example, how multi-threading should be used for a specific component, use of tokens to identify a request end-to-end, etc.
• Logging: Include specific patterns for details like understanding the flow, identifying a request, etc. Sample log snippets also can be extremely helpful.
• Troubleshooting: Provide information on how to troubleshoot the application. This should cover things like log locations, how to analyze logs, other system parameters to analyze, etc. If you can take a few key scenarios, that can also be helpful.
• Common Problems and Solutions: This is useful to capture the commonly observed issues and provide guidance on how to resolve them. As you can imagine, sections like these will continue to grow and can provide extremely useful information for the support knowledgebase.

There are a lot of areas to cover and not everything needs to be done on day one. However, having place holder sections and updating these over time can help you in building useful documentation.

Handling Future Updates To Documentation

Keeping documentation up-to-date is critical to ensure it continues to be an effective tool. Good checkpoints when you can ensure that the documentation is updated.

• Any important technical assumptions are introduced or changed
• Agile iteration boundaries
• When new features are developed
• When new major release begins

Conclusion

As we can see from this post, technical or internal documentation can be a quite effective tool in building quality software and keeping teams in sync. Hence, instead of looking at it as an overhead, look at it as an investment that will pay you off as you embark on your software journey.

Happy developing!
– Nitin

The post How To Approach The Internal Documentation Of Your Software Projects? appeared first on Cloud Nine Apps.

Code Coverage has been an important quality metric to measure the robustness of the code for several years now. It is part of the release criteria for many organizations from development to quality assurance and, at times, even for the senior management team. In fact, it is not unusual that several teams strive for a higher code coverage metric anywhere from 60-80% as the bare minimum threshold for a release. With all that said it is important to understand that code coverage by itself is not as useful. For example, even if you had a very high code coverage of 80% and the majority of your core logic is in that other 20% of the code, chances are high the code could have some serious defects that may slip into the release. What is worse that even if the code coverage were 100% that does not mean all the functionality has been covered! There could be important functional scenarios that might have been missed in the production code and the unit tests, which may again lead to an incomplete release. Don’t get me wrong. Code Coverage is important, but not when it is looked in isolation. When combined with good functional unit tests, it can be extremely useful. And, that’s what we will cover in this article.

Let’s See Some Code

What would be a better way of showing other than using an actual code? So, let’s take a barebone Inventory Management example that offers the following basic functionality.
Note: The functionality and logic are intentionally kept simple so that we can focus on the main topic of this article.

• Get product details.
• Get the price of a product.
• Get the price change of a product.

In order to support this functionality, we have 3 classes.

• InventoryManagerDelegate: This contains the core business logic and will typically be used by another tier or layer, such as a REST API layer to offer the inventory management APIs.
• InventoryDAO: The Data Access Object to handle all database interactions, such as adding and retrieving a product.
• Product: The model or data object to store product information (a.k.a. POJO (Plain Old Java Object) in the Java lingo).

Here is the source code for these classes.

package com.cloudnineapps.samples;

/**
 * The inventory manager delegate.
 */
public class InventoryManagerDelegate {

  /** The DAO. */
  private InventoryDAO dao;
  
  
  /** Initializes the delegate. */
  public void init() throws Exception {
    dao = new InventoryDAO();
    dao.createSchema();
  }

  /**
   * Returns the details for the product with the supplied title.
   * 
   * @param title The product title.
   */
  public Product getProductDetails(String title) throws Exception {
    Product product = null;
    try {
      product = dao.getProduct(title);
    }
    catch(IllegalArgumentException ex) {
      // Product not found, handle gracefully
      product = new Product();
    }
    
    return product;
  }
  
  /**
   * Returns the price for the specified product.
   * 
   * @param title The product title.
   */
  public double getProductPrice(String title) throws Exception {
    // NOTE: This code does not gracefully handle the product not found scenario
    Product product = dao.getProduct(title);
    return product.getPrice();
  }
  
  /**
   * Returns the price change for the specified product from the current price. A negative value
   * indicates decrease in price and a positive value indicates an increase.
   * 
   * @param title The product title.
   * @param currentPrice The current price of the product.
   */
  public double getProductPriceChange(String title, double currentPrice) throws Exception {
    // NOTE: This code does not gracefully handle the product not found scenario
    double price = 0;
    try {
      Product product = dao.getProduct(title);
      price = product.getPrice();
    }
    catch(Exception ex) {
    }
    return (currentPrice - price);
  }
  
  /**
   * Adds a product with the supplied details.
   * 
   * @param id The product ID.
   * @param title The product title.
   * @param description The product description.
   * @param price The product price.
   */
  public void addProduct(int id, String title, String description, double price) throws Exception {
    dao.addProduct(id, title, description, price);
  }
}

package com.cloudnineapps.samples;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.Statement;

/**
 * The inventory DAO.
 */
public class InventoryDAO {
  
  /** The database name. */
  private static final String DB_NAME = "inventory.db";

  /** Returns the current database connection. */
  public Connection getConnection() throws Exception {
    return DriverManager.getConnection(String.format("jdbc:hsqldb:file:data/%s", DB_NAME), "SA", "");
  }
  
  /** Closes the supplied connection. */
  public void closeConnection(Connection con) throws Exception {
    if (con != null) {
      con.close();
    }
  }
  
  /** Creates the database schema. */
  public void createSchema() throws Exception {
    String[] sqls = {
      "CREATE TABLE IF NOT EXISTS product("
        + "id INT NOT NULL,"
        + "title VARCHAR(255) NOT NULL,"
        + " description VARCHAR(255) NOT NULL,"
        + " price REAL NOT NULL,"
        + " PRIMARY KEY(id));",
      "CREATE UNIQUE INDEX IF NOT EXISTS idx_product_title ON product(title);"
    };
    Connection con = getConnection();
    try {
      for(int i = 0; i < sqls.length; i++) {
        Statement stmt = con.createStatement();
        stmt.execute(sqls[i]);
        stmt.close();
      }
    }
    finally {
      closeConnection(con);
    }
  }
  
  /**
   * Returns the product with the specified title, if any. Otherwise, null.
   * 
   * @param title The product title.
   * 
   * @exception IllegalArgumentException when the title was not found.
   */
  public Product getProduct(String title) throws Exception {
    Product product = null;
    String sql = "SELECT id, description, price FROM product WHERE title=?";
    Connection con = getConnection();
    PreparedStatement stmt = null;
    ResultSet rs = null;
    try {
      stmt = con.prepareStatement(sql);
      stmt.setString(1, title);
      rs = stmt.executeQuery();
      if (rs.next()) {
        int i = 1;
        int id = rs.getInt(i++);
        String description = rs.getString(i++);
        double price = rs.getDouble(i++);
        product = new Product();
        product.setId(id);
        product.setTitle(title);
        product.setDescription(description);
        product.setPrice(price);
      }
      else {
        // Product not found
        throw new IllegalArgumentException(String.format("A product with title '%s' not found.", title));
      }
    }
    finally {
      rs.close();
      stmt.close();
      closeConnection(con);
    }
        
    return product;
  }
  
  /**
   * Adds a product with the supplied details.
   * 
   * @param id The product ID.
   * @param title The product title.
   * @param description The product description.
   * @param price The product price.
   */
  public void addProduct(int id, String title, String description, double price) throws Exception {
    String sql = "INSERT INTO product(id, title, description, price) VALUES(?, ?, ?, ?)";
    try {
      if (getProduct(title) != null) {
        // Product already exists, for now skip processing
        return;
      }
    }
    catch(IllegalArgumentException ex) {}
    Connection con = getConnection();
    PreparedStatement stmt = null;
    try {
      stmt = con.prepareStatement(sql);
      int i = 1;
      stmt.setInt(i++, id);
      stmt.setString(i++, title);
      stmt.setString(i++, description);
      stmt.setDouble(i++, price);
      stmt.executeUpdate();
    }
    finally {
      stmt.close();
      closeConnection(con);
    }
  }
}

package com.cloudnineapps.samples;

/**
 * The product.
 */
public class Product {
  
  private int id;
  private String title;
  private String description;
  private double price;

  public int getId() {
    return id;
  }
  
  public void setId(int id) {
    this.id = id;
  }
  
  public String getTitle() {
    return title;
  }
  
  public void setTitle(String title) {
    this.title = title;
  }
  
  public String getDescription() {
    return description;
  }
  
  public void setDescription(String description) {
    this.description = description;
  }
  
  public double getPrice() {
    return price;
  }
  
  public void setPrice(double price) {
    this.price = price;
  }
}

Most of the code is self-explanatory. But, here are some highlights.

• The delegate initializes the DAO, which initializes the schema.
• The delegate offers 3 methods that correspond to the 3 core use cases – getProductDetails(), getProductPrice() and getProductPriceChange().
• You may have already noticed in the comments in the getProductPrice() and getProductPriceChange() method bodies that these do not handle the scenario when the product with the specified title is not found.

Let’s Unit Test This Code

Note: There are many types of unit testing methodologies used from unit testing each layer to sub-integration style tests. For the purpose of this article, this distinction is not relevant as the points covered can be applied to multiple types of unit tests.

package com.cloudnineapps.samples;

import junit.framework.TestCase;

/**
 * The unit tests for Inventory Manager delegate.
 */
public class TestInventoryManagerDelegate extends TestCase {

  /** The delegate. */
  private InventoryManagerDelegate delegate;
  
  
  public void setUp() throws Exception {
    delegate = new InventoryManagerDelegate();
    delegate.init();
    delegate.addProduct(1, "TV", "4K TV", 299.99);
    delegate.addProduct(2, "Receiver", "4K Receiver", 149.99);
    delegate.addProduct(3, "Audio System", "Surround Sound", 199.99);
  }
  
  /** Tests retrieval of product details successfully. */
  public void testGetProductDetailsSuccess() throws Exception {
    // Initialize
    String title = "TV";
    
    // Execute
    Product product = delegate.getProductDetails(title);
    
    // Validate
    assertEquals("Incorrect title.", title, product.getTitle());
  }
  
  /** Tests retrieval of product details when title does not exist. */
  public void testGetProductDetailsWithNonExistingTitle() throws Exception {
    // Initialize
    String title = "Remote";
    
    // Execute
    Product product = delegate.getProductDetails(title);
    
    // Validate
    assertNull("The title must be null.", product.getTitle());
  }
  
  /** Tests retrieval of product price successfully. */
  public void testGetProductPriceSuccess() throws Exception {
    // Initialize
    String title = "TV";
    double expectedPrice = 299.99;
    
    // Execute
    double price = delegate.getProductPrice(title);
    
    // Validate
    assertEquals("Incorrect price.", expectedPrice, price);
  }
  
  /** Tests retrieval of product price change successfully. */
  public void testGetProductPriceChangeSuccess() throws Exception {
    // Initialize
    String title = "TV";
    double currentPrice = 249.99;
    double expectedPriceChange = -50;
    
    // Execute
    double price = delegate.getProductPriceChange(title, currentPrice);
    
    // Validate
    assertEquals("Incorrect price change.", expectedPriceChange, price);
  }
}

Fairly straight-forward, right?

• The first thing to notice is these unit tests are written with functionality in mind. For example, successful retrieval of product details and when product title was not found.
• A couple of functional tests for getting product price and price change have been intentionally left out to show why simply relying on code coverage is not a good idea. For example, the test to check the behavior when a product is not found while getting price.

Let’s Generate The Code Coverage

Before we can talk about why code coverage is not enough, let’s generate it for this code. Here are some screenshots.

Overall Code Coverage

Delegate Code Coverage

Code Coverage of DAO getProduct() method

As we can see, the code coverage seems to be fairly good.

Why Code Coverage Is Not Enough?

Now, we can talk about why code coverage is not enough. The code exhibits 2 commonly observed issues in coding.

1. Missing Code For Functionality: The getProductPrice() method does not have code to gracefully handle the scenario when the product is not found. Instead, it simply propagates the exception.
2. Defective Code For Functionality: The getProductPriceChange() method does not correctly handle the scenario when the product is not found. In this case, the price change will actually return the current price of the product thus leading to incorrect behavior. This is a defect.

So, even though the code coverage is indicating a very high number (almost 100%), it by no means is a guarantee that the code is going to meet the business requirements. The first issue is very obvious as that code does not even exist in the production code. So, there is no way a code coverage tool will be able to measure its impact. However, the second issue is more subtle. It is an indication of how critical defects can easily slip through even when the code coverage was so high. Hence, it is extremely important that code coverage is not used solely to gauge the quality of code, especially by the developers.

Another important observation is the code coverage tool will report a line to be covered as long as it was hit at least once in the entire execution. However, as we can see, 2 of our methods have not been tested for missing product and hence the line where the DAO is generating the IllegalArgumentException is not even hit in the unit testing for these methods. But, it was hit for the get product details unit tests and hence the code coverage tool will report it as covered. While some code coverage tools may be better than others, it is perhaps easy to understand for a developer that these type of details are often buried in details and may not be easy to find. The point being, just because a line is covered in the code coverage report, it is not an indication that it is covered for each relevant functional scenario.

So, What’s The Solution?

In my experience, a combination of good functional unit tests along with code coverage is a reasonably good way of tackling this. A functional unit test is written with the business requirement in mind (like the one we saw in our sample code). There are many advantages to using this approach.

• Firstly, you stop thinking in terms of making permutations and combinations, which are easy to miss. Many developers (including some of the smartest ones) are confused when it comes to unit testing. “What should I write? If a method takes 3 parameters, should I just pass null and combinations of these in my unit tests.” Not that this thought process is not important. But, functional unit tests make it easy to think in terms of how the product will be used and thus what positive and negative scenarios could arise.
• The functional unit tests focus on real-world scenarios and make sure your code can handle these correctly. Hence, by writing these you are not only making the code more robust but also ensuring that you are not missing any critical functionality.
• As a developer, your focus changes from attaining a code coverage number to ensuring as much of relevant functional scenarios are covered as possible.
• I firmly believe that writing functional unit tests is a lot more fun. Sometimes, you have to be bit creative, both from coding the tests as well as coming up with scenarios.

I am sure at this point someone may be thinking “What about QA folks? Won’t they cover it in their tests?” The answer is “It is quite likely they would.” But, as a developer, you do not want to rely on giving a drop to QA to measure its quality. If you could unit test your code more effectively, won’t the code be much better and make you a stronger professional? Besides, the later the defects are found, the more expensive are these to fix. So, the sooner, you can take care of issues in the development lifecycle, the better. And, when you combine these functional unit tests with a continuously improving code coverage, you have a lot more reliable and robust code that meets the business needs.

Happy coding!
– Nitin

The post Code Coverage Is Not Enough appeared first on Cloud Nine Apps.

Online shopping has been popular for many years now. It is fast and convenient with lots of choices. On top of that leading online retailers have been trying to make it as convenient as possible to deliver everything from daily necessities to luxury goods. And, it would be fair to say in this digital age many of us have resorted to using online shopping as the de facto mode of shopping for most needs if not all. Having said that, online shoppers can benefit from applying some simple tweaks to the way they shop. And, if you are already doing these, well, you are already smart then!

Buying What You Need When You Need

Before we touch upon how to be a smart online shopper, let’s just understand a fairly common online shopping behavior. You wake up one day and realize you need to buy an item or perhaps a bunch of items. It could be the birthday gift for someone special, an item that you needed, but did not have time to research and it’s needed now, or just a situation that the holidays are about to start and you have not gotten any gifts for your loved ones. I am sure many of us can relate to such situations without thinking hard. And, there is nothing wrong about it. You have a need and you rush to your favorite online shopping site(s), perhaps look for some price comparisons, shipping costs, etc and make your best possible purchase. Sometimes you may not even have time for that. After all, the routine takes over and you have to make some hasty decisions. With online shopping, this behavior is easier to get into as you do not have to go anywhere. You know all you need to do is just go online and place an order. So, things could get procrastinated easily. Although, not always intentionally.

Cut To Smart Shopping

Smart shopping is also about what you need. But, not necessarily doing it when you need it. IMHO smart shopping involves the following.

• Plan for what you need a bit ahead of time: While you may not be able to predict every single need, chances are high that you can predict several of your upcoming needs, at least, for the near future. Think of things like birthdays, anniversaries, festivals, those home improvements you want to do, things that can improve your lifestyle, health, and so on. There are many advantages to planning a bit ahead.
  • You can plan your budget better. For example, instead of having all the gifts bought in the same month, maybe you could spread the purchase costs over a couple of months to reduce your credit card bill.
  • I believe an important aspect of shopping gifts is buying things that the recipients will really like and not just something that you want to give. By planning ahead, you are giving yourself some lead time to find the most appropriate gifts that they would like. Again, you do not have to do all the research at once. Spread it over time so that you can do a good job while not impacting your other commitments.
• Look for the best deals: Who does not love deals? Online shopping offers many venues to save money from coupons to limited time deals. The challenge is how to find good deals? There are some well-known practices followed by many smart shoppers.
  • Use price comparison sites like pricegrabber.com, bizrate.com, etc.
  • For coupons, use sites like retailmenot.com, groupon.com, and so on.
  • Prices of several items vary over the year. This is due to the obvious nature of supply-and-demand. For example, a summer item is likely to be somewhat cheaper when bought in winter because of the low demand. So, if you could plan your purchases such that you make these during the low-demand period, you may be able to save yourself some money.
• Buy when the price drops: The key difference between this and the earlier point of looking for best deals is in this case you buy only when the price drops. The advantage is instead of you spending time finding coupons and comparing prices, you simply get notified when the price drops and then you make your purchase saving yourself both time and money. There are sites like camelcamelcamel.com that can track prices and notify you when the price drops.

Often, a combination of these strategies can help achieve a more satisfying shopping experience in terms of time, savings and the value you get of your purchases.

Taking Smart Shopping One Step Further

You may be wondering what more can be done? Being a DIY (do-it-yourself) homeowner and an online shopper, I firmly believe that the value of shopping is not just in getting the best deal, but in getting the best value out of a purchase. Hence, I like to think of purchases as projects. This makes my purchases goal-driven and the value realization is often much better than if I were to buy the items individually. What could be a project? Say, you want to set up a home theater, you could treat it like a project and organize the items you want to buy as part of that project. Over time, I’ve seen the following benefits of this project-based approach.

• Firstly, you can have a better overall estimate of how much you will need to spend, which helps in budgeting and identifying how these purchases will be funded.
• You do not have to buy everything at once. Buy when the prices drop or at a point that is more comfortable for you.
• You can track which items have already been bought and which are remaining. That way, you can plan for the pending item purchases.
• Last, but not the least, since these purchases are with a goal in mind, the sense of accomplishment is higher than buying the items individually.

If it sounds too much, it is not in reality, especially given the value. You just need a way to ensure you can manage purchases like a project. And, this is precisely one of the main reasons why I came up with the idea of the FREE Shopping Guru app, which helps in planning, saving and buying with Amazon. In fact, an important point for many online shoppers is what all should you buy for a given goal? If it is something that you are well-versed with, that’s good. But, that may not be the case always. So, how do you get a jump start? Again, this is where the Shopping Guru app takes a novel approach of providing out-of-the-box project templates that can give you a starting point for what all you should buy for some common goals. Of course, the actual items bought can differ from person to person based on price point, aesthetics, etc. But, the template gives you a reasonable starting point. And, if you do not find a template that matches your needs, you can start from the “Blank Project” template. You will still get the benefits of organizing the items under a project, overall budget estimate, manage which purchases have been completed, and so on. On top of this, the app also provides managing ad hoc item purchases for those one-off needs, price watch, and price drop alert along with a convenient Savings Dashboard to track your savings over time.

“As a DIY homeowner I have done several projects over the years and I do the majority of my shopping on Amazon because of the number of choices and their fast delivery. However, the challenge was I just did not know what all I should buy and I wished there was something that gave me a jump start. Over the years as I helped other members in the community, I sensed this is a common problem and that’s when I thought to have an app that provides a template-based approach will be helpful to many people. The template can guide on what all you should look for. Of course, the actual items bought may be different from person to person based on prices, aesthetics and other criteria. But, at least it will give a good starting point. Secondly, because Amazon’s site has frequent price changes, it would be nice if there were a way to track price drops and save money. I put these ideas together and Shopping Guru was born.”

The app does a best effort to make the most out of your purchases. However, you can use any other means of your choice. Interestingly, at times I like to take savings from my earlier projects to fund some future projects, which in turn may also save some money. And, the shopping journey continues!

Note that the project-based approach does not completely eliminate the need for ad hoc purchases. For example, those batteries that you always need around the home and other daily necessities. But, it can certainly be helpful in managing other purchases where you are trying to achieve some target. I like to call it value-driven shopping, which helps in achieving goals small or big and over time these values combined result in much higher satisfaction from the online shopping.

Happy smart shopping!
– Nitin

Interested in making the most out of your Amazon purchases?

• Make goal driven purchases
• Manage ad hoc item purchases
• Monitor prices and get price drop alerts
• Buy when prices drop and save money!

Use the FREE Shopping Guru mobile app to plan, shop and save with Amazon.

The post Be A Smart Online Shopper appeared first on Cloud Nine Apps.