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

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

Небольшое эссе из книги «Getting Real», написанной сотрудниками компании 37signals. Оригинал можно прочитать здесь.

Спецификация — это абстрактный документ, в большинстве случаев не имеющий ничего общего с готовым программным продуктом. Почему? С удовольствием объясним:

1. Спецификация — это фикция

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

Всего шесть месяцев назад Amazon объявила о том, что электронные Kindle-книги продаются лучше книг в твёрдом переплёте. А уже вчера, в последнем квартальном отчёте о доходах, компания объявила, что электронные книги обогнали и книги в мягком переплёте. Это можно считать важной вехой в издательской индустрии.

[Это перевод статьи из блога компании RethinkDB — калифорнийского стартапа, который занимается разработкой MySQL storage engine, оптимизированного под SSD-диски. Оригинал статьи можно прочитать здесь]

В последние месяцы RethinkDB довольно активно нанимает новых сотрудников, и за это время мы твердо убедились в том, что Джеф Этвуд (Jeff Atwood) в своей статье о FizzBuzz ни на йоту не отошел от истины.

Без лишнего хвастовства могу сказать, что мы предъявляем очень высокие требования к соискателям вакансий. И мы совершенно не намерены снижать эту планку. Более того, мы уверены, что чем больше слабых программистов мы отфильтруем, тем лучше и сильнее в итоге окажется наша команда. Некоторые, впрочем, отмечают, что под наши требования скоро будут подпадать только обладатели PhD в computer science со вторым дипломом по квантовой механике.

Конечно, всё это гнусные инсинуации. Наше основное правило — не нанимать людей, которые не умеют программировать.

Чтобы не быть голословными, мы опубликуем наш основной тест, отсеивающий 19 из 20 кандидатов еще на этапе телефонного собеседования (при том, что до телефонного собеседования мы допускаем не всех подряд, а только тех, чье резюме нам понравилось).

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

Тогда я говорил, что цифры показывают «интересный рост», и казалось, что «экономика выздоравливает». Сегодня я понимаю, что чем больше людей дует в одну дудку, тем быстрее все вокруг начинают плясать под нее.

Мелодия 2011 года называется IPO, и услышать ее музыку сегодня хотят слишком многие.

«Говорящие цифры»

Первая статья об экспериментальном определении характеристик кэш-памяти появилась на свет несколько необычным образом. Играясь с утилитами из lmbench, я получил те самые три графика, и задался вопросом, сколько же информации об исследуемой системе можно из них вытянуть. Определив некоторые характеристики кэша и TLB, я затем задал эти графики студентам как домашнее задание — предвкушая, что им удастся обнаружить что-то такое, что я проглядел. В целом, студенты меня разочаровали, и не заметили даже связь ассоциативности с наклоном ступенек на графике. В конце семестра я собираюсь рассказать им своё решение; а чтобы оно к тому времени не забылось, я написал на скорую руку ту статью.

Затем Yekver предложил мне идею простой программы для Windows, которая определяла бы характеристики кэша автоматически, не требуя ручного анализа графиков. (Тем более, что версии lmbench для Windows не существует.) Для замера времени будем использовать функцию __rdtsc, которая возвращает 64-битное количество тактов с момента последнего сброса процессора. Сначала определим тактовую частоту процессора, замерив на произвольной нагрузке время выполнения и количество потребовавшихся тактов. Затем для расчёта времени доступа к памяти будем делить количество потраченных тактов на тактовую частоту процессора.

Подобно прошлому эксперименту, мы будем брать данные различного объёма от 4КБ до 512МБ, и проходить по массиву миллионы раз с последующим усреднением результата. Чтобы минимизировать влияние дополнительных операций в цикле нагрузки, следуя примеру авторов lat_mem_rd, используем для тела нагрузки операцию p=(void**)*p;, которая компилируется в одну машинную команду, и развернём её 256 раз, чтобы возврат к началу цикла выполнялся относительно редко.

Первого октября 2014 года американское Национальное Агентство Геопространственной Разведки (NGA) опубликовало отчет, в котором изложена критика системы координат Web Mercator, используемой во множестве картографических веб-сервисов. К документу прилагалось подробное разъяснение проблемы и рекомендации для партнеров NGA. Документ получил большой резонанс, но далеко не все статьи, основанные на этом отчете, отличались точностью и грамотностью изложения. Это касается, например, статьи на сайте ГИС Ассоциации, которую, по причине грубейших ошибок в терминологии, можно считать безграмотной. Поскольку именно с этой системой координат разработчики веб-сервисов сталкиваются чаще всего, я считаю, что есть смысл разобраться в проблеме.

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

Мы рады поделиться с вами записью наших выступлений и видео с уникальной секции по высоким нагрузкам с конференции CodeFest. Вы можете задавать ваши вопросы к докладам в комментариях и мы на них обязательно ответим.

1. «Панель: Тренды разработки в высоконагруженных интернет-проектах».
Алексей fisher Рыбак (Badoo) собрал вместе лучших экспертов из Яндекса, Mail.ru, 2ГИС и Communico и обсудил с ними современные тенденции в разработке и поддержке больших высоконагруженных проектов. Плюс эксперты рассказали об интересных решениях и поделились личным опытом.

Всемирная техподдержка

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

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

Свой собственный сленг рано или поздно образуется в любой команде. Айтишный же, наверное, складывается на 90% из словечек, которые более-менее понятны любой другой компании-разработчику, особенно в контексте. А на 10% — из особенностей фунциональности разрабатываемого продукта или конкретного разработчика.
Под катом – профессиональный словарик девелоперов Parallels. А какие у вас в команде крылатые выражения?

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

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


Вот так отныне отображается цена у нас при выборе опций. Вверху Евро, ниже, стоимость услуг в BTC по текущему курсу (-30% скидка)

Очередной приступ паранойи был вполне обоснован — он наступил после прочтения статьи о методах анонимности в сети, где автор на примере браузера FireFox рассказывал о потенциальных утечках идентификационной информации. И стало интересно — а на сколько озвученные решения применимы, скажем, к браузеру Google Chrome?
Скрыть реальный IP — используем разные VPN сервера, отключить львиную долю отслеживающих скриптов — Adblock Plus и Ghostery, убрать Referer — не вопрос, что то ещё забыли… Ах да — User-Agent — своеобразный «отпечаток», по которому (в связке, скажем, с IP) легко идентифицировать пользователя. И с этим надо было что-то делать. Найденные решения лишь статично изменяли значение User-Agent, чего было явно недостаточно. Тогда и было решено написать плагин для скрытия реального User-Agent'a, а если быть точнее — подменять его на рандомный. Или почти рандомный.

Для нетерпеливых сразу: исходники на GitHub и расширение в Google Webstore.

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

Unable to execute dex: method ID not in [0, 0xffff]: 65536
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536

И вы в ступоре, вы неспособны создать DEX файл для APK. Вы не имеете ни малейшего представления о том, что это и как это исправить. И что бы вы не делали, оно будет приводить вас к самому логичному состоянию: ПАНИКА.

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



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

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

Здравствуй Хабр! Хочу рассказать как мы делали свою собственную Big Data.

Каждый стартап хочет собрать что-то дешевое, качественное и гибкое. Обычно так не бывает, но у нас, похоже, получилось! Ниже идёт описание нашего решения и много моего сугубо субъективного мнения по этому поводу.

И да, секрет в том, что используется 6 сервисов гугла и собственного кода почти не писалось.

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

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

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

Можно ли ответить на вопросы клиента еще до того, как он их задаст? Общаться с клиентом по-свойски или в официальном тоне? За какое время надо отвечать на вопросы в почте? Как сделать клиента счастливым и постоянным?

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

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

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

Чуть больше года назад я опубликовал сравнение российских облачных операторов: статья многим понравилась и была полезна. Примерно через полгода я начал получать много отзывов и просьб о том, что неплохо было бы сделать новый обзор, актуализировав данные по ценам, добавив в запрос дополнительные сервисы и дополнив его новыми компаниями. В этот раз в сравнение вошли уже 34 компании (в прошлом году их было более, чем в 2 раза меньше), включая зарубежные сервисы Amazon и Rackspace, а сбор информации занял более двух месяцев.



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