В БД я бы все-таки валил инфу по трафику, потому что это статистика и прогнозы в будущем. На крайний случай, если фид данных отвалится - можно будет строить маршрут исходя из статистики.
"По окончании работы над проектом супруги разослали копии игры примерно 250 профильным ютуберам, и отрицательных отзывов от них почти не последовало." - вероятно потому что ютуберы игру и вовсе не смотрели
А чисто теоретически, спортсменам такая штука помогла бы? Ну например бегунам, если сконфигурить длину ног таким образом, чтобы достичь идеальных пропорций... или MMA-бойцам ударникам, чтобы могли втащить сопернику ногой с любой точки арены
Если кто-то из ваших коллег сильно не любит встречи - значит ему/ей либо нечего на них сказать, либо вы не даете высказаться. И всегда держите в логове ставки тех кто участвует во встрече, митинг на час на 8 человек = минус рабочий день для компании. Есть, конечно ребята, которые во время митинга решают рабочие вопросы, кодят или тестировать успевают, но это лишь значит что на этом митинге им нечего делать.
Тачем невозможно пользоваться на ходу. Кнопки тоже не панацея - логика их расположения у части автопроизводителей вызывает вопросы об адекватности тамошних дизайнеров. У меня вот управление задним дворником над головой находится, а громкость можно регулировать только правой рукой, которая 99% времени не на руле. Идеально было бы - перепрограммируемый набор кнопок на руле и центральной консоли, но такое редкость.
По поводу сроков - хотел дополнить немного, у нас тимлиды занимаются распределением задач сообразно грейду и скиллам разработчиков, то есть PM ставит все задачи на лида, а лид уже оценивает и раскидывает их. В таком раскладе, если при делегировании задачи на кого-то, тимлид контролирует оценку, учитывает и уровень разраба, и возможные подводные камни и потом совсем не следит за тем что происходит - это немного странно, т.к. именно ошибка лида в этом процессе может привести к срыву сроков.
Менеджеры есть, но то что тимлиды +-погружены в сроки и в моральное состояние команды и отдельных разработчиков, мне кажется вполне естественно. По крайней мере хороший тимлид знает о том что условный прогер Вася не вывозит свою часть задолго до того как менеджер начнет истерить о срыве сроков и принимает меры.
Я как тот самый "настоящий программист" в свитере и с бородой, фигачивший ассемблерные вставки в код на плюсах, могу сказать, что джуны всегда были нужны, и не только программисты, а вообще все, QA, аналитики, PM, датасаентисты, тысячи их. Если ваша команда/компания не может использовать вчерашних экспедиторов, столяров, экономистов и торгпредов, внезапно решивших пойти в ИТ - значит у вас что-то с процессами внутри не так. Да, это долго и местами больно, и дорогу осилят не все - но результат в любом случае стоит того. Иначе бы обучением и стажировкой людей без профильного образования вообще бы никто не занимался, но мы видим обратное.
Разница между выпускниками профильных специальностей, самоучками и закончившими курсы сводится на нет безбожно далекой от полноценного использования в проектах квалификацией. Которая нарабатывается только в команде, под руководством "настоящих погромистов", на реальных проектах и под грузом ответственности.
Туда же камеры наблюдения, понатыканные вообще везде... уж хотя бы московское видеонаблюдение должно было засечь хоть парочку. Дело наверное все-таки не в камерах, а в отсутствии интереса к теме - те же дипфейки, нейросети и Unreal Engine позволяют генерить соответствующий контент в промышленных масштабах. Просто всем... пофиг
так у нас как таковых "чистых" сеньоров в аутсорс-командах то и нет, специально это выделил... либо тимлидство/техлидство, либо добро пожаловать на аутстаф
Спасибо за фидбек) По ссылкам, которые я привел, как раз и раскрываются ответы на первые два вопроса:
1) В конфигурационном файле /etc/gitlab/gitlab.rb есть такая настройка external_url
2) Переменные LANG and LC_* на чистых инстансах Ubuntu не всегда изначально заданы и, если вы получаете при установке такую проблему, как у меня - задайте их сообразно инструкции, ссылка на ктороую приведена в статье
3) По поводу импорта, возможно, у меня не хватает знаний, но экспорт-импорт через bare в случае Bitbucket Cloud -> GitLab выглядит как будто надо делать это для каждой репы отдельно. Это пугает, их там 140+ штук
Как написал в начале статьи, все случилось как всегда ВНЕЗАПНО и времени на "из чего выбирали", "проводили сравнение", к сожалению, не было, здесь речи не шло о каком-то стратегическом взвешенном решении. Тут скорее умудрились наступить на грабли которые слишком явно торчали из травы и статья как раз о минимизации вреда от удара ими по башке. Вред = время простоя, в течение которого тестеры и клиенты не получают сборки. Выбирали по принципу с чем работали ранее, у нас несколько проектов велось и ведется до сих пор в гитлабе заказчика.
Периодически гоняем мысль в голове взять один из своих серверов, нарезать виртуалку и развернуть репы там, но каждый раз находится больше "против" чем "за". В первую очередь из-за сетевой инфраструктуры - к сожалению у провайдеров в городе регулярно бывают проблемы и даже наличие двух каналов не гарантирует доступность. Во вторую - железный сервак это не только мощно и шумно, случается так что надо с ним что-то так же физически делать, а для этого нужен админ в офисе. В эпоху удаленки это роскошь. Так что пока что облако.
Благодарствую, разобрались
я только не понимаю, какой speed они меняют, который maxspeed?
В БД я бы все-таки валил инфу по трафику, потому что это статистика и прогнозы в будущем. На крайний случай, если фид данных отвалится - можно будет строить маршрут исходя из статистики.
нет, не совсем, трафик это информация по пробкам, вот есть пример реализации
я так полагаю, данные по трафику так же можно валить в БД и далее учитывать при построении маршрута, например меняя maxspeed (мое предположение)
Спасибо, классная статья, тоже люблю Graphopper)
А как на примере Postgres данные по трафику задавать?
"По окончании работы над проектом супруги разослали копии игры примерно 250 профильным ютуберам, и отрицательных отзывов от них почти не последовало." - вероятно потому что ютуберы игру и вовсе не смотрели
А чисто теоретически, спортсменам такая штука помогла бы? Ну например бегунам, если сконфигурить длину ног таким образом, чтобы достичь идеальных пропорций... или MMA-бойцам ударникам, чтобы могли втащить сопернику ногой с любой точки арены
Если кто-то из ваших коллег сильно не любит встречи - значит ему/ей либо нечего на них сказать, либо вы не даете высказаться. И всегда держите в логове ставки тех кто участвует во встрече, митинг на час на 8 человек = минус рабочий день для компании. Есть, конечно ребята, которые во время митинга решают рабочие вопросы, кодят или тестировать успевают, но это лишь значит что на этом митинге им нечего делать.
Тачем невозможно пользоваться на ходу. Кнопки тоже не панацея - логика их расположения у части автопроизводителей вызывает вопросы об адекватности тамошних дизайнеров. У меня вот управление задним дворником над головой находится, а громкость можно регулировать только правой рукой, которая 99% времени не на руле. Идеально было бы - перепрограммируемый набор кнопок на руле и центральной консоли, но такое редкость.
По поводу сроков - хотел дополнить немного, у нас тимлиды занимаются распределением задач сообразно грейду и скиллам разработчиков, то есть PM ставит все задачи на лида, а лид уже оценивает и раскидывает их. В таком раскладе, если при делегировании задачи на кого-то, тимлид контролирует оценку, учитывает и уровень разраба, и возможные подводные камни и потом совсем не следит за тем что происходит - это немного странно, т.к. именно ошибка лида в этом процессе может привести к срыву сроков.
Менеджеры есть, но то что тимлиды +-погружены в сроки и в моральное состояние команды и отдельных разработчиков, мне кажется вполне естественно. По крайней мере хороший тимлид знает о том что условный прогер Вася не вывозит свою часть задолго до того как менеджер начнет истерить о срыве сроков и принимает меры.
Я как тот самый "настоящий программист" в свитере и с бородой, фигачивший ассемблерные вставки в код на плюсах, могу сказать, что джуны всегда были нужны, и не только программисты, а вообще все, QA, аналитики, PM, датасаентисты, тысячи их. Если ваша команда/компания не может использовать вчерашних экспедиторов, столяров, экономистов и торгпредов, внезапно решивших пойти в ИТ - значит у вас что-то с процессами внутри не так. Да, это долго и местами больно, и дорогу осилят не все - но результат в любом случае стоит того. Иначе бы обучением и стажировкой людей без профильного образования вообще бы никто не занимался, но мы видим обратное.
Разница между выпускниками профильных специальностей, самоучками и закончившими курсы сводится на нет безбожно далекой от полноценного использования в проектах квалификацией. Которая нарабатывается только в команде, под руководством "настоящих погромистов", на реальных проектах и под грузом ответственности.
Туда же камеры наблюдения, понатыканные вообще везде... уж хотя бы московское видеонаблюдение должно было засечь хоть парочку. Дело наверное все-таки не в камерах, а в отсутствии интереса к теме - те же дипфейки, нейросети и Unreal Engine позволяют генерить соответствующий контент в промышленных масштабах. Просто всем... пофиг
так у нас как таковых "чистых" сеньоров в аутсорс-командах то и нет, специально это выделил... либо тимлидство/техлидство, либо добро пожаловать на аутстаф
У нас тормозил и Bitbucket Cloud, поэтому сильной разницы не заметили)
Спасибо за фидбек) По ссылкам, которые я привел, как раз и раскрываются ответы на первые два вопроса:
1) В конфигурационном файле /etc/gitlab/gitlab.rb есть такая настройка external_url
2) Переменные
LANGandLC_*на чистых инстансах Ubuntu не всегда изначально заданы и, если вы получаете при установке такую проблему, как у меня - задайте их сообразно инструкции, ссылка на ктороую приведена в статье3) По поводу импорта, возможно, у меня не хватает знаний, но экспорт-импорт через bare в случае Bitbucket Cloud -> GitLab выглядит как будто надо делать это для каждой репы отдельно. Это пугает, их там 140+ штук
По поводу импорта через bare - может я чего не понимаю, но из Bitbucket в GitLab это можно сделать строго по одному. А это 140+ реп на минутку...
Как написал в начале статьи, все случилось как всегда ВНЕЗАПНО и времени на "из чего выбирали", "проводили сравнение", к сожалению, не было, здесь речи не шло о каком-то стратегическом взвешенном решении. Тут скорее умудрились наступить на грабли которые слишком явно торчали из травы и статья как раз о минимизации вреда от удара ими по башке. Вред = время простоя, в течение которого тестеры и клиенты не получают сборки. Выбирали по принципу с чем работали ранее, у нас несколько проектов велось и ведется до сих пор в гитлабе заказчика.
регистрацию отключили как все зарегались, 2fa сделали, а насчет апишки и вайтлиста - спасибо, не подумали
Периодически гоняем мысль в голове взять один из своих серверов, нарезать виртуалку и развернуть репы там, но каждый раз находится больше "против" чем "за". В первую очередь из-за сетевой инфраструктуры - к сожалению у провайдеров в городе регулярно бывают проблемы и даже наличие двух каналов не гарантирует доступность. Во вторую - железный сервак это не только мощно и шумно, случается так что надо с ним что-то так же физически делать, а для этого нужен админ в офисе. В эпоху удаленки это роскошь. Так что пока что облако.