Огромное количество статей и новостей об успехе того или иного стартапа можно встретить сегодня в интернете каждый день. Многомиллионные инвестиции, обсуждаемые сервисы и продукты, вирусные видео о гениях предпринимательства: все это заставляет вас задуматься о создании своего проекта. Вы начинаете изучать данную тему, интересоваться новыми маркетинговыми стратегиями, взахлеб читаете книги популярных гуру бизнеса и в итоге находите ту идею, которая сможет сделать вас миллионером. Вы уверены, что раз многие добились такого успеха, то это не так уж сложно. Есть руководства в интернете, инвесторы и государственные фонды, а также полно информации о легких методах ведения бизнеса. Что может быть легче с такой классной идеей, как у меня?!

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Когда вы используете приложения на node.js в продакшене, вам приходится задумываться о стабильности, производительности, безопасности и удобстве поддержки. Данная статья описывает мои мысли о лучших практиках использования node.js в бою.

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

Всем привет! Хочется затронуть очень важную тему – сколько стоит создание сайта и почему именно столько.

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

Возьмем пример – у вас небольшая компания, которая закупает вещи в Китае и перепродает их в Томске. Продолжительное время вы работали через группы в соцсетях, накопилась некая клиентская база, которая неплохими темпами увеличивается и вам надоело постоянно отвечать в сообщениях какие размеры есть в наличии, что уже продано, что скоро появится в наличии и т.д. Решение очевидно – нужен свой сайт, где будет весь ваш ассортимент с возможностью заказать, оплатить, задать вопрос, в общем, с виду – довольно стандартный интернет магазин. Вы вбиваете в поисковик «создание сайтов в Томске» или открываете 2Gis, рассылаете всем свой запрос и с нетерпением ждете… Примерно половина вам не ответят совсем, потому что это были ребята, которые решили «будем делать сайты», добавили себя в 2Gis, но… «Пацан к успеху шел, не получилось, не фартануло» (с). Заказов нет и они уже давно занимаются другим делом. Еще четверть ответит вам тогда, когда вы уже выберите себе исполнителя. Наверное, они очень заняты, чтобы отвечать на входящие запросы. В сухом остатке получите примерно 15-20 предложений.

Разброс цен получится просто шокирующий, от 5 000р. до 3 500 000р. Скорее всего вы выберете нечто близкое к нижней границе, но не самое дешевое, студию у которой не самое страшное портфолио, тысяч за 25 000 – 30 000р. и они уже сделали несколько подобных магазинов, с мыслью «да, за 1 500 000 конечно очень клево делают, но мне не нужно что-то выдающееся, за 25 нормальный вариант». Это логично, все мы хотим сэкономить и не ясно, почему я должен платить 3 500 000, когда есть предложения выгоднее.

Не так давно, в начале августа, на конференции Android Developer Conference (Andevcon) 2015, проходившей в Бостоне, корпорация Intel анонсировала INDE Multi-OS Engine — фреймворк для разработки нативных кроссплатформенных приложений на Java.

Загрузочная флешка с набором нужного софта — замечательный инструмент системного администратора. Казалось бы, что может быть лучше? А лучше может быть загрузочный сервер!

Представьте, вы выбрали в BIOS загрузку по сети и можете установить ОС/вылечить компьютер от вирусов/реанимировать диски/протестировать ОЗУ/etc с PXE Boot сервера, ведь это куда удобнее, нежели бегать с флешкой от машины к машине.
А в случае большого компьютерного парка, такой инструмент и вовсе незаменим.

Вот такое меню встречает нашу команду инженеров при загрузке с PXE



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

Коллеги, хочу предложить вам описание решений которые помогли в проекте по миграции большого приложения с SQL Server на MariaDB / MySQL.

Возможно, это кому то поможет в аналогичном проекте.

Всем привет! Давненько что-то на хабре не было «экскурсий» по офисам IT-компаний. Не так давно мне удалось побывать в офисе юзабилити-компании UIDesign Group (или сокращенно UIDG), который очень мне понравился.



Именно поэтому я решил рассказать вам о нем.

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

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

Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.

Внимание! Новая информация о переводе!

Здравствуй, подхабр переводов. Я хочу обратиться к тебе с просьбой. Суть просьбы, как все уже догадались, в том, что нужна помощь в переводе. Переводим руководство Эпл по проектированию интерфейсов.¹ Это полезный и важный документ для всех разработчиков и дизайнеров ПО. Да и не только ПО. В нём описываются как общеизвестные, так и не очень распространённые принципы, следование которым сделает дизайн, окружающий нас, на порядок лучше.

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

О нет, опять, только не это!

Начальник отдела только что сообщил нам о том, что нас ждет очередная реорганизация. Все, о чем я мог думать во время его речи — «Ну вот, приехали».

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

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

Потому что большинство из нас уже по горло сыто переменами.

О чем речь?

Кто занимался веб-разработкой на Java, наверняка сталкивался с такой проблемой как java.lang.OutOfMemoryError: PermGen space. Возникает она, как правило, после перезапуска веб-приложения внутри сервера без перезапуска самого сервера. Перезапуск веб-приложения без перезапуска сервера может понадобиться в процессе разработки, чтобы не ждать лишнее время запуска самого сервера. Если у вас задеплоено несколько веб-приложений, перезапуск всего сервера может быть гораздо дольше перезапуска одного веб-приложения. Или же весь сервер просто нельзя перезапускать, так как другие веб-приложения используются. Первое решение, которое приходит на ум – увеличить максимальный объем PermGen памяти, доступный JVM (сделать это можно опцией -XX:MaxPermSize), но это лишь отсрочит падение, после нескольких перезапусков вы снова получите OutOfMemoryError. Хорошо было бы иметь возможность сколько угодно раз перезапускать и передеплоивать веб-приложение на работающем сервере. О том, как побороть PermGen, и пойдет дальнейший разговор.

Переведено в Alconost.

Если сегодня спросить у начинающих предпринимателей на кого они равняются, прозвучат привычные имена: Стив Джобс, Элон Маск, Марк Цукерберг, некоторые вспомнят еще Билла Гейтса. Но, к сожалению, немногие назовут Джеффа Безоса — основателя и генерального директора Amazon.

Недавно нам удалось пообщаться с великим Монти — Майклом Видениусом, автором оригинальной версии открытой СУБД MySQL, который в настоящее время работает над ее ответвлением, MariaDB. (Кстати, обе эти базы поддерживаются в Jelastic.)

Как известно, мир производит и обрабатывает все больше данных (так называемый феномен «Big Data»). Общепринято мнение, что данных теперь так много, что обрабатывать их с помощью традиционных баз данных и программных методов трудно или невозможно. Это вызвало волну нереляционных баз данных (NoSQL), в которых упор делается на высокую масштабируемость. Эксперт в области баз данных, Монти, поделился с нами своими мыслями о текущем и будущем состоянии SQL, NoSQL и Big Data. Некоторые его ответы были несколько неожиданными, так что мы с радостью приводим здесь русский перевод расшифровки нашей беседы:

Герхард Лауссер — эксперт в области nagios-совместимых систем мониторинга, автор множества публикаций, разработчик широко используемых плагинов для мониторинга многих коммерческих систем (один из них — check_hpasm, мы даже подробно разбирали ранее). Интервью выполнено сотрудником компании WürthPhoenix, которая занимается производством систем мониторинга в виде aplliance под торговой маркой NetEye и опубликовано в блоге компании^* в 2010 году. г-н Лауссер излагает взгляд на использование систем мониторинга для мониторинга масштаба предприятия.
_{*Это не реклама, изделия NetEye и продукция компании WürthPhoenix в РФ не поставляется.}

Термин «скрам-бат» (от «scrum, but..») впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

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

Типичные примеры скрам-батов, соответственно, выглядят так:

• У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
• У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

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

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

Приветствую.

Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.

Что же такое Logstash? Зачем он нужен? Что он умеет?