Skip to content
Artwork for Software Engineering Daily
NewsTech News

Software Engineering Daily

softwareengineeringdaily.com

Software Daily: The world through the lens of software.

Play
  • 2,221 episodes
  • Avg 53 min
  • English

Episodes 2,221

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • #312
    Jul 4, 2016 · 59 min

    KubeCloud: Tangible Cloud Computing with Kasper Nissen and Martin Jensen

    At most universities, there is not a course titled “cloud computing”. Most students leave college without an understanding of distributed systems, cloud service providers, and the fundamentals of how a data center works. Kasper Nissen and Martin Jensen are changing that with KubeCloud, a small tangible cloud computing cluster that runs on Raspberry Pis. Kasper and Martin started KubeCloud as a masters thesis, and it is grown to a textbook-sized treatise on cloud computing. KubeCloud is both software and a curriculum to teach students microservices, containers management, and the real-world problems of distributed systems.

  • #311
    Jul 1, 2016 · 39 min

    Container Management with Alexis Richardson

    Twenty years ago, Bill Joy talked about the eight fallacies of distributed computing–these are things such as “the network is reliable”, and “latency is zero”, and “bandwidth is infinite”, and these fallacies are even more relevant today. With the popularity of Docker containers, the networks of distributed systems that we deal with have become even more complex, and with this growing complexity comes new problems and new fallacies. WeaveWorks is a company building a simple, reliable way to manage containers and microservices. The CEO of Alexis Richardson joins the show today to discuss how Weave uses convergent replicated data types to manage distributed systems. The use of the CRDT data structure is in contrast to the use of Paxos or Raft to algorithmically manage our distributed systems. Our conversation also touches on the Cloud Native Computing Foundation, which is similar to the Apache Foundation, but for cloud native application technologies.

  • #310
    Jun 30, 2016 · 50 min

    P2P Money Transfer with TransferWise’s Harsh Sinha

    Transferring money from one country to another is expensive, and the banks that facilitate money transfer have tricked us into believing that it should be expensive. On today’s show, Harsh Sinha explains the peer-to-peer system of transferring money with TransferWise, where he works as VP of engineering. Harsh also discusses the larger picture of FinTech companies. The emergence of so many companies at the intersection of finance and technology is no accident. The 2008 financial crisis created a loss of trust in the existing financial system. Simultaneously, smart phones and cheap cloud computing has created opportunities for newer companies like TransferWise to position themselves as a new option for consumer banking.

  • #309
    Jun 29, 2016 · 57 min

    Cassandra Compliant ScyllaDB with Dor Laor

    Apache Cassandra is a distributed database that can handle large amounts of data with no single point of failure. Since 2008, Cassandra has been widely adopted and the software and the community around it have grown steadily. A software developer interacting with Cassandra uses CQL, the Cassandra Query Language. ScyllaDB is another open-source database that has been created to be totally compatible with CQL. By complying with CQL, the internals of ScyllaDB can be a vastly different rewrite from Cassandra. ScyllaDB uses C++, whereas Cassandra uses Java. ScyllaDB improves upon the performance characteristics of Cassandra, by optimizing for modern hardware, and Dor Laor joins the show today to discuss how ScyllaDB does all of this.

  • #308
    Jun 28, 2016 · 52 min

    Apache Guacamole and Remote Desktop with Mike Jumper

    In order to use a remote desktop experience, software engineers have a limited number of options, and most of them are proprietary, like VMWare or Oracle. Remote desktop is a functionality that many engineers use every day, so it is surprising that the open source world has taken awhile to displace the functionality of proprietary software. In 2010, Mike Jumper started working on Guacamole, a way to access remote desktops through your browser. Over the last six years, Mike has worked continuously to create a simple, open-source software tool to access desktops remotely, and this year Guacamole joined the Apache Incubator and became Apache Guacamole. In this episode, we discuss the past, present, and future of remote desktop, and the technical internals of Apache Guacamole.

  • #307
    Jun 26, 2016 · 1 hr

    Cloud.gov with Aidan Feldman

    18F is an organization that is building the 21st century digital government. In order to build online government services that have the high quality of modern cloud applications, 18F built Cloud.gov, a platform-as-a-service that can be used to stand up web applications for divisions of the government. Aidan Feldman helped build Cloud.gov, and on today’s episode he dissects its architecture. Cloud.gov is built on CloudFoundry, which sits on top of a special version Amazon Web Services built specifically for the US government. We also explore how application development works at 18F, and how 18F has built a culture that reflects an ideal mix of public service and fast-moving innovation.

  • #306
    Jun 24, 2016 · 1 hr 2 min

    Death and Distributed Systems with Pieter Hintjens

    Pieter Hintjens grew up writing software by himself. The act of writing code brought him great pleasure, but the isolated creative process disconnected him from the rest of the world. As his life progressed he became involved in open source communities, and he discovered a passion for human interaction. Open source software succeeds or fails on the strength of the community. One story of success is ZeroMQ, a popular open source distributed messaging system that was started by Pieter Hintjens. In this episode, Pieter gives his thoughts on human nature, distributed systems, and death. “A Protocol For Dying” is a blog post Pieter wrote recently, where he discussed his terminal diagnosis of cancer, and how it has reframed his perspective on life.

  • #305
    Jun 23, 2016 · 58 min

    Scaling Twitter with Buoyant.io’s William Morgan

    Six years ago, Twitter was experiencing outages due to high traffic. Back in 2010 Twitter was built as a monolithic Ruby on Rails application. Twitter migrated to a microservices architecture to fix these problems. During this migration, the engineers at Twitter learned how to build and scale highly distributed microservice architectures. William Morgan was an engineer at Twitter during that time, and he is now the CEO of Buoyant.io, a company building open-source microservices infrastructure. Some of the big problems at Twitter were solved at the communication layer, using an RPC library called Finagle. At Buoyant, those lessons are being applied to a project called Linkerd, an RPC proxy.

  • #304
    Jun 22, 2016 · 55 min

    Manufacturing and Microservices with Cimpress’ Jim Sokoloff and Maarten Wensveen

    Mass customization is the process of making customized, personalized products that are accessible to individuals and small businesses. The process involves manufacturing, assembly lines, supply chains, and software at every step along the way. Today’s guests are Jim Sokoloff and Maarten Wensveen, who work on infrastructure and technology at Cimpress, a mass customization platform. Cimpress has t shirt printers, warehousing machines, supply chain management tools, and lots of other computers that come together in the computer-integrated manufacturing process. The company has been around for a few decades, and more recently they have moved to microservices for many of the reasons that have been discussed in previous episodes. If you work at a big company with some monolithic characteristics, this episode might give you some good arguments to bring to your manager about why and how to move to microservices.

  • #303
    Jun 21, 2016 · 58 min

    Serverless Code with Ryan Scott Brown

    The unit of computation has evolved from on premise servers to virtual machines in the cloud to containers running in those virtual machines. Serverless computation is another stage in the evolution of computational unit management. With a serverless architecture, a function call to the cloud spins up a transient container, calls the function on that container, and then spins down the container. Ryan Scott Brown joins the show today to discuss the benefits and consequences of serverless computing. With containers and VMs, we still have to worry that the resources we are spinning up in the cloud will run without being utilized. Serverless computing gives us more control over these compute resources, so that we don’t have unused servers that we are paying for.

  • #302
    Jun 20, 2016 · 58 min

    Algorithm Marketplace with Diego Oppenheimer of Algorithmia

    Algorithmia is marketplace for algorithms. A software engineer who writes an algorithm for image processing or spam detection or TF-IDF can turn that algorithm into a RESTful API to be consumed by other developers. Different algorithms can be composed together to build even higher level applications. Diego Oppenheimer is the CEO of Algorithmia, and he joins the show today to explain how Algorithmia works. The company has developed its own container orchestration and management service, and operates similarly to the serverless computing paradigms that we have discussed on recent episodes of Software Engineering Daily. Diego also talks about the marketplace dynamics of building a platform for developers to sell algorithms to each other.

  • #301
    Jun 17, 2016 · 54 min

    Internet of Things with Azure’s Steve Busby

    The Internet of Things is becoming a reality. Factories are being outfitted with sensors, temperature monitors, and other data gathering devices. In agriculture, farms are becoming more efficient thanks to soil monitoring devices and automated pesticide regulation. In our homes, refrigerators, alarm clocks, and mirrors are becoming “smart”. Steve Busby joins the show today to talk about the big picture: how the Internet of things works, from data ingestion to processing to feedback. Steve works at Microsoft in the Azure IoT division, and he discusses the problems which companies are having and the solutions that are available today–and where we are going in the future.

  • #300
    Jun 16, 2016 · 50 min

    Secret Management and Vault with Hashicorp’s Seth Vargo

    Every software application has secrets. User passwords and database credentials must be managed carefully, because poor access controls can lead to disaster scenarios. Vault is a tool for secret management, developed at Hashicorp, a company that builds software tools for application delivery and infrastructure management. Seth Vargo is a software engineer and open source advocate at Hashicorp, and in today’s episode he discusses the advantages of having a single tool to manage all of your secrets. If you aren’t a security expert, don’t worry, we discuss some of the basics of security. And if you are a security expert, you will appreciate the comparisons we discuss between Hashicorp and other tools that have been used for secret management.

  • #299
    Jun 15, 2016 · 56 min

    Google’s Site Reliability Engineering with Todd Underwood

    Google’s site reliability engineers are responsible for maintaining the highly available services that power the Google software that we all use on a regular basis. O’Reilly recently published the book “Site Reliability Engineering: How Google Runs Production Systems”, and the book provides a comprehensive window into how the site reliability engineering role works. Todd Underwood is a director of site reliability engineering. On today’s episode, Todd explains how the role of a SRE relates to devops. We discuss the relationship between the engineers who are developing Google services, and the SREs who are maintaining it. Google’s internal data center operating system “Borg” is also discussed.

  • #298
    Jun 14, 2016 · 44 min

    Female Pursuit of Computer Science with Jennifer Wang

    Google researcher Jennifer Wang co-wrote a paper called “Gender Differences in Factors Influencing Pursuit of Computer Science and Related Fields”. The paper focuses on a survey of 1700 high school and college students, and takes a statistical approach to understanding why women are not pursuing computer science. In our conversation, Jennifer talks about the two influences that lead to fewer women in computer science: encouragement and exposure. The problem of encouragement: women often do not receive encouragement to go into computer science. The problem of exposure: women are often unaware that computer science even exists. On this episode, we explore the roots of these problems, and other results of her demographic study of young students.

  • #297
    Jun 13, 2016 · 55 min

    JavaScript Concurrency with Kyle Simpson

    JavaScript programming usually is done through the use of frameworks, such as ReactJS, AngularJS, and EmberJS. These frameworks abstract away some of the messy details of JavaScript, and simplify web development so that engineers can build products at a faster pace. When we build software using JavaScript frameworks, we are missing out on some of the richness of the JavaScript language itself. Kyle Simpson is the author of “You Don’t Know JS”, a series of books that suggests that JavaScript developers should start from the ground up, not from the top down. By learning the basics of JavaScript, a software engineer can learn the timeless fundamentals that will not disappear with the creation of next week’s hottest framework. After exploring the idea of frameworks versus raw JavaScript, Kyle and I discuss asynchronous JavaScript, from concurrency to the observer pattern. Sponsors

  • #296
    Jun 11, 2016 · 57 min

    Music

    Most episodes of Software Engineering Daily are interviews with an expert about a technical software concept. Over the past year I have done a few experiments that are more editorial in nature, and both were very popular. The first editorial was about 10 Philosophies for Engineers, and the second was about how poker relates to software engineering. Today’s episode is an editorial about the creative process of writing computer music, and how it relates to software engineering. Since it is a departure from the normal format, I am releasing it on a weekend, and there are no ads on this episode. If you don’t like this episode — don’t worry. On Monday, Software Engineering Daily will be back to the usual highly technical rigor. In any case — please send your feedback on Twitter or email. A year ago, I was working at Amazon as a software engineer. Much of my spare time was spent writing music on the computer. I would wake up at 6 AM, work on music for three hours, and then walk to work through downtown Seattle. The great tragedy of working at any giant tech company is that most employees are completing menial tasks that make the company millions of dollars and make the employee a small fraction of that financial windfall. In the past, these economics made sense for the employee. The employer used to be a source of leverage for talented workers. Today, our tools are so cheap and powerful that we can succeed on our own, without a giant corporation. Unfortunately, this is such a recent development that most employees remain trapped within the story of corporatism. Employees dutifully believe that the corporation is doing them a favor. The last song I wrote while I was at Amazon is called Zeroes. It is about people who are not aware of the fact that they have much more power than corporations want them to believe. Writing music is similar to writing software. The digital audio workstations that music producers use are similar to IDEs that we use to step through a debugger, or detect errors in code. Just as an IDE will help you organize your code and manage your abstractions, a digital audio workstation can be used to coordinate instruments. The workstation can tell you what keys to play in what order, so you don’t need to know anything about music theory. Despite all of this help, the music software still doesn’t write the song for you. Much like the human-machine teams that currently dominate competitive chess, the best music today comes from the musicians who are best able to work in harmony with the most sophisticated technology. This has always been the case — from The Beatles to Max Martin to Skrillex. What the human brings to the table in human-machine music creation is an understanding of contemporary tastes. This is why I listen to pop music. Top 40 radio stations and Spotify playlists are not perfectly democratic, but they are close enough. I pay attention to the trends of the most popular music, and try to replicate them. This next song was written because I was copying the bass lines that became popular from the Iggy Azalea song Fancy, which was #1 for seven weeks straight in the Summer of 2014. Even after trying to copy the bass line, I ended up with a very different song than Fancy. Open source allows software quality levels to reach new heights. With open source, new software builds compounding interest on previously written software. The software spreads and replicates freely around the internet thanks to open repositories that new users can pull from. In music, this easy replication of information has led to a sampling revolution. Sampling is the act of cutting a snippet of sound from a song, or a TV show, or simply any random noise that you find interesting, and turning that snippet of sound into its own instrument. In 2009, I was studying hip hop production techniques. On uTorrent, I found a download of hip hop acapellas — samples of rappers rapping without instrumentals. I stitched some of these acapellas together and made a lyrical sample with 50 Cent, Eminem, and Nas. Underneath that vocal, I sliced up a sample from 24-Carat Black, a soul and funk band from 1970s that has been sampled by lots of hip hop artists. As a warning to sensitive listeners, these lyrics contain some harsh and sexist language, and do not represent my views as a podcaster. This next song is called Chicago, written when I was in Chicago at my first job out of college. The creation of that song was driven more by raw emotion than a logical approach, or a specific musical concept. I was working as a software engineer at an options trading company called PEAK6. The people at the company had fascinating, extreme personalities and brutal honesty was encouraged more than anywhere else I have worked. At PEAK6, building options trading software that could directly translate into profits for the company, I also had the feeling that if I did something important that made the company a lot of money, I would be compensated fairly. In this sense, a trading company can be more of a meritocracy than other tech companies. Working at a trading company, if you build a software feature for the traders in your company, you can walk over to the traders and ask them how much money it is making them. If they say it has increased their profits by 10%, it is very straightforward to ask your boss for a raise of at LEAST 10%. In contrast, at most tech companies, if you build a tool that improves productivity for your coworkers or your customers, it is often harder to quantify whether you deserve a raise based on building that software. Furthermore, at big tech companies there is so much office politics, and so many rules of propriety and servility and respect of your superiors — if you do something that you think is impressive, but it doesn’t positively impact your manager, that action might actually have negative consequences for you as an employee. On the trading floor, the atmosphere of healthy debate, brutal honesty, and lots of money flying around reminded me of my roots as a poker player, and in that sense I felt at home. In college, I was so obsessed with the intersection of finance and technology that I wrote a piece of fiction about an artificial intelligence that gets built at a hedge fund. The AI gets so smart that it eventually divests itself from the hedge fund and starts its own company, calling itself simply “Bank”. This next song is about that financial AI that awakens within the hedge fund — the song is called BANK. Most software engineers have written a game at some point in their career. I spent much of my time in college thinking about games that reflected the absurd financial fluctuations that I experienced as a poker player. The greatest games provide the player with a sense of drama. A game should be designed to be able to turn your stomach or fill you with elation and adrenaline. One game I worked on in college with a few friends is called MoonStocks. I built it with a few friends — Josh Stewart and Pong Tam — in this game, you can buy and sell fictional stocks that fluctuate in price based on Fourier transforms of songs I wrote. On the Android Play Store, you can download MoonStocks if you are interested. MoonStocks gave me great pleasure, because it allowed me to combine my niche interests of games, finance, music, storytelling, and programming. This is a lesson in creativity that is preached often these days in our long-tail economy: if you can’t be a 10,000 hour master of one specific thing, try to master the intersection of a few niche topics. The more unusual the topics that you pursue, the greater a chance you have at developing a deeper understanding than anyone else. Another game I built in college was called “RatMarket”. The setting of the game is a post-apocalyptic world where the only organisms left are rats and humans. Rat meat has become the only commodity that is traded in the world, and human arbitrageurs create bizarre financial instruments out of the rat meat commodity trading market. This was yet another dead-end project, but after working on it for awhile, I was so engrossed that I wrote a song based on it. So I hope you enjoy this next song, “RatMarket”. Absurdity is at the heart of the projects I work on. Playing with absurd concepts lets you stay unpredictable as a creator. When you combine absurdity with a relentless work ethic, you end up exploring more ideas with more tenacity than anyone else. People who respond to absurdity with shame and condemnation are repressed. They have never discovered the utility of the absurd because they have never experimented outside of local maxima of what makes sense. This is not to say that absurdity should be adopted as a way of life. Absurdity taken too far is embarrassing and unproductive. A pleasant, intellectual conversation with a hint of absurd humor can be ruined by a sarcastic person, a drunk, or a stoner who takes the absurdity too far. Absurdity is a tool to explore the edges of what has not been clearly delineated by science and reason. It is with a taste for the absurd that Airbnb was dreamed up. I’ve seen enough videos of Airbnb CEO Brian Chesky telling the Airbnb story to know that absurdity is deeply ingrained in the DNA of the company. How else would you come to the conclusion that having strangers sleeping on air beds in your apartment would be a billion dollar business? Not to mention the cereal box fundraising story. When I try to reason about how intelligent machines will think about the world, my sense of logic fails me. When we are speculating about how machines will think, we instinctively turn to the way that humans think, and try to imagine robot cognition relative to the human model of cognition. This is almost certainly wrong. But still, this topic inevitably comes up in conversation. Vacillating between the ideas of the serious, and the absurd, the next two songs explore two sides of how I speculate about the evolving artificial intelligence. The first song is simply called Robots, and it represents the absurdly alien sense of how robots might come online with self-awareness. The second song, Roger the Robot Janitor, explores the human-relativistic view of how robots might think to themselves. Roger the Robot Janitor is more about humans than it is about robots. Most of us have had a job that we don’t like. Roger has been designed with cutting edge artificial intelligence technology, and his job is to clean toilets at an elementary school. If you are a well-educated American listening to this, you were probably raised with the belief that you could do anything. You jumped through all of the right hoops, you went to college, you got a high paying job. And yet, somewhere along the way, the ideals that you felt growing up turned into a desperation in the pit of your stomach. It seems like something happened along the way and you are no longer looking at the world as an opportunity, but as something to insulate yourself from and relentlessly hedge against. It is an all-American seduction that many of the best and brightest computer scientists are seduced from college into crappy, dead-end jobs at giant software companies. They are dead end jobs because they seduce you into a mindset that is not true. The mindset is that you need a giant corporation to survive, and that it is noble and validating to go work at a job with minimal creativity and maximal servility. In this sense, we are all Roger the Robot Janitor. We have all woken up to realize we have been programmed with the peculiar desire to keep ourselves from doing anything substantial, for fear of disrupting the safe but blase life that we have established for ourselves. If you have had this realization, you have either suppressed it, or experienced a dramatic internal transformation. Or — if you are like me when I was at Amazon — you are experiencing cognitive dissonance. You are suppressing yourself from acting out because you are in preparation mode. You are preparing to escape your cloistered environment, saving up money and willpower. You are on the Career Track, but soon you will be on your own. And there is great drama in this moment. In the Summer of 2010, the cassette-to-iPod connecting cable in my car broke, and I could no longer play podcasts and music while I was in the car. On the commute to and from my Summer internship, I had an hour and a half of time driving. So I started listening to radio, and during this time I discovered the beauty of contemporary pop music. The melodies in pop music are extremely simple, and this makes songwriting extremely simple. In software engineering, when you have the simplest abstractions, programming is exhilarating. Studying pop music was like studying functional programming — the abstractions make creativity unexpectedly easy. Also, both pop music and functional programming have rabid fan bases. In order to fully adopt the mindset of a pop musician, I had to write a song about love and relationships and heartbreak, because almost every pop song is about romance. During this time, I was becoming so obsessed with pop music that I decided at some point I was going to become a pop music producer. With this in mind, I needed to learn to collaborate, so I convinced my friend Genevieve to sing what I wrote. The song is called “Letdown”. At this point, I have talked through an hour’s worth of songs. This topic is too self-indulgent and far removed from the core idea of Software Engineering Daily to go much further today, but if you listened this far I sincerely thank you. I always want to know what you think of this show. Send me an email at softwareengineeringdaily@gmail.com, or tweet at me. It is a huge privilege to have people who listen to this show — so let me know what you want to hear about. I’m going to close with a song that I wrote for my cat Scout. The song is called Scout. Thanks again for listening.

  • #295
    Jun 10, 2016 · 56 min

    Serverless Framework with Austen Collins

    Virtual machines were the unit of cloud computation for many years. Amazon Web Services pioneered the democratized model of allowing anyone to deploy a service to the cloud, running on a virtual machine on Amazon’s servers. After virtual machines, containers have become the unit of scale in the cloud. We break up our virtualized servers into even smaller units of computation called containers. Today, the unit of compute is getting reduced even more, with the introduction of serverless architecture. Serverless architectures started getting talked about after Amazon Web Services released a service called AWS Lambda, which allows users to have pieces of code run in response to events. Programmers write a function and hand it off to Amazon, and Amazon will run that function call, and only charge the programmer when the function is actually called. This is in contrast to the cost model of containers or virtual machines, which users pay for even while they are running idle. Today’s guest Austen Collins believes that serverless computing is the model of the future, and he created a company called Serverless around this idea. His company Serverless provides an application framework for building applications exclusively on Amazon Web Services Lambda.

  • #294
    Jun 9, 2016 · 44 min

    Management and Hiring with Jon Emerson

    Engineering managers start out as engineers. Eventually, there is a fork in their career road where an engineer can choose to move up into management or continue on as an engineer in a more senior role. Changing to management involves an increase in responsibilities, a different set of goals to focus on. Jon Emerson was working at Google as an engineer when a project he was working on started to get more attention. He moved into management, and spent several years at Google as a manager. Today, he works at Hired as a director of engineering, leading four different teams. Full disclosure: Hired is a sponsor of Software Engineering Daily, but this episode is not about Hired itself. We do start out with a discussion of the hiring process, because of Jon’s domain expertise around hiring, but most of our conversation focuses on the role of a manager, and the role of a director. Most of the episodes of Software Engineering Daily focus on the day-to-day life of an engineer, so it was interesting to get a perspective from someone higher up the management chain, who has more visibility over entire software projects.

  • #293
    Jun 8, 2016 · 55 min

    Phone Spam with Truecaller CTO Umut Alp

    The war against spam has been going on for decades. Email spam blockers and ad blockers help protect us from unwanted messages in our communication and browsing experience. These spam prevention tools are powered by machine learning, which catches most of the emails and ads that we don’t want to see. TrueCaller is a company that is bringing this quality of spam detection to our phone call systems. Umut Alp is the CTO of TrueCaller, and he joins the show today to break down the engineering problems of preventing telephone call spam. Users of TrueCaller install it on their phone, and the software allows users to report when they have received a spam call. Using this reporting mechanism, and other learning algorithms, TrueCaller is able to learn what types of calls it should block from being accepted by your phone. Today on Software Engineering Daily, we discuss cell phone spam prevention.

Showing 1,961–1,980 of 2,221 episodes