Download full source code.
I sometimes have scenarios where I launch multiple tasks, each using a different method. When they complete, I want to know the returned value, and which method returned the value.
By default, the launched tasks get Id
s in the form of an int
. However, the method name is not easily accessible.
The Task
does contain the method name, buried inside a messy string. The string is different depending on whether the method is local to where you launched the task, or if it is in another class.
In the following code, I launch three tasks, one uses a local method, and two are methods in another class.
Worker worker = new Worker();
var tasks = new Task<int>[]
{
DoSomeLocalWork(1000),
worker.DoSomeWork(2000),
worker.DoSomeOtherWork(3000),
};
Here is an extension method that gets the method name for the two variations of Task.ToString()
-
1public static class TaskExtensions
2{
3 public static string MethodName(this Task task)
4 {
5 string taskName;
6 string taskNameFull = task.ToString();
7
8 if(taskNameFull.Contains("<<<Main>"))
9 {
10 int start = taskNameFull.IndexOf("__") + 2;
11 int end = taskNameFull.IndexOf("|");
12 int length = end - start;
13 taskName = taskNameFull.Substring(start, length);
14 }
15 else
16 {
17 int start = taskNameFull.IndexOf(",") +1;
18 int end = taskNameFull.IndexOf(">", start);
19 int length = end - start;
20 taskName = taskNameFull.Substring(start, length);
21 taskName = taskName.Replace("+<", ".");
22 }
23
24 return taskName;
25 }
26}
Usage of the extension method is very easy, just call task.MethodName()
-
foreach (var task in tasks)
{
try
{
Console.WriteLine($"{task.MethodName()}. Id {task.Id}, result {await task}, status {task.Status}");
}
catch(OperationCanceledException ex)
{
Console.WriteLine($"{task.MethodName()}. Id {task.Id}, status {task.Status}, {ex.Message}");
}
}
The code is not meant to be efficient, it is to demonstrate the steps needed.
Download full source code.
We had our first in-person rehearsal for the Cloud Next ’24 developer keynote, and my stress level dropped a little bit. It feels good to be close to the finish line, and we have such a great team involved in it. Heading home now, and snuck in a bit of reading throughout the day.
[blog] The Future of Frontend is Already Here. This might be the best thing I read this week so far. Kate does an excellent job explaining the frontend landscape, and gave me a half dozen projects or companies I need to look at.
[blog] Why We Built a Write Back Cache for Our Asset Library with Google Cloud Spanner. The team at Squarespace wanted to improve some user and dev experiences, and wrote up an explanation of why (and how) they built a cache.
[blog] From whoami to whoarewe with GKE Workload Identity for Fleets. I like the ability to do identify federation across a set of Kubernetes clusters. Here’s more on how it works.
[blog] Analyzing the next token probabilities in large language models. How does an LLM pick the next word in a sentence? Read this for additional understanding.
[article] How to Get Tech-Debt on the Roadmap. I thought this was a very good perspective on how to frame and prioritize work on technical debt.
[article] Tutorial: Using LangChain and Gemini to Summarize Articles. Jani put together a straightforward demo for you to see how you might use the popular LangChain framework to work with an LLM.
[blog] Listen hear: How designers create sounds for Pixel. We’re surrounded by things that involved thoughtful design, yet we may barely notice! One of those could be sounds on our phones.
[blog] Achieving Greatness Without Falling Apart. Elite performers are often very competitive, but also grounded in a way that the quest can be as fulfilling as the “win.”
[blog] Practical Tutorial to Retrieval Augmented Generation on Google Colab. Good demo that anyone can follow along with to try out RAG with Anthropic models.
##
Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:
We are excited to highlight new learning content released focused on Semantic Kernel.
.NET Conf Student Zone – Explore AI
On the .NET Conf Student Zone you can learn in a beginner-friendly virtual event where you’ll learn how to build projects using C# and .NET. In the Explore AI dedicated section, shown below, you can learn about AI, how to get started, and using GPT models to improve text completions with Semantic Kernel.
Who Needs Semantic Kernel? – Join Semantic Kernel expert, John Maeda VP of Design and Ai as he introduces Blake – the app developer who came back from December holidays in 2023 to a boss suddenly wanting AI in their App ASAP.
Semantic Kernel for Beginners – Get introduced to Semantic Kernel for developers, covering essential components such as the kernel SDK, planners, memories and connectors. Learn through examples and applications.
APL-2005 Learning Path: Developing AI Agents using Azure OpenAI and the Semantic Kernel SDK
Microsoft Learn released a new learning path called APL-2005 Develop AI agents using Azure OpenAI and the Semantic Kernel SDK – Training | Microsoft Learn. This learning path is focused on how to use the Semantic Kernel SDK to build intelligent applications that automate tasks and perform natural language processing.
Some suggested Prerequisites are:
There are five key Modules in the Learning Path
Summary
Please reach out if you have any questions or feedback through our Semantic Kernel GitHub Discussion Channel. We look forward to hearing from you! We would also love your support, if you’ve enjoyed using Semantic Kernel, give us a star on GitHub.
The post Learning Paths for Semantic Kernel appeared first on Semantic Kernel.
This article explains how to load documents into the React Document Viewer by selecting values from a drop-down list. The drop-down list is populated with the values that then loaded into the Document Viewer.
In this annual post, the Swift Server WorkGroup (SSWG) reflects on the community, ecosystem-wide accomplishments and the workgroup’s focus areas for the year ahead.
Since our previous update, Swift on the Server has continued to grow in many ways. Let’s start with a look at the progress made in 2023, then look ahead and next steps for 2024.
For the first time ever, the SSWG ran a developer community survey aimed at collecting feedback and information about the shape and breadth of the Swift server ecosystem. We received a great response, and we’d like to thank everyone who participated!
We’ve analyzed the responses to help direct the workgroup’s efforts, as well as provide visibility into how the ecosystem is doing. For example, while the majority of respondents already use Swift Concurrency, there remain challenges in some areas with adoption.
We also learned that there is a lot of interest in standardized tooling such as swift-format
and sourcekit-lsp
, and interest in building out support for various IDEs.
You can read the full SSWG Community Survey 2024 Report over on the Swift forums.
The SSWG has continued to focus on growing the ecosystem by incubating packages and providing guidance to package authors. We’ve seen a lot of new, in-development, and improved packages in the last year.
By participating in the Google Summer of Code, we were able to provide swift-memcache-gsoc, which makes it easier to communicate with Memcached servers. The wire protocol and higher-level connection APIs are done, with connection pools and key sharding on the roadmap.
We’ve seen a lot of progress on the adoption of Structured Concurrency. Most new libraries are adopting it, and we’re working on a guide to help existing libraries adopt it as well.
Two big drivers of Structured Concurrency in the ecosystem have been SwiftNIO’s introduction of NIOAsyncChannel
and the ServiceGroup
in the rewritten ServiceLifecycle package. Together they are foundational pieces for higher-level libraries like Hummingbird and gRPC to build logic using Structured Concurrency.
Tooling has seen some tremendous improvements in 2023 with the introduction of Swiftly, Dependabot for Swift, and Chiseled Containers.
In addition, thanks to the introduction of Package Plugins, we’ve seen the OpenAPI Generator make an entry. This plugin allows you to generate Swift boilerplate code from an OpenAPI specification. This is a great way to build both HTTP clients and servers.
Since our update post of 2023, Sven A. Schmidt has joined the workgroup. Sven has already been involved with the documentation workgroup and is known for his work on the Swift Package Index.
Last year, we saw seven new packages enter the SSWG incubation process. A tremendous amount of work has been done on these packages, showing how rapidly the ecosystem is expanding:
In addition, MongoKitten was pitched and approved at the start of 2024. MongoKitten is a popular MongoDB driver for Swift.
In preparation for Swift 6, we’ll be looking at the impact of strict concurrency checking across the server ecosystem. We are planning to enable strict checking on every incubated package and make each package compile warning-free under the strict checking rules.
Adoption of Structured Concurrency has been going strong but the journey isn’t finished. In the coming year, we’ll be focusing on adopting Structured Concurrency in even more libraries, with the goal of making SwiftNIO an implementation detail of more and more libraries.
In addition to working on libraries, we are also planning work on more guides for developers of libraries and applications, describing how to adopt Structured Concurrency and the benefits it brings.
In 2023, we’ve extensively prepared for a standardized HTTP server and middleware. The in-progress, Hummingbird rewrite is already taking advantage of the new HTTP types. The goal for 2024 is to produce a low-level, general-purpose HTTP server package.
Marketing Swift on the Server is a big focus area for 2024. With the introduction of the redesigned navigation of the Swift.org website, we’ll be better able to showcase Swift on the Server.
We’re looking to create more content for the ecosystem, such as integrated example projects and showcases of existing server-focused projects.
In addition, we’re looking to connect developers by organizing online user group meetings. We’re currently planning the first Swift Server User Group meeting, with a goal of 3-4 meetings per year.
Finally, we’re excited to see the return of the ServerSide.swift conference in 2024, hosted in London.