Захожу на гитхаб, ищу репозитории проектов, сходные по профилю с теми, для которых мы ищем программистов.
Просматриваю issues, выбираю подходящие — такие, для которых не потребуется слишком много времени (идеально — вечер) и для которых потребуется разобраться в самом проекте.

У каждого соискателя я спрашиваю ссылку на профиль на гитхабе (или других сервисах) или еще какие способы посмотреть на то, что соискатель делал. Если способа показать свой код у соискателя нет (или, например, на гитхабе только один репозиторий и тот с конфигами) — я кидаю ему ссылку на одну из issues и прошу отправить мне ссылку на pull request по завершении.

По pull request'у сразу видно как соискатель умеет разбираться в чужом коде и как он пишет код. Я не даю классических тестовых заданий — это убийство времени в никуда, этот код будет выброшен, он не поможет никому решить какую-либо задачу.

Рассматриваются российские эквайеры с оплатой в рублях. Отсортировано случайно.
Заказчика интересует — куда и как быстро будут переводиться снятые с клиента деньги.

1. www.assist.ru
Много где попадается мне при оплате Webmoney. Никаких замечаний
Для работы с картоном необходимо заключить договор с ucscard.ru, который сотрудничает и с chronopay.com
Комисия 3,9% — 4,2%. Требует открытия счета в Росбанке
Электронная валюта через КИТ Финанс и 4%, открытия счета не требуется.

2. www.chronopay.com/ru
Был пост, что их юзают Вконтакте, даже со скриншотами, но

Вконтакте юзает сейчас

3. www.raiffeisen.ru/business/ecommerce

4. www.cyberplat.ru
на момент проверки сайт недоступен.
1-2 часа не мог зайти. во как

5. www.payonlinesystem.ru
Свежие кажутся.
от 4% и ниже

6. paymentgate.ru
Пишут об ихних требованиях
— Наличие счета у Компании в ОАО Альфа-Банк
— Физическое присутствие на рынке, т.е. наличие наземных точек продаж,
известность на рынке, год успешной работы.
— Оборот компании должен составлять не менее 20 млн. руб. в год.
Случалось, что не мог зайти на сайт, в то время, как на другие вход был

7. liqpay.com
(Приватбанк)
Украина, работают с Россией.
Перевод денег на внутренний виртуальный счет бесплатно, моментально. Есть возможность с ними сделать что угодно. Не совсем удобная схема для крупной коммерческой компании, с контролем финансов, если деньги на счет будут приходить от не резидента. 2 раза общался с суппортом. Время не помню, но отвечали сразу. По вопросу о переводе стредств на р/с счет в России обещали по оставленым контактам ответить.

8. www.pay4all.ru
г. Томск
На текущий момент внедрений не обнаружено
Работают с цифровой подписью.
Получается ЭЦП + эквайринг, что может иметь смысл с нашим непростым законодательством.
Случалось, что не мог зайти на сайт, в то время, как на другие вход был.
Перевод денежных средств на любой счет в банке.

TODO
изучить что говорит Закон об эквайринге.

Посты и страницы в интернете датированные ранее 2008 годом я не читаю.

Мой список книг, которые мне хочется прочесть, изрядно вырос, спасибо топику “запасаемся на зиму”. Под катом вы обнаружите список книг, составленный по комментариям в том топике.

В народе есть известная поговорка „Первый Блин Комом“, чего не могу сказать о своём свежем опыте интернет торговли. Скорее всего, это просто исключение подтверждающее правило, но, тем не менее, хочется рассказать о тех небольших выводах, что я сделал за последний месяц.

Итак, небольшая история о том, как можно довольно легко заработать за один месяц минимум 15 000 евро.

Мой профессиональный род деятельности — веб-разработка. Занимаюсь R&D в одной небольшой IT компании, пишу «навороченные» приложения для корпоративных интранетов и, в принципе, на жизнь не жалуюсь. Конечно, при таком раскладе хочется параллельно вести какой-нибудь интересный проект, чем неоднократно занимался в мире Open Source. Со временем, правда, захотелось на побочных проектах так же как-то зарабатывать, что с Open Source оказалось не так просто, как может показаться из статей на Хабре :) Потому и решил попробовать для себя что-то принципиально новое — открыть интернет магазин.

Не знаю, как у вас, но у меня любимая часть интервью — логические задачи.
Довелось пройти немало собеседований на вакансию разработчика, поэтому набралась небольшая коллекция.
Спешу поделиться с вами!

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

Если вы недовольны своей работой, вам наверняка порой приходит в голову мысль: «Пора бросать это дело». Так почему же вы не бросаете?

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

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

Мы в Alconost перевели для вас статью Александра Кьерульфа, называющего себя одним из мировых экспертов по счастью на работе. Он проанализировал 10 самых распространенных оправданий, мешающих людям бросить опостылевшее рабочее место.

Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

Сегодня публикуем статью нашего коллеги Дмитрия Коткина, уже полюбившегося хабровчанам по теме противостояния давлению в переговорах.

Признаться, мы долго думали, публиковать ли этот материал, потому что тема денег — крайне неоднозначна, и всегда поляризует аудиторию. Более того, статья была написана не для ИТ-шников. Но в конце концов решили статью запостить, потому что приемы там изложены, как нам показалось, достаточно универсальные, и в конце концов там не предлагается вести себя на собеседовании как здесь:

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”

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

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

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



Недавно я просматривал логи и заметил, что на истории движения с этого датчика очень чётко видны фазы моего сна, когда я сплю один. Это не удивительно, он очень хорошо фиксирует любое моё движение, даже если я лежу под одеялом. Сразу же возникла мысль — почему бы не сделать мой будильник «умным»?

После пары лет поисков, мы в Alconost наконец-то нашли инструмент безболезненного управления задачами: Trello. Инструмент простой и не перегруженный лишним функционалом, по сути — это доски со стикерами-тикетами, перемещающимися от колонки “Идеи” или “Предложения” к колонке “Сделано”.

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

О том, как ребятам из Fog Creek Software удалось сделать такой удивительно простой и одновременно функциональный продукт — в посте Боби Грэйса (Bobby Grace) “How We Make Trello”

Переведено в Alconost.

Дейл Риз — один из разработчиков PHP-фреймворка Laravel — выложил на Гитхаб весьма приятную подборку цветовых схем, совместимую с Sublime Text 2, Vim и TextMate. В неё входят преимущественно тёмные темы (21 из 25), и, что бывает не так уж часто, практически все они выглядят очень прилично — есть из чего выбрать. Инструкции по установке и скриншоты каждой темы — в репозитории.
Под катом — скриншоты всех 25 схем.

Robot Odyssey

Нью-йоркский программист Дэвид Ауэрбах (David Auerbach) вспоминает компьютерную игру, для прохождения которой ему понадобилось 13 лет и которая определила его будущее как программиста.

На хабре часто публикуют статьи о самоорганизации — нам всем хочется меньше прокрастинировать, и делать больше полезного. Но что если делать полезное мешает дичайшая усталость? Никакая организация задач усталость не уберет.

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

Итак, если у вас один из следующих симптомов (расположены в порядке усугубления ситуации) — прошу под кат. Как обратили внимание в комментариях — такой список располагает к самовнушению, так что не поддавайтесь :-)

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

Уровень углекислого газа (CO2) один из важных показателей качества воздуха в помещении. Еще его уровень очень удобно использовать для управления вентиляцией.

В статье расскажу о доработке проветривателя и дистанционном управлении вентиляторами посредством микроконтроллеров и датчика CO2.
Также, при желании, после небольшой доработки эту же схему можно применить и для управление приточной-вытяжной системой.

Вот и подоспела вторая часть из серии «Начало Пути»! К сожалению, из-за проблем на работе эту статью пришлось разбить на две части, т.к. времени категорически не хватает.

Итак, мы узнаем о:

1. Звуковых картах.
2. Наушниках.
3. MIDI-Клавиатурах.

P.S. Кстати в этой статье я постарался учесть все ваши пожелания, поэтому хочу предупредить, что все ниже написанное является моим личным мнением.
P.P.S. Цены взяты с сайта muztorg.ru.

Доброго времени суток всем читателям нашего блога! Это первая статья из серии «Начало пути», в которой я расскажу о программной части нашей маленькой звукозаписывающей «студии». В течении недели будет опубликовано еще три статьи — одна про «железо», вторая про базовые термины, которые могут нам повстречаться и еще одна про основы сведения. Эта серия в первую очередь полезна новичкам, знатоки скорее всего ничего полезного для себя не откроют.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Когда-то я* говорил, что без идеального задокументированного кода с многоуровневой плагинной архитектурой заказчик будет мучиться в конвульсиях каждый раз, когда его пальцы будут соприкасаться с клавиатурой. Теперь я заказчик и понимаю, что мне нафиг не нужен идеальный код, депенденси инджекшены и два синьора по цене одного. Главное, чтобы работало и было сделано в срок. И желательно бесплатно.

Когда-то я говорил, что к собеседованию должен готовиться не только соискатель, но и интервьювер. Теперь я сам провожу собеседования, но после десятого интервью все соискатели выглядят как китайцы – одинаково.

Когда-то я говорил, что опаздывать на встречи могут только пид$расы. Теперь я сам часто опаздываю на встречи, но в то же время не сплю с мужиками.

Когда-то я говорил, что главное в любом проекте – правильный процесс. Ну и еще печеньки. Теперь у меня только православный скрам, настоянный на канбане, но проекты факапятся с таким же успехом.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.