Originally posted on the Test Double blog here Introduction React is an amazing library. Over the last 5 years it has transformed the landscape of frontend development and spawned an incredible ecosystem of tools, libraries, and patterns. Over that time, React has changed quite a bit. As React has evolved, so too have our applications, tools, and approaches. This year (2019), React went through one of its biggest changes with React v16.

Introduction If you want to get new-agey and deploy a GraphQL API in a serverless architecture, what’s the best way? You can make that work with API Gateway but it’s a little cludgey and normally results in implementing a super Lambda function that contains all your GraphQL resolver logic. Lucky us! AWS has a GraphQL specific API proxy called AppSync. Last month, I did an article overviewing AppSync and concluded I would try it out on an upcoming project.

Introduction I recently learned about AWS AppSync while perusing A Cloud Guru courses and stumbling on this one: “Introduction to AWS AppSync”. I am excited! AppSync is a managed service for deploying GraphQL APIs. Think of it like API Gateway but for GraphQL instead of HTTP requests. GraphQL is to AppSync as HTTP is to API Gateway. From the course learnin and my trials so far, the workflow breaksdown like this:

Elements of this post have been ruminating in my mind for a few years now. This is the best I have been able to put it into words; such as they are. Experiment A thought experiment for your consideration. An app is developed–the Omniscient Life app–with the following features: Scans your biometrics to identify you using government databases Collects all audio/video about your life into a history stream by connecting with NSA/CIA/GCHQ surveillance archives Data mines the videos using AI to identify micro expressions to add a “thought-track” as subtitles or commentary Connects to your social media (Facebook, Twitter, and LinkedIn) to share your history stream With this app, you can view any moment of your lifewith your accompanying psychological and emotion state via the “thought-track”.

Introduction I have built several production web applications using React and Redux and generally have had an excellent experience with those technologies. One of React’s greatest assets IMO is it’s ability to integrate into all kinds of stacks and setups but still play nice with the other kids. That was something that impressed me back in Spring 2014 when I first used React. We got React running in the jQuery spaghetti code of a massive, legacy Ruby on Rails application with incredibly little effort and huge productivity benefits to the team.

When deploying static websites, I am not a fan of provisioning servers to distribute them. There are so many alternatives that are cheaper, simpler, and faster than managing a full backend server: S3 buckets, Content-Delivery Networks (CDNs), etc. But the catch with getting rid of a server is now you don’t have a server anymore! Without a server, where are you going to submit forms to? Lucky for us, in a post-cloud world, we can solve this!

Not all python objects handle changes the same way. Some objects are mutable, meaning they can be altered. Others are immutable; they cannot be changed but rather return new objects when attempting to update. What does this mean when writing python code? This post will talk about (a) the mutability of common data types and (b) instances where mutability matters. Mutability of Common Types The following are some immutable objects: