Проект может в себя включать несколько команд. И в каждой команде должен быть тимлид. РП руководит ТЛ. Каждый ТЛ руководит своей командой. Если команда в проекте одна, то как правило РП и есть ТЛ или наоборот
В свое время на zx spectrum делал печать числа в Dec путем сдвига числа на 2 и на 8. Остатки сдвигов — и есть ваше очередное число с конца. Точный алгоритм не помню но работало это очень быстро
VAST — это кроссплатформенный протокол описания видео рекламы. Автор вскольз упомянул OpenRTB и не раскрыл тему до конца. Те, кто его не знают — не поймут для чего и как работает VAST. В последнем примере, как раз таки работает OpenRTB (обмен запросами и предложениями), а вот результат (предложение) в контексте видел рекламы — и есть VAST внутри этого OpenRTB
Прочитал между строк. Батырев сам себе противоречит. Он пишет о целях в долгосрочной перспективе. Что не сходится почти со всеми понятиями смарта. Смарт техника применима максимум на неделю. Так что Батырев просто не понимает как ей пользоваться правильно
В основном, проблема разделения мысли и уточнений. Придерживайтесь правил:
Если часть речи можно выкинуть — это уточнение и оно отделяется запятыми.
Если часть речи на конце и как вывод — ставьте тире.
Чхать Яндекс такси хотел на клиентов) да и на себя тоже. Он борется с ветряными мельницами) Лишь бы за трендами угнаться. А если быть точнее — исправлять надо причину обращений в поддержку, а не саму поддержку.
Да пусть не решают. Они даже не интересуются где когда и на чем будет запускаться их детище. А если знают, то не могут противостоять, т.к бизнес диктует правила. Опытные разработчики обычно не задерживаются в таких кампаниях, т.к опыт им подсказывает к чему все приведет.
Если бизнес не прислушивается к мнению творителей этого бизнеса — бизнес загибается в течение пару лет. А потом выходят куча статей на тему «Почему 90% стартапов умирают»
Не читал другие комменты. Их очень много. Выскажу свое мнение.
90% разработчиков работают по принципу этого мультфильма: g.co/kgs/y4Sjws
Не исключаю, что автор этом методом грешит.
О чем можно вообще спорить. Вот вам явный пример: эта статья и 1000+ комментариев, которые грузятся СРАЗУ! СРАЗУ КАРЛ! НАХРЕНА МНЕ ВСЕ 1000+ комментариев?
Я, для того, что бы написать этот коммент специально взял ноут 2020 года, потому что мобильный браузер завис на 1 минуту, а потом еще 1 минуту я скролил до конца, а потом еще ждал 1 минуту, пока браузер одуплится и нарисует мне то, где я нахожусь. Да куда уж там. мой ноут не сразу одуплился, да еще поднапрягся до свиста вентилятора. Вкладка выжрала 500МБ из 8ГБ и 30% процессора использует постоянно.
И вот Вы хотите сказать, что сейчас стало лучше? Да хуже все. А знаете почему? Да потому что появились вот такие Хоромы в виде гигабайтов памяти и многоядердных процессоров. НО! 90% разработчиков не учитывают тот, факт, что не у каждого пользователя последние технологии. Да даже и если последние, то никто не думает о том, что ваш софт будет запущен параллельно с другими программами и банально на софт будет выделено 1 ядро и 10% этой гигабайтной памяти. Вот и получается, что софт тормозит.
Вот Вам другая точка зрения, почему 90% пользователей говорит «Раньше было лучше»
Спасибо. Это я видел. Там нигде нет формата данных этих характеристик. А вы приводите скрины как раз с этими форматами. Например 2A2B характеристика толком даже в GATT Specification Supplement не описана
UPD: описана. Просто ссылки не верные. Если идти по ссылке кидает на Email. Если руками поискать «Exact time 256» — то это другая секция и там все описано
Перфекционизм — очень коварная штука. Много комментариев по этому поводу написано выше(ранее). Я так же являюсь им. И как не странно — программист. Но ближе к 1-ому типу. Всегда ищу идеальный вариант.
На своем опыте выявил как обуздать его. Нужно просто составить план действий (в моем случае Тех.задание), в котором будет прописаны все возможные и не возможные варианты развития. Только зная, то, что Вам известно что и как делать — Вы без запинки совести не будете думать, что можно сделать лучше. А все потому, что, чем лучше продумать все возможные варианты и охватить их сразу за один раз — вот, к чему стремится перфекционист.
И тут возникает другая проблема — идеально продумать все шаги. Не раз за собой замечал, прежде чем браться делать какую то задачу — я очень долго ленюсь ее начать делать, потому что не продумал все варианты.
Но бизнес — так же штука коварная. В нем надо здесь и сейчас. Поэтому для себя нашел следующий способ: 1. обдумываю MVP версию фичи. 2. На этапе написания — задаю вопрос: «А что если...» и если может быть что-то, что не в ходит в MVP, просто пишу комментариями свои мысли. Это очень сильно снимает тревогу за то, что не все сделано идеально, но т.к. есть заметки по этому поводу — вы как бы снимаете с себя ответственность за будущие баги или недоработки. И это могут увидеть все. А это еще больший плюс в карму
Из Ваших слов — в любом случае разгребать вину Уберу и никак не сослаться на то, что виновата пешеход. Учебная езда ИИ не допустима на дорогах общего пользования. Тут как минимум виноват водитель, которая кстати не смотрела вообще в этот момент
Вы слишком сильно превышаете ожидания текущих систем ИИ. А уж это
Велосипедист мог, да и должен был остановится на соседней полосе, и автопилот видимо так же считал что он будет действовать если не по правилам то по логике увидев движущийся автомобиль, а когда этого не произошло…
подавно еще не работает. Тут вы как раз и говорите о «контексте», которого у убера явно нет. Старт такому явлению положил Амазон с его магазином Амазон Го.
Таким образом, в своем комментарии, Вы же сами написали, что убер виноват. Что и требовалось доказать.
Прочитайте еще раз, что Вы написали и подумайте. Умейте различать понятие «внезапно выскочил» и «определенно двигался». В случае с убером было «определенно». А вот почему убер не остановился — причина в том, что у него, скоррее всего, нет контекста движения. для него каждый кадр — это независимые обьекты. Вот он и увидил «траекторию» в последний момент, когда уже было поздно.
П.С. Без обид. Вы скорее всего не программист, раз так рассуждаете.
Проект может в себя включать несколько команд. И в каждой команде должен быть тимлид. РП руководит ТЛ. Каждый ТЛ руководит своей командой. Если команда в проекте одна, то как правило РП и есть ТЛ или наоборот
В свое время на zx spectrum делал печать числа в Dec путем сдвига числа на 2 и на 8. Остатки сдвигов — и есть ваше очередное число с конца. Точный алгоритм не помню но работало это очень быстро
_.mapValues(users, user => user.age)
Вы под «капот» заглядывали? Загляните — после этого перестанете так утверждать. Только в этом методе используется куча подвызовов
VAST — это кроссплатформенный протокол описания видео рекламы. Автор вскольз упомянул OpenRTB и не раскрыл тему до конца. Те, кто его не знают — не поймут для чего и как работает VAST. В последнем примере, как раз таки работает OpenRTB (обмен запросами и предложениями), а вот результат (предложение) в контексте видел рекламы — и есть VAST внутри этого OpenRTB
Прочитал между строк. Батырев сам себе противоречит. Он пишет о целях в долгосрочной перспективе. Что не сходится почти со всеми понятиями смарта. Смарт техника применима максимум на неделю. Так что Батырев просто не понимает как ей пользоваться правильно
На день, в одном типе работ не может быть больше одной цели дня. Пример: работа — выполнить часть или всю задачу. Дом — приготовить ужин
По поводу целей дня — рекомендую прочитать книгу "Найди время" от известных сотрудников Гугл: Джейк Кнапп, Джон Зерацки
В основном, проблема разделения мысли и уточнений. Придерживайтесь правил:
Если часть речи можно выкинуть — это уточнение и оно отделяется запятыми.
Если часть речи на конце и как вывод — ставьте тире.
Текущая и предыдущие статьи — хороши. Но вот беда — читать трудно. С пунктуацией беда
Рад видеть, что администрации не все равно и они обращают внимания на проблемы
Чхать Яндекс такси хотел на клиентов) да и на себя тоже. Он борется с ветряными мельницами) Лишь бы за трендами угнаться. А если быть точнее — исправлять надо причину обращений в поддержку, а не саму поддержку.
Если бизнес не прислушивается к мнению творителей этого бизнеса — бизнес загибается в течение пару лет. А потом выходят куча статей на тему «Почему 90% стартапов умирают»
90% разработчиков работают по принципу этого мультфильма: g.co/kgs/y4Sjws
Не исключаю, что автор этом методом грешит.
О чем можно вообще спорить. Вот вам явный пример: эта статья и 1000+ комментариев, которые грузятся СРАЗУ! СРАЗУ КАРЛ! НАХРЕНА МНЕ ВСЕ 1000+ комментариев?
Я, для того, что бы написать этот коммент специально взял ноут 2020 года, потому что мобильный браузер завис на 1 минуту, а потом еще 1 минуту я скролил до конца, а потом еще ждал 1 минуту, пока браузер одуплится и нарисует мне то, где я нахожусь. Да куда уж там. мой ноут не сразу одуплился, да еще поднапрягся до свиста вентилятора. Вкладка выжрала 500МБ из 8ГБ и 30% процессора использует постоянно.
И вот Вы хотите сказать, что сейчас стало лучше? Да хуже все. А знаете почему? Да потому что появились вот такие Хоромы в виде гигабайтов памяти и многоядердных процессоров. НО! 90% разработчиков не учитывают тот, факт, что не у каждого пользователя последние технологии. Да даже и если последние, то никто не думает о том, что ваш софт будет запущен параллельно с другими программами и банально на софт будет выделено 1 ядро и 10% этой гигабайтной памяти. Вот и получается, что софт тормозит.
Вот Вам другая точка зрения, почему 90% пользователей говорит «Раньше было лучше»
UPD: описана. Просто ссылки не верные. Если идти по ссылке кидает на Email. Если руками поискать «Exact time 256» — то это другая секция и там все описано
На своем опыте выявил как обуздать его. Нужно просто составить план действий (в моем случае Тех.задание), в котором будет прописаны все возможные и не возможные варианты развития. Только зная, то, что Вам известно что и как делать — Вы без запинки совести не будете думать, что можно сделать лучше. А все потому, что, чем лучше продумать все возможные варианты и охватить их сразу за один раз — вот, к чему стремится перфекционист.
И тут возникает другая проблема — идеально продумать все шаги. Не раз за собой замечал, прежде чем браться делать какую то задачу — я очень долго ленюсь ее начать делать, потому что не продумал все варианты.
Но бизнес — так же штука коварная. В нем надо здесь и сейчас. Поэтому для себя нашел следующий способ: 1. обдумываю MVP версию фичи. 2. На этапе написания — задаю вопрос: «А что если...» и если может быть что-то, что не в ходит в MVP, просто пишу комментариями свои мысли. Это очень сильно снимает тревогу за то, что не все сделано идеально, но т.к. есть заметки по этому поводу — вы как бы снимаете с себя ответственность за будущие баги или недоработки. И это могут увидеть все. А это еще больший плюс в карму
подавно еще не работает. Тут вы как раз и говорите о «контексте», которого у убера явно нет. Старт такому явлению положил Амазон с его магазином Амазон Го.
Таким образом, в своем комментарии, Вы же сами написали, что убер виноват. Что и требовалось доказать.
П.С. Без обид. Вы скорее всего не программист, раз так рассуждаете.