Программирование *

1. Мы не правы

Хочу поделиться личным опытом (об/м)учения в Яндекс.Практикуме на курсе "Веб-разработчик", и почему, вернувшись на год назад в прошлое, я бы никогда не стал там учиться даже за бесплатно.

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

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

1) прибыльную (на комбинате я получал 24 тысячи в месяц);

2) перспективную (в IT действует меритократия, а в строительной сфере без связей, которых у меня нет, далеко на уедешь и высоко не взлетишь);

3) интересную и интеллектуальную. 

У меня есть старший брат – веб-разработчик с 10-летним стажем, за плечами которого опыт разработки в Яндексе, TopTal и нынешняя работа senior-программистом в Amazon. Я специально так подробно рассказываю о своём брате, т. к. далее эта информация понадобится для понимания контекста.

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

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

Идея

01/12/2010, 12:49
Пришла эта мысль в голову и не вылазит. Хочу обсудить с сообществом полезность и целесообразность. Основную часть технических подробностей пока опускаю, но сделать сие вполне реально либо в качестве плагина (SDK), либо даже скрипта (MAXScript).
Итак, смысл в том, чтобы бесплатно (или не очень) использовать чужие компы для рендера своих сцен. Есть система рейтинга, т.е. нельзя долго рендерить свое («качать»), но не рендерить чужое («раздавать»). Для тех, кто боится, что его сцены или текстуры будут использовать чужие нехорошие люди, предусмотрена защита — координаты всех объектов сцены изначально обнуляются, правильные координаты шифруются и передаются на рендер отдельным файлом, текстуры бьются на маленькие квадратики и собираются в одну тоже только перед рендером. Показ самой визуализации (VFB) можно отключить, т.е. человек даже не видит, что он рендерит. Аналогичные действия происходят и после рендера — изображение автоматически разбивается на кусочки (либо просто перемешиваются пиксели по какому-то закону) и собрать его правильно можно только на стороне автора сцены. Для альтруистов есть возможность отключения защиты, т.е. сцена с барахлом передается в свободном доступе. Защита может быть и другая, и вообще все что я пишу еще до конца не обдумано — только варианты.
…
Ну вот в общем как-то так, прошу не кидаться помидорами, и, если велосипед я не изобрел, то обсудим, насколько вообще жизнеспособна эта идея.

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

Это моя небольшая история, как я за месяц написал карманное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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

Это еще одна статья про демосцену, сайзкодинг, ассемблер, MS‑DOS и ретрокодинг. То есть, о том, как ночами напролет добровольно и бесплатно писать бесполезный и очень трудоемкий код, и получать от этого массу удовольствия (и седую бороду). Даже если вы уже пробовали и вам не понравилось, вам все равно стоит почитать. Возможно, вы что‑то делали не так. Например, использовали не те буквы и цифры. А еще тут есть подборка «демок» размером в 256 байт!

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

• Работает в Linux, OS X и Windows
• Обладает приличной скоростью работы
• Приятным интерфейсом (включая всевозможные анимации)
• Гибко настраиваем (правда, не в GUI, а в json-конфигах)
• Имеет множество плагинов, число которых растёт как на дрожжах
• Поддерживает VIM-режим
• Использует fuzzy-поиск

В этой статье описано создание эмулятора 16-битной приставки Sega Mega Drive на C++.

Будет много интересного: эмуляция процессора Motorola 68000, реверсинг игр, графика на OpenGL, шейдеры, и многое другое. И все это на современном C++. В статье много картинок, можно хоть на них посмотреть.

Мы переживаем величайший кризис качества программного обеспечения в истории вычислительной техники. Калькулятор теряет 32 ГБ оперативной памяти. ИИ-помощники удаляют рабочие базы данных. Компании тратят 364 миллиарда долларов, чтобы избежать решения фундаментальных проблем.

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

Вот примеры.

1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.

«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY — хороший принцип, но бывают исключения.

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

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

«Здравствуйте, я – Сергей. Мне запрещают разговаривать с клиентами. Но я в этом не виноват.»

Заблуждение 1. В сутках 24 часа или 86 400 секунд

Cloud9