DEV Community: Alin Pisica

Acta Non Verba: Building a GTD Task Manager by Conversation with GitHub Copilot

Alin Pisica — Sun, 15 Feb 2026 21:40:28 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

A while ago I read David Allen's Getting Things Done it and it kind of changed the way I do things.
Seeing this challenge I felt that it is a perfect opportunity of combining the pleasure with work, and I created Acta.

Acta is a command-line task manager built around the Getting Things Done (GTD) methodology combined with my current needs (I use an external tool at the moment for tracking tasks, but I end up finding myself pretty often in the need of adding a new task right from the terminal, while I work - it removes friction as much as possible, and keeping my in my flow). The name comes from the Latin phrase "Acta non verba" - actions, not words - which felt fitting for a tool designed to get things off your mind and into motion.

The workflow mirrors the GTD capture-process-do loop:

CAPTURE → PROCESS → DO
   ↓         ↓       ↓
Inbox    Actionable  Work

Capture - Dump a task into the inbox instantly, with optional @context tags (e.g., @project, @article, @research)
Process - Review the inbox: assign a due date and priority, or mark as done/remove
Do - Work through tasks in priority order: overdue first, then today's, then upcoming
List - Filter tasks by context, keyword, regex, or field (e.g., priority:high)
Stats - Analytics dashboard: completion rate, context breakdown, overdue count, priority distribution

The app is built with .NET 10, Spectre.Console for the terminal UI, and compiled as a NativeAOT binary - a single, fast executable with no runtime dependency, cross-compiled for Linux, Windows, and macOS.

Didn't write a console app since university, and for a long time I wanted to try out Spectre.Console touches crept in. The interactive menu greets you with a FigletText banner reading "Acta, non verba" and I tried to integrate colors as much as I can, without making it disturbing.

What makes this project meaningful to me is that I didn't write most of the code. I guided it out of GitHub Copilot, one natural-language prompt at a time. It was a fun time and a perfect example of Copilot CLI's functionalities: it created a tool that I needed, based on my needs and requirements, with as little input as possible from my side.

Demo

Project Repository: Acta - GitHub

Uploaded builds for specific distros under the releases/ folder.

The GTD loop in action

# Capture tasks anywhere, any time
acta capture "Renew car insurance @admin"
acta capture "Review PR #42 @work"
acta capture "Buy coffee beans @shopping"

# Process the inbox (assign dates, priorities, remove noise)
acta process

# Work through today's tasks
acta do

# Focus on a specific context
acta do @work

# Search and filter
acta list "@work priority:high"
acta list "/renew|review/"      # regex

# Analytics at a glance
acta stats

Interactive mode

Run acta with no arguments to get the full interactive menu:

  ___        _
 / _ \      | |
/ /_\ \ ___| |_ __ _   _ __   ___  _ __    __   _____ _ __| |__   __ _
|  _  |/ __| __/ _` | | '_ \ / _ \| '_ \   \ \ / / _ \ '__| '_ \ / _` |
| | | | (__| || (_| |_| | | | (_) | | | |   \ V /  __/ |  | |_) | (_| |
\_| |_/\___|\__\__,_(_)_| |_|\___/|_| |_|    \_/ \___|_|  |_.__/ \__,_|

── Productivity for the weak-willed ──────────────────────────────────────

What do you feel like doing?
> Capture
  Process
  List
  Do
  Stats
  Help
  Exit

What the task list looks like

 #   Pri  Title                          Context        Due         Status
 ─   ───  ─────────────────────────────  ─────────────  ──────────  ──────
 1   ❗❗ Review PR #42                   @work         2026-02-15  →
 2   ❗   Write article for Dev.To        @article      2026-02-20  →
 3   ·    Upload content on Git           @dev          -           ○ ⏸2h

(Add a screenshot or recording before publishing)

My Experience with GitHub Copilot CLI

What was fun? Well, everything.

I felt like I was the project manager, product owner and architect, while Copilot acted like an army of developers. I wrote the requirements in plain English; Copilot wrote the code, spotted its own bugs, refactored its own architecture, and generated its own documentation. What follows is the story of how that actually played out across three phases.

Phase 1 - Building from scratch, prompt by prompt

I started with a simple instruction:

"Create a new .NET console project named Acta, add Spectre.Console package, and enable NativeAOT in the csproj file. The project will be a CLI-based tasks management based on 'Getting Things Done' idea."

Copilot scaffolded the project correctly. After, I directed him in how the model should look, how data should be stored and how it should process the data. It went smoothly, with minimal corrections. I did not ask for his decision making, I made the calls, and only directed towards him as simply as possible, giving it plenty of room to juggle. I prompted it everythime to ask for clarification questions, if needed.

From there I fed it one feature at a time. Each prompt described the behavior, not the implementation:

"Create a StorageService that reads and writes a list of TaskItem to a JSON file in the local AppData folder using System.Text.Json source generation."
"Populate the Capture choice. The user should be asked for the task's input text. He can provide context by specifying elements with '@' inside the task."
"Allow the user to also directly capture tasks using acta capture "Insert task text here" directly from CLI, without running the executable."
"Create the 'list' action. It should list elements based on filters or contexts. @home shows home tasks, make bed @home shows tasks matching 'make bed' with context @home. Multiple contexts, multiple words, all lowercase."

The StorageService prompt is worth highlighting. Copilot's first attempt failed to compile. More interesting: after the build error, it didn't just fix the error - it scanned the rest of the code for null-safety warnings it hadn't been asked to fix, and resolved them proactively. That was the moment I realized this wasn't just autocomplete.

By the end of Phase 1 the app had:

capture (inline and interactive)
process (inbox review with date assignment)
list (context and keyword filtering)
(task queue with overdue → today → upcoming priority order).

Everything was working and I had my "mini-tool" ready to go into my dev enviroment and day-to-day tasks.

Phase 2 - Copilot refactors itself

As expected, from the initial phase, everything was in one place: commands, display logic, filtering, menu handling. I asked Copilot to look at it and generate summaries for everything that was existing.
I identified the problems (tight coupling, mixed concerns, poor testability) based on his explanations (not leaving room for interpretation), proposed a structure (Commands / Services / Models / Utilities), and listed him the file structure I wanted - along with what would stay the same.

Then it did the refactoring:

Program.cs shrank from 354 lines to 54
9 new source files were created across 4 directories
TaskFilterService, TaskDisplayService, CommandDispatcher, and ContextParser emerged as focused, single-responsibility classes
Every existing command worked identically after the change - zero breaking changes

Phase 3 - Copilot plans its own roadmap, then implements it

After the refactoring, went on the classical path of a software product: improve it. I asked him to produce a nextsteps.md: a prioritized list of missing features and UI improvements, each with impact assessment, effort estimate, and a specific list of files to modify. It even laid out a 5-phase implementation roadmap. I did not suggest anything, I wanted to test its limitations and see how far it could go. It amazed me. Did it create something revolutionary, that did not exist until now? No, of course, we all know how it works (right? right? it can't invent new things... YET). Did it create a list of features that improved the product, and it reduced my time of defining and describing the features? Yes.

I picked some of them and asked for implementations (I updated the .md file wiht my own changes).

Advanced search: regex syntax (/pattern/), fuzzy matching (oml → Complete), field-specific filters (priority:high, context:@work), exclusion with -
Task priority levels: Critical / High / Medium / Low / None, with visual indicators and color coding throughout the UI
Snooze: defer tasks by 1h/2h/4h/tomorrow/next week/custom, with automatic filtering and a ⏸ indicator showing remaining time
Analytics dashboard: completion rate, context distribution, priority breakdown, overdue counts - displayed as a formatted multi-table panel via Spectre.Console

In the same pass it added colored status indicators, a task detail view, keyboard shortcut help, and context autocomplete infrastructure. 5 new services, 1 new command, 11 modified files - all building cleanly with zero warnings. In the meantime, I made a coffee.

What I actually learned

The prompt is the design doc. The quality of what Copilot produced was directly proportional to how precisely I described the user experience I wanted. Vague prompts produced vague code. "Allow me to filter by context" gave me something workable; "I can use make bed @home and it should show all elements containing 'make bed' with the @home context, searched in any word order, case-insensitive" gave me exactly what I needed.

It catches its own mistakes - if you give it feedback. The failed StorageService build was a normal failure mode. What wasn't normal was watching Copilot read the build output, identify the root cause, fix it, and then scan for related issues it hadn't been asked about.

The developer becomes the curator. My job shifted from writing code to knowing what to ask for, recognizing when the output was right, and deciding when to push back. The code I guided into existence is better-structured and more thoroughly documented than most code I write from scratch, simply because Copilot's defaults lean toward clean architecture. All code was reviewed and checked by me. I do not think that any code written by or with an AI tool should end up in a production-ready environment without the manual review of a developer.

Fun fact: Copilot helped me review this, rephrase some weirdly mentioned items and corrected some grammar mistakes. It does more than coding, if used correctly. It does more than coding, if used under supervision. It can be an amazing tool, but no hammer has ever replaced the blacksmith.

Bullet Summarization - Postmark Challenge

Alin Pisica — Fri, 06 Jun 2025 22:20:24 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

Bullet Summarizer is a summarization-as-a-service solution that acts based on email forwarding. The main goal is to drastically reduce the time needed to catch up on lengthy email threads, especially when multiple participants are involved.

The application can be directly integrated into any existing system, leveraging AI capabilities (any LLM can be integrated - ChatGPT has been used for the demo due to ease of implementation). All the data collected can also be stored into a client's databse for future reporting, analysis and tracking.

The core use case consists of saving time and reducing decision fatigue through a clean and structured view on relevant email threads.

Demo

The source code can be found here.

Any user can forward a thread of emails to the following address: 81ec20c617d2beee13278436d818e91c@inbound.postmarkapp.com. Due to domain issues and outbound rules, some users may not receive a reply with the summarization. In this case, the safest way to demonstrate the functionalities would be to replicate the runtime into your own environment. In order to replcate locally, fill in the appsettings.json file with the Postmark and ChatGPT Keys, together with the connection string.

In order to demonstrate the app's functionalities, I have opted for two different scenarios. Each scenario was based on fictive personas, so all names and examples should be taken with a grain of salt. The initial thread will be attached as a spoiler, in order to minimize the content.

In case of failure when sending the results to the user's email, I have created a simple Metabase dashboard that consists of all the tables from the database. All new entries should be automatically added to the dashboard: Metabase Dashboard.

For hosting I used a small Hetzner instance, directly exposing the Metabase UI and the API.

Scenario 1. App Launch - Team discussing bug fixes and timelines

The initial thread of emails:
scenario-1

============ Forwarded message ============
From: AlinPisica WebsiteContact <alin.pisica.web.contact@gmail.com>
To: "testmail janedoe"<testmailjanedoe730@gmail.com>
Cc: "Alin Pisica"<contact@alinpisica.com>
Date: Sun, 01 Jun 2025 22:33:22 +0300
Subject: Re: Urgent: FitFit Launch Status – Bugs Still in QA?
============ Forwarded message ============

Will do, Jane.
I’ll prepare a fallback launch plan (Aug 21) with revised Marketing and QA checkpoints just in case. Will share with you tomorrow morning.
Also, I suggest we lock down any non-critical merges starting Monday. Alin, let’s finalize that cutoff list on our 10AM sync tomorrow.
We’ll make this launch happen 💪

Cheers,
 —
 Mike Rays
 Chief Technology Officer
 📞 +1 (555) 224-7765
 ✉️

În dum., 1 iun. 2025 la 22:33, testmail janedoe < mailto:testmailjanedoe730@gmail.com > a scris:

Thanks both, this gives me more confidence.
Mike – let’s get a contingency plan in place anyway. Can you prep a quick internal doc outlining what the “Plan B” would look like if we needed to delay by 5 days?
Alin – great work jumping on these issues. Please send me a short daily update until the weekend. Doesn’t need to be long – just a few bullet points so I can keep stakeholders in the loop.

Thanks,
 —
 Jane Doe
 Chief Executive Officer
 📞 +1 (555) 010-1987
 ✉️

On Sun, Jun 1, 2025 at 10:32 PM Alin Pisica < mailto:contact@alinpisica.com > wrote:

Hi Mike, Jane,
Quick update on my side:
✅ iOS crash: root cause found (Bluetooth permission regression in the new onboarding flow). Fix is in progress, should be in QA before lunch.
🔄 Sync issue: looks like the wearable module sends a malformed timestamp when the phone app is in background mode. I'm working on a patch that auto-corrects it on the mobile side. ETA: end of day.
If we don’t find anything new, both of these will be resolved this week.
Let me know if anything else pops up.

Best,
—
Alin Pisica
Software Developer
📞 +1 (555) 988-2210
✉️

---- On Sun, 01 Jun 2025 22:31:55 +0300 AlinPisica WebsiteContact < mailto:alin.pisica.web.contact@gmail.com > wrote ---

Hi Jane,

I understand the concern. I’ve already gone through the high-priority issues. Out of the 7:

3 are already in review, fix is done.
2 are visual bugs on smaller Android screens – not launch blockers in my opinion.
1 involves syncing between wearable and mobile – that one needs deeper investigation.
1 crash reported on some iOS builds – flagged by QA yesterday.

Alin is working on the iOS crash right now. I’ll let him chime in on the sync issue.
We should be fine for 16th if we stay focused. I don’t recommend postponing yet.

Cheers,
 —
 Mike Rays
 Chief Technology Officer
 📞 +1 (555) 224-7765
 ✉️

În dum., 1 iun. 2025 la 22:31, testmail janedoe < mailto:testmailjanedoe730@gmail.com > a scris:

Hi Mike, Alin,

I’ve just reviewed the QA dashboard this morning and noticed that we still have 7 open bugs marked as “high priority”. With only 15 days until launch, I’m getting worried.

Can we please regroup and assess:

- Which of these are actual blockers?
- What’s realistically going to be fixed before the 16th?
- Do we need to consider pushing back the launch?

Let’s sync before EOD. I’d appreciate a written update before 2PM so I can align with Marketing.

Thanks,
 —
 Jane Doe
 Chief Executive Officer
 📞 +1 (555) 010-1987
 ✉️

Result:

Result as text:

scenario1text

High-Level Summary:
    The team is working on critical bugs for the upcoming launch and preparing contingency plans. There are discussions on bug fixes, release timelines, and communication updates.

Tone:
    The email exchanges are focused and collaborative, addressing urgent launch preparations and troubleshooting.

Participants
    Alin Pisica (contact@alinpisica.com) - Role: Software Developer
    Mike Rays (mike@fitfitapp.com) - Role: Chief Technology Officer
    Jane Doe (jane@fitfitapp.com) - Role: Chief Executive Officer

Action Items
    Prepare fallback launch plan: Develop a revised launch plan with checkpoints and an August 21 deadline.
    Assigned to: Mike Rays, Due: 2025-06-07

    Finalize cutoff list for non-critical merges: Determine which code merges can be blocked starting Monday.
    Assigned to: Alin Pisica, Due: 2025-06-07

    Send daily update on bug fixes: Alin to provide brief daily status updates until the weekend.
    Assigned to: Alin Pisica, Due: 2025-06-07

    Create contingency plan document: Outline Plan B for a potential 5-day delay in the launch.
    Assigned to: Mike Rays, Due: 2025-06-07

Key Dates and Deadlines
    Fallback launch plan readiness: 2025-06-07

    Final cutoff list for code merges: 2025-06-07

    Daily bug update reports: 2025-06-07

    Contingency plan document completion: 2025-06-07

Bullet Points
    Development team is fixing the iOS crash caused by Bluetooth permission regression and working on a patch for wearable synchronization issues. (Related to: Bug fixes and patches in progress.)

    Seven high-priority bugs are still open; some are review-ready, others require further investigation. (Related to: Current bug status and issue prioritization.)

    Management is considering a last-minute contingency plan for delay but currently aims to proceed as scheduled. (Related to: Risk management and launch planning.)

    Team members are providing daily updates to keep stakeholders informed about progress and issues. (Related to: Stakeholder communication.)

Scenario 2. Mortgage approval - Renegotiation of a property

The initial thread of emails:

scenario-2

============ Forwarded message ============
From: Alin Pisica <contact@alinpisica.com>
To: "testmail janedoe"<testmailjanedoe730@gmail.com>
Cc: "AlinPisica WebsiteContact"<alin.pisica.web.contact@gmail.com>
Date: Sun, 01 Jun 2025 22:39:34 +0300
Subject: Re: Mortgage Credit Approved – Next Steps for Purchase of Property on Linden Street
============ Forwarded message ============

Hi Jane, Mike,

Thank you both – that’s very generous and reasonable. I’m comfortable covering the additional €2,000 from savings and happy we found a middle ground.
Mike – please move forward with the updated paperwork for €153,000 and send over the revised credit agreement when ready.
Jane – I’ll ask my notary to propose a few slots between 6–9 August.
Excited to get this done!

Cheers,
—
Alin Pisica
📞 +40 766 302 118
✉️

---- On Sun, 01 Jun 2025 22:38:56 +0300 testmail janedoe < mailto:testmailjanedoe730@gmail.com > wrote ---

Hi Mike, Alin,

Thanks for the transparency.
Alin – I understand this has been a process for you, and I don’t want to block your efforts. I’m willing to accept €153,000 and move forward, if we can schedule the notary before August 10th. That way I can align with my own moving timeline.
Let’s finalize this – I’d be happy to sell to you.

Best,
 —
 Jane Popescu
 Property Owner
 📞 +40 723 551 449
 ✉️

On Sun, Jun 1, 2025 at 10:38 PM AlinPisica WebsiteContact < mailto:alin.pisica.web.contact@gmail.com > wrote:

Hi Alin, Jane,

Alin – after a quick internal review, we can approve an additional €5,000, bringing your credit ceiling to €153,000, under the same conditions (interest rate and term). However, you would need to cover the remaining €2,000 difference through your own contribution.

Jane – would you consider splitting the difference with Alin to help close the sale? Perhaps meeting in the middle could make this work for both sides.

Let me know your thoughts so we can move quickly.

Regards,
 —
 Mike Rays
 Loan Officer – Residential Mortgages
 FirstBank Europe
 📞 +40 745 882 220
 ✉️

În dum., 1 iun. 2025 la 22:38, Alin Pisica < mailto:contact@alinpisica.com > a scris:

Hi Jane, Mike,

Jane – I respect your position, but this comes as a surprise. We agreed on €148,000 and I’ve already paid for valuation, legal checks, and initiated paperwork with the bank based on that amount.

Mike – Is there any way the bank can increase the approved amount to match the new price? Otherwise, I’d be forced to withdraw.

I still really want the house, but I’m already stretched with my budget.

Thanks,
—
Alin Pisica
📞 +40 766 302 118
✉️

---- On Sun, 01 Jun 2025 22:37:30 +0300 AlinPisica WebsiteContact < mailto:alin.pisica.web.contact@gmail.com > wrote ---

Dear Jane, Alin,

I’m pleased to inform you that the credit application for Mr. Alin Pisica has been officially approved. The credit covers the initially agreed price of €148,000 for the property located at 24 Linden Street.

Next steps:

We can begin preparing the pre-contract.
The notary appointment can be set once Jane confirms availability.
Please confirm if there are any last-minute changes to the agreed terms.

Looking forward to your confirmation to proceed.

Kind regards,
 —
 Mike Rays
 Loan Officer – Residential Mortgages
 FirstBank Europe
 📞 +40 745 882 220
 ✉️

Result:

Result as text:

scenario2text

High-Level Summary:
    Alin agrees to proceed with a property purchase at the approved mortgage amount of €153,000 after some negotiation. The next step is scheduling a notary appointment between August 6-9.

Tone:
    Informal and cooperative tone, with Alin expressing readiness to move forward and finalize the sale.

Participants
    Alin Pisica (contact@alinpisica.com) - Role: Buyer
    Jane Popescu () - Role: Seller
    Mike Rays (mike.rays@firstbankeu.com) - Role: Loan Officer

Action Items
    Send updated credit agreement: Mike to prepare and send the revised credit documents reflecting €153,000 limit.
    Assigned to: Mike Rays, Due: 2025-06-10

    Schedule notary appointment: Jane to propose options for notary appointments between August 6-9.
    Assigned to: Jane Popescu, Due: 2025-07-31

Key Dates and Deadlines
    Notary appointment between: 2025-08-06 to 2025-08-09

Bullet Points
    Alin agrees to move forward with the purchase at €153,000 mortgage limit. (Related to: Alin Pisica)

    The bank approved the mortgage for €148,000 initially, then increased to €153,000 after negotiation. (Related to: Mortgage approval)

Code Repository

The code is structured using a 3 layered architecture, split into three projects: API (that acts as the main app - exposing the API and using the background workers), Core (that hosts all the domain logic, models, types) and Infrastructure (the communications, integrations and processes).

The database migrations are created using DbUp, opting for a simple schema regarding the storage of all the results. No foreign keys or indexes were used in order to keep the system simple for demo purposes, easy to reproduce/run locally and avoid any possible issue regarding database optimizations. All the database migrations are located under Infrastructure/Repository/Database/Scripts. The queries and database access is simplified by using Dapper.

In order to host it on linux as a service, utilities are included into the utils folder (bash scripts for starting, stoping and checking the service's status, together with the service template to run under systemctl).

How I Built It

Tech Stack

Tech Stack used:

.NET 8 for the API, processing and orchestration
PostgreSQL for storing the inbound emails and summarization results (action items, bullet points, etc.)
Structured Chat GPT for the NLP management, understanding and extracting information
Metabase for dashboard visualisation

Architecture

The architecture consists of a .NET app that has the following three functionalities:

a publicly exposed API endpoint that is used as a webhook for Postmark's connectivity
a background worker that retrieves unprocessed emails from the database and stores them into an in-memory queue
a background worker that retrieves data from the in-memory queue, computes the summarization, saves the results into database and sends the email to the user

Structured GPT Response

In order to easily obtain a consistent response, I have leveraged the functionality of structured answering of ChatGPT. In this way, every response is returned using a stable data structure that can be easily interpreted and mapped to our needs.

The response schema can be found here

Upcoming features

Since I loved working with Postmark, I am thinking of extending the current product with the following functionality:

update the reasoning service to easily integrate with multiple LLM providers
integrate directly with Google Sheets and Google Tasks to directly upload and manage data based on email interactions
create multiple forwarding rules and differential results for all participants (each thread participant will receive its own copy of the summarization but only with its personal interests)
add follow up functionalities - the system should follow up on previous summarizations to make sure that all the action items have been completed

Why changing my job changed my perspective

Alin Pisica — Mon, 22 Jun 2020 03:46:24 +0000

The further you get away from yourself, the more challenging it is. Not to be in your comfort zone is great fun. - Benedict Cumberbatch

The beginning

Everything started 2 years ago, when I left my freelancing passion and moved to a normal developer position in a small company. Everything worked fine, I was a little bit familiar with the technology stack, but there were still a lot of things to learn. As said, it was done. Months passed by and everything became so easy that I was thinking "Wow, I am so good at this."
Oh... I was so wrong! I was thinking that I am good because I kept working on the same project for a long period of time, doing a lot of refactoring and repetitive task and not so much thinking before coding.

This gave me a lot of confidence, I knew how everything should be done, each new feature would be just a small change in the whole project so it wouldn't affect me a lot. Every day I was more and more efficient, everything was easier from time to time... or at least this is how it seemed.

And so a new adventure begins

Then, an opportunity came. A remote job, still a flexible program (being a 2nd year in university had a lot of influence on my working schedule). With this being said, so it started. A new job, a new adventure, I was thinking I am good at what I am doing then... one week in and I was "Where am I? Why I don't know how to do this, even though I have worked with this stack?". And so the questioning started. I was so wrong in so many ways that I didn't know where to start. Am I dumb? Everything I have learned is useless? Is this something that I will never be able to do it? Is this the end of my career, even though I am only 20?

The answer was no. It was a little bit harder than expected, but after 3 months here I already can say that my evolution has went from ground-bottom to the sky faster than expected. For now, I came with a conclusion that I would highly tell to anyone else that I meet: you still young? Change jobs, seek adventures, try something new. You will never know everything and this is the time to find everything you don't and fix it!.

Step out of your comfort zone. Do it and do it often. Seek discomfort, try something new, do something that you haven't done before, try to bring some new things into your life.

If you wanna do it, you gotta do it right
Let's get to it, gotta fight the fight - https://www.youtube.com/watch?v=jbanrxTqlEY

What 20 hackathons taught me?

Alin Pisica — Wed, 21 Aug 2019 17:14:26 +0000

Team[TeamName] - from not having a name to making one.

This year was a productive one. Excepting the internship and finishing my first year in uni, I managed to participate in 20 hackathons, more than 75% of them being finished with a prize (mostly first).

How it all begun?

Take three wannabe programmers, give them a beer while having a discussion, let them find an ad about and hackathon a make them join. That's where it all began. We had no idea about how we work together, how we get along when writing code or how we think. We went to our first hackathon, an algorithmic-only one where we finished on the 4th position, considering the fact that none of us had a background in algorithmics, we had no access to the internet and we were forced to use only one computer. That's where the fun part came in. We managed to understand that we have a lot of fun working together, and we kept doing it.

How it evolved?

The next hackathon, where we had to make a Mortal Kombat bot (which you can see in action here), we managed after long 24 hours to win the first prize. The smile came, we realized that this is for us. The next months were full of hackathons, the weekend after weekend, even 2 hackathons on the same day (a 24 hours one and a 12 hours one), one of them finishing with first prize.
We built everything that came in our minds, starting with Mortal Kombat bots, continuing with apps for monitoring pollution in smart cities, apps for monitoring people's movement in hospitals, a pair of AR glasses that displays on the lens the details about the car you are looking at etc.

What's the biggest realization that came from hackathons?

A startup. After 24 hours at the biggest bank in Romania, we managed to win the 2nd prize and get involved in a startup incubator with the idea. At the moment, it is in development, but for this, another article is coming ^_^.

What I learned?

Have fun. No matter what you do, if you are trying to play 100% serious you are not going to make it. Or maybe you will, but the satisfaction will be less.
Risk. Don't get discouraged. We heard "You are not gonna' make it" / "It's impossible to finish it so fast" so often that became a habit. We were asked to build prototypes and we delivered fully functional apps, just because we risked it and wanted to prove that we can actually do it.
Travel. Some of the hackathons were not close to home, we had to travel, 14 hours in a train without a bed, food or anything, traveling for the first time with a plane (the train experience taught us that a 40 mins flight is better than a 14 hours train travel) and I discovered a lot of places. One of the advantages of the programming world is that you can work from anywhere. Do it!
Meet people. No matter where you are, no matter if the persons around you are "bigger" than you, get in touch with them. Your network will evolve so fast that you will have friends from every domain, who can teach you a thing or two and put you on a good track, especially if you are at the beginning.
Sleep is for the weak. Kidding. Or not. Depends. 2 hours are enough.

In the end, I'll leave you with a pic of the best team that I've ever been a part of.

How to make Conway's Game of Life

Alin Pisica — Mon, 04 Jun 2018 21:30:49 +0000

The Game Of Life, is a cellular automation devised by the British mathematician John Horton Conway in 1970.

The so-called game has no players, it's evolution being determined by its initial state, being required no more inputs. The objective is to see how an initial grid-based configuration evolves based on some conditions that are pre-implemented inside it.

Even if it may seem hard at the beginning, it's one of the fastest-to-implement and easy-to-understand visualizations.

How are we making it?

All we need is C++, SFML Library (for graphics, of course, who would like to see a game in a Terminal?) and a little bit of patience.

We start with a two-dimensional orthogonal grid array of cells (which are going to represent our life forms), being implemented in their own class, with not-so-many methods (all they have to do is to be able to draw themselves to the window, die, be born, and changing states in the initial-setup part of the game).

Cell's components:

isAlive() > return if the cell is alive or not
getX(), getY() > get cell's coordinates
draw() > draw the cell on screen
setPosition() > set position on screen
kill(), born() > change cell's state to alive or not alive
update() > get cell's input from window (change state on click)

After we implemented the cell class, the rest of the game is easier than you might think. In the game-loop, all we have to do is just follow 3 steps:

Clone the grid in a gridCopy.
Traverse the grid and update the gridCopy based on the current conditions (we have to update them in the gridCopy, because once we kill/create a new cell in the main grid, number of neighbors of the next cell will be smaller than real) a) Any live cell with fewer than two live neighbors dies, as if by underpopulation. b) Any live cell with two or three live neighbors lives on to the next generation. c) Any live cell with more than three live neighbors dies, as if by overpopulation. d) Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.
Move the gridCopy into the main grid.

You can see the full code on GitHub and the practical demo of the application on YouTube. Have fun coding and, until next time, keep smiling, life is too short to have bugs!

You can find the original article on MY BLOG.

How to make a Maze Generator

Alin Pisica — Mon, 04 Jun 2018 21:28:00 +0000

What are we going to make? A maze generator. How? Let's see.

What do we need?

We're going to make the project in C++, using SDL Library for graphics. They have a really nice tutorial on setting up SDL, which is really easy and fast, right here.

Let's code!

First of all, what do we understand by maze? Hmmm... Let's take a look at the dictionary: a confusing network of intercommunicating paths or passages. I don't like how it sounds, let's make it simpler: a collection of rooms that have or have not a connection. So, how are we going to structure this? In a normal way, it can be structured as a graph, but for the simplicity of this problem, we're gonna make it as an NxN grid.

Now comes the fun part, where the thinking is happening... What should contain every cell from the grid? Let's call it a room. What does a normal room? Walls. So, theoretically, our connections between the rooms, are represented by walls. .

Now, how do we connect 2 rooms? By removing the wall between them. And how we can do that? By removing two walls. Now here comes the question "Wait, between two rooms we have two walls". Theoretically no, but in this model, yes, because when you remove the left wall of a room, you have to remove the right wall of the room situated at it's left. Kind of confusing, but this image will most probably make it clearer.

How does the algorithm look like?

The algorithm is based on a backtrack solution (Also, you can find Kruskal and Prim's version on randomizing a maze) and it works like this:

Pick one room, make it the starting point and mark it as visited
While there are unvisited rooms
1. If the current cell has any neighbors which have not been visited
  1. Choose one random neighbor that hasn't been visited yet
  2. Push the current room to the stack
  3. Remove the wall between the current room and the next stack (bye bye walls, welcome roads)
  4. Make the current cell the chosen one and mark it as visited
2. Else If there are no unvisited neighbors and stack is not empty
  1. Pop a cell from the stack
  2. Make it the current cell

It's a very simple algorithm, that can make some very interesting visual effects and be helpful in some situations... And with this, my childhood thinking that mazes from books were manually designed is ruined. You can check it out here and see it in action here.

You can find the original article on MY BLOG.

How to prepare for a competitive programming contest

Alin Pisica — Fri, 19 Jan 2018 19:11:17 +0000

What is this about?

Tomorrow in the morning I'll have a regional programming contest, where I'm at my 4th participation. Overall, I got into the competitive programming area like 4 years ago and I think I learned some tricks that might help you with getting rid of panic and stress.

What is a competitive programming contest?

You receive few algorithmic problems and you are required to solve them as efficient and optimized you can, considering the limit times and memory given to you.

Now, here comes the fun part:

1. If it's a given theme, focus on it, but don't forget the others

If the contest is based on some "ideas" or only on some data structures or algorithms (for example, all of the problems are graph-related), try to focus on it but never, absolutely never, don't forget the other ones. You don't know when you have an opportunity to use something that you wouldn't expect to.

2. Don't stress yourself

Even if it's a contest, it is not meant to make you stressed. Before, while it happens and even after it you have to be as chilled as you can, and try not to get make yourself some problems when they shouldn't be here.

3. One day before, don't touch algorithms

Don't. Just don't. You will keep your eyes and mind focused more than ever on the things you do the day before, and it might screw you up. Do anything else, take a walk, read a book, just don't touch the algorithms or problems. Maybe for some of you, this might be helpful, but for the big majority, this ain't helping at all.

4. Split the problem

A lot of competitive challenges, come with a very big description, that might get you scared. Get a pen and a paper, read a phrase and shortly remove the unnecessary words and try to translate them into a more "understandable" logic
For this, I recommend all the tutorials from TopCoder.

5. Don't miss the fun

Even if it's a contest, it is a great opportunity to meet new people with same passions like you. Don't forget to talk, socialize and have fun (and yes, even problems are fun).

In the end, I can tell you this: stay focused but don't go obsessed with it. Take your time and even if you don't get it the first time, keep working and everything will come to the expected end. Until next time, good luck and happy coding!

My real journey begins now

Alin Pisica — Mon, 15 Jan 2018 18:18:37 +0000

Greetings! I consider, that first, it would be better if I introduce myself. So, overall, I am an 18 years-old Romanian guy, passionated by everything that is related to the science side. At 3 years old I got my first PC, and that's how it all started. I learned to use it alone (no-one was there to teach me) and also, I started learning English alone (by using it). So, until now, everything kept on: I'm a self-taught programmer (if we can call it that, considering that I learned pretty much from documentation and other's code) and, also, I'm gonna apologize for my bad English (I learned it alone).

Four years ago, I got into the programming world, by discovering the Pascal language. I started learning it and, in the meantime, got in contact with many other languages. Now, I use as the main-2-languages, a nice combo that goes well hand-in-hand (C++ and Node). I got involved in many projects and also managed to win some important competitive programming contests in my country.

Now, some while after trying to discover everything on my own, I'm gonna try to take it to the next level. I'm gonna try to make this not only a passion but a profession. So far, I'm gonna try to keep you guys updated on my projects and learning process, hoping that you will be willing to give me some tips and tricks. That would be until now, I'm gonna come back with a new post, that will either keep you intrigued or bored. Until then, happy coding!