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

Команда

• Основные роли которые нужно распределить между участниками команды: администратор, дизайнер пространства, технические вопросы, продвижение, ивенты, сообщество, спецпроекты.
• Как правило, в основной команде будет 4-8 человек и еще 5-20 волонтереов или друзей проекта.
• Зарплаты с первого дня. Несколько сильных профессионалов на старте значительно улучшат результат по сравнению с полностью волонтерской командой.
• Коворкинг — это бизнес тысячи мелочей. Все в голове не удержишь, так что нужно использовать вики, гугл-доки или Trello/Basecamp/Asana.

Во второй половине марта 2012 года уязвимость AtomicReferenceArray позволила проникнуть на ноутбук специального агента ФБР Кристофера Стэнгла и похитить с его рабочего стола файл под названием NCFTA_iOS_devices_intel.csv, который содержал список из 12 367 232 уникальных идентификаторов (UDID) устройств на iOS, имена владельцев, названия и тип устройств, токены APN и проч.

Группа Antisec выложила в открытый доступ информацию об 1 000 001 устройств, убрав конфиденциальную информацию, и оставив только поля для идентификации устройств.

Удивительно, что такая книга, как эта, до сих пор не была замечена на Хабре. Не могу не попытаться исправить этот недочет.
Итак, хочу представить вам книгу американского информатика Дугласа Роберта Хофштадтера «Гедель, Эшер, Бах: эта бесконечная гирлянда».

Ахилл: Вот если бы книга называлась «Гориллы, серебро, золото» или «Эму, золото…» — тогда бы я еще мог понять…
Черепаха: Может быть, вы предпочли бы «Медь, серебро, бабуины»?

Будучи написано более тридцати лет назад, это невероятное произведение ничуть не утратило своей интересности.

Я работаю в компании, которая занимается разработкой заказных учётных систем уже достаточно долго. Примерно столько же времени существует технологический отдел — команда людей, которые разрабатывают инструменты и фреймворки для своих товарищей, а те уже в свою очередь создают системы для заказчиков. Кратко можно сказать, что мы (технологи) унифицируем процесс написания бизнес-логики за счёт собственного ORM, объединяем проектировщиков и программистов за счёт UML-редактора с генераторами кода, предоставляем различные UI элементы управления, позволяющие продуктивно работать пользователям конечных приложений.
В этой статье я хочу поделиться своим опытом относительно процесса создания технологического слоя.

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

Наверное, вы уже слышали о таких вещах как CSS3 Pie, Selectivizr, HTML5 Boilerplate, CSS3 Media queries и т.п. Речь пойдет о том, как использовать все эти инструменты вместе: дело в том, что неоднократно были замечены конфликты между ними. Ну, а если вы не совсем понимаете, зачем вам HTML 5 и CSS 3, тогда не стану навязывать эти технологии; просто скажу, что они позволяют сократить время верстки (хотя, это не единственный плюс).

Написать этот пост меня привлекла эта статья. Многие ее помнят по вот этой картинке.

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

My God, it's full of stars!

Arthur C. Clarke

Кто из нас в детстве не мечтал «бороздить просторы вселенной», как капитан Пикард, прогуливаться по неизведанным планетам далёких миров, встречать рассветы двойных или тройных звёзд, погружаться в атмосферы газовых гигантов, ронять корабли в чёрные дыры? И я тоже не исключение. Конечно, частично эту мечту воплощали книги, фильмы и «Элит»-ные игры. Но вся романтика в них разрушалась банальными купи-продай и «пиу-пиу» в «жидком» космосе на скоростях самолётов времён первой мировой войны. Да и тем немногим виртуальным миркам не хватало свободы, детальности и масштабов реальной вселенной.

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

Но вот, чуть больше года назад, я совершенно случайно наткнулся на вселенную Space Engine, и она просто взорвала мне мозг и размазала его по полу своим масштабом и невероятной детализацией.

Ища на просторах сети музыкальный плеер для сайта, я наткнулся на интересный плеер под названием Speakker, написанный на jQuery.

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

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

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

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

Введение

На определенной стадии изучения серверного программирования мне захотелось написать свой простенький фреймворк. Я рассчитывал, что это поможет более глубоко понять идеологию MVC и Zend Framework в частности. Когда дело дошло до части представления и генерации html я вспомнил о паттерне Компоновщик (Composite pattern). Возможно я несколько исказил его применение, но мысль пошла оттуда.

Я думаю, что в процессе изучения той или иной СУБД каждый из вас не раз изобретал велосипеды для решения своих задач, не зная о существовании той или иной функции или приема, которые бы могли в разы ускорить выполнение запросов и уменьшить объем кода. В данной статье я хочу поделиться с вами своим опытом работы с очень «добрым» и «отзывчивым» MySQL, часто позволяющему программисту делать вещи, которые другие СУБД переварить бы не смогли. Материал будет полезен скорее тем, кто только решил углубиться в чудесный мир запросов, но возможно и опытные программисты найдут тут что-то интересное.

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

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Начать свое присутствие на Хабре мы решили с материала, подготовленного для Конференции уральских веб-разработчиков, в котором описаны проверенные на собственной практике и оказавшиеся вполне успешными методы борьбы с DDoS-атаками. Целевая аудитория данной статьи — это программисты, имеющие в распоряжении vds или dedicated. Статья не претендует на полноценное руководство и многие сисадминские нюансы в ней намеренно опущены. Мы рассматриваем только DDoS типа http flood как наиболее распространенный тип DDoS и наиболее дешевый для заказчика.

Целевая аудитория данной статьи – это программисты, имеющие в распоряжении VDS или Dedicated.

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

Введение

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

1. Авторизация пользователей в случае закрытия Loginza или отказа от нее — в этом случае мы потеряем пользователей, в привязанных профилях которых не указан email;
2. Дополнительная информация, например, ВКонтакте умеет отдавать фото пользователя в нескольких видах, в том числе квадратный аватар. С Логинзой получить эти данные не представляется возможным, сервис сам решает какие данные запрашивать и какие отдавать;
3. С момента продажи Яндексу Логинза начала умирать: на запросы пользователей никто не отвечает, сервис не развивается, а находится в том виде, в котором был 1-2 года назад.

Встал вопрос замены и использовать альтернативные сервисы желания уже не возникало — никто не представлял возможности «общаться» с соц. сетью напрямую, а расширенные поля профиля обычно включались в платные услуги. Хотелось автономного решения с возможностью гибкой настройки запрашиваемых полей и в итоге я остановился на php библиотеке HybridAuth.

Описанный ниже метод защиты был взломан, читайте продолжение этого поста: Защита против взломов in-app покупок. Часть 2.

Не так давно шумели новости о активации in-app покупок бесплатно и даже без джейлбрейка. Идея проста: в систему устанавливаются ssl сертификаты и прописывается кастомный dns сервер, который запросы к серверам apple будет пересылать на сервер взломщиков. Сервер взломщиков будет подтверждать покупку и она успешно активируется на устройстве. После выхода этой новости паники было много и Apple даже пришлось что-то делать и рассказывать разработчикам, как защитить их приложение. На самом деле проблема была не нова, на джейлбрейкнутых устройствах уже давно можно было активировать in-app покупки бесплатно. Решение проблемы также не ново, оно описано в документации Apple, но практической реализацией никто себя не утруждал. О моей версии такой защиты и пойдет речь ниже.