mitaichik

OkHttp вроде нормальная, но там зависимость com.google.android. Имеет ли смысл юзать ее на не андройд приложениях?

В общем, покапавшись, выяснилось что в phpStorm для этого есть специальная аннотация @mixin.

Так же с помощью этой аннотации можно помечать и кастомные примеси, например, поведения в Yii

В общем, разработчики PhpStorm ответили что такой возможности пока нет. Попробую написать плагин для шторма, который делает это.

В общем, для этих целей существует ng-init

В общем, не нашел ничего лучше чем написать простенькую функцию:

CREATE OR REPLACE FUNCTION acc_has_expert_rating(ratings acc_rating[])
    RETURNS bool AS
$$
DECLARE
		rating acc_rating; 
BEGIN

	FOREACH rating IN ARRAY ratings
	LOOP 
			IF rating."isExpert" THEN 
				RETURN TRUE;
			END IF;
	END LOOP;

  RETURN false;
END;
$$
LANGUAGE 'plpgsql';

Кому интересно: распознать такую капчу не так то сложно: единственная проблема - это наличие эффекта сферы.

Сначала нам необходимо вычислить центр и радиус сферы. Для этого нам поможет "сетка" которая есть на капче.

Сначала нам необходимо удалить гардиент, так как в середине капчи он может сливаться с сеткой. Гардиент имеет довольно линейную зависимость, поэтому легко вычислить у удалить.

Затем необходимо вычислить координаты линий сетки. Я это сделал с помощью прохода по нижнему и правому краю. Цвет пикселей сетки примерно одинаков (с очень маленьким разбросом), поэтому их легко вычленить.

Затем, проходя по линиям сетки, вычисляется где они сдвигаются в ту или иную сторону - это сообственно начало эффекта сферы. Имея 3 таких координаты (справа/слева и с низу или сверху) можно вычислить его радиус и центр.

Следующий шаг - бинаризация изображения. Для этого можно применить постеризацию и бинаризацию по порогу, Первый, увы больно тупо работает (можно указать только кол-во цветов), второй более точно настраиваемый, поэтому я заюзал его.

Далее у нас получаются чернобелый исходник цифр, но с пустыми пикселями от сетки, и все еще с эффектом сферы.

Следующий шаг - убираем эффект сферы. Это элементарно, ибо мы знаем его параметры.

Далее нам надо "восстановить" пустые пиксели от сетки. Сначала думал юзать дилитацию, но расстояние между цифрами не позволяет это. Затем думал заюзать центры гравитации, чтоб они цифры как бы сжались, удалив пустоты, но не нашел алгоритма для этого. В итоге написал свой алгоритм, который работает гораздо лучше (так как он учитывает координаты линий сетки, в отличии от простой дилитации).

Получаются практически нормальные цифры. Сегментация - написал свой алгоритм, довольно тупой, ничего сложного.

После всего у нас получаются разбитые цифры. На это на все я натравил FANN. Сначала обучил его с помощью антигейта, теперь уже сам работает как надо.

В итоге - капча распознаются с приемлемым результатом. Самое крутое, что все необходимое можно спокойно сделать с помощью imagemagick.

Но существуют 2 проблемы: Если сетка слишком частая - то она при наложении эффекта сферы дико искривляется, что затрудняет поиск начала ее смещения. Плюс если удается вычислить только 2 координаты начала сферы - не удается точно вычислить ее центр по вертикальной оси. Это все влияет на процент распозноваемости.

Но РЖД дает возможность запросить новую капчу, очень быстро, и получается что в среднем за 3 попытки распознавания ее удается обойти в любом случае (но обычно меньше).

Естественно, это все требует времени, но время в моем случае не столь критичное, так как РЖД в лбом случае отдает ответ от 10 до 40 секунд - пользователи уже привыкли к этому, и лишние 2 секунды роли не сыграют.

Вот как-то так...

Я тоже периодически задаюсь этим вопросом. И вот что я надумал:

1. Это, безусловно, опыт. Причем опыт на самых разных уровнях: знание языка и библиотек (SDK, интерфейсов, да хоть список аргументов функций). Опыт проектирования классов - раньше сидел, думал как лучше спроектировать взаимодействие классов, что где разместить и т.п, по 10 раз все переписывал. Сейчас же, прочитав книжки про паттерны, проектирование в общем - структура выстраивается сама собой (я даже не буду упоминать про важность сего при рефакторингах и т.п.). Опыт проектирования целых "подсистем" - например, если ты делал сервис тех-поддержки, или интернет-магазин, то во второй раз ты сделаешь его гораздо быстрее, у всех все примерно одинаково.

2. Опасность веб-разработки (точнее, скриптовых языков) - это "легкость тестирования". Как то я общался с другом - он был веб-разработчиком и переквалифицировался на десктоп. Он говорил, что одна из особенностей в том, что в вебе ты можешь изменить строку, открыть браузер, и просто обновить страницу - ты сразу увидишь результат. В десктопе (а точнее - компилируемых языках) - у тебя пройдет кучу времени, прижде чем проект скомпилируется, поэтому пишешь совсем по другому - много пишешь, потом разом все тестируешь и дебажишь.

И это такой подход действительно гораздо продуктивнее. Сейчас я могу писать по несколько часов, а иногда и дней, и не разу не "обновить страницу" или запустить тесты. А потом разом все отдебажить - поверь, так гораздо быстрее получается. Единственное - такой подход возможен "при опыте", когда ты знаешь как и что писать.

3. Согласен с предыдущем высказыванием - это интерес. То что интересно - действительно можно пилить сутками (но не до фанатизма - это всегда боком выходит). С этой точки зрения хорошо работать в крупных компаниях - там задачи на любой лад. Мой пример из жизни - я сервреный программист, люблю все эти сложные хитросплетения серверных технологий, базы данных, очереди, шардинги и прочее, но... ненавижу фронтенд, ей богу. Не то чтобы не могу, просто очень не люблю. И последне несколько лет, работая в СПб, мне практически не приходилось сталкиваться с фронтендом, но пришлось переехать в маленький город, где с крупными компаниями проблема, устроился в одну контору фуллстек'ом, и когда въехал в проект, понял что там фронтенда очень много, и делать надо преимущественно его. Итог - просрал все сроки, подвел хороших людей, предложил уволить меня так как я им не подхожу, ну меня и уволили. Печальная история. Как вывод - занимайся тем, что нравиться.

4. Тут еще много всего - начиная от быстрого печатания, отсутсвие постоянных переключений между задачами, заканчивая удобной IDE и ос (например, лично для меня на маке оказалось гораздо удобнее работать чем на винде).

Но все-же, прежде всего опыт. Опыт работы над крупными и сложными проектами - на мелких мало чему научишься. И книги. И дисциплина - делать как надо, а не быдлокодить - ибо потом баги и рефакторинг сожрет в десть раз больше времени. В прочем, чтоб не быдлокодить, надо еще понимать "как правильно" - это опять книги. 4 месяца - это мелочь, за это время нельзя научиться хорошо программировать. Так что вот для начала - www.ozon.ru/context/detail/id/5508646 . Когда хорошо освоишься и получишь опыт - вот про паттерны www.ozon.ru/context/detail/id/20217137/. Ну а когда поработаешь над крупными проектами, и поймешь какая обычно жопа у них с бизнес логикой - то вот www.ozon.ru/context/detail/id/5497184

На счет времени - у меня получается с головой окунаться на 4 часа, потом требуется отдохнуть час-два. Отдохнуть - не значит заниматься совсем другим, можно просто переключиться на более простую задачу, рутинную, не требующую супер-концентрации. Потом можно снова концентрироваться. Но у каждого по своему - здесь нет стандартов.

На счет концентрации, как ее добиваться: Года 2 назад я был на Найти-ИТ, там выступал один из основателей Рексофт'а, леция называлась что то типа "Легкий путь из программиста в бизнесмене" - пожалуй, самая мудрая лекция, которую я когда-либо слышал. Он очень рекомендовал книгу "Поток" www.ozon.ru/context/detail/id/6233608/. 2 года я все хотел ее прочесть, недавно прочел - потрясающая книга. Там все ответы на твои вопросы по концентрации, и не только.

Вот еще хорошая книга, которая затрагивает поставленные тобой вопросы - www.ozon.ru/context/detail/id/2338486