Surely you've heard of Amazon Prime, and maybe you even used it at home before heading off to school.  But did you know that students can get a great deal on Amazon Prime–and all sorts of unique benefits?  Read on to find out about how students can make the best use of Amazon Prime.

What are the Main Amazon Prime Student Benefits?

You're probably already familiar with the main benefits of Amazon Prime:

• Free two-day shipping on tons of eligible items from Amazon.com
• Unlimited movie and TV streaming with Prime Video
• Unlimited music with Amazon Music Prime
• Prime prices at Whole Foods Market, both in-store and pickup/delivery

But there are tons of other benefits that are especially appealing to students.  We'll cover them all in this post.  But first, let's address the most important question.  What does it cost?

What Does Amazon Prime Cost for Students?

• 6-Month Free Trial: The journey into Amazon Prime Student begins with a wallet-friendly proposition. For starters, there's a six-month free trial, courtesy of a partnership with Sprint, allowing students to dip their toes into the Prime experience without spending a dime.
• $6.99/month After the Trial: Once the trial period ends, the subscription transitions into a half-priced haven of Prime benefits, costing significantly less than the regular Amazon Prime membership. This adjusted pricing structure is designed with the student budget in mind, ensuring that even those surviving on a diet of ramen and coffee can afford the luxury of Prime.

Who Qualifies for Amazon Prime Student?

There are two ways to qualify for Amazon Prime Student–and one doesn't even involve being a student!

• Verify enrollment as a student:  if you're enrolled as a student, a valid .edu email address is your golden ticket to entry.
• Verify eligibility by being age 18-24: That's right–if you're between 18 and 24 years old, you don't even need to be a student to qualify.

Either way, head over to the Amazon Prime Student page to get started!

What's the Difference Between Amazon Prime Student and Regular Prime?

While Amazon Prime for Students offers most of the same benefits as the normal Amazon Prime offering, there are a couple of important differences to be aware of.

• Pricing and Trial Period: The most striking difference lies in the pricing and the extended six-month trial period offered to students, compared to the standard 30-day trial for regular Prime members.
• Special Benefits for Students: While the core benefits like free shipping and streaming services are similar, Prime Student is enhanced with exclusive deals and promotions specifically aimed at students.
• Sharing of Household Benefits: Unlike the Amazon Prime offering you might be used to with your family at home, Amazon Prime for Students does not allow you to share benefits with others in your household such as roommates.

Amazon Prime Student Entertainment Benefits

• Prime Video: A treasure trove of movies and TV shows to unwind after a grueling study session.
• Amazon Music: Over two million songs ad-free, creating the perfect study ambiance or soundtrack for a break.
• Twitch Prime: Free games and exclusive in-game content for the gaming aficionados looking for a leisurely escape.

Unexpected Amazon Prime Benefits

• Calm App Subscription: 3 complimentary months of Calm, the meditation app, to help manage the stresses of student life, then $8.99 a year.
• CourseHero: one free month of AI-powered study assistance from CourseHero.  While this is a great tool, we wish the free offering was a bit more generous.
• GrubHub+: Prime for Students gives 12 months free of GrubHub+, which gives free delivery and discounts on GrubHub orders, perfect for nights when cooking is just not on the agenda

Does Amazon Prime for Students Pay for Itself?

Amazon Prime for Students easily pays for itself every month through a series of benefits:

• Free Shipping: save about $2.99 per order, though shipping varies by item and speed.  The savings on shipping alone, especially for frequent purchasers, can quickly offset the cost of the membership.
• Prime Video: save $6.99/month compared to Netflix with ads.  While the content differs between Prime Video and other platforms, you'll always find something to watch
• GrubHub+: save $9.99/month on GrubHub+, which can save $3.50 or more per delivery order and 5% off of pickup orders.  If you order food frequently (and let's be honest, you probably do), the savings can be significant.
• Amazon Music: saves $5.99/month compared to Spotify, though to be fair, real music lovers who want on-demand access to any song may still prefer the Spotify offering.

Assuming you make three Amazon purchases and four GrubHub purchases per month, and use Prime Video & Amazon Music instead of other services, students can save an estimated $36 every month.  Exact savings will vary based on your usage of the benefits above, but this estimate is not unrealistic and could be even higher if you take advantage of other benefits.

Can Housemates Share Amazon Prime Student Benefits?

Unlike normal Amazon Prime which does allow for sharing within a household, the Prime Student offering does not allow for sharing Amazon Prime benefits.  Certain features such as Prime Video can of course be used on shared devices like communal TVs, but other benefits like free shipping and GrubHub will be harder to take advantage of unless the primary account holder does the ordering.

Does Amazon Prime Student Have a Referral Program?

Though there are many references to an Amazon Prime Student referral program online, as of this writing (Feb. 2024) Amazon's site does not indicate an active referral program.  While we're always on the lookout for deals like these and will update this post if we learn anything new, it looks like Amazon is not currently offering a referral program.

Can I Get Amazon Prime for Free With Sprint or T-Mobile?

There are lots of posts out there claiming that you can get Amazon Prime for Free with a Sprint or T-Mobile subscription.  Unfortunately, it seems that these posts are all outdated: the offer ended in April 2023.  As of February 2024, Sprint (now owned by T-Mobile) has ended its free Amazon Prime promotions for new customers.  If this changes and the promotion becomes available again, we'll update it here!

Are International Students Eligible for Amazon Prime Student?

International students aren't left out of the Prime loop; with a valid .edu email and proof of enrollment, they too can enjoy the myriad benefits of Amazon Prime Student, making their transition to studying in the U.S. a bit smoother.

How to Maximize Savings with Amazon Prime Student

• Take Advantage of the Special Offers: make sure to try out the subscriptions to Calm and CourseHero, as well as any other special offers that pop up.
• Stay Alert for Deals: Come back to Amazon once in a while to keep an eye out for exclusive deals and promotions, especially during back-to-school and holiday seasons.  While the information in this post is up-to-date as of February 2024, benefits do change periodically.
• Use the Amazon App: The Amazon app is a great tool for tracking deals and managing subscriptions, ensuring you never miss out on an opportunity to save.
• Cancel Any Subscriptions you Don't Use!  While the free offerings of GrubHub+, Calm & CourseHero are great benefits, they may auto-renew after expiration.  Be sure to check the terms when you sign up and don't forget to cancel if you don't find the app helpful.

Conclusion

Amazon Prime Student is more than just a subscription service; it's a strategic partner in the quest for academic and personal success. It works perfectly with the student lifestyle, offering an array of benefits that cater to both the necessities and pleasures of college life. From substantial savings on textbooks and essentials to providing a much-needed entertainment escape, Prime Student offers a solution to a wide array of everyday problems students encounter.

To embark on this journey of convenience, savings, and enjoyment, head over to Amazon and follow the straightforward process to verify eligibility either by student status or age. Amazon Prime Student awaits to make your student life richer, easier, and infinitely more enjoyable. Join the ranks of savvy students who have already discovered this essential college hack.

Updated 2/23/2024

I recently wanted to add some new blog & page content to a running shoe price comparison site I built with Elixir/Phoenix and LiveView. I also happen to maintain a couple of different sites using the Ghost publishing platform. So naturally, I asked the question: can I use Ghost’s content creation tools to manage the content for my Elixir/Phoenix project?

Of course! Though I did have to write a small Elixir client for the Ghost content API, it was simple enough to access the content and take advantage of all the powerful Ghost CMS tools in my Phoenix app.

In this post, we’ll learn how to use the Ghost publishing platform as a simple CMS for presenting content in any Elixir project, including those built with the Phoenix Framework and LiveView.

Why Use a Headless CMS

First of all, what is a headless CMS?

A headless CMS is a content management system that allows content creators to create, edit and manage content on a different site than where it is ultimately displayed. It also provides API access so that the content can be displayed by a variety of frontends and interfaces. With a headless CMS, developers can offload managing content creation tools, and at the same time have more control over how the content is presented.

In practical terms, a headless CMS gives a developer pre-built tools for creating and managing content that can be displayed on a site they’re building, without building out a full blogging platform themselves.

Though some developers will be tempted to build their own content management, there are tons of features including SEO tools, media management, permissions & powerful content editors which make a headless CMS a better choice in most cases.

What is Ghost?

Ghost is a popular open-source blogging platform that is known for its simplicity and power. It is lightweight and built on a modern technology stack, making it a great choice for developers who want a straightforward and easy-to-use CMS. Though most people use Ghost as the frontend for their content as well, the platform also features a robust content API, which allows it to function as a headless CMS.

On the content creation side, Ghost offers a range of other features, including a simple and easy-to-use editor, media management, user management and built-in SEO tools. It even includes tools for mailing lists, audience management, payments and more.

Overall, Ghost is a great option for developers looking to use a headless CMS in their project, and its feature set and API make it a strong contender for managing blog-like content in Elixir/Phoenix and LiveView applications.

While there are a number of other headless CMS options that can work with Elixir, here are some of the things I really like about Ghost:

• lightweight & responsive
• clean & modern content management interface
• options for both fully-managed hosting or self-hosted content
• completely free for self-hosted & reasonably pricing for managed
• fully open-source

On the last two points: many headless CMS providers are closed-source and don’t allow the option to self-host. While they may offer free or affordable tiers for small sites, they come with a real risk of vendor lock-in or spiraling costs as a site grows. I recommend the Ghost’s managed hosting to help support the development of the platform, but also appreciate the peace of mind that the self-hosted, open-source option provides.

How to Use Ghost in Your Elixir/Phoenix Project

Let’s consider a simple use case where we have blog content in a Ghost CMS, and we’d like to display it in our Phoenix/LiveView app. We’ll integrate the client, then build a simple LiveView to display the blog index, and then individual posts.

GitHub - jonklein/ghost_content: An Elixir client for the Ghost Content API

An Elixir client for the Ghost Content API. Contribute to jonklein/ghost_content development by creating an account on GitHub.

GitHubjonklein

First, you’ll need to add the ghost_content package to your project.

# mix.exs

def deps do
  [    
    {:ghost_content, "~> 0.1.0"}
  ]
end

Next, you’ll need to configure the package using your Ghost API host, and API key. For help on getting the proper values for your Ghost blog, consult the Ghost Content API documentation.

# config.exs

config :my_app, :ghost_content,
  host: "https://my.ghost.host", 
  api_key: "my-ghost-api-key"

Once you’ve added & configured ghost_content in your project, we’ll add the LiveViews to fetch and display the blog content. In the examples below, we’ll show the bare minimum to get up and running, but it should be simple enough to expand on the functionality once you get the blog index and posts displaying in your app.

First, let’s add simple routes to our new blog functionality. We’ll show a list of all posts at /blog, and show individual posts at /blog/:slug , where :slug is the identifier for the post we’ve configured in the Ghost CMS.

# router.ex

live("/blog/", MyApp.BlogLive.Index, :index)
live("/blog/:slug", MyApp.BlogLive.Show, :show)

With our routing in place, we’ll create the index page showing our list of blog posts. We simply make a call to the Ghost content API to fetch the posts in our mount() call, then render the contents, linking out to the individual posts:

defmodule MyApp.BlogLive.Index do 
  use MyAppWeb, :live_view
  
  def mount(_params, _session, socket) do
    {:ok, %{posts: posts}} =
      GhostContent.config(:my_app)
      |> GhostContent.get_posts()
    
    {:ok, assign(socket, :posts, posts)}
  end  

  def render(assigns) do
    ~H"""
      <h1>Recent Blog Posts</h1>
      <ul>
      <%= for post <- @posts do %>
        <li><a href={~p"/blog/#{post.slug}"}><%= post.title %></a></li>
      <% end %>
      </ul>
    """  
  end
end

Finally, we’ll add a simple LiveView to show individual posts. In this case, we’ll use the slug from the route to lookup the post content:

defmodule MyApp.BlogLive.Show do
  use MyAppWeb, :live_view
  def mount(%{"slug" => slug}, _session, socket) do
    {:ok, %{posts: [post]}} =
      GhostContent.config(:my_app)
      |> GhostContent.get_post_by_slug(slug)
    
    {:ok, assign(socket, :post, post)}
  end
 
  def render(assigns) do
    ~H"""
      <%= @post.title %>  
      <div class="ghost-blog-content">
        <%= raw(@post.html) %>
      </div>
    """
  end
end

Note that to display the content we use raw(@post.html). This is because the content API is giving us actual HTML content and we want to render it as-is (rather than with HTML content escaped). Using raw() can be dangerous with untrusted content, but in this case, because we have authored the content ourselves, it is trusted.

Regarding styling, because we’re displaying raw HTML content that was authored in Ghost, the content we render in our app is unstyled. We won’t be able to take common styling approaches like adding class names to the individual HTML elements in our content. Instead, we simply wrap the entire blog content with a div with a special class name (ghost-blog-content), then apply styles to elements within that div in our app.css:

# app.css 

.ghost-blog-content h1 { font-size: 2em; }
.ghost-blog-content h2 { font-size: 1.5em; }

# more .ghost-blog-content styles ...

And voila! With these simple LiveViews in place, we have the foundations of a Ghost blog in our Phoenix app. There are a number of details we’ve ignored like pagination, displaying tag & author data, navigation, etc., but these are simple enough to add once we have the basics in place.

One final note on SEO: to take full advantage of the SEO functionality of Ghost, be sure to grab the proper values from the Ghost post structure (title, feature_image and description) and expose them in the proper meta tags in your HTML content.

Jonathan is software developer & engineering leader who loves Elixir. When he’s not writing code, he can be found running or scouring the internet for great deals on running shoes.

“No, please”, I begged her, “don’t do it”.

My wife looked up from her phone and locked eyes with mine. Slowly, she raised the phone and turned it so I could bear witness. She lifted her other hand to the phone and–with a wry smile–tapped “Purchase”.

Candy Land. With that simple tap, my wife had purchased Candy Land for our darling 5-year-old for Christmas. And in doing so, doomed us to hours of insufferable gameplay.

If you’ve played the kids’ game Candy Land, you know that it feels like it goes on forever. But can it actually, literally go on forever? In this post, I set off to find out.

The First Rule of Candy Club

If you are unfamiliar with Candy Land, congratulations! But sadly, I’ll need to explain the rules to you so you can understand the rest of this post.

Candy Land is a kids’ boardgame in which players attempt to navigate over a series of colored squares through a land made out of candy. A “CANDY-LAND” if you will. The goal is to reach the Candy Castle, but various obstacles along the way make the task more difficult.

What’s great (I guess) about Candy Land is that it’s a board game that even the smallest kids can play. With a bit of assistance, even 3-year-olds can participate in game night. Sure, I can appreciate that.

So why is Candy Land such an aggravating game then? Well, for one thing, there is no strategy at all. There are, in fact, no decisions made by the players. Each turn, a player picks up the next card from the deck which tells them how far to advance. Occasionally, a special card will send the player to another square far away on the board–sometimes forward, sometimes back.

So without any player influence on how each turn unfolds, you have no control whatsoever over the outcome. You are just a passive vessel for the game of Candy Land. In mathematical terms, the game is fully deterministic. The outcome was decided before you even started, you just don’t know it yet.

You have no control whatsoever over the outcome. You are just a passive vessel for the game of Candy Land.

The fact that the game is deterministic is aggravating enough, but what makes it worse is that the game–seemingly–goes on forever. Because the special cards can send you back in the board and erase most of your progress, the game can drag on seemingly indefinitely.

Most of our games with our son eventually do end, after far too long. And sometimes we have to simply stop playing when the game has outlived its welcome (though the 5 year old disagrees). But during a particularly painful game, I asked the question: is it possible for a Candy Land game to actually go on forever?

Constructing an Imperfect Game

To figure out if a never ending-game is actually possible, we started to analyze the game:

• there are 64 cards, or 66 depending on who you ask (the official rules state 64, while people with the actual gamecount 66)
• each card determines how the player moves: either a single color (move to the next square of that color), a double color (move forward two squares of that color), or a special candy image (move to the special square)
• there are 134 spaces from the start of the game to the Candy Castle
• after a card is are used, is it placed back at the bottom of the deck

With these rules in mind, we can describe how a never-ending sequence would work. A never-ending game sequence for a single player would be a sequence of cards that form a loop of destinations: if a player ends up on the same square at the same point in the card sequence, we have defined a loop.

So to get a never-ending two player game, we simply need to find two distinct loops of 33 cards and interleave them.

With this realization in mind, our Infinite Candy Land seemed so close I could, uh, taste it. “I know!”, I announced proudly, “I’ll write a Candy Land simulation and use some search techniques to find overlapping Candy Land loops. Maybe a genetic algorithm or Monte Carlo simulation would be a good app-…” I trailed off as I opened my laptop.

My wife rolled her eyes and pushed the laptop closed. “It’s simple”, she said.

Don’t Overthink It

So it turns out, no fancy search techniques are needed. It’s trivial to create a never ending game. Once we figured out how, we were able to do so on our first attempt.

Here’s how we did it. The following is a description of the loop for a single player, so is done with 33 cards–4 “special” cards and 29 regular color cards:

• The first card in the loop is a “special” card near the start of the board–it brings the player to the specified square on the first turn.
• The other “special cards” are distributed evenly throughout the deck so that when a player starts to approach the goal, they are pulled back to elsewhere on the board.
• After playing the 33rd card, the sequence starts again and the player starts again on the initial “special” square on their 34th turn.

It turns out constructing a deck following these rules is simple. And if we do the same thing for the other subset of 33 cards, we can have a sequence for the other player. If we then interleave these two sequences, voila the game of Candy Land will in fact go on forever.

Game Over

So, as it turns out, the game doesn’t just feel like it goes on forever. It can literally go on forever. In fact, some readers of this may be caught in an endless loop of Candy Land at this very moment. Condolences.

Of course, this all makes the assumption that you don’t make the common sense modification of shuffling the cards when they run out. But hey, rules is rules. Also, I’m informed that some newer editions of Candy Land actually come with a spinner instead of cards. But for the sake of this rant, I am a strict Candy Land Originalist.

Jonathan is a master-level Candy Land player. When he’s not playing candy land, he can be found running or scouring the internet for running shoes.

Have you ever wished you could have an AI-powered assistant right at your fingertips while browsing the web in Safari?  We are thrilled to introduce GPTWebHelper, a new Safari extension that brings the incredible power of OpenAI's ChatGPT to any webpage you visit.

We built GPTWebHelper because we couldn't find a way to leverage the power of ChatGPT in a lot of the apps we use every day.  We spend a lot of time on the web in the Safari browser, and on a lot of different sites–and we couldn't find a solution to access ChatGPT on all of them without switching back and forth between windows or copy/pasting text around.

The Power of ChatGPT

So, how does it work? Once installed, GPTWebHelper is activated with a single click, right next to the address bar on any page. A handy chat popup will appear, ready to assist you.

GPTWebHelper can help you read & digest content by answering questions, explaining concepts, translating texts, or summarizing pages. With GPT Web Helper, you no longer need to open countless tabs or switch between applications. Simply ask your questions directly within the chat window, and the AI assistant will promptly provide relevant and accurate answers, acting as your knowledgeable virtual guide.

But it's not just for reading content–GPTWebHelper also helps you create.  Emails, blog articles, social media posts & more are a breeze–anywhere on the web you need to create content, GPTWebHelper is there to assist you.  From creating content from scratch to editing, correcting & modifying text, you get the full power of ChatGPT at your disposal.

Try out GPTWebHelper

Whether you're a student looking for additional learning resources, a professional seeking quick and reliable information, or simply a curious individual exploring the web, GPT Web Helper is your go-to extension that brings the limitless potential of ChatGPT directly to your fingertips.

Discover the transformative power of ChatGPT in Safari – find GPTWebHelper in the App Store and give it a try!

async & await are key concurrency tools for most JavaScript developers and have been in common use for many years.  In the Swift language, on the other hand, async and await are relatively new, appearing in Swift 5.5, and are generally not the most common idiom for dealing with concurrency.  While they may not be the most common approach, there are definitely scenarios in which they can be used to craft a cleaner solution.  In this post, we will explore the use of async & await patterns of handling asynchronous operations in Swift for those coming from a JavaScript background.

Concurrency and Callbacks

Concurrency, broadly speaking, is the ability for a language to manage multiple streams of computation at the same time.  Note that concurrency is distinct from parallelism, which is the ability to improve performance by actively performing two tasks at the same time (e.g., on multiple processors or cores).  

In both JavaScript and in Swift, simple concurrency can be achieved through the use of functions that accept callbacks, and the two have comparable syntax:

// JavaScript:
readFile(path, r => { console.log(result) })
performExpensiveComputation()

// Swift:
readFile(path: path, completion: { result in print(result) })
performExpensiveComputation()

In the two example above, we make use concurrency to do two things at once: read a file, performing some operation with the result, and perform some other expensive computation.  In this example, we don't know and don't care which operation completes first–only that both streams of computation are performed.

Why Async/Await?

For simple concurrency, callbacks work just fine.  To understand why we need async and await, we need to consider some a complicated example.   Let's consider a completely fictional (but plausible) chain of asynchronous computation to read a file, parse the contents, fetch & process some metadata, and post the result to a server:

fetchFile(url: url) { contents in 
  parseFile(contents: contents) { parsed in
    fetchMetadata(parsedData: parsed) { metadata in 
      processMetadata(metadata: metadata) { processed in 
        postProcessedDataToServer(data: processed) { result in
          logResult(result)
        }
      }
    }
  }
}

Yikes!  We've created "callback hell".  This is where async and await come into play: they replace callbacks with a linear syntax for perfoming concurrent computations.  Let's refactor our code to make use of async and await. First, the finished computation using await:

let fileContents = await fetchFile(url: url)
let parsed = await parseFile(contents: fileContents)
let metadata = await fetchMetadata(parsedData: parsed)
let processed = await processMetadata(metadata: metadata)
let result = await postProcessedDataToServer(data: processed)
logResult(result)

Behind the scenes, we've also updated the signature for the functions we're using.  We'll get into the exact implementations later, but here's how the declarations change:

// with callbacks:
func fetchFile(url: URL, callback: (Data) -> Void) { ... }

// with async/await:
func fetchFile(url: URL) async -> Data { ... }

Async/Await Patterns in Swift & JavaScript

Let's take a look at some common async/await patterns you may be familiar with in the JavaScript world, and see how they are implemented in Swift.

Basic async Function Implementation

First, let's take a look at the most basic usage.  In order to use await, you'll need to write async functions.  In both Swift and JavaScript, the simplest possible way to implement an async function is to await the result of another async function!  

First, a simple example in JavaScript:

async function loadData(url) {
  return await fetch(url)
}

In Swift, we can do the same thing using existing async Foundation function on URLSession to read data from a URL in async fashion:

func loadData(url: String) async throws -> Data {
  let request = URLRequest(url: URL(string: url)!)
  let (data, _) = try await URLSession.shared.data(for: request)
  return data
}

Composing Async Functions from Callbacks

What about creating an async function when no existing async function exists?  For example, when adapting a function using a callback?

In JavaScript, we can create an async function by returning a Promise.  In this case, we wrap an existing apiCall function in a promise to make it async:

async function asyncApiCall() {
  return new Promise((resolve, reject) => {
    apiCall((result, error) => {
      if (result) {
      	resolve(result)
      } else {
     	reject(error)
      }
    })
  })
}

Similarly, in Swift, we can construct an async call using a Continuation.  The full details of continuations in Swift are a much larger topic, but in context of composing an async function, they can be used in a way similar to the JavaScript Promise in the example above:

func fetch(url: String) async throws -> Data? {
  let request = URLRequest(url: URL(string: url)!)
        
  return try await withCheckedThrowingContinuation { continuation in
    URLSession.shared.dataTask(with: request) { data, _, err in
      if(err == nil) {
        continuation.resume(returning: data)
      } else {
        continuation.resume(throwing: err!)
      }
    }
  }
}

Here we use continuation.resume in the same way as the JavaScript Promise functions resolve and reject: we can resume with either a return value, or an error.

Combining Multiple Async Calls

Combining async calls works a a bit differently in JavaScript and Swift.

As we alluded to earlier, async calls in JavaScript are just promises under the hood.  Because of this, if we call an async function without await, we can get a Promise object, and thus handle multiple async calls using  Promise.all():

async function fetchData() { ... }

func fetchMultiple(urls) {
  let promises = urls.map(url => {
    return fetchData(url) // note -- we're not using await! 
  })
  
  return Promises.all(promises)
}

In Swift, we can achieve something similar with a TaskGroup:

// assume we have the following:
func fetchData() async -> Data { ... }

func fetchMultiple(urls: [String]) async -> [Data] {
  return await withTaskGroup(of: Data.self) { group in
    urls.forEach { url in group.addTask { await self.fetch(url: url) } }
    
    var data: [Data] = []
    for await i in group { data.append(i) }        
    return data
  }
}

In this example, we add the individual calls to a TaskGroup (using await while makign the call!) and then assemble the results manually.  

Conclusion

async/await are powerful tools for dealing with asynchronous code and relatively new to the Swift ecosystem.  While async & await are not the only approach to building concurrency in Swift, they are especially useful when representing a linear flow of logic which relies on complex asynchronous tasks, and helping to unwind the "callback hell" that can occur when building this logic with callbacks.

After a long wait, React Native 0.72 is finally here! It brings a number of highly requested features, improvements in performance and the developer experience, and several other important changes.  In this post, we’ll see what’s new in React Native 0.72, and most importantly, why it matters to React Native developers.

New Metro Features

React Native 0.72 introduces several important features in the Metro, the default JavaScript bundler in React Native projects.

One of the more important highlights of this release is the addition of beta support for symlinks in Metro, a long-requested feature by the community. In short, the feature allows the Metro bundler to follow symbolic links, which enables a variety of previously unsupported project structures and tools. This change lets React Native work seamlessly with monorepo setups and pnpm, eliminate the need for complicated workarounds or third party tools.

Similarly, support for Package Exports has been added to Metro, providing an alternative to the “main” field in package.json. This feature allows npm packages maintainers to define their public API more precisely and target React Native specifically. By enabling support for Package Exports, your app is more compatible with the wider JavaScript ecosystem.

Both of these new Metro features are considered to be beta, and you’ll need to update your configuration to enable them. To enable these features in your project, update your metro.config.js file and add the following options:

const config = { 
  // … 
  resolver: {   
    unstable_enableSymlinks: true,
    unstable_enablePackageExports: true, 
  },
};

Also note that the default setup of metro.config.js has changed in the new release, so be sure to update your configuration according to the template.

Improved Error Handling & Reporting in Development

One ongoing pain-point of React Native development is error reporting. During development, it’s not uncommon for small errors or typos to unleash a swarm of cryptic errors in the logs or a blank screen or “redbox” error. React Native 0.72 improves on the error reporting in development with several changes.

First, the core Hermes JavaScript engine has improved error messages for attempting to invoking undefined functions, now showing the variable name that was called. This might sound small, but it’s a great improvement over tracking down a cryptic “undefined is not a function” message! Additionally, the stack traces now filter out internal byte code frames, giving a far more readable call stack.

For component styling, previously an invalid property in StyleSheet would result in a redbox error. This release relaxes this requirement, allowing such errors to fail silently during development, similar to how invalid CSS property errors are handled in browsers. The errors can still be caught and reported at build-time.

Finally, the React Native CLI itself is updated with this release, enhancing error output by reducing duplication, clarifying wording, reducing verbose stack traces, and adding deep links to relevant docs for certain commands.

New Architecture & Performance Improvements

If you’ve been following React Native development for a while, you’ll know that each new release brings incremental improvements to the “New Architecture”, and React Native 0.72 is no exception.

The new Fabric rendering engine gets a boost with improved text rendering performance of up to 27% on iOS and 18% on Android. More detailed info on Fabric performance improvements is available in this blog post.

Also, the new architecture JavaScript engine, Hermes, has also seen a number of performance improvements, with faster compilation of large object literals and multiple optimizations to JSON parsing. These improvements will especially benefit apps that do a lot of JSON manipulation or bundling of many objects.

Finally, for iOS, the New Architecture is now compatible with the commonly used use_frameworks! CocoaPod configuration — this was a blocker for many apps in integrating the New Architecture in previous released.

As a side note on the New Architecture, as of React Native 0.72, New Architecture updates will be managed by a dedicated working group, allowing for more focused and frequent updates. If you’re interested in New Architecture updates, be sure to follow working group.

Breaking Changes and Deprecated Components

React Native 0.72 has a great set of improvements, but there are also some breaking changes around packages and features included by default. Be sure to review these changes and update your dependencies accordingly!

The primary change is that a few components such as Slider, DatePickerIOS, and ProgressViewIOS have been removed from the React Native core and have been extracted into community packages. If you’re using the components, simply find and install the recommended community package.

Additionally, several packages have been renamed and now live under react-native/packages and are published under the @react-native npm scope. These changes will not affect developers who do not have a direct dependency on a renamed package. However, developers should update any renamed dependency to its ~0.72 version when upgrading to React Native 0.72.

React Native 0.72: Not Dead, Better Than Ever

If you’re a long time React Native developer, it’s worth thinking a couple of years when everybody seemed to be asking “Is React Native Dead”? Suffering at the time from poor performance, some high profile projects moving off of React Native and increased competition from new frameworks like Flutter, it seemed like React Native had some fundamental challenges to tackle. It’s safe to say that over the past several releases, and in particular with the introduction of the New Architecture, the team has lived up the challenge.

React Native 0.72 continues this progress with an impressive step forward, driven by community feedback and featuring many significant updates and improvements. If you’re using an older version of React Native, especially a version without the Hermes JavaScript engine, it’s worth the time and effort to get up and running in 0.72.

React Native upgrades can be a bit tricky, so when you are ready to upgrade to 0.72, it’s always a good idea to consult the React Native Upgrade Helper tool and look at the upgrade documentation. If you are using Expo, React Native version 0.72 will be supported in the Expo SDK 49 release.

Good luck, and happy hacking on your React Native apps!

Earlier this year, during the run-up to the Boston Marathon, I needed a new pair of shoes for race day. Nike’s new VaporFly 3 shoes had been announced, but with no specific release date in the US — only rumors.

So over the course of several days, I found myself in a near constant “refresh loop”, looking to see when I could get my hands on the new shoes and make sure I got them in time for race day.

The story has a happy ending, as the shoes were released in early April and I got them in time for race day, but the whole thing got me thinking: there’s got to be a better way to keep an eye out for changes to web content!

Well, of course, there are better ways — a number of Chrome extensions can keep an eye out for changing content on websites. But there were none for the Safari Browser! Until now.

Introducing Expedition: Website Monitoring for Safari, Made Simple

Inspired by my obsessive refreshing to get a new pair of shoes, I developed Expedition: a simple browser extension to help you monitor web content in Safari.

Expedition lets you select targeted content from websites, and automatically checks the content periodically in the background. When content changes, you can easily access the updates from the Expedition toolbar icon.

Expedition is great for tracking changes in headlines, prices, sports scores, social media stats and much more.

Want to give it a try? Check out Expedition in the Mac OS App Store!

Though the exact origins of life on earth remain a mystery, there are a number of tools we can use to try to understand and explain the emergence of self-replicating systems, a key pre-requisite. One of the most interesting models is the hypercycle, which describes a set of cyclical chemical reactions which together form self-replicating loops of emergent behaviors.

These self-replicating loops represent a plausible model of the origin of life.  Also, they look pretty freakin' cool. In this post, we'll explore what a hypercycle is, how it can teach us about the origins of life, and how we can build a hypercycle simulation using WebGL pixel shaders.

What is a "Hypercycle"?

A hypercycle is a mathematical model that describes a set of chemical reactions, leading to a cycle of molecules that depend on each other for their survival. Each molecule in the hypercycle catalyzes the replication of another molecule in the system, forming a cycle of replication that is self-sustaining.

Self-replication is the ability of a molecule or system to make copies of itself: a process that is essential for the emergence of life. In a hypercycle, each molecule catalyzes the replication of another molecule in the system, creating a cycle of self-replication.

If we introduce a spatial element into the model, we can simulate the hypercycle in a reaction-diffusion system.  Reaction-diffusion systems describe the behavior of chemicals that interact with each other through chemical reactions and are transported through a medium by diffusion. These systems can create complex patterns and behaviors that are essential to the formation of life.

What can the Hypercycle teach us about the origins of life?

The hypercycle is a simple model for explaining the emergence of self-replicating systems. The model proposes that the first self-replicating systems on earth were sets of molecules that catalyzed each other's replication, forming a self-sustaining cycle of replication.  This interdependence creates a selection pressure that favors the evolution and adaptation of the system as a whole.  Over time, the theory goes, these self-replicating systems evolved and adapted, eventually giving rise to the first living cells.

It's worth noting that the hypercycle is an abstract model.  Generally speaking, the model does not propose a specific set of chemicals or reactions.  Instead, it's simply a model which lets us probe some of the properties that could give rise to such self-replicating systems.  In principle, hypercycle behavior can emerge from simple chemical reactions, RNA molecules,  proteins  or even entire organisms (of the three options, the "RNA world" hypothesis is the most popular).

So while the model doesn't predict the exact agents involved in the origin of life on earth, we can use simulation of hypercycles to explore all kinds of questions related to the origins of self-replication and life:

• What kinds of networks of chemical reactions can form self-replicating systems?
• What kinds of temporospatial dynamics give rise to stable populations?
• What are the effects of changing variables like reactivity and diffusion rates
• What other kinds of changes to the system (like temperature, introduction of other agents), can stabilize or destabilize self-replicating hypercycles?

In short, while it doesn't predict a specific set of agents or behaviors responsible for the origin of life, it can help us understand the conditions under which self-replication and life can emerge.

How do we build a Hypercycle simulation?

To build a hypercycle simulation, we need to understand the math behind the hypercycle.  The hypercycle can be described mathematically as a set of differential equations that describe the replication of each molecule in the system. These equations can be solved numerically to simulate the behavior of the system over time.

Formally, the hypercycle equations are defined as:

At each timestep, the chemical x_i is produced through a reaction with chemical x_j at a rate specified by k_i,j.  In most models, each chemical i reacts only with i-1, so this can be simplified–the summation term is replaced with a single reaction term.  k_i represents the rate of self-reproduction and degradation of a chemical itself (and can sometimes be ignored).   The φ term at the end is a degradation expression based on the concentration of all of the chemicals, which keeps the total concentration constant.

Additionally, to satisfy the cyclical nature of the model, we assume that the "first" and "last" chemical x refer to the same entity:

Things get really interesting when we introduce a spatial dynamic as well.  The math is similar, but occurs at every point on a huge grid.  Additionally, the chemicals spread out or diffuse slightly at each time step.  

To simulate and visualize the hypercycle, we'll build a discretized version of the reaction-diffusion system with spatial dynamics using OpenGL shaders in order to  create a realistic real-time simulation of a hypercycle.  Our strategy will be to create a texture that represents the spatial concentration of the chemicals at each pixel.  We'll use the standard 4 color channels (red, green, blue and alpha) to represent the concentrations of 4 different chemicals which comprise the hypercycle.  

Before getting into the details, here's a demo of our model that you can inspect and play with.  You can make changes to the model, or adjust the reaction, diffusion and decay constants to see what kinds of effect it has on the behavior of the system.

You can play with the model, including adjusting the core reaction and diffusion parameter values to see what effects it has on the system as a whole.  By modifying those values, we can create different kinds of visual patterns, transition the system from stable to chaotic dynamics  or "blow up" the simulation completely.

The Hypercycle Simulation in WebGL

To build our interactive hypcercycle simulation, we'll create a couple of simple pixel shaders in WebGL.  We use a simple wrapper called SwissGL to help us setup the WebGL environment and execute the shaders.  In this post we show only the shader code itself – if you wish to see the full code used to setup and execute the shaders, you can find it in the Codepen example above.

Our simulation is made up of three simple shader programs: one to initialize the data, one to perform our simulation at each timestep, and the last to display our simulation data on screen.  

First, we have a simple shader to initialize our data to some pseudo-random values.  This shader could be almost anything that produces initial data (including an existing image texture), but in this case, we use SwissGL's built-in random hash function to sample random data based on a seed we provide:

vec4 random = vec4(
  hash(ivec3(I, seed * 1.0)).x,
  hash(ivec3(I, seed * 2.0)).x,
  hash(ivec3(I, seed * 3.0)).x,
  hash(ivec3(I, seed * 4.0)).x
);
out0 = normalize(random);

The output of this shader is stored in a texture that represents the state of our system.

Next is the core simulation loop.  At each step, we compute the next state by taking the current state, then calculating and combining terms for reaction, diffusion and decay, and storing the results in an updated state texture:

precision highp float;

// Diffusion: sample a pixel in each direction, scale by diffusionRate 
vec4 current = texture(points, UV);
float dx = 1.0 / size;
vec4 n1 = texture(points, UV + vec2(dx, 0));
vec4 n2 = texture(points, UV + vec2(0, dx));
vec4 n3 = texture(points, UV + vec2(-dx, 0));
vec4 n4 = texture(points, UV + vec2(0, -dx));
vec4 diffusion = diffusionRate * (((n1 + n2 + n3 + n4) / 4.0) - current);

// Reaction: chemical x reacts with (x-1) scaled by reactionRate:
vec4 reaction = (reactionRate * current * current.argb);

// Decay: chemicals decay at decayRate (can be 0)
vec4 decay = current * (1.0 - decayRate);

// Output: sum our terms and normalize
out0 = normalize(decay + reaction + diffusion);

Note that our reaction term uses pixel swizzling to multiple each chemical concentration by the previous chemical concentration.  This is the "cycle" part of our simulation:  current.rgba * current.argb .

Finally, with the simulation state updated, we can display the state of our simulation on screen.  Though we could sample the simulation state texture directly and use the result as the color value to display, it doesn't always produce the best results.  Instead, we'll assign a color to each chemical in the simulation, and produce a final color value weighted by the concentrations of each chemical:

vec4 s = texture(points, UV);
vec3 color = (s.x * c1 + s.y * c2 + s.z * c3 + s.w * c4);
out0 = vec4(color, 1.0);

Probing the Origins of Life – In Software

The hypercycle model provides an intriguing framework for understanding the origins of self-replicating systems and the emergence of life on earth.  By studying the behavior of self-replicating systems, we can gain insight into the fundamental principles that govern the behavior of living systems.

The hypercycle is just one example of how mathematical models and computer simulations can help us better understand the real world, and in some cases, help us explore the mysteries and origins of life itself.

If you're developing an app which allows users to upload user-generated content such as photos, video or any other kind of document, you'll need to spend some time building out some infrastructure to handle file uploads.  

Typically these uploads are stored in a CDN or other storage provider such as Amazon S3. While the most straightforward solution is to upload files first to your backend server and then to the storage provider, this approach can cause performance issues and other problems.

In this post, we'll learn how to build secure, direct file uploads from web and mobile clients to AWS S3, skipping the step of sending the data to the server.  Though the code examples are presented in JavaScript both the server and client calls, this approach can work with any server and client technologies, including native mobile client apps.

Sever-Proxied Uploads vs Direct Client Uploads

The most straightforward approach to file uploads is to build out a backend API to process and deliver the file content to the storage provider.  This approach works okay, but it's a bit inefficient. Instead of delivering the file upload to its ultimate destination, you're transferring the file twice: first to your server, and then to your storage provider.  This means your upload is slow, and it consumes unnecessary server resources.

Furthermore, while the configuration of course varies by server software and hosting provider, you'll often find your app bumps up against file-size limits when you try to upload large files.  Just as an example, the popular nginx server, used to "front" many web services, has a default upload limit of 1MB.  This can be increased, but may be out of your control as an application developer, and even a larger setting may be too small for your application.

Direct uploads, in contrast, upload your content directly to the storage provider, by passing the need to upload the content to your own server.  This sounds simple, but is a bit tricky in practice!  To do a direct upload in a secure fashion, there are a couple of additional considerations.

Security Considerations of Direct Client Uploads

Direct client uploads offer a way to improve on the user experience and resource use problems associated with server-proxied uploads.  But implementing direct client uploads must be done with caution: if implemented incorrectly, it can lead to security issues like incorrect permissions or leaking of credentials.

The challenge is giving the client permission to upload the file in a secure fashion.  If we were to try to use the same credentials we use on the backend, it means they pass through the client and can be intercepted by an attacker.  Even if we create separate keys with limited access for the client, an attacker could still upload arbitrary content allowing them to fill up storage, perform DOS attacks, etc.  The only secure solution is to let a client upload only the content that we authorize.

Essential what we want is a one-time key that allows a direct upload of a file that we allow.  As it turns out, S3 (and other storage providers) allow us to generate something like this in the form of a pre-signed URL.  This is a URL referencing our S3 object, with a signature parameter appended.  This special URL allows us to write to the referenced object and only the referenced object.

Implementing Direct Client Uploads

Our approach to direct client uploads will leverage pre-signed URLs to let the client upload directly to our storage provider.  Of course, generating the pre-signed URL requires service provided credentials with sufficient credentials, so the signing cannot be done on the client.  Instead, we'll make a server request to validate the upload metadata (checking user authorization, file type, size, etc), generate a signed URL, and return it to the client.

The image below shows the difference in flow between a server-proxied upload and  a direct client upload.

Here are the basic steps to building a secure, direct client upload with a pre-signed URL:

• Implement a file input handler in client to receive a file from the user
• Send the file metadata to the server to validate the request
• Generate a pre-signed upload URL on the server and return it to the client
• Make a PUT request from the client to upload the file to S3

Server-Side Signed URL Generation

In the typical upload approach, our server holds AWS credentials which allow it to upload files.  In the direct upload approach, the client won't have direct access to these credentials–it would be highly insecure to put them in the client!

So in order to give the client permission to upload a file directly, we need to generate a pre-signed upload URL on the server, and send it back to the client.  The pre-signed URL is a URL to an S3 object which contains a signature that grants write permission to that resource (and of course, only that resource).

We'll implement a service on our backend to fetch the upload URL using the AWS SDK:

import AWS from "aws-sdk"

const s3 = new AWS.S3()

const getUploadURL = async (bucket: string, path: string, contentType: string) => {
  let putURL = await s3.getSignedUrlPromise('putObject', {
    Bucket: bucket,
    Key: path,
    Expires: 120,
    ContentType: contentType
  })

  return putURL
}

This function to generates our signed URL–next we'll write a quick service to expose the functionality.  For example, using the Express web server, we could write a service as follows:

app.post("/upload_url", async (req: Request, res: Response) => {
  let url = await uploadURL(userUploadBucket, req.body["path"], req.body["content_type"])
  res.send({ put_url: url })
})

Client-Side Upload Implementation

Once we've implemented the backend service, we'll use it to fetch the upload destination URL, then deliver our file content to the URL via a PUT request.

We'll typically implement this in the onChange handler of our file input.

const handler = (e: ChangeEvent<HTMLInputElement>) => {
  const files = e?.target?.files;

  if (files && files.length > 0) {
    let extension = files[0].name.split(".").pop()

    if (extension != null) {
        let response = await fetch(`${serverURL}/upload_url`, {
        	method: 'POST',
	        headers: { 'Content-Type': 'application/json' },
    	    body: JSON.stringify({ directory, extension, content_type: contentType })
       	})
            
        let json = await response.json()
    
        let uploadResponse = await fetch(json.url, {
          method: "PUT",
          body: content
        })
        
        // handle completion, update state to display uploaded file, etc
    }
  }
}

Tada!  With this code in place, we can perform uploads direct to S3 without sending them to a backend server first.

One Last Catch!  Displaying Uploaded Files

Though our upload implementation may be complete, the feature is probably not done yet!  In most web apps, after uploading the content, the uploaded file gets displayed back to the user.  The simplest way to do this is to use the newly uploaded URL.  The catch is that the upload URL we've generated doesn't actually allow us to view the object!  Instead, we need to generate another URL that will be used to view the object after it's uploaded.  Don't worry, this is simple!  We just have our original service return two URLs:

const uploadURL = async (bucket: string, path: string, contentType: string) => {
    var getURL = s3.getSignedUrl('getObject', {
        Bucket: bucket,
        Expires: 60 * 60 * 24 * 7,
        Key: path
    });

    let putURL = await s3.getSignedUrlPromise('putObject', {
        Bucket: bucket,
        Key: path,
        Expires: 120,
        ContentType: contentType
    })

    return { getURL, putURL }
}

Recap – Faster Uploads for Web & Mobile Apps 🎉

Direct client uploads to S3 are a great technique for building more responsive frontend applications.  By uploading your content directly to S3, you avoid the performance and resource consumption issues associated with sending large files through your backend server.

In case you haven't used it before, the Phoenix Framework is an amazingly powerful web development framework for the Elixir programming language.  It packs a ton of powerful features like channels for real-time websocket based communication, and LiveView, a server-rendered technology which enables the development of real-time interactive apps in the browser, without writing a line of JavaScript.  And because it's built on the Erlang/OTP, Elixir and Phoenix bring kick-ass support for scalability, fault tolerance and concurrency right out of the box.

Version 1.7 of Phoenix is now live, and it's packed with great new features, especially for LiveView. In this post, we'll take a look at the new features in Phoenix version 1.7, and why they matter.

Though LiveView already provided a great developer experience, this release feels like  "LiveView 2.0" in terms of the well thought out API changes and improvements.

Verified Routes

Verified routes are a new & greatly improved way to construct links within your Phoenix application.

When creating internal links in previous versions of Phoenix, we would typically use a route helper to generate a URL fragment for us.  For example, if we had a PageController defined in our router, and wanted to generate a link to it from somewhere else in the app, we might have code like the following:

# router.ex
get "/pages/:page", PageController, :show


# elsewhere in our app:
MyAppWeb.Router.Helpers.page_path(conn_or_endpoint, :show, "landing", options)

That works well, but can sometimes be a pain: it’s verbose, and requires knowledge of exactly how routes and actions are named. In practice, using helpers to generate URLs often involves consulting the router.ex file or using mix phx.routes to make sure you get the right module and action names.

It would be far simpler to just refer to the path directly when creating a link:

<a href="/app/pages/landing" />...</a>

However, writing the path like this comes with a major downside: you have no way of knowing at build-time if you get the path wrong or if it changes later on. There are no errors or warnings to tell you you’re using a broken path. (In fact, as an example, the path used above is incorrect, but we'd have no way of knowing!)

This is where verified routes come in: using Elixir's sigil syntax, we can reference a route with ~p in front of a string and take advantage of compile-time route validation.  It also allows us to add query params the way we would with the route helpers:

iex> query = [posts: 1, search: "elixir"]
iex> ~p"/pages/landing?#{query}"
"/pages/landing?posts=1&search=elixir"

LiveView Streams

A neat new feature to LiveView in 1.7 is the addition of streams.  LiveView Streams allow you to manage updates, inserts and deletes to large datasets without needing to store and reload the entire collection on the server as one would with a regular LiveView assignment.  They also helps to reduce the amount of re-rendering required to modify items on the frontend.

To create a stream, call stream/3 , providing the socket, the name of the stream, and the initial dataset:

  def mount(_params, _session, socket) do
    {:ok, stream(socket, :posts, Blog.list_posts())}
  end

Then, in then template, instead of accessing a @posts assign, you simply use @stream.posts instead.  If the contents of the collection change, you can use stream_insert/4 or stream_delete/3.  The  stream_insert/4 function handles both new records and updates, and also supports re-ordering of existing records.

Unified Rendering for LiveView & Static HTML

Phoenix 1.7 introduces a new Phoenix.Template rendering system which unifies how rendering works between static HTML and LiveView content.

Phoenix offers two distinct ways to render content: traditional static HTML, and  LiveView for building rich, dynamic web applications.  In practice, many applications use both approaches, depending on the type of content being rendered.  For example, you might use a controller-based static approach for a login page, but an interactive LiveView once the user is logged in.

In the past, the two different approaches to rendering had different APIs and conventions making it difficult to reuse templates and other functionality between the two.  With Phoenix 1.7, these differences are resolved with unified APIs using Phoenix.Template instead of Phoenix.View.

One of the most important changes is the introduction of unified function components that work in both LiveViews and in static-rendered controllers.  Previously, sub-templates would be rendered differently in a controller vs. within a LiveView.  Now, both kinds of content can use the new component approach:

# Rendering a table from a controller-based template (pre 1.7)
<%= render("table", user: user) %>

# Rendering a table from LiveView or controller (1.7)
<.table user={@user}>

This change greatly simplifies the developer experience for building content and enhances template reusability.

For backwards compatibility, you can still use Phoenix.View in your application, but may wish to migrate to Phoenix.Template to take advantage of the unified APIs.  Note that both Phoenix.Template and Phoenix.View are separate dependencies, so be sure to install the one(s) you need.

Collocated Views & Updated Directory Structure

A related change which helps to unify LiveView and controller-based rendering is in the directory structure: prior to 1.7, controller-based pages kept views and templates in a separate lib/my_app_web/views hierarchy, while LiveView typically placed template files right alongside the LiveView or LiveComponent module.

In 1.7, the "colocated" view approach is brought over to controller-based templates to unify the approach between the two.  Note that this applies not just to HTML templates, but also to other formats such as JSON views.  Keeping the template content closer to the controller code helps with project organization and consistency.  Like many of the other changes here, however, this change is optional and fully backwards compatible.

Component-Based Generators with Tailwind and More

Building on the new unified function component support, Phoenix 1.7 introduces a new set of standard Core Components for key HTML functionality such as forms, tables, etc:

<.simple_form :let={f} for={@changeset} action={~p"/posts"}>
  <.error :if={@changeset.action}>
    Oops, something went wrong! Please check the errors below.
  </.error>

  <input field={{f, :title}} type="text" label="Title" />
  <input field={{f, :views}} type="number" label="Views" />

  <:actions>
    <.button>Save Post</.button>
  </:actions>
</.simple_form>

These default components will be created for you in a core_components.ex file when creating a project with phx.new. The components, by default, use Tailwind for styling, but can be fully customized or replaced with other styling libraries such as Bootstrap, Bulma, or your own plain CSS if you'd like.

How to Upgrade

To update, you’ll want to follow the upgrade guide. In addition to simply updating dependency versions, you’ll need to make some changes throughout your existing project to make use of new modules and patterns.

I found it was useful to create an empty new 1.7 project from scratch and compare the generated files — there were a few files that were missing or changed after following the upgrade instructions. For example, the core_components.ex file mentioned above was missing since it's generated with phx.new, and the root-level  template HTML files were both updated (and moved).

Recap — the Best Web Framework Keeps Getting Getter

Phoenix 1.7 adds a number of great new features and refines the developer experience especially when working with LiveView.  Honestly, though LiveView already provided a great developer experience, this release feels a bit like "LiveView 2.0" just in terms of the well thought out API changes and improvements.

With this release, Phoenix remains one of the most exciting web frameworks out there today. It earns that distinction owing to the marriage of innovative and powerful high-level features like channels and LiveView, built on the rock solid, highly performance foundation of Erlang/OTP.

If you haven’t used the Phoenix Framework before, the 1.7 release is a great time to get started! Check out the following for further reading on what makes the Phoenix framework so powerful.

• Phoenix Framework official documentation & getting started guides
• Building real-time chat with Phoenix and LiveView in 50 lines of code
• Interactive Server-Rendered Webapps: You Don’t Need JavaScript
  

The pipe operator in the wonderful Elixir language is one of the most underrated features for developer experience.  Two simple, recently added functions can greatly enhance how the pipe operator is used, enabling longer and more readable computational pipelines.

Programming Elixir ≥ 1.6: Functional |> Concurrent |> Pragmatic |> Fun 1st Edition

by Dave Thomas

⭐️⭐️⭐️⭐️

In this post, we'll explore these two new functions, tap() and then().  We'll learn what they are, how they're used and see how they can be used with the pipe operator to write cleaner, simpler code in Elixir.

The Pipe operator in Elixir

If you've written any code in Elixir, you're probably familiar with the pipe operator.  The pipe operator in Elixir is a powerful tool that allows developers to write more readable and expressive code. It allows developers to chain together function calls, "piping" the output of one expression into the first argument of the next:

# A nested expression without the pipeline operator

function_d(function_c(function_b(function_a(value))))

# The same expression using the pipeline operator

value
|> function_a
|> function_b
|> function_c
|> function_d

The pipe operator helps to solve the "parenthesis hell" found in many languages, in which a deeply nested series of function calls leads to a mess of opening and closing parenthesis which can be difficult to read or to spot missing characters in.

Additionally, pipelines are easy to read because they present computation as a simple linear flow without variable bindings or inline flow control

Pipeline Side Effects with tap()

The first function to enhance the power of pipelines is tap().  The tap() function lets you add side effects to a pipeline.  In a functional programming context, side effects refers to actions which have effects other than manipulating the function's input value.  In practical terms this might include logging, saving data, analytics calls, etc.

If you use IO.inspect() or dbg() in your Elixir code, you're probably already familiar with the idea of inserting them into the middle of a pipeline.  This is especially common during development to provide additional logging to an application.  In the following example, we show a simple pipeline with an IO.inspect() call in the middle:

get_user_id()
|> MyApp.get_user()
|> IO.inspect()
|> render_user()

The tap() function is similar in spirit, but allows for other kinds of side effects than simple logging.  The function takes two arguments: an input value v, and a function f.  It executes the function f with the input, f(v), then returns the same input v unmodified.  Consider a scenario in which we need to perform some analytics logging when looking up and rendering a user record:

user = get_user_id()
|> MyApp.get_user()

Analytics.track(:user_viewed, user.id)

render_user(user)

Using the tap() function, we can insert the analytics call into our pipeline and continue with the computation:

get_user_id()
|> MyApp.get_user()
|> tap(fn user -> Analytics.track(:user_viewed, user.id) end)
|> render_user()

This lets us write longer pipelines without having to store intermediate values, and improves readability.

Transforming Pipeline Data with then()

Another challenge with pipelines is that the data we receive as the output from one function is not quite the input we need to another.  A common example of this might be when we need a particular field from a struct to perform a computation.

For example, imagine an authorization use-case in which we need to look up a user, fetch a permission field off of the user struct, then perform some sort of computation to determine whether the user has permission to take an action.  We might write this code as follows:

# Look up a user, get their permissions, see if they can edit the page

user = get_user_id()
|> MyApp.get_user()

can_edit = user.permissions
|> can_edit_page(page_id)

Using the then() function, we can improve on this and simplify our pipeline:

can_edit = get_user_id()
|> MyApp.get_user()
|> then(fn u -> u.permissions end)
|> can_edit_page(page_id)

Or, using the function capture operator (&):

can_edit = get_user_id()
|> MyApp.get_user()
|> then(& &1.permissions)
|> can_edit_page(page_id)

In effect, then() allows us to pipe computations into anonymous functions without breaking the pipeline.  This simple change lets us build longer pipelines without intermediate bindings or calls to functions defined elsewhere.

Recap: Build Better Pipelines with tap() and then()

Pipelines help improve code readability by implementing simple, linear flows of information, removing (or at the very least abstracting out) flow control and variable bindings.  While deceptively simple, these two new Elixir functions, tap() and then() can enable longer and more readable pipelines, and are part of what makes the Elixir language such a joy to use.

React Native 0.71 has just been released, touting a number of new features and improvements.  In this post, we'll take a look at what's new, why it matters, and how to upgrade your React Native app to take advantage of the latest version.

First-Class Support for TypeScript

The year is 2023, and there's really no reason to not be using TypeScript.  Well, actually, sometimes the thing that holds people back from using it is lack of support in the libraries and frameworks they rely on.  Though React Native has had TypeScript support for years, enabling it has involved bringing your own configuration and manually installing separate type definition packages.

As of React Native 0.71, there's no longer any excuse: the new version has first-class support for TypeScript, including bundled type definitions, eliminating the need for external dependencies.  This means that enabling TypeScript in your project is even simpler than before. In fact, if you create a new project via the React Native CLI, TypeScript is now enabled by default.

As part of the effort to add first-class TypeScript support, the React Native team has updated all of the documentation to include type information.  This is a very nice touch, as projects sometimes add TypeScript support, but frustratingly don't provide type information in the docs, forcing developers to sift through source files to hunt down the types themselves.

Why it Matters

Using TypeScript in your React Native project will help you find and fix issues in your code before they're shipped.  While the lack of formal TypeScript support in the past may have kept you from adding it to your project, first-class support in React Native 0.71 means now is the time to start using it.  TypeScript is a massive win for code quality and developer tooling, and is simply where the industry is going.  

Improved Layout with Flexbox Gap

React Native 0.71 adds a number of enhancements to layout & styling.  One of the most notable changes is the addition of flexbox gap support to the React Native layout engine.

React Native's flexbox-based layout engine already provides a powerful way to produce responsive mobile designs.  But managing the spacing between elements can be a bit tricky and sometimes downright annoying.  

The usual approach to managing the space between elements is with the margin style.  The main problem with margin is that it's typically applied to all sibling elements (like all Views in a list), resulting in unwanted margins at the start or end of the elements (or both), as well as doubled margins between elements:

The usual solution is simple enough, but a bit ugly: apply margin only on the right, and then use no margin for the last item.  While this approach works well enough, it does require special case logic and a style change for one item in the list.  Okay, okay, that's not the end of the world, but now there's a better way: flexbox gap.

gap is a style attribute applied at the container level rather than at the item level, and does exactly what we want: it controls the gap size between items without introducing any unwanted space.

Why it Matters

gap is a relatively new addition to flexbox, but I've been using it happily on the web for a while now.  While it is a simple feature, it does invoke a feeling of "where has this been all my life?", and it removes the need for hacky CSS selectors or extra styling logic in your JavaScript.  Introduction of flexbox gap support in React Native is a huge win for developer and designer ergonomics.

New Architecture Updates

One of the most important change in React 0.71 is the continued rollout of the New Architecture.

If you've been following React Native development for a while, you'll note that  "New Architecture Updates" have been touted in the last several versions.  You might cynically think that the "New Architecture" is some kind of vaporware that is never actually completed – but this is far from the truth!  There are a couple of reasons that the New Architecture updates are an ongoing effort over several releases.

First, the term refers not to just one architectural change, but several independent improvements to React Native:

• Hermes – a high performance JavaScript engine
• Turbo Modules – the new native module system
• Fabric – new optimized rendering system

Second, the changes have mostly opt-in and are at various levels of maturity.  For example, the Hermes engine has been stable and enabled by default since version 0.70.  Other changes, such as the Fabric rendering system, need to be manually enabled and are still considered in beta.

Finally, the rollout of some of the changes is, in practice, dependent on upgrades from popular 3rd party packages.  The current stable release of the popular Reanimated package, for example, is not compatible with the new Fabric renderer, though a pre-release version does include support.

0.71 continues the rollout of the new architecture with massively improved build performance using pre-built artifacts, a greatly simplified integration process on iOS (via the new RCTAppDelegate class) and a number of bug fixes & other improvements

With the changes in 0,71 (and using the pre-release version of Reanimated), I was able to get my app fully up and running with Fabric and the new architeture, though I did encounter some cosmetic issues due to another 3rd party package in my project.  I'll probably hold off on leaving it enabled until the 3rd party issues are fully resolved, but it's amazing to see the full new architecture in action.

Why it Matters

Though React Native's new architecture is a work-in-progress, every new release provides real, incremental value to React Native developers.  If you haven't already enabled Hermes, for example, it's now fully supported and will your app give a major performance boost.  And while Fabric is still considered experimental, it's definitely time to start getting your app ready for the change with React Native 0.71.

How to Upgrade

Upgrading React Native can be tricky, but there are a couple of tricks to make the process a bit smoother.

First, double-check the latest version of React Native.  As of this writing, version 0.71.1 of React Native has been released with some minor improvements, so when following the instructions below, be sure to use the latest version!

Next, you'll need to update a number of core dependencies.  Updating React Native to 0.71.1 is the main change, but a number of other packages will need to be upgraded as well.  While you can try to do this manually, there's a community maintained tool you can use to show you all of the outdated dependencies in your project:

npx @rnx-kit/align-deps --init
npx @rnx-kit/align-deps --requirements react-native@0.71

Once you've update your core dependencies, you'll also need to make a number of changes in some supporting files in your project, such as the native project build files.

The best way to see the full list of changes needed is to use the React Native upgrade helper tool.  This tool lets you specify your current version of React Native and shows all the changes needed to upgrade to version 0.71.1.  For example, if you're upgrading from 0.70.6 to 0.71.1, here's the full list of changes you'll need to make.

If you're upgrading from a much older version of React Native, the list of changes can be huge and frankly, pretty intimidating. In this case, it can sometimes be more efficient to create a pristine new React Native 0.71.1 project and migrate your components & application code over to the new project.  Or, use the new project for reference and copy over files individually to your existing one.

My own upgrades from 0.70 went pretty well, though I did enounter one issue with the popular react-native-splash-screen package.  Fortunately, others had already encountered the issue and found a simple workaround:

not working splash screen for react-native 0.71.0 · Issue #606 · crazycodeboy/react-native-splash-screen

Run react-native info in your project and share the content. What react-native-splash-screen version are you using? 3.3.0 What platform does your issue occur on? Both Describe your issue as precise...

GitHubcrazycodeboy

Recap

React Native 0.71 introduces a number of new features, some of which offer immediate value to React Native developers, while others provide steady infrastructure improvements and longer term value.

For a full list of changes in React Native 0.71, checkout the official blog post on the topic.

Professional React Native: Expert techniques and solutions for building high-quality, cross-platform, production-ready apps

by Alexander Benedikt Kuttig

⭐️⭐️⭐️⭐️⭐️

Today I'm happy to introduce Blixtcode, a new tool for creating & sharing beautiful videos of code samples.  Here's a quick example of the kind of video you can build:

Why Blixtcode?  I've seen lots of great tools for sharing static images of code samples, but couldn't find anything for videos, so I decided to make our own.

The tool is still in development, so your feedback is greatly appreciated.  Give it a try for yourself and let me know how you like it!

According to Stack Overflow's yearly developer study for 2022, JavaScript remains the most popular language for the 10th year in a row.  The language continues to grow in popularity and is now the language of choice for many not only on the frontend, but also the backend.

JavaScript has also matured greatly over the past several years, with new tooling and frameworks that make JavaScript development a more consistent and pleasurable experience.  And the adoption of TypeScript means JavaScript developers are now producing better quality code with fewer bugs, making it a more defensible choice for serious projects.

If you haven't learned JavaScript yet, or are looking to expand your horizons, now is the perfect time.  In this post, we'll look at 5 different recommended books for learning JavaScript, each coming at the language from a unique angle.

Learn the Basics

If you've never worked with JavaScript before and are looking to learn the fundamentals, JavaScript from Beginner to Professional is an excellent choice.  The book is filled with hands on examples of real-world JavaScript applications and covers just enough HTML, CSS and canvas background to build a variety of projects.

This is an excellent choice for those approaching JavaScript for the first time, or for more novice JavaScript developers looking to expand their horizons.

JavaScript on the Backend with Node.js

While most JavaScript resources are focused on frontend development, JavaScript is a solid choice for building out backends as well.  The book Node.js: The Comprehensive Guide to Server-Side JavaScript Programming teaches JavaScript with a focus on the server-side.

The book covers building backends using the Express and Nest.js frameworks, using REST and GraphQL to build out server-side APIs.  It also covers more advanced server-side topics such as scalability, performance, testing and security.

This book is an excellent resource for frontend developers looking to apply their JavaScript knowledge to the backend and become more full-stack developers.

Frontend Essentials with JavaScript, HTML & CSS

If you're learning JavaScript with a focus on fonrtned design, but haven't yet mastered HTML & CSS, you'll definitely want a resource that teaches all three.  The book Teach Yourself HTML, CSS and JavaScript covers the basics of JavaScript, but also covers HTML and CSS in detail at the same time.

This book is a good choice for developers who are learning JavaScript specifically for frontend development, and for those who are more interested in the visual and design aspect.  It's also a good choice for people completely new to web development who haven't yet learned how HTML, CSS and JavaScript work together to build interactive applications.

Level Up with TypeScript

If you already know  JavaScript and are looking to bring your skills up to a more professional level, I definitely recommend mastering the TypeScript language. TypeScript is essentially a typed version of JavaScript, which means it helps you produce better quality code with fewer bugs.  The book Learning TypeScript is a great resource to get you started.

If you're learning JavaScript to land a position and a tech company, TypeScript is practically a prerequisite these days–it's where the industry is heading. I actually recommend that all developers learning JavaScript should learn TypeScript, but because TypeScript is a superset of JS, it's okay to learn JavaScript first before diving in.

For Younger JavaScript Learners (or for the Young at Heart)

For younger learners, JavaScript for Kids is a great option. It teaches the basics of JavaScript and programming in general, and builds out kid-friendly projects like games and animations along the way.

In spite of the title, this book isn't just for kids–many of the reviews mention this book is great for adults too.  In particular, for adults learners without any kind of programming experience, this book teaches basic programming techniques in approachable, easy-to-understand lessons.  The book is a great choice for kids, or for adults who are looking to learn the fundamentals of JavaScript and programming in general before taking on some of the more advanced resources.

Learn JavaScript in 2023!

In 2023, the JavaScript language is more popular than ever.  If you've been putting off learning JavaScript, there's no better time than the present to dig in.  Whether you're looking to broaden your knowledge to land a backend developer job, or are just getting started with programming, there are resources here to help you on your journey.  And in case none of these books are of interest to you, here are some other places to get started on your JavaScript learning:

• JavaScript basics on JavaScript.com
• A wealth of tutorials from W3schools.com
• More JavaScript articles on Blixtdev

Though there are more choices than ever, React remains the king of web frontend development frameworks and there's never been a better time to start learn it.  We've compiled a list of 5 books that address different aspects of React development and can help you become a React master in 2023.

When choosing a resource on learning React, it's important to get one that's up to date.  React has changed a lot over the years, so be sure to pick one that teaches  React 18 and addresses the latest techniques: functional components, hooks, error boundaries, etc.

Our list of React books features several high-quality, up-to-date resources for learning React and related technologies.  While all of these books cover some React basics, they each also address React development from a slightly different angle, covering various advanced techniques as well, such as React Native development, backend integrations, etc.

Without further ado, here are our favorite books you can use to learn React in 2023!

Learning the Basics

If you're not at all familiar with React or relatively new to programming in general, we recommend React: Up & Running: Building Web Applications.  This book covers all of the basics of React app development: JSX, tooling, basic hooks, basic state management, and much more.

React: Up & Running: Building Web Applications 2nd Edition

by Stoyan Stefanov

⭐️⭐️⭐️⭐️

The book does assume a bit of JavaScript knowledge, so be sure to brush up on your JavaScript before starting with this (though to be honest, one of the best ways to improve your JavaScript is to simply dive in).

Learn Common Patterns, Tools & Techniques

Once you've learned the fundamentals of React and start building an application, you'll almost certainly run into some bigger challenges: how do you manage state and server communication in a large application?  How do you handle authentication?  How do you test and debug applications?

React Cookbook: Recipes for Mastering the React Framework 1st Edition

by David Griffiths and Dawn Griffiths

⭐️⭐️⭐️⭐️⭐️

The book React Cookbook: Recipes for Mastering the React Framework focuses on some of these common application development challenges and gives a cookbook for solving them.  While these kinds of application development challenges are not unique to React, there are most certainly patterns and tools that experienced React developers use to solve them–this book shows you how.

Master React Hooks

One of the biggest changes in the React ecosystem over the past several releases has been the migration to using functional components and hooks.  Understanding how hooks work is key to understanding the lifecycle of functional components as well as the philosophy behind modern React development.

Learn React Hooks: Build and refactor modern React.js applications using Hooks

by Daniel Bugl

⭐️⭐️⭐️⭐️⭐️

While any up-to-date React resource will address the basics of hooks like useState and useEffect,  we recommend Learn React Hooks: Build and refactor modern React.js applications using Hooks for learning more advanced hook techniques and in particular for developers working with code containing older-style class components.  This book can help developers to adapt and refactor class components into modern functional components.

Go Full-Stack & Learn the Backend

If you're learning React because you're a full-stack kind of developer or if you're on a mission to build a particular application, you might want to learn frontend and backend development at the same time.  In that case, you'll benefit from a resource which addresses both, and shows how they work together.

Full-Stack Web Development with GraphQL and React: Taking React from frontend to full-stack with GraphQL and Apollo 2nd Edition

by Sebastian Grebe

⭐️⭐️⭐️⭐️

The book Full-Stack Web Development with GraphQL and React: Taking React from frontend to full-stack with GraphQL and Apollo shows not only how to build a React frontend, but also a fully functional backend and how to make them work together.  This is a great resource which shows the "big picture" of full-stack web application development, not just a siloed frontend approach.z

Go Native and Build for Mobile & Beyond

If you already know some React but are looking to start building native mobile apps for iOS and Android, React Native is a great tool.  If you can build an app with React, you get started with React Native mobile apps in no time.

Professional React Native: Expert techniques and solutions for building high-quality, cross-platform, production-ready apps

by Alexander Benedikt Kuttig

⭐️⭐️⭐️⭐️⭐️

While React developers will have no problem getting started with the basics of React Native development, there are a number of more advanced topics you'll want to master to truly become a React Native developer such as native animations, build tools, CI, automation.  We recommend Professional React Native: Expert techniques and solutions for building high-quality, cross-platform, production-ready apps to learn about these techniques.

Learn React in 2023

No matter which approach you choose, these are some great resources for learning React in 2023.  In addition to these books, there are also some great free resources to help you learn.  Here are some places to get started!

• The React team's Intro to React tutorial
• The official React documentation
• More React articles on Blixtdev