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

«Наши клиенты были счастливы, продукт великолепен, при этом у нас была ужасная конверсия в регистрации. Вот что мы с этим сделали».

Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.

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

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

Сегодня я хочу рассказать вам о проекте, над которым я работал (и продолжаю работать) в Evernote с 2008 года, и которое несколько дней назад стало Свободным ПО.



Для многих разработчиков локализация ассоциируется с дополнительным пластом проблем: как поддерживать локализованные ресурсы в актуальном состоянии? А что если языков не 2-3, а 20-30? Как вовремя отправлять новые строки на перевод? А что если во время перевода разработка ушла вперед, и каких-то строк уже нет, а есть новые? Как мержить присланные переводчиками файлы ресурсов? Не секрет, что из-за этого многие просто забивают на локализацию или стараются отложить ее на потом.

Сейчас у Evernote более 150 млн пользователей по всему миру, более 70% этих пользователей находятся за пределами США, каждый месяц мы переводим по 15 тыс. новых слов в 40 с лишним проектах на более чем 26 языков, и выпускаем новые релизы наших продуктов одновременно на всех языках. При этом на техническую поддержку всей этой системы требуется один человек, и то изредка.

Как нам это удается?

Привет Хабр. История начинается с того что мы решили сделать гео сервис с возможностью размещения меток на карте самими пользователями.
И когда решили залить в базу 1 миллион маркеров то поняли, что даже если запрашивать маркеры только в определенном радиусе то все работает очень медленно и кластеризация на клиенте тоже не вариант :)

А где-то под этим лесом находится манхетен

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

Сегодня я приготовил для вас большое интервью с Андреем Паньгиным aka apangin, ведущим инженером Одноклассников. Андрей больше 6 лет проработал JVM-инженером в Sun Microsystems, в том числе, в команде HotSpot, а последние 5 лет работает в Одноклассниках, решая там вопросы, связанные с JVM и производительностью. Так что Андрей по праву считается одним из сильнейших JVM-щиков в России.



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

Вот о чем мы поговорили с Андреем:

• чего стоит переезд с Java 7 на Java 8;
• что происходит с sun.misc.Unsafe;
• архитектура Одноклассников;
• инженерные компромиссы, шардинг и GC;
• системы хранения данных и Cassandra;
• в чем Одноклассники впереди планеты всей, а чему еще стоит поучиться у Google;
• как стать крутым системным программистом.

(Я знаю, что начало затянутое. Будем работать над тем, чтобы быстрее раскачиваться и входить в тему.)

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

На сайте centos-admin.ru дизайнер придумал очень здоровский эффект для формы логина. Идея формы состоит в том, что пользователь вводит свои логин и пароль в Redmine и попадает авторизованным на свою страничку.

Все бы здорово, но в Ruby on Rails (на коих Redmine сделан) прямые POST запросы с внешних сайтов не принимаются — для успешного запроса нужен авторизационный токен.

Сей токен генерируется rails-приложениями в автоматическом режиме, хранится в cookies. В связи с этим сперва думал в iframe загружать сайт с Redmine-ом и из cookies брать нужный ключ. Но как-то это совсем не rails-way.

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

Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

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

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

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

В тот же день я получил 18 личных сообщений с просьбой скинуть контакты агентов.

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

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

Я часто езжу на велосипеде и мотоцикле, поэтому вопрос «а будет ли дождь» беспокоит меня достаточно часто. Как оказалось, Центральная Аэрологическая Обсерватория регулярно выкладывает у себя на сайте снимки с метеорологических радиолокаторов. Чтобы ими пользоваться не хватает двух вещей: возможности приблизить карту и посмотреть как двигались облака за последний час. Если добавить эти две фичи, получается полезная штука:

Плохие новости: Росгидромет запретил ЦАО публиковать данные в реальном времени, теперь они доступны с задержкой в 24 часа. Ставьте лайки, возможно, получится в каком-то виде получить актуальные данные обратно.
Ничоси, про это даже петиция есть — "Вернуть открытый доступ снимков ДМРЛ (радары)". И в Росгидромет уже письма писали.

Привет, Хабр!

В одном своём проекте на Yii2 мне захотелось совместить Adjacency List и Nested Sets. Причём так, чтобы в случае отключения поведения Nested Sets, функционал оставался полностью работоспособен. Затем я понял, что Nested Sets мне не нужен, т. к. в базе всё равно приходилось хранить полный путь, поэтому на замену я решил применить Materialized Path. Имеющийся на GitHub Behavior (matperez/yii2-materialized-path) был недостаточно функционален, поэтому пришлось написать свой, а так как я недавно уже писал свои поведения для Adjacency List и Nested Intervals, я решил, почему бы не сделать набор таких поведений с единым API, и возможностью произвольно подключать их к модели одновременно, используя преимущество каждого.

В этой серии публикаций будет описан интегрированный в сервис ViaLatM язык сценариев.



Язык сценариев ViaLatM позволяет:

• Создавать новые параметры на основе сообщений, приходящих от устройств
• Осуществлять логическую обработку событий, возникающих в устройствах
• Формировать новые системные события
• Посылать команды на устройства
• Осуществлять ретрансляцию сообщений устройств во внешние системы

Знаете ли вы JPA? А Hibernate? А если проверить?




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

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

В данной работе примеры приведены на языке програмиирования C.

Для организации работы веб-карт по технологии Slippy Map требуется организовать тайловое хранилище, в котором могут предварительно рендериться (генерироваться) тайлы в заранее заданном контексте карты, либо использоваться набор сервисов для генерации тайлов по запросу, либо некий симбиоз из первых двух подходов.
Первый подход имеет недостаток — требуется слишком большое хранилище для тайлов. Так, по данным OpenstreetMap по состоянию на март 2011 года требовалось 54ТБ места для хранения тайлов. По моим подсчетам для актуальных данных на июнь 2015 года эта цифра уже составляет около 100ТБ (это только оценка, на реальный эксперимент я не решился) для хранения тайлов масштабов 0...17. Такой «прирост» оценок вызван тем, что за прошедшее время данные OpenStreetMap существенно пополнились, детализировались районы, которые в марте 2011 года были пустыми. Нельзя также списывать со счетов неоптимальность сжатия (в моем случае по сравнению с OpenStreetMap) формата PNG (у меня средний размер тайла составляет 4.63КБ против 633 байт OpenStreetMap'а в марте 2011 года), сложность стиля рисования карты mapnik'ом и прочие мои нюансы. В любом случае требуется ОЧЕНЬ много места для тайлового хранилища, что может себе позволить далеко не каждый сервер. Ситуация усугубляется еще и тем, что для блочных файловых систем маленькие по размеру тайлы расходуют целый блок (тайл размером 103 байта может занимать целый блок, например, 4КБ), что приводит к неэффективному расходованию физического пространства жесткого диска. Для большого количества тайлов (для крупных масштабов карт) в рамках одной директории может еще наблюдаться проблема невозможности хранения требуемого количества файлов либо директорий больше, чем позволяет файловая система. Но при всем при этом данный поход обеспечивает комфортное время выполнения запроса на отдачу тайла.
Второй подход хоть и не требователен к емкости тайлового сервера, но требует организовать и поддерживать несколько сервисов (PostgreSQL, Postgis, HStore, mapnik, renderd, mod_tile, apache), которые бы надежно генерировали и отдавали тайл запрашиваему клиентскому сервису. Также требуется периодически подчищать кэш тайлов. Иными словами платой за небольшую емкость жесткого диска тайлового сервера является сложность архитектуры и значительное время выполнения запроса на отдачу каждого конкретного тайла (по моим подсчетам до 500мс только для 1 клиента, для высоконагруженного сервиса это время может вырасти до неприемлемых величин).

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

В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.

В этот раз мы протестировали PostgreSQL на RAID-0 массиве из двух SSD дисков. RAID массив собирался с помощью mdadm. Размер страйпа (блока информации, который распределяется на все диски массива) – 512k.