Optional.ofNullable() это не мешает. Всё отличие между of() и ofNullable() заключается в простой проверке на null. Если Optional делали как средство борьбы с NPE, то почему более коротким (читай — дефолтным) сделали метод, который ожидает не-null аргумент? Неужели пытались производительность улучшить, убрав один if?
Чего только не придумают, лишь бы не добавлять в язык elvis operator. Неужели никому из тех кто работал с этим JEP не показалось, что эта конструкция как минимум громоздкая и неуклюжая? Кто-нибудь в курсе, почему изменений непосредственно языка боятся как огня? Я ещё могу принять объяснение, которое приводили против литералов коллекций — такая конструкция гвоздями прибила бы язык к стандартной библиотеке, потому что нужно было бы специфицировать, какой тип коллекции должен возвращать литерал (хотя наличие autoboxing'а, Iterable и AutoClosable уменьшают вес этого аргумента). Но чем помешает прокачка тернарного оператора? Сочетание символов ?: и так является невалидным, введение его как языковой конструкции не сломает существующий код. Равно как оператор ?. для null-safe доступа к методам и свойствам. Да, Optional удобен в тех ситуациях, когда нужно явно обозначить, что значение может отсутствовать, но писать Optional.ofNullable() (кстати, почему Optional.of() бросает NPE если на входе null?) каждый раз, когда хочется просто получить вложенное свойство — неудобно.
Не поймите меня неправильно, я не хейтер, я сам пишу на Java и радуюсь улучшению API стандартной библиотеки. Но requireNonNullElse — это какой-то сюр.
В Беларуси как-то справились (с предубеждениями), отменили внутренние билеты по паспортам и небеса на землю не упали.
Не совсем отменили. Если покупать бумажный билет в кассе, паспорт действительно не потребуют. Но при покупке билета через интернет, обязателен номер документа, подтверждающего личность. По электронным билетам в поезд пустят только при предъявлении паспорта/военника/водительских прав. Распечатанный или показанный на телефоне электронный билет не прокатит, несмотря на то что на нём есть штрих-код, по которому влёгкую могли бы его проавлидировать.
Вы путаете феминизм первой-второй волн (который боролся за равные права женщин и мужчин; первая волна — де-юре, вторая — де-факто) с интерсекциональным феминизмом, который является самым мейнстримным (читай — громче всех себя проявляющим) феминизмом в данный момент, и который как раз порождает подобные перлы. В основе интерсека лежит теория привилегий, которые человек получает по факту рождения, просто из-за принадлежности к определённой социальной группе. По мнению интерсеков, из-за определённых стереотипов, сложившихся в обществе относительно этих групп, человек принадлежащий к этим группам может получить от социума больше благ, чем люди, принадлежащие к другим социальным группам. И полом тут не ограничиваются. Например, мужчины имеют привелегии относительно женщин (потому что патриархат, в их видении это и есть сексизм), белые относительно цветных (но не наоборот, расизм может существовать только по отношению к угнетённым расам), здоровые относительно больных и инвалидов (эйблизм), молодые относительно пожилых (эйджизм), соответствующие текущим стандартам красоты против несоответствующих (лукизм) и куча других -измов. В системе ценностей интерсеков белый здоровый молодой цисгендерный мужчина, проживающий в стране первого мира и имеющий постоянную рабту, является угнетателем относительно практически всех других социальных групп. И именно с этим угнетением интерсеки и борются. Их стремление — компенсировать привилегии какими-либо санкциями в отношении привилегированных групп.
Spring Boot умеет подтягивать настройки из семнадцати разных источников прямо из коробки. Достаточно вынести то что хочется менять без перекомпиляуии в проперти. Если хочется влиять не только на проперти, но и на создаваемые бины, можно поиграться с профилями и аннотациями Conditional*.
Liquibase так себе решает в ряде случаев. Пока апдейтается база, с ней работает активные инстансы приложения, и важно их не сломать. Мы не можем просто так переименовать или дропнуть колонку, существенно поменять формат данных, пока с ней работают не обновлённые инстансы приложения. Если мы не хотим даунтайма, нужно поддерживать обратную соовместимость на время миграции, и несовместимые изменения накатывать только после обновления последнего инстанса приложения. Например, данные в новом формате писать в новую колонку, при этом транслируя в старую данные в старом формате, а после обновления всех инстансов отключить обновление старой колонки и выкосить её. Вот о менеджменте таких процессов и было бы интересно почитать.
Когда у тебя в руках молоток, всё вокруг кажется гвоздями. Я, конечно, не знаю специфики задач, но…
интерактивные предметные и психологические тесты, анкеты и опросники
Чем не устраивали десятки готовых конструкторов тестов разной степени интерактивности?
электронные книги с гиперссылками, закладками и эффектом перелистывания страниц
Чем не устроил HTML + CSS + браузер?
интерактивные меню автозагрузки для DVD и CD дисков;
В те времена, когда Windows ещё не отключала автозагрузку со сменных носителей, существовало немало конструкторов меню автозагрузки разной степени интерактивности. Чем они не устраивали?
иллюстрированные базы данных с форматированным текстом, фильтрами поиска и печатью отчетов;
Эталонная задача для Microsoft Access. Но при желании и Excel можно приспособить.
защищенный веб-браузер для тестирования студентов (пока студент проходит онлайн тест, он не может открыть ничто другое ни в веб-браузере, ни на компьютере вообще);
Переопределяем популярные горячие клавиши для работы с окнами, чтобы студент не альттабнулся в другое окно. Выдёргиваем сетевой кабель, чтобы не гуглил ответы. Если для прохождения теста нужен интернет — настраиваем hosts или файрвол.
программу мониторинга активности и дистанционного (с телефона) управления компьютером для ребенка (свой родительский контроль);
Чем не устраивали десятки существующих программ родительского контроля?
удобную базу данных для хранения паролей;
Чем не устраивали десятки существующих менеджеров паролей?
скриншотер для пожилых родителей (чтобы в один клик из трея могли отправить мне скрин экрана на почту);
Чем не устраивали существующие инструменты для создания скриншотов (во многих из которых есть возможность отправить скриншот по почте)?
Я ничего не имею против творчества, самореализации или инструментов для непрофессионалов. Но уж больно ваши сценарии напоминают NIH-синдром, который вы ещё и студентам передаёте. Да ещё и рекламируете им платный инструмент. Не надо так.
Есть ложь, большая ложь и статистика. По статистике, которую регулярно озвучивает мэр Минска, в городе 250 километров велодорожек. На практике есть 27 километров центральной велодорожки (ведущей из ниоткуда в никуда) и несколько не связанных друг с другом огрызков длинной 2-3 километра каждый. Особенно потешно выглядят велодорожки вдоль развязки рядом с библиотекой — от светофора до светофора. Все остальные "велодорожки" — сделанная на отвяжись разметка на тротуаре, на которую забивают как пешеходы (и стар, и млад, а особенно дети), так и сами велосипедисты (потому что более-менее ровная поверхность только на центральных улицах, на остальных регулярно приходится объезжать ямы, трещины и пешеходов). Держать постоянную скорость в таких условиях нереально, постоянные торможения и разгоны выматывают. Даже на центральной велодорожке поджидают сюрпризы в виде мостов, которые поднимаются метра на 2 по дуге (при том что параллельно стоит абсолютно плоской пешеходный мост). Велопарковки ставят у входов в магазины и торговые центры. Рядом со входом в метро я видел ровно одну велопарковку на четыре (!) места. Разметку, повторюсь, рисуют для галочки. Например, каждый день езжу по улице, а начале которой соотношение полос для велосипедистов и пешеходов 1:3, а к концу — 2:1 (потому что тротуар сужается, а "велодорожка" нет). На этой же улице велодорожка заканчивается где-то посередине, а раз нет велодорожки, то и занижать бордюры не обязательно. А позитивное отношение пешеходов и автомобилистов к велосипедистам можно проследить в комментариях к любой новости о велоинфраструктуре на tut.by (спойлер: велосипедистам настойчиво предлагают ездить по проезжей части и сдавать на права).
При всём уважении, сэр Тим Бернерс-Ли предлагает вещи сильно оторванные от реальности.
Хранение данных в месте, полностью подконтрольном пользователю и возможность свободно мигрировать эти данные между приложениями — это замечательно. Но как быть с форматом этих данных? В статье упоминается формат LinkedData, но ни в статье, ни в описании формата не говорится, кто и как будет его стандартизировать. Те же лайки очень по разному работают в разных соцсетях. В VK это просто лайк, в YouTube — лайк или дизлайк, в Facebook — одна из вроде как пяти эмоций, в Skype (представим, что Skype это соцсеть) реакция может быть любым эмодзи. Какой должен быть формат описания лайка, чтобы его можно было мигрировать между приложениями, но при этом чтобы он не ограничивал функционал этих приложений? И лайк — это самый простой пример. В статье приводится в пример приложение для работы с расписанием. Как это-то стандартизировать? И как стандартизировать ещё тысячи форматов данных, с которыми могут работать Solid-приложения? Тут либо стандартный (читай: наименее функциональный) формат, либо vendor lock из-за невозможности перенести данные в проприетарном формате.
В статье утверждается, что благодаря тому что данные хранятся у пользователя, они не могут быть подвергнуты цензуре. Но что толку от возможности хранить нецензурированные данные, если их видишь только ты? Для того чтобы данные пользователя видел не только сам пользователь, нужно какое-то приложение, которое будет транслировать данные пользователя на широкую аудиторию. И вот это приложение уже без проблем может заниматься цензурой. Пользователь, конечно, может поднять своё приложение, которое будет транслировать его данные без цензуры. Но ведь и в нынешнем б-гомерзком централизованном Вебе кто угодно может поднять свой сайт и писать там что угодно. Вот только пользователи вряд ли захотят запоминать десятки или сотни адресов персональных приложений всех тех, кого они читают, и с радостью побегут в подверженные централизации и цензуре аггрегаторы.
Управление доступом к данным? Уже сделали в Android и Google+. В первом большинство людей бездумно дают приложению все права, которые оно запросит. Во втором концепция кругов оказалась слишком сложной для пользователей, и этим мало кто пользовался. Тут не Интернет переизобретать надо, а вести просветительскую работу и повышать сознательность населения.
Ну и вишенка на торте: у хранилища данных пользователя есть свой уникальный id. Теперь условному Google или Facebook не нужно заморачиваться с фингерпринтингом устройств пользователя — пользователь сам даст им надёжный id, по которому можно его отслеживать где угодно. Да, можно сделать себе несколько хранилищ, можно даже пользоваться одноразовыми хранилищами, но заниматься этим будут только те же пользователи, что и сейчас заморачиваются с блокировкой отслеживания через рекламу, кнопки соцсетей и аналитику.
Очевидно, потому что оператора in в Java нет. А вот ключевое слово assert есть, но его использование считается плохой практикой. Во-первых, потому что assert в Java просто проверяет условие и выкидывает исключение, если условие ложно. С ним нельзя передать сообщение, по которому можно будет определить, что именно упало, не копаясь в стектрейсах, или вывести в лог сообщения о ходе проверки. Во-вторых, ключевое слово и его поведение гвоздями прибито к спецификации языка. Представьте, что вам нужно сделать сложную проверку, которую не напишешь в одну строчку после assert. Нужно выносить в отдельный метод. Для того чтобы использовать его с assert он должен возвращать boolean, то есть, никакой информации о ходе проверки вернуть нельзя. А хочется — и тут каждый начинает городить свои велосипеды, причём, возможно, даже в рамках одного проекта. Это промашка в дизайне языка, а философия обратной совместимости не позволяет её просто исправить. Это и приводит нас к тестовым фреймворкам, которые предоставляют стандартизированный API для тестов. assertThat — точка входа в один из таких фреймворков — JUnit. assertNull, assertEquals и тому подобные методы — специализированные реализации assertThat для наиболее частых сценариев проверок.
Связка assertThat из JUnit и matcher'ов из Hamcrest позволяет писать почти на чистом английском, а если обширного набора библиотечных matcher'ов недостаточно — всегда можно написать свои.
Это не «смотрите, как я могу», это «смотрите, как ВЫ можете». Автор показывает, что в 3D-графике нет магии, и что она базируется на очень простых математических расчётах, осилить которые может любой толковый старшеклассник, причём сделать это можно даже в инструментах, не предназначенных для программирования. Меня в своё время статья о рейрейсере, уместившемся в 99 строк C++ сподвигла поглубже закопаться в матанализ. И если после прочтения этой статьи хоть один человек захочет сделать свой рендерер с блекджеком и шейдерами, то автор писал статью не зря.
Да и 2.5 года назад XML-конфигурация была уже малость старомодной. Spring 4.0 вышел в 2013, Spring Boot — в 2014. «Зато XML конфигурацию можно править без перекомпиляции приложения», скажут некоторые, и будут правы. Но неужели такая необходимость возникает часто? Я помню ровно одну историю (кажется, она была на Хабре) о том как человек правил XML-конфиги на проде, диктуя инструкции по телефону саппортёру, который в этом вашем спринге не разбирался. Кто-нибудь может накидать ещё подобных историй, в которых XML-конфиг имел бы реальные преимущества перед Java-конфигом или автоконфигурацией?
Раскажите, пожалуйста, на кого расчитана ваша статья? Как мне видится, максимальную пользу из неё извлечёт человек, который:
Знает, что такое Docker и docker-compose (потому что никаких пояснений по формату compose.yml нет).
Знает, что такое service registry и service discovery, и что Consul нужен именно для этого.
Знает, что такое Makefile, но при этом ещё и является Java-программистом.
Работает исключительно под Linux либо очень грамотно настроил констоль с bash и make под Windows.
Умеет работать с Maven, Spring Boot, Spring Data, Spring Cloud, Browserless и Feign.
Знает современный JavaScript.
Обладает достаточными знаниями во всех вышеперечисленных областях, чтобы по обрывкам кода и конфигурационных файлов собрать рабочий проект.
Это я к чему… Пояснений много не бывает. Ваша статья была бы гораздо полезнее, если бы вы хотя бы в двух словах объясняли, зачем нужна каждая из использованных технологий, приводили ссылки на документацию и выложили бы полный код проекта на GitHub.
Я, конечно, не преподаватель, и не могу оценить доходчивость своих объяснений, но я бы делал это так.
Всё сразу вываливать на начинающего я бы не стал. Первый десяток-другой задач начинающий будет решать без написания собственных функций, используя минимальный набор встроенных (ввод-вывод, математика). На этом этапе можно применить метафору «чёрного ящика», на вход в который подаются какие-то значения (ну, или не подаются), внутри они как-то обрабатываются и возвращается результат обработки (ну, или не возвращается). Можно показать, в каком порядке программа будет разбирать выражение с функцией, сказать, что при выполнении программы вызов функции «заменяется» на результат её выполнения с переданными параметрами. Не отходя от метафоры «чёрного ящика» (буквально, не показывая синтаксис объявления функций, на простых картинках) показать какие бывают функции, что они могут делать. Объяснить, что в функции выносится часто используемый код, чтобы его не копипастить. Для начала использования готовых функций этого должно быть достаточно.
Первые самостоятельно написанные функции, скорее всего, будут «плоскими», то есть, не будут вызывать другие функции. В этот момент нужно объяснить про области видимости переменных (в случае с Python; в случае с Java это нужно объяснять раньше, рассказывая про циклы и условне операторы). Дать несколько упражнений на определение, какие переменные видны из функции (в случае с Python пока не рассказывать, что функции можно объявлять внутри функций, циклов или условных операторов, это оставить на потом, когда сформируется более чёткое понимание областей видимости). После этого можно показывать, что будет происходить, если из функции вызвать другую функцию. На этом этапе тот факт, что из функции не видны переменные из области, в которой функцию вызвали, не должен вызывать диссонанса. Нужно мотивировать начинающего активно использовать отладчик для понимания хода выполнения программы и изменения видимых переменных. И только на этом этапе можно рассказывать про стек вызовов.
У вашего отца был сильный математический бэкграунд, отсюда и непонимание императивных функций. У ребёнка, только начинающего изучать программирование, такого бэкграунда нет, поэтому ему можно вешать на уши любую лапшу будет легче усвоить, что такое функция в контексте программирования.
Почему не начать с объяснения что такое класс, что такое метод, что такое переменная и так далее?
Потому что (ИМХО) начинающим надо давать не ООП, а программирование. То есть, объяснять, как выполняется программа, как хранятся и изменяются её данные, учить декомпозировать задачу, сторить алгоритмы, отлаживать их. ООП нужно для того чтобы структурировать сложные программы, а задачи, которые будет решать новичок, долгое время будут умещаться в один метод main одного объекта (если мы говорим о Java). При этом Java заставляет использовать ООП даже для простейших операций ввода:
Scanner scanner = new Scanner(System.in);
String s = scanner.nextLine();
Чтобы новичок понял, что тут происходит, нужно объяснить ему про синтаксис объявления переменных, классы, создание объектов, конструкторы, потоки ввода-вывода, вызовы методов, различие классов и объектов. Ах да, ещё не забыть упомянуть, что классы надо импортировать, попутно объясняя про пакеты. Если это не объяснить, код будет бездумно копипаститься, что, на мой взгляд, вредно для процесса обучения. А если объяснять, то на новичка единовременно вывалится огромный поток информации, который он в какой-то момент перестанет усваивать.
Тем временем в Python (да, я буду топить за Python как первый язык) это выглядит так:
s = input()
Объясняем, что такое переменная, что такое функция, как происходит вызов функции и присвоение значения. Всё. Новичок продолжает изучение программирования не отвлекаясь на ООП.
Я целиком и полностью поддерживаю вашу идею нести образование детям, но вот насчёт возможности «правильно преподнести» Java ребёнку, который до этого вообще не занимался программированием, я бы поспорил. Посмотрите на Hello World на Java. Какие вопросы могут возникнуть у человека, который до этого не видел ни одного языка программирования? «Что такое public?» «Что такое class?» «Что такое static?» «Что такое void?» «Что такое main?» «Что такое String[]?» «Зачем писать System.out.println через точки?» «Почему нельзя написать просто System.out.println(...);, зачем весь код вокруг этой строки?» Что можно ответить на такие вопросы, не углубляясь в ООП? «Не обращай внимание, потом объясню»? Подобный ответ может выработать опасный шаблон поведения: не задумываться, что написано снаружи main, просто копипастить код. В то же время Hello World на Python выглядит так:
print('Hello World!')
Объяснять нужно только что такое print, да и то человеку, имеющему минимальные знания английского это будет интуитивно понятно. Жирным плюсом Python, по моему опыту (опыту изучения, не преподавания), является то, что он не вываливает на новичка кучу ненужных ему понятий, а позволяет вникнуть в них постепенно. Тот же цикл for для новичка выглядит достаточно просто:
for i in range(1, 10):
print(i)
Интерпретируется просто: перебираем i в диапазоне от 1 до 10. Позже новичок узнаёт, что перебирать можно не только числа, но и элементы списков или символы строк. А ещё позже — что в цикле for можно перебирать любой iterable — объект, реализующий определённый контракт. В конце концов, он учится писать свои iterable. На каждой ступени новичок знает только детали, необходимые ему для работы, ему не мешают совершенно лишние для начинающего понятия классов, объектов, модификаторов доступа, без которых проблематично написать программу на Java.
А ещё у Python есть прекрасный интерактивный режим, ИМХО более дружественный, чем JShell.
Ну и ещё мысль, безотносительно языка программирования. Людям, которые только начинают изучать программирование не понятны вещи, которые нам, опытным программистам, кажутся очевидными, аксиоматичными. Года 3 назад моя сестра в университете изучала Java. Она умудрялась регулярно ставить меня в тупик самыми элементарными вопросами, вроде того как работает передача по ссылке или что такое this. У меня, человека, который лет 7 профессионально пишет на Java подобные понятия отложились так глубоко на подкорке, обрели исключительно образную, понятийную форму, что объяснять это словами мне было проблематично. Возможно, это только мой личный опыт, но именно из-за него я бы не стал собственные глубокие познания в языке позиционировать как аргумент за использование языка для обучения программированию. Опытному программисту не сложно изучить новый язык, а смена контекста помогла бы встряхнуться, посмотреть свежим взглядом на неочевидные моменты, прописать их подробнее.
Optional.ofNullable()это не мешает. Всё отличие междуof()иofNullable()заключается в простой проверке на null. ЕслиOptionalделали как средство борьбы с NPE, то почему более коротким (читай — дефолтным) сделали метод, который ожидает не-null аргумент? Неужели пытались производительность улучшить, убрав один if?Чего только не придумают, лишь бы не добавлять в язык elvis operator. Неужели никому из тех кто работал с этим JEP не показалось, что эта конструкция как минимум громоздкая и неуклюжая? Кто-нибудь в курсе, почему изменений непосредственно языка боятся как огня? Я ещё могу принять объяснение, которое приводили против литералов коллекций — такая конструкция гвоздями прибила бы язык к стандартной библиотеке, потому что нужно было бы специфицировать, какой тип коллекции должен возвращать литерал (хотя наличие autoboxing'а, Iterable и AutoClosable уменьшают вес этого аргумента). Но чем помешает прокачка тернарного оператора? Сочетание символов
?:и так является невалидным, введение его как языковой конструкции не сломает существующий код. Равно как оператор?.для null-safe доступа к методам и свойствам. Да, Optional удобен в тех ситуациях, когда нужно явно обозначить, что значение может отсутствовать, но писать Optional.ofNullable() (кстати, почему Optional.of() бросает NPE если на входе null?) каждый раз, когда хочется просто получить вложенное свойство — неудобно.Не поймите меня неправильно, я не хейтер, я сам пишу на Java и радуюсь улучшению API стандартной библиотеки. Но requireNonNullElse — это какой-то сюр.
Не совсем отменили. Если покупать бумажный билет в кассе, паспорт действительно не потребуют. Но при покупке билета через интернет, обязателен номер документа, подтверждающего личность. По электронным билетам в поезд пустят только при предъявлении паспорта/военника/водительских прав. Распечатанный или показанный на телефоне электронный билет не прокатит, несмотря на то что на нём есть штрих-код, по которому влёгкую могли бы его проавлидировать.
Чем не устраивали десятки готовых конструкторов тестов разной степени интерактивности?
Чем не устроил HTML + CSS + браузер?
В те времена, когда Windows ещё не отключала автозагрузку со сменных носителей, существовало немало конструкторов меню автозагрузки разной степени интерактивности. Чем они не устраивали?
Эталонная задача для Microsoft Access. Но при желании и Excel можно приспособить.
Переопределяем популярные горячие клавиши для работы с окнами, чтобы студент не альттабнулся в другое окно. Выдёргиваем сетевой кабель, чтобы не гуглил ответы. Если для прохождения теста нужен интернет — настраиваем hosts или файрвол.
Чем не устраивали десятки существующих программ родительского контроля?
Чем не устраивали десятки существующих менеджеров паролей?
Чем не устраивали существующие инструменты для создания скриншотов (во многих из которых есть возможность отправить скриншот по почте)?
Я ничего не имею против творчества, самореализации или инструментов для непрофессионалов. Но уж больно ваши сценарии напоминают NIH-синдром, который вы ещё и студентам передаёте. Да ещё и рекламируете им платный инструмент. Не надо так.
Есть ложь, большая ложь и статистика. По статистике, которую регулярно озвучивает мэр Минска, в городе 250 километров велодорожек. На практике есть 27 километров центральной велодорожки (ведущей из ниоткуда в никуда) и несколько не связанных друг с другом огрызков длинной 2-3 километра каждый. Особенно потешно выглядят велодорожки вдоль развязки рядом с библиотекой — от светофора до светофора. Все остальные "велодорожки" — сделанная на отвяжись разметка на тротуаре, на которую забивают как пешеходы (и стар, и млад, а особенно дети), так и сами велосипедисты (потому что более-менее ровная поверхность только на центральных улицах, на остальных регулярно приходится объезжать ямы, трещины и пешеходов). Держать постоянную скорость в таких условиях нереально, постоянные торможения и разгоны выматывают. Даже на центральной велодорожке поджидают сюрпризы в виде мостов, которые поднимаются метра на 2 по дуге (при том что параллельно стоит абсолютно плоской пешеходный мост). Велопарковки ставят у входов в магазины и торговые центры. Рядом со входом в метро я видел ровно одну велопарковку на четыре (!) места. Разметку, повторюсь, рисуют для галочки. Например, каждый день езжу по улице, а начале которой соотношение полос для велосипедистов и пешеходов 1:3, а к концу — 2:1 (потому что тротуар сужается, а "велодорожка" нет). На этой же улице велодорожка заканчивается где-то посередине, а раз нет велодорожки, то и занижать бордюры не обязательно. А позитивное отношение пешеходов и автомобилистов к велосипедистам можно проследить в комментариях к любой новости о велоинфраструктуре на tut.by (спойлер: велосипедистам настойчиво предлагают ездить по проезжей части и сдавать на права).
Хранение данных в месте, полностью подконтрольном пользователю и возможность свободно мигрировать эти данные между приложениями — это замечательно. Но как быть с форматом этих данных? В статье упоминается формат LinkedData, но ни в статье, ни в описании формата не говорится, кто и как будет его стандартизировать. Те же лайки очень по разному работают в разных соцсетях. В VK это просто лайк, в YouTube — лайк или дизлайк, в Facebook — одна из вроде как пяти эмоций, в Skype (представим, что Skype это соцсеть) реакция может быть любым эмодзи. Какой должен быть формат описания лайка, чтобы его можно было мигрировать между приложениями, но при этом чтобы он не ограничивал функционал этих приложений? И лайк — это самый простой пример. В статье приводится в пример приложение для работы с расписанием. Как это-то стандартизировать? И как стандартизировать ещё тысячи форматов данных, с которыми могут работать Solid-приложения? Тут либо стандартный (читай: наименее функциональный) формат, либо vendor lock из-за невозможности перенести данные в проприетарном формате.
В статье утверждается, что благодаря тому что данные хранятся у пользователя, они не могут быть подвергнуты цензуре. Но что толку от возможности хранить нецензурированные данные, если их видишь только ты? Для того чтобы данные пользователя видел не только сам пользователь, нужно какое-то приложение, которое будет транслировать данные пользователя на широкую аудиторию. И вот это приложение уже без проблем может заниматься цензурой. Пользователь, конечно, может поднять своё приложение, которое будет транслировать его данные без цензуры. Но ведь и в нынешнем б-гомерзком централизованном Вебе кто угодно может поднять свой сайт и писать там что угодно. Вот только пользователи вряд ли захотят запоминать десятки или сотни адресов персональных приложений всех тех, кого они читают, и с радостью побегут в подверженные централизации и цензуре аггрегаторы.
Управление доступом к данным? Уже сделали в Android и Google+. В первом большинство людей бездумно дают приложению все права, которые оно запросит. Во втором концепция кругов оказалась слишком сложной для пользователей, и этим мало кто пользовался. Тут не Интернет переизобретать надо, а вести просветительскую работу и повышать сознательность населения.
Ну и вишенка на торте: у хранилища данных пользователя есть свой уникальный id. Теперь условному Google или Facebook не нужно заморачиваться с фингерпринтингом устройств пользователя — пользователь сам даст им надёжный id, по которому можно его отслеживать где угодно. Да, можно сделать себе несколько хранилищ, можно даже пользоваться одноразовыми хранилищами, но заниматься этим будут только те же пользователи, что и сейчас заморачиваются с блокировкой отслеживания через рекламу, кнопки соцсетей и аналитику.
Связка assertThat из JUnit и matcher'ов из Hamcrest позволяет писать почти на чистом английском, а если обширного набора библиотечных matcher'ов недостаточно — всегда можно написать свои.
Раскажите, пожалуйста, на кого расчитана ваша статья? Как мне видится, максимальную пользу из неё извлечёт человек, который:
Это я к чему… Пояснений много не бывает. Ваша статья была бы гораздо полезнее, если бы вы хотя бы в двух словах объясняли, зачем нужна каждая из использованных технологий, приводили ссылки на документацию и выложили бы полный код проекта на GitHub.
Всё сразу вываливать на начинающего я бы не стал. Первый десяток-другой задач начинающий будет решать без написания собственных функций, используя минимальный набор встроенных (ввод-вывод, математика). На этом этапе можно применить метафору «чёрного ящика», на вход в который подаются какие-то значения (ну, или не подаются), внутри они как-то обрабатываются и возвращается результат обработки (ну, или не возвращается). Можно показать, в каком порядке программа будет разбирать выражение с функцией, сказать, что при выполнении программы вызов функции «заменяется» на результат её выполнения с переданными параметрами. Не отходя от метафоры «чёрного ящика» (буквально, не показывая синтаксис объявления функций, на простых картинках) показать какие бывают функции, что они могут делать. Объяснить, что в функции выносится часто используемый код, чтобы его не копипастить. Для начала использования готовых функций этого должно быть достаточно.
Первые самостоятельно написанные функции, скорее всего, будут «плоскими», то есть, не будут вызывать другие функции. В этот момент нужно объяснить про области видимости переменных (в случае с Python; в случае с Java это нужно объяснять раньше, рассказывая про циклы и условне операторы). Дать несколько упражнений на определение, какие переменные видны из функции (в случае с Python пока не рассказывать, что функции можно объявлять внутри функций, циклов или условных операторов, это оставить на потом, когда сформируется более чёткое понимание областей видимости). После этого можно показывать, что будет происходить, если из функции вызвать другую функцию. На этом этапе тот факт, что из функции не видны переменные из области, в которой функцию вызвали, не должен вызывать диссонанса. Нужно мотивировать начинающего активно использовать отладчик для понимания хода выполнения программы и изменения видимых переменных. И только на этом этапе можно рассказывать про стек вызовов.
У вашего отца был сильный математический бэкграунд, отсюда и непонимание императивных функций. У ребёнка, только начинающего изучать программирование, такого бэкграунда нет, поэтому ему
можно вешать на уши любую лапшубудет легче усвоить, что такое функция в контексте программирования.Потому что (ИМХО) начинающим надо давать не ООП, а программирование. То есть, объяснять, как выполняется программа, как хранятся и изменяются её данные, учить декомпозировать задачу, сторить алгоритмы, отлаживать их. ООП нужно для того чтобы структурировать сложные программы, а задачи, которые будет решать новичок, долгое время будут умещаться в один метод main одного объекта (если мы говорим о Java). При этом Java заставляет использовать ООП даже для простейших операций ввода:
Чтобы новичок понял, что тут происходит, нужно объяснить ему про синтаксис объявления переменных, классы, создание объектов, конструкторы, потоки ввода-вывода, вызовы методов, различие классов и объектов. Ах да, ещё не забыть упомянуть, что классы надо импортировать, попутно объясняя про пакеты. Если это не объяснить, код будет бездумно копипаститься, что, на мой взгляд, вредно для процесса обучения. А если объяснять, то на новичка единовременно вывалится огромный поток информации, который он в какой-то момент перестанет усваивать.
Тем временем в Python (да, я буду топить за Python как первый язык) это выглядит так:
Объясняем, что такое переменная, что такое функция, как происходит вызов функции и присвоение значения. Всё. Новичок продолжает изучение программирования не отвлекаясь на ООП.
Объяснять нужно только что такое print, да и то человеку, имеющему минимальные знания английского это будет интуитивно понятно. Жирным плюсом Python, по моему опыту (опыту изучения, не преподавания), является то, что он не вываливает на новичка кучу ненужных ему понятий, а позволяет вникнуть в них постепенно. Тот же цикл for для новичка выглядит достаточно просто:
Интерпретируется просто: перебираем i в диапазоне от 1 до 10. Позже новичок узнаёт, что перебирать можно не только числа, но и элементы списков или символы строк. А ещё позже — что в цикле for можно перебирать любой iterable — объект, реализующий определённый контракт. В конце концов, он учится писать свои iterable. На каждой ступени новичок знает только детали, необходимые ему для работы, ему не мешают совершенно лишние для начинающего понятия классов, объектов, модификаторов доступа, без которых проблематично написать программу на Java.
А ещё у Python есть прекрасный интерактивный режим, ИМХО более дружественный, чем JShell.
Ну и ещё мысль, безотносительно языка программирования. Людям, которые только начинают изучать программирование не понятны вещи, которые нам, опытным программистам, кажутся очевидными, аксиоматичными. Года 3 назад моя сестра в университете изучала Java. Она умудрялась регулярно ставить меня в тупик самыми элементарными вопросами, вроде того как работает передача по ссылке или что такое this. У меня, человека, который лет 7 профессионально пишет на Java подобные понятия отложились так глубоко на подкорке, обрели исключительно образную, понятийную форму, что объяснять это словами мне было проблематично. Возможно, это только мой личный опыт, но именно из-за него я бы не стал собственные глубокие познания в языке позиционировать как аргумент за использование языка для обучения программированию. Опытному программисту не сложно изучить новый язык, а смена контекста помогла бы встряхнуться, посмотреть свежим взглядом на неочевидные моменты, прописать их подробнее.