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

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

Что до моего опыта, то свой первый заказ я выполнил на бирже поздней весной 2005, а уже зимой 2006 ушел с работы и никогда туда больше не возвращался. Мне посчастливилось всегда держать на очень высоком уровне конвертацию заявки в заказ. Как исполнитель я последний раз выходил на биржу во время кризиса 2008-2009, быстро восстановился и с того же 2009 использую их только как заказчик. Вам решать, насколько мои советы будут полезны. А желающих приглашаю под кат и за парты.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

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

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

В эту прекрасную пятницу осмелюсь предложить хабрасообществую небольшую подборку приложений, предназначенных для увеличения продуктивности во время работы с фронтэндом. Если ваш любимый апп здесь не представлен — добро пожаловать в комментарии!

Form Builder



Этот прекрасный генератор форм поможет вам в создании красивейших CSS логин-боксов и прочих input вещей, при минимальных временных затратах. Помимо форм на сайте этого проекта можно создавать и другие не менее красивые CSS элементы, в том числе кнопки и ленты.

Многие слышали про Selenium WebDriver — один из самых популярных инструментов для написания приёмочных/интеграционных тестов.


Используя Selenium, мы очень быстро заметили, что нам раз от раза приходится писать один и тот же код, чтобы инициализировать браузер вначале, закрыть его в конце, делать скриншоты после каждого упавшего теста и т.д. (пруфлинк).

Поэтому мы решили выделить этот повторяющийся код в отдельную библиотеку. Так на свет появился Selenide.

Поиск русского гайда по сдаче на OCAJP 7 не увеньчался успехом, так что я решил написать свой.

Что это за сертификат рассказывают в этом видео. Сдавать или нет каждый решает для себя сам, но этот сертификат является базовым в иерархии Oracle для интересующихся Java.

Для себя я решил сдавать на OCP чтобы во-первых систематизировать знания, а во-вторых поднять привлекательность для работодателей.

Началось как обычно с чтения CodeRanch. Когда я начинал готовиться книг посвященных OCA 7 еще не было в природе. Сейчас уже появился официальный гайд. Но учитывая ценник (30$), я все же воздержался бы от покупки. Сейчас расскажу почему.

С каждым днём во мне крепнет осознание того, что JavaScript стремится играть ту же роль (занять ту же нишу), которая была свойственна Бейсику лет тридцать или даже пятнадцать тому назад.

Иными словами, JavaScript становится простым и распространённым языком, далеко переросшим своё первоначальное предназначение, и на нём теперь можно сочинить почти какое угодно приложение (и клиентское, и серверное, и консольное… и даже с GUI, как я недавно убедился).

Создаются целые операционные системы (Firefox OS, Google Chrome OS, Open webOS), для которых JavaScript является не менее «родным», чем Си для UNIX в своё время.

Появляются языки, транслируемые в JavaScript (можно вспомнить CoffeeScript, Dart, новорождённый TypeScript, и так далее).

Заметив это, уместно тотчас же порадоваться тому, что к джаваскрипту предъявляют, по крайней мере, меньше серьёзных претензий, чем некогда к Бейсику, который по справедливости невзлюбили за его GOTO и поощрение «макаронного кода». Притом джаваскрипт гораздо лучше переносится и с платформы на платформу, и из браузера во браузер.

Кроме того, многие существующие проблемы джаваскрипта не имеют особенного значения, потому что устраняются широко распространёнными средствами с открытым исходным кодом. Так, нестрогость синтаксиса устраняется строгою проверкою исходного кода (JSLint, например). Нехватка средств обработки данных (массивов, объектов) и функций устраняется подключением Underscore, а строки помогает обработать Underscore.string, а даты — moment.js, например. Сложность употребления методов DOM (в которой, впрочем, повинен не язык JavaScript, а браузеры и их разнобой) преодолевается с помощью jQuery. И так далее. Это входит в привычку у программистов.

При создании портала крайне часто основной функцией BackEnd является работа с БД. Как правило сейчас никто не использует обычные и не очень удобные для написания Statement’ы, а в место этого используют ORM фреймворки. В случае с GWT этим фреймворком скорее всего становится Hibernate, так как на сервере у нас Java. Мне далеко не первому пришла в голову мысль о том, что крайне удобно и просто было бы передавать не отдельные данные а целиком POJO(персистентные объекты) используемые Hibernate. Вот я создал свой сервис, возвращающий на клиентскую часть POJO. POJO пронаследовал от Serializable. Запускаю приложение и получаю вот такое вот исключение:

Caused by: com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentSet' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.
at com.google.gwt.user.server.rpc.impl.StandardSerializationPolicy.validateSerialize(StandardSerializationPolicy.java:83)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:591


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

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

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



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

Привет, Хабр!
Все программисты делятся на тех, кто использует систему контроля версий, и тех кто ещё ёё не использует. Одной из самых популярных на сегодняшний день, является git. И хотя его структура направлена на децентрализованное хранение данных, все мы пользуемся github, assembla, bitbucket или githost. Главный недостаток этих хостингов, в том, что это чужие проекты, которые в любой момент могут прикрыть ваш аккаунт или слить данные налево. И тут на сцене появляется GitBlit! Git сервер на Java, полностью контролируемый вами, с множеством плюшек и веб-интерфейсом. Сегодня будем запускать его на бесплатном хостинге от Redhat.

На прошлой неделе на Хабре было целых две статьи о реализации RESTful web-сервисов на Java. Что ж, не будем отставать и напишем свой вариант на Scala, с монадами и аппликативными функторами. Матёрые разработчики на Scala вряд ли найдут в этой статье что-то новое, а любители Django вообще скажут что у них эта функциональность есть «из-коробки», но я надеюсь что Java-разработчикам и просто любопытствующим будет интересно почитать.

Подготовка

За основу возьмём задачу из предыдущей статьи, но постараемся решить её так, что бы код решения умещался на экран. Хотя бы на 40-дюймовый и пятым шрифтом. В конце концов, в XXI веке должна быть возможность решать простые задачи без мегабайтов xml-конфигов и десятков абстрактных фабрик.

Для тех, кто не хочет ходить по ссылкам уточню: мы собираемся реализовать простейший RESTful сервис для доступа к базе данных клиентов. Из необходимой функциональности — создание и удаление объектов в базе, а также постраничная выдача списка всех клиентов с возможностью сортировки по разным полям.

В качестве кирпичиков, из которых мы будем строить дом, возьмём:

• Scala — даже не кирпичик, а скорее фундамент,
• Unfiltered — отличная библиотека для обработки HTTP-запросов,
• Squeryl — библиотека для запросов к базе данных,
• Jackson — библиотека для работы с JSON, изначально написанная для Java, но на ура справляющаяся и со Scala-типами,
• Scalaz — библиотека, позволяющая писать в коде разные забавные символы типа ⊛, ↦ или ∃, а заодно реализующая такие полезные абстракции, как аппликативные функторы, моноиды, полугруппы и стрелки Клейсли. Последние, правда, мне пока не приходилось использовать, но скорее всего это объясняется тем, что я ещё не достиг нужной степени функционального просветления.

По ходу статьи я постараюсь давать достаточно пояснений, что бы код был понятен людям не знакомым со Scala, но не обещаю что у меня получится.

Эта статья – о стандартных управленческих методах, которые помогают повысить эффективность работы и быстро занять высокую позицию даже в такой, казалось бы, не ассоциирующейся с понятием «управление» области, как фриланс.
Речь пойдет о вполне прозаических вещах: стратегическом и календарном планировании, учете и отчетности.
Все, что написано в статье, я проверил на себе в течение года и убедился, что метод работает.

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

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

В этом посте я опишу свои исследования, которые мне пришлось проделать, когда на проекте стал вопрос об автоматизации тестирования. Проект представляет собой веб-сайт, клиентская часть которого написана на Flex, а серверная — на Python(Django).

Выбор средств для автоматизации

Для начала рассмотрим путь от начала, который я прошел, прежде чем остановился на связке Java + Selenium + FlexMonkium. А это:

• Selenium + Sfapi
• Ranorex
• FlexMonkey
• Selenium + FlexMonkium

Поиск по Хабру не нашел подробных статей по системе Alfresco. В данной статье попробую убить сразу двух зайцев: рассказать что представляет из себя система Alfresco и как мы используем ее в нашей работе.

Как хранятся документы в небольшой организации? Самое простое — на локальном диске. А если необходима совместная работа — пересылаются по почте, либо, самый популярный вариант, на сетевом диске. Еще прекрасный вариант — Google Docs, но не уверен что он широко используется в Российской практике.

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

При мысли о системе электронного документооборота первыми на ум приходят дорогие решения от известных вендоров, таких как Microsoft, EMC, 1С и т.д. Но есть и альтернатива закрытым решениям — система управления документами с открытым исходным кодом Alfresco. Или, если по-английски, то Open Source Enterprise Content Management System (ECM, CMS).

Конкуренты Alfresco — это закрытое ПО, такое как EMC Documentum, Open Text, Sharepoint. Сами разработчики Alfresco пишут о своих конкурентах, как о наследии 90-х годов, которое:

• слишком дорого стоит
• слишком сложно использовать, разворачивать, масштабировать
• слишком сложно модифицировать под свои нужды
• слишком “проприетарно”

Попробую рассказать о системе, а вы уже решайте правы ли были разработчики.

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

Сложность материала будет нарастать от начала к концу статьи, так что для профи первые части могут показаться скучными и банальными, но дальше будет намного интереснее :)

В прошлый раз мы попытались разобраться со следующими вещами:

• 1. Не смотря на расхожее мнение «всё в JS является объектами» — это не так, мы выяснили, что из 6 доступных программисту типов данных аж 5 является примитивами и лишь один представляет тип объектов.
• 2. Про объекты мы узнали, что это такая структура данных, которая содержит в себе пары «ключ-значение». Значением может быть любой из типов данных (и это будет свойство объекта) или функция (и это будет метод объекта).
• 3. А вот примитивы – это не объекты. Хотя с ними и можно работать как с объектом (и это вызывает заблуждение что примитив – это объект), но…
• 4. Переменные можно объявить как по простому (литерально) (var a = ‘str’), так и через функцию-конструктор (обёртка)(var a = new String(‘str’)). Во втором случае мы получим уже не примитив, а объект созданный конструктором String(). (что за магический оператор new и что такое функция-конструктор мы узнаем дальше).
• 5. Узнали, что именно за счёт создания обёртки над примитивом (new String(‘str’)) c ним можно работать как с объектом. Именно эту обёртку создаёт интерпретатор вокруг примитива, когда мы пытаемся работать с ним как с объектом, но после выполнения операции она разрушается (поэтому примитив никогда не сможет запомнить свойство, которое мы ему присвоим a.test = ‘test’- свойство test исчезнет с обёрткой).
• 6. Узнали, что у объектов есть метод toString() который возвращает строковое представление объекта (для типа number valueOf() – вернёт числовое значение).
• 7. Поняли, что при выполнении операций конкатенации или математических операциях примитивы могут переопределить свой тип в нужный. Для этого они используют функции-обёртки своих типов, но без оператора new (str = String(str)).(в чём разница и как это работает, поговорим дальше)
• 8. И наконец, узнали, что typeof берёт значения из жёстко зафиксированной таблицы (вот откуда ещё одно заблуждение, основанное на typeof null //object).

Потребовалось мне вывести деньги с PayPal в России, только вот через посредников работать не хотелось.
Пришлось получить карту Payoneer для вывода PayPal на эту карту. Сколько не искал, так и не нашел полноценной, пошаговой инструкции.
Поэтому пишу сам.



ВНИМАНИЕ! Все ниженаписанное является де-юре нарушением законодательства РФ и Украины, и вообще выдумкой автора и плодом работы в фотошопе. Применяя описанное на практике, вы действуете на свой страх и риск, и ни автор, на администрация сайта не несет ответственности за ваши действия.