Demo Data from EDBT 2026 / reviewers in the wild / expert
Krishna Nareddy
dblp:124/2188
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2014
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Computer networks · 1Software engineering, systems software and programming languages · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Storage systems · 100% |
Topics — the 2 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Storage systems › storage architecture › block storage
cloud block storage |
0.2 | 1 | 2014 | Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications · NSDI 2014 |
Storage systems
virtual storage |
0.1 | 1 | 2014 | Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications · NSDI 2014 |
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2014 | Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications
James W. Mickens, Ed Nightingale, Jeremy Elson, Darren Gehring, Asim Kadav, Vijay Chidambaram, Krishna Nareddy |
NSDI | 9 |
| 2012 | Facilitating enterprise software developer communication with CARESabstractEnterprise software developers must regularly communicate with one another to obtain information and coordinate changes to legacy code, but find it cumbersome and complicated to determine the most relevant and expedient person to contact. This becomes especially difficult when the relevant person has transferred teams or changed their personal contact information since contributing to the project. We conducted a year-long series of surveys and interviews to help us learn how, why, and how often software developers discover and communicate with one another. In response to what we saw, we designed, deployed, and evaluated a domain-specific, IDE-embedded, photo-oriented, communication tool. We overcame a significant challenge found in long-lived projects: uniquely identifying individuals years after their contributions to the project. After deploying our tool, iteratively refining it, and deploying it again on a company-wide scale, most users reported that it simplified the process of finding and reaching out to other developers and offered them a sense of community with their colleagues, even if those colleagues did not currently work on their team. The lessons learned from our study and tool development should apply to other large, multi-team, legacy software projects. Anja Guzzi, Andrew Begel, Jessica K. Miller, Krishna Nareddy |
ICSM | 4 |