Я из тех наивных, кто верит описаниям вакансий, если там написано "человек-оркестр" - для меня это важная характеристика проекта с которым предстоит работать, что его делал такой же балалаечник, но кончился и нужен следующий.
Что делать:
ии помогает при большом наплыве, если у вас наплыва нет и вы не фаанг - применяйте кожаных.
парттайм действительно полезная тема, если конечный или периодический поток задач.
удалёнка - просто расширяет воронку кандидатов, кто-то готов с этим мириться, а кто-то - банк или оборонка.
джуны бывают разные, если не путать джуна с новичком окончившим курсы - за год и правда можно вырастить хорошего спеца. И если мы раньше боялись что через полгода такой сбежит, то теперь самое время ему научиться и остаться, потому что бежать особо некуда.
Если qr-код содержит токен на предъявителя, по которому потом продавец может затребовать списание, как проходит проверка суммы, по обоюдному согласию данных от продавца и покупателя при подключении к сети, или только по данным от предъявителя токена?
Сам работаю в feature-driven, и радует когда удаётся слышать реальные отзывы, и roadmap строится не из фич соседей по рынку, а из запросов пользователей.
Однако часто встречаю и другой кейс замкнутой техподдержки, где цель оператора не решить проблему, а закрыть тикет. При таком подходе клиент видит проблему, пишет с предложением улучшить, а в итоге ему предлагают "переустановить браузер".
Были и более яркие примеры: однажды тех.партнёр не признал ошибку, но за счёт более грамотного общения в итоге ещё и увёл клиента, пока мы отвечали сухим "проблема не на нашей стороне".
Спасибо, энциклопедично, в своё время очень не хватало такого материала, всё действительно было в рекламных pdf. Не уж то до сих пор так? Надеюсь допишете серию)
Для меня так и осталось загадкой как происходит оценка, когда на основе GAID/AAID/IDFA и облака интересов происходит оценка конверсии, принимая во внимание, что программатик родился ещё до бума нейронок. Но я был со стороны SSP, в магию особо не лез.
Вот тут всё верно. Руководитель может делегировать только свои функции - управление, постановку и/или контроль исполнения.
И тогда, возвращаясь к заголовку, можно сказать что проблема делегирования в том, что ответственность за постановку и за контроль передавать нужно аккуратно.
Говорят даже по-другому: "ответственность нельзя передать, её можно взять", поэтому делегируют только тем кто сам готов взять ответственность за результат.
Передача ответственности заключается в доверии принятия управленческих решений, от простого к сложному по мере роста доверия.
Без передачи ответственности "они" так и будут бегать с каждым мелким вопросом.
Приятно сделано, и цены не кусаются, вместо своего сворма/кубера можно заехать в готовое облако, вроде все необходимые настройки есть: маршрутизация, секреты, ресурсы... спасибо)
Посмотрел в доке, не увидел возможности маскировать переменные в логах, выходит что секреты будут видны plain text. Для личных экспериментов - не критично, для корпоративных, думаю, ощутимо.
В остальном всё нужное есть, сертификаты можно привезти в контейнере или поставить снаружи, IAM накидать своим контейнером и тоже привезти в готовом виде.
Какой-то SLA заявляете? Судя по user agreement, быстро поднятое упавшим не считается.
По фиксированной цене можно продавать только готовый продукт, а любой кастдев - это всегда субъективная оценка. И так не только в нашей с вами айтишечке. Стадион/завод/дом/мост также строят по примерной оценке плюс риски. А в рисках может быть и x2 и больше.
Спасибо за историю. А почему не брали оплату вперёд? На сколько помню 2010-ые - тогда это было действительно не модно, доверия к интернет-площадкам особо небыло, но это могло стать выходом из ситуации с кассовым разрывом, а также снизило бы число заказов и возвратов.
17 таблиц, 1300 poi на странице, 50K записей в хранилище... боюсь гадать на кофейной гуще, но кажется нагрузка не в объёме данных и проблема не в типе хранилища.
Я бы посмотрел:
где именно проблема: в бд или в прослойке, так как если браузер показывает pending - это ещё не значит что проблема в бд.
на суммарное количество запросов в бд, возможно не решена n+1.
на структуру запросов, возможно join`ы оптимальнее разбить на отдельные запросы с lazy-load.
банальные индексы не там и не те, лишние сортировки или limit/offset.
на математику внутри запросов, для расчёта попадания координат в область есть стандартные методы.
возможно грузить стоит отдельно координаты для отображения на карте, а отдельно - детальную информацию для просмотра.
Имхо, методики scrum и прочие из семейства - помогают менеджерам как-то контролировать не до конца понятную им область, держать руку на пульсе и корректировать направление как можно раньше. Программистам тоже помогают, но в другом: научиться общаться "словами из рота" и слышать друг друга.
На сколько рьяно следовать каждой из методик - уже зависит от команды и от самого менеджмента, вечный баланс между "шашечки" и "ехать".
Продуктовая и заказная разработка - это два разных мира. Фриланс по проектам на пару месяцев не особо учит вести большие и сложные проекты. Фриланс даст какие-то азы, но лучшее подтверждение опыта - что вы год проработали в серьёзном проекте.
Просите денег по рынку, ну или по своим затратам, в первый год это не важно, гораздо ценнее получаемый опыт. Однако имейте в виду, что повышать зарплату без смены места работы тяжелее, чем вместе со сменой. места. Вдруг захотите остаться)
Смотрите на компании, где будете делать основной продукт, который приносит ощутимую долю прибыли компании. Не нужно "чинить принтеры" (со всем уважением к товарищам). Кстати, это не только it касается.
Ноунейм компании тоже делают классные продукты, почему нет)
HR-ы просто хотят найти подходящего кандидата. Какого - никто не знает. Будьте честны и открыты. Но никто не любит совмещение и непонятный рабочий день. Если вы учитесь, не предлагайте работать между парами.
Я работал на первом курсе, на втором уже работал программистом в ноунейм конторе. Всё реально, если оно вам действительно надо. Но профильное образование всё же лучше.
На фрилансе редко делают упор на качество, да и учиться особо не у кого. Учиться лучше у людей с опытом, чем "по книжкам".
Вуз имеет место в части компаний. Делать приложухи можно без вуза. Расти вглубь и по карьере без вуза сейчас уже тяжелее. Совсем без вуза - не попадёте под всевозможные blue card.
Алгоритмы модно спрашивать, поэтому спрашивают. Может и не пригодится в работе, но олимпиадные и алгоритмические задачи ещё никому не вредили, тут стоит поупражняться.
Врать - а какой смысл? Вот возьмут вас, через месяц расстанетесь - только время потеряете и трудовую замараете. Вы выбираете работодателя точно также как и он вас. Ищите того, кто вам подходит и сможет вам что-то дать, кроме денег конечно.
Использую именно такое разделение на уровни, с одним лишь дополнением, Lead не просто может спихнуть, а знает кому из сотрудников лучше отдать ту или иную задачу, кому что интереснее и кто сделает качественнее)
Смутил вывод что "их особенно-то никто и не разрабатывал", имхо это всё же следствие. Нам преподавали что троичные компьютеры просто выходили сложнее и дороже. И охотно верю, что в те времена было проще сбегать-посмотреть заряжена ли ячейка, чем измерять на сколько и каким зарядом.
И отдельный вопрос - хранение заряда разного полюса в соседних ячейках на магнитной ленте. А ещё были перфокарты, где небыло "наполовину-дырок", так что двоичность вроде как оправдана.
Отмечу наблюдение - на заводах часто встречаются очень вкусные столовки, не чета этим кафе в бизнес-центрах.
Я из тех наивных, кто верит описаниям вакансий, если там написано "человек-оркестр" - для меня это важная характеристика проекта с которым предстоит работать, что его делал такой же балалаечник, но кончился и нужен следующий.
Что делать:
ии помогает при большом наплыве, если у вас наплыва нет и вы не фаанг - применяйте кожаных.
парттайм действительно полезная тема, если конечный или периодический поток задач.
удалёнка - просто расширяет воронку кандидатов, кто-то готов с этим мириться, а кто-то - банк или оборонка.
джуны бывают разные, если не путать джуна с новичком окончившим курсы - за год и правда можно вырастить хорошего спеца. И если мы раньше боялись что через полгода такой сбежит, то теперь самое время ему научиться и остаться, потому что бежать особо некуда.
Если qr-код содержит токен на предъявителя, по которому потом продавец может затребовать списание, как проходит проверка суммы, по обоюдному согласию данных от продавца и покупателя при подключении к сети, или только по данным от предъявителя токена?
Сам работаю в feature-driven, и радует когда удаётся слышать реальные отзывы, и roadmap строится не из фич соседей по рынку, а из запросов пользователей.
Однако часто встречаю и другой кейс замкнутой техподдержки, где цель оператора не решить проблему, а закрыть тикет. При таком подходе клиент видит проблему, пишет с предложением улучшить, а в итоге ему предлагают "переустановить браузер".
Были и более яркие примеры: однажды тех.партнёр не признал ошибку, но за счёт более грамотного общения в итоге ещё и увёл клиента, пока мы отвечали сухим "проблема не на нашей стороне".
Спасибо, энциклопедично, в своё время очень не хватало такого материала, всё действительно было в рекламных pdf. Не уж то до сих пор так? Надеюсь допишете серию)
Для меня так и осталось загадкой как происходит оценка, когда на основе GAID/AAID/IDFA и облака интересов происходит оценка конверсии, принимая во внимание, что программатик родился ещё до бума нейронок. Но я был со стороны SSP, в магию особо не лез.
Вот тут всё верно. Руководитель может делегировать только свои функции - управление, постановку и/или контроль исполнения.
И тогда, возвращаясь к заголовку, можно сказать что проблема делегирования в том, что ответственность за постановку и за контроль передавать нужно аккуратно.
Говорят даже по-другому: "ответственность нельзя передать, её можно взять", поэтому делегируют только тем кто сам готов взять ответственность за результат.
Передача ответственности заключается в доверии принятия управленческих решений, от простого к сложному по мере роста доверия.
Без передачи ответственности "они" так и будут бегать с каждым мелким вопросом.
Во избежание такого пишутся алиасы для названий классов полиморфных связей. Алиас кладётся в базу и не зависит от неймспейса реального класса.
https://laravel.com/docs/12.x/eloquent-relationships#custom-polymorphic-types
Приятно сделано, и цены не кусаются, вместо своего сворма/кубера можно заехать в готовое облако, вроде все необходимые настройки есть: маршрутизация, секреты, ресурсы... спасибо)
Посмотрел в доке, не увидел возможности маскировать переменные в логах, выходит что секреты будут видны plain text. Для личных экспериментов - не критично, для корпоративных, думаю, ощутимо.
В остальном всё нужное есть, сертификаты можно привезти в контейнере или поставить снаружи, IAM накидать своим контейнером и тоже привезти в готовом виде.
Какой-то SLA заявляете? Судя по user agreement, быстро поднятое упавшим не считается.
По фиксированной цене можно продавать только готовый продукт, а любой кастдев - это всегда субъективная оценка. И так не только в нашей с вами айтишечке. Стадион/завод/дом/мост также строят по примерной оценке плюс риски. А в рисках может быть и x2 и больше.
Спасибо за историю.
А почему не брали оплату вперёд? На сколько помню 2010-ые - тогда это было действительно не модно, доверия к интернет-площадкам особо небыло, но это могло стать выходом из ситуации с кассовым разрывом, а также снизило бы число заказов и возвратов.
Важно уточнить, правда ли я не могу на что-то повлиять, или я просто привык так думать. А забор и правда стоит починить.
Расскажите подробнее где и как тормозят запросы?
17 таблиц, 1300 poi на странице, 50K записей в хранилище... боюсь гадать на кофейной гуще, но кажется нагрузка не в объёме данных и проблема не в типе хранилища.
Я бы посмотрел:
где именно проблема: в бд или в прослойке, так как если браузер показывает pending - это ещё не значит что проблема в бд.
на суммарное количество запросов в бд, возможно не решена n+1.
на структуру запросов, возможно join`ы оптимальнее разбить на отдельные запросы с lazy-load.
банальные индексы не там и не те, лишние сортировки или limit/offset.
на математику внутри запросов, для расчёта попадания координат в область есть стандартные методы.
возможно грузить стоит отдельно координаты для отображения на карте, а отдельно - детальную информацию для просмотра.
Имхо, методики scrum и прочие из семейства - помогают менеджерам как-то контролировать не до конца понятную им область, держать руку на пульсе и корректировать направление как можно раньше. Программистам тоже помогают, но в другом: научиться общаться "словами из рота" и слышать друг друга.
На сколько рьяно следовать каждой из методик - уже зависит от команды и от самого менеджмента, вечный баланс между "шашечки" и "ехать".
Продуктовая и заказная разработка - это два разных мира. Фриланс по проектам на пару месяцев не особо учит вести большие и сложные проекты. Фриланс даст какие-то азы, но лучшее подтверждение опыта - что вы год проработали в серьёзном проекте.
Просите денег по рынку, ну или по своим затратам, в первый год это не важно, гораздо ценнее получаемый опыт. Однако имейте в виду, что повышать зарплату без смены места работы тяжелее, чем вместе со сменой. места. Вдруг захотите остаться)
Смотрите на компании, где будете делать основной продукт, который приносит ощутимую долю прибыли компании. Не нужно "чинить принтеры" (со всем уважением к товарищам). Кстати, это не только it касается.
Ноунейм компании тоже делают классные продукты, почему нет)
HR-ы просто хотят найти подходящего кандидата. Какого - никто не знает. Будьте честны и открыты. Но никто не любит совмещение и непонятный рабочий день. Если вы учитесь, не предлагайте работать между парами.
Я работал на первом курсе, на втором уже работал программистом в ноунейм конторе. Всё реально, если оно вам действительно надо. Но профильное образование всё же лучше.
На фрилансе редко делают упор на качество, да и учиться особо не у кого. Учиться лучше у людей с опытом, чем "по книжкам".
Вуз имеет место в части компаний. Делать приложухи можно без вуза. Расти вглубь и по карьере без вуза сейчас уже тяжелее. Совсем без вуза - не попадёте под всевозможные blue card.
Алгоритмы модно спрашивать, поэтому спрашивают. Может и не пригодится в работе, но олимпиадные и алгоритмические задачи ещё никому не вредили, тут стоит поупражняться.
Врать - а какой смысл? Вот возьмут вас, через месяц расстанетесь - только время потеряете и трудовую замараете. Вы выбираете работодателя точно также как и он вас. Ищите того, кто вам подходит и сможет вам что-то дать, кроме денег конечно.
Желаю удачи!
А почему не создали свой чат? Пусть миллион первый, но по-моему люди активно вступали куда угодно. И конверсия в рамках мессенджера проще.
Алиса повторяет, если ей сказать "что?"
Даже есть баг на эту тему, в режиме разговора:
Алиса: - А знаете что такое ____?
Я: что?
И далее Алиса тут повторяет вопрос, вместо того чтобы продолжить общение
upd: проверил, в режиме "придумай" так не сработало.
Использую именно такое разделение на уровни, с одним лишь дополнением, Lead не просто может спихнуть, а знает кому из сотрудников лучше отдать ту или иную задачу, кому что интереснее и кто сделает качественнее)
Такое разделение называется high context и low context communication. Говорят что эти принципы также являются национальными чертами.
Релиз здорового человека, спасибо вам! За маркдаун — два плюса в карму. За уровни сложности — ещё один. За тёмную тему заготовил грузовик плюсов)
Смутил вывод что "их особенно-то никто и не разрабатывал", имхо это всё же следствие. Нам преподавали что троичные компьютеры просто выходили сложнее и дороже. И охотно верю, что в те времена было проще сбегать-посмотреть заряжена ли ячейка, чем измерять на сколько и каким зарядом.
И отдельный вопрос - хранение заряда разного полюса в соседних ячейках на магнитной ленте. А ещё были перфокарты, где небыло "наполовину-дырок", так что двоичность вроде как оправдана.