Небольшое предисловие. В 2010 году на Хабре был опубликован пост Ebay. Украина. О таможне и пересылках, в котором aevdox рассказал о нюансах доставки товаров с Ebay применительно к Украине и, особенно, об украинских таможенных правилах. Прочитав этот пост, я почувствовал, что мне есть, что к нему добавить, и, не будучи хабражителем, написал письмо автору. Так там появился «Upd # 3».

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

А теперь к сути. С принятием в 2012 году нового Таможенного кодекса Украины (далее – ТК) и его вступлением в силу информация в статье «Ebay. Украина. О таможне и пересылках» сразу же безнадёжно устарела. Прежде всего потому, что новый кодекс отменил нормативно-правовые акты, на которые я ссылался в своём дополнении (Закон № 2681-III, Постановление Кабмина № 1652), и теперь эти отношения регулирует сам кодекс. Регулирует он их уже иначе. Я попытался разобраться с тем, что же изменилось для нас, простых покупателей с Ebay, и соответственно актуализировать информацию в статье.

Если вкратце – «жить стало легче, жить стало веселей».

Хочу рассказать ещё об одной теме, по которой материалов пока что чрезвычайно мало. Речь пойдёт о разработке back-end'а на основе Microsoft Azure Mobile Services. Хотя вводных статей на эту тему немало, легко заметить, что традиционный пример с TodoItems (которым подавляющее большинство введений ограничиваются) содержит потенциальные проблемы для большого проекта.

Самый главный минус демонстрационного проекта заложен в особенностях EntityDomainManager, который вынуждает отправлять через JSON те же классы, что используются в ORM (допустим, используем Entity Framework). Во-первых, сериализуемый класс должен наследоваться от EntityData, получается, что в базе данных оказываются не всегда нужные и удобные поля (например, он идентифицируется строкой, но хорошо ли строить индексы всегда на строках?). Во-вторых, EF располагает к наследованию класса только для схемы code first, не предусматривающей в текущей версии mapping'а на хранимые процедуры (вновь вопрос о быстродействии БД). И, в конце концов, а где тогда слой логики? Ведь структура БД не обязательно тождественна внешнему интерфейсу.

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

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

Знание алгоритма JPEG очень полезно не только для сжатия изображений. В нем используется теория из цифровой обработки сигналов, математического анализа, линейной алгебры, теории информации, в частности, преобразование Фурье, кодирование без потерь и др. Поэтому полученные знания могут пригодиться где угодно.

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.

Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»

Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.

К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.

Что ты предлагаешь, чувак?

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

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

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

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

Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).

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

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

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

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

Автоматизация тестирования – место встречи двух дисциплин: разработки и тестирования. Наверное поэтому, я отношу эту практику к сложным, но интересным.

Путем проб и ошибок мы пришли к следующему технологическому стеку:

1. SpecFlow (опционально): DSL
2. NUnit: тестовый фреймворк
3. PageObject + PageElements: UI-абстракиця
4. Контекст тестирования (информация о целевом окружении, пользователях системы)
5. Selenium.WebDriver

Для запуска тестов по расписанию мы используем TFS 2012 и TeamCity.
В статье я опишу, как мы к этому пришли, типовые ошибки и пути их решения.

Заметил, что на Хабре никто не писал про отличный JavaScript шаблонизатор Swig.

JavaScript в поледнее время становится все более популярным и находит новые неожиданные сферы применения. Вот и меня не обошел этот тренд, так что при just-for-fun разработке одного проекта я не удержался и решил попробовать использовать JS одновременно на сервере (Node.JS), веб-клиенте (Backbone.js — все серьезно :) ) и в мобильном приложении (PhoneGap). Следующим шагом для меня стал выбор шаблонизатора, причем поддержка как node, так и браузера была обязательным критерием. До этого я имел дело в основном в Django Template Language, так что выбор пал на Swig.

Особенности Swig:

• Django Template подобный синтаксис
• Крайне высокая скорость работы (бенчмарки)
• Поддержка node.js и основных браузеров
• Совместимость с Express
• Открытый исходный код

Vim — уникальный по своей гибкости редактор, который при должной настройке может едва ли не идеально удовлетворять все пожелания работающего с ним. Правда эта настройка может продолжаться месяцы, а то и годы, что является и достоинством, и недостатком vim’а. Существует множество статей и туториалов по использованию Vim для разработки на Python и Django, надеюсь мне удастся рассказать что-то новое. В своей статье я постараюсь по минимуму упоминать плагины общего назначения, вроде NERDTree или surround.vim и опишу несколько более специализированных расширений и настроек, которые существенно упростили процесс работы на Python.

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

Надо сразу сказать, что первое руководство действительно для новичков — профессионалы вряд ли обнаружат там нечто секретное и таинственное. Любопытно только то, что в Google не поленились и подготовили соответствующий одностраничный PDF-документ сразу в 13 языковых редакциях, включая и русский (английская версия). При этом документ (А4) выглядит визуально привлекательно и информативно, так что его можно распечатать и повесить в офисе, если вдруг возникнет необходимость в напоминании банальностей.

Второй документ более серьезного уровня и уже только на английском языке. Он довольно подробно и с примерами описывает различные «best practices» вроде создания уникальных заголовков веб-страниц, заполнения мета-тегов или улучшения структуры URL. Забрать документ можно отсюда.

Это перевод статьи Being a Remote Worker Sucks — Long Live the Remote Worker Скотта Хенселмана за 27 февраля.

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

Работать удалённо – прекрасно, отстой.

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

Введение

Во многих web проектах присутствуют элементы, значение которых необходимо часто менять. Это могут быть счётчики, индикаторы, уведомления и подобные элементы. Показывать ли актуальные значения после обновления страницы или же можно реализовать автообновление всех этих данных? Для нас ответ очевиден: если есть возможность динамически менять элементы, то для обновления страниц не остается места.

Здравствуйте! В этой статье я вкратце расскажу вам о процессах, потоках, и об основах многопоточного программирования на языке Java.
Наиболее очевидная область применения многопоточности – это программирование интерфейсов. Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации. Например, поток, отвечающий за интерфейс, может ждать завершения другого потока, загружающего файл из интернета, и в это время выводить некоторую анимацию или обновлять прогресс-бар. Кроме того он может остановить поток загружающий файл, если была нажата кнопка «отмена».

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

Давайте начнем. Сначала о процессах.

В прошлый раз я писал о создании приложения на nodejs с использованием expressjs как фреймворка и jade как шаблонитизатора. В этот раз я хочу остановиться на тестирование серверной части.

Для тестов воспользуемся:
— Mocha — фреймворк позволяющий писать тесты и запускать легко и просто. Генерирует отчеты в различных вариантах, а так же умеет создавать документацию из тестов.
— Should — библиотека для тестов в стиле «утверждения» _{(Не нашел правильного названия)}
— SuperTest — библиотека для тестирования HTTP серверов на nodejs
— jscoverage — для оценки покрытия кода тестами

Первоисточник: Том ДеМарко “Deadline. Роман об управлении проектами”

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

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

Обычно мы пишем про хостинги, в частности про зарубежный shared хостинг в США. Но чтобы писать, нужно иметь аналитические данные под рукой. Вот как раз тут требуется помощь Google Docs, если файл получится предположительно меньше 400 000 строк.

За несколько месяцев работы с таблицами Google пришлось много раз анализировать посредством формул разного рода данные. Как и ожидалось — то, что можно было решить в MS Excel, можно реализовать и в Google таблицах. Но многочисленные попытки решить проблемы с помощью любимого поисковика приводили только к новым вопросам и почти к нулевым ответам.
Посему, было решено облегчить жизни другим и прославить себя.

Кратко о главном

Для того чтоб Excel, либо spreadsheet (таблица Google) поняли что написанное — это формула, необходимо поставить знак "=" в строку формул (Рисунок 1).


Рисунок 1
Далее, начинаем писать формулу с клавиатуры либо выделяем мышкой те ячейки, с которыми мы собираемся работать.

Схема успеха

Джон, мы потеряли два листа математических выкладок! Что делать?
Как обычно, Билл… напиши: «отсюда с очевидностью следует…»



Чтобы прочитать некраткую сопроводительную записку к схеме – добро пожаловать под кат.

Всем привет! В этом топике мне хотелось бы обсудить одну из самых интересных и в тоже время загадочных тем для большинства, как мне кажется, инди-разработчиков – это продвижение своих собственных приложений. Скажу пару слов о себе: я примерно 2 года занимаюсь Android-разработкой (исключительно в качестве хобби, правда). У меня есть десяток приложений в Play Store, с совокупным количеством загрузок более 5 млн. Ни то что бы очень много, да и большая часть загрузок приходится на одно приложение, но какие-то выводы касательно маркетинга я для себя сделал. Здесь я хочу поделиться своим опытом, наблюдениями, а так же призываю Вас рассказывать о своих результатах в комментариях. Обмен опытом в этом вопросе был бы полезен всем, я думаю.

Хорошо это или плохо, но для Android-приложений существует большое количество различных рынков продаж. С одной стороны приходится публиковать в нескольких, с другой — охват обеспечивается более широкий. Когда я задумался о том, что пора бы задействовать альтернативные маркеты для своего приложения, то толковой информации не нашёл. Сразу хочу предупредить, что программа предназначена для узкой русскоязычной аудитории, абсолютно ничем не примечательна, является по сути обычным rss-ридером для моего сайта халявы. Т.е. для многих этот опыт не будет показателен. Также я не использовал никаких средств для раскрутки своего приложения(реклама, обзоры, накрутка).