Forked from: corbanb/gist:76d0658493e93830af48 which borrowed heavily from http://blog.shupp.org/2012/08/12/local-timezone-lookups-by-coordinates-with-postgis/ to make this geared towards mac users, which has been updated.
$ psql -U <user> -d template_postgis
$ template_postgis=> select postgis_lib_version(); should return installed version!
$ template_postgis=> \d+tz_world
| # Step 1 | |
| def create_subscription(email, plan_id, payment_method_id) do | |
| with %User{customer_id: nil, name: name} = user <- | |
| Repo.get_by(User, email: email), | |
| {:ok, %Stripe.Customer{id: customer_id}} <- | |
| Stripe.Customer.create(%{ | |
| name: name, | |
| email: email, | |
| payment_method: payment_method_id, |
| defmodule MyApp.PubSubLib do | |
| @moduledoc """ | |
| This library implements easy to use Publish-Subscribe functionality. | |
| ## Usage | |
| Use this library with `use MyApp.PubSubLib`. | |
| ## Example | |
| defmodule MyApp.MyPublishingModule do |
If a project has to have multiple git repos (e.g. Bitbucket and Github) then it's better that they remain in sync.
Usually this would involve pushing each branch to each repo in turn, but actually Git allows pushing to multiple repos in one go.
If in doubt about what git is doing when you run these commands, just
I have this abstraction in my application code called a "CloudFile". This is where I store in the database information about
files on S3 and it gives me a resource for other resources to own. For example, a user would have an avatar_cloud_file_id.
On the front-end, I would load this relationship and display the avatar with user.avatar_cloud_file.download_url
defmodule RL.CloudFile do
use Ecto.Schema
import Ecto.Changeset
@timestamps_opts type: :utc_datetime_usec
Various search databases and backends as alternatives to Elasticsearch.
| module.exports = { | |
| parser: "@typescript-eslint/parser", // Specifies the ESLint parser | |
| extends: [ | |
| "plugin:@typescript-eslint/recommended" // Uses the recommended rules from the @typescript-eslint/eslint-plugin | |
| ], | |
| parserOptions: { | |
| ecmaVersion: 2018, // Allows for the parsing of modern ECMAScript features | |
| sourceType: "module" // Allows for the use of imports | |
| }, | |
| rules: { |
| defmodule MyApp.Repo.Migrations.AddPostgresTriggerAndFunctionForAllTables do | |
| use Ecto.Migration | |
| def up do | |
| # Create a function that broadcasts row changes | |
| execute " | |
| CREATE OR REPLACE FUNCTION broadcast_changes() | |
| RETURNS trigger AS $$ | |
| DECLARE | |
| current_row RECORD; |
When it comes to inputs, there are two types of them, "uncontrolled" and "controlled" inputs.
The inputs on the Login/Signup components were uncontrolled, that means that they owned their own state, or more specifically they own their own value.
In practical terms, an uncontrolled component is one whose value is changed exclusively by the user interacting with it.
You can still set the initial state of an uncontrolled component with defaultValue (and defaultChecked).
A controlled component is one that does not own its state, but rather its state is controlled by the component that rendered it.
I recently wanted to rename a model and its postgres table in a Phoenix app. Renaming the table was simple and documented, but the table also had constraints, sequences, and indexes that needed to be updated in order for the Ecto model to be able to rely on default naming conventions. I couldn't find any examples of what this would look like but was eventually able to figure it out. For anyone else in the same situation, hopefully this example helps.
In the example below, I'm renaming the Permission model to Membership. This model belongs to a User and an Account, so it has foreign key constraints that need to be renamed.
defmodule MyApp.Repo.Migrations.RenamePermissionsToMemberships do
use Ecto.Migration