Xanadu. Связи всего со всем, версионирование, композитные документы, упрощенный копирайт и еще куча плюшек - все то, чего лишена нынешняя сеть. Идея старее самого Интернета, но так и не была реализована.
Невообразимо тяжело читать из-за сухости изложения и высокого уровня абстракции обсуждаемых тем (картинка в голове при желании складывается, но все ж), однако сами идеи не устарели до сих пор. Особенно интересна OHS, на удивление сильно перекликающаяся с идеями Xanadu Теда Нельсона и отчасти реализованная в Hypercard, убитой вернувшимся в Apple Стивом Джобсом. Похоже, они и правда в 60-х варились в едином информационном поле :)
PS Переводить аббревиатуры, на мой взгляд, совершенно излишне, поскольку убивает всю поэтику названия — сравните CoDIAK и ПРИВЗ.
Итоговый интерфейс достаточно сильно напоминает Epoxy от Airbnb. Потенциально ваше решение можно использовать для тех же целей — создания длинных экранов (не обязательно списковых) целиком в одном RecyclerView.
Не менее внушительной является цикличная программа «99bottles»
К сожалению, из-за отсутствия форматирования в данном куске кода абсолютно невозможно усмотреть цикл повторения символов исходника, равный размеру алфавита шифрования, т.е. 94. В оригинале это видно гораздо лучше.
И в целом интересной информации по языку в статье нема. А ведь рассказать есть про что: на Malbolge уже и квайн есть, и ROTR реализован, и японцы целые исследовательские статьи про генерацию программ написали. Но нет, из раза в раз один и тот же копипаст из статьи на вики, выправленной автором комментария еще в студенческие годы.
Браво! Мне сразу вспомнился незавершенный, увы, Xanadu Project и HyperCard, позволявший создавать связанные базы знаний на Macintosh годах в 80-90-х. Про последний можно глянуть на Internet Archive. Все они тоже черпали вдохновение из идей Буша
Наверное, потому, что это интересно. Сделать нечто свое. такое, что никто до тебя не делал, ну или хотя бы что-то, в чем ты будешь досконально разбираться от и до. Сам такой фигней маюсь
Я, как говорится, novice to Android development, поэтому рассматривать буду именно с этой точки зрения.
Из несомненных плюсов:
Открытость платформы и огромное комьюнити. Говорили уже, повторяться бессмысленно.
Хорошая документация. Nuff said.
Быстрое развитие. Всего каких-то два года назад в топе был SDK 16, а нынче уже 24 вышел. Изменений за это время воз и маленькая тележка.
Material Design. Возможность создать приложение с интерфейсом, будто бы спроектированным профессиональным дизайнером — это просто круто. А ведь все, что требуется — следовать гайдам. Увы, 90% приложений в PlayMarket до сих пор его не используют.
Но и минусов хватает, как в самой платформе, так и около нее:
Activity и Fragment lifecycle. Это и в самом деле головная боль, причем по сей день. Архитектурных решений много, но все они в той или иной степени костыльны. По сию пору кажется, что это можно значительно упростить. Но по факту это невозможно, поскольку:
Необходимо поддерживать старые версии ОС. Это мешает производить кардинальные изменения в платформе. Отчасти спасают Support Libraries.
Отсутствие многих высокоуровневых средств в самой платформе. До сих пор не понимаю отсуствия штатного аналога Picasso или Retrofit. Third-party — оно, конечно, здорово, но непонятно, почему сторонние разработчики вынуждены создавать решения, которые должны быть предоставлены самими разработчиками платформы. IMHO, разумеется
Довольно-таки печальное состояние в области обучения современному программированию под Android. Учебников с основами (в которых до сих пор описываются те же AsyncTask-и) — завались, как и сборников статей с трехкнопочными примерами, разрозненных туториалов по Dagger'у, RxJava etc тоже хватает, а вот полноценных курсов, где все это связывается воедино и показано, как же создается современное мобильное приложение от А до Я, раз-два и обчелся. За счет этого порог вхождения в эту область на данный момент крайне высок.
Еще печальнее с информацией по внутренней кухне. Здесь либо закопаться в исходники с головой, либо записываться на курс от Linux Foundation. Ну еще можно посмотреть в описание Context pattern. На этом, в общем-то, и все.
PS Вспомнил еще кое-что, но это скорее к разработчикам библиотек и Android Studio.
Пора бы уже и запилить наконец полноценную поддержку DataBinding'а в студии. На оператор :: до сих пор ругается, && не распознает и т.д. (на момент версии 2.2 RC). Информативность сообщений об ошибках оставляет желать лучшего. Например, на днях встретилась ошибка при компиляции, что-то вроде "Cannot find the setter for attribute 'android:layout_height' on android.widget.ImageView with parameter type float". Суть понятна — биндинг не воспринимает параметр, но в чем причина и как исправить — пришлось лезть на AOSP Issue Tracker. Попонятнее сообщение требуется, где будет указана именно причина возникновения проблемы.
С Dagger 2 ситуация не лучше. Чтобы найти причину ошибки при генерации классов, приходится мотать в самый низ. Почему бы не скрыть всю вышележащюю портянку, информативность которой около нуля?
Похоже на "Цивилизацию 2190" Жерара Клейна, хотя там речь немного про иное
Xanadu. Связи всего со всем, версионирование, композитные документы, упрощенный копирайт и еще куча плюшек - все то, чего лишена нынешняя сеть. Идея старее самого Интернета, но так и не была реализована.
В сторону AOP не смотрели? Аналитика — это как раз одна из немногих задач, которые хорошо ложатся на эту парадигму: https://habr.com/ru/company/yandex/blog/280117/
Невообразимо тяжело читать из-за сухости изложения и высокого уровня абстракции обсуждаемых тем (картинка в голове при желании складывается, но все ж), однако сами идеи не устарели до сих пор. Особенно интересна OHS, на удивление сильно перекликающаяся с идеями Xanadu Теда Нельсона и отчасти реализованная в Hypercard, убитой вернувшимся в Apple Стивом Джобсом. Похоже, они и правда в 60-х варились в едином информационном поле :)
PS Переводить аббревиатуры, на мой взгляд, совершенно излишне, поскольку убивает всю поэтику названия — сравните CoDIAK и ПРИВЗ.
Итоговый интерфейс достаточно сильно напоминает Epoxy от Airbnb. Потенциально ваше решение можно использовать для тех же целей — создания длинных экранов (не обязательно списковых) целиком в одном RecyclerView.
Пробовал год назад — hr ответила, что кандидаты с опытом менее 2 лет не рассматриваются. Хм, ну ок :)
Как водится, печально, что замкадышам ничего не светит
К сожалению, из-за отсутствия форматирования в данном куске кода абсолютно невозможно усмотреть цикл повторения символов исходника, равный размеру алфавита шифрования, т.е. 94. В оригинале это видно гораздо лучше.
И в целом интересной информации по языку в статье нема. А ведь рассказать есть про что: на Malbolge уже и квайн есть, и ROTR реализован, и японцы целые исследовательские статьи про генерацию программ написали. Но нет, из раза в раз один и тот же копипаст из статьи на вики, выправленной автором комментария еще в студенческие годы.
В 2 коммита уложились. Чудо, не иначе
Спасибо, давно так не рыдал
В группы Telegram напишите, там сейчас народу много обитает: в pro.jvm, в группу Новосибирской GDG, например
Браво! Мне сразу вспомнился незавершенный, увы, Xanadu Project и HyperCard, позволявший создавать связанные базы знаний на Macintosh годах в 80-90-х. Про последний можно глянуть на Internet Archive. Все они тоже черпали вдохновение из идей Буша
Наверное, потому, что это интересно. Сделать нечто свое. такое, что никто до тебя не делал, ну или хотя бы что-то, в чем ты будешь досконально разбираться от и до. Сам такой фигней маюсь
А где же классика, Brainfuck/Malbolge/Befunge?
У вас Malbolge. Ох, и далеко же вам спускаться за принцессой...
Спасибо, весьма интересно. Перевод второй части будет?
Я, как говорится, novice to Android development, поэтому рассматривать буду именно с этой точки зрения.
Из несомненных плюсов:
Но и минусов хватает, как в самой платформе, так и около нее:
PS Вспомнил еще кое-что, но это скорее к разработчикам библиотек и Android Studio.
Пора бы уже и запилить наконец полноценную поддержку DataBinding'а в студии. На оператор :: до сих пор ругается, && не распознает и т.д. (на момент версии 2.2 RC). Информативность сообщений об ошибках оставляет желать лучшего. Например, на днях встретилась ошибка при компиляции, что-то вроде "Cannot find the setter for attribute 'android:layout_height' on android.widget.ImageView with parameter type float". Суть понятна — биндинг не воспринимает параметр, но в чем причина и как исправить — пришлось лезть на AOSP Issue Tracker. Попонятнее сообщение требуется, где будет указана именно причина возникновения проблемы.
С Dagger 2 ситуация не лучше. Чтобы найти причину ошибки при генерации классов, приходится мотать в самый низ. Почему бы не скрыть всю вышележащюю портянку, информативность которой около нуля?
Автор существует и он перенес проект на гитхаб, ибо давно пора :)