MeetRecord

meetrecord

Among the blockchain and cryptocurrencies world, a lot of projects have seen the light. The most famous being Bitcoin and Ethereum, propelled by a wide media coverage. But one project has not made newspapers headlines yet is trying to achieve a tremendous work. As many blockchains are being built from scratch for lots of different needs all over the world, the Hyperledger Project launched by the Linux Foundation will try to standardize and democratize blockchain within the business world. Instead of letting companies solve their issues on their own, Hyperledger will combine a cross-industry knowledge to allow enterprises to build customized blockchains that would answer specific needs. Let’s have a deeper look on what is Hyperledger. Context In 2015, the Linux Foundation, the nonprofit organization enabling mass innovation through open source, The original goal was to develop The Hyperledger Project was born. But what does this purpose really mean? announced the collaboration of industry leaders to advance blockchain technology at an enterprise level. “an open source distributed ledger framework to build robust, industry-specific applications, platforms and hardware systems to support business transactions”. The first members to join the movement were mostly banks, financial services firms or IT companies. But as time went by, more and more corporations joined the project to the point that the member list reaches as of September 26th from very different sectors and horizons. We can find in the list big industry-leader firms as well as start-ups, from logistic to healthcare and from finance to government, all of them having contributed either financially either by providing line of codes and development progress. The 2 biggest contributors are IBM and Intel. As of July 2018, Hyperledger hosts . 270 contributing organizations 10 projects with 3.6 million lines of code and close to 28,000 participants who have come to 110+ meetups around the world “Distributed ledgers are poised to transform a wide range of industries” — Jim Zemlin, Executive Director of the Linux Foundation, after the launch of the Hyperledger Project As blockchain being a recent innovation and a hard-to-catch concept for non-tech profiles, the need for a cross-industry collaboration rised within the business world. You have to understand that Hyperledger is not a company, not a cryptocurrency and not a blockchain. It is a worldwide collaborative effort to transparently and openly enlighten blockhain potential to solve business issues. Understanding Bitcoin and Ethereum is pretty easy-going because it is practical and has proven true usefulness among developers and users. Understanding Hyperledger is another challenge. Hyperledger logo, https://www.hyperledger.org/ Hyperledger has written a Charter in the beginning of 2016, a kind of white paper, stating the guidelines and what it is trying to achieve. Among the 4 missions announced we can read : Create an enterprise grade, open source distributed ledger framework and code base Promote participation of leading members of the ecosystem Can it be more vague? What you have to remember behind these sentences is that the Linux Foundation, through its Hyperledger Project Thus it is an infrastructure in which you can find ongoing blockchain-related projects. All of them are non-currency projects and industrial applications. And that’s an important point. wants to create an environment in which communities of software developers and companies meet and coordinate to build blockchain frameworks. You won’t have any Hyperledger Coin around because the project doesn’t intend to host its own cryptocurrency like Ethereum for example. “By not pushing a currency, we avoid so many of the political challenges of having to maintain a globally consistent currency” — Brian Behlendorf, Hyperledger Executive Director So, we have a global movement, organized in several projects, initiated by The Linux Foundation, lead by reknown persons from tech, open-source and data world with years of experience and supported by 270 contributing companies and organizations aiming to develop non-currency blockchain-based projects for the business world. Let’s dive into those projects. Hyperledger Projects Let’s start with the 2 projects that are available and production-ready that are Hyperledger Sawtooth and Hyperledger Fabric. is a blockchain mainly developed by Intel that intends to test the functionality of a new consensus mechanism called Proof of Elapsed Time (PoeT) and to allow an enterprise to run distributed ledgers maintained without a central authority. Hyperledger Sawtooth The PoeT is an algorithm that attempts to distribute network mining rights through a fair random system. It aims to eliminate environmental and energy-consumption issues underlying Proof of Work consensus algorithm used by Bitcoin and other cryptocurrencies. . In short, each participating node in the network is required to wait for a randomly chosen time period, and the first one to complete the designated waiting time wins the new block. The process follows a fair lottery system instead of rewarding the most powerful node In their presentation video, Hyperledger illustrates the potential of Sawtooth with the seafood supply chain, where Sawtooth provides an immutable record of provenance and lineage of various goods like fish. Thanks to Internet of Things (physical connected devices) and sensors combined with Sawtooth, it is possible to trace any fish’s journey from ocean to the table. Sawtooth is written in Python and targeted at providing blockchains that could eventually be applied to the Internet of Things and various financial systems. is a project driven under the mentoring of IBM. Surprinsingly, Fabric is the most widely adopted blockchain by the biggest enterprises. Indeed, using the Ethereum platform for companies to build applications on top of it is a constraint because . What Hyperledger Fabric provides is a base to build a specific blockchain for a specific industry and run applications that are related to specific needs. Hyperledger Fabric Ethereum has its own protocol, thus is less flexible It’s not beginner friendly at all but it deserves credit to . Built as a modular framework where applications can easily scale up to any level, Fabric intends to provide basic blockchain services like transparency, decentralization and security. provide design and customization to meet precise requirements Beside Sawtooth and Fabric, other projects are worth to mention. which is a permissionable smart contract machine developed to the specification of the Ethereum Virtual Machine (EVM). Hyperledger Burrow which is a distributed ledger built for decentralized identities. It provides tools, libraries and reusable components for creating and using independent digital identities. It doesn’t use Proof of Work and uses blockchain-based identity solutions. Hyperledger Indy which is a blockchain framework designed to be simple and easy to incorporate into infrastructure projects that require distributed ledger technology. Hyperledger Iroha Example Let’s put Burrow and Indy in perspective with a use case presented in the Hyperledger’s white paper. Usually, banks gather personally identifiable information (PII) on every customer and prospect to assess a risk if a loan is asked. These information are sensitive and juicy target for hackers. Moreover, loan applicants often need to share these information with several banks to increase their chance to obtain a loan but also increase the chance for these information to be abused. Thanks to a secured blockchain, applicants can disclose the assessed information confidently and banks can conform with regulation and rely on this distributed ledger that acts as a source of truth. On top of that, we can imagine the Hyperledger Burrow that would turn the loan application into a smart contract, attaching identities to the loan. With Hyperledger Indy, applicants can share only the information the banks need to make a decision without placing any personal data in the equation. Perspectives Although most Hyperledger’s projects are still in the development phase, some companies have started using Sawtooth or Fabric as enabler for empowering their product or service. Everledger for instance is a company that tracks high-value goods on their blockchain. . This reduces jewelry fraud (estimated at millions of dollars) by replacing the paper-based tracking method with a digitized one. This latter was designed through Hyperledger Fabric allowing clients, authorities, lawyers, accounts and every intermediary of the diamond’s supply chain to transparently track the recording process of diamonds Everledger logo, https://www.everledger.io/ And Everledger is not the only one who saw the potential of Hyperledger’s projects. Spearheaded by Intel and IBM, their massive clients portfolio is starting to pay attention to the opportunities offered by private blockchains. Fortunately, as Sawtooth and Fabric are up and running, companies’ enquirements about business use cases can be answered. Anyhow, Hyerperledger’s projects are on the verge to answer an enormous market where needs for collaboration have never been bigger. With this in mind, Hyperledger announced on October 1st a partnership with its direct competitor, (EEA). EEA is the global standards organization driving the adoption of Enterprise Ethereum, a consortium of companies from start-ups to industry-leader to answer business needs through a private version of the Ethereum platform. Both organizations are now each other’s Associate Member and co-contribute to their development. the Enterprise Ethereum Alliance This significant partnership proves that because distributed ledgers are being built in various industries, an open source and collaborative development strategy supporting multiple players across the globe is required in order to realize the promise of blockchain. The willingness of cross-industry mass adoption in the coming years can not be achieve by one company alone. that would deliver billions in economic value Conclusion CEO of IBM Ginni Rometty declared that in terms of making them really cheap to record and easy to verify. A concern extremely true for worldwide companies. what internet was to information, blockchain is to transactions In that perspective and to make the technology more mature, an important acknowledgment has been made by he Linux Foundation: Bitcoin and Ethereum are hardly scalable due to a consensus that is needed to be found simultaneously by peers within the network Bitcoin and Ethereum do not support private transactions Based on that, Hyperledger is trying to find new ways to achieve consensus no matter the size of the network and to build private blockchains to match business needs, leaving Proof of Work alongside. What you need to remember from this article is that Besides Sawtooth and Fabric which are the most advanced and well-known projects, Hyperledger has taken eight other initiatives under its wing, ranging from an implementation of the Ethereum smart contract engine (Burrow) to a distributed digital identity system (Indy) to an interoperability platform for doing transactions across ledgers (Quilt). Hyperledger will help secure and customize supply verifications, logistics, distribution and payment verifications between entities. Finally, whether you are an entrepreneur, a project manager, a consultant, an advisor or an executive, . Ethereum and other cryptocurrencies blockchain are not necessarily the keys to unlock industrial issues encountered in the business world. You might consider using Hyperledger Fabric or Sawtooth depending on what you’re aiming to achieve. be careful of which blockchain could answer your needs Just keep in mind what Brian Behlendorf rightfully said about blockchain: “it will shake up how business transactions are done, particularly in the finance and healthcare sectors”.

WTF is Hyperledger ?

Kafka Message Testing: How to Write Integration Tests 

Introduction The article demonstrates the use of null-state analysis to remove compiler warnings of “check code for null safety”. Learning Objectives Discover how to set up the nullable context in your C# project or codebase. Prerequisites for Developers Familiarity with introductory-level C# programming Know how to use Visual Studio Code or Visual Studio .NET SDK version 6.0 or newer Getting Started .NET developers often face the System.NullReferenceException, which happens when a null is referenced at runtime and results in the most common exception in the .NET application. As the creator of null, Sir Tony Hoare, refers to null as the "billion-dollar mistake." Example The variable records is set to null and then immediately referenced which results in System.NullReferenceException TestRecord records = null;
    
    _ = records.ToString();
    
    record TestRecord(int Id, string Name); As the applications grow in the number of lines of code and become more complex, spotting such issues as a developer can be challenging. This is where C# compiler steps in. Define null safety In the previous example, a developer can avoid the System.NullReferenceExceptionby checking if the records variable was null as shown below. TestRecord records = null;
    
    // Check for null
    if (records is not null)
    {
        _ = records.ToString();
    }
    
    record TestRecord(int Id, string Name); Nullable Types The default value for all reference types is null. string first;                  // first is null
    string second = string.Empty   // second is not null, instead it's an empty string ""
    int third;                     // third is 0 because int is a value type
    DateTime date;                 // date is DateTime.MinValue In the example mentioned earlier: The variable “first” is null because a reference type “string” was declared but not assigned any value. The variable “second” is assigned the value “string.Empty” during declaration. The variable “third” has a value of 0 even though it was not explicitly assigned. The variable “date” is uninitialized, but its default value is “System.DateTime.MinValue.” Post C# 2.0 version, we can define nullable values using Nullable<T>. This allowed value types to be assigned with a value of null. int? first;            // first is implicitly null (uninitialized)
    int? second = null;    // second is explicitly null
    int? third = default;  // third is null as the default value for Nullable<Int32> is null
    int? fourth = new();    // fourth is 0, since new calls the nullable constructor Nullable context As per my experience, this is a must-have feature that should be enabled in every .Net application as it enables control for how the compiler understands reference type variables. There are four types of nullable contexts disable enable warnings annotations Enable nullable context it can be enabled by adding <Nullable> item to the <PropertyGroup> inside the application .csproj file as shown below <Project Sdk="Microsoft.NET.Sdk">
    
        <PropertyGroup>
            <OutputType>Exe</OutputType>
            <TargetFramework>net6.0</TargetFramework>
            <Nullable>enable</Nullable>
        </PropertyGroup>
    
        
    
    </Project> Alternatively, developers can also add scope nullable context which means the nullable context will be applicable only in the defined scope. #nullable enable Complete Code on GitHub GitHub — ssukhpinder/30DayChallenge.Net C# Programming🚀 Thank you for being a part of the C# community! Before you leave: If you’ve made it this far, please show your appreciation with a clap and follow the author! 👏️️ Follow us: | | | | | X LinkedIn Dev.to Hashnode Newsletter Tumblr Visit our other platforms: | | | | GitHub Instagram Tiktok Quora Daily.dev More content at C# Programming Also published . here

The 30-Day .NET Challenge, Day 9: Null Safety

Having been in software long enough to work across industries and with a variety of distributed systems, I know every system has its day. Software and systems engineers create performance requirements, latency constraints, and sweat the details on software quality. Their hard work ensures retail sites stay online through black Friday, ad campaigns survive the Superbowl, accounting systems make it through tax season, and media sites stay up to date during the election. And that’s not even counting safety critical systems we rely on each day, systems that keep our hospitals, our vehicles, and our industries humming. Last week was record setting for the financial markets. We saw a few days in the top-ten all time value traded in equities ( ) as well as Thursday and Friday this week in the top 15 days ever on volume in equities. If you are a software or hardware engineer in FinTech, most likely you’re seeing greater processing volume and much higher than average usage of your systems. $791B Market volume, volatility, and events like the one-day point drop in the Dow, the highest ever, have had cascading impacts across calculation, analytics, risk, portfolio accounting, and pretty much every system that touches the markets. If you are lucky enough to work with real-time market data, this was (hopefully) a defining week that really showed what your systems can do! If not, this was a week that should make it easy to justify addressing gaps and taking action on your lessons learned. 4.4% Better, Continuously Last week’s market activity highlighted not only the collaborative environment we have between our trading desk and engineering, but was also a testament to the continuous evolution of our trading systems. At PEAK6 Capital Management , we’ve been in the options markets and successful for over 22 years. These systems allow us to provide liquidity, increase market flow, and carry risk when our counterparties need it most. They do this by giving our traders a view of the markets, a view of our positions, and the ability to analyze and act on opportunities as conditions change. In order to make sure we keep getting better, our product and engineering teams push on technical initiatives. Adopting infrastructure as code, updating our service mesh, coordinating nightly processing with Apache Airflow, unifying streaming data pipelines using Apache Kafka, and leaning on Kubernetes for scheduling have made it easier than ever to scale, deploy, and quickly adjust to changing demands on our systems. That’s not to say we don’t run into issues or occasionally exit the market when our risk checks deem it necessary. Rather, we’re continually learning and continually making our systems more resilient, better able to meet demand. Great systems are built on a clear understanding of their non-functional requirements (e.g. all those architectural “-ilities”, like availability, usability, maintainability, extensibility, scalability, etc). At PEAK6, our systems are built for low-latency (in the millis) market analysis and trading strategy execution. We are not a high-frequency trading platform, and by making this distinction, we have a bit more flexibility choosing between our systems’ maintainability and scalability. However, as you’ll see in the numbers below, we still love our metrics and understanding exactly how our systems are performing. So, what do record setting market conditions look like for an options trading platform? Record Setting, Unprecedented In order to understand how last week went for our systems, it’s necessary to understand historic market values. The following chart shows all previous market selloffs with number of days from peak to 10% drawdown. The drop last week moved ridiculously fast, only taking six days! If we look at the S&P 500 (SPY), we can see the free fall (left) and overall SPY traded on Friday (right) was the highest it has ever seen (104.27B). Option markets’ volumes both by notional value and number of contracts show a similar picture. The following two charts below show how options volume compared to previous weeks. The above notional by market shows a small jump Tuesday around $25B with giant leaps in notional Thursday ($34B) and Friday ($50B). The below contracts by market shows a marked increase beginning on Friday the 21st moving from ~30 million to just over ~40 million contracts. Record setting volume like this is not seen often and as we’ll see below, it puts our systems to the test.Record setting volume like this is not seen often and as we’ll see below, it puts our systems to the test. A Rising Tide Lifts… Our Data Processors? Looking across our trading platform, the first and most obvious place we saw impacts were across our market data feeds. These run daily receiving tick by tick data for options’ quotes and trades. If we look back through October 2018, we see a fairly consistent messages/day between ~25 and ~50 billion. Starting in late January, however, you start to see rates increase with huge peaks for the last week well over 75B messages per day culminating in over messages/day processed on Friday! And this is only our options data, as in it doesn’t count our CTA and UTP stock data integrations! 101B As this market data moves downstream, we calculate derived data like prices, greeks, user defined calcs, etc. These get pumped into the tools our traders use to get a real-time view of the markets. You can see the impact from the CPU load on our data daemons, especially on Tuesday, when one of these nodes bounced and our scripts rebalanced. As more volatility means more opportunity, our execution systems also experienced sustained bursts generated both by our trading desk and recalculation events for risk checks and fill rates as we went out to the market. This meant more reactive processing end to end throughout each day. After trading hours, all this data and all these trades need to go through clearing where nightly processing will kick out final settlements, positions, and reports that will fuel analysis for the coming day. These systems also had to deal with the huge volume and we saw not only delayed processing from our data vendors, but also increased load on our realtime, archiving and nightly data summarization. For example, on a normal week, we might process ~5 TB/day tick data, but last week we had ~8 TB/day. Integration Stress As I mentioned above, our data vendors were also impacted. Some quick highlights in the wild here were and . Additionally, Cboe and other firms put out notices that their systems may be overloaded. Here’s a short except from the Cboe warning: NYSE Arca Resolves Delays in Trades Reported to the OCC Toronto Exchange Closes Early Due to Technical Issue Cboe Global Markets Inc. is warning market participants that massive volumes in S&P 500 weekly options are getting close to overloading its software system. The exchange sent an email to market participants indicating that it has exceeded 90% capacity in its market data feed that enables the streaming of weekly S&P 500 option quotes as of 2:57 p.m. in New York, and would send another email once the 95% threshold is breached. Preparing for a Marathon a Sprint at a Time Here are a few ways we prepared to keep our software running during these all-time highs: Our systems are designed for high-availability by default including an active-active configuration that allows us to quickly move traffic from our trading users in the case of localized failure. (See Kevin’s blog post on the Metro cluster as an ) example Our systems are designed for quick redeployment and scale out meaning we could increase the number of replicas in Kubernetes to horizontally scale as well as create ad-hoc instances where necessary and have our service discovery rebalance usage. We are always tuning, especially during times of high pressure. In several cases, we tuned JVM behavior for our Java apps, investigated HyperThreading performance, and reconfigured our Kubernetes workers to better handle load (and occasionally dropped in some memory!). We have automated alerting and log aggregation that make it easy for us to triage issues. We are risk diligent, holding off on releases and constantly weighing the cost-benefit of rolling out updates. This means we might push out patches for critical issues, but wait on larger or less-critical updates. We have great processes and trust between our trading teams, trading support teams, and our engineering teams so that we can quickly de-escalate firm risk while reducing recovery time. All of these preparations were the result of our product, trading, and engineering teams working together to ensure our systems were well-built for failure. Capabilities like redeployment, horizontally scaling, and failover aren’t emergent and need constant diligence to remain viable. We might not use all these capabilities as we have this past week, but knowing that we have them ensures we can remain stable and available when the markets push us to our limit. Better, Faster, Stronger In sharing this post, I hope you have a better understanding of how PEAK6 builds systems and the kinds of stresses our trading platform can experience. If you’re in technology, I hope you can see the power of observability into your systems. It’s never too late to start measuring what you care about. It’s the only way you can make it better so that you understand how your systems perform, what your systems do under pressure, and what it might look like on your system’s record setting day. Notes US Equity and US Equity Options data from Cboe Exchange, Inc. and https://markets.cboe.com/us/equities/market_statistics/ https://markets.cboe.com/us/options/market_statistics/ CNN Business, Feb 27, 2020. Dow falls 1,191 points — the most in history https://www.cnn.com/2020/02/27/investing/dow-stock-market-selloff/index.html Unprecedented Collapse Chart and Markets summary from the Heisenberg Report: https://heisenbergreport.com/2020/02/29/what-just-happened-the-historic-selloff-explained-by-nomuras-charlie-mcelligott/ SPY Daily OHLC from and Bloomberg TradingView.com Seeking Alpha’s From Bubble to Bust: https://seekingalpha.com/article/4328579-from-bubble-to-bust

Indebted to the Tech

we explored one of the most complex topics I’ve presented on this blog. We examined potential runtime failures that can occur when using Tensor Flow. These included mismatched dimensions and missing placeholders. In an ideal world, we would catch these issues at compile time instead. At its current stage, the Haskell Tensor Flow library doesn’t support that. But we demonstrated that it is possible to add a layer to do this by using dependent types. In the last couple weeks Now, I’m still very much of a novice at dependent types, so the solutions I presented were rather clunky. This week I’ll show a better example of this concept from a different library. The library uses dependent types everywhere. It allows us to build verifiably-valid neural networks with extreme concision. So let’s dive in and see what it’s all about! Grenade Shapes and Layers The first thing to learn with this library is the two concepts of Shapes and Layers. Shapes are best compared to tensors from Tensor Flow, except that they exist at the type level. In Tensor Flow we could build tensors with arbitrary dimensions. Grenade currently only supports up to three dimensions. So the different shape types either start with , or , depending on the dimensionality of the shape. Then each of these type constructors take a set of natural number parameters. So the following are all valid “Shape” types within Grenade: D1, D2 D3 D1 5D2 4 12D3 8 10 2 The first represents a vector with 5 elements. The second represents a matrix with 4 rows and 12 columns. And the third represents an 8x10x2 matrix (or tensor, if you like). The different numbers represent those values , not the term level. If this seems confusing, here’s a that goes into more depth about the basics of dependent types. The most important idea is that something of type can have 5 elements. A vector of 4 or 6 elements will not type-check. at the type level good tutorial D1 5 only So now that we know about shapes, let’s examine layers. Layers describe relationships between our shapes. They encapsulate the transformations that happen on our data. The following are all valid layer types: ReluFullyConnected 10 20Convolution 1 10 5 5 1 1 The layer describes a layer that takes in data of any kind of shape and outputs the same shape. In between, it applies the activation function to the input data. Since it doesn’t change the shape, it doesn’t need any parameters. Relu relu A layer represents the canonical layer of a neural network. It has two parameters, one for the number of input neurons and one for the number of output neurons. In this case, the layer will take 10 inputs and produce 20 outputs. FullyConnected A layer represents a 2D convolution like we saw with our network. This particular example has 1 input feature, 10 output features, uses a 5x5 patch size, and a 1x1 patch offset. Convolution MNIST Describing a Network Now that we have a basic grasp on shapes and layers, we can see how they fit together to create a full network. A network type has two type parameters. The second parameter is a list of the shapes that our data takes at any given point throughout the network. The first parameter is a list of the layers representing the transformations on the data. So let’s say we wanted to describe a very simple network. It will take 4 inputs and produce 10 outputs using a fully connected layer. Then it will perform an activation. This network looks like this: Relu type SimpleNetwork = Network  ‘[FullyConnected 4 10, Relu]  ‘[ ‘D1 4, ‘D1 10, ‘D1 10] The apostrophes in front of the lists and terms indicated that these are promoted constructors. So they are types instead of terms. To “read” this type, we start with the first data format. We go to each successive data format by applying the transformation layer. So for instance we start with a 4-vector, and transform it into a 10-vector with a fully-connected layer. Then we transform that 10-vector into another 10-vector by applying . That’s all there is to it! We could apply another layer onto this that will have 3 outputs like so: D1 relu FullyConnected type SimpleNetwork = Network  ‘[FullyConnected 4 10, Relu, FullyConnected 10 3]  ‘[ ‘D1 4, ‘D1 10, ‘D1 10, `D1 3] Let’s look at MNIST to see a more complicated example. We’ll start with a 28x28 image of data. Then we’ll perform the convolution layer I mentioned above. This gives us a 3-dimensional tensor of size 24x24x10. Then we can perform 2x2 max pooling on this, resulting in a 12x12x10 tensor. Finally, we can apply an layer, which keeps it at the same size: Relu type MNISTStart = MNISTStart  ‘[Convolution 1 10 5 5 1 1, Pooling 2 2 2 2, Relu]  ‘[D2 28 28, D3 24 24 10, D3 12 12 10, D3 12 12 10] Here’s what a full MNIST example might look like (per the on the library’s Github page): README type MNIST = Network    '[ Convolution 1 10 5 5 1 1, Pooling 2 2 2 2, Relu     , Convolution 10 16 5 5 1 1, Pooling 2 2 2 2, FlattenLayer, Relu     , FullyConnected 256 80, Logit, FullyConnected 80 10, Logit]    '[ 'D2 28 28, 'D3 24 24 10, 'D3 12 12 10, 'D3 12 12 10     , 'D3 8 8 16, 'D3 4 4 16, 'D1 256, 'D1 256     , 'D1 80, 'D1 80, 'D1 10, 'D1 10] This is a much simpler and more concise description of our network than we can get in Tensor Flow! Let’s examine the ways in which the library uses dependent types to its advantage. The Magic of Dependent Types Describing our network as a type seems like a strange idea if you’ve never used dependent types before. But it gives us a couple great perks! The first major win we get is that it is very easy to generate the starting values of our network. Since it has a specific type, we can let type inference guide us! We don’t need any term level code that is specific to the shape of our network. All we need to do is attach the type signature and call ! randomNetwork randomSimple :: MonadRandom m => m SimpleNetworkrandomSimple = randomNetwork This will give us all the initial values we need, so we can get going! The second (and more important) win is that we can’t build an invalid network! Suppose we try to take our simple network and somehow format it incorrectly. For instance, we could say that instead of the input shape being of size 4, it’s of size 7: type SimpleNetwork = Network  ‘[FullyConnected 4 10, Relu, FullyConnected 10 3]  ‘[ ‘D1 7, ‘D1 10, ‘D1 10, `D1 3]-- ^^ Notice this 7 This will result in a compile error, since there is a mismatch between the layers. The first layer expects an input of 4, but the first data format is of length 7! Could not deduce (Layer (FullyConnected 4 10) ('D1 7) ('D1 10))        arising from a use of ‘randomNetwork’      from the context: MonadRandom m        bound by the type signature for:                   randomSimple :: MonadRandom m => m SimpleNetwork        at src/IrisGrenade.hs:29:1-48 In other words, it notices that the chain from to using a layer is invalid. So it doesn’t let us make this network. The same thing would happen if we made the layers themselves invalid. For instance, we could make the output and input of the two fully-connected layers not match up: D1 7 D1 10 FullyConnected 4 10 -- We changed the second to take 20 as the number of input elements.type SimpleNetwork = Network   '[FullyConnected 4 10, Relu, FullyConnected 20 3]  '[ 'D1 4, 'D1 10, 'D1 20, 'D1 3]

…

/Users/jamesbowen/HTensor/src/IrisGrenade.hs:30:16: error:    • Could not deduce (Layer (FullyConnected 20 3) ('D1 10) ('D1 3))        arising from a use of ‘randomNetwork’      from the context: MonadRandom m        bound by the type signature for:                   randomSimple :: MonadRandom m => m SimpleNetwork        at src/IrisGrenade.hs:29:1-48 So Grenade makes our program much safer by providing compile time guarantees about our network’s validity. Runtime errors due to dimensionality are impossible! Training the Network on Iris Now let’s do a quick run-through of how we actually train this neural network. Readers with a keen eye may have noticed that the we’ve built is the same network we used to train the Iris data set. So we’ll do a training run there, using the following steps: SimpleNetwork Write the network type and generate a random network from it Read our input data into a format that Grenade uses Write a function to run a training iteration. Run it! 1. Write the network type and generate the network So we’ve already done this first step for the most part. We’ll adjust the names a little bit though. Note that I’ll include the imports list as an appendix to the post. Also, the code is on the of my repository in ! [grenade](https://github.com/jhb563/HTensor/tree/grenade) branch Haskell Tensor Flow IrisGrenade.hs type IrisNetwork = Network   '[FullyConnected 4 10, Relu, FullyConnected 10 3]  '[ 'D1 4, 'D1 10, 'D1 10, 'D1 3]

randomIris :: MonadRandom m => m IrisNetworkrandomIris = randomNetwork

runIris :: FilePath -> FilePath -> IO ()runIris trainingFile testingFile = do  initialNetwork <- randomIris  ... 2. Take in our input data We’ll make use of the function we used back when we . Then we'll make a dependent type called , which uses the type. This type is a container for a shape. We want our input data to use for the 4 input features. Then our output data should use for the three possible categories. readIrisFromFile first did Iris IrisRow S S D1 4 D1 3 -- Dependent type on the dimensions of the rowtype IrisRow = (S ('D1 4), S ('D1 3)) If we have malformed data, the types will not match up, so we’ll need to return a to ensure this succeeds. Note that we normalize the data by dividing by 8. This puts all the data between 0 and 1 and makes for better training results. Here's how we parse the data: Maybe parseRecord :: IrisRecord -> Maybe IrisRowparseRecord record = case (input, output) of  (Just i, Just o) -> Just (i, o)  _ -> Nothing  where    input = fromStorable $ VS.fromList $ float2Double <$>      [ field1 record / 8.0, field2 record / 8.0, field3 record / 8.0, field4 record / 8.0]    output = oneHot (fromIntegral $ label record) Then we incorporate these into our main function: runIris :: FilePath -> FilePath -> IO ()runIris trainingFile testingFile = do  initialNetwork <- randomIris  trainingRecords <- readIrisFromFile trainingFile  testRecords <- readIrisFromFile testingFile

  let trainingData = mapMaybe parseRecord (V.toList trainingRecords)  let testData = mapMaybe parseRecord (V.toList testRecords)

  -- Catch if any were parsed as Nothing  if length trainingData /= length trainingRecords || length testData /= length testRecords    then putStrLn "Hmmm there were some problems parsing the data"    else … 3. Write a function to train the input data This is a multi-step process. First we’ll establish our learning parameters. We’ll also write a function that will allow us to call the function on a particular row element: train learningParams :: LearningParameterslearningParams = LearningParameters 0.01 0.9 0.0005

-- Train the network!trainRow :: LearningParameters -> IrisNetwork -> IrisRow -> IrisNetworktrainRow lp network (input, output) = train lp network input output Next we’ll write two more helper functions that will help us test our results. The first will take the network and a test row. It will transform it into the predicted output and the actual output of the network. The second function will take these outputs and reverse the process to get the label out (0, 1, or 2). oneHot -- Takes a test row, returns predicted output and actual output from the network.testRow :: IrisNetwork -> IrisRow -> (S ('D1 3), S ('D1 3))testRow net (rowInput, predictedOutput) = (predictedOutput, runNet net rowInput)

-- Goes from probability output vector to labelgetLabels :: (S ('D1 3), S ('D1 3)) -> (Int, Int)getLabels (S1D predictedLabel, S1D actualOutput) =   (maxIndex (extract predictedLabel), maxIndex (extract actualOutput)) Finally we’ll write a function that will take our training data, test data, the network, and an iteration number. It will return the newly trained network, and log some results about how we’re doing. We’ll first take only a sample of our training data and adjust our parameters so that learning gets slower. Then we’ll train the network by folding over the sampled data. run :: [IrisRow] -> [IrisRow] -> IrisNetwork -> Int -> IO IrisNetworkrun trainData testData network iterationNum = do  sampledRecords <- V.toList <$> chooseRandomRecords (V.fromList trainData)  -- Slowly drop the learning rate  let revisedParams = learningParams         { learningRate = learningRate learningParams * 0.99 ^ iterationNum}  let newNetwork = foldl' (trainRow revisedParams) network sampledRecords  .... Then we’ll wrap up the function by looking at our test data, and seeing how much we got right! run :: [IrisRow] -> [IrisRow] -> IrisNetwork -> Int -> IO IrisNetwork    run trainData testData network iterationNum = do      sampledRecords <- V.toList <$> chooseRandomRecords (V.fromList trainData)      -- Slowly drop the learning rate      let revisedParams = learningParams             { learningRate = learningRate learningParams * 0.99 ^ iterationNum}      let newNetwork = foldl' (trainRow revisedParams) network sampledRecords      let labelVectors = fmap (testRow newNetwork) testData      let labelValues = fmap getLabels labelVectors      let total = length labelValues      let correctEntries = length $ filter ((==) <$> fst <*> snd) labelValues      putStrLn $ "Iteration: " ++ show iterationNum      putStrLn $ show correctEntries ++ " correct out of: " ++ show total      return newNetwork 4. Run it! We’ll call this now from our main function, iterating 100 times, and we’re done! runIris :: FilePath -> FilePath -> IO ()runIris trainingFile testingFile = do ...  if length trainingData /= length trainingRecords || length testData /= length testRecords    then putStrLn "Hmmm there were some problems parsing the data"    else foldM_ (run trainingData testData) initialNetwork [1..100] Comparing to Tensor Flow So now that we’ve looked at a different library, we can consider how it stacks up against Tensor Flow. So first, the advantages. Grenade’s main advantage is that it provides dependent type facilities. This means it is more difficult to write incorrect programs. The basic networks you build are guaranteed to have the correct dimensionality. Additionally, it does not use a “placeholders” system, so you can avoid those kinds of errors too. This means you’re likely to have fewer runtime bugs using Grenade. Concision is another major strong point. The training code got a bit involved when translating our data into Grenade’s format. But it’s no more complicated than Tensor Flow. When it comes down to the exact definition of the network itself, we do this in only a few lines with Grenade. It’s complicated to understand what those lines mean if you are new to dependent types. But after seeing a few simple examples you should be able to follow the general pattern. Of course, none of this means that Tensor Flow is without its advantages. As we saw a couple weeks ago, it is not too difficult to add very thorough logging to your Tensor Flow program. The Tensor Board application will then give you excellent visualizations of this data. It is somewhat more difficult to get intermediate log results with Grenade. There is not too much transparency (that I have found at least) into the inner values of the network. The network types are composable though. So it is possible to get intermediate steps of your operation. But if you break your network into different types and stitch them together, you will remove some of the concision of the network. Also, Tensor Flow also has a much richer ecosystem of machine learning tools to access. Grenade is still limited to a subset of the most common machine learning layers, like convolution and max pooling. Tensor Flow’s API allows approaches like support vector machines and linear models. So Tensor Flow offers you more options. One question I may explore in a future article would be to compare the performance of the two libraries. My suspicion is that Tensor Flow is faster due to how it gets all its math down to the C-level. But I’m not too familiar yet with HMatrix (which Grenade depends on for its math) and its efficiency. So I could definitely be wrong. Conclusion Grenade provides some truly awesome facilities for building a concise neural network. A Grenade program can demonstrate at compile time that the network is well formed. It also allows an incredibly concise way to define what layers your neural network has. It doesn’t have the Google level support that Tensor Flow does. So it lacks many cool features like logging and visualizations. But it is quite a neat library for its scope. One thing I haven’t mentioned is its mechanics for Generative/Adversarial networks. I’d definitely like to try that out soon! Grenade is a simpler library to incorporate into Stack compared to Tensor Flow. If you want to compare the two, you should check out our so you can install TF and get started! Haskell Tensor Flow guide If you’ve never written a line of Haskell before, never fear! Download our for some free resources to start your Haskell education! Getting Started Checklist Appendix: Compiler Extensions and Imports {-# LANGUAGE DataKinds #-}{-# LANGUAGE BangPatterns #-}{-# LANGUAGE TupleSections #-}{-# LANGUAGE GADTs #-}

import           Control.Monad (foldM_)import           Control.Monad.Random (MonadRandom)import           Control.Monad.IO.Class (liftIO)import           Data.Foldable (foldl')import           Data.Maybe (mapMaybe)import qualified Data.Vector.Storable as VSimport qualified Data.Vector as Vimport           GHC.Float (float2Double)import           Grenadeimport           Grenade.Core.LearningParameters (LearningParameters(..))import           Grenade.Core.Shape (fromStorable)import           Grenade.Utils.OneHot (oneHot)import           Numeric.LinearAlgebra (maxIndex)import           Numeric.LinearAlgebra.Static (extract)

import           Processing (IrisRecord(..), readIrisFromFile, chooseRandomRecords)

Grenade! Dependently Typed Neural Networks

we built our first neural network and used it on a real machine learning problem. We took the Iris data set and built a classifier that took in various flower measurements. It determined, with decent accuracy, the type of flower the measurements referred to. Last week But we’ve still only seen half the story of Tensor Flow! We’ve constructed many tensors and combined them in interesting ways. We can imagine what is going on with the “flow”, but we haven’t seen a visual representation of that yet. We’re in luck though, thanks to the Tensor Board application. With it, we can visualize the computation graph we’ve created. We can also track certain values throughout our program run. In this article, we’ll take our Iris example and show how we can add Tensor Board features to it. Here’s the with all the code so you can follow along! Github repo Add an Event Writer The first thing to understand about Tensor Board is that it gets its data from a source directory. While we’re running our system, we have to direct it to write events to that directory. This will allow Tensor Board to know what happened in our training run. eventsDir :: FilePath
eventsDir = "/tmp/tensorflow/iris/logs/"

runIris :: FilePath -> FilePath -> IO ()
runIris trainingFile testingFile = withEventWriter eventsDir $ \eventWriter -> runSession $ do
... By itself, this doesn’t write anything down into that directory though! To understand the consequences of this, let’s boot up tensor board. Running Tensor Board Running our executable again doesn’t bring up tensor board. It merely logs the information that Tensor Board uses. To actually see that information, we’ll run the tensorboardcommand. >> tensorboard --logdir=’/tmp/tensorflow/iris/logs’
Starting TensorBoard 47 at http://0.0.0.0:6006 Then we can point our web browser at the correct port. Since we haven’t written anything to the file yet, there won’t be much for us to see other than some pretty graphics. So let’s start by logging our graph. This is actually quite easy! Remember our model? We can use the logGraph function combined with our event writer so we can see it. model <- build createModel
logGraph eventWriter createModel Now when we refresh Tensor Flow, we’ll see our system’s graph. But, it’s very large and very confusing. The names of all the nodes are a little confusing, and it’s not clear what data is going where. Plus, we have no idea what’s going on with our error rate or anything like that. Let’s make a couple adjustments to fix this. Adding Summaries So the first step is to actually specify some measurements that we’ll have Tensor Board plot for us. One node we can use is a “scalar summary”. This provides us with a summary of a particular value over the course of our training run. Let’s do this with our errorRate node. We can use the simple scalarSummary function. errorRate_ <- render $ 1 - (reduceMean (cast correctPredictions))
scalarSummary "Error" errorRate_ The second type of summary is a histogram summary. We use this on a particular tensor to see the distribution of its values over the course of the run. Let’s do this with our second set of weights. We need to use readValue to go from a Variable to a Tensor. (finalWeights, finalBiases, finalResults) <-
  buildNNLayer numHiddenUnits irisLabels rectifiedHiddenResults
histogramSummary "Weights" (readValue finalWeights) So let’s run tensor flow again. We would expect to see these new values show up under the Scalars and Histograms tabs. But they don’t. This is because we still to write these results to our event writer. And this turns out to be a little complicated. First, before we start training, we have to create a tensor representing all our summaries. logGraph eventWriter createModel
summaryTensor <- build mergeAllSummaries Now if we had no placeholders, we could run this tensor whenever we wanted, and it would output the values. But our summary tensors depend on the input placeholders, which complicates the matter. So here’s what we’ll do. We’ll only write out the summaries when we check our error rate (every 100 steps). To do this, we have to change our error rate in the model to take the summary tensor as an extra argument. We’ll also have it add a ByteString as a return value to the original Float. data Model = Model
  { train :: TensorData Float
          -> TensorData Int64
          -> Session ()
  , errorRate :: TensorData Float
              -> TensorData Int64
              -> SummaryTensor
              -> Session (Float, ByteString)
  } Within our model definition, we’ll use this extra parameter. It will run both the errorRate_ tensor AND the summary tensor together with the feeds: return $ Model
  , train = ...
  , errorRate = \inputFeed outputFeed summaryTensor -> do
      (errorTensorResult, summaryTensorResult) <- runWithFeeds
        [ feed inputs inputFeed
        , feed outputs outputFeed
        ]
        (errorRate_, summaryTensor)
      return (unScalar errorTensorResult, unScalar summaryTensorResult) Now we need to modify our calls to errorRate below. We’ll pass the summary tensor as an argument, and get the bytes as output. We’ll write it to our event writer (after decoding), and then we’ll be done! -- Training
  forM_ ([0..1000] :: [Int]) $ \i -> do
    trainingSample <- liftIO $ chooseRandomRecords trainingRecords
    let (trainingInputs, trainingOutputs) = convertRecordsToTensorData trainingSample
    (train model) trainingInputs trainingOutputs
    when (i `mod` 100 == 0) $ do
      (err, summaryBytes) <- (errorRate model) trainingInputs trainingOutputs summaryTensor
      let summary = decodeMessageOrDie summaryBytes
      liftIO $ putStrLn $ "Current training error " ++ show (err * 100)
      logSummary eventWriter (fromIntegral i) summary

  liftIO $ putStrLn ""

  -- Testing
  let (testingInputs, testingOutputs) = convertRecordsToTensorData testRecords
  (testingError, _) <- (errorRate model) testingInputs testingOutputs summaryTensor
  liftIO $ putStrLn $ "test error " ++ show (testingError * 100) Now we can see what our summaries look like by running tensor board again! Scalar Summary for our Error Histogram Summary for our Weights Annotating our Graph Now let’s look back to our graph. It’s still a bit confusing. We can clean it up a lot by creating “name scopes”. A name scope is part of the graph that we set aside under a single name. When Tensor Board generates our graph, it will create one big block for the scope. We can then zoom in and examine the individual nodes if we want. We’ll make three different scopes. First, we’ll make a scope for each of the hidden layers of our neural network. This is quite easy, since we already have a function for creating these. All we have to do is make the function take an extra parameter for the name of the scope we want. Then we wrap the whole function within the withNameScope function. buildNNLayer :: Int64 -> Int64 -> Tensor v Float -> Text
             -> Build (Variable Float, Variable Float, Tensor Build Float)
buildNNLayer inputSize outputSize input layerName = withNameScope layerName $ do
  weights <- truncatedNormal (vector [inputSize, outputSize]) >>= initializedVariable
  bias <- truncatedNormal (vector [outputSize]) >>= initializedVariable
  let results = (input `matMul` readValue weights) `add` readValue bias
  return (weights, bias, results) We supply our name further down in the code: (hiddenWeights, hiddenBiases, hiddenResults) <- 
  buildNNLayer irisFeatures numHiddenUnits inputs "layer1"
let rectifiedHiddenResults = relu hiddenResults
(finalWeights, finalBiases, finalResults) <-
  buildNNLayer numHiddenUnits irisLabels rectifiedHiddenResults "layer2" Now we’ll add a scope around all our error calculations. First, we combine these into an action wrapped in withNameScope. Then, observing that we need the errorRate_ and train_ steps, we return those from the block. That’s it! (errorRate_, train_) <- withNameScope "error_calculation" $ do
    actualOutput <- render $ cast $ argMax finalResults (scalar (1 :: Int64))
    let correctPredictions = equal actualOutput outputs
    er <- render $ 1 - (reduceMean (cast correctPredictions))
    scalarSummary "Error" er

    let outputVectors = oneHot outputs (fromIntegral irisLabels) 1 0
    let loss = reduceMean $ fst $ softmaxCrossEntropyWithLogits finalResults outputVectors
    let params = [hiddenWeights, hiddenBiases, finalWeights, finalBiases]
    tr <- minimizeWith adam loss params
    return (er, tr) Now when we look at our graph, we see that it’s divided into three parts: our two layers, and our error calculation. All the information flows among these three parts (as well as the “Adam” optimizer portion). Much Better Conclusion By default, Tensor Board graphs can look a little messy. But by adding a little more information to the nodes and using scopes, you can paint a much clearer picture. You can see how the data flows from one end of the application to the other. We can also use summaries to track important information about our graph. We’ll use this most often for the loss function or error rate. Hopefully, we’ll see it decline over time. Next week we’ll add some more complexity to our neural networks. We’ll see new tensors for convolution and max pooling. This will allow us to solve the more difficult MNIST digit recognition problem. Stay tuned! If you’re itching to try out some Tensor Board functionality for yourself, check out our . It goes into more detail about the practical aspects of using this library. If you want to get the Haskell Tensor Flow library running on your local machine, check it out! Trust me, it’s a little complicated, unless you’re a Stack wizard already! in-depth Tensor Flow guide And if this is your first exposure to Haskell, try it out! Take a look at our guide to with the language! getting started

Putting the Flow in Tensor Flow!

Two weeks ago, we began our machine study in earnest by constructing a full neural network. But this network was still quite simple by deep learning standards. In this article, we’re going to tackle a much more difficult problem: image recognition. Of course, we’ll still be using a well known data set with well-known results, so this is only the tip of the iceberg. We’ll be using the . This set classifies images of handwritten digits as the numbers 0–9. This problem is so well-known that the folks at Tensor Flow refer to it as the “Hello World” of machine learning. MNIST data set We’ll start this problem by using a very similar approach to what we used with the Iris data set. We’ll make a fully-connected neural network with two layers, and then use the “Adam” optimizer. This will give us some decent results by our beginner standards. But MNIST is a well known problem with a very large data set. So we’re going to hold ourselves to a higher standard of accuracy this time. This will force us to use some more advanced techniques. But to start with, let’s examine what we need to change to adapt our Iris model to work for the MNIST problem. As with the last couple weeks, the code for all this is on if you want to follow along. Github Re-use and Recycle! Generally, we can re-use most of the code we had with Iris, which is good news! We still have to make a few adjustments here and there though. First, we’ll use some different constants. We’ll use in place of , and instead of . We’ll also bump up the size of our hidden layer and the number of samples we’ll draw on each iteration: mnistFeatures irisFeatures mnistLabels irisLabels mnistFeatures :: Int64mnistFeatures = 784

mnistLabels :: Int64mnistLabels = 10

numHiddenUnits :: Int64numHiddenUnits = 1024

sampleSize :: IntsampleSize = 1000 We’ll also change our model to use as the result type instead . Word8 Int64 data Model = Model { train :: TensorData Float         -> TensorData Word8 -- Used to be Int64         -> Session () , errorRate :: TensorData Float             -> TensorData Word8 -- Used to be Int64             -> SummaryTensor             -> Session (Float, ByteString) } Now we have to change how we get our input data. Our data isn’t in CSV format this time. We’ll use helper functions from the Tensor Flow library to extract the images and labels: import TensorFlow.Examples.MNIST.Parse (readMNISTSamples, readMNISTLabels)…runDigits :: FilePath -> FilePath -> FilePath -> FilePath -> IO ()runDigits trainImageFile trainLabelFile testImageFile testLabelFile =  withEventWriter eventsDir $ \eventWriter -> runSession $ do

   -- trainingImages, testImages :: [Vector Word8]   trainingImages <- liftIO $ readMNISTSamples trainImageFile   testImages <- liftIO $ readMNISTSamples testImageFile

   -- traininglabels, testLabels :: [Word8]   trainingLabels <- liftIO $ readMNISTLabels trainLabelFile   testLabels <- liftIO $ readMNISTLabels testLabelFile

   -- trainingRecords, testRecords :: Vector (Vector Word8, Word8)   let trainingRecords = fromList $ zip trainingImages trainingLabels   let testRecords = fromList $ zip testImages testLabels   ... Our “input” type consists of vectors of elements. These represent the intensity of various pixels. Our “output” type is , referring to the actual labels (0-9). We read the images and labels from separate files. Then we zip them together to pass to our processing functions. We’ll have to make a few changes to these processing functions for this data set. First, we have to generalize the type of our randomization function: Word8 Word8 -- Used to be IrisRecord SpecificchooseRandomRecords :: Vector a -> IO (Vector a) Next we have to write a new encoding function that will put our data into the format. This looks like our old version, except dealing with the new tuple type instead of the . TensorData IrisRecord convertDigitRecordsToTensorData  :: Vector (Vector Word8, Word8) -> (TensorData Float, TensorData Word8)convertDigitRecordsToTensorData records = (input, output) where   numRecords = Data.Vector.length records    input = encodeTensorData [fromIntegral numRecords, mnistFeatures]     (fromList $ concatMap recordToInputs records)   output = encodeTensorData [fromIntegral numRecords] (snd <$> records)   recordToInputs :: (Vector Word8, Word8) -> [Float]   recordToInputs rec = fromIntegral <$> (toList . fst) rec And then we just have to substitute our new functions and parameters in, and we’ll be able to run our digit trainer! Current training error 89.8Current training error 19.300001Current training error 13.300001Current training error 11.199999Current training error 8.700001Current training error 6.5999985Current training error 6.999999Current training error 5.199999Current training error 4.400003Current training error 5.000001Current training error 2.3000002

test error 6.830001 So our accuracy is 93.2%. This seems like an alright number. But imagine being a Post office and having 6.8% of your mail sorted into the wrong Zip Code! (This was the original use case of this data set). So let’s see if we can do better. Convolution and Max Pooling Now we could train our model longer. This will tend to improve our error rate. But we can also help ourselves by making our model more complex. The fundamental flaw with what we’ve got so far is that it doesn’t account for the 2D nature of the images. This means we’re losing a ton of useful information. So the first thing we’ll do is treat our images as being 28x28 tensors instead of 1x784. This way, our model can pick out specific areas that are significant for the identification of the digit. One thing we want to account for is that our image might not be in the center of the frame. To account for this, we’re going to apply convolution. When using convolution, we break the image into many different overlapping tiles. In our case, we’ll make our strides size “1” in every direction, and we’ll use a patch size of 5x5. So this means we’ll center a 5x5 tile around each different pixel in our image, and then come up with a score for it. That score tells us if this part of the image contains any important information. We can represent this score as a vector with many features. So with 2D convolution, we’ll be dealing with 4-dimensional tensors. The first dimension is the sample size. The second two dimensions are the shape of the image. The final dimension is the number of features of the “score” for each part of the image. So each original image starts our with a single feature for the “score” of each pixel. This score is the actual intensity of that pixel! Then each layer of convolution will act as a mini neural network per pixel, making as many features as we want. Max pooling is a form of down-sampling. After our first convolution step, we’ll have scores on the 28x28 image. We’ll use 2x2 max-pooling, meaning we divide each image into 2x2 squares. Then we’ll make a new layer that is 14x14, using only the “best” score from each 2x2 box. This makes our model more efficient while keeping the most important information. Simple demonstration of max-pooling Implementing Convolutional Layers We’ll do two rounds of convolution and max pooling. So we’ll make a function that creates a layer that performs these two steps. This will look a lot like our other neural network layer. We’ll take parameters for the size of the input and output channels of the layer, as well as the tensor itself. So our first step will be to create the weights and bias tensors using these parameters: patchSize :: Int64patchSize = 5

buildConvPoolLayer :: Int64 -> Int64 -> Tensor v Float -> Text                  -> Build (Variable Float, Variable Float, Tensor Build Float)buildConvPoolLayer inputChannels outputChannels input layerName = withNameScope layerName $ do weights <- truncatedNormal (vector weightsShape)   >>= initializedVariable bias <- truncatedNormal (vector [outputChannels]) >>= initializedVariable ... where   weightsShape :: [Int64]   weightsShape = [patchSize, patchSize, inputChannels, outputChannels] Now we’ll want to call our convolution and max pooling functions. These are still a little rough around the edges (the Haskell library is still quite young). The C versions of these functions have many optional, named attributes. For the moment there don’t seem to be any functions that use normal Haskell values for these arguments. Instead, we’ll be using values, assign bytestring names to values. OpAttr where ... convStridesAttr = opAttr "strides" .~ ([1,1,1,1] :: [Int64]) poolStridesAttr = opAttr "strides" .~ ([1,2,2,1] :: [Int64]) poolKSizeAttr = opAttr "ksize" .~ ([1,2,2,1] :: [Int64]) paddingAttr = opAttr "padding" .~ ("SAME" :: ByteString) dataFormatAttr = opAttr "data_format" .~ ("NHWC" :: ByteString) convAttrs = convStridesAttr . paddingAttr . dataFormatAttr poolAttrs = poolKSizeAttr . poolStridesAttr . paddingAttr . dataFormatAttr The argument for convolution refers to how much we shift the window each time. The argument for pooling refers to how big the windows will be that we perform the pooling over. In this case, it's 2x2. Now that we have our attributes, we can call the library functions and . This gives our resulting vector. We also throw in a call to between these steps. strides strides conv2D’ maxPool’ relu buildConvPoolLayer :: Int64 -> Int64 -> Tensor v Float -> Text                  -> Build (Variable Float, Variable Float, Tensor Build Float)buildConvPoolLayer inputChannels outputChannels input layerName = withNameScope layerName $ do weights <- truncatedNormal (vector weightsShape)   >>= initializedVariable bias <- truncatedNormal (vector [outputChannels]) >>= initializedVariable let conv = conv2D' convAttrs input (readValue weights)       `add` readValue bias let results = maxPool' poolAttrs (relu conv) return (weights, bias, results) where   ... Modifying our Model Now we’ll make a few updates to our model and we’ll be in good shape. First, we need to reshape our input data to be 4-dimensional. Then, we’ll apply the two convolution/pooling layers: imageDimen :: Int32imageDimen = 28

createModel :: Build ModelcreateModel = do let batchSize = -1 -- Allows variable sized batches let conv1OutputChannels = 32 let conv2OutputChannels = 64 let denseInputSize = 7 * 7 * 64 :: Int32 -- 3136 let numHiddenUnits = 1024

 inputs <- placeholder [batchSize, mnistFeatures] outputs <- placeholder [batchSize]

 let inputImage = reshape inputs (vector [batchSize, imageDimen, imageDimen, 1])

 (convWeights1, convBiases1, convResults1) <-    buildConvPoolLayer 1 conv1OutputChannels inputImage "convLayer1" (convWeights2, convBiases2, convResults2) <-   buildConvPoolLayer conv1OutputChannels conv2OutputChannels convResults1 "convLayer2" Once we’re done with that, we’ll apply two fully-connected (dense) layers as we did before. Note we’ll reshape our result from four dimensions back down to two: let denseInput = reshape convResults2 (vector [batchSize, denseInputSize])(denseWeights1, denseBiases1, denseResults1) <-  buildNNLayer (fromIntegral denseInputSize) numHiddenUnits denseInput "denseLayer1"  let rectifiedDenseResults = relu denseResults1(denseWeights2, denseBiases2, denseResults2) <-   buildNNLayer numHiddenUnits mnistLabels rectifiedDenseResults "denseLayer2" And after that we can treat the rest of the model the same. We’ll update the parameter names and add the new weights and biases to the that the model can change. params As a review, let’s look at the dimensions of each of the intermediate tensors here. Then we can see the restrictions on the dimensions of the different operations. Each convolution step takes two four-dimensional tensors. The final dimension of argument 1 must match the third dimension of argument 2. Then the result will swap in the final dimension of argument 2. Meanwhile, pooling with a 2x2 stride size will take this resulting 4-dimensional tensor and halve each of the inner dimensions. input: n x 784inputImage: n x 28 x 28 x 1convWeights1: 5 x 5 x 1 x 32convBias1: 32conv (first layer): n x 28 x 28 x 32convResults1: n x 14 x 14 x 32convWeights2:  5 x 5 x 32 x 64conv (second layer): n x 14 x 14 x 64convResults2: n x 7 x 7 x 64denseInput: n x 3136denseWeights1: 3136 x 1024denseBias1: 1024denseResults1: n x 1024denseWeights2: 1024 x 10denseBias2: 10denseResults2: n x 10 So for each input, we’ll have a probability for all 10 of the possible inputs. We pick the greatest of these as the chosen label. Results We’ll run our model again, only this time we’ll use a smaller sample size (100 per training iteration). This allows us to train for more iterations (20000). This takes quite a while to train, but we get these results (printed every 1000 iterations). Current training error 91.0Current training error 6.0Current training error 2.9999971Current training error 2.9999971Current training error 0.0Current training error 0.0Current training error 0.99999905Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0Current training error 0.0

test error 1.1799991 Not too bad! Once it got going, we saw very few training errors, though still ended up with a model that was a tad overfit. The Tensor Flow MNIST suggests using a dropout factor. This helps diminish the effects of overfitting. But this option isn’t available to us yet in Haskell. Still, we got close to 99% accuracy, which is a success for us! expert tutorial And here’s what our final graph looks like. Notice the extra layers we added for convolution: Conclusion So that’s it for convolutional neural networks! Our goal was to adapt our previous neural network model to recognize digits. Not only did we pick a harder problem, but we also wanted higher accuracy. We achieved this by using more advanced machine learning techniques. Convolution allowed us to use the full 2x2 nature of the image. It also checked for the digit no matter where it was in the image. Max pooling enabled us to make our algorithm more efficient while keeping the most important information. If you’re itching to see what else Haskell can do with Tensor Flow, check out our . It’ll walk you through some of the trickier parts of getting the library working on your local machine. It will also go through the most important information you need to know about the types in this library. Tensor Flow Guide If you’re new to Haskell, here are a couple more resources you can dig into before you try your hand at Tensor Flow. First, there’s our . This will point you toward some helpful resources for learning the language. Next, you can check out our so you can learn how to organize a project! If you want to use Tensor Flow in Haskell, Stack is a must! Getting Started Checklist Stack mini-course

Deeper Still: Convolutional Neural Networks

Last week we got acquainted with the core concepts of Tensor Flow. We learned about the differences between constants, placeholders, and variable tensors. Both the Haskell and Python bindings have functions to represent these. The Python version was a bit simpler though. Once we had our tensors, we wrote a program that “learned” a simple linear equation. This week, we’re going to solve an actual machine learning problem. We’re going to use the , which contains measurements of different Iris flowers. Each flower belongs to one of three species. Our program will “learn” a function choosing the species from the measurements. This function will involved a fully-connected neural network. Iris data set Formatting our Input The first step in pretty much any machine learning problem is data processing. After all, our data doesn’t magically get resolved into Haskell data types. Luckily, is a great library to help us out. The Iris data set consists of data in .csv files that each have a header line and then a series of records. They look a bit like this: Cassava 120,4,setosa,versicolor,virginica6.4,2.8,5.6,2.2,25.0,2.3,3.3,1.0,14.9,2.5,4.5,1.7,24.9,3.1,1.5,0.1,0... Each line contains one record. A record has four flower measurements, and a final label. In this case, we have three types of flowers we are trying to classify between: Iris Setosa, Iris Versicolor, and Iris Virginica. So the last column contains the numbers 0,1, and 2, corresponding to these respective classes. Let’s create a data type representing each record. Then we can parse the file line-by-line. Our type will contain the feature data and the resulting label. This type will act as a bridge between our raw data and the tensor format we’ll need to run our learning algorithm. We’ll derive the “Generic” typeclass for our record type, and use this to get . Once our type has an instance for , we can parse it with ease. As a note, throughout this article, I’ll be the imports section from the code samples. I’ve included a full list of imports from these files as an appendix at the bottom. We'll also be using the extension throughout. IrisRecord FromRecord FromRecord omitting OverloadedLists {-# LANGUAGE DeriveGeneric #-}{-# LANGUAGE OverloadedLists #-}

...

data IrisRecord = IrisRecord  { field1 :: Float  , field2 :: Float  , field3 :: Float  , field4 :: Float  , label  :: Int64  }  deriving (Generic)

instance FromRecord IrisRecord Now that we have our type, we’ll write a function, , that will read our data in from a CSV file. readIrisFromFile readIrisFromFile :: FilePath -> IO (Vector IrisRecord)readIrisFromFile fp = do  contents <- readFile fp  let contentsAsBs = pack contents  let results = decode     HasHeader contentsAsBs :: Either String (Vector IrisRecord)  case results of    Left err -> error err    Right records -> return records We won’t want to always feed our entire data set into our training system. So given a whole slew of these items, we should be able to pick out a random sample. sampleSize :: IntsampleSize = 10

chooseRandomRecords :: Vector IrisRecord -> IO (Vector IrisRecord)chooseRandomRecords records = do  let numRecords = Data.Vector.length records  chosenIndices <-     take sampleSize <$> shuffleM [0..(numRecords - 1)]  return $ fromList $ map (records !) chosenIndices Once we’ve selected our vector of records to use for each run, we’re still not done. We need to take these records and transform them into the that we’ll feed into our algorithm. We create items of by feeding in a shape and then a 1-dimensional vector of values. First, we need to know the shapes of our input and output. Both of these depend on the number of rows in the sample. The “input” will have a column for each of the four features in our set. The output meanwhile will have a single column for the label values. TensorData TensorData irisFeatures :: Int64irisFeatures = 4

irisLabels :: Int64irisLabels = 3

convertRecordsToTensorData :: Vector IrisRecord                            -> (TensorData Float, TensorData Int64)convertRecordsToTensorData records = (input, output)  where    numRecords = Data.Vector.length records     input = encodeTensorData       [fromIntegral numRecords, irisFeatures] (undefined)    output = encodeTensorData       [fromIntegral numRecords] (undefined) Now all we need to do is take the various records and turn them into one dimensional vectors to encode. Here’s the final function: convertRecordsToTensorData :: Vector IrisRecord                            -> (TensorData Float, TensorData Int64)convertRecordsToTensorData records = (input, output)  where    numRecords = Data.Vector.length records     input = encodeTensorData       [fromIntegral numRecords, irisFeatures]      (fromList $ concatMap recordToInputs records)    output = encodeTensorData       [fromIntegral numRecords]       (label <$> records)    recordToInputs :: IrisRecord -> [Float]    recordToInputs rec =       [field1 rec, field2 rec, field3 rec, field4 rec] Neural Network Basics Now that we’ve got that out of the way, we can start writing our model. Remember, we want to perform two different actions with our model. First, we want to be able to take our training input and train the weights. Second, we want to be able to pass a test data set and determine the error rate. We can represent these two different functions as a single object. Remember the monad, where we run all our Tensor Flow activities. The training will run an action that alters the variables but returns nothing. The error rate calculation will return us a float value. Model Session data Model = Model  { train :: TensorData Float -- Training input          -> TensorData Int64 -- Training output          -> Session ()  , errorRate :: TensorData Float -- Test input              -> TensorData Int64 -- Test output              -> Session Float  } Now we’re going to build a fully-connected neural network. We’ll have 4 input units (1 for each of the different features), and then we’ll have 3 output units (1 for each of the classes we’re trying to represent). In the middle, we’ll use a hidden layer consisting of 10 units. This means we’ll need two sets of weights and biases. We’ll write a function that, when given dimensions, will give us the variable tensors for each layer. We want the weight and bias tensors, plus the result tensor of the layer. buildNNLayer :: Int64 -> Int64 -> Tensor v Float             -> Build (Variable Float, Variable Float, Tensor Build Float)buildNNLayer inputSize outputSize input = do  weights <- truncatedNormal (vector [inputSize, outputSize]) >>=    initializedVariable  bias <- truncatedNormal (vector [outputSize]) >>=    initializedVariable  let results = (input `matMul` readValue weights) `add`                 readValue bias  return (weights, bias, results) We do this in the monad, which allows us to construct variables, among other things. We’ll use a distribution for all our variables to keep things simple. We specify the size of each variable in a tensor, and then initialize them. Then we’ll create the resulting tensor by multiplying the input by our weights and adding the bias. Build truncatedNormal vector Constructing our Model Now we’ll start building our object, again within the monad. We begin by specifying our input and output placeholders, as well the number of hidden units. We’ll also use a of -1 to account for the fact that we want a variable number of input samples. Model Build batchSize irisFeatures :: Int64irisFeatures = 4

irisLabels :: Int64irisLabels = 3-- ^^ From above

createModel :: Build ModelcreateModel = do  let batchSize = -1 -- Allows variable sized batches  let numHiddenUnits = 10  inputs <- placeholder [batchSize, irisFeatures]  outputs <- placeholder [batchSize] Then we’ll get the nodes for the two layers of variables, as well as their results. Between the layers, we’ll add a “rectifier” activation function : relu (hiddenWeights, hiddenBiases, hiddenResults) <-   buildNNLayer irisFeatures numHiddenUnits inputslet rectifiedHiddenResults = relu hiddenResults(finalWeights, finalBiases, finalResults) <-  buildNNLayer numHiddenUnits irisLabels rectifiedHiddenResults Now we have to get the inferred classes of each output. This means calling to take the class with the highest probability. We’ll also the vector and then it. These are some Haskell-Tensor-Flow specific terms for getting tensors to the right type. Next, we compare that against our output placeholders to see how many we got correct. Then we’ll make a node for calculating the error rate for this run. argMax cast render actualOutput <- render $ cast $   argMax finalResults (scalar (1 :: Int64))let correctPredictions = equal actualOutput outputserrorRate_ <- render $ 1 - (reduceMean (cast correctPredictions)) Now we have to actually do the work of training. First, we’ll make vectors for our expected outputs. This means converting the label into the vector , and so on. We’ll compare these values against our results (before we took the max), and this gives us our loss function. Then we will make a list of the parameters we want to train. The optimizer will minimize our loss function while modifying the params. oneHot 0 [1,0,0] adam let outputVectors = oneHot outputs (fromIntegral irisLabels) 1 0let loss = reduceMean $ fst $ softmaxCrossEntropyWithLogits finalResults outputVectorslet params = [hiddenWeights, hiddenBiases, finalWeights, finalBiases]train_ <- minimizeWith adam loss params Now we’ve got our and nodes ready. There's one last step here. We have to plug in for the placeholder values and create functions that will take in the tensor data. Remember the pattern from ? We use it again here. Finally, our model is complete! errorRate_ train_ feed last week return $ Model  { train = \inputFeed outputFeed ->       runWithFeeds        [ feed inputs inputFeed        , feed outputs outputFeed        ]        train_  , errorRate = \inputFeed outputFeed -> unScalar <$>      runWithFeeds        [ feed inputs inputFeed        , feed outputs outputFeed        ]        errorRate_  } Tying it all together Now we’ll write our main function that will run the session. It will have three stages. In the preparation stage, we’ll load our data, and use the function to get our model. Then we’ll train our model for 1000 steps by choosing samples and converting our records to data. Every 100 steps, we'll print the output. Finally, we’ll determine the resulting error ratio by using the test data. build runIris :: FilePath -> FilePath -> IO ()runIris trainingFile testingFile = runSession $ do  -- Preparation  trainingRecords <- liftIO $ readIrisFromFile trainingFile  testRecords <- liftIO $ readIrisFromFile testingFile  model <- build createModel

  -- Training  forM_ ([0..1000] :: [Int]) $ \i -> do    trainingSample <- liftIO $ chooseRandomRecords trainingRecords    let (trainingInputs, trainingOutputs) =          convertRecordsToTensorData trainingSample    (train model) trainingInputs trainingOutputs    when (i `mod` 100 == 0) $ do      err <- (errorRate model) trainingInputs trainingOutputs      liftIO $ putStrLn $         "Current training error " ++ show (err * 100)

  liftIO $ putStrLn ""

  -- Testing  let (testingInputs, testingOutputs) =         convertRecordsToTensorData testRecords  testingError <- (errorRate model) testingInputs testingOutputs  liftIO $ putStrLn $ "test error " ++ show (testingError * 100)

  return () Results So when we actually run all this output, we’ll get the following results on our test set. Current training error 60.000004Current training error 30.000002Current training error 39.999996Current training error 19.999998Current training error 10.000002Current training error 10.000002Current training error 19.999998Current training error 19.999998Current training error 10.000002Current training error 10.000002Current training error 0.0

test error 3.333336 Our test sample size was 30, so this means we got 29/30 this time around. Results change though from run to run (I obviously used the best results I found). Since our sample size is so small, we have high entropy here (sometimes the error rate is like 40%). Generally we’ll want to train longer on a larger test set, so that we get more consistent results, but this is a good start. Conclusion In this article we went over the basics of making a neural network using the Haskell Tensor Flow library. We made a fully-connected neural network and fed in real data we parsed using the library. This network was able to learn a function to classify flowers from the Iris data set. Considering the small amount of data, we got some good results. Cassava Come back next week, where we’ll see how we can add some more summary information to our tensor flow graph. We’ll use the tensor board application to view our graph in a visual format. For more details on installing the Haskell Tensor Flow system, check out our . It should walk you through the important steps in running the code on your own machine. In-Depth Tensor Flow Tutorial Perhaps you’ve never tried Haskell before at all, and want to see what it’s like. Maybe I’ve convinced you that Haskell is in fact the future of AI. In that case, you should check out our for some tools on starting with the language. Getting Started Checklist Appendix: All Imports Documentation for Haskell Tensor Flow is still a major work in progress. So I want to make sure I explicitly list the modules you need to import for all the different functions we used here. import Control.Monad (forM_, when)import Control.Monad.IO.Class (liftIO)import Data.ByteString.Lazy.Char8 (pack)import Data.Csv (FromRecord, decode, HasHeader(..))import Data.Int (Int64)import Data.Vector (Vector, length, fromList, (!))import GHC.Generics (Generic)import System.Random.Shuffle (shuffleM)

import TensorFlow.Core (TensorData, Session, Build, render, runWithFeeds, feed, unScalar, build,                        Tensor, encodeTensorData)import TensorFlow.Minimize (minimizeWith, adam)import TensorFlow.Ops (placeholder, truncatedNormal, add, matMul, relu,                      argMax, scalar, cast, oneHot, reduceMean, softmaxCrossEntropyWithLogits,                       equal, vector)import TensorFlow.Session (runSession)import TensorFlow.Variable (readValue, initializedVariable, Variable)

Digging in Deep: Solving a Real Problem with Haskell Tensor Flow

This image is a nice representation of how modern web-applications work. I found it on this article about Web API’s on a Raspberry Pi In the last year we, at , have developed several React-based applications. Greenhouse Group One of the latest projects I’m working on is an internal tool to monitor marketing expenses for the marketeers within our company. It was my responsibility to set up this new tool based upon the experiences we’ve gained and from a proof of concept the team had built. I would like to share with you the story on how we created this application. What tools did we use and where we diverted from the traditional paths. Our toolkit To give you an idea of he tools we use, here’s a list of what’s in our day-to-day toolkit: t We use to transpile our ES6 written code to be production-ready. Webpack is running as our dev-server and is the engine for building and compiling our code to the acceptance and production environments. For linting we rely on (The with some customisations) and we use for testing our code. Babel 6 ESLint AirBnB preset Jest When we initially started we knew we had to implement some sort of state-management where we could store data application-wide rather than just per component to be more persistent while the user switched between views. From the moment when we started React development, we embraced and we use it ever since. Although it might have it flaws and is not as extensive as for example, it serves our purpose and until today has not given us any implementation problems. Redux Mobx Adding API requests to React When you’re creating a web-application just having a static frontend isn’t enough. We need the data from our API’s and in Javascript the traditional way to get that is by . Since we are building internal applications (and one of them is even an Electron app) we don’t have to worry much about browser coverage. We are only required to support Google Chrome, so even before we implemented API calls with XMLHttpRequest we decided to give that new a try. XMLHttpRequests Fetch API Then the next questions arise, how do you make API requests with React? The most common answer was in that time (beginning 2016) to do them in . The response you got from the request would be stored in the Component’s local state and you are able to render the fetched data. ComponentDidMount But with data in 1 component, how do you get the same data to a sibling? Moving API requests away from the component Should we move the request to the parent? But what if we would sync that “component-state” with Redux and make it available in the application-wide state? An option was to move the request to the state’s actions. But actions may not be blocking, while a Fetch request is. So the next step was to figure out . With Redux-Thunk you’ll get a middleware which reacts on Redux actions, does it things and then dispatches other actions again. Redux-Thunk We fiddled with thunks for a while, but we ended up with quite some side-effects which gave testing problems and weren’t so easy to read. With the thunks you would dispatch an action, which then did its work and dispatched another action. It might be that our approach was a bit off or that it just hadn’t matured enought, but we were looking for a way where it was easier to follow what the side-effects were of our actions within the state. Then Redux-Saga came in It was October 2016 when we met , quite fast we figured it could solve our problems. And after some concepts and less then a month later we integrated our first Saga in one of our applications. The main difference between Thunks and Saga’s is that where Thunks are controlled based upon the action that is dispatched, Saga’s listen independently to actions, more like reducers and act upon that. Redux-Saga In Saga’s it’s less complex to ask for a certain task and depending on the payload and results of certain steps in a Saga results will kick off. Explained in actual code I want to give you an example of how we make API requests in our code, it might clear up this complex matter; Most of our Components are wrapped with Redux’ connect, which we call Connectors. The most simple Connector may look like this: import { connect } from 'react-redux';import App from 'components/app';export default connect()(App); Once a Component is mounted we would like to fetch data so it can be shown within the render of our Component. This is one of those components: import React from 'react';export default class App extends Component {    componentDidMount() {        this.props.fetchRecords();    }        render() {        const { records } = this.props;                return (            <div className="app">                {records.map(record => (                    <div className="record" key={record.id}>{record.name}</div>                ))}            </div>        );    }} (To keep my code blocks small, I didn’t add PropTypes in the samples) As you can see, I used 2 props that weren’t included in the intial Connector. So I have to edit that file. I’ll add a dispatchToProps to the Redux connect and a stateToProps. The first one will, once called, dispatch an action to the store. The stateToProps will pass data directly from the records reducers to the Component. In my example I’ll load the data directly from state, however internally we make use of Selectors (often in combination with ) for easier re-use of state selectors and to optimize rendering once the reference of reducers changed, but the data itself hasn’t. Reselect import { connect } from 'react-redux';import App from 'components/app';import fetchRecords from 'actions/fetch-records';const stateToProps = state => ({    records: state.records.data});const dispatchToProps = {    fetchRecords};export default connect()(App); Now, once the Component is mounted it will call , which is due to the Redux Connect a function which will dispatch the action to the store. fetchRecords fetchRecords I have to add the following code to add a Saga which listens for . Since I will not explain Redux-Saga in details in this article, Assume that I have a rootSaga which will my newly created Saga. fetchRecords spawn import { takeLatest, put, call } from 'redux-saga/effects';import fetchFailed from 'actions/fetch-failed';import setRecords from 'actions/set-records';export default function* onFetchRecords() {  yield takeLatest('RECORDS/FETCH', function fetchRecords() {    try {        const response = yield call(fetch, 'https://api.service.com/endpoint');        const responseBody = response.json();    } catch (e) {        yield put(fetchFailed(e));        return;    }    yield put(setRecords(responseBody.records));  });} In the example above you can see that it will listen for , once that action comes by it will do a Fetch request. When the Fetch fails it will throw an exception. In that case we will dispatch the action. When the request succeeds it will dispatch and will pass the records we got from the server. RECORDS/FETCH fetchFailed setRecords Here you can see how our Reducer can handle those actions together with our Saga; export default (state = {data: [], loading: false}, action = {}) => {  switch (action.type) {    case 'RECORDS/FETCH':    case 'RECORDS/FETCH_FAILED':      return {          ...state,          loading: true,          data: []      };    case 'RECORDS/SET':      return {          ...state,          loading: false,          data: action.payload      };    default:      return state;  }}; With these small pieces of code I’ve showed you a initial example of how you can move your API calls from ComponentDidMount to Redux Saga’s and have your data easily available in your Reducers in stead of only Component state. Interested in more about this topic or does this sound cooler than you do in your day to day job? Let me know!

Stories, News & Mentions about MEETRECORD

Meetrecord’s Stories on HackerNoon