Forem: Austin

Build It, Block It, Visualize It: Introducing Unify Viz Blocks 2.0

Austin — Tue, 09 Apr 2024 09:50:25 +0000

Hello Everyone! 🌟 Welcome to Unify Viz Blocks 2.0!

We're excited to share some big news with you. Our team has been working hard, and it’s finally here: Unify Viz Blocks 2.0! With this update, we're adding more than 500 new blocks to our already robust library, empowering you to create even more stunning charts, graphs, and dashboards directly within Unify.

Designed for Deeper Insights and Engagement

Each block has been meticulously crafted to not only enhance the visual appeal of your data presentations but also to make data analysis more intuitive and insightful. From dynamic area charts and detailed bar graphs to insightful funnel charts, comprehensive heatmap blocks, and revealing scatter plots, Unify Viz Blocks 2.0 offers a diverse range of options to suit your every need.

84 Area Chart Blocks: Visualize data trends over time with new levels of depth and clarity.
196 Bar Chart Blocks: Compare different data sets with ease, thanks to enhanced detail and customization options.
32 Funnel Chart Blocks: Track conversion rates and process efficiency with precision, identifying opportunities for improvement.
170 Heatmap Blocks: Discover patterns and correlations within your data, making complex data sets understandable at a glance.
40 Scatter Plot Blocks: Explore the relationships between variables, unlocking new insights with sophisticated analytical capabilities.

Empower Your Data Analysis Across Any Field

Unify Viz Blocks 2.0 is designed to be a game-changer across a variety of fields, whether you're in cybersecurity, finance, marketing, or any other domain where data plays a crucial role. Visualize data in ways that are not only more engaging but also provide clearer insights, helping you to make informed decisions based on complex data sets.

Simplifying Complexity

We understand the challenges of working with complex data, which is why we’ve focused on creating a user-friendly experience that doesn’t compromise on power or flexibility. Whether you’re a data scientist, a business analyst, or someone who just loves to explore data, Unify Viz Blocks 2.0 is designed to cater to your needs, simplifying the complex and bringing your data to life.

Ready to Transform Your Data?

Dive into the vast possibilities offered by Unify Viz Blocks 2.0 and start exploring your data in new, more meaningful ways. With over 250+ blocks at your fingertips, your ability to analyze, understand, and present data is about to reach new heights.

Join us in embracing the future of data visualization. Welcome to Unify Viz Blocks 2.0. Learn more →

Unify Viz - 300+ Premium charts for Figma and React

Austin — Tue, 26 Dec 2023 13:51:10 +0000

We are thrilled to announce the launch of Unify Viz. Prepare to revolutionize the way you analyze data with this feature-rich library of 300+ charts for Figma and React.

What is Unify Viz?

Unify Viz is a comprehensive set of Figma components and React code assets that empower users to effortlessly design and develop captivating data visualizations. It offers a vast selection of more than 300 chart combinations, ensuring that you will consistently discover the ideal graphic representation for your data. Additionally, Unify Viz is continuously updated with new chart options, providing you with an ever-expanding library of possibilities to enhance your data storytelling.

What sets Unify Viz apart?

While there are numerous Figma and React component libraries available, few offer both design assets and matching code. This often creates friction during the handoff process, as charts can be challenging to design and build with all their intricacies. With Unify Viz, your designer can simply copy and paste the component, adjust labels and colors, and share the code link with the developer. It's as simple as that! Every chart includes a corresponding Figma design and code sample for easy implementation.

What's included in Unify Viz?

We offer a comprehensive collection of 21 chart categories, each catering to different data visualization needs. These include an Area Chart, Line Chart, Bar Chart, Pie Chart, Donut Chart, Sankey Plot, Bubble Plot, Funnel Chart, Heatmap, Gauges, Map, Meter, Radial, Scatter, Sparklines, Treemap, Venn Diagram and more!

In addition to the extensive range of Base Charts, we also provide an impressive selection of 300+ Variations of these charts. This ensures that you have ample options to customize and tailor your visualizations to suit your specific requirements.

To enhance your design workflow, our package includes ready-to-use Figma Components. These components are designed to seamlessly integrate with your Figma projects and enable quick and efficient chart creation.

For developers using React, we offer a handy set of React Component Snippets. These snippets simplify the process of integrating our charts into your React applications, saving you valuable time and effort.

As part of our commitment to continuously enhance our offering, we provide free monthly updates. These updates include new charts, feature improvements, and bug fixes, ensuring that you always have access to the latest and greatest in data visualization.

For those seeking additional assistance, we offer optional support and consulting services. Our team of experts is available to provide guidance, answer questions, and help you maximize the value of our charts in your projects.
To cater to a wide range of app styles and preferences, our charts are available in both Light and Dark Color Schemes. Each scheme offers a diverse palette of colors, allowing you to find the perfect match for your app's visual identity.

Why did we create Unify Viz?

At Good Code, we work with customers of all sizes and have found that while there are many resources available, they often require additional assembly. This can be frustrating for developers who are just starting out or don't have time to build complex charts from scratch. We wanted to simplify the process by making it as easy as copy and paste. That's why we call it Unify – because we are unifying the design and development of data visualizations!

Previews

How can you get Unify Viz?

We launched the product today at https://store.goodcode.us. We hope you enjoy the package, and stay tuned for more amazing charts in future updates!

The cyber-security impacts of an AWS Outage

Austin — Wed, 08 Dec 2021 13:42:12 +0000

On the morning of December 7th, AWS had a major outage that effected a large portion of the us-east regions. The outage affected everything from the AWS Console to Disney+, Netflix and even home security devices such as Ring and Wyze.

The outage lasted a good duration of the afternoon where for a good portion of the time AWS service health dashboard didn't even report any issues per AWS: "This issue is also affecting some of our monitoring and incident response tooling."

For most people, it was an inconvenience but its situations like this where not only cyber criminals thrive but even average criminals can monopolize on this too.

Let's imagine you use a Ring camera ( without the security subscription ) to monitor your home while you're at work. Around lunch time, it was widely known that there was a major outage and even broadcasted on local TV news. Ordinary criminals become aware of the situation and act targeting anyone with that nice Ring sign in their front-yard.

Most products like Ring or Wyze have mandatory disclosures about outages like this; ironically enough I received one from Wyze which I have only a smart plug but never received one from Ring which I have setup around my entire home.

Now let's imagine your company has EC2 machines setup for monitoring or SAAS services to scan for phishing attempts or even security response automation. Sophisticated attackers have systems setup to monitor critical infrastructure like AWS for outages and then start attacks. If an attacker see that a system is down, they will launch a series of attacks to try and bypass the systems that might be down. If these systems are down then it creates opportunities for attacks to slide under the radar and likely never even be noticed until it's too late.

After everyone's PagerDuty alarms stop and the dust settles, situations like this can be good opportunities to remind organizations that putting all your eggs in one basket ( or us-east-1 in this case ) should be treated as a security vulnerability not just 'bad devops'.

These situations also highlight our reliance on infrastructure that most of us highlight as 'too big to fail' but it's better to be prepared for the worst than not.

Mergers & Acquisitions - For the JavaScript Developer

Austin — Fri, 10 Sep 2021 12:38:32 +0000

Introduction

Technology changes at lightning speed and for larger businesses to grow their core business but stay innovative and capture new markets, it's almost always easier to acquire a smaller organization and roll them into their broader product offering than actually build something. One thing that I've learned over the years is that for a business, the time to market or opportunity loss cost largely outweighs actual dollars.

Over my career, I've been part of 4 acquisitions, including my own company ( https://crft.app ) last year. If you've ever been part of an acquisition after the champaign popping is over, it's right to how can we integrate these applications so they feel like one offering. This is always messy because it's almost never the case that both companies have the same technology, languages, tools that are the same. The first acquisition I was apart of our technology stack was heavy C# / .NET and the acquiring company was Java. At the time, there wasn't any frontend tooling like we have today and putting ASPX pages in JSP pages was pretty much a iframe and then a rewrite.

During the acquisition of my company last year, the dreams and aspirations of React finally were realized to me. In this article, I want to take you through how we took two completely different applications written in React and made one unified page ( no iframes required ).

The Theory

A React application is just a set of components pieced together to build a larger application. If you have two different applications written in React, theoretically you should be able to treat one of them like any other component you might install from NPM.

In our particular case, we wanted to create two experiences; one experience that was embedded in the larger application and another that was a stand alone version. This would allow us to create a unified experience for the existing customers but also serve two distinct personas ( since one buyer might not want the other product and vice versus ). This increases code and deployment complexity but it can also help keep some things isolated which makes merging easier.

I hypothesized that we could keep the same code bases and products and then build/package one of the apps and just have on consume the other.

Audit the tech

The first thing you need to do is audit the overlap and figure out what 'container' level items are shared and what can't be. This list usually looks something like:

Authentication ( Custom / Okta / Auth0 / etc )
Store ( Redux / Recoil / etc )
Component Libraries ( Material / Custom / etc )
Style Systems ( SASS / PostCSS / CSS-IN-JS )
Test Systems ( Cypress / Jest / etc )
Build Systems ( Webpack / CRA / etc )
Programming Languages ( JavaScript / TypeScript / CoffeeScript < sorry if thats you )
Backend APIs ( Rest / GraphQL / SOAP < sorry if thats you )
Backend Cloud Providers ( GCP / AWS / Azure / etc )

Once we have an understanding of the tech, we can start to tease out the overlap and put together a plan.

Where do things overlap?

The only thing that overlapped in the frontends was the authentication providers. Luckily most organizations are not writing their own auth providers anymore and so if you have 2 organizations both using let's say Okta, you can actually share the same authentication token minters and its like magic, no seriously I couldn't believe it just worked ( < This might be a future article ).

To make things even more fun, one application is JavaScript + custom webpack and the other is TypeScript CRA. Now I know what your about to say, TypeScript is just JavaScript but believe me converting a large mature code base from JavaScript to TypeScript is quite a lift, mainly because you find so many things that might be 3 years old that the types don't match up and you have to go in circles if this is even used anymore and how to fix it. The last time I did this migration on a mature large code base, it took us about 3 weeks of 3 full time developers on it. I won't argue that knocking out this tech debt and making the code bases the same language has quite a bit of merit but the business wants the product out yesterday and a code migration is just scary for most PMs.

Given the language differences, a copy / paste into the same directory was not really an option. Going back to my original theory, since both systems are React which is just a bunch of components, why can't we build and bundle one of the applications and publish it to NPM just like I do on my open-source projects ( shameless plug: https://github.com/reaviz ).

Rollup to the rescue

Webpack is not really designed to package things for consuming them externally; its possible but not ideal. Rollup on the other hand is perfect for this, it can help you include / exclude / compile to different targets in a ( somewhat ) easy fashion.

We already defined our overlap above, in our case:

React / React DOM
React Router
Moment
Classnames
Okta React / Signin Widget

We want to make sure we have both applications on the same versions and then we can exclude these items from our Rollup build. This will help make the integration easier and the package size smaller.

The next thing we need to do is tease out the 'provider' level items that don't overlap. This typically looks like:

Theme
Notifications
Error Boundaries
HTTP Providers ( Apollo / etc )
State management

and then make a new component called something like Embed.tsx that encapsulates those items and defines the sub applications routes. Here's a rough outline of what mine looked like:

export const Embed: FC = () => (
  <Theme>
    <Notifications>
      <ApolloProvider>
        <ErrorBoundary>
          <Suspense fallback={<Loader />}>
            <Switch>
              <Route
                path="/embed/home"
                component={Home}
              />
              { /* rest of your routes */ }
            </Switch>
          </Suspense>
        </ErrorBoundary>
      </ApolloProvider>
    </Notifications>
  </Theme>
);

This is the component that we will embed in the parent application and the component that will be in the rollup build path.

Next thing is the rollup config. This is going to differ based on your toolchain but they roughly look something like this:

const resolve = require('@rollup/plugin-node-resolve').default;
const commonjs = require('@rollup/plugin-commonjs');
const postcss = require('rollup-plugin-postcss');
const svgr = require('@svgr/rollup').default;
const url = require('@rollup/plugin-url');
const babel = require('@rollup/plugin-babel').default;
const json = require('@rollup/plugin-json');
const replace = require('rollup-plugin-re');
const peerDepsExternal = require('rollup-plugin-peer-deps-external');

const pkg = require('./package.json');

const extensions = ['.js', '.jsx', '.ts', '.tsx', '.svg', '.css', '.json'];

module.exports = [
  {
    input: './src/Embed/Embed.tsx',
    output: [
      {
        file: pkg.browser,
        sourcemap: true,
        format: 'umd',
        name: 'emebed',
        strict: false,
        inlineDynamicImports: true
      }
    ],
    plugins: [
      peerDepsExternal(),
      resolve({
        browser: true,
        extensions,
        preferBuiltins: false
      }),
      postcss({
        plugins: [
          require('postcss-preset-env')({ stage: 1 }),
          require('autoprefixer')
        ]
      }),
      replace({
        patterns: [
          {
            test: /(['`"])(\/home)/g,
            replace: '$1/embed/home'
          }
          /** rest of your routes */
        ]
      }),
      json(),
      url(),
      svgr(),
      commonjs(),
      babel()
    ]
  }
];

Let's take a moment to review what this is doing:

The input defines the entry path for our new Embed component.
The output defines how we want to package the application
The plugins defines things that tools like CRA typically handle for us that we need to include a rollup version for.

Inside the plugins, we have 2 things I want to make sure and note:

peerDepsExternal plugin will resolve the packages we deteremined overlapped and exclude them from the build. I defined these packages in the peerDependencies section of the package.json.
replace plugin will rewrite the paths of anchors and history.push type components. Typically you can use the Redirect component in react-router to do this but it causes us quite a bit of issues so we opted for this approach.

This configuration will now compile the TypeScript to JavaScript and all the styles and images in a friendly format that any React app can consume.

Bringing the code together

Another fun challenge was that one company used Github and the other Gitlab and of course different build systems.

NPM provides an excellent way to publish and version packages so instead of manually copying or submodules, why not take this approach?

At this point, it truly became just like any other NPM dependency we would include in a React app.

Wrapping up

Every organization has different requirements, tools, timelines and priorities but more than likely in these situations its mainly focused around time to market. Hopefully this brain dump can help make someone's life easier the next time you get a new step-parent of a company.

I hope you enjoyed the post, if you liked it follow me on Twitter and Github for more JavaScript tips/opinions/projects/articles/etc!

Asking Your Big Security Data Questions

Austin — Tue, 08 Dec 2020 17:52:50 +0000

Humans are now producing more data on a day-by-day basis than ever before. Every minute, users on the internet generate 2.5 quintillion bytes of data on average. The data varies from selfies and pictures of food, to network data created every time we visit a website or get a DoS attack.

As humans become more ‘datafied’ the cyber security industry needs to ingest and make decisions on this vast information every day. With the pace of of data creation showing no signs of slowing down, this means that the cyber security industry needs to adapt to identify threats faster and respond more quickly to more events that could make or break a business.

Interpreting Data with Technology

As the amount of data grows, we need to be able to better understand this information and make decisions from it. Promising technology like machine learning and neural networks dominate every sector of business today, but the problem is the very fact that they are still promising — not yet delivering in a practical sense.

It still takes a lot of work to create good insights from the information, often employing the need for a data scientist. And, while the data science field is growing at an exponential rate every year, it takes time and money to build and perfect these algorithms that many organizations just can’t afford.

Even after organizations invest in all this technology, it doesn’t solve the root problem of how we as humans interact with our data.

Today’s Interfaces

Today many interfaces are built around the technical challenges that developers encounter. To be frank, they look like they were created for computers, not humans. These interfaces are either a circus input elements like checkboxes and text boxes where you don’t even know what to type in them…

…or so complex you have to be a database developer to write a simple query.

SELECT
   extract(dow FROM sale_timestamp) AS day,
   count(sale_id) as num_sales
FROM SALES
WHERE sale_timestamp >= now() - INTERVAL '7 DAY'
GROUP BY extract(dow FROM scale_timestamp)

As humans, we don’t communicate this way. The above query is actually a simple question you might walk up and ask a colleague: How many sales did we close each day last week? Asking this question of a computer is clearly more complex.

Although software engineering is becoming a more common skill, it’s not a valid reason for us avoid the root problem: Why can’t we ask simple questions of our data like we do of each other?

Turning to NLP

Another old but new technology emerging to deal with this issue is called Natural Language Processing (NLP). This technology literally dates back to the birth of computers in the 1950s, but until recently we have not been able to harness it well. Even with all the technology at our hands today, much like machine learning, it’s still emerging and relatively buggy.

Just try and ask Siri What time does Best Buy open today? That’s a relatively easy question to process and understand but, still our technology is not quite there.

Now imagine trying to use a methodology and ask an open ended question on a petabyte of data about your network traffic today as you work to understand if there was a network attack. The level of complexity cyber security teams require of NLP goes above and beyond what our technologies are able to deliver today.

So it’s easy to see how human and technological limitations are currently holding security teams and analysts back from asking direct questions of our data. But how do we as an industry move forward to overcome these challenges?

Approaches to Solving This

The cybersecurity industry needs to ingest and make decisions on this information every day, but as more data is generated it gets harder and harder to find meaningful answers from it.

This issue is compounded by today’s interfaces, which feel like they were built for computers. Even the most ambitious UIs fall victim to limitations in the way we as humans operate. As data grows, how do analysts communicate with machines? How do we ask the data better questions to make critical business decisions?

The State of the Cybersecurity Industry

Splunk is among one of the most popular organizations in the space that security practitioners use to analyze data and make decisions. Splunk and similar companies tend to use a SQL-like experience to find and filter data.

This method, while powerful, takes years of experience to become an expert at and be effective and still yet is error prone. In interfaces like the one depicted above, it’s also difficult to re-adjust the query without re-writing and pivoting on data.

Auditing the Available Technologies

Exciting new technologies like NLP are promising, but it can be cumbersome to type out simple questions in the ‘right’ way to achieve the desired response. NLP is also difficult to use when analysts don’t know exactly what they are looking for. Imagine trying to ask Siri What stores have the new Call of Duty game in stock and are within a 15 mile range and open after 5PM? Even after you have a broad set of answers, you need to analyze and pivot on results, which would require re-typing the question multiple times, with slightly new conditions.

Point-and-click interfaces are easy to use, but very quickly become complex and difficult to understand. They are unpopular amongst senior analysts who just want to jump into a terminal and type out a grep query.

Technologies that use SQL are very powerful, but require years of training to be effective. It is also still difficult to pivot on the information without re-writing the query.

I wanted to combine the strengths of all of these technologies; making a tool that is easy for entry level analysts to use and powerful enough for the most sophisticated analysts. We also wanted to make it feel more natural, as if you were asking your data a question like you would a colleague.

The Ideal State

I believe that the ideal state is on that builds on the strengths of some of the oldest and newest technologies to create an intuitive interface. As analysts explore their data sets, you can quickly type or point and click queries that provide context such as suggestions and visual elements such as calendars.

In this experience, the analysts can filter down to find insights that are important to them. By providing an experience that allows a user to visually ask the question one word at a time, the analyst can create better queries. Once the user creates a query, they can easily go back and edit it without having to re-create the full query, allowing for easy data pivoting. The experience takes creating and modifying complex queries — like showing Insights created in the past seven days, are unassigned and still open — and makes them easy enough for an entry level analyst to build.

This is just one of the ways we are making it easy for security operations centers to operate more effectively while addressing the security job gap in the market today.

🔗 Static IPs for AWS Lambdas

Austin — Fri, 14 Aug 2020 13:41:57 +0000

Introduction

As more and more organizations move to the cloud, developers are faced with new challenges of how to secure these new services. As this trend continues, you can expect to see hybrid models of some cloud and some on-premise. How you secure the tunnels for traditional architectures like VMs is quite straight forward, however, for the some of the newer serverless architecture patterns it can be quite difficult.

There are a few approaches you can take to secure these new technologies to communicate to on-premise infrastructure:

Static IPs for Whitelisting
SSH Tunnels
VPNs

These approaches are fairly straight forward with VMs but with services like Lambdas where you can expect to see the IPs change a few times a week it can be very difficult to create predictable ranges that don't open all of AWS to your infrastructure.

In this article, I will show you how to setup Static IPs and in the future posts, we will dive into the other approaches.

Static IPs

This is one of the easier but also less secure options. Security is less about making impossible passwords and more about adding several layers. Each layer has its own vulnerabilities but combining a few together can improve your security posture. I recommend adding static IPs in addition to one of the other approaches.

In AWS, it's not the most straight forward thing to do since it requires a variety of resources for a VPC:

Public Subnet
Private Subnet
NAT Gateway
Elastic IP
2 Routes (public/private)
Internet Gateway

Luckily, we can script all this with a CloudFormation:

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "AWS CloudFormation for VPC",
    "Parameters": {
        "env": {
            "Type": "String"
        }
    },
    "Resources": {
        "VPCStaticIP": {
            "Type": "AWS::EC2::VPC",
            "Properties": {
                "CidrBlock": "11.0.0.0/16",
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc"
                                ]
                            ]
                        }
                    }
                ]
            }
        },
        "SubnetPublic": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "CidrBlock": "11.0.0.0/24",
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc",
                                    "-",
                                    "public-subnet"
                                ]
                            ]
                        }
                    }
                ],
                "VpcId": {
                    "Ref": "VPCStaticIP"
                }
            }
        },
        "SubnetPrivate": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "CidrBlock": "11.0.1.0/24",
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc",
                                    "-",
                                    "private-subnet"
                                ]
                            ]
                        }
                    }
                ],
                "VpcId": {
                    "Ref": "VPCStaticIP"
                }
            }
        },
        "InternetGateway": {
            "Type": "AWS::EC2::InternetGateway",
            "Properties": {
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc",
                                    "-",
                                    "igw"
                                ]
                            ]
                        }
                    }
                ]
            }
        },
        "VPCGatewayAttachment": {
            "Type": "AWS::EC2::VPCGatewayAttachment",
            "Properties": {
                "InternetGatewayId": {
                    "Ref": "InternetGateway"
                },
                "VpcId": {
                    "Ref": "VPCStaticIP"
                }
            }
        },
        "RouteTablePublic": {
            "Type": "AWS::EC2::RouteTable",
            "Properties": {
                "VpcId": {
                    "Ref": "VPCStaticIP"
                },
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc",
                                    "-",
                                    "public-route"
                                ]
                            ]
                        }
                    }
                ]
            }
        },
        "RoutePublic": {
            "Type": "AWS::EC2::Route",
            "Properties": {
                "DestinationCidrBlock": "0.0.0.0/0",
                "GatewayId": {
                    "Ref": "InternetGateway"
                },
                "RouteTableId": {
                    "Ref": "RouteTablePublic"
                }
            }
        },
        "SubnetRouteTableAssociationPublic": {
            "Type": "AWS::EC2::SubnetRouteTableAssociation",
            "Properties": {
                "RouteTableId": {
                    "Ref": "RouteTablePublic"
                },
                "SubnetId": {
                    "Ref": "SubnetPublic"
                }
            }
        },
        "EIP": {
            "Type": "AWS::EC2::EIP",
            "Properties": {
                "Domain": "vpc"
            }
        },
        "NatGateway": {
            "Type": "AWS::EC2::NatGateway",
            "Properties": {
                "AllocationId": {
                    "Fn::GetAtt": [
                        "EIP",
                        "AllocationId"
                    ]
                },
                "SubnetId": {
                    "Ref": "SubnetPublic"
                }
            }
        },
        "RouteTablePrivate": {
            "Type": "AWS::EC2::RouteTable",
            "Properties": {
                "VpcId": {
                    "Ref": "VPCStaticIP"
                },
                "Tags": [
                    {
                        "Key": "Name",
                        "Value": {
                            "Fn::Join": [
                                "",
                                [
                                    "lambavpc",
                                    "-",
                                    "private-route"
                                ]
                            ]
                        }
                    }
                ]
            }
        },
        "RoutePrivate": {
            "Type": "AWS::EC2::Route",
            "Properties": {
                "DestinationCidrBlock": "0.0.0.0/0",
                "NatGatewayId": {
                    "Ref": "NatGateway"
                },
                "RouteTableId": {
                    "Ref": "RouteTablePrivate"
                }
            }
        },
        "SubnetRouteTableMainAssociationPrivate": {
            "Type": "AWS::EC2::SubnetRouteTableAssociation",
            "Properties": {
                "RouteTableId": {
                    "Ref": "RouteTablePrivate"
                },
                "SubnetId": {
                    "Ref": "SubnetPrivate"
                }
            }
        }
    },
    "Outputs": {}
}

This formation will create all the resources I mentioned above, next all you have to do is attach your Lambda to the new VPC network:

If you are using the AWS SDK you can also do this programmatically like this example in JavaScript:

const AWS = require('aws-sdk');

const lambda = new AWS.Lambda();

const result = await lambda
  .createFunction({
    Code: {
      S3Bucket: 'BUCKET',
      S3Key: 'KEY'
    },
    FunctionName: 'NAME',
    Handler: 'index.main',
    Publish: true,
    Runtime: 'nodejs12.x',
    VpcConfig: {
      SecurityGroupIds: [
        env.SG_ID
      ],
      SubnetIds: [
        env.SUBNET_ID1,
        env.SUBNET_ID2
      ]
    }
  })
  .promise();

We can test this by making a simple Lambda that will call a website that tells us our IP.

const axios = require('axios');

exports.handler = async () => {
  const result = await axio.get('https://www.whatismyip.com/');
  console.log('Result': result);
}

Recapping the above, this is not the most secure option but it is a layer you can add to make things more secure. When you combine this with other factors you can help harden your code so you don't have to worry about waking up at 2AM to fix an attack.

About Me

My name is Austin McDaniel, I'm the CTO and Co-founder of CRFT where we are setting out to disrupt how organizations automate security operations in the cloud.

Follow me on Twitter and Github for all things JavaScript, Cloud, Security and Data viz.

🎣 React Hooks: The journey of mixins to hooks

Austin — Fri, 01 Nov 2019 15:18:50 +0000

A brief introduction

Unless you live under a rock (not sure that would be comfortable 😂), you've heard of hooks and how they have exploded in popularity with the community.

It's easy to get caught up in the hype and not really understand how we got here and why. If you haven't watched the original video that Dan did at ReactConf in 2018, I recommend giving it a quick watch. The video explains what hooks give us and why they made them.

How did we get here?

React has two ways to develop components: classes and functions. The irony here is that up until recently the JavaScript community had complained for so many years why don't we have classes in JavaScript and even built things like createClass/etc. Recently the community has flipped the other direction going full on functional. Why did this happen? Well maybe its the fact that as humans we often want what we can't have or maybe its just because we realized that once we got them they don't really fit the JavaScript prototypical inheritance model.

Prior to the launch of hooks, the functional component development approach was limited to very basic components since there was no way to leverage state or life-cycle functions. When I first saw hooks, I had flash backs to Angular 1.x code with huge functions. Granted thats a huge no-no but let's be honest in the real world it will happen eventually. I personally favored the class approach because it kept things very organized so I wasn't sold on the functional approach at first but the more I used them the more I enjoyed them.

History time!

As I used hooks more and more, I started enjoying them more. One day when I was using hooks, I thought to myself how did we get here and as I started thinking about it, there is quite a history here.

The problem statement is simple, how do we share the code between several components? After all code re-use is one of the first things we are often taught when we start writing code. This is typically code that handles generic things like window resize events, scroll events, etc. The hard problem is how do you make this as explicit as possible so there isn't 'magical' bits going on.

Directives

In Angular, there is a concept of directives which allow you to decorate elements with bits of functionality. For example, I could do something like:

<div
  [appWindowResize]="myBreakpoints" 
  (windowWidthChanged)="setNewSize($event)">
</div>

When I first started writing React, this was one of biggest things I missed. One of the biggest issues with this approach is its difficult difficult to chain these together with shared scope.

Mixins

The early versions of React used a createClass method and had a concept of mixins. Not too long ago React put out a article called Mixins Considered Harmful. The premise behind the article is that as components grow with several mixins it becomes 'incomprehensible' to understand whats going on. A component with mixins might look something like this:

var Button = React.createClass({
  mixins: [WindowReisze, Orientation, Animation, Tap, Drag]
});

in the body of this component, now you have all these methods that are there now magically. Where did these methods come from, what if they have name overlap, and so on.

On top of all of this, React favor a more functional approach so the createClass was not really good approach for this.

Decorators

Once classes landed in JavaScript, we instantly started bringing concepts from other languages like C#. Angular doubled down on this approach in Angular 2.x making the entire framework driven off decorators.

@Component({ ... })
export class MyComponent {
  @Input() name: string;
}

Honestly, I don't have a problem with decorators but we hadn't even let the paint dry on classes before we started adding all these other language features and well they had to change. Now all of this code that relies so heavily on decorators is likely gonna have to be re-thought.

The problem with decorators for React is the same problem I mentioned above, React favors a functional approach and when you apply decorators to functions, it ends up looking something like:

@bind
@resize
function bar() { ... }

and it becomes hard to comprehend again.

Higher Order Components (HOCs)

Higher order components came next. They gave us similar features as decorators but didn't require the new language feature. However they had the same problem as decorators, they are hard to reason what's going on with them.

export default withRouter(
  connect<{}, {}, {}, DashboardProps>(
    mapStateToProps,
    mapDispatchToProps
  )(Dashboard)
);

In the example above, there is only two HOCs wired up and I already couldn't tell you what exactly is going on.

Render Functions

Once we came to the realization that all these higher order approaches suffered the same problem of being difficult to reason with, the community came up with the 'render functions' approach. While this approach is more explicit and favors a declarative approach that feels natural for web dev, it gets out of control quite quickly.

<Route>
  {route => (
     <Permissions>
       {roles => (
          <Query variables={{ foo: true }}>
            {data => (
              <Dashboard {...data} {...route} {...roles} />
            )}
          </Query>
       )}
     </Permissions>
  )}
</Route>

This approach is more explicit but thats comes with a price too.

Wrapping up...

As you can see all of these approaches come with a price. Hooks give us a fresh look at making composable components with high code re-use but its hard to tell how they will play out in the real world after several developers have worked on the same bits of code in a large code base

I hope you enjoyed the post, if you liked it follow me on Twitter and Github for more JavaScript tips/opinions/projects/articles/etc!