Определяем местоположение по коммитам в git

Готово (пока только в онлайн версии). Так же добавил цвета и фильтры, чтобы понять где основная команда или сотрудники конкретного суб. подрядчика.

Определяем местоположение по коммитам в git

В данном случае это смесь Аргентино-Бразильцев. При том, что часть Бразильцев я отрезал по Испанскому алфавиту и частично по популярным фамилиям, а в сторону Аргентины сдвинул, т.к. у неё более сильная экономика и IT отрасль. Но возможно я ошибся, т.к. следуя "карте офисов", работяги Canonical имеются в Сан-Паулу, а это Бразилия (на 1000 км выше).

Видимо "карта офисов" для ТОП 100 компаний сильно поправит разброс и нужно будет её сделать.

Определяем местоположение по коммитам в git

Да, все так и есть. Это проверка только для Европы или островов. В районе Латинской Америки она уже не используется, т.к. слишком много испаноязычных стран.

Определяем местоположение по коммитам в git

Я взял это https://github.com/telegramdesktop/tdesktop Возможно это не официальная сборка, но выглядит как официальная

Конструктор сайтов Wix прекращает работу в России с 12 сентября

Тысячи мелких бизнесов, которые держали там сайты, сейчас окажутся очень неприятной ситуации.

• для программистов время дикого фриланса

• доверие к готовым площадкам снова пошатнется

• Тильда, видимо, будет пытаться очень быстро масштабироваться (но пойдут ли туда те кто уже обжегся?)

ТОП ошибок тех. интервьюеров

С одной стороны, сталкивался редко. С другой стороны, свой опыт, в этом плане, переосмыслил.

Начнём с причин:

• На реальном проекте задача часто имеет большой контекст и историю вопроса. Трудно вырезать её из контекста и в компактном виде представить на собеседовании.

• Большая часть задач на большинстве проектов достаточно банальны. Ты полу-копированием по образцу пишешь простой код по перекладываю JSON`ов.

Чтобы решить эти проблемы:

• делаем маленькие обособленные задачи;

• рассматриваем в них ту самую меньшую часть, где нужно подумать;

И в этот момент может оказаться, что далеко не все задачи «‎про алгоритмы», на самом деле «‎про алгоритмы». Переосмысливая пройденные алгоритмические секции, сейчас я понимаю, что 50% кода там это и были задачи про бизнес.

Например, на фронте: задача проверки анаграмм;

• Решение в «‎классическом» виде покажет, что человек понимает узкие места производительности. Если взять его в команду, то вряд ли мы потом получим тех. долг вида «‎всё тормозит, работать невозможно».

• Решение «‎в лоб» (через кучу методов массива) говорит о том, что он хорошо знает базовое API и скорее всего в рабочих задачах часто сможет решить проблемы обычным способом, не создавая на проекте «‎ад зависимостей», которые потом через пару лет мы физически не сможем обновить или удалить малой кровью.

ТОП ошибок тех. интервьюеров

Разный хэш при разном порядке будет для объектов где больше одной буквы, а по условию:

конкретно для этого массива. Все объекты простые: одна буква, одна цифра, никаких 0, null, undefined, глубокой вложенности и т.п.

const input = [{ a: 1 }, { b: 2 }, { a: 1 }, { a: 2 }, { d: 4 }];
const output = [...new Set(input.map(JSON.stringify))].map(JSON.parse);

За предположение и рассуждение "+", а вот решения, лично я, требую самое топорное, которое придет в голову. Короткое решение + объяснение, где и как оно может развалится в будущем и какие ограничения. Есть другая ачивка, которую соискатель случайно не должен выбить на собесе — «переусложненние»‎. Меня самого за это пару раз срезали и я стал более внимательно к этому относится.

ТОП ошибок тех. интервьюеров

доп. условие к ней такое: решить в самом простом виде, конкретно для этого массива. Все объекты простые: одна буква, одна цифра, никаких 0, null, undefined, глубокой вложенности и т.п. Любой подход (при условии что порядок конкретно этих объектов может быть любой). Если можно просто и в лоб, можете сделать просто и в лоб.

Шагающий аэростат однажды сможет исследовать Титан или морское дно Земли

Гелий текуч и его невозможно долго держать в какой бы то небыло таре. По итогу он все равно утекает.

Ачивки за коммиты в git. Пятничный пост

Пока не знаю, написал просто "почтальон". С английским там вообще ахтунг, т.к. половина идиом или названий переведена "просто", без всяких отсылок (

Ачивки за коммиты в git. Пятничный пост

Нет, просто так)) На самом деле «самый короткий»: текст коммита, имя, срок работы, email — все подходит под фразу и трудно иконки придумывать для разных ачивок. Была мысль 15см с Ивлеевой, но это не перевести. Не знаю какие ещё фразы подобрать для соседних ачивок того же типа

Ачивки за коммиты в git. Пятничный пост

На всякий случай проговорю, что все эти ачивки можно посмотреть и для пользователей gitlab/gitea. А вот плагин-интеграцию в интерфейс действительно хочется, но пока не хватает ресурсов разработки на это дело (

Ачивки за коммиты в git. Пятничный пост

Фронтом не вытянуть, тк лог выдерается через консольную команду гиту. А арендовать сервер под это дело — подумаю. Дело в том, что буквально 10 человек с монорепами на пару гигов по сути завалят его работой. По опросам народ больше хотел «развернуть у себя», поэтому пока фокус был такой (обход приватных реп, склейка данных о разных микросервисах и тп)

Ачивки за коммиты в git. Пятничный пост

fix-man и значок какого нибудь Рассомахи или спайдера. И за пару revert — зассал или «что ж ты фраер сдал назад» или «к успеху шел, не фартануло». Только на английский тяжко будет перевести

Ачивки за коммиты в git. Пятничный пост

Это к сожалению трудно скриптом определить. Люди ставят разные имена и абсолютно непохожие почты. Но попробую

Ачивки за коммиты в git. Пятничный пост

Код сразу в мастер/dev льется? Ну вот это будет легко прикрутить

Ачивки за коммиты в git. Пятничный пост

нет, просто опечатка, поправлю

Готовимся к вопросам по вёрстке на интервью Frontend-разработчика: «Как скрыть элемент доступно?»

А есть какой-то практический случай, зачем вообще нужно такое поведение?

Как реализовать drag & drop используя RxJS

Возникла та же мысль. Решил попробовать. Вышло так:

let active = null;
document.querySelectorAll('.draggable')
  .forEach(element => {
    element.addEventListener('mousedown', (event) => {
      active = { event, element };
    });
    element.addEventListener('mouseup', () => {
      active = null;
    });
  });
document.addEventListener('mousemove', (event) => {
  if (!active) return;
  active.element.style.left = (event.x - active.event.offsetX) + 'px';
  active.element.style.top = (event.y - active.event.offsetY) + 'px';
});

Как я статистику git парсил

git сохраняет информацию о событие слияния веток. Если ветка подписана номером задачи, то можем посчитать разницу. Например:

2021-06-08>Ivan>[e-mail]>JIRA-476 feat(Excel): add typograf for text on Approving page, refactor Approve list item
2021-06-11>Mikhail>[e-mail]>Merge pull request #189 in ACRQ/acrq-frontend from feature/JIRA-476-Add-typograf-for-text-on-Approving-page to master

Смотрим на вторую строку. Она имеет маркировку "Merge pull request...", а далее написано название ветки. Из этого названия "feature/JIRA-476-Add-typog..." мы можем узнать номер задачи (JIRA-476).

Теперь смотрим прошлые строки и находим ближайшую, которая подписана номером этой задачи. В нашем случае это строка 1, т.к. её текст "JIRA-476 feat(Excel): add..."

Т.к. в логе есть дата обоих событий, мы можем посчитать разницу между ними. Но, т.к. это "время ожидания влития" мы не знаем причину, по которой ветка не вливалась (т.к. не известно когда был создан PR и были ли к нему замечания). Причины могут быть такие:

1. PR висел и ждал апрувов. Их ставили очень медленно, но без замечаний.

2. PR можно влить, только если прошла сборка кода. Но скрипт сборки не работал.

3. О задаче просто забыли и PR никто не создал.

4. PR ожидал подтверждения тестировщика, но у него была большая очередь других задач.

5. Влитие кода отложили по бизнес причинам

6. и т.д.

Вся эта схема сработает только если в команде есть жесткие правила по именованию веток и коммитов.