<commit_before>Intercom Export
===============

System to help export Intercom.io conversations into Zendesk tickets. The codebase is designed to be adaptable
for importing into other systems or even exporting from things other than Intercom.

Usage
-----

```
$ intercom_export --intercom-app-id <APP ID> --intercom-api-key <APP KEY> \
                  --zendesk-address <DOMAIN>.zendesk.com --zendesk-username <USERNAME> --zendesk-token <TOKEN>
```

Design
------

The `coordinator` is the heart of the import. This breaks the problem down into several discrete stages.

 1. Source - This is simple an enumerable, currently this is an enumerable of all Intercom conversations
 2. Splitter - This takes an item from the source and splits it into several `parts` that make syncying
    easier. For instance an Intecom conversation will be split into all of the users involved in the
    conversation, and the conversation itself with the users replaced by references.
 3. Finder - This takes a part (something in the land of Intercom), and tries to find it's equivalent in
    Zendesk
 4. Differ - This compares the Intercom part, with the search result from Zendesk and then creates commands.
 5. Executor - This executes each command.

The idea of breaking it into these components is to allow other front-ends (Intercom), to be slotted in by
only adding a few classes. It should also be possible to slot in other back-ends (Zendesk) with a small amount
of modification.

Tests
-----

$ rspec

Status
------
<commit_msg>Improve README<commit_after>Intercom Export
===============

System to help export Intercom.io conversations into Zendesk tickets. The codebase is designed to be adaptable
for importing into other systems or even exporting from things other than Intercom.

Usage
-----

```
$ intercom_export --intercom-app-id <APP ID> --intercom-api-key <APP KEY> \
                  --zendesk-address <DOMAIN>.zendesk.com --zendesk-username <USERNAME> --zendesk-token <TOKEN>
```

Design
------

The `coordinator` is the heart of the import. This breaks the problem down into several discrete stages.

 1. `source` - This is simple an enumerable, currently this is an enumerable of all Intercom conversations
 2. `splitter` - This takes an item from the source and splits it into several `parts` that make syncying
    easier. For instance an Intecom conversation will be split into all of the users involved in the
    conversation, and the conversation itself with the users replaced by references.
 3. `finder` - This takes a part (something in the land of Intercom), and tries to find it's equivalent in
    Zendesk
 4. `differ` - This compares the Intercom part, with the search result from Zendesk and then creates commands.
 5. `executor` - This executes each command, replacing references to Intercom items, with ids from Zendesk.

The idea of breaking it into these components is to allow other front-ends (Intercom), to be slotted in by
only adding a few classes. It should also be possible to slot in other back-ends (Zendesk) with a small amount
of modification.

Tests
-----

```
$ rspec
```

Status
------

{'fraction_non_alphanumeric': 0.08056265984654731, 'fraction_numerical': 0.00319693094629156, 'mean_word_length': 3.554585152838428, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '847846', 'n_tokens_mistral': 845, 'n_tokens_neox': 809, 'n_words': 434}