Bridger Aerospace announced on February 20th, the deployment of a Pilatus PC-12 Multi-Mission Aircraft (MMA) to Oklahoma to provide aerial intelligence for early-season wildfires. This marks the earliest seasonal deployment of any Bridger Aircraft since the company’s inception in 2014.

Bridger Aerospace Announces Earliest Fire Season Dispatch in Company ...

Looking for the best truck dispatch company to help you improve driver efficiency and minimize downtime? If so, check out this list.

5 best truck dispatching company options - FreightWaves Ratings

The Columbus Dispatch is the number one source for Columbus and Ohio breaking politics, business, obituaries, Ohio sports and entertainment news.

The Columbus Dispatch: Columbus, Ohio, News, Politics & Sports

Carrier Service Delivering Excellence in Logistics Welcome to MetroMax Logistics Services, your trusted partner for secure and lightning-fast carrier services. When you think carrier service, think MetroMax Logistics Services. Let’s Talk Logistics Services We Provide We focus on diverse carrier ...

Dispatch Company | Independent Truck and Freight ...

Nationwide Transport Services offers trustworthy and reliable truck dispatching services. Over 150,000 trucks nationwide. Contact us today.

Truck Dispatch Services | Freight Dispatch Company

Dispatch Company &amp; Lease Operator Opportunities Dispatch Company We&#x27;re a dispatch company offering truck dispatch services for motor carriers operating under their own MC Authority. A time-tested approach and the very best truck dispatchers, makes a recipe for success!

Dispatch Company & Lease Operator Opportunities

See what employees say it&#x27;s like to work at Dispatch. Salaries, reviews, and more - all posted by employees working at Dispatch.

Working at Dispatch | Glassdoor

With Dispatch&#x27;s Lua, Unity, and Unreal SDKs, shopping for physical goods within digital worlds is now possible. Checkout happens entirely within the experience without redirection.Book a demo · Bring end-to-end checkout into any human and AI powered conversations.Book a demo ... The first round of ad spend is on us. Claim your free ad credit now. ... Offer for qualified brands only. Up to $1,000 per company...

Dispatch

Find loads and trucks fast with full access to the trusted DAT Network. Freight matching designed for shippers, brokers and carriers.

Truck Dispatch Services - DAT

Logity Dispatch is a truck dispatch company that provides top-notch truck delivery services to owner-operators and small transportation companies.

Dispatch Services for Drivers and Trucking Companies

dispatch

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

They say the devil's in the details, but in the case of , it's more like a mischievous gremlin with a penchant for blockchain security. I plunged headfirst into this tech rabbit hole to witness Mitja Gorochevsky, the wild mind behind and this radical consensus algorithm, unleash his latest creation on a crowd of unsuspecting tech enthusiasts. Acki Nacki GOSH The Scene: A Digital Carnival of Quirk Picture a virtual stage where coding wizards and crypto evangelists collide—that's the kind of energy that crackled through the air as Mitja took the reins. The vibe was part tech conference, part cyberpunk circus, with Acki Nacki taking center stage as a personified defender of integrity. blockchain But even gremlins have their off days. Internet gremlins, that is. The demo hit a few snags thanks to connectivity hiccups, but that didn't dampen the spirit. It just added a layer of unpredictable chaos to the mix, as if Acki Nacki was flexing its trickster muscles. Enter Acki Nacki: The Multi-Headed Hydra of Blockchain Now, hold on to your crypto wallets because Acki Nacki is no ordinary consensus algorithm. Imagine a multi-core, multi-threaded execution environment where anyone can drop a contract and run operations in parallel with lightning-fast, under-1-second finality. And all this on the decentralised supercomputer known as GOSH. "The odds of a successful malicious attack on GOSH (with Acki Nacki) is not just less likely than a successful attack on Bitcoin," Mitja boldly declared, "it's less likely than an asteroid hitting Earth and wiping us all out tomorrow!" Hackathon Hoedown and the GOSH Gold Rush But the real party starts with the "Underworld" hackathon. A siren call to tech rebels, inviting them to bend the boundaries of what's possible. Here are the challenges they laid down: Wallet apps that make your crypto quiver with glee. Visualisation tools to make blockchains look like trippy art installations. Security tooling so tight that even the NSA would be impressed. SDKs, TVMs, ZKPs... basically, if it sounds like alphabet soup, it's fair game. Why go through all this trouble? Because the only way to score GOSH tokens is either through this hackathon or the "Die Last" validator games. It's a tech wild west where your coding skills are your six-shooter. Is anyone paying attention, though, Ben? Well, I'm glad you asked. For me, the big-news-plot-twist of the evening, away from all the tech bluster, is that the United Nations, the global epitome of diplomatic collaboration, has chosen GOSH to host its decentralized autonomous organization (DAO) for the Internet Governance Forum (IGF). This move underscores the growing recognition of GOSH as a reliable and secure platform for handling critical aspects of Internet governance. I can already picture Acki Nacki, the mischievous guardian of blockchain integrity, now donning the mantle of responsibility as it becomes the backbone for this huge UN-backed initiative. Conclusion: A Glimpse into a Decentralized Future, Gremlins and All Did Acki Nacki live up to the hype? The jury's still out, but one thing's for certain: Mitja knows how to throw a tech party that leaves you questioning reality and craving more. In a world of sterile blockchain conferences, this was a jolt of raw, unadulterated innovation. Hold on tight, folks—the GOSH ride is just getting started.

Deep in the Tech Underworld, a Gremlin-Like Consensus Wakes: Dispatches of the Acki Nacki Freakshow

Scientific American Supplement, No. 799, April 25, 1891 by Various, is part of the HackerNoon Books Series. You can jump to any chapter in this book . THE NEW GERMAN DISPATCH BOAT METEOR. here THE NEW GERMAN DISPATCH BOAT METEOR. In time of war the dispatch boats are the eyes of the fleet. It is their duty to reconnoiter and ascertain the strength of the enemy and to carry the orders of the commander. For this service great speed is of the utmost importance. As all nations have increased the speed of their war ships during the last few years, it has become necessary to build faster dispatch boats. Although our new vessels of this class, Blitz, Pfeil, Greif, Jagd, and Wacht, fulfill the requirements, still greater speed was deemed requisite, and steps were taken for the construction of the Meteor, which was launched at Kiel in 1890. This vessel is 262 ft. long, 31 ft. wide, and has a draught of 13 ft., and a displacement of 950 tons. There are two independent engines, each of which develops 2,500 h.p., making a total of 5,000 h.p.; and each engine drives a screw. When both engines are running with their full power, the Meteor has a speed of 24 knots (over 27½ miles) an hour, which is equal to the speed of a freight train. As the resistance of the water increases greatly with an increase in the speed of the vessel, the engines of the Meteor are very large in comparison with the size of the vessel. The largest armored vessel in the navy, the Konig Wilhelm, for example, has a displacement of 9,557 tons, and its engines develop 8,000 h.p., driving the vessel at a rate of 14 knots an hour; that is, 0.84 h.p. to each ton of displacement, while in the Meteor there is 5.26 h.p. to each ton of displacement. The Meteor has a crew of 90 men, and an armament of eight light guns, and has no rigging; only one mast for signaling. Steam power is used for raising the anchor, removing the ashes from the engine room, and for distilling water. The vessel is lighted with electricity, and is also provided with electrical apparatus for search lights.— . [1] Illustrirte Zeitung This, we believe, is the fastest vessel of the kind afloat.—ED. S.A. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Various (2004). Scientific American Supplement, No. 799, April 25, 1891. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/11649/pg11649-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

THE NEW GERMAN DISPATCH BOAT METEOR

Modern Central Processing Units (CPUs) contain multiple cores which allow for several threads to be run in parallel and more than one task to be performed at a time. This enables your iPhone app to, for instance, download a large file in the background while the user interface remains responsive. Apple provides two methods for multitasking in iOS development, Grand Central Dispatch (GCD) and NSOperation. In this article, we will look at GCD. If you need a refresher on the basics of concurrency in iOS development, check out . this article GCD was introduced in iOS 4 and offers the developer flexibility when using concurrency in their application. The main idea behind GCD is to move thread management closer to the It abstracts threads away from the developer, who will not need to consider so many details. In essence, GCD decides which thread should be used to execute any given task. operating system. Content Overview Dispatch Queues Quality of Service (QOS) Background Utility User-Initiated User-interactive Order and Manner of Dispatch Synchronous vs Asynchronous Serial vs Concurrent Serial Queues Concurrent Queues Global Queues Dispatch Methods Conclusion Dispatch Queues A term that is frequently used when discussing GCD is . A dispatch queue is an abstraction layer on top of a queue that contains tasks to be executed following the FIFO (first in, first out) algorithm. dispatch queue GCD manages a collection of dispatch queues. The work items submitted to these dispatch queues are executed on a pool of threads. There is a dispatch queue that represents the application’s main thread (also known as the UI thread) and multiple dispatch queues which represent the many background threads. Quality Of Service (QOS) A quality-of-service (QOS) class categorizes the work items which are performed on a dispatch queue. With this parameter, the priority of a given task is specified. There are four QOS classes that may be assigned to a queue. Background These are tasks that can take minutes or hours to complete such as loading or processing large amounts of data. They are not time-critical and the user needs to be able to do other things while they are happening. Such tasks are mapped to a low-priority queue. Utility These tasks take seconds or minutes and should be completed immediately. An example of a utility task would be one with a loading bar, such as a download. User-initiated These are tasks initiated by the user which should be executed right away, such as opening a document. They will be mapped to a high-priority queue and should only take a few seconds or less. User-interactive These are UI tasks that need to be finished immediately to ensure that the user is able to continue with the next interaction. They are mapped to the queue with the highest priority and run on the main thread. Order and manner of dispatch When using queues, the order and manner in which tasks are dispatched need to be chosen. GCD queues can be serial or concurrent and pushing tasks to them can happen synchronously or asynchronously. Synchronous vs asynchronous When a work item is scheduled synchronously, the execution of code that is happening on the current thread is paused until the item’s execution is completed. It is important not to execute a work item synchronously on the main queue as this results in a deadlock. When it is scheduled asynchronously, the code on the current thread continues to be executed while the work item is scheduled to run on another thread. Serial vs concurrent In a serial queue, tasks are executed one after the other according to the FIFO algorithm. The serial queue just needs one thread since only one task is running at a time. A concurrent queue creates as many threads as it has tasks dispatched into it. The developer does not control the creation of the threads. Serial Queues An example of a serial queue can be found below. func mySerialQueue() {
 let serialQueue = DispatchQueue(label: "com.kraken.serial")
 serialQueue.async {
 sleep(1)
 print("Task 1")
 }
 serialQueue.async {
 print("Task 2")
 }
} Despite the “sleep” instruction within the first task, the output will be: Task1
Task2 This is because the tasks are executed serially in the order in which they were added to the queue. Serial execution is not ideal since one task has to wait for the other. Even if the task that is first in the queue takes much longer than the task behind it, the first task will be given priority. Think of it like two people waiting in line at the grocery store with the first person making a large purchase for the whole week while the person behind them is only buying one small item. In this case, it makes sense to let the person with the small item pass first so that they can go on with their day without any unnecessary delay. Concurrent Queues Let us look more closely at how multiple tasks, or work items, can be run at the same time by utilizing a concurrent queue. Using the .concurrent flag creates a queue that allows many tasks to be performed simultaneously. One task does not have to wait for another to finish. func concurrentQueues(){
 let myQueue = DispatchQueue(label: "com.multithreading.concurr", qos: .utility, attributes: .concurrent)
 myQueue.async {
 for i in 0..<10 {
 print("1")
 }
 }
 myQueue.async {
 for j in 0..<10 {
 print("2")
 }
 }
} In this case, the output would alternate between “1” and “2” as the threads belonging to each of the two tasks are getting switched out. With concurrent execution, it is important not to call methods that block the current thread. If a task that blocks a thread is scheduled by a concurrent dispatch queue, it will cause the system to create new threads to run other concurrent tasks in the queue. As a result, the system could run out of threads. Apps can also use up too many threads if too many private concurrent dispatch queues are created. Each dispatch queue consumes thread resources. Instead of creating private concurrent queues, tasks can be submitted to one of the global concurrent dispatch queues. Global Queues GCD creates a set of dispatch queues also known as global queues. They can be used freely like custom queues. let myGlobalQueue = DispatchQueue.global() The QOS class can be set by the developer. If this parameter is not set, the default case is used. let myGlobalQueue = DispatchQueue.global(qos: .userInitiated) Accessing the main queue to perform tasks such as updating the UI can be done by calling the main queue and specifying if a synchronous or asynchronous call should be made. DispatchQueue.main.async {} Dispatch Methods Let us look at some of the different functions GCD provides to dispatch tasks. Dispatch Group A dispatch group is a group of tasks that is monitored as one unit. This way, collections of tasks can be aggregated. Multiple work items are attached to a group and scheduled for asynchronous execution. This way, multiple processes can be started but only one event is needed which occurs when all tasks have been completed. For instance, a dispatch group can be useful when multiple calls to APIs need to be made on a background thread before the UI can be updated on the main thread. func myTask1(dispatchGroup:DispatchGroup){
 DispatchQueue.global().async {
 print("Task 1 finished")
 dispatchGroup.leave()
 }
}

func myTask2(dispatchGroup:DispatchGroup){
 DispatchQueue.global().async {
 print("Task 2 finished")
 dispatchGroup.leave()
 }
}
 
func myDispatchGroup(){
 let dispatchGroup = DispatchGroup()
 dispatchGroup.enter()
 myTask1(dispatchGroup: dispatchGroup)
 dispatchGroup.enter()
 myTask2(dispatchGroup: dispatchGroup)
 
 dispatchGroup.notify(queue: .main) {
 print("All tasks finished.")
 }
} In the given example, the two tasks are grouped together and the main queue is only notified once they have both been completed. Dispatch Work Item A dispatch work item encapsulates a block of code and provides the flexibility to cancel the given task. Imagine that you are using the search function in an app. With every typed letter, a new search call is made and the previous one is canceled. func search(_ searchBar: UISearchBar, textChanged searchText: String) {
 workItem?.cancel()
 
 let searchWorkItem = DispatchWorkItem {
 print("Run search call with text: \(searchText)")
 }
 
 workItem = searchWorkItem
 DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(100), execute: searchWorkItem)
} Dispatch Semaphore The dispatch semaphore uses a counting semaphore to control access to a resource that can be accessed by multiple threads. This is a way to implement the critical section, where a shared resource is accessed by a process that would not operate correctly if the resource was accessed concurrently by another process. let mySemaphore = DispatchSemaphore(value: 1)
mySemaphore.wait()
task { (result) in
 mySemaphore.signal()
} wait() is called to access a shared resource. signal() is called when a shared resource should be released. The value contained in DispatchSemaphore describes the number of tasks running concurrently. Dispatch Barrier Another way to implement the critical section is a dispatch barrier which ensures that no other task is being processed while the given one is executed. func myDispatchBarrier(){
 let myConcQueue = DispatchQueue(label: "com.kraken.barrier", attributes: .concurrent)
 
 for i in 1…3 {
 myConcQueue.async() {
 print("Asynchronous Task")
 }
 }
 
 for j in 1…3 {
 myConcQueue.async(flags: .barrier) {
 print("Barrier")
 }
 }
} The three “Barrier” printouts in the output will not be interrupted by an “Asynchronous Task” printout at any point. Async after This method can be utilized to delay the execution of a task. GCD enables the developer to set the amount of time after which the task should be run. let time = 2.0
DispatchQueue.main.asyncAfter(deadline: .now() + time){
 print("Delayed task")
} Conclusion With GCD, has provided a multithreading model that is efficient and minimizes the risk of issues related to concurrency such as deadlocks. Apple Expensive tasks are performed in the background, leaving the main thread unaffected and thus improving the responsiveness of the application. As thread management is taken on by the operating system, the developer does not have to implement it by hand and can rely on GCD to match the running applications to the available system resources in a balanced manner. Also published here. The lead image for this article was generated by HackerNoon's AI Image Generator via the prompt "ios development”.

Grand Central Dispatch (GCD) in iOS: The Developer's Guide

Welcome to other chapters of Let’s Understand Chrome V8 Dispatch is responsible for scheduling bytecode, which is equivalent to registering EIP++, and jumps to the next bytecode. Dispatch consists of two parts, one is a dispatch table and the other is the physical register. The table is an array that contains all bytecode addresses. V8 uses the physical register to dispatch bytecode for getting greater efficiency. 1. Dispatch Table The dispatch table is an array of pointers, which is used to store the address of the bytecode processing program. The array type is Code, and the Code Class is below: class Code: public HeapObject {
 public: NEVER_READ_ONLY_SPACE
 using Flags = uint32_t;
 #define CODE_KIND_LIST(V)\
 V(OPTIMIZED_FUNCTION)\
 V(BYTECODE_HANDLER)\
 V(STUB)\
 V(BUILTIN)\
 V(REGEXP)\
 V(WASM_FUNCTION)\
 V(WASM_TO_CAPI_FUNCTION)\
 V(WASM_TO_JS_FUNCTION)\
 V(JS_TO_WASM_FUNCTION)\
 V(JS_TO_JS_FUNCTION)\
 V(WASM_INTERPRETER_ENTRY)\
 V(C_WASM_ENTRY)
 enum Kind {
 #define DEFINE_CODE_KIND_ENUM(name) name,
 CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
 #undef DEFINE_CODE_KIND_ENUM
 NUMBER_OF_KINDS
 };
 static
 const char * Kind2String(Kind kind);
 #ifdef ENABLE_DISASSEMBLER
 const char * GetName(Isolate * isolate) const;
 V8_EXPORT_PRIVATE void Disassemble(const char * name, std::ostream & os,
 Address current_pc = kNullAddress);
 #endif
 //................omit................
 }; : In the isolate, there is another pointer array that is the same type as the dispatch table. It holds all the Builtins addresses, which can confuse beginners easily. Note The dispatch table is maintained by BuildWithMacroAssembler, code is below: Code BuildWithMacroAssembler(Isolate * isolate, int32_t builtin_index,
 MacroAssemblerGenerator generator,
 const char * s_name) {
 HandleScope scope(isolate);
 // Canonicalize handles, so that we can share constant pool entries pointing
 // to code targets without dereferencing their handles.
 CanonicalHandleScope canonical(isolate);
 constexpr int kBufferSize = 32 * KB;
 byte buffer[kBufferSize];
 MacroAssembler masm(isolate, BuiltinAssemblerOptions(isolate, builtin_index),
 CodeObjectRequired::kYes,
 ExternalAssemblerBuffer(buffer, kBufferSize));
 masm.set_builtin_index(builtin_index);
 DCHECK(!masm.has_frame());
 generator( & masm);
 int handler_table_offset = 0;
 // JSEntry builtins are a special case and need to generate a handler table.
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSEntry), Builtins::ASM);
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSConstructEntry), Builtins::ASM);
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSRunMicrotasksEntry), Builtins::ASM);
 if (Builtins::IsJSEntryVariant(builtin_index)) {
 handler_table_offset = HandlerTable::EmitReturnTableStart( & masm);
 HandlerTable::EmitReturnEntry( &
 masm, 0, isolate -> builtins() -> js_entry_handler_offset());
 }
 //.....................................................
 //................omit.............................
 } You can see regarding how to debug the BuildWithMacroAssembler. When the value of the parameter builtin_index is 65, the function pointer generator points to which is responsible for maintaining the Dispatch table, code is below: Chapter 9 Generate_InterpreterEnterBytecodeDispatch static void Generate_InterpreterEnterBytecode(MacroAssembler * masm) {
 // Set the return address to the correct point in the interpreter entry
 // trampoline.
 Label builtin_trampoline, trampoline_loaded;
 Smi interpreter_entry_return_pc_offset(
 masm -> isolate() -> heap() -> interpreter_entry_return_pc_offset());
 DCHECK_NE(interpreter_entry_return_pc_offset, Smi::kZero);
 // If the SFI function_data is an InterpreterData, the function will have a
 // custom copy of the interpreter entry trampoline for profiling. If so,
 // get the custom trampoline, otherwise grab the entry address of the global
 // trampoline.
 __ movq(rbx, Operand(rbp, StandardFrameConstants::kFunctionOffset));
 __ LoadTaggedPointerField(
 rbx, FieldOperand(rbx, JSFunction::kSharedFunctionInfoOffset));
 __ LoadTaggedPointerField(
 rbx, FieldOperand(rbx, SharedFunctionInfo::kFunctionDataOffset));
 __ CmpObjectType(rbx, INTERPRETER_DATA_TYPE, kScratchRegister);
 __ j(not_equal, & builtin_trampoline, Label::kNear);
 __ movq(rbx,
 FieldOperand(rbx, InterpreterData::kInterpreterTrampolineOffset));
 __ addq(rbx, Immediate(Code::kHeaderSize - kHeapObjectTag));
 __ jmp( & trampoline_loaded, Label::kNear);
 __ bind( & builtin_trampoline);
 // TODO(jgruber): Replace this by a lookup in the builtin entry table.
 __ movq(rbx,
 __ ExternalReferenceAsOperand(
 ExternalReference::
 address_of_interpreter_entry_trampoline_instruction_start(
 masm -> isolate()),
 kScratchRegister));
 __ bind( & trampoline_loaded);
 __ addq(rbx, Immediate(interpreter_entry_return_pc_offset.value()));
 __ Push(rbx);
 // Initialize dispatch table register.
 __ Move(
 kInterpreterDispatchTableRegister,
 ExternalReference::interpreter_dispatch_table_address(masm -> isolate()));
 // Get the bytecode array pointer from the frame.
 __ movq(kInterpreterBytecodeArrayRegister,
 Operand(rbp, InterpreterFrameConstants::kBytecodeArrayFromFp));
 if (FLAG_debug_code) {
 // Check function data field is actually a BytecodeArray object.
 __ AssertNotSmi(kInterpreterBytecodeArrayRegister);
 __ CmpObjectType(kInterpreterBytecodeArrayRegister, BYTECODE_ARRAY_TYPE,
 rbx);
 __ Assert(
 equal,
 AbortReason::kFunctionDataShouldBeBytecodeArrayOnInterpreterEntry);
 }
 // Get the target bytecode offset from the frame.
 __ movq(kInterpreterBytecodeOffsetRegister,
 Operand(rbp, InterpreterFrameConstants::kBytecodeOffsetFromFp));
 __ SmiUntag(kInterpreterBytecodeOffsetRegister,
 kInterpreterBytecodeOffsetRegister);
 // Dispatch to the target bytecode.
 __ movzxbq(r11, Operand(kInterpreterBytecodeArrayRegister,
 kInterpreterBytecodeOffsetRegister, times_1, 0));
 __ movq(kJavaScriptCallCodeStartRegister,
 Operand(kInterpreterDispatchTableRegister, r11,
 times_system_pointer_size, 0));
 __ jmp(kJavaScriptCallCodeStartRegister);
 }
 //================================separation=========================
 void Builtins::Generate_InterpreterEnterBytecodeDispatch(MacroAssembler * masm) {
 Generate_InterpreterEnterBytecode(masm);
 } In the above code, the is the entry point of bytecode dispatch, and the is the key code that implements the bytecode dispatch. Here are two important concepts: Generate_InterpreterEnterBytecodeDispatch Generate_InterpreterEnterBytecode The is a Builtin and its index is 65. (The index may be dissimilar in different V8 versions) Generate_InterpreterEnterBytecodeDispatch V8 uses a physical register to manage the dispatch table, the name of the register is . Using the physical register can avoid the push and pop of the dispatch table frequently, to improve efficiency. kInterpreterDispatchTableRegister Here are the key lines of code： Line 35, loads the dispatch table to the A register. Line 37 of code, take out the table address from the isolate. The implementation of A is in the below three functions. (1) ExternalReference ExternalReference::interpreter_dispatch_table_address(
 Isolate * isolate) {
 return ExternalReference(isolate -> interpreter() -> dispatch_table_address());
}
interpreter::Interpreter * interpreter() const {
 return interpreter_;
}
Address dispatch_table_address() {
 return reinterpret_cast < Address > ( & dispatch_table_[0]);
} Line 39 takes out the bytecode array from the stack. (2) Line 51 takes out the offset of the target bytecode from the bytecode array. (3) Lines 56 and 58 calculate the target bytecode address and store the address in kJavaScriptCallCodeStartRegister. (4) Line 61 jumps to register kJavaScriptCallCodeStartRegister and executes bytecode. Figure 1 is the call stack. (5) 2. TailCall The Dispatch() is the last step in a bytecode, so its alias is the tail call. Let’s look at a few bytecodes： IGNITION_HANDLER(StaGlobal, InterpreterAssembler) {
 TNode < Context > context = GetContext();
 //omit..............
 Goto( & end);
 Bind( & no_feedback);
 CallRuntime(Runtime::kStoreGlobalICNoFeedback_Miss, context, value, name);
 Goto( & end);
 Bind( & end);
 Dispatch(); // !!! this is the tail call.
 }
 IGNITION_HANDLER(LdaContextSlot, InterpreterAssembler) {
 TNode < Context > context = CAST(LoadRegisterAtOperandIndex(0));
 TNode < IntPtrT > slot_index = Signed(BytecodeOperandIdx(1));
 TNode < Uint32T > depth = BytecodeOperandUImm(2);
 TNode < Context > slot_context = GetContextAtDepth(context, depth);
 TNode < Object > result = LoadContextElement(slot_context, slot_index);
 SetAccumulator(result);
 Dispatch(); //!!! here also is.
 }
 IGNITION_HANDLER(LdaImmutableContextSlot, InterpreterAssembler) {
 TNode < Context > context = CAST(LoadRegisterAtOperandIndex(0));
 TNode < IntPtrT > slot_index = Signed(BytecodeOperandIdx(1));
 TNode < Uint32T > depth = BytecodeOperandUImm(2);
 TNode < Context > slot_context = GetContextAtDepth(context, depth);
 TNode < Object > result = LoadContextElement(slot_context, slot_index);
 SetAccumulator(result);
 Dispatch(); //!!! here 
 } The above three bytecodes all end with Dispatch(). Below is the code of Dispatch: void InterpreterAssembler::Dispatch() {
 Comment("========= Dispatch");
 DCHECK_IMPLIES(Bytecodes::MakesCallAlongCriticalPath(bytecode_), made_call_);
 TNode < IntPtrT > target_offset = Advance();
 TNode < WordT > target_bytecode = LoadBytecode(target_offset);
 if (Bytecodes::IsStarLookahead(bytecode_, operand_scale_)) {
 target_bytecode = StarDispatchLookahead(target_bytecode);
 }
 DispatchToBytecode(target_bytecode, BytecodeOffset());
 } The 2nd line is the comment function. When debugging, we can use its output information to locate the execution position. The 4th line takes out the offset of the target(next) bytecode. The 5th line loads the target bytecode. The 9th line calls which calls eventually. DspatchToBytecode() DispatchToBytecodeHandlerEntry() void InterpreterAssembler::DispatchToBytecodeHandlerEntry(
 TNode < RawPtrT > handler_entry, TNode < IntPtrT > bytecode_offset) {
 // Propagate speculation poisoning.
 TNode < RawPtrT > poisoned_handler_entry =
 UncheckedCast < RawPtrT > (WordPoisonOnSpeculation(handler_entry));
 TailCallBytecodeDispatch(InterpreterDispatchDescriptor {},
 poisoned_handler_entry, GetAccumulatorUnchecked(),
 bytecode_offset, BytecodeArrayTaggedPointer(),
 DispatchTablePointer());
} In , parameter 1 is the target bytecode and 2 is the offset of the bytecode. Parameter 1 is used to load the bytecode handler and 2 is used to load operands. Then call , which is below: DispatchToBytecodeHandlerEntry TailCallBytecodeDispatch template < class...TArgs >
 void CodeAssembler::TailCallBytecodeDispatch(
 const CallInterfaceDescriptor & descriptor, TNode < RawPtrT > target,
 TArgs...args) {
 DCHECK_EQ(descriptor.GetParameterCount(), sizeof...(args));
 auto call_descriptor = Linkage::GetBytecodeDispatchCallDescriptor(
 zone(), descriptor, descriptor.GetStackParameterCount());
 Node * nodes[] = {
 target,
 args...
 };
 CHECK_EQ(descriptor.GetParameterCount() + 1, arraysize(nodes));
 raw_assembler() -> TailCallN(call_descriptor, arraysize(nodes), nodes);
 } In the above code, the 5th line creates the descriptor, as below: CallDescriptor * Linkage::GetBytecodeDispatchCallDescriptor(
 Zone * zone,
 const CallInterfaceDescriptor & descriptor,
 int stack_parameter_count) {
 const int register_parameter_count = descriptor.GetRegisterParameterCount();
 const int parameter_count = register_parameter_count + stack_parameter_count;
 DCHECK_EQ(descriptor.GetReturnCount(), 1);
 LocationSignature::Builder locations(zone, 1, parameter_count);
 locations.AddReturn(regloc(kReturnRegister0, descriptor.GetReturnType(0)));
 for (int i = 0; i < parameter_count; i++) {
 if (i < register_parameter_count) {
 // The first parameters go in registers.
 Register reg = descriptor.GetRegisterParameter(i);
 MachineType type = descriptor.GetParameterType(i);
 locations.AddParam(regloc(reg, type));
 } else {
 int stack_slot = i - register_parameter_count - stack_parameter_count;
 locations.AddParam(LinkageLocation::ForCallerFrameSlot(
 stack_slot, MachineType::AnyTagged()));
 }
 }
 MachineType target_type = MachineType::Pointer();
 LinkageLocation target_loc = LinkageLocation::ForAnyRegister(target_type);
 const CallDescriptor::Flags kFlags =
 CallDescriptor::kCanUseRoots | CallDescriptor::kFixedTargetRegister;
 return new(zone) CallDescriptor( // --
 CallDescriptor::kCallAddress, // kind
 target_type, // target MachineType
 target_loc, // target location
 locations.Build(), // location_sig
 stack_parameter_count, // stack_parameter_count
 Operator::kNoProperties, // properties
 kNoCalleeSaved, // callee-saved registers
 kNoCalleeSaved, // callee-saved fp
 kFlags, // flags
 descriptor.DebugName());
 } In , parameter 2 is the target bytecode, and parameter 3 is the stack parameter count. This function is used to apply for register resources and create a . The gives what parameters to supply when executing a bytecode. The comments on lines 24 to 25 give its layout. GetBytecodeDispatchCallDescriptor CallDescriptor CallDescriptor In , the on the 9th line is below, we see that it’s parameter 1 is . TailCallBytecodeDispatch TailCallN() CallDescriptor void RawMachineAssembler::TailCallN(CallDescriptor * call_descriptor,
 int input_count, Node *
 const * inputs) {
 // +1 is for target.
 DCHECK_EQ(input_count, call_descriptor -> ParameterCount() + 1);
 Node * tail_call =
 MakeNode(common() -> TailCall(call_descriptor), input_count, inputs);
 schedule() -> AddTailCall(CurrentBlock(), tail_call);
 current_block_ = nullptr;
 } The 5th line generates a node. In the 7th line adds the node to the end of the current basic block. So far, the dispatch is completed and the next bytecode is started to execute. Figure 2 shows the function call stack. AddTailCall() Okay, that wraps it up for this share. I’ll see you guys next time, take care! Please reach out to me if you have any issues. : qq9123013 : v8blink@outlook.com WeChat Email Also published . here

Let's Understand Chrome V8 — Chapter 11: Bytecode Dispatch 

Sometimes we need to make multiple asynchronous requests and get the result when all requests have finished. In this post, I’ll show how to do this in three ways in Swift: with DispatchGroup with RxSwift with Combine I think in a real situation you must think twice before making multiple requests like in this example. Because it can consume more energy, drain the battery faster, and it is better overall if we can make it with a single request. Let’s say we have a simple method that takes a movie ID and gives a movie object: And let’s say we have a list of movie IDs and we want to get a list of movie objects of these IDs. We can call the method for given IDs in parallel and get notified when we got all of the responses using the : getMovie DispatchGroup Here we used the method to let the know a new block entered the group. When we got the response we have to call a method, and when all entered blocks leave the group we will be notified. group.enter() DispatchGroup group.leave() In the example below, If we've made requests one after another, the total time would be more than six seconds. But we were notified in less than two seconds because the movies loaded in parallel: Let’s see how can we do it using RxSwift: We can also achieve this using the Combine: I’ve created a simple project with all three methods. The source code is available here on . GitHub

Concurrent Requests in Swift Using DispatchGroup, RxSwift and Combine

Micah Rosenbloom , Managing Partner is one of the most interesting people in tech. Scott Belsky As a founder of , he built the preeminent creative community for designers on the web, turned into a that made a dozen people on his team millionaires in just seven years. He could have raised money for another startup at any valuation he wanted. Behance $6.5M of VC $150M exit He was just getting started. As an , he was the first check into companies like Uber, Pinterest and Warby Parker. He became a Venture Partner at , easily one of the . He could have remained a full-time investor. Instead, he missed “building teams and products for creative people” and returned to Adobe to take an at the 36-year old tools company. angel investor Benchmark top three funds of the last 15 years executive role In a world where founders want to be famous, and get rich quick, Scott has charted an atypical path and that makes his perspective incredibly valuable, as the founders he’s advised can attest. Fortunately for those without direct access, he’s written a book, , laying out some of his advice. It’s an important book. As he recently said at an event I hosted with him, so many business books and anecdotes amount to “I won the lottery. Go play my numbers” (a quote he shared in his book from entrepreneur Andrew Wilkinson). This book does the opposite and shines a bright light on the unenjoyable, but necessary parts of the process. The Messy Middle I hope this messy middle of takeaways will convince you to read it. Funding shouldn’t be celebrated, it should make your nervous Scott has backed many of the most-forward thinking startups of the last few years, but the tenor of the advice given in the book is strikingly old-school. In 378 pages, I don’t think Scott shares a single “hack” to help companies raise funding. In fact, he’s fond of lines like, “For strong companies fundraising is a tactic, for weak companies, it’s a goal.” He’s not promoting bootstrapping by any means, but there is a persistent thread through the book urging founders not to try to paper over problems, with short-term solutions, or money. The book is very much about building, not banking. The best startups are stay-ups Another bit of vintage advice that pervades the book is about the power of perseverance. “You can get the big things right and not succeed because you don’t endure long enough,” is a great line that all founders should internalize. We’ve all become so used to stories of outlier startups getting traction rapidly, that we forget about the much more common success mode of an “overnight success story a decade in the making.” Patience is a virtue, and vitally important to the success of startups. Resources become depleted, resourcefulness does not Scott bootstrapped Behance for half a decade and didn’t have the luxury of adding new head count to solve problems. Instead, one of his execs came up with a simple maxim to be deployed when a new request for employees was made — “Refactor, refactor, hire.” Basically, figure out what processes and tools could be improved, added, or removed to solve the same problem as a new FTE. Only after going through this process twice does it make sense to bring on new staff. Good founders hack laziness “I’ve long believed that biologically and psychologically we are geared towards a very short-term reward system from birth. Think about the average lifespan used to be 26 years old, back in the 1700s. The idea of spending five to 10 years of your life building something was not only unfathomable, it was just not smart,” says Scott, who believes we need to build systems to hack our natural responses. , a professor at Harvard Business School, confirms that and has demonstrated that progress is the best motivator for future progress. Teresa Amabile Scott believes you have to help your team understand that they’re making progress to make more progress. This can come in any number of forms, including office space, like a “Done” wall, a space in the office that highlights finished projects to give tangible form to the company’s momentum. is full of big picture theoretical frameworks, but also makes quick diagnoses of some modern startup pathologies, like “Insecurity Work,” which Scott defines as tasks that have: The Messy Middle No intended outcome That don’t move the ball forward And are quick enough that you can do it multiple times per day Email is a good proxy for most people, but it could be anything from micromanaging a calendar to obsessing over less salient stats. His advice is to embrace these tics, but to time box them to a short period once a day. Over optimization is dangerous In a world where productivity gurus tout the benefit of virtual assistants and tools to screen you from time sucks, Scott sells the benefits of serendipity. For instance, Scott met Pinterest co-founder Ben Silbermann through a semi-warm introduction from one of his employees before the photo sharing startup had any traction. Many would have advised him to avoid such a low-probability intro, but it’s quite possibly one of the most profitable meetings that has ever occured! As Scott writes, don’t “optimize the art out of your business,” and “the greatest businesses start more art than science, and then they adopt science.” Product market fit is a journey, not a destination. Scott dedicates nearly half of the book to the art of product design. He has crafted dozens of lines that will stick with you long after finishing the book. Some of my favorites are: Product market fit is a journey, not a destination Don’t search for better answers, ask different questions Passion doesn’t make up for lack of demand Build your narrative before your product If a picture is worth a thousand words, a mockup answers a thousand questions Optimize the first 30 seconds for lazy, vanity, and selfishness Simple is sticky Products either help you save time or spend time If we take the easy option, how long will it take for our competitors to catch up? Be curious about competitors, but don’t emulate them Improving the first mile had more impact than any new feature When something works, focus on what makes it work, rather than rough edges I can’t do justice to the meaning behind each one, but I hope this quick overview convinces you to , or give the a listen. buy the book audio edition

Dispatches from the Messy Middle

At the risk of oversimplifying, it seems like everywhere crypto goes, it ends up disrupting something. Which isn’t a bad thing. Traditional industries that have become bloated, sloppy versions of themselves could use a quick splash of water to the face. But it’s important to keep in mind that while worry about the volatility that this disruption brings, that the disruption itself occurs because industries aren’t serving the interests of their users as well as ‘Crypto Company X’ can. Wall Street investors Whether it’s pleasant or not, disruption usually yields growth. Which why it’s so exciting to see a crypto company that’s gearing up to enable one of the biggest disruptions this year. The World of Dispatch Labs So, what’s the Platform about? Well, with blockchain going mainstream, Dispatch Labs has decided to build the right architecture to make sure blockchain is business-ready. Dispatch The most interesting thing about Dispatch is that disruption isn’t some inevitable side effect of their platform. Dispatch created a platform specifically for disrupting a host of industries. How did they do this? Well, by enabling the development of secure, decentralized peer-to-peer applications on a massive scale, they’re able to capitalize on a massive industry-wide opportunity. But before we get to that, let’s take a step back and really try to understand what Dispatch is all about. At its core, Dispatch was designed to be the first blockchain protocol to leverage on-chain smart contracts to manage distributed storage of application data off-chain. Those smart contracts then “program” (for lack of a better word) how the data can be accessed, linked and governed, like your typical SaaS-based centralized architecture. Here’s where things get interesting. Because of its design, Dispatch actually enables business applications to without having to worry about sacrificing speed or functionality. And by moving to the distributed architecture of blockchain, these same business applications become infinitely less vulnerable to hacking and . easily migrate to blockchain security breaches That’s right, the massive opportunity is the chance to protect business applications from their centralized ways. Make no mistake, being centralized is the reason business applications are so susceptible to security breaches, downtime and those pesky hosting costs that seem to be ever-growing. Alright, so the distributed nature of blockchain provides a natural defense for these business applications. Great, but the reality of current blockchain protocols is that they lack both the functionality and the scalability to handle the most important aspect of modern business applications — the data. But Dispatch’s solution to this problem is actually pretty ingenious. The Dispatch protocol extends the functionality of blockchain by integrating the management and distribution of off-chain artifacts, or programmable data on the private Dispatch Artifact Network (DAN for short). The Dispatch blockchain is itself a shared ledger, growing linearly while the data managed by the chain can continue to grow exponentially. Dispatch enables the decentralized management of data storage as well, allowing for Dapps that build and run operations on the access, manipulation and distribution of that data. Of course, at this point, some of you reading might be skeptical. “Okay, that sounds pretty good, but how do they manage to have that level of stability while maintaining efficiency?” Well, Dispatch anticipated the potential for some transaction speed and size scalability issues, which is why they’ve implemented a variety of existing and new protocols. Dispatch actually uses Delegated Proof of Stake (DPoS) to establish a consensus, and uses the Dispatch Virtual Machine (DVM) to allow for the creation and execution of stateful programs using the blockchain’s shared state. The DVM allows for the executing of the smart-contracts to handle artifact operations, and lets build apps that require the storage of data, as well as the running of operations on that data. That data is then stored within the DAN, which ensures node data management. Dapp developers So where does this leave Dispatch as a platform? They’re a fundamental evolution in the way blockchain technologies function, as well as a testament to what those blockchain technologies are capable of. Dispatch’s architecture facilitates many use cases that are simply not possible with existing blockchains. Think of the possibilities. Content Delivery Networks, streaming services, peer-to-peer marketplaces…the list goes on and on. As a decentralized network where Dapp developers and individuals can sell, distribute or store files, content, data, and information, it’s easy to see why Dispatch look like it’ll be the framework for future data intensive computational applications. First you have to consider how impactful it will be when hundreds of business applications end up storing their data using Dispatch. The shift is inevitable, simply by virtue of it being so much safer than a centralized security system. That vulnerability is Dispatch’s opportunity for some massive disruption. Not only has Dispatch been able to offer the benefits of blockchain, they’ve actually managed to facilitate the process to such a degree that businesses would be foolish not to protect their data using Dispatch. What new ways would you like to see blockchain’s utility expanded? Disclosure: The author has had a working or personal relationship with one or more companies mentioned in this article in the past. Access to mentioned company’s management and information was made through the author’s personal network. All information was vetted prior to posting. Disclaimer: This essay is not intended to be a source of investment, financial, technical, tax, or legal advice. All of this content is for informational purposes only.

Why Dispatch Labs Could Enable The Biggest Disruptions In Crypto For 2018

In the code base I work on, we are doing an evil thing. Something that shouldn’t be done. We are making dispatch calls in such as componentWillReceiveProps, componentWillUpdate, and componentDidUpdate. React lifecycle methods Here is one such scenario. We have two different components that are accessing two different pieces of state. class Address extends React.Component {render() {return <input value={this.props.address} onChange={this.props.changeAddress}/>;}} function mapStateToProps(state) {return {address: state.address}} function mapDispatchToProps(dispatch) {return {changeAddress: (address) => dispatch(changeAddress(address)),}} connect(mapStateToProps, mapDispatchToProps)(Address); class Zipcode extends React.Component {render() {return <input value={this.props.zipcode} onChange={this.props.changeZipcode}/>;}} function mapStateToProps(state) {return {zipcode: state.zipcode}} function mapDispatchToProps(dispatch) {return {changeZipcode: (zipcode) => dispatch(changeZipcode(zipcode)),}} connect(mapStateToProps, mapDispatchToProps)(Zipcode); Now suppose we want to add an alert to the address component if the user enters an address that doesn’t appear to be in the zip code they enter. We’re going to store this alert data in the redux state. There are many ways we could do that. But the solution would need to check the address when either (1) the address changed or (2) the zip code changed. Our application uses redux-saga, so these solutions are from that perspective. I am also assuming we would need to make some call to do the actual checking. Thus we are going to need to do this work in some async middleware. network Solution 1 We dispatch another action when changeZipcode or changeAddress is called. For instance, the mapDispatchToProps function of the Zipcode component would change to: function mapDispatchToProps(dispatch) {return {changeZipcode: (zipcode) => {dispatch(changeZipcode(zipcode));dispatch(checkAddress());}}} Then we have a saga waiting for the checkAddress action to do the actual check of the address against the zipcode and update some state for us to render in the Address component. I don’t like this solution very much because both changeZipcode and changeAddress would need this exact same logic. Solution 2 Maybe we just have a saga waiting for changeZipcode or changeAddress actions and do the check when those happen. Now we don’t need a checkAddress action. Solution NEVER DO THIS Well here is how we do it. Zipcode would not change at all. Instead we add a on Address that checks whether address or zipcode changed. If so, dispatch another action to check the address. componentWillReceiveProps class Address extends React.Component {componentWillReceiveProps(nextProps) {if (this.props.zipcode !== nextProps.zipCode || this.props.address !== nextProps.address) {this.props.checkAddress();}} render() {return (<div>{this.props.addressAlert}<input value={this.props.address} onChange={this.props.changeAddress}/>;</div>);}} function mapStateToProps(state) {return {address: state.address,addressAlert: state.addressAlert,zipcode: state.zipcode,}} function mapDispatchToProps(dispatch) {return {changeAddress: (address) => dispatch(changeAddress(address)),checkAddress: () => dispatch(checkAddress()),}} connect(mapStateToProps, mapDispatchToProps)(Address); I felt a chill when I first saw this. I looked up and asked why many times. It felt so wrong. . Why does Address care about zipcode again?? It makes the component know way more than it should This might not seem so bad. In fact, you may be saying it’s perfectly fine. Address cares about zipcode because it needs to update an address alert when zipcode changes. But here’s the thing. Your components should not be thinking about external state transitions. That concern is in the land of and only there. redux Potential problems To illustrate my point a bit more here are some potential problems. For instance, you may have a very hot piece of state that when changed, a lot of your application needs to change. You would need to add that piece of state to every component that cares about it and then write that componentWillReceiveProps check. How do you keep two components from dispatching the same action when they see that piece of state change? Or even worse, you can have a cascade of renders. Component A does first dispatch Component B watches for change of state from dispatch in Component A and does second dispatch Component C watches for change of state from dispatch in Component B and does third dispatch And so on and so on. Your application can go through these multi step transformations, but it’s really difficult to trace back that first action that kicked off the whole transformation. One last thing. I’m not saying these updating lifecycle methods are bad. You absolutely need them for when your component has its own internal state. Or when you need to do some imperative DOM work when interfacing with a non react library. But they should be for kicking off other changes to your redux state in response to other redux events. never In conclusion, make your components as simple as possible. The best component is simply a function of it’s props. And if you ever see a dispatch call in updating lifecycle methods like componentWillReceiveProps, componentWillUpdate, and componentDidUpdate there is most definitely a better way.

Evil things you do with redux — dispatch in updating lifecycle methods

Since I’ve mentioned it in the title, I guess you are familiar with **Redux.**But did you know that this kind of architecture has been used in software development for more than twelve years now? Actually, the idea itself is even older, but it was not until 2005 when Martin Fowler defined it as . “event sourcing” Even though it’s not identical, Redux shares a lot of similarities with this model and I think there is still more we can learn from it. In this post, I’ll describe the problem I faced and how it could’ve been avoided if I used event sourcing principles. Using actions as events In short, what I’m suggesting is using (facts describing what had happened) which describes an intent of what should happen in the future. actions as events rather than commands I’m not the first person to suggest this or the first one that compared Redux with event sourcing. Here are just a few resources describing similar ideas: Naming actions in past tense Is redux conflating actions with events? Redux and it’s relation to CQRS (and other things) Why do we need middleware for async flow in Redux? Undo/Redo For more then three years I’ve worked as a lead frontend developer on a . browser-based code editor Like any other editor it has a lot of features which can be used in different ways. One example is: “undo/redo”. Obviously, for this feature, the editor has to support and shortcuts, but there are many ways to invoke the same action: Cmd+Z Cmd+Y Shortcuts ( , ) Cmd+Z Cmd+Y Main Menu ( ) Edit -> Undo, Edit -> Redo Toolbar ( ) Undo/Redo icon GoTo Anything ( ) “undo”, “redo” typed command So, I did what most of us would probably do:Every time “undo/redo function” is requested, a component would dispatch an “ ” or “REDO” type action. UNDO And this worked just fine. But after a year or so, the company asked me if I could provide analytics on how our app is used. What actions are used in a toolbar, how does this relate to shortcuts etc? Well, when you are working on a large scale app, these kind of tasks (which usually affect multiple teams) are probably not the most desirable ones. Especially, when you don’t know much about event-driven architectures… So, let’s just say I made some wrong decisions. Event sourcing What exactly can we learn from event sourced systems? As the term “event sourcing” suggests — use events as your source of truth. Rather than using a command “UNDO”, we can describe what actually happened: “UNDO_SHORTCUT_INVOKED”“UNDO_MAIN_MENU_ITEM_CLICKED”“UNDO_TOOLBAR_ICON_CLICKED”“UNDO_GOTO_ANYTHING_INVOKED” If you don’t want to bloat your (or some other developer’s) reducers, you can also transform these actions in something with more generic type: <a href="https://medium.com/media/723e40459d2d52eccc31bf6503b5a5c4/href">https://medium.com/media/723e40459d2d52eccc31bf6503b5a5c4/href</a> And we’re back where we started. But now if your CEO wants you to generate analytics, you can do something like this: <a href="https://medium.com/media/e414a482528b8410b8ab64ef195ca3e7/href">https://medium.com/media/e414a482528b8410b8ab64ef195ca3e7/href</a> What is a process manager? This term is borrowed from where the same concept is also referred as “saga”: CQRS/ES terminology a piece of code that coordinates and routes messages between and . bounded contexts aggregates Redux middleware I used in these examples is one that I built myself — . redux-orchestrate But you can also use more popular options like or . redux-saga redux-observable Cons Everything has its trade-offs, so here are some disadvantages you should consider: Transforming actions requires middleware which has its own complexity Dispatching more granular actions results in more messages that need to be handled Event -> Process Manager -> Command concept may not apply to every use-case. It’s not a silver bullet solution and you should use it where it makes sense to you. Conclusion By using commands you are predicting the future.This is problematic because you never know how your app will grow, how many people will work on it and what features should be implemented in the future. By using events you are describing the past — facts which are always true and which can be used in ways you currently can’t imagine. Events can be coordinated by a process manager which can handle side-effects and transform actions before they hit the reducer.

Stories, News & Mentions about DISPATCH

Dispatch’s Stories on HackerNoon

Dispatch's News & Mentions