Pull to refresh
8
0
Александр Жешев @jishi

User

Send message

Дмитрий, спасибо за статью! Настроили у себя в Kibana event_status и event_context, заказчик очень доволен. Этого прям катастрофически не хватало для нормального мониторинга, уже привыкли обходиться "кое-как".

И ещё, можете рассказать, в чём принципиальное отличие Grafana?

Надо устроить конкурс на самое энтерпрайз-решение! Итак, поскольку у нас в штате нет русского гения, который может летмишоую формулу, то нам потребуется база данных, в которые мы занесём множители и результат. База данных, само собой, не в Oracle, а то вдруг санкции, а в православном Postgres Pro. На неё нужна одна виртуалка. Сервер приложений будет на второй виртуалке. Резервирование оставим на Stage2 проекта, заказчик как раз ещё бизнес-фич принесёт: либо сложение с вычитанием, либо таблицы Брадиса, либо фазы Меркурия, с такими заказчиками сложно предугадать. Раз у нас энтерпрайз, писать будем на Java. У меня сегодня генератор дичи барахлит, какие ещё будут предложения, коллеги?

К нам устраивался парень, у которого в резюме было "Опытный пользователь WinRAR". Если бы его не привела мама - может, и взяли бы...

Это чтоб отсеивать тех, кто даже трёхмесячные курсы программирования не осилил?

При этом в новостях перенос чата с айфона на самсунг с помощью стороннего приложения это вин, а с андроида на айфон до сих пор боль: либо бэкапить каждый чат руками, либо покупать левое приложение за 50уе, а оно ещё и просит пароль к гугл аккаунту и к айклауд...

Я так смотрю по рейтингу самой статьи и конкретно моих комментов про уровень технических скиллов у ПМ-а — людям не нравятся такие как я, кто не программировал, не учился в политехе и не обладает технической специальностью и при этом приходят в IT, пусть и на менеджерскую позицию.

Нет, дело не только в «нравится — не нравится». ПМ это прежде всего коммуникация, а она приходит с опытом. То, что вы описали — это поиск работы на позицию координатора проектов, очень джуниор ПМ. Нормальный проджект должен уметь отличать бэк от фронта, знать технический бэкграунд, но прежде всего — понимать процесс разработки. Что на входе, что на выходе, как организовать требования заказчика, как заказчика убедить строить небоскрёб не из фанеры, а скворечник не башенным краном. Я не могу отправить моего прекрасного тимлида общаться с заказчиком в одно лицо: тимлид слишком дофига знает, умеет и может, в итоге мы можем получить непредсказуемый набор работ с непредсказуемый сроками. ПМ должен, не обидев заказчика, уметь говорить «нет», равно как и «да, но после MVP», и не забывать про «вот вам бесплатная плюшка за то, что оплатили нашу работу вчера».
А с другой стороны у меня тимлид и набор девелоперов, каждый со своими плюсами и особенностями, и мне надо понимать, как с ними общаться, какой информацией их порадовать, и кто горит желанием выйти 8 марта за двойную оплату, а кого не пинговать до конца короткой недели.
Коллега, а в какой тулзе вы такие красивые картинки рисуете? Я обычно бизаги пользуюсь, но там уровень визуала чуть ниже, а хотелось бы выше… Или это RM+, в нем сразу и чеки ставятся?
Мы тоже пришли к варианту перевода длинных регламентов в схемы бизнес-процессов, но чек-листы ещё круче и удобнее.
:-) Виноват, не «Монровия», а «Моровия». Это из классического труда Тома де Марко по управлению проектами «Deadline», где разбираются и вопросы, затронутые Вами в статье (замечу, просто отличной) и ряд нескольких других. Если ещё не читали эту книгу — очень рекомендую, написано хорошо, переведено тоже неплохо и без административной ерундистики.
Что касается груминга — он довольно подробно описан как на Хабре, так и в документах по agile, раньше назывался backlog grooming, сейчас backlog refinement и это один из основных артефактов, который очень полезен и тогда, когда наш agile совсем не agile.

Я за 10 лет работы ПМ ни разу не видел компании, где бы PMBoK был в чистом виде, но ряд банков был очень близок. В этом нет ничего плохого, главное, что это работало. Как, наверное, и с любой методологией.

Вот бы о моём сне кто-то так же заботился По факту вы добились ожидаемого результата за счет внедрения уточнения требований, что-то среднее между анализом по PMBoK и грумингом историй. Прямо вплотную подошли к test driven development вот тут: "В идеале, задачи на тестирование должны быть сформированы до регистрации задач на разработку", а это прямой путь к заветной разработке без багов. Не хотите ли заняться шмерцингом информации у нас в Монровии?

Товарищ belator сказал абсолютно верно: получение доходов с приложения физлицом будет квалифицировано как незаконная предпринимательская деятельность. Так что ребятам надо задуматься об ИП (у меня при регистрации ушло около 6 тр на накладные расходы), плюс каждый год в декабре платить взносы в ФСС и ПФ (сейчас вроде всё в налоговой учитывается, но как факт), это порядка 28-32 тр в год, плюс налоги 6% с доходов, из которых вычитается сумма, уплаченная как взносы, плюс 1% за доходы сверх 300к в год.
Инвесторы стартаперам обычно говорят: «если у вас нет конкурентов в этой теме, и вы не создали новый рынок, тогда вы что-то делаете не так».
Интересно, это весь трэвел мира с миллиардными бюджетами на всякий бабложательный сакс не догадался сделать такие карточки? Ох-ох! Не может быть такого, что пара десятков сайтов с такими карточками уже давно на кладбище стартапов? Карточки, наверное, кул. Но что-то все стараются нафигачить картинок на сайт побольше да поярче, некоторые снимают видео тоннами — и только для того, чтобы клиенты составили правильное представление о том месте, куда они поедут в первый раз.
Огромное спасибо. Если вы не против — перепишу на PHP.
Отличное наблюдение! В некоторых банках этот замечательный подход работает на ура. С ужасом вспоминаю клиент-банк, реализованный на почтовых ящиках, систему бюджетирования максимум на 75 клиентов и папку на 300 батничков с именами asasas.bat. Всё работает, к программистам приходишь — сидят смотрят фильмы, а ближайшие две недели выделены на таск «рефакторинг кода». И все при деле.
Нет, зачем? Распознавалка не капч, а сканированных документов. Или это уже не актуально?
А что ещё можно по такому же алгоритму распознавать? Лица? Звуки?.. (пошёл думать)
> Как оказалось каптча не очень сложная и легко поддается взлому.
> Количество правильно распознанных каптч: 49.17 %

А если мой алгоритм объединить с вашей нейронной сетью, то получится отличный онлайн-OCR. Красивая тема :-)
Да, осталось придумать, кому и зачем нужна онлайн-OCRка…
Вот такую капчу расшифровать очень сложно будет. Надо подумать — и над использованием, и над алгоритмом. Спасибо!
Константин, сейчас с каких бирж заказы приходят? И как теперь жить, раз вы принципиально не работаете с СБР? :-)
Кстати, спасибо за совет про md5, даже не подумал.
Спасибо за подсказку, переместил. К сожалению, код правда никакого интереса не представляет.
Вот для интереса пример аппроксимации. Говорят, её ещё можно как-то рассчитывать методом среднеквадратичного отклонения, но я так не умею.

function unify($pix_arr, $width, $height)
{
GLOBAL $maincolors, $approx_lvl;

reset($pix_arr);
$new_arr=array();

$nw=0;
for ($w=1; $w<=$width; $w+=$approx_lvl)
	{
	$nh=0;
	
	for ($h=1; $h<=$height; $h+=$approx_lvl)
		{
		$pix1=$pix_arr[$h][$w];
		$pix2=$pix_arr[$h][$w+1];
		$pix3=$pix_arr[$h+1][$w];
		$pix4=$pix_arr[$h+1][$w+1];
		
		if (!$maincolors[$pix1] || !$maincolors[$pix2] || !$maincolors[$pix3] || !$maincolors[$pix4]) 
			{
			$new_arr[$nh][$nw]=1;
			}
		else $new_arr[$nh][$nw]=0;
		$nh++;
		}
	$nw++;
	}
	
return $new_arr;	
}
Как показывает единичный кейс, даже миллион пикселей может стать миллионом долларов.
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity