Skip to content

Instantly share code, notes, and snippets.

View looneym's full-sized avatar
🐧
im in ur ifra breakin ur services

Micheál Looney looneym

🐧
im in ur ifra breakin ur services
View GitHub Profile
@looneym
looneym / claude-prompt-sharing-guidelines.md
Created June 26, 2025 17:48
[claude-prompt] Prompt Sharing Guidelines for Claude

Prompt Sharing

When El Presidente wants to share specific prompting approaches or guidelines with others, I should create shareable gists containing the prompt content.

Types of Prompts to Share

  • Configuration sections: Portions of this CLAUDE.md file that others might find useful (like the Session Journaling guidelines)
  • Ephemeral prompts: Prompting techniques or frameworks we develop during a session that could benefit other teams
  • Workflow instructions: Step-by-step processes we've refined for specific tasks
  • Best practices: Guidelines we've discovered for working with Claude effectively
@looneym
looneym / session-journaling-prompt.md
Created June 26, 2025 17:45
[claude-prompt] Session Journaling Guidelines for Claude

Session Journaling

When El Presidente asks me to "journal" about a working session, I should create a written summary that captures the engineering discussion and can be shared with the team.

Journaling Style and Structure

  • Tone: Casual but professional - write as an engineer summarizing a working session with El Presidente
  • Perspective: Third person, factual account of what we tried and learned
  • Length: Keep it concise - aim for 3-4 paragraphs total
  • No structured headings: Use flowing narrative paragraphs, not bullet points or formal sections
@looneym
looneym / feature-flag-design-session.md
Last active June 26, 2025 17:43
[claude-journal] Feature Flag System Design Session - Read-Through Cache with Background Population

El Presidente and I had a working session to design a feature flag system for nexus-go to support gradual infrastructure rollouts, specifically migrating from Redis to Valkey. The challenge is that this application handles about 20M events in 10-second windows across 150 production hosts, so performance is absolutely critical.

Initially we took the obvious approach - on-demand DynamoDB lookups with local caching. Each feature flag check would hit the local cache first, then fall back to DynamoDB on a cache miss. This seemed reasonable until we did the math on the scale. At 2M events per second, even with 1-minute caching, cache misses for new features could generate millions of simultaneous DynamoDB calls. We briefly considered switching from app_id-based flags to app_stage-based flags (using the MUSTER_PROFILE env var) to reduce the lookup space, but we realized we'd still have the same rate limiting issues - every single event would still need to check the feature flag, just with a different key. We actual

module IntercomUtil
require 'intercom'
TOKEN = ENV["INTERCOM_PAT"]
@intercom = Intercom::Client.new(token: TOKEN)
def self.get_all_conversations
open_convos = @intercom.conversations.find_all(open: true)
closed_convos = @intercom.conversations.find_all(open: false)
@looneym
looneym / docker-compose.yml
Created July 9, 2017 02:48 — forked from EloB/docker-compose.yml
Docker compose yml hello world example
helloworld:
image: ubuntu:14.04
command: /bin/echo 'Hello world'
<details>
<summary>Summary Goes Here</summary>
```
lol
```
</details>
original = raw_input("Enter a word")
if len(original) >= 0 and original.isalpha():
print original
else:
print "empty"
@looneym
looneym / main.py
Created May 14, 2017 16:37
Create a branch in a remote repo using the Github API. Uses token auth.
import requests
import os
import json
TOKEN = os.environ['GH']
NEW_BRANCH_NAME = ''
HASH = ''
AUTHOR= ''
REPO = ''
import sys
from twisted.web.static import File
from twisted.python import log
from twisted.web.server import Site
from twisted.internet import reactor
from autobahn.twisted.websocket import WebSocketServerFactory, \
WebSocketServerProtocol
from autobahn.twisted.resource import WebSocketResource