Daniel V. Klein
Daniel Klein is a Software and Site Reliability Engineer in Google's Pittsburgh office, where he alternately breaks things or fixes them for a living. His non-Google persona is also quite interesting.
Authored Publications
Sort By
Preview abstract
A modified alert triggering system modifies alerts associated with calendar events. The system identifies a user’s normal calendar hours. Further, the system determines that a calendar event is scheduled outside of user’s normal calendar hours. Based on determining that the calendar event is scheduled outside of user’s normal calendar hours, the system modifies an alert for the calendar event. For example, the modified alert can be louder than a normal alert, the modified alert can be a different alert tone than the normal alert tone, etc. The system then triggers the modified alert for the calendar event.
View details
Preview abstract
The disclosed subject matter relates to computer implemented methods for associating locations with healthcare events. In one aspect, a method includes receiving location data from a location-aware client device. The location data includes latitude and longitude information. The method further includes determining, based on the received location data, a routine travel pattern of a user associated with the location-aware client device. The method further includes detecting an anomaly in the routine travel pattern. The method further includes detecting a healthcare event. The healthcare event can be a visit to a healthcare facility and/or a healthcare transaction. The method further includes correlating the anomaly in the routine travel pattern of the user with the healthcare event. The method further includes associating one or more healthcare event locations to the healthcare event based on the correlation.
View details
Preview abstract
Spatial and/or temporal triggers may be established so that when actuated, one or more notifications such as reminders may be provided to one or more users. These triggers may be established manually, e.g., by a user operating a user interface, automatically, e.g., by scraping calendar and/or email data to ascertain and/or predict various aspects of upcoming appointments such as start times, duration, date, location, and so forth, or a combination of the two. Spatial triggers may be actuated based on a determination that a user is, or will be, at a particular location. Temporal triggers may be actuated at particular points in time, e.g., at the scheduled time of an event or at some predetermined time interval before or after the event. Using one or more triggers, it is possible to provide notifications to a user at some predetermined time interval prior to a scheduled event, so that the user has sufficient time to make appropriate arrangements, such as buying tickets, making a reservation, scheduling a rendezvous with a friend, and so forth. A calendar system may also be interfaced with to manually or automatically establish triggers.
View details
Preview abstract
Updating production software is a process that may require dozens, if not hundreds, of steps. These include creating and testing the new code, building new binaries and packages, associating the packages with a versioned release, updating the jobs in production datacenters, possibly modifying database schemata, and testing and verifying the results. There are boxes to check and approvals to seek, and the more automated the process, the easier it becomes. When releases can be made faster, it is possible to release more often, and organizationally, one becomes less afraid to “release early, release often”. This is the fundamental driving force behind the work described in this paper – making rollouts as easy and as automated as possible, so that when a “green” condition (defined below) is detected, we can more quickly perform a new rollout. Humans may still be needed somewhere in the loop, but we strive to reduce the purely mechanical toil they need to perform.
This paper describes how we, as Site Reliability Engineers working on several different Ads and Commerce services at Google, do this, and shares information on how to enable other organizations to do the same. We define Push On Green and describe the development and deployment of best practices that serve as a foundation for this kind of undertaking. Using a “sample service” at Google as an example, we look at the historical development of the mechanization of the rollout process, and discuss the steps taken to further automate it. We then examine the steps remaining, both near and long-term, as we continue to gain experience and advance the process towards full automation. We conclude with a set of concrete recommendations for other groups wishing to implement a Push On Green system that keeps production systems not only up-and-running, but also updated with as little engineer-involvement and user-visible downtime as possible.
View details
Preview abstract
A paste system can be used to generate hypertext based on determining context of a paste command. The paste system receives a selection of certain text in a document. The paste system then receives a paste command from a user of the paste system. The paste command can include data temporarily stored in memory, e.g., stored in a clipboard. The data can be stored as a result of a past copy command from the user. For example, the data can be a URL of a website. The paste system analyzes the data and determines if the data includes a URL. The system does this by, e.g., recognizing if the data includes “http” and/or “www”. If the system recognizes the data as URL, then the system generates hypertext from a combination of the selection of the text and the data. The user can then click on the generated hypertext and the hypertext system will automatically direct the user to the website identified by the URL.
View details
Preview abstract
We recommend the creation of a system that allows users to report, to an online database system, the originating telephone number of unwanted solicitations, advertisements or robotically placed calls (henceforth called 'spammers'). We also recommend that users' telephones or external hardware may automatically query the database about the telephone number of an incoming call (before the call is answered, or even before the telephone rings) to determine if the caller has been flagged as a spammer by other users, and optionally block the call or otherwise handle it differently from a non-spam call.
The recommended system thereby would provide a means whereby users can make reports of spam calls as well as ask if others have reported a caller as a spammer. While the first few people called would get spammed, after a sufficient number of reports are made, further calls would be blocked.
The recommended system would work on most types of telephonic platforms - smartphones, some feature phones, POTS lines, VoIP, PBX, and telephony providers - through the use of software and optional inline hardware. In addition to crowd-sourced blacklisting, we also recommend a means to whitelist specific numbers so that, for example, emergency calls will always go through.
View details
