Default

default

In this post, I'll explain how to provide a default value when querying an absent key in a hash map in different programming languages. Java Let's start with Java, my first professional programming language. In older versions, retrieving a value from a map required using the get() method: Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Initialize an empty map
Attempt to retrieve a non-existent key
Assign a default value if the key is absent With Java 1.8, the Map interface introduced a more concise way to handle absent keys: var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 Retrieve the value with a default in one step Kotlin Kotlin provides several approaches to retrieving values from a map: get() and getOrDefault() function just like their Java counterparts.
getValue() throws an exception if the key is missing.
getOrElse() accepts a lambda to provide a default value lazily. val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 Retrieve the default value
Lazily evaluate the default value Python Python is less forgiving than Java when handling absent keys—it raises a KeyError: map = {}
value = map['absent']                                    #1 Raises a KeyError To avoid this, Python offers the get() method: map = {}
value = map.get('absent', 'default')                     #1 Alternatively, Python's collections.defaultdict allows setting a default for all absent keys: from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] Automatically provide a default value for any absent key Ruby Ruby's default behavior returns nil for absent keys: map = {}
value = map['absent'] For a default value, use the fetch method: map = {}
value = map.fetch('absent', 'default')                  #1 Provide a default value for the absent key Ruby also supports a more flexible approach with closures: map = {}
value = map.fetch('absent') { |key| key }               #1 Return the queried key instead of a constant Lua My experience with Lua is relatively new, having picked it up for Apache APISIX. Let's start with Lua's map syntax: map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end Initialize a new map
Iterate over key-value pairs
Print each key-value pair Fun fact: the syntax for tables is the same as for maps: table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end Initialize a new map


Loop over the pairs of key values


Print the following:
1	one
2	two

Lua arrays start at index 0! We can mix and match indices and keys. The syntax is similar, but there's no difference between a table and a map. Indeed, Lua calls the data structure a table: something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end The result is the following: 1	one
a	A
b	B I n Lua, absent keys return nil by default: map = {}
value = map['absent'] To provide a default, Lua uses metatables and the __index metamethod: Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b, where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod, which should be a function) to compute the sum.
-- Metatables and Metamethods Each table in Lua may have its own metatable. As I said earlier, when we access an absent field in a table, the result is nil. This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil; otherwise, the metamethod will provide the result.
-- The __index Metamethod Here's how to use it: table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 Create the table
Create a metatable
Associate the metatable with the table
Define the __index function to return the absent key
The __index function is called because the key is absent Summary This post explored how to provide default values when querying absent keys across various programming languages. Here's a quick summary: Scope

Scope

Value

Value



Programming Language

Per call

Per map

Static

Lazy



Java

❎

❌

❎

❌



Kotlin

❎

❌

❎

❎



Python

❎

❎

❌

❎



Ruby

❎

❌

❎

❎



Lua

❌

❎

❎

❌ In this post, I'll explain how to provide a default value when querying an absent key in a hash map in different programming languages. Java Let's start with Java, my first professional programming language. In older versions, retrieving a value from a map required using the get() method: get() Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Initialize an empty map Attempt to retrieve a non-existent key Assign a default value if the key is absent Initialize an empty map Attempt to retrieve a non-existent key Assign a default value if the key is absent With Java 1.8, the Map interface introduced a more concise way to handle absent keys: Map var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 Retrieve the value with a default in one step Retrieve the value with a default in one step Kotlin Kotlin provides several approaches to retrieving values from a map: get() and getOrDefault() function just like their Java counterparts. getValue() throws an exception if the key is missing. getOrElse() accepts a lambda to provide a default value lazily. get() and getOrDefault() function just like their Java counterparts. get() getOrDefault() getValue() throws an exception if the key is missing. getValue() getOrElse() accepts a lambda to provide a default value lazily. getOrElse() val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 Retrieve the default value Lazily evaluate the default value Retrieve the default value Lazily evaluate the default value Python Python is less forgiving than Java when handling absent keys—it raises a KeyError : KeyError map = {}
value = map['absent']                                    #1 map = {}
value = map['absent']                                    #1 Raises a KeyError Raises a KeyError KeyError To avoid this, Python offers the get() method: get() map = {}
value = map.get('absent', 'default')                     #1 map = {}
value = map.get('absent', 'default')                     #1 Alternatively, Python's collections.defaultdict allows setting a default for all absent keys: collections.defaultdict from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] Automatically provide a default value for any absent key Automatically provide a default value for any absent key Ruby Ruby's default behavior returns nil for absent keys: nil map = {}
value = map['absent'] map = {}
value = map['absent'] For a default value, use the fetch method: fetch map = {}
value = map.fetch('absent', 'default')                  #1 map = {}
value = map.fetch('absent', 'default')                  #1 Provide a default value for the absent key Provide a default value for the absent key Ruby also supports a more flexible approach with closures: map = {}
value = map.fetch('absent') { |key| key }               #1 map = {}
value = map.fetch('absent') { |key| key }               #1 Return the queried key instead of a constant Return the queried key instead of a constant Lua My experience with Lua is relatively new, having picked it up for Apache APISIX. Let's start with Lua's map syntax: map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end Initialize a new map Iterate over key-value pairs Print each key-value pair Initialize a new map Iterate over key-value pairs Print each key-value pair Fun fact: the syntax for tables is the same as for maps: table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end Initialize a new map Loop over the pairs of key values Print the following:
1	one
2	two

Lua arrays start at index 0! Initialize a new map Initialize a new map Loop over the pairs of key values Loop over the pairs of key values Print the following: 1	one
2	two Lua arrays start at index 0! Print the following: 1	one
2	two 1	one
2	two Lua arrays start at index 0! We can mix and match indices and keys. The syntax is similar, but there's no difference between a table and a map. Indeed, Lua calls the data structure a table: something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end The result is the following: 1	one
a	A
b	B 1	one
a	A
b	B I n Lua, absent keys return nil by default: nil map = {}
value = map['absent'] map = {}
value = map['absent'] To provide a default, Lua uses metatables and the __index metamethod: __index Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b, where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod, which should be a function) to compute the sum. -- Metatables and Metamethods Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b , where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod , which should be a function) to compute the sum. a+b a b __add metamethod -- Metatables and Metamethods Metatables and Metamethods Each table in Lua may have its own metatable . metatable As I said earlier, when we access an absent field in a table, the result is nil. This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil; otherwise, the metamethod will provide the result. -- The __index Metamethod As I said earlier, when we access an absent field in a table, the result is nil . This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil ; otherwise, the metamethod will provide the result. nil __index nil -- The __index Metamethod The __index Here's how to use it: table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 Create the table Create a metatable Associate the metatable with the table Define the __index function to return the absent key The __index function is called because the key is absent Create the table Create a metatable Associate the metatable with the table Define the __index function to return the absent key __index The __index function is called because the key is absent __index Summary This post explored how to provide default values when querying absent keys across various programming languages. Here's a quick summary: Scope

Scope

Value

Value



Programming Language

Per call

Per map

Static

Lazy



Java

❎

❌

❎

❌



Kotlin

❎

❌

❎

❎



Python

❎

❎

❌

❎



Ruby

❎

❌

❎

❎



Lua

❌

❎

❎

❌ Scope

Scope

Value

Value Programming Language

Per call

Per map

Static

Lazy Java

❎

❌

❎

❌ Kotlin

❎

❌

❎

❎ Python

❎

❎

❌

❎ Ruby

❎

❌

❎

❎ Lua

❌

❎

❎

❌ Scope Scope Value Value Scope Scope Scope Scope Value Value Value Value Programming Language Per call Per map Static Lazy Programming Language Programming Language Per call Per call Per map Per map Static Static Lazy Lazy Java ❎ ❌ ❎ ❌ Java Java ❎ ❎ ❌ ❌ ❎ ❎ ❌ ❌ Kotlin ❎ ❌ ❎ ❎ Kotlin Kotlin ❎ ❎ ❌ ❌ ❎ ❎ ❎ ❎ Python ❎ ❎ ❌ ❎ Python Python ❎ ❎ ❎ ❎ ❌ ❌ ❎ ❎ Ruby ❎ ❌ ❎ ❎ Ruby Ruby ❎ ❎ ❌ ❌ ❎ ❎ ❎ ❎ Lua ❌ ❎ ❎ ❌ Lua Lua ❌ ❌ ❎ ❎ ❎ ❎ ❌ ❌

Default Values for Absent Keys: A Cross-Language Guide to Hash Map Querying

United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 25 of 37. C. The Foreclosure Created By Google’s Agreements Is Enhanced By Google’s Ownership Of The Chrome Browser 968. About 20% of all general search queries in the United States go through the default on user-downloaded versions of Chrome (e.g., Chrome on Windows and Apple devices). Tr. 5763:9–13, 5765:6–15 (Whinston (Pls. Expert)) (user-downloaded Chrome includes Chrome on Windows and Apple devices; explaining that the yellow part of the bar (20%) on UPXD104 at 37 is user-downloaded Chrome); id. 10639:10–17 (20% of U.S. search queries come through user-downloaded Chrome). These are defaults not challenged by Plaintiffs’ complaint but still affect the portion of the relevant markets available to rivals and thus magnify the significance of the foreclosure created by the challenged agreements. 969. Because Google always sets itself as the Chrome search default, rivals cannot achieve distribution by being set as that default. In other words, queries going through the default on user-downloaded Chrome are not “fully available” to Google’s rivals. Tr. 922:19–23 (Kolotouros (Google)) (“Chrome, as an application, has Google as the default search engine, that is correct.”); Tr. 5768:2–18 (Whinston (Pls. Expert)) (User-downloaded “Chrome queries are not fully available . . . to rivals, because Chrome is coming with a default in it to Google.”); id. 10639:10–19 (Google sets itself as the default on Chrome, which means rivals cannot access default distribution through Chrome.). 970. Even if Google is not engaging in exclusionary conduct by setting itself as the default on Chrome, the presence of Chrome makes the foreclosure caused by Google’s exclusionary contracts more significant. Tr. 5768:2–18 (Whinston (Pls. Expert)) (explaining that the presence of Chrome “color[s]” what the foreclosure range means—“when you think about these numbers [the 33% and the 50%,] . . . you shouldn’t think of it . . . relative to a hundred percent. You really should think of it in some sense relative to some smaller possible available market because of the presence of Chrome.”); id. 5752:18–5753:9 (discussing UPXD104 at 33, which states that foreclosure analysis needs to “consider[] how much of the market is available to rival sellers.”). Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.
This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 25 of 37. United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 25 of 37. HackerNoon’s Legal PDF Series here C. The Foreclosure Created By Google’s Agreements Is Enhanced By Google’s Ownership Of The Chrome Browser 968. About 20% of all general search queries in the United States go through the default on user-downloaded versions of Chrome (e.g., Chrome on Windows and Apple devices). Tr. 5763:9–13, 5765:6–15 (Whinston (Pls. Expert)) (user-downloaded Chrome includes Chrome on Windows and Apple devices; explaining that the yellow part of the bar (20%) on UPXD104 at 37 is user-downloaded Chrome); id. 10639:10–17 (20% of U.S. search queries come through user-downloaded Chrome). These are defaults not challenged by Plaintiffs’ complaint but still affect the portion of the relevant markets available to rivals and thus magnify the significance of the foreclosure created by the challenged agreements. 969. Because Google always sets itself as the Chrome search default, rivals cannot achieve distribution by being set as that default. In other words, queries going through the default on user-downloaded Chrome are not “fully available” to Google’s rivals. Tr. 922:19–23 (Kolotouros (Google)) (“Chrome, as an application, has Google as the default search engine, that is correct.”); Tr. 5768:2–18 (Whinston (Pls. Expert)) (User-downloaded “Chrome queries are not fully available . . . to rivals, because Chrome is coming with a default in it to Google.”); id. 10639:10–19 (Google sets itself as the default on Chrome, which means rivals cannot access default distribution through Chrome.). 970. Even if Google is not engaging in exclusionary conduct by setting itself as the default on Chrome, the presence of Chrome makes the foreclosure caused by Google’s exclusionary contracts more significant. Tr. 5768:2–18 (Whinston (Pls. Expert)) (explaining that the presence of Chrome “color[s]” what the foreclosure range means—“when you think about these numbers [the 33% and the 50%,] . . . you shouldn’t think of it . . . relative to a hundred percent. You really should think of it in some sense relative to some smaller possible available market because of the presence of Chrome.”); id. 5752:18–5753:9 (discussing UPXD104 at 33, which states that foreclosure analysis needs to “consider[] how much of the market is available to rival sellers.”). Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. storage.courtlistener

20% of All General Searches in the U.S. Go Through the Default on User-Downloaded Version of Chrome

Google's Monopoly: Defaults Have A Powerful Effect On Users’ Search Behavior

Protect People From Themselves: Reducing Default Risks in P2P Lending

If I would have to point out one of the most confusing Dispatchers in the world of Kotlin coroutines, that would be the Unconfined dispatchers. Called with Dispatchers.Unconfined when creating a coroutine scope, this a kind of dispatcher that doesn’t really care. The whole idea of the Unconfined dispatcher is simply to pick up a Thread for no other goal than to simply use it. There is no other criteria involved when using a Thread.Coroutines use a system called green threading or also known as user space threading. We can refer to routines as contructs that are designed to gain control of a Thread, but specifically they are managed by the schedulers to run in platform or system threads. By platform threads, we are talking about the threads accessible by the programming language or higher abstraction that we use in our development environment.When we talk about the unconfined dispatchers, it is important to understand what these terms are. And so let’s get clear to what is green threading and user space threading. These terms are used interchangeably. However, there is a very subtle difference: User space threading is used to emphasize that it is the user that schedules the threads. In other words, this is what we refer to when we start threads via our code. Green threading emphasizes on what goes on behind the curtain. Green threads are also called fibers and these are virtual threads that are multiplexed to be used on top of system threads. This is all something very difficult to visualize. But for the case of the Unconfined Dispatchers this is all we need to know about this part. Being aware of the existence of platform threads, virtual threads and system threads and how they work is important because the platform threads will then perform this multiplexing mechanism onto specific system threads and this is why in Kotlin, specifically, we can find dispatchers specifically to be used with the CPU, the Dispatchers.Default, dispatchers specific for IO operations called Dispatchers.IO and dispatchers specific for single threaded UI , such as Dispatchers.Main for other operations as alternatives to the Dispatchers.Unconfined context. Making tests using the Spring Framework we will very easily come across the fact that the Spring Framework uses Dispatchers.Unconfined. When I made it was generally said that Dispatchers.Unconfined were to be used in tests only due to their unpredictability. this video do not rely on a particular platform scheduling system oriented to a specific kind of Thread, it becomes very unpredictable how coroutines launched like this would perform. There were also mentions of the possibility that Dispatchers.Unconfined could eventually block the execution of the application in production code, but to be honest I have never ever seen that, even working so much with the Spring Framework for server-side programming as I currently do with Kotlin. And to top that up they mention precisely that, because of that risk, all nested coroutines form an event-loop. They explain that in their documentation here: Dispatchers.Unconfined https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-unconfined.html?embedable=true But hold on. Why is the Spring Framework using Dispatchers.Unconfined in their implementation instead of other Dispatchers like for example the Dispatchers.IO? And why not test this before anything? Well, first let’s have a look at an issue that was opened on GitHub about this: https://github.com/spring-projects/spring-framework/issues/32032?embedable=true I came across this subject when I was casually looking for something else and I bumped into another issue on StackOverflow: https://stackoverflow.com/questions/77810077/controller-code-using-unconfined-dispatcher-by-default?embedable=true Someone had found out that, for whatever reason, the Dispatchers.Unconfined was being used and so I created a service on my GitHub Repo here to prove that: https://github.com/jesperancinha/jeorg-spring-master-test-drives?embedable=true And this service is called car-parts-reactive and that is located in the root directory of the project: git clone https://github.com/jesperancinha/jeorg-spring-master-test-drives.git
cd car-parts-reactive
make b
make run The method we want to have a look at is this one in the controller CarController: @GetMapping("/break")
suspend fun getBreak(): String {
    println("Current Coroutine Context -> $coroutineContext")
    println("Current Coroutine Job -> ${coroutineContext.job}")
    println("Main Coroutine Context -> ${currentCoroutineContext()}")
    println("Main Coroutine Job -> ${currentCoroutineContext().job}")
    println("Current Thread -> ${Thread.currentThread()}")
    return "break"
} This method will print out a series of useful information to the console about the corroutine that has been called. The suspend function marked with the suspend modifier isn’t itself a coroutine, but it can only be called by coroutines in Kotlin. And that’s what happens when we call the method. This way we get access to the coroutine context and checkout what dispatcher is being used. Important to note is that using the currentCoroutineContext() function, we are accessing the coroutine context via a top level function in the kotlinx coroutines library. Using coroutineContext, we are accessing the getter of a value located in the kotlin standard library itself. They don’t share exactly the same implementation.In the root of the car-parts-reactive module we’ll find file generated-requests.http and if you are using IntellJ, you can easily make requests to the application with the code contents: ###
GET http://localhost:8080/break

###
GET http://localhost:8080/keys

###
GET http://localhost:8080/parts

###
GET http://localhost:8080/parts/list

###
GET http://localhost:8080/parts/suspend

###
GET http://localhost:8080/parts/correct When you have the application running, try to run a simple REST request against endpoint : http://localhost:8080/break There should be a result in the console similar to this: Current Coroutine Context -> [Context2{micrometer.observation=io.micrometer.observation.NoopObservation@52c86bb3, reactor.onDiscard.local=reactor.core.publisher.Operators$$Lambda$1234/0x000000080165d210@7166cb50}, MonoCoroutine{Active}@5474a700, Dispatchers.Unconfined]
Current Coroutine Job -> MonoCoroutine{Active}@5474a700
Main Coroutine Context -> [Context2{micrometer.observation=io.micrometer.observation.NoopObservation@52c86bb3, reactor.onDiscard.local=reactor.core.publisher.Operators$$Lambda$1234/0x000000080165d210@7166cb50}, MonoCoroutine{Active}@5474a700, Dispatchers.Unconfined]
Main Coroutine Job -> MonoCoroutine{Active}@5474a700
Current Thread -> Thread[#50,reactor-http-epoll-2,5,main] We can see in all counts that the dispatcher being used is the Dispatchers.Unconfined. If we go back to the issue that was created on GitHub, we’ll see that the answer to why the spring framework uses Dispatchers.Unconfined turns out to be the best solution for their cases, according to them. So what they mean, is that in spite of these dispatchers appear to be limited and restrictive, they apparently, and after testing are actually a very good fit for a reactive framework.Of course this is great to read because it makes it clear why actually, unconfined dispatchers are used in Spring.But let’s go back to the basics. I made a few quizzes about unconfined dispatchers and what I like about it is that they are still quite mysterious to me. And let’s get one thing clear before we move on. There can be some confusion regarding context and scope. Scope refers to where the coroutine is available and context to how it gets dispatched. There can be confusion about this because both terms are quite intimately connected to each other. For example, we cannot create a scope without a dispatcher and they go hand in hand. A scope allows me to launch coroutines with keywords like async and/or launch, but a context is related to how that coroutine gets assigned a Thread.Let’s make two quizzes. We start with this one in this video: https://www.youtube.com/shorts/7Rv_zcT_yPE?embedable=true In this video I show a simple implementation of some code that makes some calls and these different calls will print the words “master”, “mouse” and “cat” in different orders. The code is available here: https://github.com/jesperancinha/jeorg-kotlin-test-drives?embedable=true For this quiz, the code is available here: git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/coroutines-crums-group-1
make b And the code is this one: private suspend fun runUnconfinedCoroutinesTest() {
    logger.infoTextSeparator("Unconfined means that all coroutines will execute concurrently on the starting thread in the scope of the parent thread")
    val job = CoroutineScope(Dispatchers.Unconfined).launch {
        launch {
            logger.infoThread("Cat Before thread ==> ${Thread.currentThread()}")
            delay(100)
            logger.info("This is cat @ ${LocalDateTime.now()}")
            logger.info("Cat context $coroutineContext")
            logger.infoThread("Cat After Resume thread ==> ${Thread.currentThread()}")
        }
        launch {
            logger.info("This is mouse @ ${LocalDateTime.now()}")
            logger.info("Mouse context $coroutineContext")
        }
        logger.info("This is master @ ${LocalDateTime.now()}")
        logger.info("Master context $coroutineContext")
        logger.infoThread(Thread.currentThread())

    }
    job.join()
} When we run this code, many things can happen, but one thing we can predict is how the logs are going to work out in the console. One thing about unconfined dispatchers is that they use the same context, same dispatchers, on the first sub coroutines. If these coroutines need to suspend, they may or may not return to the original Thread they were sharing. In the code above they will most likely not return to the original thread. Nesting in coroutines follows some very important rules as mentioned in their documentation: kotlinlang.org So this is the same as saying that the initial call executes in the same continuation in the same call-frame. This also means that the first 3 launches will run concurrently. The launch that logs a cat does this too, but beacause it has a delay, it will resume either in the same Thread or another thread. So this means that Mouse and Master will be the first things to see in the log and Cat will be the last log in the console. We can see all of this in this log sample: This is master @ 2024-03-21T18:49:00.661284475
Master context [StandaloneCoroutine{Active}@6ce139a4, Dispatchers.Unconfined]
Thread[#1,main,5,main]
Master After Resume thread ==> Thread[#1,main,5,main]
Cat Before thread ==> Thread[#1,main,5,main]
This is mouse @ 2024-03-21T18:49:00.703936722
Mouse context [StandaloneCoroutine{Active}@433d61fb, Dispatchers.Unconfined]
Mouse After Resume thread ==> Thread[#1,main,5,main]
This is cat @ 2024-03-21T18:49:00.801217959
Cat context [StandaloneCoroutine{Active}@52c68062, Dispatchers.Unconfined]
Cat After Resume thread ==> Thread[#28,kotlinx.coroutines.DefaultExecutor,5,main] And this explains the answer I give to this quiz on this video: https://www.youtube.com/shorts/MGxvkW0t8QM?embedable=true But moving on. I have another quiz for you and it is this one on this video: https://www.youtube.com/shorts/LEyEJkJA3xE?feature=share&embedable=true The code for this quiz is available here: git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/jeorg-kotlin-coroutines-unconfined
make b And this is the class we are discussing: object UnconfinedCoroutineLauncher {
    private val logger = object {
        fun info(logText: Any?) = ConsolerizerComposer.out().yellow(logText)
        fun infoBefore(logText: Any?) = ConsolerizerComposer.out().green(logText)
        fun infoAfter(logText: Any?) = ConsolerizerComposer.out().red(logText)
        fun infoTitle(logText: String) = ConsolerizerComposer.outSpace()
            .cyan(ConsolerizerComposer.title(logText))
    }

    @JvmStatic
    fun main(args: Array<String> = emptyArray()) = runBlocking {
        logger.infoTitle(
            "Unconfined Coroutines scope tests / There are currently ${
                Runtime.getRuntime().availableProcessors()
            } CPU's available"
        )
        CoroutineScope(Dispatchers.Unconfined).launch {
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Siamese Cat is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(1)
                logger.infoAfter("Siamese Cat just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Mouse is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(20)
                logger.infoAfter("Mouse just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Maine Coon is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(30)
                logger.infoAfter("Maine Coon is just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
        }.join()
    }
} The best way to pick one or more options form the one I give in the quiz, is to look at the order the animals start. In this case the can all start in random orders. However they will all share the same thread because they are just being launched from that call stack. This way, the Siamese Cat, the Mouse and the Main Coon need to share he same Thread number on those calls and so that eliminates already options B and D. The Siamese cat only has a delay of 1 ms and that means that, although seemingly unlikely, option A is still very possible. It is actually very likely that this coroutine starts and ends before any of the other two start. 1 ms is just too much of a short time. We have to consider that possibility as well. And this is why the right answers to this questions are A and C, and this is only one example of that result: Running on context [StandaloneCoroutine{Active}@4de5031f, Dispatchers.Unconfined]
Siamese Cat is launching on Thread-main with id 1
Siamese Cat just ran on Thread-main with id 1
Running on context [StandaloneCoroutine{Active}@691a7f8f, Dispatchers.Unconfined]
Mouse is launching on Thread-main with id 1
Running on context [StandaloneCoroutine{Active}@50a7bc6e, Dispatchers.Unconfined]
Maine Coon is launching on Thread-main with id 1
Mouse just ran on Thread-kotlinx.coroutines.DefaultExecutor with id 21
Maine Coon is just ran on Thread-kotlinx.coroutines.DefaultExecutor with id 21 Find the video answer to this . quiz here My idea with this article is to show some interesting cases I found with . You may find these issues while working with Kotlin coroutines and very likely a lot of people will tell you just to use the Default dispatcher. That can lead to a miscommunication problem. There is such a thing called , which is specific for CPU operations. When people say that when in doubt, use the default dispatcher, they probably do not mean the context. Make sure to double check, because, especially if you are working in server-side programming with certain frameworks, what they probably mean is that you shouldn’t use any specific dispatchers. Most of frameworks like the Spring Framework already offer support to use suspend functions and so your concern as a developer is for the most cases only to implement the suspend functions and not use any specific context. Use the default of course and that is, in Spring, the . Have a good one everyone! Dispatchers.Unconfined Dispatchers.Default Dispatchers.Default Dispatchers.Unconfined Also published . here

They Said to Use the Default Dispatchers but I Found it Was Unconfined

The checkbox is one of the most useful inputs for building dynamic apps with React. In this guide, we will see how to make the checkbox checked (or unchecked) by default. defaultChecked Prop As a React developer, you are probably familiar with JSX. It’s a templating language to easily develop UIs in React. Its biggest advantage is that most elements and development processes are very similar to HTML. Similar to HTML, you can set the attribute on checkbox inputs. It needs to be set to a Boolean value. If set to , the checkbox will be automatically selected. If the value is , or there’s no default at all, the checkbox will not be automatically selected. defaultChecked true false Let’s look at an example: <input type="checkbox" defaultChecked="true" /> This is a simple uncontrolled checkbox. The attribute is set to a Boolean value . In the real world, is often set to a Boolean value from the state, or a complex condition that evaluates to or . defaultChecked true defaultChecked true false Set the Default Value of a Controlled Checkbox in React In most cases, it’s best to create controlled inputs in React. These are inputs that get their value from the state. Changes to the checkbox also update the state. Let’s look at a of a controlled checkbox: live demo import "./styles.css";
import { useState } from "react";
export default function App() {
 const [checkbox, setCheckbox] = useState(true);
 const handleChange = (e) => setCheckbox(e.target.checked);
 return (
   <div>
    <input type="checkbox" defaultChecked="true" onChange={handleChange} />
    <p>Checkbox is {checkbox ? "checked" : "unchecked"}</p>
    </div>
  );
} style="width:100%; height: 500px; border:0; border-radius: 4px; overflow:hidden;" 

 title="clever-ives" 

 allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking" 

 sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" When it first loads, the checkbox is selected because is set to . defaultChecked true The event handler tracks change events, accesses the current status (checked or not), and stores it in the state. In this case, we do not set the attribute on an input. attribute results in less code and works the same. value defaultChecked We can keep track of the current value of the checkbox and use it for conditional styling, rendering, and other dynamic features in React. For example, you can use conditional styling to implement the dark mode. If you’d like to learn more, check out my . I’ve published several articles about working with inputs in React. React guides with examples

How to Set A Default Checkbox Value in React

One of the key features of the Spring Boot framework is the built-in support for embedded servers. It includes support for embedded Tomcat, Jetty, and Undertow servers. This means you don’t need any external web servers and no need to deploy WAR files anymore. The embedded Tomcat server is available through the dependency. spring-boot-starter-web However, if you want Jetty or Undertow servers then you can include or dependencies. spring-boot-starter-jetty spring-boot-starter-undertow This article explains how to replace the default embedded Tomcat with Jetty or Undertow servers. https://youtu.be/1gEoiMVULt4?si=RVOx-P3o65KPN2-p&embedable=true Replace Tomcat With the Jetty in Spring Boot To use the embedded Jetty server instead of Tomcat, you need to exclude the from and include the dependency. Also, you will need to exclude the default added spring-boot-starter-tomcat dependency. spring-boot-starter-tomcat spring-boot-starter-web spring-boot-starter-jetty For Spring Boot Version 2.x.x For , make the following changes to your file. Gradle build.gradle dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group:'org.springframework.boot', module:'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-jetty'
} If you’re using build tools, you need to add this to your file. Maven pom.xml <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency> For Spring Boot Version 3.x.x The above configuration works for Spring Boot version 2.x, but it will throw the following error if you’re using the latest Spring Boot version 3.x. java.lang.ClassNotFoundException: jakarta.servlet.http.HttpSessionContext 
with Spring Boot 3 and Jetty server This is because Jetty does not yet support Servlet 6.0. To use Jetty with Spring Boot 3.0, you will have to downgrade the Servlet API to 5.0. You can use the property to do so. jakarta-servlet.version Ref: Spring-Boot-3.0-Migration-Guide ext['jakarta-servlet.version'] = '5.0.0'
dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web')
    implementation 'org.springframework.boot:spring-boot-starter-jetty'
    modules {
        module("org.springframework.boot:spring-boot-starter-tomcat") {
            replacedBy("org.springframework.boot:spring-boot-starter-jetty")
        }
    }
} If you’re using build tools, you need to add this to your file. Maven pom.xml <properties>
    <java.version>17</java.version>
    <jakarta-servlet.version>5.0.0</jakarta-servlet.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <artifactId>spring-boot-starter-tomcat</artifactId>
                <groupId>org.springframework.boot</groupId>
            </exclusion>
        </exclusions>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
</dependencies> Replace Tomcat With Undertow in Spring Boot To use Undertow instead of Tomcat, first, you need to exclude the spring-boot-starter-tomcat from spring-boot-starter-web. Then you should add the undertow starter as shown here. For , make the following changes to your file. Gradle build.gradle dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group:'org.springframework.boot', module:'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-undertow'
} If you’re using build tools, you need to add this to your file. Maven pom.xml <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency> Also published here

Replacing Default Tomcat Server With Jetty or Undertow in Spring Boot 3: A Guide

In today's article, you'll learn how HTML elements are stacked by . default Note, I'll NOT teach you how to change the stacking order of elements (you may use the CSS property for this purpose) but only teach you how things work "naturally". z-index I believe understanding how element stacking works by default will make it easier for you to learn how to control it, a concept I'll cover in a future article. Table of contents Important terms The default stacking order Demo Summary Conclusion Important terms : You may recall from high school math classes the , which is formed by the , and axes. In this system, if you combine two axes you create a two-dimensional . The remaining axis will always be perpendicular to the plane and form with it the 3D coordinate system. Consider the below z-axis 3D coordinate system x y, z plane image You can think of the plane (the blue layer) as the screen you're looking at right now. Since you're facing the screen (you're perpendicular to the screen) you're on the -axis. xy z Although the image only shows one layer on the plane, the plane can contain an infinite number of layers. The overlapping can be total or partial. xy overlapping : Considering the system described above in the context of a web page, is the total or partial superposition of elements. The higher the stack, the closer to the user-facing the screen. Stacking stacking : The element, which is the top-level element of any HTML document, is also known as the . Root element <html> root element : Positioned element A positioned element is an element whose computed position value is either relative, absolute, fixed, or sticky. (In other words, it's anything except static.) : A descendant element is an element that is nested within another element, regardless of how deeply nested. Descendant element : An element that is a descendant of the root element and that has NOT been positioned. Descendant non-positioned element : An element that is a descendant of the root element and that has been positioned. Descendant positioned element : Keep in mind that the element is a container for the and the elements. The former is NOT visible to the user and contains metadata about your page, for instance, it links your page to external style sheets. The latter is a container for the visible portion of your page. Therefore, the descendants of the element that matters to us is the one inside the element. Note <html> <head> <body> <html> <body> The default stacking order Once you understand the terms described above, understanding the default stacking order is pretty straightforward: At the very bottom of the stack goes the element. <html> Then, its non-positioned descendant elements, in order of appearance in the source code. And finally, its positioned descendant elements, in order of appearance in the source code. Demo https://www.youtube.com/watch?v=zac8nGU2RkU&embedable=true <body>
  <div class="static1">Static #1</div>
  <div class="relative">Relative</div>
  <div class="absolute">Absolute</div>
  <div class="fixed">Fixed</div>
  <div class="sticky">Sticky</div>
  <div class="static2">Static #2</div>
</body> You can see from the demo and from the snippet above that both static elements go below the positioned elements when they overlap, even though comes last in the source code. This proves that in this imaginary positioned elements are closer to the user than non-positioned elements. Static #2 z-axis, The way the positioned elements overlap proves that they are stacked in order of appearance. What about the ? root element The next paragraph might blow your mind 🤯 I haven't set any styles to it, which makes it keep its . The white background you see comes from the light your device's screen emits. Don't believe me? See the for the . transparent background-color Formal definition background-color If you set a different to the you'll confirm that it is below its descendant elements. background-color root element Summary The first thing to consider is that, when we talk about , we're talking about a tridimensional conceptualization of pages. Elements are stacked on the z-axis, which is an imaginary axis perpendicular to the screen. stacking HTML Second, in order to understand how elements are stacked by default, i.e., without the property, we need to make a distinction between three types of elements: z-index The root element (the element) which is a container for every other element you add to your page. <html> Non-positioned elements, which have their computed value equals to . position static Positioned elements, which have their computed value equals to anything but . position static Third, stacking will only be observable in cases of overlapping between elements. Fourth, you may not have noticed, but there's no distinction between the different types of positioned elements. By that I mean that absolutely positioned elements do not have precedence over relatively positioned elements or vice-versa, for example. They have the same "weight" and the one that comes later on the source code will be on top. Conclusion Once you understand what means in the context of web pages and the different types of elements that can be stacked, understanding the default stacking order becomes crystal clear. stacking From a philosophical perspective, when you compare the section with the section you can see that learning may be more difficult, but it will make learning the easier. Important Terms default stacking order why how Finally, this article does NOT deal with the stacking of nested elements of a stacked element, nor with how to alter the stacking order, but I promise I'll cover that in a future article 🫡 This project's source code is available at this . Go ahead and give it a star! repo Did you like this article? Share it with your friends, or leave a comment or a reaction. Of course, there's nothing stopping you from doing everything 😄 If you're on HackerNoon, don't forget to if you want to get my latest articles straight to your inbox. subscribe

How Are HTML Elements Stacked by Default?

Solidity's custom errors offer significant advantages in blockchain development, enhancing smart contract robustness and clarity. These errors provide detailed and precise error messages, improving the ease of issue diagnosis. Additionally, they strengthen code readability by allowing for clear naming of error conditions and improve gas efficiency by enabling compact encoding of error information. Embracing these custom errors can revolutionize your Solidity development experience. Let's see how we can use custom errors in our Ethereum smart contracts. Defining Custom Errors In Solidity, defining a custom error is a straightforward process that enhances the clarity and specificity of error messages in smart contracts. To define a custom error, you use the error keyword followed by a unique name for the error. If you want to include specific details or parameters in the error message, add them in parentheses after the error name. error NumberTooHigh(uint256 from, uint256 number); Or we can omit the parameters and define a custom error with them. error Unauthorized(); Using Custom Error Once defined, we can trigger this error using the revert statement followed by the error name and required parameters. This approach makes the code more readable and provides a clear context for the error, aiding developers in diagnosing and addressing issues more efficiently. We can use the' revert' keyword to utilize errors that don't require parameters. Then, we specify the desired custom error name and call it a regular function. revert Unauthorized(); To use a custom error with parameters, we must pass the error name and parameters when reverting, similar to how we would pass them in a function. revert NumberToLow(from, number); Consuming Custom Errors When utilizing a smart contract that has custom errors, it can provide users with more specific explanations of what went wrong. By utilizing libraries such as ethers.js or web3.js, developers have a more effective means of managing and presenting information to users. Using the Remix test environment, we can see how a custom error is present in the log console. TL;DR Custom errors in Solidity can improve the transparency and effectiveness of smart contract code, providing more insightful feedback for developers and smart contract consumers, for instance, using a Web3 library. Adding them to your toolkit can be highly beneficial and reduce gas costs. Links Sample code Custom Errors in Solidity Embracing Custom Errors in Solidity documentation revert

How to Master Custom Errors in Solidity: Beyond Default Messages

In this tutorial, you will learn how to resolve the "SyntaxError: non-default argument follows default argument" in Python. This common error occurs when you provide a default value for one or more arguments in a function definition, and then you place a non-default argument after the default ones. This tutorial will cover the following topics: Understanding Default and Non-Default Arguments Why This Error Occurs How to Resolve the Error Examples and Explanations Best Practices Understanding Default and Non-Default Arguments Before we dive into resolving the error, it's essential to understand the difference between . default and non-default arguments in Python Default Arguments Default arguments are the parameters of a function that have a default value assigned to them. If the caller doesn't provide a value for a default argument, the function will use the specified default value. Default arguments are defined with an equal sign ( ) followed by the default value. = def greet(name, greeting="Hello"):
    print(greeting, name) In this example, is a default argument with the default value "Hello". If you don't provide a value for , the function will use "Hello" as its value. greeting greeting Non-Default Arguments Non-default arguments, also known as positional arguments or required arguments, are the parameters of a function that must be provided by the caller. They don't have a default value, so the caller must always provide a value for them. def greet(name, greeting):
    print(greeting, name) In this example, both and are non-default arguments, and the caller must provide values for both of them. name greeting Why This Error Occurs The "SyntaxError: non-default argument follows default argument" occurs when a with a non-default argument after one or more default arguments. Python doesn't allow this because it creates ambiguity in the function call. function is defined Consider the following example: def example_function(a=1, b):
    pass This function definition will raise a syntax error because the non-default argument follows the default argument . When you and provide only one argument, Python wouldn't know whether to assign the value to or . b a call this function a b How to Resolve the SyntaxError: Non-Default Argument Follows Default Argument To resolve the "SyntaxError: non-default argument follows default argument" error, ensure that all non-default arguments are placed before any default arguments in your function definition. If you want to provide a default value for an argument, make sure it comes after all the required arguments. def example_function(b, a=1):
    pass In this example, by placing the non-default argument before the default argument . we have fixed the error b a Examples and Explanations Let's explore some examples to better understand how to resolve this error in different situations. Example 1: Simple Function With One Default and One Non-Default Argument # Incorrect function definition
def greet(greeting="Hello", name):
    print(greeting, name)

# Correct function definition
def greet(name, greeting="Hello"):
    print(greeting, name)

# Calling the function
greet("Alice") Output: Hello Alice In this example, the incorrect function definition has the default argument before the non-default argument , causing the syntax error. greeting name We fix the error by placing the non-default argument before the default argument . name greeting Example 2: Function With Multiple Default and Non-Default Arguments # Incorrect function definition
def calculate(a=0, b, operation="+"):
    if operation == "+":
        return a + b
    elif operation == "-":
        return a - b
    elif operation == "*":
        return a * b
    elif operation == "/":
        return a / b

# Correct function definition
def calculate(b, a=0, operation="+"):
    if operation == "+":
        return a + b
    elif operation == "-":
        return a - b
    elif operation == "*":
        return a * b
    elif operation == "/":
        return a / b

# Calling the function
print(calculate(5))
print(calculate(3, 2))
print(calculate(3, 2, "*")) Output: 5
5
6 In this example, the incorrect function definition has the default argument before the non-default argument , causing the syntax error. We fix the error by placing the non-default argument before the default arguments and . a b b a operation Example 3: Function With Keyword-Only Arguments You can use the character in the function definition to indicate that all following arguments are keyword-only arguments. This allows you to have default arguments before non-default arguments without causing a syntax error. * # Correct function definition with keyword-only arguments
def display_data(first_name, last_name, *, age=None, city=None):
    print(f"Name: {first_name} {last_name}")
    if age:
        print(f"Age: {age}")
    if city:
        print(f"City: {city}")

# Calling the function
display_data("Alice", "Smith", age=30, city="New York") Output: Name: Alice Smith
Age: 30
City: New York In this example, we use the character to indicate that and are keyword-only arguments. This allows us to have the default arguments and before the non-default arguments and without causing a syntax error. * age city age city first_name last_name Best Practices To avoid the "SyntaxError: non-default argument follows default argument" error in your Python code, follow these best practices: Always place non-default arguments before default arguments in your function definition. If you want to provide a default value for an argument that needs to appear before non-default arguments, consider using keyword-only arguments with the character in the function definition. * When working with a function that has both default and non-default arguments, consider using keyword arguments in the function call to make the code more readable and less error-prone. By following these best practices, you'll be able to write more robust and maintainable that avoids the "SyntaxError: non-default argument follows default argument" error. Python code Disclaimer: The code examples and explanations provided in this tutorial are generated by ChatGPT-4, an AI language model. However, a human editor has reviewed, edited, and tested the content to ensure accuracy and quality. Approximately 60% of the text in this tutorial is generated by human effort to provide a more reliable and coherent learning experience.

Stories, News & Mentions about DEFAULT

Default’s Stories on HackerNoon