Saturday, August 6, 2016

360|AnDev: CFP process

One of the reasons why I decided to run 360|AnDev is that I want a inclusive place for Android developers to learn from each other. Inclusivity has many dimensions: identities, financial status, level of experience, to name a few. We want everyone to feel welcome, and we know that the speakers will set a tone for the whole conference, so we were very careful in our CFP process.

Core track

I know from experience that conferences are great to forge connections that help you in your career, but a lot of beginners fear that they do not have enough background to participate. To address that, we dedicated one room one day to cover fundamental topics, to let beginners know that there is something for them.

The rest of the conference has more advanced topics so that we take of experienced developers as well.

Clear, specific guideline

When I reach out and ask people to speak, they often ask, why would anyone listen to me, and what would I talk about? We address those two questions specifically on the Call For Papers page.

Contrary to popular belief, you do not need to be an expert to teach. In fact, for fundamental classes it is often best to hear from someone who has just learned it. They know the pain points, and highlight details which may seem obvious to experts.

After that, we offer some topics to get people started. It is not an exhaustive list, but it gives a flavor of what we are looking for, which is much more useful than, "Everything is good, just submit!"

Cover travel cost

We want everyone to be able to come and speak, regardless of their financial situation. It costs quite a bit extra to cover 2 nights of hotel plus flight for each speaker, but we care about inclusivity enough to do so. This way, people don't shy away from submitting because they are between jobs, they work for themselves, their companies have murky policies about conference reimbursements etc.

Q&A hangout

Even with a detailed CFP page, we know we cannot anticipate all the questions. We hosted a Q&A hangout for potential speakers to chat with us directly. Yes, we answered questions, but the most powerful part about the hangout is to put a human face behind the conference, to have a chance to tell everyone that, yes, we want you. We have a few talks that resulted directly from the hangout.

Anonymous voting

With all that effort, we hope to have a variety of talk proposals from speakers with different background. Next step is to make sure that the selection process preserves that, rather than just pick out the famous people.

Our talk selection has two rounds. In the first round, we removed all personally identifiable information from titles and abstracts, and send them out to members of the Android community for voting. Here is the voting guideline:

  • 5: OMG I'll drop everything to see this talk (Please do not give this score to more than 20 talks).
  • 4: I'd like to see this talk.
  • 3: Neutral. I'll probably see this talk, but skip if there is another talk at the same time.
  • 2: I'd rather be in the hallway than see this talk.
  • 1: Offensive/Too commercial/Inappropriate.
  • 0: Abstain.

In the second round, Dave and I look at proposals from each track, from the highest-scoring one down. For the most part we just take the ones ranked highest by the voters, but sometimes there are multiple proposals on the same topic, and their scores are too close to use as a differentiator.

In that case, we compare the titles and abstracts to see what will be covered. We also look into the speaker to try to get a sense of how well the material will be delivered. This is why this round is no longer anonymous.

Final program

While there are still many ways to improve, we are very proud of what we managed to achieve for the first year of our conference. Here is our final speaker roster:

Friday, July 1, 2016

One year of sketchnoting

I made my first sketchnote at Write/Speak/Code 2015 on the impostor syndrome talk by Neha Batra.

I started with a single black pen, added a gray marker as I experimented with shading.

My friend saw the little gray hearts and suggested that I get the primary colors, which was perfect since I was about to attend Google I/O.

The overwhelmingly positive reaction I got for my sketchnotes gave me the confidence to try drawing as well, which, mind you, I grew up believing that I cannot draw. It was a pleasant surprise to discover the joy of copying and coloring.

When I first wrote about sketchnoting, I said there is no way I can draw portraits. Guess what, I do that now!

At Write/Speak/Code 2016 I sketchnoted for Neha again, and it is really fun to see how much I have progressed in a year.

You can do it too

I have seen many other engineers start sketchnoting since I posted my first sketchnote last year, and it was been absolutely delightful. Wanna get started? Here are some resources:

Saturday, June 25, 2016

Write/Speak/Code: 10x Myself

I am very active in the Android community, blogging and speaking and sharing code, but I can only do so much as one person. To scale my efforts, I mentor others to do the same, which aligns with the goals of Write/Speak/Code exactly.

During Write day last year I shared my conference report blogging formula, I have seen it being adopted widely. Some examples:

For speaking, last year I met fellow Android developers Yash Prabhu and Danielle Vass at Write/Speak/Code, and I am delighted to see them start their speaking careers shortly afterwards.

This year, I was on the writing panel again, and also moderated the conference organizers panel. I hope to inspire many more women to go forth and share their knowledge. Storify:

Besides mentoring, I took the opportunity of being surrounded by amazing women to level up my own career as well. One of my 2016 speaking goals is to give a keynote, and during Write/Speak/Code I brainstormed and refined a topic that I am super excited about: The State of Android Testing.

I'd love to hear your Write/Speak/Code story. Did you get started on writing, speaking or open source because of it? Let me know!

The State of Android Testing

We all know testing is good for you, but it is very overwhelming. What is a unit test? What is an instrumentation test? Espresso, Robolectric, Mockito… what do all these libraries do? More fundamentally, why should I test?

I'd like to give a keynote talk to answer all these questions. Do you know a conference that would be interested? Perhaps Droidcon NYC?

Saturday, June 4, 2016

Coding live stream

I first heard about live streaming when I watched Dina Rodriguez hand lettering on Twitch.

But I wasn't sure what to do in front of a live audience, so I didn't do anything about it until I met Liam Spradlin at Google I/O. He started streaming after watching Dina, and encouraged me to try it, giving me lots of practical tips. There was a lot of code labs announced at Google I/O, so I thought, hey I want to do them anyway, why not live stream too?

Software

OBS, Open Broadcaster Software. Free, available in Windows, Mac and Linux.

Streaming service

restream.io: Stream to many places at the same time. I picked:

Layout

Here is how my desktop looked like during live stream:

My monitor resolution is 2560x1600, and I cropped the Display Capture to 1920x1080 so get the 16:9 aspect ratio. I popped out the chats from the 3 services so I can monitor them, but put them outside of the capture area so my audience won't see them.

I put the emulator outside as well, and declare it as a source in OBS so it is always visible, even when I type in Android Studio. If I want to hide it, I move it down in the list of sources in OBS.

The last source is my webcam. I cropped it to a square.

Here is how it looks like when I stream:

The emulator source is in the top right, and the webcam source is in the bottom right.

Preparation

  • Click "Start Recording" in OBS to see what it captures, and adjust the microphone, webcam etc as needed.
  • Set up the channels in restream.io, and copy the stream key to OBS.
  • For each channel, set up archiving on the site itself e.g. YouTube.
  • Set up OBS with the instructions from livecoding.tv: https://www.livecoding.tv/obs-guide
  • Increase the font size of your browser and IDE.
  • Try out a little bit whatever you plan to do while streaming. I was going to stream from my Linux box, but couldn't get the Android Wear N Preivew emulator going, so I had to switch to my Mac.
  • Advertise multiple times before the live stream, and once again after you have started streaming.

Streaming

Keep an eye out on the chat windows when you stream. Live stream is much less fun without audience interaction! I say my reply out loud, but type links into the chat window so people can click on them.

Results

I trimmed the video to skip the initial part when I'm setting things up and waiting for people to show up.

People seem to like it!

Next

I'll try to stream once a month. I'll be announcing them on Twitter, and you can also subscribe to our YouTube channel to get notified of the recorded videos.

Thursday, June 2, 2016

Advanced Espresso at #io16

I missed the Advanced Espresso talk at Google I/O this year because it was at the same time as Building rich fitness experiences with Google Fit platform and Android Wear, where Fit Cat was featured.

Finally got a chance to watch it at home, and wow, lots of good tips and tricks!

onTransitionToIdle (at 10:33)

According to the talk, it's preferable to set the state of the idling resource once, and call the idle transition callback when the state changes to idle. A good example is CountingIdlingResource, in the decrement function.

I went back to look at my custom idling resources, and try to skip calling the idle transition callback in isIdleNow. That gives me this error:

Caused by: java.lang.IllegalStateException: Resource com.sqisland.espresso.idling_resource.intent_service.IntentServiceIdlingResource isIdleNow() is returning true, but a message indicating that the resource has transitioned from busy to idle was never sent.

So it's seems like I must call the callback. From the doc, it seems harmless to call it multiple times, so I'm going to leave my querying idling resources as is.

For idling resources that query the state in isIdleNow, there is no need to call the idle transition callback. See IntentServiceIdlingResource for an example.

loopMainThreadForAtLeast (at 11:18)

Try to avoid it, but if you need some time to pass in your test, do not call Thread.sleep or SystemClock.sleep. Instead, use UiController.loopMainThreadForAtLeast.

You will need to make a custom ViewAction to get access to the UiController. Note: Not to store the UIController outside the ViewAction, because it may not be valid any more.

More tips

  • (12:10) Do not copy and paste between tests. Create helper functions.
  • (13:35) Use available Matchers. Write your own only if necessary, with TypeSafeMatcher and BoundedMatcher.
  • (15:08) Use CountingIdlingResource.
  • (15:54) Change IdlingPolicy if the defaults are too short.
  • (16:35) Focus on testing behavior, not layout properties. Use position assertions e.g. isBelow if you must verify layout. They are relative and easier to maintain.
  • (17:35) Write many small tests rather than large ones.
  • (18:44) Launch directly into desired screen and state with intents.
  • (19:56) Most UI tests should be as hermetic as possible.
  • (20:37) Use Espresso Intents to intercept Intents that launch external apps.
  • (21:19) Learn how to run long running animations. Read ANIMATOR_DURATION_SCALE from system settings and disable that in your app when it is zero. Show surface updates from Developer Tools to see hidden animations.
  • (24:00) Implement your own FailureHandler if you want to log extra information when your test fails.
  • (24:41) Developer Tools FTW!
  • (25:05) Change touch and hold delay for slow devices / emulator
  • (25:49) Enable testing for accessibility issues. Super easy: AccessibilityValidator.enable()

Thank you Wojtek KaliciƄski for the informative talk!

Thursday, May 26, 2016

Tips on hosting Google Hangout on Air

My friend Yash is hosting an Ask Me Anything via Google Hangout, and asked me for some tips. Thought I'd share them with everyone!

Rule number one of Google Hangout: Anything that could go wrong, will.

That said, here are a few things you can do to make it better.

  1. Get on it 15 minutes before event time to get over technical difficulties.
  2. Go live 5 minutes before event time so people who come early can already see the live stream. Otherwise their window will stay static until they refresh i.e. they won't know the event has started. Also, by starting a bit early people can start posting questions already.
  3. Send reminder emails / tweet after you go live for the same reason as number 2.
  4. If you use the Q&A module, beware that it may or may not work. So you may need a different place to post questions e.g. the event comments.
  5. It's better to have another person to keep an eye on the questions so you can focus on talking. Have that person ask the questions for you to answer.

Here is an example of a Google Hangout on Air we did for 360|AnDev: