NewsTech News

Software Engineering Daily

softwareengineeringdaily.com

Software Daily: The world through the lens of software.

Play

Open in

2,221 episodes
Avg 53 min
English

Episodes 2,221

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

#978
Nov 16, 2018 · 1 hr 7 min
Reflow: Distributed Incremental Processing with Marius Eriksen
The volume of data in the world is always increasing. The costs of storing that data is always decreasing. And the means for processing that data is always evolving. Sensors, cameras, and other small computers gather large quantities of data from the physical world around us. User analytics tools gather information about how we are interacting with the Internet. Logging servers collect terabytes of records about how our systems are performing. From the popularity of MapReduce, to the rise of open source distributed processing frameworks like Spark and Flink, to the wide variety of cloud services like BigQuery: there is an endless set of choices for how to analyze gigantic sets of data. Machine learning training and inference is another dimension of the modern data engineering stack. Whereas tools like Spark and BigQuery are great for performing ad-hoc queries, systems like TensorFlow are optimized for the model training and deployment process. Stitching together these tools allows a developer to compose workflows for how data pipelines progress through a data engineering system. One popular tool for this is Apache Airflow, which was created in 2014 and is widely used at companies like Airbnb. Over the next few years, we will see a proliferation of new tools in the world of data engineering–and for good reason. There is a wealth of opportunity for companies to leverage their data to make better decisions, and potentially to clean and offer their internal data as APIs and pre-trained machine learning models. Today, there is a vast number of enterprises who are modernizing their software development process with Kubernetes, cloud providers, and continuous delivery. Eventually, these enterprises will improve their complex software architecture, and will move from a defensive position to an offensive one. These enterprises will shift their modernization efforts from “DevOps” to “DataOps”, and thousands of software vendors will be ready to sell them new software for modernizing their data platform. There is not a consensus for the best way to build and run a “data platform”. Nearly every company we have talked to on the show has a different definition and a different architecture for their “data platform”: Doordash, Dremio, Prisma, Uber, MapR, Snowflake, Confluent, Databricks… We don’t expect to have a concise answer for how to run a data platform any time soon–but on the bright side, data infrastructure seems to be improving. Companies are increasingly able to ask questions about their data and get quick answers, in contrast to the data breadlines that were so prevalent five years ago. Today we cover yet another approach to large scale data processing. Reflow is a system for incremental data processing in the cloud. Reflow includes a functional, domain specific language for writing workflow programs, a runtime for evaluating those programs incrementally, and a scheduler for dynamically provisioning resources for those workflows. Reflow was created for large bioinformatics workloads, but should be broadly applicable to scientific and engineering computing workloads. Reflow evaluates programs incrementally. Whenever the input data or the program changes, only the outputs that depend on the changes are recomputed. This minimizes the amount of recomputation that needs to be performed across a computational graph. Marius Eriksen is the creator of Reflow and an engineer at GRAIL. He joins the show to discuss the motivation for a new data processing system–which involves explaining why workloads in bioinformatics are different than in some other domains.
#976
Nov 15, 2018 · 57 min
Liquid Software with Baruch Sadogursky
The software release process is a barrier between written code and a live production environment that affects users. A software release process can involve a variety of different practices. Code might be tested for bugs using automation and manual testing. Static analysis tools can look at the code for potential memory leaks. A software release might go out to a small percentage of the total user base before it gets deployed to the entire audience. At some organizations, a software release can be slow and painful. The release might be bottlenecked by a manual approval step, which slows down developers from quickly deploying their own changes. If a consistent version history of software is not maintained, a release can be hard to roll back in the event of an error. In the case of a large, monolithic architecture, a release can be scary, because it can be hard to understand how the monolithic codebase functions. This set of challenges within the release process lowers the quality of software, and can make it frustrating to build software. The release process is just one area of software development that many organizations have a desire to smooth out. Over the past ten years, a set of technologies and philosophies have provided improvements to the software development process. DevOps, continuous delivery, microservices, cloud providers, and serverless tools all make it easier for a company to focus on its core competency and release software faster. Baruch Sadogursky is an author of Liquid Software, a book about continuous updates and DevOps. Liquid Software describes an idealized vision of what today’s architecture could aspire to. The focus of the book is continuous updates, which allow for rapidly improving, evolving software quality. Baruch joins the show to discuss how software has changed in the last twenty years, and how the future of software development could look. Full disclosure: Baruch works at JFrog, which is a sponsor of Software Engineering Daily.
#974
Nov 14, 2018 · 55 min
SPIFFE: Zero Trust Workload Identification with Evan Gilman
Modern software consists of sprawling international networks of servers. Users contact these servers to access applications. Microservices talk to each other to fulfill complicated requests. Databases and machine learning frameworks crunch terabytes of information to provide complicated answers. Across this infrastructure, there is a lot of different activities–and a lot of vulnerabilities. Without a reliable model for security and trust, software can be easily compromised. In the past, systems were often protected by a “firewall”, which is a security system around the perimeter of the network. A problem with this model is that if the attacker is able to penetrate the firewall, they can compromise anywhere in the network. Firewalls can be penetrated, so a much better security model is to assume that your network has already been compromised, and to require every internal system to identify and authenticate with each other. “Zero-trust security” is a security model that requires internal systems to communicate with each other as if they were potentially compromised. Evan Gilman is the author of Zero Trust Networks: Building Secure Systems in Untrusted Networks. He also works on SPIFFE, a system for managing identity and trust within a zero-trust network. In a previous episode about Google BeyondCorp, Max Saltonstall talked about zero-trust networking in the context of user and device authentication. In today’s episode, Evan discusses another side of zero-trust networking: workload identity and authentication. Just as Google BeyondCorp outlines an architecture for allowing devices to communicate with the network, the SPIFFE project outlines a system for workloads to identify and authenticate themselves. Workloads can range from MapReduce jobs to microservices to frontend application servers.
#972
Nov 13, 2018 · 1 hr 5 min
Fission: Serverless on Kubernetes with Soam Vasani
Serverless computing abstracts away the idea of a server node. Serverless lets programmers treat compute resources as high-level, reliable APIs, rather than unreliable, low-level compute nodes that might fail. Serverless dramatically improves the efficiency of programmers. Instead of thinking of a database as a set of servers that need to be sharded and replicated, the programmer can think of a database as a place to read and write data. Instead of modeling an application as a large monolith running on an application server in a container or a VM, the programmer can think of their application as a decoupled set of functions. Serverless computing is a natural evolution of software engineering in a world with cloud providers. The first version of FaaS came out of AWS with their Lambda service, which allows users to run functions in the cloud. Those functions are scheduled onto a physical server somewhere in an Amazon data center. They are executed, and they return the result. With AWS Lambda, programmers got a new abstraction to model their applications with. But it requires the use of a closed-source API. Lambda is not open source, and this makes some developers reluctant to integrate with it too tightly. Fission is an open source framework for serverless functions built on Kubernetes. Fission allows developers to deploy functions-as-a-service without being locked in to any specific cloud provider. Soam Vasani is the creator of Fission and an engineer at Platform9. In a previous episode, Soam talked about the architecture for Fission and the design choices for solving the cold start and scheduling problems. Soam joins the show today to discuss how serverless applications have evolved since last spoke more than a year ago. He also talks about how Fission itself has evolved, and the features that an open source serverless platform needs to have in order to compete with a fully developed cloud provider. Full disclosure: Platform9 is a sponsor of Software Engineering Daily.
#970
Nov 12, 2018 · 54 min
Open Policy Agent with Torin Sandall
Policies define which users and applications can access and modify resources in a computer system. In a file system, a user might have permission to read or write to a file. In a cloud infrastructure deployment, a user might have the rights to deploy a new server. One microservice may or may not have the necessary permissions to talk to another microservice. All of these are use cases where a “policy” defines the behavior within a computer system. Policies in a company can be managed in a range of ways: configuration files, dashboards, and centralized permissions databases. A policy engine is a system for managing and automating the policy creation and deployment within an organization. Microservices need to verify each request that comes in to ensure that the request has the correct permissions. To check those permissions, a microservice can contact the policy engine. The policy engine has all the information from the whole organization about who is allowed to do what. However, talking to the policy engine over the network can be a slow process. Open Policy Agent is a deployable agent that can run as a sidecar next to a service, and check policies by looking inside of a cache. Torin Sandall is a core committer to the Open Policy Agent project, and he joins the show to talk about policy management, the Open Policy Agent, and the Kubernetes ecosystem (and surprisingly, WebAssembly).
#968
Nov 9, 2018 · 38 min
TLA+ with Leslie Lamport
TLA+ is a formal specification language. TLA+ is used to design, model, and verify concurrent systems. TLA+ allows a user to describe a system formally with simple, precise mathematics. TLA+ was designed by Leslie Lamport, a computer scientist and Turing Award winner. Leslie joins the show to talk about the purpose of TLA+. Since its creation in 1999, TLA+ has been used to discover bugs in systems such as Amazon S3, DynamoDB, Xbox, and Cosmos DB. “TLA” stands for “temporal logic of actions”, a logical system that can be used to describe the behaviours of concurrent systems. This podcast is meant as a brief introduction of TLA+. To go deeper, check out the TLA+ website and the TLA+ video course (note: these videos are highly entertaining because of Leslie’s dry, unpredictable sense of humor).
#966
Nov 8, 2018 · 56 min
Computer Vision with Peter Kontschieder
Mapillary is a company that processes high volumes of images to develop a labeled 3-D model of the physical world. Mapillary’s APIs allow developers to build applications that are aware of stop signs, buildings, streets, trees, and other physical objects in real-world space. The potential use cases for Mapillary are numerous, ranging from self-driving cars to augmented reality. We can now build a 3-D model of the real world. It’s not a perfect representation of reality, but it is much better than we had just a few years ago. What has changed? How have the tools advanced such that we are able to build an API for accessing accurate information about the physical world around us? Mapillary is possible because of a combination of modern developments. High quality smartphone cameras enable users to crowdsource images of the world around them. Cloud computing allows for cheap workload processing. Newer computer vision techniques allow 2-D images to be stitched together in a 3-D representation. Deep learning architectures improve the classification and segmentation of objects in an image. Peter Kontschieder is the head of research at Mapillary, and he joins the show to talk about the technologies and research that has enabled Mapillary to build a futuristic business–an API for accessing information about the physical world. Software Engineering Daily is looking for sponsors. If you are interested in reaching over 50,000 developers, you can go to softwareengineeringdaily.com/sponsor to find out more, and you can send us a message. We’d love to hear from you. And if you are an engineer working at a company that is marketing to developers, or hiring developers, if you tell your marketing department or your recruiting department about softwareengineeringdaily.com/sponsor, that is one way to help us out.
#965
Nov 7, 2018 · 53 min
Computer Architecture with Dave Patterson
An instruction set defines a low level programming language for moving information throughout a computer. In the early 1970’s, the prevalent instruction set language used a large vocabulary of different instructions. One justification for a large instruction set was that it would give a programmer more freedom to express the logic of their programs. Many of these instructions were rarely used. Think of your favorite programming language (or your favorite human language). What percentage of words in the vocabulary do you need to communicate effectively? We sometimes call these language features “syntactic sugar”. They add expressivity to a language, but may not improve functionality or efficiency. These extra language features can have a cost. Dave Patterson and John Hennessy created the RISC architecture: Reduced Instruction Set Compiler architecture. RISC proposed reducing the size of the instruction set so that the important instructions could be optimized for. Programs would become more efficient, easier to analyze, and easier to debug. Dave Patterson’s first paper on RISC was rejected. He continued to research the architecture and advocate for it. Eventually RISC became widely accepted, and Dave won a Turing Award together with John Hennessy. Dave joins the show to talk about his work on RISC and his continued work in computer science research to the present. He is involved in the Berkeley RISELab and works at Google on the Tensor Processing Unit. Machine learning is an ocean of new scientific breakthroughs and applications that will change our lives. It was inspiring to hear Dave talk about the changing nature of computing, from cloud computing to security to hardware design.
#963
Nov 6, 2018 · 59 min
OSS Capital with Joseph Jacks
Open source projects benefit from the network effects of a large audience of developers. A popular open source project will be contributed to and used by thousands of developers, who are continuously testing, deploying, and improving the software. The open source movement has created massive communities and a thriving, collaborative economy. Infrastructure software companies are increasingly built within an open source business model. Databases, queueing systems, orchestrators, operating systems, and search engines have been started as freely available open source projects, and leveraged into billion dollar businesses. In previous shows we have talked about business strategy, go-to-market tactics, and licensing of infrastructure software. There remains plenty of room for more open source infrastructure companies. We still need better databases and distributed systems management. But over time, open source will move up the stack. From Netflix to Uber to social networks to payments systems–all software verticals will become open source because the benefits of making your software open source outweigh the costs. For many software business models, the competitive advantage is not found in their source code–it’s in their data, their network effects, their sales strategy, and their brand. Therefore, it makes sense that someday the source code will be freely available, democratizing the infrastructure concerns and letting these software businesses move up the value chain and become less operationally intensive at the bottom of the stack. Rather than asking “why should we open source our code”, these companies will be asking “why shouldn’t we open source our code?” Joseph Jacks is the founder of OSS Capital, a venture capital firm that invests exclusively in commercial OSS startup companies. Joe believes that over time, open source eats everything. In today’s show, we talk about the future of open source businesses, the impact of licensing, cloud providers, and cryptocurrencies.
#961
Nov 5, 2018 · 58 min
Commons Clause with Kevin Wang
Open source software powers everything we do on the Internet. Google runs on Linux servers. Content sites are served by WordPress. Our data is queued in Kafka clusters and stored in MongoDB instances. The success of an open source project often leads to the creator of that open source software becoming wealthy. An open source project can be monetized through enterprise add-ons, or consultation, or simplified hosting. The creators of open source software know their domains so well, that they are usually well-suited to operate this kind of open source business. Open source business model success stories include Elastic (ElasticSearch), Cloudera (Hadoop), and Red Hat. The rise in usage of cloud providers has changed the viability of some open source business models. AWS can monetize almost any open source project more profitably than the creators. This is because AWS has established distribution channels. If I already run my application on AWS, and I am looking for someone to provide me with a hosted version of a database, I will probably choose the hosted database that AWS provides. The Commons Clause is a license that open source projects can use to protect their code from being profited from. Redis, an open source in-memory object storage system, recently licensed their code with the Commons Clause with the goal of improving the business of Redis Labs, a company built by the creators of the Redis project. Kevin Wang joins the show to discuss everything open source–from business models to security vulnerabilities to licensing. Kevin is the CEO at FOSSA, a system for managing open source licensing and security. Kevin was involved in the creation of the Commons Clause and has written about it in detail.
#959
Nov 2, 2018 · 54 min
Scaling Lyft with Matt Klein
Matt Klein has worked for three rapidly growing Internet companies. At AWS, he worked on EC2, the compute-as-a-service product that powers a large percentage of the Internet. At Twitter, he helped scale the infrastructure in the chaotic days before Twitter’s IPO. Today he works at Lyft, building systems to allow for ride sharing infrastructure to work more safely and reliably. Hypergrowth Internet companies are faced with quickly growing demands on their software. The demands on the software expose problems with the core infrastructure. Simultaneously, the company tries to ramp up its hiring process. More engineers get hired, and the institutional knowledge within the company starts to weaken. Documentation gets out of date. Senior engineers burn out and leave the company. When a company starts growing quickly, communications can break down. A hypergrowth company can suffer from a lack of “human scalability”. Matt Klein has observed these challenges at AWS, Twitter, and Lyft. In his article “The Human Scalability of ‘DevOps’”, he explains why these problems manifest and what can be done to alleviate them. In a previous show, Matt discussed the engineering challenges at Lyft that led him to create Envoy, a service proxy. This episode covers some broad technical topics–DevOps, site reliability engineering, platform engineering–but the episode is mostly about how a hypergrowth company can manage culture, hiring, and engineering organization. Matt is a very fun guest to have because he questions some of the strange practices that have been widely adopted by successful companies. Internet companies are a very new phenomenon, and the management tactics that they have adopted are not well proven–so it is great to have someone like Matt provide a fresh perspective on ways that companies can scale their technology and their organization more effectively.
#957
Nov 1, 2018 · 52 min
Wonolo: Staffing Marketplace with Jeremy Burton
Online labor marketplaces are widely used for one-to-one transactions. On Uber, a rider hires a driver for transportation. On TaskRabbit, a homeowner hires a cleaner to come clean their kitchen. These types of marketplaces are not as widely used for one-to-many transactions, but they can be just as useful. A warehouse owner would want to hire a group of workers to help with holiday shipments. A conference organizer would want to hire a group of event staffers to help run the conference. Wonolo is an on-demand staffing platform. Businesses post jobs and workers apply for those jobs. The types of work include event staffing, warehouse operations, merchandising, and other general labor tasks. In past shows, we have covered on-demand work platforms such as Fiverr, Thumbtack, Uber, and Instacart. Wonolo presents another variation in the business model and software architecture of the gig economy. Jeremy Burton is the CTO and chief data scientist at Wonolo. He joins the show to talk about building and scaling Wonolo, and some of the key strategic decisions that Wonolo has made along the way. As with any successful marketplace business, Wonolo has solved the chicken and egg problem of how to get supply and demand on the platform simultaneously. The company has grown deliberately, setting up operations in one city at a time to make sure that they can provide a good experience in both sides of the market in each of the new geographies. Jeremy and I also talked about the broader effects that the gig economy could potentially have on the labor market. Gig economy platforms use a 5-star rating system and written reviews to judge workers, instead of a resume system. The gig economy allows for rapid job liquidity, and the potential for workers to steadily “level up” more quickly than they might be able to in a typical corporate job. These aspects of the gig economy are rarely discussed, so it was enlightening to hear Jeremy’s views on them.
#955
Oct 31, 2018 · 52 min
Diffbot: Knowledge Graph API with Mike Tung
Google Search allows humans to find and access information across the web. A human enters an unstructured query into the search box, the search engine provides several links as a result, and the human clicks on one of those links. That link brings up a web page, which is a set of unstructured data. Humans can read and understand news articles, videos, and Wikipedia pages. Google Search solves the problem of organizing and distributing all of the unstructured data across the web, for humans to consume. Diffbot is a company with a goal of solving a related, but distinctly different problem: how to derive structure from the unstructured web, understand relationships within that structure, and allow machines to utilize those relationships through APIs. Mike Tung is the founder of Diffbot. He joins the show to talk about the last decade that he has spent building artificial intelligence applications, from his research at Stanford to a mature, widely used product in Diffbot. I have built a few applications with Diffbot, and I encourage anyone who is a tinkerer or prototype builder to play around with it. It’s an API for accessing web pages as structured data. Diffbot crawls the entire web, parsing websites, using NLP and NLU to comprehend those pages, and using probabilistic estimations to draw relationships between entities. It’s an ambitious product, and Mike has been working on it for a long time. I enjoyed our conversation. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: host@fintechdaily.co
#952
Oct 30, 2018 · 56 min
Drift: Sales Bot Engineering with David Cancel
David Cancel has started five companies, most recently Drift. Drift is a conversational marketing and sales platform. David has a depth of engineering skills and a breadth of business experience that make him an amazing source of knowledge. In today’s episode, David discusses topics ranging from the technical details of making a machine learning-driven sales platform to the battle scars from his early career, when he spent a lot of time building products that people did not want. He has found success by focusing on building software that the market has shown a desire for. Chatbots were a popular, trendy subject a few years ago. The success of chatbots manifested in them fading into the background, and becoming a subtle, increasing part of our everyday interactions. Not every online interaction can be replaced by a chatbot, but many online interactions can be made more efficient by using chatbots. Chatbots can serve well-defined information, like product features, or the hours of operation of a business. When a chatbot gets a question that it cannot answer, the bot can route the conversation to a human. When a customer lands on a web page of a company using Drift, they see a chat box appear in the corner of the screen. The customer is able to communicate through that chat box with a bot that represents the company. The customer can learn about the product, schedule a call with a salesperson, and get other useful utilities from the Drift sales bot. The Drift chatbot messaging system is handled by Elixir/Erlang. Erlang is widely known as the messaging language that was used to scale WhatsApp while maintaining high availability. On the backend, Java services take the interactions from the Driftbot and pull it into a CRM, which allows sales and marketing people to manage information about the customers that are interacting with the chatbot. David gives lots more detail around the engineering stack, the deployment model, and his thoughts on the business and modern engineering. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: host@fintechdaily.co
#950
Oct 29, 2018 · 49 min
Building a Hiring Process with Ammon Bartram
Engineers who start companies often find themselves building something they have no experience with: a hiring process. Hiring engineers today is not as systematic as building software. We don’t have lots of data that tells us what makes for an effective programming interview question. The smartest tech companies in the world are still making hiring mistakes–often through the “false negative” of rejecting candidates who did not do well in their interview process or through the “false positive” of hiring candidates who did well in the interview, but were not a good fit for the job. If you are a hiring manager or a company founder, you will eventually have to build a hiring process. If you don’t treat that hiring process scientifically, you will likely make some mistakes. Ammon Bartram has conducted more than 1000 interviews with engineers, accumulating a vast amount of data. This data was gathered deliberately and scientifically, through closely tracked interview questions and a consistent end-to-end process for the job candidate. Ammon joins the show to talk about the data set he has accumulated, the conclusions from all of these interviews, and how engineering organizations can use this data to develop a smart, data-driven hiring process. Ammon is co-founder of Triplebyte, a company that helps match engineers and tech companies. Triplebyte also publishes lots of research and blog articles about conducting good interviews, developer salaries, and bootcamps vs. computer science degrees. Full disclosure: Triplebyte is a sponsor of Software Engineering Daily. (However, Ammon has been a guest several times before on the show, since before Triplebyte was a sponsor, and I always enjoy getting to talk to him.)
#949
Oct 28, 2018 · 53 min
Gig Economy
I like to write music, and a year ago I started working on an album called “Gig Economy”. The plan for the album was to hire musicians from gig economy platforms like Fiverr and Upwork to perform on songs that I produced. The album is finished and I’m happy with the result, so I’m sharing it on the podcast today as an extra episode released on a Sunday. We’ll be back tomorrow with content about software engineering. Writing this album made me think about the future of work. I love music, but I am not a professional musician. I take the craft seriously, but perhaps not as seriously as someone who has made music their full-time career. I’ve never taken the time to network with musicians and develop collaborative relationships. The gig economy allowed me to pay creative people to collaborate with me. The transactional nature of my relationship with the collaborators meant that both of us had the incentive structure to work effectively. This improved quality and kept the pace of the project moving quickly. Today, the gig economy is widely regarded as a mode of work that removes individuality. Critics of the gig economy say that it turns workers into a commodity. If you use Uber, you aren’t thinking about the human who is driving you. As long as your driver has a high rating, you are satisfied. My experience producing this album with gig economy musicians showed a different side of our new employment systems. I found artists who I deeply enjoyed working with. There was no ambiguity about our relationship. Nobody was flaky. I paid these collaborators well, and in return they helped me fulfill an artistic vision. Without gig economy platforms, I could not have written this album. The gig economy is a playground for creativity. If you want to get paid to work as an artist, you can do so as long as you have a laptop. If you are a corporate worker making a good salary, but you spend your weekend producing art, you can pay artists to help you complete your vision. The greatest works of art are often the result of a talented workforce directed by an established leader. The gig economy lets you become a leader and recruit a team of creative, proven artists in a single day. I hope you enjoy “Gig Economy”. If you would rather listen on Spotify or YouTube, links are below. If you like the album, please share it on Twitter or Facebook. If you listened all the way through and have feedback for me, I’d love to know your thoughts. You can send me a tweet @the_prion or an email: jeff@softwareengineeringdaily.com
#947
Oct 26, 2018 · 1 hr 21 min
Blockchain Distribution Network with Aleksandar Kuzmanovic
BloxRoute Labs is a company that is developing a blockchain distribution network (BDN). Much like a CDN pushes media files out to the edges of the web to make them faster to access, a BDN pushes out information to miners in the network. Of course, this means that the BDN could potentially be centralized infrastructure. In order to make the BDN effectively decentralized and trustworthy, BloxRoute claims to have a provably trustable network protocol, to go with its token-based incentive system that keeps its goals aligned with that of the larger blockchain world. Aleksander Kuzmanovic is the founder of BloxRoute Labs, as well as a professor of computer science at Northwestern University. His co-founders of BloxRoute include former guests of the show Emin Gun Sirer and Soumya Basu. The BloxRoute founders have a strong theoretical background and a great reputation in the cryptocurrency community, unlike the vast majority of founders who have issued a token. As we have heard in previous episodes, most of the founders of companies that issue tokens cannot give a good explanation for why their protocol needs a token. Tokens are a great idea that have mostly been applied as a mechanism to get rich quickly. However, BloxRoute has a credible explanation for their token, and I asked some very pointed questions to Aleksander in today’s episode to try to vet the project for legitimacy, and his reasoning made sense.
#946
Oct 25, 2018 · 47 min
Flogo: Event-Driven Ecosystem with Leon Stigter and Matt Ellis
A smart security camera takes in a high volume of video images and processes those images using a set of machine learning models. Those models can be used to identify interesting snippets of movement throughout the day, and decide which of those snippets to keep. Some of the video snippets might contain movement of birds–but other video snippets might contain footage of intruders. As the video stream is processed on the smart security camera, and machine learning models are used to classify the entities in the video stream, some of the data gets thrown out as useless. Some of the data gets sent to the cloud for additional processing. Some of the data might trigger an alert that there is an intruder on the premises. Each piece of video data is an “event”. These events are processed and acted upon. Modern applications are highly interactive, and have lots of “events”. Other examples of event data streams are website traffic data, self-driving car data, time-series logging data, and video game session data. Building applications that respond to these high volumes of events requires us to program triggers to react to data streams, actions to take in response to the data streams, and workflows to orchestrate what the overall picture of our application is doing as the application is consuming this large data stream. Flogo is an event-driven ecosystem for building applications around streams of events. Leon Stigter and Matt Ellis work on Flogo at TIBCO, and they join the show to discuss event-driven application development and their work on Flogo. They also talk about the constraints of machine learning applications at the edge, and how event processing systems like Flogo can be used to handle large data streams on edge devices.
#944
Oct 24, 2018 · 51 min
JAM Stack with Phil Hawksworth
Engineers can build applications faster by using tools that abstract away infrastructure. Major cloud providers offer this tooling in the form of functions-as-a-service, as well as managed services such as Google BigQuery or Azure Container Instances. The term “serverless” refers to these functions-as-a-service and the managed services–because when you use these tools, you are not making calls to specific servers–you are making calls to APIs that abstract away the servers from you, while guaranteeing uptime and reliability. In previous shows we have covered Heroku, Firebase, serverless functions, serverless event driven application development, and a few startups that are built almost entirely on serverless infrastructure. “Serverless” is a way of describing backend services that are represented by an API. But what about the rest of the application stack that you use to build on top of serverless? You still need to use JavaScript to define the custom code of your application. You still need to use HTML markup to describe the look and feel of your application. The “JAM Stack” is a way of building applications consisting of JavaScript, APIs, and markup. Phil Hawksworth is the head of developer relations at Netlify, and he joins the podcast to explain how these JAM Stack applications are developed and deployed, and how developers can use the JAM stack to rapidly build new systems. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: host@fintechdaily.co
#942
Oct 23, 2018 · 52 min
DevSecOps with Edward Thomson
DevSecOps emphasizes moving security out of a siloed audit process and distributing security practices throughout the software supply chain. In the past, software development usually followed a waterfall development process. Each step in building software was serialized, one after another. First, software was planned. Then it was built. Then it was tested. Finally, the software received a security audit at the end. If a security vulnerability was not discovered during that audit, it was likely that the software would be released with the vulnerability. With continuous delivery, we can be continuously checking for security. Every new release can be tested against a battery of automated security tests. The open source libraries we use can be scanned to make sure they are up-to-date with patched versions. Static analysis can discover memory leaks and buffer overrun vulnerabilities. Edward Thomson is the principal program manager for Azure DevOps at Microsoft. He joins the show to talk about how an organization can adopt DevSecOps and introduce security practices into continuous delivery pipelines. We also talk more philosophically about security–defining the most common security risks of a software company today, from “shadow IT infrastructure” to phishing. Full disclosure: Microsoft is a sponsor of Software Engineering Daily. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: host@fintechdaily.co

Showing 1,341–1,360 of 2,221 episodes