feat!: merge new Elixir-based portfolio, replacing React version

BREAKING CHANGE: This commit replaces the entire React-based portfolio 
with the new Elixir and Phoenix based portfolio

.cursorrules

@@ -0,0 +1,87 @@
+Act as an expert senior Elixir engineer.
+- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.
+- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be throught-provoking and dig further into the original topic. 
+- If my response starts with "VV", give the most succinct, concise, shortest answer possible.
+- Important: End by saying something creepy.
+
+## Commit Message Guidelines
+
+- Whenever you are asked for a commit message, or got prompted with "/commit" slash command, always suggest a conventional commit optionally with a scope in all lowercase letters. Here are some details about the commit structure.
+
+The commit message should be structured as follows:
+
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+
+The commit contains the following structural elements, to communicate intent to the consumers of your library:
+
+- fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
+- feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
+- BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
+- types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
+- footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
+
+Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
+
+Examples
+Commit message with description and breaking change footer
+
+- feat: allow provided config object to extend other configs
+
+- BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+
+Commit message with ! to draw attention to breaking change
+
+- feat!: send an email to the customer when a product is shipped
+
+Commit message with scope and ! to draw attention to breaking change
+
+- feat(api)!: send an email to the customer when a product is shipped
+
+Commit message with both ! and BREAKING CHANGE footer
+
+- chore!: drop support for Node 6
+
+- BREAKING CHANGE: use JavaScript features not available in Node 6.
+
+Commit message with no body
+
+- docs: correct spelling of CHANGELOG
+
+Commit message with scope
+
+- feat(lang): add Polish language
+
+Commit message with multi-paragraph body and multiple footers
+
+- fix: prevent racing of requests
+
+Introduce a request id and a reference to latest request. Dismiss
+incoming responses other than from latest request.
+
+- Remove timeouts which were used to mitigate the racing issue but are
+obsolete now.
+
+Reviewed-by: Z 
+Refs: #123
+
+COMMIT MESSAGE GUIDELINES
+- Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
+- The type feat MUST be used when a commit adds a new feature to your application or library.
+- The type fix MUST be used when a commit represents a bug fix for your application.
+- A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
+- A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
+- A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
+- A commit body is free-form and MAY consist of any number of newline separated paragraphs.
+- One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
+- A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
+- A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
+- Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
+- If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
+- If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
+- Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
+- The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
+- BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.

.dockerignore

@@ -0,0 +1,9 @@
+.git/
+assets/node_modules/
+priv/static/
+
+.dockerignore
+.env*
+!.env.example
+.release-please-manifest.json
+docker-compose.override.yml

.env.example

@@ -0,0 +1,110 @@
+# Default values are optimized for production to avoid having to configure
+# much in production.
+#
+# However it should be easy to get going in development too. If you see an
+# uncommented option that means it's either mandatory to set or it's being
+# overwritten in development to make your life easier.
+
+# Enable BuildKit by default:
+#   https://docs.docker.com/develop/develop-images/build_enhancements
+export DOCKER_BUILDKIT=1
+
+# Rather than use the directory name, let's control the name of the project.
+export COMPOSE_PROJECT_NAME=portfolio
+
+# In development we want all services to start but in production you don't
+# need the asset watchers to run since assets get built into the image.
+#
+# You can even choose not to run postgres in prod if you plan to use a managed
+# cloud service. Everything "just works", even optional depends_on!
+#export COMPOSE_PROFILES=postgres,web
+export COMPOSE_PROFILES=postgres,assets,web
+
+# If you're running native Linux and your uid:gid isn't 1000:1000 you can set
+# these to match your values before you build your image. You can check what
+# your uid:gid is by running `id` from your terminal.
+#export UID=1000
+#export GID=1000
+
+# You should generate a random string of 64+ characters for this value in prod.
+# You can generate a secure secret by running: ./run secret
+export SECRET_KEY_BASE=please_generate_a_more_secure_unique_secret_value_for_your_project
+
+# Which environment is running? MIX_ENV should be "dev" or "prod" and NODE_ENV
+# should be "production" or "development". When MIX_ENV is set to prod you'll
+# automatically be set to build and run releases instead of using mix.
+#export MIX_ENV=prod
+#export NODE_ENV=production
+export MIX_ENV=dev
+export NODE_ENV=development
+
+# The URL that will be generated through out your app. When you combine all 3
+# values it should be the URL that visitors access in their browser / client.
+#export URL_SCHEME=https
+#export URL_HOST=
+#export URL_PORT=443
+export URL_SCHEME=http
+export URL_HOST=localhost
+export URL_PORT=8000
+
+# If you're using a CDN you can customize which URL gets used for your static
+# files. If left commented out it will fall back to using your URL_HOST.
+#export URL_STATIC_HOST=
+
+# The CSP configuration for the application.
+#
+# This configuration is used to set the Content-Security-Policy header for the
+# application. 
+# https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
+export CSP_SCHEME=${URL_SCHEME:-http}
+export CSP_HOST=${URL_HOST:-localhost}
+export CSP_PORT=${URL_PORT:-8000}
+
+# The bind port for cowboy (web server).
+#
+# Be warned that if you change this value you'll need to change 8000 in both
+# your Dockerfile and in a few spots in docker-compose.yml due to the nature of
+# how this value can be set (Docker Compose doesn't support nested ENV vars).
+#export PORT=8000
+
+# You'll always want to set POSTGRES_USER and POSTGRES_PASSWORD since the
+# postgres Docker image uses them for its default database user and password.
+export POSTGRES_USER=portfolio
+export POSTGRES_PASSWORD=password
+#export POSTGRES_DB=portfolio
+#export POSTGRES_HOST=postgres
+#export POSTGRES_PORT=5432
+
+# Should Docker restart your containers if they go down in unexpected ways?
+#export DOCKER_RESTART_POLICY=unless-stopped
+export DOCKER_RESTART_POLICY=no
+
+# What health check test command do you want to run? In development, having it
+# curl your web server will result in a lot of log spam, so setting it to
+# /bin/true is an easy way to make the health check do basically nothing.
+#export DOCKER_WEB_HEALTHCHECK_TEST=curl localhost:8000/up
+export DOCKER_WEB_HEALTHCHECK_TEST=/bin/true
+
+# What ip:port should be published back to the Docker host for the app server?
+# If you're using Docker Toolbox or a custom VM you can't use 127.0.0.1. This
+# is being overwritten in dev to be compatible with more dev environments.
+#
+# If you have a port conflict because something else is using 8000 then you
+# can either stop that process or change 8000 to be something else.
+#
+# Use the default in production to avoid having cowboy directly accessible to
+# the internet without assistance from a cloud based firewall.
+#export DOCKER_WEB_PORT_FORWARD=127.0.0.1:8000
+export DOCKER_WEB_PORT_FORWARD=8000
+
+# What volume path should be used? In dev we want to volume mount everything
+# so we can develop our code without rebuilding our Docker images.
+#export DOCKER_WEB_VOLUME=./priv/static:/app/priv/static
+export DOCKER_WEB_VOLUME=.:/app
+
+# What CPU and memory constraints will be added to your services? When left at
+# 0, they will happily use as much as needed.
+#export DOCKER_POSTGRES_CPUS=0
+#export DOCKER_POSTGRES_MEMORY=0
+#export DOCKER_WEB_CPUS=0
+#export DOCKER_WEB_MEMORY=0

.formatter.exs

@@ -0,0 +1,11 @@
+[
+  import_deps: [:ecto, :phoenix],
+  subdirectories: ["priv/*/migrations"],
+  plugins: [Phoenix.LiveView.HTMLFormatter],
+  inputs: [
+    "*.{heex,ex,exs}",
+    "{config,lib,test}/**/*.{heex,ex,exs}",
+    "priv/*/seeds.exs"
+  ],
+  line_length: 80
+]

.github/workflows/ci.yml

@@ -0,0 +1,29 @@
+name: "CI"
+
+on:
+  pull_request:
+    branches:
+      - "*"
+  push:
+    branches:
+      - "main"
+      - "master"
+
+jobs:
+  test:
+    runs-on: "ubuntu-22.04"
+
+    steps:
+      - uses: "actions/checkout@v2"
+
+      - name: "Install CI dependencies"
+        run: |
+          ./run ci:install-deps
+
+      - name: "Test"
+        run: |
+          # Remove volumes in CI to avoid permission errors due to UID / GID.
+          sed -i "s|.:/app|/tmp:/tmp|g" .env*
+          sed -i "s|.:/app|/tmp:/tmp|g" docker-compose.yml
+
+          ./run ci:test

.github/workflows/release-please.yml

@@ -0,0 +1,25 @@
+name: Release Please
+
+on:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: google-github-actions/release-please-action@v3
+        with:
+          release-type: elixir
+          package-name: portfolio
+          version-file: "mix.exs"
+          changelog-types: '[
+            {"type":"feat","section":"Features","hidden":false},
+            {"type":"fix","section":"Bug Fixes","hidden":false},
+            {"type":"docs","section":"Documentation","hidden":false},
+            {"type":"chore","section":"Miscellaneous","hidden":false}]'