• Чем Slack лучше Telegram?

    KazeZlat
    @KazeZlat
    Погромист-затейник
    Вообще, телеграм и слэк сравнивать несовсем корректно, ибо использование ТГ для работы в качестве основного мессенджера - боль, если вам требуется больше одной конфы.

    Главное отличие - ваша рабочая и личная переписка разделена. В телеграме мем от друга в личку может занять вас на пару минут. В слэке тоже можно, но это будет значить, что ваш коллега целенаправленно хотел вас порадовать свежим мемасиком.

    В слэке компании разделены серверами, и это больше похоже на Discord, только для работы. На каждом сервере есть каналы, для каждого канала можно очень гибко настроить уровни доступа и режим уведомлений (даже с учётом временной зоны работника, никто вам ночью не пришлёт нервное письмо с правками)

    Пробежимся по плюсам:
    1. Каждый работник может настроить себе кастомные уведомления. Типа
    уведомлять меня, когда кто-нибудь напишет "синхрофазотрон" или назовет меня по имени
    2. Можно шарить снипеты с подсветкой синтаксиса множества языков и другие вложения
    3. Поддержка сторонних сервисов. Ссылки с гуглодоков и других сервисов могут обрабатываться прямо в слэке (например, можно отметить выполненным таск в Asana сообщением в Slack, некоторым удобно)
    4. Адекватный бот, с веб-хуками и прочими плюшками.

    А теперь про минусы:
    1. Нативное приложение очень заметно жрет оперативку
    2. Бесплатно доступны для поиска только последние 10000 сообщений (не такой уж прям критичный минус, если не держать флудилку на том же серваке)
    3. Нет стикерпаков и видеосообщений в кружочках =(
    Ответ написан
    Комментировать
  • Чем Slack лучше Telegram?

    chupasaurus
    @chupasaurus
    Сею рефлекторное, злое, временное
    Чего навспоминал за 5 минут:
    • Статусы пользователей
    • Ветки комментариев внутри канала
    • Сниппеты
    • Подсветка синтаксиса для кучи языков
    • Поддержка в куче различных проектов без нужды в напильнике, зачастую самими авторами проектов
    • Возможность работы без мыши
    • Гостевые доступы до определённых каналов
    • Настройка уведомлений шире, чем mute channel :)
    Ответ написан
    8 комментариев
  • С чего начинать проектировать приложение?

    max-kuznetsov
    @max-kuznetsov
    Главный IT-архитектор
    Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, и кто/что будет их потреблять.

    Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.

    Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

    Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

    Между слоем сервисов и слоем доступа к данным нарисуйте большой контур и назовите его слоем бизнес-логики. В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.

    Теперь справа нарисуйте несколько длинных прямоугольников снизу доверху и написшите в них: логирование, конфигурация, мониторинг производительности, обработка исключений и что-то ещё, что является общей инфраструктурой (или сквозной функциональностью) для всех слоёв вашей программы.

    Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

    А дальше - детально прорабатывайте каждый маленький квадратик. Всё.
    Ответ написан
    2 комментария