General

Blockchain Adoption in 2023 with Medha Parlikar (Casper Labs) | Engineering Leadership

Published Jul 14, 2023

Updated Aug 9, 2023

3 min read

Tracy Lee hosts the Engineering Leadership Series and introduces Medha Parlikar, the Chief Technology Officer and co-founder of Casper Labs. Medha shares that Casper Labs has developed the technology behind the public Casper network, a decentralized blockchain protocol.

Medha has a long history in technology, starting in the early 80s when she and her father built computers in their basement. She has been working in IT and personal computing ever since, transitioning into web 2.0 and eventually falling into the blockchain space in 2017. After a project she was involved in ran out of funds during the 2017 ICO crash, Medha co-founded Casper Labs with the aim of building a public decentralized blockchain technology that can be utilized by enterprises and brought to the masses.

Tracy asks Medha about the evolution of blockchain and its buzzword status. Medha believes that adopting blockchain technology is similar to adopting cloud technology or the internet. She advises CTOs and CIOs to find someone who understands the technology and can guide them through the adoption process, comparing it to having a Sherpa. Companies like Red Hat, AWS, and VMware have played significant roles in leading and developing technologies like Linux and cloud computing.

Medha emphasizes that blockchain adoption doesn't have to be daunting or scary. It can be approached incrementally, considering the risk-averse nature of enterprises. She encourages companies to proceed with caution and find trusted partners who can help them navigate the disruptive technology and its potential benefits.

Tracy shifts the conversation to the challenges surrounding blockchain adoption. Medha explains that scalability, privacy, and regulatory uncertainty are common concerns. However, she believes that with proper planning and a trusted partner, enterprises can overcome these challenges. Blockchain technology holds great value and promise, and she encourages CTOs and CIOs to explore its potential benefits while mitigating risks.

Medha shares her perspective on the role of blockchain in the enterprise. She believes that blockchain can provide transparency, trust, and efficiency in various industries, including supply chain management, finance, and healthcare. Blockchain has the potential to revolutionize business processes and enable new models of collaboration and trust.

Tracy asks Medha about the role of education and awareness in promoting blockchain adoption. Medha acknowledges the need for education to bridge the gap between technical understanding and business requirements. She highlights the importance of explaining blockchain's benefits in a language that executives and decision-makers can understand.

Medha also stresses the significance of community building and collaboration within the blockchain ecosystem. She encourages individuals and organizations to actively participate in communities, attend conferences, and engage in discussions to share knowledge, foster innovation, and drive the widespread adoption of blockchain technology.

In conclusion, Medha Parlikar, as the CTO of Casper Labs, offers insights into blockchain technology adoption. She emphasizes the need for trusted partners, incremental approaches, and careful consideration of regulatory challenges. Medha envisions blockchain as a transformative force in various industries, and she encourages education, community building, and collaboration to drive its adoption forward.

To watch the full conversation, check it out here.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Intro to Smart Contracts - Oracles: Connecting the External World to the Blockchain

A few weeks ago, I published my first blog post on smart contracts, introducing some basic definitions as well as how these decentralized apps function on the Ethereum blockchain. If you need a refresher, a smart contract is a distributed blockchain application that stores logic and executes actions when the conditions of a particular agreement are met. These contracts are built using languages like Solidity, which is one of the programming languages for developing decentralized applications. However, one limitation of using smart contracts is that they can only process information which exists on the blockchain, so in order for these applications to see wider adoption, blockchain developers needed to create a method for quickly and automatically recording and leveraging disparate information otherwise not stored on a network. This is where oracles come into play. A blockchain oracle is a piece of software- typically an API- that fetches information available on the web and reports that information to smart contracts on the blockchain. This information could include anything from world events: from changes in the stock market to that day’s dew point in San Francisco. Any information which a smart contract must depend on in order to function, but isn’t able to pull from the blockchain, might require the help of thousands of oracles, all reporting requested information so that the smart contract can execute on accurate, trustworthy, real-time data. This offers a number of advantages for industries looking to further automate their processes. For example, freight companies can code smart contracts that notify workers in a particular region when to take further precautions due to inclement weather. This decentralized app can automatically issue this warning without direct oversight by continuously pulling available weather data from oracles. We might also see an expansion of smart contract technology used in the medical field as well. Hospitals can automate medical supply ordering processes to respond to real-time changes in their stock or availability of stock, using oracles that can continuously update the smart contract with inventory and/or the volume of inventory currently available from suppliers. This can ensure that hospitals, especially during this difficult period, can reduce administrative overhead and ensure that they have the best chance at securing the supplies that they need. Of course, this use case is not unique to the medical field as this type of decentralized app could also benefit retailers or manufacturers who are constantly working to predict their supply needs against demand. Oracles can help combat the ever-present “bull-whip” risks, through which sharp increases in demand, followed by periods of lower demand, often leads to retailers and manufactures acquiring more inventory and raw materials than they truly need, by continuously updating automated ordering applications with second-by-second data on present demand. Chainlink, a network agnostic oracle platform, is the leading platform for connecting real-world data to the blockchain through oracles. It facilitates the transfer of tamper-proof data between the APIs drawing real world data from centralized locations on the internet and the smart contracts receiving and responding to that data. Similar to other networks, it issues its own ERC677 token, called LINK, and is used to compensate node operators that verify smart contracts executed on the Chainlink network, or can be used as any other ERC20-based token might be. To learn more about how you can build your own smart contracts on the Ethereum network while leveraging all of the information available on the web, reach out to This Dot Labs to connect with one of our Solidity experts! We can’t wait to hear your ideas!...

Sep 16, 2021

3 mins

Blockchain

Double Click: Web 3 is Coming! But is it Over Hyped?

Welcome to the Double Click! This is the weekly blog series that shines a spotlight on emerging technologies, technological concepts, and community projects that enrich the JavaScript Ecosystem! This week, we're talking about all of the hype and controversy surrounding Web 3, or the future of the web. If you are just hearing about Web 3 for the first time, it is the concept that the "web" as we know it, will eventually be composed largely of decentralized applications and tokenized systems that allow users to engage in peer-to-peer interactions without the use of enterprise sites and services. I know this might seem vague, but it might make more sense if we consider that "Web 1" was the period of time when the internet consisted of usenets and message boards, and "Web 2" occured as enterprises began digital products to create an interfaceable internet. "Web 3" now refers to a potential future where most of our web interactions will be facilitated by machines and decentralized protocols rather than centralized services, such as those owned by banks and payment processors. I am extremely excited about the potential that blockchain technologies have to revolutionize the web as we know it. If you follow any of my recent blog posts, you will know that I am a huge proponent of decentralized applications, and even offer Solidity development services through This Dot Labs. That being said, developers who are just getting into the industry do not need to worry that all of their hard work learning JavaScript and frameworks was for naught. Though blockchain will only continue to grow in popularity and expand in functioning, we're not quite on the doorstep of a web revolution that will fundamentally change the sort of skills and expertise needed on the market. We will still need centralized applications, web sites, mobile applications, and more for quite a while. However, if you are interested in becoming an early blockchain adopter, there are tons of opportunities to become involved. With all of the Web 3 hype, there are hundeds of new projects and companies popping up with opportunities for developers. But if you aren't quite ready to make the full leap into this pioneering space, you can contribute to blockchain community projects, such as those offered by various networks and tokens, or building your own decentralized application. After all, JavaScript and Solidity use nearly identical syntax! But what do you think? Do you believe we're on the precipice of a great new web development revolution, or are you not quite buying the hype yet? Be sure to let me know by tweeting me at @ladyleet....

Oct 5, 2021

2 mins

BlockchainJavaScriptWeb Development

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Understanding the Difference Between :focus and :focus-visible in CSS I have learned my fair share about the importance of keyboard accessibility, so I know that visual indication of the focused element is very important. But the well-known :focus pseudo-class is not always the best fit for this job. That's where :focus-visible comes in. Let's look at the differences between these two pseudo-classes and explore the best practices for using them effectively. What is the :focus Pseudo-Class? The :focus pseudo-class is a CSS selector that applies styles to any element that receives focus, regardless of how that focus was triggered. This includes focus events from keyboard navigation, mouse clicks, and touch interactions. Example Usage of :focus ` In this example, the button will display a blue outline whenever it is focused, whether the user clicks on it with a mouse, taps it on a touchscreen, or navigates to it using the keyboard. What is the :focus-visible Pseudo-Class? The :focus-visible pseudo-class is more specialized. It only applies styles to an element when the browser determines that the focus should be visible. This typically occurs when the user navigates via the keyboard or assistive technologies rather than through mouse or touch input. Example Usage of :focus-visible ` Here, the button will only show a blue outline when focused through keyboard navigation or another input method that usually requires visible focus indicators. Key Differences Between :focus and :focus-visible :focus - Behavior: Applies to any element that receives focus, regardless of the input method. - Use Cases: Ensures that all interactions with the element are visually indicated, whether by mouse, keyboard, or touch. :focus-visible - Behavior: Applies styles only when the focus should be visible, such as using a keyboard or assistive technology. - Use Cases: Ideal for scenarios where you want to provide focus indicators only to keyboard and assistive technology users while avoiding unnecessary outlines for mouse and touch users, typically required by design. Accessibility Implications :focus - Pros: - Guarantees that all users can see when an element is focused, which is critical for accessibility. - Cons: - Can lead to a suboptimal experience for mouse users, as focus styles may appear unnecessarily during mouse interactions. :focus-visible - Pros: - Enhances user experience by showing focus indicators only when necessary, thus keeping the interface clean for mouse and touch users. - Tailors the experience for keyboard and assistive technology users, providing them with clear visual cues. - Cons: - Additional considerations may be required to ensure that focus indicators are not accidentally omitted, especially in older browsers that do not support :focus-visible. - There may be cases where you want to show focus indicators for all users, regardless of input method. Best Practices for Using :focus and :focus-visible To achieve the best accessibility and user experience, combining both :focus and :focus-visible in your CSS is often a good idea. Combining :focus and :focus-visible ` Here is a Stackblitz example of what such styling could look like for you to try out and play with. Additional Tips - Test with Keyboard and Assistive Technology: Ensure that your web application is navigable using a keyboard (Tab, Shift + Tab, etc.) and that focus indicators are visible for those who rely on them. It's never a bad idea to include accessibility testing in your e2e testing suite. - Provide Clear Focus Indicators: Make sure that focus indicators are prominent and easy to see. A subtle or hard-to-spot focus indicator can severely impact accessibility for users who rely on keyboard navigation. Conclusion The :focus-visible pseudo-class offers a more refined way to manage focus indicators, improving accessibility and user experience, particularly for keyboard and assistive technology users. By understanding the differences between :focus and :focus-visible, and applying best practices in your CSS, you can create more accessible and user-friendly web applications. Remember, accessibility should never be an afterthought. By thoughtfully applying focus styles, you ensure that all users, regardless of how they interact with your site, can easily navigate and interact....

Nov 8, 2024

3 mins

AccessibilityCSSPlaywright

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Blockchain Adoption in 2023 with Medha Parlikar (Casper Labs) | Engineering Leadership

You might also like

Intro to Smart Contracts - Oracles: Connecting the External World to the Blockchain

Double Click: Web 3 is Coming! But is it Over Hyped?

Introduction to Zod for Data Validation

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Let's innovate together!

You might also like

Intro to Smart Contracts - Oracles: Connecting the External World to the Blockchain

Double Click: Web 3 is Coming! But is it Over Hyped?

Introduction to Zod for Data Validation

Understanding the Difference Between `:focus` and `:focus-visible` in CSS