Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

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

В 1988 году в продаже появилась абсолютно новая камера глубокого сна для межзвёздных перелётов, совместимая со всеми популярными 16-битными компьютерами. К сожалению, в ней использовалcя порядок записи байтов от старшего к младшему, в то время как спецификации DCPU-16 требовали записи от младшего к старшему. Это вызвало серьёзный баг в приложенных драйверах, из-за чего вместо требуемых 0x0000 0000 0000 0001 года сон продолжался 0x0001 0000 0000 0000 лет.

Наступил 281 474 976 712 644 год нашей эры. Первые люди начали просыпаться в глубинах вселенной, которая находится на грани исчезновения, все дальние галактики потеряны в красном смещении, формирование звёзд давно завершилось и во Вселенной доминируют массивные чёрные дыры».

Преобразование Хафа служит для поиска на изображении фигур, заданных аналитически: прямых, окружностей и любых других, для которых вы сможете придумать уравнение с небольшим количеством параметров. О преобразовании Хафа написано немало, и данная статья не ставит цели подробно осветить все аспекты. Я лишь объясню общий принцип, останавливаясь на особенностях, мешающих его реализации на GPU «в лоб» и, конечно же, предложу решение. Те, кто знают проблемы и хотят сразу видеть решение, могут пропустить пару-тройку разделов.

Интернет-школа программирования Codecademy расширила программу обучения и с понедельника запустила курс по HTML, CSS и JS.

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

Все советы автономны и их порядок не имеет значения.

Раз за разом я вижу отблески самого себя в «молодых» программистах. Они сражаются с теми же концепциями, что и я когда-то, попадают в те же ментальные ловушки и, в общем-то, делают те же ошибки. Написав пост 4 wrong ways, я задумался, насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз, в некоторые по нескольку и видел те же ошибки у других.

В какой-то момент я стал замечать, что пишу более качественный: оптимальный, логичный и читаемый код, но пишу его медленно. По крайней мере, куда медленнее, чем лет 15 назад. Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.

Проблема в контроле. Я стал жестче и глубже контролировать код и… стал тратить на этот контроль слишком много ресурсов.

Основной принцип прост. Если контролю подлежит 10-20% случаев, то на контроль надо тратить… 0% ресурсов. Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.

Многим известны книги Томаса Лимончелли по системному администрированию, очень ценные для админа книжки. На его сайте тоже немало интересного, среди прочего нашёл такую статью: «A list of dumb things to check». На русском языке она, к сожалению, не нагуглилась, переводил сам. После допилинга под свои условия буду использовать как часть КМБ у себя в отделе, а первоначальный перевод выкладываю тут.

Мы с другом решаем пойти в поход от Сан Франциско до Лос Аджелеса, чтобы заскочить в гости к нашим друзьям на Ньюпорт Бич. Посмотрим на карту и примерно прикинем путь по берегу:



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

 

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

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.

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

Итак, давайте представим, что перед программистом стоит задача написать новый модуль или дописать некоторую функциональность к уже существующей системе. Что будет делать опытный специалист? Он нальёт себе китайского чая, откинется на спинку кресла, возьмёт карандаш и начнёт думать. Он нарисует структуру модуля, обдумает сущности, интерфейсы и взаимодействие между ними, опустится на уровень конкретных методов, вероятно, напишет юнит-тесты на интерфейсы. Только потом он начнёт наполнять кодом существующую структуру (либо делегирует эту задачу десятку индусов-кодеров).

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

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

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

Иллюстраций: 34, символов: 51 609.

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

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

Из последних сил и отбросив такт, ты начинаешь свой рассказ.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Многие на Хабрахабр приняли участие в Google AI Challenge. Скачали инструменты для локального тестирования и уже ощутили прелесть и удобство их:

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

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

На хабре уже имеется много информации по этому состязанию, однако вся она освещает отдельные моменты реализации, но не картину в целом. Постараюсь исправить это положение как можно более кратко, но в целом.
Данное описание предназначено для тех, кто что-то слышал о данном мероприятии, но всё желание что-то сделать отбила необходимость разбираться в тонкостях реализации. Пост состоит частично из перевода материалов с официального сайта, частично из анализа стратегий других ботов и чистой логики. Также в конце поста будет ссылочка на PHP-бота (чуть сложнее чем из starter-pack), который позволит вам попробовать собственные силы дописав имеющийся код. Официальный сайт состязания: aichallenge.org

Введение

Меня до глубины души задело заявление моего коллеги, что использовать исключения — это неправильно. А далее последовала череда объяснений: это медленно, это некрасиво, это неэффективно, это неудобно.