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

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

Здравствуй, Хабр!

Представляю вам курс «Введение в логику», недавно прошедший на Хекслете. Он основан на учебнике по математике Романа Добровенского. Курс состоит из шести лекций общей продолжительностью 2 часа 20 минут.

• Трейлер курса
• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая и шестая.
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• RSS подкаста (совместим с iTunes; сам iTunes Store пока не принимает новые подкасты)
• Плейлист на YouTube
• Форум курса

Первая лекция. Базовые понятия логики, логические операции, наша первая теорема и закон Де Моргана.

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

Компания Dell взяла курс на полное обновление линеек ноутбуков. Обновлен дизайн лаптопов. Сегодня речь пойдет об одном таком обновлении — Dell XPS 14.

Когда мне предложили познакомиться поближе с ультрабуком Dell XPS 13 Developer Edition, я, честно говоря, довольно долго сопротивлялся. Во-первых, об XPS 13 на Хабре уже написано. Сделал это лично добрых полтора года назад. Во-вторых, Developer Edition в названии означает, что работает ультрабук на Ubuntu 12.04 LTS. Linux для меня — другая планета. Летал туда несколько десятков раз, но каждый раз возвращался обратно. Причем точно не помню — то ли уходил сам с гордо поднятой головой, то ли операционная система давала мне крепкого пинка для ускорения…

В итоге знакомство все же состоялось. И внезапно обнаружилось, что XPS 13 отличается от изученного полтора года назад целиком и полностью, а сама Ubuntu стала настолько удобна для повседневной работы, что я уже несколько дней работаю только на ней, не испытывая ни малейшего дискомфорта. И этот пост тоже целиком написан в LibreOffice Writer.

Что ж, вот и первая статья из обещанной серии.
Первое, что я буду делать — настраивать Software AP, или беспроводную сеть на базе компьютера. На этом этапе, конечно, нужен доступ к консоли сервера с правами рута. Кроме того, нужно также подключение к интернету НЕ через внутреннюю вайфай-карточку — кабелем, через 3G-модем, короче, как пожелаете, но только не по вайфаю, который мы будем использовать для создания беспроводной сети. Я на первое время подключил и сервер, и ноут, с которого управлял сервером, в одну сеть по кабелю — так надёжнее всё-таки. Буду использовать пакет hostapd — он довольно известен как надёжное решение и мануалов под него достаточно, а для DHCP и DNS серверов буду использовать dnsmasq — решение как раз под домашние сети, его использует DD-WRT, не удивлюсь, если кто-то ещё.

Как правильно нарисовать иконку (размер 32х32, часть I)

Хочу предложить вашему вниманию урок по созданию иконок размером 32х32 в программе Adobe Photoshop. Данный урок позволит научиться рисовать иконки не прилагая много усилий – в итоге вы поймете что рисование иконок для интерфейсов не такая уж и сложная задача, нужно лишь запастись терпением, и знать представление о работе в программе Adobe Photoshop.

Итак, начнем! В первую очередь, чтобы иконки не выбивались из размера и были похожи по стилю, нужно сделать шаблон, на основе которого мы будем рисовать серию иконок.

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

Программисты знакомые с ctypes врядли найдут тут что-то интересное, новичков же прошу под кат.

Программирую на Java вот уже 7 лет. Но на работе часто приходится обучать новое поколение. В связи с этим и решил сделать некоторую шпаргалку, которая, надеюсь, пригодится и для хабрчан. Если кто-то может помочь дополнить чем-то информацию из этой статьи, то пишите! Итак:

Основные ресурсы для начального обучения

• www.javable.com — сайт со статьями и tutorial'ом по Java. Все в основном на русском.
• www.exampledepot.com — очень полезный ресурс, где собраны краткие примеры использования классов для тех или иных пакетов
• java.sun.com — без первоисточника не обойтись. Для любого Java программиста JavaDoc должен быть истиной в последней инстанции. Так же здесь можно найти серию tutorial'ов на все возможные темы.

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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

Введение

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

Так давайте попытаемся написать программу, которую проблематично будет создать на других языках. Как следует из названия статьи, эта программа будет редактировать собственный код по мере своего выполнения. Для ее создания я использую Common Lisp, а точнее его интерпретатор SBCL.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

По работе мне несколько раз приходилось участвовать в собеседовании кандидатов на должность клиент-сайдера у нас в компании, смотреть на их познания в Javascript. Удивительно что никто из них не знал толком как же работает jQuery изнутри, даже те, кто отметил свои знания jQuery уровнем «отлично», увы.

У jQuery очень низкий порог вхождения, о нем часто пишут и используют всюду, где только можно (и даже там, где, в общем-то, не нужно), поэтому некоторые даже не смотрят на чистый Javascript. Зачем, мол, его знать, когда есть jQuery, а по нему — тонны примеров и готовых плагинов? Даже на Хабре видел статью про рисование на Canvas, где автор подключил jQuery и использовал его только один раз — для того, чтобы получить доступ к Canvas по его идентификатору. И не считал это чем-то ненормальным.

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

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

Все языки

«Есть два подхода к программированию. Первый — сделать программу настолько простой, чтобы в ней очевидно не было ошибок. А второй — сделать её настолько сложной, чтобы в ней не было очевидных ошибок.»
Tony Hoare. Профессор, занимался реализацией Алгол 60, сейчас исследователь в Microsoft Research.

Algol 60 (позже повлиявший на C)

«Я не мог устоять перед искушением добавить в язык нулевой указатель (null), просто потому, что его так легко было реализовать. Это привело к бессчётному множеству ошибок, уязвимостей и сбоев, которые нанесли ущерб, наверное, в миллиард долларов за последние сорок лет.»
Tony Hoare.

Как известно, наш проект Jelastic создан с целью облегчить жизнь разработчикам, и, конечно же мы всегда прислушиваемся к их пожеланиям, изучаем их психологию, мышление и другие аспекты. Ниже мы публикуем статью одного из ведущих компьютерных публицистов — Нейла МакАлистера — которая ранее публиковалась в InfoWorld и нашем английском блоге.
Некоторые из положений статьи могут показаться спорными (например, мы в каком-то смысле сами «оффшорные» с нашей разработкой в России и Украине), но все они крайне интересны.

Оказывается, даже столь рациональные люди с развитой логикой, как разработчики, верят мифам. Некоторые программисты верят в то, во что они хотят верить, вопреки всему.
Например, классическим заблуждением является мнение, что можно ускорить разработку проекта за счет добавления большего количества разработчиков. Фредерик Брук развеял этот миф еще в 1975 году в своей книге «Мифический человеко-месяц».
Брук считал, что добавление разработчиков в уже достаточно развитый проект никак не ускорит процесс. Напротив, это замедлит процесс разработки еще больше. По сути это опровергает множество общепринятых понятий относительно управления программными проектами.
Конечно, некоторые примеры Брукса кажутся сегодня устаревшими, но общая идея и сейчас актуальна. Его доводы уж очень убедительны. 37 лет спустя, мифическое мышление продолжает преобладать среди программистов. Мы продолжаем делать те же ошибки.
Вот несколько примеров современных мифов о программировании, многие из которых берут начало с более давних заблуждений.

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

На конференции разработчиков видеоигр Casual Connect в Сиэтле сооснователь и глава корпорации Valve, проработавший 13 лет в компании Microsoft Гейб Ньюэлл назвал Windows 8 «катастрофой для всех в сфере PC». Гейб также заявил, что за спад после Windows 8 будет потеряно несколько важных торговых марок производителей оборудования, а для многих пользователей сотрутся границы программных платформ.

Обычно Ньюэлл, рабочий стол которого свободно ездит по всему офису Valve к интересующим его проектам, не демонстрирует своё мнение о тенденциях движения гигантов уровня Apple и Microsoft к закрытым экосистемам, но в интервью Эду Фраю он высказал несколько интересных аргументов.

Гейб говорит, что недооцененный фактор, отталкивающий рыночный интерес от платформы Linux, — это наличие малого количества видеоигр. На данный момент в Valve идут работы над портированием Left 4 Dead 2 и других игр Steam, что является подготовкой к ходу, который сам Ньюэлл назвал «стратегия страховки». Если предсказания главы Valve о Windows 8 подтвердятся, то порты послужат хорошей альтернативой.

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

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

Java существует достаточно долго, на ней написано огромное количество софта и она является лидером в своей области. Однако Java не лишена недостатков. При проектировании языка важным критерием была простота и легкость изучения языка, и эта простота заставляет писать огромное количество лишнего кода, что бы компенсировать недостаточную гибкость языка: паттерны проектирования, XML конфиги, AOP, гетеры-сеттеры, try catch finaly синтаксис и т.д. Так же очевидно что не для всех задач чистый ООП подход является оптимальным, некоторые задачи намного эффективнее выполнять в функциональном стиле.

Существует много разных языков — Groovy, Python, Ruby, JRuby и еще много других, которые потенциально могут заменить java. Так почему же именно Scala?