Posts on RevoluGame

Designing a Homelab Backup Strategy I Can Actually Trust

Tue, 23 Jun 2026 10:00:00 +0100

Most homelab diagrams start with the fun parts: the NAS, the containers, the dashboards, the automations, the small machines doing useful little jobs around the house. Backup diagrams are usually less glamorous. A few arrows to a NAS, maybe one more arrow to the cloud, and the comforting feeling that important files probably exist in more than one place.

In short: I want the NAS to be the local backup hub, Synology DSM to handle snapshots and Hyper Backup jobs, USB disks to provide an offline copy, cloud storage to provide encrypted offsite history, and Prometheus plus ntfy to tell me when the system stops doing its job.

That word, “probably”, is the problem.

I do not want a backup strategy that looks reassuring in a diagram. I want one that answers boring, specific questions: what happens if I delete a folder by mistake? What happens if the NAS dies? What happens if ransomware encrypts a mounted share? What happens if storage gets corrupted despite the UPS and clean shutdown path? What happens if I have to rebuild the whole thing on different hardware?

So this is the target architecture I want my homelab backups to move toward: not just more copies, but copies that fail for different reasons, are encrypted where they leave the house, and are tested often enough that “restore” is not a theory.

The rule behind the design

The common version is the 3-2-1 rule: keep three copies, on two different types of media, with one copy offsite. For a homelab, I think the more useful target is closer to 3-2-1-1-0:

three copies of important data
two different storage types or systems
one offsite copy
one offline or immutable copy
zero untested restores

The last two matter more than they look. A cloud sync is useful, but it is not the same thing as an offline backup. If a bad script deletes a directory and that deletion syncs perfectly to the cloud, the cloud did its job and I still lost the data. Likewise, a backup I have never restored from is mostly a hope with timestamps.

The goal is not to back up everything with the same level of paranoia. The goal is to classify data by how painful it would be to lose, then give each class the right recovery path.

Layer	Job	In this setup
Local hub	Fast recovery and one place to collect backups	Synology DSM
Snapshots	Quick rollback from mistakes	DSM Snapshot Replication
Offsite	Survive local loss	Encrypted Hyper Backup to cloud
Offline	Survive compromised or damaged online copies	Rotated USB disks
Monitoring	Notice broken backup jobs	Prometheus and ntfy
Restore tests	Prove the plan works	Scheduled restores from NAS, cloud, and USB

What needs protecting

In my setup, the important things fall into a few buckets.

Irreplaceable data is the obvious one: documents, photos, personal notes, scanned paperwork, source repositories, and anything else that cannot be recreated from a package manager or a public download.

Service state is the data that makes self-hosted apps mine: Docker bind mounts, named volumes, databases, Home Assistant backups, Gitea repositories, application config, and the little bits of state that are easy to forget until a restore fails without them.

Rebuild information is everything needed to reconstruct the machines: compose files, .env files, systemd units, NUT configuration, firewall notes, package lists, and the “why is this weird thing configured this way?” documentation that future me will absolutely need.

Convenience data is useful but not precious: media files, caches, generated reports, downloads, and anything I would be annoyed to lose but not devastated by.

Those buckets should not all get the same policy. Photos deserve versioned, offsite, offline protection. A container image cache does not.

Data class	Examples	Backup policy
Irreplaceable	photos, documents, notes, source repositories	NAS, snapshots, encrypted cloud, offline USB
Service state	Home Assistant, Gitea, app data, databases	app-aware export to NAS, then cloud and USB
Rebuild information	compose files, `.env` references, NUT config, systemd units	Git where safe, NAS backup for secrets and local-only files
Convenience	media, downloads, generated reports	NAS if useful, lower retention, no drama
Ephemeral	caches, container images, build artifacts	usually not backed up

The NAS is the hub, not the backup strategy

The NAS is the center of the design because it is the easiest place for every machine to send backups. In my case that NAS is a Synology running DSM, which gives me a few useful primitives out of the box: shared folders, Time Machine support, snapshots, notifications, USB disk handling, and Hyper Backup for versioned backup jobs. Home Assistant can push scheduled backups to it. Macs can use it as a Time Machine target. Linux machines can send restic, borg, kopia, or plain snapshot artifacts to it. Docker hosts can dump databases and copy application state to it.

But the NAS is not the strategy by itself. It is just the first aggregation point.

The layout I want is explicit enough that each source has its own place:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


/backups/
 home-assistant/
 macos-time-machine/
 ubuntu/
 docker/
 databases/
 native-apps/
 sentinel/
 gitea/
 restore-tests/

That structure matters less than the habit behind it: every source should have an obvious owner, an obvious schedule, and an obvious restore procedure. If I cannot tell what created a backup or how to use it, the backup is already weaker than it looks.

On DSM, I want Snapshot Replication enabled for the important shared folders where it is available. Snapshots are not a substitute for backup, because they live on the same system, but they are excellent for fast recovery from accidental deletion, bad sync jobs, and “I changed this file yesterday and now regret it” moments.

Docker apps need app-aware backups

Backing up Docker compose files is necessary, but not sufficient. A compose file tells me how to start the container; it does not necessarily contain the application state.

For each Docker app, I want four things backed up:

the compose file
the environment file or secret reference
bind-mounted application data or named volumes
database dumps created by the database itself

That last point is where a lot of homelab backups get fragile. Copying a live database directory may work until the day it does not. For Postgres, MariaDB, SQLite-backed apps, and similar systems, the backup job should either use the application/database’s recommended export mechanism or stop/quiesce the service before taking the copy.

In practice, the pattern should be boring:

1

prepare app -> dump database -> snapshot/copy data -> send to NAS -> verify artifact

The restore procedure should be just as boring:

1

create clean app directory -> restore compose/env -> restore data -> import database -> start app

If I cannot write that procedure down for an app, I do not really have a backup of that app yet.

Home Assistant gets its own lane

Home Assistant OS already has a good backup concept, so I do not want to fight it. The ideal version is simple:

scheduled Home Assistant backups
automatic copy to the NAS
NAS backup copied onward to cloud and offline storage
occasional restore into a test VM or spare install

The last item is the important one. Home Assistant is full of integrations, devices, add-ons, secrets, and local assumptions. A backup file existing on disk is not the same thing as knowing that I can restore it and have the house come back in a sane state.

For this category, I care less about elegant tooling and more about a tested recovery note: where the backup lives, what credentials I need, what device integrations might need manual attention, and how I know the restore worked.

The small machines count too

It is easy to forget the little infrastructure boxes because they do not feel like data stores. My NUT server is a good example. If it disappeared, I could probably rebuild it from memory, but “probably” is exactly what this strategy is trying to remove.

For small utility machines, I want a lightweight backup of:

/etc files specific to the service
systemd units and timers
scripts
package list or install notes
any local state that is not disposable

For something like a NUT server, that means backing up /etc/nut/, notification scripts, and service overrides to the NAS, while also keeping the non-secret parts in Git. The backup does not need to be large. It just needs to make rebuilds boring.

Gitea is not just “on the Mac”

Time Machine is good for recovering a Mac. It is not automatically a good application-level backup for every service that happens to run on that Mac.

For Gitea, I want a dedicated backup path: repositories, database, app.ini, custom templates, LFS data if used, and the pieces that make Git-over-SSH work. In my case SSH is enabled through Gitea’s built-in SSH server, so the restore procedure needs to account for Gitea’s SSH host keys, the configured SSH port, and the user/container mapping that lets Git operations reach the right repositories. Gitea has its own dump command, and that should be part of the plan rather than relying only on a filesystem-level Mac backup.

The reason is simple: restoring the web UI is not the same thing as restoring the developer workflow. If the repositories and database come back but every remote now fails on git push, the backup is incomplete.

The nice property of an app-native Gitea backup is that it can be restored somewhere else. That is the bar I care about. If the Mac dies, I should be able to bring Gitea up on another machine without first resurrecting the Mac exactly as it was.

Cloud backup should be encrypted and versioned

The cloud copy should not be a raw mirror of the NAS. It should be an encrypted, versioned backup repository.

The exact tool matters less than the properties:

client-side encryption before data leaves home
versioned snapshots
retention policy
integrity checks
credentials with the smallest practical permissions
restore procedure documented outside the backup itself

restic, borg, kopia, and similar tools all fit this model better than a blind sync. Since the NAS is Synology DSM, Hyper Backup is also a natural option here: it can send versioned, encrypted backups to cloud providers, rsync destinations, another Synology, or local USB storage. The important part is not the brand of tool, but that the cloud target is a backup repository with history, not just a synchronized copy of today’s mistakes.

The cloud provider is allowed to disappear from the recovery path for local failures, and the local NAS is allowed to disappear from the recovery path for cloud restores. If both are required at the same time, the design has a hidden coupling.

USB disks are for offline recovery

The USB disk is not there because I enjoy plugging in drives. It is there because offline storage survives a different class of failures.

On DSM, this is a good fit for a Hyper Backup task targeting an external USB disk. An ideal USB backup flow looks like this:

1

plug in disk -> run backup -> verify -> unmount -> physically disconnect

Even better, rotate two disks: one at home, one somewhere else. That is less convenient than a permanently attached drive, but convenience is not the job of this copy. Its job is to be unreachable when a compromised machine, broken script, or accidental deletion tries to destroy everything it can see.

This is the copy I want if the NAS and cloud repository are both logically damaged. Not because that is likely, but because that is the kind of failure that makes every online copy suspect at the same time.

A second NAS is useful if it changes the failure mode

An offsite NAS would be a good future upgrade, but only if it is not just another always-mounted destination with a different hostname.

The best version is pull-based: the offsite NAS connects in, pulls encrypted backup artifacts, and stores them with its own retention. That way, if the primary NAS is compromised, it cannot trivially reach out and delete the offsite copy with the same credentials it uses for normal backups.

If that is too much complexity, cloud plus rotated USB disks may be a better tradeoff. The point is not to collect backup destinations. The point is to avoid shared failure modes.

Monitoring is part of the backup system

A backup job that fails silently for three months is not a backup job. It is a delayed surprise.

Every recurring backup should report somewhere when it succeeds and when it fails. In my homelab, that means Prometheus for machine-readable state and history, and ntfy for the human-facing “you need to look at this” notification. The tooling is less important than the invariant: if a backup stops running, I should find out before I need it.

DSM’s own notifications should be part of this too. If a Hyper Backup task fails, a USB disk is not mounted, a volume degrades, or a snapshot job stops running, that should end up in the same alerting path as the rest of the homelab health checks.

The signal I want from each job is small:

last successful run
duration
size or number of changed files
destination
verification status
retention/prune result

Those fields are enough to spot most weirdness: a job that stopped running, a backup that suddenly became tiny, a cloud upload that never finished, or a prune operation that failed and left the repository growing forever.

Restore tests make it real

This is the part I most want to make non-optional.

I want a small restore calendar:

monthly: restore a random document or photo from NAS and cloud
quarterly: restore a Docker app into a temporary directory or VM
quarterly: restore a Home Assistant backup into a test instance
yearly: simulate losing the NAS and recover the most important data from cloud or USB

The test does not have to be dramatic. It just has to be real. A restored file should open. A restored database should start. A restored Home Assistant instance should boot far enough to prove the backup is usable.

The restore notes should live somewhere I can reach during an outage. A recovery plan stored only on the NAS it is meant to recover is a joke with excellent formatting.

The target architecture

The architecture I want to end up with looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


Mac
 -> Time Machine -> NAS
 -> Gitea app backup -> NAS

Ubuntu
 -> compose/config backup -> NAS
 -> app data + database dumps -> NAS

Home Assistant OS
 -> scheduled backups -> NAS

Sentinel / NUT server
 -> config + scripts -> NAS

NAS
 -> DSM Snapshot Replication for important shares
 -> Hyper Backup encrypted cloud backup
 -> Hyper Backup rotated offline USB backup
 -> optional offsite NAS pull backup

Monitoring
 <- every backup job reports status

Restore tests
 <- periodically restore from NAS, cloud, and USB

It is not the most exotic setup. That is a feature. The best backup strategy for a homelab is one I will actually maintain when nothing is on fire.

My checklist before calling this done

Before I consider this strategy real, I want to be able to check off the following:

every important service has a documented restore procedure
every database has an app-aware dump or quiesced backup
Home Assistant backups are copied beyond the Home Assistant machine
Gitea has an app-native backup, not just Time Machine coverage
small utility machines have their service configs backed up
DSM snapshots are enabled for important shared folders
Hyper Backup cloud jobs are encrypted, versioned, and periodically verified
at least one Hyper Backup USB target exists and is disconnected after backup
backup jobs report success and failure somewhere visible
restore tests happen on a schedule
recovery notes are available without depending on the NAS

The real lesson is that “where do I copy this?” is the wrong first question. The better question is: “which failure is this copy supposed to survive?”

Once each backup has a job, the architecture becomes easier to reason about. The NAS is for fast local recovery. The cloud is for offsite encrypted history. The USB disk is for offline survival. App-native exports are for portable restores. Monitoring is for noticing when the whole system quietly stops doing its job.

And restore tests are what turn the drawing from a comforting picture into a system I can actually trust.

How I Use Obsidian for Work, Personal Life, and AI

Mon, 22 Jun 2026 00:00:00 +0200

Over the years, I’ve tried countless productivity tools, note-taking systems, and documentation platforms.

In short: I use Obsidian as the central place where notes, project documentation, meeting summaries, infrastructure knowledge, and AI-ready context come together. The goal is not just to store information, but to make it reusable by both me and the AI assistants I work with.

Most of them failed for the same reason: information ended up scattered across multiple locations.

Meeting notes lived in one tool. Documentation lived somewhere else. Tasks were tracked separately. Project knowledge slowly disappeared into chat conversations and ticket systems. I would often remember that a useful decision had been made, but not whether it was buried in Slack, a meeting doc, a ticket comment, or a notebook page.

Today, almost everything I write, document, plan, or archive ends up in Obsidian.

Obsidian has become the central hub for both my professional and personal life. It stores my notes, project documentation, infrastructure knowledge, diagrams, meeting summaries, and increasingly serves as the foundation for my AI workflows.

That last part is what makes it more than a personal knowledge base. It is not just where I keep information. It is where I build usable context for both myself and the tools I rely on.

Obsidian is not just where I store notes. It is where scattered information turns into usable context.

My Vault Structure

I keep things intentionally simple by following a structure inspired by the PARA methodology:

Inbox
Projects
Areas
Resources
Archive

This structure has remained largely unchanged for years because it scales well without becoming complicated.

What I like about PARA in practice is that it gives me enough structure to find things later without forcing me to over-design the system upfront.

Inbox

The Inbox is where everything starts.

Ideas, meeting notes, technical thoughts, project requests, architecture discussions, blog post ideas, and random observations all land here first.

I don’t spend time deciding where information belongs during capture.

The objective is simple: capture first, organize later.

Projects

Projects contain anything with a defined goal and an end date.

Examples include:

New product features
Infrastructure migrations
Customer implementations
Internal tooling
Blog articles
Side projects

Each project contains all relevant information:

Meeting notes
Documentation
Research
Architecture diagrams
Decisions
Action items

The goal is to keep everything related to a project in a single place.

Areas

Areas represent ongoing responsibilities.

Unlike projects, they never truly end.

For work, these include:

Infrastructure
Security
Monitoring
Development practices

For personal life:

Finance
Health
Learning
Home

Most long-term operational knowledge eventually ends up here.

Resources

Resources are reference materials I may need in the future.

Examples include:

Technical documentation
Research notes
Configuration examples
Learning material
AI experiments
Troubleshooting guides

Whenever I solve a problem that I know I’ll encounter again someday, I document it here.

How Information Enters Obsidian

Obsidian is my source of truth, but it isn’t always where information originates.

A large portion of my notes start on my Supernote.

During meetings, brainstorming sessions, architecture discussions, or debugging sessions, I prefer writing by hand.

The process is straightforward:

Take notes on the Supernote
Export the document
Run OCR
Import into Obsidian

1

Capture -> OCR -> Obsidian -> organize -> reuse

This gives me the benefits of handwriting while still keeping everything searchable and connected.

I’ve found that writing by hand helps me think more clearly, while Obsidian excels at organizing and maintaining information over time.

Daily Notes and Tasks

My Daily Note acts as the operational dashboard for the day.

It contains:

Tasks
Meeting summaries
Follow-ups
Personal reminders
Work items

I rely heavily on the Tasks plugin to manage action items across projects and areas.

Instead of manually maintaining task lists, tasks are collected from the notes where the work actually happens.

This keeps context attached to the task itself.

When I revisit a task weeks later, I can immediately see the meeting, project, or discussion that generated it.

Excalidraw for Architecture and Thinking

Not all knowledge is textual.

For architecture discussions, infrastructure planning, system design, and brainstorming, I use the Excalidraw plugin directly inside Obsidian.

Almost every significant technical project generates diagrams:

Infrastructure layouts
Application architecture
Data flows
Deployment pipelines
System interactions

Keeping diagrams alongside documentation is incredibly valuable.

Months later, I can revisit a project and immediately recover both the visual and written reasoning behind a decision.

Excalidraw has effectively become my digital whiteboard.

Where AI Fits Into the Workflow

AI has become an important part of my workflow, but not in the way many people expect.

I don’t use AI as a replacement for documentation.

I use it to help process, organize, and leverage documentation.

Processing Meeting Notes

One of the biggest time sinks after meetings is turning conversations into actionable information.

To solve this, I built a workflow around Gemini, Claude, and Obsidian.

After a meeting:

Gemini generates a transcript.
The transcript is processed by Claude using Claude Cowork.
Claude produces:
- A concise summary
- Key decisions
- Open questions
- Action items
Action items are formatted for the Obsidian Tasks plugin.
The tasks are inserted directly into my Daily Note.
I review and approve the result.
The meeting note is stored in the appropriate project or area.

The important part is the review step.

AI speeds up the transformation from conversation to structured knowledge, but I still validate the output before it becomes part of the system.

AI accelerates the process, but I remain responsible for validating the output.

The result is that meetings become structured knowledge instead of forgotten conversations.

Building an AI-Ready Knowledge Base

One lesson I’ve learned is that AI is only as good as the context it receives.

For this reason, I maintain a separate Obsidian vault specifically designed for AI consumption.

This vault contains:

Infrastructure documentation
Project documentation
Runbooks
Deployment procedures
Architecture decisions
Operational knowledge

The documentation is actively maintained because it serves two audiences:

Humans
AI assistants

When Claude needs to help troubleshoot an issue, understand a project, or generate documentation, it already has access to the context it needs.

Instead of repeatedly explaining how systems work, I can point the AI at the relevant documentation.

The quality of the answers improves dramatically.

AI as a Team Member

The best way I can describe this setup is that AI starts behaving less like a search engine and more like a knowledgeable team member.

It understands:

Current projects
Infrastructure architecture
Existing procedures
Historical decisions

Not because the model is smarter, but because the documentation exists.

A good example is troubleshooting. If I ask Claude to help investigate a deployment issue in a project that already has architecture notes, runbooks, and past decisions documented in the vault, the conversation starts much further along. Instead of spending time reconstructing the system from memory, I can focus on the actual problem.

The value doesn’t come from AI alone.

It comes from combining AI with a well-maintained knowledge base.

One System, Many Uses

Obsidian has become much more than a note-taking application for me.

It’s where projects begin, documentation evolves, knowledge accumulates, and AI gains the context needed to be genuinely useful.

The core workflow remains surprisingly simple:

Capture information.
Organize it.
Document continuously.
Maintain context.
Let AI help process and leverage that knowledge.

Everything else is just tooling.

The real value comes from building a system where information is captured once, maintained properly, and remains accessible for both humans and machines.

That is why Obsidian has become so central to both my work and personal life. It is not merely a note-taking app. It is the layer where scattered information becomes durable knowledge, and where that knowledge becomes useful not just to me, but to the AI systems that help me work with it.

How the Supernote Became the Starting Point for Almost Everything I Write

Sun, 21 Jun 2026 00:00:00 +0200

In a recent meeting, I noticed something familiar happen again.

While everyone else stayed inside docs, tickets, and browser tabs, I was filling page after page on my Supernote: arrows between ideas, underlined decisions, a rough architecture sketch in the margin, and a few questions to come back to later. By the end of the conversation, I did not have polished notes. I had something more useful: a map of how I understood the problem.

That pattern shows up everywhere in my work.

I do not use the Supernote as my primary note repository. Every note eventually ends up in Obsidian. The Supernote serves a different purpose: it is where ideas begin.

Almost everything I write starts there.

The Supernote is not where my notes live. It is where my ideas become clear.

The Supernote Is My Thinking Device

When people talk about digital note-taking devices, they often focus on organization.

For me, organization happens later.

The Supernote is where I dump ideas, explore solutions, sketch architectures, and work through problems. It is where I write things that do not yet have a clear structure.

Sometimes it is meeting notes. Sometimes it is a rough outline for a blog post. Sometimes it is pages of random thoughts while trying to understand why a system behaves in a certain way.

The common thread is that I am using handwriting to think.

There is something about writing by hand that slows my brain down just enough to make connections I would otherwise miss.

Meetings Start Here

Most of my meeting notes are taken on the Supernote.

I do not try to create perfect documentation during meetings. Instead, I focus on capturing information quickly:

Decisions
Action items
Questions
Technical details
Follow-up topics

The goal is not to produce a polished document. The goal is to stay engaged in the conversation while preserving the important information.

After the meeting, the notes become part of a larger workflow.

A typical page starts messy: fragments, arrows, quick diagrams, and just enough structure to make the next step obvious.

From Supernote to Obsidian

Every note eventually finds its way into Obsidian.

My process is fairly simple:

Write notes on the Supernote.
Export them as PDF.
Run OCR locally using Ollama.
Import the resulting text into Obsidian.
Organize and connect the information with the rest of my knowledge base.

1

Supernote -> PDF export -> local OCR -> Obsidian -> linked notes

That OCR step matters more than it might sound.

It is not perfect, especially when my handwriting gets messy or a page is full of diagrams and fragments. But it is good enough to turn rough handwritten thinking into searchable text without sending private notes to a cloud service. Once the text is in Obsidian, I can clean it up, link it to related notes, and decide what is worth keeping.

This gives me the best of both worlds.

I get the flexibility and freedom of handwriting during the thinking phase, while still benefiting from searchability, linking, and long-term knowledge management inside Obsidian.

The Supernote captures ideas.

Obsidian preserves them.

Debugging on Paper

One of the most valuable uses of the Supernote has been debugging.

Whenever I encounter a difficult problem, I often stop looking at the screen and start writing.

I draw system diagrams. I map data flows. I write assumptions. I list hypotheses. I document failed attempts.

Many times, the act of writing reveals gaps in my understanding that were not obvious while staring at logs or source code.

The Supernote has effectively replaced the whiteboards and notebooks I used in the past.

Gathering Thoughts Before Writing

Most of my articles start as handwritten notes.

Not because handwriting is faster. It is definitely slower.

But that is exactly why it works.

Writing by hand forces me to think about what I am trying to say before I say it.

Instead of immediately producing paragraphs, I build a structure:

Main idea
Supporting points
Examples
Counterarguments
Conclusions

By the time I open my editor, most of the hard part has already happened.

The writing is no longer about discovering what I think. It is about shaping it.

Organized Chaos

If someone opened my Supernote, they would probably be confused.

Many pages contain incomplete sentences, arrows pointing in every direction, diagrams, random observations, and fragments of ideas.

That is intentional.

The Supernote is not where I create finished work.

It is where I create clarity.

The messy notes eventually become technical documentation, blog posts, project plans, or meeting summaries. Before they become structured documents, they are simply thoughts on a page.

Two Tools, Two Jobs

I have realized that my workflow has two distinct phases:

The first phase is thinking.

The second phase is storing and organizing knowledge.

The Supernote excels at the first.

Obsidian excels at the second.

Trying to force one tool to do both has never worked particularly well for me.

By separating the thinking process from the knowledge management process, I have ended up with a workflow that feels natural and sustainable.

Almost everything I write starts with the Supernote.

Not because that is where the final version lives.

When I need a durable system, I use Obsidian. When I need to understand something, prepare to write, or find my way through a messy problem, I reach for the Supernote first.

That is probably the real lesson for me: the best tool is not always the one that stores everything. Sometimes it is the one that helps ideas take shape before they are ready to be stored anywhere at all.

My homelab stack in 2026: what runs, why, and how it all connects

Sat, 20 Jun 2026 10:00:00 +0100

I’m not going to make the case for self-hosting here. If you’re reading this, you already get it. What I want to do instead is be honest about what I actually run, why I made the specific choices I made, and - more interestingly - how the pieces talk to each other in ways that weren’t always planned from the start.

In short: my 2026 homelab runs on a mix of Raspberry Pis, a Mac Mini, and an Ubuntu mini PC. Traefik handles routing, Tailscale provides remote access, Prometheus watches the stack, Ntfy connects notifications, and local AI runs through Ollama and OpenWebUI.

The stack runs across four machines. The bulk of Docker workloads are split between a Mac Mini and an Ubuntu mini PC. Network infrastructure - Traefik and CoreDNS - runs on a Raspberry Pi 4, which also handles the NUT server for UPS management; keeping the network layer on its own always-on hardware means a container crash elsewhere doesn’t take down routing or DNS. Home Assistant runs on a Raspberry Pi 5 with the Hailo 8 AI HAT. Frigate runs alongside it as a Home Assistant add-on, which is what gives it direct access to the Hailo 8 for hardware-accelerated camera object detection - no GPU needed in the main machines for that workload.

The mental model that makes sense of the whole thing: everything gets served through Traefik, everything ships metrics to Prometheus, and Ntfy acts as the notification bus that ties async events together. Most of the rest are applications that plug into those three rails.

Category	Tools
Network	Tailscale, Traefik, CoreDNS
Dev & CI/CD	Gitea, GitHub, Woodpecker CI, Docker Registry, WUD
AI	Ollama, OpenWebUI
Search	SearXNG
Documents	Paperless-NGX, Paperless-AI
Passwords	Vaultwarden
Monitoring & management	Prometheus, Portainer, Homer
Notifications & sharing	Ntfy, Pairdrop
Home automation	Home Assistant, Frigate

graph TD
 subgraph pi4["Pi 4 — Network layer"]
 TS[Tailscale]
 TR[Traefik]
 DNS[CoreDNS]
 end

 subgraph main["Mac Mini + Ubuntu — Services"]
 GIT[Gitea]
 WP[Woodpecker CI]
 REG[Docker Registry]
 WUD[WUD]
 OLLAMA[Ollama]
 OWU[OpenWebUI]
 SEARX[SearXNG]
 PAI[Paperless-AI]
 PAPER[Paperless-NGX]
 NTFY[Ntfy]
 end

 subgraph pi5["Pi 5 — Home automation"]
 HA[Home Assistant]
 FRIGATE[Frigate]
 end

 TS --> TR
 GIT --> WP --> REG
 WUD -->|alert| NTFY
 OLLAMA --> OWU
 OLLAMA --> PAI --> PAPER
 OWU -->|search| SEARX
 FRIGATE --> HA
 HA -->|notify| NTFY

The foundation

Traefik

Everything HTTP goes through Traefik. It’s the reverse proxy in front of every Docker-hosted service, and the main reason I chose it over Nginx or Caddy is Docker-native autodiscovery. When I bring up a new container with the right labels, it appears behind a subdomain with automatic TLS, no config file reload required. That removes enough friction that I’m less tempted to leave things running unproxied on bare ports.

Traefik handles Let’s Encrypt certificate issuance and renewal. Services that aren’t on the public internet use a DNS-01 challenge, so they get valid certs without being exposed to the web. The rest of the stack is effectively Traefik labels plus container configs all the way down.

Tailscale

Tailscale is how every machine in the stack is reachable from outside the local network. All four machines are on the same Tailnet, which means I can reach any service from anywhere without opening ports or maintaining a VPN server.

📝 Note

Tailscale isn’t fully self-hosted — the coordination server is Tailscale’s. The traffic itself is peer-to-peer and never leaves the devices, but the key exchange goes through their infrastructure. For a homelab, that trade-off is easy to accept; for stricter control, Headscale is the self-hosted alternative.

CoreDNS

CoreDNS handles local name resolution. All internal subdomains resolve to the local machine without ever leaving the network, which means Traefik’s label-based routing is actually usable on every device without editing hosts files or relying on split-horizon DNS from the router. CoreDNS sits upstream of the system resolver and forwards anything it doesn’t own to the public DNS of choice. It’s invisible when it works, which is most of the time.

Dev & CI/CD: the pipeline

This is where the most deliberate architecture lives, because I wanted something that felt like a real deployment pipeline rather than manually building and copying images around.

Gitea

Gitea is where all private repositories live: infra configs, personal projects, anything I don’t want on a third-party server. Public projects still go to GitHub because that’s where the audience is, but a number of those GitHub repositories are mirrored back to Gitea as a local backup. The split is simple: Gitea for control and resilience, GitHub for reach.

Woodpecker CI

Woodpecker CI is the pipeline runner, hooked directly into Gitea webhooks. Push to a branch, a pipeline runs. The config lives as a .woodpecker.yml at the repo root, which means pipeline definitions are versioned alongside the code. Woodpecker builds Docker images and pushes them to a local registry on the same host.

Local Docker registry

A plain Docker registry container, served behind Traefik. Woodpecker pushes here; docker compose pulls from here. Keeping images local means builds are fast, no rate limits, and nothing depends on an external registry being up. Not sophisticated. Exactly as much complexity as needed.

WUD - What’s Up Docker

WUD watches running containers and detects when upstream image versions are newer than what’s deployed. It doesn’t auto-update by itself in my setup, I use it as a detection layer. When it spots a new version, it fires a notification through Ntfy, which I’ll get to shortly. The result is that upstream updates surface as notifications I can act on rather than surprises I discover when something breaks.

Local AI: Ollama + OpenWebUI

I run Ollama for local model inference. The main draws are the obvious ones: no data leaves the machine, no per-token cost, models available offline. Local models cover summarization, document classification, and general Q&A; tasks where a smaller model is good enough and keeping data local matters.

Code assistance is the clear exception: small models aren’t reliable enough there, so that goes to cloud APIs - Claude or Codex depending on the task. OpenWebUI makes the split seamless: it sits in front of Ollama but also accepts API keys for cloud providers. In practice I open one interface and pick a model from a dropdown rather than switching tools. Local by default, cloud when it’s actually worth it.

OpenWebUI also connects to SearXNG as a search tool, which means it can pull current information without phoning home to a commercial search provider.

Search: SearXNG

SearXNG is my default search engine on all devices. It’s a meta-search engine. It queries multiple sources and aggregates results. But the key property is that queries don’t get tied to an account or used to build a profile. Results are good enough for 95% of searches, and for the other 5% I have a single click to fall back to whatever source I want.

The setup is minimal: one container behind Traefik, set as the default search engine in the browser. It’s one of those things that took twenty minutes to deploy and I’ve never thought about since.

Documents: Paperless-NGX + Paperless-AI

Paperless-NGX handles all document management. Scan or drop a PDF into the inbox, it gets OCR’d, indexed, and stored. The tagging and correspondent system means I can find anything in seconds rather than digging through a folder hierarchy.

On top of that I run Paperless-AI, which hooks into the Paperless-NGX API and uses a local Ollama model to automatically suggest tags, correspondents, titles (and various other custom properties) as documents come in. This closes a loop with the AI section: Ollama isn’t just a chat model, it’s doing practical classification work for real files. The whole thing runs locally, so no document content touches an external service.

Password management: Vaultwarden

Vaultwarden is a self-hosted Bitwarden-compatible server. All credentials live locally, sync across devices through the standard Bitwarden clients, and never touch a third-party server. It’s one of those services where the self-hosted case is unusually strong: the upstream Bitwarden clients are excellent, Vaultwarden is a drop-in replacement, and keeping your password vault on your own hardware removes a meaningful point of trust.

💡 Tip

A password vault is the one thing you cannot lose and cannot recover from a partial backup. I wrote a dedicated post about the backup architecture covering how I handle this specifically for Vaultwarden.

Monitoring & management

Prometheus

Prometheus scrapes metrics from the stack. Node exporter covers the host, cAdvisor covers containers, and individual services expose their own endpoints where supported. The main value isn’t dashboards (though those exist) - it’s having a queryable record of system state over time, and a place to hook alerts when something drifts.

Portainer

Portainer is the visual management layer. I use it for quick container inspection, pulling logs, and managing stacks without SSHing in every time. It doesn’t replace Prometheus, they have different jobs. Prometheus tells me what happened and when; Portainer tells me what’s running right now and lets me poke at it.

Homer

Homer is a static dashboard - a single page with links to every service, configured via a YAML file. It’s the least technical piece in the stack and the one my family actually uses. Rather than memorizing subdomains or digging through bookmarks, everyone has Homer as a home page: a clean grid of icons that opens whatever they need. The split between Portainer and Homer is intentional - Portainer is for me, Homer is for everyone else.

Ntfy

Ntfy is the thread that ties the whole async event model together. It’s a self-hosted push notification server. HTTP POST to a topic, and every subscribed client gets a notification. Woodpecker sends build results here. WUD sends image update alerts here. Home Assistant sends automation notifications here. Having one place where things send notifications means I can manage subscriptions in one app and stop checking dashboards compulsively.

The pattern is simple enough that anything can use it: if a script or service needs to tell me something happened, it makes an HTTP request. No SDK, no auth complexity, just a POST.

Pairdrop

Pairdrop is AirDrop for the local network, any device on the LAN can discover others and transfer files peer-to-peer through the browser. No account, no cloud relay, no app install. I use it constantly for moving files between phone, laptop, and desktop without thinking about it.

Home automation: Home Assistant

Home Assistant is the one thing in the stack that runs on bare OS rather than Docker. It’s Home Assistant OS on a dedicated Raspberry Pi 5, which is a deliberate choice: the add-on ecosystem, hardware device support, and the supervisor layer all work better outside a container. Trying to run it in Docker introduced enough friction with USB devices and networking that the clean answer was to give it its own machine.

Frigate runs as a Home Assistant add-on rather than a standalone container, and that placement matters: it gives Frigate direct access to the Hailo 8 AI HAT on the Pi 5 for hardware-accelerated object detection on camera streams. Running it as an add-on keeps the integration tight and avoids the networking gymnastics that come with trying to expose a hardware accelerator across container boundaries.

It integrates back into the rest of the stack through Ntfy, automations that need to notify me fire an HTTP call to the same notification server everything else uses. One less thing to configure separately.

What’s next

One thing I’m actively removing is n8n. On paper it’s a great fit — nice UI, trivial to set up, an enormous library of nodes. In practice, for the automations I actually run, it’s massively oversized. A tool that big has a way of becoming its own maintenance surface, and when I look at what I’m using it for, most of it is simple enough to replace with a script and an HTTP call to Ntfy. Sometimes the right answer is less, not more.

The stack has been stable enough that I’ve been iterating on individual services rather than adding new ones. The pieces that took the most time to get right were the CI/CD pipeline (getting Woodpecker, the local registry, and WUD to work as a coherent unit) and Paperless-AI (tuning the prompts so document classification is actually useful rather than just technically running).

If any of this is useful as a starting point, most of these services have reasonable official documentation and active communities. The architecture isn’t novel, it’s mostly standard self-hosting patterns assembled with some thought about how the parts should talk to each other.

Designing Single-Purpose Agents Instead of One Big Automation Script

Wed, 17 Jun 2026 10:00:00 +0100

“Agent” has become one of those words that means everything and nothing this year. Before it was a hype term, I’d already ended up with a small flock of them in my homelab. Not because I was chasing a trend, but because I kept hitting the same wall every time I tried to write One Big Script: it grew a dozen unrelated responsibilities, and a bug in one of them risked taking down all of them.

In short: I prefer many small, single-purpose automation agents over one large script because each agent has a narrow job, a clear output contract, and an independent schedule. The system stays maintainable because agents communicate through JSON artifacts, one notification channel, and one dashboard.

So instead, every recurring chore in my homelab is its own small, independently-scheduled program. There turned out to be more of them than I expected once I actually sat down and counted.

A note for muggles: the repo behind all this is named hogwarts, and every agent gets sorted to match. Once you start naming services after wizards, it turns out you owe each one an in-character job description, whether it asked for one or not.

The standing watch. Four observers poll continuously and report into one correlator every five minutes. This is the layer that exists so I find out about a problem before it becomes a 3am page instead of after:

Argus Filch watches running Docker containers for restart loops, failed healthchecks, and containers that just quietly vanish.
Astronomy Tower polls Prometheus for firing alerts, down scrape targets, and recording rules that stopped working without telling anyone.
Marauder’s Map scans the UniFi network for offline devices, WAN failover events, and firewall rules that drifted open.
Mad-Eye’s Watch tracks TLS certificate expiry across configured endpoints. Constant vigilance: a warning at 30 days, a critical at 7.
The Headmaster is the one role on this list that isn’t single-purpose by design. Its entire job is reading what the other four decided was worth reporting and correlating that into one status, surfaced as an incident only when it’s actually worth one.

The daily and weekly chores. These run on their own cron schedules and never talk to each other directly:

Molly’s Cupboard reviews the Home Assistant entity list weekly: unavailable entities, missing or duplicate names, disabled automations. (Molly Weasley: keeps the household running, judges your clutter lovingly.)
Rita’s Desk is the RSS morning digest: feeds in, previous day’s articles out, ranked against persistent tag scores I vote on. Deterministic by design, no LLM in the loop. (Never met a headline she wouldn’t print, but at least she always sources it.)
Kreacher’s Kitchen plans the week’s meals from my recipe library and a couple of trusted cooking sites. (Grumbles the entire time, still gets dinner on the table.)
The Library picks a tech topic every night, gathers sources, and writes a 5-minute digest plus a 15-20 minute deep dive. (Lives in the package manifest as research-digest, but it spends every night in the Restricted Section, so the Library it is.)
Madam Pince’s Catalogue lists every running container and cross-checks it against the service directories in the infra repo, flagging any container that has no matching documentation. (A very particular librarian: every book gets catalogued, or it gets confiscated.)
Dobby’s Rounds is the homelab’s free elf: weekly housekeeping that prunes old snapshots, reports, and state files before they pile up.
O.W.L.s is the daily infrastructure audit: config drift, open ports, compliance. Read-only and deliberately paranoid about it. (Ordinary Wizarding Level exams: thorough, exhausting, and not interested in your excuses.)
Auror Office is the daily cross-domain security digest, correlating O.W.L.s’ findings with auth logs, Docker posture, and the network observers above into one report. (No badge, but it does go looking for dark wizards. I’ve written about how this one and O.W.L.s work together in more detail elsewhere.)
…and others, including media management, recommendations, and a handful more in the same spirit. Small enough that listing every one of them would be its own blog post.

Thirteen-plus names, just as many jobs. Outside of the two correlators built specifically to know about everyone else — the Headmaster and the Auror Office — not one of them needs to care that the rest exist.

The three conventions that make this work

None of these agents are individually clever. What makes the flock manageable is that they all obey the same three small contracts:

1. One artifact format. Every agent writes its result as JSON (and often a companion Markdown note) to its own outbox/latest/ path. A “latest” pointer plus a timestamped archive, every time. No agent reads another agent’s outbox directly. If something needs cross-referencing, that’s a different, explicitly-correlating agent’s job, not an implicit dependency.

2. One notification channel. Every agent that needs to tell me something pushes through the same ntfy topic convention, with a deep link back into wherever the full detail lives. I don’t maintain five different alerting integrations; I maintain one, and every agent is a thin client of it.

3. One aggregation point. A single dashboard reads everyone’s outbox/latest/ and renders it. It doesn’t collect anything itself. It has no Docker access, no Home Assistant credentials, no API keys. It’s a pure read layer over JSON files other things produced. That’s the only place in the whole system that’s allowed to know all the agents exist.

That’s the entire integration surface. Three conventions, and I can add a sixth agent tomorrow without touching the other five.

Why decompose instead of consolidate

The obvious objection: isn’t five small things more to maintain than one big thing? In my experience, no. For the same reason a set of small services usually beats a monolith at work.

A bug in Peeves’ Trakt pagination cannot break Molly’s Home Assistant checks, because they don’t share a process, a deploy, or a schedule. I can test each one in complete isolation with a fixture file instead of live credentials. I can hand any single agent’s directory to a contributor - human or an AI coding agent - and they have everything they need to understand and change it, without first having to load the other four into their head. And when I retire one (Peeves only matters because I still have a media server; that won’t be true forever), deleting it is deleting a directory, not untangling a shared module.

This is the same lesson as service boundaries and team topologies at any reasonably-sized engineering org: the interface between components should be small, explicit, and boring, and almost all of the design effort should go into keeping it that way. Not into making any individual component clever. The cleverness, if there is any, belongs inside one agent’s narrow walls, where it can’t leak.

The boring plumbing is the point

None of the five agents above is doing anything technically hard. RSS parsing, a REST API client, a cron job - this is all stuff any of us could write in an afternoon. The actual design work was deciding, up front, that “outbox JSON + one notification channel + one dashboard” would be the entire contract between them, and then refusing to let any agent reach around it.

That discipline is cheap when you only have one agent. It’s the only thing that keeps five (or fifteen) from turning back into the One Big Script I was trying to avoid in the first place.

Backing Up the One Credential That Can't Be Wrong

Mon, 15 Jun 2026 10:00:00 +0100

Most things in my homelab can fail and I shrug. A container restarts, a dashboard is stale for an hour, a media file gets deleted by mistake: annoying, recoverable, fine. The password vault is not in that category. If it’s wrong, or gone, or merely unreachable at the wrong moment, I lose access to everything else at once. It’s the one piece of infrastructure that earns the extra paranoia.

In short: my password vault backup strategy keeps three copies that survive different failure modes: the primary vault, a live self-hosted Vaultwarden mirror, and an offline KeePass archive. The important part is not the number of backups, but making sure they do not all fail for the same reason.

So instead of “back it up somewhere,” I sat down and asked the question I’d ask at work for any single point of failure: which specific failure does each copy need to survive? That question is what actually shaped the design. Not “more backups.”

Three copies, three different failure modes

The vault lives day-to-day in Dashlane. Around it, a script keeps two more copies current:

A dated, offline KeePass .kdbx archive. The script exports the vault, converts it to KeePass format, and syncs the file to NAS over rsync. This file needs nothing else to be true. No Dashlane account, no Vaultwarden instance, no network to be opened. KeePassXC plus a master passphrase is the entire recovery path.
A live Vaultwarden mirror. The script wipes and re-imports a self-hosted Vaultwarden instance on every run, so it never drifts and never accumulates stale duplicates. Unlike the .kdbx, this one behaves like a normal vault app day-to-day. Useful if Dashlane itself is the thing that’s unavailable.
The original, in Dashlane. Still the primary, still the one I actually use day to day.

Each of these answers a different question. If Dashlane has an outage or I get locked out of the account, Vaultwarden keeps working normally. If my entire home network and every service on it is down, or I’m on a borrowed machine with nothing installed, the .kdbx file plus a passphrase I’ve memorized is the whole recovery procedure. No SSH keys, no app, no account, no network. If the NAS itself dies, the live Vaultwarden mirror (running elsewhere) and Dashlane are both still fine.

That’s the test I’d apply to any redundancy claim: two backups that die from the same root cause aren’t two backups, they’re one backup with extra steps. These three don’t share a single point of failure with each other.

The part that matters more than the architecture

Diagrams of “three copies in three places” are easy to draw and easy to get wrong in the implementation details, and the details are where a vault backup script can quietly turn into a liability instead of a safety net.

The script exports the raw vault to CSV in plaintext before converting it. There’s no way around that, the conversion tool needs plaintext input. So the entire design constraint became: that plaintext must never outlive the script’s own execution. It’s written to a private temp directory, and a shell trap deletes it on every exit path. Success, failure, or interruption, not just the happy path. The master passphrase that protects the .kdbx is treated as its own tier-zero secret: it lives outside the repo, outside the backup, memorized or written down somewhere physically safe, because it’s the one credential that unlocks the credential store.

It’s a small thing, a trap ... EXIT instead of cleanup code only at the bottom of the script. But it’s exactly the kind of detail that’s invisible when it works and catastrophic when it doesn’t. I’d rather the script crash and still clean up after itself than ship a feature and leave a plaintext export sitting in a temp folder because someone hit Ctrl-C at the wrong moment.

Threat-model your one credential that can’t be wrong

Every system has at least one of these. The credential, the key, the record that everything else assumes is correct and available. For most of us it’s a password vault; for some it might be a signing key or a recovery seed.

The exercise worth doing isn’t “add more backups.” It’s listing the ways that one thing could become unavailable or wrong, and checking that your copies don’t all fail for the same reason. If they do, you’ve built redundancy theater, not redundancy.

Running a Personal SOC: Bringing Production Security Practices Home

Fri, 12 Jun 2026 10:00:00 +0100

At work, nobody questions why we have logging, alerting, and a daily look at what changed overnight. At home, the same network runs a NAS, a media stack, Home Assistant, and a handful of containers. And for years my only “security monitoring” was noticing something was broken.

So I built myself a small, read-only security operations setup for the homelab: a daily audit script and a cross-domain digest agent that correlates it with everything else running on the network. Nothing here is novel security research. The interesting part is which production habits turned out to be worth carrying home, and which ones I deliberately left at the office.

Two layers, not one

The setup is split into two pieces with different jobs.

The daily audit is the boring, deterministic layer. Once a day it collects, locally and read-only:

listening sockets, flagging anything bound to a wildcard interface
Docker/container posture: privileged containers, dangerous bind mounts, host network mode, dangerous capabilities
systemd service drift against an expected allowlist
a local secrets/config hygiene scan (path, line, and pattern only - never the matched value)
cached apt list --upgradable, optionally enriched with a trivy fs scan
whether the monitoring artifacts and timers it depends on are actually present

It writes a deterministic Markdown digest and a JSON report to a local outbox. That’s it. No remediation, no service restarts, no firewall changes. The rule I gave it was “assume breach, trust no single signal, change nothing during observation.”

The SOC agent is the correlation layer on top. It runs once a day and pulls together SSH auth logs (brute-force detection, unexpected successful logins, elevated sudo activity), Docker security posture, UniFi network signals (unknown MAC addresses, active IPS/DPI/flood/scan/rogue alarms), and re-surfaces anything security-relevant the daily audit already found. Everything gets a severity from ok up through critical, and the result is written as an Obsidian note with YAML frontmatter. So a year of these becomes a searchable, taggable incident timeline instead of a folder of text files nobody opens.

Where the LLM fits - and where it doesn’t

Both agents can optionally hand their findings to a local Ollama model to write a short narrative summary on top of the facts. This is the part I was most careful about, because it’s the part most people get backwards.

The model never sees raw logs, full inventories, or matched secrets. It only compact finding titles, IDs, severities, and evidence keys. It doesn’t decide what’s a finding; the deterministic analyzers do that. And if Ollama is unreachable or returns something unusable, the deterministic digest ships as-is. The LLM is a narrator, never the source of truth.

That’s the same boundary I’d want on a production alerting pipeline: detection logic stays deterministic and testable, and generative summarization sits strictly downstream of it, never upstream.

The part that’s just operational discipline

A few choices here have nothing to do with security theory and everything to do with habits from running things in production:

Output paths are permissioned, not just “private by convention.” Reports get 0600, runtime directories 0700.
Stale data is treated as a finding, not silently trusted. Upstream reports older than a configured threshold are flagged rather than quietly re-surfaced as current.
Notifications are a tap-through, not the whole story. A push notification carries the headline and a link into the actual note - useful at a glance, but the record of truth lives in the note, not in a chat history that scrolls away.
Everything is replayable offline. Both agents accept a fixture file in place of live collection, so I can test a new analyzer rule against a known input before it ever touches my real network.

What it actually buys me

Mostly, it buys me the same thing it buys at work: I notice drift before it becomes an incident, instead of after. A container that quietly picked up a privileged flag, a port that got published wider than intended, an unfamiliar MAC address on the network. These are exactly the kind of small, boring facts that are easy to miss and easy to detect deterministically.

It’s not a real SOC. There’s no 24/7 coverage, no incident response retainer, and the threat model is “don’t get owned by something dumb,” not “defend against a motivated attacker.” But the muscle is the same one I use at work: write the check once, make it boring and deterministic, let a model help you read the output, and keep a record you can actually search six months later.

If you’re already doing this professionally, the homelab version costs you an evening and pays you back the first time you catch something you would have otherwise missed entirely.

Home Assistant Roomba Script

Wed, 07 Feb 2024 10:00:00 +0100

I recently acquired a Roomba j9+ from iRobot. While it’s an excellent vacuum robot, I found the accompanying app lacking, especially since it requires the vacuum to be online, and the robot has a camera—an aspect I’m not particularly fond of.

To overcome these limitations, I decided to integrate my Roomba into my Home Assistant setup. However, due to a recent iRobot update, the local API no longer provides map data. This article outlines a Python script-based solution I devised for seamless integration.

Prerequisites

Before we dive into the script, there are a few essential prerequisites:

Map and Room Configuration:
- Ensure you have created the map and defined different rooms using the official iRobot app.
Dorita980 Library:
- We will use the dorita980 library to interact with the Roomba. This JavaScript library also helps us retrieve commands sent to the robot. To keep things straightforward, we’ll run it in a custom Node.js app or a Docker container. More info here.

Retrieving necessary data

With the prerequisites in place, follow these steps to get the required map and room IDs:

Install dorita980

1

npm install dorita980

Get Credentials

1

npm run get-roomba-password-cloud

This command will provide your BLID and password, crucial for Home Assistant integration.

Retrieve Map and Room IDs

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// index.js
const BLID = 'YOUR_BLID';
const PASSWORD = 'YOUR_PASSWORD';
const ROBOT_IP = 'YOUR_ROBOT_IP';

const dorita980 = require('dorita980');
const robot = new dorita980.Local(BLID, PASSWORD, ROBOT_IP);

robot.on('connect', () => {
 robot.getRobotState().then((state) => {
 console.log(state.lastCommand);
 });
});

Start the job from the iRobot app, close the app from your mobile and run:

1

node index.js

Note: if you installed the HA iRobot extension before these steps: As per this comment, make sure the Continuous option is NOT enabled in HA integration. Don’t forget to turn it back on once you are done.

You’ll get something like:

1
2
3
4
5
6
7
8
9


{
 command: 'start',
 pmap_id: 'YOUR_MAP_ID',
 user_pmapv_id: 'YOUR_USER_MAP_ID',
 regions: [
 { params: {}, region_id: 'YOUR_ROOM_ID', type: 'rid' },
 { params: {}, region_id: 'YOUR_ZONE_ID', type: 'zid' },
 ]
}

Note: If you decide to edit the map, the user_pmapv_id will change, so you’ll need to update it.

Install the iRobot extension

Add the officiel HA integration for iRobot (here) and log in to your robot using the credentials.

The script

Back to the main topic: the script.

In order to have a better control from the UI, I’ve decided to create a couple of helpers:

vaccum_room_[the name of the room] this is a toggle that will trigger a job in a specific room
vaccum_room_[the name of the room]_mop this is also a toggle, but this will tell the robot to also mop the room

We also need a couple of other helpers for the various modes and options we can set on the robot:

vacuum_mode: quiet | normal | powerful (dropdown)
vacuum_mop_mode: eco | standard | ultra (dropdown)
vacuum_scrub: true | false (toggle)
vacuum_two_pass: true | false (toggle)

There’re a couple of other options we could set, but I don’t use them, so they are hardcoded in the script.

How to use it

Two ways of using it, you can either change the toggles, and call the script from the UI, or you can create an automation.

Now if you want to create an automation, you can use the input_boolean and input_select helpers to set everything up, and call the script when everything is ready.

For my specific needs:

I turn on the plug
I change the toggles to true for the room I want to clean
I wait for 3 seconds (just to make sure the script has time to get the new state)
I call the script

This automation is triggered by a calendar event, so I can schedule the cleaning easily.

Stripe webhooks with NextJS

Sun, 30 Apr 2023 00:00:00 +0000

Before we start

Stripe webhooks enable receiving notifications when an event occurs in your stripe account, such as payment or subscription creation, customer creation, among others.

Data received varies depending on the event: payment intent id, amount, currency, etc., for payment creation, for example.

This NextJS tutorial focuses on webhook management solely, not stripe integration for your application. Assuming that you have a stripe account and prior knowledge in payment intent or customer creation, we will cover setting up a webhook handler in NextJS.

Setup webhook in Stripe

Go to your stripe dashboard, then click on the “Developers” tab, then on “Webhooks”.

Then click on “Add endpoint”.

The url is the url of your NextJS application. For instance, if your application is deployed on Vercel, it will be something like https://your-app.vercel.app/api/webhooks.

Then, you need to choose the events you want to listen to. For instance, if you want to listen to the payment_intent.succeeded event, you need to select “Payment intent succeeded” in the “Event types” dropdown.

Then click on “Add endpoint”.

Create a webhook handler

Lets jump right into the code. First, we need to create a handler that will be called when a webhook is received. We are going to create a file called webhooks.ts in the pages/api folder.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64


// pages/api/webhooks.ts
import { buffer } from 'micro';
import { NextApiRequest, NextApiResponse } from 'next';
import Stripe from 'stripe';

// This part is necessary so that NextJS doesn't parse the request body
// Otherwise it will manipulate it and stripe will reject it
export const config = {
 api: {
 bodyParser: false,
 },
};

// the handler
const handleWebhook = async (
 req: NextApiRequest, 
 res: NextApiResponse
 ) => {
 if (req.method === 'POST') {
 try {
 // get the stripe signature
 const sig = req.headers['stripe-signature'];
 const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
 apiVersion: '2022-11-15',
 typescript: true,
 });
 const buf = await buffer(req);
 const stripeEvent = stripe.webhooks.constructEvent(
 buf,
 sig!,
 process.env.STRIPE_ENDPOINT_SECRET!
 );
 // now you have access to the stripe event

 switch (stripeEvent.type) {
 // this is where we are going to add our logic 
 // depending on the event type
 case '':
 break;
 // ...
 }

 // just inform stripe that you received the event
 res.send({ status: 'success' });
 return;
 } catch (error: any) {
 // lets handle any errors coming from stripe
 console.log(error);
 res.status(500).json({ error: error.message });
 return;
 }
 }

 // if the request is not a POST request, we return a 404
 res.status(404).json({
 error: {
 code: 'not_found',
 message:
 "The requested endpoint was not found",
 },
 });
}

export default handleWebhook;

Event specific logic

Lets say you have a subscription for your software and you want to update your database with the subscription ID when the checkout session is completed. You can do something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


case 'checkout.session.completed':
 const session = stripeEvent.data.object as Stripe.Checkout.Session;

 const subscription = await stripe.subscriptions.retrieve(
 session.subscription as string
 );

 // update your database with the subscription id or status, ...

 break;

For the events list, you can refer to the stripe documentation.

Environment variables

As you can see, we will need 2 environment variables (locally in your .env.local file):

STRIPE_SECRET_KEY
STRIPE_ENDPOINT_SECRET

You can find them in your stripe dashboard, in the “Developers” tab, then “API keys”.

Testing the webhook locally

Now that we have our webhook handler, we need to test it. The problem is that we can’t test it locally because stripe needs to be able to send a request to our application. So we need to expose our local application to the internet.

The easiest way is to use stripe cli. You can download it here.

Then, you need to login to your stripe account:

1

stripe login

Then, you need to start listening to the events and forward the request to our local application.:

1

stripe listen --load-from-webhooks-api --forward-to localhost:3000

Now we can just use our app locally and debug the events based on our flow.

If you want to trigger a specific event, you can use the trigger command:

1

stripe trigger payment_intent.succeeded

Just as a general note, you should test in “test mode” first, then when you are ready, you can switch to “live mode”.

NextJS api validators

Mon, 17 Apr 2023 00:00:00 +0000

NextJS background

NextJS is a popular React framework for building server-rendered React applications. It provides a feature called “API Routes” that allows you to create serverless functions within your NextJS application to handle API requests.

API Routes in NextJS provide a convenient way to create server-side logic for handling HTTP requests, such as fetching data from a database, processing form submissions, or integrating with third-party APIs. These API Routes are automatically deployed as serverless functions and can be accessed via API endpoints.

To create an API Route in NextJS, you can create a file with the .js or .ts extension in the pages/api directory of your NextJS project. This file represents the API endpoint that you want to create. For example, you can create a file called myApi.ts in the pages/api directory to create an API endpoint with the URL path /api/myApi.

Inside the API Route file, you can define your server-side logic using JavaScript or TypeScript. You can use popular Node.js libraries for handling HTTP requests and responses, such as http, express, or axios. For example, you can define an API Route that handles a POST request and returns a JSON response like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// pages/api/myApi.ts

export default function handler(req: NextApiRequest, res: NextApiResponse) {
 if (req.method === 'POST') {
 // Handle POST request logic here
 const { email, address } = req.body;
 // Process the data and send response
 res.status(200).json({ message: 'Data received', email, address });
 } else {
 res.status(400).json({ message: 'Invalid request method' });
 }
}

This is quite easy to setup and great to use. Except when the application grows and you need to validate the data coming from the client.

For instance, if you want to have the same endpoint and handle the GET and the POST request, you can do something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// pages/api/myApi.ts

export default function handler(req: NextApiRequest, res: NextApiResponse) {
 if (req.method === 'POST') {
 // your logic
 res.status(200).json({ message: 'Post method' });
 } else if (req.method === 'GET') {
 // your get logic
 res.status(200).json({ item: {name: 'my item', price: 0} });
 } else {
 res.status(400).json({ message: 'Invalid request method' });
 }
}

And if you need to validate the data coming from the client, you will need to add some logic to check if the data is valid or not.

That’s when next-api-decorators comes in handy.

Main caveat: you handler needs to be a class rather than a function.

What you need to install

1

npm install next-api-decorators class-validator

So now, you can create a class that will handles our previous requests like so:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// pages/api/myApi.ts

class MyApiRouteHandler {
 @Post()
 @HttpCode(200) // will return a 200 if everything is ok
 createItem() {
 return { message: 'Post method' };
 }

 @Get()
 @HttpCode(200) // will return a 200 if everything is ok
 getItem() {
 return ({ item: {name: 'my item', price: 0} });
 }
}
export default createHandler(MyApiRouteHandler);

Way cleaner and easier to read.

Validation

Now lets add some validation to our request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// pages/api/myApi.ts

export default class MyApiRouteHandler {
 @Post()
 @HttpCode(201) // will return a 201 if everything is ok
 createItem(
 @Body(ValidationPipe) body: ItemCreationDto,
 @Req() req: NextApiRequest,
 @Res() res: NextApiResponse
 ) {
 const { name, price } = body;
 return { message: 'Post method', name, price };
 }
}

We are using the ValidationPipe from class-validator to validate our request body.

1
2
3
4
5
6
7
8
9


class ItemCreationDto {
 @IsString()
 @IsNotEmpty()
 name: string;

 @IsNumber()
 @IsNotEmpty()
 price: number;
}

Now when you call your endpoint, you will get a 400 error if your body is not valid. So quite easy to use. Now you can just insert your data in the database for instance without having to write extra code for validation.

Conclusion

In conclusion, NextJS API validator is a valuable tool for building secure and robust APIs in a TypeScript context. By leveraging its features for type checking, data validation, and sanitization, you can create APIs that are more resilient to common security risks, provide better error handling, and deliver a more reliable and secure user experience. Incorporating NextJS API validator in your NextJS TypeScript projects can greatly enhance the overall quality and security of your APIs.

UI Design - Rent A Car

Tue, 28 Mar 2023 00:00:00 +0000

Just having fun with CSS by creating (and tweaking) a UI design for a rental car website from Figma.

Original design by uidesigndaily.com.

Here’s the final result:

Right click > View Frame Source to see the code.

Create a blog with supabase and nextjs - part 5

Wed, 22 Mar 2023 00:00:00 +0000

Create a supabase account

Until now we’ve been using supabase locally with docker. Lets create the necessary accounts so we can deploy our blog to the cloud.

Go to supabase and create an account, and then a project. We won’t go into details about the project creation, you can find more information in the docs.

We have a couple of different ways of doing it, either by using the sql editor and copy pasting the migration file, or by using github actions.

If you created the database manually from the UI, you can just get the migration by running:
1
npx supabase db diff -f first-migration

Create a Github repository

Create a new repository or fork my repository if you haven’t done everything on your side already.

Github actions

Lets go back to the database. What we want to do is deploy the database to supabase when we push to the main branch. We can do that by using github actions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


## .github/workflows/deploy-migrations.yml
name: Deploy Migrations to Supabase

## targets the main branch - when we push to main, the workflow will run
on:
 push:
 branches:
 - main
 workflow_dispatch:

jobs:
 deploy:
 runs-on: ubuntu-latest

 env:
 SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
 SUPABASE_DB_PASSWORD: ${{ secrets.SUPABASE_DB_PASSWORD }}
 SUPABASE_PROJECT_ID: ${{ vars.SUPABASE_PROJECT_ID }}

 steps:
 - uses: actions/checkout@v3

 - uses: supabase/setup-cli@v1
 with:
 version: latest

 - run: |
 supabase link --project-ref $SUPABASE_PROJECT_ID
 supabase db push

We need to create a folder called .github/workflows and create a file called deploy-migrations.yml with the content above.

In github (Settings > Secrets and variables > Actions), we also need to create the following secrets:

SUPABASE_ACCESS_TOKEN
SUPABASE_DB_PASSWORD

And the following variable:

SUPABASE_PROJECT_ID

You can find the values in the supabase dashboard.

Deploying the blog

First we need to create a vercel account and link it to our github account. Once that’s done, just create a new project.

Once again setup the supabase environment variables in the vercel dashboard. Those values are for Next.js this time.

And that’s it, we’re done. You can now go to your project and commit/push to the main branch to deploy the database and the blog.

Create a blog with supabase and nextjs - part 4

Tue, 21 Mar 2023 00:00:00 +0000

If you want to jump straight to the source code, here’s the link to the github repository.

One thing we haven’t done yet is server side rendering. We are currently fetching the posts using the useEffect hook. This means that the posts won’t be available until the component is mounted. We can do better by using the getStaticProps function from nextjs to fetch the posts on the server.

Lets use the /posts/[id] page to do just that.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


export const getServerSideProps = async (ctx: GetServerSidePropsContext) => {
 const supabase = createServerSupabaseClient(ctx); // from '@supabase/auth-helpers-nextjs';
 const { data } = await supabase
 .from('posts')
 .select('*')
 .eq('id', ctx.params?.id)
 .single();

 if (!data) {
 // if the post doesn't exist, return 404
 return {
 notFound: true,
 };
 }

 // return the post a prop
 return {
 props: {
 post: data,
 },
 };
};

By using getServerSideProps, we can now fetch the post on the server and pass it to the component as a prop. Our PostPage component already have the post prop so we can just use it (see part 2).

Next step we are going to deploy our blog

Github actions: Deploy a Hugo website to a FTP server

Mon, 20 Mar 2023 10:00:00 +0000

Introduction

Nowadays, it never has been easier to build and host a website for having any form of online presence. You don’t even need a lot of web development knowledge. There are many tools and resources available that make the process easier than ever. One such tool is Hugo, a fast and flexible static site generator that allows users to create websites quickly and easily. In addition, deploying a Hugo site to a web server can be made even simpler through the use of Github Actions (assuming your code is hosted on github), a powerful automation tool that can be used to automatically deploy a website to a FTP server. In this article, we’ll explore how to use Hugo to build a website and then deploy it to a FTP server using Github Actions, providing a step-by-step guide for those looking to get their website up and running quickly and efficiently.

Github actions

Github actions is a great tool to automate your workflow. It is free for repositories (with some limitations on private repositories) and you can use it to build, test and deploy your code.

Setting up the environment variables

You need to set up some environment variables in your repository. You can do this by going to Settings > Secrets & Variables > Actions in your Github repository (under Security).

You need to set up the following variables:

Creating the workflow

Now that we have the environment variables set up, we can create the workflow. You can create a file called main.yml in the .github/workflows folder in your repository.

The workflow consists of two jobs: “build” and “deploy”. The “build” job builds the hugo site and the “deploy” job deploys the site to the FTP server.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81


name: 🚀 Deploy to prod

# Will trigger the workflow on each push to the main branch
on:
 push:
 branches:
 - main

 # Allows you to run this workflow manually from the Actions tab
 workflow_dispatch:

jobs:
 # The first job will build the hugo site and upload the artifact
 build:
 name: 🔧 Build Hugo site
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.111.2
 steps:
 - name: Install Hugo CLI
 run: |
 wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
 && sudo dpkg -i ${{ runner.temp }}/hugo.deb

 - name: Install Dart Sass Embedded
 run: sudo snap install dart-sass-embedded

 - name: Checkout
 uses: actions/checkout@v3
 with:
 submodules: recursive
 fetch-depth: 0

 - name: Install Node.js dependencies
 run: '[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true'

 - name: Build with Hugo
 env:
 # For maximum backward compatibility with Hugo modules
 HUGO_ENVIRONMENT: production
 HUGO_ENV: production
 run: |
 hugo \
 --gc \
 --minify

 # We save the result as an artificat so we can use it in the next job
 - name: Upload artifact
 uses: actions/upload-artifact@v3
 with:
 name: release-artifact
 path: './public'

 # The second job will deploy the site to the FTP server using the artifact from the first job
 deploy:
 name: 🎉 Deploy
 runs-on: ubuntu-latest
 needs: build
 steps:
 - name: Checkout
 uses: actions/checkout@v3

 # Download the artifact we just created
 - name: Download artifact
 uses: actions/download-artifact@v3
 with:
 name: release-artifact
 path: './public' # This is the path where the artifact will be downloaded to

 - name: Deploy file
 uses: wlixcc/SFTP-Deploy-Action@v1.2.4
 with:
 server: ${{ vars.ftp_server }}
 username: ${{ vars.ftp_username }}
 ssh_private_key: ${{ secrets.ftp_password }}
 # or if you only use a password
 # sftp_only: true
 # password: ${{ secrets.ftp_password }}
 port: ${{ vars.ftp_port }}
 remote_path: '/var/www/app' # This will depend on your server
 local_path: './public/*' # This is the path where the artifact is located

Now you only need to commit and push your changes to the main branch and the workflow will be triggered.

Sources:

Other alternatives

You can deploy your hugo site to a lot of other services like Netlify, Vercel, Render, etc. You can find a list of all the services here.

Create a blog with supabase and nextjs - part 3

Mon, 20 Mar 2023 00:00:00 +0000

If you want to jump straight to the source code, here’s the link to the github repository.

The `useSignIn` hook

We are going to create a hook to handle the signin process. We will use the useAuth hook from @supabase/auth-helpers-nextjs to handle the authentication. It returns an object with two methods: signInWithEmail and signOut.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


import { useSupabaseClient } from '@supabase/auth-helpers-react';

const useSignIn = () => {
 const supabase = useSupabaseClient();

 const signInWithEmail = async (email: string) => {
 const { error } = await supabase.auth.signInWithOtp({
 email: email,
 });
 if (error) throw error;
 };

 const signOut = async () => {
 const { error } = await supabase.auth.signOut();
 if (error) throw error;
 };

 return { signInWithEmail, signOut };
};

export default useSignIn;

Here’s a breakdown of the hook’s functionality:

`signInWithEmail` method

The signInWithEmail method is an asynchronous function that takes an email address as an argument. It uses the Supabase client obtained from the useSupabaseClient hook to call the signInWithOtp method and attempt to sign the user in with a magic link.

The user will only need to check his/her email and click on the link to sign in.

`signOut` method

The signOut method is an asynchronous function that calls the signOut method of the Supabase client obtained from the useSupabaseClient hook to sign the user out of their account. If the sign-out attempt fails, the function throws the error.

The `usePosts` hook

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


import { useState } from 'react';
import { Database } from '@/types/database.types';
import { useSupabaseClient, useUser } from '@supabase/auth-helpers-react';
import { Post } from '@/types/Post';

const useGetPosts = () => {
 // Retrieve Supabase client and user from context
 const supabase = useSupabaseClient<Database>();
 const user = useUser();

 // Initialize posts state
 const [posts, setPosts] = useState<Post[]>([]);

 // Retrieve posts from the database
 const getPosts = async (limit?: number) => {
 const { data, error } = await supabase
 .from('posts')
 .select('*')
 .limit(limit || 50);
 if (error) throw error;
 setPosts(data || []);
 };

 // Create a new post in the database
 const createPost = async (title: string, body: string) => {
 if (!user) throw new Error('User not found');
 const { data, error } = await supabase
 .from('posts')
 .insert({
 title,
 body,
 author: user.id,
 })
 .select()
 .single();
 if (error) throw error;
 return data;
 };

 // Update an existing post in the database
 const updatePost = async (id: string, title: string, body: string) => {
 const { data, error } = await supabase
 .from('posts')
 .update({
 title,
 body,
 })
 .match({ id })
 .select()
 .single();
 if (error) throw error;
 return data;
 };

 return {
 getPosts,
 updatePost,
 createPost,
 posts,
 };
};

export default useGetPosts;

This custom hook provides functionality for retrieving and manipulating posts from a Supabase database.

Nothing too fancy about it, it’s just a wrapper around the Supabase client. In terms of security, the RLS are already taking care of everything so we don’t need to worry about that.

Lets integrate the hooks in the app

First lets do the signin page.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// --- src/components/SignupModal.tsx ---
const { signInWithEmail } = useSignIn();

const handleSubmit = async (evt: FormEvent<HTMLFormElement>) => {
 evt.preventDefault();
 try {
 await signInWithEmail(email);
 } catch (error: any) {
 console.log(error.message);
 }
};

Previously the posts array was just an empty array we were saving in the state. Now we are going to fetch the posts from the database. The useGetPosts hook provides a getPosts method that we can use to fetch the posts and a posts state that we can use to display the posts. So no changes to the UI.

1
2
3
4
5


// --- src/components/PostList
const { getPosts, posts } = useGetPosts();
useEffect(() => {
 getPosts();
}, []); // only on mount

Creating a post is pretty straightforward.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// --- src/pages/new.tsx ---
const router = useRouter();
const { createPost } = usePosts();

const handleSubmit = async (title: string, body: string) => {
 try {
 const { id } = await createPost(title, body);
 router.push(`/posts/${id}`);
 } catch (error: any) {
 console.log(error.message);
 }
};

We call the hook that will create a new post in the database and redirect the user to the newly created post if it succeeds.

And finally lets update the detail page the same way.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// --- src/pages/posts/[id].tsx ---
const router = useRouter();
const { updatePost } = usePosts();

const handleSubmit = async (title: string, body: string) => {
 try {
 await updatePost(post.id, title, body);
 router.reload();
 } catch (error: any) {
 console.log(error.message);
 }
};

The last step is to fetch the post and display them in the post page (/posts/[id]), based on the id in the url. To do that, we are going to do it differently and use the getServerSideProps function from Next.js.

Next step lets do some SSR

Create a blog with supabase and nextjs - part 2

Sun, 19 Mar 2023 00:00:00 +0000

If you want to jump straight to the source code, here’s the link to the github repository.

Preview of the UI

Here’s what we are going to build:

The home page

Based on what we’ve done in the previous part, we are now going to create a component to display the posts called PostList.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// --- src/components/PostList.tsx ---
const PostList = () => {
 const [posts, setPosts] = useState<Post[]>([]);
 return (
 <Container>
 <Stack direction="horizontal" gap={3}>
 <h1>Latest posts</h1>
 <Link href={`/posts/new`} legacyBehavior>
 <Button>+ new post</Button>
 </Link>
 </Stack>
 <Row xs={1} md={2}>
 {posts.map((post) => (
 <Col key={post.id}>
 <PostCard post={post} />
 </Col>
 ))}
 </Row>
 </Container>
 );
};
export default PostList;

Nothing complicated, we just display the posts in a grid. We also have a button to create a new post.

Because we are using bootstrap, we need to use the legacyBehavior prop on the Link component to make it work. Now by default next/link creates a a tag with a href attribute. This is not compatible with bootstrap as bootstrap already creates a a tag with the Button component.

More info in the doc here.

Quick note about the types: we are using the Post type from the types/Post.ts file which uses the types from the database. You can generate them by running: npm run dev:gen-types

Now we need a nav bar to display the login button and the title of the blog.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


// --- src/components/Header.tsx ---
const Header = () => {
 const user = useUser(); // hook from '@supabase/auth-helpers-react';
 const [showModal, setShowModal] = useState(false);
 const handleLogout = () => {
 // logout logic will go here
 };
 return (
 <>
 <SignupModal show={showModal} handleClose={() => setShowModal(false)} />
 <Navbar bg="light">
 <Container>
 <Navbar.Brand href="#home">My Supabase blog</Navbar.Brand>
 <Navbar.Toggle />
 <Navbar.Collapse className="justify-content-end">
 {user ? (
 <Button variant="link" onClick={handleLogout}>
 Logout
 </Button>
 ) : (
 <Button onClick={() => setShowModal(true)}>Login</Button>
 )}
 </Navbar.Collapse>
 </Container>
 </Navbar>
 </>
 );
};
export default Header;

Those components will be used in the index.tsx file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// --- src/pages/index.tsx ---
const Home = () => {
 return (
 <>
 {/* see previous step */}
 <main>
 <Header />
 <PostList />
 </main>
 </>
 );
};

We are going to use the Modal component from bootstrap to display the login form so we don’t need to create a separate page.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


// --- src/components/SignupModal.tsx ---
const SignupModal = ({ show = false, handleClose }: Props) => {
 const [email, setEmail] = useState('');

 const handleSubmit = async (evt: FormEvent<HTMLFormElement>) => {
 evt.preventDefault();
 // login logic will go here
 };

 return (
 <Modal show={show} onHide={handleClose}>
 <Card body>
 <Form id="login" onSubmit={handleSubmit}>
 <Form.Group className="mb-3" controlId="formLoginEmail">
 <Form.Label>Email address</Form.Label>
 <Form.Control
 type="email"
 value={email}
 onChange={({ target }) => setEmail(target.value)}
 />
 </Form.Group>
 <Button type="submit" disabled={loading}>
 Login
 </Button>
 </Form>
 </Card>
 </Modal>
 );
};

export default SignupModal;

Post creation page

For this new page (/posts/new), we are going to keep the logic simple and in the page, the form will be a separated component called PostEditForm.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// --- src/pages/posts/new.tsx ---
const NewPostPage = () => {
 const handleSubmit = async (title: string, body: string) => {
 // create post logic will go here
 };

 return (
 <>
 <main>
 <Header />
 <Container>
 <Link href="/" legacyBehavior>
 <Button variant="link">{'<'}Back to all posts</Button>
 </Link>
 <h1>New Post</h1>
 <PostEditForm saveForm={handleSubmit} />
 </Container>
 </main>
 </>
 );
};

export default NewPostPage;

The PostEditForm component is pretty simple, it just displays a form with one input and a submit button.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


// --- src/components/PostEditForm.tsx ---
const PostEditForm = ({ saveForm, post }: Props) => {
 const [title, setTitle] = useState('');
 const [body, setBody] = useState('');

 // if we are editing a post, we need to set the initial values on mount
 useEffect(() => {
 if (post) {
 setTitle(post.title);
 setBody(post.body);
 }
 }, [post]);

 const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
 e.preventDefault();
 await saveForm(title, body);
 };

 return (
 <Form onSubmit={handleSubmit}>
 <Form.Group className="mb-3">
 <Form.Label>Title:</Form.Label>
 <Form.Control
 value={title}
 onChange={({ target }) => setTitle(target.value)}
 />
 </Form.Group>
 <Form.Group className="mb-3">
 <Form.Label>Content:</Form.Label>
 <Form.Control
 as="textarea"
 rows={3}
 value={body}
 onChange={({ target }) => setBody(target.value)}
 />
 </Form.Group>
 <Button type="submit">Save</Button>
 </Form>
 );
};

export default PostEditForm;

The post page and the edit page 📝

The post page will display the post and a button to edit it. The edit component will be the same as the new post component but with the initial values set.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// --- src/pages/posts/[id].tsx ---
const PostPage = ({ post }: Props) => {
 const [isEditing, setIsEditing] = useState(false);

 const handleSubmit = async (title: string, body: string) => {
 // update post logic will go here
 };

 return (
 <main>
 <Header />
 <Container>
 <Link href="/" legacyBehavior>
 <Button variant="link">{'<'}Back to all posts</Button>
 </Link>
 {isEditing ? (
 <PostEditForm post={post} saveForm={handleSubmit} />
 ) : (
 <>
 <h1>{post.title}</h1>
 <div>{post.body}</div>
 {user && user.id === post.author && (
 <Button onClick={() => setIsEditing(true)}>Edit post</Button>
 )}
 </>
 )}
 </Container>
 </main>
 );
};

The UI is now done, in the next part we will create the hooks to fetch the data from the database.

Next step the hooks 🎣

Create a blog with supabase and nextjs - part 1

Sat, 18 Mar 2023 00:00:00 +0000

If you want to jump straight to the source code, here’s the link to the github repository.

In short: this tutorial starts a Next.js and Supabase blog application from scratch. It covers project setup, Supabase initialization, the first database table, row-level security policies, and the initial Next.js page structure.

Introduction

In this tutorial, we will build a simple blogging application using Next.js and Supabase. Next.js is a popular React framework for building server-side rendered and statically generated web applications, while Supabase is an open source Firebase alternative that provides a PostgreSQL database and authentication APIs out of the box. By combining these technologies, we can easily create a performant and scalable blogging platform.

Throughout this tutorial, we will cover the following topics:

Setting up a Next.js project and integrating Supabase for authentication.
Creating a PostgreSQL database schema for our blog application using Supabase.
Implementing server-side rendering and client-side routing with Next.js.
Building a user interface for creating, editing, and deleting blog posts using React components.
Deploying our application to the cloud using Vercel.

By the end of this tutorial, you will have a fully functional blog application that can be customized and expanded to suit your needs. So let’s get started!

Setup our project

Create a new project with next.js and typescript:

1

npx create-next-app@latest --typescript

Install supabase and bootstrap:

1
2
3
4


npm install supabase --save-dev
npm install @supabase/supabase-js
npm install @supabase/auth-helpers-nextjs @supabase/auth-helpers-react
npm install react-bootstrap bootstrap

Now we can initialize supabase:

1

npx supabase init

Which will create the supabase folder with the config, and finally, start all the services:

1

npx supabase start

Now for the Next.js part, we need to create a .env.local file in the project root and add the following environment variables (see the screenshot below for the values):

1
2


NEXT_PUBLIC_SUPABASE_URL=<your-supabase-api-url>
NEXT_PUBLIC_SUPABASE_KEY=<your-supabase-api-key>

Lets start the dev server:

1

npm run dev

We are good to go!

via GIPHY

The database

We only need a posts table with the following columns:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


create table "public"."posts" (
 "id" uuid not null,
 "title" text not null,
 "body" text not null,
 "created_at" timestamp with time zone default now(),
 "author" uuid not null
);

CREATE UNIQUE INDEX posts_pkey ON public.posts USING btree (id);

alter table "public"."posts" add constraint "posts_pkey" PRIMARY KEY using index "posts_pkey";
alter table "public"."posts" add constraint "posts_author_fkey" FOREIGN KEY (author) REFERENCES auth.users(id) not valid;
alter table "public"."posts" validate constraint "posts_author_fkey";

You can either create the table manually, or use the supabase dashboard.

Quick note on the author column: we are using directly the uuid from the auth.users table. Usually as a good practice I would create a profiles table with the id as the primary key and additionnal infos (like the name, the avatar, etc…). But for this tutorial I will keep it simple.

Lets turn on RLS (Row Level Security) for the posts table, and authorise everyone to read the table, any logged in user to create posts, and finally only the owner can update:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


alter table "public"."posts" enable row level security;

create policy "everyone can see posts"
on "public"."posts"
as permissive
for select
to public
using (true);

create policy "only logged in users can create posts"
on "public"."posts"
as permissive
for insert
to authenticated
with check (true);

create policy "only the user can edit"
on "public"."posts"
as permissive
for update
to public
using ((auth.uid() = author))
with check ((auth.uid() = author));

You can see (and actually create/edit) those policies in the supabase dashboard:

Note: no delete for now - so I’ve kept it out of the policies - but it would be the same, only owners can delete.

NextJs setup

Lets get rid of the default page in the pages folder and replace the index.tsx with the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import Head from 'next/head';
const Home = () => {
 return (
 <>
 <Head>
 <title>Posts list</title>
 <meta name="description" content="Blog made with NextJs and Supabase" />
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <link rel="icon" href="/favicon.ico" />
 </Head>
 <main>{/* Our components will go here */}</main>
 </>
 );
};
export default Home;

As a reminder, the pages folder is a special directory in a Next.js project that contains the pages of your application. When you create a new file in this folder, Next.js automatically generates a route for it based on the file name. For example, the index.js in the pages folder, it will be mapped to the root URL of your application.

For our application, we will have the following pages:

/: the home page, which will list all the posts
/posts/[id]: the post detail page
/posts/new: the new post page

In terms of structure, our src folder will look like the following:

So to recap, we will have:

components: our React components
hooks: our custom hooks for getting/setting data from supabase
pages: our Next.js pages
styles: for some custom styling
types: for our database types

Everything is now ready, lets jump on the UI!

Next step: the UI

Supabase initial DB migration

Sat, 04 Mar 2023 00:00:00 +0000

Supabase edge functions - a quick start

Mon, 27 Feb 2023 00:00:00 +0000

Supabase edge functions are quite powerful, but you need to setup a lot of things to get started. So here is a quick start guide to get you started.

Disclaimer: this is how I use them in real projects, with my prefered stack, and this post is a way for me to remember how to setup everything.

Usually, I use Next.js, and I want to use the same stack for my edge functions. So I will use the following stack:

1

npx create-next-app@latest --typescript

1
2


npx install supabase --save-dev
npm install @supabase/supabase-js --save

First lets init the supabase project, and start the local server:

1
2


npx supabase init
npx supabase start

Now to create an edge functions:

1

npx supabase functions new my-function

To test it, your need to run the Functions watcher

1

npx supabase functions serve

So for our test, the edge function will be called by an endpoint. So we need to create a new endpoint in /pages/api/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// pages/api/simple-edge-function.ts
import { createClient } from '@supabase/supabase-js';
import { NextApiRequest, NextApiResponse } from 'next';

const simpleEdgeFunction = async (
 req: NextApiRequest,
 res: NextApiResponse
) => {
 const supabase = createClient(
 process.env.NEXT_PUBLIC_SUPABASE_URL || '',
 process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY || ''
 );

 // 'my-function' is the name of the function you created from the cli above
 const { data, error } = await supabase.functions.invoke('my-function', {
 body: { name: 'Functions' },
 });

 console.log(data);

 res.status(200).json({ data, error });
};

export default simpleEdgeFunction;

Now go to supabase/functions/my-function/index.ts, and simply return a string:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// this is the example from the supabase documentation
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts';

console.log('Hello from Functions!');

serve(async (req: Request) => {
 const { name } = await req.json();
 const data = {
 message: `Hello ${name}!`,
 };

 return new Response(JSON.stringify(data), {
 headers: { 'Content-Type': 'application/json' },
 });
});

Now if you call the endpoint:

1

curl http://localhost:3000/api/simple-edge-function

it will return:

1
2
3
4
5
6


{
 "data": {
 "message": "Hello Functions!"
 },
 "error": null
}

And print in the functions watcher console:

1

Hello from Functions!

and in the supabase console:

1

{ message: 'Hello Functions!' }

If you need to use an env file, you need to run the watcher with the --env-file parameter:

1

npx supabase functions serve --env-file .env.local

Setup supabase locally with docker

Tue, 14 Feb 2023 00:00:00 +0000

Recently I’ve started using supabase, so I wanted to share the best way (in my opinion) to work locally using docker.

After playing around with a test project, I’ve found that the best way to work locally with supabase is using docker.

The doc is quite limited, so here’s how I’ve done it (and how I’m still using it).

Prerequisites

I’m assuming you already have docker installed on your machine, and you have a test project. It doesn’t need to be much, just a simple project with a few tables.

You project also needs supabase as a dev dependency (or globally installed).

npm install supabase@latest --save-dev

The docker side of things

In order to initialize the configurations for your project, you need to run:

supabase init

It will create a supabase folder with a config.toml file inside. You should not have to change it, but in case you need to, you can change a couple of things:

ports for each service
auth related config (allow signup, …)
external auth providers (github, google, …)

Now that everything is setup, you can start your project with:

supabase start

Once everything is ready, you’ll get access to:

API URL: http://localhost:54321
Database URL: postgresql://postgres:postgres@localhost:54322/postgres
Studio URL: http://localhost:54323
Inbucket URL: http://localhost:54324

Assuming you haven’t changed the default ports in the config.toml file.

The database side of things

What you probably want to do if you’re not starting from scratch, is to use your existing database. So in order to dump your existing database, you need to run:

1
2


supabase login
supabase db dump -f init-file.sql

This will create the first migration file in supabase/migrations and it will be used to init your database when you start or reset it.

You can create a seed.sql file in the supabase folder, if you want to setup the project with existing data (default testing user for instance).

Now when you do some changes on your local db, create a migration file:

supabase db diff -f "migration-name"

Or directly create a migration file, and add the changes you want to apply:

supabase db migrate create -n "migration-name"

If you want to double check everything works (which you probably should), reset your DB:

supabase db reset

The first migration will be run first, then all your migrations will be applied. Once that’s done, it will do the seeding.

Supabase recently updated their doc, so you can find additional info here: Supabase CLI documentation

Let's build a weather app with vite and react - part 3

Mon, 19 Sep 2022 00:00:00 +0000

Now that we have our mapbox integration, we want to open a new page when we click on the city.

Routing

1

npm install --save react-router-dom

Let’s update our main function App in order to create a new route and have two pages:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


function App() {
 return (
 <BrowserRouter>
 <Routes>
 <Route path='/' element={<MainPage />} />
 <Route path='/city' element={<CityPage />} />
 </Routes>
 </BrowserRouter>
 );
}

We are now going to slightly change our list in order to open the new page when you click on the link.

In order to do that, we are going to remove the onClick we added in step 1, and use the Link component from react-router.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


const CityList = (props: CityListProps) => {
 return (
 <ListGroup>
 {props.cities.map((city) => (
 <ListGroup.Item key={city.name} action>
 <Link to={`/city?lat=${city.lat}&lng=${city.lng}`}>{city.name}</Link>
 </ListGroup.Item>
 ))}
 </ListGroup>
 );
};

We are going to only use the latitude and longitude in order to identify the cities. So we only need to pass them as url parameters for our new page.

The reason for that is that we are going to use weatherbit.io API and using lat/lng is the recommanded way (and I believe most of the weather API are doing the same).

Weatherbit API

First thing first, you’re going to need to create an account on weatherbit in order to get an API key. It’s free, takes 2 minutes and doesn’t require a credit card or anything.

Now that it’s done, we are going to only use one endpoint: Current Weather API.

It’s quite straightforward:

1
2


const url = 'https://api.weatherbit.io/v2.0/current?lat=35.7796&lon=-78.6382&key=API_KEY'
const result = await axios.get(url);

Back to our app, we need to get the latitude and longitude from the url, so let’s use react-router:

1
2
3
4
5
6
7
8


import { useLocation } from 'react-router-dom';
// [...]

const location = useLocation();
// location.search will be similar to: ?lat=51.507322&lng=-0.127647
const [latqs, lngqs] = location.search.substring(1).split('&');
const lat = latqs.split('=')[1];
const lng = lngqs.split('=')[1];

You can move that into a separate method (utils) for clarity (I’ve called it getSearchLatLong).

Calling the endpoint

We are going to need to call the endpoint once the component is first mounted and save it in the state. Let’s use useEffect and useState for that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


const CityPage = () => {
 const location = useLocation();
 const [weatherData, setWeatherData] = useState<WeatherData>();

 useEffect(() => {
 const getWeather = async () => {
 const {lat, lng} = getSearchLatLong(location.search)

 const url = `https://api.weatherbit.io/v2.0/current?key=${API_KEY}&lat=${lat}&lon=${lng}`;
 const result = await axios.get(url);

 setWeatherData(result.data.data[0]);
 };
 if (!weatherData) getWeather();
 }, []);

 // ...
}

The API will return data like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
 "data": [
 {
 "wind_cdir": "WSW",
 "rh": 58,
 "pod": "d",
 "lon": -0.1276,
 "pres": 1017.9,
 "timezone": "Europe/London",
 // [...]
 }
 ],
 "count": 1
}

We are only going to save the first observation (we should only receive one anyway).

Displaying the weather

Let’s just display the info we received in a simple way:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


return (
 <Container>
 <NavBar />
 <ViewContainer>
 {weatherData ? (
 <>
 <h1>
 {weatherData.city_name}{' '}
 <img
 src={`https://www.weatherbit.io/static/img/icons/${weatherData.weather.icon}.png`}
 />
 </h1>
 <ul>
 <li>
 <Thermometer /> {weatherData.temp}° (feels like{' '}
 {weatherData.app_temp}°)
 </li>
 <li>
 <Wind /> {weatherData.wind_spd}m/s {weatherData.wind_cdir}
 </li>
 </ul>
 </>
 ) : (<div>Loading...</div>)}
 </ViewContainer>
 </Container>
)

A couple of things to note:

The Thermometer and Wind components are both images from react-bootstrap-icons, so if you want to use it, just install the lib and import the component you want.

Weatherbit does return an icon for the current weather, so we simply are going to use their image. More info can be found here.

In the next tutorial, we will save the cities in the local storage in order to quickly access the ones we’ve looked at already.

Let's build a weather app with vite and react - part 2

Sat, 27 Aug 2022 00:00:00 +0000

If you haven’t already, read part 1 before starting.

Mapbox

We are now going to see how we could search for cities calling the mapbox API. In order to use the API, you’ll need to create an account (it’s free, even if they might ask for a credit card in order to confirm your identity).

Now that you have your account created, get the Default public token from the account page.

In order to call the API, we are going to use axios.

1

npm install --save axios

Saving the user input

Now that we have all the libs we need, we are going to start “saving” what the user is typing in the component state.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// src/pages/MainPage.tsx
const MainPage = () => {
 const [searchText, setSearchText] = useState('')
 // ...
 return (
 { /* ...*/ }
 <Form.Control
 placeholder='Search city'
 onChange={(evt) => setSearchText(evt.target.value)}
 />
 { /* ...*/ }
 )
}

Calling the API

We are going to create a function called callApi this will only call the mapbox endpoint with the value we just saved in the state.

Here’s the documentation for the endpoint we are going to use.

We simply need to call the GET https://api.mapbox.com/geocoding/v5/{endpoint}/{search_text}.json?access_token={access_token}&types={types} endpoint where:

endpoint will be mapbox.places in our case
search_text will be the value we saved in our local state
access_token the token you got from your account page
types will be place because we want to see the cities (see here for more info)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


const callApi = async () => {
 try {
 const access_token = '[your token]'
 const result = await axios.get(`
 https://api.mapbox.com/geocoding/v5/mapbox.places/${searchText}.json?access_token=${access_token}&types=place
 `)
 } catch (error) {
 // if you need to handle any error returned by mapbox
 console.log(error)
 }
}

Once we do get the results, we want to save the cities into a new variable in the component state.

Also we do not need to save everything, so for now we are going to save a name and the GPS location.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


const [cities, setCities] = useState([])
// ...
const callApi = async () => {
 // ...
 setCities(
 result.data.features.map((city: any) => ({
 name: city.place_name,
 lat: city.geometry.coordinates[1],
 lng: city.geometry.coordinates[0],
 }))
 )
 // ...
}

And obviously if we want to display the values from Mapbox rather than the hardcoded list, we need to delete the cities const we created in Part 1.

What we want now is, every time we get a new key stroke, we want to call mapbox and request the list of cities.

For that let’s use useEffect and call our callApi function every time the searchText changes.

1
2
3


useEffect(() => {
 callApi()
},[searchText])

So this is working as expected, every time we type a letter, it will call the mapbox api and returns the list of cities.

Optimisation

This is not very optimised, most of the calls won’t really be needed. When you type a city’s name, you might want to type x letters before it actually does the search, and by doing that not use the entire quote of requests.

In order to fix that, we are going to create a debounce hook, that will call our function only after x milliseconds.

We are going to create a basic one, if you want to cover all scenarios, you might want to use a fancy one from a third party library.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// src/hooks/useDebounce.ts
import { useRef } from 'react'
const useDebounce = () => {
 let timer = useRef(0)
 const debounce = (
 callback: () => void, // the method you want to call
 delay: number // the time in ms
 ) => {
 clearTimeout(timer.current)
 timer.current = setTimeout(() => {
 callback()
 }, delay)
 }
 return { debounce }
}
export default useDebounce

If you’ve never used useRef:

useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.

In our case we don’t want the timer var to be recreated every re render, otherwise it will defeat the purpose of this timer.

So for every key stroke, the method will be called, and the timer will be reset until the timer ends. Once the delay is reached, the callback will be called.

Lets see how we use it in our main component:

1
2
3
4
5
6
7
8
9


// src/pages/MainPage.tsx
const MainPage = () => {
 // ...
 const { debounce } = useDebounce()

 useEffect(() => {
 debounce(callApi, 500)
 }, [searchText])
}

So now when you type, the endpoint will only be called if you stop typing for 500ms.

Next step Part 3

Let's build a weather app with vite and react - part 1

Tue, 16 Aug 2022 00:00:00 +0000

Setup the project

We are going to use vite, with react and everything will be TypeScript.

The plan for this group of tutorials it to learn how to use vite, quickly build a UI with React and Bootstrap, and then add more features on top of it.

Vitejs

For this first part, let’s start by creating the project:

Most of the boilerplate is unnecessary, so we are going to remove the css files and use styled-components instead.

Our folder structure will look like this:

Additional libraries

Let’s install what we need.

1
2


npm run install styled-components --save
npm run install @types/styled-components --save-dev

And while we are at it, let’s install react-bootstrap:

1
2


npm install react-bootstrap bootstrap --save
npm install react-bootstrap-icons --save

Now that we have everything ready, we can start creating the main page, which will contain a search bar and a list of components (cities). Each city will be clickable.

Let’s build the main page

We only need a search bar, and a list of cities. The CityList component will be separate for clarity, and will have a cities property containing the results of our search.

For now we will hardcode it to:

1
2
3
4
5
6


const cities = [
 { name: 'London', lat: '51.507351', lng: '-0.127758' },
 { name: 'New York', lat: '40.730610', lng: '-73.935242' },
 { name: 'Tokyo', lat: '35.689487', lng: '139.691706' },
 { name: 'Paris', lat: '48.856614', lng: '2.352222' },
];

So the main page will look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// src/pages/MainPage.tsx
const MainPage = () => {
 return (
 <ViewContainer>
 <InputGroup className='mb-3'>
 <Form.Control
 placeholder='Search city'
 aria-label='Search city'
 aria-describedby='city'
 />
 <Button variant='outline-primary' id='city'>
 Search
 </Button>
 </InputGroup>
 <CityList cities={cities} />
 </ViewContainer>
 );
};

export default MainPage;

For our CityList component, we will only loop over the cities property and display the name of each city in a ListGroup component.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// src/components/CityList.tsx
const CityList = (props: CityListProps) => {
 const onCityClick = (city: City) => {
 console.log(city);
 };

 return (
 <ListGroup>
 {props.cities.map((city) => (
 <ListGroup.Item
 key={city.name}
 action
 onClick={() => onCityClick(city)}
 >
 <h4>{city.name}</h4>
 </ListGroup.Item>
 ))}
 </ListGroup>
 );
};

export default CityList;

As we are using typescript, we need to type our variables properly, so here are the types used in this component:

1
2


type City = { name: string; lat: string; lng: string };
type CityListProps = { cities: Array<City>; };

Our first part is now done, we do have a project ready with hardcoded data.

In our second part we will see how to search for cities using MapBox.

Next step Part 2

Some fun with Pico-8

Mon, 12 Jul 2021 00:00:00 +0000

Here is an animation I’ve done just to have fun with Pico-8.

GraphQL server example

Sat, 05 Dec 2020 00:00:00 +0000

This is not an in depth tutorial, if you want to follow a step by step guide, have a look at the official documentation here.

The goal of this exercise was for me to investigate/discover how hard/easy it would be to start using GraphQL.

Lets create an Apollo Server with NodeJS so we can play with GraphQL. The server will distribute data retrieved from the nintendo eshop (cause why not ¯\_(ツ)_/¯).

Quick setup

Create the project

1
2


mkdir graphql-server-example
cd graphql-server-example

Initialise NodeJS

1

npm init --yes

Add the dependencies

1

npm install apollo-server-express express

Create the base code

Copy/paste the following into an index.js file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


const express = require('express');
const { ApolloServer, gql } = require('apollo-server-express');
 
const typeDefs = gql`
 type Query {
 hello: String
 }
`;
 
const resolvers = {
 Query: {
 hello: () => 'Hello world!',
 },
};
 
const server = new ApolloServer({ typeDefs, resolvers });
 
const app = express();
server.applyMiddleware({ app });
 
app.listen({ port: 3006 }, () =>
 console.log('Now browse to http://localhost:3006' + server.graphqlPath)
);

Run node index.js and you’ll have access to GraphQL Playground at http://localhost:3006/graphql

Lets play

Lets define our types now. So we need to add a type to our typeDefs:

1
2
3
4
5


type Game {
 id: String
 name: String
 releaseDate: String
}

And we need to change our Query to return a list of games:

1
2
3


type Query {
 games: [Game]!
}

For this to work we obviously need to do a http request in order to get all titles. That’s when we need to define a datasource (doc here).

First install npm install apollo-datasource-rest.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


const { RESTDataSource } = require('apollo-datasource-rest');

class EshopAPI extends RESTDataSource {
 constructor() {
 super();
 this.baseURL = 'https://ec.nintendo.com/api/GB/en/';
 }

 async getAllGames() {
 const { contents } = await this.get('search/sales', {
 "count": 10,
 "offset": 0,
 });
 return Array.isArray(contents) ? contents.map(game => ({
 id: game.id || 0,
 name: game.formal_name,
 releaseDate: game.release_date_on_eshop
 })) : [];
 }
}

module.exports = EshopAPI;

Now go back to the main file to specify it in the ApolloServer constructor:

1
2


const dataSources = () => ({ eshopAPI: new EshopAPI() });
const server = new ApolloServer({ typeDefs, resolvers, dataSources });

And now you can get the list of games:

If you want more GraphQL example, look at the SpaceX tutorial which uses a REST API and a SqlLite DB.

Simple calendar component for React

Fri, 05 Oct 2018 00:00:00 +0000

First here is the repository on github and the demo page.

Why a new component?

Quite simple answer, I needed a calendar that could be customized easily for multiple small projects.

This component handles the display of the calendar, and you can give it a custom element for the cells and/or the title (meaning name of the days). You could also don’t use this custom component and just display the date (for a date picker for example - see below).

The main callback is onDateSelected which will be called - as you would guess - when a cell has been clicked with the date as parameter, so you can do anything, like displaying a modal to create lets say an event.

Quick demo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


function DatePicker() {
 var date = new Date('08/05/2018');
 return (
 <div>
 <div>
 {/* you could add buttons to navigate between months */}
 <h1>August</h1>
 </div>
 <Calendar
 className="minimal-calendar"
 currentMonth={date}
 onDateSelected={date => console.log(date)}
 cellContainerStyle={{
 textAlign: 'center',
 cursor: 'pointer'
 }}
 showMonthName={false}
 titleComponent={CustomTitleCell}
 />
 </div>
 );
}

Create a node module with Haxe

Sat, 04 Mar 2017 00:00:00 +0000

In this post, I’m not going to talk about npm (except for the initialisation part), but about how to code your module with Haxe.

Project setup

First thing to do is to create our npm project.

1

npm init --yes

--yes because I’m lazy and I don’t want to enter the default value for each prompt.

My default package.json file looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
 "name": "test-node-package",
 "version": "1.0.0",
 "description": "",
 "main": "dist/index.js",
 "scripts": {
 "build": "haxe build.hxml",
 "dev": "npm run build -- -debug"
 },
 "keywords": [],
 "author": "RevoluGame",
 "license": "ISC",
 "files": ["dist"]
}

The files parameter will tell npm which file/directory to import while installing the module. I only specify the dist directory, because for a production usage, the Haxe sources are not needed. But still, if you want to publish everything, just forget about the files parameter.

My project looks like:

1
2
3
4
5
6
7


- test-node-package
 - dist
 - index.js
 - src
 - Main.hx
 - package.json
 - build.hxml

The Haxe part

Now that we have our project setup, we can start working on our module.

Let’s say we want to do the following in another project:

1
2


var test = require('test-node-package');
test.foo("world");

In Haxe you will have to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class Main
{
 @:expose("foo")
 public static function foo(bar: String)
 {
 trace('Hello $bar');
 }

 public static function main() {}
}

The @expose metadata will make your method available in Javascript with the name you specified (in our case: foo).

You will probably need to use the nodejs lib, so don’t forget to add it in your build.hxml:

1

-lib hxnodejs

Haxe React - tic tac toe example

Mon, 06 Feb 2017 00:00:00 +0000

I’ve ported the tic-tac-toe example from the react-js documentation to haxe. You can find it here.

What is different:

I’ve changed the event handling in order to use msignal instead of passing a function down to the right component.

I’ve created an History/HistoryItem component to get a cleaner code.

To test it, just checkout the repo, install the dependancies:

haxelib install react
haxelib install msignal

And build the app.

Pico8 tools for haxe

Sun, 23 Oct 2016 00:00:00 +0000

I’m prototyping a lot for the Pico-8 console with haxe (using the hxpico8 library), so in order to help my productivity, I’ve built some tools.

What for?

The first aim was to initialize a new project quickly so you don’t lose time and you can start coding right away.

Once the project is built, the tool will take care of the compilation/deployment. Because I’m using haxe, I can’t code directly into the pico8 console and test right away. So the tool will do it for you by:

compiling your code
backing up the pico8 file used by the console
copying the code (the one generated by the hxpico8 lib) into your p8 file and keeping all graphics/sounds…
copying the file to where the console can read it.

Once that’s done, you just have to reload your game in the Pico8 console, and test it.

For more information, please take a look at the github repository.

Pico-8 debut

Sat, 23 Apr 2016 00:00:00 +0000

Quick post to help you start with pico-8 and haxe.

What is Pico-8 ?

If you never heard of it:

PICO-8 is a fantasy console for making, sharing and playing tiny games and other computer programs. When you turn it on, the machine greets you with a shell for typing in Lua commands and provides simple built-in tools for creating your own cartridges.

For more info, please check the official website.

How to use haxe for pico-8 ?

The easiest way to use haxe, is to use YellowAfterlife’s library in order to build lua code. Here is the Github repository.

I’ve created an empty project (as a gist) which you can find below :

Coloring - post mortem

Sun, 29 Mar 2015 00:00:00 +0000

It took me a while but I finally did it.

I released a new version of my LD31 entry, coloring.

I had to rewrite it completely, because I used my HTML5 framework (AGE) and I wanted to deploy it on mobile. So thanks to haxe and OpenFl I did it without trashing all my old code.

So what’s new ?

Animations
Better score handling with combos
A preview of the colors order and which one can pop
A tutorial, to help the beginners understand the game mechanism
Google play integration for the Android version (leaderboard and trophies)
Lots of bug fixes :)

For the first time, I did integrate unit tests in order to test all (or at least the most) game possibilities. For that I used munit which is really great.

For the leaderboard integration, I’ve used linden-google-play library which is a native extension for OpenFl.

So here you can play the old version, and the new one on itch.io or directly on Google Play:

Enjoy, and let me know what you think.

Coloring - tutorial preview

Thu, 19 Feb 2015 00:00:00 +0000

I have integrated a tutorial which is playable as a little party of Coloring.

How is it working?

Each turn you play, you have to complete a small challenge, receiving explanations on how to:

place a card on the board
merge cards
understand the UI
unblock a color
reach a score

What does it look like?

Now I’ve this system working, I’m thinking: why not add achievements or in game challenges ? Stay tuned :)

Coloring - post LD update

Sun, 08 Feb 2015 00:00:00 +0000

It took me a while, but here is the new version of my last LD entry.

So what’s new so far:

Complete rewrite: I use openfl to be able to deploy it to mobile (only tested on Android so far)
Animations
New score system with combos (based on the Fibonacci sequence)
Better merge system
User Interface (based on Kenney’s assets)

For a better understanding, here are some screenshots :

Stay tuned for the more information :)

How to change colors with a smoothly effect

Sat, 13 Dec 2014 00:00:00 +0000

For the last Ludum Dare, I wanted to have a nice effect on the background of my puzzle game in order to change the color based on the action on the board.

My game is in JavaScript, but except the background property, it should work on other platform too.

So, what do we need ?

First we have to get the initial color (color1) and the new one (color2). In order to change the color smoothly, we will do it with a Timer object.

1
2
3
4
5
6


// définition de la classe
function changeColor(
pElem: js.html.Element,
pInitialColor: RGB,
pEndColor: RGB
){}

Here is the RGB typedef:

1
2
3
4
5


typedef RGB = {
var r : Int;
var g : Int;
var b : Int;
}

The first step is the calculate the distance between those two colors (all methods are based on the RGB type):

1
2
3
4
5


var distance = {
r: Math.round(Math.abs(color1.r - color2.r)),
g: Math.round(Math.abs(color1.g - color2.g)),
b: Math.round(Math.abs(color1.b - color2.b))
}

Now that we have the difference, we have to calculate the value that will determine how the color will change between each step:

1
2
3
4
5
6
7
8
9


var incR = Std.int( Math.abs( Math.floor(distance.r / INCREMENT_VALUE) ) );
var incG = Std.int( Math.abs( Math.floor(distance.g / INCREMENT_VALUE) ) );
var incB = Std.int( Math.abs( Math.floor(distance.b / INCREMENT_VALUE) ) );

var increment = {
r: incR == 0 ? 1 : incR,
g: incG == 0 ? 1 : incG,
b: incB == 0 ? 1 : incB
};

The INCREMENT_VALUE value allows use to determine how we want the effect to change. The higher the value is, the quicker the effect will be.

I’ve set it to 100.

Now we have to calculate the new color :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


if (color1.r > color2.r)
{
color1.r -= increment.r;
if (color1.r <= color2.r) // if we've reach the right color
increment.r = 0;
}
else
{
color1.r += increment.r;
if (color1.r >= color2.r) // if we've reach the right color
increment.r = 0;
}

And same thing for each tone.

I’ll now add this step to the Timer object.

I’m using the Timer class in order to have a cross platform method. But you can use any kind of listener or Signal.

1
2
3
4
5


var timer = new haxe.Timer(Math.round(1000 / (INCREMENT_VALUE/2)))
timer.run = function()
{
// [...]
}

In this loop, you’ll have to change the property of your object.

For example in JavaScript you’ll have :

1

pElem.style.background = rgb2hex(currentColor);

Where rgb2hex transform the RGB object in hexa :

1
2
3
4
5
6
7


private static function rgb2hex(color: RGB): String
{
return "#" +
StringTools.hex(color.r, 2) +
StringTools.hex(color.g, 2) +
StringTools.hex(color.b, 2);
}

Here is an example :

LD31 - Game submitted

Sun, 07 Dec 2014 00:00:00 +0000

So here it is, my LD 31 entry is named COLORING.

It’s a simple puzzle game where you have to align at least two cards of the same color to unlock the next one. The game ends when there is no place left, and of course the main goal is to have the best score ;)

Check it out here.

Here are screenshots:

Please let me know what you think about this game!

Ludum Dare 31 - first day

Sat, 06 Dec 2014 00:00:00 +0000

So this time the theme is Entire Game on One Screen.

Actually, I’m not really inspired by this theme (probably because you can do almost everything :D).

After the first day I’ve made a puzzle game … but I’m not really happy with it, so we’ll see tomorrow if I try something else … or not.

You can play the current version here.

LudumDare 30 : results

Tue, 16 Sep 2014 00:00:00 +0000

Here are the results for my LD30 entry 2LOVERS.

Global results

Ratings

That’s my best entry so far.

Thanks everyone ! and again, great job to all participants.

LudumDare 30: 2LOVERS - Post mortem

Mon, 25 Aug 2014 00:00:00 +0000

After quite some time since the last time I’ve joined the Ludum Dare, I’ve submitted my game according to the theme : Connected Worlds.

The game is quite simple, lovers have to collect all the to open the gate to the next level. In some levels, you’ll find switches that can open one or more gates when one of the player stands on it and of course, be carreful of the deadly traps .

What went right

The theme: I had a few ideas in mind
The tools: when you’re using tools you know, you don’t have to lose time that you don’t have ;)
Not enough levels for a complete game, but enough for a 48 hours game

What I can improve

Work a little longer, I’ve tried to have a “normal” weekend at home (normal you said??)

And the usual

The design: I need to work on that
No sound: so next time maybe I’ll try if I have time and some motivation
I had some difficulties to find cool levels

You can play it here.

LudumDare 30 : Day 1

Sat, 23 Aug 2014 19:00:00 +0000

So far, I’m sort of happy with my idea.

I’m using Tiled for the level design.

There is still a lot to do.

For now I’ve implemented those features :

Players can die (by falling into traps)
Collecting hearts
Opening of the gate when all the hearts are collected
Going to the next level when both players have reached the gate

LudumDare 30 : I'm in !

Sat, 23 Aug 2014 08:00:00 +0000

It’s been quite some times since my last participation (more than a year actually).

So let’s get started ! The theme is : Connected worlds

For those of you that don’t know what the rules are, please check it out here.

My tools

Haxe + AGE
Gimp

I’ll push my code to github.

My idea

The player controls the two heros.

The goal for both heros is to go to the other world by picking up all items to open the gate.

Jawbone UP analyzer application update

Fri, 15 Aug 2014 00:00:00 +0000

Quick update

The application is now live, you can test it if you have a Jawbone UP account (and the Jawbone wristband of course).

So now the application lets your track your 10 last workouts :

For now it only works on running activities. It lets you track the number of kilometers you’ve run, and for each workout the speed average.

The app is accessible here.

Authorization

To access the application you’ll need to authorize the following :

Don’t be afraid, there is no data stored on this app.

This application is still under development

Jawbone UP analyzer - Work in progress

Sun, 06 Jul 2014 00:00:00 +0000

I’ve worked all week end on a personal project based on the Jawbone UP API.

What’s the objective ?

Jawbone created a great phone app, easy to use and quite beautiful. But I want to let the user analyze data with another experience. Not only check data per day, but to be able to find patterns for bad/good habits.

Here is the first feature, that analyzes moves and sleeps through a heat map (using cal-heatmap) :

Of course, all classical vizualiser are implemented too :

With a simple look, you can see if your objective is filled, and how was your night through a progress bar (light sleep, sound sleep, awake time), or through the Jawbone graph.

I’ve already implemented the same thing for sleeps and workouts.

What’s next ?

I need to implement research for a specific date (if you need to check for specific data) and some extra cool features… Stay tuned for that :)

No availability date for now.

Chromecast : first impressions

Sun, 23 Mar 2014 00:00:00 +0000

At last, the Chromecast is available in Europe. You can find it on the play store or in physical stores for 35€ (cheap, right?).

What is Chromecast ?

Chromecast is a thumb-sized media streaming device that plugs into the HDMI port on your TV. Set it up with a simple mobile app, then send your favorite online shows, movies, music and more to your TV using your smartphone, tablet or laptop. From the chromecast website

How does it work ?

It’s really simple, you just have to plug the hdmi key into your tv, and go to chromecast.com/setup to setup the key (you can use a mobile or your desktop to do that). And that’s it.

Now go to a compatible application, click on the icon and enjoy.

The only problem is that you have to be connected on the same network, you can’t just broadcast a content to the key (I was thinking about displaying a presentation from my tablet to a TV, but it’s impossible to do so without any network…).

The existing apps

So… In France, there are not much apps for now (the chromecast has only been available for a few days). But you can use all of google’s app (music - movies), France Television’s catch up app, SFR, and that’s pretty much it (for the officials apps). CanalPlay and probably Netflix will come soon.

You can find others by searching “chromecast” in the play store.

Let’s code

A few days ago, Google released another update for the Chromecast SDK (check out the release note).

I’ve tested the Chrome Sender API, and it’s pretty cool. You just have to install the google cast plugin into Chrome, and start a new app.

As usual, I’m coding with Haxe ;)

I’ve started to create all external classes, it’s available on Github.

Here is a basic initialization (don’t forget to activate the Google Cast plugin) :

1
2
3
4


var sessionRequest = new SessionRequest(Media.DEFAULT_MEDIA_RECEIVER_APP_ID);
var apiConfig = new ApiConfig(sessionRequest, sessionListener, receiverListener);

Chromecast.initialize(apiConfig, onInitSuccess, onError);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


function onInitSuccess(){
 trace('init success');
}

function onError(){
 trace('init error');
}

function sessionListener(s: Session) {
 session = s;
 trace('New session ID: ' + session.sessionId);
}

function receiverListener(pStatus: String) {
 if(pStatus == ReceiverAvailability.AVAILABLE)
 trace('receiver available');
}

Now, if you want to broadcast something :

1
2
3


var mediaInfo = new MediaInfo("http://commondatastorage.googleapis.com/gtv-videos-bucket/big_buck_bunny_1080p.mp4", "video/mpeg");
var request = new LoadRequest(mediaInfo);
session.loadMedia(request, onMediaDiscovered, onMediaError);

1
2
3
4
5
6
7


function onMediaDiscovered(media: Media){
 trace("new media session ID:" + media.mediaSessionId );
}

function onMediaError(e:Dynamic){
 trace(e);
}

With these few lines, you can create a video player from Chrome, and displaying the content to your TV.

Check out the documentation and have fun!

1GAM updates

Sat, 08 Feb 2014 00:00:00 +0000

After some hours of work, here is the new features for this second beta :

Up to 4 players (1 keyboard and 3 game pads, or 4 game pads)
Desktop app with full screen support (thanks to node-webkit)
New weapons
Shotgun
Magnum
Machine gun
Double gun
Each weapon has limited ammunition
New user interface
Monsters has now lives

What’s next

More game design

Before playing, here are some instructions

Use the mouse to navigate in the menu
Each player needs to press start (or enter) for his controller, if the same player re press the same pad’s button, then it will go back to the previous player’s controller selection
Use the keyboard to select a level
Keyboard : arrow keys to move, SPACE to shoot
Game pad : left joystick to move, A - cross to jump, X - square to shoot

Download

Download the game to test it, and let me know what you think about it. Keep in mind that it’s a beta version ;)

You can play it here.

February's 1GAM

Sun, 02 Feb 2014 00:00:00 +0000

My new job has made me realize how much I miss coding games. So this weekend, I’ve decided to start on an old idea of mine for the February’s OneGameAMonth. Nothing really new actually, but I need to (re)start from somewhere.

The concept

It’s mostly a super crate box like game. You are alone in an arena, and you have to fight until you die.

Power ups and weapons are spawning randomly in the level. The player will be able to carry only one weapon, so if you take a weapon, you’ll loose the previous one. But you can’t use a weapon indefinitely, each weapon has a number of shots (except for the default gun). So be careful with your choices.

The goal is to obtain the better score you can. You need to beat a score to unlock the next level.

I would like to have a multi-player local mode, where you are both (or maybe 1 to 4 players?) in the same arena, and you have to get the better score. You can’t directly kill the other players, but you can help them die.

The tools

As always, I’ve been using :

Haxe with my personal html5 engine AGE
Tiled
Kenney’s Platformer art assets DELUXE

The prototype

Right now, what’s working?

Movements - Gravity - Collisions detection
You can use the XBOX 360 and PS3 controllers (and probably others) and the keyboard
Monsters spawns
Power ups’ boxes spawns (but power ups are not implemented yet)
Scores (Right now, you can’t really die, and since monsters are indefinitely spawning from the top of the level, you could have a huge score :D)

So, what’s next?

More monsters
More weapons
More levels
Multi-players mode

Here is a screenshot:

You can play it here.

Stay tuned…

Tools for better productivity

Sun, 05 Jan 2014 00:00:00 +0000

It’s been a while since my last post. For my defense, I’ve started a new job since September, I’m now a project manager on a Digital Cinema project (see the official press release).

For the first post of the year, I want to give some feedback on tools to increase productivity on projects.

Email : the worst thing ever

When you receive at least 100 emails per day… it just becomes really complicated to keep track of everything without missing a conversation or just forget to follow/reply to one.

Sure, Outlook (I’m using it at work…) has a task manager, but I don’t find it really useful. For example, you can’t use it with your team; someone else can create a task for you, but you can’t share one you’ve created… so its use is limited.

It’s really easy to lose an email, maybe one you’ve read on your mobile, and then forgot to answer…

So the question is “How to keep track of important conversations” ? My answer is with Evernote.

Evernote : keep track of everything

For those who don’t know what Evernote is:

Evernote makes it easy to remember things big and small from your everyday life using your computer, phone, tablet and the web.

In my case, I’m using it to take notes during meetings and to save important mails (questions / remarks from clients). It’s easier to search for information through mails when they are well organized and synced between all your devices. You can create reminders if you want to be sure not to forget something.

If during a meeting someone draw a diagram, just take a picture and annotate it with Skitch. You can do the same on a web page, by using the web clipper (from your web browser). And of course when you are working on PDF documents, you can also annotate them.

Another useful functionality: you can use Evernote to save contact cards (with Evernote Hello).

But the part I don’t like in Evernote is the collaborative part.

For your information, this functionality is part of the premium package.

If you start using Evernote with shared notes, you will have a lot of conflicts into your notes, and that’s really frustrating. Actually, there is a web-based app which takes care of that: LiveMinutes.

But to share notes, all the members of your team must have a premium account, which is not always the case…

Trello : collaborate with your team

According to the website

Trello is the fastest, easiest way to organize anything, from your day-to-day work, to a favorite side project, to your greatest life plans.

To clarify what this tool is, you have boards divided into lists, divided into cards. It’s in those cards where you add your tasks, ideas, …

What a Trello board looks like :

This tool is really useful when used with a team. You can assign people to tasks, add comments on specific cards, add a deadline…

You can use it as a scrum board or simply as a personal todo list.

Just create cards, drag & drop each one of them into the right list and use labels to distinguish cards. Simple, efficient and intuitive.

The best thing is that this tool is free and completely free. Of course, give a fee if it helps your journey, but if you can’t, you can always use it. There is a premium package, but with gadget options (from my point of view).

Mural.ly : order your brain

Mural.ly is an online whiteboard designed to visually organize ideas and collaborate in a playful way.

If you are already using Evernote, just use your notes on murral.ly boards to organize ideas, and brainstorm with your team.

If you want to add a link, just drag and drop it on the wall to display a capture of the web page. Create connections between ideas, and create layers to demonstrate your ideas (via the presentation mode) to your team and let them participate. Add stickers with annotations, comment ideas…

Everything is available to help you organize your brain for your projects.

LudumDare 27: games selection

Tue, 27 Aug 2013 00:00:00 +0000

Since I couldn’t take part to the Ludum Dare #27, I’ve selected some games I liked. There always is plenty of great concepts made during this few hours, I can’t play and speak about all of them, so I’ve selected 5 games that I like more (a least so far) :

The theme was 10 seconds.

The Village of Lost Time by EpaceGames

You play a Native American trying to save his daughter by destroying evil totems. Each turn last 10 seconds, and is repeated in the next one. For example, the gatherer is going to take javelins in the 1st round, in the 2nd round, the same action will be repeated, and you will have to play with another person. Three class are available, depending of the resources you’ve collected. The concept is great and so is the graphic style. At first, it’s a little bit hard to understand what has to be done, but after that, it’s just fun.

The Village of Lost Time by EpaceGames[/caption]

Subject 18120 by deammer

A 2D shoot them up, between super crate box and super puzzle platformer. You play a rat that just escaped a research lab, and wants revenge. The speech is classic, but the realization is good. The pixel art style is really great too. Nothing to say about controls. Great job ! There are many sorts of weapons with different effects given randomly, everything is here to have some fun. You only have drugs for 10 seconds, after that, your life is going to be sucked down.

Subject 18120 by deammer

Proletarian Ninja X by Deepnight

Deepnight is one of these guys that always end up with a great game at each Ludum Dare. Even if he says he gives up 24 hours before the end :D

#ld48 Gave up :( — Sébastien Bénard (@deepnightfr) August 24, 2013

In this game, you are going to control a ninja ; you have to destroy every enemy but with 10 seconds on each contract, you have to hurry. Controls are fun, the graphic style is, as usual, nice, with the same pixel effect as the older games. The levels are fun and the difficulty increases, so it’s fun to play.

Proletarian Ninja X by Deepnight

Potato Lagoon by Rezoner

It’s a shoot them up with vegetables and butterflies … okay … that saying, each level changes after 10 seconds. The graphic style is cute and as usual, the music is great (really great). You can find upgrades to increase fire power, extra life, … The only problem is that I don’t really like controls, I find them… weird I think, maybe they fit for mobile devices, I haven’t tested the Android version.

Potato Lagoon by Rezoner

Gas and Air! by tripleVisionGames

You control an hot-air balloon, and you have only 10 seconds of gas left, use it carefully to go as far as you can. The graphic style is really cool, sounds are great. For sure, the theme fits but there’s nothing new. The realization is great, there is power up, the game is neither too much or not enough difficult, just classic and well done.

Gas and Air! by tripleVisionGames

SMS Racing by hlink

I know, it’s now the sixth game, but consider it as a bonus :D Build on top of the Unity racing demo, SMS Racing lets you send small messages while driving. The goal is to complete a lap while texting messages each 10 seconds. I’ve selected this game just because of its message: it’s dangerous to use your phone when driving !.

First steps with Ripple

Sat, 13 Jul 2013 00:00:00 +0000

A few months ago, I discovered a really cool plugin for chrome. It’s Ripple, an open source project hosted by Apache to emulate mobile devices into you browser (Chrome actually …). But I’ve never really had the time (or the project) to test it.

So here it is !

Just as a reminder, I'm using Haxe for the javascript part. And the last Phonegap version (2.9.0).

Installation

First, you have to install the chrome plugin.

Now, create a new phonegap project :

1

create /path/to/dir/MyProject com.you.myproject MyProject

Create your application (or just test with the default Phonegap app) :

1
2
3
4
5
6
7
8
9


class Main {
 static function main() {
 js.Browser.document.addEventListener( "deviceready", function(e) {
 new JQuery(function() {
 trace("hello world");
 });
 });
 }
}

Go to your working directory and start the server :

1
2


cd /path/to/dir/MyProject
nekotools server

Go to http://emulate.phonegap.com?url=localhost:2000&platform=phonegap and enable the plugin if it isn’t.

Be sure to have the 2.0.0 version in the platform panel (on the left) otherwise, it will not work.

It can really save you time, because deploy to a real device is much longer, and more difficult to debug. So if you use the chrome developer tools… you will not let go this plugin! But it sure doesn’t replace a real device for testing ;)

[FR] L'Open Data : un service pour tous

Sun, 02 Jun 2013 00:00:00 +0000

Malgré les efforts de l’État (etalab, data.gouv.fr), nous pouvons observer une grande disparité entre les initiatives des différentes communes françaises concernant l’open data.

De grandes villes ouvrent des portails accessibles par tous et mis à jour très régulièrement (pour ne pas tous les citer, on peut trouver Nantes, Montpellier, Toulouse et même Paris) alors que d’autres sont relativement en retard (non non, je ne parlerai pas de Lille…).

De mon point de vue, le partage de données publiques peut être d’une très grande utilité pour la collectivité. Des particuliers, voire même des entreprises, développent, depuis une initiative personnelle ou par le biais de concours (Dev’Kings, Dataconnexions…), des applications qui peuvent rendre la vie de tous les jours beaucoup plus simple.

Par exemple via des applications indiquant les emplacements de parking, les vélos en libre service, les transports en commun, etc. (la SNCF, la RATP, ou JC Decaux ayant ouvert leurs données récemment). Voire des applications touristiques, mais encore et surtout des statistiques.

Par exemple, voici une petite démo de ce qui peut être fait rapidement et qui pourrait être très utile dans certains cas, même si bien sûr je ne vous souhaite pas que ce genre de service vous soit un jour utile ;). J’ai décidé de prendre les informations concernant les défibrillateurs de la ville de Montpellier et de les afficher sur une carte, en y ajoutant la géolocalisation de l’utilisateur. Service tout bête qui ne m’a pas pris plus d’une heure (en comptant le nettoyage des données) pour afficher les positions des défibrillateurs sur une carte (via Leaflet).

Et pourquoi ne pas en faire une application mobile, et en y ajoutant un guide sur l’utilisation d’un défibrillateur, et un bouton pour appeler rapidement les secours ? Voilà ce qu’il serait possible de faire, simplement en partant d’une liste de coordonnées GPS mis à disposition par la ville de Montpellier.

Pour prendre un exemple concret, récemment j’ai développé une application permettant aux utilisateurs du réseau V’Lille de vérifier la disponibilité de vélos proches de leur position (Lille Aux Vélos). Il m’a été difficile de me procurer les informations dont j’avais besoin. A aucun moment Transpole ne fait mention de son API ni même de ses données alors que tout est accessible sans restrictions…

Pourquoi développer cette application me direz-vous ? Pour la simple et bonne raison que Transpole a jugé utile de développer une application sur iPhone, mais de simplement faire une application qui contient le site mobile (lent et pas vraiment utilisable) sur Android… Et puis, comme on dit : “on n’est jamais mieux servi que par soi-même” ;).

Alors on peut se demander pourquoi de grandes villes ou grands groupes ne font pas un petit effort qui irait certainement dans leur sens, en permettant à d’autres personnes de développer des services annexes aux leurs et donc de faciliter la vie de tous les jours à tant de gens …

F5 if nothing shows

Trouver ma position (si inaccessible le centre de Montpellier est utilisé comme référence)
Trouver le défibrillateur le plus proche

Screenshot saturday - Planets experiment

Thu, 30 May 2013 00:00:00 +0000

So now, it’s officially the 1PAM (one prototype a month).

It’s a simple conquest game, my first targeting HTML5. So it was more an excuse to update my game engine, so that it can compile to js.

AGE is still an Haxe framework, but now NME is not required anymore. The engine will be compatible Flash (again) soon.

Here is the link, if you want to test it.

Ludum Dare 26 : Post mortem

Mon, 29 Apr 2013 00:00:00 +0000

This weekend took place the 26th edition of the Ludum Dare event. So as I was busy for half the weekend, I decided to enter the contest, but with only 12 hours to make a game.

This time, with my coworkers from Atelier 801, we decided to work together, not on the same game, but at the same place, the company’s headquarters. It was really a good experience, and it helped me to focus on working.

I’ve used Haxe to make a flash game.

You can find the game here : What the fish !! and the vote form here.

How I prepared

For each theme in the final theme voting round, I’ve tried to come with a game concept. So before the beginning of the contest, I had lots of ideas.
I went to bed early the day before, so I was able to get up in the early morning.

What went right

I found a really simple (minimalist) game idea, where you have to kill fishing boats with potatoes (wait… what??). And of course, do not kill the pink salmons ;)
I made all the sprites really quickly, because I didn’t want to lose time on this.
I make flash games for a living, so the code is not really what’s bothering me the most.
Working with other people also participating to the Ludum Dare contest sets up a really nice working atmosphere.

What could have been better

The theme :D, because I had other (great?) ideas, but ideas that didn’t really fit with this theme
To have a little more time…

Pull-to-refresh with Phonegap

Sat, 06 Apr 2013 00:00:00 +0000

It’s been a while since my last post. I’ve been working on some projects that are quite time-consuming; that’s why I can’t (despite having 3 prototypes) work much longer on games for the one game a month challenge.

For one of my apps using Phonegap and JQuery Mobile, I needed a list with the “pull to refresh” fonctionnality. After somes searchs and tests, I ended up using the Jquery Mobile iscrollview widget, that works pretty well.

So here is a quick start for this feature.

This widget is a JQueryMobile version of the iScroll widget.

According to the autor website :

The script development began because mobile webkit (on iPhone, iPad, Android) does not provide a native way to scroll content inside a fixed width/height element.

By the way, this plugin allows you to use a lot of features like :

Pinch / Zoom
Pull up/down to refresh
Improved speed and momentum
Snap to element
Customizable scrollbars

The code

Assuming that you have a Phonegap project already initialized, you need to add to your main html file :

1
2
3
4
5


<link rel="stylesheet" href="css/jquery.mobile.iscrollview.css" />
<link rel="stylesheet" href="css/jquery.mobile.iscrollview-pull.css" />

<script src="js/iscroll.js" type="text/javascript"></script>
<script src="js/jquery.mobile.iscrollview.js" type="text/javascript"></script>

And a page like this :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


<div data-role="page" id="main" data-position="fixed">
 <div data-role="header">
 <h1>Test iScroll</h1>
 </div>
 <div data-iscroll="" data-role="content" class="iscroll-wrapper">
 <div class="iscroll-pulldown">
 <span class="iscroll-pull-icon"></span>
 <span class="iscroll-pull-label"></span>
 </div>
 <ul data-role="listview">
 <li>Item 1 culpa aut nam qui</li>
 <li>Item 2 minima quam temporibus quidem</li>
 <li>Item 3 commodi sint facilis numquam</li>
 </ul>
 <div class="iscroll-pullup">
 <span class="iscroll-pull-icon"></span>
 <span class="iscroll-pull-label"></span>
 </div>
 </div>
</div>

The “list-view” inside the “data-iscroll” tag will now have the “pull to refresh” feature. If you need to do some actions (like refresh the content, …) you have to listen for some events :

1
2
3
4
5
6
7
8
9


var document = untyped __js__("document");
document.addEventListener("deviceready", function(e) {
 new JQuery(function() {
 new JQuery(".iscroll-wrapper").bind({
 iscroll_onpulldown: onPullDown,
 iscroll_onpullup: onPullUp
 });
 });
});

Here is the complete list of events for the pull-to-refresh feature :

iscroll_onpulldown
iscroll_onpullup
iscroll_onpulldownreset
iscroll_onpulldownpulled
iscroll_onpulldownloading
iscroll_onpullupreset
iscroll_onpulluppulled
iscroll_onpulluploading

The event callbacks takes two arguments :

1

onPullDown(event: Event, data: Dynamic):Void

The event argument is a basic JQuery Event. The data argument has only one member : iscrollview, that is the reference to the iscrollview object that made the callback.

And after that, if you want to hide the top or bottom part, just refresh the componant :

1

data.iscrollview.refresh();

Customization

You can also custom the pull label text. All these options has default values, but you can custom them all :

pullDownResetText (default: “Pull down to refresh…”)
pullDownPulledText (default: “Release to refresh…”)
pullDownLoadingText (default: “Loading…”)
pullUpResetText (default: “Pull up to refresh…”)
pullUpPulledText (default: “Release to refresh…”)
pullUpLoadingText (default: “Loading…”)

If you want to change those values from the html, just set the correct attribute :

1

<span class="iscroll-pull-label" data-iscroll-loading-text="Custom loading text" data-iscroll-pulled-text="Custom pulled text">Custom reset text</span>

For more informations, here is the place you want to go.

One Game A Month Challenge

Tue, 01 Jan 2013 00:00:00 +0000

What is the ‘one game a month’ challenge ?

The goal is to publish at least one game by month for a year (so 12 games … if the calendar has not changed since the last time I checked).

Why ?

In my (short) indie developper’s life, finishing games is like the most difficult thing to do, mainly because of the lack of motivation. On my computer, I have a lot of prototypes … but not a real game (by real, I mean finished).
So I hope this challenge will help motivating me, by showing my work to the whole community, and will allow me to improve my skills.

I’m not really a good 2D artist, but I’m really trying to upgrade this skill, so that I can make games without being limited by the design. I am aware that I’m not going to become a real artist, but if I can make basic pixel assets, it will be a fantastic move !

Earn XP for doing what you love: making games!

This challenge has an XP system based on the achievements you won. All this system is juste for fun, there is no gain, just motivation and pride (at least if games are published ^^).

My profile page : onegameamonth.com/RevoluGame.

Let’s start with the first game !!

A quick start with nape and tilelayer

Wed, 26 Dec 2012 00:00:00 +0000

Recently, I started a mobile game with NME, and I wanted to give a try to nape. Since I’ve seen the NME’s runnermark, I’ve wanted to try the tilelayer library too. So why not dot it at the same time !

Overall view

Nape

This month was annonced the 2.0 version of nape. Nape is an open-source Haxe/AS3 physics engine that lets you do cross platform applications. It’s fast and powerful (actually I prefer nape over box2d, it’s much easier to use, and really fast). See by yourself : http://napephys.com/samples.html.

Just download it through haxelib :

1

haxelib install nape

Tilelayer

To quote the github description :

A lightweight and very optimized wrapper over NME’s powerful but lowlevel ‘drawTiles’ which offers the best rendering performance (ie. batching) on native platforms.

To install the haxelib version :

1

haxelib install tilelayer

Simple implementation

So now to use these two great libraries :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import nape.phys.Body;
import aze.display.TileSprite;

class Entity
{
 // The tilelayer's sprite
 public var sprite(default, null): TileSprite;
 // The nape's body
 public var body(default, null) : Body;

 public function new(){}
	
 /**
 * Update the positions and the rotation
 **/
 public function update()
 {
 if(sprite != null && body != null)
 {
 sprite.x = body.position.x;
 sprite.y = body.position.y;
 sprite.rotation = body.rotation;
 }
 }
}

All the entities will have to be updated on each frame, as well as the nape’s space and the layer :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


class Main 
{
 var _space : Space;
 var _layer : TileLayer;
 var _entities : List<Entity>;

 public function new() 
 {
 var tilesheet = new SparrowTilesheet(
 Assets.getBitmapData("assets/spritesheet.png"), 
 Assets.getText("assets/spritesheet.xml")
 );
 _layer = new TileLayer(tilesheet);
 addChild(_layer.view);

 _space = new Space( new Vec2(0, 600));
 }

 public function update()
 {
 _space.step(1/60);
 for(entity in _entities)
 entity.update();
 _layer.render();
 }
}

Now to define a simple rectangular entity :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class Box extends Entity
{
 public function new(pSpace: Space)
 {
 super();

 // Nape's data
 body = new Body(BodyType.DYNAMIC);
 body.shapes.add(new Polygon(Polygon.box(50, 50)));
 body.position.setxy(10, 10);
 body.space = pSpace;
 
 sprite = new TileSprite('box');
 }
}

And simply add it to the stage :

1
2
3


var box = new Box(_space);
_entities.add(box);
_layer.addChild( box.sprite );

AGE - How to support physic engines

Sat, 17 Nov 2012 00:00:00 +0000

In the previous post, we have seen how to use the Box2D support into the AGE engine. Now I just want to show you how simple it is to add a new framework/engine support.

For example, we are going to add the Nape support.

For those of you who don’t know, Nape is a Haxe/AS3 physics engine. Since Nape is really close to Box2D, it will be simple to understand how box2d has been added to AGE.

The behavior

Since AGE is based on a behaviors system, we are just going to create a new behavior, that we will call NapeMovementBehavior :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


class NapeMovementBehavior implements IBehavior
{
 private var _entity : BasicEntity;
 public var enabled(default, null) : Bool;

 public function update():Void {}
 
 public function enable()
 {
	enabled = true;
 }
 
 public function disable()
 {
	enabled = false;
 }

 public function destroy():Void {}
}

Now we are going to initialize the data needed by Nape for the behavior’s entity :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


private var _body : Body;
public static var world : Space;
public function new(pEntity: BasicEntity, pDynamic:Bool)
{
 if(world == null)
 world = new Space( new Vec2(0, 500) );

 _body = new Body( (pDynamic ? BodyType.DYNAMIC : BodyType.STATIC), 
 new Vec2(pEntity.x + pEntity.halfWidth, pEntity.y + pEntity.halfHeight)
 );
	 
 var block:Polygon = new Polygon(Polygon.box(pEntity.width,pEntity.height));
	 
 _body.shapes.add(block);
 _body.align();
				
 _body.space = world;
	
 _entity = pEntity;
}

If you need more information on how Nape is working, go check the documentation. So for now, we have a basic entity initialized for working into Nape.

We have to update the entity position into the game based on the Nape’s one :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public function update():Void
{
 #if cpp
 _entity.x = _body.position.x;
 _entity.y = _body.position.y;
 #else
 _entity.x = _body.position.x - _entity.halfWidth;
 _entity.y = _body.position.y - _entity.halfHeight;
 #end
 
 _entity.rotation = _body.rotation * 57.2957795;
}

There is some differences between c++ and flash: with the flash renderer, we must have the center point at the top left position (for now).

Now the destroy function (called after the behavior has been removed) :

1
2
3
4


public function destroy():Void
{
 world.bodies.remove(_body);
}

If you have noticed, the world variable is static, because we have to update it on each frame. So to keep the behaviors system intact, we are going to use the BehaviorsManager :

1
2
3
4
5
6
7
8
9


public function new(pEntity: BasicEntity, pDynamic:Bool)
{
 if(world == null)
 { 
	world = new Space( new Vec2(0, 500) ); 
 BehaviorsManager.getInstance().registerUpdater(globalUpdate);
 }
 // [...]
}

Now the globalUpdate() function is going to be called on each frame :

1
2
3
4


public function globalUpdate():Void
{
 world.step(1/30, 10, 10);
}

How to use it ?

Now to use this behavior with an entity, just add the NapeMovementBehavior to the behaviors list :

1
2
3
4


var e : BasicEntity = new BasicEntity(0, 0);
e.makeGraphic(32, 32, 0xFFFF0000); // create a rectangle
e.addBehavior( new NapeMovementBehavior(e, true) ); // add the behavior
add(e); // add the entity to the game

Here is a quick demo (drag the blocks) :

You can see the NapeMovementBehavior class here and the NapeEntity class here.

AGE - Box2D support

Sat, 10 Nov 2012 00:00:00 +0000

Since Box2D is one of the most used physics engine, I’ve started to implement it into the AGE game engine.

I’ve used the box2d version from haxelib, so don’t forget to add the following to your nmml file :

1

<haxelib name="box2d" />

I’ve implemented it with the behaviors system. So now we have a Box2dEntity that has a special Behavior (Box2dMovementBehavior) which initialize and update all the Box2D stuff.

For example, to define an entity :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import com.revolugame.age.display.Box2dEntity;

class Block extends Box2dEntity
{
 public function new (pX: Int, pY: Int)
 {
 super(pX, pY);
 makeGraphic(32, 32, 0xFF000000);
 initBox2dStuff(30, true, 0, 0, 0);
// ^ friction
// ^ restitution
// ^ density
// ^ if the entity is dynamic
// ^ conversion meters to pixels
 }
}

1

add(new Block(10, 50));

And that’s it !

The Box2D support works with Flash and C++ but needs some optimization for now.

Here is a quick example (click on the blocks to remove them) :

You can also apply a force or an impulse on your entity :

1
2


_b2dBehavior.applyImpulse(1, 2); // x, y
_b2dBehavior.applyForce(1, 2); // x, y

Another example (click on the oranges to apply a random impulse) :

For more information on Box2D, check out the flash documentation.

Case study: mobile app with Haxe

Sat, 28 Jul 2012 00:00:00 +0000

Problematic

I needed to look for the best technologies to use for a cross platform mobile application. I need to develop a simple application, linked with all Android/Iphone/Windows tools like the calendar, contacts, etc… and of course, the application must have a simple and integrated UI (as close as possible to the OS).

My first thought was to give NME a try for a non game application.

NME

NME is my favorite tool for a game or a big application (RIA) that needs good performances (when you compile, it produces C++ code and not Java or objective-C).

NME is not 100% integrated with all the OS. You can do it, but you have to code specific parts for each OS, and you have to know C++ and that’s not my case right now.

And finally, there is no simple UI framework that can be used with a cross platform mobile app (and for a commercial project, I’m not comfortable with using a young library like Cocktail or HaxeAsWing).

I’ve heard about PhoneGap, a simple tool that lets you code JavaScript and deploy it to all the most used mobile OS platforms. So why not give it a try?

What is PhoneGap ?

Developing with PhoneGap gives you the freedom to create mobile applications for iOS, Android, Blackberry, Windows Phone, Palm WebOS, Bada and Symbian using the web code you know and love: HTML, CSS and Javascript.

How is PhoneGap working?

To deploy to a specific platform, you are going to need the SDK, and what’s best to compile and deploy (for Windows it’s Visual Studio, for the others you can just use the terminal with the SDK tools).

For each platform (I promise, that is the last time I’m saying that) you have to create a default project (look at the Getting Started Guide).

Now that you have the structure, we can start the JavaScript part.

Every JS (and html/css) files must be in the www directory.

Since I’m using Haxe, I need to generate all the externals for using code completion. Here is an example of what you have to do :

1
2
3
4
5
6
7
8
9


@:native("window.device")
extern class Device 
{
	//public static var name	(default, null) : String;
	public static var cordova	(default, null)	: String;
	public static var platform	(default, null)	: String;
	public static var uuid		(default, null)	: String;
	public static var version	(default, null)	: String;
}

Now in your JS project, if you want to display your uuid :

1

js.Lib.document.getElementById("uuid").innerHTML = Device.uuid;

And the HTML part :

1

<h4>UUID: <span id="uuid"> </span></h4>

PhoneGap allows you access to all the device functionalities. Look at the documentation for more details.

So now we have a basic project working, we have to search for an UI framework. And since we can use any JS framework … we have plenty of choices.

JavaScript UI framework

I personally have selected SenchaTouch for its community and its maturity.

Like PhoneGap, you have to generate externals. But since it’s a bigger library, we must automate that. So I’ve searched on the web to see if someone had already done that, and I found on Github externals that has been generated by Joshua Granick.

But there are some errors that prevent the compilation. After some research (and thanks to the Google Haxe Group) I found how to fix all the errors. There are two problems :

args: must be changed to ?args: Array< Dynamic >
The Array and the String class must be removed

Just to be sure I have the last SenchaTouch version, I’ve generated them by using (thanks again to Joshua) BuildHX. Since this tool is only working on Windows, I’ve updated the sources to use the Linux version of JSDuck.

Here is the package with all the externals classes for the last version of the SenchaTouch Framework (2.0.1.1).

You can now test the Getting Started Project. You can download here the Haxe portage (hosted on haxejs). There are some minor changes that need to be made for it to be working (It’s just some parameters that are missing).

Conclusion

From my point of view, PhoneGap is what’s better for me, mostly because of its HTML5 support. For the rest, I prefer the SenchaTouch approach and of course Haxe JS.

AGE - QuadTree implementation

Sun, 08 Jul 2012 00:00:00 +0000

What is the QuadTree ?

If we look at the wikipedia page, we can find a small explanation (it’s the best one I have found so far) :

A quadtree is a tree data structure in which each internal node has exactly four children. Quadtrees are most often used to partition a two dimensional space by recursively subdividing it into four quadrants or regions.

Why would I add it ?

The first approach to detect collisions between entities was to check for each entity if it collided with one of the others entities in the world. So you can use this method for a really small game, because the number of tests is not that big. But if you have, for example, a game with 100 entities moving around the screen, which can collide with each other, the number of tests between entities will be 100x100 !! And at least half (probably more) of them are not necessary. The Quadtree allows you to eliminate those unnecessary checks.

How does it work ?

Each time an entity is added to the stage, we just have to look into the tree and find where to put it. A node is simply a rectangular zone with entities and other nodes in it.

So basically, any node will be divided in 4 nodes if more than n entities are completely contained within the node. For AGE, I have decided to use n = 2.

Here is a more concrete example :

The world has 1 entity, the entity is added to the root node (depth = 0).

A second entity is added, so the world has been divided. The first entity (the red one) is pushed down to the top left node, and the second one is pushed down to the top right node (depth = 1).

A third entity is added to the stage. This one is contained in the top left node. This node has already another entity, so we just divide this node in 4. Now the first entity (the red one) does not fit entirely in a sub node, so this entity is going to stay on the same node (top left at depth 1). But the other entity (the blue one) is pushed down to the bottom right node at depth 2. For the last entity, nothing has to change for now.

Now, our tree has been set. Before checking for collisions, we have to query the tree to determine which entities are worth testing for a rectangular zone (the rectangular zone can correspond to the theoretical position of an entity, to know if we can move it or not). So, the quadtree is going to return each entity contained in a node that have an intersection with our request zone (we have to return entities that are not entirely in a sub node too).

Here is a simple example: use the arrow keys to move the black entity, and look at the nodes (especially when near the entity at the right of the world) :

AGE project setup

Sun, 01 Jul 2012 00:00:00 +0000

Since the 0.2 version, you can quickly and easily install AGE in haxelib, just by using the ant task :

1
2


git clone https://github.com/po8rewq/AGE.git
ant

For now, you can run the following command to setup a new project :

1

haxelib run AGE

This will generate a basic structure for your project, with the nmml file, and the MonoDevelop - FlashDevelop project files.

Here is the list of all arguments you can use :

-help : the help screen
-output : /your/project/directory (default: the current directory)
-name : Your Project Name
-main : MainProjectClass (default: Main)
-size : WIDTH HEIGHT (default: 800x600)
-fps : FPS (default: 30)
-bgColor : COLOR (default: 0xCECECE, you can use both 0xFF0000 and #FF0000 syntax)

This tool has only been tested on Linux …

AGE : Another Game Engine

Mon, 18 Jun 2012 00:00:00 +0000

I’ve tried a lot of game engines since I’ve started making games. And I’ve never been completely happy with them… so I have decided to develop and share my new Haxe/NME game engine.

Why another engine ?

For the past two years I have built game engines, first for AS3, then for Haxe just to learn how it works. I have made games with Flixel, Flashpunk (for the most known), but each time there is something I am not confortable with (how collisions are handled in Flixel for example). So as they say, if you want something done, it’s better to do it yourself: that’s why I decided to create my own game engine, in order to use a tool that’s best suited for me. Despite the specificities I wanted to add, I tried to keep it as simple and as generic as possible.

Basic concepts : the behaviors

Ever since I discovered this behaviors concept, it seems that I can’t do without it!

But what is this ? It’s a small concept, but it’s so simple that I don’t understand why no other game engines (that I am aware of) use it.

For example, you can have a default jump behavior, and if the player catches a power up, you can enable the jet pack behavior :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


class Player extends Entity
{
 private var _jumpBehavior : JumpBehavior;
 private var _jetpackBehavior : JetPackBehavior;

 public function new()
 {
 super(0, 0);
 
 _jumpBehavior = new JumpBehavior(this);
 addBehavior(_jumpBehavior);
 
 _jetpackBehavior = new JetPackBehavior(this);
 addBehavior(_jetpackBehavior, false);
 }

 public override function update()
 {
 super.update();
 if( powerup )
 {
 _jumpBehavior.disable();
 _jetpackBehavior.enable();
 }
 }
}

And all the player needs to do is in the update() function of the Behavior Class. So simple, and you can add it to any entity you like.

By default, there is two behaviors : Collisions and Movements. You can decide not to use them. But if you want collisions and movement, just activate them:

1
2


solid = true;
movable = true;

Follow the work on github.

Appliquer un tileset sur une tilemap

Sun, 13 May 2012 00:00:00 +0000

Maintenant que nous avons vu comment avoir un monde généré aléatoirement, et pouvant servir de donjon, voyons maintenant comment appliquer un tileset sur cette même map.

Nous avons besoin de déterminer l’état de chaque cellule en fonction de l’état des quatre cellules avoisinantes (on ne prendra pas compte des diagonales).

Plutôt que partir sur des conditions relativement énorme vu le nombre de cas à traiter, nous allons nous baser sur le même principe que pour les nombres binaires, car de la même manière nous devons représenter une combinaison de 4 valeurs dans un état 1 ou 0.

Un peu de théorie

Pour essayer de mieux comprendre, voici l’énumération des premiers nombres, et ce que ça veut dire pour nous.

Décimal - Binaire (Explication)
0 - 0
1 - 1 (2⁰)
2 - 10 (2¹)
3 - 11 (2¹ + 2⁰)
4 - 100 (2²)
5 - 101 (2² + 2⁰)
6 - 110 (2² + 2¹)
7 - 111 (2² + 2¹ + 2⁰)
8 - 1000 (2³)
…

Ok… mais comment je détermine la valeur de mes cellules ?

En pratique nous devons donc regarder les cellules environnantes et déterminer la valeur de chaque cellule en fonction des autres.

Tout d’abord le schéma correspondant aux valeurs de chaque cellule voisine :

Une case pleine sur la gauche vaut 8, une case pleine en dessous 4, un case pleine au dessus 1, et une case à droite 2.

Et voici un exemple avec les valeurs pour chaque cellule pleine :

Chaque valeur ainsi obtenue permet d’avoir la position de la tile dans la tileset :

Et voici un rendu final :

Génération aléatoire d'un donjon

Sun, 13 May 2012 00:00:00 +0000

Dans le post Génération aléatoire d’un terrain, nous avons vu comment générer un terrain grâce à la méthode des Automates Cellulaires.

Dans ce post-ci, nous allons maintenant voir comment générer des donjons, c’est-à-dire avoir la possibilité de se déplacer sur toutes les zones de la carte, sans avoir de murs bloquant le déplacement.

La méthode reste relativement la même, cependant nous allons devoir traiter plusieurs cas supplémentaires.

Le plus gros souci de nos cartes pour un donjon correspond aux trop grosses zones vides. Pour les éliminer, nous allons simplement ajouter une condition supplémentaire à la transformation : si une cellule est entourée de 0 mur dans un rayon de 1, nous passons la cellule en type mur.

1
2
3
4
5


for(p in levelMap)
 if( R1(p) >= 5 || R2(p) <= 1)
 p = 1;
 else
 p = 0;

Où Rn(p) est le nombre de voisin de type mur à une distance n de la cellule p. La fonction comptabilisant le nombre de voisins compte forcément la case en cours de test.

Voici ce que nous pouvons obtenir en 5 passes :

Comme on peut le constater, nous avons presque toutes les zones accessibles, et aucune grosse zone vide, mais il nous faut maintenant traiter le cas des blocs seuls, isolés un peu partout sur le terrain.

Pour continuer à nettoyer ça, nous allons rajouter des passages supplémentaires, mais avec des conditions différentes :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


for(i in 0...3)
 for(p in levelMap)
 if( R1(p) >= 5 || R2(p) <= 1 )
 p = 1;
 else
 p = 0;

for(i in 0...2)
 for(p in levelMap)
 if( R1(p) >= 5 )
 p = 1;
 else
 p = 0;

Ce qui va maintenant nous permettre d’obtenir, par exemple :

Et pour finaliser notre donjon, nous pouvons ajouter les bordures.

Voici un exemple de rendu final avec un ratio de 0.45, suivi de 5 itérations 1, et 3 itérations 2 :

HxSpriter released

Tue, 08 May 2012 00:00:00 +0000

HxSpriter is the Haxe implementation of the Spriter application and file format. It’s a port a the SpriterAS3 lib, but working with NME. It basically lets you use Spriter with your games or applications.

First of all, what’s Spriter?

Spriter is a powerful animation tool for creating highly detailed 2d real-time game characters and effects in an intuitive, visual editor. The characters are saved to a format that allows game engines to produce higher quality visuals, while also using less video ram, and requiring less disk space per frame than traditional 2d sprite animation.

Spriter also provides several game specific features like collision boxes, and sound effect triggering, and saves to an open format that will be useable across many different game engines and platforms.

Spriter is currently in an usable beta state, but it’s really subject to changes, so the various implementations might stop working from a version to another, and they will need constant updating. The file format may also get incompatible across future versions, and the application may cause some crashes. For these reasons, Spriter is not production ready, but you can test it and play with it if you want.

How to use it ?

To use it, just install it from haxelib :

1

haxelib install HxSpriter

In your NME file, you have to define a sprites directory (just rename the directory where you have all your Spriter’s animations).

1

<assets path="path/to/the/sprites/directory" rename="sprites" />

Now, if you want to use the library :

1
2
3


var spriter : BitmapSpriter = new BitmapSpriter('BetaFormatHero.SCML', 100, 300);
spriter.playAnimation('idle_healthy');
addChild(spriter);

Or with the Flixel port :

1
2
3


var spriter : FlxSpriter = new FlxSpriter('BetaFormatHero.SCML', 100, 300);
spriter.playAnimation('idle_healthy');
add(spriter);

Or with HaxePunk :

1
2
3


var spriter : HxpSpriter = new HxpSpriter('BetaFormatHero.SCML', 100, 300);
spriter.playAnimation('idle_healthy');
addGraphic( spriter );

You can also checkout the repository : https://github.com/po8rewq/hxSpriter.

FlxCollisions port to Haxe

Fri, 27 Apr 2012 00:00:00 +0000

Here is the FlxCollisions demo ported to the Haxe version of Flixel. Watch the FPS value of the Android version… just awesome! This demo uses the tmx file to generate the level (Tmx library).

You can download sources on github

Tmx format with Flixel Haxe

Thu, 26 Apr 2012 00:00:00 +0000

During the past few days, I’ve been working with the HaxePunk framework to develop a game. But because of a lack of performance on Android (and no time to try to fix it), I’ve tried the Flixel port to see if I could build a game quickly.

First of all, I’ve tried the example based on Demo on my Android device and… surprise, the game turns at 50-60 FPS. So against my heart, I decided to start building my game on Flixel (actually, I really prefer the HaxePunk structure).

First of all, I tried to remember how Flixel works (I’ve already used it on My Hero Factory…).

So I started to initialise a project, and tried to import a level I’ve made with Tiled Map Editor… only to discover the tmx format is not supported in Flixel o_O.

Thanks to Matt Tuttle, the library is already ported to HaxePunk (the original one was from Thomas Jahn) so it was not difficult to make it work with Flixel.

So here is how you used it (make sure to download the sources) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Create a TmxMap with a tmx file
var tmx : TmxMap = new TmxMap( nme.Assets.getText('levels/map01.tmx') );

// Basic level structure
var t:FlxTilemap = new FlxTilemap();

// Generate a CSV from the layer 'map' with all the tiles from the TileSet 'tiles'
var mapCsv:String = tmx.getLayer('map').toCsv( tmx.getTileSet('tiles') );

t.loadMap(mapCsv, "gfx/tiles.png", 8, 8, FlxTilemap.OFF);
add(t);

And that’s it! Of course if you want to have collisions detections, just add:

1
2
3
4
5


override public function update()
{
 super.update();
 FlxG.collide(_player, _tilemap);
}

My entry for Ludum Dare 23

Tue, 24 Apr 2012 00:00:00 +0000

Last weekend, I entered the great contest that is Ludum Dare. For those who don’t know what the Ludum Dare is, it’s an event that takes place every 3 months, and that gathers a lot of people wanting to create games… in only 48 hours for the solo contest, and around a precise theme. To give you an idea of the popularity of this contest, people submitted over 1200 games during the weekend!

When the subject of this Ludum Dare has been announced (Tiny World), a lot of people started to post on the official website all their ideas, and that it was an inspiring subject … but it wasn’t my case. So I took 2 or 3 hours looking for a good idea and trying to have a good concept.

Thanks to the coffee, I managed to finish my game in time to submit it (click to see the entry). Its name ? Pixel World !

How I prepared

Trying concepts using HaxePunk to start learning this great tool
Used tiled map editor with HaxePunk
In fact, I prepared all the tools I needed

What went right

I tried to stay simple and to focus on the concept
I used tools I was familiar with (HaxePunk, MonoDevelop and Gimp), so I didn’t lose time on that
Thanks to my lack of drawing abilities, I managed not to spend too much time on the graphic design (actually, it helped me to find a cool concept!)

What could have been better

More updates on my progress (I tried to stay away from the website, in order not to be distracted by watching the other’s amazing games)
I spent too much time on the level design : I tried to stay simple, but didn’t want to have a game that was too simple to play…

Next time

I will try to add sounds/music to my game
Much more updates on my work on the website
Less coffee ? (just kidding… or am I?)

Here’s my work

Play the game

Génération aléatoire d'un terrain : Cellular Automaton

Sun, 15 Apr 2012 00:00:00 +0000

Cette méthode est utilisée dans beaucoup de domaines comme par exemple les maths, la physique…

Elle consiste à avoir une grille contenant des cellules, chacune ayant un état (dans notre cas eau/terre).

Pour chaque cellule, on regarde l’état des cellules voisines pour déterminer son nouvel état. Si une cellule est entourée d’au moins 5 cellules de type terre, alors la cellule est transformée en cellule terre, sinon on la passe en cellule de type eau.

Voici un exemple en 8 passes :

Pour plus de renseignements sur cette méthode : Cellular Automaton (ou Automate Cellulaire en français).

Il y a deux façons de procéder lors du traitement des données :

Pour chaque cellule, faire le traitement et modifier directement les données du tableau (et donc prendre le nouvel état en considération lors du traitement de la cellule suivante)
On traite les données à un instant t.

C’est cette deuxième solution que nous allons utiliser.

Génération aléatoire du tableau

Dans un premier temps, nous devons donc générer aléatoirement des données dans notre tableau initial.

Pour ce faire, nous avons besoin d’un ratio pour nos cellules de type terre.

1

public static var LAND_RATIO : Float = 0.50;

Nous avons besoin d’un enum listant les états possibles pour chaque cellule (seul l’enum sera utilisé, le reste servira lors de l’affichage des données) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


package ;

enum CellType {
 land;
 water;
}

class CellTypes implements haxe.Public
{
 /**
 * Retourne la valeur sous forme de chaîne
 * de caractères pour un type donné
 */
 static function toString( t: CellType ) : String
 {
 return switch(t)
 {
 case land : 'land';
 case water : 'water';
 }
 }

 /**
 * Retourne la couleur pour un type donné
 */
 static function toColor( t: CellType ) : UInt
 {
 return switch(t)
 {
 case land : 0x00ff00;
 case water : 0x0000ff;
 }
 }
}

Puis nous générons les données :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var cells : Array< Array< CellType > > = new Array();
for (i in 0...MAP_WIDTH)
{
 cells[i] = new Array();
 for(j in 0...MAP_HEIGHT)
 {
 if(Math.random() < LAND_RATIO)
 cells[i][j] = CellType.land;
 else
 cells[i][j] = CellType.water;
 }
}

Nous avons maintenant un tableau complètement aléatoire. Il nous faut alors le traiter pour obtenir un terrain qui nous va bien.

Traitement de données

Pour ce faire, nous devons définir un nombre d’itérations déterminant le niveau de nettoyage de notre terrain :

1
2


for(i in 0...5)
 cleanLand();

Et voici notre méthode de traitement de chaque cellule. Comme nous l’avons dit plus haut, le traitement se fait à un instant t. Nous avons donc besoin d’un tableau temporaire pour stocker nos nouvelles valeurs le temps de finir le traitement global du terrain :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


private function cleanLand():Void
{
 for (i in 0...MAP_WIDTH)
 {
 for (j in 0...MAP_HEIGHT)
 {
 if(getAdjacentType(i, j, CellType.land) >= 5)
 tmpValues[i][j] = CellType.land;
 else
 tmpValues[i][j] = CellType.water;
 }
 }
}

Cette méthode retourne pour une cellule donnée le nombre de cellules du type spécifié en paramètre (le type de la cellule traitée est également pris en compte) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


private function getAdjacentType(col:Int, row:Int, lookFor:CellType):Int
{
 var found:Int = 0;
 for (i in -1...2)
 {
 for (j in -1...2)
 {
 // Une cellule null est prise en compte comme une cellule de type eau
 if (landArray[col + i] != null && landArray[col+i][row+j] == lookFor
 || (landArray[col + i] == null || landArray[col+i][row+j] == null) && lookFor == CellType.water)
 ++found;
 }
 }
 return found;
}

Voici un exemple de résultat :

La méthode pour obtenir un terrain utilisable dans un donjon (où toutes les cellules de type terre doivent être liées) est la même, mais il vous sera nécessaire de faire des traitements supplémentaires.

Le plus simple, sur un résultat comme celui ci-dessus, est de faire en sorte de reconnecter toutes les parties. Dans un premier temps, il faut augmenter le ratio de cellule de type terre, et le passer à 60% pour avoir quelque chose qui ressemble plus à un donjon. Et enfin, refaire quelques itérations pour supprimer (ou connecter, au choix) les parties ne l’étant pas encore.

Sauvegarder une liste d'entiers dans un shared object

Sun, 30 Oct 2011 00:00:00 +0000

Voici une petite astuce qui peut vous simplifier la vie. Dans un grand nombre de jeux, nous avons besoin de stocker la liste des niveaux terminés par le joueur, et de pouvoir y accéder rapidement. La méthode la plus simple est de stocker cette donnée dans un SharedObject que nous retrouverons à chaque lancement de session.

Sauvegarde des données

Pour stocker une liste d’entiers dans un SharedObject sous la forme d’un entier seul, il faut sauvegarder la somme des puissances de 2 des valeurs souhaitées.

1
2
3
4
5
6
7
8


var mySo:SharedObject = SharedObject.getLocal("myApplication");
var dataToSave : Array = [2, 5, 4];
var somme : int = 0;
for each(var data : int in dataToSave)
{
somme += Math.pow(2, data);
}
mySo.data.savedValue = somme;

Récupération des données

Et pour récupérer les données :

1
2
3
4
5
6


var intValue : int = mySo.data.savedValue;
var currentIndex : int; // identifiant du niveau à tester
if( ( Math.pow(2, currentIndex) & intValue) > 0 )
{
// L'entier est bien présent dans la liste
}

NME - Premiers pas sous android

Sat, 10 Sep 2011 00:00:00 +0000

La version 3 de NME est enfin disponible sur **haxelib **!!

Le rêve de tout développeur est en train de se réaliser : developper une application, et la publier sur toutes les plates formes ! C’est enfin possible grâce à **haXe **et NME.

Quelques précisions

Avant d’aller plus loin, voyons un peu de quoi il s’agit. Si vous êtes familié avec Haxe, vous ne l’êtes peut etre pas avec NME.

**NME **(pour Neko Media Engine) est un framework open source permettant de publier une application vers tout type de plate forme (windows, linux, android, ios, et j’en passe). Ce framework s’appui sur le langage haXe, ce qui permet d’avoir une syntaxe proche de l’Actionscript. **NME **s’occupe ensuite de mapper tout ca, et de publier pour la plate forme voulue.

Nous ne nous interresserons pour le moment, qu’à la plate forme android.

Voici un schéma permettant de comprendre le fonctionnement :

(source: www.haxenme.org)

NME va utiliser le compilateur haxe, avec la librairie **HXCPP **pour générer les classes C++. La compilation va se poursuivre via le SDK et le NDK Android.

Et pour terminer, en passant par une tache Ant, le processus de compilation va se terminer et lancer (si besoin) l’installation sur le périphérique Android.

Installation

Voici la liste des étapes à suivre pour avoir un environnement de travail fonctionnel. Je suis sous linux, mais sous n’importe quelle plate forme, l’approche reste à peu de chose prêt la même.

Tout d’abord, haxe : télécharger l’installeur sur le site haxe.org, décompresser puis :

1
2
3


haxelib install hxcpp
haxelib install nme
haxelib install gm2d

Il nous faut maintenant récuperer le SDK et le NDK android (menu de gauche pour le NDK) :

1
2


wget http://dl.google.com/android/android-sdk_r12-linux_x86.tgz
wget http://dl.google.com/android/ndk/android-ndk-r6b-linux-x86.tar.bz2

Le JDK java :

1

sudo apt-get install openjdk-6-jdk

Et enfin, ant

1

sudo apt-get install ant1.8

Une fois que tout est téléchargé/installé, nous devons setter les variables d’environnements :

1
2
3
4


ANDROID_SDK
ANDROID_NDK_ROOT
ANDROID_HOST=linux_x86 [linux only]
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk

Petite application de test

Le code :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


package ;

import flash.display.Sprite;
import flash.display.StageAlign;
import flash.display.StageScaleMode;
import flash.geom.Rectangle;
import flash.Lib;

class Sample extends Sprite
{
 public function new()
 {
 super();

 Lib.current.stage.align = StageAlign.TOP_LEFT;
 Lib.current.stage.scaleMode = StageScaleMode.NO_SCALE;

 trace('Hello World');

 var rect : Sprite = new Sprite();
 rect.graphics.beginFill(0xFF0000);
 rect.graphics.drawRect(0, 0, 200, 200);
 rect.graphics.endFill();
 addChild(rect);
 }

 public static function main ()
 {
 Lib.current.addChild( new Sample() );
 #if nme
 Lib.current.addChild(new nme.display.FPS() );
 #end
 }
}

Le fichier de configuration (myConfigFile.nmml) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


<project>
 <app title="Sample from revolugame" main="Sample" />
 
 <window width="0" height="0" orientation="landscape" fps="60" background="0xffffff" resizeable="true" hardware="true" />
 
 <set name="BUILD_DIR" value="Export" />
 <classpath name="src" />
 
 <haxelib name="nme" />
 
 <target name="android" />
 
 <ndll name="std" />
 <ndll name="regexp" />
 <ndll name="zlib" />
 <ndll name="nme" haxelib="nme" />
</project>

Lancer la compilation :

1

haxelib run nme test myConfigFile.nmml android

L’option test correspond à build suivi de run, mais il est également possible de ne lancer que l’une de ces options.

Pour tester l’application en flash, suffit de remplacer android par flash.

Posts on RevoluGame

Designing a Homelab Backup Strategy I Can Actually Trust

The rule behind the design

What needs protecting

The NAS is the hub, not the backup strategy

Docker apps need app-aware backups

Home Assistant gets its own lane

The small machines count too

Gitea is not just “on the Mac”

Cloud backup should be encrypted and versioned

USB disks are for offline recovery

A second NAS is useful if it changes the failure mode

Monitoring is part of the backup system

Restore tests make it real

The target architecture

My checklist before calling this done

How I Use Obsidian for Work, Personal Life, and AI

My Vault Structure

Inbox

Projects

Areas

Resources

Archive

How Information Enters Obsidian

Daily Notes and Tasks

Excalidraw for Architecture and Thinking

Where AI Fits Into the Workflow

Processing Meeting Notes

Building an AI-Ready Knowledge Base

AI as a Team Member

One System, Many Uses

How the Supernote Became the Starting Point for Almost Everything I Write

The Supernote Is My Thinking Device

Meetings Start Here

From Supernote to Obsidian

Debugging on Paper

Gathering Thoughts Before Writing

Organized Chaos

Two Tools, Two Jobs

My homelab stack in 2026: what runs, why, and how it all connects

The foundation

Traefik

Tailscale

CoreDNS

Dev & CI/CD: the pipeline

Gitea

Woodpecker CI

Local Docker registry

WUD - What’s Up Docker

Local AI: Ollama + OpenWebUI

Search: SearXNG

Documents: Paperless-NGX + Paperless-AI

Password management: Vaultwarden

Monitoring & management

Prometheus

Portainer

Homer

Communication & file sharing

Ntfy

Pairdrop

Home automation: Home Assistant

What’s next

Designing Single-Purpose Agents Instead of One Big Automation Script

The three conventions that make this work

Why decompose instead of consolidate

The boring plumbing is the point

Backing Up the One Credential That Can't Be Wrong

Three copies, three different failure modes

The part that matters more than the architecture

Threat-model your one credential that can’t be wrong

Running a Personal SOC: Bringing Production Security Practices Home

Two layers, not one

Where the LLM fits - and where it doesn’t

The part that’s just operational discipline

What it actually buys me

Home Assistant Roomba Script

Prerequisites

Retrieving necessary data

Install dorita980

Get Credentials

The `useSignIn` hook

`signInWithEmail` method

`signOut` method

The `usePosts` hook