Наверняка вы видели такую картинку.
Все, абсолютно все мои коллеги, друзья, знакомые, даже я сам смеюсь над этими горе-разработчиками, захламившими программу кнопками, ссылками и прочим шлаком.
Хотя мне то что смеяться. Я, как архитектор ERP систем, сам регулярно прикладываю к этому свои руки, и понимаю, откуда возникает такой хаос.
Данная заметка является ответом на недавний постJoshua.
Вначале планировался отдельный коммент, но в итоге я понял, что он слишком большой.
Я проработал более 6 лет в компании, которая занимается разработкой и внедрением PDM-системы собственного изготовления. Это несколько другой класс систем для других целей, но смысл и грабли те же самые: имеем крупную корпоративную систему, которая позволяет автоматизировать/информатизировать что-то. Я сам вначале очень поражался тому факту, который был озвучен в статье и целиком и полностью, а именно:
В этом посте я хотел бы рассказать историю развития бесплатной версии моего приложения, которая увидела свет чуть больше года назад. Рассказать о том, как мне удалось исключительно техническими средствами увеличить количество загрузок (и, в данном случае, прибыль) в три раза.
Исторически в Почте Mail.Ru использовался механизм от «большого» Поиска (go.mail.ru); однако для задач поиска по почтовым ящикам такой вариант не был оптимальным ввиду большого потребления ресурсов и относительной сложности в обслуживании. Поиском по почте пользуются около 3% владельцев почтовых ящиков; однако, хотя эта цифра кажется относительно небольшой, ящики этих людей обычно достаточно объемны, и поиск им действительно необходим. Поэтому мы приняли решение написать специализированный поисковый демон, который будет заниматься именно поиском по почте. Основными требованиями к нему стали ограничения по потребляемым ресурсам (размер индекса — не более 3% от размера почтового ящика, среднее потребление оперативной памяти — не более 100 Мб, средняя утилизация CPU — не более 3%) и скорости исполнения запросов (среднее время — не более 200 мс). О том, как он был организован, я расскажу ниже.
В субботу у меня ближе к полуночи появилось свободное время и жгучее желание сделать игрушку под браузер, забавы ради и увеличения опыта для. С жанром определился довольно быстро: т.к. на MMORPG в этот раз у меня точно не хватило бы времени, я решил делать просто мясорубку. Минут 20 ушло на написание базового кода для управления игроком и его противниками. И тут встал вопрос — 2D или 3D (вернее так: Canvas/SVG или все же полноценный WebGL)?
В связи с неожиданным успехом совершенно ненаучной публикации о создании фонов за достаточно краткий отрезок времени, и вследствие неожиданного интереса хабрчан к изобразительному искусству я решил продолжить небольшие, но я надеюсь, увлекательные истории посвященные тому, как можно сделать что-либо просто, и тому из чего это простое состоит.
Сказанное выше означает, что данный материал, как и большинство материалов, которые я планирую публиковать далее, будут, интересны как начинающим, так и вовсе незнакомым с графикой людям, как база на будущее. Довольно развязная манера излагать теорию, неуместные шутки и истории из жизни художников помогут сделать эту публикацию полезной и для тех, кто просто хочет отдохнуть, попутно впитывая новую информацию.
У тех матерых спецов, которые рано или поздно всенепременно явятся сюда, чтобы линчевать меня (хотя бы за подобную манеру изложения и отношение к предмету), — я заранее прошу прощения. Каюсь, грешен, но ничего с собой поделать не могу, и графоманию эту намерен и дальше продвигать в массы.
Партия реверансов сделана, тылы прикрыты, паноптикум можно считать открытым.
Уверен, что голая теория вам нужна не более чем собаке пятая лапа. Признаюсь также, что все разы, когда я сталкивался с голой теорией, заканчивались крепким сном. Когда-то давно, когда я только начинал изучать первый пакет трехмерного моделирования, купив пару толстенных книг и проигнорировав при этом известное положение о том, что важен совсем не размер, со мной начали приключаться удивительные вещи. На первых же страницах. Я засыпал. Позорно. В тех позах, в которых меня застигала чертова книга. Везде. Даже в метро.
Я не хочу того же для вас. Хочу, чтобы история была интересной, а посему – долой нудную теорию, долой правила, лекторский тон и никому не нужный апломб. Никаких графиков, таблиц и сравнений. Только эмоции и веселье, по возможности, наподобие этой работы. Один из артов которые я изготовил во время компании в поддержку финансирования разработки игры Wasteland 2.
Что же останется в статье, если убрать особливо техническую информацию, — спросите вы?
Здравствуйте! В этой статье я вкратце расскажу вам о процессах, потоках, и об основах многопоточного программирования на языке Java.
Наиболее очевидная область применения многопоточности – это программирование интерфейсов. Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации. Например, поток, отвечающий за интерфейс, может ждать завершения другого потока, загружающего файл из интернета, и в это время выводить некоторую анимацию или обновлять прогресс-бар. Кроме того он может остановить поток загружающий файл, если была нажата кнопка «отмена».
Еще одна популярная и, пожалуй, одна из самых хардкорных областей применения многопоточности – игры. В играх различные потоки могут отвечать за работу с сетью, анимацию, расчет физики и т.п.
История началась с того, что в начале дня раздался звонок. Взволнованный голос клиента рассказал, что комп не загружается, документы не открываются, а вместо привычного рабочего стола на экране угрожающая надпись с приблизительным смыслом: «заплати нам деньги и мы вернем тебе рабочий стол и документы». Знакомая многим ситуация: вероятнее всего на компьютере очередной винлокер, работы по выпилу вымогателя займут максимум 10 минут.
Ради удаления винлокера за 10 минут не хотелось ехать в другой конец города, поэтому договорились о том, что системник привезут ко мне, я его приведу в порядок и верну обратно.
Получил системник, включил. Загрузился виндовс ХР. Появился рабочий стол – никаких признаков винлокера, с первого взгляда все нормально. Однако, попытавшись открыть первый попавшийся документ с рабочего стола, получил в ответ «страшное» сообщение:
Недавно нам понадобилось снять несколько видеороликов для своих продуктов. Ролики планировались достаточно короткими и, что характерно, всего их должно было быть около 20 штук. По сути, каждый из них должен был представлять собой «скринкаст» работы с нашими продуктами с тем или иным образом оформленными комментариями.
Тише едешь дальше будешь...? Оценка производительности.
Больше 7 лет я занимаюсь анализом производительности в составе группы Performance Analysis новосибирского отделения Интел. Мы работаем над улучшением производительности различных приложений, а точнее, ищем способы, с помощью которых ее смог бы улучшить наш компилятор. За это время накопился полезный опыт, который, на мой взгляд, был бы интересен посетителям уважаемого Хабра. Речь в данном случае будет идти не об алгоритмической оптимизации приложений, а о различных модификациях приложений без принципиального изменения их алгоритмов. Понятно, что алгоритмические оптимизации программы тоже имеют право на жизнь, но это совсем другая задача.
В настоящее время активно развивается система дистанционного обучения, теперь уже не является проблемой получение полноценного образования практически по любому предмету дистанционно. Онлайн-обучение имеет ряд преимуществ – обучение в индивидуальном темпе, свобода и гибкость, доступность, социальное равноправие. В сети появляется все больше сервисов, помогающих получать новые знания.
Статья содержит перечень ресурсов для онлайн-обучения, представляющих интерес преимущественно для программистов.
Прежде чем приступать вообще к использованию веток, и даже если вы и не думаете их использовать, необходимо прочесть Этот Священный Талмуд.
После того как вы прочли статью о ветках в svnbook, вы уже понимаете для чего нужны ветки, как с ними работать и в каких случаях их необходимо использовать. В принципе, после этого, то, что написано под катом вам уже скорее всего не нужно. Но если вам было лень читать, то может текст ниже вас заинтересует, и вы все таки прочтете статью документации. А может, просто поможет вам лучше понять то, что только что прочли в svnbook-е.
На картинке изображенна турецкая снайперская винтовка с очень подходящим названием — JNG. В статье, как вы уже догадались — речь пойдёт о графическом формате JNG, а отнюдь не об оружии. На хабре уже мелькали темы, касающиеся этого формата, однако их было не много, а некоторые, к сожалению, впоследствии были удалены авторами. Не смотря на то, что JNG не особо популярный формат и базируется на формате MNG, который, судя по всему, можно считать мёртворождённым, у JNG есть одно очень хорошее свойство – это высокая степень сжатия графики с потерями плюс начиие альфа канала.
По сути JNG представляет из себя подвид формата MNG (однако со своим маркером в заголовке, позволяющим отличать оба этих формата). Цветовые данные сохраняются в JPEG формате, а вот альфа может хранится в одном из двух вариантов – либо тоже сжатая при помощи JPEG, как картинка в оттенках серого, либо используя такое же как в PNG — сжатие без потерь.
Где может пригодится JNG? Для меня он больше всего подошёл для хранения текстурных атласов в мобильных играх. Небольшой пример – исходный набор графики от игры весил 57 мегабайт, после замены всех png на jng – набор графики стал весить 15 мегабайт. Неплохой выигрыш для мобильной игры. Поиск других областей, где можно применить jng оставлю на усмотрение читателя, я же опишу чем смотреть, чем создавать а также как грузить (с примерами кода на C/C++) картинки в формате JNG, а также немного теории об его устройстве.
В этой статье описывается как самостоятельно сделать водяное охлаждение для компьютера не используя заводских компонентов. Если есть проблема с шумом или есть желание разогнать процессор, то можно последовать моему решению и сделать аналогичную систему.
Благодаря псевдоклассу :checked, появившемуся в CSS3, можно стилизовать формы с чекбоксами и радиокнопками как угодно. В этом топике рассмотрен один очень простой способ, причем без использования JavaScript.
В данной инструкции я попытался осветить основные моменты разработки игр. Инструкция будет полезна для людей, собирающихся заняться разработкой игр в роли лидера (главного разработчика и организатора).
Хочу отметить, что игры бывают разные – большие и маленькие, сложные и лёгкие, и поэтому для каждой игры эта инструкция верна в какой-то своей определённой степени. Охватить всё не удалось, но передать общие моменты, думаю, получилось.
В процессе развития нашей игры на HTML5, мы столкнулись с дилеммой: рисовать для каждого элемента эффект разрушения или попробовать сделать это программно на JavaScript (canvas). Если с первым способом всё понятно (проверенно работает, но много работы художнику), то со вторым у нас были сомнения относительно скорости рендера, ведь это 60FPS x 64 x 4 байта ~ 1 МБ/сек. на один элемент, а если их 40 на одном экране?
Каждый, кому приходилось заниматься разработкой сайтов, знает об ошибках браузеров.
Однако до сегодняшнего дня я думал, что нужно хотя бы использовать хитрые конструкции CSS, вложенные иерархии DIV-ов и таблиц, всякие float-ы и коллапсирующиеся margin-ы, чтобы налететь на реальную ошибку.
Я был уверен, что существует хотя бы одна ситуация, когда можно не опасаться никаких засад и приколов: мы всегда можем обернуть фрагмент обычного текста обыкновенным DIV-ом (display:block; и float:none;) и быть уверенными, что наш текст останется внутри него:
<DIV>
Этот текст никогда не выйдет за пределы обычного DIV-а!
</DIV>
Но на самом деле нет пределов в этом жестоком мире браузерного маразма: