Technical Talk Notes

There are 2 posts filed in Technical Talk Notes (this is page 1 of 1).

AnDevCon 2017 – How Yahoo Finance Scales on Android – Vikram Bodicherla

I saw Vikram‘s talk at Droidcon NYC 2016 talk about app performance, and wanted to make sure I made it to his talk.  He talks about overall processes for a successful development team along with tools and tips for shipping apps.

Developers shouldn’t be afraid to dip your toes into “product”.
 Contribute to feature definition to make your voice heard as a user and for technical implementation.

Understanding your users – Fantasy Football Example:
You should be aware of who is using your app. You might think everyone using a fantasy football app are very serious users, but we find that 12% randomly pick, and 60% are first year users. Try to find patterns between different types of users of your app. Build personas of your users. Building personas of your users is a way to explain behavior that would be hard to explain otherwise. Give these personas name and put them up on the wall in your office. Know who your users are and design for them.

Personas for fantasy football includes:

  • Seasoned pros
  • People that are forced to join by their friends
  • People that are serious, but learning
  • “average” users

Data Driven Decisions via Experiments:
DAUs and Downloads are really “Vanity Metrics”, since they don’t gain a ton of insight. Data driven insights are real; not opinions. Wrong decisions can be validated quickly, so feel empowered to test, measure, and grow. Instead of doing costly user research, you can push something to a small group of users, and gain data there vs. expensive user research.

Each experiment should have:

  • A hypothesis
  • An owner
  • A deadline for the end of the experiment.
  • Planned removal of the code from your app. You learned something from it, now “Let it go!!!”

Scrum
Planning is a good investment. You can see how long things will take, determine dependencies, and people can show interest in pieces of the work.  Agile is important because it’s not adverse to change like Waterfall is.

Types of stories in Scrum:

  • User story
  • Engineering story

Scrum story checklist:

  • Clear definition
  • Acceptance criteria
  • Edge cases and error scenarios
  • Analytics
  • Animations and design

Grooming

  • should be (1x/week for 1 hour)
  • It helps the team to understand stories -> Determine level of effort for stories (Points)
  • Stories should have reasonable detail. Be very critical and make sure the story is well defined.
  • Don’t get hung up on one story. If your getting hung up, move on and take that offline so you don’t waste your entire grooming on one thing.
  • NEVER write stories during Grooming.
  • NEVER point a story that doesn’t have all the details.

If you get roll-over and carry-over after a sprint consistently, you’re doing something wrong and should revisit your processes.

Daily stand-ups should be no greater than 10 minutes and should provide high level updates. Low level updates should be taken “offline”, or “parking lotted”.

At the end of the sprint, you can hold a retrospective and demo completed stories.  Please prepare up front for this so we don’t have to wait for you to launch the emulator or recompile your project.

“If you’re are not practicing scrum in sprit, you are better off not doing it.”

Continuous Delivery

  • Minimizing the time between “code complete” and “deployable”
  • deployable != deploy
  • This can only be achieved with continuous integration (CI)
  • If you do deploy immediately to your users, you get immediate feedback, but not always the best for your users. Vikram recommend every 2 weeks on average, but depends.
  • Have internal alpha and beta programs for internal users to try the app before it goes to production.

Pull Request (PR) Tools

  • facebook/mention-bot – Can tag reviewers based on “git blame” history
  • SonarCube
  • https://codecov.io for Code Coverage
  • Danger -> Keep PRs <500 lines, PR message should be >25 chars.
  • Emulator in an iframe, running the code in the PR.  -> https://appetize.io Removes need to compile and install.

APK storage and deployment:

Culture

  • How you act/think/interact. Keep high standards, because you are what your lowest standard is.
  • Ownership is important. Communicate deviations and compromises so it’s not lost. Proactively check app quality issues and triage as soon as you can.
  • Set goals, but aim for 70%. If you get 100%, then your goals are not high enough.

Meeting etiquite

  • Everyone needs to have value, or they shouldn’t be there
  • Reject meetings if they are not needed
  • Meeting owner should have adgenda, goals and come out with action items.
  • There should be a hard start and end type.

Code is a liability. Once it’s out there, you have to support it. Changing code is expensive.  Deleting code is a good thing.

Feature Flags – Client-side feature flags are important, along with remote feature flags.  Client-side flags should take priority, but if it’s on, then use the remote flag.

AnDevCon 2017 – A Room With a ViewModel – Mark Murphy (CommonsWare)

Word of the day: “Transmogrify”
“to transform, especially in a surprising or magical manner.”

Mark draws a great comparison between Room and Retrofit as they both use annotation processing, and describe either a URL path, or a DB query.  The @Query annotation in Room, is similar to the path in Retrofit that is provided to @GET, @POST, etc.

Parameters can be sent with the syntax :postalCodes.  You can pass parameters into a query this way:

@Query(“SELECT * FROM Customer WHERE postalCode IN (:postalCodes)”)
List<Customer> findCustomersInPostalCodes(String… postalCodes)

Cool DB Testing Tip for Android Instrumentation Tests: In-memory databases work the same way that SQLite databases do that are saved to the disk. In-memory database are great for instrumentation tests because they are fast, and when you are done with it, it’s gone from memory, and doesn’t persist to disk.  It’s not recommended to use in-memory databases in true client apps however.

Types used in Room need a @TypeConverter.  You can specify the type converters to be used in the following way:

@TypeConverters({TypeConverter.class})

Caveats about relations:
You can use @ForeignKey on a child, but… <OMG head explosion />.  Foreign keys are there, but there aren’t any magical methods generated to retrieve a child. You can just get an ID for the child, and then have to re-query for that. You can specify cascading deletes however which is useful.

Room Migrations – Create instances of Migration –  A little more sane than just plain SQLite.

Note about SQLCipher – It was last updated in 2009, and the APIs are really hard (if not impossible) to integrate with Room.

LiveData – Room works really well with Rx programming. 🙂

Predictions: We will go through a lot of iterations of the APIs as kinks are worked out and things stabilized.  The guess is that a final version would be available around Google I/O 2018.

Check out Mark Murphy on the internet: