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

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



Все дело в том, что разработка ПО — это не просто алгоритмы или языки.

Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.

Примечание переводчика: Тема наследования в JavaScript является одной из самых тяжелых для новичков. С добавлением нового синтаксиса с ключевым словом class, понимание наследования явно не стало проще, хотя кардинально нового ничего не появилось. В данной статье не затрагиваются нюансы реализации прототипного наследования в JavaScript, поэтому если у читателя возникли вопросы, то рекомендую прочитать следующие статьи: Основы и заблуждения насчет JavaScript и Понимание ООП в JavaScript [Часть 1]

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

JavaScript является очень мощным языком. Настолько мощным, что в нем сосуществует множество различных способов проектирования и создания объектов. У каждого способа есть свои плюсы и минусы и я бы хотел помочь новичкам разобраться в этом. Это продолжение моего предыдущего поста, Хватит «классифицировать» JavaScript. Я получил много вопросов и комментариев с просьбами привести примеры, и для именно этой цели я решил написать эту статью.

Здравствуйте, коллеги.

Сегодня мы хотели затронуть такую многогранную и противоречивую тему, как фреймворки JavaScript. За последние несколько месяцев в издательстве неоднократно обсуждались перспективы издания книг и по Angular.js, и по Knockout.js, а книга по Backbone.js у нас выходила в прошлом году. Следующий материал призван помочь разобраться в сильных и слабых сторонах различных фреймворков JavaScript. Возможно, после изучения статьи читателю будет проще ответить на вопросы о том, так ли схожи эти фреймворки, и желает ли он дополнительно изучить какую-то из технологий, упомянутых в этом обзоре. Мы же попросим вас поделиться вашими соображениями о том, нужны ли новые книги по этим фреймворкам, если да — то по каким (высказываемся в комментариях, не стесняемся давать ссылки на книги).

Я всегда затрудняюсь ответить на вопрос: откуда берутся идеи для игр? Но в этот раз, я более-менее точно могу сказать, что эта идея родилась у меня когда я увидел баннер «World of Tanks» на каком-то из сайтов. Знаете, бывают такие баннеры, которые привлекают внимание пользователя микро-играми, прежде чем перенаправить его на сайт рекламодателя? Так вот, на этом баннере был танк, который по клику мог проезжать то или иное расстояние, зачем-то пробивая при этом кирпичные стены. Вот именно с этого момента я стал размышлять, по дороге на работу, о раннере с танковой тематикой. Тут же родилась и отсылка к нашумевшему хиту от Wargaming в названии. Она показалась мне забавной, учитывая, что суть моей игры — это движение по некой дороге, пути, с целью пройти максимальное расстояние. Под хабракатом вас ждет рассказ об игре, разработке, технические детали и все-все-все, что должно быть в классической «gamedev story».

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

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

Наверняка многие из вас смотрели онлайн-курсы и думали о том, что способны рассказать не хуже, а то и ещё интереснее? Вы пошли работать в большую компанию, оставив академическую карьеру, но умеете и хотите преподавать? А может быть, вы преподаёте в вузе, но рассказывать из года в год одно и то же, обучая максимум 100 студентов в год, вам кажется неразумной тратой времени в век технологий?

Есть отличная новость!

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

Примечание переводчика: данный пост является логическим развитием, а точнее «предысторией» поста Вникаем в include и extend и был подсказан в комментариях к нему пользователем murr, за что ему большое спасибо.

Классы и объекты в Ruby связаны между собой достаточно затейливо и не сразу можно понять что к чему. Из-за особого назначения классов очень легко потерять из вида тот факт, что классы — это тоже объекты Ruby. От «обычных» объектов их отличает два вещи: они служат образцом для создания новых объектов и они являются частью иерархии классов. Все верно, классы могут иметь экземпляры себя (объекты), суперклассы (родителей) и подклассы (детей).

Если классы — это объекты, то у них должен быть свой собственный класс. Классом всех классов (как объектов) в Ruby является класс Class:

# один из способов создать новый класс
Dog = Class.new
    
# общепринятый способ создания класса
class Dog
    # какая-то реализация собачьего поведения
end

Dog.class
=> Class

Доброго времени!
У нас вышло 2 издание книги Чеда Фаулера «Программист-фанатик»



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

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

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

Безопасность

Тактика хакера: практическое руководство по тестированию на проникновение (The Hacker Playbook: Practical Guide To Penetration Testing)

Книга написана в стиле планирования футбольной игры. Здесь подробно и пошагово разобраны проблемы и трудности, с которыми сталкиваются специалисты по безопасности, тестируя системы защиты. В частности, рассматриваются атаки на различные типы сетей, обход антивирусов и взлом систем безопасности. Автор книги — Питер Ким, специалист по IT-безопасности с многолетним опытом, CEO компании Secure Planet.

Статья даст вам краткий обзор того, как строятся интерфейсы с помощью React JS.
Вы можете параллельно писать код с помощью starter kit, или просто продолжать читать.

Оригинал изображения

Полгода назад я рассказывал про свой опыт работы фрилансером на oDesk. После этого я решил оставить разработку Android приложений на заказ и заняться своей давней мечтой — созданием игр. Мы с друзьями объединились, и работа закипела…

Для начала хочу рассказать о текущем состоянии проекта:
Время от разработки до публикации: 2 месяца
Время нахождения в магазинах приложений: 3 месяца
Загрузки iOS: > 15000 (93 % русскоязычные пользователи)
Загрузки Android: > 35000 (63 % русскоязычные пользователи)

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

Давным-давно мы с друзьями играли в Starcraft по диалапному модему. Я часто проигрывал, пока не прочитал на одной из BBS фразу, которая всё поменяла. Принцип очень простой: в стратегиях реального времени выигрывает тот, кто постоянно атакует. Нужно было научиться мыслить категориями постоянного создания угроз.

К чему я это. Есть такой мужик — Дэвид Сирлин. Киберспортсмен, чемпион по Street Fighter, гейм-дизайнер, настольщик, киберспортивный тренер. У него есть целая теория на тему того, как тренироваться и играть так, чтобы выигрывать. Универсальная, применима ко всем играм. Ниже — основные тезисы первой части и мои комментарии. Прочитать про основные вещи из книги будет интересно и с точки зрения GameDev (в особенности — балансировки), и просто по жизни.

За более чем десять лет моих активных поисков и применения GTD/PM-методик в своей, без малого, десятилетней практике фрилансера и предпринимателя, до меня наконец дошло — серебряной пули нет. Многие знали об этом всегда, мне же понадобились годы. Когда для тебя одновременное количество проектов измеряется не одним десятком. Когда ты прокрастинатор настолько, что даже прокрастинируя этой статьей от работы умудряешься прокрастинировать прокрастинацию чтением писем Лейбница и готов прокрастинировать рекурсивно. Когда ты перфекционист шестого разряда и программист-романтик, то до последнего надеешься, что есть универсальное лекарство. Но его нет…

Было бы счастье, да… многолетние поиски философского камня принесли и свои плоды. У меня накопился большой сундук различных подходов, которыми я хочу поделиться.

От переводчика: при разработке Web-payment.ru, сайта с мониторингом обменников и множеством разделов о платежных системах, я на интуитивном уровне использовал принципы, описанные в этой статье. Подсознательно я их знал, но не мог сформулировать. Предлагаю вам ознакомиться с интересным подходом, которым поделился опытный программист, автор многих книг Jeffrey Ventrella.

Мой папа часто говорил мне: «Помедленнее, сынок, ты делаешь дело слишком быстро».

Мне довелось поработать во многих высокотехнологичных стартапах в заливе Сан-Франциско. Сейчас мне 52 и я программирую медленно и внимательно. Меня можно считать кем-то вроде дизайнера, пищущего код. Читая пост дальше, вы и сами это поймете.

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

Важная правда об асинхронности в своей первозданной форме: нет никакого потока.

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

Не внемлем этим крикам. Если операция по-настоящему асинхронная, то никакого потока нет.

Скептики не убеждены. Высмеем же их.

Здесь было много статей об универсальных Lock-free объектах, однако, для некоторых частных случаев они излишне громоздки. Мой случай как раз таким и являлся: требовалось организовать одностороннюю передачу информации от одного потока другому. Главный поток запускает рабочий, после чего он может только запросить его остановку и никак больше управлять он им не может. В свою очередь рабочий поток может уведомлять главный о своем текущем состоянии (прогрессе выполнения), а также отсылать промежуточные результаты выполнения. Получается, что требуется только передача данных от рабочего к главному потоку.

Разумеется, возможно, я изобрёл велосипед или, хуже того, велосипед с глюками. Поэтому комментарии и критика очень приветствуются!