Forem: Will Ceolin

Where's the layer panel/variable mode in Figma UI3

Will Ceolin — Sun, 17 Nov 2024 16:32:37 +0000

Most tutorials showing how to create light/dark mode toggles in Figma tell you to go to the Layer section in the Design panel. However, that panel was renamed in the latest UI3 Figma design.

You can go to Appearance -> Apply variable mode (it's the first icon) to accomplish the same thing now:

How to run a local Phoenix app on another machine

Will Ceolin — Wed, 08 May 2024 16:09:55 +0000

When you create a new Phoenix app, it uses the 127.0.0.1 IP address by default. To run it locally on another machine (e.g. your phone), you need to change this on config/dev.exs.

Find the http config on that file. You’ll see something like this:

http: [ip: {127, 0, 0, 1}, port: 4000]

Now, change it to:

http: [ip: {0, 0, 0, 0}, port: 4000]

That’s it! Now you’ll be able to test your Phoenix app locally on other machines by using your network’s IP address.

Phoenix LiveView: When to use navigate, patch, href, redirect, push_patch, push_navigate

Will Ceolin — Wed, 18 Oct 2023 11:47:59 +0000

TL;DR

navigate and push_navigate: When you're navigating to the same live_session.
patch and push_patch: When you're navigating to the same module/page/liveview. For example, when only the attributes change - from /posts/1 to /posts/2.
href and redirect: When you're navigating to another live session or outside a live view.
Don't use navigate when navigating to another live_session.

Examples

Let's say we have the following routes:

live_session :public_routes do
  live "/", HomeLive
  live "/posts", PostsLive
end

live_session :private_routes do
  live "/posts/:id/content, PostEdit, :content
  live "/posts/:id/metadata, PostEdit, :metadata
end

We have two live sessions: public_routes and private_routes.

From / to /posts

In this case, we'll use navigate (client) or push_navigate (server) because we're navigating to the same public_routes live session:

<.link navigate={~p"/posts"}>Posts</.link>

This will keep the browser page but mount a new LiveView process to reload its content only.

From /posts to /posts/:id/content

In this case, we'll use href (client) or redirect (server) because we're moving from the public_routes live session to the private_routes one:

<.link href={~p"/posts/#{post.id}/content"}>Edit</.link>

This will cause a full page reload.

From /posts/:id/content to /posts/:id/metadata

In this case, we'll use patch (client) or push_patch (server) because we're navigating to the same page/module. We're only changing the page attributes:

<.link patch={~p"/posts/:id/metadata"}>Metadata</.link>

When using patch you'll also need to define a handle_params callback to handle the parameters change.

While navigate mounts a new live view, patch updates the current live view, sending less data back.

Motivation

I recently made a mistake where the topbar would be displayed twice while navigating between different live sessions. This happens because I tried to:

live navigate (<.link navigate) across live sessions, which requires an extra round trip to the server and looks like the cause of your unwanted behavior. Regular link href is all you need here and it will not dispatch the loading event in that case, resolving the behavior you're seeing.

Reading the docs, it was confusing to me to understand the difference between all those options, especially because I was looking at the wrong places.

I was looking the push_navigate/2 and push_patch/2 docs but a better explanation is available on the live navigation and link attributes docs.

How to get the host from a LiveView Socket

Will Ceolin — Mon, 25 Sep 2023 17:09:35 +0000

First, you need to allow the WebSocket to display the URI. You can do it by editing your endpoint.ex file:

socket "/live", Phoenix.LiveView.Socket, websocket: [connect_info: [:uri, session: @session_options]]

In the example above, we added :uri the connect_info websocket option.

Now, we can create a mount hook to get access to the host value. In the example below, we'll add the host to our socket assigns, so we can use it in our LiveView with socket.assigns.host:

# host_plug.ex
def on_mount(:add_host, params, _session, socket) do
  %URI{host: host} = Phoenix.LiveView.get_connect_info(socket, :uri)

  socket = Phoenix.Component.assign(socket, host: host)

  {:cont, socket}
end

Now, you need to add this mount hook to our live_session in our router.ex file:

scope "/", MyAppWeb do
  pipe_through [:browser]

  live_session :my_routes,
    on_mount: [{MyAppWeb.HostHook, :add_host}] do
    live "/", HomeLive
  end
end

That's it! Now we can get the host in our LiveView by using socket.assigns.host.

Note: If you're getting an error like this: ** (MatchError) no match of right hand side value: nil, it might mean that you forgot to add :uri to your connect_info as I mentioned on the first step.

How to use stripe-mock with GitHub Actions

Will Ceolin — Mon, 26 Jun 2023 17:36:08 +0000

stripe-mock is a library that allows you to mock the Stripe API. It's useful for testing purposes when you don't want to make requests to the actual API.

You can also use it with GitHub Actions on the testing pipeline for your CI environment.

stripe-mock has a Docker image you can use on GitHub Actions: stripe/stripe-mock.

This allows us to use service containers to run the mock server:

jobs:

  test:
    runs-on: ubuntu-latest

    services:
      stripemock:
        image: stripe/stripe-mock:latest
        ports: ['12111:12111']

That's it! Now the mock Stripe API will be running on port 12111 when you run your tests on GitHub Actions.

How to fix the "Callback info about the Mix.Task behaviour is not available." error from Dialyzer

Will Ceolin — Wed, 12 Apr 2023 19:44:23 +0000

Add this to the dialyzer options in your mix.exs file:

def project do
  [
    dialyzer: [
      plt_add_apps: [:mix]
    ]
  ]
end

Unit testing a page title on Phoenix LiveView

Will Ceolin — Fri, 07 Apr 2023 20:49:45 +0000

TL;DR:

assert page_title(lv) =~ "my page title"

Phoenix LiveView has a live_title/1 component that allows us to easily update a page title and see those changes reflect in the browser.

They also have a page_title/1 function to test if your page title was updated using the page_title assign.

You can use it to make sure you're assigning a page_title to your pages:

def mount(_params, _session, socket) do
  {:ok, assign(socket, :page_title, "My page title")}
end

How to clear Elixir warnings on VSCode

Will Ceolin — Fri, 07 Apr 2023 20:36:52 +0000

After making changes to my Phoenix project, VSCode often gives me warnings:

Phoenix.LiveView.TagEngine.component/3 defined in application :phoenix_live_view is used by the current application but the current application does not depend on :phoenix_live_view.
Invalid type specification for function coming from the ElixirLS Dialyzer.
And other warnings that I don't remember now.

Here are some the things that help me to clear those warnings on VSCode:

Delete the _build, .elixir_ls and deps directories.
Reinstall dependencies: mix deps.get
With an .ex file open, go to the Command Palette (Cmd + Shift + P) and run these commands: Elixir: Trigger mix clean --deps in language server and Elixir: Restart language server, then restart VSCode.

If Elixir (not VSCode) starts complaining about routes not found, then you can delete the _build directory and compile your project again (mix compile).

How to find what changed between two Phoenix versions

Will Ceolin — Tue, 07 Mar 2023 21:46:36 +0000

TL;DR: Just use Phoenix Diff.

Phoenix generators are great and flexible because they don't have any magic into it. You can easily change the generated code. However, this flexibility comes with a price: When something changes, it can be hard to find out what you need to change in your generated code as well.

As someone new to Elixir & Phoenix, that's an issue I'm often facing - and so is Greg Coladarci, who posted about this on the Elixir Forum.

That's how I found out about Phoenix Diff, a tool created by Navin Peiris and maintained by Aaron Renner. Thank you, Matt Jones, for the tip!

36 companies hiring globally

Will Ceolin — Fri, 17 Feb 2023 08:16:11 +0000

I often wasted time applying to "remote" jobs just to find out they were "US only", "East Coast only", "Europe only", etc.

It was kinda hard to find companies that hire globally. So, I've created a list to compile them all. I'm adding the initial list below but you can keep contribute to it on GitHub:

ceolinwill / global-hiring

A list of companies hiring globally.

Global Hiring

Have you ever spent a lot of time applying for a remote job just to find out the company you're applying to doesn't hire in your country This happened to me. That's why I've decided to create a list of companies hiring globally.

My goal here is to group companies with a global hiring policy. This means: Companies that don't have restrictions on where you can live Companies hiring US only, East Coast only, Europe only, etc. shouldn't be included here.

Some context: There are lots of lists for remote companies. @yanirs has this awesome established remote companies list, for example. We also have websites such as RemoteOK and FindAsync where we can find remote jobs. However, many remote companies don't hire globally.

Contributions are welcome.

Why hiring globally?

Some of the benefits include (feel free to improve this list):

Access to a larger talent pool: When…

View on GitHub

The list

Company	Business/products	Languages	Open Salary
37 Signals	Productivity tools	Ruby	Yes
AcceleratorApp	Incubators, accelerators	TypeScript	No
Airbase	FinTech	Python, JavaScript	No
Almanac	Collaboration tools	Ruby, JavaScript	No
Automattic	Open-source tools	PHP, JavaScript	No
Buffer	Social media tools	PHP, JavaScript	Yes
Cal	Scheduling infrastructure	TypeScript	Yes
Deepgram	Speech recognition	Python	Yes
Deno	Developer Tools / PaaS	Rust, TypeScript, WASM	No
designstripe	Design tools	TypeScript, Python	No
Doist	Productivity	Python, TypeScript	No
Empower	FinTech	C#, Kotlin, Swift	No
Fly.io	Cloud hosting	Rust, Go, Ruby, Elixir	Yes
Forem	Blogging platform	Ruby, JavaScript	Yes
Ghost	Blogging platform	JavaScript	No
Giant Swarm	Cloud		No
Gumroad	Platform for creators	Ruby, JavaScript	Yes
Invisible	Operations as a Service	Python, Typescript	Yes
Iterative	Machine learning	Python, TypeScript	Yes
Migaku	Language learning	JavaScript	Yes
OpenCraft	E-learning	Python, JavaScript	No
Ox	Coversation coach	Python, TypeScript	No
Pitch	Presentation tools	TypeScript	No
Protocol Labs	Web3	JavaScript, Python, Go, Rust	Yes
Proxify	Hiring/vetting developers	Java, Golang	Yes
Remote	Global hiring and payroll	Elixir, TypeScript	No
rtCamp	WordPress projects	PHP, JavaScript	No
SafetyWing	Insurance for nomads	Java, Kotlin, JavaScript	No
Service Bell	Live chat	Python, TypeScript	No
Spruce	Identity control	JavaScript	No
Standard Bots	Robotics	C++, TypeScript	No
Sticker Mule	E-commerce	Golang, JavaScript	Yes
Unsplash	Stock photos	Ruby	No
Xapo Bank	Banking, crypto	Python, Kotlin	No
Wikimedia	Non-profit	PHP, Python, Go	No
Zapier	Automation tools	Python, JavaScript	Yes

How to add a link to an image in Phoenix

Will Ceolin — Sat, 11 Jun 2022 20:49:00 +0000

Edit (2023-05-11): This is much simpler in Phoenix 1.7+ thanks to Verified Routes:

<.link navigate={~p"/post/123"}>
  <img src={~p"/images/logo.png"} alt="Logo" />
</.link>

Let's say you have an image and you want to link it to another route in the Phoenix Framework. You can use link/2 with a code block to accomplish that:

<%= link to: Routes.page_path(@conn, :index) do %>
  <img src={Routes.static_path(@conn, "/images/phoenix.png")} alt="Phoenix Framework Logo"/>
<% end %>

In the example above, we'll link the Phoenix logo (phoenix.png) to the home page.

13 features I wish Firebase had

Will Ceolin — Tue, 25 Jan 2022 14:32:24 +0000

I love Firebase. I love how quickly it allows me to develop a new product without having to worry about infrastructure. I feel like Firebase is a dream for indie developers.

However, Firebase isn't perfect. There are some important features I wish they would work on. Some of those are now handled by products such as PlanetScale and Xata.

But I love using Firebase. I think they have the potential to really be a BaaS (Backend-as-a-Service), providing everything you need to run a backend without having to worry about infrastructure and scale.

Yesterday, Michael Bleigh from Firebase, asked this on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1485665341439033345-538'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1485665341439033345&theme=dark" }

So, I've decided to write this post in response with the most important features I wish Firebase would have right now.

1. Full-text Search

I don't think I ever worked on a project where I didn't need full-text search at some point. We usually end up having to use something like Elastic or Algolia. They're great services and Firebase even recommend them but it would be great if full-text search would be included in their SDK, at least for Firestore.

I hope one day we can simply run a query like this:

const postsRef = collection(db, 'posts');
const query = await searchCollection(postsRef, 'da vinci');

That query would return all posts where the word da vinci is mentioned based on a ranking that we could define using a configuration file (e.g. firestore.search.json):

"posts": {
  "priority": ['title', 'content', 'author']
}

We could also override the priority when we run our query by specifying which fields we want to search on:

const postsRef = collection(db, 'posts');
const query = await searchCollection(postsRef, 'da vinci', ['author']);

The query above would run a full-text search on the author property only.

2. Aggregation queries

When I need data aggregation I either use Cloud Functions (for simpler aggregations) or I don't use Firebase at all. I know data aggregation is hard to accomplish on Firestore but it would be a game-changer for their product if they manage to do it.

I'd love to see queries like these:

const postsRef = collection(db, 'posts');
const queryRef = query(postsRef, where('author', '==', 'davinci'));
const postsCount = await count(queryRef); // 242

Where I count the number of documents in a given collection based on a specific query. The query above, for example, would return the number of posts a specific user has published.

I'd love to see similar queries for other data aggregations such as sum, average, min, max, etc. For example, a few years ago I was working on this IoT application where we needed to display real-time aggregated data for energy consumption. We weren't using Firebase for that but, given Firebase's real-time capabilities, it would have been amazing to use it if it would support data aggregation like this:

const consumptionRef = collection(db, 'consumption');

const queryRef = query(
  consumptionRef,
  where('customerID', '==', 'uid')
  where('createdAt', '>=', '2021-01-01')
  where('createdAt', '<=', '2021-01-31')
  groupBy('hour')
);

const consumption = await sum(query, 'kwh');

The query above would sum all values from the kwh field grouped by hour based on the createdAt property. It would return something like this:

[{
  "date": 2021-01-01 00:00:00,
  "kwh": 0.05
}, {
  "date": 2021-01-01 01:00:00,
  "kwh": 0.04
}, {
  "date": 2021-01-01 02:00:00,
  "kwh": 0.03
}, { ... }]

In theory, I'm already able to accomplish something similar to that using Cloud Functions where I'd have an onWrite trigger for the consumption collection and it would update a _dataAggregation/{collectionName}/{consumerID}/{dateGroup} document (i.e. _dataAggregation/consumption/123/2021_01_01_01_00_00). But that's too much work, so I don't use Firebase when I need that kind of aggregation.

However, I'd love if Firestore would allow us to setup data aggregations similar to how we're able to have indexes. We could have a firestore.aggregation.json file like this:

[{
  "collectionName": "consumption",
  "operation: "sum",
  "kind": { "type": "date", "field": "createdAt" },
  "groupBy": ["hour", "day", "month", "year"],
  "filters": ["customerID", "roomID"],
  "field": "kwh"
}]

When we deploy a new aggregation file, Firestore would automatically create those aggregations and watch for changes in the specified documents/fields to update the aggregation - similar to how we'd do this using Cloud Functions but automatically.

3. Detailed usage logs

Sometime ago I ran into an issue where my Firestore bill had a spike but I didn't see an increase in traffic. Debugging that was really painful. The spike was coming from the number of reads. Initially, I thought I was suffering an attack (we didn't have AppCheck back then) but that wasn't the case. It turns out, I had a Cloud Function that was reading (extremely) often from a collection.

My life would have been much easier if Firebase would provide detailed logs of reads/writes/deletes for each document. Key Visualizer may help with this nowadays but it would be amazing to have easily accessible logs from the Firebase Console. For example:

Go to the "Usage" tab on Firestore.
Select "Reads", "Writes", or "Deletes".
Group by "collections" or "documents".
Order then by ascending or descending.

4. Joins using references

Firestore has a Reference data type but it isn't very useful at the moment. I wish we could use References to automatically have joins.

For example, let's say we create the following post in our database:

const post = {
  author: doc(db, 'users', user.uid),
  content: 'whatever',
  createdAt: serverTimestamp(),
  title: 'hello world!'
};

I know Firebase isn't a relational database but I wish it would automatically create a relation between the author field and its reference. So, when I'd fetch this post, I could do author.name to get the author name, for example.

We can do this using Cloud Functions and adding a authorData field and keep it in sync with author/{authorID} but it would amazing if Firestore would automatically do this for us.

In their backend, they could have a trigger that automatically fetches the author document when the post is created and they could automatically update the author data when users/{userID} changes. This way our queries would still be fast and cheap but we wouldn't have to handle this logic by ourselves.

5. Automatic backups for Firestore

The official Firestore documentation has a tutorial on how to backup your Firestore database periodically. But I wish they would do backups automatically, at least on a daily basis, and provide an one-click option in the console to restore (or download) a backup.

6. Data migration

Doing data migrations on Firestore can be painful. I wish Firebase would provide an official tool for handling that. Something that we could call from the CLI:

# Create a new /migrations/2022_01_20_10_28_54-rename-post-author.js file
firebase migrate new rename-post-author

# Run pending migrations
firebase migrate

# Run a specific migration
firebase migrate up 2022_01_20_10_28_54-rename-post-author.ts

# Undo a migration
firebase migrate down 2022_01_20_10_28_54-rename-post-author.ts

Migration files would need to have up and down functions:

const postsRef = db.collection('posts');

async function up() {
  const posts = await postsRef.get();
  const batch = db.batch();

  // Rename post author for each post
  posts.forEach((post) => {
    const data = post.data();

    const updates = {
      author: data.user,
      user: deleteField()
    };

    batch.update(post.ref, updates);
  });

  return batch.commit();  
}

async function down() {}

7. Migration branches

Databases such as PlanetScale and Xata are using version control for data migrations. It's easier to update your data structure without breaking anything in production. I wish Firebase would have that feature too.

We could use the Firebase Migrate tool I suggested on the item above to create new branches:

# Run the migration on a new branch
firebase migrate -b rename-post-author

# Create a merge request to merge our feature branch into main 
firebase migrate -mr rename-post-author main

# Interactive panel to list all merge requests and merge them
firebase migrate -lmr

8. SSR Hosting deployed to the edge

Hosting services like Vercel, Fly.io, and CloudFlare Workers allow you to deploy both static files and server-side code close to your users (the edge). I wish Firebase Hosting would also allow us to do it.

Right now, Firebase Hosting only allows us to deploy static files. If we need server-side rendering, then we need to use Cloud Functions on top of it, which adds complexity and it has the cold starts issue.

I wish Firebase Hosting would allow us to deploy server-side code to the edge without using Cloud Functions. It would be another step to use only Firebase for a full-stack application.

9. Custom error messages for Security Rules

When a security rule fails, we get a Permission denied error from Firestore. I remember reading somewhere they do this for security rules because they don't want users to know which security rule failed.

However, sometimes it's useful to show users a specific validation failed. I wish Firebase would allow us to write custom error messages for each security rule. For example:

match /posts/{postID} {
  allow create: if
    custom({
      rule: request.resource.data.description.size() < 1000,
      message: 'The post description needs to have less than 1000 characters.'
    })
}

This would allow us to use fewer client-side validations and rely on the error messages coming from the backend (Firestore).

10. Deploy Firestore to the edge

When we create a new Firebase project, we need to choose which region our GCP resources will live in. That includes where our Firestore database will be located. That's not ideal for global services because some requests will be far away from users, adding latency.

It would be amazing if Firestore would be deployed to the edge (close to users).

11. JSON import/export for the Firestore Emulator

The Firestore Emulator allows us to import/export but it does so in its own format. Sometimes, it's useful to fetch some initial data (ex. working locally, testing, etc.). It would be great if the --import flag could accept a json file to import the data.

12. Support indexes in the emulator

I wish I could use more the Firebase Emulator but it's hard to trust it when there are unsupported features such as indexes. I wish Firebase would pay more attention to this and only release new features when it's also available in the emulator.

Otherwise, the emulator doesn't give us confidence that things will be working in the same way as they will in production. I had an issue a few times where I worked on a feature and only found out it was broken after it was already merged to our staging environment where I'd get a missing index error and I'd need to open a new PR to fix it.

There's an open issue for this on GitHub, though.

13. Self-hosted / open-source

Even though I love using Firebase, it's hard to convince larger teams to use it. The main issue people argue about is because Firebase isn't open-source and it would lock us into their product.

If Firebase products were open-sourced and allow us to self-host them, it would be much easier to convince larger teams (especially in enterprise) to adopt their products. Most of the time, I don't even think we would self-host Firebase but making it open-source adds transparency to the process and it's an ensure that we could do it in case things change or Google eventually shuts Firebase down.

Additional notes

I know there are workarounds to implement some of the functionality above but the user experience isn’t great and they require a lot of work. I wish Firebase would become a backend-as-a-service that allows you to not worry about none of the things above, so you can focus on your product only.

I also know some of those features are best handled by SQL databases but, then, SQL comes with its own challenges (don't need to do SQLsplaining to me). Some of them are being resolved by products like PlanetScale and Xata, though. I think the product that manages to solve those issues will have a huge business in their hands, especially with the rise of Jamstack.

Follow me on Twitter