Git для начинающих. Урок 6.
git push и git pull
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.
Что такое push (пуш)
Зачем пушить на сервер
Когда пушить на сервер
Когда сделали новый коммит или несколько коммитов
Как узнать, что есть незапушенные коммиты
В командной строке набрать git status
Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая
«is up-to-date» означает, что у нас нет незапушенных коммитов
master и origin/master
git push в терминале
Как пушить в PhpStorm
Что такое pull (пулл)
Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.
Зачем пулиться с сервера
Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах
git pull в терминале
Как пулить в PhpStorm
Когда что-то пошло не так.
Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры
git push rejected
Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое
Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?
Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.
Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.
Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.
Как избавиться от мердж-коммита
Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.
При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.
Мердж-коммит в PhpStorm
PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.
Что могу посоветовать
Если мы работаем в одиночку, то удаленный репозиторий нужен только для сохранения резевной копии. Скорее всего, мы будем в него только пушить.
Но при работе в команде имеет смысл подумать над такими вещами:
Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.
В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.
Понимаем сленг программистов: мини-словарь для начинающих разработчиков
Начинающие разработчики не сразу понимают старших товарищей. Фразы вроде «я апишку свитчнул» или «заимпорти другую либу» звучат для новичков как лекция по математическому анализу для первобытного человека. Поэтому мы решили сделать небольшой словарь профессионального сленга программистов.
Слова и фразы в словаре отсортированы по алфавиту. Кстати, словарь можно дополнять. Пиши в комментариях термины, с которыми вы сталкивались на работе.
Аджайл — от англ. Agile. Общий термин, описывает ценности и принципы гибкой разработки программного обеспечения, а также практические подходы к разработке. Понятие Agile стало популярным после публикации Манифеста гибкой разработки программного обеспечения в 2001 году.
Айдишник — id, идентификатор.
Альфа — этап разработки программного обеспечения, на котором разработчики добавляют в программу новые функции, а тестировщики испытывают программу. Это внутренний или непубличный этап.
Апишка — API, программный интерфейс приложения или интерфейс прикладного программирования.
Аутсорс — аутсорсинг, передача компанией части операционной деятельности другой компании.
Адаптив — адаптивный дизайн, адаптация интерфейса к использованию на разных экранах.
Баг — от англ. Bug — жучок, клоп. Ошибка в программе.
Бахнуть — что-то быстро сделать, изменить или дополнить функциональность приложения.
Бета — бета-версия, приложение на стадии публичного тестирования.
Бот — сокращение от «робот». Ботом называют программу, которая автоматизирует интерфейс. Пример — автоответчик в чате.
Бэкенд — от англ. Back-end. Программно-аппаратная или серверная часть приложения.
Бэкап, бэкапить — резервная копия или процесс создания резервной копии приложения.
Ворнинг — от англ. Warning — предупреждение. Предупреждающее сообщение в интерфейсе.
Войтивайти — шуточное, обозначает процесс переквалификации далёкого от сферы IT специалиста в разработчика.
Выкатить — сделать доступным для пользователей. Например, «выкатили новую версию сайта» значит сделали новую версию сайта доступной для пользователей.
Выпадашка — выпадающее меню, то же, что и «дропдаун».
Галера — компания, в которой платят низкие зарплаты и не ценят разработчиков.
Гит — система контроля версий Git или сервис GitHub.
Г****окод — плохой, некачественный код. Объяснение термина есть в статье нашего студента.
Градиент — плавный переход из одного цвета в другой.
Движок — в веб-разработке так называют системы управления контентом.
Дебажить — устранять ошибки, баги.
Деплой, деплоить — развёртывание, публикация рабочей версии приложения. Пример: задеплоить сайт — перенести сайт с тестового на рабочий сервер, сделать его доступным для пользователей.
Джун, джуниор — от англ. Junior. Младший разработчик. Специалист без опыта или с минимальным опытом работы.
Дезигнер — презрительно-снисходительное название дизайнера.
Драй — от англ DRY, don’t repeat yourself. Принцип программирования, предлагающий избегать повторений кода.
Дропдаун — выпадающее меню, то же, что и «выпадашка».
Жаба — язык программирования Java.
Жабаскрипт — язык программирования JavaScript.
Залить — загрузить. Например, «залить файлы на сервер».
Запилить — сделать что-то, добавить какую-то функциональность.
Змея — язык программирования Python.
Исходник — файлы, в которых находится исходный код приложения, или сам исходный код.
Итерация — повторение. «Мы сделали несколько итераций» — мы повторили шаг несколько раз.
Коммит, коммитить — от англ. To commit — совершать. В контексте работы над приложением — сохранять код в репозитории.
Костыль — код, который нужен, чтобы исправить несовершенство ранее написанного кода.
Это интересно На Хекслете есть раздел с бесплатными курсами. Здесь есть курсы по логике, английскому языку, операционным системам, по языкам и инструментам программирования. Регистрируйтесь и учитесь бесплатно!
Либа — от англ. Library — библиотека. Речь идет о библиотеках кода, например, React.
Линтер — общее нарицательное название программ, которые анализируют код и предупреждают разработчика об ошибках.
Лист — от англ. List — список.
Локалка — локальный. Например, локальный сервер или сеть.
Мидл — от англ. Middle — средний. Уровень разработчика, следующий за джуниором. Опыт и уровень знаний миддла позволяет ему самостоятельно решать серьезные задачи.
Мёржить — от англ. Merge, сливать. Речь идет об объединении или слиянии веток кода.
Меншить — от англ. Mention — упоминание. Речь идёт об упоминаниях в чатах или соцсетях. «Менши меня, когда будет готово» значит «упомяни меня, когда будет готово».
Навбар — навигационный блок на сайте или в интерфейсе программы.
Накатить — внести изменения, задеплоить новую версию приложения. Противоположное термину «откатить».
Откатить — удалить изменения, вернуть предыдущую версию приложения. Противоположное термину «накатить».
Ось — операционная система.
Падаван — ироничное название стажёра или джуниора.
Пилот — пробная (пилотная) версия продукта.
Питон — язык программирования Python.
Подвал — то же, что и «футер». Элемент структуры страницы, который находится в нижней части и содержит служебную информацию.
Поплыла вёрстка — некорректное отображение страницы в браузере.
Продакшн или продакшен (продакшн-код) — обозначение кода для рабочей версии приложения.
Пушить — использовать команду push, публиковать что-то.
Пэхапэ — язык программирования PHP, то же, что и «пыха».
Пыха — язык программирования PHP, то же, что и «пэхапэ».
Релиз — программное обеспечение на стадии публичного использования. Стабильная версия программы, которая прошла тестирование.
Рекурсия — описание процесса с помощью самого процесса. Например, выражение «рекурсивный вызов функции» описывает ситуацию, в которой функция вызывает сама себя.
Репа — репозиторий, хранилище данных. Например, код программы можно хранить в репозитории на GitHub.
Ридми — файл Readme, в котором содержится информация о программе.
Ругаться, например, линтер ругается — сообщения об ошибках в коде, работе сервиса и так далее.
Сабж — от английского Subject — тема, предмет. «По сабжу» — по теме обсуждения.
Свитчнуть, свичнуть — переключить. От английского switch.
Сетка — модульная сетка, используется для дизайна и вёрстки страниц.
Сеньор, синьор — от англ. Senior — старший разработчик.
Стек — изначально абстрактный тип данных. В разговорной речи используется для обозначения списка технологий, которые использует разработчик или компания. Пример: «Наш стек — HTML/CSS, JavaScript, React».
Софт — от англ. Software — программное обеспечение.
Софт-скилы — от англ. Soft skills — знания и качества специалиста, прямо не связанные с профессиональной деятельностью. Примеры: коммуникабельность, проактивность.
Темплейт — от английского template — шаблон.
Тестировщик — специалист по тестированию программного обеспечения.
Тимлид — от английского Team leader — руководитель команды. Координатор группы программистов.
Убить — удалить что-то. Например, «убить профиль» означает удалить профиль.
Фидбек — от англ. Feedback — обратная связь.
Фича — функция, возможность. От англ. Feature.
Фреймворк — от англ. Framework — каркас. Инструмент разработки, набор типовых шаблонных решений, упрощающих работу программиста. Примеры: Laravel, Bootstrap.
Фронтенд — от англ. Front-end — клиентская часть приложения.
Хатэмээль, хатээмэль — HTML, язык гипертекстовой разметки.
Хардкодить — статически прописывать в коде данные, которые должны вычисляться динамически. Плохая практика, антипаттерн в программировании.
Хацкер, кулхацкер — ироничное название начинающего специалиста, который считает себя опытным программистом. От английского hacker и cool hacker.
Хедер, хэдер — элемент структуры веб-страницы, находится в верхней части и содержит логотип, меню, служебную информацию.
Цэмээс, цээмэс — от англ. CMS — content management system, система управления контентом.
Цээсэс — от англ. CSS — Cascading Style Sheets, каскадные таблицы стилей.
Юзать — от английского to use — использовать.
Ява — язык программирования Java.
Яваскрипт — язык программирования JavaScript.
ЯП — язык программирования.
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Способы взаимодействия сервисов друг с другом. Пулинг/пуш. Достоинства/недостатки. Выбор
Курьер доставил заказ. По смене статуса заказа надо уведомить заинтересованные стороны об этих событиях.
Клиент отправляет сообщение в чат поддержки. Нужно уведомить сервисы поддержки о поступивших данных от клиента.
Построение отчёта завершено. Ожидающий отчёт пользователь может его загрузить. Надо его уведомить об этом.
Знакомые/типовые ситуации. Одному сервису надо уведомить другой (другие) о происшедших событиях.
Давайте немного усложним:
Какие способы уведомления есть?
Активность со стороны сервера
Это, в общем-то, типовое решение. Сервер держит список заинтересованных сторон. По мере появления событий выполняет HTTP-запросы к клиентам.
Подвариант этого решения: Websocket. Сервер отправляет события в сокеты всем подписанным сторонам.
Повторы, обработка ошибок
Рано или поздно любой TCP/HTTP-канал сталкивается с недоступностью другой стороны. Что делать после возникновения ошибки? Повторять запросы? Что делать с вновь поступающими запросами? Ждать, пока успешно выполнятся предыдущие?
Рассмотрим виды ошибок:
Получив неустранимую ошибку, клиент может только записать её в лог. То есть, если полная остановка доставки сообщений не приемлема, то, получив неустранимую ошибку, типовым решением будет считать, что «уведомление доставлено», и переходить к доставке следующих уведомлений. Вероятно, это единственный нормальный путь.
Идя по этому пути, надо постоянно и внимательно следить за мониторами таких ошибок. Анализировать трафик на тему «почему возникла неустранимая ошибка?» и «можно ли жить дальше с этой ошибкой».
Но это не самая большая проблема.
Более интересными являются проблемы:
500-е ошибки
Мы выполняем запрос-передачу данных для сервера X. Происходит 500-я ошибка. Что это?
Возможны два варианта:
Сервис-приёмник данных по какой-то причине именно сейчас не работает (перегружается, переключается БД итп). В этом случае повтор запроса в дальнейшем приведёт нас к успеху.
В сервисе допущена ошибка, приводящая к 500. В этом случае, сколько бы повторов мы ни сделали, до исправления кода в приёмнике ситуация не изменится.
То есть, по повторяемости запросов ошибки у нас делятся на три вида:
Те, которым повтор поможет (сетевые, устранимые 500-ки).
Те, которым повтор не поможет, но выглядят как те, которым поможет (неустранимые 500-ки).
Те, которым повтор не поможет (например 40x-ки).
Разрабатывая политику повторов, помимо указанной проблемы, имеем ещё множество других проблем:
Как часто повторять запросы?
Не будем ли мы «укладывать» внешний сервис, повторяя запросы?
Не будем ли сами «укладываться», если одна из внешних систем по какой-то причине имеет некорректный TCP-стек ( iptables DROP )?
Если посмотреть на систему повторов запросов, то обнаружится, что практически в каждом случае она выбирается индивидуально.
Если сервис, генерирующий событие, и занимается доставкой его до заинтересованных сторон, то имеем
минимальный лаг доставки
минимальная нагрузка на хранилище сообщений;
необходимость повторов в случае неуспеха доставок
необходимость ведения реестра, кому что доставлено и кому что нужно доставить
двусмысленность некоторых ошибок: непонятно, можно (нужно) ли повторять, или нет
система повторов может быть причиной DDoS для клиентских сервисов.
Также есть некоторое количество организационных минусов:
После того, как клиент прекратил де-факто работу (тут два варианта: сервера выключены, сервера не выключены), система продолжает доставлять ему уведомления.
Вебсокет в режиме клиент-сервер
Часть описанных проблем решает постоянное соединение, инициируемое клиентом. Однако именно часть.
Пулинг
Достоинства пулинга
Максимально быстрое восстановление работоспособности после факапов.
Недостатки пулинга
минимальный лаг доставки сообщений равен интервалу пулинга, который обычно выбирается ненулевым
множество сервисов пулящих один создают существенно бОльшую нагрузку, нежели случай с активным сервисом. Сервисы, для которых нет сейчас никаких сообщений, всё равно создают нагрузку на подсистему доставки сообщений.
Ещё один неочевидный, организационный недостаток пулинга: часто способ получения новой порции данных связан со структурой хранения данных.
отсутствие двусмысленности, описанной выше
наиболее быстрое восстановление работоспособности после сбоя
максимальная независимость от сетевого стека TCP на клиенте
нет необходимости хранить/майнтенить список клиентов.
Лаг доставки
Как правило, запросы для пулинга формулируются как «есть ли данные для меня; если есть, то какие?». Такие запросы (в случае, если они некорректно спроектированы) зачастую имеют следующие проблемы:
при перегрузках количество данных в ответе может расти, или время выполнения запроса ухудшаться.
В случае, если получение очередной порции данных сопровождается простой выборкой из BTREE индекса, то и ответ на вопрос «есть ли данные?», как правило, сравнительно бесплатен. Об индексах поговорим ниже.
А сейчас давайте рассмотрим алгоритм работы традиционного пулера.
Обрабатываем полученные данные
Пауза соответствующая интервалу
Если рассматривать этот алгоритм, то видим, что переменная index и есть то, что связывает нас со структурой хранения данных.
Такой алгоритм, как правило, используют новички и. приводят себя к трудноустранимой проблеме: запросы с большими значениями index сделать индексируемыми крайне сложно. Почти невозможно.
Почему разработчик попадает в такую ситуацию? Потому что проектирует БД и API отдельно друг от друга. А нужно посмотреть на все компоненты в целом и на влияние их друг на друга.
Проблема состоит в том, что в БД, как правило, данные хранятся в виде плоских таблиц. Когда мы получаем очередную порцию данных с одними и теми же условиями фильтрации, то приходится делать что-то вроде следующего:
Как сделать план независящим от положения смещения? Использовать вместо смещения выборку из индекса:
Первичная инициализация. index := 0
Выполняем запрос limit данных, передавая в запрос index
Пауза, соответствующая интервалу
В системе с такой архитектурой, как правило, уже нет существенных препятствий к снижению интервала до минимальных значений (вплоть до нуля).
Но давайте ещё порефлексируем над архитектурой. Что плохого в ней?
Алгоритм привязан к структуре данных
Выполняется практически полностью на стороне клиента
Вследствие предыдущей проблемы сложно, например, централизованно модифицировать его на иную работу после факапов/проблем.
Пользователь может сам подставлять в index произвольные значения. Иногда это может быть нежелательно или приводить к багам, которые разработчику сервера сложно понять.
Давайте ещё раз модифицируем алгоритм. Заменим index на state и управлять им будем с сервера:
Выполняем запрос limit данных, передавая в запрос значение state
Что мы получили? Гибкость.
Переменная state определяется только сервером и не обязана быть привязанной к числу смещения. При желании в этой переменной можем хранить JSON со многими полями.
Если в переменной state хранится не только позиция окна, а, например, и значения фильтров и криптоподпись, то эту переменную имеет смысл называть курсором. Переименуем переменную ещё раз и избавимся от постоянных задержек:
Если данные были, перейти к шагу 2
Таким образом, получаем алгоритм, минимизирующий число запросов, если данных для клиента нет, и запрашивающий данные с максимальной производительностью, если таковые имеются.
Рекомендации по работе с курсорами:
Поскольку хранением курсора между запросами озадачен клиент, то имеет смысл хранить в курсоре и версию ПО сервера. В этом случае можно написать дополнительный код, обеспечивающий обратную совместимость (конвертацию форматов курсоров).
Во избежание трудных багов весь набор фильтров, полученных в первом запросе, хорошо хранить в курсоре и в последующих запросах игнорировать параметры фильтрации не из курсора. Перфекционисты могут даже выделить инициализацию курсора в отдельный запрос.
Во избежание введения в соблазн пользователей использовать в своём коде какие-то данные из курсора, лучше не использовать человекочитаемую строку в значении курсора. JSON, пропущенный через base64-кодирование (и криптоподписанный) подходит идеально.
Пример. Изменение алгоритма после сбоя.
Любая система гарантированной доставки сообщений из точки А в точку B в случае факапов будет накапливать пул недоставленных сообщений. После восстановления работоспособности будет период времени, когда приёмник данных сильно отстаёт от источника.
В случае, если порядок доставки сообщений возможно нарушать, то обработчик запроса с курсором может (продетектировав значительное отставание) начать возвращать два потока данных: тот, на который подписан клиент, и тот же, но с более актуальными данными.
Таким образом, пользователи, запросившие отчёт прямо во время факапа, продолжат его ждать (и дождутся). А пользователи, запросившие отчёт после факапа, получат его с небольшой задержкой.
Пример алгоритма серверной стороны, включающего второй поток в случае сильного отставания, приведён на рисунке.
Пофантазировав, схему можно дополнить не одним, а несколькими фолбеками.
Курсорная репликация
Описанные курсоры можно использовать для репликации данных с сервиса на сервис.
Часто один сервис должен иметь у себя кеш/реплику части данных другого сервиса. При этом требований синхронности к этой реплике нет. Поменялись данные в сервисе A. Они должны максимально быстро поменяться и в сервисе B.
Например, мы хотим реплицировать табицу пользователей с сервиса на сервис.
Для такой репликации можно использовать что-то готовое из инструментария баз данных, а можно сделать небольшой «велосипед». Предположим, что пользователи хранятся в БД PostgreSQL. Тогда делаем следующее:
модифицируем изменяющие пользователей запросы, чтобы на каждое изменение записи пользователя значение lsn устанавливалось бы из растущей последовательности
строим по полю lsn (уникальный) BTREE индекс.
В этом случае обновление записи пользователя будет выглядеть примерно так:
А запрос для работы курсора будет выглядеть как-то так:
Итоги
Почти во всех случаях, когда применяется активная система уведомлений зависимых сервисов, её можно заменить описанной курсорной подпиской.
При этом проблемы доступности клиентов, настроек, работоспособности TCP-стека останутся у клиентов
Максимально быстрое и простое восстановление после простоя/сбоев. Отсутствие двусмысленностей в кодах ошибок.
20 сленговых выражений, которые знает каждый программист, но не понимает обычный человек
Айтишники говорят на особом языке — малопонятном англо-русском диалекте. Несмотря на то, что большинство слов из сленга программистов — англицизмы, знание английского не поможет понять, о чем речь.
Например, слово пушить, образованное от английского «push», — нажимать, давить, означает загружать код на сервер GIT — систему отслеживания версий.
Составил список из 20 «айтишных» выражений, которые нужно знать человеку, прежде чем заговорить с программистом 👨💻
1. Аппрувить (от англ. «approve») — согласовать.
2. Баг (от англ. «bug») — ошибка в коде, из-за которой программа дает сбой или работает неправильно.
3. Багрепорт (от англ. «bug report») — сообщение или отчет об ошибке, которая привела к сбою в работе программы.
4. Битый — нерабочий. Если при переходе по ссылке, вылезает сообщение, что страница не найдена, значит, ссылка битая.
5. Бэкапить (от англ. «back up») — сохранять резервную копию. Бэкапить информацию надо как можно чаще, чтобы была возможность вернуть удаленные данные, или сохранить проделанную работу, если произойдет системный сбой.
6. Бэклог (от англ. «backlog») — список функций в порядке приоритета для реализации в следующих версиях продуктов.
7. Говнокод — код, который не подходит под определение хорошего кода. Хороший код — это компромисс между оптимальным кодом в части быстродействия, расширяемостью и читабельностью. Нетолерантные к чужой работе программисты часто употребляют слово говнокод в своем лексиконе.
8. Индусский код — код, написанный длинно и витиевато. Все потому что в Индии платят программистам за каждую строчку кода. Особо сообразительные специалисты прописывают лишние бесполезные строки.
9. Костыль — криво, но быстро реализованное решение проблемы в коде. Временная мера, которая поддерживает программу в рабочем состоянии, пока айтишники работают над трудоемким решением. Нередко работающий костыль остается на века и служит стабильнее «правильно написанной вещи» 😁
10. Крипово (от англ. «creepy») — страшно.
11. Разраб — сокращение от разработчик, но с намеком на тяжелый и подневольный труд.
12. Сейвить (от англ. «save») — сохранить изменения.
12. Спринт (от англ. «sprint») — отрезок времени, забег, за который команда разработчиков добавляет продукту новые функции.
13. Таски (от англ. «task») – задачи.
14. Тултип (от англ. «tooltip»)— всплывающая подсказка, которая появляется при наведении курсора.
15. Факап (от англ. «fuck up») — провал задачи, важного дела.
16. Фиксить (от англ. «fix») — исправлять ошибки в коде.
17. Фича (от англ. «feature») — особенность, фишка продукта. В интернете гуляют мемы и шутки на тему: «Это не баг — это фича». Иногда сложно с первого взгляда понять, программная ошибка перед тобой или новая возможность.
18. Хард скиллы (от англ. «hard skills») — технические навыки.
19. Чекнуть (от англ. «check») — проверить.
20. Шерить (от англ. «share») — предоставлять доступ к каким-либо данным.
А какими словами из айтишного сленга вы можете дополнить этот список?
А мержить?!
Какой пул реквест без этого?
Где подробнее прочитать про бэклог? Как составлять, как вести, какими инструментами по каким методикам?
А то все говорят, но никто не знает)
Виталий, почитайте вот эти статьи:
Сегодня, по ходу, День знаний 🤔
Руководитель компании «Мастерская цифровых решений»
Составил список из 20 «айтишных» выражений
А что вас собственно смущает?)) Вообще я 20 лет в энергетике, но последний год руковожу IT-компанией, которая разрабатывает продукты для автоматизации процессов в электроэнергетике.
Вообще-то это плохо скрываемая белая зависть была, а не робкое смущение 🤭
Не поделитесь случаем с электриком изучающим программирование, какие именно процессы автоматизируете для энергетической отрасли? )
Искандер, конечно, поделюсь)
У нас есть продукт GIPRO, можете посмотреть по ссылке gi-pro.ru. Это платформа, интегрированная с сайтом Минэнерго, в ней сейчас собрано 88 тысяч инвестиционных проектов 22 электросетевых компаний ПАО «Россети». Вся информация обработана методом Big Data, структурирована, есть удобные фильтры по параметрам, а также инструменты для автоматического расчета стоимости проектов по УНЦ. Реализована привязка к госзакупкам.
Соответственно GIPRO автоматизирует процесс инвестиционного планирования в части расчетов стоимости проектов. Также платформа полезна проектным, строительным институтам, подрядчикам, которые могут быстро получить полную информацию по текущим и будущим проектам.
Есть продукт Easy Task – система управления проектами, специализированная под проектные институты. Есть видеогид по функциям, посмотрите, если интересно: https://www.youtube.com/watch?v=ezkM47Kyxrk
С Изи Таском под импортозамещение ПО попадаете в госзакупках?
Пришёл срок замены карты, по сроку действия. Стоит сразу сказать, что на низовом видимом варианте сотрудники Сбера работают отлично. Всегда помогут, подскажут, доброжелательно и в целом приятно. Но когда работает та невидимая часть Сбера к которой не приедешь, увы начинаются проблемы.