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

И эта история о том, как мы разрабатывали систему автоматизации для ресторанов.

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


Если вы не попробовали Ардуино только потому, что не можете начать, не зная что к чему, я сейчас спасу вас.

Давид Ревуа — прекрасный художник, работающий со свободным программным обеспечением, постоянный член сообществ Krita Foundation и Blender Institute, концепт-художник анимационных проектов Gooseberry Open Movie Project, Mango Open Movie Project (Tears of Steel) и Durian Open Movie Project (Sintel). В этой статье он делится с начинающими художниками списком знаний, которые необходимо приобрести, чтобы работы получались реалистичными. Он обращает внимание, что для рисования «в цифре» следует обзавестись теми же навыками, что и в традиционной технике. Итак, приобщимся к его опыту.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

Электронная почта — отличный инструмент коммуникации, который позволяет компаниям доставлять аудитории контент удобным для нее способом. При этом читать письма в формате plain text не всегда удобно, поэтому в современных новостных рассылках используются различные графические элементы.

Вёрстка HTML для электронной почты — интересная и довольно сложная задача. Письма должны одинаково хорошо отображаться на старых устройствах и версиях программных клиентов.

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

Примечание переводчика: Представленный ниже материал содержит значительное количество технических терминов, при переводе которых могут возникнуть неточности. Если вы заметили опечатку, ошибку или неточность перевода — напишите нам, и мы оперативно всё исправим.

Всем, привет! Наша команда сейчас проходит важный этап становления любого разработчика игр — первый запуск игры на Steam Greenlight. Пока я готовил материал для этой статьи, наша игра вошла в ТОП-100 проектов на Greenlight, набрала почти 2000 голосов «ЗА» и через 12 дней получила зелёный свет.

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

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



Хотя игровые достижения не должны быть основной целью в вашей игре, это не мешает им существенно влиять на поведение игрока и его вовлеченность. Давным-давно, на одном из крупных проектов передо мной поставили масштабную задачу: создать мощную систему игровых достижений. В течении следующих 30 месяцев, я, как раб на галерах, провел за проектированием и тестированием различных систем достижений в сотнях игр. Меня поглотила бесконечная обработка данных: игровых комментариев, постов на форумах, непосредственное общение с игроками, изменения в игровых рейтингах. Я совершил и продолжаю совершать кучу ошибок, но я также усвоил несколько бесценных уроков. И эти знания нельзя держать в секрете…

---

Official translation (with a bit of polishing) is available here.

---

Очередная вводная статья для начинающих программировать графику реального времени

У меня когда-то возникла задача (быстро) визуализировать молекулы. Например, молекула может быть представлена просто как набор сфер навроде вот этого:



Конкретно этот вирус состоит из примерно трёх миллионов атомов. Вы можете скачать его модель на замечательном сайте rcsb.org.

Это отличный топик для обучения шейдерам.

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

Deus Ex Human Revolution — это компьютерная игра 2011 года, которая является более успешным продолжением оригинальной Deus Ex, чем Invisible War. Но этот пост не о качестве игры, а о демонстрации её технических принципов. Адриан Курреж провёл несколько часов за реверс-инжинирингом, пытаясь понять с помощью инструмента Renderdoc, как происходит обработка каждого из кадров Human Revolution. Затем Адриан изложил результаты в своём блоге.

Современные SSD-накопители достаточно надежные, а с учетом того, что цена за 1 ГБ (в долларах) постепенно падает, то использовать SSD во многих случаях даже более рационально, чем работа с HDD. Но какой SSD выбрать?

Полтора года назад журналист Tech Report решил провести эксперимент по выявлению наиболее надежных SSD. Он взял шесть моделей накопителей: Corsair Neutron GTX, Intel 335 Series, Kingston HyperX 3K, Samsung 840, Samsung 840 Pro, и поставил все шесть на цикличный процесс чтения/записи. Объем памяти каждого накопителя составлял 240-256 ГБ, в зависимости от модели.

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.

Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.

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

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

Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости.

Можно ли сегодня создать популярное приложение? Рынки поделены, ниши заняты, конкуренция — очень плотная… Но не время разработчикам предаваться печали! Общая планка приложений все еще остается низкой, и обойти всех конкурентов все еще возможно. Так утверждает Кэти Сьерра (Kathy Sierra) в своем выступлении со сложно переводимой темой «Building the minimum Badass User» и его продолжении.

Кэти Сьерра известна в России прежде всего как автор мирового бестселлера «Изучаем Java». Но книги по программированию — это далеко не всё, чем она занимается. Теория обучения, разработка интерфейсов, маркетинг приложений, мотивация — вот неполный список тем, по которым она регулярно пишет статьи и выступает на конференциях. В поле нашего внимания попали именно эти два выступления, потому что они обобщают и резюмируют самое ценное из её собственного опыта разработки, а также сотен прочитанных Кэти научных работ. Перед вами — не перевод, а, скорее, конспект наиболее интересных мыслей и практических рекомендаций.

Много лет назад я был назначен ответственным за пожарную безопасность в одном офисе IT-компании. Выглядело это так: «Распишись здесь и здесь, всё, твою фамилию на щитке повесим, больше ничего не надо». Проблема была в том, что я нашёл, что же действительно означает такая роспись. И начал «строить» всех в офисе по соблюдению правил безопасности. Если вы не пробовали, сообщаю — зачастую очень сложно делать в обычных условиях. В чём проблема? В том, что большая часть людей считает эту норму условностью. Все нарушают, и мы будем.

Теперь представьте, что вы вводите правило, которому невозможно следовать. Или которому не будут следовать, потому что привыкли делать иначе. И не обеспечиваете жёсткий контроль за каждым случаем. Ну, вроде как форума, где материться по правилам нельзя, но модератору плевать. За примерами чуть покрупнее далеко ходить не надо, но не будем сегодня об этом. Представили?

Знаете, что мы в результате только что сделали внутри компании или отдела? Мы создали ситуацию, в которой виноват каждый человек отдельно, но никто в целом. И это очень важный и жестокий инструмент контроля.

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

Знание алгоритма JPEG очень полезно не только для сжатия изображений. В нем используется теория из цифровой обработки сигналов, математического анализа, линейной алгебры, теории информации, в частности, преобразование Фурье, кодирование без потерь и др. Поэтому полученные знания могут пригодиться где угодно.

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

Райан Грум – не совсем типичный разработчик. Он любит технологии так же, как и любой компьютерный фанат. И у него довольно приличный опыт и познания в программировании, IT-безопасности и разработке софта.



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

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

Привет Хабр!

Несколько дней назад я увидел статью об установке системы погодного регулирования в многоквартирном доме. Обладая ReadOnly аккаунтом, я не смог поучаствовать в обсуждении статьи, поэтому решил написать свою, со SCADA и регуляторами, но она не будет столь же оптимистичной, и – спойлер! – будет иметь печальный конец.
Вес картинок под катом ~1.5 мб.

Доброе время суток, хабровчане. Сегодня я хочу рассказать вам про рисование симметричной волнистой линии при помощи Кривых Безье, используя только 2 точки.

Предисловие

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