# Building a GitHub Activity CLI - A Ruby Journey

## Links

* GitHub Repo → [https://github.com/sulmanweb/github-activity-cli](https://github.com/sulmanweb/github-activity-cli)
    
* Roadmap.sh Task → [https://roadmap.sh/projects/github-user-activity](https://roadmap.sh/projects/github-user-activity)
    
* My Solution for UpVotes → [https://roadmap.sh/projects/github-user-activity/solutions?u=67124acb791f57dd60b7e0e4](https://roadmap.sh/projects/github-user-activity/solutions?u=67124acb791f57dd60b7e0e4)
    

---

Have you ever wanted to quickly check someone's GitHub activity right from your terminal? I recently took on this challenge by building a simple yet powerful CLI tool in Ruby. Let me walk you through how I built this GitHub Activity CLI, sharing both the technical details and lessons learned along the way.

## Project Overview

The GitHub Activity CLI is a command-line tool that fetches and displays a user's recent GitHub activities. It's built with Ruby and follows clean code principles while keeping the implementation straightforward and maintainable.

## The Challenge

The project requirements came from [roadmap.sh's GitHub User Activity project](https://roadmap.sh/projects/github-user-activity). The main goals were to:

* Fetch a user's recent GitHub activities using the GitHub API
    
* Display the activities in a readable format
    
* Handle various types of GitHub events (pushes, issues, PRs, etc.)
    
* Implement proper error handling
    

## Project Structure

I organized the code into a clean, modular structure:

```ruby
├── bin
│   └── github-activity    # Executable CLI script
└── lib
    ├── activity_formatter.rb   # Formats different event types
    ├── github_activity.rb      # Main application logic
    └── github_client.rb        # Handles GitHub API communication
```

## Technical Implementation

### 1\. The GitHub Client

The heart of the application is the `GitHubClient` class that handles all API communications:

```ruby
class GitHubClient
  BASE_URL = 'https://api.github.com'

  def fetch_user_events(username)
    uri = URI("#{BASE_URL}/users/#{username}/events")
    response = make_request(uri)
    
    case response
    when Net::HTTPSuccess
      JSON.parse(response.body)
    when Net::HTTPNotFound
      raise "User '#{username}' not found"
    else
      raise "Failed to fetch GitHub activity: #{response.message}"
    end
  end
end
```

I used Ruby's built-in `Net::HTTP` library to keep dependencies minimal. The client handles basic error cases and returns parsed JSON data.

### 2\. Event Formatting

One of the interesting challenges was formatting different types of GitHub events. I created a dedicated `ActivityFormatter` class that handles this using a clean pattern:

```ruby
class ActivityFormatter
  def format(event)
    case event['type']
    when 'PushEvent'
      format_push_event(event)
    when 'CreateEvent'
      format_create_event(event)
    when 'IssuesEvent'
      format_issues_event(event)
    # ... other event types
    end
  end
end
```

This approach makes it easy to add support for new event types and keeps the formatting logic organized.

### 3\. The Main Application

The `GitHubActivity` class ties everything together:

```ruby
class GitHubActivity
  def initialize(username)
    @username = username
    @client = GitHubClient.new
    @formatter = ActivityFormatter.new
  end

  def run
    events = @client.fetch_user_events(@username)
    if events.empty?
      puts "No recent activity found for user '#{@username}'"
      return
    end

    display_events(events)
  end
end
```

## User Experience

I focused on making the CLI intuitive and user-friendly. Users can simply run:

```bash
./bin/github-activity username
```

The output is clean and readable:

```ruby
Recent GitHub activity for sulmanweb:
--------------------------------------------------
Pushed 2 commits to sulmanweb/project
Created branch in sulmanweb/new-repo
Closed issue 'Bug fix needed' in sulmanweb/app
```

## Learning Outcomes

Building this CLI taught me several valuable lessons:

1. **API Integration**: Working with the GitHub API showed me the importance of good error handling and response parsing.
    
2. **Code Organization**: Breaking the functionality into separate classes made the code more maintainable and testable.
    
3. **User Experience**: Even for a CLI tool, user experience matters. Clear output and helpful error messages make a big difference.
    

## Supporting the Project

Want to help make the GitHub Activity CLI even better? There are several ways you can contribute:

### Financial Support

* ⭐ Star the repository to show your support
    
* 💝 Consider upvoting my solution at [GitHub Activity CLI solution page](https://roadmap.sh/projects/github-user-activity/solutions?u=67124acb791f57dd60b7e0e4)
    
* 🎁 Share the project with your network
    

### Technical Contributions

* 🐛 Report bugs and suggest features through GitHub Issues
    
* 🔧 Submit pull requests for bug fixes or enhancements
    
* 📚 Help improve the documentation
    
* 🌐 Help with translations if you speak multiple languages
    

## Future Improvements

While the current version works well, there's always room for improvement:

* Add authentication to handle API rate limits
    
* Include more detailed event information
    
* Add filtering options for specific event types
    
* Implement caching for faster repeated queries
    

## Getting Started

Want to try it out? Here's how:

1. Clone the repository
    
2. Make the CLI executable: `chmod +x bin/github-activity`
    
3. Run it: `./bin/github-activity <username>`
    

## Conclusion

Building this GitHub Activity CLI was a great exercise in creating a focused, useful tool while maintaining clean code practices. It shows how a relatively simple idea can be turned into a practical utility that others can use and build upon.

The source code is available on GitHub, and I welcome any feedback or contributions from the community. Happy coding! 🚀

---