В смысле, привет, Хабр! Если вы можете сказать про себя слово «интроверт» (как и я) то вас, скорее всего, можно заносить в эту категорию. Другое дело, что категория, мягко говоря, размыта. И в неё от души навалено сразу несколько синдромов.

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

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

А теперь давайте разбираться в деталях.

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

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

В приложениях, работающих с базами данных, естественным образом возникает потребность в тестах, которые проверяют корректность результатов выполнения запросов. На помощь приходят различные встроенные (embedded) базы данных. В этой статье я расскажу о том, как мы перевели unit-тесты с HSQLDB на PostgreSQL: зачем это затеяли, с какими трудностями столкнулись и что нам это дало.

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

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

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

Без преувеличения можно сказать, что SQL — один из самых распространенных в мире языков. Информационные системы могут быть написаны на Java, Python, JavaScript, C#, PHP и десятке других языков, но SQL база в том или ином виде будет в абсолютном большинстве таких систем. Среди бизнес-приложений процент систем, использующих SQL, вообще стремится к 100%.

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

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

(Управляющие карты)
(Посвящается Международному году Периодической таблицы химических элементов)
(Последние дополнения сделаны 8 апреля 2019. Список дополнений сразу под катом)


(Цветок Менделеева, Источник)

Помнится, мы проходили утку. Это были сразу три урока: география, естествознание и русский. На уроке естествознания утка изучалась как утка какие у нее крылышки, какие лапки, как она плавает и так далее. На уроке географии та же утка изучалась как житель земного шара: нужно было на карте показать, где она живет и где ее нет. На русском Серафима Петровна учила нас писать «у-т-к-а» и читала что-нибудь об утках из Брема. Мимоходом она сообщала нам, что по-немецки утка так-то, а по-французски так-то. Кажется, это называлось тогда «комплексным методом». В общем, все выходило «мимоходом».

Вениамин Каверин, Два капитана

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

Здравствуй, Хабр!

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

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



SQL (ˈɛsˈkjuˈɛl; англ. structured query language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных. Подробнее…

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

Кому будет полезна статья:

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

То есть всем тем, кому нужно учить, объяснять, и кто не знает за что хвататься, как планировать уроки, что рассказывать.

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

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

Практические задачи по Java — для курсов и прочих занятий

Несколько вводных слов

Последние несколько лет я читаю курс по программированию на Java. Со временем он менялся — то добавлялись, то выкидывались разные части, менялась последовательность тем, менялся подход к построению плана самих занятий, и так далее. То есть, курс совершенствовался. Одной из основных проблем, возникших при подготовке курса — это задачи. О них и пойдёт речь.

Дело в том, что каждое моё занятие состоит из двух частей. На первой я выступаю в роли лектора — рассказываю с примерами кода о какой-то новой теме (классы, наследование, дженерики и так далее). Вторая часть — практическая. Очевидно, что нет смысла просто рассуждать о программировании, надо программировать. Приоритет на занятиях — решение задач, то есть программирование чего-то как-то. Программирование на занятиях отличается от программирования дома, так как на занятиях можно задать вопрос, показать код, получить быструю оценку кода, комментарии по улучшению, исправлению написанного. Очень легко было найти задачи для самых первых занятий. Задачи на циклы, условные операторы, и ООП (к примеру, написать класс «Собака» или класс «Вектор»). Сервисы вроде leetcode позволяют даже проверить правильность решения таких задач сразу, онлайн. Но какие задачи дать студентам на занятии, которое было посвящено коллекциям? Потокам? А аннотациям? За несколько лет я придумал, или переработал несколько таких задач, и эта статья, по сути, является сборником этих задач (к некоторым задачам прилагается решение).

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Каким образом за столетия до изобретения подъёмных кранов и грузовиков были созданы древние сооружения наподобие Стоунхенджа или статуй Моа́и на острове Пасхи? В своём новом эксперименте исследователи из Массачусетского технологического института (MIT) создали бетонные сооружения весом около 25-тонн, которые, несмотря на их вес, можно передвигать вручную. Таким образом, появился новый довод в пользу теории, согласно которой древние строители были мастерами равновесия и умело использовали рычаги.

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

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



Ниже я приведу примеры игр на программирование действий (обучающих и не только), которые можно купить в России? Их можно и нужно применять, чтобы не только объяснить детям алгоритмику и даже робототехнику, но и просто весело и приятно провести время в кругу семьи. Ссылки умышленно не даю (это не реклама) — все игры ищутся в поиске по их названиям и их можно купить в разных магазинах (как онлайн так и оффлайн). Если не найдете — спросите меня в комментариях и я дам ссылки.

Учить английский по играм и книгам — приятно и довольно эффективно. А если игра и книга объединены в одно мобильное приложение — еще и удобно. Так сложилось, что на протяжении последнего года я неспешно знакомился с жанром мобильных «геймбуков»; по итогам ознакомления готов признать, что это интересная, самобытная и не слишком известная широкой публике ветвь не то игр, не то литературы. В этой экспериментальной для Skyeng статье я тряхну «игрожуровой» стариной, сделав обзор наиболее интересных представителей жанра и их издателей.

Два инди-разработчика рассказывают, как использовали автоматизацию, один аккаунт Google Play и единственный шаблон игры про слот-машины для создания и публикации более тысячи приложений.

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

Участие в обычном гейм-джеме привело к созданию машины обработки данных, которой в результате удалось заработать приличную сумму: 50 тысяч долларов за два с лишним года. Спустя годы, имея на руках данные (и деньги), разработчики этой машины по изготовлению игр, которая создавала только «мусорные» слот-автоматы с моделью free-to-play, использовали GDC как трибуну, чтобы подать тревожный сигнал индустрии, в которой «правильное» поведение часто ограничивается вниманием к игрокам, заискиванием перед издателями и сбором положительных обзоров критиков. В случае этих разработчиков нарушение всех этих правил привёл к слишком успешным результатам, вызвав у них сильный дискомфорт.

Побеждаем в «гонке ко дну»

Вернёмся в 2013 год: в то время два разработчика видеоигр уже несколько лет пытались добиться успеха на растущем рынке мобильных игр. Один из них, Алекс Шварц, помогал в создании качественной мобильной игры Jack Lumber. (В прошлой жизни я даже написал о ней хороший отзыв в уже несуществующем журнале The Daily, работавшем только на планшетах.) Второй, Зиба Скотт, разработал приятную мобильную головоломку Girls Like Robots.

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

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

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


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

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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

В недавней статье товарищ KvanTTT поднял вопрос:

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

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

Сразу скажу, материал холиварный. Местами слишком эмоциональный. Очень спорный. Слишком личный — часто основан на собственном опыте, небогатом, хоть и разнообразном. Пост касается школьных и университетских текстов учебников: у «профессиональной» литературы своя специфика, своя аудитория. Решения у проблемы в текущих реалиях нет. При этом, часть «моих» наблюдений задолго до меня высказывали такие авторитеты, как Кнут и Хэмминг; чуть менее популярные ребята даже запилили инструкцию "Как читать математику".

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

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

Когда твой парень — fullstack

Работая программистом и проживая в пяти минутах ходьбы от офиса, крайне тяжело успеть «отойти» от работы, отойдя от работы.

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

Как бы не так!

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

И вот однажды она приходит к тебе и торжественно заявляет:
— Я готова! Готова учиться программированию! Давай!

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

О том, как я, не имея никакого практического опыта в обучении, решил ввести в программирование человека, объяснившего, что «ты же умный» и «всё у нас получится», расскажу под катом.

Добро пожаловать!