NExTNet

nextnet

Hey Hackers, has been nominated in HackerNoon's annual Startup of the Year awards in San Francisco, USA. NExTNet Inc. Please vote for us . here Read more about us below to understand why we deserve your vote. Are you also participating in SOTY 2023? If so, click here to fill out this interview. Meet NExTNet Inc. is a Venture-backed Silicon Valley-based Enterprise software startup developing Generative AI technologies for mission-critical applications in biotech and pharma. Our mission is to organize and integrate the world's biomedical knowledge and make it accessible. Imagine NExTNet = Oracle x Palantir. Meet our team . NExTNet here My Role In late 2017, I founded a fast-growing biotechnology platform company developing ground-breaking silicon chip technologies to accelerate the development of personalized medicine. Imagine Nvidia for biotech. I founded in late 2020 frustrated by the extremely high technical barrier to accessing the scattered knowledge buried within mountains of multi-modal and disparate biomedical data and information. Our goal is to democratize access to the world's biomedical knowledge to accelerate drug discovery and development. There are more than 23,500 diseases known to mankind, of which ~3% have some form of cure or treatment. Mekonos, NExTNet How We're Disrupting the ‘ Industry Intersection of AI and Biomedical Roughly 95% of the world’s data have been generated in the last 5-10 years. The emergence of high-resolution, multi-modal biomedical data (10s of millions of scientific publications, patents, grants, sequencing data, gene and protein expression, drug compounds, biochemical pathways, diseases, imaging, etc.) at scale has resulted in an enormous amount of human knowledge scattered across data silos. Querying all that knowledge has become remarkably complex. At NExTNet, we use our proprietary Large Language Models stack to mine for associations between scientific content in text (e.g., published literature, clinical trial record, patents) and other public and proprietary databases (gene sequencing, protein expression, diseases, pathways, pathogens, drugs, imaging...) and semantically link them into the world's fastest-growing scientific semantic web. The technical barrier to query and access such scattered knowledge is scarily high: an average researcher would need to have extensive knowledge of the command-line interface by mastering myriads of R libraries, learning a whole suite of Python packages or architecting complex queries using languages such as SQL, SPARQL, etc. NExTNet's cloud-native platform allows these researchers and scientists to ask and answer complex questions in simple natural language without having to master coding, querying languages, or arcane statistics. Our commercial and technological breakthrough is enabling scientists to identify patterns hidden deep within disparate and multi-modal datasets, ranging from scientific papers and clinical trial reports to gene sequencing and protein expression atlases -- so that they can quickly find leads buried in mountains of information via our Graphical User Interface (GUI). We are disrupting the intersection of Language and Generative Artificial Intelligence and the Biomedical industry. Standing Out from The Crowd Knowledge discovery for life sciences R&D is an embryonically developing market. The key problem in biomedicine today: Biomedical knowledge is growing at an exponential rate. As the amount of disparate data (e.g., scientific text, molecular data from sequencing, gene editing and other experiments etc.) increases, it becomes harder and harder for researchers to stay up-to-date with the state of the art. Since the technical barrier to access knowledge buried deep within all these multi-modal data silos is very challenging without the knowledge of the command-line interface, decisions are made without key insights and missed knowledge. At NExTNet, our 10x value increase over competitors is our state-of-the-art Generative AI pipeline not only reads 10s of millions of scientific text (full-length peer-reviewed publications, abstracts, patents, grants etc.) but also analyzes a massive corpus of molecular databases (genes, proteins, and pathways) and mines for hidden associations and patterns across these disparate data (public domain and proprietary). Our competitors are just limited to text mining without expanding into other modalities of data. Our Predictions/Thoughts on the Drug Discovery and Development/ Biomedical Research Industry in 2023 As a startup, we are laser-focusing on the drug discovery and development market due to the heavy $$$ being spent before any clinical trial is done in the pre-clinical phases over the course of 3-7 years at least. There is also a significant amount of VC money being invested in AI drug discovery companies (Atomwise, Insilico, Benevolent AI, Exscientia, Insitro, Recursion, etc. that have their own therapeutic pipeline). Given the significant risks associated with bringing a drug to market coupled with long development timelines (that can stretch up to a decade or even more), engaging with regulatory agencies such as the FDA, etc., and long cycle time of co-development partnerships (e.g. upfronts + milestones + royalties), we decided early on to just focus on the software development and rather enable other biotech and pharma companies developing cutting-edge therapeutics their proprietary data on top of NExTNet's semantic knowledge network --> ask and answer complex biological questions to advance their drug development efforts. A company such as Benchling has found significant success so far as an Enterprise software company. 'contextualize' To give a sense of the massive cost of drug discovery and development: 30 years ago, it took ~$300M USD to bring a drug to market v/s today it takes ~$2.4B USD (accounting for inflation). This is not because any single stage of the discovery and development process for a given molecule has gotten that much more expensive. In fact, there have been meaningful increases in productivity for a number of these stages -- so if anything the total cost of bringing a drug to market should have gotten cheaper. The real reason for such high costs in bringing a drug to market is that most of the drugs that we put in every single phase fail and the funnel has gotten progressively wider and wider narrowing down to a smaller and smaller number of drugs that make it to the next phase. This is clearly a failure of our ability to look at say characteristics (e.g., understanding molecular mechanisms of action, biological processes, etc.) at one stage and predict what's going to succeed in the next stage. This is where better predictive ML models (e.g. natural language AI) can help tremendously. In addition, diseases have traditionally been diagnosed by their symptoms and their location in the body and not by the underlying molecular mechanisms, pathways, or biological processes unique to a specific patient. Identifying targets and discovering connections with pathways early on in the disease progression helps with intervening at the causal stage rather than the symptoms. Hence a lot of the prescribed medicines don't often work on patients. What word defines the state of the ‘ Industry’ in 2023? intersection of AI and Biomedical Language AI Why we decided to participate in HackerNoon's Startup of the Year awards We got invited! :) Final Thoughts Biomedical knowledge is immense and growing quickly. The publicly available knowledge is disconnected - it is impossible to identify patterns/associations hidden deep within such disconnected knowledge. A company's internal knowledge is disconnected from it too. This presents a significant challenge for scientists in the biomedical industry because they: Miss important and potentially relevant knowledge Unable to stay up to date or keep up with new knowledge Decisions are made without the advantage of complete insights At NExTNet, we are building the best-in-class Generative/Language AI stack to enable scientists to identify patterns hidden deep within disparate and multi-modal datasets, ranging from scientific papers and clinical trial reports to gene sequencing and protein expression atlases -- so that they can quickly find leads buried in mountains of information. Start your biomedical knowledge discovery journey by signing up for free right . here is nominated as NExTNet Inc. Startup of the Year in San Francisco, USA. Vote for us today!

Generative AI & Biotech's Future - Interview with Startups of the Year Nominee, NExtNet Inc.

La IA generativa y el futuro de la biotecnología: entrevista con la nominada a Startups del año, NExtNet Inc.

L'avenir de l'IA générative et de la biotechnologie - Entretien avec le candidat de la startup de l'année, NExtNet Inc.

जेनरेटिव एआई और बायोटेक का भविष्य - वर्ष के नामांकित व्यक्ति, नेक्स्टनेट इंक. के स्टार्टअप के साथ साक्षात्कार।

ジェネレーティブ AI とバイオテクノロジーの未来 - Startups of the Year ノミネート、NExtNet Inc. へのインタビュー

IA generativa e futuro da biotecnologia - Entrevista com Startups indicadas do ano, NExtNet Inc.

Tương lai của AI & Công nghệ sinh học sáng tạo - Phỏng vấn Người được đề cử Công ty khởi nghiệp của năm, NExtNet Inc.

生成式人工智能和生物技术的未来 - 采访年度初创公司提名者 NExtNet Inc.

Every Reason You Should be Getting Started With .Net Aspire

Startups of The Year 2023 Winners: North America 

In the previous parts of this series, we've talked about , which each have their own strengths and weaknesses. But, what if we could combine the reliability of TCP with the efficiency of UDP? That's where Reliable UDP, or RUDP, comes in! TCP and UDP protocols Hello again! My name is Dmitrii Ivashchenko, Lead Software Engineer at MY.GAMES. As titled "Unity Networking Landscape 2023", we'll explore some methods to ensure dependable data transmission utilizing the (not so steady) UDP protocol. part of our ongoing series Content Overview Reliable UDP Basic RUDP Client Basic RUDP Server Implementations Wrapping Up Reliable UDP The architecture of RUDP (Reliable UDP) provides a solution that allows us to overcome the disadvantages related to the unreliability of the UDP protocol. The main disadvantages of UDP that need to be overcome are data loss, changes in their delivery order, and the possibility of errors. The goal of RUDP is to create reliable connections similar to the TCP protocol. The following methods can be used to implement RUDP: to prevent data loss, an error code can be inserted into the transmitted packet, and errors can be checked. When an error is detected, the packet can either be ignored or retransmission requested. The insertion of error correction codes can also be used, but it can lead to excessive bandwidth consumption, as the probability of error at the UDP level is usually very low. To solve the problem of data loss, we can continually retransmit undelivered packets until confirmation is received from the receiver. This method is more efficient in terms of processing complexity and resource usage than waiting for a signal of packet loss from the receiver. To ensure the sequence of data processing, the order of packet arrival can be checked, and data waiting for the undelivered packet can be temporarily saved. Then, after any lost packets have arrived, all the data is transmitted into the game. Thus, RUDP effectively controls lag. Comparison with TCP and UDP RUDP has the ability to retransmit lost packets and receive acknowledgments from the recipient. It's faster than TCP and takes advantage of UDP's guaranteed packet delivery and convenient retransmission structure. However, RUDP is not a standard protocol like UDP or TCP. It must be implemented according to its specification or use ready-made implementations (such as in the form of a software library). RUDP can be a good alternative to UDP when faster response times and high reliability are required in a game, as it guarantees the retransmission of lost packets and preserves the order of their delivery. RUDP is specifically designed to provide a normal flow of data and can be used in any type of game. It provides reliable communication by confirming the successful delivery of transmitted packets and by use of the timeout function. RUDP provides a reliable communication channel between the sender and receiver to ensure successful packet delivery. The sender and a receiver maintain a predetermined window size to avoid errors when packets are lost. When sending data over an unreliable channel using RUDP, one can expect a higher success rate in delivery. During the sending and receiving process, the "base" and "next" variables track the window size. The process is repeated continuously to check the number of packets in the buffer, and the timeout is reset after a packet is transmitted. To test the performance of RUDP, simulations of packet loss and network delay are conducted. Packets are correlated with the current system time and network delay before transmission. Basic RUDP Client This is a basic example of how you can implement RUDP in Unity using C#. The class demonstrates reliable packet transmission by attaching sequence numbers to the data packets and tracking the sequence numbers for in-order delivery. Out-of-order packets are stored and processed when the missing packets arrive. RUDPClient The method attaches the sequence number to the data and sends the packet to the server using UDP (implementation code not included). SendData The method processes the received packets, checks for in-order delivery, and handles out-of-order packets. ReceiveData using System;
using System.Collections.Generic;
using UnityEngine;

public class RUDPClient : MonoBehaviour
{
    // Variables for reliable packet transmission
    private int nextSequenceNumber = 0;
    private int expectedSequenceNumber = 0;
    private Dictionary<int, byte[]> sentPackets = new Dictionary<int, byte[]>();

    // Send data over the reliable UDP connection
    private void SendData(byte[] data)
    {
        // Attach the sequence number to the data
        byte[] packet = AttachSequenceNumber(data);

        // Send the packet to the server
        SendPacket(packet);
    }

		// Process the received data
    private void ProcessData(byte[] data)
    {
        // Process the received data here
        Debug.Log("Received data: " + System.Text.Encoding.UTF8.GetString(data));
    }

    // Send the packet to the server
    private void SendPacket(byte[] packet)
    {
        // Send the packet to the server using UDP
        // UDP implementation code goes here
    }
} Now we'll need the method. This code adds a sequential number to the transmitted data. It creates a new byte array that includes the sequential number and the transmitted information. AttachSequenceNumber Then, the packet is saved in the dictionary for tracking. Every time this method is called, the sequential number is incremented for the next packet. sentPackets // Attach the sequence number to the data
private byte[] AttachSequenceNumber(byte[] data)
{
    // Create a new byte array to hold the packet
    byte[] packet = new byte[data.Length + sizeof(int)];

    // Copy the sequence number to the packet
    BitConverter.GetBytes(nextSequenceNumber).CopyTo(packet, 0);

    // Copy the data to the packet
    data.CopyTo(packet, sizeof(int));

    // Store the packet in the sentPackets dictionary for tracking
    sentPackets[nextSequenceNumber] = packet;

    // Increment the sequence number for the next packet
    nextSequenceNumber++;

    return packet;
} To receive data from the server, we will need the method. It extracts the sequence number from the packet and checks if the packet has arrived in the correct order. If the packet arrives in the expected order, the data is extracted from the packet and processed. Then, the expected sequence number is incremented for the next packet. If a packet with a number different from the expected one arrives, it is saved for subsequent processing. ReceiveData Next, we check for the presence of packets with sequential numbers that arrived out of order. Such packets are also processed and removed from the dictionary. sentPackets // Receive data from the server
private void ReceiveData(byte[] packet)
{
    // Extract the sequence number from the packet
    int sequenceNumber = BitConverter.ToInt32(packet, 0);

    // Check if the packet is in order
    if (sequenceNumber == expectedSequenceNumber)
    {
        // Process the data from the packet
        byte[] data = new byte[packet.Length - sizeof(int)];
        Array.Copy(packet, sizeof(int), data, 0, data.Length);

        // Process the received data
        ProcessData(data);

        // Increment the expected sequence number for the next packet
        expectedSequenceNumber++;

        // Check if there are any out-of-order packets waiting
        while (sentPackets.ContainsKey(expectedSequenceNumber))
        {
            // Process the data from the out-of-order packet
            byte[] outOfOrderData = new byte[sentPackets[expectedSequenceNumber].Length - sizeof(int)];
            Array.Copy(sentPackets[expectedSequenceNumber], sizeof(int), outOfOrderData, 0, outOfOrderData.Length);

            // Process the received out-of-order data
            ProcessData(outOfOrderData);

            // Remove the processed out-of-order packet from the dictionary
            sentPackets.Remove(expectedSequenceNumber);

            // Increment the expected sequence number for the next packet
            expectedSequenceNumber++;
        }
    }
    else
    {
        // Packet is out of order, store it for later processing
        sentPackets[sequenceNumber] = packet;
    }
} Basic RUDP Server This example demonstrates the server-side implementation of RUDP in Unity using C#. The class receives data packets from the client and checks for duplicate packets. If a packet is not a duplicate, it stores it for processing and checks if there are any out-of-order packets waiting to be processed. RUDPServer using System.Collections.Generic;
using UnityEngine;

public class RUDPServer : MonoBehaviour
{
    private Dictionary<int, byte[]> receivedPackets = new Dictionary<int, byte[]>();
    private int nextSequenceNumber = 0;

    // Receive data from the client
    private void ReceiveData(byte[] packet)
    {
        // Extract the sequence number from the packet
        int sequenceNumber = BitConverter.ToInt32(packet, 0);

        // Check if the packet has already been received
        if (!receivedPackets.ContainsKey(sequenceNumber))
        {
            // Store the packet for processing
            receivedPackets[sequenceNumber] = packet;

            // Check if there are any out-of-order packets waiting
            while (receivedPackets.ContainsKey(nextSequenceNumber))
            {
                // Process the data from the out-of-order packet
                byte[] data = receivedPackets[nextSequenceNumber];

                // Process the received data
                ProcessData(data);

                // Remove the processed out-of-order packet from the dictionary
                receivedPackets.Remove(nextSequenceNumber);

                // Increment the next expected sequence number
                nextSequenceNumber++;
            }
        }

        // Send an acknowledgement packet to the client
        SendAcknowledgement(sequenceNumber);
    }

    // Process the received data
    private void ProcessData(byte[] data)
    {
        // Process the received data here
        Debug.Log("Received data: " + System.Text.Encoding.UTF8.GetString(data));
    }

    // Send an acknowledgement packet to the client
    private void SendAcknowledgement(int sequenceNumber)
    {
        // Create the acknowledgement packet
        byte[] acknowledgement = BitConverter.GetBytes(sequenceNumber);

        // Send the acknowledgement packet to the client using UDP
        // UDP implementation code goes here
    }
} The method handles the received data. The server also sends an acknowledgment packet to the client to confirm the successful receipt of a packet. ProcessData Implementations When it comes to developing your own version of RUDP, there are a lot of complexities to consider, so it's easier to use a proven third-party solution. There are several RUDP implementations available for Unity. Let's take a look. LiteNetLib LiteNetLib is a reliable lightweight library for .NET Standard 2.0 that can be used in Mono, .NET Core, and .NET Framework. It offers a range of features without overloading the processor or using a lot of memory. Data packets have a small size (only 1 byte for unreliable and 4 bytes for reliable packets). The library provides simple mechanisms for handling connections and supports peer-to-peer connections. LiteNetLib includes helper classes for sending and reading messages, supports multiple data transmission channels, and various sending mechanisms. Data transmission can be reliable considering order, reliable without considering order, reliable considering sequence (only the last packet), ordered but unreliable with duplicate prevention, and simple sending of UDP packets without considering order and reliability. Additional features include a fast packet serializer, automatic merging of small packets, automatic fragmentation of reliable packets, automatic determination of MTU, optional CRC32C checksums, NAT punching for UDP, NTP time requests, IPv6 support, packet loss, and delay simulation, and connection statistics collection. LiteNetLib supports numerous platforms, including Windows, Mac, Linux (.NET Framework, Mono, .NET Core, .NET Standard), Lumin OS (Magic Leap), Monogame, Godot, and Unity 2018.3 (Desktop platforms, Android, iOS, Switch). The library also offers support for multicast, which is useful for finding hosts in a local network. Ruffles Ruffles is a fully managed UDP library designed for high performance and low latency. One of the distinctive features of Ruffles is its connection calling system, which prevents DOS attacks and slot filling. The library manages connections, ensuring high performance without creating garbage, making it an excellent choice for performance-intensive applications. Ruffles also supports working with channels and uses multithreading by default. The library is thread-safe and has no external dependencies, making it easy to integrate into various projects. It supports both IPv4 and IPv6 in dual mode, allowing both technologies to be used together. Ruffles also has a feature for merging small packets and fragmentation, as well as merging acknowledgments, which improves data transmission efficiency. With Ruffles, you can collect connection statistics, detect MTU along the route, and track network bandwidth. Hazel Networking Hazel Networking is a low-level networking library for C# that provides connection-oriented, message-based communication over UDP and RUDP. The goal of this fork is to create a simple interface for ultra-fast UDP-based communication for games. It supports UDP and reliable RUDP, as well as packet encryption using DTLS for increased security. Hazel Networking also offers the ability to broadcast UDP for local multiplayer. The library is fully thread-safe, and all of its protocols are connection-oriented, like TCP, and message-based, like UDP. It supports both IPv4 and IPv6. In addition, Hazel Networking automatically collects statistics on data flowing in and out of connections, and is designed to be as fast and lightweight as possible. ENet-CSharp ENet-CSharp is an independent implementation of ENet with a modified protocol for C# and other languages. This implementation is characterized by its simplicity and efficiency, while consuming few resources. It supports dual a IPv4/IPv6 stack, making it versatile for use in various network conditions. Connection management is also implemented, which ensures reliability and orderliness of data transmission. Data can be transmitted through different channels, which increases communication efficiency. The benefit of this ENet implementation is that it provides data exchange reliability by implementing packet fragmentation and reassembly. This allows for efficient operation even when transmitting large amounts of data. Through aggregation, the system can combine multiple data packets into one, which increases transmission efficiency. The adaptability and portability of the implementation make it easy to integrate and use in various systems and applications. kcp2k Kcp2k is a C# implementation of KCP based on the original version of KCP in C. It is compatible with netcore and Unity, and is designed to work with Mirror Networking. KCP is a protocol that is both fast and reliable: it can reduce average delay by 30%-40%, and reduce maximum delay by three times. However, KCP requires 10%-20% more bandwidth than TCP. KCP is implemented using a pure algorithm, and it does not handle sending and receiving the underlying protocol (e.g. UDP). Therefore, users must define their own method of transmission for the base data packet and provide it to KCP as a callback. Additionally, external transmission of clocks is necessary as there are no internal system calls for this purpose. In addition to the main features, kcp2k offers additional high-level C# code for managing client and server connections, as well as an additional Unreliable channel. Unity Transport Package Unity Transport Package (UTP) is a networking library specifically created for developing multiplayer games. It functions as the core protocol for both Netcode for GameObjects and Netcode for Entities, but it can also be utilized with a custom solution. Thanks to its connection-based abstraction layer provided through UDP and WebSockets, Unity Transport supports all platforms compatible with the Unity engine. You can configure both UDP and WebSockets with or without encryption. Wrapping up In this part of the series, we took a look at ensuring dependable data transmission while using the untrustworthy UDP protocol. We now know about the most prevalent implementations and their functionalities. We discussed libraries that offer useful utilities for utilizing RUDP and incorporating it into multiplayer games. In the next article of this series, we'll talk about why connecting multiple devices located at different parts of the world is not a straightforward process, despite having a complete range of libraries and protocols available to us.

Unity Realtime Multiplayer, Part 3: Reliable UDP Protocol

Holochain Hackathons promote a sense of building, community and collaboration and perhaps most importantly — they’re fun! Whether you want to learn more about Holochain or you’re an experienced Holochain developer ready to launch your next great idea, we would love to see you at our next Hackathon. The possibilities for what hApps can be created are truly endless and we’re so excited to see what you will build next. Join us for an agent-centric, self-organized experience and hands-on learning about Holochain! How does it work? Our Hackathons are 2.5 days of collaboration with teams of people building projects and infrastructure for the Next Net. Whether you come with an idea, project or team — it doesn’t matter. Everyone has the opportunity to learn by doing at our events. For folks that aren’t sure they can/want to attend the whole weekend, we welcome folks to come on the first night for our introduction to Holochain and project-brainstorm breakout sessions to see if they’re interested. Who can come? We want the Next Net to be built by a community representative of global diversity. We welcome all who participate constructively in our community, including but not limited to people of varied age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views. People of all ages are welcome — yes, even kids! We welcome you. You don’t need to have experience working in Holochain, or be a developer- regardless of your background, you will have the opportunity to learn by doing. Our attendance usually consists of developers, entrepreneurs, project owners, activists, artists, designers and more. Our participation guidelines ensure that everyone feels safe and welcome. We’re always working to improve the experience at our events. If you have an idea, concern or question about our Hackathons’ inclusivity, don’t hesitate to reach out to us at events@holo.host. What are some things people have done at past Holochain Hackathons? Oh, we never thought you’d ask! First, like we mentioned earlier, some people come with a team and a project in mind that they’re ready to get going on. Others come solo and find a project they’re passionate about and a team they vibe with during our brainstorming sessions. We’re proud to say that our community has developed a bunch of really interesting projects at our events, and often times the project doesn’t end when the Hackathon does — people keep collaborating and building well after the event has ended. Some exciting projects we’ve seen that are all developed as fully distributed, peer-to-peer apps are: · YouTube Clone · Reddit Clone · Chat Apps · Games Apps · Social Activism Apps · Password Management App · So many more We know there’s an entire world of possibilities that can be built on Holochain and we’re excited to see what you can create! Ok, I’m Interested… but, how much does it cost? We want our events to be accessible so we keep our registration fees on the low-end of the range of similar events cost locally. All our events are run on a non-profit basis with the registration fees going towards the cost of the event space, food, and materials. We also have scholarships available for folks that cost is still a barrier. We invite you to reach out to us at events@holo.host to learn more. Are there any upcoming Hackathons? Yes! There are two Holochain Hackathons ‘Spring Edition’ happening in: Seattle — March 13th — March 15th — Get tickets here NYC — March 27th- March 29th — Get tickets here Also we have a small gift for Hacker Noon Hackathon goers, Seattle Hackathon 33% off discount code: REIhack Pssst don’t tell anyone ;) Just kidding! Feel free to spread the love! Don’t see a Hackathon in your area? Why not organize your own? For communities with an active Holochain meetup group, who want to organize their own Hackathon, reach out to events@holo.host to start organizing your Hackathon. Imagine what you can build! Holochain Hackathons promote a sense of building, community and collaboration and perhaps most importantly — they’re fun! Whether you want to learn more about Holochain or you’re an experienced Holochain developer ready to launch your next great idea, we would love to see you at our next Hackathon. The possibilities for what hApps can be created are truly endless and we’re so excited to see what you will build next. Join us for an agent-centric, self-organized experience and hands-on learning about Holochain! How does it work? How does it work? Our Hackathons are 2.5 days of collaboration with teams of people building projects and infrastructure for the Next Net. Whether you come with an idea, project or team — it doesn’t matter. Everyone has the opportunity to learn by doing at our events. For folks that aren’t sure they can/want to attend the whole weekend, we welcome folks to come on the first night for our introduction to Holochain and project-brainstorm breakout sessions to see if they’re interested. Who can come? Who can come? We want the Next Net to be built by a community representative of global diversity. We welcome all who participate constructively in our community, including but not limited to people of varied age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views. People of all ages are welcome — yes, even kids! We welcome you. You don’t need to have experience working in Holochain, or be a developer- regardless of your background, you will have the opportunity to learn by doing. Our attendance usually consists of developers, entrepreneurs, project owners, activists, artists, designers and more. Our participation guidelines ensure that everyone feels safe and welcome. We’re always working to improve the experience at our events. If you have an idea, concern or question about our Hackathons’ inclusivity, don’t hesitate to reach out to us at events@holo.host. What are some things people have done at past Holochain Hackathons? What are some things people have done at past Holochain Hackathons? Oh, we never thought you’d ask! First, like we mentioned earlier, some people come with a team and a project in mind that they’re ready to get going on. Others come solo and find a project they’re passionate about and a team they vibe with during our brainstorming sessions. We’re proud to say that our community has developed a bunch of really interesting projects at our events, and often times the project doesn’t end when the Hackathon does — people keep collaborating and building well after the event has ended. Some exciting projects we’ve seen that are all developed as fully distributed, peer-to-peer apps are: · YouTube Clone · Reddit Clone · Chat Apps · Games Apps · Social Activism Apps · Password Management App · So many more We know there’s an entire world of possibilities that can be built on Holochain and we’re excited to see what you can create! Ok, I’m Interested… but, how much does it cost? Ok, I’m Interested… but, how much does it cost? We want our events to be accessible so we keep our registration fees on the low-end of the range of similar events cost locally. All our events are run on a non-profit basis with the registration fees going towards the cost of the event space, food, and materials. We also have scholarships available for folks that cost is still a barrier. We invite you to reach out to us at events@holo.host to learn more. Are there any upcoming Hackathons? Are there any upcoming Hackathons? Are there any upcoming Hackathons? Yes! There are two Holochain Hackathons ‘Spring Edition’ happening in: Seattle — March 13th — March 15th — Get tickets here Get tickets here NYC — March 27th- March 29th — Get tickets here Get tickets here Also we have a small gift for Hacker Noon Hackathon goers, Seattle Hackathon 33% off discount code: REIhack Also we have a small gift for Hacker Noon Hackathon goers, Seattle Hackathon 33% off discount code: REIhack Also we have a small gift for Hacker Noon Hackathon goers, Seattle Hackathon 33% off discount code: REIhack Pssst don’t tell anyone ;) Just kidding! Feel free to spread the love! Don’t see a Hackathon in your area? Don’t see a Hackathon in your area? Why not organize your own? For communities with an active Holochain meetup group, who want to organize their own Hackathon, reach out to events@holo.host to start organizing your Hackathon. events@holo.host Imagine what you can build!

Holochain Community Hackathons

For quite some time I used Gson for serialisation in our Kotlin and Java-applications. It was the most brittle part of our code, for several reasons: When Gson doesn’t find a no-arg constructor, is used. This means initialisers aren’t called and the deserialised objects could be broken. sun.misc.Unsafe Gson uses reflection to set and retrieve fields. Reflection is slow on Android. Nulls in JSON are able to break Kotlin’s null-safe typing. To improve on that situation, I decided to write an Annotation Processor that generates serialisation code at compile-time, for that would give the most freedom. Here are my design-choices: All necessary data needs to be in the constructor I decided to instantiate deserialised objects with an existing constructor only (the one with the most arguments). This ensures that they are always initialised properly. The only needed annotation is @GsonSerializer which goes on the top of a class: @GsonSerializer
class AppState(val userName: String,
               val notifications: List<String>) This forces separation of initial from generated data. It also removes the need to exclude lazy or @Transient properties. The generated serialiser is an extension function on JsonWriter: fun JsonWriter.value(obj: AppState?) {
    if (obj == null) {
        nullValue()
        return
    }
    beginObject()
    name("userName").value(obj.userName)
    name("notifications").array(obj.notifications) { value(it) }
    endObject()
} The field names and types are taken from the constructor. The code assumes they are also accessible as members, which is easy to obtain. Developer-friendly deserialisation Deserialisation is more complex, since it does a couple of things to help development: It throws informative errors when fields are missing Field-names and enum-values are matched case-insensitive. I realise this is debatable, but it prevents some flow-breaking bugs and was never an issue in production. Serialisation keeps the original casing. The deserialiser: fun JsonReader.nextAppState(): AppState {

    var userName: String? = null
    var notifications: MutableList<String>? = null

    beginObject()
    while (hasNext()) {
        when (nextName().toLowerCase()) {
            "username" -> userName = nextString()
            "notifications" -> notifications = readList(JsonReader::nextString)
            else -> skipValue()
        }
    }
    endObject()

    val obj = AppState(
        userName = checkNotNull(userName) {"error parsing AppState, field not found: userName: String"},
        notifications = checkNotNull(notifications) {"error parsing AppState, field not found: notifications: List"}
    )

    return obj
} Nested objects Since all methods are created as extensions on JsonWriter and JsonReader adding support for more fields is as simple as creating a new extension method or adding @GsonSerializer to the referenced class: @GsonSerializer
class AppState(val user: UserInfo,
               val time: ZonedDateTime)

class UserInfo(name: String) The generated code for this example won’t compile because it misses: JsonWriter.value(UserInfo) JsonReader.nextUserInfo() JsonWriter.value(ZonedDateTime) JsonReader.nextZonedDateTime() To make it work add @GsonSerializer to UserInfo and add the following code for ZonedDateTime fun JsonWriter.value(obj: ZonedDateTime) {
    value(obj.toString())
}

fun JsonReader.nextZonedDateTime(): ZonedDateTime {
    return ZonedDateTime.parse(nextString())
} Abstract Types Reading and writing abstract types is necessary and possible, consider this: @GsonSerializer
class AppState(val requests: Set<NetworkRequest>)

@GsonSerializer
interface NetworkRequest

@GsonSerializer
data class LoginReq(val username: String, val password: String) : NetworkRequest The processor checks the type-hierarchy and writes the object and type-name into an array. I chose an array over an object so I wouldn’t have to cache anything in case the type-name arrives after the data during deserialisation. fun JsonWriter.abstractValue(obj: NetworkRequest?) {
    if (obj == null) {
        nullValue()
        return
    }
    beginArray()
    when (obj) {
        is LoginReq -> value("LoginReq").value(obj)
        else -> throw IllegalStateException("type $obj not annotated")
    }
    endArray()
}

/* deserialize */
fun JsonReader.nextNetworkRequest(): NetworkRequest {
    beginArray()
    val typeName = nextString()
    val obj: NetworkRequest = when (typeName) {
        "LoginReq" -> nextLoginReq()
        else -> throw IllegalStateException("unknown type: $typeName")
    }
    endArray()

    return obj
} Graphs and circular objects Using another annotation @ParentRef, the processor is able to process circular graphs, like a leaf-node having a references to it’s root @GsonSerializer
class Root(var leaf: Leaf?)

@GsonSerializer
data class Leaf(@ParentRef val root: Root, val number: Int) The deserialiser for Leaf returns a function now: fun JsonReader.nextLeaf(): (root: Root) -> Leaf {
    var number: Int? = null

    beginObject()
    while (hasNext()) {
        when (nextName().toLowerCase()) {
            "number" -> number = nextInt()
            else -> skipValue()
        }
    }
    endObject()

    return { root->
        Leaf(
            root = root,
            number = checkNotNull(number) {"error parsing Leaf, field not found: number: Int"}
        )
    }
} For type-safe deserialisation to work, the field in the parent-object must be either nullable or a collection-type: fun JsonReader.nextRoot(): Root {

    var leaf: ((Root) -> Leaf)? = null
    
    beginObject()
    while (hasNext()) {
        when (nextName().toLowerCase()) {
            "leaf" ->  {
                 leaf = nextOrNull(JsonReader::nextLeaf)
             }
            else -> skipValue()
        }
    }
    endObject()

    /* construct parent */
    val obj = Root(
        leaf = null
    )

    /* set child */
    obj.leaf = leaf?.invoke(obj)

    return obj
} Summary This was a short overview about my new method of serialisation. I can’t share any code yet but the principles are clear. The choice of compile-time-generation and Kotlin with it’s extensions methods and lambdas makes it possible to easily create convenient and fast serialisation-code. Assuming all necessary data to be passed in the constructor helps keeping everything safe and enforces separation of initial from generated data. I hope you can take some ideas with you. Happy coding.

Generated JSON-Serialisation for Kotlin

Previously Undisclosed Flaw Let Hackers Hijack Millions of Systems Through Innocent-Looking Files

পূর্বে অপ্রকাশিত ত্রুটি হ্যাকারদের নির্দোষ চেহারার ফাইলগুলির মাধ্যমে লক্ষ লক্ষ সিস্টেম হাইজ্যাক করতে দেয়

Una falla no revelada anteriormente permitió a los piratas informáticos secuestrar millones de sistemas mediante archivos de apariencia inocente

Aurretik ezagutarazi gabeko akatsak Hackerrek milioika sistema bahitu ditzakete itxura errugabeko fitxategien bidez

Une faille jusqu'alors non révélée a permis aux pirates de pirater des millions de systèmes via des fichiers apparemment innocents

Una falla precedentemente non rivelata ha permesso agli hacker di dirottare milioni di sistemi tramite file dall'aspetto innocente

これまで公表されていなかった欠陥により、ハッカーは無害に見えるファイルを通じて何百万ものシステムを乗っ取ることが可能

កំហុសដែលមិនបានបង្ហាញពីមុន អនុញ្ញាតឱ្យពួក Hacker លួចចូលប្រព័ន្ធរាប់លានតាមរយៈឯកសារដែលមើលទៅគ្មានកំហុស

Faute oyo elobamaki te liboso Tika ba pirates ba détourner ba millions ya ba systèmes na nzela ya ba fichiers oyo emonanaka lokola innocent

Өмнө нь илчлэгдэж байгаагүй алдаа нь хакеруудад гэмгүй мэт харагдах файлуудаар дамжуулан сая сая системийг хулгайлах боломжийг олгосон.

Ранее нераскрытая уязвимость позволила хакерам взломать миллионы систем с помощью невинных на вид файлов

Mbere Amakosa Ataramenyekana Reka Hackers Banyere Amamiriyoni ya Sisitemu Binyuze muri dosiye zisa n'inzirakarengane

Ilgari oshkor etilmagan kamchilik xakerlarga begunoh ko'rinadigan fayllar orqali millionlab tizimlarni o'g'irlashiga imkon berdi.

10 More Patterns to Solve 1000 More LeetCode Problems - Part II

Mastering Maps in Go: Everything You Need to Know

গো-তে মানচিত্র আয়ত্ত করা: আপনার যা জানা দরকার

Maps in Go meistern: Alles, was Sie wissen müssen

Dominar mapas en Go: todo lo que necesitas saber

Maîtriser les cartes en Go : tout ce que vous devez savoir

गो में मानचित्रों पर महारत हासिल करना: वह सब कुछ जो आपको जानना चाहिए

Go でマップをマスターする: 知っておくべきことすべて

Go로 지도 마스터하기: 알아야 할 모든 것

Dominando mapas em Go: tudo o que você precisa saber

Освоение карт в Go: все, что вам нужно знать

Go'da Haritalarda Uzmanlaşmak: Bilmeniz Gereken Her Şey

Làm chủ bản đồ trong Go: Mọi thứ bạn cần biết

掌握 Go 中的 Maps：你需要知道的一切

In the , we figured out how to implement  server-side interceptors. In this article, we try to figure out how to log GRPC requests on the client side. We must implement three interfaces ClientInterceptor, ClientCall, and ClientCall.Listener. previous article There are default implementations such as SimpleForwardingClientCall and SimpleForwardingClientCallListener in which all methods are implemented. If we look at their implementation, we can see that they invoke a next implementation ClientCall or ClientCall.Listener. The Implementation Our implementation will be straightforward; we will store requests and responses in Queues, and then put this data to MDC. First, let’s implement ClientCall.Listener. import com.google.protobuf.GeneratedMessageV3
import com.google.protobuf.util.JsonFormat
import io.grpc.ClientCall
import io.grpc.ForwardingClientCallListener.SimpleForwardingClientCallListener
import io.grpc.Metadata
import io.grpc.Status
import org.slf4j.LoggerFactory
import org.slf4j.MDC
import java.util.Queue

class LoggingClientCallListener<ReqT, ResT>(
    delegate: ClientCall.Listener<ResT>,
    private val requestQueue: Queue<ReqT>,
    private val responseQueue: Queue<ResT>
) : SimpleForwardingClientCallListener<ResT>(delegate) {

    override fun onMessage(message: ResT) {
        responseQueue.offer(message)
        super.onMessage(message)
    }

    override fun onClose(status: Status, trailers: Metadata) {
        val request = requestQueue
            .filterIsInstance<GeneratedMessageV3>()
            .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = PROTOBUF_TO_JSON_PRINTER::print)

        val response = responseQueue
            .filterIsInstance<GeneratedMessageV3>()
            .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = PROTOBUF_TO_JSON_PRINTER::print)

        if (status.isOk) {
            MDC.put("request", request)
            MDC.put("response", response)
            logger.info("The request was processed successfully")
            MDC.clear()
        } else if (UNSUCCESSFUL_STATUS_CODES.contains(status.code)) {
            MDC.put("request", request)
            logger.error("An error occurred while processing the request", status.asRuntimeException())
            MDC.clear()
        }

        super.onClose(status, trailers)
    }

    companion object {
        private val logger = LoggerFactory.getLogger(LoggingServerCallListener::class.java)
        private val PROTOBUF_TO_JSON_PRINTER = JsonFormat.printer()
        private val UNSUCCESSFUL_STATUS_CODES = listOf(
            Status.INVALID_ARGUMENT.code,
            Status.INTERNAL.code,
            Status.NOT_FOUND.code
        )
    }
} We have overridden the two methods. First, we have overridden the onMessage method. The method will be invoked before the client will receive data. The method can be invoked from zero to n times if the method result is defined as Stream. Second, we have overridden the onClose method. The method will be called before the client closes the connection, and no data will be retrieved after that. After that, we must implement the interface ClientCall. import io.grpc.ClientCall
import io.grpc.ForwardingClientCall.SimpleForwardingClientCall
import io.grpc.Metadata
import java.util.*

class LoggingClientCall<ReqT, RespT>(
    delegate: ClientCall<ReqT, RespT>,
    private val requestQueue: Queue<ReqT>,
    private val responseQueue: Queue<RespT>
) : SimpleForwardingClientCall<ReqT, RespT>(delegate) {

    override fun sendMessage(message: ReqT) {
        requestQueue.offer(message)
        super.sendMessage(message)
    }

    override fun start(responseListener: Listener<RespT>, headers: Metadata) {
        super.start(LoggingClientCallListener(responseListener, requestQueue, responseQueue), headers)
    }
} We have overridden two methods also. First, we have overridden the sendMessage method. This method will be invoked before a message will be sent to a service. We push our message to the queue. In the next method, we create our implementation of our LoggingClientCallListener. This method will be invoked before all methods. Next, we must implement our client interceptor and register this interceptor in the stub. import io.grpc.*
import java.util.concurrent.LinkedBlockingDeque

class LoggingClientInterceptor : ClientInterceptor {
    override fun <ReqT : Any, RespT : Any> interceptCall(
        method: MethodDescriptor<ReqT, RespT>,
        callOptions: CallOptions,
        next: Channel
    ): ClientCall<ReqT, RespT> {
        return LoggingClientCall(next.newCall(method, callOptions), LinkedBlockingDeque(), LinkedBlockingDeque())
    }
} fun main(args: Array<String>) {
	val client = OurServiceGrpc
		.newBlockingStub(ManagedChannelBuilder.forAddress("localhost", 8080).build())
		.withInterceptors(LoggingClientInterceptor())
} I hope I managed to show you how to use server and client interceptors in GRPC.

How to Implement Client-Side Interceptors for Logging GRPC Requests

Stories, News & Mentions about NEXTNET

Categories

Trending Topics

Stories, News & Mentions about NEXTNET

Nextnet’s Stories on HackerNoon

Categories

Trending Topics