Если вы когда-нибудь сталкивались с задачей ресайза картинок в браузере, то вы наверное знаете, что это очень просто. В любом современном браузере есть такой элемент, как холст (<canvas>). На него можно нанести изображение нужных размеров. Пять строчек кода и картинка готова:

function resize(img, w, h) {
  var canvas = document.createElement('canvas');
  canvas.width = w;
  canvas.height = h;
  canvas.getContext('2d').drawImage(img, 0, 0, w, h);
  return canvas;
}

Из холста картинку можно сохранить в JPEG и, например, отправить на сервер. Можно было на этом закончить статью, но сперва давайте взглянем на результат. Если вы поставите рядом такой холст и обычный элемент <img>, в который загружена та же картинка (исходник, 4 Мб), то вы увидите разницу.

Здравствуйте, меня зовут Александр Акбашев, я Lead QA Engineer в проекте Skyforge. А также по совместительству ассистент tully в Технопарке на курсе «Углубленное программирование на Java». Наш курс идет во втором семестре Технопарка, и мы получаем студентов, прошедших курсы по C++ и Python. Поэтому я давно хотел подготовить материал, посвященный самым распространенным ошибкам новичков в Java. К сожалению, написать такую статью я так и не собрался. К счастью, такую статью написал наш соотечественник — Михаил Селиванов, правда, на английском. Ниже представлен перевод данной статьи с небольшими комментариями. По всем замечаниям, связанным с переводом, прошу писать в личные сообщения.



Изначально язык Java создавался для интерактивного телевидения, однако со временем стал использоваться везде, где только можно. Его разработчики руководствовались принципами объектно-ориентированного программирования, отказавшись от излишней сложности, свойственной тем же С и С++. Платформонезависимость виртуальной машины Java сформировала в своё время новый подход к программированию. Добавьте к этому плавную кривую обучения и лозунг «Напиши однажды, запускай везде», что почти всегда соответствует истине. Но всё-таки ошибки до сих пор встречаются, и здесь я хотел бы разобрать наиболее распространённые из них.

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

Все начиналось с того, что я приобрел участок земли в деревне, мимо которого не проходили электрические провода. «Ничего страшного, — подумал я. — Ведь по закону меня должны подключить к электросетям за 6 месяцев с момента заключения договора». Если бы я тогда знал, что мне придется освоить автономное энергоснабжение и окунуться в мир солнечной энергетики…

Этой статьей мы открываем цикл статей на Хабре о нашей разработке под Android.
Согласно докладу компании Crittercism от 2012 года, OutOfMemoryError — вторая по распространенности причина «крашей» мобильных приложений.
Честно говоря, и в Badoo эта ошибка была в топе всех крашей (что неудивительно при том объеме фотографий, которые просматривают наши пользователи). Борьба с OutOfMemory — занятие кропотливое. Мы взяли в руки Allocation Tracker и начали играться с приложением. Наблюдая за данными зарезервированной памяти, мы выявили несколько сценариев, при которых выделение памяти росло с подозрительной стремительностью, забывая при этом уменьшаться. Вооружившись несколькими дампами памяти после этих сценариев, мы проанализировали их в MAT (http://www.eclipse.org/mat/).
Результат был занимательный и позволил нам в течение нескольких недель снизить количество крашей в разы. Что-то было специфично для нашего кода, но также выявились типичные проблемы, присущие большинству Android приложений.
Сегодня поговорим о конкретном случае утечки памяти. О нем многие знают, но часто закрывают на это глаза (а зря).

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

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

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

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

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

Всем снова здравствуйте! Дошли руки написать крутую статью на весьма важную тему для разработчиков игр. Итак, поговорим о защите ваших драгоценных игр и приложений, которые вы пилите на Unity в надежде заработать на буханку хлеба, от взлома злобными школьниками. Почему школьниками? Потому что надежной на 100% защиты априори быть не может. И кто захочет, все равно взломает. Вопрос лишь в том, сколько времени и сил он на это потратит. И как любят шутить безопасники — терморектальный криптоанализ никто не отменял.

Итак, в статье я постараюсь максимально доступно рассказать о 3 аспектах (и конечно, предложу реализацию):

• защита данных приложения (сейвов)
• защита памяти приложения
• защита внутриигровых покупок (Google Play)

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Захотелось как-то исполнить команду find в ftp-пространстве, но любой нормальный ftp сервер этого не даст сделать, а решение ну очень хотелось найти.

Все, кто привык к полноценно оформленным страницам сайтов, предпочитает вид «прибитого» (прилипающего, sticky) к низу футера страницы. Но есть в интернете две беды: нерастущие вниз поля ввода и неприбитые (к низу окна) футеры. Например, когда открываем короткие по высоте страницы типа habrahabr.ru/settings/social — сразу бросается в глаза, что информация, призванная быть в нижней части окна просмотра, прилипает к содержанию и находится где-то посередине, а то и в верхней части окна, когда внизу — пусто.

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

Давным-давно мы с друзьями играли в Starcraft по диалапному модему. Я часто проигрывал, пока не прочитал на одной из BBS фразу, которая всё поменяла. Принцип очень простой: в стратегиях реального времени выигрывает тот, кто постоянно атакует. Нужно было научиться мыслить категориями постоянного создания угроз.

К чему я это. Есть такой мужик — Дэвид Сирлин. Киберспортсмен, чемпион по Street Fighter, гейм-дизайнер, настольщик, киберспортивный тренер. У него есть целая теория на тему того, как тренироваться и играть так, чтобы выигрывать. Универсальная, применима ко всем играм. Ниже — основные тезисы первой части и мои комментарии. Прочитать про основные вещи из книги будет интересно и с точки зрения GameDev (в особенности — балансировки), и просто по жизни.

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

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

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



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

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

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



Мы в Яндекс.Почте, сложном и массовом проекте, накопили заметный опыт в поиске и устранении таких утечек, и хотим им поделиться.

Бодрый день, хаброчеловеки!

Что такое Redis?

Redis — это высокопроизводительное нереляционное распределённое хранилище данных. В отличие от Memcached, который может в любой момент удалить ваши данные, вытесняя старые записи новыми, Redis хранит информацию постоянно, таким образом он похож на MemcacheDB.

Чем Redis отличается от существующих решений?

API для работы с Memcached (MemcacheDB) позволяет хранить массивы, но эти массивы будут сериализованы и сохранены как строки, таким образом атомарные операции над такими массивами не возможны.
Redis позволяет хранить как строки, так и массивы, к которым можно применять атомарные операции pop / push, делать выборки из таких массивов, выполнять сортировку элементов, получать объединения и пересечения массивов.

Производительность

110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня (тесты).

Высокая скорость работы Redis обеспечивается тем, что данные хранятся в оперативной памяти и сохраняются на диск либо через равные промежутки времени, либо при превышении определённого количества не сохранённых запросов. Из этого вытекает, что используя Redis, вы можете потерять результаты нескольких последних запросов, что вполне приемлимо для большинства веб-приложений, учитывая, что обращение к Redis по скорости сравнимо с обращением к оперативной памяти. Тем не менее, потерь можно избежать через избыточность — Redis поддерживает неблокирующую master-slave репликацию.

Sharding

Redis, как и Memcached, может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

API

API доступно для следующих языков:

• Ruby
• Python
• PHP
• Erlang
• Tcl
• Perl
• Lua
• Java

API для PHP доступно как в виде модуля, написанного на C, так и в виде PHP5 класса, который общается с Redis-сервером через сокеты, таким образом не требуется устанавливать модуль.
Кроме того существует PHP5 класс от отечественного разрабочика (с именем, заслуживающим доверия. Я серьёзно.) — IMemcacheClient. (Спасибо DYPA за наводку)

Перспективы развития

Разработка ведётся очень активно, комиты происходят почти каждый день, сейчас доступна версия Redis 0.900 (1.0 release candidate 1), которая очень скоро станет версией 1.0
В ближайшем будущем авторы обещают внедрить разные интересные фичи, в том числе и сжатие данных.

Лицензия и поддерживаемые платформы

Redis — написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией =)

Up: Rediska — удобный PHP-клиент для key-value базы Redis. Оф.сайт.

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

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

На Хабре в последнее время вовсе перестали упоминать марсоход «Curiosity», который все также прилежно трудится на Красной планете. Оно и понятно — ведь успехи марсохода постоянны, ну, а плюс ко всему, сейчас устройство находится в транзитной стадии, если так можно выразиться, после чего начнется новая стадия исследований в новой локации. Однако, за последние несколько дней с марсоходом приключилась неприятность — серьезный сбой в электросистеме, которая привела к прекращению работы Curiosity.

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