Очередная новость: Гугл пожертвует $350k на разработку Python.
То есть пожертвует в специальный "некоммерческий фонд", который занимается разработкой Питона: PSF.
Президентом фонда является Гвидо ван Россум, изначальный разработчик языка. Что ж, дело хорошее. Гвидо настоящий программист и знает своё дело (в отличие от Расмуса Ледорфа, разработчика PHP, который никогда способным программистом не был и за почти 30 лет разработки своего языка не потрудился хоть какой-то талант развить, и к программированию и программистам относится с демонстративным пренебрежением).
Одновременно, Гвидо работает в Microsoft, недавно выйдя из "официального ухода на пенсию". В 65 лет захотелось поработать фулл-тайм. Поработать не в своём фонде над своим языком, а в коммерческой компании.
Вот такой вот успешный язык.
Ну что ж, а куда пойдут деньги?
Посмотрим отчёт за предыдущий период (2019 год):
- по тысяче баксов каждому из сотни докладчиков международных конференций, на билеты и пиво ($140k)
- тудым, сюдым, проекты всякие, поддержка в Android ($250k)
- тудым, сюдым, организационные издержки, хостинги, всё такое ($50k)
- тудым, сюдым, тренинги всякие, "инициативы по всему миру" ($325k)
- тудым, сюдым, "усиление брендов", "торговые марки" ($270k)
- разработка python ($25k)
Ну то есть КПД фонда примерно 2.5% ($25k от $1M). Остальное ушло кому надо и на какие надо важные дела. При этом номинальный глава фонда вынужден в 65 лет снова выходить на работу.
Не трудно прикинуть, что даже если целиком годовое пожертвование Гугла направить на разработку Python, то его хватит на работу, в лучшем случае, двух хороших американских программистов.
По-моему это не поддержка, а насмешка какая-то.
#programming #python
То есть пожертвует в специальный "некоммерческий фонд", который занимается разработкой Питона: PSF.
Президентом фонда является Гвидо ван Россум, изначальный разработчик языка. Что ж, дело хорошее. Гвидо настоящий программист и знает своё дело (в отличие от Расмуса Ледорфа, разработчика PHP, который никогда способным программистом не был и за почти 30 лет разработки своего языка не потрудился хоть какой-то талант развить, и к программированию и программистам относится с демонстративным пренебрежением).
Одновременно, Гвидо работает в Microsoft, недавно выйдя из "официального ухода на пенсию". В 65 лет захотелось поработать фулл-тайм. Поработать не в своём фонде над своим языком, а в коммерческой компании.
Вот такой вот успешный язык.
Ну что ж, а куда пойдут деньги?
Посмотрим отчёт за предыдущий период (2019 год):
- по тысяче баксов каждому из сотни докладчиков международных конференций, на билеты и пиво ($140k)
- тудым, сюдым, проекты всякие, поддержка в Android ($250k)
- тудым, сюдым, организационные издержки, хостинги, всё такое ($50k)
- тудым, сюдым, тренинги всякие, "инициативы по всему миру" ($325k)
- тудым, сюдым, "усиление брендов", "торговые марки" ($270k)
- разработка python ($25k)
Ну то есть КПД фонда примерно 2.5% ($25k от $1M). Остальное ушло кому надо и на какие надо важные дела. При этом номинальный глава фонда вынужден в 65 лет снова выходить на работу.
Не трудно прикинуть, что даже если целиком годовое пожертвование Гугла направить на разработку Python, то его хватит на работу, в лучшем случае, двух хороших американских программистов.
По-моему это не поддержка, а насмешка какая-то.
#programming #python
Python software foundation: "фирма" работает
Немного взглянули в прошлый раз на бухгалтерию Python Software Foundation. Внешне организация маскируется под такое формальное легальное прикрытие сбора денег на нужды программистов (цель понятная и благородная). Суть компании описывается коротко и однозначно: "PSF – это организация, стоящая за Python".
Возвращаясь к нашему предыдущему материалу возникает, конечно, вопрос, почему КПД работы этой организации такой низкий, если декларируемая функция совпадает с реальной.
Среди "инициатив по всему миру", "популяризации программирования среди женщин", "поедании тако и поездках на велосипеде" (кратко об этом дальше) и других важных вещей, которыми занимаются сотрудники фонда, проскакивает кое-что, что всё же имеет непосредственное отношение к языку и инфраструктуре разработки: поддержка и развитие менеджера пакетов PyPI.
Результат многолетнего (двадцатилетнего, если считать от основания PSF) развития этого направления заключается в том, что PyPI, без оговорок, худший пакетный менеджер среди всех конкурентов. Даже Go, который в этом аспекте подвергался справедливой критике, всё же не был настолько позорно отставшим от передовых образцов. Даже NPM лучше: хотя, казалось бы, хуже и найти невозможно.
Гугл, кстати, закинул денег (см. прыдыдущий материал) в том числе на "аудит кода в PyPI". На то, чтобы сделать из PyPI продукт, которым не стыдно было бы пользоваться в "самом популярном динамическом языке", денег он, разумеется, не дал: Google поддерживает свою закрытую альтернативу, которой в определённых рамках после многошаговой регистрации даже можно пользоваться бесплатно.
Пакетный менеджер
То есть, на пальцах: чтобы понять, какую максимальную версию пакета А (заданную в манифесте как '1.*') можно использовать с пакетом B (версии, положим, тоже '1.*'),
Хорошо, эффективность выполнения PSF-ом своих прямых функций установили. Денег разработчикам сторонних решений (pipenv, например – приличный production-ready продукт, который можно просто взять и вмёрджить в основной дистрибутив python и закрыть вопрос) приниципиально решили не давать. На счетах PSF при этом скопилось 4 миллиона баксов. Чем же он занимается?
Достаточно посмотреть официальный список наёмных сотрудников, чтобы все вопросы снять. Полный список сотрудников и их обязанностей такой:
– директор (управление персоналом и трансляция воли совета директоров)
– счетовод, бухглатер и главный бухглатер (обязанности понятны)
– секретарь директора (сбор средств на благотворительных акциях, организация конференций)
– ивент-менеджер (организация конференций)
– Директор Инфраструктуры (заседание в комитетах, хостинг сайта python.org)
Про Директора Инфраструктуры, единственного айтишника среди всей команды, в официальном резюме сказано вот что: любит тако и кататься на велосипеде, притворяется что его любят кошки, а зовут его Ee W. Durbin III. Игра слов непереводимая и не до конца понятная, но ясно, что это что-то вроде "Вась И. Турбин Третий". При этом у человека есть и настоящее имя, конечно, в смысле по паспорту, но на лицевой странице фонда и в официальной переписке он предпочитает выступать Дурбин-Третьим. "Человек и пароход".
#programming #python
Немного взглянули в прошлый раз на бухгалтерию Python Software Foundation. Внешне организация маскируется под такое формальное легальное прикрытие сбора денег на нужды программистов (цель понятная и благородная). Суть компании описывается коротко и однозначно: "PSF – это организация, стоящая за Python".
Возвращаясь к нашему предыдущему материалу возникает, конечно, вопрос, почему КПД работы этой организации такой низкий, если декларируемая функция совпадает с реальной.
Среди "инициатив по всему миру", "популяризации программирования среди женщин", "поедании тако и поездках на велосипеде" (кратко об этом дальше) и других важных вещей, которыми занимаются сотрудники фонда, проскакивает кое-что, что всё же имеет непосредственное отношение к языку и инфраструктуре разработки: поддержка и развитие менеджера пакетов PyPI.
Результат многолетнего (двадцатилетнего, если считать от основания PSF) развития этого направления заключается в том, что PyPI, без оговорок, худший пакетный менеджер среди всех конкурентов. Даже Go, который в этом аспекте подвергался справедливой критике, всё же не был настолько позорно отставшим от передовых образцов. Даже NPM лучше: хотя, казалось бы, хуже и найти невозможно.
Гугл, кстати, закинул денег (см. прыдыдущий материал) в том числе на "аудит кода в PyPI". На то, чтобы сделать из PyPI продукт, которым не стыдно было бы пользоваться в "самом популярном динамическом языке", денег он, разумеется, не дал: Google поддерживает свою закрытую альтернативу, которой в определённых рамках после многошаговой регистрации даже можно пользоваться бесплатно.
Пакетный менеджер
pip не позволяет фиксировать версии (нет аналога Gemfile.lock или package-lock.js), ошибается в сложных (но встречающихся на практике) случаях разрешения зависимостей, и, как вишенка на торте, не умеет отдельно скачивать метаданные.То есть, на пальцах: чтобы понять, какую максимальную версию пакета А (заданную в манифесте как '1.*') можно использовать с пакетом B (версии, положим, тоже '1.*'),
pip-у, в общем случае, требуется полностью скачать из PyPI все версии пакетов А и B соответствующие маске (1.1, 1.2, 1.2.2, 1.3, и т.д.).Хорошо, эффективность выполнения PSF-ом своих прямых функций установили. Денег разработчикам сторонних решений (pipenv, например – приличный production-ready продукт, который можно просто взять и вмёрджить в основной дистрибутив python и закрыть вопрос) приниципиально решили не давать. На счетах PSF при этом скопилось 4 миллиона баксов. Чем же он занимается?
Достаточно посмотреть официальный список наёмных сотрудников, чтобы все вопросы снять. Полный список сотрудников и их обязанностей такой:
– директор (управление персоналом и трансляция воли совета директоров)
– счетовод, бухглатер и главный бухглатер (обязанности понятны)
– секретарь директора (сбор средств на благотворительных акциях, организация конференций)
– ивент-менеджер (организация конференций)
– Директор Инфраструктуры (заседание в комитетах, хостинг сайта python.org)
Про Директора Инфраструктуры, единственного айтишника среди всей команды, в официальном резюме сказано вот что: любит тако и кататься на велосипеде, притворяется что его любят кошки, а зовут его Ee W. Durbin III. Игра слов непереводимая и не до конца понятная, но ясно, что это что-то вроде "Вась И. Турбин Третий". При этом у человека есть и настоящее имя, конечно, в смысле по паспорту, но на лицевой странице фонда и в официальной переписке он предпочитает выступать Дурбин-Третьим. "Человек и пароход".
#programming #python
Понятно, что на всю Америку, несомненно, нашёлся бы хотя бы один программист, который мог бы за всю тусовку бухгалтеров пополам с ивент-менеджерами изображать (хотя бы из соображений естественной социальной маскировки) хардкорный технический уклон фирмы. Мол, ничего, что у нас тут собрались одни "организаторы", я за десятерых решаю вопросы развития языка и делаю по два PR в неделю, поэтому меня и одного хватит. Такие люди ведь есть. Назначение Дурбина-Третьего, поэтому, с такой специфической автобиографией, выглядит отнюдь не недоработкой, а демонстративным жестом: плевать нам на вас, гики, и так съедите и будете ходить на наши конференции по стагнирующему языку и платить деньги как миленькие, ещё и прыгать от радости. (И ходят, и платят, и прыгают.)
Итак, фирма занимается организацией ивентов. Команда подобралась сбалансированная.
Эту же команду можно поставить на организацию ивентов по защите прав кошек и собак небольшого роста (вместо Дурбина взять Кошкину, активистку и владелицу домашнего питомника на 15 голов), региональных авторалли (последнего члена команды заменить на автослесаря Петровича, кхм, в смысле, Джонсона, из соседней мастерской), продвижения депутатов городского совета небольших региональных центров, и т.п. И поставят, как выдохнется текущее направление работы.
В этом смысле понятен акцент в отчётности на "узнавании брендов" и "охвате конференций", и отсутствие ссылок на вклад в развитие языка и платформы. Это попросту не их профиль, о чём они, фактически, открыто сообщают.
Здесь, конечно, расчёт на то, что программисты – совсем тупые и не понимают, что если в развитие языка реально не вкладываться, то разработка на нём очень быстро станет очень унылой. Это ведь не политика, где тамада может прыгать до бесконечности, тут конкретный измеримый продукт на выходе есть. Или, в данном случае, нет.
Что ж, увы, в какой-то мере это правда. Но, в отличие от многих других сфер труда, в программировании очень хорошо работает (в определённых границах) естественная селекция: чем умнее, тем больше зарабатывает.
Языки для бедных тоже нужны.
#programming #python
Итак, фирма занимается организацией ивентов. Команда подобралась сбалансированная.
Эту же команду можно поставить на организацию ивентов по защите прав кошек и собак небольшого роста (вместо Дурбина взять Кошкину, активистку и владелицу домашнего питомника на 15 голов), региональных авторалли (последнего члена команды заменить на автослесаря Петровича, кхм, в смысле, Джонсона, из соседней мастерской), продвижения депутатов городского совета небольших региональных центров, и т.п. И поставят, как выдохнется текущее направление работы.
В этом смысле понятен акцент в отчётности на "узнавании брендов" и "охвате конференций", и отсутствие ссылок на вклад в развитие языка и платформы. Это попросту не их профиль, о чём они, фактически, открыто сообщают.
Здесь, конечно, расчёт на то, что программисты – совсем тупые и не понимают, что если в развитие языка реально не вкладываться, то разработка на нём очень быстро станет очень унылой. Это ведь не политика, где тамада может прыгать до бесконечности, тут конкретный измеримый продукт на выходе есть. Или, в данном случае, нет.
Что ж, увы, в какой-то мере это правда. Но, в отличие от многих других сфер труда, в программировании очень хорошо работает (в определённых границах) естественная селекция: чем умнее, тем больше зарабатывает.
Языки для бедных тоже нужны.
#programming #python
Недавно рассматривали организационную экосистему Python. В принципе, все всё правильно поняли.
Как точно резюмировал один из читателей: "постмодерн".
Другой читатель, посмотрев на фотографию директора Python Software Foundation, критично (в мой адрес) прокомментировал: "ну, ты бы ещё поставил ей в упрёк, что у неё в интересах «дивёрсити» указано!". Но позвольте, я ведь просто выложил фотографию с подписью, которую человек сам о себе с гордостью демонстрирует, практически, на своём официальном сайте. Мне показался такой упрёк забавным и показательным, я и сам что-то подобное чувствовал при написании текста: иррационально кажется, что прямое дословное цитирование чьих-то пиар ходов одновременно является как бы критикой автора этих ходов. С одной стороны, хорошо бы при пересказе чьей-то позиции по ходу заочной полемики, по возможности, сглаживать острые углы, если человек явно ошибся. Но в случае фирмы, специализирующейся на популяризации самой себя, ошибки в демонстративных жестах никакой быть не может, это целенаправленная самопрезентация.
Хотел дальше по этой линии постов вкратце разобрать список учредителей PSF (в отличие от показанной ранее "исполнительной" части организации, там есть "содержательные" персонажи). Но пока отложим: думаю, надо нам всем ещё поработать над собой, над повышением уровня толерантности и ментального самоконтроля, чтобы от рассмотрения профилей значимых общественных деятелей (самими этими деятелями о себе и написанных) возникала положенная цивилизованному человеку автоматическая улыбка и чувство эмпатии, а не сложная композиция плохо "диверсифицированных" мыслей.
Перескочим сразу на следующую тему (в этой линии тем). JetBrains участвует в кампании по сбору средств на Django (деньги собирает отдельная организация) – отчисляет все поступления с продаж IDE PyCharm в Django Software Foundation. Дело стоящее, давайте в меру сил и доступных средств поучаствуем в популяризации хорошего языка и фреймворка.
Участвовать будем путём критического анализа отдельных аспектов фреймворка и сопутствующей инфраструктуры. Материал будет потихоньку выкладываться.
#programming #django #python
Как точно резюмировал один из читателей: "постмодерн".
Другой читатель, посмотрев на фотографию директора Python Software Foundation, критично (в мой адрес) прокомментировал: "ну, ты бы ещё поставил ей в упрёк, что у неё в интересах «дивёрсити» указано!". Но позвольте, я ведь просто выложил фотографию с подписью, которую человек сам о себе с гордостью демонстрирует, практически, на своём официальном сайте. Мне показался такой упрёк забавным и показательным, я и сам что-то подобное чувствовал при написании текста: иррационально кажется, что прямое дословное цитирование чьих-то пиар ходов одновременно является как бы критикой автора этих ходов. С одной стороны, хорошо бы при пересказе чьей-то позиции по ходу заочной полемики, по возможности, сглаживать острые углы, если человек явно ошибся. Но в случае фирмы, специализирующейся на популяризации самой себя, ошибки в демонстративных жестах никакой быть не может, это целенаправленная самопрезентация.
Хотел дальше по этой линии постов вкратце разобрать список учредителей PSF (в отличие от показанной ранее "исполнительной" части организации, там есть "содержательные" персонажи). Но пока отложим: думаю, надо нам всем ещё поработать над собой, над повышением уровня толерантности и ментального самоконтроля, чтобы от рассмотрения профилей значимых общественных деятелей (самими этими деятелями о себе и написанных) возникала положенная цивилизованному человеку автоматическая улыбка и чувство эмпатии, а не сложная композиция плохо "диверсифицированных" мыслей.
Перескочим сразу на следующую тему (в этой линии тем). JetBrains участвует в кампании по сбору средств на Django (деньги собирает отдельная организация) – отчисляет все поступления с продаж IDE PyCharm в Django Software Foundation. Дело стоящее, давайте в меру сил и доступных средств поучаствуем в популяризации хорошего языка и фреймворка.
Участвовать будем путём критического анализа отдельных аспектов фреймворка и сопутствующей инфраструктуры. Материал будет потихоньку выкладываться.
#programming #django #python
В целом если вы видели один MVC фреймворк, вы видели их все. Переходя с Rails на Django (и наоборот) вы, может быть, ожидаете увидеть какие-то различия, но на самом деле всё в точности то же самое.
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке
В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов:
В строке импорта выше
Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (
Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле
#programming #django #python
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке
app/models/car.rb лежит класс Car, то вам достаточно в коде написать Car, и Rails его найдут.В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов:
from car_service.models import Car. В этом есть плюс: IDE всегда знает, откуда что взялось. Минус: существенное увеличение boilerplate-а и когнитивной нагрузки на его обслуживание.В строке импорта выше
car_service это, в терминах Python, имя пакета (имя выбрано произвольно: допустим, мы делаем бэкофис для автомастерской). А в терминах DJango, это имя "приложения" (application). models.py – имя файла, где лежит исходный код класса Car. Да, в Django в один файл принято запихивать десяток классов. Это одно из многих проявлений знаменитого питоновского акцента на красоту и элегантность кода.Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (
INSTALLED_APPS) в settings.py (файл настроек проекта). (Кстати, термин application здесь в итоге близок тому, как он понимается в экосистеме Elixir/Phoenix.) В терминах Rails этому car_service нет прямого аналога, иногда что-то подобное можно назвать "ресурсом" (resource, в терминах REST), иногда bounded context (опять же в Phoenix более прямые аналоги).Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле
car_service/models.py, а модель User в папке accounts/models.py.#programming #django #python
Питоновские пакеты, из-за обязательного явного импорта, могут экспортировать не только классы, но и переменные или константы:
Как было сказано выше, в Django в роли "вьюх" (т.е., в терминах Rails, "контроллеров") могут выступать отдельные функции. А могут и классы. Первое называется function based views, а второе class based views.
Привыкшему к REST веб-разработчику сподручнее сразу использовать class based views, чтобы не получать очередного когнитивного диссонанса от использования конструкций вроде
#programming #django #python
# some_file.pyПолучается своеобразная двойная иерархия: классы наследуют друг друга, а пакеты друг из друга импортируют всякую всячину. Поэтому в Питоне, где можно, частенько классы и не создают, просто группируют функции внутри файла (и файлы внутри пакета), и импортируют их в других файлах (и других пакетах). В Ruby для создания коллекции функций обязательно использовать, по меньшей мере, модули (modules); но вообще в качестве стандартной единицы распространения кода выступает класс, при этом имя файла (по соглашению/кодстайлу) однозначно соответствует имени класса (и в одном файле всегда только один класс).
NUMBER = 1
# another_file.py
from .some_file import NUMBER
print(NUMBER) #=> 1
Как было сказано выше, в Django в роли "вьюх" (т.е., в терминах Rails, "контроллеров") могут выступать отдельные функции. А могут и классы. Первое называется function based views, а второе class based views.
Привыкшему к REST веб-разработчику сподручнее сразу использовать class based views, чтобы не получать очередного когнитивного диссонанса от использования конструкций вроде
if request.method == 'POST' в мейнстримном фреймворке, созданном на самом элегантном языке программирования.#programming #django #python
Следующее существенное отличие Django от Rails это система миграций
В Rails миграции это просто тонкая обёртка над SQL-кодом: добавь такой-то столбец, удали такой и т.д. Все миграции хранятся в одной папке в хронологическом порядке. Движок определяет, какие миграции прошли, на основе того, есть ли отметка о данной миграции в специальной служебной таблице в базе данных.
В Django тоже есть аналогичная таблица, но этим дело не заканчивается. Во-первых, миграции разделены по "приложениями" (см. выше). В каждом приложении хранятся миграции (по конвенции), касающиеся моделей этого приложения. Вместо подразумеваемой цепочки зависимостей из Rails (где мы, фактически, считаем, что каждая миграция зависит от всех по времени более ранних), в Django в начале каждой миграции явно указывается, от каких предыдущих она зависит (они могут быть из других "приложений"). Получается сложный граф зависимостей.
Представим, что во время рефакторинга мы удалили некое "приложение" или два "приложения" объединили в одно. Что происходит с миграциями? Происходит, как можно догадаться, fuck up beyond all repair. Вам придётся либо оставить миграции в покое (удалив из устаревшего "приложения" все другие файлы), либо переписать все миграции, фактически, с нуля. Элегантному фреймворку – элегантные решения.
Далее важно понять, что в Django миграции это не простые прямолинейные команды для движка. Это декларация о том, что должно быть в базе данных. Когда мы пишем в миграции А "добавить столбец X, Y", а в миграции B (следующей по времени позже A) "добавить столбец Z, удалить столбец X", движок (во время исполнения миграций, когда он считывает все файлы) понимает: "ага, у нас в базе сейчас столбцы Y, Z" (важно отметить, что к базе данных при этом он подключается только для получения списка уже сделанных миграций – если вы там сами что-то наворотили отдельно, то всё сломается).
Django формирует, на основе виртуального суммирования всех миграций, некое своё (точное) представление о том, какая сейчас структура в БД (исходя из того, что она создавалась исключительно миграциями). Это называется State, "состояние".
Затем Django доходит до миграций, которые ещё не были выполнены, и выполняет соответствующие SQL-инструкции (database operations). Здесь операция вроде "добавить столбец M" выступает уже в двух ролях:
– во-первых, как database operation (аналогично Rails) – инструкции буквально выполнить
Как можно было предполагать, этот изящный подход к проблеме от, как складывается впечатление, какого-то победителя региональных олимпиад по computer science, в реальных приложениях работает отлично 80% времени. Оставшиеся 20% времени вам потребуется, вырывая волосы на голове, вгрызаться в (довольно сложный, но всё же за пару дней можно разобраться) DSL миграций и писать миграции типа SeparateDatabaseAndState (это когда вы буквально говорите Django, мол, я сам в базе произведу нужные операции, не надо "читать мысли", а потом отдельно ещё ему объясняете для этого "внутреннего образа схемы БД", что же вы сделали).
Тема миграций напрямую связана с темой моделей. Модели в Django требуют явного указания полей (похоже на gem DataMapper), в то время как в Rails поля подгружаются в рантайме из базы данных. Явное указание полей модели позволяет делать "автомиграции" – написать команду, которая (в соответствии с теми изменениями, что вы внесли в моделях, сравнивая их со State, который был вычислен из предыдущих миграций) сгенерирует миграцию, в которой удаляются (добавляются, изменяются) соответствующие поля. Это издевательски небольшая, но иррационально приятная компенсация за все прочие мучения.
#programming #django
В Rails миграции это просто тонкая обёртка над SQL-кодом: добавь такой-то столбец, удали такой и т.д. Все миграции хранятся в одной папке в хронологическом порядке. Движок определяет, какие миграции прошли, на основе того, есть ли отметка о данной миграции в специальной служебной таблице в базе данных.
В Django тоже есть аналогичная таблица, но этим дело не заканчивается. Во-первых, миграции разделены по "приложениями" (см. выше). В каждом приложении хранятся миграции (по конвенции), касающиеся моделей этого приложения. Вместо подразумеваемой цепочки зависимостей из Rails (где мы, фактически, считаем, что каждая миграция зависит от всех по времени более ранних), в Django в начале каждой миграции явно указывается, от каких предыдущих она зависит (они могут быть из других "приложений"). Получается сложный граф зависимостей.
Представим, что во время рефакторинга мы удалили некое "приложение" или два "приложения" объединили в одно. Что происходит с миграциями? Происходит, как можно догадаться, fuck up beyond all repair. Вам придётся либо оставить миграции в покое (удалив из устаревшего "приложения" все другие файлы), либо переписать все миграции, фактически, с нуля. Элегантному фреймворку – элегантные решения.
Далее важно понять, что в Django миграции это не простые прямолинейные команды для движка. Это декларация о том, что должно быть в базе данных. Когда мы пишем в миграции А "добавить столбец X, Y", а в миграции B (следующей по времени позже A) "добавить столбец Z, удалить столбец X", движок (во время исполнения миграций, когда он считывает все файлы) понимает: "ага, у нас в базе сейчас столбцы Y, Z" (важно отметить, что к базе данных при этом он подключается только для получения списка уже сделанных миграций – если вы там сами что-то наворотили отдельно, то всё сломается).
Django формирует, на основе виртуального суммирования всех миграций, некое своё (точное) представление о том, какая сейчас структура в БД (исходя из того, что она создавалась исключительно миграциями). Это называется State, "состояние".
Затем Django доходит до миграций, которые ещё не были выполнены, и выполняет соответствующие SQL-инструкции (database operations). Здесь операция вроде "добавить столбец M" выступает уже в двух ролях:
– во-первых, как database operation (аналогично Rails) – инструкции буквально выполнить
ALTER TABLE...
– во-вторых, как state operation – инструкции обновить "внутренний образ" того, какая у нас текущая структура базы данныхКак можно было предполагать, этот изящный подход к проблеме от, как складывается впечатление, какого-то победителя региональных олимпиад по computer science, в реальных приложениях работает отлично 80% времени. Оставшиеся 20% времени вам потребуется, вырывая волосы на голове, вгрызаться в (довольно сложный, но всё же за пару дней можно разобраться) DSL миграций и писать миграции типа SeparateDatabaseAndState (это когда вы буквально говорите Django, мол, я сам в базе произведу нужные операции, не надо "читать мысли", а потом отдельно ещё ему объясняете для этого "внутреннего образа схемы БД", что же вы сделали).
Тема миграций напрямую связана с темой моделей. Модели в Django требуют явного указания полей (похоже на gem DataMapper), в то время как в Rails поля подгружаются в рантайме из базы данных. Явное указание полей модели позволяет делать "автомиграции" – написать команду, которая (в соответствии с теми изменениями, что вы внесли в моделях, сравнивая их со State, который был вычислен из предыдущих миграций) сгенерирует миграцию, в которой удаляются (добавляются, изменяются) соответствующие поля. Это издевательски небольшая, но иррационально приятная компенсация за все прочие мучения.
#programming #django
Rails-разработчик, однажды наступив на грабли, знает, что в миграциях нельзя использовать код моделей. Модель может быть изменена или удалена, а миграция (в идеале) должна работать "с нуля" на свежей версии кода.
Django, будучи способным вычислить State, знает, какие поля у каких моделей в какой момент времени (на момент исполнения какой миграции) существовали. Поэтому внутри миграции вы, через специальный DSL, можете получить "призрак" класса своей модели на момент прохождения данной миграции: в ней будут все стандартные методы и ассоциации (но, конечно, все кастомные методы будут недоступны).
#programming #django
Django, будучи способным вычислить State, знает, какие поля у каких моделей в какой момент времени (на момент исполнения какой миграции) существовали. Поэтому внутри миграции вы, через специальный DSL, можете получить "призрак" класса своей модели на момент прохождения данной миграции: в ней будут все стандартные методы и ассоциации (но, конечно, все кастомные методы будут недоступны).
#programming #django
Нативная интеграция с самим собой
В пятницу планирую с 19:00 до 20:00 по Москве провести занятие "Лаборатории Metapractice" (онлайн).
Metapractice – opensource сообщество по психологическому моделированию человеческой активности.
Занятие будет посвящено "Авторефреймингу": установке в своё подсознание "резидентной программы" для решения (эмоциональных, психологических, поведенческих) проблем во сне. Звучит несколько претенциозно, я понимаю, но мы сейчас на переломе веков находимся: психологическая лексика и концепции устаревают, появляются удачные метафоры из области программирования (искусственные "нейросети" становятся, в чём-то парадоксально, метафорой для естественных), но технологии "нейропрограммирования" при этом тоже находятся в зачаточном состоянии.
Приходится использовать "инженерный" язык, несколько обгоняющий время, для описания моделей, которые являются закономерным развитием классиков психотехники.
Занятие будет в значительной мере тестовое (поэтому цена невысокая), с прицелом на серию повторных тематических встреч, если тема вызовет интерес. Потихоньку нащупаю манеру подачи и контент, вызывающий активный интерес трудящихся. Из-за неконвенциональности материала это займёт какое-то время, но эра "психологии в метафоре программирования" явно наступает. Надо хотя бы азы программирования человеческой активности освоить на примерах, чтобы рассуждения в mass media на эту тему и результаты очередных экспериментов с засовыванием головы живых существ в томограф понимались в правильном контексте.
Запись по ссылке:
https://metapractice.livejournal.com/600132.html
#psychology #courses
В пятницу планирую с 19:00 до 20:00 по Москве провести занятие "Лаборатории Metapractice" (онлайн).
Metapractice – opensource сообщество по психологическому моделированию человеческой активности.
Занятие будет посвящено "Авторефреймингу": установке в своё подсознание "резидентной программы" для решения (эмоциональных, психологических, поведенческих) проблем во сне. Звучит несколько претенциозно, я понимаю, но мы сейчас на переломе веков находимся: психологическая лексика и концепции устаревают, появляются удачные метафоры из области программирования (искусственные "нейросети" становятся, в чём-то парадоксально, метафорой для естественных), но технологии "нейропрограммирования" при этом тоже находятся в зачаточном состоянии.
Приходится использовать "инженерный" язык, несколько обгоняющий время, для описания моделей, которые являются закономерным развитием классиков психотехники.
Занятие будет в значительной мере тестовое (поэтому цена невысокая), с прицелом на серию повторных тематических встреч, если тема вызовет интерес. Потихоньку нащупаю манеру подачи и контент, вызывающий активный интерес трудящихся. Из-за неконвенциональности материала это займёт какое-то время, но эра "психологии в метафоре программирования" явно наступает. Надо хотя бы азы программирования человеческой активности освоить на примерах, чтобы рассуждения в mass media на эту тему и результаты очередных экспериментов с засовыванием головы живых существ в томограф понимались в правильном контексте.
Запись по ссылке:
https://metapractice.livejournal.com/600132.html
#psychology #courses
Livejournal
Лаборатория Metapractice (37) Говорит Москва: пробуем онлайн-формат через Zoom
https://metapractice.livejournal.com/551080.html Где и когда Пятница, 7.05.2021, 19:00-20:00 по Москве. Ссылка на встречу в Zoom придёт на ваш e-mail (после записи, перед занятием). UPD. Ссылка на встречу отправлена. Убедитесь, что получили. Формат и тема…
Пошли серьёзные разговоры об отмене ЕГЭ
Оставим в стороне гуманитарные предметы – всё же ни СССР, мягко говоря, первенством в гуманитарных науках не славился, ни Россия, по наследству. Гуманитарные науки у нас считаются вторичными ("гуманитарное образование – это отсутствие технического" и всё такое прочее). Важно понимать, что в цивилизованных странах Европы всё с точностью до наоборот: технически науки считаются вторичными по сравнению с гуманитарными. Образованный человек должен знать латынь, древнегреческий и классическую философию; прикасаться к техническим наукам это ниже достоинства и может быть оправдано только бизнесом на очень большие деньги (в США, кстати, другое отношение). Условный Ernst & Young в российских ВУЗах набирает аналитиков (в том числе) из изучающих профессионально физику. В Английских ВУЗах – из изучающих профессионально теологию. Не трудно догадаться, что английские теологи могут, в силу положения и имеющихся компетенций, командовать российскими физиками, но никак не наоборот.
Но до некоторого времени техническое образование в России было массовым и, в целом, неплохим. При сравнительно небольших усилиях (со стороны самого ученика или со стороны родителей) школьник из глубокой провинции мог поступить в пять ведущих ВУЗов одновременно и переехать в Москву. Не требовалось ни мотивирующего письма, ни собеседования, ни характеристики со школы, ни рекомендаций преподавателей, ни участия в кружках-секциях-конференциях, ни принадлежность к какому-нибудь меньшинству, ни несписываемого при личном банкротстве кредита размером в пару годовых зарплат специалиста высокого уровня. Соотношения лёгкости поступления и качества получаемого образования было беспрецедентно высоким.
Надо было всего лишь сдать один экзамен в конце обучения в школе (сдать у себя в городе, никуда не уезжая) при наличии развитой инфраструктуры подготовки к этому экзамену в любой форме (хоть просто на школьных занятиях, хоть с дополнительной литературой, хоть в кружках, хоть по ютюб-видео, хоть с репетитором).
Экзаменационные задачи были удачно подобраны и, в целом (с поправкой на грандиозный масштаб процесса) объективно проверялись. Получаемый балл беспристрастно позволял разделить школьников на страты: кого вообще нельзя допускать к любой серьёзной работе, кому в техникум, кому формальное высшее, кому полноценное (по крайней мере, если уклон школьника был техническим) образование.
Видимо, социальный лифт оказался неожиданно мощным и "брать скрипача, который лучше играет" (см. известный анекдот) больше неприемлемо.
Детей в любом случае жалко, но вот жалко ли родителей? Мне нет, хотя некую экзистенциальную (следовательно, отстранённую) печаль испытываю. Все эти годы раздавался голос как бы из народных масс: "ЕГЭ отупляет", "поколение ЕГЭ", "натаскивание на ЕГЭ"; разноголосый гул как бы пролетарской оппозиции. Гул голосов людей, которые даже в общих чертах не представляют саму СТРУКТУРУ, например, экзамена по математике, уж не говорю о том чтобы вчитаться в содержание. Скажем, в современном экзамене вообще нет задач типа "выберите верный ответ из предложенных вариантов" – как такой простой факт может быть малоизвестным, если экзамен проводится с миллионным размахом каждый год? А вот так.
Но ни одного объединения родителей (хотя, в отличие от многих других областей, школьное обучение ведь по естественным причинам "профсоюзоёмкое"), насколько я знаю, отчётливо не сказало "а мы ЗА ЕГЭ!".
Поэтому, не столько жалко этих родителей, сколько печально от той безнадёжной простоты, с которой людей убедили, что "понизить им градус" это им же на пользу. Да какой убедили, те сами просили все эти годы.
#education
Оставим в стороне гуманитарные предметы – всё же ни СССР, мягко говоря, первенством в гуманитарных науках не славился, ни Россия, по наследству. Гуманитарные науки у нас считаются вторичными ("гуманитарное образование – это отсутствие технического" и всё такое прочее). Важно понимать, что в цивилизованных странах Европы всё с точностью до наоборот: технически науки считаются вторичными по сравнению с гуманитарными. Образованный человек должен знать латынь, древнегреческий и классическую философию; прикасаться к техническим наукам это ниже достоинства и может быть оправдано только бизнесом на очень большие деньги (в США, кстати, другое отношение). Условный Ernst & Young в российских ВУЗах набирает аналитиков (в том числе) из изучающих профессионально физику. В Английских ВУЗах – из изучающих профессионально теологию. Не трудно догадаться, что английские теологи могут, в силу положения и имеющихся компетенций, командовать российскими физиками, но никак не наоборот.
Но до некоторого времени техническое образование в России было массовым и, в целом, неплохим. При сравнительно небольших усилиях (со стороны самого ученика или со стороны родителей) школьник из глубокой провинции мог поступить в пять ведущих ВУЗов одновременно и переехать в Москву. Не требовалось ни мотивирующего письма, ни собеседования, ни характеристики со школы, ни рекомендаций преподавателей, ни участия в кружках-секциях-конференциях, ни принадлежность к какому-нибудь меньшинству, ни несписываемого при личном банкротстве кредита размером в пару годовых зарплат специалиста высокого уровня. Соотношения лёгкости поступления и качества получаемого образования было беспрецедентно высоким.
Надо было всего лишь сдать один экзамен в конце обучения в школе (сдать у себя в городе, никуда не уезжая) при наличии развитой инфраструктуры подготовки к этому экзамену в любой форме (хоть просто на школьных занятиях, хоть с дополнительной литературой, хоть в кружках, хоть по ютюб-видео, хоть с репетитором).
Экзаменационные задачи были удачно подобраны и, в целом (с поправкой на грандиозный масштаб процесса) объективно проверялись. Получаемый балл беспристрастно позволял разделить школьников на страты: кого вообще нельзя допускать к любой серьёзной работе, кому в техникум, кому формальное высшее, кому полноценное (по крайней мере, если уклон школьника был техническим) образование.
Видимо, социальный лифт оказался неожиданно мощным и "брать скрипача, который лучше играет" (см. известный анекдот) больше неприемлемо.
Детей в любом случае жалко, но вот жалко ли родителей? Мне нет, хотя некую экзистенциальную (следовательно, отстранённую) печаль испытываю. Все эти годы раздавался голос как бы из народных масс: "ЕГЭ отупляет", "поколение ЕГЭ", "натаскивание на ЕГЭ"; разноголосый гул как бы пролетарской оппозиции. Гул голосов людей, которые даже в общих чертах не представляют саму СТРУКТУРУ, например, экзамена по математике, уж не говорю о том чтобы вчитаться в содержание. Скажем, в современном экзамене вообще нет задач типа "выберите верный ответ из предложенных вариантов" – как такой простой факт может быть малоизвестным, если экзамен проводится с миллионным размахом каждый год? А вот так.
Но ни одного объединения родителей (хотя, в отличие от многих других областей, школьное обучение ведь по естественным причинам "профсоюзоёмкое"), насколько я знаю, отчётливо не сказало "а мы ЗА ЕГЭ!".
Поэтому, не столько жалко этих родителей, сколько печально от той безнадёжной простоты, с которой людей убедили, что "понизить им градус" это им же на пользу. Да какой убедили, те сами просили все эти годы.
#education
Вкратце об инфляции
Традиционно: это не инвестиционная рекомендация.
1. Инфляция, очевидно, будет всё больше.
2. Также очевидно, всё больше будет зазор между "владельцами активов" и "потребителями активов". Государственная пропаганда по всему миру остроумно прикрывает этот неизбежный тренд рассуждениями о том, как круто будет жить в экономике будущего с общими самокатами, общими машинами, общими квартирами, и кушать насекомых.
3. "Акции технологических компаний" – это лотерея. Акция – это доля в бизнесе. Практически все "технологические гиганты" практически прямым текстом говорят, что мало того что плевать хотели на инвесторов, но их даже прибыль/прибыльность не интересует. "Не надо денег".
4. Акции компаний, занимающихся извлечением физических ресурсов (при их вдумчивом анализе, диверсификации и т.д.) – это очевидный контр-инфляционный ход. Акции производителей еды (владельцев сельхозземли, производителей оборудования, удобрений и т.д. и т.п.) – это супер-ход с поправкой на то, что цены на еду (в любом месте мира) могут начать директивно регулироваться, и тогда это станет не таким уж прикольным ходом.
5. IPO – это способ переложить деньги из своего кармана напрямую в карман брокера (см. комиссии).
6. Криптовалюта (ну конечно, у нас же как бы околоайтишный канал). Есть два мнения: первое, что это "виртуальные фантики", чисто спекулятивный актив (типа акций техногигантов, только ещё практически не регулируется, что открывает широкие просторы для повторения давно уже запрещённых рыночных манипуляций). Второе: что это базовая инфраструктура современного финтеха, обеспечивающая дешёвые трансграничные переводы и ликвидирующая риски контрагента (посредника, осуществляющая перевод). Дополню оригинальной мыслью: владение криптовалютой это ставка на антиутопический образ будущего без государств (административно, в стиле серии игр C&C), где иного инструмента "народной торговли" (торговли за пределом небольших центров порядка) быть просто не может. Другое дело, что кто сказал, что в таком мире станут использовать именно биткоин, да и вообще любую из существующих на данный момент "монет"?
7. Купить квартиру это хорошо. Но купить квартиру, в которой на самом деле хотелось бы жить (в цивилизованном районе не умирающего города, достаточной площади, подходящей планировки и т.д. и т.п.), это совсем другое дело. И третье дело – купить квартиру таким образом, чтобы остались деньги на "что-то ещё". Что-то ещё – грубо говоря, реальный бизнес либо дети (для всех по-своему, тут невольно проецирую типичную "мужскую точку зрения"). Вложи в достойную квартиру все деньги сейчас (или возьми ипотеку с платежом в размере всех свободных средств) и гарантированно не сможешь купить вторую через десять лет.
8. Опционы на физические ресурсы – это высокотехнологичный способ потерять все деньги на ставках на движение цены. Одновременно, это ограниченное во времени окно возможности вытянуть из "маркет-мейкеров" (продавцов опционов) с их анахроничной арифметикой расчёта "справедливой цены опциона" немного денег на покупку долгосрочных активов. То, что для них немного, для отдельного человека – более чем значительный прирост капитала.
P.S. Читатели просят конкретных рекомендаций. А глас народа, как известно, глас божий. Рекомендации такие:
1. Понять, что на тему денег любой другой человек (отличный от вас самих) может дать только такие конкретные рекомендации: "берите все деньги и несите мне". Если это настолько прямо не выражается, то с вами не до конца искренны.
2. Берите все деньги и несите мне: научу зарабатывать программированием и/или оптимизированному психологическому отношению к накоплениям и тратам.
3. Инвестиции - это сложно. Не ведитесь на хайп.
4. Отталкиваясь от пунктов изначального списка подберите источники информации, раскрывающие их подробней (пункты выбраны целенаправленно - источников, задающих подобный дискурс, не так уж много).
#investing
Традиционно: это не инвестиционная рекомендация.
1. Инфляция, очевидно, будет всё больше.
2. Также очевидно, всё больше будет зазор между "владельцами активов" и "потребителями активов". Государственная пропаганда по всему миру остроумно прикрывает этот неизбежный тренд рассуждениями о том, как круто будет жить в экономике будущего с общими самокатами, общими машинами, общими квартирами, и кушать насекомых.
3. "Акции технологических компаний" – это лотерея. Акция – это доля в бизнесе. Практически все "технологические гиганты" практически прямым текстом говорят, что мало того что плевать хотели на инвесторов, но их даже прибыль/прибыльность не интересует. "Не надо денег".
4. Акции компаний, занимающихся извлечением физических ресурсов (при их вдумчивом анализе, диверсификации и т.д.) – это очевидный контр-инфляционный ход. Акции производителей еды (владельцев сельхозземли, производителей оборудования, удобрений и т.д. и т.п.) – это супер-ход с поправкой на то, что цены на еду (в любом месте мира) могут начать директивно регулироваться, и тогда это станет не таким уж прикольным ходом.
5. IPO – это способ переложить деньги из своего кармана напрямую в карман брокера (см. комиссии).
6. Криптовалюта (ну конечно, у нас же как бы околоайтишный канал). Есть два мнения: первое, что это "виртуальные фантики", чисто спекулятивный актив (типа акций техногигантов, только ещё практически не регулируется, что открывает широкие просторы для повторения давно уже запрещённых рыночных манипуляций). Второе: что это базовая инфраструктура современного финтеха, обеспечивающая дешёвые трансграничные переводы и ликвидирующая риски контрагента (посредника, осуществляющая перевод). Дополню оригинальной мыслью: владение криптовалютой это ставка на антиутопический образ будущего без государств (административно, в стиле серии игр C&C), где иного инструмента "народной торговли" (торговли за пределом небольших центров порядка) быть просто не может. Другое дело, что кто сказал, что в таком мире станут использовать именно биткоин, да и вообще любую из существующих на данный момент "монет"?
7. Купить квартиру это хорошо. Но купить квартиру, в которой на самом деле хотелось бы жить (в цивилизованном районе не умирающего города, достаточной площади, подходящей планировки и т.д. и т.п.), это совсем другое дело. И третье дело – купить квартиру таким образом, чтобы остались деньги на "что-то ещё". Что-то ещё – грубо говоря, реальный бизнес либо дети (для всех по-своему, тут невольно проецирую типичную "мужскую точку зрения"). Вложи в достойную квартиру все деньги сейчас (или возьми ипотеку с платежом в размере всех свободных средств) и гарантированно не сможешь купить вторую через десять лет.
8. Опционы на физические ресурсы – это высокотехнологичный способ потерять все деньги на ставках на движение цены. Одновременно, это ограниченное во времени окно возможности вытянуть из "маркет-мейкеров" (продавцов опционов) с их анахроничной арифметикой расчёта "справедливой цены опциона" немного денег на покупку долгосрочных активов. То, что для них немного, для отдельного человека – более чем значительный прирост капитала.
P.S. Читатели просят конкретных рекомендаций. А глас народа, как известно, глас божий. Рекомендации такие:
1. Понять, что на тему денег любой другой человек (отличный от вас самих) может дать только такие конкретные рекомендации: "берите все деньги и несите мне". Если это настолько прямо не выражается, то с вами не до конца искренны.
2. Берите все деньги и несите мне: научу зарабатывать программированием и/или оптимизированному психологическому отношению к накоплениям и тратам.
3. Инвестиции - это сложно. Не ведитесь на хайп.
4. Отталкиваясь от пунктов изначального списка подберите источники информации, раскрывающие их подробней (пункты выбраны целенаправленно - источников, задающих подобный дискурс, не так уж много).
#investing
Вкратце о том, какой редактор для программирования лучше
Вышла четвёртая версия известного редактора кода Sublime Text. За новую версию просят ещё $70 (при условии, что куплена предыдущая за $75).
Это в очередной раз заставляет сообщество встрепенуться и обсудить важнейший вопрос программирования: в чём писать код?
Конечно, это вопрос из серии "кому суп жидкий, кому жемчуг мелкий". Например, удачную версию XCode (IDE для iOS/macOS) отличает от неудачной то, что в первом случае средний балл в AppStore 2.5, а во втором 0.5 (из пяти). Однако деваться некуда, поэтому и мыслей лишних в голове не появляется.
Разработчики же Sublime, по-моему, поняли, что на фоне бесплатных и open source аналогов терять уже нечего, и надо успеть вытянуть последние деньги из ностальгирующей клиентуры. Рост среднего количества ядер на машине типового программиста позволила проклятому Electron-у (браузерному движку, в котором запускаются настольные приложения на JavaScript) ликвидировать разрыв в производительности, который ещё лет пять назад был критически большим. Открываются папки проектов в том же VSCode всё ещё с заметной невооружённым глазом пробуксовкой, но вот набор текста, поиск, GoTo File и всё такое работают не медленней, чем в "нативном" текстовом редакторе.
Для "взрослого" (в плане профессионального опыта, а не биологического возраста) разработчика вопрос выбора редактора решается автоматически и машинально. Обсуждать его во время перекура или переписки ни о чём в пабликах, конечно, занятно, но никакого интереса (после интенсивной начальной настройки) тема не вызывает.
Если "старший" коллега всерьёз, с нажимом, на собеседовании или во время вхождения в проект, интересуется вашим редактором и причинами его выбора, то это либо признак достигнутого уровня доверительности общения (из серии – "а куда вы ездите отдыхать летом?" – можно и к такому вопросу за уши притянуть оценку человека как специалиста), либо грубое нарушение негласного этикета, либо проявление наивности и глубокого непонимания вопроса "откуда берутсядети программы".
Уж точно они берутся не из текстового редактора.
Поэтому ответ на вопрос в чём писать код, в стиле предыдущей горькой иронии, конечно, понятный: да ни в чём не пишите. И без вас напишут.
Обсуждать выбор редактора кода это как обсуждать выбор, скажем, термобелья для повседневной жизни: один раз поинтересоваться вопросом, конечно, можно, но вообще-то в интернете уже на эту тему всё написано. И конечный выбор всё равно оправдан только личным опытом, а непрошенные оценки со стороны – это что-то странненькое.
Если человек в начале двухтысячных нашёл себе консольную поделку (хорошо, если со встроенной поддержкой юникода – бывает и без), в которой следующие двадцать лет писал самые радостные в своей жизни программы, то не грех иногда и послушать его сантименты. Дедушек надо уважать. Другой расклад, если он начинает бегать с горящими глазами, ругаться, бить по рукам и требовать всех примерить и начать носить его секондхенд. Тут уже сложно удержаться от мысли, что человек-то маленько ку-ку.
#programming
Вышла четвёртая версия известного редактора кода Sublime Text. За новую версию просят ещё $70 (при условии, что куплена предыдущая за $75).
Это в очередной раз заставляет сообщество встрепенуться и обсудить важнейший вопрос программирования: в чём писать код?
Конечно, это вопрос из серии "кому суп жидкий, кому жемчуг мелкий". Например, удачную версию XCode (IDE для iOS/macOS) отличает от неудачной то, что в первом случае средний балл в AppStore 2.5, а во втором 0.5 (из пяти). Однако деваться некуда, поэтому и мыслей лишних в голове не появляется.
Разработчики же Sublime, по-моему, поняли, что на фоне бесплатных и open source аналогов терять уже нечего, и надо успеть вытянуть последние деньги из ностальгирующей клиентуры. Рост среднего количества ядер на машине типового программиста позволила проклятому Electron-у (браузерному движку, в котором запускаются настольные приложения на JavaScript) ликвидировать разрыв в производительности, который ещё лет пять назад был критически большим. Открываются папки проектов в том же VSCode всё ещё с заметной невооружённым глазом пробуксовкой, но вот набор текста, поиск, GoTo File и всё такое работают не медленней, чем в "нативном" текстовом редакторе.
Для "взрослого" (в плане профессионального опыта, а не биологического возраста) разработчика вопрос выбора редактора решается автоматически и машинально. Обсуждать его во время перекура или переписки ни о чём в пабликах, конечно, занятно, но никакого интереса (после интенсивной начальной настройки) тема не вызывает.
Если "старший" коллега всерьёз, с нажимом, на собеседовании или во время вхождения в проект, интересуется вашим редактором и причинами его выбора, то это либо признак достигнутого уровня доверительности общения (из серии – "а куда вы ездите отдыхать летом?" – можно и к такому вопросу за уши притянуть оценку человека как специалиста), либо грубое нарушение негласного этикета, либо проявление наивности и глубокого непонимания вопроса "откуда берутся
Уж точно они берутся не из текстового редактора.
Поэтому ответ на вопрос в чём писать код, в стиле предыдущей горькой иронии, конечно, понятный: да ни в чём не пишите. И без вас напишут.
Обсуждать выбор редактора кода это как обсуждать выбор, скажем, термобелья для повседневной жизни: один раз поинтересоваться вопросом, конечно, можно, но вообще-то в интернете уже на эту тему всё написано. И конечный выбор всё равно оправдан только личным опытом, а непрошенные оценки со стороны – это что-то странненькое.
Если человек в начале двухтысячных нашёл себе консольную поделку (хорошо, если со встроенной поддержкой юникода – бывает и без), в которой следующие двадцать лет писал самые радостные в своей жизни программы, то не грех иногда и послушать его сантименты. Дедушек надо уважать. Другой расклад, если он начинает бегать с горящими глазами, ругаться, бить по рукам и требовать всех примерить и начать носить его секондхенд. Тут уже сложно удержаться от мысли, что человек-то маленько ку-ку.
#programming
Telegram
Metaprogramming
Почему НЕ надо становиться программистом. Из каждого утюга пишут про то, как классно быть программистом (автор - конечно, один из таких "утюгов"), для разнообразия напишем, почему (новичку) не надо становиться программистом:
1. Недостаток программистов …
1. Недостаток программистов …
Вкратце об удалённой работе
Во время спада предыдущей и наплыва последующей очередной волны карантина актуализируется, в который раз, тема удалённой работы. Не удобней ли будет вернуться в офис (если разрешат)? Не проще ли там контролировать сотрудников? Не способствует ли "рабочая обстановка" "рабочей продуктивности"? А может закрыть их навсегда, вроде бы и так справляемся?
На самом деле, никакой удалённой работы не существует. Да и вообще "работа" – это анахроничный артефакт индустриальной эпохи: эпохи больших заводов, строгого распорядка дня, смен, конвейеров, профсоюзов, мастеров и т.д. В современном мире концепция "работы" едва ли имеет больше смысла, чем, например, концепция "пролетариата" (спойлер: такого класса тоже нет в современном обществе).
Несколько столетий и много поколений подряд над большим количеством людей по ряду причин издевались, вынуждая подстраивать естественные ритмы жизни под несовершенную технику и примитивную организацию труда. Конечно, мы всё же в лучшем случае только одной ногой в двадцать первом веке, так что и сейчас внешние ограничения актуальны для существенного количества людей: многие профессии по-прежнему требуют производственного распорядка.
Однако поговорим про программистов. У программистов синдром человека, вышедшего из тюрьмы: свобода есть, а что делать с ней не понятно. Слишком много простора для манёвра и не говорят каждую минуту, чем заниматься (или не заниматься). Чуть ли не хочется обратно в ставшей привычной камеру – ну хорошо, пусть более комфортную, конечно, но будьте добры столь же понятную.
Вот есть целый день свободный, а что делать-то? А что хочется, то и делай. И человек начинает метаться, а то и буквально сходить с ума. Не является таким уж большим секретом тот факт, что 4 часа продуктивного "кодинга" в день для программиста это норма (это для довольно продуктивного программиста). Ну пусть 6 часов в режиме "поднапрячься". Отсюда не трудно прикинуть, что 4 фактических часа работы в офисе – это 12 часов потраченной жизни (4 поработать, 4 почитать про политику на айтишных сайтах, 1 час обед, 3 часа дорога в две стороны). А 4 часа дома – это 4 часа дома.
И вот имея в виду эту разницу в 8 часов каждый день никакие "отвлекают домашние дела", "не могу сосредоточиться", "выгораю через два месяца", "даже кушаю за рабочим столом", "мало общаюсь с людьми" не звучат убедительно. Но все эти оправдания ведь не придуманы, их всерьёз называют.
Или, пуще того: говорят, мол, "не чувствую себя программистом". А мне вот интересно, что такое "чувствовать себя программистом"? Я больше 20 лет увлечённо занимаюсь программированием, но могу лишь догадаться или вычислить, что это за чувство такое, но не могу, буквально, проявить сочувствия. Я охотно называю сам себя программистом – однако это либо понятный ярлык для дистанцированного профессионального общения (такая краткая спецификация публичного API для взаимодействия), либо попросту тонкое издевательство (сорт иронии или самоиронии). Запрети мне эту идентификацию (пусть не только на словах, но даже в мыслях) – прикроюсь другой. Запрети вторую, найду третью. Отбери все – останется что-то на уровне "я есть тот, кто делает это и то, и сё, и это круто". Только облегчение почувствую от того, что не надо играть роли.
Жизнь "удалёнщика" – это и есть реальная жизнь. Не биполярная беготня между ненавистной работой и насыщенным по интенсивности, но примитивным по содержанию отпуском (в который надо "всё успеть"), а острое (временами, без сомнения, неприятное) осознание всего происходящего, от которого невозможно скрыться и сбежать, дождавшись "конца рабочего дня" (или, наоборот, его начала), "выходных" (или, наоборот, понедельника), "отпуска" (выхода на работу).
"Удалёнщик" это свободный человек и хозяин (своей) жизни. Свободный человек никуда не торопится, но всегда и всюду вовремя. Он профессионал своего дела, но он не определяется своей профессией. Он никогда не работает и у него никогда не бывает отпуска.
#psychology #programming
Во время спада предыдущей и наплыва последующей очередной волны карантина актуализируется, в который раз, тема удалённой работы. Не удобней ли будет вернуться в офис (если разрешат)? Не проще ли там контролировать сотрудников? Не способствует ли "рабочая обстановка" "рабочей продуктивности"? А может закрыть их навсегда, вроде бы и так справляемся?
На самом деле, никакой удалённой работы не существует. Да и вообще "работа" – это анахроничный артефакт индустриальной эпохи: эпохи больших заводов, строгого распорядка дня, смен, конвейеров, профсоюзов, мастеров и т.д. В современном мире концепция "работы" едва ли имеет больше смысла, чем, например, концепция "пролетариата" (спойлер: такого класса тоже нет в современном обществе).
Несколько столетий и много поколений подряд над большим количеством людей по ряду причин издевались, вынуждая подстраивать естественные ритмы жизни под несовершенную технику и примитивную организацию труда. Конечно, мы всё же в лучшем случае только одной ногой в двадцать первом веке, так что и сейчас внешние ограничения актуальны для существенного количества людей: многие профессии по-прежнему требуют производственного распорядка.
Однако поговорим про программистов. У программистов синдром человека, вышедшего из тюрьмы: свобода есть, а что делать с ней не понятно. Слишком много простора для манёвра и не говорят каждую минуту, чем заниматься (или не заниматься). Чуть ли не хочется обратно в ставшей привычной камеру – ну хорошо, пусть более комфортную, конечно, но будьте добры столь же понятную.
Вот есть целый день свободный, а что делать-то? А что хочется, то и делай. И человек начинает метаться, а то и буквально сходить с ума. Не является таким уж большим секретом тот факт, что 4 часа продуктивного "кодинга" в день для программиста это норма (это для довольно продуктивного программиста). Ну пусть 6 часов в режиме "поднапрячься". Отсюда не трудно прикинуть, что 4 фактических часа работы в офисе – это 12 часов потраченной жизни (4 поработать, 4 почитать про политику на айтишных сайтах, 1 час обед, 3 часа дорога в две стороны). А 4 часа дома – это 4 часа дома.
И вот имея в виду эту разницу в 8 часов каждый день никакие "отвлекают домашние дела", "не могу сосредоточиться", "выгораю через два месяца", "даже кушаю за рабочим столом", "мало общаюсь с людьми" не звучат убедительно. Но все эти оправдания ведь не придуманы, их всерьёз называют.
Или, пуще того: говорят, мол, "не чувствую себя программистом". А мне вот интересно, что такое "чувствовать себя программистом"? Я больше 20 лет увлечённо занимаюсь программированием, но могу лишь догадаться или вычислить, что это за чувство такое, но не могу, буквально, проявить сочувствия. Я охотно называю сам себя программистом – однако это либо понятный ярлык для дистанцированного профессионального общения (такая краткая спецификация публичного API для взаимодействия), либо попросту тонкое издевательство (сорт иронии или самоиронии). Запрети мне эту идентификацию (пусть не только на словах, но даже в мыслях) – прикроюсь другой. Запрети вторую, найду третью. Отбери все – останется что-то на уровне "я есть тот, кто делает это и то, и сё, и это круто". Только облегчение почувствую от того, что не надо играть роли.
Жизнь "удалёнщика" – это и есть реальная жизнь. Не биполярная беготня между ненавистной работой и насыщенным по интенсивности, но примитивным по содержанию отпуском (в который надо "всё успеть"), а острое (временами, без сомнения, неприятное) осознание всего происходящего, от которого невозможно скрыться и сбежать, дождавшись "конца рабочего дня" (или, наоборот, его начала), "выходных" (или, наоборот, понедельника), "отпуска" (выхода на работу).
"Удалёнщик" это свободный человек и хозяин (своей) жизни. Свободный человек никуда не торопится, но всегда и всюду вовремя. Он профессионал своего дела, но он не определяется своей профессией. Он никогда не работает и у него никогда не бывает отпуска.
#psychology #programming
Продолжаем цикл "Django глазами Rails-разработчика" (1/3)
Скопилось некоторое количество заметок для себя, которые, как мне кажется, могут быть полезны любому Rails-разработчику, начавшему использовать Django (или наоборот, хоть и в меньшей мере). Не смотря на то, что заметки по понятной причине (поводом для их создания служило, в первую очередь, раздражение от необходимости в очередной раз бороться с фреймворком на ровном месте) сфокусированы на каких-то "острых углах", в целом впечатление довольно ровное и, местами, даже положительное (позитив будет в конце).
Поехали: на что надо обращать внимание Rails-pазработчику в отношении Django, чтобы избежать когнитивного диссонанса и сэкономить время.
1. В Django нет единого кодстайла. Переходя с Rails, где формат названия классов (и файлов, в которых лежат классы), методов, модулей, путей и т.д. строго формализован, и ожидая от фреймворка разрекламированно элегантного языка подобного, рискуешь получить когнитивный диссонанс. В разных популярных библиотеках название метода может быть
2. Примеры кода из документации могут просто не работать в окружении той же версии, для которой написана документация. Часто "есть нюанс", который описан где-то на соседних страницах.
3. Всё может падать без поднятия исключений. Например, сломаться какая-то функция в шаблоне или логгирование – узнать об этом можно только по отсутствию эффекта, сообщения об ошибке может не быть.
4. Пожалуй, худший язык шаблонов из всех существующих. В целом эзотерический синтаксис вызова "хелпер"-функций (которые, создавая дополнительную сложность, разделяют на "фильтры" и "теги") усложняется отсутствием элементарной функциональности: невозможно взять элемент из хеша (по ключу, хранящемуся в переменной), невозможно вызвать метод прокинутого в шаблон объекта (хотя можно взять значение любого атрибута), нельзя сделать присвоение переменной (например, для конкатенации двух строк), и т.д. Хотелось бы оправдать такую ограниченость шаблонов соображениями безопасности (например, liquid-шаблоны известного e-commerce сервиса Shopify, используемые для кастомизации вида пользовательских витрин/магазинов, используют похожий синтаксис, не позволяя при этом писателю шаблона "вылезти из песочницы"), но это будет большой натяжкой: всё равно можно залезть куда угодно через переданные объекты, пользовательский код шаблонов исполнять нельзя.
5. Для нормальной отладки надо использовать сторонние решения (например, debug toolbar). Например, вы иначе не сможете посмотреть код SQL-запросов – в логах их отображение прямолинейным путём не получиться добиться. Впрочем, типовые сторонние решения удобные и достойные, сглаживающие этот недостаток фреймворка.
6. Кстати, про SQL-запросы: в Django нет SQL-кеша. Достали из базы модель по одному и тому же primary key десять раз – получите десять запросов в базу.
7. Открытые (и актуальные) баги десятилетней давности во фреймворке и брошенные мейнстримные пакеты – это норма.
8. Обновление на одну минорную версию какого-то там пакета, который являлся зависимостью какого-то там ещё пакета, который является зависимостью пакета, который вы используете, которое всё сломало – запросто. См. предыдущие посты по тегу про отсутствие встроенного менеджера пакетов (с той функциональностью, которая есть во всех других современных языках – например, lock-файлом) и необходимость использовать сторонние решения.
9. Кстати, про пакеты. В мире Rails для каждой распространённой задачи (как правило) есть гем, являющийся явным "гегемоном". В Django (как правило) существует два и более способа что-то сделать (поддерживаемых pypi пакета), причём оба плохи.
#programming #django #rails
Скопилось некоторое количество заметок для себя, которые, как мне кажется, могут быть полезны любому Rails-разработчику, начавшему использовать Django (или наоборот, хоть и в меньшей мере). Не смотря на то, что заметки по понятной причине (поводом для их создания служило, в первую очередь, раздражение от необходимости в очередной раз бороться с фреймворком на ровном месте) сфокусированы на каких-то "острых углах", в целом впечатление довольно ровное и, местами, даже положительное (позитив будет в конце).
Поехали: на что надо обращать внимание Rails-pазработчику в отношении Django, чтобы избежать когнитивного диссонанса и сэкономить время.
1. В Django нет единого кодстайла. Переходя с Rails, где формат названия классов (и файлов, в которых лежат классы), методов, модулей, путей и т.д. строго формализован, и ожидая от фреймворка разрекламированно элегантного языка подобного, рискуешь получить когнитивный диссонанс. В разных популярных библиотеках название метода может быть
setup, set_up, setUp: это норма.2. Примеры кода из документации могут просто не работать в окружении той же версии, для которой написана документация. Часто "есть нюанс", который описан где-то на соседних страницах.
3. Всё может падать без поднятия исключений. Например, сломаться какая-то функция в шаблоне или логгирование – узнать об этом можно только по отсутствию эффекта, сообщения об ошибке может не быть.
4. Пожалуй, худший язык шаблонов из всех существующих. В целом эзотерический синтаксис вызова "хелпер"-функций (которые, создавая дополнительную сложность, разделяют на "фильтры" и "теги") усложняется отсутствием элементарной функциональности: невозможно взять элемент из хеша (по ключу, хранящемуся в переменной), невозможно вызвать метод прокинутого в шаблон объекта (хотя можно взять значение любого атрибута), нельзя сделать присвоение переменной (например, для конкатенации двух строк), и т.д. Хотелось бы оправдать такую ограниченость шаблонов соображениями безопасности (например, liquid-шаблоны известного e-commerce сервиса Shopify, используемые для кастомизации вида пользовательских витрин/магазинов, используют похожий синтаксис, не позволяя при этом писателю шаблона "вылезти из песочницы"), но это будет большой натяжкой: всё равно можно залезть куда угодно через переданные объекты, пользовательский код шаблонов исполнять нельзя.
5. Для нормальной отладки надо использовать сторонние решения (например, debug toolbar). Например, вы иначе не сможете посмотреть код SQL-запросов – в логах их отображение прямолинейным путём не получиться добиться. Впрочем, типовые сторонние решения удобные и достойные, сглаживающие этот недостаток фреймворка.
6. Кстати, про SQL-запросы: в Django нет SQL-кеша. Достали из базы модель по одному и тому же primary key десять раз – получите десять запросов в базу.
7. Открытые (и актуальные) баги десятилетней давности во фреймворке и брошенные мейнстримные пакеты – это норма.
8. Обновление на одну минорную версию какого-то там пакета, который являлся зависимостью какого-то там ещё пакета, который является зависимостью пакета, который вы используете, которое всё сломало – запросто. См. предыдущие посты по тегу про отсутствие встроенного менеджера пакетов (с той функциональностью, которая есть во всех других современных языках – например, lock-файлом) и необходимость использовать сторонние решения.
9. Кстати, про пакеты. В мире Rails для каждой распространённой задачи (как правило) есть гем, являющийся явным "гегемоном". В Django (как правило) существует два и более способа что-то сделать (поддерживаемых pypi пакета), причём оба плохи.
#programming #django #rails
Продолжаем цикл "Django глазами Rails-разработчика" (2/3)
В продолжение предыдущего поста:
10. И в целом, в Python/Django, в отличие от Ruby/Rails, регулярно встречаются ситуации, когда есть два (три, четыре...) способа сделать элементарную вещь, причём все плохие. Например, в Python нет нормальной интерполяции строк (и в Django аналогично с интерполяцией фрагментов HTML). Зато есть три (или четыре?) плохих способа. В Python нет нормального способа проверить существование файла – опять, вместо этого предлагают три-четыре костыля. Нет нормального фреймворка для тестирования (справедливости ради, здесь всё же есть мейнстримный pytest, т.е. только одно плохое решение, а не несколько, что хотя бы избавляет от мук выбора). И т.д.
11. В Django работа с почтой реализована на уровне Rails 2.x (то есть примерно 2007 года).
12. В Django ужасно некрасивый по форме и кривой по функциональности ORM. В Rails в целом понимают, что ORM нужен для пяти операций, которые покрывают 90% функциональности. В Django прямо заявляют, что ORM должен покрывать 100% кейсов, а про SQL забудьте, это другой уровень абстракции. Поэтому то, что в Rails решается вставкой SQL-кода из пяти ключевых слов в одну функцию внутри scope-а (метода класса; в Django аналогом будет метод "менеджера"), в Django превращается в попытку описать ограниченными и криво работающими примитивами Django-классов то, чего вы хотите получить, но сильно обходным путём (по сути такое описание AST-дерева SQL инструкции через сборку Django-классов, определяющих узлы этого дерева). Подобный идиотизм был и в Phoenix-е (фреймворке на Elixir-е), но там всё же мучения были, по воспоминаниям, гораздо меньше из-за того, что функциональный язык для таких штук прямо приспособлен.
13. Кстати, про ORM. В Django крайне затруднительно создать работающее виртуальное (computed, не существующее в базе данных) поле. В Rails с этим никаких проблем: определяем атрибут в модели, просто как в обычном Ruby-классе, и в формах всё работает. Впрочем, см. п.5 в следующем посте.
#programming #django #rails
В продолжение предыдущего поста:
10. И в целом, в Python/Django, в отличие от Ruby/Rails, регулярно встречаются ситуации, когда есть два (три, четыре...) способа сделать элементарную вещь, причём все плохие. Например, в Python нет нормальной интерполяции строк (и в Django аналогично с интерполяцией фрагментов HTML). Зато есть три (или четыре?) плохих способа. В Python нет нормального способа проверить существование файла – опять, вместо этого предлагают три-четыре костыля. Нет нормального фреймворка для тестирования (справедливости ради, здесь всё же есть мейнстримный pytest, т.е. только одно плохое решение, а не несколько, что хотя бы избавляет от мук выбора). И т.д.
11. В Django работа с почтой реализована на уровне Rails 2.x (то есть примерно 2007 года).
12. В Django ужасно некрасивый по форме и кривой по функциональности ORM. В Rails в целом понимают, что ORM нужен для пяти операций, которые покрывают 90% функциональности. В Django прямо заявляют, что ORM должен покрывать 100% кейсов, а про SQL забудьте, это другой уровень абстракции. Поэтому то, что в Rails решается вставкой SQL-кода из пяти ключевых слов в одну функцию внутри scope-а (метода класса; в Django аналогом будет метод "менеджера"), в Django превращается в попытку описать ограниченными и криво работающими примитивами Django-классов то, чего вы хотите получить, но сильно обходным путём (по сути такое описание AST-дерева SQL инструкции через сборку Django-классов, определяющих узлы этого дерева). Подобный идиотизм был и в Phoenix-е (фреймворке на Elixir-е), но там всё же мучения были, по воспоминаниям, гораздо меньше из-за того, что функциональный язык для таких штук прямо приспособлен.
13. Кстати, про ORM. В Django крайне затруднительно создать работающее виртуальное (computed, не существующее в базе данных) поле. В Rails с этим никаких проблем: определяем атрибут в модели, просто как в обычном Ruby-классе, и в формах всё работает. Впрочем, см. п.5 в следующем посте.
#programming #django #rails
Продолжаем цикл "Django глазами Rails-разработчика" (3/3)
В завершении цикла обещанный позитив:
1. В шаблонах Django используется интересный и, в целом, функциональный механизм наследования. Он более последовательный и логичный чем система layouts и partials из Rails. В Django любую вьюху можно отнаследовать от любой другой (например, зашитой в сторонний пакет или встроенную админку), а затем точно также отнаследовать ещё одну и т.д. Родительская вьюха через инструкцию block (аналог content_for из Rails) обозначает места, куда дочерняя может (через ту же инструкцию) вставить контент (заменив или дополнив тот, что туда прописала одна из родительских вьюх). Вещи типа двух (трёх, четырёх...) лэйаутов для одной вьюхи реализую логично и прямолинейно, в отличие от Rails, где это делается с помощью хитрых манёвров и велосипедостроения.
2. В Django встроенная админка с довольно неплохой функциональностью. В целом она вызывает смешаные чувства восхищения и раздражения. Первое – когда делаешь нечто стандартное, а второе – когда пытаешься дописать свою функциональность (пусть создатели фреймворка и не сделали этот процесс очень удобным или элегантным, но явно предусмотрели все необходимые "точки расширения"). Увы, я не пользовался active-admin или аналогичными гемами, поэтому не могу сравнить с прямыми аналогами из мира Rails: наверное, там примерно такое же впечатление осталось бы.
3. До какого-то времени в Python не было оператора case. "Используйте if или хеши (dict-ы)". В последнюю версию добавили pattern matching, который, на первый и беглый взгляд, производит впечатление менее небрежной работы, чем аналог из последних версий Ruby (на практике в обоих языках использовал эту фичу, пока что, весьма мало для вердикта).
4. В Django встроено управление пользователями. Создавая новый проект, не надо с нуля создавать модель пользователя, функциональность управления паролями, расписывать логику токенов подтверждения почты и вот это всё. На мой взгляд, это удобней использования рубишного гема devise (который, зачастую, добавляет уже слишком много всего).
5. В Django есть встроенная абстракция "форм" (form objects). Промежуточный слой между моделями (прибиты гвоздями к базе данных) и интерфейсом пользователя (который вовсе не обязан вводить данные в том формате, который используется у вас в БД) это очевидная необходимость, и в Rails не является частью фреймворка только из-за специфических анахроничных взглядов DHH на архитектуру типового веб-приложения. (Частично компенсируется наличием сторонних gem-ов.)
#programming #django #rails
В завершении цикла обещанный позитив:
1. В шаблонах Django используется интересный и, в целом, функциональный механизм наследования. Он более последовательный и логичный чем система layouts и partials из Rails. В Django любую вьюху можно отнаследовать от любой другой (например, зашитой в сторонний пакет или встроенную админку), а затем точно также отнаследовать ещё одну и т.д. Родительская вьюха через инструкцию block (аналог content_for из Rails) обозначает места, куда дочерняя может (через ту же инструкцию) вставить контент (заменив или дополнив тот, что туда прописала одна из родительских вьюх). Вещи типа двух (трёх, четырёх...) лэйаутов для одной вьюхи реализую логично и прямолинейно, в отличие от Rails, где это делается с помощью хитрых манёвров и велосипедостроения.
2. В Django встроенная админка с довольно неплохой функциональностью. В целом она вызывает смешаные чувства восхищения и раздражения. Первое – когда делаешь нечто стандартное, а второе – когда пытаешься дописать свою функциональность (пусть создатели фреймворка и не сделали этот процесс очень удобным или элегантным, но явно предусмотрели все необходимые "точки расширения"). Увы, я не пользовался active-admin или аналогичными гемами, поэтому не могу сравнить с прямыми аналогами из мира Rails: наверное, там примерно такое же впечатление осталось бы.
3. До какого-то времени в Python не было оператора case. "Используйте if или хеши (dict-ы)". В последнюю версию добавили pattern matching, который, на первый и беглый взгляд, производит впечатление менее небрежной работы, чем аналог из последних версий Ruby (на практике в обоих языках использовал эту фичу, пока что, весьма мало для вердикта).
4. В Django встроено управление пользователями. Создавая новый проект, не надо с нуля создавать модель пользователя, функциональность управления паролями, расписывать логику токенов подтверждения почты и вот это всё. На мой взгляд, это удобней использования рубишного гема devise (который, зачастую, добавляет уже слишком много всего).
5. В Django есть встроенная абстракция "форм" (form objects). Промежуточный слой между моделями (прибиты гвоздями к базе данных) и интерфейсом пользователя (который вовсе не обязан вводить данные в том формате, который используется у вас в БД) это очевидная необходимость, и в Rails не является частью фреймворка только из-за специфических анахроничных взглядов DHH на архитектуру типового веб-приложения. (Частично компенсируется наличием сторонних gem-ов.)
#programming #django #rails
Вкратце про цветовую дифференциацию штанов организаций
Периодически то там, то здесь в самопрезентации организаций (например, статьях на пресловутом "хабре") или рекламе (например, тексте вакансий) присутствуют слова типа "бирюзовая компания" и т.п.
Речь в таких случаях идёт о так называемой "Спиральной динамике" (Бек-Кован-Уилбер), популярном философском(?) учении, развитом из эссе Клара Грейвза "Теория уровней человеческого существования" (и дальнейших работах).
Цветовые маркеры оказались удачными "мемами", в отличие от тяжёлых и труднозапоминаемых буквенных мнемоник Грейвза, да и в целом учение о том, "куда нам всем дальше развиваться", в стиле похожем на Марксизм как бы отстранённо объясняющее как бы объективные тренды, но при этом и вроде как направляющее общественные стремления, оказалось как всегда востребованным, и теория (философия?) пошла в массы.
Обширные описания каждого из "цветных уровней"... Кстати, уровней чего? Говорится, уровней развития индивидуального сознания – хотя как бы это и не уровни, а просто категории, и нельзя сказать, что человек на предыдущей ступени в чём-то уступает человеку на последующей – но зачем-то же их выстроили в пирамидку?.. Но одновременно и как бы уровня общественных отношений, свойственных людям соответствующего сознания...
Так вот, обширные описания можно почитать в вики. Можно от них отмахнуться, но ради спортивного интереса можно всё же внимательно выслушать евангелистов популярной (в определённых кругах) философии (теории?), провести интенсивный "терраморфинг" предлагаемого фреймворка, населив скучные остовы более-менее очерченными феноменами и сделать краткую выжимку сути.
Выжимка по ключевым феноменам каждого из уровней будет примерно такая (нещадно сокращаю пост):
1. Бежевый уровень: нехватка физических ресурсов или, метафорически, производных ресурсов в роли как бы физических ресурсов. "Чёрная дыра" (как у того мужика из "Автострады-60") на месте определённых потребностей (как буквально пищи, так и, например, перманентная жажда денег и т.п.).
2. Фиолетовый: взаимодействие с "мистическими силами".
3. Красный: борьба по правилам за власть.
4. Синий: участие в бюрократических структурах и системах, нижестоящего ругай, перед вышестоящим заискивай.
5. Оранжевый: доминант рационального (в широком смысле научного) познания.
6. Зелёный: отождествление (с другим человеком, обществом в целом, "природой" и т.п.).
7. Жёлтый:клиповое фрагментарно-системно-калейдоскопическое мышление, поведение и т.д.
8. Бирюзовый: дезактивация "эго" как такового, полная идентификация с "духом" (whatever it means), распространение соответствующего знания, отношений и т.п.
Отсюда хорошо понятно, что нормальная коммерческая компания действует (в нормальном "правовом поле") на красном (и немного синем) уровне. Бизнес – это война, но, в идеале, война по правилам.
В то же время, организация, которая называет себя бирюзовой (по смыслу это просто hillarious – уморительно смешно – что-то вроде: мы зарабатываем деньги, но делаем это ради развития души), стремясь рефлекторно занять (сделать claim) вершину любой обнаруженной пирамидки, действует как бежевая: вместо борьбы "по правилами" (или хотя бы "по понятиям") она по беспределу пытается влезть с известно каким лицом в известно какой ряд. Тем самым показывая компульсивную потребность (т.е. зависимость) добиваться чего-то вроде "превосходства" – а, как уже было сказано выше, все такой интенсивности/выраженности компульсии (аддикции) – это бежевый уровень.
Зачем во всём этом разбираться? Ну, аллегорически выражаясь, если живёшь среди православных христиан, наверное, имеет смысл прочитать Библию и попробовать резюмировать для себя какие-то полезные мысли и идеи.
#psychology
Периодически то там, то здесь в самопрезентации организаций (например, статьях на пресловутом "хабре") или рекламе (например, тексте вакансий) присутствуют слова типа "бирюзовая компания" и т.п.
Речь в таких случаях идёт о так называемой "Спиральной динамике" (Бек-Кован-Уилбер), популярном философском(?) учении, развитом из эссе Клара Грейвза "Теория уровней человеческого существования" (и дальнейших работах).
Цветовые маркеры оказались удачными "мемами", в отличие от тяжёлых и труднозапоминаемых буквенных мнемоник Грейвза, да и в целом учение о том, "куда нам всем дальше развиваться", в стиле похожем на Марксизм как бы отстранённо объясняющее как бы объективные тренды, но при этом и вроде как направляющее общественные стремления, оказалось как всегда востребованным, и теория (философия?) пошла в массы.
Обширные описания каждого из "цветных уровней"... Кстати, уровней чего? Говорится, уровней развития индивидуального сознания – хотя как бы это и не уровни, а просто категории, и нельзя сказать, что человек на предыдущей ступени в чём-то уступает человеку на последующей – но зачем-то же их выстроили в пирамидку?.. Но одновременно и как бы уровня общественных отношений, свойственных людям соответствующего сознания...
Так вот, обширные описания можно почитать в вики. Можно от них отмахнуться, но ради спортивного интереса можно всё же внимательно выслушать евангелистов популярной (в определённых кругах) философии (теории?), провести интенсивный "терраморфинг" предлагаемого фреймворка, населив скучные остовы более-менее очерченными феноменами и сделать краткую выжимку сути.
Выжимка по ключевым феноменам каждого из уровней будет примерно такая (нещадно сокращаю пост):
1. Бежевый уровень: нехватка физических ресурсов или, метафорически, производных ресурсов в роли как бы физических ресурсов. "Чёрная дыра" (как у того мужика из "Автострады-60") на месте определённых потребностей (как буквально пищи, так и, например, перманентная жажда денег и т.п.).
2. Фиолетовый: взаимодействие с "мистическими силами".
3. Красный: борьба по правилам за власть.
4. Синий: участие в бюрократических структурах и системах, нижестоящего ругай, перед вышестоящим заискивай.
5. Оранжевый: доминант рационального (в широком смысле научного) познания.
6. Зелёный: отождествление (с другим человеком, обществом в целом, "природой" и т.п.).
7. Жёлтый:
8. Бирюзовый: дезактивация "эго" как такового, полная идентификация с "духом" (whatever it means), распространение соответствующего знания, отношений и т.п.
Отсюда хорошо понятно, что нормальная коммерческая компания действует (в нормальном "правовом поле") на красном (и немного синем) уровне. Бизнес – это война, но, в идеале, война по правилам.
В то же время, организация, которая называет себя бирюзовой (по смыслу это просто hillarious – уморительно смешно – что-то вроде: мы зарабатываем деньги, но делаем это ради развития души), стремясь рефлекторно занять (сделать claim) вершину любой обнаруженной пирамидки, действует как бежевая: вместо борьбы "по правилами" (или хотя бы "по понятиям") она по беспределу пытается влезть с известно каким лицом в известно какой ряд. Тем самым показывая компульсивную потребность (т.е. зависимость) добиваться чего-то вроде "превосходства" – а, как уже было сказано выше, все такой интенсивности/выраженности компульсии (аддикции) – это бежевый уровень.
Зачем во всём этом разбираться? Ну, аллегорически выражаясь, если живёшь среди православных христиан, наверное, имеет смысл прочитать Библию и попробовать резюмировать для себя какие-то полезные мысли и идеи.
#psychology