Pull to refresh
68
0
Дмитрий Ситников @fo2rist

Software developer

Send message
Хорошо напишет индекс только тот у кого будет реальная база с реальными пользовательскими данными, совсем в вакууме его написать не выйдет. А пользу книжек никто не оспаривал, тем более в таких тонких вещах как базы данных, или алгоритмы.
Согласен, и у автора как раз о балансе, и это верно. Главное, не садиться думать надолго.
Очень сложный вопрос. Лично я смотрю по задаче. Ключевые места архитектуры тестируются достаточно тщательно, а общая логика — весьма поверхностно. На моей практике тесты всегда не успевают за динамикой проекта, и просто требуют обновления, вместо того, чтобы давать уверенность. В любом случае нельзя считать, что корректный запуск тестов означает правильность очередного изменения.
Архитектуру, правильную на 90%, уже не так сложно поменять, а практика показывает, что «идеально» выбранная архитектура, вдруг тоже становится неподходящей, когда меняются требования.
Надеюсь, скоро у них закончатся заказчики.
Получил в подарок :) Спасибо!
Общие впечатления хорошие, возникла одна проблема — легкость обнаружения персонажей, поэтому в варианте на 4х мы например кидаем карту эникейщик/инсайдер рандомом, чтобы никто в игре не знал, кто рядом с ним, даже когда хакеры вычислены (он определяются легче всех).
Второе усовершенствование: у нас и инсайдер и эникещик могут возвращать сетевые узлы админу, что также поднимает уровень интриги.
Как я уже писал, прошел примерно год с первой практики, посвященной мобильным устройствам. Сам процесс обучения менялся все это время. Например, конференции мы проводим чуть только пару месяцев, но этот опыт нам уже нравится.
Hello wallpaper там есть, просто потому, что было 100500 часов, но не нашлось именно таких, которые рисуются по всему экрану :) Они позволили мне сэкономить одно место под виджет на девайсе 320x480.
Пожалуй, расширю понятие «неудачное» — приложение, которое не выполняет заявленных функций, или выполняет их плохо (и такие были, они внутренний ценз не прошли).
oDesk Wizard не хватает, функционала, согласен. Но оно для нас успешно, как минимум, нам уже писали из oDesk по его поводу.
А остальные проекты получились не из «студенческих» :)
Часы — демо приложение, для отработки обоев. Кстати, я им пользуюсь: единственные часы, которые «размазаны» по всему экрану.
Shabbat и Yahrzeit, как ни парадоксально, были нам заказаны, и дизайн пришел от заказчика.
Может уйти. К сожалению, формально он нам ничем не обязан. Но мы предлагаем обучение и хорошие условия труда (новые проекты и приятные бонусы), думаю, это достаточно, чтобы у нас оставались люди, которые хотят расти (я правда верю в положительную мотивацию). Кроме того мы можем предлагать долгосрочный контракт, но опять же, юридически он не может задержать сотрудника, только морально.
Неудачное приложение в маркет не попадет (мы не позволим), а цель должна быть стоящей.
Приходят. Уровень разный. Но минимальные требование — понимание алгоритмов и представление об ООП и том, что такое аккуратный код. В противном случае мы можем только посоветовать литературу для домашнего обучения (что и делаем, если кандидату интересно).
Это для сотрудников, но, если сильно хочется, пишите в личку, я добавлю в список, если идея хорошая ;)
Поделитесь интересным? План обучения я, конечно, вижу, он внушителен, но по нему много не поймешь.
Огромное спасибо! Это лучший на сегодняшний день редактор 9-patch.
Да, примерно так. Вроде, уже не мало, и это они только для одного поля показывают сообщение, а если назначить их на другое поле, то понадобится еще и новый экземпляр WatcherErrorNotifier (либо класс придется расширить).
Кроме того АПИ в явном не гарантирует порядок оповещения вотчеров, добавленных через addTextChangedListener.
Чтобы обрабатывать несколько разных полей ввода (на форме их обычно много) нам пришлось бы или вешать на каждое по вотчеру и выносить проверки в отдельный код, или делать большой свич в одном вотчере, чтобы различать, какое именно поле изменилось.
Плюс в валидаторы добавляются чекеры в нужном порядке и каждый со своим сообщением об ошибке, этот код потом гораздо проще поддерживать.
Если не использовать группировку валидаторов (она нужна далеко не всем) и внешние вьюхи для ошибок, кода будем совсем не много. Попробуйте добавить в свой пример еще хотя бы отдельную проверку на пустоту строки и вывод разных сообщений об ошибках, и вы увидите, что кода получится уже не мало.
Тем, что он не является валидатором, а только сообщает об изменениях текста. Собственно, вотчер и используется валидатором, чтобы определять, когда нужно перепроверить условия (если конечно валидатор не работает в «ручном» режиме).
Согласен, можно будет добавить вариант с контекстом и resId, чтобы не писать getString().

Information

Rating
Does not participate
Location
США
Registered
Activity