Nasty Hacker: The Dirty Hacks That Made Our Hackathon Awesome

The Problem: No Data, No Demo

We had a beautiful dashboard. We had a perfect architecture. We had everything… except data.

For a hackathon demo, you need data. Lots of it. Spread across time. With realistic patterns. And we had nothing.

So we did what any self-respecting hacker would do: we hacked it.

Hack #1: Creating 10 Mock Users in Entra ID

We needed users. Real users. Users that could create commits, work items, and pull requests. So we created them programmatically.

The Hack: A PowerShell script that creates 10 Azure AD users:

# create-devops-users.ps1
for ($i = 1; $i -le 10; $i++) {
    $displayName = "SampleUser$i"
    $userPrincipalName = "$displayName@geekindata.com"

    # Create user in Azure AD
    az ad user create --display-name $displayName `
        --user-principal-name $userPrincipalName `
        --password "TempPassword123!@#$i"

    # Add to DevOps organization
    $body = @{ principalName = $userPrincipalName; principalType = "user" }
    Invoke-RestMethod -Uri "https://vssps.dev.azure.com/$Organization/_apis/graph/users" `
        -Method Post -Headers $headers -Body ($body | ConvertTo-Json)
}

Why It’s Nasty: We’re creating real Azure AD users just for demo data. They’re in security groups. They’re real enough to fool the system.

The Result: 10 users ready to generate commits and work items.

Hack #2: Mock Commits by Mock Users

Now we had users. But they hadn’t done anything. So we made them work programmatically.

The Hack: A Python script that creates commits with backdated timestamps:

# create_commits_and_prs_simple.py
def create_commit(repo_id, branch_name, commit_message, file_path, 
                 file_content, author_email, author_name, old_object_id):
    # Backdate commits randomly across 30 days
    commit_date = datetime.now() - timedelta(days=random.randint(0, 30))

    body = {
        "commits": [{
            "comment": commit_message,
            "author": {
                "name": author_name,
                "email": author_email,
                "date": commit_date.isoformat() + "Z"  # Backdated!
            },
            "changes": [{
                "changeType": "add",
                "item": {"path": file_path},
                "newContent": {"content": file_content, "contentType": "rawtext"}
            }]
        }]
    }
    requests.post(url, headers=HEADERS, json=body)

Why It’s Nasty: We’re creating mock commits with mock code files, authored by mock users, backdated to look like real work happened over time.

The Result: Hundreds of commits spread across 30 days, making our repository look active.

Hack #3: Mock Code Files

Every commit needs code. So we generated mock Python files:

code_content = f'''
"""
Implementation for User Story #{story['id']}
{story['title']}
"""

def main():
    print("Story {story['id']}: {story['title']}")
    # Implementation here
    pass
'''

Why It’s Nasty: It’s not real code. It’s a template. But it’s enough to create commits and generate activity.

The Result: Every commit has a file. Every file has content. It’s mock, but it works.

Hack #4: Programmatic Work Item Creation

We needed work items. Lots of them. So we scripted their creation:

# create-marketing-user-stories.ps1
function Create-WorkItem {
    param([string]$Title, [string]$Description, [string]$AssignedTo)

    $body = @(
        @{ op = "add"; path = "/fields/System.Title"; value = $Title },
        @{ op = "add"; path = "/fields/System.Description"; value = $Description },
        @{ op = "add"; path = "/fields/System.AssignedTo"; value = $AssignedTo }
    )

    Invoke-RestMethod -Uri $uri -Method Post -Headers $headers -Body ($body | ConvertTo-Json)
}

Why It’s Nasty: We’re creating work items via API calls, assigning them to mock users, linking them together. It’s automation masquerading as human work.

The Result: 50+ user stories, all assigned, all linked, all ready for our dashboards.

Hack #5: Auto-Assigning Users

Work items need owners. So we assigned them automatically:

# assign-users-to-workitems.ps1
$assignments = @(
    @{ StoryId = 47; UserIndex = 0 },
    @{ StoryId = 54; UserIndex = 9 },
    @{ StoryId = 61; UserIndex = 1 }
)

foreach ($assignment in $assignments) {
    $user = $sampleUsers[$assignment.UserIndex]
    $body = @(@{ op = "replace"; path = "/fields/System.AssignedTo"; value = $user.mailAddress })
    Invoke-RestMethod -Uri "$baseUrl/$($assignment.StoryId)" -Method Patch -Body ($body | ConvertTo-Json)
}

Why It’s Nasty: We’re programmatically assigning work items to users who never asked for them. It’s mock workload distribution, but it looks real.

Hack #6: Mock Data Generation in Gold Layer

Our dashboards needed varied data. So we generated it directly in the gold layer:

# GenrateGoldData.Notebook/notebook-content.py
def random_date(start_date, end_date):
    """Generate random date between start and end"""
    time_between = end_date - start_date
    random_days = random.randrange(time_between.days)
    return start_date + timedelta(days=random_days)

# Spread commits across 12 months
for i in range(NUM_NEW_COMMITS):
    commit_date = random_date(START_DATE, END_DATE)  # Last 12 months
    lines_added = random.randint(10, 500)
    message = random.choice(commit_messages) + f" #{random.randint(1, 1000)}"

    data.append((commit_id, repo.RepositoryId, user.UserEmail, message, commit_date, lines_added))

Why It’s Nasty: We’re bypassing the entire medallion architecture. Instead of waiting for real data to flow through Bronze → Silver → Gold, we’re injecting mock data directly into Gold.

The Result: 100 commits spread across 12 months. 50 work items with varied dates. Data that looks real because it’s spread across time.

Hack #7: Creating Mock Branches and Pull Requests

Commits need branches. Branches need pull requests. So we created them:

# Create branch
branch_name = f"refs/heads/feature/story-{story['id']}"
create_branch(repo_id, branch_name, base_object_id)

# Create commit on branch
create_commit(repo_id, branch_name, commit_message, file_path, code_content, user["mailAddress"], user["displayName"])

# Create PR linked to work item
create_pull_request(repo_id, branch_name, "main", title, description, [story["id"]])

Why It’s Nasty: We’re creating entire Git workflows programmatically. Branches, commits, PRs—all mock, all linked, all looking like real development activity.

The Result: Complete Git history. Branches for every story. PRs linked to work items.

The Collection of Hacks

User Creation:

create-devops-users.ps1 – Creates 10 Azure AD users
add-existing-users-to-devops.ps1 – Adds them to DevOps

Work Item Generation:

create-marketing-user-stories.ps1 – Creates user stories
create-50-more-stories.ps1 – Creates 50 more stories
assign-users-to-workitems.ps1 – Auto-assigns users

Git Activity Generation:

create_commits_and_prs_simple.py – Creates commits and PRs
create_branches_commits_prs.py – Creates branches, commits, PRs

Data Generation:

GenrateGoldData.Notebook/notebook-content.py – Generates varied gold layer data

Why These Hacks Are Awesome

They Enable Demos: Without data, our dashboards would be empty. With hacks, they’re impressive.

They Show Real Patterns: Even mock data, when spread across time, reveals patterns. Our dashboards show trends because the data has temporal distribution.

They Save Time: Instead of waiting weeks for real data, we generated months of activity in hours.

They’re Reusable: Every hack is scripted. We can spin up a new project with full data in minutes.

The Business Value

These hacks enabled:

Immediate demos with realistic data
Dashboard testing with varied scenarios
Pattern analysis across time periods
User experience testing with multiple users
Performance testing with substantial data volumes

The Hackathon Reality

In a hackathon, you don’t have time for real users to do real work, real development cycles, or real data accumulation.

So you hack it. You create mock users. You generate mock commits. You backdate everything. You make it look real.

And it works. Our dashboards look impressive. Our analytics show patterns. Our demos tell a story.

The Dirty Truth

Is it real data? No.

Does it work? Yes.

Is it ethical? For a hackathon demo? Absolutely.

We’re not claiming this is production data. We’re showing what’s possible when you have data. And when you don’t have data, you create it.

These hacks demonstrate the power of creative problem-solving. When you need data for a hackathon demo, sometimes the best approach is the nastiest one: create it yourself. Mock users, mock commits, mock work items, all scripted, all automated, all enabling awesome dashboards.

Arctic Cloud Developer Challenge Submissions

Nasty Hacker😶‍🌫️