Cyndi Chin

Firefox iOS: Homepage Rebuild Project

Thu, 29 May 2025 07:08:25 +0000

Overview

This blog post goes over the homepage rebuild project for the Firefox iOS app, which I led and was dev complete by release version 138. This post is mainly a self reflection of the project and I hope to share my thoughts for those who are interested.

Homepage Feature

Before I dive in, this post assumes some knowledge of how the Firefox homepage works from the user perspective. If you are unfamiliar with the homepage feature, there is a brief wiki that gives an overview of the homepage feature. You can read more details there and feel free to reach out to me if you have further questions!

Background Context

Proposal

The homepage is one of the main features in the Firefox app and we want to contiously improve and enhance the experience for our users. There was a time when our homepage code caused app crashes every other week.

One common crash that the homepage was facing was caused by the collection view layout becoming out of sync with the underlying data—often triggered by tab actions like closing tabs. This inconsistent state led to crashes when the layout expected more cells than the data could provide. There were also unsafe access patterns, like reading from arrays without bounds checks and thread-unsafe data updates in general.

To put out the fires, the team implemented temporary patches and band-aid fixes to help stabilize the application. However, these fixes were never intended to be long term solutions, as they make the code brittle and difficult to update.

Knowing that in the near future we want to experiment on the homepage, we took this opportunity to propose rebuilding the homepage instead of refactoring it. Therefore, a proposal was written to compare the two options with a recommendation to rebuild the homepage, which was eventually approved.

In the long-term, rebuilding will achieve the following benefits compared to refactoring:

less dev time in untangling code
less effort in pulling apart dependencies
avoid encountering unknowns that arise when refactoring

By investing in a complete rebuild, we ensure the homepage will not only perform better, but also make it easier for future development and feature expansion.

With the approval, we began the homepage rebuild project.

Goal

The main goal of the project was to rebuild the homepage by integrating Redux for state management and using diffable data source to allow the UI to respond better to changes in the underlying data. Previously, the homepage was reloading an unnecessary large amount of times which also caused poor user experience such as flickering icons and diffable data source solves this by making updates on the differences.

There were 3 main key objectives that were listed out for this project:

A. Centralized State Management with Redux

Implement Redux architecture to centralize and standardize state management across the homepage. Each section in the homepage will have itself contained Redux components if needed. Redux will provide a single source of truth, making it easier to track, debug, and manage state transitions for each homepage section. This should significantly reduce the likelihood of state-related bugs, eliminate some usage of delegates and provide a single directional flow of information.

An example of a section using Redux architecture: The Top Sites section will have its own state (TopSitesSectionState), action (TopSitesAction) and middleware (TopSitesMiddleware).

B. Enhanced UI Updates with Diffable Data Source

Integrate diffable data source to manage dynamic content updates in the UI. This will allow the system to efficiently handle changes to the data model, such as insertions, deletions, and reordering of elements, without requiring full updates in reloading the whole collection view, which we are doing currently. This will lead to smoother and more performant UI transitions and less crashes in terms of inconsistencies between data and UI.

This implementation can be found in HomepageDiffableDataSource.

C. Improved Stability, Reliability + Maintainability

The combination of Redux and diffable data source is expected to enhance the stability and reliability of the homepage. By reducing the complexity of state and UI management, we aim to eliminate crashes and other issues that have previously affected the user experience. The improved architecture will also make the codebase more robust and easier to extend in the future. The goal is to facilitate easier onboarding to our homepage code, faster development cycles, and more straightforward debugging and feature enhancements.

From testing, there have been minimal bugs, but as of writing this blog, we are still running the experiment and confirming with metrics is still to be determined.

Expected Outcomes

More maintainable and scalable homepage architecture for future development

Reduced instances of crashes
Improved application stability
Ease of development and iteration
Enhance user experience through smoother + more responsive UI updates

Project Development

This project was in development from October 2024 until April 2024, but was not worked 100% capacity (i.e. vacation time and work weeks).

Set Up

During the initial stages of development, there were a couple of actions taken before pure code implementation.

Estimation: To give better estimates on the project, I created a spreadsheet that outline the different tasks. Originally, the estimation provided was with two full time engineers, but due to re-prioritization it became mainly one engineer at a time.
Epic: Created separate tasks that needed to be complete for the project.
Public channel: Created a public communication channel so that the team and stakeholders can view any questions or status updates.
Documentation: Internal doc that was created (I reused some of that information here).
Architecture Diagram: Created initial diagram to confirm with the team on the architecture before implementing. Updated and used this diagram to perform handoff to engineers that will be working on the new homepage features.

Implementing New Homepage

The homepage rebuild project has been implemented and dev complete (aside from some nice to haves). Most of the new code can be found in the Homepage Rebuild folder.

Phase Breakdown

Due to the large scope of the homepage, the rebuild project was broken up into two phases. The phases were also a way to help QA test and familiarize with the homepage rebuild project without waiting until full completion. This would help catch issues earlier if needed.

Phase I - Create a foundation for the homepage using diffable data source and compositional layout and start the Redux foundation for the following subsections:

Header
Top Sites Section
Pocket Section
Customize Homepage

Also, includes wallpaper, context menu, scrolling logic.

Phase II - Continue to rebuild the other homepage subsections:

Messaging
Bookmarks Section
Jump Back In

Also, includes adding telemetry + adhering to our new telemetry naming guidelines.

I foresaw that top sites and jump back in section would take the most time so I made sure to split the two in different phases to balance out the timeline. To help in keeping tracking with my progress, I would create a simple spreadsheet shown below, which really helps me when working on a self-led project.

New Telemetry Guidelines

The biggest blocker of this project was having undefined telemetry guidelines. When we received the guideline to keep the telemetry consistent with previous implementation, it was discovered that there some flaws in the existing implemention. After discussion and review, we decided to implement new telemetry that adheres to our new telemetry naming guidelines (another initiative on the team), while keeping a few the same. Going forward, having telemetry requirements upfront and defined earlier would’ve helped move the project more quickly.

Writing Unit Tests

One of the issues that the old homepage faced was flaky unit tests. Since the project was an opportunity to rewrite the homepage from the ground up, I wanted to make sure that I was developing with a TDD mindset and created solid tests. This prompted the wiki documentation - Unit tests guidelines.

The homepage project also led to developing unit tests for middlewares. This prompted creating the StoreTestUtility class and thanks to the collaboration with my team members, we also developed a better mock for testing middlewares. Our guidelines in testing with store is documented in this wiki. The issues with testing our Redux architecture is that our store and its middlewares are global and cause tests to be less isolated or testable. As we are moving forward to using a Redux architecture through the app, we are still learning what works best for our project. With that, we are still refining unit tests, such as needing to modify having the global middlewares set for the store. See more details in this PR.

Decision Table

Throughout the project, there were many decisions made and changes to the homepage as well as clarification as what we wanted. Later in the development, I decided to create a decision table in the ongoing project document, but it would have been helpful to make this table earlier. A decision table is a visual tool that allows us to systematically list decisions considered and the outcomes. It helps teams ensure consistency and communicate decisions clearly.

Testing the New Homepage

As of May 30, the new homepage is still under experimentation and hidden behind a feature flag. It can be tested in our nightly builds, or you if you pull down the Firefox iOS repo (https://github.com/mozilla-mobile/firefox-ios), the feature flag has been enabled in dev mode by default. See details on configuration in homepageRebuildFeature.yaml.

Checklist

While working on this project from end to end, I developed a checklist for myself that I hope to expand + continue for the future. Happy to hear any feedback on this list.

Initial Project Assignment

Confirm design is finalized (+ went through design system review)
Confirm telemetry requirements defined
Create project documentation (notes / feature overview)
Create public communication channel
Create spike + develop initial architecture diagram
Create tickets in epic

Project Implementation

Create spreadsheet with timeline + delegate tasks
Add unit tests / UI tests
Accessibility review
Post weekly status on Epic ticket or public channel
Confirm feature works in all themes / devices (iPad, iPhone, split view, multitasking)

Project Completion

Finalize all documentation
Create QA Request
Experiment created (if needed)

Final Thoughts + Wrap Up

Overall, I feel very fortunate to be able to work on this rewrite on a large feature using modern APIs and gained more confidence in working with our Redux architecture. Previously, I haven’t really worked with the homepage. With the homepage rebuild, I avoided going too much out of scope, so some areas are not adopting Redux fully and still follow MVVM (wallpapers) and the cell UI + data layer was reused. Having this experience, I was able to solidify my knowledge in diffable data source, compositional layout and improving our guidelines in Redux.

Leading this project gives me more confidence to take on bigger projects. While I was able to break a complex project into separate tasks, I would like to have worked more closely with other engineers throughout the project. I was grateful that my teammate has also helped me with wallpapers and scrolling logic when I was out of office. During the time where we were both discussing the project, I really enjoyed to conversations and pairing we had.

Xcode Testing Tools

Wed, 25 Sep 2024 05:16:33 +0000

Part of the Mobile Development series

Overview

This blog post assumes you have some familiarity with Xcode and tests.

Here are some Xcode tools that I use when writing tests to make sure that my tests are valuable.

Run tests repeatedly

Running tests repeatedly helps catch issues early and provide a level of confidence that the tests are not flaky. In order to run tests repeatedly, this can be accomplished by going to the test navigator in Xcode and right clicking on the test that you would like to run repeatedly.

After you select an option to run the tests repeatedly, then you should see a prompt pop up to specify some parameters. I usually keep the default settings and change the maximum repetitions to use 1000 times for individual test classes and 10 times for when I run the whole test suite.

Select “Run” and can verify if your newly created tests have succeeded for all runs.

Check code coverage

Code coverage is a good way to indicate whether your tests are hitting certain code paths. It is a way of measuring how much production code the test code covers. This helps us discover whether we tested different paths of control flow.

First, we need to make sure that code coverage is enabled in our Test Plan configurations. After selecting the test plan in the Project navigator, you should see a similar configuration as below. Ensure that the Code Coverage setting is On.

Next, I turn on the code coverage bar by navigating to the setting shown in the screenshot below. Then, I run the tests to see how much of the file is covered.

The coverage bar will show you the number of times a test has executed a part of the code. Green indicators show if the portion of a code has been reached, and red will be shown if no tests covers that specific part of the code. By using these indicators, this can help us confirm if we test multiple paths. Usually, the happy paths are covered, but its also important to cover other cases as well such as what happens when we return early.

View the reports

After running tests, I also look at the Tests and Coverage sections in the Report Navigator. The reports provides a high level overview on tests and the metrics related to the code coverage. By heading over to the report navigator, I can view the test results and view if there are any issues.

Here is an example of what a Test report may look like. This may be useful to understand patterns, trends and issues that occurred when running tests.

Additionally, you can also view code coverage results from the Coverage report in the Report Navigator. This may be useful to understand gaps in coverage and areas that may need more testing.

Wrap up

Overall, these are some handy tools that I use in Xcode while I am writing, viewing or troubleshooting tests. Hope sharing this will also help others who aren’t aware of these tools. In general, I enjoy writing tests because it gives me a sense of confidence in the code that I am writing and ensures that my production code is testable and decoupled. Additionally, it reaffirms that I understand the code and provides me feedback when I am implementing requirements. The bonus for me that it can also catch bugs early on.

More resources

To learn more about other Xcode tools, check out my other blog on debugging tools:

Xcode Debugging Tools

Useful Apple Docs on testing tools:

First Look into Quick + Nimble

Wed, 18 Oct 2023 09:16:33 +0000

Part of the Mobile Development series

Quick + Nimble Overview

This blog post will document my initial investigation in using Quick + Nimble.

What is Quick + Nimble?

Quick is a behavior driven development (BDD) testing framework and Nimble is a matching framework that helps make tests easier to read. Coupled together, they provide the advantage of being able to be very descriptive when writing unit tests in comparison to using XCTests.

Quick + Nimble vs. XCTests

Both frameworks have their advantages and disadvantages, so I created a chart to list down the positive and negatives from my experimentation, discussing with coworkers and surfing the interwebs.

Quick + Nimble

Pros	Cons
Supports BBD and acceptance testing better since tests are descriptive	Third Party Dependency
Can easily read what is being tested	Does not have performance testing
Structure is consistent with testing done across other languages and platforms	Learning curve for developers used to XCTests
Easier to create subsets of tests in a suite
Active community and open source project

XCTests

Pros	Cons
Default native testing framework that is well integrated with Xcode	Hard to read and understand what is being tested
Less of a learning curve	Assertion methods are not as thorough as the Nimble matching framework
Can test performance	Less flexible in comparison
Support for UI testing

When it comes to making a decision between the two, I lean towards using XCTests as the default testing framework for my personal project. However as the project gets bigger, then I will look into using a combination of both Quick + Nimble + XCTests. For a project in which there are more contributors and stakeholders, I can see the benefits of using Quick + Nimble as its easier to perform acceptance testing, understand the value of a tests and modularize the code.

Setting Up Quick + Nimble via SPM

It was fairly easy to add the dependencies if your project is using the Swift Package Manager. Here is a snippet of what it looks like to add the frameworks in the Package.swift file.

dependencies: [
    .package(url: "https://github.com/Quick/Quick.git", from: "7.3.0"),
    .package(url: "https://github.com/Quick/Nimble.git", from: 13.0.0"),
]

After adding the dependencies to the package, we can use them in a test target by adding them as products to the dependency section for the test target.

.testTarget(
    name: "DiscoverKitTests",
    dependencies: [
        "DiscoverKit",
        .product(name: "Quick", package: "Quick"), 
        .product(name: "Nimble", package: "Nimble")
    ]
)

We can test if we incorporated the dependencies properly by importing the frameworks and creating a simple test file. For example, the following file that exists in the DiscoverKitTests target should not receive any compile errors after building. This is the start of writing a unit test.

import Quick
import Nimble

@testable import DiscoverKit

final class DiscoverKistTests: AsyncSpec {
    override class func spec() {
    }
}

Quick Glance at Writing Unit Tests with Quick + Nimble

Quick provides uses a single function spec() to define a suite of test cases. spec() is can be composed of multiple sections which are describe(), context() and it().

describe() - acts as a container and defines the behavior or action you want to test at a high level
context() - can be used if more details are needed to clarify a certain scenario that is being tested (optional)
it() - used to define individual test cases as we would with a function in XCTests; expectation checks belong here.

import Quick
import Nimble

@testable import DiscoverKit

final class DiscoverKistTests: AsyncSpec {
    override class func spec() {
        describe("the Discover tab") {
            it("shows loading state at initial load") {
                ...
            }
            it("shows recommendation list after fetch") {
                ...
            }
            it("shows error state after fetching error") {
                ...
            }
        }
    }
}

When writing a test, the above constructs are used to organize the test cases within the suite. There are also other constructs to know such as beforeEach and afterEach that acts similar to setting up and tear down of a tests. Although it looks like one giant test case if you are used to creating a function per test case with XCTests, you can still run the individual it test cases by going to the test navigator and selecting on the test you want.

Within each test case, we want to validate and fulfill test expectations. Nimble provides that power through using expect(), which replaces assertions from XCTests. There are a wide range of different matchers that can be used, some examples are:

# Checking if two values are equal
expect(value).to(equal(expectedValue))

# Checking if boolean is true
expect(isHappy).to(beTrue())

# Checking if result is nil
expect(result).to(beNil())

# Checking if collection contains a string
expect(books).to(contain("Harry Potter"))

Resources

To learn more about Quick + Nimble, here are some useful resources that dives deeper into the framework:

SwiftUI and Architecture Considerations

Thu, 29 Jun 2023 04:43:03 +0000

Part of the Mobile Development series

SwiftUI Overview

This blog post will go over my current understanding of SwiftUI and existing architectures that can be used to apply.

What is SwiftUI?

In iOS development, there are two popular frameworks used to build user interfaces for apps in the Apple ecosystem, which are SwiftUI and UIKit. SwiftUI is a UI framework that takes a more declarative approach in developing apps for Apple’s ecosystem. While there have been many discussions surrounding architectures around UIKit, I’m curious to understanding and see what discussions there have been regarding SwiftUI architecture and whether we can apply the same solutions.

SwiftUI is becoming more popular in the iOS development community and was introduced in iOS 13 as a way to simplify the development process in creating UI for apps. The decision to choose between SwiftUI and UIKit is largely depending on the development goals for the app and complexity. For the purpose of this post, we will focus on SwiftUI and consider various architectures that can be applied.

Resources

To learn more about SwiftUI, here are some useful resources that dives deeper into the framework:

Common Architecture Patterns

There are several architecture patterns that are floating around when it comes to iOS development. Reading objc’s app architecture book, I have learned some sample iOS application design patterns in Swift. Although the examples in the book were using UIKit as the framework for building user interfaces, this has led me to ponder about the different architectures that can be developed with the SwiftUI framework.

MVC - Model-View-Controller
MVVM-C - Model-View-ViewModel + Coordinator
MVC-VS - Model-View-Controller+ViewState
MAVB - ModelAdapter-ViewBinder
ELM - The Elm Architecture

There isn’t one solution or one way to architect an application and the decision is mainly a group discussion with the developers that are working on the application. This is the beauty of programming where we get to use our creative mindset to determine how to program so that we maintain a solid foundation for an application that is constantly iterating and changing.

SwiftUI Architecture in Pocket’s iOS App

My main experience with building an application in SwiftUI is through Pocket’s iOS app. Therefore, I will briefly outline what the current architecture that the Pocket currently uses for their iOS app. Although there still needs to be discussion, let’s analyze the current architecture as it is in this open source repository: https://github.com/Pocket/pocket-ios

Currently, the project has a mix of UIKit and SwiftUI, but we’re moving towards replacing as many of our UIKit views with SwiftUI views. When creating these SwiftUI views, we are following the MVVM architecture approach.

MVVM (Model-View-ViewModel) allows us to separate the state and logic handling from our views into classes called view models. Our view models typically conform to the ObservableObject protocol so that changes can be reported back to the view. The view that wants to make UI updates based on the viewmodel will create a property variable with the view model as its type. By making this separation, we can write tests for our code more easily. We create @Published properties in the view model class to announce when changes occur and SwiftUI will monitor those changes.

class ViewModel: ObservableObject {
  @Published private(set) var model: Model
}

struct ContentView: View {
  @ObservedObject var viewModel: ViewModel
}

Architectures aside MVVM

There are resources out there that argue the use of MVVM for SwiftUI. Some argue that MVVM is over engineering the code as mentioned in this thread. One popular architecture that I noticed was the The Composable Architecture (TCA) developerd by pointfree. I hope to investigate this architecture future and will expand upon this blog post with my learnings from there.

Considerations

As we move forward to adopting a mindset of using SwiftUI as our main framework for building our user interface elements, there are some considerations that we want to keep in mind.

Dependency Injection: improve our existing DI patterns; consider using SwiftUI’s Environment class to handle this
Architecture: while we are using the MVVM approach, we may not need a view model in cases where it may see overkill
Navigation: Previously, we utilized MVVM-C with our UIKit framework and our coordinators handled the presentation layer. However, we decided to remove this, but we may consider using NavigationPath as a way to organization our complex presentation

Summary

Overall, this is my initial research and consideration of using SwiftUI in applications. I will continue to iterate and expand this post as I learn about various architectures that can be considered. Any feedback is appreciated!

Xcode Debugging Tools

Wed, 07 Dec 2022 08:30:03 +0000

Part of the Mobile Development series

Xcode Debugging Tools

As I started my official iOS career in 2020, there were some tips and tricks in using Xcode to debug issues that I picked up along the way. This is an ongoing post in which I’ll continue to add my lesson learns as I become exposed to them and find it useful to share with others.

Most of the tools that we will be going over are listed in the debug menu shown below:

UI Test Recorder

Going from left to right, you’ll see a red record button. If you are planning on implementing UI tests, this is helpful in generating automatic code for you. First, create a UI test case and then press the record button which will run the simulator. Now, the recorder will attempt to write code that matches the actions you take in the Simulator. Although I tend to write the code myself, this is useful in understanding how Xcode will interpret your actions and can provide insight on some names and what type of element you are interacting with.

View Hierarchy

As someone who is passionate about the UI, I really like this view hierarchy because you can see the layers of different UI elements that are appearing. It is useful if you have some weird UI bug to address as and want to see what the hierarchy looks like and there are attributes for each element.

Memory Debugger

Although I rarely use the memory debugger, it helps to know that this tool is available and provides more insight when there is a memory leak and you can see if an instance is created multiple times. This will give is a clue is something should be deallocated.

Environment Overrides

Accessibility is usually seen as the last thing and sometimes isn’t emphasized when it comes to building features. However, I definitely think it should be a consideration throughout if not at the beginning. The environmental overrides is useful for making sure that the app works in different environments. The environments could be based of dark mode, text sizes or other accessibility details.

SwiftLint Overview

Tue, 06 Dec 2022 08:03:03 +0000

Part of the Mobile Development series

SwiftLint Overview

What is SwiftLint? A tool that allows us to enforce certain Swift style guide and conventions. It is an open source library and more details can be found here: https://github.com/realm/SwiftLint

What are the benefits? Having a consistent style guide across a codebase helps the repository become more readable and maintainable. Also, incorporating SwiftLint will prevent engineers from having to manually comment style nitpicks in open Pull Requests (PR) since SwiftLint will catch it.

There are thorough details in how to install and use SwiftLint in the GitHub repository, but this post will walk through how SwiftLint was incorporated in the Pocket project using Swift Package Manager (SPM) specifically. We will also go into seeing how warnings and errors are generated for violating the SwiftLint rules and how we can create custom rules that are specific to our projects.

This post will go over the following:

Installation
SwiftLint in Action
Custom Rules

Installation

Add SwiftLint to Build Phase in Pocket (iOS)

First, we want to add a Build Phase so that we run the swiftlint checks after each build.

Below is an example in the Pocket project, but feel free to configure the shell script differently.

export PATH="$PATH:/opt/homebrew/bin"

if which swiftlint > /dev/null; then
  if [ "$CONFIGURATION" = 'Debug' ]; then
    swiftlint
  else 
    echo "Skipping swift lint because it is not a local developer build."
  fi  
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

Next, we want to add the configuration file.

Create the SwiftLint Configuration File

Add a .swiftlint.yml file in the directory you want to run the SwiftLint command from. This is what the file looks like in the Pocket repository: https://github.com/Pocket/pocket-ios/blob/develop/.swiftlint.yml

There are a set of rules that the SwiftLint can check for. There are two main groups:

disabled_rules: Disable rules from the default enabled set.
opt_in_rules: Enable rules that are not part of the default set.

Include and remove any rules that you want to apply the codebase. The rule directory is located here: https://realm.github.io/SwiftLint/rule-directory.html

For more details on configuration: https://github.com/realm/SwiftLint#configuration

SwiftLint in Action

Once you add the .swiftlint.yml file, we can verify that swiftLint is checking that the codebase is adhering to the Swift Style rules. If you don’t see any warnings, we can see it in action with a simple test using the vertical whitespace rule (https://realm.github.io/SwiftLint/vertical_whitespace.html). Make sure that the disabled_rules does not include the identifier vertical_whitespace. Then go to any of your files and add a bunch of vertical line spaces. The following warning should appear:

Now you have SwiftLint integrated and working in your project! If you don’t want to address the issues manually, there is a neat command to auto fix the issues: swiftlint --fix. Sometimes it can’t auto fix the issues, but it does a pretty great job from what I seen.

If you are seeing the following issue -bash: swiftlint: command not found, you can run the following command brew install swiftlint to make sure it is installed properly.

Custom Rules

As mentioned above, SwiftLint has a rule directory of all the different rules that you can disable or enabled depending on which set the rule belongs to. However, these set of rules are limited in numbers and at times we may want to add custom rules that are not included in the set from the directory. The custom rules uses regular expressions to capture any violations. For example, the rule below will warn if there is any string with internal func in the codebase. This custom rule is for demo purposes as it does not check whether it is redundant or not.

There are many regex tools out there that we can use such as https://regex101.com to help us test out these rules.

You can also do a rule request by opening an issue on the open source repository as well: https://github.com/realm/SwiftLint/issues

Summary

Overall, SwiftLint is amazing tool that I recommend integrating into your iOS projects at setup. It keeps you in check to make sure that a certain Swift Style is consistent across the codebase and becomes really helpful as a project has multiple engineers working on it. As always, feel free to reach out to me and provide any feedback or questions.

[OMSCS] INTA 6450: Data Analytics + Security

Tue, 16 Aug 2022 09:48:00 +0000

Part of my OMSCS Review series

INTA 6450: Data Analytics + Security

In Summer 2022, I completed my sixth course in the OMSCS Program at Georgia Tech, Data Analytics and Security (INTA6450). I was interested in this course because of the course project, which students can hone their data analytics skills on real world cybersecurity data. The data comes from NowSecure, a mobile app security company that the course has a partnership with. NowSecure scans all Android and iOS apps available on public app stores.

With my background in security incident response and mobile development, I was interested to see how I can utilize my data analytic skills to find patterns and security vulnerabilities that are existing on mobile applications, which are installed on millions of devices.

Topics Covered: big data, linear regression, decision trees, clustering, probability, bayesian reasoning, neural nets, R, Python

I recommend taking this course for someone who wants an easy A course with a light workload. However, I wouldn’t take this course again because I didn’t learn too much and didn’t think I gain or improved my skillset. I did get a high level overview of big data and techniques used to perform data analytics, but it was at a superficial level and I doubt I will retain the information. The highlight for me was being able to gain access to a dataset that contained detailed analyses and reports of various mobile applications in the app store.

This course may be more well suited for someone passionate about data analytics as Professor Borowitz was very friendly and passionate about the topic. Therefore, going to office hours may have provided someone who was interested in the topic with more value.

Overall, I wouldn’t recommend this course unless you want to take an easy class or enjoy data analytics.

Course Overview

The workload for this course was pretty light and I didn’t spend more than 5 hours a week on the course. I followed the syllabus, so I watched the lectures and completed the quizzes / discussions as they came out. The coding assignments were also easy because it was altering the code and then writing about those changes. Towards the end of the semester, it was a bit more time consuming as we had to complete the final project as a group.

Assignments

The assignments consisted of lecture activities (i.e. quiz, discussion posts), computing activities (i.e. R and Python tasks) and the final project. There were two options to pick from the project: Enron or NowSecure. I decided to choose NowSecure due to my interest in the mobile space. There were no exams.

Here is the breakdown of the Assignments:

Lecture Activities (30%)

Quizzes (9 total) - 50 points each
Discussions (11 total) - 4 points each

The quizzes were open book and you can find the answers exactly on the slides or videos from the lectures, so it is easy to do well on them. For the discussions, the grading was also easy as long as you answer all the questions. Discussions would consist of reading an article or getting your opinion on a topic relating to the the lectures of that week.

Computing Activities (20%)

R Exercises (4 total) - 10 points each
Crime and Punishment Python Exercise (1 total) - 10 points each

The programming exercises were essentially to just make changes or add extensions to the code that was already provided. It was a way to give exposure to different languages and some libraries that might be helpful for our project.

Project Activities (50%)

Course Project, Part 1 Proposal – 20 points
Course Project, Part 1 Peer Review – 10 points
Course Project, Part 2 Paper – 30 points
Course Project, Part 2 Presentation – 30 points
Course Project, Part 2 Presentation Peer Review – 5
points
Peer Review of Teammates – 5 points

The project was very open ended and creativity was given to use in terms of how we wanted to analyze a dataset. Since I choose to do the NowSecure project, our project was to find security vulnerabilities and patterns that surrounding insecure applications.

For Part 1, the proposal was an individual assignment where you create a proposal for the project. The project was very vague and the professor provided some templates in what direction you can take the project. My initial proposal was to focus on applications that have misconfigured APIs and using this finding to predict that the application is also prone to contain other features such as data leakage, exposure of excessive information, and lack of proper cryptographic methods.

For Part 2, the paper and presentation were group assignments. We could utilize any of our proposals in Part 1, but our group decided to go with a different route. In general, the paper consist of our analytical goal for the project, the methodologies we used, results we found, whether those results were good and if we could fix or not fix any problems with the approach we used. Our project goal, specifically, was to implement a ML model that predicts whether an application is secure enough to be available in the Android marketplace and we did this using key attributes related to the OWASP Top 10 Mobile Risks.

The presentation (~20 min) was to cover the information in our paper and project. We discussed the pattern of security risk we focused on and our results of these findings. Also, we described what our limitations were and future enhancements.

Tip: Make sure to get a good group for the course project.

How do I prepare for this course?

It is helpful if you have prior knowledge of Python for the final project, but not necessary. It’s important to find great group members early on. I got lucky that I had a great group and everyone contributed / participated in the meetings. We also had a data scientist which helped as he had more expertise in creating machine learning models using python libraries.

Lessons Learned

From this class, I got to exercise my muscles in using Python to parse JSON data. Also, I got exposure to analyzing a dataset that contain information about mobile applications. Aside from that, I honestly don’t have much main takeaways from this course and learned very little, which is why I wouldn’t take it the course again.

[Book Review] Essentialism by Greg Mckeown

Wed, 29 Dec 2021 06:11:03 +0000

Part of the Book Review series

Book Review: Essentialism by Greg Mckeown

Essentialism walks you through the mindset of an Essentialist and discusses how we can develop a systematic approach for determining what are the important things in our lives and how we can focus our energy in contributing to those essentials when making a decision. It is not about getting more things done, it is about getting the right things done.

An essentialist is one who knows how to live a life true to oneself and how to discern what is important and eliminate what is not.

Rating: 5/5

Recommended If:

you constantly feel busy, but also feel like you aren’t being productive or getting things done
you want to make the best investment of your time and energy in contributing to only what is essential to you
feel obligated to live the life others have set for you
you are looking for an interesting read to expand your horizons
you reflect on your life and regret on the decision you made in the past as it wasn’t contributing to what you value

Highlights

“Essentialism is a disciplined, systematic approach for determining where our highest point of contribution lies, then making execution of those things almost effortless”
“Living by design, not by default”
“If you don’t prioritize your life, someone else will”
“If the answer isn’t a definite yes, then is should be no”
“Essential Intent - makes one decision that eliminates 1,000 later decisions”
“Remember, forcing these people to solve their own problems is equally beneficial for you and for them”
“Every day do something that will inch you closer to a better tomorrow”
“Done is better than perfect”
“Learning essential new skills is never easy. But once we master them and make them automatic … the skill remains with us for the rest of our lives”
“Life is available only in the present moment, if you abandon the present moment you cannot live the moments of your daily life deeply”
“In work, do what you enjoy. In family life, be completely present.”

Going Forward

This book help me realize that we should enjoy the journey and not just focus on the destination. We are also in control of our own choices, so we should spend time on the few essentials as opposed to spreading yourself thin. After reading the different steps, I aim to incorporate the following into my life:

Schedule one hour of blank space every day to think and escape from the busy life
Keep a journal to identify patterns or trends as small, incremental changes are hard to see in the moment, but can have a huge cumulative effect
Have consistent sleep
Apply selective criteria to opportunities before I make a decision
Create my essential intent
Learn the slow “yes”, and quick “no”
Build in buffers to reduce the friction cause by the unexpected
Focus on small wins vs setting big goals

This is my second time reading the book and I enjoyed it as much as the first as I am someone who feels constantly busy and always says “yes” to all opportunities that comes to me. After the first read, I realize that I am better now in saying “no” and not taking on opportunities that are not essential. However, I am constantly applying this systematic approach and still working on focusing on living in the present and appreciating the journey.

Summary

The book was broken into four sections: essence, explore, eliminate, and execute.

Part I: Essence

What is the core mind-set of an Essentialist?

This section discusses what an Essentialist is and how they choose, discern and view trade-offs. The way of the Essentialist is to practice the idea of less but better. This is achieved in a disciplined way by saying “no” more and to pause to think if you are investing in the right activities. As there are many more opportunities now, especially with technology around, an Essentialist learns to filter through all the different options to select what is truly essential to them. This way we make significant progress in the things that matter.

Nonessentialism is everywhere as we have too many choices, too much social pressure, and the constant idea of ‘you can have it all’. The core mind-set of an essentialist contains the following:

We can choose how to spend our energy and time vs. I have to do it
Only a few thing really matter vs. It’s all important
The reality of trade-offs (we can’t have it all or do it all) vs. I can do both

The next parts of the book describe the system that we can go through to obtain the mindset of an essentialist, which can be broken up to three components: explore, eliminate and execute. This process can be applied when making a decision.

Part II: Explore

How can we discern the trivial many from the vital few?

To explore is the beginning stage where we want to evaluate our professional and personal lives and understand what activities or efforts we want to focus on. In this stage, ask yourself three questions:

What do you feel inspired by?
What are you particularly talened at?
What meets a significant need in the world?

The book breaks this section into escape, look, play, sleep and select.

Escape: it is critical to set time to think, breadth and observe; this allows us to have clarity and space to explore different possibilities and options
Look: be a journalist of your own life to avoid focusing on the details and see the bigger picture; hear what is not being said and find the essential information
Play: do simply for joy rather than a means to an end; play sparks exploration and expand our minds
Sleep: sleep enables the highest level of contribution and is a priority
Select: be selective, explicit and right by saying yes only to top 10% of the opportunities

Part III: Eliminate

How can we cut out the trivial many?

To eliminate is to actively get rid of those that do not make the highest possible contribution. By eliminating, we earn the time necessary to achieve what is essential. In this stage, ask yourself these questions:

What out of my priorities, will I say no to?
If I didn’t already own this, how much will I spend to buy it?
If we could be truly excellent at one thing, what would it be?

The book breaks this section into clarify, dare, uncommit, edit and limit.

Clarify: be clear about your purpose as motivation and cooperation can deteriorate when there is none
Dare: a clear “no” can be more graceful than a vague or noncommital “yes”
Uncommit: sunk-cost bias to continue to invest time and energy into something because we already incurred a cost that cannot be recouped; tendency is to undervalue things that aren’t ours and overvalue things because we already own them
Edit: cutting, condensing and correcting enable us to check ourselves
Limit: know your boundaries and set rules for a direct “no”

Part IV: Execute

How can we make doing the vital few things almost effortless?

To execute is to create a process that makes getting the essential things done as effortless as possible. After understanding what efforts to keep in our life, we want a system that is routine to execute the essential things as easy as possible.

The book breaks this section into buffer, subtract, progress, flow, focus, and be.

Buffer: be prepared and build a buffer for unexpected events, planning fallacy is a phenonmenon that people tend to underestimate how long a task will take (even when they done it before)
Subtract: understand what obstacle is keeping you back from achieving what really matters and how to remove them
Progress: start small and get big results, don’t go for the flashiest wins as small and concrete wins create momentum and affirms further success; there is power in steadiness and repetition
Flow: expend a small amount of initial energy to reate the routine and then executing the essentials will be autopilot
Focus: every second spent worrying about a past or future moment distracts us from what is important in the here and now, so focus on the now and be present
Be: the life of an Essentialist is a life of meaning and a life that really matters; live a life without regret

[OMSCS] CS7632: Game AI

Mon, 13 Dec 2021 12:07:55 +0000

Part of my OMSCS Review series

CS7632: Game AI

In Fall 2021, I completed my fourth course in the OMSCS Program at Georgia Tech, Game AI (CS7632).

I love playing video games and I was curious to see how AI agents are working behind the scenes, especially in games like Chess. Last semester, I took Artificial Intelligence and this class gave me a better insight on how it can be applicable to games. Overall, we learned about the role of AI in games and our assignments were based on implementing algorithms for different aspects of a game.

Topics Covered: agent movement, path planning, decision making, goal-oriented behavior, learning, and procedural content generation

I highly recommend taking this course for someone who has taken AI and enjoy learning about how games work.

The workload was a lot easier than CS6600: Artificial Intelligence, but a bit more time consuming than CS6300: Software Development Process.

Professor Wilson was really responsive in Piazza and he was very nice in answering our questions about the assignments. The Slack channel was active, but I didn’t feel that I needed it as much as the assignments weren’t too difficult. Overall, I enjoy learning about AI being used in games, but not sure how practical this knowledge will be during my day to day.

Course Overview

This course opens you up to consider how AI in academia differs from AI in games. For example, in games, we may want to dumb down the AI to make the gameplay more fun for the user. There is a sweet line when it comes to user experience as we want to avoid anxiety from a difficult game, but also avoid boredom.

I found myself putting in 8 - 10 hours a week for this course and would say that most people get 100s on the assignments, so an A is doable. I wouldn’t say it was an easy A. The lectures were a bit slow, so I had to increase them to 2x speed. They also had transcripts for the lectures which was helpful during the exam.

Since the assignments are in Unity, you will be using C#. I didn’t have much experience in C#, but knowing other languages help me ramp on it. The class was very organized and the professor was super responsive.

Assignments

Here is the breakdown of the Assignments:

Assignment 0 - “Roll-A-Ball” Unity Tutorial
Assignment 1 - Grid Lattice

Assignment 2 - Path Network

Assignment 3 - AStar Pathfinding

Assignment 4 - Navigation Mesh Generation

Assignment 5 - Decision Making with Finite State Machines (Prison Dodgeball)
- There was a tournament that you could have participated to get extra points, but I didn’t not go through it as I didn’t think my implementation was that great.

Assignment 6 - Race Track
- This was my favorite assignment because it was fun to see how I can create rules that trigger the vehicle to move right or left on its own depending on its position.

Assignment 7 - Procedural Content Generation
- This was the easiest assignment as there was no coding involved and was more about tweaking parameters in Unity. However, some students got creative with applying textures.

With each assignment (except the last one), there were regrade opportunities. You are allowed two weeks for assignments, so I never felt pressured to stay up late to finish an assignment. The hardest assignment for me was the Finite State Machine (Prison Dodgeball) assignment.

Exams

There was a midterm and a final (non cumulative). Both exams were open book and allowed 4 hours, which was more than enough. My score for the final was around the same as the midterm so the difficulty was fairly the same. The professor did curve the midterm which helped me retain an A.

How do I prepare for this course?

To prepare for this course, you can start with the Unity Tutorial (mentioned as Assignment 0 above). All of the assignments are done in Unity so a familiarity with that helps. Additionally, I recommend taking AI as some of the concepts in that course was reiterated in this class.

Lessons Learned

From this course, I was able to understand how AI is applied to games. I was able to learn how to use Unity and C# to complete some projects. This class inspired me to learn how to create games in Swift so I purchased this book: Apple Game Frameworks and Technologies: Build 2D Games with SpriteKit & Swift by Tammy Coron

Topics Covered:

How to create discretized spaces so that agents can move throughout the game world
How agents plan their paths whether using a grid lattice or navmesh to generate areas where they can move to
Understanding how agents make a decision depending on the circumstances that are occuring in the game state
In learning, we have exploitation and exploration where there is a balance between whether we want to explore or go down the path we believe has the highest reward
Games like minecraft uses procedural content generation to generate their terrain
Other topics: camera control, minimax, Monte Carlo Tree Search

[OMSCS] CS6300: Software Development Process

Wed, 12 May 2021 08:20:55 +0000

Part of my OMSCS Review series

CS6300: Software Development Process

In Spring 2021, I completed my second course in the OMSCS Program at Georgia Tech, Software Development Process (CS6300). I wanted to take this course because I am at the entry point of my career and wanted to get better insight on improving my software engineering skills.

As someone who didn’t graduate from a CS degree, I thought this was a good foundational course to improve my software engineering fundamentals and become a better developer. Overall, we learned about various software engineering practices and methodologies as well as implementing them through projects.

Topics Covered: git commands, basic android development, object oriented design, design documentation (i.e. requirements, test cases, use cases), white-box and black-box testing, agile methodologies, test-driven development (TDD), refactoring

I highly recommend taking this course for someone who doesn’t have much experience in software development or software engineering. It provides a pretty good foundation and highlights many topics that I see from my day job as an engineer.

This course definitely opens you up to consider what is good architecture design, what software development cycles are, agile methodology and keeping in mind testing / refactoring. The downside is that the individual project seemed a bit tedious as it was a bit difficult trying to figure out all the test cases that we needed to cover. However, I felt that this class was pretty fair and on the easy side of things. In my class, many of the students struggled with A6, but I felt that keeping it simple with this assignment and revisiting the lectures helped for doing well on this. Personally, the group project was the most time consuming as we had to schedule meetings with our team members and delegate tasks.

Professor Orso and the TA’s were pretty responsive in Piazza and they held Office Hours every week (though I didn’t attend all of them). Additionally the Slack channel for this course was also very helpful.

Tip: Pay close attention to Piazza and read each detail of the assignments.

Overall, I enjoyed being able to build an Android App that has a persistent database and multiple UI screens.

Course Overview

The workload for this course was pretty light and the lectures I was able to finish within two days after work. Each week there was an assignment and I typically finished them before the weekend. It was nice that as the assignment went on, the difficulty increased so there wasn’t a high learning curve for me. I did do a lot of googling when it came to building the Android App and developing in Java. Because I became used to implementing in Java, I started adding semi-colons at work haha.

Assignments

Here is the breakdown of the Assignments:

Assignment 0 - Participation / Syllabus Quiz
Assignment 1 - Team Matching Survey
Assignment 2 - Git Usage
Assignment 3 - Basic Java Coding and JUnit Testing
Assignment 4 - Simple Android App
Assignment 5 - Software Design
- Developing a UML diagram for the upcoming group project which will be used to compare with your team members
Group Project - Building an Android App to keep track of user’s current job, job offers and compare them
Assignment 6 - White-Box Testing
Individual Project - building a command line called cleave via Java that is used on a file and outputs a specific pattern. This command line had various options and for each option there is a different output. The goal of this project was to use test-driven development (TDD) by writing test cases before building the command line.

Exams

There were no exams so that was nice too! I really like project based courses.

How do I prepare for this course?

Personally, I didn’t prepare because I read on OMSCentral that the course had a light workload and was an easy A. Additionally, I have experience in coding in an OOP language (Swift), so it was easy to pick up Java. The main issue was understanding the IDE and the syntax of using Java as well as how to build an Android App.

Lessons Learned

From this class, I got to exercise my muscles in Java and developing Android Apps. We also utilized Android Studio and IntelliJ so got to have a bit of experience with those. This class inspired me to consider creating a simple Android app in the future. It was fun to be able to create and build an app, but also got to exercise my muscles in testing and addressing bugs.

From this class, these are my main take aways that I will keep in mind as I continue to progress my career and hobby in software development:

Create designs and diagrams to before building projects
Develop code that is maintainable and scalable
Consider testing when building new features and keep in mind TDD

Cyndi Chin

Firefox iOS: Homepage Rebuild Project

Overview

Homepage Feature

Background Context

Proposal

Goal

Expected Outcomes

Project Development

Set Up

Implementing New Homepage

Phase Breakdown

New Telemetry Guidelines

Writing Unit Tests

Decision Table

Testing the New Homepage

Checklist

Final Thoughts + Wrap Up

Xcode Testing Tools

Overview

Run tests repeatedly

Check code coverage

View the reports

Wrap up

More resources

First Look into Quick + Nimble

Quick + Nimble Overview

What is Quick + Nimble?

Quick + Nimble vs. XCTests

Setting Up Quick + Nimble via SPM

Quick Glance at Writing Unit Tests with Quick + Nimble

Resources

SwiftUI and Architecture Considerations

SwiftUI Overview

What is SwiftUI?

Resources

Common Architecture Patterns

SwiftUI Architecture in Pocket’s iOS App

Architectures aside MVVM

Considerations

Summary

Xcode Debugging Tools

Xcode Debugging Tools

UI Test Recorder

View Hierarchy

Memory Debugger

Environment Overrides

SwiftLint Overview

SwiftLint Overview

Installation

Add SwiftLint to Build Phase in Pocket (iOS)

Create the SwiftLint Configuration File

SwiftLint in Action

Custom Rules

Summary

[OMSCS] INTA 6450: Data Analytics + Security

INTA 6450: Data Analytics + Security

Do you recommend this course?

Course Overview

Assignments

How do I prepare for this course?

Lessons Learned

[Book Review] Essentialism by Greg Mckeown

Book Review: Essentialism by Greg Mckeown

Recommended If:

Highlights

Going Forward

Summary

Part I: Essence

Part II: Explore

Part III: Eliminate

Part IV: Execute

[OMSCS] CS7632: Game AI

CS7632: Game AI

Do you recommend this course?

Course Overview

Assignments

Exams

How do I prepare for this course?

Lessons Learned