Всем привет!

Сегодня расскажу, как на боевых серверах во время нагрузки, в пыли и грязи, эффективно отлавливать узкие места в производительности больших веб-приложений на PHP, а также искать и устранять «нестандартные» ошибки. Многие из описанных техник мы с успехом применяем на нашем облачном сервисе «Битрикс24».
Информация, надеюсь, пригодится системным администраторам и разработчикам, обслуживающим сложные веб-проекты, а также менеджерам, которые хотят выстроить эффективный и быстрый процесс поиска и устранения узких мест и ошибок проектов на PHP.

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

Когда мы рассказывали о нашей системе переводов, нас попросили написать и о том, как идет продвижение TeamLab, в особенности, на зарубежные рынки. Сегодня попробуем. Были и взлеты и падения, шли очень часто методом проб и ошибок, но любой опыт бесценен, вот им и поделимся, может, кому пригодится. Не будем писать умных, и уже ставших банальными, советов про SEO, Adwords и прочее, постараемся быть по максимуму конкретными.



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

В графическом приложении для рисования используется SurfaceView и пара Bitmap размером с экран (например, я хочу изобразить плавное листание страниц книги).

На многих устройствах с большим разрешением экрана приложение падает c ошибкой
AndroidRuntime: java.lang.OutOfMemoryError: bitmap size exceeds VM budget

Проблема в том, что память для Bitmap, а также для SurfaceView резервируется из общей кучи процесса. Лимит размера кучи — невелик, как правило немногим больше 10Мб. И задается этот лимит при сборке системы.

Попытки улучшить ситуацию урезанием формата пикселя с 32 бит до 16 не слишком помогают. Проблема просто вылезает позже — например, при открытии окна поверх SurfaceView (видимо, при этом создается еще один Bitmap размером с экран).

Ограничение размера графических буферов программы в 3-4 экрана — это до обидного мало! Попробуем исправить такую несправедливость.

Доброго времени суток!

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

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

Для примера возьмём приложение Petclinic, исходной код которого можно найти на GitHub. В качестве IDE буду использовать свою любимую IntelliJIDEA.

На Хабре несколько раз публиковались статьи, где JRebel либо просто упоминался, либо выкладывалась информация, что вышла новая версия. При этом, не всем читателям было понятно, о чём вообще речь, и как данное ПО работает.

Как непосредственному участнику разработки данного продукта, мне хотелось бы прояснить некоторые моменты, почему JRebel существует и как он может помочь Java-разработчику.

Откуда ноги растут?

Изначальная проблема известна практически любому разработчику, который работает с Java: после каких-либо изменений в проекте, для того, чтобы увидеть результат, тратится довольно много времени на сборку и развёртывание в контейнере. На Хабре уже публиковались отличные статьи о том, как можно ускорить или автоматизировать процесс разработки, не стану повторяться. Но дело в том, что в упомянутых способах есть свои изъяны: далеко не все изменения возможно перегрузить в развёрнутом приложении штатными средствами; очень легко получить утечки памяти, которые приведут к надобности перезапуска контейнера. Технические детали хорошо расписаны в серии статей в нашем сайте — любопытных приглашаю почитать.

Куда уходит время?

Как выглядит цикл разработки web-приложения, в классическом виде:
1. Сделали изменения в коде (или в ресурсах)
2. Собрали JAR/WAR/EAR
3. Развернули полученный архив в контейнере
4. Открыли развёрнутое приложение, и, после некоторых манипуляций увидели результаты своего труда.

В зависимости от размера приложения, используемого контейнера, и некоторых других факторов, этапы 2, 3 и 4 могут занимать от нескольких секунд, до совершенно невменяемых цифр. Наша компания проводила опрос разработчиков относительно используемых технологий и времени которое затрачивается на развёртывание приложения. Как оказалось, в среднем на развёртывание тратится около 3 минут за раз, и около 10 минут в час. В плачевных случаях, где на развёртывание уходит более получаса, нет даже смысла спрашивать у человека, сколько раз в час он может повторить этот процесс. Ответ очевиден.

Когда перезапуск контейнера/приложения занимает считанные секунды, проблема, описанная выше, не ощущается так сильно. Однако, по мере роста и усложнения проекта, неудобства дадут о себе знать. Тут-то и можно задуматься: может быть, JRebel — это то, что вам нужно?

Про Play уже писали на хабре: Отличный Java MVC фреймворк и ‘Hello World’ tutorial. В этой статье Томас Рёмер из компании ZeroTurnaround рассказывает о своих любимых фишечках в Play! framework.

В течение последнего года я разрабатывал два проекта с помощью Play! Framework. Это сервер лицензий JRebel и LiveRebel. Я перепробовал разные фреймворки для этих двух задач, и в конце концов мой выбор свёлся к двум кандидатам: Struts и Play! Framework. Play! казалась более рискованной, прикольной, бунтарской , в то время как Struts считалась чем-то вроде старой рабочей лошадки, которая работает и гарантированно добивается результата. После некоторых споров в команде мы решили рискнуть и попробовать Play!.. С тех пор я полюбил некоторые особенности Play! больше, чем другие, и хотел бы поделиться своей любовью.

В данной статье я попытаюсь показать, как можно создать простой чат, используя Node.js в связке с Socket.IO. Изначально я хотел построить чат на чистых Websockets, но столкнулся с практически полным отсутствием готовых реализаций сервера для них в Интернете. Так что решил не изобретать велосипед, а использовать готовую библиотеку.
В моем случае сервер работает под Ubuntu, поэтому все примеры будут для неё (и ссылки в примерах — на него же).

Установка компонентов

Первым делом нам потребуются собственно Node.js (инструкция по инсталляции и ссылки на скачивание здесь) и Socket.IO. Модули для Node.js проще всего устанавливать, используя менеджер npm —

curl http://npmjs.org/install.sh | sh
npm install socket.io

Серверная часть

Структура серверной части такова: сервер принимает сообщение, если это команда — выполняет определенные действия, если просто сообщение — рассылает всем остальным участникам.

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

Эмулятор который идет в комплекте с Android SDK, не очень шустрый.
Основная идея использовать VirtualBox + Android X86, для преодоления проблем с производительностью.

Что нам необходимо:
Среда разработки Eclipse + Android SDK тут,
а также VirtualBox.

Под катом много картинок, и процесс установки, а также некоторые полезные советы.

1. Что это такое и зачем это нужно?

In-App Purchase, грубо говоря, представляет собой сервис покупки виртуальных товаров внутри приложения (например игровой валюты, новых уровней, игровых предметов и т.д.). Применяется он в основном в играх, в тех случаях, когда встает вопрос о необходимости заработка на своем творении, а распространять его платно не особо хочется (или нет смысла).

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

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

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

В данном посте я хочу уделить внимание сервису C2DM от компании Google и попытаюсь рассказать, как реализовать поддержку данного сервиса в вашем Android-приложении. Напомню, что C2DM — это специальный сервис, предоставляющий API для отправки сообщений приложениям, установленным на устройствах Android. Использование данного сервиса является незаменимым способом при необходимости передать сообщение пользовательскому приложению, зарегистрированному в системе, но не являющемуся на данный момент активным.

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

Под катом я расскажу, как написать простые клиентское и серверное приложения, покажу некоторые «подводные камни», а также дам ссылки на примеры кода.

У меня для вас есть хорошая новость. Кажется, я сегодня уломал отцов Kerrighed дебианизировать свои труды.

Что это означает для нас, для обычных людей? У вас есть компьютер, где стоит Ubuntu или ещё какой-то Дебиан-подобный Linux? Назовём его Компьютер №1. На нём вы сможете сделать что-то обычное, типа

apt-get install kerrighed-kernel...

ну, вероятно, придётся уж потратить и пару минут на конфигурацию. Далее, перезагрузив Ubuntu, вы увидите новоиспечённое ядро в grub-меню. Выбираете и попадаете в обычную Ubuntu с одним необычным свойством, назовём его "SSI with DRBL"…

Что за зверь «SSI with DRBL»?

Аннотация
Введение
1. auto
2. decltype
3. Ссылка на временный объект (R-value reference)
4. Правые угловые скобки
5. Лямбда-функции (Lambdas)
6. Suffix return type syntax
7. static_assert
8. nullptr
9. Новые стандартные классы
10. Новые направления в развитии статических анализаторов кода
Заключение
Библиографический список

Аннотация

В статье рассмотрены новые возможности языка Си++, описанные в стандарте C++0x и поддержанные в Visual Studio 2010. На примере PVS-Studio рассмотрено, как изменения языка отразятся на инструментах статического анализа кода.

Падение программы — это очень гадкая вещь. К сожалению все мы не идеальны и даже применяя наиболее безопасные методы разработки (например TDD) мы не застрахованы от того что программа свалится. Особенно плохо, если она свалится уже у заказчика. Но на пути к идеалу у нас всегда есть инструментарий, который может помочь расследовать падение программ, выявить ошибки, а главное исправить их.
Одно грустно, что многие, даже очень опытные разработчики не знакомы с этим инструментарием и многие компании не включают данную практику в свою работу. Я говорю о postmortem отладке.
В данной статье я хочу показать азы работы с данным зверем и возможно подтолкну этим самым разработчиков на расширение своих познаний в области оладки. Итак, приглашаются к чтению C++ Windows разработчики, тим-лиды, ну и руководителям отделов разработки будет неплохо ознакомиться.