Любой инженер стремится сделать процесс своей работы максимально оптимизированным. Нам, как мобильным разработчикам iOS, очень часто приходится работать с однообразными структурами языка. Компания Apple улучшает инструменты разработчиков, прилагая много усилий, чтобы нам было удобно программировать: подсветка языка, автодополнение методов и многие другие возможности IDE позволяют нашим пальцам успевать за идеями в голове.



Что делает инженер, когда необходимый инструмент отсутствует? Верно, сделает всё сам! Ранее мы уже рассказывали о создании своих кастомных инструментов, теперь поговорим о том, как модифицировать Xcode и заставить его работать по твоим правилам.

Diablo 1 — это классический roguelike 1996 года в жанре hack and slash. Это была одна из первых успешных попыток познакомить широкие массы с roguelike, которые до этого имели нишевую графику в виде ASCII-арта. Игра породила несколько сиквелов и множество имитаций. Она известна своей тёмной, мрачной атмосферой, сгущающейся по мере спуска игрока в подземелья, располагающиеся под городом Тристрам. Это была одна из первых для меня игр с процедурной генерацией карт, и возможность генерации столь правдоподобных уровней просто потрясла меня.

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

Благодарю Дэвида Бревика и команду Blizard North за создание такой потрясающей игры, а также galaxyhaxz и команду Devilution за их удивительную работу по восстановлению читаемого исходного кода проекта.

Игровой процесс в изучении английского успешно используется уже долгое время и преподаватели ищут новые возможности для его улучшения.

Визуальная новелла — это что-то среднее между компьютерной игрой и классической книгой. По сути это интерактивная история, основу которой составляет текст, но для удобства восприятия читателю демонстрируют картинки героев и локаций.

Именно из-за акцента на тексте визуальные новеллы считаются отличным способом изучения иностранных языков. Но есть несколько нюансов.

• Во-первых, большинство визуальных новелл создается в Японии. Естественно, на японском. Если вы учите японский — радуйтесь и пользуйтесь. Но для изучения английского нужно обратить внимание на локализацию — далеко не всегда они получаются хорошими.
• Во-вторых, если локализация удалась, то это вдвойне хорошо. Ведь при переводе локализаторы очень нечасто используют сложные или малоиспользуемые конструкции и лексику, ограничиваясь общеизвестной. Поэтому практически все хорошие новеллы можно читать с уровнем английского Intermediate и Upper-Intermediate.

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

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

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

Лечу Crash'и NSLog'ами. Недорого. Многолетний опыт. 100% гарантия.

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

Все началось с того, что на одном из относительно больших проектов начало стабильно вываливаться исключение при авторизации пользователя. «Ну и что тут такого? У всех бывает. Проверку на nil забыли поставить или где-то накосячили. „Тоже, мне, большое событие — crash на проекте“, — подумает большая часть программистов. В принципе — абсолютно согласен. Crash — не такое уж и редкое явление в программировании под iPhone, и с ним сталкиваешься по десять раз на день. Но этот был особенным. От него уже начало попахивать „магией“, когда мне сказали про его некоторые параметры и особенности:

• Воспроизводимость на симуляторе: 100%
• Воспроизводимость на устройстве: 0%
• Путь к крэшу (после локализации крэша): ~ 40 секунд
• Настройки оптимизации при компиляции (-O1,-O2...) не влияют на воспроизводимость
• XIB'ы в проекте не используются

Да выглядел он довольно безобидно:

// Code
UITextView * textView = [ [UITextView alloc] initWithFrame:CGRectMake(0, 150, _width, _height)];

// Exception
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', 
    reason: 'CALayer bounds contains NaN: [0 0; nan 200]'

»Ну тут же и ежу понятно, что width — после вычисления — NaN!", — подумал я. Бегло поглядев где и как вычисляется ширина вьюхи, и не найдя ничего особого опасного, я, для утверждения своей догадки, поставил перед созданием вьюхи NSLog. А вдобавок, и точку останова на строке с созданием элемента.

// Source:
NSLog(@"width = %f", _width);

//Output:
width = 200

«Гм», — подумал про себя я, и продолжил выполнение программы после точки останова. И крэша не произошло…

Введение

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

Есть у меня папка со старыми картинками, которые я собирал в нулевых. Переношу с компьютера на компьютер вместе со всеми моими файлами при каждом апгрейде, изредка захожу поностальгировать. Но каждый раз меня немного смущало то, что стандартный просмотрщик Windows 7 не показывал GIF-анимацию, хотя память мне подсказывала, что во времена XP анимация показывалась без проблем. При очередном приступе ностальгии я всё же решил запустить просмотрщик из XP на Windows 7. После преодоления ряда препятствий, я теперь уверен — GIF-анимация там действительно поддерживалась! А главное — теперь я могу смотреть свою старую папку с картинками в аутентичном интерфейсе просмотрщика картинок Windows XP, что создаёт более подходящую атмосферу =)


Скачать: shimgvw_xp32.7z (включает бинарник и исходный код лаунчера, плюс shimgvw.dll из англоязычной Windows XP SP3).

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

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

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

Несколько месяцев назад я наткнулся в твиттере на математические головоломки Катрионы Ширер. Они сразу меня увлекли: каждая головоломка такая осязаемая, ручной работы, словно просит её решить. И на каждую вы можете легко потратить час времени, а то и больше.

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

Наслаждайтесь. И не говорите, что врач не предупреждал.

А знаете ли вы, чем занимаются ваши сотрудники на работе?

Работая в должности начальника IT отдела в компании, я занимался абсолютно всеми вопросами, связанными с IT, около IT и даже немного больше. Думаю, всем вам знакомо, когда в IT-поддержку звонят люди и жалуются, что кулер не работает. Да-да, тот самый, который воду охлаждает. На вопрос зачем звонить в IT, а не АХО, ответить внятно не могут, лишь бормочут что-то типа «провода, элетричество». Впрочем, меня данные проблемы мало волновали, хоть временами и доставали, внутри отдела поржали и ладно, своих задач стояло много: бюджеты, сервера, телефония, службы и помощь пользователям. Вот о них, о пользователях и хотелось бы поговорить. Наверняка, все сталкивались с резюме людей, в которых написано, что-то типа «отличное владение MS Office» или что-то в том же духе, при этом на рабочем месте они зовут IT-поддержку, чтобы вставить таблицу в документ Word… Ладно, бывает, поможем, научим… Так и проходят дни, то сервис новый поднастроить, то людям помочь. А видя такой уровень пользователей, приходится делать им какие-либо ограничения, так называемая «защита от дурака» — лишить прав, запретить удалять файлы на шаре, запретить некоторые сайты.


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

Часто приходится видеть, как новички пробуют Common Lisp и потом жалуются, что с ним невозможно нормально работать. Как правило, это происходит из-за того, что они не понимают как настроить себе процесс, обеспечивающий тот самый "быстрый отклик" от среды разработки, когда ты поменял функцию, скомпилировал её и изменения тут же начали использоваться внутри уже "бегущей" прогрммы без её перезапуска.

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

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

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

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

Полгода назад или около того я загорелся-таки идей написать свой плагин для Intellij IDEA. Согласно задумке, он должен был считать, сколько времени разработчик потратил на проект (всего, за день, за сеанс) и отображать результат на диаграмме. Никакой магии, но такая функция здорово помогла бы мне рассчитывать время работы.

Недавно нам на глаза попалась статья В Dropbox разработали алгоритм lossless-сжатия для файлов H.264 и JPEG и мы решили протестировать это решение и получить какие-то ощутимые технические детали.

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

Так же, эффекта от данного вида сжатия можно ожидать в двух случаях: если в файле в качестве кодера используется CAVLC или если файл закодирован блоками PU и TU максимального размера. А это возможно только в том случае, если кодек H.264 настроен на максимально быстрое кодирование.

Это четвертая статья в цикле «Теория категорий для программистов».

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

Без объектов

Самая простая категория — без объектов и, как следствие, без морфизмов.

Это третья статья в цикле «Теория категорий для программистов».

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

Кому нужны типы?

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

Думаю, многим, также, как и мне, книга «Getting Started with LLVM Core Libraries» покажется интересной. Это первая книга, посвященная целиком и полностью LLVM. В основном, как следует из названия, ориентирована на новичков, которые только обратили свое внимание на LLVM, но уже имеют опыт программирования на C++.

От переводчика

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

Вот и наступил момент, когда очередные наушники вышли из строя. Работали бы сто лет, но самое слабое место современных наушников — провод в районе разъёма — опять дало о себе знать. Опять в магазин? Ну уж нет, слишком руки прямые. К тому же придётся искать точно такую модель, что непросто, ибо вкладыши постепенно вытесняются ненавистными (мною) in-ear ухосуйками. А звук у них неожиданно хороший для такого класса наушников.



Значит, берём в руки инструмент, и поехали. Под катом фотографий на 800 кБ.

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

Мотивация

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

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

Во всяком случае, это только первый черновик стандарта, который я предлагаю. Комментарии приветствуются!

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.