Contact Tracing and Exposure Notification
An overview of the COVID-19 Exposure Notification API by Google & Apple
An overview of the COVID-19 Exposure Notification API by Google & Apple
I have a relatively simple problem, my cat, Nick, can open our front door and let himself out. Since he's a strictly indoor cat, this is a problem. In true computer nerd fashion, I way over-engineered a solution to lock the doors automatically after a specified delay to prevent Nick from escaping. My solution involves the [Ruby Functions Framework](https://github.com/GoogleCloudPlatform/functions-framework-ruby), a container, [Google Cloud Run](https://cloud.google.com/run), and [Google Cloud Tasks](https://cloud.google.com/tasks).
After writing up or reading about all these interviews, I feel like I can offer some general tips on how to do well on DevRel interviews. Of course, standard caveats apply. I've only done DevRel at Google and only know Google's hiring process inside and out. But, I believe the tips below are general enough to apply to many other companies as well.
It has been a while since I wrote about App Engine and Ruby. Honestly, there wasn't a lot of news to share. It continued to work! But now Google has released App Engine Standard for Ruby. And that gives me a chance to address the common issues people reported during early testing.
A couple of months ago, my coworker [Mark Mandel](https://twitter.com/Neurotic) asked if anyone had a way of visualizing dependencies in [Cloud Build](https://cloud.google.com/cloud-build/). As you'd expect, several of us jumped at the problem. I wrote my solution up in Ruby using the graph gem.
All of the problems I see in mentorship come from one flawed assumption. Too many folks assume their mentee is just like them. Or at least that their mentee is a younger, less experienced, or less capable version of themselves. And once that assumption is made it is hard to be an effective mentor.
Many people don't understand that giving a good interview is a skill that can be learned and improved. There seems to be a tendency to use the same questions that you were asked when you were a candidate. It also seems like new interviewers often overestimate what can be accomplished in 30 - 60 minutes or where the hiring bar should be for a position. Whatever the reason, the result is that many technical interview questions are pretty awful at assessing anything. So I figured today I'd try to give some guidance on improving your interview questions.
This is where friction logs come in handy. A friction log is a document that lists out all the little stuff that makes the tool hard to use but frames it around a narrative or customer use case. I learned about them in my first weeks at Google. We often ask new DevRelers to write friction logs for common scenarios they are familiar with from previous work. The critical difference between a friction log and a bug list is that the friction log puts the issues in context. It tells the story of the entire user experience from start to finish. Well written friction logs are one of the best tools I know for developing user empathy in folks who don't get to talk to customers very often.
Many folks who are new to operations approach things with an absolutist mindset. They see things as correct or incorrect and secure or insecure. In reality, operations of all types is balancing opposing forces. After all, the most secure website in the world wouldn't be accessible to anyone and certainly wouldn't have users.
Org-mode supports arbitrary tags on headlines. If you are using Org to track tasks, then you might tag items "work" or "phone". Tags go at the end of the line, surrounded by colons. You can use `C-c C-C` to enter a tag in the minibuffer, but most of the time I type the tag, surrounded by colons.
A few weeks back, Myles Borins and I did a talk at Google I/O about choosing which cloud services to use in different situations. We both feel that the best technical talks have a solid storyline and so we had a hypothetical business built around "Cat Facts as a Service" motivating our talk.
I've had some fantastic managers. The folks I've worked for at Google have been especially supportive. They help me reach my goals and also make room for me to be me. Like most of us though, I've had a few bad managers as well. One incident, in particular, stands out.
Earlier this week I got to help host a group of girls visiting Google. They are middle school students in an after-school program focused on engineering, mathematics, and science. My role during the day was to lead computational thinking activities from [CS Unplugged](https://classic.csunplugged.org/). Based on advice from co-workers the group completed the [Error Detection](https://classic.csunplugged.org/error-detection/) and [Sorting Networks](https://classic.csunplugged.org/sorting-networks/) activities. It was during the sorting networks activity that the kids taught me how vital even subtle parts of UI could be.
About a week ago my mac complained that it was running out of disk space. I deleted a bunch of old TV shows and GoPro videos and called it good. Today I went to do an external backup and saw that my drive was still full. Half an hour of investigation and I realized my 500 GB drive had 230 GB of local Time Machine backups. In fact, it was full enough that the Time Machine GUI wouldn't start, I couldn't run more backups, and several other basic utilities on my mac stopped working. It took about three hours of experimenting to get the backups under control and the disk back to 50% full. If you run into a similar situation here's what worked for me.
In Python list comprehensions are used in places where a Rubyists would chain methods from Enumerable. For example, if I wanted to return the squares of all multiples of three less than 50 in Ruby, I would write something like this.
There's a good chance you have some kinds of tests for your code. You probably have some unit tests and you may have higher level integration tests. Maybe your integration tests are written in something like [cucumber](https://cucumber.io) or a [record/replay](https://www.cio.com/article/3077286/application-testing/record-playback-automation-its-a-trap.html) test automation tool. Now, the hard question, do you run these tests against production? Most folks I talk to don't. They think of testing as something that happens in pre-production environments. If you have a QA/test team working on your project you may even think of testing as something that delays the push from development to production. As a former tester, I'd like to propose that you run at least some of your tests against production.
I noticed that people had a lot of assumptions about what a made a whiteboard answer good. Most of those assumptions were not things that I and others I know look for in whiteboard interviews. So I decided to share what I'm looking for in a whiteboard interview.
Auntie Aja is back. This time I want to talk a bit about conference session proposals. It is CFP season. I'm busy submitting talk proposals to events I want to attend. My coworkers and friends are doing the same. Like many folks, I'm asking coworkers and friends to review my abstracts to make sure I'm not missing anything important. I'm also advising people who don't submit to events very often on how to improve the chances that their submission will be accepted. Today I'll cover some of the issues I see over and over.
The tech industry has a problem that I refer to as the " the toaster problem," which is of course, best illustrated by "the parable of the toaster". Suppose you are in the break room and a new employee says "Hey, can you help me with the toaster?" You spend the next 10 minutes explaining how the various knobs and dials work. You say that this toaster uses photoelectric sensors to detect browning instead of a thermostat or a timer. You teach them that the little red bits inside the toaster are filaments that have electric current run through them and that's why you shouldn't stick a knife into the toaster while it is plugged in.
I can't tell you how to make your buckets and objects 100% secure, I can give you some basic advice that is pretty universally applicable. The vast majority of this information came from a week of research into the security of GCS buckets in a typical use case that I did in early December.
Earlier this week, a conversation on the Seattle.rb Slack reminded me of one of my favorite hidden Gems in Ruby, the `case` statement. Most languages have syntax for multiway branching. Java calls it `switch`. Lisp uses `cond`. Ruby calls it `case` which relates back to the [mathematical roots](https://en.wikipedia.org/wiki/Switch_statement#History) of this construct. Ruby's implementation of this feature is particularly flexible, and many folks don't realize all the things you can do with it.
Audit logs are boring. At least we hope they’re boring. If your audit logs are exciting, you are likely having a bad day. But audit logging of some sort is often a good idea, and many of us forget to set it up and verify that we understand the data on a regular basis. This post walks through setting up and using the audit logging capabilities of GCP.
This year there have been many problems that require writing an interpreter for a simple language. My favorite of these has been [day 16](http://adventofcode.com/2017/day/16) which had you execute some dance moves that modify an array. One of the dance moves is 'spin' which involves rotating the array by a constant. Another is 'exchange X Y' where the elements in the array at X and Y change places. The moves themselves aren't complicated. The parsing of the input file isn't complicated either. The problem gets hard though when you are asked to execute the entire sequence of dance moves 999,999,999 times.
December 8th is my three year anniversary at Google. Every year I've written an anniversary blog post talking about what I've learned about Developer Relations as a career in the past year. Last December I decided my theme for 2017 would be "consistency and sustainability," but looking back, the unintentional theme of this year ended up being risk-taking. I'm guessing that the value of mid-career risk-taking isn't unique to DevRel, but interpersonal risk-taking has been the source of many of my proudest moments over the last year, so it seems to be a worthy topic for a blog post.
I find it distasteful that I'm writing a blog post on personal brand. When I started thinking about the topic about five years ago every fiber of my nerdy self bristled at the idea. Like many developers, I wanted to believe that it was only the content that mattered and eventually people would see the brilliance in my ideas. But as much as I wish the world were a pure meritocracy, it isn't. How you present ideas matters, and part of presenting your ideas is how you present yourself.
One way to build things like Twitter bots is to use Markov Chains. If you read the formal papers on Markov Chains and Markov Models, they seem quite complex, but they are pretty simple. The basic rule that all Markov processes must satisfy is that what happens next must be determinable only from the current state.
I write most of my posts in Markdown. For things I can't neatly do in Markdown, I'll use erb or even straight HTML. Since ZenWeb lets me have multiple renderers per file I can mix and match these as well. My blog also makes extensive use of conditionals and includes. For example, depending on the date on a post either the MIT license or the Apache 2 license (which Google prefers) is added to the footer. This footer is only added to posts where syntax highlighting is turned on. I also have code that automatically adds links to GitHub when I put `code: [link here]` in the metadata at the top of the post.
The App Engine gem provides a set of tools that make it easier to use App Engine with Ruby and especially with Rails. It isn't that it is hard to use App Engine with Rails, we know folks are doing it already. In fact, I've used it for some of my projects, but we knew we could do better.
If no one has told you yet, as your career in tech progresses you will eventually become a custodian of culture. If you run a meetup or a team, if you lead an open source project, or if you organize an event people will be looking to you to know what is and isn't okay in that space. You get this responsibility whether you want it or not. You don't have to be internet famous to have this responsibility. If there are people you work with who have been around for less time than you, then you are going to help set the culture for them.
All the conferences I've spoken at use a body-mounted mic. The most common types are lapel mics, which clip on your shirt, or over the ear mics, which may end up taped to your face. Body mics always have a battery pack that is about the size of a deck of playing cards. If you are wearing pants with usable pockets or belt loops, you can either put the battery pack in a pocket or hang it from your belt. If you aren't wearing pants, or your pockets are not big enough, finding a place to put the battery pack is a challenge.
On September 5th I put my battleship API to the test by having the attendees at Seattle.rb's quarterly coding workshop try to build clients against it. In the process, I learned some interesting things.
One technique for doing classification is called K Nearest Neighbors or KNN. To use the algorithm you need to have some data that you've already classified correctly and a new data point that you wish to classify. Then you find the K (a somewhat arbitrary number) of existing data points that are the most similar (or near) to your new datapoint. You assign the new datapoint to whatever class the majority of the neighbors have.
Last time I finished writing the battleship server. The next step is to deploy it somewhere. I'm close to my first real deadline, Seattle.rb next Tuesday evening, so I'm taking the easy way out and deploying it on Google App Engine. In the future, I plan to write up a blog post for doing a Kubernetes deployment. I also hope to eventually port the logic to both Node.js and Python because I think the language comparison will be interesting.
This post should help you learn some of the power user features of Stackdriver Logging. I encourage you to try some of the things in the post so that when you are working to resolve an outage, you already know the tools well.
A handful of folks have asked, 'Are you okay?'. That's a surprisingly hard question. I'm going to be more honest and less generous than I usually am and hope it doesn't have significant negative repercussions.
My initial design called for two endpoints, `/new_game` and `/turn`. I added a third endpoint at `/` that displays the rules and the format for messages to the other endpoints. One assumption I made is that the server always goes second. This isn't necessary but made figuring out the logic much simpler.
Based on a Twitter Poll I'll be doing a series on the basics of Machine Learning over the next few months. I plan to have a post out on the first Thuday of every month covering some algorithm or conceptual aspect of Machine Lepparning.
Last Time I wrote about a set of data structures and objects to implement battleship. I promised that this time I'd show how to implement the turn taking and running the game locally against itself.
One of my goals for this summer is to get out of my Ruby rut. I love Ruby. I like how the language feels. I like the principle of least surprise. I appreciate that it has both strong object oriented and functional roots. And of course, I love the Ruby community. As much as I love Ruby, I believe most successful programmers are polyglots and can be productive in multiple languages. So I came up with what I'm calling the battleship project.
The biggest issue I have as a minority in tech is knowing when something happens because of my gender or when it happens for other reasons. Another way I phrase is this is, 'did that happen because the other person is sexist, because I'm a jerk, or because the other person an equal opportunity jerk?'
Many people say tech interviews are awful. I'm not going to question that. I think, for the most part, all interviews are awful. It is both easy to decide in 30 - 60 minutes if you feel that someone can do the job, and hard to be sure that you are making that decision for the right reasons.
You are not your code. You are not your ideas. You are not your products. You are not your job. You are not your employer. If I had to give one piece advice to any random person in tech, I would say, 'you are not your code'. This is not a unique piece of advice. A quick search for 'You Are Not Your Code' on Google returns more than 150,000 results. However, it is the piece of advice that took me a long time to understand and has had a large impact on my overall contentment and my job satisfaction.
A couple of weeks ago I wrote about some of the handy methods that are part of the Enumerable module in Ruby. This week I thought I would talk about how you can create a class that has all these handy methods by using the Enumerable mixin in your class.
For this month I wanted to branch out and focus on technical or scientific talks from outside of the Ruby community.
The product I am most excited about at the moment is Stackdriver Debugger. Every time I get to demonstrate Debugger at a conference people are initially incredulous. Once they see that it actually works and that I am not just making stuff up they are either excited or curious about how it works.
Managing my to do list and staying focused has often been a challenge. At previous jobs, I used a variety of online tools to manage my tasks. When my work was bug driven, I used the OmniFocus Ruby gems to pull my tasks into OmniFocus, and then every day I triaged my tasks in OmniFocus. When my work was mostly in Trello, I grabbed a card (or was assigned one) and a pair after standup every morning and tried to finish it by evening. Both of those workflows worked well for me.
This week I have been learning how to access Stackdriver Monitoring with the google-cloud-monitoring gem.
Giving a good keynote is harder than presenting a regular session. If it is a plenary session, you need to deliver content that is interesting and relevant to a wide range of skill levels and interests. Speaking first thing in the morning or last of the day also means that you have to be engaging to convince folks to show up or not leave early.
I wanted to reprise a demo I did at RubyConf 2015 where I used a distributed system to do sentiment analysis based on emoji. At the time I felt I had used some of the hottest technologies. I used Docker containers for each of the different pieces of the pipeline and then used Kubernetes to orchestrate the whole thing. It seemed like a logical way to deploy something that I hoped I would spin up and down on a regular basis as the need for a Kubernetes demo arose. Last week I dug into the code to try and get the demo running again after a 12-month hiatus. It is amazing what you forget during that time. I am sharing some of what I learned in this blog post so that hopefully someone else doesn't have to have the same battle I did.
A lot of Rubyists do not know much of enumerable beyond `each`. Here are a handful of methods that are handy to know both for interviews and general purpose coding.
At RailsConf I'll be giving a talk on Natural Language Processing. As part of my preparation for this talk, I've been reading a bunch of the history of Natural Language Processing, and I've been experimenting with Google's Natural Language API. The Ruby Gem for this API is alpha, but it works well enough to do basic experimentation.
Thus far my 'Talks I Love' series has only included technical talks. At this point it would be easy to believe that this series is about fantastic technical content, not about the art of speaking. But this series has always been focused on the art of speaking and I've been wanting to pull from non-technical sources of inspiration. So this month, instead of technical talks I've used speeches from American politicians.
In Minesweeper, when you click on a square the game reveals the number of mines nearby. If there aren't any mines nearby, the neighboring squares are revealed. If those squares do not have any mines nearby, the process is repeated until you get to a square that has a mine nearby. This behavior, a progressive reveal until you get near a mine, is the trickiest part of implementing the game. The first two implementations I tried didn't work. Then I remembered, when I implemented Minesweeper in college I used depth-first search for the progressive reveal.
At Google Cloud Next two weeks ago I had the chance to chat with many folks using or experimenting with Google products. Questions about change management and audit logging came up frequently. Some folks wanted notifications for configuration changes. Others wanted a quick and easy way to see who is doing what for auditing purposes. Many attendees were not aware of Google Cloud's existing audit logging capabilities or how to set alerts on specific audited events.
As I'm writing tutorials, working on new code, or creating my talks I usually take notes. A couple years ago I adopted `org-mode` in Emacs for my notes.
As we have gotten closer to GA, I've built a few non-trivial Rails applications and deployed them to GAE. I've also given some one-on-one help to others deploying to App Engine or Google Cloud for the first time. In this process, we've found and fixed a few bugs, and I've built a list of common things that trip people up on their first deploys.
This month's 'Talks I Love' post focuses on speaking rate. For me, this is one of the most challenging aspects of good delivery. My normal speaking rate is faster than average, and when I get nervous that rate increases even more. Learning to slow down, pause, and let things sink in is one of my current speaking goals.
This week I sat down to learn the tools that were available for monitoring BigQuery using Stackdriver.
The most important thing you can do is listen. Actively listen with the intent to understand. Don't focus on how you can respond to what you are hearing but try to get a solid understanding of things from someone who has direct experience.
Google Cloud Next is March 8 - 10 in San Francisco. We have a dedicated team of a long time Ruby developers making large strides in our Ruby support. Here are several talks that I believe Ruby developers would enjoy.
Google Cloud Next is March 8 - 10 in San Francisco. There are many breakout sessions for all sorts of different interests and skill levels. Here are some of the sessions I think will be interesting to DevOps engineers and those in related roles.
One of the most useful phrases I know is 'What are you trying to do?'. I use it a lot when I am helping folks learn. I use it a lot with myself when I'm feeling overwhelmed.
There are several different ways. Some are better suited for particular scenarios. I thought I would write up what the options are and when I would choose to use each method.
Storytelling is at the core of all public speaking. A story is the backbone of a good talk.
I've been really enjoying it as a diversion from my holiday tasks. I've finished fourteen of the twenty-five problems at this point and thought it would be fun to do a walkthrough of how I approach these problems.
Two years ago I started work in Developer Relations. I had absolutely no idea what my job would look like when I started. I was pretty sure it would involve public speaking, but I wasn't sure what else I would do.
Fog has the uneviable task of trying to provide a logical unified interface to a large number of cloud providers that have different functionality and philosophies.
Like most of America, I watched the presidential debates. While I did pay attention to the content, I was more drawn in by the speaking style of each of the candidates. Rhetoric is one of my nerdy passions.
Managing API keys and other secrets across a build and deployment pipeline can be a pain.
This is a quick tutorial on uploading files to Google Cloud Storage with Ruby.
The headline for this blog post is a bit sensational. Realistically I can't tell you why a given talk was accepted or rejected.
A couple years ago I sat in the back of a talk listening to the person on stage discuss their struggle with depression.
At one of the local meet-ups I attend containers and containerization is a relatively common topic of discussion. Google is a big advocate of containers so it probably isn't a surprise that there are four different ways to run a container on Google Cloud Platform.
So what does fostering diversity look like if diversity isn't a check box?
Recently, Google Cloud Platform and GitHub made data from nearly three million open source repositories available on BigQuery.
While we were discussing this, the tester in me wondered, what are the most common 500 gems?
Once I had a basic Sinatra app running I wanted to see how difficult it would be to add support for uploading files.
I've been a Developer Advocate at Google for a bit over a year now. I was really unsure when I took this position but now I feel like I finally starting to figure it out.
My team at work recently launched a series of one-minute videos that we're calling Cloud Minute.
This is the third part in my series on building and deploying a Rails app using Docker containers and Kubernetes.
Kubernetes will take care of some of the low level monitoring and management tasks so that I can focus more on application development.
To try out Docker I wrote a simple To Do list application using the rails scaffold.
Using BigQuery for log investigation lets you use familiar tools like SQL to dig into your logs, extract the interesting data, and even make charts of the data.
On Monday I had the opportunity to help host a group of 29 5th and 6th grade girls at the Google office in Fremont.
I know a lot of folks (myself included) get thwarted trying to make a hash of arrays
This blog post is a basic outline of my process for problem solving mathy stuff
Seattle.rb has had a second Euler coding challenge now and the third is currently underway.
After being initially skeptical of Dev Bootcamps I've come to appreciate the work they do and believe they have a place in the landscape...
People who've learned the basics of programming (in Ruby or another language) need resources that help them get coding 'mileage'
During the last six months it feels like at every Seattle.rb meeting we have someone who is brand new and asks 'How do I learn to code?' or 'How do I learn Ruby?'.
To remedy this I'm putting my money where my mouth is and offering up $100 to be split between two winners of a Coding Challenge during May 2014.
Data is a hot buzz word in the industry. Every day there are more startups using Big Data
Data is a hot buzz word in the industry. Every day there are more startups using Big Data
`assert_nothing_raised` is the 9th most commonly used assertion in ruby
For the month of June I'm going to spend 2.5 hours a week on my personal programming projects.
Tests reassure me that I didn't break anything and when I do break things they help me find the problem.
Your tests verify that your code is functioning correctly. Good tests verify the contract/api the software provides to users.
Like most people, I have days where I find it hard to concentrate and be productive.
Tomorrow I'll be giving a talk called A Taste of Prolog at Cascadia Ruby Conf.