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

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

Описание устройства

WiFi Pineapple — это продукт предприимчивых американцев, которые заказали у китайцев Wi-Fi роутер с двумя беспроводными интерфейсами и одним проводным, написали под него прошивку на базе OpenWRT и напичкали утилитами для взлома\перехвата и анализа трафика.

У устройства 3 сетевых интерфейса (2 беспроводных с возможностью работы в режиме монитора и 1 проводной ), 1 USB порт для флешки\3-4G модема\GPS-треккера и слот для microSD карт.

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

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

Здравствуйте, дорогие читатели Хабрахабра!

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

1. Создание проекта, простой UI, привязка к сервису мгновенных сообщений
2. Делаем красивый UI, добавляем видео и аудио звонки, передачу фото и документов

К сожалению, пособие о том, как набрать 400 000 000 пользователей и продать сервис за 19 Инстаграмов, затерялось где-то на книжной полке. Постараюсь его найти, если кому интересно.

Заинтересовавшихся прошу под кат.

iBeacon, анонсированная Apple в недавнем прошлом технология микро-навигации и микро-позиционирования. iBeacon представляет собой небольшой (размером с монету) девайс, выполняющий функцию маяка. Конкретнее, транслирует через Bluetooth Low Energy сигнал со своим уникальным идентификатором. Сигнал маяка обнаруживается смартфоном с возможностью определения расстояния до него. Дальность обнаружения в зависимости от модели маяка достигает 50-70 метров. Маяк работает автономно от батарейки, которой хватит от полугода до двух, а то и до трех лет.

Возможные области применения ограничены только фантазией:

• in-door навигация в торговых центрах, на выставках и конференциях;
• in-place информация и специальные предложения для посетителей торговых сетей;
• смартфон — экскурсовод в музеях;
• смартфон — ключ от квартиры, автомобиля, номера в гостинице или пропуск в офис.

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

Схема успеха

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



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

На Хабре не раз поднимался вопрос автодополнения адресов в форме (раз, два, три).

Но вот и перед мной появилась задача реализовать такое автодополнение для небольшого интернет магазина. Критерии были такие:

• Автодополнение адресов только Москвы
• Автодополнение адреса одной строкой
• Решение должно быть бесплатно (лимит запросов не менее 1000 в сутки)
• Возможность подключить без дополнительных JS библиотек. (Я использую AngularJS Bootstrap-UI, в котором есть директива Typeahead, реализующая автодополнение формы)
• Стопроцентный uptime не обязателен

Но какой источник данных выбрать? Я выбрал целых четыре, и решил их сравнить: в одном углу ринга заморские Google Geocode и Google Autococomplete, а в другом отечественные КЛАДР в облаке и DaData подсказки.

DISCLAIMER: Автор никак не причастен к разработчикам ни одного из представленных сервисов.

Google использует своего «паука» FeedFetcher для кэширования любого контента в Google Spreadsheet, вставленного через формулу =image(«link»).

Например, если в одну из клеток таблицы вставить формулу

=image("http://example.com/image.jpg")

Google отправит паука FeedFetcher скачать эту картинку и закэшировать для дальнейшего отображения в таблице.

Однако если добавлять случайный параметр к URL картинки, FeedFetcher будет скачивать её каждый раз заново. Скажем, для примера, на сайте жертвы есть PDF-файл размером в 10 МБ. Вставка подобного списка в таблицу приведет к тому, что паук Google скачает один и тот же файл 1000 раз!

=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")
=image("http://targetname/file.pdf?r=4")
...
=image("http://targetname/file.pdf?r=1000")

Все это может привести к исчерпанию лимита трафика у некоторых владельцев сайтов. Кто угодно, используя лишь браузер с одной открытой вкладкой, может запустить массированную HTTP GET FLOOD-атаку на любой веб-сервер.

Атакующему даже необязательно иметь быстрый канал. Поскольку в формуле используется ссылка на PDF-файл (т.е. не на картинку, которую можно было бы отобразить в таблице), в ответ от сервера Google атакующий получает только N/A. Это позволяет довольно просто многократно усилить атаку [Аналог DNS и NTP Amplification – прим. переводчика], что представляет серьезную угрозу.



С использованием одного ноутбука с несколькими открытыми вкладками, просто копируя-вставляя списки ссылок на файлы по 10 МБ, паук Google может скачивать этот файл со скоростью более 700 Мбит/c. В моем случае, это продолжалось в течение 30-45 минут, до тех пор, пока я не вырубил сервер. Если я все правильно подсчитал, за 45 минут ушло примерно 240GB трафика.

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

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

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

На всякий случай договоримся о терминах:

• Проектирование — это детальная проработка с исследованием: задачи, концепция, коммуникация, архитектура, оценка ресурсов. Об этом я писал ранее неоднократно (можно посмотреть в списке моих постов) и буду продолжать писать.
• Бриф (иногда его называют ТЗ, что неправильно по сути)— требования, общая структура сайта на уровне разделов верхнего уровня и их краткого описания. Об этом писали хабра-авторы в разных статьях: Техническое задание на сайт, Техническое задание: как уберечь себя от ошибок и рисков или Типовой шаблон технического задания на разработку сайта
• Agile — определили общую идею, общие требования, провели в меру желания и способностей проектирование — сценарии, пользователи, архитектура — и понеслась. Никто не знает, когда сайт можно будет запускать; это решается по ходу.

NB. Прошу обратить внимание, уважаемые agile-адепты! Я сознательно использую термин Agile не так, как об этом написано в Википедии или в Манифесте. Я использую его для обозначения подхода, когда команда разработчиков не знает, что получится в итоге и действует короткими пробежками с оценкой промежуточных результатов. Именно это я имел «удовольствие» несколько раз наблюдать как подход к созданию сайта.

Методология сравнения проста как пареная репа: рассматриваем каждый метод с точки зрения его плюсов и минусов, применимости. Всё субъективно, основано на личном опыте и опыте коллег. Рассматривать я буду каждый подход применительно к двум самым распространённым типам сайтов — корпоративный сайт компании и коммерческий стартап-сервис.

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Сейчас всё больше мобильных приложений становятся геозависимыми. Одни просто не имеют смысла без знаний о местоположении пользователя, другие становятся с ним удобнее. Это так называемые Location Based Services (LBS): навигаторы, форскверы, инстаграмы с геотегами фотографий и даже приложения-напоминалки, которые срабатывают около конкретного места, например, рядом с офисом или магазином.

Для сервисов и приложений Яндекса мы создали собственную реализацию метода определения местоположения без GPS — Яндекс.Локатор. Он экономит время пользователя и делает наши приложения чуточку умнее. В Навигаторе и Картах она избавляет от ввода начальной точки маршрута, даже если вы на крытой парковке. А при выборе фильма в Киноафише или товара в мобильном Маркете помогает сразу показать, где их найти именно в вашем районе города. Ну и, разумеется, при поиске кафе и банкоматов — позволяет показывать вам сразу ближайшие, даже когда вы в метро.


Технологию мы давно открыли в виде бесплатного API. Сегодня хотим рассказать, как она устроена.

30 и 31 мая в техноцентре Digital October прошел международный форум Positive Hack Days 2012, посвященный вопросам практической безопасности. Полторы тысячи человек, десятки докладов и мастер-классов, масштабные соревнования СTF, насыщенная конкурсная программа — все это PHDays. Сейчас уже можно с полной ответственностью заявить, что нам удалось смешать особый коктейль из представителей интернет-сообщества, профессионалов в области ИБ и хакеров из разных стран мира и что коктейль получился вкусным.

Сегодня мы, как и обещали, публикуем записи докладов и мастер-классов с PHDays 2012. Среди гигабайтов видео, посвященного информационной безопасности, есть вещь, как говорится, посильнее «Фауста» Гёте — доклад Брюса Шнайера, легенды мировой криптографии. Приятного просмотра!

Kismet — это многофункциональная бесплатная утилита для работы с беспроводными сетями Wi-Fi. Пользователям она знакома в основном по статьям на тему взлома, где программа используется для обнаружения скрытых сетей или захвата пакетов. Взламывать чужие сети — плохо, а между тем Kismet — это гораздо больше чем отмычка в руках злоумышленника. В арсенале инженера информационной безопасности эта программа становится прекрасным инструментом для наблюдения и анализа эфира 802.11.

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

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

Производители обычно выпускают рекомендации для построения GUI под их OS. Дошла очередь и до Google Android:

Приветствую вас, уважаемый хабрачеловек!

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

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

Из видеокурса вы узанаете:

• С чего начать разработку плагина.
• Что такое хуки, экшены и фильтры.
• Как сделать страницу настроек плагина в админке блога.
• Принципы программирования на PHP функционала плагина.