(Иллюстрации к статье А.П. Ершова «Программирование — вторая грамотность»)

Стив Джобс не написал ни строчки кода, Билл Гейтс — написал. Пол Грэм — первоклассный программист, Питер Тиль — юрист по образованию, сооснователь PayPal и владелец Palantir (написал ли он что-нибудь?), а Илон Маск в детстве написал свою игру и успешно её продал.

Никита truesnow из #tceh сказал мне, что на курсе «Врубаемся в Ruby» они научат программировать любого человека, даже с нуля. Я спросил его: «А с гуманитарием справитесь?» И мы задумались, были ли случаи, когда «гуманитарий» выучил язык программирования?

На ум сразу пришел бомж-программист, но после успеха с его приложением он предпочёл остаться «дзен-монахом». Есть ли еще примеры? Вдохновляющий пример, что научиться кодить может каждый — слепой программист. Когда я прочитал статью на Хабре «Смотря на код с закрытыми глазами», то понял, что нет преград, кроме собственных отмазок.

А у меня для вас есть три истории из моей жизни. Просто три истории.

История первая — ламер

Слово «ламер» я прочитал в «Компьютерре». Там давалось такое определение: «Ламер — отнюдь не безграмотный человек, не умеющий (как бы это помягче выразиться?) программировать». Окрылённый истиной я побежал и рассказал об этом друзьям-одноклассникам, но они предпочли поиграть в футбол, вместо того чтобы освоить суперспособности. Забавно, что потом все они зарабатывали программированием деньги, а я нет. Через неделю я записался в краевую станцию юных техников (КСЮТ), где был кружок по программированию. Там для новичков давали qbasic. А боги прогали на C.

Привет, Хабр!

В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).

К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.

Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.



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

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

Привет, Хабр!

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

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

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

Ох. Звучит знакомо?

• Реализация AI: как сделать максимально просто?
• RPC клиент-сервер: json или бинарная «самопальщина»?
• Асинхронные сокеты или многопоточная архитектура?
• Кеширование объектов на уровне приложения или больше памяти для СУБД?
• Работа с БД без Reflection API: действительно ли это так сложно?

        Сегодня мы продолжим рассматривать архитектуру и особенности реализации игрового backend'а на С++ для онлайн игры на примере ММО РПГ «Звездные Призраки». Это вторая часть статьи про сервер, начало можно прочитать здесь.

В то время пока я собирался на ланч, мой ко-воркер Дейв окликнул меня: «Хэй, Алекс, а ты не хочешь заниматься улучшениями навыков своего программирования?». Я задумался. Это было интересное предложение, но я склонялся ответить отказом: «Сейчас я занимаюсь развитем навыков говорения на языках, дружище!». Ладно, шучу. Утро началось с того, что я добрался до почты и заполучил в руки копеечный китайский Кубик, случайно заказанный на али. К обеду я проштудировал мануал сборки и обновил мышечную память, а к вечеру пришло осознание, что я наигрался. Будущее кубика было ясным: он будет пылиться на полке, раз или два в неделю может быть я буду его собирать, чтобы привести мысли в порядок или отвлечься, но не более того. Соревнование в механической скорости сборки? Non merci, уж лучше скворечники делать…

Ситуацию, как всегда, спасли мысли об автоматизации. После недолгого изучения я узнал рекогнисцировку. Для начала, число Бога уже давно найдено и равно 20. Правда задача сборки от этого не упрощается, т.к. использовать граф кратчайших путей для всех возможных конфигураций кубика не очень спортивно и немножко накладно по ресурсам. Алгоритм Бога предполагает под собой некое разумное количество использованной памяти, и в то же время обязан обеспечить минимально возможное число модификаций. Так вот, такого алгоритма еще нет. Есть ряд алгоритмов, позволяющих заметно ускорить сборку по сравнению с традиционными шаблонными методоми, но повторять кем-то уже проложенный (математически) путь мне показалось скучным. Если кому интересно, вот хороший анализ Далее есть традиционные шаблонные методы. Идея здесь в послойной сборке снизу вверх с использованием формул. Формула — последовательность модификаций Кубика, приводящая к таким-то целевым модификациям, и таким-то побочным. Соответственно, побочные модификации почти всегда падают на еще не собранные слои. Различаются шаблонные методы уровнем детализации шаблонов. Всякого рода спидкуберы знают все мыслимые шаблоны для большого количества частных случаев, что позволяет отыграть лишнюю 0.1 секунду с каждой модификации на соревнованиях. Пример, на что еще можно потратить жизнь.

Итак, я постепенно формировал для себя задачу. В итоге, формулируется она так: за кратчайшее реальное время необходимо написать решалку для Кубика Рубика.

Что мы знаем о Кубике? Число его состояний описывается как

(8! × 3^7) × (12! × 2^11)/2 = 43 252 003 274 489 856 000

.

Часть 1. Введение. Создание класса и добавление свойств. Расширение класса С++ с помощью Blueprint.
Часть 2. Классы геймплея. Структуры. Отражение (reflection) в Unreal. Object/Actor итераторы. Менеджер памяти и сборщик мусора.
Часть 3. Префиксы в именах классов. Целочисленные типы. Типы контейнеров. Итераторы контейнеров. Цикл For-each, хеш-функции.
Часть 4. Unreal Engine 4 для Unity разработчиков.
Часть 5.…



От Автора: Начало лето выдалось жарким на проекты, поэтому оформление перевода долго откладывал, дальше будет быстрее.

Эта статья является продолжением перевода части документации по UE4. Оригинальную статью вы можете найти пройдя по это ссылке.

Часть 1. Введение. Создание класса и добавление свойств. Расширение класса С++ с помощью Blueprint.
Часть 2. Классы геймплея. Структуры. Отражение (reflection) в Unreal. Object/Actor итераторы. Менеджер памяти и сборщик мусора.
Часть 3. Префиксы в именах классов. Целочисленные типы. Типы контейнеров. Итераторы контейнеров. Цикл For-each, хеш-функции.
Часть 4. Бонусная. Unreal Engine 4 для Unity разработчиков.



Эта статья является переводом части документации по UE4. Оригинальную статью вы можете найти пройдя по это ссылке.

Первый Android телефон T-Mobile G1 был представлен в октябре 2008, а сейчас уже насчитывается более 1 миллиарда активных пользователей платформы по всему миру. По статистике 1,5 миллионов Android-устройств активируется каждый день. Приложения и разработчики являются основной составляющей Android экосистемы, поэтому для нас задача обучения и помощи разработчикам является одной из самых приоритетных.

Сегодня компании e-Legion и Google совместно запускают первую онлайн школу мобильных Android–разработчиков.

Начиная с 2011 года компания-разработчик мобильных приложений e-Legion организовывала бесплатные оффлайн школы мобильных разработчиков. Первой стала iOS-школа, которая собрала больше 200 заявок и выпустила 12 студентов осенью 2011 года. Потом были школы мобильных разработчиков под Windows Phone и Android. С каждым анонсом на Хабре нас ждал вопрос о том, будет ли запись лекций и можно ли поучаствовать тем, кто живет не в Питере. Каждый раз мы отвечали что-то из серии «скоро все будет». И вот, наконец-то, это «скоро» наступило. Мы решили создать школу, в которую сможет поступить желающий из любого города и которую можно пройти дистанционно.

Привет!

23derevo перед выступлением на Mobius попросил меня рассказать немного о процессе клиентской разработки в Zeptolab.



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

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



Осторожно: статья проиллюстрирована крупными анимированными изображениями.

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

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

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

Итак, вы работаете на Java с самого её появления? Вы помните те дни, когда она называлась «Oak», когда про ООП говорили на каждом углу, когда сиплюсплюсники думали, что у Java нет шансов, а апплеты считались крутой штукой?

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

Управление жизненным циклом приложений это очень важный подход который позволяет создавать качественные системы. Но полноценное создание ALM среды и настройка инструментов может требовать создания сложной инфраструктуры. Вот почему год назад, в рамках первой конференции //Build/ в тестовую эксплуатацию был запущен сервис tfspreviev.com. По сути это облачный вариант Team Foundation Server, который готов к эксплуатации сразу. Вчера состоялся долгожданный RTM этого сервиса. Приятным сюрпризом оказалось то что он бесплатен для команд до 5 человек.

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

На просторах интернета часто встречаются «команды», которые существуют уже годами, список разработчиков состоит из десятка персон, да ещё и «нужны все!». При этом никакой адекватной демки нет даже в ближайших планах. Глядя на это всё так и хочется сказать: «Да что же вы, блин, делаете?!». Но это деструктив. Мало раскритиковать. Нужно и позитивные примеры предоставить.

Эти размышления натолкнули меня на занятный эксперимент: в ноябре на gamedev.ru стартовал «конкурс леталок». Конкурс предполагал разработку в течении двух месяцев. Однако мне показалось, что это многовато. Поэтому я записался в участники… И забыл о конкурсе на полтора месяца.

Основная идея эксперимента — сделать полноценный проект за две недели. Срок завершения конкурса — неплохой дедлайн. К тому же последняя неделя конкурса совпала с концом новогодних праздников, что дало возможность не отвлекаться на другие задачи. Итак: конкурс, проект с нуля, две недели.

Global Game Jam — крупнейший международный хакатон, в рамках которого участники из сотен городов одновременно создают игры на заданную тему. GGJ проходит с 2008 года, однако еще ни разу не проводился на территории Беларуси. 23-25 января 2015 при поддержке СООО «Гейм Стрим», минского центра разработки Wargaming, состоялся первый Global Game Jam Minsk.
Результаты хакатона и советы для участников от специалистов из Wargaming, HalfBus и GameJam под катом.

Факт 1

Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом. Это как если бы вы разобрали боинг 747 и увидели, что топливопровод держится вешалкой для одежды, а шасси смотаны изолентой.

Бен Черри

Думаю, многим знакома такая разновидность веб-форумов, как имиджборды. Да-да, вы правильно поняли — именно на примере имиджборды я расскажу об опыте создания сайта на C++. Что же сподвигло меня заняться столь сомнительной пользы проектом? Левая пятка. В этом случае действительно никаких особых причин не было. Просто проснулся однажды утром и понял — хочу. Но это все лирика.

На Хабре хватает статей о веб-сайтах на C++: например, с использованием FastCGI или CppCMS. Но все это — HelloWorld'ы и туториалы. Я же вам расскажу о полноценном (пусть и не идеальном с точки зрения архитектуры и чистоты кода) проекте, постараюсь осветить различные тонкости.

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

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

Надеюсь будет интересно Web разработчикам посмотреть на потуги С++ника, ну а С++ разработчикам узнать для себя что-то новое.

Маркетологи быстро выяснили, что в «системе принятия решений о доверии» есть уязвимость — люди охотнее доверяют рукописному тексту, чем печатному. Очень быстро появились рукописные шрифты и подписи в объявлениях/письмах, но они легко распознавались. Теперь же есть возможность автоматизированного написания «от руки» настоящей ручкой (даже перьевой), с учетом всех отступов, расстояний неровностей, несоблюдением пропорций, нажима и углом наклона (осталось следы от шоколадки и кофе автоматически эмулировать).

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

У сервиса Bond, который предоставляет услуги по отправке реальных писем, есть все шансы пройти «рукописный тест Тьюринга» (т.е. человек не сможет отличить, писал ли этот текст человек или робот).

Я часто говорил, что достаточно знаю ИТ, чтобы не доверять ИТ, теперь же рухнуло и доверие к «реальным документам». Достаточно несколько школьных сочинений скормить нейронным сетям, чтобы они смогли писать за меня (и даже лучше чем я). Кстати, сервис Bond предоставляет услуги по улучшению/тьюнингу вашего почерка.

Итак, что же нам нужно, чтобы на нас оставили завещание?
Шаг первый. Создаем 3d принтер, который эмулирует письмо от руки
Шаг второй. Создаем самообучающуюся программу и скармливаем ей несколько листов рукописного текста жертвы клиента
Шаг третий. Profit

Под катом краткий обзор оборудования, примеры писем, знакомство с проектами Maillift (письма «от руки»), Bond (письма от руки и распознание и эмуляция почерка), Herald (как студенты свой принтер спаяли)